[Bug c++/69029] New: [6 Regression] bogus -Wmisleading-indentation warning on one-line loops

[trippels at gcc dot gnu.org]

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

Bug ID: 69029
   Summary: [6 Regression] bogus -Wmisleading-indentation warning
on one-line loops
   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
CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

markus@x4 tmp % cat while.cpp
int main() {
  int i = 0;
  do i++; while (i < 3);
}

markus@x4 tmp % g++ -Wall -c while.cpp
while.cpp: In function ‘int main()’:
while.cpp:3:11: warning: statement is indented as if it were guarded by...
[-Wmisleading-indentation]
   do i++; while (i < 3);
   ^

while.cpp:3:3: note: ...this ‘do’ clause, but it is not
   do i++; while (i < 3);
   ^~

[Bug middle-end/68999] [6 Regression]: FAIL: gfortran.fortran-torture/execute/save_1.f90 execution

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com

--- Comment #7 from Uroš Bizjak  ---
Patch at [1].

[1] https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02082.html

[Bug target/69012] gcc-6.0.0 internal compiler error building libgfortran for mips64el target

[bernd.edlinger at hotmail dot de]

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

--- Comment #3 from Bernd Edlinger  ---
I will have a look, but please,
can you attach a preprocessed source for maxval_r4.c


Thanks.

[Bug target/66232] -fPIC -fno-plt -mx32 fails to generate indirect branch via GOT

[uros at gcc dot gnu.org]

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

--- Comment #8 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Dec 23 09:49:28 2015
New Revision: 231923

URL: https://gcc.gnu.org/viewcvs?rev=231923=gcc=rev
Log:
[PATCH] Allow indirect call via GOT for 64-bit Pmode x32

From: H.J. Lu  

Since Pmode is 64-bit with -maddress-mode=long for x32, indirect call
via GOT slot doesn't need zero_extend.  This patch enables indirect call
via GOT for x32 with 64-bit Pmode.

gcc/

PR target/66232
* config/i386/constraints.md (Bs): Allow GOT slot for x32 with
64-bit Pmode.
(Bw): Likewise.
(Bz): Likewise.
* config/i386/predicates.md (call_insn_operand): Likewise.
(sibcall_insn_operand): Likewise.

gcc/testsuite/

PR target/66232
* gcc.target/i386/pr66232-10.c: New test.
* gcc.target/i386/pr66232-11.c: Likewise.
* gcc.target/i386/pr66232-12.c: Likewise.
* gcc.target/i386/pr66232-13.c: Likewise.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr66232-10.c
trunk/gcc/testsuite/gcc.target/i386/pr66232-11.c
trunk/gcc/testsuite/gcc.target/i386/pr66232-12.c
trunk/gcc/testsuite/gcc.target/i386/pr66232-13.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/constraints.md
trunk/gcc/config/i386/predicates.md
trunk/gcc/testsuite/ChangeLog

[Bug target/69014] [4.9/5/6 Regression] gcc.c-torture/execute/991023-1.c FAILs with -Os -fmodulo-sched -fno-tree-vrp

[ktkachov at gcc dot gnu.org]

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Created attachment 37112
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37112=edit
dom1 tree dump from 4.8

[Bug target/69014] [4.9/5/6 Regression] gcc.c-torture/execute/991023-1.c FAILs with -Os -fmodulo-sched -fno-tree-vrp

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Created attachment 37113
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37113=edit
dom1 tree dump from 4.9

[Bug target/69014] [4.9/5/6 Regression] gcc.c-torture/execute/991023-1.c FAILs with -Os -fmodulo-sched -fno-tree-vrp

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #4 from ktkachov at gcc dot gnu.org ---
I'm still looking into why the wrong-code occurs but there's a code quality
regression between 4.8 and 4.9 at the tree-level.
At expand time for 4.8 the function foo looks like:
foo ()
{
;;   basic block 2, loop depth 0
;;pred:   ENTRY
  blah = 1;
  return 1;
;;succ:   EXIT

}

whereas for 4.9 it's:
foo ()
{
  int blah_lsm.4;
  int i;
  int _8;

;;   basic block 2, loop depth 0
;;pred:   ENTRY
  goto ;
;;succ:   4

;;   basic block 3, loop depth 2
;;   Invalid sum of incoming frequencies 7656, should be 8750
;;pred:   5
  blah_lsm.4_3 = 1;
  if (i_7 == 6)
goto ;
  else
goto ;
;;succ:   5
;;4

;;   basic block 4, loop depth 1
;;   Invalid sum of incoming frequencies 9998, should be 8748
;;pred:   3
;;2
  # i_11 = PHI 
;;succ:   5

;;   basic block 5, loop depth 2
;;pred:   3
;;4
  # i_12 = PHI 
  # blah_lsm.4_6 = PHI 
  i_7 = i_12 + 1;
  if (i_7 <= 6)
goto ;
  else
goto ;
;;succ:   3
;;6

;;   basic block 6, loop depth 0
;;   Invalid sum of incoming frequencies 1094, should be 1250
;;pred:   5
  # blah_lsm.4_14 = PHI 
  blah = blah_lsm.4_14;
  _8 = blah_lsm.4_6;
  return _8;
;;succ:   EXIT

}

I've attached the dom1 dumps from 4.8 and 4.9.
Jeff, do you have any insight into what is happening?

[Bug target/69014] [4.9/5/6 Regression] gcc.c-torture/execute/991023-1.c FAILs with -Os -fmodulo-sched -fno-tree-vrp

[ktkachov at gcc dot gnu.org]

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

--- Comment #5 from ktkachov at gcc dot gnu.org ---
I also meant to add that the differences in tree dumps start at the dom1 pass

[Bug target/69012] gcc-6.0.0 internal compiler error building libgfortran for mips64el target

[paul.hua.gm at gmail dot com]

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

--- Comment #4 from Paul Hua  ---
Created attachment 37114
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37114=edit
preprocessed source for maxval_r4.c

The compile command line :

cc1 -fpreprocessed maxval_r4.i -mel -quiet -dumpbase maxval_r4.c -mabi=32
-minterlink-mips16 -march=mips64r2 -mllsc -mips64r2 -mno-shared -auxbase-strip
maxval_r4.o -g -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla -Wunknown-pragmas -std=gnu11
-std=gnu11 -version -fcx-fortran-rules -ffunction-sections -fdata-sections -o
maxval_r4.s

Thanks.

[Bug target/69012] gcc-6.0.0 internal compiler error building libgfortran for mips64el target

[paul.hua.gm at gmail dot com]

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

--- Comment #5 from Paul Hua  ---
Created attachment 37115
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37115=edit
building command

[Bug rtl-optimization/69030] New: ICE on x86_64-linux-gnu at -O2 and above in 32-bit mode (ICE in copy_rtx, at rtl.c:358)

[chengniansun at gmail dot com]

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

Bug ID: 69030
   Summary: ICE on x86_64-linux-gnu at -O2 and above in 32-bit
mode (ICE in copy_rtx, at rtl.c:358)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

The following code crashes gcc-trunk at -O2 and -O3 on x86_64-linux-gnu in
32-bit mode (not in 64-bit mode)

$: gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20151222 (experimental) [trunk revision 231896] (GCC) 
$: 
$: gcc-trunk -m32 small.c -w -g -O3
small.c: In function ‘main’:
small.c:25:1: internal compiler error: in copy_rtx, at rtl.c:358
 }
 ^

0xa87c13 copy_rtx(rtx_def*)
../../gcc-trunk/gcc/rtl.c:358
0x99e7d4 remove_pseudos
../../gcc-trunk/gcc/lra-spills.c:426
0x99e77f remove_pseudos
../../gcc-trunk/gcc/lra-spills.c:435
0x99e77f remove_pseudos
../../gcc-trunk/gcc/lra-spills.c:435
0x99f0b3 spill_pseudos
../../gcc-trunk/gcc/lra-spills.c:474
0x99f0b3 lra_spill()
../../gcc-trunk/gcc/lra-spills.c:586
0x9800ed lra(_IO_FILE*)
../../gcc-trunk/gcc/lra.c:2367
0x936f99 do_reload
../../gcc-trunk/gcc/ira.c:5385
0x936f99 execute
../../gcc-trunk/gcc/ira.c:5556
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$: 
$: gcc-trunk -m32 small.c -w -g -O2
small.c: In function ‘main’:
small.c:25:1: internal compiler error: Segmentation fault
 }
 ^

0xaed4af crash_signal
../../gcc-trunk/gcc/toplev.c:334
0x995f83 lra_eliminate_regs_1(rtx_insn*, rtx_def*, machine_mode, bool, bool,
long, bool)
../../gcc-trunk/gcc/lra-eliminations.c:664
0x99e812 remove_pseudos
../../gcc-trunk/gcc/lra-spills.c:425
0x99e77f remove_pseudos
../../gcc-trunk/gcc/lra-spills.c:435
0x99e77f remove_pseudos
../../gcc-trunk/gcc/lra-spills.c:435
0x99f0b3 spill_pseudos
../../gcc-trunk/gcc/lra-spills.c:474
0x99f0b3 lra_spill()
../../gcc-trunk/gcc/lra-spills.c:586
0x9800ed lra(_IO_FILE*)
../../gcc-trunk/gcc/lra.c:2367
0x936f99 do_reload
../../gcc-trunk/gcc/ira.c:5385
0x936f99 execute
../../gcc-trunk/gcc/ira.c:5556
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$: 
$: cat small.c
int a, b, c = 7, d;
static unsigned e, g;
char f;
static unsigned fn1() {
  unsigned h = e - b ^ c;
  int i = h / c & a * g, j = g * h;
  if (h) {
if (d)
  h = e;
j = a;
a = (a && (g % f && i) % h) | c | ~2;
if (b)
  printf("", 1);
  }
  c = i;
  a = j;
  return 2;
}

int main() {
  for (; b < -18; --b)
g = 0;
  fn1();
  return 0;
}
$:

[Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN

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

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

--- Comment #11 from Andreas Schwab <sch...@linux-m68k.org> ---
FAIL: gcc.dg/pr61441.c (test for excess errors)
Excess errors:
/usr/local/gcc/gcc-20151223/gcc/testsuite/gcc.dg/pr61441.c:12:7: warning:
implicit declaration of function 'issignaling'
[-Wimplicit-function-declaration]
pr61441.c:(.text+0x22): undefined reference to `issignaling'
pr61441.c:(.text+0xe2): undefined reference to `issignaling'
pr61441.c:(.text+0x162): undefined reference to `issignaling'

UNRESOLVED: gcc.dg/pr61441.c compilation failed to produce executable

[Bug gcov-profile/69004] Building t-engine on ARM fails during -fprofile-use stage

[tulipawn at gmail dot com]

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

--- Comment #1 from PeteVine  ---
Here's the exact error (was quoting from memory previously):

physfs.c
../src/physfs/physfs.c:76:5: warning: initialization from incompatible pointer
type
 &__PHYSFS_Archiver_BIND_PHYSFS,
 ^
../src/physfs/physfs.c:76:5: warning: (near initialization for
‘supported_types[0]’)
../src/physfs/physfs.c: In function ‘PHYSFS_seek’:
../src/physfs/physfs.c:2121:5: error: corrupted value profile: ic profile
counter (609869 out of 609868) inconsistent with basic-block count (609868)
 return(fh->funcs->seek(fh->opaque, pos));
 ^

[Bug middle-end/58306] error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count

[tulipawn at gmail dot com]

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

PeteVine  changed:

   What|Removed |Added

 CC||tulipawn at gmail dot com

--- Comment #6 from PeteVine  ---
I'm getting something similar on armv7:

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

[Bug gcov-profile/69004] Building t-engine on ARM fails during -fprofile-use stage

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-12-23
 Ever confirmed|0   |1

--- Comment #2 from Richard Earnshaw  ---
To make progress on this we're going to need a test-case.

I think it should be sufficient if you can provide:

- The profile data
- Preprocessed source for the file that crashes during profile annotation.

It may be possible to do some reduction on the source file, but it still needs
to show the same error (that probably means the whole function that's causing
the fault will need to be left intact).

[Bug gcov-profile/69004] Building t-engine on ARM fails during -fprofile-use stage

[t.artem at mailcity dot com]

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

Artem S. Tashkinov  changed:

   What|Removed |Added

 CC||t.artem at mailcity dot com

--- Comment #3 from Artem S. Tashkinov  ---
(In reply to Richard Earnshaw from comment #2)
> To make progress on this we're going to need a test-case.
> 
> I think it should be sufficient if you can provide:
> 
> - The profile data
> - Preprocessed source for the file that crashes during profile annotation.
> 
> It may be possible to do some reduction on the source file, but it still
> needs to show the same error (that probably means the whole function that's
> causing the fault will need to be left intact).

Well, great, bug 58306 has been there for two years already with zero feedback
from developers.

[Bug target/69031] New: ICE: in hash_rtx_cb, at cse.c:2533 with -fPIC -fselective-scheduling and __builtin_setjmp()

[zsojka at seznam dot cz]

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

Bug ID: 69031
   Summary: ICE: in hash_rtx_cb, at cse.c:2533 with -fPIC
-fselective-scheduling and __builtin_setjmp()
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: powerpc-unknown-linux-gnu

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

Compiler output:
$ powerpc-unknown-linux-gnu-gcc -O2 -fPIC -fselective-scheduling testcase.c 
testcase.c: In function 'foo':
testcase.c:8:1: internal compiler error: in hash_rtx_cb, at cse.c:2527
 }
 ^

0x115ad3b hash_rtx_cb(rtx_def const*, machine_mode, int*, int*, bool, int
(*)(rtx_def const*, machine_mode, rtx_def**, machine_mode*))
/repo/gcc-trunk/gcc/cse.c:2527
0x115acd4 hash_rtx_cb(rtx_def const*, machine_mode, int*, int*, bool, int
(*)(rtx_def const*, machine_mode, rtx_def**, machine_mode*))
/repo/gcc-trunk/gcc/cse.c:2511
0xada92b vinsn_init
/repo/gcc-trunk/gcc/sel-sched-ir.c:1206
0xada92b vinsn_create
/repo/gcc-trunk/gcc/sel-sched-ir.c:1237
0xadadf3 init_global_and_expr_for_insn
/repo/gcc-trunk/gcc/sel-sched-ir.c:3014
0xad898a sched_scan
/repo/gcc-trunk/gcc/sel-sched-ir.c:2801
0xadd601 sel_init_global_and_expr(vec)
/repo/gcc-trunk/gcc/sel-sched-ir.c:3033
0xafbf11 sel_region_init
/repo/gcc-trunk/gcc/sel-sched.c:6889
0xafbf11 sel_sched_region(int)
/repo/gcc-trunk/gcc/sel-sched.c:7613
0xafd9a9 run_selective_scheduling()
/repo/gcc-trunk/gcc/sel-sched.c:7699
0xad161d rest_of_handle_sched
/repo/gcc-trunk/gcc/sched-rgn.c:3715
0xad161d execute
/repo/gcc-trunk/gcc/sched-rgn.c:3825
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Only this target seems to have this problem.

Tested revisions:
r231903 - FAIL
5-branch r231870 - FAIL
4_9-branch r231865 - FAIL
4_8-branch r224828 - FAIL

[Bug gcov-profile/69004] Building t-engine on ARM fails during -fprofile-use stage

[tulipawn at gmail dot com]

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

--- Comment #4 from PeteVine  ---
The above error (using -mcpu=cortex-a5 -ffast-math) is a little different from
this one (after taking those two flags out, leaving just -O3
-fomit-frame-pointer):

physfs.c
../src/physfs/physfs.c:76:5: warning: initialization from incompatible pointer
type
 &__PHYSFS_Archiver_BIND_PHYSFS,
 ^
../src/physfs/physfs.c:76:5: warning: (near initialization for
‘supported_types[0]’)
../src/physfs/physfs.c: In function ‘PHYSFS_openRead’:
../src/physfs/physfs.c:2292:1: error: corrupted profile info: profile data is
not flow-consistent
 }
 ^
../src/physfs/physfs.c:2292:1: error: corrupted profile info: number of
executions for edge 36-37 thought to be -1
../src/physfs/physfs.c:2292:1: error: corrupted profile info: number of
executions for edge 36-1 thought to be 1

I'll be attaching the rest of the required data shortly.

[Bug rtl-optimization/69032] New: [5/6 Regression] ICE: in cfg_preds_1, at sel-sched-ir.c:4809 with -fsched-pressure -fsel-sched-pipelining -fselective-scheduling

[zsojka at seznam dot cz]

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

Bug ID: 69032
   Summary: [5/6 Regression] ICE: in cfg_preds_1, at
sel-sched-ir.c:4809 with -fsched-pressure
-fsel-sched-pipelining -fselective-scheduling
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: powerpc-unknown-linux-gnu

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

Compiler output:
$ powerpc-unknown-linux-gnu-gcc -O2 -fsched-pressure -fsel-sched-pipelining
-fselective-scheduling testcase.c 
testcase.c: In function 'foo':
testcase.c:8:1: internal compiler error: in cfg_preds_1, at sel-sched-ir.c:4753
 }
 ^

0xadf08f cfg_preds_1
/repo/gcc-trunk/gcc/sel-sched-ir.c:4753
0xadf15c cfg_preds
/repo/gcc-trunk/gcc/sel-sched-ir.c:4793
0xadf15c get_seqno_by_preds(rtx_insn*)
/repo/gcc-trunk/gcc/sel-sched-ir.c:4094
0xafb2f6 find_seqno_for_bookkeeping
/repo/gcc-trunk/gcc/sel-sched.c:4723
0xafb2f6 generate_bookkeeping_insn
/repo/gcc-trunk/gcc/sel-sched.c:4779
0xafb2f6 move_op_at_first_insn
/repo/gcc-trunk/gcc/sel-sched.c:6052
0xaf1268 code_motion_path_driver
/repo/gcc-trunk/gcc/sel-sched.c:6643
0xaf1793 code_motion_process_successors
/repo/gcc-trunk/gcc/sel-sched.c:6331
0xaf1793 code_motion_path_driver
/repo/gcc-trunk/gcc/sel-sched.c:6597
0xaf1793 code_motion_process_successors
/repo/gcc-trunk/gcc/sel-sched.c:6331
0xaf1793 code_motion_path_driver
/repo/gcc-trunk/gcc/sel-sched.c:6597
0xaf65c3 move_op
/repo/gcc-trunk/gcc/sel-sched.c:6688
0xaf65c3 move_exprs_to_boundary
/repo/gcc-trunk/gcc/sel-sched.c:5212
0xaf65c3 schedule_expr_on_boundary
/repo/gcc-trunk/gcc/sel-sched.c:5424
0xaf7e2e fill_insns
/repo/gcc-trunk/gcc/sel-sched.c:5566
0xaf9a0d schedule_on_fences
/repo/gcc-trunk/gcc/sel-sched.c:7342
0xaf9a0d sel_sched_region_2
/repo/gcc-trunk/gcc/sel-sched.c:7480
0xafc43b sel_sched_region_1
/repo/gcc-trunk/gcc/sel-sched.c:7522
0xafc43b sel_sched_region(int)
/repo/gcc-trunk/gcc/sel-sched.c:7623
0xafd9a9 run_selective_scheduling()
/repo/gcc-trunk/gcc/sel-sched.c:7699
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Other targets do not seem to have this issue.

Tested revisions:
r231903 - FAIL
5-branch r231870 - FAIL
4_9-branch r231865 - OK
4_8-branch r224828 - OK

[Bug rtl-optimization/67145] [6 Regression] associativity from pseudo-reg ordering

[ysrumyan at gmail dot com]

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

--- Comment #3 from Yuri Rumyantsev  ---
Created attachment 37120
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37120=edit
non-tested patch

[Bug target/69014] [4.9/5/6 Regression] gcc.c-torture/execute/991023-1.c FAILs with -Os -fmodulo-sched -fno-tree-vrp

[ktkachov at gcc dot gnu.org]

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

--- Comment #6 from ktkachov at gcc dot gnu.org ---
Created attachment 37121
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37121=edit
CFG dump before doloop pass

[Bug middle-end/67797] builtin functions should be able to know when their first argument is returned

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Keywords||missed-optimization
   Last reconfirmed||2015-12-23
  Component|target  |middle-end
 Ever confirmed|0   |1
Summary|[ARM] Unnecessary r0 saving |builtin functions should be
   |for memset call |able to know when their
   ||first argument is returned
   Severity|normal  |enhancement

--- Comment #1 from Richard Earnshaw  ---
This isn't target specific.  GCC does not currently realise that many string
functions return their first argument as a result.

[Bug target/68793] Bad optimization by split-wide-type on NEON

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug fortran/69011] [6 Regression] [OOP] ICE in gfc_advance_chain for ALLOCATE with SOURCE

[vries at gcc dot gnu.org]

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

--- Comment #5 from vries at gcc dot gnu.org ---
There's a bit of code in gfc_trans_allocate:
...
  if (code->expr3 && !code->expr3->mold)
{
  /* Initialization via SOURCE block (or static default initializer).
 Classes need some special handling, so catch them first.  */
  if (expr3 != NULL_TREE
  && TREE_CODE (expr3) != POINTER_PLUS_EXPR
  && code->expr3->ts.type == BT_CLASS
  && (expr->ts.type == BT_CLASS
  || expr->ts.type == BT_DERIVED))
{
  /* copy_class_to_class can be used for class arrays, too.
 It just needs to be ensured, that the decl_saved_descriptor
 has a way to get to the vptr.  */
  tree to;
  to = VAR_P (se.expr) ? se.expr : TREE_OPERAND (se.expr, 0);
  tmp = gfc_copy_class_to_class (expr3, to,
 nelems, upoly_expr);
}
...

Without r229621, we have:
...
(gdb) call debug_generic_expr (expr3)
(struct integrand *) previous->_data.data + (sizetype) ((previous->_data.offset
+ (integer(kind=8)) self->_data->steps * previous->_data.dim[0].stride) *
(integer(kind=8)) previous->_vptr->_size)
(gdb) p expr3.base.code
$10 = POINTER_PLUS_EXPR
...
and the gfc_copy_class_to_class is not triggered.

With r229621, we have:
...
(gdb) call debug_generic_expr (expr3)
(struct integrand *) (previous->_data.data + (sizetype)
((previous->_data.offset + (integer(kind=8)) self->_data->steps *
previous->_data.dim[0].stride) * (integer(kind=8)) previous->_vptr->_size))
(gdb) p expr3.base.code
$1 = NOP_EXPR
...
and the gfc_copy_class_to_class is triggered, and we hit the assert.

So AFAIU, r229621 inhibits folding in this case. That looks not incorrect to
me.

I've got no idea what the POINTER_PLUS_EXPR test in the bit above is trying to
achieve (and more generally, I've got little knowledge of fortran, and no
knowledge of the fortran frontend), so I've got no idea how this assert should
be fixed.

[Bug rtl-optimization/67145] [6 Regression] associativity from pseudo-reg ordering

[ysrumyan at gmail dot com]

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

--- Comment #4 from Yuri Rumyantsev  ---
I attached simple non-tested patch which restores performance on x86. This
change is no perfect but using it I noticed 2%-6% speed-up on 32-bit x86
platform. The idea of patch is very simple - we do not bail out if nothing
changed but re-materialize all PLUS rtx-instructions with register-operand. It
is important since an order of the operands in ops is different, i.e. if we
have  x + y + z on function entry, ops is {x,z,y} if REG(x) < REG(z) < REG(y).

[Bug ipa/67811] [TM] ICE with try-block in transaction

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |rth at gcc dot gnu.org

--- Comment #4 from Richard Henderson  ---
Fixed.

[Bug fortran/67779] Strange ordering with strings in extended object

[vries at gcc dot gnu.org]

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

--- Comment #9 from vries at gcc dot gnu.org ---
PR69011 is probably a duplicate.

[Bug target/69014] [4.9/5/6 Regression] gcc.c-torture/execute/991023-1.c FAILs with -Os -fmodulo-sched -fno-tree-vrp

[ktkachov at gcc dot gnu.org]

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

--- Comment #7 from ktkachov at gcc dot gnu.org ---
Created attachment 37122
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37122=edit
CFG dump before doloop pass (loop_invariant pass)

[Bug gcov-profile/69004] Building t-engine on ARM fails during -fprofile-use stage

[rearnsha at gcc dot gnu.org]

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

--- Comment #10 from Richard Earnshaw  ---
(In reply to PeteVine from comment #4)
> The above error (using -mcpu=cortex-a5 -ffast-math) is a little different
> from this one (after taking those two flags out, leaving just -O3
> -fomit-frame-pointer):
> 
> physfs.c
> ../src/physfs/physfs.c:76:5: warning: initialization from incompatible
> pointer type
>  &__PHYSFS_Archiver_BIND_PHYSFS,
>  ^
> ../src/physfs/physfs.c:76:5: warning: (near initialization for
> ‘supported_types[0]’)
> ../src/physfs/physfs.c: In function ‘PHYSFS_openRead’:
> ../src/physfs/physfs.c:2292:1: error: corrupted profile info: profile data
> is not flow-consistent
>  }
>  ^
> ../src/physfs/physfs.c:2292:1: error: corrupted profile info: number of
> executions for edge 36-37 thought to be -1
> ../src/physfs/physfs.c:2292:1: error: corrupted profile info: number of
> executions for edge 36-1 thought to be 1
> 
> I'll be attaching the rest of the required data shortly.

OK, I think I'm now correctly reproducing this.  Just to confirm can you please
re-run the profile-use compile and add '-v' to the list of options.  I need to
see the full set of options passed to the invocation of the cc1 command (main
compiler invocation).

[Bug gcov-profile/69004] Building t-engine on ARM fails during -fprofile-use stage

[tulipawn at gmail dot com]

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

--- Comment #11 from PeteVine  ---
COLLECT_GCC_OPTIONS='-MMD' '-MP' '-D' 'GLEW_STATIC' '-D' 'NDEBUG=1' '-D'
'PHYSFS_SUPPORTS_ZIP' '-I' '../src' '-I' '../src/luasocket' '-I' '../src/fov'
'-I' '../src/expat' '-I' '../src/lxp' '-I' '../src/libtcod_import' '-I'
'../src/physfs' '-I' '../src/zlib' '-I' '../src/bzip2' '-I' '/usr/include/SDL2'
'-I' '/usr/include/GL' '-I' '../src/luajit2/src' '-I' '../src/luajit2/dynasm'
'-O2' '-fomit-frame-pointer' '-O3' '-fprofile-use' '-v' '-o'
'../obj/Release/physfs/physfs.o' '-c' '-march=armv7-a' '-mfloat-abi=hard'
'-mfpu=vfpv3-d16' '-mthumb' '-mtls-dialect=gnu'
 /usr/lib/gcc/arm-linux-gnueabihf/4.9/cc1 -quiet -v -I ../src -I
../src/luasocket -I ../src/fov -I ../src/expat -I ../src/lxp -I
../src/libtcod_import -I ../src/physfs -I ../src/zlib -I ../src/bzip2 -I
/usr/include/SDL2 -I /usr/include/GL -I ../src/luajit2/src -I
../src/luajit2/dynasm -imultiarch arm-linux-gnueabihf -MMD
../obj/Release/physfs/physfs.d -MP -MQ ../obj/Release/physfs/physfs.o -D
GLEW_STATIC -D NDEBUG=1 -D PHYSFS_SUPPORTS_ZIP ../src/physfs/physfs.c -quiet
-dumpbase physfs.c -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb
-mtls-dialect=gnu -auxbase-strip ../obj/Release/physfs/physfs.o -O2 -O3
-version -fomit-frame-pointer -fprofile-use -fstack-protector -Wformat
-Wformat-security -o /tmp/ccI0Wt0G.s

[Bug gcov-profile/69004] Building t-engine on ARM fails during -fprofile-use stage

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #12 from Richard Earnshaw  ---
Confirmed.  A 4.9.3 cross compiler with the testcase also shows the error.

.../cc1 -O3 -fprofile-use physfs.i -quiet -fpreprocessed -o p.s  
-fomit-frame-pointer -ftest-coverage -march=armv7-a -mfpu=vfpv3-d16
-mfloat-abi=hard -mthumb -mtls-dialect=gnu -fstack-protector
../src/physfs/physfs.c:76:5: warning: initialization from incompatible pointer
type
../src/physfs/physfs.c:76:5: warning: (near initialization for
‘supported_types[0]’)
../src/physfs/physfs.c: In function ‘PHYSFS_openRead’:
../src/physfs/physfs.c:2292:1: error: corrupted profile info: profile data is
not flow-consistent
../src/physfs/physfs.c:2292:1: error: corrupted profile info: number of
executions for edge 36-37 thought to be -1
../src/physfs/physfs.c:2292:1: error: corrupted profile info: number of
executions for edge 36-1 thought to be 1

[Bug fortran/69011] [6 Regression] [OOP] ICE in gfc_advance_chain for ALLOCATE with SOURCE

[vries at gcc dot gnu.org]

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

--- Comment #6 from vries at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #4)
> Marking as blocking PR 67779 because we need to fix this to get to the
> wrong-code issue in that PR again.

I suspect this PR is simply a duplicate of the other PR, and that there is no
blocking relation.

[Bug c++/69029] [6 Regression] bogus -Wmisleading-indentation warning on one-line loops

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-23
 Ever confirmed|0   |1

--- Comment #2 from Markus Trippelsdorf  ---
(In reply to David Malcolm from comment #1)
> Looks like it would be fixed by:
>   https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02050.html

Ah, yes indeed it does. Thanks.
I will close this bug once the patch gets committed.

[Bug fortran/69011] [6 Regression] [OOP] ICE in gfc_advance_chain for ALLOCATE with SOURCE

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Blocks||67779

--- Comment #4 from Thomas Koenig  ---
Marking as blocking PR 67779 because we need to fix this to get to the
wrong-code issue in that PR again.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
[Bug 67779] Strange ordering with strings in extended object

[Bug fortran/69011] [6 Regression] [OOP] ICE in gfc_advance_chain for ALLOCATE with SOURCE

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vries at gcc dot gnu.org

--- Comment #3 from vries at gcc dot gnu.org ---
Sounds similar to PR67779

[Bug c++/69029] [6 Regression] bogus -Wmisleading-indentation warning on one-line loops

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
Looks like it would be fixed by:
  https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02050.html

[Bug target/69014] [4.9/5/6 Regression] gcc.c-torture/execute/991023-1.c FAILs with -Os -fmodulo-sched -fno-tree-vrp

[ktkachov at gcc dot gnu.org]

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

--- Comment #8 from ktkachov at gcc dot gnu.org ---
I've attached the CFG before and after the doloop pass, which I think
introduces the badness.

In loop3 the loop header exit condition is transformed but it disregards the
fact that the CC reg is also being used in another basic block inside the loop
(insn 12).

But since the CC reg was clobbered by the doloop_end pattern, its use in insn
12 that expects the result of the comparison from insn 19 is now bogus.

I think the solution here is to reject the doloop transformation if there is
any use of the CC reg after the loop exit basic block

[Bug testsuite/68232] gcc.dg/ifcvt-4.c fails on some arm configurations

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #4 from James Greenhalgh  ---
Author: jgreenhalgh
Date: Wed Dec 23 16:35:20 2015
New Revision: 231929

URL: https://gcc.gnu.org/viewcvs?rev=231929=gcc=rev
Log:
[Patch testsuite] Skip gcc.dg/ifcvt-4.c for targets on which it may not work

gcc/testsuite/

PR testsuite/68232
* gcc.dg/ifcvt-4.c: Skip for arm*-*-* and powerpc64le*-*-*.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/ifcvt-4.c

[Bug target/67710] FAIL: gcc.dg/darwin-*version-*.c (test for excess errors) with Xcode 7

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #4)
> Unfortunately, it doesn't work on Mac OS X 10.11.2: every link test
> FAILs with
> 
> FAIL: 17_intro/freestanding.cc (test for excess errors)
> Excess errors:
> ld: warning: object file
> (/var/folders/1d/k16rgv6d5039jhvlj8_dzk4h00021y/T//cc0iIoOX.o) was built for
> newer OSX version (10.11.2) than being linked (10.11)
> 
> I've found that while ld strips the micro version passed to
> -mmacosx_version_min, clang does not, resulting in this mess.

hum.
>  Given that ld(1) documents the version number format as ., for
> now it seems that gcc should only pass this to as and ld.

ld < 85.2..ish didn't understand the minor.

> Looking...

Actually, I think it would be better to leave macosx-version-min alone, and
push a new flag (the information is all there in darwin-driver.c).

propose -mmacosx-major-version=10.xx

If you're not going to tackle this in the short-term, I'll take a look.

[Bug tree-optimization/68911] [6 Regression] wrong code at -Os and above on x86-64-linux-gnu (in 32- and 64-bit modes)

[amker at gcc dot gnu.org]

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

--- Comment #4 from amker at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #2)
> This goes wrong during vrp1.
> Analyzing # of iterations of loop 2
>   exit condition [e_6, + , 1] <= 93
>   bounds on difference of bases: -4294967202 ... 93
>   result:
> zero if e_6 > 94
> # of iterations 94 - e_6, bounded by 94
> looks wrong to me, e_6 as well as the additions and comparison are performed
> in unsigned type, therefore 94 - e_6 is I believe not bounded by 94.  The
> value ranges for e_6 clearly allow (and in the testcase are) some very large
> unsigned numbers, so 94 - e_6.  If assuming the value of f is arbitrary (it
> is not), then the possible values of e before entering the
> while (e < 94)
>   e++;
> loop are either 2, 94, 0xU or 0xfffeU (of course f is not
> arbitrary and as b and d are both 0, it will be actually 0xU each
> time.
> But from those 4 numbers the number of iterations would be bound by 96.

The immediate dump of loop before vrp1 is as below:

  :
  e_15 = e_1 + 1;

  :
  # e_1 = PHI 
  if (e_1 <= 93)
goto ;
  else
goto ;

The loop niter analyzed before/after r224020 are both like below:
Analyzing # of iterations of loop 2
  exit condition [e_8, + , 1] <= 93
  bounds on difference of bases: -4294967202 ... 93
  result:
zero if e_8 > 94
# of iterations 94 - e_8, bounded by 94
Analyzing # of iterations of loop 2
  exit condition [e_8, + , 1] <= 93
  bounds on difference of bases: -4294967202 ... 93
  result:
zero if e_8 > 94
# of iterations 94 - e_8, bounded by 94

The only difference after patching is now we explicitly record {e_8, 1}_loop as
a no-wrap control_iv.

Seems to me the bound information is correct because that information must be
used when "zero if e_8 > 94" is satisfied, as commented in source code:

  tree may_be_zero; /* The boolean expression.  If it evaluates to true,
   the loop will exit in the first iteration (i.e.
   its latch will not be executed), even if the niter
   field says otherwise.  */
  tree niter;   /* The expression giving the number of iterations of
   a loop (provided that assumptions == true and
   may_be_zero == false), more precisely the number
   of executions of the latch of the loop.  */

So no_overflow property of control_iv should also be used only when may_be_zero
is false. 

For now VRP tries to update range information using loop niter bound when the
control iv doesn't wrap/overflow, but I think that is not enough.  We can not
assume any information from loop if the loop exits immediately.

So, IMHO, we should only update value range with loop niter bound when
may_be_zero is false.  This will fix this issue and won't hurt other cases
because when the loop exits immediately, there is no useful loop niter bound
information anyway.

[Bug c++/69035] New: [constexpr] Using bultins sometimes make the expression non-constant

[wielkiegie at gmail dot com]

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

Bug ID: 69035
   Summary: [constexpr] Using bultins sometimes make the
expression non-constant
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wielkiegie at gmail dot com
  Target Milestone: ---

Hello,

I have a problem when using builtins (like __builtin_clz()) inside constexpr
functions.

Example:

constexpr int foo(int x) { return __builtin_clz(x); }

Using foo() as a constant-expression results in the following error:

char tab[foo(1)];
// error: size of array ‘tab’ is not an integral constant-expression

However, if I add something to the foo(1) (and this something is not zero) it
starts to work:

char tab[foo(1)+1];
// no error.

Using __builtin_clz() directly also works:

char tab[__builtin_clz(1)];
// no error.

As does adding 1 inside foo():

constexpr int foo2(int x) { return __builtin_clz(x) + 1; }
char tab[foo(1)];
// no error.

The clang compiler does not produce these errors and works with every example
provided here.

[Bug middle-end/67797] builtin functions should be able to know when their first argument is returned

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
Note that gcc knows about it, thanks to the "fn spec" attribute (see also
ERF_RETURNS_ARG), it just doesn't try hard enough to take advantage of it.

[Bug c++/69023] bitset whose name is used in constant-expression rejected

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Thanks for the reference!  I now see it quoted in the code as well.   (I should
have looked it up before opening the bug.)  I'll close it as invalid, though
perhaps adding a test case might be useful since I don't see this case covered
in the test suite.  Let me submit one.

[Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #29 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #28)
> Will report back.

From a current build log (5.3.1-4) [1]:

Comparing stages 2 and 3
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Comparison successful.

So, I think we can mark this as resolved unless I am overlooking something. You
can check the log yourself in any case.

Adrian

> [1] https://people.debian.org/~glaubitz/gcc-5_5.3.1-4_sh4.build

[Bug c/69033] New: [6 regression] many internal compiler errors starting with r231928

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 69033
   Summary: [6 regression] many internal compiler errors starting
with r231928
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

There are over a hundred internal compiler errors showing up on power BE and LE
starting with the changes for r231928.  

Here is just one example:

seurer@genoa:~/tests/gcc$ gcc-test -c swaps-p8-1.c  -mcpu=power8 -O2
seurer@genoa:~/tests/gcc$ gcc-test -c swaps-p8-1.c  -mcpu=power8 -O3
swaps-p8-1.c:35:1: internal compiler error: in increase_alignment, at
symtab.c:2104
 }
 ^

0x1036887b symtab_node::increase_alignment(unsigned int)
/home/seurer/gcc/gcc-test/gcc/symtab.c:2104
0x10b1c28f increase_alignment
/home/seurer/gcc/gcc-test/gcc/tree-vectorizer.c:817
0x10b1c28f execute
/home/seurer/gcc/gcc-test/gcc/tree-vectorizer.c:855

These were all the failures:

FAIL: g++.dg/torture/pr44069.C   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error)
FAIL: g++.dg/torture/pr44069.C   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: g++.dg/torture/pr44069.C   -O3 -g  (internal compiler error)
FAIL: g++.dg/torture/pr44069.C   -O3 -g  (test for excess errors)
FAIL: g++.dg/torture/pr49644.C   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error)
FAIL: g++.dg/torture/pr49644.C   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: g++.dg/torture/pr49644.C   -O3 -g  (internal compiler error)
FAIL: g++.dg/torture/pr49644.C   -O3 -g  (test for excess errors)
FAIL: g++.dg/torture/pr55875.C   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error)
FAIL: g++.dg/torture/pr55875.C   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: g++.dg/torture/pr55875.C   -O3 -g  (internal compiler error)
FAIL: g++.dg/torture/pr55875.C   -O3 -g  (test for excess errors)
FAIL: g++.dg/tree-ssa/pr34355.C  -std=gnu++11 (internal compiler error)
FAIL: g++.dg/tree-ssa/pr34355.C  -std=gnu++11 (test for excess errors)
FAIL: g++.dg/tree-ssa/pr34355.C  -std=gnu++14 (internal compiler error)
FAIL: g++.dg/tree-ssa/pr34355.C  -std=gnu++14 (test for excess errors)
FAIL: g++.dg/tree-ssa/pr34355.C  -std=gnu++98 (internal compiler error)
FAIL: g++.dg/tree-ssa/pr34355.C  -std=gnu++98 (test for excess errors)
FAIL: gcc.c-torture/compile/pr25224.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (internal compiler error)
FAIL: gcc.c-torture/compile/pr25224.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gcc.c-torture/compile/pr25224.c   -O3 -g  (internal compiler error)
FAIL: gcc.c-torture/compile/pr25224.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/execute/20010915-1.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler
error)
FAIL: gcc.c-torture/execute/20010915-1.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
FAIL: gcc.c-torture/execute/20010915-1.c   -O3 -g  (internal compiler error)
FAIL: gcc.c-torture/execute/20010915-1.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/execute/20020402-1.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler
error)
FAIL: gcc.c-torture/execute/20020402-1.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
FAIL: gcc.c-torture/execute/20020402-1.c   -O3 -g  (internal compiler error)
FAIL: gcc.c-torture/execute/20020402-1.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/execute/20030105-1.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler
error)
FAIL: gcc.c-torture/execute/20030105-1.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess
errors)
FAIL: gcc.c-torture/execute/20030105-1.c   -O3 -g  (internal compiler error)
FAIL: gcc.c-torture/execute/20030105-1.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/execute/20040218-1.c   -O3 -g  (internal compiler error)
FAIL: gcc.c-torture/execute/20040218-1.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/execute/20041126-1.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler
error)
FAIL: gcc.c-torture/execute/20041126-1.c   -O3 -fomit-frame-pointer

[Bug gcov-profile/69004] Building t-engine on ARM fails during -fprofile-use stage

[tulipawn at gmail dot com]

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

--- Comment #13 from PeteVine  ---
Thanks; I've just remembered another one (involving lto during final link) that
doesn't happen on x86 so I'm probably going to open an issue. Could you tell me
whether a failure like this belongs in gcc bugtracker?


===> LD ufo
release-openpandora-armv7l/ufo/client/ui/node/ui_node_textentry.cpp.o (symbol
from plugin): warning: memset used with constant zero length parameter; this
could be due to transposed parameters
release-openpandora-armv7l/ufo/client/ui/node/ui_node_textentry.cpp.o (symbol
from plugin): warning: memset used with constant zero length parameter; this
could be due to transposed parameters
/home/odroid/temp/ccWdtp4n.s: Assembler messages:
/home/odroid/temp/ccWdtp4n.s:22332: Error: offset out of range
/home/odroid/temp/ccWdtp4n.s:22366: Error: offset out of range
/home/odroid/temp/ccWdtp4n.s:22637: Error: offset out of range
/home/odroid/temp/ccWdtp4n.s:22646: Error: offset out of range
lto-wrapper: /usr/bin/g++-4.9.real returned 1 exit status
/usr/bin/ld.bfd.real: lto-wrapper failed
collect2: error: ld returned 1 exit status
make: *** ufo Error 1

[Bug target/69034] New: ICE: RTL check: expected elt 1 type 'e' or 'u', have 'i' (rtx unspec) in copy_replacements_1, at reload.c:6323 with -fPIC and "X" asm input

[zsojka at seznam dot cz]

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

Bug ID: 69034
   Summary: ICE: RTL check: expected elt 1 type 'e' or 'u', have
'i' (rtx unspec) in copy_replacements_1, at
reload.c:6323 with -fPIC and "X" asm input
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: powerpc64-unknown-linux-gnu

I don't know how much is this related to PR63669 and PR68254.

RTL checking must be enabled.

Compiler output:
$ powerpc64-unknown-linux-gnu-gcc -O -fPIC testcase.c 
testcase.c: In function 'foo':
testcase.c:7:1: internal compiler error: RTL check: expected elt 1 type 'e' or
'u', have 'i' (rtx unspec) in copy_replacements_1, at reload.c:6323
 }
 ^

0xab4996 rtl_check_failed_type2(rtx_def const*, int, int, int, char const*,
int, char const*)
/repo/gcc-trunk/gcc/rtl.c:802
0xa8412b copy_replacements_1
/repo/gcc-trunk/gcc/reload.c:6323
0xa83e7f copy_replacements_1
/repo/gcc-trunk/gcc/reload.c:6323
0xa8b56c copy_replacements
/repo/gcc-trunk/gcc/reload.c:6294
0xa8b56c find_reloads_address
/repo/gcc-trunk/gcc/reload.c:5027
0xa93ef6 find_reloads(rtx_insn*, int, int, int, short*)
/repo/gcc-trunk/gcc/reload.c:2885
0xaafe99 calculate_needs_all_insns
/repo/gcc-trunk/gcc/reload1.c:1506
0xaafe99 reload(rtx_insn*, int)
/repo/gcc-trunk/gcc/reload1.c:995
0x920775 do_reload
/repo/gcc-trunk/gcc/ira.c:5397
0x920775 execute
/repo/gcc-trunk/gcc/ira.c:5556
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Only powerpc64 and aarch64 choke on this testcase in trunk.

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


Tested revisions:
r231903 - FAIL
5-branch r231870 - FAIL
4_9-branch r231865 - FAIL
4_8-branch r224828 - FAIL

[Bug c++/64786] Eliminate exceptions thrown/caught inside a function

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-23
 Ever confirmed|0   |1
   Severity|normal  |enhancement

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

[Bug driver/64690] -freport-bug issue with comments

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Fixed a while back.

[Bug libgomp/65070] libgomp calls syscall instruction directly

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Not a bug, if you want to use OSv, then the OS is not linux anymore.

[Bug tree-optimization/66278] Missed auto-vectorization of an array subtraction

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-24
 Ever confirmed|0   |1
   Severity|normal  |enhancement

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

[Bug c++/69005] [5/6 Regression] infinite(?) recursion in template instantiations

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
If we remove the copy constructor declaration or make it defaulted, clang
rejects this testcase, also due to excessive recursive instantiation, and GCC
starts accepting it.  We're definitely into corner cases here.

Let's simplify the testcase:

template T&& declval();

template class function;

template
struct function<_Res(_Arg)>
{
  function() noexcept { }

  function(const function&) { }

  template()(declval<_Arg>()))>
  function(_Functor) { }

  _Res operator()(_Arg) const;
};

struct Foo {
  function Func;
};

extern Foo exfoo;
Foo f (exfoo);

The problem is that when we decide we need to figure out the exception
specification for the Foo copy constructor, we look for which Foo constructor
it will call.  We consider the template constructor as a possible candidate and
do template argument deduction, which means substituting into the default
argument.  As part of that we need to copy Foo into the parameter of
operator(), so we need the exception specification for the Foo copy constructor
again, and so on ad infinitum.

I think the NotSelf business is trying to guard against this sort of thing, but
it doesn't work, because there's no shortcut evaluation of __and_ as there is
with &&.  It seems entirely useless on this constructor, since the standard
already says that a template constructor will never be instantiated to produce
a X(X) constructor:

12.8/6 "A declaration of a constructor for a class X is ill-formed if its first
parameter is of type (optionally cv-qualified) X and either there are no other
parameters or else all other parameters have default arguments. A member
function template is never instantiated to produce such a constructor
signature."

Given that passage, we could disqualify this template sooner; since the first
function parameter is just a template parameter, if we're copying an object of
the class type we know deduction would try to give us an X(X) constructor, so
we might as well not bother with deduction.  That would short-circuit this
process and make us accept the testcase.  I think I'll go ahead and do this for
GCC 6.

But really, this is a serious edge case.  It would be more portable to make
your substitution fail sooner so that we  we don't even get into the decltype
if NotSelf is false.  This works for me (and clang without the copy
constructor), though there are certainly many ways to formulate it:

  template, void>,
   typename = _Requires<_Callable<_Functor>, void>>
  function(_Functor) { }

[Bug middle-end/69026] dwarf2out.c:4295 warning: ‘finder[...]addr_table_entry_struct_union::label’ may be used uninitialized

[gary at intrepid dot com]

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

--- Comment #1 from Gary Funck  ---
This can be most easily reproduced by doing a regular configure and make, then
cd-ing into the gcc build directory and forcing a re-compilation of dwarf2out.c
at -O3.

cd bld/gcc
rm dwarf2out.o
make CXXFLAGS='-O3 -g' dwarf2out.o
[...]
/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/dwarf2out.c: In function
‘addr_table_entry* add_addr_table_entry(void*, ate_kind)’:
/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/dwarf2out.c:4295:41: error:
‘finder.addr_table_entry::addr.addr_table_entry::addr_table_entry_struct_union::label’
may be used uninitialized in this function [-Werror=maybe-uninitialized]
   inchash::add_rtx (a->addr.rtl, hstate);
 ^

/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/dwarf2out.c:4345:20: note:
‘finder.addr_table_entry::addr.addr_table_entry::addr_table_entry_struct_union::label’
was declared here
   addr_table_entry finder;
^~

[Bug ipa/67811] [TM] ICE with try-block in transaction

[rth at gcc dot gnu.org]

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

--- Comment #5 from Richard Henderson  ---
Author: rth
Date: Thu Dec 24 00:45:15 2015
New Revision: 231943

URL: https://gcc.gnu.org/viewcvs?rev=231943=gcc=rev
Log:
PR ipa/67811

 * tree-cfg.c (make_edges_bb): Add abort edge for outer transactions.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-cfg.c

[Bug target/69012] gcc-6.0.0 internal compiler error building libgfortran for mips64el target

[paul.hua.gm at gmail dot com]

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

--- Comment #8 from Paul Hua  ---

(In reply to Bernd Edlinger from comment #6)
> (In reply to Paul Hua from comment #5)
> > Created attachment 37115 [details]
> > building command
> 
> I'm unable to reproduce.
> What is your cross-compiler command line?

The command line have been submitted on comment #4：

$where_build_obj/gcc/cc1 -fpreprocessed maxval_r4.i -mel -quiet -dumpbase
maxval_r4.c -mabi=32 -minterlink-mips16 -march=mips64r2 -mllsc -mips64r2
-mno-shared -auxbase-strip maxval_r4.o -g -O2 -Wall -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla -Wunknown-pragmas -std=gnu11
-std=gnu11 -version -fcx-fortran-rules -ffunction-sections -fdata-sections -o
maxval_r4.s

[Bug middle-end/69025] df-scan.c:2536 warning: array subscript is above array bounds

[gary at intrepid dot com]

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

--- Comment #1 from Gary Funck  ---
This can be most easily reproduced by doing a regular configure and make, then
cd-ing into the gcc build directory and forcing a re-compilation of df-scan.c
at -O3.

cd bld/gcc
rm df-scan.o
make CXXFLAGS='-O3 -g' df-scan.o
[...]
In file included from /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/target.h:53:0,
 from /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/df-scan.c:28:
/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/df-scan.c: In function ‘void
df_ref_record(df_ref_class, df_collection_rec*, rtx, rtx_def**, basic_block,
df_insn_info*, df_ref_type, int)’:
/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/hard-reg-set.h:156:44: error: array
subscript is above array bounds [-Werror=array-bounds]
   (!!((SET)[(BIT) / UHOST_BITS_PER_WIDE_INT] \
   ~^

/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/df-scan.c:2536:18: note: in expansion
of macro ‘TEST_HARD_REG_BIT’
   else if (!(TEST_HARD_REG_BIT (elim_reg_set, regno)
  ^

cc1plus: all warnings being treated as errors

[Bug lto/65950] Loop is not vectorized with lto.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-24
 Ever confirmed|0   |1

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

Right before the vectorizer:

Without LTO:
  :
  # k_36 = PHI 
  # ivtmp_88 = PHI <16(5), ivtmp_40(7)>
  _11 = (long unsigned int) k_36;
  _12 = _11 * 4;
  _14 = v_13(D) + _12;
  _15 = *_14;
  _16 = k_36 + -1;
  _17 = (float) _16;
  _23 = pretmp_83 + _12;
  _24 = *_23;
  _25 = _17 * _24;
  _26 = _15 + _25;
  *_14 = _26;
  k_28 = k_36 + 1;
  ivtmp_40 = ivtmp_88 - 1;
  if (ivtmp_40 != 0)
goto ;
  else
goto ;

  :
  goto ;


With LTO:

  :
  _11 = (long unsigned int) k_2;
  _12 = _11 * 4;
  _14 = v_13(D) + _12;
  _15 = *_14;
  _16 = k_2 + -1;
  _17 = (float) _16;
  _22 = *_21;
  _23 = _22 + _12;
  _24 = *_23;
  _25 = _17 * _24;
  _26 = _15 + _25;
  *_14 = _26;
  k_28 = k_2 + 1;

  :
  # k_2 = PHI 
  # ivtmp_36 = PHI <17(3), ivtmp_35(4)>
  _10 = K_9 + 16;
  ivtmp_35 = ivtmp_36 - 1;
  if (ivtmp_35 != 0)
goto ;
  else
goto ;

Notice the difference in the CFG.

[Bug tree-optimization/69036] New: g++ hangs compiling tree-ssa-loop-ivopts.c at -O3

[gary at intrepid dot com]

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

Bug ID: 69036
   Summary: g++ hangs compiling tree-ssa-loop-ivopts.c at -O3
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gary at intrepid dot com
  Target Milestone: ---

While trying to build and bootstrap GCC at -O3 (using
--with-build-config=bootstrap-O3) on an x86-64, the compiler hangs in the final
stage while trying to build tree-ssa-loop-ivopts.o.  As shown below, the
failure can be triggered by doing a regular bootstrap build and then forcing
the compilation of tree-ssa-loop-ivopts.c at -O3.  Interestingly, it does not
replicate _unless_ the compiler is fully bootstrap, which may indicate there is
an issue with GCC (prev-gcc) compiling itself.  Also, when the compiler hangs,
it appears that its memory requirement steadily climbs over time.

The first failing version appears to be this one:

r231674 | rguenth | 2015-12-16 01:21:04 -0800 (Wed, 16 Dec 2015) | 8 lines

2015-12-16  Richard Biener  

PR tree-optimization/68892
* tree-vect-slp.c (vect_analyze_slp_cost_1): Properly compute
cost for permuted loads.

* gcc.dg/vect/bb-slp-pr68892.c: New testcase.

Steps to reproduce.

1. Standard configure and make.

(cd ./src; svn up -q -r231674)
src=`cd src; pwd`
rm -rf bld
mkdir bld
cd bld
$src/configure
nj=`getconf _NPROCESSORS_ONLN`
make -j$nj >& make.log

2. cd into gcc build directory and attempt to remake tree-ssa-loop-ivopts.o at
-O3.

cd gcc
rm tree-ssa-loop-ivopts.o
make CXXFLAGS='-O3 -g' tree-ssa-loop-ivopts.o
[compiler hangs]

[Bug middle-end/64993] Missed ccmp optimization with simple code

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Fixed:

foo_c:
cmp w0, 9
mov w0, 33
ccmpw1, w0, 0, gt
mov w2, 4
mov w0, 26
cselw0, w2, w0, le
ret

[Bug rtl-optimization/64713] Missed ccmp optimization

[pinskia at gcc dot gnu.org]

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

Bug 64993 Summary: Missed ccmp optimization with simple code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64993

   What|Removed |Added

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

[Bug target/67919] GCC Compiler failed with "gcc-5.2.0/gcc/expr.c:6529:1: internal compiler error: output_operand: invalid shift operand"

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
No news on this bug for 2 months now so closing.

[Bug tree-optimization/65968] Failure to remove casts, cause poor code generation

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-23
 Ever confirmed|0   |1

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

AARCH64 it is not as bad as x86_64 though:

With -UEASY:
.L2:
ldr q0, [x0]
smull   v2.4s, v0.4h, v0.4h
smull2  v0.4s, v0.8h, v0.8h
xtn v1.4h, v2.4s
xtn2v1.8h, v0.4s
str q1, [x0], 16
cmp x1, x0
bne .L2

With -DEASY:
.L2:
ldr q0, [x0]
mul v0.8h, v0.8h, v0.8h
str q0, [x0], 16
cmp x1, x0
bne .L2

[Bug tree-optimization/66012] Sub-optimal 64bit load is generated instead of zero-extension

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Happens on aarch64 also:
test:
adrpx0, l
add x1, x0, :lo12:l
ldr x1, [x1, 8]
ldr w0, [x0, #:lo12:l]
orr x0, x0, x1, lsl 32
ret

[Bug c++/69035] [constexpr] Using bultins sometimes make the expression non-constant

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
This seems to be fixed in gcc HEAD 6.0.0 20151217 (experimental).

[Bug c++/64524] gcc does not warn about same expression in both parts of ternary operator

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-23
Summary|gcc can't detect same   |gcc does not warn about
   |expression in both parts of |same expression in both
   |ternary operator|parts of ternary operator
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #8 from Andrew Pinski  ---
confirmed.

[Bug tree-optimization/66012] Sub-optimal 64bit load is generated instead of zero-extension

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-23
 Ever confirmed|0   |1
   Severity|normal  |enhancement

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

[Bug c/69033] [6 regression] many internal compiler errors starting with r231928

[nathan at gcc dot gnu.org]

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

--- Comment #1 from Nathan Sidwell  ---
patch r231928 reverted.  Analysis at
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02100.html

[Bug tree-optimization/65712] pthread_self prints wrong result when used with ucontext

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I think this is invalid as pthread_self is marked as const or pure which means
it does not change with respect of function calls.

If anything is a deficiency in POSIX.

[Bug middle-end/68034] Print warning when memset is optimized out

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
  Component|c   |middle-end
   Severity|normal  |enhancement

[Bug other/65933] final.c:2239:8: error: 'vector_type_mode' was not declared in this scope

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
I think this has been fixed.

[Bug other/65933] final.c:2239:8: error: 'vector_type_mode' was not declared in this scope

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #3 from John David Anglin  ---
Fixed.

[Bug c++/69023] bitset whose name is used in constant-expression rejected

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Author: msebor
Date: Wed Dec 23 21:52:50 2015
New Revision: 231938

URL: https://gcc.gnu.org/viewcvs?rev=231938=gcc=rev
Log:
PR c++/69023 - bitset whose name is used in constant-expression rejected
* g++.dg/lookup/name-clash11.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/lookup/name-clash11.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/66261] operations that simplify whether the pointers are the same or not (++p;++q;--p;--q)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-23
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Confirmed.
Of course does this show up in real code, I don't know.  Also if we switch
around the decrements or increments around, GCC Is able to optimize it away.

[Bug target/69012] gcc-6.0.0 internal compiler error building libgfortran for mips64el target

[bernd.edlinger at hotmail dot de]

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

--- Comment #9 from Bernd Edlinger  ---
(In reply to Paul Hua from comment #8)
> (In reply to Bernd Edlinger from comment #6)
> > (In reply to Paul Hua from comment #5)
> > > Created attachment 37115 [details]
> > > building command
> > 
> > I'm unable to reproduce.
> > What is your cross-compiler command line?
> 


and how exactly did you configure your cross compiler?

[Bug libgomp/65070] libgomp calls syscall instruction directly

[nyh at math dot technion.ac.il]

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

--- Comment #4 from Nadav Har'El  ---
There is a fine line between relying on "Linux" (e.g., the glibc ABI functions
as defined in LSB for example), and relying on obscure architecture-specific
tricks (like calling the syscall *instruction* in a way that only works on
x86-64). The latter may be justified when performance is the ultimate concern,
but I wonder if this is the case here (as I explained in my previous comments).
When is not the case, I don't understand why not use the syscall() library
function. *That* is the Linux ABI, not the x86-64 instruction.

This is not only an OSv question (although my attempt to use it in OSv brought
up this question). It's also a question why all this complexity is needed, when
glibc's syscall() function already has it. It looks to me like gratuitous
duplication, unless I'm missing the real reason why this was done.

[Bug libfortran/68987] [5/6 Regression] double free or corruption in _gfortran_st_write_done when a write statement to an internal file uses an invalid format and the ERR= specifier appears.

[jvdelisle at gcc dot gnu.org]

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

--- Comment #3 from Jerry DeLisle  ---
My guilty commit is rev 222111.  Went to far on the patch for pr65089 or took
care of the needed free somewhere else

This fixes it. Testing further.

diff --git a/libgfortran/io/format.c b/libgfortran/io/format.c
index 0b00016a..2068af7e 100644
--- a/libgfortran/io/format.c
+++ b/libgfortran/io/format.c
@@ -1180,8 +1180,27 @@ format_error (st_parameter_dt *dtp, const fnode *f,
const char *message)
   *p++ = '^';
   *p = '\0';

-  generate_error (>common, LIBERROR_FORMAT, buffer);
+  /* Cleanup any left over memory allocations before calling generate
+ error.  */
+  if (is_internal_unit (dtp))
+{
+  if (dtp->format != NULL)
+   {
+ free (dtp->format);
+ dtp->format = NULL;
+   }

+  /* Leave these alone if IOSTAT was given because execution will
+return from generate error in those cases.  */
+  if (!(dtp->common.flags & IOPARM_HAS_IOSTAT))
+   {
+ free (dtp->u.p.fmt);
+ free_format_hash_table (dtp->u.p.current_unit);
+ free_internal_unit (dtp);
+   }
+}
+
+  generate_error (>common, LIBERROR_FORMAT, buffer);
 }

[Bug rtl-optimization/52203] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7136 with -fsel-sched-pipelining -fselective-scheduling2 and other custom flags

[zsojka at seznam dot cz]

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

--- Comment #12 from Zdenek Sojka  ---
4.7 is not maintained anymore, can this be closed?

[Bug gcov-profile/69004] Building t-engine on ARM fails during -fprofile-use stage

[tulipawn at gmail dot com]

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

--- Comment #5 from PeteVine  ---
Created attachment 37118
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37118=edit
Preprocessed source

Corresponding to the latter error.

[Bug gcov-profile/69004] Building t-engine on ARM fails during -fprofile-use stage

[tulipawn at gmail dot com]

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

--- Comment #6 from PeteVine  ---
Created attachment 37119
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37119=edit
Profile data

[Bug gcov-profile/69004] Building t-engine on ARM fails during -fprofile-use stage

[tulipawn at gmail dot com]

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

--- Comment #7 from PeteVine  ---
I think I erroneously attached the preprocessed source from the profile-use
stage; you wanted from profile-generate, right?

[Bug gcov-profile/69004] Building t-engine on ARM fails during -fprofile-use stage

[rearnsha at gcc dot gnu.org]

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

--- Comment #8 from Richard Earnshaw  ---
(In reply to PeteVine from comment #7)
> I think I erroneously attached the preprocessed source from the profile-use
> stage; you wanted from profile-generate, right?

We need the one from the phase where the compiler crashes.  So profile-use is
probably right.

[Bug c++/69016] In C++14 standard, function with auto as return and arguments returns result with the datatype of first argument only

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #3 from TC  ---
Dup of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64969 and friends?

[Bug gcov-profile/69004] Building t-engine on ARM fails during -fprofile-use stage

[tulipawn at gmail dot com]

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

--- Comment #9 from PeteVine  ---
Great, let me know if you need anything else.

Here's output from gcc -v:

Using built-in specs.
COLLECT_GCC=/usr/bin/gcc-4.9.real
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.9/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.9.3-8ubuntu2~14.04' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-armhf/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-armhf
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-armhf
--with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --enable-multilib --disable-sjlj-exceptions
--with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb
--disable-werror --enable-multilib --enable-checking=release
--build=arm-linux-gnueabihf --host=arm-linux-gnueabihf
--target=arm-linux-gnueabihf
Thread model: posix
gcc version 4.9.3 (Ubuntu/Linaro 4.9.3-8ubuntu2~14.04)

[Bug c++/69023] bitset whose name is used in constant-expression rejected

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #3 from TC  ---
[basic.scope.class]/1, item 2:

A name N used in a class S shall refer to the same declaration in its context
and when re-evaluated in the completed scope of S. No diagnostic is required
for a violation of this rule.

[Bug target/69012] gcc-6.0.0 internal compiler error building libgfortran for mips64el target

[bernd.edlinger at hotmail dot de]

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

--- Comment #6 from Bernd Edlinger  ---
(In reply to Paul Hua from comment #5)
> Created attachment 37115 [details]
> building command

I'm unable to reproduce.
What is your cross-compiler command line?

[Bug target/69012] gcc-6.0.0 internal compiler error building libgfortran for mips64el target

[bernd.edlinger at hotmail dot de]

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

--- Comment #7 from Bernd Edlinger  ---
FYI, I used:
../gcc-trunk/configure --prefix=/home/ed/gnu/mips64el-unknown-linux
--target=mips64el-unknown-linux --enable-languages=c --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --enable-plugin --enable-initfini-array
--with-arch=mips64r2 --with-abi=64 --enable-gnu-indirect-function
--with-long-double-128 --enable-shared --enable-threads=posix --disable-libgcc
--disable-libssp --disable-libgomp --disable-libquadmath --disable-libatomic

[Bug tree-optimization/52272] [4.9/5/6 regression] Performance regression of 410.bwaves on x86.

[amker at gcc dot gnu.org]

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

--- Comment #31 from amker at gcc dot gnu.org ---
(In reply to wuxiang from comment #30)
> (In reply to amker from comment #29)
> > I think this is fixed.
> 
> Hi, I saw your patch, and patched it on gcc-4.8.4，but no improvement of
> 410.bwaves on x86_64 with gcc-4.8.4. 
> > The patch improves 410.bwaves by 3-4% on x86_64.
> Does this just test with gcc trunk before and afer the patch?

Yes, it was tested against trunk.  The code/data-structure have been changed a
lot since gcc 4.8, it may need some non-trivial change to rebase against 4.8,
but I think the basic idea described by comment#5 still holds.

[Bug fortran/68940] -Wno-error=compare-reals not working

[jahns at dkrz dot de]

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

--- Comment #3 from Thomas Jahns  ---
Created attachment 37111
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37111=edit
Source to demonstrate problem with  -Wno-error=unused-parameter

Running gfortran shows the problem:

$ gfortran -Wall -Werror -Wextra -Wno-error=unused-parameter -o
gfortran-werror-wunused-parameter gfortran-werror-wunused-parameter.f90 ; echo
$?
gfortran-werror-wunused-parameter.f90:2.24:

  REAL, PARAMETER :: bar = 0.5
1
Warning: Unused parameter 'bar' declared at (1)

1

But I just noticed this is no longer a problem with gfortran 5.1.0, only in
4.9.2.

[Bug rtl-optimization/68173] gcc takes a long time and a lot of memory with -O0 on source file with very large expression

[stevenb.gcc at gmail dot com]

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

--- Comment #15 from stevenb.gcc at gmail dot com  ---
> I wonder if we should (finally) use a RB tree for bitmap.  I even remember
> some patches posted to improve this (from Steven?) this or last year?

I used splay trees, they're a lot easier than balanced trees like RB or AVL.

https://gcc.gnu.org/ml/gcc-patches/2013-03/msg00170.html

[Bug driver/69028] New: ICE on *any* valid Cilk+ code C/C++: -fcilkplus is incompatible with -fprofile-arcs

[yury.zaytsev at traveltainment dot de]

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

Bug ID: 69028
   Summary: ICE on *any* valid Cilk+ code C/C++: -fcilkplus is
incompatible with -fprofile-arcs
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yury.zaytsev at traveltainment dot de
  Target Milestone: ---

I have found that Cilk+ programs are basically unusable with `--coverage`,
irrespective of whether it's a C or C++ program, therefore I'm marking this as
a driver issue.

Additionally, I set the severity to major, because I haven't found any
indication that profiling is unsupported with Cilk+ runtime and it's arguably
one of the fundamental features of the compiler. In comparison, OpenMP runtime
certainly does support profiling.

Affected are GCC 4.9 and GCC 5.x, I didn't have a chance to try on GCC 6 /
trunk.

$ cat ice.c 
#include 

void parallel() {
}

int main() {
cilk_spawn parallel();
cilk_sync;
}

$ gcc-4.9 -fcilkplus ice.c
$ g++-4.9 -fcilkplus ice.c
$ gcc-5 -fcilkplus ice.c
$ g++-5 -fcilkplus ice.c

$ gcc-4.9 -fcilkplus -fprofile-arcs ice.c 
ice.c: In function '_cilk_spn_0':
ice.c:9:1: internal compiler error: Segmentation fault
 }
 ^

$ g++-4.9 -fcilkplus -fprofile-arcs ice.c 
ice.c: In function '':
ice.c:9:1: internal compiler error: Segmentation fault
 }
 ^

$ gcc-5 -fcilkplus -fprofile-arcs ice.c 
ice.c:9:1: internal compiler error: Segmentation fault
 }
 ^
0x9a106f crash_signal
../../src/gcc/toplev.c:383
0x6b688f coverage_checksum_string
../../src/gcc/coverage.c:542
0x6b7a86 coverage_compute_profile_id(cgraph_node*)
../../src/gcc/coverage.c:625
0xb8ef3e init_node_map(bool)
../../src/gcc/value-prof.c:1308
0xa37b1e tree_profiling
../../src/gcc/tree-profile.c:545
0xa37b1e execute
../../src/gcc/tree-profile.c:670

$ g++-5 -fcilkplus -fprofile-arcs ice.c 
ice.c:9:1: internal compiler error: Segmentation fault
 }
 ^
0xa8842f crash_signal
../../src/gcc/toplev.c:383
0x79c71f coverage_checksum_string
../../src/gcc/coverage.c:542
0x79d916 coverage_compute_profile_id(cgraph_node*)
../../src/gcc/coverage.c:625
0xc75cae init_node_map(bool)
../../src/gcc/value-prof.c:1308
0xb1ed3e tree_profiling
../../src/gcc/tree-profile.c:545
0xb1ed3e execute
../../src/gcc/tree-profile.c:670

$ gcc-5 --version
gcc-5 (Ubuntu 5.2.1-23ubuntu1~12.04) 5.2.1 20151031

$ gcc-4.9 --version
gcc-4.9 (Ubuntu 4.9.2-0ubuntu1~12.04) 4.9.2

[Bug target/69012] gcc-6.0.0 internal compiler error building libgfortran for mips64el target

[paul.hua.gm at gmail dot com]

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

Paul Hua  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #2 from Paul Hua  ---
The "internal compiler error" appeared after trunk revision 225260, and the
revision 225249 can be successfully compiled.

The r225260 show:

commit 32e90dc6a0cda452b426b370326e315ac6f10f02
Author: edlinger 
Date:   Wed Jul 1 16:10:30 2015 +

gcc/ChangeLog:
2015-07-01  Bernd Edlinger  

PR rtl-optimization/61047
* rtlanal.c (get_initial_register_offset): New function.
(rtx_addr_can_trap_p_1): Check offsets of stack references.

testsuite/ChangeLog:
2015-07-01  Bernd Edlinger  

PR rtl-optimization/61047
* gcc.c-torture/execute/20150611-1.c: New testcase.


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

any one can fixing this ?