[Bug target/67788] [6 Regression] bootstrap failure in libgfortran on powerpc-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #1 from Matthias Klose  ---
Created attachment 36425
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36425=edit
preprocessed source

[Bug bootstrap/67789] New: Bootstrap failure with java starting at rev 228022

[pthaugen at gcc dot gnu.org]

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

Bug ID: 67789
   Summary: Bootstrap failure with java starting at rev 228022
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pthaugen at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, dje at gcc dot gnu.org,
meissner at gcc dot gnu.org, segher at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
 Build: powerpc64-unknown-linux-gnu

Bootstrap started failing on 32-bit libjava build at r228022.

Configured as:

/home/pthaugen/src/gcc/trunk/gcc/configure
--prefix=/home/pthaugen/install/gcc/trunk --enable-decimal-float --enable-lto
--with-as=/opt/at8.0/bin/as --with-ld=/opt/at8.0/bin/ld --without-ppl
--without-cloog --disable-libsanitizer --enable-languages=c,java
--disable-bootstrap --with-cpu=power8


Failing portion of make cmd:

[pthaugen@tul80p1 libjava]$ pwd
/home/pthaugen/work/build/gcc/trunk/powerpc64-unknown-linux-gnu/32/libjava

[pthaugen@tul80p1 libjava]$ /home/pthaugen/work/build/gcc/trunk/./gcc/gcj
-B/home/pthaugen/work/build/gcc/trunk/powerpc64-unknown-linux-gnu/32/libjava/
-B/home/pthaugen/work/build/gcc/trunk/powerpc64-unknown-linux-gnu/32/libjava/
-B/home/pthaugen/work/build/gcc/trunk/./gcc/
-B/home/pthaugen/install/gcc/trunk/powerpc64-unknown-linux-gnu/bin/
-B/home/pthaugen/install/gcc/trunk/powerpc64-unknown-linux-gnu/lib/ -isystem
/home/pthaugen/install/gcc/trunk/powerpc64-unknown-linux-gnu/include -isystem
/home/pthaugen/install/gcc/trunk/powerpc64-unknown-linux-gnu/sys-include -m32
-fclasspath=
-fbootclasspath=/home/pthaugen/src/gcc/trunk/gcc/libjava/classpath/lib
--encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c
-fsource-filename=/home/pthaugen/work/build/gcc/trunk/powerpc64-unknown-linux-gnu/32/libjava/classpath/lib/classes
-MT java/lang.lo -MD -MP -MF java/lang.deps @java/lang.list  -fPIC -o
java/.libs/lang.o -save-temps
ccWB6wRZjx.s: Assembler messages:
ccWB6wRZjx.s:18368: Error: symbol `.LCF369' is already defined

Adding -fno-shrink-wrap fixes the error. Appears the prolog is getting
duplicated.

[Bug middle-end/67754] [graphite] Many testsuite failures

[spop at gcc dot gnu.org]

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

--- Comment #10 from Sebastian Pop  ---
Yes, with -m32 it fails with an ICE.  Thanks for pointing this out.

[Bug bootstrap/67789] Bootstrap failure with java starting at rev 228022

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||67788

--- Comment #1 from Andrew Pinski  ---
Most likely the same issue as PR67788.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67788
[Bug 67788] [6 Regression] bootstrap failure in libgfortran on
powerpc-linux-gnu

[Bug target/67788] [6 Regression] bootstrap failure in libgfortran on powerpc-linux-gnu

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org

--- Comment #2 from Segher Boessenkool  ---
Hi!

I cannot reproduce the problem; could you email me the relevant
dump files?  Or just everything -da produces.

[Bug bootstrap/67789] Bootstrap failure with java starting at rev 228022

[meissner at gcc dot gnu.org]

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

--- Comment #3 from Michael Meissner  ---
Yes, it looks like my issue is the one raised by PR67788, so I imagine they are
the same issue.

[Bug target/67788] [6 Regression] bootstrap failure in libgfortran on powerpc-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #3 from Matthias Klose  ---
Created attachment 36426
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36426=edit
rtl dumps

[Bug bootstrap/67789] Bootstrap failure with java starting at rev 228022

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  ---
I see similar failures, except it is in building the 32-bit module fpu.o in the
libgfortran library on a 64-bit big endian power7 box. It is failing in
building the 32-bit libraries. This is not seen in building little endian
power8, since that system no longer does not have 32-bit support.

I believe the issue is the prologue for -fpic/-fPIC is not expecting the
prologue to be cloned. It sets up the TOC address by calling to a label and
then adjusting the address to get the TOC pointer. The label is created
multiple times when the blocks are re-ordered. If -fno-reorder-blocks is given,
it does not clone the label definition.

As I see it, there are several ways to solve this problem:

1) Simply disable shrink-wrapping/reorder-blocks if V.4 pic. This is probably
just papering over the problem.

2) Add a target hook so the backend can say whether or not a particular
function's prologue can be split. The static function in rs6000.c uses_TOC
would return true if it shouldn't be split.

3) Recognize in shrink-wrap if labels are created in the prologue, and don't
shrink wrap them.

[Bug bootstrap/67789] Bootstrap failure with java starting at rev 228022

[meissner at gcc dot gnu.org]

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

--- Comment #4 from Michael Meissner  ---
Here is the function that shows the error when compiled with -fPIC:


void
set_fpu_rounding_mode (int mode)
{
  int rnd_mode;

  switch (mode)
{
  case 2:
   rnd_mode = FE_TONEAREST;
   break;

  case 4:
rnd_mode = FE_UPWARD;
break;

  case 1:
rnd_mode = FE_DOWNWARD;
break;

  case 3:
rnd_mode = FE_TOWARDZERO; 
break;

  default:
return;
}

  fesetround (rnd_mode);
}

[Bug rtl-optimization/67787] [6 Regression] wrong code at -O3 on x86_64-linux-gnu

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org
  Known to fail||6.0

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Confirmed. I have a patch in testing.

[Bug rtl-optimization/67037] [4.9/5/6 Regression] Wrong code at -O1 and above on ARM

[edlinger at gcc dot gnu.org]

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

--- Comment #6 from Bernd Edlinger  ---
Author: edlinger
Date: Wed Sep 30 18:51:31 2015
New Revision: 228303

URL: https://gcc.gnu.org/viewcvs?rev=228303=gcc=rev
Log:
2015-09-30  Bernd Edlinger  

PR rtl-optimization/67037
* lra-constraints.c (process_addr_reg): Use copy_rtx when necessary.

testsuite:
2015-09-30  Bernd Edlinger  

PR rtl-optimization/67037
* gcc.c-torture/execute/pr67037.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr67037.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/67778] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in maybe_record_trace_start, at dwarf2cfi.c:2297

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
  Known to work||5.2.0
   Target Milestone|--- |6.0
Summary|ICE on valid code at -O3 on |[6 Regression] ICE on valid
   |x86_64-linux-gnu in |code at -O3 on
   |maybe_record_trace_start,   |x86_64-linux-gnu in
   |at dwarf2cfi.c:2297 |maybe_record_trace_start,
   ||at dwarf2cfi.c:2297
  Known to fail||6.0

[Bug target/67770] [4.9/5/6 Regression] i386: -fshrink-wrap can interact badly with trampolines

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||i?86-*-*
 Status|UNCONFIRMED |NEW
  Known to work||4.6.4
   Keywords||wrong-code
   Last reconfirmed||2015-09-30
 Ever confirmed|0   |1
Summary|i386: -fshrink-wrap can |[4.9/5/6 Regression] i386:
   |interact badly with |-fshrink-wrap can interact
   |trampolines |badly with trampolines
   Target Milestone|--- |4.9.4
  Known to fail||4.7.4, 4.8.5, 4.9.3, 5.2.0,
   ||6.0

--- Comment #1 from Richard Biener  ---
Confirmed.  Happens since shrink-wrapping was added.

[Bug c/67764] -Wconversion generates false warnings for bitmask+cast expressions

[marcin.slusarz at intel dot com]

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

--- Comment #2 from Marcin Ślusarz  ---
That's still gcc bug.

[Bug middle-end/67766] [6 Regression]: Bootstrap failure on alpha-linux-gnu: ICE in simplify_subreg, at simplify-rtx.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug target/67788] [6 Regression] bootstrap failure in libgfortran on powerpc-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #4 from Matthias Klose  ---
Created attachment 36429
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36429=edit
preprocessed source

[Bug target/67474] [6 regression] tree-vect-loop.c:2759:1: error: insn does not satisfy its constraints breaks ARM bootstrap

[mikpelinux at gmail dot com]

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

--- Comment #2 from Mikael Pettersson  ---
Still occurs with gcc-6-20150927.  Started with r227382, an LRA patch.

[Bug target/67788] [6 Regression] bootstrap failure in libgfortran on powerpc-linux-gnu

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-09-30
 Ever confirmed|0   |1

--- Comment #5 from Segher Boessenkool  ---
Okay, I can reproduce the problem now (-m32 -fPIC -msecure-plt).

The problem is that load_toc_v4_PIC_1_normal (and friends)
create the asm label manually.

[Bug c++/67790] New: verify_ssa failed: definition in block 20 follows the use

[dcb314 at hotmail dot com]

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

Bug ID: 67790
   Summary: verify_ssa failed: definition in block 20 follows the
use
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

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

For gcc trunk dated 20150930 on x86_64

$ ../results/bin/gcc -O3 --std=c++0x -c bug232.cc
hb-ot-layout.cc: In function ‘void hb_ot_layout_position_finish(hb_font_t*,
hb_buffer_t*)’:
hb-ot-layout.cc:795:1: error: definition in block 20 follows the use
for SSA_NAME: vect__57.4352_121 in statement:
vect__141.4353_119 = -vect__57.4352_121;
hb-ot-layout.cc:795:1: internal compiler error: verify_ssa failed
0xf95f47 verify_ssa(bool, bool)
../../src/trunk/gcc/tree-ssa.c:1047
0xc7d445 execute_function_todo
../../src/trunk/gcc/passes.c:1969
0xc7e837 do_per_function
../../src/trunk/gcc/passes.c:1653
0xc7e837 execute_todo
../../src/trunk/gcc/passes.c:2019

[Bug target/51726] LTO and attribute 'selectany'

[ktietz at gcc dot gnu.org]

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

--- Comment #6 from Kai Tietz  ---
Created attachment 36427
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36427=edit
Suggested patch

I will do some further testing with that patch, and later on send patch
upstream with a testcase for the common-case with selectany-attribute.

It would be appreciated  if you could test patch too.

[Bug middle-end/67790] verify_ssa failed: definition in block 20 follows the use

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-30
 CC||trippels at gcc dot gnu.org
  Component|c++ |middle-end
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
trippels@gcc2-power8 ~ % cat test.i
struct {
  int x_advance;
  int y_advance;
} * a;
int b, c, d;
void fn1() {
  for (; d; d++) {
c -= a[d].x_advance;
b -= a[d].y_advance;
  }
}

trippels@gcc2-power8 ~ % gcc -O3 -c test.i
test.i: In function ‘fn1’:
test.i:6:6: error: definition in block 6 follows the use
 void fn1() {
  ^
for SSA_NAME: vect__9.19_72 in statement:
vect__23.20_73 = -vect__9.19_72;
test.i:6:6: internal compiler error: verify_ssa failed
0x10a54107 verify_ssa(bool, bool)
../../gcc/gcc/tree-ssa.c:1047
0x106d4fcb execute_function_todo
../../gcc/gcc/passes.c:1978
0x106d5b93 do_per_function
../../gcc/gcc/passes.c:1654
0x106d5e3f execute_todo
../../gcc/gcc/passes.c:2028
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/67690] [5/6 Regression] wrong code with -O2 on x86_64/Linux

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
Author: mpolacek
Date: Wed Sep 30 11:45:40 2015
New Revision: 228287

URL: https://gcc.gnu.org/viewcvs?rev=228287=gcc=rev
Log:
PR tree-optimization/67690
* tree-ssa-ifcombine.c (pass_tree_ifcombine::execute): Call
reset_flow_sensitive_info_in_bb.
* tree-ssa-tail-merge.c: Include "stringpool.h" and "tree-ssanames.h".
(replace_block_by): Call reset_flow_sensitive_info_in_bb.
* tree-ssanames.c: Include "gimple-iterator.h".
(reset_flow_sensitive_info_in_bb): New function.
* tree-ssanames.h (reset_flow_sensitive_info_in_bb): Declare.

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

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr67690.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/tree-ssa-ifcombine.c
branches/gcc-5-branch/gcc/tree-ssa-tail-merge.c
branches/gcc-5-branch/gcc/tree-ssanames.c
branches/gcc-5-branch/gcc/tree-ssanames.h

[Bug c++/67773] destructor called on temp object before and named object after move, while not being called on named object before move

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
I don't see a bug here, could you please try a supported release and explain
exactly what output you are seeing and what you expect to see.

[Bug c++/67773] destructor called on temp object before and named object after move, while not being called on named object before move

[awenocur at aol dot com]

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

--- Comment #4 from Adam Wenocur  ---
(In reply to Jonathan Wakely from comment #3)
> Oh, are you expecting this:
> 
>   a_thing = demo(demo::second);
> 
> to have the same behaviour as this:
> 
>   a_thing.~demo();
>   new(_thing) demo(demo::second);
> 
> ?
> 
> That's not how C++ works.

I don't expect the same behavior, however I expect the same end result:

for the destructor to be called on to be called on the named variable before
the move, then for it to be called on the temporary object.

[Bug c++/67773] destructor called on temp object before and named object after move, while not being called on named object before move

[awenocur at aol dot com]

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

--- Comment #5 from Adam Wenocur  ---
(In reply to Jonathan Wakely from comment #3)
> Oh, are you expecting this:
> 
>   a_thing = demo(demo::second);
> 
> to have the same behaviour as this:
> 
>   a_thing.~demo();
>   new(_thing) demo(demo::second);
> 
> ?
> 
> That's not how C++ works.

I don't expect the same behavior, however I expect the same end result:

for the destructor to be called on to be called on the named variable before
the move, then for it to be called on the temporary object.

[Bug target/67780] New: Excess instructions for when returning an int from testing a bit in a uint16_t table, including slow-decode-on-Intel length-changing prefix. Seen with ctype (isalnum)

[peter at cordes dot ca]

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

Bug ID: 67780
   Summary: Excess instructions for when returning an int from
testing a bit in a uint16_t table, including
slow-decode-on-Intel length-changing prefix.  Seen
with ctype (isalnum)
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---
Target: x86, x86-64

tags and stuff may be incomplete, I'm not sure if x86, x86-64 is correct for
target.

Many of the ctype glibc functions (isalnum, for example) compile to a lookup of
a 16bit type mask, and then returning one bit of that.

All the glibc macros boil down to something essentially like this:

unsigned short* get_table(void);  // one less layer of indirection than
__ctyle_b_loc
int foo(int c) {
  return get_table()[c] & 1U<<10;
}
int bar(int c) {
  return get_table()[c] & 1U<<3;
}

Testing on godbolt (https://goo.gl/SWJEyP) shows:

g++ from 4.4.7 to 4.6.4 make sub-optimal x86-64 code that uses mov+movsx
separately.

g++ 4.7.3 to 5.2.0 make terrible x86-64 and x86 code that uses AND $1024, %ax. 
This is a case where the operand-size prefix changes the length of the *rest*
of the instruction, stalling the decoders in Intel CPUs for multiple cycles.


 gcc avoids the LCP with -m32 -mtune=pentium3, but not with -mtune=core2. 
Core2 may avoid the LCP stall if the instruction is part of a very small
(64byte) loop, since core2 can use its instruction fetch queue as a loop buffer
(before the decoders, but maybe with insn lengths already marked).  Intel CPUs
with a uop-cache (SnB and later) are hurt less often by LCP stalls, but in this
case writing the partial register is a bad idea anyway.


Clang produces an optimal sequence:
foo(int):# @foo(int)
pushq   %rbx
movslq  %edi, %rbx
callq   get_table()
movzwl  (%rax,%rbx,2), %eax
andl$1024, %eax # imm = 0x400
popq%rbx
retq


5.2.0 g++ -O3 -march=native -mtune=native on godbolt (where native=haswell)
does this:

foo(int):
pushq   %rbx#
movslq  %edi, %rbx  # c,
callget_table() #
movzwl  (%rax,%rbx,2), %eax # *_7, *_7
popq%rbx#
andw$1024, %ax  #, D.2584
movzwl  %ax, %eax   # D.2584, D.2585
ret

The last movzwl is there I guess to avoid the partial-register penalty from
writing %ax instead of %eax.  The 3 instruction bytes for movzwl  take more
space than was saved by using andw with an imm16 (4 bytes including the
operand-size prefix) instead of andl with an imm32 (5 bytes).  Since we're
tuning for Haswell, we should omit the movzwl.  Agner Fog says that Haswell has
no visible perf penalties for writing partial registers.  SnB/IvB still need an
extra uop, but maybe have a smaller penalty than earlier CPUs.  It sounds like
core2 takes 2-3 extra cycles to insert the extra uop.

Maybe that's not why gcc was using movzwl?  bar compiles to
...
movzwl  (%rax,%rbx,2), %eax # *_7, *_7
popq%rbx#
andl$8, %eax#, D.2604
movzwl  %ax, %eax   # D.2604, D.2605
ret

That's  AND r32, imm8   so gcc doesn't try to save space by using the
LCP-penalty-inducing imm16 version this time.  However, it zero-extends twice:
once as part of the load, and again after the and.

Since the high bit of the 16bit word can't be set after the AND, the 3-byte
movzwl could be replaced with the one-byte CWDE to sign-extend ax to eax, but
either way it just shouldn't be there wasting space in the uop cache.  This is
probably still a target bug, since ARM and ARM64 don't have an extra
instruction after the AND.



This is a regression from older g++, like 4.4.7: which produced

foo(int):
pushq   %rbx#
movl%edi, %ebx  # c, c
callget_table() #
movslq  %ebx,%rbx   # c, c
movzwl  (%rax,%rbx,2), %eax #* D.2216, tmp61
popq%rbx#
andl$1024, %eax #, tmp61
ret

Note the 32bit mov before the call, then sign-extending after.  Other than
that, it's optimal.


This bug affects the C frontend, not just C++ (which is all godbolt gives
access to for easy testing):

objdump -d /lib/x86_64-linux-gnu/libc-2.21.so  # on x86-64 Ubuntu 15.04:

0002e190 :
   2e190:   48 8b 05 69 5c 39 00mov0x395c69(%rip),%rax#
3c3e00 <_IO_file_jumps+0x5c0>
   2e197:   48 63 ffmovslq %edi,%rdi
   2e19a:   64 48 8b 00 mov%fs:(%rax),%rax
   2e19e:   0f b7 04 78 movzwl (%rax,%rdi,2),%eax
   2e1a2:   66 25 00 04 and

[Bug c++/67773] destructor called on temp object before and named object after move, while not being called on named object before move

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Oh, are you expecting this:

  a_thing = demo(demo::second);

to have the same behaviour as this:

  a_thing.~demo();
  new(_thing) demo(demo::second);

?

That's not how C++ works.

[Bug c/67730] [5/6 Regression] No warning when returning NULL in void function

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Wed Sep 30 11:26:44 2015
New Revision: 228286

URL: https://gcc.gnu.org/viewcvs?rev=228286=gcc=rev
Log:
PR c/67730
* c-typeck.c (c_finish_return): Use the expansion point location for
certain "return with value" warnings.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr67730.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/67690] [5/6 Regression] wrong code with -O2 on x86_64/Linux

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #8 from Marek Polacek  ---
Fixed.

[Bug c++/67777] unsigned wchar_t and signed wchar_t should cause compiler errors but do not.

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
This is a GNU extension, use -Wpedantic or -Werror=pedantic to get a
diagnostic.

The diagnostic is not enormously helpful though:

w.cc:1:17: warning: long, short, signed or unsigned used invalidly for
‘parameter’ [-Wpedantic]

[Bug c++/67777] unsigned wchar_t and signed wchar_t should cause compiler errors but do not.

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Trevor Hickey from comment #0)
> Why can we add signed/unsigned qualifiers to wchar_t?  

It produces a type of the same size but with the opposite signedness, like
std::make_signed/std::make_unsigned.

[Bug tree-optimization/67690] [5/6 Regression] wrong code with -O2 on x86_64/Linux

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Author: mpolacek
Date: Wed Sep 30 09:24:02 2015
New Revision: 228284

URL: https://gcc.gnu.org/viewcvs?rev=228284=gcc=rev
Log:
PR tree-optimization/67690
* tree-ssa-ifcombine.c (pass_tree_ifcombine::execute): Call
reset_flow_sensitive_info_in_bb.
* tree-ssa-tail-merge.c (replace_block_by): Likewise.
* tree-ssanames.c: Include "gimple-iterator.h".
(reset_flow_sensitive_info_in_bb): New function.
* tree-ssanames.h (reset_flow_sensitive_info_in_bb): Declare.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr67690.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ifcombine.c
trunk/gcc/tree-ssa-tail-merge.c
trunk/gcc/tree-ssanames.c
trunk/gcc/tree-ssanames.h

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

[arjen.markus895 at gmail dot com]

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

Bug ID: 67779
   Summary: Strange ordering with strings in extended object
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arjen.markus895 at gmail dot com
  Target Milestone: ---

Created attachment 36421
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36421=edit
Source file demonstrating the problem

The attached program constructs a small array of integers and strings and then
sorts them. The output is:
 Sorting ...
 Result:
   1
   2
   3
   4
   5
   6
   7
   8
   9
  10
 String = 10 
 String = 1  
 String = 2  
 String = 3  
 String = 4  
 String = 5  
 String = 6  
 String = 7  
 String = 8  
 String = 9   

What is unexpected is the fact that "String = 10" comes before "String = 1". I
have not been able to reduce the code (other than removing the derived type
with integers) and still exhibit the odd ordering. The ten integers show that
the quicksort routine does its job, though. When comparing the strings in a
small program, "String = 10" definitely comes after "String = 1" as I would
expect.

[Bug c++/60153] Variadic template parameter's typedefs cause internal compile error: in dependent_type_p on RedHat

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-30
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Markus Trippelsdorf  ---
markus@x4 /tmp % cat test.ii
enum foo { y };
template  class A;
template  struct B { typedef T value_type; };
template  struct madscience_intitializer {
  template  using ret_type = A;
};
int main() { madscience_intitializer::ret_type<1, y>; }

markus@x4 /tmp % g++ -std=c++14 -c test.ii
test.ii: In function ‘int main()’:
test.ii:7:68: internal compiler error: in dependent_type_p, at cp/pt.c:21951
 int main() { madscience_intitializer::ret_type<1, y>; }
^
0x5e0df4 dependent_type_p(tree_node*)
../../gcc/gcc/cp/pt.c:21951
0x5e1138 dependent_scope_p(tree_node*)
../../gcc/gcc/cp/pt.c:21982
0x5cdf87 make_typename_type(tree_node*, tree_node*, tag_types, int)
../../gcc/gcc/cp/decl.c:3569
0x5f0ac8 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:13266
0x5f4e77 coerce_template_parameter_pack
../../gcc/gcc/cp/pt.c:7362
0x5f4e77 coerce_template_parms
../../gcc/gcc/cp/pt.c:7564
0x5f5418 coerce_innermost_template_parms
../../gcc/gcc/cp/pt.c:7747
0x5f5932 lookup_template_class_1
../../gcc/gcc/cp/pt.c:8247
0x5f5932 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/gcc/cp/pt.c:8588
0x68efbe finish_template_type(tree_node*, tree_node*, int)
../../gcc/gcc/cp/semantics.c:3046
0x648cf9 cp_parser_template_id
../../gcc/gcc/cp/parser.c:14405
0x648f67 cp_parser_class_name
../../gcc/gcc/cp/parser.c:20561
0x6430d6 cp_parser_qualifying_entity
../../gcc/gcc/cp/parser.c:5986
0x6430d6 cp_parser_nested_name_specifier_opt
../../gcc/gcc/cp/parser.c:5670
0x649990 cp_parser_simple_type_specifier
../../gcc/gcc/cp/parser.c:15679
0x639515 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:15376
0x64ca3a cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:12264
0x65bdca cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11830
0x63ced4 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11777
0x63da02 cp_parser_declaration_statement
../../gcc/gcc/cp/parser.c:11393
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug rtl-optimization/67635] [SH] ifcvt missed optimization

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 CC||kyrylo.tkachov at arm dot com

--- Comment #1 from Oleg Endo  ---
Here are some more missed ifcvt cases.  I haven't done any analysis what's
happening, just dumping them here for later.  When compiling those cases, they
result in conditional branches, although they could be done without.

I ran into these when adding the addsicc pattern to SH (PR 54236 attachment
36012).  However, I haven't committed the actual addsicc part, because it
doesn't seem to do anything on SH.

Kyrill, maybe some of those cases could be interesting for you, since you've
been doing some ifcvt work recently.

// this is a GCC 6 regression.  it works on GCC 5
// if "y != x" is changed to "y == x" it also works.
int test_01_3 (int x, int y)
{
  if (y != x)
++x;
  return x;

/*
GCC 5:
cmp/eq  r4,r5
mov #-1,r1
mov r4,r0
rts 
subcr1,r0
*/
}

// another GCC 6 regression.  works on GCC 5
int test_01_5 (int x, float y, float z)
{
  if (y >= z)
++x;

  return x;
}
/*
good:
fpchg
fcmp/gt fr4,fr5
mov #0,r0
bt  .L6
fcmp/eq fr4,fr5
.L6:
addcr4,r0<< expected addc
fpchg
rts 
nop
*/


int test_00 (int x, int y)
{
  return x == 0 ? 1 : x;
}

int test_00_1 (int x, int y)
{
  return x ? x += 1 : x;
}

unsigned int test_02 (unsigned int x)
{
  return x == 0 ? x + 1 : x;  // will not use addcc in ifcvt
}

int test_02 (int x)
{
  return x == 0 ? x + 1 : x; // will not use addc
}


// doesn't work with unsigned int, but ...
unsigned int test_03 (unsigned int x)
{
  return x > 0 ? x + 1 : x;
}

// ... works with signed int (in pr54236-5.c)
int test_05_3 (int x)
{
  return x > 0 ? x + 1 : x;
}


int test_05_1 (int x)
{
  return x != 0 ? x + 1 : x;
}

int test_05_2 (int x)
{
  return x == 0 ? x + 1 : x;
}

unsigned int check_0 (unsigned int x)
{
  return x == 0 ? 1 : x;
}

unsigned int test_130 (unsigned int x)
{
  return x != 0 ? (x - 1) : x;
}

unsigned int test_101 (unsigned int x, unsigned int y)
{
  return x == y ? 1 : x;
}

unsigned int test_102 (unsigned int x)
{
  return x == 3 ? 1 : x;
}

[Bug c++/67773] destructor called on temp object before and named object after move, while not being called on named object before move

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Specifically, a move assignment doesn't destroy anything, it just performs an
assignment. So the named variable is not destroyed, its move assignment
operator is called, which does whatever it is written to do. The temporary is
destroyed at the end of the expression, moving from it doesn't alter its
lifetime in any way. The named variable is destroyed at the end of the block as
usual, move assigning to it doesn't alter its lifetime in any way.

There are online compilers you can use to check the results from various GCC
and Clang releases, e.g. http://melponlorg/wandbox

You will find none of them runs a destructor on the target of a move
assignment, because that's not how C++ works.

[Bug c++/67773] destructor called on temp object before and named object after move, while not being called on named object before move

[awenocur at aol dot com]

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

--- Comment #6 from Adam Wenocur  ---
Whoops! Sorry about the malformed double-post.

Another way of explaining the problem is that the compiler appears to be
suppressing the wrong destructor call.  Since this is a move and not a copy, or
in C++03 it's a copy elision, it should be suppressing the destructor call on
the temporary variable.  It's not doing this though; it's suppressing the first
destructor call on the named variable instead.

When I get a chance, I'll build a GCC for testing purposes.  What version would
be appropriate in this case?  Is 4.8.5 supported?

[Bug target/67780] Excess instructions for when returning an int from testing a bit in a uint16_t table, including slow-decode-on-Intel length-changing prefix. Seen with ctype (isalnum)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target|x86, x86-64 |x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-30
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug c++/60188] [c++11] ICE with parameter pack in default template parameter

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #3 from Markus Trippelsdorf  ---
Also happens with valid code.
Dup of 60153.

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

[Bug c++/60153] Variadic template parameter's typedefs cause internal compile error: in dependent_type_p on RedHat

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||reichelt at gcc dot gnu.org

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

[Bug c/67781] New: Wrong code generated on mips32 with -O1 -fexpensive-optimizations

[jdboyer at media5corp dot com]

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

Bug ID: 67781
   Summary: Wrong code generated on mips32 with -O1
-fexpensive-optimizations
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jdboyer at media5corp dot com
  Target Milestone: ---

Created attachment 36422
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36422=edit
Test program that shows the problem

I'm using a custom build of gcc 5.2.0, for cross-compiling on mips32. It was
generated on a Centos 7 x86_64 system (gcc 4.8.2).

The configuration was done using the following arguments:
  --target=mips-linux --enable-tls --with-arch=mips32 --with-float=soft

Then, if I use the generated compiler to compile the attached program
"shift.c", the result will be wrong when using -O2, but good when using -O1.

More precisely, the argument -fexpensive-optimizations is most probably the
cause. Let's say I compile the program like this:

  mips-linux-gcc shift.c -o shift -O1 -fexpensive-optimizations

If I execute the program in the embedded system, the result is wrong:

  [root@10.11.254.210 jdboyer]# ./shift
  123456

If I compile it like this instead:

  mips-linux-gcc shift.c -o shift -O2 -fno-expensive-optimizations

The result is good:

  [root@10.11.254.210 jdboyer]# ./shift
  12345678

[Bug libstdc++/65049] Undefined behaviour with std::char_traits

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |5.3

[Bug target/67782] New: [SH] Improve bit tests of values loaded from memory

[olegendo at gcc dot gnu.org]

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

Bug ID: 67782
   Summary: [SH] Improve bit tests of values loaded from memory
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olegendo at gcc dot gnu.org
  Target Milestone: ---
Target: sh*-*-*

The following example

int test (int* x)
{
  return (*x & (1 << 14)) == 0;
}

compiled with -O2 -m4 -ml:
mov.l   @r4,r1
mov.w   .L2,r2
tst r2,r1
rts 
movtr0
.align 1
.L2:
.short  16384

compiled with -Os -m4 -ml (uses some constant optimization in tstsi_t pattern):
mov.l   @r4,r0
swap.b  r0,r0
tst #64,r0
rts 
movtr0

Instead of loading the whole 32 bit value from memory, loading one byte is
enough:
   mov.b@(1,r4),r0
   tst  #64,r0
   rts
   movt r0

Because the value has to go into R0 anyway, using a displacement mov.b is OK,
if the displacement is in range and if no further address calculations are
needed (e.g. for a different mode than displacement addressing).  If the
constant is not shared with anything else, this can be a win.

Actually the SLOW_BYTE_ACCESS macro has a similar effect.  Defining it to 0
will make some optimizations try things like above.  Although that particular
case doesn't see any improvement, there are some hits in the CSiBE set.  For
example in linux tcp_input.c:

SLOW_BYTE_ACCESS = 1:
mov.l   @(32,r4),r3
mov.l   @(12,r3),r3
tst r10,r3

SLOW_BYTE_ACCESS = 0:
mov.l   @(32,r4),r0
mov.b   @(13,r0),r0
tst #192,r0

tcp_input.c seems to have quite a couple of such cases.  There are also other
cases like binfmt_script.s:

SLOW_BYTE_ACCESS = 1:
mov.l   @r4,r1
add #-68,r15
mov.w   .L54,r2
extu.w  r1,r1
cmp/eq  r2,r1
bf/s.L67

SLOW_BYTE_ACCESS = 0:
mov.w   .L54,r1
add #-68,r15
mov.w   @r4,r2
cmp/eq  r1,r2
bf/s.L67

However, overall the code seems to get a bit worse.  It seems this kind of
transformation has to be done by taking a bit more context into account.  One
idea would be to do it rather later, before/during peephole2, although then
utilizing tst #imm,R0 might be difficult.

It would also be possible to do this during combine by using some special
patterns/predicates that accept a memory operand before register allocation,
and split out the memory load in split1.  However, there are quite a few
patterns involved and the final tstsi_t pattern is formed during split1.  So
maybe tstsi_t can be extended to look for a memory load of the operand and its
addressing mode, and convert the memory load accordingly.  Although that
wouldn't catch the cmp/eq case above.

[Bug ipa/67783] New: quadratic time consumption in IPA inlining with -O1 and higher

[skvadrik at gmail dot com]

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

Bug ID: 67783
   Summary: quadratic time consumption in IPA inlining with -O1
and higher
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skvadrik at gmail dot com
  Target Milestone: ---

Created attachment 36423
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36423=edit
1.c, real1.c

Consider the following code (1.c):

static void f (const char * const * p) {}
void g (const char * p)
{
loop:
if (*p++) goto loop;
if (*p++) goto loop;
// ...
if (*p++) goto loop;
f ();
}

Compilation time with -O1 grows quadratically in the number of repetitions of
statement 'if (*p++) goto loop;'. For example, 80 repetitions result in 11s:
$ time gcc -c 1.c -O1

real0m11.134s
user0m11.097s
sys 0m0.013s

96 repetitions result in 30s, 120 repetitions result in 1m20s and so on. See
file '1.c' in attach. Also see file 'real1.c' in attach for an example of
real-world program (autogenerated by re2c) from which '1.c' was cut down (it
exhibits quadratic behaviour with -O2 and higher).

I tried to analyze a bit. Here's what I found:

Time report:
$ gcc -c 1.c -O1 -ftime-report

Execution times (seconds)
 phase setup :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%)
wall1066 kB (29%) ggc
 phase opt and generate  :  11.44 (100%) usr   0.00 ( 0%) sys  11.47 (100%)
wall2385 kB (66%) ggc
 ipa inlining heuristics :  11.34 (99%) usr   0.00 ( 0%) sys  11.36 (99%)
wall  12 kB ( 0%) ggc
 df reaching defs:   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%)
wall   0 kB ( 0%) ggc
 df live regs:   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%)
wall   0 kB ( 0%) ggc
 register information:   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%)
wall   0 kB ( 0%) ggc
 alias stmt walking  :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%)
wall   0 kB ( 0%) ggc
 tree CFG cleanup:   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%)
wall   0 kB ( 0%) ggc
 tree split crit edges   :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%)
wall  37 kB ( 1%) ggc
 scev constant prop  :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%)
wall  33 kB ( 1%) ggc
 tree SSA verifier   :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%)
wall   0 kB ( 0%) ggc
 tree STMT verifier  :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%)
wall   0 kB ( 0%) ggc
 dominance computation   :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%)
wall   0 kB ( 0%) ggc
 loop init   :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%)
wall1595 kB (44%) ggc
 branch prediction   :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%)
wall   6 kB ( 0%) ggc
 initialize rtl  :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%)
wall  12 kB ( 0%) ggc
 TOTAL :  11.44 0.0011.48  
3617 kB
Extra diagnostic checks enabled; compiler may run slowly.
Configure with --enable-checking=release to disable checks.

So, it must be IPA inlining.

First,`valgrind --tool=callgrind` showed that 99% of time was spent in
'estimate_function_body_sizes' from 'gcc/gcc/ipa-inline-analysis.c'.I further
tracked it down to loop on line 2759:
   
https://github.com/gcc-mirror/gcc/blob/master/gcc/ipa-inline-analysis.c#L2759
and inner loop on line 2791:
   
https://github.com/gcc-mirror/gcc/blob/master/gcc/ipa-inline-analysis.c#L2791
This nested loop causes quadratic time consumption.

Second, if I comment out 'f ();' in the end of '1.c', file compiles
instantly, but the number of iterations in nested loop remains quadratic. So
the problem is not in quadratic number of iteration, it's in the loop's body.
Note that the function 'f' is empty and its argument is immutable, so it cannot
change 'p' and influence control flow.

This is what `perf record`/`perf report` shows:

  14.38%  cc1  cc1[.] find_var_scev_info
  13.58%  cc1  cc1[.] analyze_scalar_evolution_1
  11.25%  cc1  cc1[.] loop_preheader_edge
   8.56%  cc1  cc1[.] instantiate_scev_r
   7.83%  cc1  cc1[.] interpret_rhs_expr
   6.82%  cc1  cc1[.] htab_find_slot_with_hash
   6.65%  cc1  cc1[.] analyze_scalar_evolution
   5.63%  cc1  cc1[.] useless_type_conversion_p
   5.62%  cc1  cc1[.] chrec_convert_1
   3.06%  cc1  cc1[.] compute_scalar_evolution_in_loop
   2.98%  cc1  cc1[.]
chrec_contains_symbols_defined_in_loop
   1.90%  cc1  cc1[.] instantiate_scev
   1.80%  cc1  

[Bug c/67730] [5/6 Regression] No warning when returning NULL in void function

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Author: mpolacek
Date: Wed Sep 30 12:21:03 2015
New Revision: 228288

URL: https://gcc.gnu.org/viewcvs?rev=228288=gcc=rev
Log:
PR c/67730
* c-typeck.c (c_finish_return): Use the expansion point location for
certain "return with value" warnings.

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

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr67730.c
Modified:
branches/gcc-5-branch/gcc/c/ChangeLog
branches/gcc-5-branch/gcc/c/c-typeck.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c++/67773] destructor called on temp object before and named object after move, while not being called on named object before move

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Adam Wenocur from comment #6)
> Another way of explaining the problem is that the compiler appears to be
> suppressing the wrong destructor call.  Since this is a move and not a copy,
> or in C++03 it's a copy elision,

No, you can't elide an assignment to an existing variable.

> it should be suppressing the destructor
> call on the temporary variable.  It's not doing this though; it's
> suppressing the first destructor call on the named variable instead.

No, that's not how C++ works.

> When I get a chance, I'll build a GCC for testing purposes.  What version
> would be appropriate in this case?  Is 4.8.5 supported?

No, the currently supported versions are listed on the home page,
https://gcc.gnu.org/

The oldest supported release is 4.9.3

[Bug fortran/66979] gfortran internal compiler error with malformed FLUSH statement

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
  Known to fail||4.7.4, 4.8.5, 4.9.4, 5.2.1,
   ||6.0

--- Comment #2 from kargl at gcc dot gnu.org ---
I have a patch.

[Bug middle-end/67790] [6 Regression] verify_ssa failed: definition in block 20 follows the use

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|verify_ssa failed:  |[6 Regression] verify_ssa
   |definition in block 20  |failed: definition in block
   |follows the use |20 follows the use

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

[Bug libstdc++/67791] Crash using std::thread and iostream with dynamic loading of a shared library

[nexyon at gmail dot com]

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

--- Comment #1 from nexyon at gmail dot com ---
Created attachment 36431
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36431=edit
the source of the main program

[Bug fortran/67039] Documentation of pseudorandom number intrinsics is incorrect

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #4)
> > > Resolved as WONTFIX?
> >
> > Probably not.  See the last 2 paragraphs in comment #1.
> 
> Sorry, but my question was motivated by the reading of these two
> paragraphs!-(
> Thus two more explicit questions:
> 
> (1) Shall I submit a patch to replace in the manual all the "Fortran 95 and
> later" with "Fortran 90 and later" where appropriate?

No.  gfortran never tried to address the Fortran 90 standard.
Whatever is stated in F90 is irrelevant to the extent that 
gfortran is a Fortran 95 compiler and F90 beget F95.

> 
> (2) Shall I submit a patch to replace 
> 
> The Fortran 2003 standard specifies the intrinsic RANDOM_SEED to initialize 
> the pseudo-random numbers generator and RANDOM_NUMBER to generate 
> pseudo-random numbers.
> 
> with
> 
> The Fortran 9? standard specifies the intrinsic RANDOM_SEED to initialize
> the pseudo-random numbers generator and RANDOM_NUMBER to generate 
> pseudo-random numbers. These intrinsics should be used in new codes.
> 

I would not not call out a particular standard version.  Probably
something like 

 The Fortran standard specifies the intrinsic subroutine RANDOM_SEED
 to initialize the pseudo-random numbers generator and the intrinsic
 subroutine RANDOM_NUMBER to generate pseudo-random numbers.  These
 subroutines should be used in new codes.

[Bug go/66870] split stack issues on ppc64le and ppc64

[ian at gcc dot gnu.org]

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

--- Comment #23 from ian at gcc dot gnu.org  ---
Author: ian
Date: Wed Sep 30 23:06:11 2015
New Revision: 228311

URL: https://gcc.gnu.org/viewcvs?rev=228311=gcc=rev
Log:
PR target/66870
* config/rs6000/sysv4.h (TARGET_CAN_SPLIT_STACK_64BIT): Define.
* configure.ac: Define HAVE_GOLD_ALTERNATE_SPLIT_STACK on Power
based on gold linker version.
* gcc.c: Add -fuse-ld=gold to STACK_SPLIT_SPEC if
HAVE_GOLD_ALTERNATE_SPLIT_STACK defined.
* configure, config.in: Regenerate.
go:
* gospec.c (lang_specific_driver): Set appropriate split stack
options for 64 bit compiles based on TARGET_CAN_SPLIT_STACK_64BIT.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.in
trunk/gcc/config/rs6000/sysv4.h
trunk/gcc/configure
trunk/gcc/configure.ac
trunk/gcc/gcc.c
trunk/gcc/go/ChangeLog
trunk/gcc/go/gospec.c

[Bug libstdc++/67791] Crash using std::thread and iostream with dynamic loading of a shared library

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
So the problem here is libstdc++ first tries to figures out if you are linked
against pthreads and if you are not then it skips locks in some cases.  In this
case since the main program was not linked against pthreads and you initialized
libstdc++ via the include of iostream, it sets the single threaded use case.

[Bug libstdc++/67791] New: Crash using std::thread and iostream with dynamic loading of a shared library

[nexyon at gmail dot com]

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

Bug ID: 67791
   Summary: Crash using std::thread and iostream with dynamic
loading of a shared library
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nexyon at gmail dot com
  Target Milestone: ---

Created attachment 36430
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36430=edit
the source of the shared library

If you think the summary of this bug is long/strange: yes, to me this seems
like the most weird bug, I have ever found.

What I am doing is the following:

* I have a main program (main.cpp) that loads a dynamic library thread.so and
calls a function in there.
* main.cpp also includes  without actually using this library.
(sounds weird, eh?)
* The function in thread.so creates a std::thread and runs it.
* The application crashes when the thread should be started.

Let me show you what happens (or: how to reproduce):

--

% g++ -g -fPIC -shared -o thread.so thread.cpp -std=c++11 -lpthread
% g++ -g -ldl -o main main.cpp
%  gdb main
GNU gdb (GDB) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from main...done.
(gdb) r
Starting program: /data/Work/Computer/Programming/Audaspace/bug/main 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt full
#0  0x in ?? ()
No symbol table info available.
#1  0x7790e493 in __gthread_create (__args=,
__func=0x7790e330 , __threadid=0x7fffdd60)
at
/build/gcc-multilib/src/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu/bits/gthr-default.h:662
No locals.
#2  std::thread::_M_start_thread (this=0x7fffdd60, __b=...) at
/build/gcc-multilib/src/gcc-5.2.0/libstdc++-v3/src/c++11/thread.cc:149
No locals.
#3  0x76d99826 in std::thread::thread(void (&)(int, unsigned long long*), int&&,
unsigned long long*&) (this=0x7fffdd60, __f=
@0x76d993e2: {void (int, unsigned long long *)} 0x76d993e2
) at /usr/include/c++/5.2.0/thread:137
No locals.
#4  0x76d99463 in run () at thread.cpp:17
a = 4196233
c = 0x7fffdd70
t1 = {_M_id = {_M_thread = 0}}
#5  0x00400793 in main (argc=1, argv=0x7fffdea8) at main.cpp:9
handle = 0x612c40
run_func = 0x76d99430 
(gdb)

--

Now why is this weird/funny?

There are two ways you can get rid of the crash:

* the first is to add -lpthread to the second g++ line (the one that compiles
main.cpp and links the main program) OR
* you remove the line #include  in main.cpp

I found this bug in a way bigger code base as you can imagine and I already
spent a lot of time to get it down to this minimal example. I hope you can
find, what is the problem here! Thanks!

[Bug libgcc/67792] New: GCC 5.2 - make clean fails in libgcc

[gary at intrepid dot com]

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

Bug ID: 67792
   Summary: GCC 5.2 - make clean fails in libgcc
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gary at intrepid dot com
  Target Milestone: ---

When building with both the GCC 5.2 release and the latest gcc-5-branch, after
a successful build and bootstrap, a 'make clean' at the top level fails as
follows.

make[1]: Leaving directory `/eng/upc/dev/gary/gcc-5-x/save/x86_64-unknown-linux
-gnu/libstdc++-v3'
make[1]: -B/eng/upc/dev/gary/gcc-5-x/rls/x86_64-unknown-linux-gnu/bin/: Command
 not found
make[1]: Entering directory `/eng/upc/dev/gary/gcc-5-x/save/x86_64-unknown-linu
x-gnu/libgcc'
make[1]: -B/eng/upc/dev/gary/gcc-5-x/rls/x86_64-unknown-linux-gnu/bin/: Command
 not found
/bin/sh: line 0: test: !=: unary operator expected
rm -f libgcc_tm.h libgcc.map
Makefile:172: *** Recursive variable `AR_FOR_TARGET' references itself (eventua
lly).  Stop.

Above, the compiler has not yet been installed under 'rls/...', and therefore
is not found.  It wasn't clear to me why AR_FOR_TARGET is recursive:

 170 # Flags to pass to recursive makes.
 171 
 172 AR_FOR_TARGET = $(AR)

Top-level configure:

/eng/upc/dev/gary/gcc-5-x/src/configure CFLAGS='-g3 -O3' CXXFLAGS='-g3 -O3' CC=
/usr/bin/gcc CXX=/usr/bin/g++ --prefix=/eng/upc/dev/gary/gcc-5-x/rls --enable-l
anguages=all

[Bug c/67793] New: Detect incorrect function arg sizes at compile time.

[rusty at rustcorp dot com.au]

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

Bug ID: 67793
   Summary: Detect incorrect function arg sizes at compile time.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rusty at rustcorp dot com.au
  Target Milestone: ---

It would be great if GCC warned on this:

extern int func_(char x[32]);
int main(int argc, char *argv[])
{
char p[8];

return func(p);
}

Failing that, if __builtin_object_size() returned a compile-time constant where
possible, we could do this (with __builtin_constant_p):

#define SIZE_CHECK(v,min) ({static_assert(__builtin_object_size((v), 0) >=
(min), "too small"); (v)})

extern int func_(char x[32]);
#define func(x) func_(SIZE_CHECK((x),32))

[Bug c/67764] -Wconversion generates false warnings for bitmask+cast expressions

[egall at gwmail dot gwu.edu]

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

--- Comment #3 from Eric Gallager  ---
Wait actually I think this might be a dup of bug 40752

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

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Confirmed. Looking into it

[Bug target/67788] New: [6 Regression] bootstrap failure in libgfortran on powerpc-linux-gnu

[doko at gcc dot gnu.org]

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

Bug ID: 67788
   Summary: [6 Regression] bootstrap failure in libgfortran on
powerpc-linux-gnu
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

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

seen with trunk 20150930, 

/home/doko/gcc/gcc-snapshot-20150930/build/./gcc/xgcc
-B/home/doko/gcc/gcc-snapshot-20150930/build/./gcc/
-B/usr/lib/gcc-snapshot/powerpc-linux-gnu/bin/
-B/usr/lib/gcc-snapshot/powerpc-linux-gnu/lib/ -isystem
/usr/lib/gcc-snapshot/powerpc-linux-gnu/include -isystem
/usr/lib/gcc-snapshot/powerpc-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
-I../../../src/libgfortran -iquote../../../src/libgfortran/io
-I../../../src/libgfortran/../gcc -I../../../src/libgfortran/../gcc/config
-I../.././gcc -I../../../src/libgfortran/../libgcc -I../libgcc
-I../../../src/libgfortran/../libbacktrace -I../libbacktrace -I../libbacktrace
-std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules
-ffunction-sections -fdata-sections -g -O2 -MT fpu.lo -MD -MP -MF .deps/fpu.Tpo
-c ../../../src/libgfortran/runtime/fpu.c  -fPIC -DPIC -o .libs/fpu.o
-save-temps
fpu.s: Assembler messages:
fpu.s:736: Error: symbol `.L148' is already defined
fpu.s:781: Error: symbol `.L148' is already defined

I Also saw this building gzlib.so in zlib.

Configured with: ../src/configure -v --with-pkgversion='Ubuntu
20150930-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++
--prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id
--disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--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-6-snap-powerpc/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-snap-powerpc
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-snap-powerpc
--with-arch-directory=ppc --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-secureplt --disable-softfloat --with-cpu=default32
--disable-softfloat --enable-targets=powerpc-linux,powerpc64-linux
--enable-multiarch --disable-werror --with-long-double-128 --enable-multilib
--enable-checking=yes --build=powerpc-linux-gnu --host=powerpc-linux-gnu
--target=powerpc-linux-gnu

binutils version is 2.25.1

[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE

[derodat at adacore dot com]

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

--- Comment #41 from Pierre-Marie de Rodat  ---
Thank you again for spotting this! Yes, these artificial defs break the
consevativeness for the MIR analysis. I guess your proposal would work:
considering as uninintialized registers than aren’t is conservative
although it will prevent more optimizations that one could expect in
REE. I don’t know if it’s a problem in practice but your example shows
that we have a lot of registers in this situation.

At this point, though, I wonder why artificial defs do not describe what
actually happens for this function. Shouldn’t we instead fix DF to emit
artificial defs only for actual input registers? I’ll investigate this.

… and then I will followup on gcc-patches as you suggested. Once more,
thank you all for your help in this! :-)

[Bug middle-end/67785] New: irrevocable-3.c: transaction_callable does nothing on external declaration

[jason at gcc dot gnu.org]

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

Bug ID: 67785
   Summary: irrevocable-3.c: transaction_callable does nothing on
external declaration
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason at gcc dot gnu.org
CC: aldyh at gcc dot gnu.org, rth at gcc dot gnu.org,
torvald at gcc dot gnu.org
  Target Milestone: ---

In gcc.dg/tm/irrevocable-3.c:

extern void bar(void) __attribute__((transaction_callable));

void
foo()
{
__transaction_relaxed {
bar();
}
}

The transaction_callable attribute seems to have no effect; the transaction
goes irrevocable and calls the non-transaction entry point for bar whether or
not it is present.

Shouldn't the transaction call the TM clone if _ITM_beginTransaction says to
run instrumented code?  If not, what is the point of the attribute?

[Bug c/67784] New: Incorrect parsing when using declarations in for loops and typedefs

[jacques-henri.jourdan at inria dot Fr]

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

Bug ID: 67784
   Summary: Incorrect parsing when using declarations in for loops
and typedefs
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jacques-henri.jourdan at inria dot Fr
  Target Milestone: ---

The following code snippet does not parse correctly:

typedef int T;

void h() {
  for(int T; ;)
if(1)
  ;
  T *x;
  x = 0;
}

However, this one does:

typedef int T;

void h() {
  for(int T; ;)
if(1)
  ;
  ;
  T *x;
  x = 0;
}

[Bug ipa/66424] [5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu in 32-bit mode

[aurelien at aurel32 dot net]

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

Aurelien Jarno  changed:

   What|Removed |Added

 CC||aurelien at aurel32 dot net

--- Comment #11 from Aurelien Jarno  ---
For the record this bug badly affects the MIPS target when using
-mtune=mips32r2, option which is implied by the -march=mips32r2 option. This
causes for example ffmpeg to be miscompiled, which causes its testsuite to fail
completely.

It's not a problem anymore now that the bug has been fixed on the gcc-5-branch,
however I prefer to mention it here, so that people debugging this issue find
this bug.

[Bug rtl-optimization/67787] New: wrong code at -O3 on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

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

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

This is a regression from 5.2.x.

I wasn't able to get rid of the call to printf. 


$ 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 20150930 (experimental) [trunk revision 228291] (GCC) 
$ 
$ gcc-trunk -O2 small.c; ./a.out
 $ 
$ gcc-5.2 -O3 small.c; ./a.out
 $ 
$ 
$ gcc-trunk -O3 small.c
$ ./a.out
 Aborted
$ 





int printf (const char *, ...);

int a, c, f, g;
char b;

static int
fn1 ()
{
  char h;
  int k = -1, i, j;
  for (; b < 16; b++)
;
  printf (" ");
  if (b < 5)
k++;
  if (k)
{
  int l = 2;
  a = h = b < 0 || b > (127 >> l) ? b : b << 1;
  return 0;
}
  for (i = 0; i < 1; i++)
for (j = 0; j < 7; j++)
  f = 0;
  for (c = 0; c; c++)
;
  if (g)
for (;;)
  ;
  return 0;
}

int
main ()
{
  fn1 ();

  if (a != 32) 
__builtin_abort (); 

  return 0;
}

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

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Started with r227368.

[Bug rtl-optimization/67029] [5 Regression] gcc-5.2.0 unable to find a register to spill with O3 fsched-pressure fschedule-insns

[hjl at gcc dot gnu.org]

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

--- Comment #15 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Wed Sep 30 16:39:44 2015
New Revision: 228299

URL: https://gcc.gnu.org/viewcvs?rev=228299=gcc=rev
Log:
Add alternative_mask to ira_implicitly_set_insn_hard_regs

Since ira_implicitly_set_insn_hard_regs may be called outside of
ira-lives.c, it can't use the local variable, preferred_alternatives.
This patch adds an alternative_mask argument to
ira_implicitly_set_insn_hard_regs.

Backport from mainline

gcc/

PR rtl-optimization/67029
* ira-color.c: Include "recog.h" before including "ira-int.h".
* target-globals.c: Likewise.
* ira-lives.c (ira_implicitly_set_insn_hard_regs): Add an
adds an alternative_mask argument and use it instead of
preferred_alternatives.
* ira.h (ira_implicitly_set_insn_hard_regs): Moved to ...
* ira-int.h (ira_implicitly_set_insn_hard_regs): Here.
* sched-deps.c: Include "ira-int.h" after including "ira.h".
(sched_analyze_insn): Update call to
ira_implicitly_set_insn_hard_regs.
* sel-sched.c: Include "ira-int.h" after including "ira.h".
(implicit_clobber_conflict_p): Update call to
ira_implicitly_set_insn_hard_regs.

gcc/testsuite/

PR rtl-optimization/67029
* gcc.dg/pr67029.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr67029.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/ira-color.c
branches/gcc-5-branch/gcc/ira-int.h
branches/gcc-5-branch/gcc/ira-lives.c
branches/gcc-5-branch/gcc/ira.h
branches/gcc-5-branch/gcc/sched-deps.c
branches/gcc-5-branch/gcc/sel-sched.c
branches/gcc-5-branch/gcc/target-globals.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/67029] [5 Regression] gcc-5.2.0 unable to find a register to spill with O3 fsched-pressure fschedule-insns

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #16 from H.J. Lu  ---
Fixed.

[Bug c/65345] ICE with _Generic selection on _Atomic int

[mpolacek at gcc dot gnu.org]

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

--- Comment #13 from Marek Polacek  ---
No, the only problem is that I sort of forgot about this one ;).  I'll get it
done tomorrow.

[Bug c/67570] comparison rules fails

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #5 from Joseph S. Myers  ---
As noted, not a bug.

[Bug target/66810] [6] ICE on tree error_mark with -miamcu

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
The current patch is at

https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00879.html

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

[su at cs dot ucdavis.edu]

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

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

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

This is a regression from 5.2.x.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20150930 (experimental) [trunk revision 228291] (GCC) 
$ 
$ gcc-trunk -Os small.c; ./a.out
15
$ gcc-5.2 -O2 small.c; ./a.out
15
$ 
$ gcc-trunk -O2 small.c; ./a.out
-32
$ 
$ 


-


int printf (const char *, ...);

int a, b = 10;
char c;

int
main ()
{
  char d;
  int e = 5;
  for (a = 0; a; a--)
e = 0;
  c = (b & 15) ^ e;
  d = c > e ? c : c << e;
  printf ("%d\n", d);
  return 0;
}

[Bug c/65345] ICE with _Generic selection on _Atomic int

[jsm28 at gcc dot gnu.org]

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

--- Comment #12 from Joseph S. Myers  ---
Is there some reason the TARGET_ATOMIC_ASSIGN_EXPAND_FENV patch -
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00682.html - hasn't been
committed, minus the XFAILing and with a note to all affected target
maintainers who may need to fix their ports as requested in
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01792.html ?

[Bug bootstrap/67761] [6 Regression] Bootstrap failure on x86

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #2 from Ilya Enkovich  ---
Fixed by r228292

[Bug c/67784] Incorrect parsing when using declarations in for loops and typedefs

[jacques-henri.jourdan at inria dot Fr]

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

--- Comment #1 from Jacques-Henri Jourdan  ---
My explanation of the problem is that the parser has to do a lookahead to make
sure that there is no "else" associated to the selection statement. However,
this lookahead is done in the wrong context, which make T look like a variable
(while it is actually a type name).

[Bug rtl-optimization/67787] [6 Regression] wrong code at -O3 on x86_64-linux-gnu

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Started with r228194.