[Bug rtl-optimization/69102] [4.9/5/6 Regression] ICE: in move_op_ascend, at sel-sched.c:6138 with -fselective-scheduling2

[abel at gcc dot gnu.org]

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

--- Comment #4 from Andrey Belevantsev  ---
Created attachment 37550
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37550&action=edit
proposed patch

The problem here is readonly dependence contexts in selective scheduler.  We're
trying to cache the effect of initializing a dependence context with
remembering that context and setting a readonly bit on it.  When first moving
the insn 43 with REG_ARGS_SIZE note through the insn 3 (a simple eax set) we
also set the last_args_size field of the context.  Later, when we make a copy
of insn 43 and try to move it again through insn 3, we take the cached
dependency context and notice the (fake) dep with last_args_size insn, which is
the old insn 43.  Then the assert saying that we should be able to lift the
bookkeeping copy up the same way as we did with the original insn breaks.

Fixed by the attached patch that makes us notice only deps with the current
producer insn.  I'd need to test it more thoroughly on several arches though.

Richard, is it safe to make copies of REG_ARGS_SIZE insns? I've read the
original ML thread of the sched-deps REG_ARGS_SIZE patch and couldn't quite
figure it out -- with the current deps setting nothing prevents us from moving
the first REG_ARGS_SIZE insn up and creating bookkeeping copies on the paths
where it is inaccessible.

[Bug sanitizer/68580] FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test

[vries at gcc dot gnu.org]

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

--- Comment #6 from vries at gcc dot gnu.org ---
https://gcc.gnu.org/ml/gcc-cvs/2016-02/msg00030.html :

Author: law
Date: Mon Feb  1 22:05:58 2016
New Revision: 233054

URL: https://gcc.gnu.org/viewcvs?rev=233054&root=gcc&view=rev
Log:
Fix PR # in last change

Modified:
trunk/gcc/ChangeLog

[Bug rtl-optimization/69615] New: 0 to limit signed range checks don't always use unsigned compare

[peter at cordes dot ca]

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

Bug ID: 69615
   Summary: 0 to limit signed range checks don't always use
unsigned compare
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---

gcc sometimes misses the unsigned-compare trick for checking if a signed value
is between 0 and limit (where limit is known to be <= INT_MAX).

It seems that gcc fails when the upper limit is a variable, even if I shift or
mask it down to a small range.  clang handles this case, so I'm sure I
constructed my test case in a way that could be optimized.



All the code in this bug report is on godbolt, for ease of trying with older
versions of gcc (including for ARM64/ARM/PPC), and with clang / icc13. 
http://goo.gl/V7PFmv.   (I used -x c to compile as C, even though it only
provides c++ compilers).

This appears to be arch-independent (unless my quick skim of asm for ISAs I
barely know misled me...)



The simplest case is when the upper limit is a compile-time constant.  There's
one case where gcc and clang fail to optimize:  x<=(INT_MAX-1), or
equivalently, x
#include 
extern void ext(void);

// clang and gcc both optimize range checks up to INT_MAX-2 to a single
unsigned compare
void r0_to_imax_2(int x){ if (x>=0 && x<=(INT_MAX-2)) ext(); }  // good code
void r0_to_imax_1(int x){ if (x>=0 && x<=(INT_MAX-1)) ext(); }  // bad code
void r0_to_imax  (int x){ if (x>=0 && x<=(INT_MAX-0)) ext(); }  // good code
(test/js.  not shown)

gcc 5.3.0 -Ofast -mtune=haswell  compiles this to:

r0_to_imax_2:
cmpl$2147483645, %edi   # that's 0x7ffd
jbe .L4
ret
.L4:jmp ext

r0_to_imax_1:
movl%edi, %eax
subl$0, %eax   ## Without any -mtune, uses test edi,edi
js  .L5
cmpl$2147483647, %edi   # that's 0x7fff
je  .L5
jmp ext
.L5:ret

ICC13 compiles this last one to cmp  edi, 0x7ffe / ja, so unless my mental
logic is wrong *and* icc13 is buggy, gcc and clang should still be able to  use
the same optimization as for smaller upper-limits.  They don't: both clang and
gcc use two compare-and-branches for r0_to_imax_1.

BTW, the movl %edi, %eax / subl $0, %eax sequence is used instead of the test
instruction with -mtune=haswell, and even worse with -march=bdver2 where it
even prevents fusion into a compare-and-branch m-op.  I'll file a separate bug
report for that if anyone wants me to.  Agner Fog's microarch guide doesn't
mention anything that would give that sequence an advantage over test, unless
I'm missing something.  It slows AMD down more than (recent) Intel, but that's
not what tuning for Haswell means. :P



Now, on to the case where the limit is variable, but can easily be proven to
itself be in the range [0 .. INT_MAX-1) or much smaller.  (If the limit can be
negative (or unsigned greater than INT_MAX) the optimization is impossible: 
INT_MIN and other negative numbers could be "below" the limit.)


// gcc always fails to optimize this to an unsigned compare, but clang succeeds
void rangecheck_var(int64_t x, int64_t lim2) {
  //lim2 >>= 60;
  lim2 &= 0xf;  // let the compiler figure out the limited range of limit
  if (x>=0 && x

[Bug c++/49604] forward-declared enum's elements in class scope gets default access (class vs struct)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords|accepts-invalid |
   Last reconfirmed|2014-10-16 00:00:00 |2016-2-1
 CC||msebor at gcc dot gnu.org
  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #5 from Martin Sebor  ---
All supported versions of GCC, including the current trunk of 6.0, have the
problem.  The test case seems strictly valid, though, so removing the
accepts-invalid keyword.

[Bug lto/67548] [5 Regression] LTO drops weak binding with "ld -r"

[amodra at gmail dot com]

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

Bug 68662 Summary: [6 regression] FAIL: gcc.dg/lto/20090210 
c_lto_20090210_0.o-c_lto_20090210_1.o link, -O2 -flto -flto-partition=none 
-fuse-linker-plugin -fno-fat-lto-objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68662

   What|Removed |Added

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

[Bug target/68662] [6 regression] FAIL: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o link, -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

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

--- Comment #14 from Alan Modra  ---
Fixed with workaround. 
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg2.html queued for gcc-7 and
6.1.

[Bug target/69548] libatomic fails to build with -Os on powerpc64-linux

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

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

--- Comment #5 from Alan Modra  ---
Fixed all active branches

[Bug target/69548] libatomic fails to build with -Os on powerpc64-linux

[amodra at gcc dot gnu.org]

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

--- Comment #3 from Alan Modra  ---
Author: amodra
Date: Tue Feb  2 01:29:41 2016
New Revision: 233066

URL: https://gcc.gnu.org/viewcvs?rev=233066&root=gcc&view=rev
Log:
[RS6000] lqarx and stqcx. registers

lqarx RT and stqcx. RS are valid only with even numbered gprs.  The
predicate to enforce this happens to allow a loophole, closed by this
patch.

PR target/69548
gcc/
* config/rs6000/predicates.md (quad_int_reg_operand): Don't
allow subregs.
gcc/testsuite/
* gcc.target/powerpc/pr69548.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/pr69548.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/rs6000/predicates.md
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/69548] libatomic fails to build with -Os on powerpc64-linux

[amodra at gcc dot gnu.org]

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

--- Comment #4 from Alan Modra  ---
Author: amodra
Date: Tue Feb  2 01:29:58 2016
New Revision: 233067

URL: https://gcc.gnu.org/viewcvs?rev=233067&root=gcc&view=rev
Log:
[RS6000] lqarx and stqcx. registers

lqarx RT and stqcx. RS are valid only with even numbered gprs.  The
predicate to enforce this happens to allow a loophole, closed by this
patch.

PR target/69548
gcc/
* config/rs6000/predicates.md (quad_int_reg_operand): Don't
allow subregs.
gcc/testsuite/
* gcc.target/powerpc/pr69548.c: New test.


Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/powerpc/pr69548.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/rs6000/predicates.md
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug target/69548] libatomic fails to build with -Os on powerpc64-linux

[amodra at gcc dot gnu.org]

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

--- Comment #2 from Alan Modra  ---
Author: amodra
Date: Tue Feb  2 01:29:17 2016
New Revision: 233065

URL: https://gcc.gnu.org/viewcvs?rev=233065&root=gcc&view=rev
Log:
[RS6000] lqarx and stqcx. registers

lqarx RT and stqcx. RS are valid only with even numbered gprs.  The
predicate to enforce this happens to allow a loophole, closed by this
patch.

PR target/69548
gcc/
* config/rs6000/predicates.md (quad_int_reg_operand): Don't
allow subregs.
gcc/testsuite/
* gcc.target/powerpc/pr69548.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr69548.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/predicates.md
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/69606] [5/6 Regression] wrong code at -Os and above on x86_64-linux-gnu

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-02
 CC||rguenther at suse dot de
Version|6.0 |5.3.1
   Target Milestone|--- |5.4
Summary|wrong code at -Os and above |[5/6 Regression] wrong code
   |on x86_64-linux-gnu |at -Os and above on
   ||x86_64-linux-gnu
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
It was caused by r220164.

[Bug bootstrap/69611] Bootstrap broken on PowerPC FreeBSD, IEEE 128-bit floating point support.

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug bootstrap/69611] Bootstrap broken on PowerPC FreeBSD, IEEE 128-bit floating point support.

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #2 from Michael Meissner  ---
With the proposed patch, power8 little endian bootstraps fine, and builds the
software floating point emulator and runs the code fine.  I also checked the
power9 generation of hardware __float128 instructions, and it generates the
appropriate instructions.

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|6.0 |---
Summary|[6 Regression] wrong code   |[6 Regression] wrong code
   |with -O and simple 128bit   |with -O and simple 128bit
   |arithmetics @ aarch64   |arithmetics and vectors @
   ||aarch64

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug target/69614] New: [6 Regression] wrong code with -Os -fno-expensive-optimizations -fschedule-insns -mtpcs-leaf-frame -fira-algorithm=priority @ armv7a

[zsojka at seznam dot cz]

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

Bug ID: 69614
   Summary: [6 Regression] wrong code with -Os
-fno-expensive-optimizations -fschedule-insns
-mtpcs-leaf-frame -fira-algorithm=priority @ armv7a
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: armv7a-hardfloat-linux-gnueabi

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

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

$ armv7a-hardfloat-linux-gnueabi-gcc -Os -fno-expensive-optimizations
-fschedule-insns -mtpcs-leaf-frame -fira-algorithm=priority testcase.c
testcase.c:1:0: warning: enabling backtrace support is only meaningful when
compiling for the Thumb
 typedef unsigned short u16;
$ ./a.out 
00020002
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted

Triggering a wrong code at the arm target takes a lot of time, and even then,
the testcase is not very minimal and there are quite many extra compiler flags.

Tested revisions:
r233030 - FAIL
5-branch r233025 - OK
4_9-branch r233024 - OK
4_8-branch r224828 - OK

[Bug target/68662] [6 regression] FAIL: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o link, -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects

[amodra at gcc dot gnu.org]

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

--- Comment #13 from Alan Modra  ---
Author: amodra
Date: Tue Feb  2 00:01:16 2016
New Revision: 233061

URL: https://gcc.gnu.org/viewcvs?rev=233061&root=gcc&view=rev
Log:
[RS6000] ABI_V4 init of toc section

Since 4c4a180d lto has turned off flag_pic when linking a fixed
position executable.  So flag_pic is zero in rs6000_file_start.
However, when we get to actually emitting code, flag_pic may be on
again.  This results in undefined references to ".LCTOC1".

PR target/68662
* config/rs6000/rs6000.c (need_toc_init): New var, set it
whenever toc_label_name used.
(rs6000_file_start): Don't set up toc section here,
(rs6000_output_function_epilogue): do so here instead,
(rs6000_xcoff_file_start): and here.
* config/rs6000/rs6000.md (load_toc_aix_si): Set need_toc_init.
(load_toc_aix_di): Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/rs6000.md

[Bug bootstrap/69611] Bootstrap broken on PowerPC FreeBSD, IEEE 128-bit floating point support.

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
If __NO_FPRS__ is undefined, that means you are compiling for classic hard 
float.  Which means that the soft-fp code is not needed - if you need to 
keep it in libgcc_s.so for binary compatibility, using t-hardfp for 
hard-float multilibs, as on powerpc*-*-linux*, would be better.

[Bug target/69461] [6 Regression] ICE in lra_set_insn_recog_data, at lra.c:964

[vmakarov at gcc dot gnu.org]

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

--- Comment #11 from Vladimir Makarov  ---
I have patches fixing the two issues but when I started to test the patches I
found that LRA actually has >800 additional failures on power8 in comparison
with reload.  So I am going to look at this and try to fix this.

[Bug c++/49604] forward-declared enum's elements in class scope gets default access (class vs struct)

[felix.abecassis at gmail dot com]

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

Felix Abecassis  changed:

   What|Removed |Added

 CC||felix.abecassis at gmail dot 
com

--- Comment #4 from Felix Abecassis  ---
Confirmed again with gcc 5.3.1 on Ubuntu 16.04.
I reused the same test case than Melissa.

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

[zsojka at seznam dot cz]

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

Bug ID: 69613
   Summary: [6 Regression] wrong code with -O and simple 128bit
arithmetics @ aarch64
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-unknown-linux-gnu

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

Output:
$ aarch64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-233030-checking-yes-rtl-df-nographite-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: aarch64-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=aarch64-unknown-linux-gnu
--with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld
--with-as=/usr/bin/aarch64-unknown-linux-gnu-as
--with-sysroot=/usr/aarch64-unknown-linux-gnu --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-233030-checking-yes-rtl-df-nographite-aarch64
Thread model: posix
gcc version 6.0.0 20160201 (experimental) (GCC) 

$ aarch64-unknown-linux-gnu-gcc -O testcase.c
$ ./a.out 
8006
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted

Tested revisions:
r233030 - FAIL
5-branch r233025 - OK
4_9-branch r233024 - OK
4_8-branch r224828 - OK

[Bug c/69558] [6/7 Regression] glib2 warning pragmas stopped working

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|6.0 |7.0
Summary|[6 Regression] glib2|[6/7 Regression] glib2
   |warning pragmas stopped |warning pragmas stopped
   |working |working

--- Comment #13 from Jakub Jelinek  ---
Workaround applied, keeping this open to fix it for real for GCC 7.

[Bug rtl-optimization/69592] [6 Regression] Compile-time and memory-use hog in combine

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug preprocessor/69543] [6/7 Regression] _Pragma does not apply within macro

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|6.0 |7.0
Summary|[6 Regression] _Pragma does |[6/7 Regression] _Pragma
   |not apply within macro  |does not apply within macro

--- Comment #4 from Jakub Jelinek  ---
Workaround applied, keeping this open to fix it for real for GCC 7.

[Bug c/69612] Optimizer does not consider overflow

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Jakub Jelinek  ---
This program triggers undefined behavior.
You can e.g. use -fsanitize=undefined to see it diagnosed at runtime.
Once undefined behavior is reached, anything can happen.

[Bug rtl-optimization/69592] [6 Regression] Compile-time and memory-use hog in combine

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Mon Feb  1 22:39:31 2016
New Revision: 233059

URL: https://gcc.gnu.org/viewcvs?rev=233059&root=gcc&view=rev
Log:
PR rtl-optimization/69592
* rtlanal.c (nonzero_bits_binary_arith_p): New inline function.
(cached_nonzero_bits): Use it instead of ARITHMETIC_P.
(num_sign_bit_copies_binary_arith_p): New inline function.
(cached_num_sign_bit_copies): Use it instead of ARITHMETIC_P.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr69592.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/rtlanal.c
trunk/gcc/testsuite/ChangeLog

[Bug c/69558] [6 Regression] glib2 warning pragmas stopped working

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Author: jakub
Date: Mon Feb  1 22:36:07 2016
New Revision: 233058

URL: https://gcc.gnu.org/viewcvs?rev=233058&root=gcc&view=rev
Log:
PR preprocessor/69543
PR c/69558
* c-pragma.c (handle_pragma_diagnostic): Pass input_location
instead of loc to control_warning_option.

* gcc.dg/pr69543.c: New test.
* gcc.dg/pr69558.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr69543.c
trunk/gcc/testsuite/gcc.dg/pr69558.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-pragma.c
trunk/gcc/testsuite/ChangeLog

[Bug c/69612] New: Optimizer does not consider overflow

[roarl at pvv dot org]

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

Bug ID: 69612
   Summary: Optimizer does not consider overflow
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roarl at pvv dot org
  Target Milestone: ---

I found a short code snippet that produces different results after optimizing
with -O2. I believe my code should work as it only uses a simple test to check
if incrementation has overflowed. It looks like the optimizer, having
established that a variable is >= 0, does not believe the variable can become <
0 after incrementing. However, I am relying on just that to catch the overflow.

In the code below, the __attribute__((noinline)) is not necessary to
demonstrate the "effect", however without it the "test" routine would have to
reside in another compilation unit.

% cat bug.c
int __attribute__((noinline)) test(int a) {
if (a < 0)
return 1;
a++;
if (a < 0) // gcc -O2 thinks this can't happen, since a>=0 from above
return 2;
return a;
}

#include 
int main()
{
printf("%d\n", test(0x7FFF));
}

% gcc bug.c -o bug
% ./bug
2
% gcc -O2 bug.c -o bug
% ./bug
-2147483648
% gcc --version
gcc (SUSE Linux) 5.2.1 20151008 [gcc-5-branch revision 228597]
...

[Bug preprocessor/69543] [6 Regression] _Pragma does not apply within macro

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Feb  1 22:36:07 2016
New Revision: 233058

URL: https://gcc.gnu.org/viewcvs?rev=233058&root=gcc&view=rev
Log:
PR preprocessor/69543
PR c/69558
* c-pragma.c (handle_pragma_diagnostic): Pass input_location
instead of loc to control_warning_option.

* gcc.dg/pr69543.c: New test.
* gcc.dg/pr69558.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr69543.c
trunk/gcc/testsuite/gcc.dg/pr69558.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-pragma.c
trunk/gcc/testsuite/ChangeLog

[Bug target/69610] [5/6 Regression] ICE: SIGSEGV in arm_reload_in_hi (arm.c:15446) with -march=armv3

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Looks like a dup.
Feel free to add the testcase to PR 62254 as it is quite small

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

[Bug target/62254] [4.9/5/6 Regression] gcc-4.9 ICEs on linux kernel zlib for armv3

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz

--- Comment #6 from ktkachov at gcc dot gnu.org ---
*** Bug 69610 has been marked as a duplicate of this bug. ***

[Bug testsuite/65940] g++.dg/other/anon5.C requires dwarf4 support in ld

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #3 from Uroš Bizjak  ---
Fixed.

[Bug testsuite/65940] g++.dg/other/anon5.C requires dwarf4 support in ld

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
Author: uros
Date: Mon Feb  1 22:20:47 2016
New Revision: 233056

URL: https://gcc.gnu.org/viewcvs?rev=233056&root=gcc&view=rev
Log:
* g++.dg/other/anon5.C (dg-opetions): Use -gdwarf-2 instead of -g.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/other/anon5.C

[Bug target/69610] [5/6 Regression] ICE: SIGSEGV in arm_reload_in_hi (arm.c:15446) with -march=armv3

[zsojka at seznam dot cz]

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

--- Comment #1 from Zdenek Sojka  ---
Created attachment 37547
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37547&action=edit
another testcase, fails at -O2

$ armv7a-hardfloat-linux-gnueabi-gcc -O2 -march=armv3 -fno-forward-propagate
testcase.c
...
==19259== Invalid read of size 2
==19259==at 0xEBB91D: arm_reload_in_hi(rtx_def**) (arm.c:15446)
==19259==by 0x1042574: gen_reload_inhi(rtx_def*, rtx_def*, rtx_def*)
(arm.md:6422)
==19259==by 0x9CA5C2: operator() (recog.h:302)
==19259==by 0x9CA5C2: check_and_process_move (lra-constraints.c:1186)
==19259==by 0x9CA5C2: curr_insn_transform(bool) (lra-constraints.c:3453)
==19259==by 0x9CB446: lra_constraints(bool) (lra-constraints.c:4421)
==19259==by 0x9B729C: lra(_IO_FILE*) (lra.c:2277)
==19259==by 0x95EF39: do_reload (ira.c:5394)
==19259==by 0x95EF39: (anonymous
namespace)::pass_reload::execute(function*) (ira.c:5565)
==19259==by 0xA70D27: execute_one_pass(opt_pass*) (passes.c:2336)
==19259==by 0xA712D7: execute_pass_list_1(opt_pass*) (passes.c:2410)
==19259==by 0xA712E9: execute_pass_list_1(opt_pass*) (passes.c:2411)
==19259==by 0xA71334: execute_pass_list(function*, opt_pass*)
(passes.c:2421)
==19259==by 0x70D023: cgraph_node::expand() (cgraphunit.c:1975)
==19259==by 0x70E925: expand_all_functions (cgraphunit.c:2111)
==19259==by 0x70E925: symbol_table::compile() (cgraphunit.c:2467)
==19259==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==19259== 
testcase.c: In function 'foo':
testcase.c:28:1: internal compiler error: Segmentation fault
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug target/69577] [5/6 Regression] wrong code with -fno-forward-propagate -mavx and 128bit arithmetics since r215450

[ubizjak at gmail dot com]

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

--- Comment #6 from Uroš Bizjak  ---
IMO, we should revert r215450, and fix a couple of cases using narrowing
conversions with gen_lowpart that were introduced after r215450.

Something like:

--cut here--
Index: i386.c
===
--- i386.c  (revision 233041)
+++ i386.c  (working copy)
@@ -43276,7 +43276,7 @@
  be dropped leaving a plain DImode store.  This is indistinguishable
  from a "normal" DImode move, and so we're justified to use movsd,
  which modifies the entire 128-bit register.  */
-  if (to_size == UNITS_PER_WORD && from_size > UNITS_PER_WORD)
+  if (to_size < from_size)  
return true;
 }

Index: sse.md
===
--- sse.md  (revision 233041)
+++ sse.md  (working copy)
@@ -17291,12 +17291,12 @@
&& reload_completed && GENERAL_REG_P (operands[1])"
   [(const_int 0)]
 {
-  emit_insn (gen_vec_setv4si_0 (gen_lowpart (V4SImode, operands[0]),
+  emit_insn (gen_vec_setv4si_0 (gen_rtx_REG (V4SImode, REGNO (operands[0])),
CONST0_RTX (V4SImode),
gen_lowpart (SImode, operands[1])));
   emit_insn (gen_avx2_pbroadcast (operands[0],
-   gen_lowpart (mode,
-operands[0])));
+   gen_rtx_REG (mode,
+REGNO (operands[0];
   DONE;
 })

--cut here--

Please note that sse.md uses constructs like:

op1 = gen_rtx_REG (mode, REGNO (op1));

to generate narrowing conversions involving SSE regs before the mentioned
revision.

[Bug tree-optimization/69580] [6 Regression] From 26 seconds to 10 minutes moving from gcc 5.3.1 to gcc 6.0.0

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P1  |P4

--- Comment #7 from Jeffrey A. Law  ---
Major regression resolved.  There's still some work to do, as outlined in the
BZ and in the post for the patch, so keeping this open as  P4.

[Bug sanitizer/68580] FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test

[law at gcc dot gnu.org]

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

--- Comment #5 from Jeffrey A. Law  ---
Author: law
Date: Mon Feb  1 22:03:57 2016
New Revision: 233053

URL: https://gcc.gnu.org/viewcvs?rev=233053&root=gcc&view=rev
Log:
PR tree-optimization/68580
* params.def (FSM_MAXIMUM_PHI_ARGUMENTS): New param.
* tree-ssa-threadbackward.c
(fsm_find_control_statement_thread_paths): Do not try to walk
through large PHI nodes.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/params.def
trunk/gcc/tree-ssa-threadbackward.c

[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (6.0). The type of ICE seems to depend of the
use of --enable-checking=release during configure.

[Bug bootstrap/69611] New: Bootstrap broken on PowerPC FreeBSD, IEEE 128-bit floating point support.

[andreast at gcc dot gnu.org]

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

Bug ID: 69611
   Summary: Bootstrap broken on PowerPC FreeBSD, IEEE 128-bit
floating point support.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andreast at gcc dot gnu.org
  Target Milestone: ---

PowerPC FreeBSD does not support 128-bit floating point yet.

Bootstrap on this target is broken because of undefined references to
__sfp_handle_exceptions.

We build gcc with softfp for our 32-bit embedded targets.
Now the the sfp-machine.h is included even in the non 128-bit t-float128 case.
The definition of the __sfp_handle_exceptions is done in the mentioned header
file while the implementation is done in the sfp-exceptions.c which is only
built when 128-bit float is supported.

To fix this issue we propose to guard the affected region in sfp-machine.h with
this:

Index: config/rs6000/sfp-machine.h
===
--- config/rs6000/sfp-machine.h (revision 233015)
+++ config/rs6000/sfp-machine.h (working copy)
@@ -110,7 +110,7 @@
floating point on pre-ISA 3.0 machines without the IEEE 128-bit floating
point support.  */

-#ifndef __NO_FPRS__
+#if defined(__FLOAT128__)
 #define ISA_BIT(x) (1LL << (63 - x))

 /* Use the same bits of the FPSCR.  */
@@ -151,7 +151,7 @@
   } while (0)

 # define FP_ROUNDMODE  (_fpscr & FP_RND_MASK)
-#endif /* !__NO_FPRS__ */
+#endif /* __FLOAT128__ */

I discussed this with Michael Meissner on #irc. He agrees on this approach.
I'm running a bootstrap and will provide test results from FreeBSD PowerPC
asap.

I'd appreciate a testrun on a GNU/Linux target. I do not have such a setup yet.

TIA,
Andreas

[Bug target/69610] New: [5/6 Regression] ICE: SIGSEGV in arm_reload_in_hi (arm.c:15446) with -march=armv3 -ftree-ter (-O0)

[zsojka at seznam dot cz]

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

Bug ID: 69610
   Summary: [5/6 Regression] ICE: SIGSEGV in arm_reload_in_hi
(arm.c:15446) with -march=armv3 -ftree-ter (-O0)
   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: armv3-*-linux-gnueabi

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

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

$ armv7a-hardfloat-linux-gnueabi-gcc -march=armv3 -ftree-ter testcase.c
...
==11530== Invalid read of size 2
==11530==at 0xEBB91D: arm_reload_in_hi(rtx_def**) (arm.c:15446)
==11530==by 0x1042574: gen_reload_inhi(rtx_def*, rtx_def*, rtx_def*)
(arm.md:6422)
==11530==by 0x9CA5C2: operator() (recog.h:302)
==11530==by 0x9CA5C2: check_and_process_move (lra-constraints.c:1186)
==11530==by 0x9CA5C2: curr_insn_transform(bool) (lra-constraints.c:3453)
==11530==by 0x9CB446: lra_constraints(bool) (lra-constraints.c:4421)
==11530==by 0x9B729C: lra(_IO_FILE*) (lra.c:2277)
==11530==by 0x95EF39: do_reload (ira.c:5394)
==11530==by 0x95EF39: (anonymous
namespace)::pass_reload::execute(function*) (ira.c:5565)
==11530==by 0xA70D27: execute_one_pass(opt_pass*) (passes.c:2336)
==11530==by 0xA712D7: execute_pass_list_1(opt_pass*) (passes.c:2410)
==11530==by 0xA712E9: execute_pass_list_1(opt_pass*) (passes.c:2411)
==11530==by 0xA71334: execute_pass_list(function*, opt_pass*)
(passes.c:2421)
==11530==by 0x70D023: cgraph_node::expand() (cgraphunit.c:1975)
==11530==by 0x70DF67: output_in_order(bool) (cgraphunit.c:2213)
==11530==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==11530== 
testcase.c: In function 'foo':
testcase.c:9:1: internal compiler error: Segmentation fault
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

This happens only at -O0.

Tested revisions:
trunk r233030 - ICE
5-branch r233025 - ICE
4_9-branch r233024 - OK
4_[876]-branch - OK

[Bug c/69609] New: block reordering consumes an inordinate amount of time

[dcb314 at hotmail dot com]

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

Bug ID: 69609
   Summary: block reordering consumes an inordinate amount of time
   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 37545
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37545&action=edit
gzipped C source code

The attached code, when compiled by trunk gcc 6.0.0,
with flag -O2, seems to take about 17 minutes.

gcc 5.3.1 seems to take about 16 minutes for the same code.

In a private email, Jeffery Law says: 
>I do note that test is spending most of its time (90%) in block
>reordering, so you might want to go ahead and file it

[Bug libstdc++/69608] New: strsteambuf copy ctor and assignment inaccessible

[msebor at gcc dot gnu.org]

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

Bug ID: 69608
   Summary: strsteambuf copy ctor and assignment inaccessible
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

As far as I can see, the C++ standard doesn't prevent the copying of
strstreambuf objects.  With the resolution of issue 421 these copies should
have (almost) well-defined semantics.  But the following program fails to
compile with the latest libstdc++.

That said, I'm not sure it's a good idea for the standard to require
implementations to accept the program.  If it did, it seems that the two copies
would share the same underlying character buffer (courtesy of issue 421). 
Accessing the buffer in the copy would be undefined after the copied
strstreambuf object was destroyed.  If this hasn't been discussed in LWG yet it
might be worth bringing it up.  strstreambuf may be deprecated but the same
concern applies to similar user-defined classes that publicly derive from
basic_streambuf and expose an accsible copy ctor or assignment operator of
their own.

$ cat t.cpp && /home/msebor/build/gcc-trunk-bootstrap/gcc/xg++
-B/home/msebor/build/gcc-trunk-bootstrap/gcc -S ... t.cpp
#include 

int main ()
{
std::strstreambuf a;
a = std::strstreambuf (32);
}

In file included from
/src/gcc/trunk/libstdc++-v3/include/backward/strstream:50:0,
 from t.cpp:1:
/src/gcc/trunk/libstdc++-v3/include/backward/backward_warning.h:32:2: warning:
#warning This file includes at least one deprecated or antiquated header which
may be removed without further notice at a future date. Please use a
non-deprecated interface with equivalent functionality instead. For a listing
of replacement headers and interfaces, consult the file backward_warning.h. To
disable this warning use -Wno-deprecated. [-Wcpp]
t.cpp: In function ‘int main()’:
t.cpp:6:30: error: ‘std::strstreambuf& std::strstreambuf::operator=(const
std::strstreambuf&)’ is private within this context
In file included from t.cpp:1:0:
/src/gcc/trunk/libstdc++-v3/include/backward/strstream:102:5: note: declared
private here

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

[kelvin at gcc dot gnu.org]

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

kelvin at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kelvin at gcc dot gnu.org

--- Comment #4 from kelvin at gcc dot gnu.org ---
The spec for __sync_bool_compare_and_swap can be found at 

  https://gcc.gnu.org/onlinedocs/gcc-4.4.5/gcc/Atomic-Builtins.html

This states that the first argument may be a pointer to "any integral scalar or
pointer type that is 1, 2, 4 or 8 bytes in length", but acknowledges that
"Intel documentation allows only for the use of the types int, long, long long
as well as their unsigned counterparts."

In discussing implementation options, the "spec" says: "Not all operations are
supported by all target processors. If a particular operation cannot be
implemented on the target processor, a warning will be generated and a call an
external function will be generated. The external function will carry the same
name as the builtin, with an additional suffix `_n' where n is the size of the
data type."

On Power, we would need a different implementation depending on whether the
address of the modified data value is properly aligned.  To use, for example,
the lharx and starx instructions, we would need an assurance that the address
is a multiple of two.  In this case, the compiler can see that it is.

However, there are also situations in which the compiler can see that the
argument is not a multiple of 2, such as the following code, in which case we
would presumably need to generate a call to a helper function rather than emit
in-line code:

  class A {
bool m_fn1();
bool b;
short m_role;
  } __attribute ((packed));
  char a;
  bool A::m_fn1() { __sync_bool_compare_and_swap(&m_role, -1, a);

And there are situations in which the compiler cannot know for sure whether the
address associated with the first argument is properly aligned, such as:

  char a;
  bool __generic_atomizer(short *sp) {
return __sync_bool_compare_and_swap(sp, -1, a);
  }

In general, the compiler will not "know" that a particular shared data value is
always accessed in the same way by all threads.  That is, some threads may
access the value from contexts that are known to the compiler to be aligned and
other threads may access the same value from contexts that cannot determine the
value to be properly aligned.  So there would need to be some sort of
implementation compatibility between the in-lined implementation and the
function-call implementation.

Maybe this is all obvious to implementers and the details need not be
belabored.  I "feel" the necessity to add this comment because the lack of any
discussion about these issues in the "API specification" leaves me with
concerns that application programmers may not know how to use this API
correctly.

What should happen, for example, with the following source?

  class A {
bool i_fn1();
bool b;
double d;
long int i;
   } __attribute__((packed));
   long int larry;
   bool A::i_fn1() { __sync_bool_compare_and_swap(&i, -1, larry); }

I would be inclined to prohibit this usage, but there is nothing in the API
description that allows me to do so.

[Bug c/69602] [6 Regression] over-ambitious logical-op warning on EAGAIN vs EWOULDBLOCK

[manu at gcc dot gnu.org]

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

--- Comment #4 from Manuel López-Ibáñez  ---
Since EAGAIN and EWOULDBLOCK probably expand from a macro to a constant (or are
they enums? do we track the original form of the enum or only the underlying
value?), this is as hard as:

extern int xxx;
#define XXX xxx
int test (void)
{
  if (!XXX && xxx)
return 4;
  else
return 0;
}

thus, if this is not a regression caused by something else, it is a duplicate.

[Bug c/69602] [6 Regression] over-ambitious logical-op warning on EAGAIN vs EWOULDBLOCK

[manu at gcc dot gnu.org]

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

--- Comment #3 from Manuel López-Ibáñez  ---
I wonder when/why it started warning, since -Wlogical-op is not new in GCC 6.

This is just a more complex case of PR61534.

[Bug c/69602] [6 Regression] over-ambitious logical-op warning on EAGAIN vs EWOULDBLOCK

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
(In reply to Marek Polacek from comment #1)
> Confirmed, though there are other PRs similar in nature.  Fixing this isn't
> trivial at all.  E.g. -Wduplicated-cond has the same problem -- that's the
> reason these warnings aren't enabled by -Wall/-Wextra. :(

It isn't trivial, but it may be possible now by seeing that the operators come
from the expansion of different macros, no?

[Bug libgomp/69607] undefined reference to MAIN__._omp_fn.0 in atomic_capture-1.f with -flto

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||openacc
 CC||tschwinge at gcc dot gnu.org

--- Comment #1 from vries at gcc dot gnu.org ---
Looks similar to PR63979.

[Bug libgomp/69607] New: undefined reference to MAIN__._omp_fn.0 in atomic_capture-1.f with -flto

[vries at gcc dot gnu.org]

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

Bug ID: 69607
   Summary: undefined reference to MAIN__._omp_fn.0 in
atomic_capture-1.f with -flto
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

With compiler configured for nvptx offloading, and libgomp run with -flto, we
run into:
...
FAIL: libgomp.oacc-fortran/atomic_capture-1.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0 -foffload=nvptx-none  -O0  (test for excess errors)
FAIL: libgomp.oacc-fortran/atomic_capture-1.f90 -DACC_DEVICE_TYPE_host=1
-DACC_MEM_SHARED=1 -foffload=disable  -O0  (test for excess errors)
...

In more detail:
...
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0xf8): undefined reference
to `MAIN__._omp_fn.21'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x100): undefined reference
to `MAIN__._omp_fn.20'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x108): undefined reference
to `MAIN__._omp_fn.19'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x110): undefined reference
to `MAIN__._omp_fn.18'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x118): undefined reference
to `MAIN__._omp_fn.17'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x120): undefined reference
to `MAIN__._omp_fn.16'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x128): undefined reference
to `MAIN__._omp_fn.15'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x130): undefined reference
to `MAIN__._omp_fn.14'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x138): undefined reference
to `MAIN__._omp_fn.13'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x140): undefined reference
to `MAIN__._omp_fn.12'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x148): undefined reference
to `MAIN__._omp_fn.11'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x150): undefined reference
to `MAIN__._omp_fn.10'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x158): undefined reference
to `MAIN__._omp_fn.9'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x160): undefined reference
to `MAIN__._omp_fn.8'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x168): undefined reference
to `MAIN__._omp_fn.7'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x170): undefined reference
to `MAIN__._omp_fn.6'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x178): undefined reference
to `MAIN__._omp_fn.5'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x180): undefined reference
to `MAIN__._omp_fn.4'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x188): undefined reference
to `MAIN__._omp_fn.3'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x190): undefined reference
to `MAIN__._omp_fn.2'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x198): undefined reference
to `MAIN__._omp_fn.1'^M
/tmp/ccE4Tp7i.ltrans0.ltrans.o:(.gnu.offload_funcs+0x1a0): undefined reference
to `MAIN__._omp_fn.0'^M
collect2: error: ld returned 1 exit status^M
...

[Bug c/69605] printf %f on integers

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
https://gcc.gnu.org/wiki/FAQ#undefinedbut

[Bug rtl-optimization/69606] New: wrong code at -Os and above on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 69606
   Summary: wrong code at -Os and above 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 -Os
and above in both 32-bit and 64-bit modes.

This also affects 5.1.x and later, and is a regression from 4.9.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 20160201 (experimental) [trunk revision 233027] (GCC) 
$ 
$ gcc-trunk -O1 small.c; ./a.out
$ gcc-4.9 -Os small.c; ./a.out
$ 
$ gcc-trunk -Os small.c
$ ./a.out
Floating point exception (core dumped)
$ gcc-5.3 -Os small.c
$ ./a.out
Floating point exception (core dumped)
$ gcc-5.2 -Os small.c
$ ./a.out
Floating point exception (core dumped)
$ gcc-5.1 -Os small.c
$ ./a.out
Floating point exception (core dumped)
$ 


-


char a;
unsigned short b;
int c, d;
unsigned char e;

int
main ()
{
  int f = 1, g = ~a;
  if (b > f)
{
  e = b; 
  d = b | e; 
  g = 0;
}
  c = 1 % g;
  return 0; 
}

[Bug c++/68489] arrays of flexible array members are silently accepted

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-01
 Ever confirmed|0   |1
  Known to fail||6.0

--- Comment #1 from Martin Sebor  ---
Bug 28865 provides useful background on this problem.  GCC (in C mode) used to
accept definitions of initialized array objects of structures with flexible
array members.  That feature was removed in response to bug 28865 which pointed
out that the size of such objects (emitted into the assembly in the form of the
.size directive) is incorrect.  G++ 6.0 suffers from both of these problems
because it accepts definitions of such objects.  Prior versions rejected such
code.

The following test case demonstrates the consequences of this problem:

$ cat t.c && /home/msebor/build/gcc-trunk-git/gcc/xgcc
-B/home/msebor/build/gcc-trunk-git/gcc -Wall -Wextra -Wpedantic -std=c++11
-xc++ t.c && ./a.out 
struct S { char x; int y []; };

struct S s[2] = {
{ 1, { 2, 3 } },
{ 4, { 5, 6 } }
};

int main (void) {
__builtin_printf ("sizeof s = %zu\n"
  "s[0] @%p = { %hhi, { %i, %i } }\n"
  "s[1] @%p = { %hhi, { %i, %i } }\n",
  sizeof (struct S),
  &s [0], s[0].x, s[0].y [0], s[0].y [1],
  &s [1], s[1].x, s[1].y [0], s[1].y [1]);

if (   s [0].x != 1 || s [0].y [0] != 2 || s [0].y [1] != 3
|| s [1].x != 4 || s [1].y [0] != 5 || s [1].y [1] != 6)
__builtin_abort ();
}

t.c:6:1: warning: initialization of a flexible array member [-Wpedantic]
 };
 ^
t.c:6:1: warning: initialization of a flexible array member [-Wpedantic]
t.c: In function ‘int main()’:
t.c:14:61: warning: format ‘%p’ expects argument of type ‘void*’, but argument
3 has type ‘S*’ [-Wformat=]
   &s [1], s[1].x, s[1].y [0], s[1].y [1]);
 ^
t.c:14:61: warning: format ‘%p’ expects argument of type ‘void*’, but argument
7 has type ‘S*’ [-Wformat=]
sizeof s = 4
s[0] @0x601048 = { 1, { 2, 3 } }
s[1] @0x60104c = { 2, { 3, 4 } }
Aborted (core dumped)

[Bug tree-optimization/69580] [6 Regression] From 26 seconds to 10 minutes moving from gcc 5.3.1 to gcc 6.0.0

[law at redhat dot com]

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

--- Comment #6 from Jeffrey A. Law  ---
If you could pass it along to me privately, I can verify if it's the same issue
or not easily (that's the nice things about a PARAM, I can just crank up the
limiter and see what happens).  I also happen to have gcc-4.9 and gcc-5
compilers handy to compare against.

l...@redhat.com

Thanks for taking the time to dig this stuff out and report the issues.  We're
using the FSM bits a lot more now and plan to rely on them more in the future. 
So shaking out these cases is important.

[Bug c/69605] printf %f on integers

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

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
It has undefined behviour.

[Bug tree-optimization/69580] [6 Regression] From 26 seconds to 10 minutes moving from gcc 5.3.1 to gcc 6.0.0

[dcb314 at hotmail dot com]

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

--- Comment #5 from David Binderman  ---
(In reply to Jeffrey A. Law from comment #4)
> With the limiter, the time should come back down into the reasonable range
> and I'm going drop this to a P4 once that change goes in.  However, I'm
> going to keep this open because I think fsm_find_thread_path is horrible in
> the amount of work it duplicates and needs to be rewritten.  

I have another test case that currently seems to take about 17 minutes
with -O2.

Hopefully, this second test case is just a duplicate, but I'll wait until
your change has gone in to test it.

Good work and I look forward to seeing your change.

[Bug tree-optimization/69580] [6 Regression] From 26 seconds to 10 minutes moving from gcc 5.3.1 to gcc 6.0.0

[law at redhat dot com]

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

--- Comment #4 from Jeffrey A. Law  ---
So for the testcase we've got merge points with huge numbers of predecessors,
which as I mentioned before we dutifully try finding paths through each one.

I instrumented the compiler a bit to see what kind of distribution we see in
this code.  I was interested primarily interested in the number of PHI
arguments, but also the number of threaded paths was recorded.

Not surprisingly, the distribution is heavily skewed towards small numbers of
PHI arguments (ie, 2-5).  The largest PHI in GCC an its shared libraries was on
the order of 256 entries, but it was pretty clear handling cases up to 100
would catch the overwhelming majority of cases.  That also sets the bar at one
order of magnitude lower than what the attached testcase needs to not explode.

In terms of # paths threaded in those big nodes, it tends to be either a bunch
(roughly half) or none.  I didn't investigate the bi-modal nature, though I do
know in the provided testcase the thread paths require memory simplifications
to be able to see the jump thread path.  That means they'll need to be picked
up by the old threader when called from DOM,   DOM threads ~2600 paths, so it
seems to be doing its job.

In general, the number of threaded paths wasn't all that interesting as a
datapoint.

With the limiter, the time should come back down into the reasonable range and
I'm going drop this to a P4 once that change goes in.  However, I'm going to
keep this open because I think fsm_find_thread_path is horrible in the amount
of work it duplicates and needs to be rewritten.  It likely accounts for the
remainder of the compile-time performance issues with this test when compared
to gcc-4.9.

[Bug c/69605] New: printf %f on integers

[elmerido at yopmail dot com]

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

Bug ID: 69605
   Summary: printf %f on integers
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: elmerido at yopmail dot com
  Target Milestone: ---

#include
int main() {
printf("a= %f \n",3.14);
printf("b= %f \n",200);
return 0;
}

returns :
a= 3.14 
b= 3.14 

Compilation gives warning but still generates the binary :
i.c: In function ‘main’:
i.c:6:2: warning: format ‘%f’ expects argument of type ‘double’, but argument 2
has type ‘int’ [-Wformat=]
  printf("b= %f \n",200);
  ^

[Bug target/68741] FAIL: tr1/8_c_compatibility/cstdio/functions.cc (test for excess errors)

[danglin at gcc dot gnu.org]

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

--- Comment #5 from John David Anglin  ---
Author: danglin
Date: Mon Feb  1 20:27:47 2016
New Revision: 233049

URL: https://gcc.gnu.org/viewcvs?rev=233049&root=gcc&view=rev
Log:
PR target/68741
* inclhack.def (hpux_vsscanf): New fix.
* fixincl.x: Regenerated.
* tests/base/stdio.h [HPUX_VSSCANF_CHECK]: New test.


Modified:
branches/gcc-4_9-branch/fixincludes/ChangeLog
branches/gcc-4_9-branch/fixincludes/fixincl.x
branches/gcc-4_9-branch/fixincludes/inclhack.def
branches/gcc-4_9-branch/fixincludes/tests/base/stdio.h

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

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #20 from H.J. Lu  ---
Fixed for GCC 5.4.

[Bug target/68741] FAIL: tr1/8_c_compatibility/cstdio/functions.cc (test for excess errors)

[danglin at gcc dot gnu.org]

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

--- Comment #4 from John David Anglin  ---
Author: danglin
Date: Mon Feb  1 20:22:43 2016
New Revision: 233047

URL: https://gcc.gnu.org/viewcvs?rev=233047&root=gcc&view=rev
Log:
PR target/68741
* inclhack.def (hpux_vsscanf): New fix.
* fixincl.x: Regenerated.
* tests/base/stdio.h [HPUX_VSSCANF_CHECK]: New test.


Modified:
branches/gcc-5-branch/fixincludes/ChangeLog
branches/gcc-5-branch/fixincludes/inclhack.def
branches/gcc-5-branch/fixincludes/tests/base/stdio.h

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

[hjl at gcc dot gnu.org]

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

--- Comment #19 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Mon Feb  1 20:20:56 2016
New Revision: 233046

URL: https://gcc.gnu.org/viewcvs?rev=233046&root=gcc&view=rev
Log:
Update preferred stack boundary in ix86_update_stack_boundary

__tls_get_addr must be called with 16-byte aligned stack, which is
guaranted by setting preferred_stack_boundary to 128 bits.  Preferred
stack boundary adjustment for __tls_get_addr should be done in
ix86_update_stack_boundary, not ix86_compute_frame_layout Also
there is no need to over-align stack for __tls_get_addr and function
with __tls_get_addr call isn't a leaf function.

gcc/

Backport from mainline
PR target/68986
* config/i386/i386.c (ix86_compute_frame_layout): Move stack
alignment adjustment to ...
(ix86_update_stack_boundary): Here.  Don't over-align stack nor
change stack_alignment_needed for __tls_get_addr.
(ix86_finalize_stack_realign_flags): Use stack_alignment_needed
if __tls_get_addr is called.

gcc/testsuite/

Backport from mainline
PR target/68986
* gcc.target/i386/pr68986-1.c: New test.
* gcc.target/i386/pr68986-2.c: Likewise.
* gcc.target/i386/pr68986-3.c: Likewise.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr68986-1.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr68986-2.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr68986-3.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/i386.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/69603] [5/6 Regression] ICE: segfault with -fimplicit-none and proc_ptr_comp_24.f90

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-01
 CC||janus at gcc dot gnu.org
Summary|ICE: segfault with  |[5/6 Regression] ICE:
   |-fimplicit-none and |segfault with
   |proc_ptr_comp_24.f90|-fimplicit-none and
   ||proc_ptr_comp_24.f90
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
The ICE occurred between revisions r219318 (2015-01-07, compiles) and r219477
(2015-01-12, ICE), possibly r219439. Reduced test

PROGRAM prog
  implicit none
 TYPE object
  PROCEDURE(), POINTER, NOPASS :: f
 END TYPE object
 TYPE container
  TYPE (object), POINTER :: o(:)
 END TYPE container
 TYPE (container) :: c
 TYPE (object) :: o1, o2
 PROCEDURE(), POINTER :: f => NULL()
 o1%f => f
 CALL set_func(o2,o1%f)
CONTAINS
 SUBROUTINE set_func(o,f)
  TYPE (object) :: o
  PROCEDURE(), POINTER :: f
 END SUBROUTINE set_func
END PROGRAM prog

[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---

While playing around, one example from ./gcc/testsuite/gfortran.dg/
shows the same error with v6.0.0, but not with v5.3.1 :


$ gfortran-6 -c complex_intrinsic_6.f90
internal compiler error: in gfc_add_modify_loc, at fortran/trans.c:159


$ gfortran-5 -c complex_intrinsic_6.f90
# no ICE


---

Please correct : last line was cut away for example z4.f90 -- add "end"

[Bug fortran/69604] New: ICE in gfc_add_modify_loc, at fortran/trans.c:159

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 69604
   Summary: ICE in gfc_add_modify_loc, at fortran/trans.c:159
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

The following examples together with :

$ gfortran-6 --version
GNU Fortran (SUSE Linux) 6.0.0 20160121 (experimental) [trunk revision 232670]


$ cat z1.f90
program p
   x(n) = n()
   print *, x(n)
end


$ cat z2.f90
program p
   x(n) = n(1.0)
   print *, x(n)
end


$ cat z4.f90
program p
   complex :: z[*]
   real :: x[*]
   z = x / cmplx(0.0, x)


yield :

$ gfortran-6 -c z1.f90
internal compiler error: in gfc_add_modify_loc, at fortran/trans.c:159


$ gfortran-6 -fcoarray=single -c z4.f90
internal compiler error: in gfc_add_modify_loc, at fortran/trans.c:159


A previous version gives :

$ gfortran-5.3.1  -c z1.f90
internal compiler error: in conv_function_val, at fortran/trans-expr.c:3489

[Bug fortran/69603] New: ICE: segfault with -fimplicit-none and proc_ptr_comp_24.f90

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 69603
   Summary: ICE: segfault with -fimplicit-none and
proc_ptr_comp_24.f90
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

While playing around, one example from ./gcc/testsuite/gfortran.dg/
together with option -fimplicit-none segfaults :


$ gfortran-6 -fimplicit-none -c proc_ptr_comp_24.f90
f951: internal compiler error: Segmentation fault


$ gfortran-5.3.1 -fimplicit-none -c proc_ptr_comp_24.f90
f951: internal compiler error: Segmentation fault


Whereas, no error/ICE with :

$ gfortran-6 -c proc_ptr_comp_24.f90
$ gfortran-5.3.1 -c proc_ptr_comp_24.f90


Example originates to pr42045.

[Bug rtl-optimization/69570] [6 Regression] if-conversion bug on i?86

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

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

--- Comment #7 from Bernd Schmidt  ---
Taking it and also hoping it's not in reg-stack.

[Bug fortran/40737] Pointer references sometimes fail to define "span" symbols

[gerhard.steinmetz.fort...@t-online.de]

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

Gerhard Steinmetz  changed:

   What|Removed |Added

 CC||gerhard.steinmetz.fortran@t
   ||-online.de

--- Comment #18 from Gerhard Steinmetz  
---
FYI, compiling example from comment 17 together with -flto :


$ gfortran-6 -flto -c pr40737_c17.f90
pr40737_last.f90:23:0: internal compiler error: in get_partitioning_class, at
symtab.c:1794


$ gfortran-5.3.1 -flto -c pr40737_c17.f90
pr40737_last.f90:23:0: internal compiler error: in write_symbol, at
lto-streamer-out.c:2547

[Bug rtl-optimization/69570] [6 Regression] if-conversion bug on i?86

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
If you could, I'd appreciate it, if not, I'll find time for it this week.  But
if the bug is in reg-stack, I'll be lost anyway.

[Bug fortran/66544] [F03] ICE on function with procedure-pointer result in combination with implicit none

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #6 from Gerhard Steinmetz  
---
When running several private scripts, there was a difference between
some scripts including option -fimplicit-none, and some others that didn't.

Reducing and simplifying gave example z0.f90 from comment 1. Explicitly
including "implicit none" into source then gives first example in comment 0.


> Btw, I don't fully understand why "implicit none" should make any
> difference here.

Me too.


> There is also the very closely related PR54107, which is fixed already.

Now interestingly, compiling examples from ./gcc/testsuite/gfortran.dg/
with an additional -fimplicit-none shows the same error message as above
for these sources :

   automatic_char_len_1.f90
   data_value_1.f90
   init_flag_9.f90
   recursive_interface_1.f90
   recursive_interface_2.f90


$ gfortran-6 --version
GNU Fortran (SUSE Linux) 6.0.0 20160121 (experimental) [trunk revision 232670]

$ gfortran-6 -c recursive_interface_1.f90
# ok

$ gfortran-6 -fimplicit-none -c recursive_interface_1.f90
recursive_interface_1.f90:16:0:

   function baz() result(r3)


internal compiler error: in gfc_typenode_for_spec, at
fortran/trans-types.c:1064

[Bug rtl-optimization/69570] [6 Regression] if-conversion bug on i?86

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #5 from Bernd Schmidt  ---
Jakub, do you want to look at it or should I assign myself?

[Bug rtl-optimization/69570] [6 Regression] if-conversion bug on i?86

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Since the above commit, this bug is just latent, but we should fix it anyway.

[Bug rtl-optimization/69592] [6 Regression] Compile-time and memory-use hog in combine

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 37544
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37544&action=edit
gcc6-pr69592.patch

Untested fix.  Not all ARITHMETIC_P rtxes are handled in nonzero_bits1 or
num_sign_bit_copies1 (and even from those that are only some of them recurse to
both operands).  The cached_* stuff is to catch the cases where we recurse into
both operands; if we don't, then it might be more or significantly more work to
do it instead of less work.
On the included artificial testcase (didn't want to include crypto stuff into a
testcase) on x86_64 we need about 5.5GB of RAM without the patch and almost
nothing with the patch.

[Bug c/69602] New: over-ambitious logical-op warning on EAGAIN vs EWOULDBLOCK

[eblake at redhat dot com]

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

Bug ID: 69602
   Summary: over-ambitious logical-op warning on EAGAIN vs
EWOULDBLOCK
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eblake at redhat dot com
  Target Milestone: ---

POSIX says that EAGAIN and EWOULDBLOCK may be identical, but also that they may
be distinct.  Therefore, well-written portable code MUST check for both values
in some circumstances.

However, as shown by the sample code below, gcc 6.0's new warning is
over-ambitious, and is likely to _cause_ rather than cure user bugs, when
uninformed users unaware that Linux has the two errno values equal dumb down
the code to silence the warning, but in the process break their code on other
platforms where it is important to check for both values.

$ cat foo.c
#include 
int main(void) {
  if (errno == EAGAIN || errno == EWOULDBLOCK)
return 1;
  return 0;
}
$ gcc -o foo foo.c -Werror=logical-op
foo.c: In function 'main':
foo.c:3:23: error: logical 'or' of equal expressions [-Werror=logical-op]
   if (errno == EAGAIN || errno == EWOULDBLOCK)
   ^~
cc1: some warnings being treated as errors
$ gcc --version | head -n1
gcc (GCC) 6.0.0 20160129 (Red Hat 6.0.0-0.7)

[Bug c/69602] [6 Regresion] over-ambitious logical-op warning on EAGAIN vs EWOULDBLOCK

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Confirmed, though there are other PRs similar in nature.  Fixing this isn't
trivial at all.  E.g. -Wduplicated-cond has the same problem -- that's the
reason these warnings aren't enabled by -Wall/-Wextra. :(

[Bug fortran/67564] Segfault on sourced allocattion statement with class(*) arrays

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
> For whatever reason that I cannot uncover, the part of the original patch
> in trans-array.c is no longer necessary. The remainder (attached) is down
> to being 'obvious' and so I will commit it as soon as the regtesting is done.

I did not find any either. Note that the second piece for trans-expr.c comes
from

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278#c2 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410#c7.

[Bug c/69602] [6 Regresion] over-ambitious logical-op warning on EAGAIN vs EWOULDBLOCK

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
   Target Milestone|--- |6.0
Summary|over-ambitious logical-op   |[6 Regresion]
   |warning on EAGAIN vs|over-ambitious logical-op
   |EWOULDBLOCK |warning on EAGAIN vs
   ||EWOULDBLOCK

[Bug c++/69600] Incorrect use of copy-assignment instead of move assignment from function

[sshannin at gmail dot com]

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

--- Comment #3 from sshannin at gmail dot com ---
(In reply to Jonathan Wakely from comment #2)
> The value_type of your map is pair an you
> can't move the first part of that pair, and you can't copy the second part
> of that pair, so you can't move or copy it.

I'm not sure exactly what you mean/what the value_type typedef inside the map
has to do with this.

Note that std::map> does seem to work here (where
presumably value_type is pair>).

Also, I just confirmed this did previously work on gcc-4.8.2

[Bug other/69554] [6 Regression] Multi-location diagnostics writes too many lines

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

  Component|fortran |other

--- Comment #13 from David Malcolm  ---
I see this as a bug with the diagnostics subsystem, rather than Fortran per se;
setting component to "other"; I hope to have a look at this on Wednesday.

[Bug target/67714] [6 Regression] signed char is zero-extended instead of sign-extended

[ktkachov at gcc dot gnu.org]

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

--- Comment #10 from ktkachov at gcc dot gnu.org ---
Hi Nick,

For this failure (among others) I proposed the series at:
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01713.html

that changes the PROMOTE_MODE implementation on arm to be consistent with the
TARGET_PROMOTE_FUNCTION_MODE implementation i.e. to not do unsigned promotion
of short types

[Bug target/67714] [6 Regression] signed char is zero-extended instead of sign-extended

[nickc at gcc dot gnu.org]

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

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at gcc dot gnu.org

--- Comment #9 from Nick Clifton  ---
Created attachment 37543
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37543&action=edit
Use SUBREG_PROMOTED_SIGNED_P in place of SUBREG_PROMOTES_SIGN

Hi Guys,

  I am currently testing this patch locally.  It appears to fix the bug, and I
hope that it will not introduce any regressions.  We shall see.  (I am testing
arm-eabi and x86_64-linux-gnu).

  The problem, it appears to me is that the code in store_expr_with_bounds() is
using the SUBREG_PROMPTED_SIGN macro, which returns a tri-state value, as a
parameter to signed_or_unsigned_type_for().  This function, I think, but I am
not 100% sure, uses the parameter as a boolean, so really it should just be
told if the promotion is signed or unsigned, nothing else.

Cheers
  Nick

[Bug c++/69600] Incorrect use of copy-assignment instead of move assignment from function

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
The value_type of your map is pair an you
can't move the first part of that pair, and you can't copy the second part of
that pair, so you can't move or copy it.

[Bug tree-optimization/67921] [6 Regression] "internal compiler error: in build_polynomial_chrec, at tree-chrec.h:147" when using -fsanitize=undefined

[amker at gcc dot gnu.org]

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

--- Comment #10 from amker at gcc dot gnu.org ---
Author: amker
Date: Mon Feb  1 17:17:47 2016
New Revision: 233042

URL: https://gcc.gnu.org/viewcvs?rev=233042&root=gcc&view=rev
Log:

PR tree-optimization/67921
* fold-const.c (split_tree): New parameters.  Convert pointer
type variable part to proper type before negating. 
(fold_binary_loc): Pass new arguments to split_tree.

gcc/testsuite/ChangeLog
PR tree-optimization/67921
* c-c++-common/ubsan/pr67921.c: New test.


Added:
trunk/gcc/testsuite/c-c++-common/ubsan/pr67921.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug libgomp/69597] execution failure for libgomp.oacc-c-c++-common/atomic_capture-1.c with -flto

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org ---
Using -flto-partition=max, I get:
- 74 execution failures in libgomp.oacc-c
- 180 execution failures in libgomp.oacc-fortran

[Bug web/69601] New: current/ redirect is off by at least a day

[Joost.VandeVondele at mat dot ethz.ch]

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

Bug ID: 69601
   Summary: current/ redirect is off by at least a day
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch
  Target Milestone: ---

The current/ redirect as in e.g. :

https://gcc.gnu.org/ml/gcc-patches/current/

doesn't seem to redirect to https://gcc.gnu.org/ml/gcc-patches/2016-02/ at the
right point. I.e. it keeps pointing to 2016-01 even though the archives start
appearing at 2016-02, somehow the switching point is different by a day or
more.

[Bug c++/69600] Incorrect use of copy-assignment instead of move assignment from function

[sshannin at gmail dot com]

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

--- Comment #1 from sshannin at gmail dot com ---
Created attachment 37542
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37542&action=edit
Error output

Error output from compiler.

Note it also fails to indicate which line the problematic instantiation is on.

[Bug c++/69600] New: Incorrect use of copy-assignment instead of move assignment from function

[sshannin at gmail dot com]

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

Bug ID: 69600
   Summary: Incorrect use of copy-assignment instead of move
assignment from function
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sshannin at gmail dot com
  Target Milestone: ---

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

In some cases, it looks like the copy assignment operator is being used to
store return values from a function instead of the move assignment operator.

This causes the compilation to fail because it tries to use the copy-assignment
operator of some classes which may be movable only (unique_ptr).

Note that changing data_t to be either 'std::map' or
'std::map' allows the code to compile.

Let me know if I can provide any more details that would be helpful.

gcc-5.3.0
x86_64-unknown-linux-gnu

[Bug ada/69599] libgomp.c fipa-pta tests compiled with -flto -flto-partition=max fail in execution

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
Summary|libgomp.c/omp-nested-2.c|libgomp.c fipa-pta tests
   |execution test failure with |compiled with -flto
   |-flto -flto-partition=max   |-flto-partition=max fail in
   ||execution

--- Comment #1 from vries at gcc dot gnu.org ---
Hmm, the omp-nested-2.c test uses -fipa-pta. The other test using ipa-pta also
fails:
...
FAIL: libgomp.c/omp-nested-2.c execution test
FAIL: libgomp.c/pr46032.c execution test
...

[Bug other/67552] [meta] x86 interrupt attribute

[hjl.tools at gmail dot com]

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

Bug 69596 Summary: vzeroupper is generated in interrupt handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69596

   What|Removed |Added

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

[Bug target/69596] vzeroupper is generated in interrupt handler

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Blocks||67552
 Resolution|--- |FIXED

--- Comment #1 from H.J. Lu  ---
Fixed on hjl/interrupt/stage1 and hjl/interrupt/gcc-5-branch.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67552
[Bug 67552] [meta] x86 interrupt attribute

[Bug ada/69599] New: libgomp.c/omp-nested-2.c execution test failure with -flto -flto-partition=max

[vries at gcc dot gnu.org]

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

Bug ID: 69599
   Summary: libgomp.c/omp-nested-2.c execution test failure with
-flto -flto-partition=max
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

...
close result is child killed: segmentation violation
FAIL: libgomp.c/omp-nested-2.c execution test
...

[Bug tree-optimization/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[wdijkstr at arm dot com]

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

--- Comment #9 from Wilco  ---
The loops get optimized away in dom2. The info this phase emits is hard to
figure out, so it's not obvious why it thinks the array assignments are
redundant (the array is used all over the place so clearly cannot be removed).

[Bug c++/69098] [6 regression] Member function pointer template flagged with 'is not a function template'

[ppalka at gcc dot gnu.org]

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

--- Comment #6 from Patrick Palka  ---
This fixes it:

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index ef79b59..264c8aa 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -13735,7 +13735,19 @@ tsubst_qualified_id (tree qualified_id, tree args,
 }

   if (is_template)
-expr = lookup_template_function (expr, template_args);
+{
+  if (variable_template_p (expr))
+   {
+ expr = lookup_template_variable (expr, template_args);
+ if (!any_dependent_template_arguments_p (template_args))
+   {
+ expr = finish_template_variable (expr, complain);
+ mark_used (expr);
+   }
+   }
+  else
+   expr = lookup_template_function (expr, template_args);
+}

   if (expr == error_mark_node && complain & tf_error)
 qualified_name_lookup_error (scope, TREE_OPERAND (qualified_id, 1),

[Bug target/69577] [5/6 Regression] wrong code with -fno-forward-propagate -mavx and 128bit arithmetics since r215450

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak  ---
(In reply to Vladimir Makarov from comment #4)

> I believe machine-dependent code is more responsible for it.  I remember
> some discussion of it.  LRA follows RTL semantics where insn
> 
> (set (subreg reg 0) ...)
> 
> sets only part of subreg but x86-64 insn implementing it changes all reg.

Please see PR 67609 for the discussion.

[Bug fortran/57365] [OOP] Sourced allocation fails with unlimited polymorphism

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #4 from Dominique d'Humieres  ---
> Fails with 4.9, works with 5 and trunk(6).

Confirmed. The change on trunk (6.0) occurred between revisions r221464
(2015-03-16, fails) and r221495+3 patches (2015-03-18, succeeds).

IMO this PR can be closed as FIXED after adding a new test to the 5 and 6
branches.

[Bug tree-optimization/69355] [5 Regression] Wrong results with -O1 optimization

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[wdijkstr at arm dot com]

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

--- Comment #8 from Wilco  ---
In a few functions GCC decides that the assignments in loops are redundant. The
loops still execute but have their loads and stores removed. Eg. the first DO
loop in MP2NRG should be:

.L1027: 
  add w7, w7, 1
  add w8, w8, w10   
  cmp w7, w26 
  beq .L1026   
.L1029:  
  add w0, w11, w7
  add x0, x2, x0, sxtw 3
  ldr x1, [x0, -8] 
  add x0, x2, x7, sxtw 3
  str x1, [x0, -8] 
  cmp w9, 0 
  ble .L1027 

But with the scopedtables change it becomes:

.L1027:  
  add w2, w2, 1
  cmp w2, w3   
  beq .L1026   
.L1029:  
  cmp w4, 0
  ble .L1027

[Bug rtl-optimization/69592] [6 Regression] Compile-time and memory-use hog in combine

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Latent issue triggered by r230856, of course rewriting the testcase by hand to
use __builtin_{add,sub}_overflow instead of the code it uses would trigger this
earlier.
Bet we want to limit the recursion depth of the nonzero_bits and
num_sign_bit_copies.

[Bug tree-optimization/69556] [6 Regression] forwprop4/match.pd undoing work from recip

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Author: rguenth
Date: Mon Feb  1 15:40:23 2016
New Revision: 233040

URL: https://gcc.gnu.org/viewcvs?rev=233040&root=gcc&view=rev
Log:
2016-02-01  Richard Biener  

PR middle-end/69556
* match.pd: Guard (C1/X)*C2 -> (C1*C2)/X with single_use.

* gcc.dg/tree-ssa/recip-8.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-8.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/69598] New: gcc.dg/tree-ssa/vrp47.c scan-tree-dump-times vrp1 "[xy][^ ]* !=" 0 fails for powerpc64-linux-gnu

[tiago.brusamarello at datacom dot ind.br]

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

Bug ID: 69598
   Summary: gcc.dg/tree-ssa/vrp47.c scan-tree-dump-times vrp1
"[xy][^ ]* !=" 0 fails for powerpc64-linux-gnu
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tiago.brusamarello at datacom dot ind.br
  Target Milestone: ---

Test suite from GCC 4.9.1 for powerpc64-linux-gnu fails with the following
output:

Executing on host: powerpc64-unknown-linux-gnu-gcc
/opt/x-tools/powerpc64-unknown-linux-gnu_v1.0/test-suite/gcc/testsuite/gcc.dg/tree-ssa/vrp47.c
 -fno-diagnostics-show-caret -fdiagnostics-color=never   -O2 -fdump-tree-vrp1
-fdump-tree-dom1 -fdump-tree-vrp2 -S  -o vrp47.s(timeout = 300)
spawn powerpc64-unknown-linux-gnu-gcc
/opt/x-tools/powerpc64-unknown-linux-gnu_v1.0/test-suite/gcc/testsuite/gcc.dg/tree-ssa/vrp47.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -fdump-tree-vrp1
-fdump-tree-dom1 -fdump-tree-vrp2 -S -o vrp47.s
PASS: gcc.dg/tree-ssa/vrp47.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/vrp47.c scan-tree-dump-times vrp1 "[xy][^ ]* !=" 0
PASS: gcc.dg/tree-ssa/vrp47.c scan-tree-dump-times vrp1 "x[^ ]* [|] y" 1
PASS: gcc.dg/tree-ssa/vrp47.c scan-tree-dump-times vrp1 "x[^ ]* \\^ 1" 1
PASS: gcc.dg/tree-ssa/vrp47.c scan-tree-dump-times vrp2 " & 1;" 0

[Bug tree-optimization/69556] [6 Regression] forwprop4/match.pd undoing work from recip

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #9 from Richard Biener  ---
Fixed.