[Bug c/69985] [6 Regression] ICE: in linemap_position_for_loc_and_offset, at libcpp/line-map.c:924

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
Created attachment 37812
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37812=edit
unreduced testcase

[Bug c/69985] New: [6 Regression] ICE: in linemap_position_for_loc_and_offset, at libcpp/line-map.c:924

[trippels at gcc dot gnu.org]

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

Bug ID: 69985
   Summary: [6 Regression] ICE: in
linemap_position_for_loc_and_offset, at
libcpp/line-map.c:924
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

This is a strange ICE.

trippels@gcc2-power8 foo % ~/gcc_test/usr/local/bin/gcc -w -c -Wall
cmds-check.i
cmds-check.c: In function ‘check_chunk_refs’:
cmds-check.c:7849:6: internal compiler error: in
linemap_position_for_loc_and_offset, at libcpp/line-map.c:924
  block_group_rec->flags);
  ^~~
0x110c5cb3 linemap_position_for_loc_and_offset(line_maps*, unsigned int,
unsigned int)
../../gcc/libcpp/line-map.c:924

If I move the cmds-check.i file to a different directory gcc no longer ICEs,
so reducing is impossible.

Also seen on OpenSUSE's:
https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:Gcc6/btrfsprogs/standard/ppc64le

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from Jakub Jelinek  ---
Author: jakub
Date: Sat Feb 27 06:43:20 2016
New Revision: 233777

URL: https://gcc.gnu.org/viewcvs?rev=233777=gcc=rev
Log:
PR rtl-optimization/69896
* tree-vect-generic.c (get_compute_type): Avoid single element
vector types.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-generic.c

[Bug rtl-optimization/69896] [6 Regression] wrong code with -frename-registers @ x64_64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

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

[Bug rtl-optimization/69896] [6 Regression] wrong code with -frename-registers @ x64_64

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Sat Feb 27 06:43:20 2016
New Revision: 233777

URL: https://gcc.gnu.org/viewcvs?rev=233777=gcc=rev
Log:
PR rtl-optimization/69896
* tree-vect-generic.c (get_compute_type): Avoid single element
vector types.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-generic.c

[Bug fortran/66310] Problems with intrinsic repeat for large number of copies

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle  ---
Created attachment 37811
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37811=edit
Proposed patch

This patch fixes some signed integer problems in a few places and allows the
test case to compile on my machine up to a size of 2**26 or so before I run out
of memory.

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

[wschmidt at gcc dot gnu.org]

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

--- Comment #12 from Bill Schmidt  ---
Jakub, success.  Bootstrap on powerpc64le-unknown-linux-gnu with the attachment
from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69896#c8 clears both PR69896
and this one:

2c2
< LAST_UPDATED: Fri Feb 26 23:31:56 UTC 2016 (revision 233771)
---
> LAST_UPDATED: Fri Feb 26 23:30:24 UTC 2016 (revision 233771)
26c26
< /home/wschmidt/gcc/build/gcc-mainline-base/gcc/testsuite/g++/../../xg++ 
versi
on 6.0.0 20160226 (experimental) [trunk revision 233771] (GCC) 
---
> /home/wschmidt/gcc/build/gcc-mainline-test/gcc/testsuite/g++/../../xg++  versi
on 6.0.0 20160226 (experimental) [trunk revision 233771] (GCC) 
54,57d53
< FAIL: gcc.dg/pr69896.c (internal compiler error)
< FAIL: gcc.dg/pr69896.c (test for excess errors)
< FAIL: gcc.dg/pr69896.c 12 blank line(s) in output
< UNRESOLVED: gcc.dg/pr69896.c compilation failed to produce executable
285,286d280
< FAIL: gcc.dg/torture/pr69613.c   -O0   3 blank line(s) in output
< FAIL: gcc.dg/torture/pr69613.c   -O0  (internal compiler error)
288,290d281
< UNRESOLVED: gcc.dg/torture/pr69613.c   -O0  compilation failed to produce
exec
utable
< FAIL: gcc.dg/torture/pr69613.c   -O1   3 blank line(s) in output
< FAIL: gcc.dg/torture/pr69613.c   -O1  (internal compiler error)
292,294d282
< UNRESOLVED: gcc.dg/torture/pr69613.c   -O1  compilation failed to produce
executable
< FAIL: gcc.dg/torture/pr69613.c   -O2   3 blank line(s) in output
< FAIL: gcc.dg/torture/pr69613.c   -O2  (internal compiler error)
296,298d283
< UNRESOLVED: gcc.dg/torture/pr69613.c   -O2  compilation failed to produce
executable
< FAIL: gcc.dg/torture/pr69613.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none   3 blank line(s) in output
< FAIL: gcc.dg/torture/pr69613.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (internal compiler error)
300,302d284
< UNRESOLVED: gcc.dg/torture/pr69613.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  compilation failed to produce executable
< FAIL: gcc.dg/torture/pr69613.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects   3 blank line(s) in output
< FAIL: gcc.dg/torture/pr69613.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (internal compiler error)
304,306d285
< UNRESOLVED: gcc.dg/torture/pr69613.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  compilation failed to produce executable
< FAIL: gcc.dg/torture/pr69613.c   -O3 -g   3 blank line(s) in output
< FAIL: gcc.dg/torture/pr69613.c   -O3 -g  (internal compiler error)
308,310d286
< UNRESOLVED: gcc.dg/torture/pr69613.c   -O3 -g  compilation failed to produce
executable
< FAIL: gcc.dg/torture/pr69613.c   -Os   3 blank line(s) in output
< FAIL: gcc.dg/torture/pr69613.c   -Os  (internal compiler error)
312d287
< UNRESOLVED: gcc.dg/torture/pr69613.c   -Os  compilation failed to produce
executable
331,332c306,307
< # of expected passes  100614
< # of unexpected failures  267
---
> # of expected passes  100623
> # of unexpected failures  250
335d309
< # of unresolved testcases 8

[Bug target/54349] _mm_cvtsi128_si64 unnecessary stores value at stack

[solar-gcc at openwall dot com]

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

--- Comment #11 from Alexander Peslyak  ---
Turns out that gcc 4.6.x to 4.8.x generating "movd" instead of "movq" is
actually a deliberate hack, to support binutils older than 2.17 ("movq" support
committed in 2005, released in 2006) and (presumably) non-GNU assemblers:

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

Also related, on "vmovd":

https://sourceware.org/ml/binutils/2008-05/msg00257.html

Per H.J. Lu, this is because of an error in AMD's spec for x86-64.

More detail on this cursed intrinsic: gcc got the _mm_cvtsi128_si64x() (with
'x') form before it got Intel's _mm_cvtsi128_si64() name (without 'x').  (When
using the inline asm workaround above, this does not matter as the macro brings
the without 'x' form to older gcc as well.)  Older MSVC and Open64 had bugs for
the intrinsic (without 'x'):

http://www.thesalmons.org/john/random123/releases/1.08/docs/sse_8h_source.html#l00108

This refers to https://bugs.open64.net/show_bug.cgi?id=873 for the Open64 bug,
and I had looked at it before, but unfortunately right now their bug tracker
refuses connections (for https; and gives 404 for that path with http).  I have
no detail on what the MSVC bug was.  Apparently, these could result in
incorrect computation at runtime (the comment at the URL above mentions failed
assertions).  Using _mm_extract_epi64(x, 0) is a workaround (SSE4.1+, sometimes
slower).

[Bug tree-optimization/15826] don't use "if" to extract a single bit bit-field.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #12 from Andrew Pinski  ---
You did not read my comment #8.  Please read it again and try it again.  Your
testcase does not cover the testcase mentioned in comment #6.

[Bug middle-end/19466] [meta-bug] bit-fields are non optimal

[pinskia at gcc dot gnu.org]

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

Bug 15826 Summary: don't use "if" to extract a single bit bit-field.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15826

   What|Removed |Added

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

[Bug middle-end/19987] [meta-bug] fold missing optimizations in general

[pinskia at gcc dot gnu.org]

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

Bug 15826 Summary: don't use "if" to extract a single bit bit-field.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15826

   What|Removed |Added

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

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

[wschmidt at gcc dot gnu.org]

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

--- Comment #11 from Bill Schmidt  ---
Will check now.

[Bug tree-optimization/15826] don't use "if" to extract a single bit bit-field.

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||msebor at gcc dot gnu.org
  Known to work||5.1.0, 6.0
 Resolution|--- |FIXED

--- Comment #11 from Martin Sebor  ---
It looks to me like the missing optimization now takes place, and has since
5.1. In both foo() and andrew() the bit test is optimized away during cddce2
resulting in the following.  The BIT_FIELD_REF is still there, but I assume
that's fine.  I'll go ahead, add the test case to the test suite and resolve
this as fixed.  Please reopen if I missed something.

foo (struct s * p)
{
  unsigned char _4;
  _Bool _6;
  unsigned int _7;

  :
  _4 = BIT_FIELD_REF <*p_3(D), 8, 0>;
  _6 = (_Bool) _4;
  _7 = (unsigned int) _6;
  return _7;

}

[Bug middle-end/19466] [meta-bug] bit-fields are non optimal

[msebor at gcc dot gnu.org]

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

Bug 15826 Summary: don't use "if" to extract a single bit bit-field.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15826

   What|Removed |Added

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

[Bug middle-end/19987] [meta-bug] fold missing optimizations in general

[msebor at gcc dot gnu.org]

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

Bug 15826 Summary: don't use "if" to extract a single bit bit-field.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15826

   What|Removed |Added

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

[Bug tree-optimization/15826] don't use "if" to extract a single bit bit-field.

[msebor at gcc dot gnu.org]

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

--- Comment #10 from Martin Sebor  ---
Author: msebor
Date: Fri Feb 26 23:24:29 2016
New Revision: 233771

URL: https://gcc.gnu.org/viewcvs?rev=233771=gcc=rev
Log:
PR tree-optimization/15826 - don't use "if" to extract a single bit
bit-field
2016-02-26  Martin Sebor  

PR tree-optimization/15826
* gcc.dg/tree-ssa/pr15826.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr15826.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug target/69773] gcc ICE at -O2 and above on valid code on x86_64-linux-gnu in "assign_by_spills"

[helloqirun at gmail dot com]

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

--- Comment #2 from Qirun Zhang  ---
pr65693 fails to compile at -O0 with the same (similar) trace.

$ 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 20160226 (experimental) [trunk revision 233763] (GCC) 



$ gcc-trunk pr65693.c 
pr65693.c: In function 'foo':
pr65693.c:13:1: error: unable to find a register to spill
 }
 ^
pr65693.c:13:1: error: this is the insn:
(insn 11 35 12 2 (parallel [
(set (reg:DI 96)
(udiv:DI (reg:DI 94)
(reg:DI 106)))
(set (reg:DI 107 [97])
(umod:DI (reg:DI 94)
(reg:DI 106)))
(clobber (reg:CC 17 flags))
]) pr65693.c:10 358 {*udivmoddi4}
 (expr_list:REG_UNUSED (reg:DI 107 [97])
(expr_list:REG_DEAD (reg:DI 106)
(expr_list:REG_DEAD (reg:DI 94)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil))
pr65693.c:13:1: internal compiler error: in assign_by_spills, at
lra-assigns.c:1417
0xaf9138 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:108
0x9f4515 assign_by_spills
../../gcc/gcc/lra-assigns.c:1417
0x9f4bc3 lra_assign()
../../gcc/gcc/lra-assigns.c:1590
0x9f064b lra(_IO_FILE*)
../../gcc/gcc/lra.c:2331
0x9a76f9 do_reload
../../gcc/gcc/ira.c:5396
0x9a76f9 execute
../../gcc/gcc/ira.c:5567
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug tree-optimization/69740] [5 Regression] gcc ICE at -O2 and above on valid code on x86_64-linux-gnu in "verify_loop_structure"

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #8 from Jeffrey A. Law  ---
Fixed on trunk and gcc-5 branch.

[Bug tree-optimization/69984] [4.9/5/6] Signed comparison instruction emitted for unsigned variable comparison

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Why do you think this is a bug?

Look at:
  C = A * B;


This is the same as C = (unsigned long)( ((int)A) * ((int)B) )
due to C/C++ promotion rules.  So C is less than 31bits.  E is also the same.

Use -fwrapv to say A * B is defined as wrapping or use casts to unsigned int
before doing the multiplication.

[Bug tree-optimization/69740] [5 Regression] gcc ICE at -O2 and above on valid code on x86_64-linux-gnu in "verify_loop_structure"

[law at gcc dot gnu.org]

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

--- Comment #7 from Jeffrey A. Law  ---
Author: law
Date: Fri Feb 26 22:56:02 2016
New Revision: 233769

URL: https://gcc.gnu.org/viewcvs?rev=233769=gcc=rev
Log:

PR tree-optimization/69740
* cfghooks.c (remove_edge): Request loop fixups if we delete
an edge that might turn an irreducible loop into a natural
loop.

PR tree-optimization/69740
* gcc.c-torture/compile/pr69740-1.c: New test.
* gcc.c-torture/compile/pr69740-2.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/compile/pr69740-1.c
branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/compile/pr69740-2.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/cfghooks.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/69984] New: [4.9/5/6] Signed comparison instruction emitted for unsigned variable comparison

[edmar at freescale dot com]

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

Bug ID: 69984
   Summary: [4.9/5/6] Signed comparison instruction emitted for
unsigned variable comparison
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: edmar at freescale dot com
  Target Milestone: ---

This test case has only unsigned variables and constants:

extern void bar1 (void);
extern void bar2 (void);
void foo (unsigned short int A, unsigned short int B, unsigned long D)
{
  unsigned long C;
  unsigned long E = 0x0FFFEFFEUL;

  C = A * B;

  if (C <= D)
bar1 ();
  if (C <= E)
bar2 ();
}

Yet, gcc generates signed comparison instruction (jle) for test C<=E:


.file   "ucmp.c"
.text
.p2align 4,,15
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movzwl  %si, %esi
movzwl  %di, %ebx
imull   %esi, %ebx
movslq  %ebx, %rax
cmpq%rdx, %rax
jbe .L6
.L2:
cmpl$268431358, %ebx
jle .L7
popq%rbx
.cfi_remember_state
.cfi_def_cfa_offset 8
ret
.p2align 4,,10
.p2align 3
.L7:
.cfi_restore_state
popq%rbx
.cfi_remember_state
.cfi_def_cfa_offset 8
jmp bar2
.p2align 4,,10
.p2align 3
.L6:
.cfi_restore_state
callbar1
jmp .L2
.cfi_endproc
.LFE0:
.size   foo, .-foo
.ident  "GCC: (GNU) 6.0.0 20160226 (Fri Feb 26 14:08:27 CST 2016   
 build.sh rev=1286 s=FCtrunk Nx86_64)"
.section.note.GNU-stack,"",@progbits




-fsanitize= silently corrects the code:
(I tried with *each of*: undefined, signed-integer-overflow, bounds,
unreachable, return, address. Any one will correct the code)
ex:
...
imull   %esi, %ebx
jo  .L8
.L2:
movslq  %ebx, %rbx
cmpq%rbp, %rbx
jbe .L9
.L4:
cmpq$268431358, %rbx
jbe .L10
...



and also -fno-tree-vrp:
...
imull   %ebx, %edi
movslq  %edi, %rbx
cmpq%rdx, %rbx
jbe .L6
.L2:
cmpq$268431358, %rbx
jbe .L7
...



With PowerPC target I can trace this all the way back to 4.9.2 (Did not try
4.9.[01]). 4.8.3 generates correct code.



Test compiled with:
gcc -O3 -S ucmp.c




gcc configured with:

gcc -v
Using built-in specs.
COLLECT_GCC=/local/edmar/bug_area/opt/freescale/gcc-6.0.x-Nx86_64-linux/x86_64-linux/bin/gcc
COLLECT_LTO_WRAPPER=/local/edmar/bug_area/opt/freescale/gcc-6.0.x-Nx86_64-linux/x86_64-linux/bin/../libexec/gcc/x86_64-pc-linux/6.0.0/lto-wrapper
Target: x86_64-pc-linux
Configured with: ../src_gcc/configure
--prefix=/local/edmar/bug_area//opt/freescale/gcc-6.0.x-Nx86_64-linux/x86_64-linux
--target=x86_64-pc-linux --build=x86_64-pc-linux --enable-checking
--disable-decimal-float --enable-interfaces=c,c++ --with-cpu=generic
--enable-tls --enable-build-with-cxx --enable-languages=c,c++
--with-gmp=/local/edmar/bug_area//opt/freescale/Nx86_64/linux_host_libs/usr/64
--with-target-gmp=/local/edmar/bug_area//opt/freescale/Nx86_64/linux_host_libs/tgmp/64
--disable-target-multilib
--with-mpfr=/local/edmar/bug_area//opt/freescale/Nx86_64/linux_host_libs/usr/64
--with-mpc=/local/edmar/bug_area//opt/freescale/Nx86_64/linux_host_libs/usr/64
--with-ppl=/local/edmar/bug_area//opt/freescale/Nx86_64/linux_host_libs/usr/64
--with-isl=/local/edmar/bug_area//opt/freescale/Nx86_64/linux_host_libs/usr/64
--with-cloog=/local/edmar/bug_area//opt/freescale/Nx86_64/linux_host_libs/usr/64
--enable-cloog-backend=isl
Thread model: posix
gcc version 6.0.0 20160226 (Fri Feb 26 14:08:27 CST 2016 build.sh
rev=1286 s=FCtrunk Nx86_64) (GCC) 



ucmp.c.084t.oaccdevlow:
;; Function foo (foo, funcdef_no=0, decl_uid=1760, cgraph_uid=0,
symbol_order=1)

foo (short unsigned int A, short unsigned int B, long unsigned int D)
{
  long unsigned int C;
  int _4;
  int _6;
  int _7;
  long unsigned int E.0_12;

  :
  _4 = (int) A_3(D);
  _6 = (int) B_5(D);
  _7 = _4 * _6;
  C_8 = (long unsigned int) _7;
  if (C_8 <= D_9(D))
goto ;
  else
goto ;

  :
  bar1 ();

  :
  E.0_12 = E;
  if (C_8 <= E.0_12)
goto ;
  else
goto ;

  :
  bar2 ();

  :
  return;

}


ucmp.c.086t.ccp2:
;; Function foo (foo, funcdef_no=0, decl_uid=1760, cgraph_uid=0,
symbol_order=1)

foo (short unsigned int A, short unsigned int B, long unsigned int D)
{
  long unsigned int C;
  int _4;
  int _6;
  int _7;

  :
  _4 = (int) A_3(D);
  _6 = (int) B_5(D);
  _7 = _4 * _6;
  C_8 = (long unsigned int) _7;
  if (C_8 <= D_9(D))
goto ;
  else
goto ;

  :
  bar1 ();

  :
  

[Bug target/69969] [5 Regression] Function attribute no-vsx

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-26
Summary|[5/6 Regression] Function   |[5 Regression] Function
   |attribute no-vsx|attribute no-vsx
 Ever confirmed|0   |1

--- Comment #4 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug target/69969] [5/6 Regression] Function attribute no-vsx

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Feb 26 22:35:00 2016
New Revision: 233767

URL: https://gcc.gnu.org/viewcvs?rev=233767=gcc=rev
Log:
PR target/69969
* config/rs6000/rs6000.c (rs6000_option_override_internal): Don't
complain about -mallow-movmisalign without -mvsx if
TARGET_ALLOW_MOVMISALIGN was not set explicitly.

* gcc.target/powerpc/pr69969.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr69969.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/15766] bad parse error recovery (2 bugs)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||msebor at gcc dot gnu.org
  Known to work||6.0
 Resolution|--- |FIXED
  Known to fail||

--- Comment #8 from Martin Sebor  ---
With recent trunk of 6.0 GCC prints the following diagnostics for the test
program.  I've added a test for the first diagnostic to the test suite in
r233765.  Resolving as fixed.

t.c:1:23: error: ‘A’ does not name a type
 void confusion1(const A& a) {}
   ^
t.c: In function ‘void confusion1(const int&)’:
t.c:1:26: warning: unused parameter ‘a’ [-Wunused-parameter]
 void confusion1(const A& a) {}
  ^
t.c: In function ‘void confusion2()’:
t.c:4:24: error: expected ‘)’ before ‘;’ token
 { for (int i = 0; ; i++;) {}
^
t.c:4:25: error: expected primary-expression before ‘)’ token
 { for (int i = 0; ; i++;) {}
 ^

[Bug c++/15766] bad parse error recovery (2 bugs)

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
Author: msebor
Date: Fri Feb 26 21:50:15 2016
New Revision: 233765

URL: https://gcc.gnu.org/viewcvs?rev=233765=gcc=rev
Log:
PR c++/15766 - bad parse error recovery (2 bugs)

gcc/testsuite/ChangeLog:
2016-02-26  Martin Sebor  

PR c++/15766
* g++.old-deja/g++.other/decl5.C: Add a test case.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.old-deja/g++.other/decl5.C

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

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Try https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69896#c8 ?
I'm bootstrapping/regtesting it now on x86_64-linux and i686-linux, if it fixes
even this testcase for you and you could bootstrap/regtest it on
powerpc64*-linux, it would be appreciated.

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

[wschmidt at gcc dot gnu.org]

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

--- Comment #9 from Bill Schmidt  ---
Executing on host: /home/wschmidt/gcc/build/gcc-mainline-test/gcc/xgcc
-B/home/wschmidt/gcc/build/gcc-mainline-test/gcc/
/home/wschmidt/gcc/gcc-mainline-test/gcc/testsuite/gcc.dg/torture/pr69613.c 
-fno-diagnostics-show-caret -fdiagnostics-color=never-O0-lm-o
./pr69613.exe(timeout = 300)
spawn /home/wschmidt/gcc/build/gcc-mainline-test/gcc/xgcc
-B/home/wschmidt/gcc/build/gcc-mainline-test/gcc/
/home/wschmidt/gcc/gcc-mainline-test/gcc/testsuite/gcc.dg/torture/pr69613.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -lm -o ./pr69613.exe
/home/wschmidt/gcc/gcc-mainline-test/gcc/testsuite/gcc.dg/torture/pr69613.c: In
function 'foo':
/home/wschmidt/gcc/gcc-mainline-test/gcc/testsuite/gcc.dg/torture/pr69613.c:15:1:
warning: GCC vector passed by reference: non-standard ABI extension with no
compatibility guarantee
/home/wschmidt/gcc/gcc-mainline-test/gcc/testsuite/gcc.dg/torture/pr69613.c:15:1:
error: type mismatch in binary expression
vector(1) __int128 unsigned

__int128 unsigned

vector(1) __int128 unsigned

_61 = _14 | _60;
/home/wschmidt/gcc/gcc-mainline-test/gcc/testsuite/gcc.dg/torture/pr69613.c:15:1:
internal compiler error: verify_gimple failed
0x108d7297 verify_gimple_in_cfg(function*, bool)
/home/wschmidt/gcc/gcc-mainline-test/gcc/tree-cfg.c:5125
0x1077a553 execute_function_todo
/home/wschmidt/gcc/gcc-mainline-test/gcc/passes.c:1958
0x1077b143 do_per_function
/home/wschmidt/gcc/gcc-mainline-test/gcc/passes.c:1645
0x1077b46f execute_todo
/home/wschmidt/gcc/gcc-mainline-test/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.
compiler exited with status 1

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

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||dje.gcc at gmail dot com,
   ||seurer at linux dot 
vnet.ibm.com,
   ||wschmidt at gcc dot gnu.org
 Resolution|FIXED   |---

--- Comment #8 from Bill Schmidt  ---
The new test fails with an ICE on powerpc64le-linux.gnu.

FAIL: gcc.dg/torture/pr69613.c   -O0   3 blank line(s) in output
FAIL: gcc.dg/torture/pr69613.c   -O0  (internal compiler error)
FAIL: gcc.dg/torture/pr69613.c   -O0  (test for excess errors)

etc. for various optimization levels, lto, and so on.

I'll dig up a little more data.

[Bug rtl-optimization/69896] [6 Regression] wrong code with -frename-registers @ x64_64

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Created attachment 37810
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37810=edit
gcc6-pr69896.patch

And here is the unfinished BIT_FIELD_REF folding patch.  This fixes one issue,
where we are asking for a 1x vector out of say 2x vector, and we get
incorrectly the element instead of { element }.  But that just seems to be a
tip of an iceberg - we can then end up with say VECTOR_CST with a single
element inside of a CONSTRUCTOR and might be assuming that we get the element
type instead of the 1x vector, etc.  I'd say we really should avoid the 1x
vectors at the tree/gimple levels as much as possible.

[Bug c++/69517] [5/6 regression] SEGV on a VLA with excess initializer elements

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
  Known to fail||5.3.0, 6.0

--- Comment #7 from Martin Sebor  ---
I'll look into this.

[Bug rtl-optimization/69896] [6 Regression] wrong code with -frename-registers @ x64_64

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Created attachment 37809
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37809=edit
gcc6-pr69896.patch

Ah, managed to reproduce.  I have one patch and one partial incomplete one.
It doesn't make any sense to me to use TYPE_VECTOR_SUBPARTS () == 1 vectors
for the computation if it is the widest supported vector type, we should just
use the element type instead.  So that is what this patch does.

[Bug middle-end/69983] [6 Regression] FAIL: gcc.dg/graphite/scop-sor.c scan-tree-dump-times graphite "number of SCoPs: 1" 1

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||law at redhat dot com

[Bug middle-end/69983] New: [6 Regression] FAIL: gcc.dg/graphite/scop-sor.c scan-tree-dump-times graphite "number of SCoPs: 1" 1

[hjl.tools at gmail dot com]

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

Bug ID: 69983
   Summary: [6 Regression] FAIL: gcc.dg/graphite/scop-sor.c
scan-tree-dump-times graphite "number of SCoPs:  1" 1
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

On x86, r233669 caused:

FAIL: gcc.dg/graphite/scop-sor.c scan-tree-dump-times graphite "number of
SCoPs:  1" 1

[Bug middle-end/69920] [6 Regression] FAIL: g++.dg/torture/pr42704.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #15 from Jeffrey A. Law  ---
Fixed by Martin's patch on the trunk.

[Bug tree-optimization/68714] [6 Regression] less folding of vector comparison

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

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

[Bug rtl-optimization/69896] [6 Regression] wrong code with -frename-registers @ x64_64

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Can't reproduce such ICE (with a cross).
That said, this was a RTL bug, so if it ICEs during gimple verification, IMHO
it should be tracked in a different PR.

[Bug c++/69958] sizeof... computes wrong size

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed for GCC 6.

[Bug c++/69958] sizeof... computes wrong size

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Fri Feb 26 19:54:33 2016
New Revision: 233758

URL: https://gcc.gnu.org/viewcvs?rev=233758=gcc=rev
Log:
PR c++/69958
* pt.c (make_argument_pack): New.
(tsubst_copy) [SIZEOF_EXPR]: Handle partial expansion.
(tsubst_copy_and_build): Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic-sizeof4.C
trunk/gcc/testsuite/g++.dg/cpp0x/variadic-sizeof4a.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug hsa/69674] hsa offloading, -m32: "internal compiler error: in hsa_build_append_simple_mov"

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Jambor  ---
Fixed.

[Bug c/6906] warn about asserts with side effects

[owner at bugs dot debian.org]

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

--- Comment #6 from owner at bugs dot debian.org ---
Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian GCC Maintainers 

If you wish to submit further information on this problem, please
send it to 123...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

[Bug c/66298] -Wmisleading-indentation should also detect missing indentation

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
IIRC, currently the warning is checking for guards that appear to guard a
statement, but which don't; the above examples are all for guards that don't
appear to guard a statement, but do.

[Bug c/66298] -Wmisleading-indentation should also detect missing indentation

[fw at gcc dot gnu.org]

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

--- Comment #1 from Florian Weimer  ---
Other examples.  All should receive warnings.

  while (check_something())
// do_something(); (commented out)
  do_something();

  if (check_something())
#include "/dev/null"
  do_something();

  if (check_something())
#define MACRO
  do_something();

  if (check_something())
#pragma GCC poison ignored
  do_something();

(#pragma is tricky; they sometimes count as statements, I think.)

[Bug bootstrap/69709] [6 Regression] profiled bootstrap error on s390x-linux-gnu with r233194

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #15 from Jakub Jelinek  ---
Hopefully fixed then.

[Bug c++/15538] Misleading diagnostic for recursive template instantiation

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2005-06-20 04:11:44 |2016-2-26
 CC||msebor at gcc dot gnu.org
  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #7 from Martin Sebor  ---
Reconfirmed with 5.3.0 and trunk (6.0):

$ cat x.c && /home/msebor/build/gcc-trunk-svn/gcc/xgcc
-B/home/msebor/build/gcc-trunk-svn/gcc -S -Wall -Wextra -Wpedantic -o/dev/null
-xc++ x.c
template 
struct A { typename D::Q r;};

template
struct H : A { typedef G* Q; };

H h;
x.c: In instantiation of ‘struct A’:
x.c:5:8:   required from ‘struct H’
x.c:7:9:   required from here
x.c:2:26: error: no type named ‘Q’ in ‘struct H’
 struct A { typename D::Q r;};
  ^

[Bug target/69946] [6 Regression] Invalid ppc64 assembly emitted starting with r226005

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/69958] sizeof... computes wrong size

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/69946] [6 Regression] Invalid ppc64 assembly emitted starting with r226005

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Author: segher
Date: Fri Feb 26 18:49:18 2016
New Revision: 233755

URL: https://gcc.gnu.org/viewcvs?rev=233755=gcc=rev
Log:
powerpc: Handle DImode rotatert implemented with rlwinm (PR69946)

Some DImode rotate-right-and-mask can be implemented best with a rlwinm
instruction: those that could be a lshiftrt instead of a rotatert, while
the mask is not right-aligned.  Why the rotate in the testcase is not
optimised to a plain shift is another question, but we need to handle
it here anyway.  We compute the shift amount for a 64-bit rotate.  This
is 32 too high in this case; if we print using %h that is masked out (and
this doesn't silently let through invalid instructions, everything is
checked by rs6000_is_valid_shift_mask which is much more thorough).


PR target/69946
* config/rs6000/rs6000.c (rs6000_insn_for_shift_mask): Print rlwinm
shift amount using %h.  Add comment.

gcc/testsuite/
* gcc.target/powerpc/pr69946.c: New file.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr69946.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog

[Bug target/69841] Wrong template instantiation in C++11 on armv7l

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #4 from James Greenhalgh  ---
Goes away on trunk after r223301

Author: jason 
Date:   Mon May 18 17:14:11 2015 +

DR 1391
* pt.c (type_unification_real): Check convertibility here.
(unify_one_argument): Not here.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@223301 

After which the DECL_ALIGN in both TUs is 64, fixing the bug.

[Bug middle-end/69920] [6 Regression] FAIL: g++.dg/torture/pr42704.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)

[jamborm at gcc dot gnu.org]

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

--- Comment #14 from Martin Jambor  ---
(In reply to Dominik Vogt from comment #12)
> The Ice in 42704.c is gone on s390[x] with trunk (but not the other FAILs). 
> Is the Ice below related to this bug report or is it something totally
> different?

As far as I understand the backtrace, the ICE happens in a traversal
of an expression that is not extracted from the gimple IL function
body and that is not an SSA_NAME (and is 3-levels deep).  So I'd be
surprised if it was the same issue.

[Bug middle-end/69976] Zero the local stack on function exit

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
I think you should read the discussion starting at 
 and see how your ideas 
compare to it, then maybe try to restart that discussion and get consensus 
on a suitable API approach.

[Bug tree-optimization/69740] [5/6 Regression] gcc ICE at -O2 and above on valid code on x86_64-linux-gnu in "verify_loop_structure"

[law at gcc dot gnu.org]

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

--- Comment #6 from Jeffrey A. Law  ---
Author: law
Date: Fri Feb 26 18:17:02 2016
New Revision: 233754

URL: https://gcc.gnu.org/viewcvs?rev=233754=gcc=rev
Log:
PR tree-optimization/69740
* cfghooks.c (remove_edge): Request loop fixups if we delete
an edge that might turn an irreducible loop into a natural
loop.

PR tree-optimization/69740
* gcc.c-torture/compile/pr69740-1.c: New test.
* gcc.c-torture/compile/pr69740-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr69740-1.c
trunk/gcc/testsuite/gcc.c-torture/compile/pr69740-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfghooks.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/69920] [6 Regression] FAIL: g++.dg/torture/pr42704.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)

[jamborm at gcc dot gnu.org]

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

--- Comment #13 from Martin Jambor  ---
Author: jamborm
Date: Fri Feb 26 18:06:42 2016
New Revision: 233753

URL: https://gcc.gnu.org/viewcvs?rev=233753=gcc=rev
Log:
[PR 69920] Prevent SRA from leaving a removed SSA_NAME in IL

2016-02-26  Martin Jambor  

PR middle-end/69920
* tree-sra.c (sra_modify_assign): Do not remove loads of
uninitialized aggregates to SSA_NAMEs.

testsuite/
* gcc.dg/torture/pr69932.c: New test.
* gcc.dg/torture/pr69936.c: Likewise.


Added:
trunk/gcc/testsuite/gcc.dg/torture/pr69932.c
trunk/gcc/testsuite/gcc.dg/torture/pr69936.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c

[Bug bootstrap/69709] [6 Regression] profiled bootstrap error on s390x-linux-gnu with r233194

[krebbel at gcc dot gnu.org]

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

--- Comment #14 from Andreas Krebbel  ---
Author: krebbel
Date: Fri Feb 26 18:03:51 2016
New Revision: 233752

URL: https://gcc.gnu.org/viewcvs?rev=233752=gcc=rev
Log:
S/390: PR69709 Fix risbg splitter

This fixes a wrong code generation problem with the splitters introduced
with that patch: https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01840.html

The target operand is used as temporary.  This fails if it matches the
source of the left shift which is read after writing the temporary.

Thanks to Dominik for debugging it and thanks to Richard for the fix!

Bootstrapped and regtested on s390x with-arch=z13.

Bye,

-Andreas-

gcc/ChangeLog:

2016-02-26  Richard Henderson  

PR target/69709
* config/s390/s390.md (risbg and risbgn splitters): Allocate new
pseudo in case the target rtx matches the source of the left
shift.

gcc/testsuite/ChangeLog:

2016-02-26  Andreas Krebbel  

PR target/69709
* gcc.target/s390/pr69709.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/s390/pr69709.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/s390.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/15369] "Wrong" line number for static constructor function

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||msebor at gcc dot gnu.org
  Known to work||5.3.0, 6.0
 Resolution|--- |FIXED

--- Comment #9 from Martin Sebor  ---
This problem seems to have cleared up.  GDB prints the correct file name and
line number, and I don't see any obvious problems in the line number program
emitted by GCC.  I'm resolving this as fixed.  Please reopen it if I missed
something and the problem still persists in some form.

$ g++ -g tx_linenumber.cxx && gdb -batch -q -ex 'b tx_linenumber.cxx:10' -ex
'r' a.out
Breakpoint 1 at 0x40079a: file tx_linenumber.cxx, line 10.

Breakpoint 1, test::break_point (this=0x7fffde50) at tx_linenumber.cxx:10
10void break_point() { int b=_b; }

$ readelf -wl a.out | grep 'Set File Name'
  [0x02fc]  Set File Name to entry 2 in the File Name Table
  [0x0302]  Set File Name to entry 1 in the File Name Table

and

$ readelf -wl a.out | sed -n '/ The File Name Table/,/^  2[[:blank:]]/p'
 The File Name Table (offset 0x193):
  Entry Dir TimeSizeName
  1 0   0   0   tx_linenumber.cxx
  2 1   0   0   iostream

[Bug hsa/69568] Invalid HSAIL opcode when using builtin vector

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  ---
Fixed on trunk.  The hsa branch will pick this up next week as a part
of a merge from trunk.

[Bug hsa/69568] Invalid HSAIL opcode when using builtin vector

[jamborm at gcc dot gnu.org]

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

--- Comment #2 from Martin Jambor  ---
Author: jamborm
Date: Fri Feb 26 17:48:19 2016
New Revision: 233751

URL: https://gcc.gnu.org/viewcvs?rev=233751=gcc=rev
Log:
[hsa/69568] Fix ld instruction type for packed data

2016-02-26  Martin Jambor  

PR hsa/69568
* hsa.h (hsa_type_packed_p): Declare.
* hsa.c (hsa_type_packed_p): New function.
* hsa-gen.c (mem_type_for_type): Use unsigned type for packed
loads.
(gen_hsa_insns_for_store): Use hsa_type_packed_p.
* hsa-brig.c (emit_basic_insn): Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/hsa-brig.c
trunk/gcc/hsa-gen.c
trunk/gcc/hsa.c
trunk/gcc/hsa.h

[Bug hsa/69674] hsa offloading, -m32: "internal compiler error: in hsa_build_append_simple_mov"

[jamborm at gcc dot gnu.org]

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

--- Comment #2 from Martin Jambor  ---
Author: jamborm
Date: Fri Feb 26 17:45:37 2016
New Revision: 233750

URL: https://gcc.gnu.org/viewcvs?rev=233750=gcc=rev
Log:
[hsa/69674] Make testsuite libgomp.c/for-3.c compile with -m32

2016-02-26  Martin Jambor  

pr hsa/69674
* hsa-gen.c (gen_hsa_phi_from_gimple_phi): Use proper hsa type for
pointers.
(gen_hsa_addr): Allow integer constants in TMR_INDEX2.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/hsa-gen.c

[Bug go/69966] libgo: Port syscall.SetsockoptUcred from golang

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
Fixed on mainline, thanks.

[Bug middle-end/69920] [6 Regression] FAIL: g++.dg/torture/pr42704.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)

[vogt at linux dot vnet.ibm.com]

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

--- Comment #12 from Dominik Vogt  ---
The Ice in 42704.c is gone on s390[x] with trunk (but not the other FAILs).  Is
the Ice below related to this bug report or is it something totally different?

.../gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c: In function 'main':^M 
.../gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c:45:1: internal compiler error:
Segmentation fault^M 
0x8061ac19 crash_signal^M 
../../gcc/toplev.c:335^M 
0x80a6305e translate_isl_ast_to_gimple::collect_all_ssa_names(tree_node*,
vec*)^M 
../../gcc/graphite-isl-ast-to-gimple.c:1408^M 
0x80a630a9 translate_isl_ast_to_gimple::collect_all_ssa_names(tree_node*,
vec*)^M 
../../gcc/graphite-isl-ast-to-gimple.c:1418^M 
0x80a630a9 translate_isl_ast_to_gimple::collect_all_ssa_names(tree_node*,
vec*)^M 
../../gcc/graphite-isl-ast-to-gimple.c:1418^M 
0x80a630a9 translate_isl_ast_to_gimple::collect_all_ssa_names(tree_node*,
vec*)^M 
../../gcc/graphite-isl-ast-to-gimple.c:1418^M 
0x80a647e3 translate_isl_ast_to_gimple::rename_all_uses(tree_node*,
basic_block_def*, basic_block_def*)^M 
../../gcc/graphite-isl-ast-to-gimple.c:1569^M 
0x80a64989 translate_isl_ast_to_gimple::get_rename_from_scev(tree_node*,
gimple**, loop*, basic_block_def*, basic_block_def*, vec)^M 
../../gcc/graphite-isl-ast-to-gimple.c:1623^M 
0x80a66af9 translate_isl_ast_to_gimple::rename_uses(gimple*,
gimple_stmt_iterator*, basic_block_def*, loop*, vec)^M 
../../gcc/graphite-isl-ast-to-gimple.c:1730^M 
0x80a683c5
translate_isl_ast_to_gimple::graphite_copy_stmts_from_block(basic_block_def*,
basic_block_def*, vec\
)^M 
../../gcc/graphite-isl-ast-to-gimple.c:2596^M 
0x80a68943
translate_isl_ast_to_gimple::copy_bb_and_scalar_dependences(basic_block_def*,
edge_def*, vec)^M 
../../gcc/graphite-isl-ast-to-gimple.c:2809^M 
0x80a68f4d
translate_isl_ast_to_gimple::translate_isl_ast_node_user(isl_ast_node*,
edge_def*, std::map, std::allocator > >&)^M 
../../gcc/graphite-isl-ast-to-gimple.c:935^M 
0x80a692ed translate_isl_ast_to_gimple::translate_isl_ast_for_loop(loop*,
isl_ast_node*, edge_def*, tree_node*, tree_node*, tree_node*, std\
::map, std::allocator > >&)^M 
../../gcc/graphite-isl-ast-to-gimple.c:685^M 
0x80a6956f translate_isl_ast_to_gimple::translate_isl_ast_node_for(loop*,
isl_ast_node*, edge_def*, std::map, std::allocator > >&)^M 
../../gcc/graphite-isl-ast-to-gimple.c:854^M 
0x80a69209 translate_isl_ast_to_gimple::translate_isl_ast(loop*, isl_ast_node*,
edge_def*, std::map\
, std::allocator > >&)^M 
../../gcc/graphite-isl-ast-to-gimple.c:1032^M 
0x80a696b1 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*,
isl_ast_node*, edge_def*, std::map, std::allocator > >&)^M 
../../gcc/graphite-isl-ast-to-gimple.c:964^M 
0x80a691c1 translate_isl_ast_to_gimple::translate_isl_ast(loop*, isl_ast_node*,
edge_def*, std::map\
, std::allocator > >

[Bug go/69966] libgo: Port syscall.SetsockoptUcred from golang

[ian at gcc dot gnu.org]

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

--- Comment #1 from ian at gcc dot gnu.org  ---
Author: ian
Date: Fri Feb 26 17:36:00 2016
New Revision: 233747

URL: https://gcc.gnu.org/viewcvs?rev=233747=gcc=rev
Log:
PR go/69966
syscall: Add new Getsockopt functions.

Add GetsockoptICMPv6Filter, GetsockoptIPv6MTUInfo, GetsockoptUcred as
appropriate.  These functions exist in the master library.

For GCC PR 69966.

Reviewed-on: https://go-review.googlesource.com/19960

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/go/syscall/socket.go
trunk/libgo/go/syscall/socket_bsd.go
trunk/libgo/go/syscall/socket_linux.go
trunk/libgo/mksysinfo.sh

[Bug fortran/69964] ICE on misspelled end block data, in gfc_ascii_statement

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

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

[Bug fortran/69962] ICE on missing parameter attribute, in gfc_set_constant_character_len

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

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

[Bug middle-end/69920] [6 Regression] FAIL: g++.dg/torture/pr42704.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)

[jamborm at gcc dot gnu.org]

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

--- Comment #11 from Martin Jambor  ---
I have proposed a fix on the mailing list:

https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01824.html

[Bug middle-end/69976] Zero the local stack on function exit

[daniel.gutson at tallertechnologies dot com]

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

--- Comment #3 from Daniel Gutson  
---
Those are very good ideas but fell into the land of the backend. The red zone
IIUC is a x86_64 only ABI concept.
What do you think about adding also a -m counterpart option with the same
semantic but for the backend?
Our plan is to address separately the middle end part and the backend part
(initially for x86_64) and subdivide the latter in clobbered registers and red
zone cleaning, so 3 sets of patches.

[Bug rtl-optimization/69891] wrong code with -mstringop-strategy=libcall @ i686

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug rtl-optimization/69942] gcc.dg/ifcvt-5.c FAILs

[ysrumyan at gmail dot com]

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

--- Comment #1 from Yuri Rumyantsev  ---
The cause of issue is that before ce1 phase pde (or pre) transformation has
been done to remove partial redundant moves to variable i and j, i.e.
code
  int i = x;
  int j = y;
  if (x > y)
{
  i = a;'
  j = i;
}
has been transformed to
  int i,j;
  if (x > y)
{
  i = a;
  j = i;
}
  else
{
  i = x;
  i = y;
}
and ifcvt phase does speculative motion else-part before if-part, i.e. to
original code. This transformation is considered as true change and test is
failed. I assume that test must accept also '6 basic blocks,' to get test
passed.

[Bug c/69981] -f[no]keep-static-consts has no effect

[equinox-gccbugs at diac24 dot net]

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

--- Comment #6 from David L.  ---
Created attachment 37808
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37808=edit
patch (gcc-5.3.0)

patch attached (probably makes the user's PC explode and burns down their
house)

varpool_node::finalize_decl (tree decl)
-node->force_output = true;
+node->force_output = !TREE_READONLY (decl) || flag_keep_static_consts;

[Bug target/69245] [6 Regression] ICE in extract_insn, at recog.c:2286 on arm-linux-gnueabihf

[ktkachov at gcc dot gnu.org]

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

--- Comment #16 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Fri Feb 26 16:02:21 2016
New Revision: 233745

URL: https://gcc.gnu.org/viewcvs?rev=233745=gcc=rev
Log:
[AArch64] Set TREE_TARGET_GLOBALS in aarch64_set_current_function when new tree
is the default node to recalculate optab availability

PR target/69245
* config/aarch64/aarch64.c (aarch64_set_current_function):
Save/restore target globals when switching to
target_option_default_node.

* gcc.target/aarch64/pr69245_1.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/aarch64/pr69245_1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/testsuite/ChangeLog

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

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from ktkachov at gcc dot gnu.org ---
Fixed on trunk.

[Bug fortran/56981] Slow I/O: Unformatted 5x slower, large sys component; formatted slow as well

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #14 from Jerry DeLisle  ---
Nothing, closing

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

[ktkachov at gcc dot gnu.org]

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

--- Comment #6 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Fri Feb 26 15:59:45 2016
New Revision: 233744

URL: https://gcc.gnu.org/viewcvs?rev=233744=gcc=rev
Log:
[AArch64] PR target/69613: Return zero TARGET_SHIFT_TRUNCATION_MASK when
SHIFT_COUNT_TRUNCATED is false

PR target/69613
* config/aarch64/aarch64.c (aarch64_shift_truncation_mask):
Return 0 if !SHIFT_COUNT_TRUNCATED.

* gcc.dg/torture/pr69613.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr69613.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/69891] wrong code with -mstringop-strategy=libcall @ i686

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Author: jakub
Date: Fri Feb 26 15:53:43 2016
New Revision: 233743

URL: https://gcc.gnu.org/viewcvs?rev=233743=gcc=rev
Log:
PR rtl-optimization/69891
* dse.c (scan_insn): If we can't figure out memset arguments
or they are non-constant, call clear_rhs_from_active_local_stores.

* gcc.target/i386/pr69891.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr69891.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dse.c
trunk/gcc/testsuite/ChangeLog

[Bug target/61397] [4.9/5/6 regression] FAIL: gcc.target/powerpc/p8vector-ldst.c scan-assembler lxsdx

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #18 from Bill Schmidt  ---
I've applied Mike's test case patch to GCC 5 and GCC 6.

[Bug c/69982] missing warning when using __thread with -std=c99 -pedantic

[vincent-gcc at vinc17 dot net]

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

--- Comment #3 from Vincent Lefèvre  ---
(In reply to Jakub Jelinek from comment #2)
> [...] and __thread uses the implementation namespace, [...]

Is this really the implementation namespace?

The C standard says: "All identifiers that begin with an underscore and either
an uppercase letter or another underscore are always reserved for any use." so
that there doesn't seem to be a difference between __thread (underscore +
underscore) and _Thread_local (underscore + uppercase letter).

What if the C committee decided to choose __thread instead of _Thread_local?

[Bug c/69981] -f[no]keep-static-consts has no effect

[equinox-gccbugs at diac24 dot net]

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

--- Comment #5 from David L.  ---
(In reply to David L. from comment #4)
> Poking around a bit, in wrapup_global_declaration_2() in gcc/toplev.c, the
> check for
>else if (TREE_READONLY (decl) && !TREE_PUBLIC (decl)  
>&& (optimize || !flag_keep_static_consts  
>|| DECL_ARTIFICIAL (decl)))
> is never hit because the earlier
>   else if (node && node->definition)
> 
> needed = false;
> is taken (on both -O0 or -O1).
> 
> Thus, the value of flag_keep_static_consts is irrelevant (and this is the
> only place in the code where it's used...)

If I put a "static const int intvalnoinit;" into my test source,
-fno-keep-static-consts does actually have an effect on that.

It seems a little counterintuitive to me though that static consts only get
removed if they have no initialiser...

[Bug c/69982] missing warning when using __thread with -std=c99 -pedantic

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Well, there is a difference, __thread is an extension, while _Thread_local is
standard in a later version of the standard, and __thread uses the
implementation namespace, so it is similar for the compiler not complaining
about __attribute__((__noinline__)) even in -std=c99 -pedantic, or about
__extension__ etc.

[Bug lto/69953] [5/6 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

  Known to work||4.9.2
Summary|Using lto causes|[5/6 Regression] Using lto
   |gtkmm/gparted and   |causes gtkmm/gparted and
   |gtkmm/inkscape compile to   |gtkmm/inkscape compile to
   |fail|fail
  Known to fail||5.1.0, 6.0

--- Comment #11 from Markus Trippelsdorf  ---
Here's another testcase that only produces a local symbol for all -O levels
with -flto:


namespace Glib {
class A {};
class Object : virtual A {
protected:
  ~Object();
};
class B : virtual A {};
}
class C : Glib::Object {};
namespace Gtk {
class D : Glib::B {};
class TreeViewColumn : C, D {
  virtual ~TreeViewColumn();
};
TreeViewColumn::~TreeViewColumn() {}
}

[Bug c/69982] missing warning when using __thread with -std=c99 -pedantic

[vincent-gcc at vinc17 dot net]

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

--- Comment #1 from Vincent Lefèvre  ---
Note: This actually means that a program that switches from __thread to
_Thread_local (which could be regarded as more portable) could suddenly fail to
build with "-std=c99 -pedantic -Werror".

[Bug target/69969] [5/6 Regression] Function attribute no-vsx

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Created attachment 37807
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37807=edit
gcc6-pr69969.patch

Untested fix.

[Bug c/69981] -f[no]keep-static-consts has no effect

[equinox-gccbugs at diac24 dot net]

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

--- Comment #3 from David L.  ---
Poking around a bit, in wrapup_global_declaration_2() in gcc/toplev.c, the
check for
  else if (TREE_READONLY (decl) && !TREE_PUBLIC (decl)  
  && (optimize || !flag_keep_static_consts 
»   »  || DECL_ARTIFICIAL (decl)))

[Bug c/69982] New: missing warning when using __thread with -std=c99 -pedantic

[vincent-gcc at vinc17 dot net]

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

Bug ID: 69982
   Summary: missing warning when using __thread with -std=c99
-pedantic
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

When I compile the following program with -std=c99 -pedantic, I get a warning
for _Thread_local but not for __thread while both are invalid in C99. This is
not consistent!

__thread int x;
_Thread_local int y;

int main(void)
{
  return 0;
}

I get:

$ gcc-snapshot -std=c99 -pedantic tst.c -o tst
tst.c:2:1: warning: ISO C99 does not support '_Thread_local' [-Wpedantic]
 _Thread_local int y;
 ^

This occurs with:
gcc (Debian 20160125-1) 6.0.0 20160125 (experimental) [trunk revision 232803]
and previous versions such as 4.9.3 and 5.3.1.

[Bug c/69981] -f[no]keep-static-consts has no effect

[equinox-gccbugs at diac24 dot net]

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

--- Comment #4 from David L.  ---
Argh, for some reason this submitted in the middle of editing...

Poking around a bit, in wrapup_global_declaration_2() in gcc/toplev.c, the
check for
   else if (TREE_READONLY (decl) && !TREE_PUBLIC (decl)  
   && (optimize || !flag_keep_static_consts  
   || DECL_ARTIFICIAL (decl)))
is never hit because the earlier
  else if (node && node->definition)
needed = false;
is taken (on both -O0 or -O1).

Thus, the value of flag_keep_static_consts is irrelevant (and this is the only
place in the code where it's used...)

[Bug middle-end/69920] [6 Regression] FAIL: g++.dg/torture/pr42704.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)

[jamborm at gcc dot gnu.org]

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

--- Comment #10 from Martin Jambor  ---
I am currently bootstrapping and testing the fix I posted as:

https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01656.html

I am confident it will fix all of these problems (provided the issue
is a SSA_NAME still in the IL).

[Bug middle-end/69920] [6 Regression] FAIL: g++.dg/torture/pr42704.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)

[vogt at linux dot vnet.ibm.com]

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

--- Comment #9 from Dominik Vogt  ---
(Fails only with -m31.)

[Bug middle-end/69920] [6 Regression] FAIL: g++.dg/torture/pr42704.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)

[vogt at linux dot vnet.ibm.com]

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

Dominik Vogt  changed:

   What|Removed |Added

 CC||vogt at linux dot vnet.ibm.com

--- Comment #8 from Dominik Vogt  ---
Also failing on s390 and s390x; the same bug possibly causes several other test
failures:

FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error) 
FAIL: gcc.dg/tree-ssa/pr69666.c (internal compiler error)

Maybe these too:

FAIL: gfortran.dg/reassoc_6.f   -O   scan-tree-dump-not optimized "~"
FAIL: gcc.dg/graphite/scop-sor.c scan-tree-dump-times graphite "number of
SCoPs\
: 1" 1

[Bug c/69796] [6 Regression] ICE on invalid code in useless_type_conversion_p, at gimple-expr.c:83

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||helloqirun at gmail dot com

--- Comment #6 from Jakub Jelinek  ---
*** Bug 69974 has been marked as a duplicate of this bug. ***

[Bug c/69974] [6 Regression] gcc ICE on invalid code on x86_64-linux-gnu in "create_tmp_from_val"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Same reason for ICE as PR69796.

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

[Bug c++/69889] [6 Regression] ICE: in assign_temp, at function.c:961

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/69980] [6 regression] Supposedly wrong SLP code emitted

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug fortran/67451] [5/6 Regression] [F08] ICE with sourced allocation from coarray.

[vogt at linux dot vnet.ibm.com]

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

--- Comment #15 from Dominik Vogt  ---
The problem is gone on today's trunk for s390 and s390x.

[Bug middle-end/69920] [6 Regression] FAIL: g++.dg/torture/pr42704.C -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Target|i?86-*-*|i?86-*-* powerpc*-*-*
   ||arm*-*-*
 CC||dje at gcc dot gnu.org,
   ||seurer at linux dot 
vnet.ibm.com,
   ||wschmidt at gcc dot gnu.org

--- Comment #7 from David Edelsohn  ---
This also is failing for powerpc for -m32 multilib, AIX, and I also see on AIX.

g++.dg/torture/pr42704.C: In member function 'void
nsTreeRows::InvalidateCachedRow()':
g++.dg/torture/pr42704.C:44:1: internal compiler error: tree check: expected
class 'type', have 'exceptional' (error_mark) in get_ref_base_and_extent, at
tree-dfa.c:394

[Bug c/69981] -f[no]keep-static-consts has no effect

[equinox-gccbugs at diac24 dot net]

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

--- Comment #2 from David L.  ---
(In reply to Jakub Jelinek from comment #1)
> I disagree, removing static consts is an optimization, if you tell the
> compiler not to optimize, it doesn't perform the optimizations.

Documentation bug then?  It says it's independent of optimization.


-fkeep-static-consts
Emit variables declared static const when optimization isn't turned on,
even if the variables aren't referenced.

GCC enables this option by default. If you want to force the compiler to
check if a variable is referenced, regardless of whether or not
optimization
is turned on, use the -fno-keep-static-consts option.

[Bug c/69981] -f[no]keep-static-consts has no effect

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I disagree, removing static consts is an optimization, if you tell the compiler
not to optimize, it doesn't perform the optimizations.

[Bug c/69981] New: -f[no]keep-static-consts has no effect

[equinox-gccbugs at diac24 dot net]

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

Bug ID: 69981
   Summary: -f[no]keep-static-consts has no effect
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: equinox-gccbugs at diac24 dot net
  Target Milestone: ---

This bug is an extension of #20319; the -fkeep-static-consts option seems to
have no effect in either direction.  (#20319 was focused on the "-fkeep"
variant; my issue is with -O0 -fno-keep-static-consts.)

My application code is
extern struct foo ref;
static struct foo * const myconst = 
Where ref is defined in a library that is not always linked in, which works on
-O1 -Og -Os -O2 -O3 but not on "-O0 -fno-keep-static-consts".  I think it
should.

Trying older versions, gcc-4.2.4 already behaves the same.


$ ./test.sh
gcc-4.9.3 -O0
 l O .rodata0004 intval
 l O .data.rel.ro   0008 ptrval
gcc-4.9.3 -O0 -fkeep-static-consts
 l O .rodata0004 intval
 l O .data.rel.ro   0008 ptrval
gcc-4.9.3 -O0 -fno-keep-static-consts
 l O .rodata0004 intval
 l O .data.rel.ro   0008 ptrval
gcc-4.9.3 -O1
gcc-4.9.3 -O1 -fkeep-static-consts
gcc-4.9.3 -O1 -fno-keep-static-consts
gcc-5.3.0 -O0
 l O .rodata0004 intval
 l O .data.rel.ro   0008 ptrval
gcc-5.3.0 -O0 -fkeep-static-consts
 l O .rodata0004 intval
 l O .data.rel.ro   0008 ptrval
gcc-5.3.0 -O0 -fno-keep-static-consts
 l O .rodata0004 intval
 l O .data.rel.ro   0008 ptrval
gcc-5.3.0 -O1
gcc-5.3.0 -O1 -fkeep-static-consts
gcc-5.3.0 -O1 -fno-keep-static-consts

$ cat test.sh
#!/bin/sh

cat >const.c <

[Bug tree-optimization/69980] [6 regression] Supposedly wrong SLP code emitted

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-26
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

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

[Bug tree-optimization/69980] New: [6 regression] Supposedly wrong SLP code emitted

[kyukhin at gcc dot gnu.org]

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

Bug ID: 69980
   Summary: [6 regression] Supposedly wrong SLP code emitted
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kyukhin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 37806
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37806=edit
Reproducer

Hello,
Attached test runfails when compiled is following:
$ gfortran -m64 -Ofast repro.f90 -msse

When compiled w/ -O2  - it works fine.

Second loop nest is just for verification.

Issue lives here:
  mumax = 0;
  do k=1,26
 do i=1,3
mumax(i) = max(mumax(i), mu(i,k)+mu(i,k))
 end do
  end do

Looks like SLP emits some wrong permutations here.

[Bug target/69979] New: ARM naked function attribute not handling structs bigger than 32 bits correctly

[andre.simoesdiasvieira at arm dot com]

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

Bug ID: 69979
   Summary: ARM naked function attribute not handling structs
bigger than 32 bits correctly
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andre.simoesdiasvieira at arm dot com
  Target Milestone: ---

As reported by Cory in https://bugs.launchpad.net/gcc-arm-embedded/+bug/1549542
It seems the naked function attribute for ARM is generating code for struct
parameters being passed in registers. This code stores these structs being
passed as registers on the stack, using 'r3' as a scratch register. Apart from
being suboptimal, this writes to 'r3' even though 'r3' might be used to hold a
parameter!

For instance with the following C code:
struct test {
  int a;
  int b;
};

int
foo (struct test t, int a, int b)
{
  __asm ("mov r0, r3\n\t"
 "bx  lr");
}

when compiled with
$arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -S

will yield the following assembly:
foo:
@ Naked Function: prologue and epilogue provided by programmer.
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 1, uses_anonymous_args = 0
mov r3, r7
stm r3, {r0, r1}
.syntax unified
@ 9 "tnaked.c" 1
mov r0, r3
bx lr
@ 0 "" 2
.syntax unified
nop
mov r0, r3

As you see 'r3' will have been rewritten with the frame pointer before being
moved to 'r0' for the return. Also the last 'mov r0, r3' after the 'nop' looks
a bit odd!

Something equally weird happens when returning such a struct:

struct test
bar (int a, int b, int c)
{
__asm ("stmia r0, {r2, r3}\n\t"
   "bx lr");
}

One would naturally expect to be storing 'b' and 'c' into '[r0]', the place
where the caller expects the return value to be written to. However the
following assembly is generated, which overwrites r3 (which should contain
argument 'c'):

bar:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mov r3, r0
@ 16 "tnaked.c" 1
stmia r0, {r2, r3}
bx lr
@ 0 "" 2
.thumb
mov r0, r3
bx  lr

Again with the unexpected epilogue code creeping in.

I have observed this behavior for various ARM targets dating back to gcc 4.8
(haven't tried earlier than that).

[Bug c++/69958] sizeof... computes wrong size

[yanikibo at yandex dot com]

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

--- Comment #3 from Ibrahim Gokhan YANIKLAR  ---
*** Bug 69978 has been marked as a duplicate of this bug. ***

[Bug c++/69978] Invalid sizeof... value for variadic template arguments

[yanikibo at yandex dot com]

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

Ibrahim Gokhan YANIKLAR  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Ibrahim Gokhan YANIKLAR  ---
It's duplicate of PR 69958

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

[Bug c++/69958] sizeof... computes wrong size

[yanikibo at yandex dot com]

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

Ibrahim Gokhan YANIKLAR  changed:

   What|Removed |Added

 CC||yanikibo at yandex dot com

--- Comment #2 from Ibrahim Gokhan YANIKLAR  ---
#include 

template < std::size_t N >
struct A {  enum : std::size_t {  value = N  };  };

template < class... TL >
using B = A< sizeof...(TL) >;

template < class T >
struct C {  using type = T;  };

template < class... TL >
using D = typename C< B >::type;

template < class T, class U, class... TL >
void foo( T, U, TL... )
{
std::cout << (B::value) << std::endl;
std::cout << (D::value) << std::endl;
std::cout << (C< B >::type::value) << std::endl;
}

int main()
{
foo(10, 20, 30, 40, 50);
}

//---
// output(g++4.7):
//---
// 3
// 3
// 3

//---
// output(g++4.8-g++5.3):
//---
// 5
// 5
// 3

//---
// output(correct)
//---
// 5
// 5
// 5