[Bug gcov-profile/81080] target libgcov not built with large file support

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Wed Jun 21 07:01:34 2017
New Revision: 249435

URL: https://gcc.gnu.org/viewcvs?rev=249435&root=gcc&view=rev
Log:
2017-06-21  Richard Biener  

PR gcov-profile/81080
* configure.ac: Add AC_SYS_LARGEFILE.
* libgcov.h: Include auto-target.h before tsystem.h to pick
up _FILE_OFFSET_BITS which might differ for multilibs.
* config.in: Regenerate.
* configure: Likewise.

Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/config.in
trunk/libgcc/configure
trunk/libgcc/configure.ac
trunk/libgcc/libgcov.h

[Bug other/81146] Wine 2.10 cannot be compiled with -flto

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-06-21
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Well, trying to understand what's wrong is quite hard. The project uses a
wrapper (winegcc.c) that does a lot of magic stuff. That explains why we see
failures, I guess.

[Bug middle-end/81030] [8 Regression] ICE on valid code at -O1 (only) on x86_64-linux-gnu: verify_flow_info failed

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman  ---
(In reply to David Binderman from comment #2)
> Bug seems to occur between gcc revision 248932 and 249008.

Between revisions 248932 and 248951.

[Bug tree-optimization/80928] SLP vectorization does not handle induction in outer loop vectorization

[ro at gcc dot gnu.org]

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

--- Comment #15 from Rainer Orth  ---
Richard,

do you have the i686-pc-linux-gnu/i386-pc-solaris2.* libgomp ICEs with -m64
on the radar?  They still happen as of r249422.

Thanks.
  Rainer

[Bug middle-end/81030] [8 Regression] ICE on valid code at -O1 (only) on x86_64-linux-gnu: verify_flow_info failed

[dcb314 at hotmail dot com]

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

--- Comment #4 from David Binderman  ---
(In reply to David Binderman from comment #3)
> (In reply to David Binderman from comment #2)
> > Bug seems to occur between gcc revision 248932 and 249008.
> 
> Between revisions 248932 and 248951.

Between revisions 248942 and 248947.

[Bug tree-optimization/80928] SLP vectorization does not handle induction in outer loop vectorization

[rguenther at suse dot de]

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

--- Comment #16 from rguenther at suse dot de  ---
On Wed, 21 Jun 2017, ro at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80928
> 
> --- Comment #15 from Rainer Orth  ---
> Richard,
> 
> do you have the i686-pc-linux-gnu/i386-pc-solaris2.* libgomp ICEs with -m64
> on the radar?  They still happen as of r249422.

I tried hard to reproduce but failed so yes, on my radar but nothing I can 
do about :/

If you can direct me to a CF machine that reproduces the issue that
would be nice.

[Bug tree-optimization/80928] SLP vectorization does not handle induction in outer loop vectorization

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #16 from rguenther at suse dot de  ---
> I tried hard to reproduce but failed so yes, on my radar but nothing I can 
> do about :/
>
> If you can direct me to a CF machine that reproduces the issue that
> would be nice.

Weird: I have it in my regular i686-pc-linux-gnu builds on Fedora 25
(Xeon X7542), only for -m64.  Doesn't happen for an x86_64-pc-linux-gnu
compiler on the same box, though.

I'll see if I can find a cfarm box where it reproduces.

[Bug target/81142] Segmentation fault when using static __thread variables

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||arm

--- Comment #4 from Richard Biener  ---
Also GCC 4.9 is no longer supported.

[Bug jit/81144] jit.dg/test-operator-overloading.cc, initial compilation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug sanitizer/81148] UBSAN: two more false positives

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-06-21
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

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

[Bug lto/69866] lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:158

[thopre01 at gcc dot gnu.org]

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

--- Comment #13 from Thomas Preud'homme  ---
Author: thopre01
Date: Wed Jun 21 08:17:56 2017
New Revision: 249437

URL: https://gcc.gnu.org/viewcvs?rev=249437&root=gcc&view=rev
Log:
2017-06-21  Thomas Preud'homme  

Revert:

Backport from mainline
2017-06-15  Thomas Preud'homme  

PR lto/69866
* gcc.dg/lto/pr69866_0.c: New test.
* gcc.dg/lto/pr69866_1.c: Likewise.

Backport from mainline
2017-06-18  Jan Hubicka  

* gcc.dg/lto/pr69866_0.c: This test needs alias.


Removed:
branches/ARM/embedded-6-branch/gcc/lto/ChangeLog.arm
branches/ARM/embedded-6-branch/gcc/testsuite/gcc.dg/lto/pr69866_0.c
branches/ARM/embedded-6-branch/gcc/testsuite/gcc.dg/lto/pr69866_1.c
Modified:
branches/ARM/embedded-6-branch/gcc/lto/lto-symtab.c
branches/ARM/embedded-6-branch/gcc/testsuite/ChangeLog.arm

[Bug sanitizer/81148] UBSAN: two more false positives

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
w/o ubsan we fold this all the way to one.  With ubsan we fold it as

  bool a = -((long int) ~(x != 0) ^ 9223372036854775806) + -124 != 0;

so there's some stupid TYPE_OVERFLOW_SANITIZED check in the way somewhere.

It looks association related again, I will have a look.

[Bug sanitizer/81148] UBSAN: two more false positives

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Tomorrow, unless Marek beats me.

[Bug tree-optimization/80928] SLP vectorization does not handle induction in outer loop vectorization

[rguenther at suse dot de]

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

--- Comment #18 from rguenther at suse dot de  ---
On Wed, 21 Jun 2017, ro at CeBiTec dot Uni-Bielefeld.DE wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80928
> 
> --- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> ---
> > --- Comment #16 from rguenther at suse dot de  ---
> > I tried hard to reproduce but failed so yes, on my radar but nothing I can 
> > do about :/
> >
> > If you can direct me to a CF machine that reproduces the issue that
> > would be nice.
> 
> Weird: I have it in my regular i686-pc-linux-gnu builds on Fedora 25
> (Xeon X7542), only for -m64.  Doesn't happen for an x86_64-pc-linux-gnu
> compiler on the same box, though.
> 
> I'll see if I can find a cfarm box where it reproduces.

I have not yet built a native i686 compiler with 64bit support but only
tried a x86_64 -> i686 cross with 64bit support where it doesn't
reproduce.

Native builds for i686 on a x86_64 host are always a bit odd to produce.

[Bug tree-optimization/80928] SLP vectorization does not handle induction in outer loop vectorization

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #18 from rguenther at suse dot de  ---
[...]
> I have not yet built a native i686 compiler with 64bit support but only
> tried a x86_64 -> i686 cross with 64bit support where it doesn't
> reproduce.
>
> Native builds for i686 on a x86_64 host are always a bit odd to produce.

Indeed, probably worth documenting the procedure somewhere.  I believe
what you need is to configure with

* CC='gcc -m32' 'CXX='g++ -m32'

* --enable-targets=all

* --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu

  so configure doesn't conclude it's a cross

* using 32-bit gas and gld helps, but isn't required, I believe (it gets
  a few assembler configure tests wrong where the 32-bit and 64-bit
  results differ)

However, it's easier than having to have a separate machine with a
32-bit kernel around (if such beasts still exist)...

Rainer

[Bug target/81142] Segmentation fault when using static __thread variables

[tomas_paukrt at conel dot cz]

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

tomas_paukrt at conel dot cz changed:

   What|Removed |Added

  Known to fail||4.9.4, 5.4.0, 6.3.0

--- Comment #5 from tomas_paukrt at conel dot cz ---
I was able to reproduce this bug with GCC 5.4.0 and 6.3.0.
GCC 7.1.0 generates slightly different assembler code and I have not been able
to trigger this bug yet.

[Bug c++/81140] Update docs to reflect P0612R0: clarify meaning of "volatile access" + that it includes any glvalue

[db0451 at gmail dot com]

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

--- Comment #1 from DB  ---
Hm, in fact, I'm not sure the GCC/g++ docs ever address what happens when a
declared non-volatile object is accessed through a volatile-qualified
reference/pointer, which by my understanding is the crux of the NB issue.

So maybe we need a totally new clause in the documentation.

[Bug c++/81140] Update docs to reflect P0612R0: clarify meaning of "volatile access" + that it includes any glvalue

[db0451 at gmail dot com]

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

DB  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=33053

--- Comment #2 from DB  ---
yup: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33053

[Bug c++/81134] C++ partial template specialization issue

[manish.baphna at citi dot com]

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

--- Comment #2 from Manish  ---
Thanx Jonathan. 

Your explanation explains behavior. I wonder if standard has some preference
dictated here?

[Bug libstdc++/81092] Missing symbols for new std::wstring constructors

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
Author: redi
Date: Wed Jun 21 08:55:26 2017
New Revision: 249438

URL: https://gcc.gnu.org/viewcvs?rev=249438&root=gcc&view=rev
Log:
PR libstdc++/81092 Regenerate configure for libtool_VERSION change

PR libstdc++/81092
* configure: Regenerate.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/configure

[Bug libstdc++/81092] Missing symbols for new std::wstring constructors

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  ---
Author: redi
Date: Wed Jun 21 08:55:52 2017
New Revision: 249439

URL: https://gcc.gnu.org/viewcvs?rev=249439&root=gcc&view=rev
Log:
PR libstdc++/81092 Regenerate configure for libtool_VERSION change

PR libstdc++/81092
* configure: Regenerate.

Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/configure

[Bug target/78480] m68k-rtems compile error in libgfortran

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

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #3 from Andreas Schwab  ---
That looks like a newlib configuration bug.

[Bug libstdc++/81092] Missing symbols for new std::wstring constructors

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #14 from Jonathan Wakely  ---
Really fixed now.

[Bug c++/81134] C++ partial template specialization issue

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
The standard seems clear to me and GCC's behaviour is correct.

[Bug c++/81134] C++ partial template specialization issue

[manish.baphna at citi dot com]

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

--- Comment #4 from Manish  ---
Which section in particular you are referring?

I am looking at this doc, section 14.7 but couldn't find relevant point.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3690.pdf

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #49 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #47 from Daniel Santos  ---
[...]
> I'm sorry for the delay again.  I've been having some health problems
> infringing upon my hacking time.

No worries at all: don't even think about this stuff before you're well again!

> I wanted to study the use of __USER_LABEL_PREFIX__ to make sure I understand
> the implications.  I'm not completely clear on rather or not this is
> automatically applied when a back end uses gen_rtx_SYMBOL_REF (or some such),
> but guess is that it is.  It is also plausible to omit Darwin support for now,

That's my understanding as well.

> as I've learned that 64-bit Wine isn't yet working for Darwin either.  If 
> there
> are further problems, then that might be the smartest way to go since I don't
> have access to such a machine witch which I can test, experiment, debug, etc. 
> But if this does the trick, then all the better.

We're getting considerably closer with this latest patch.  I'll describe
the current issues below; maybe some of them are issues even beyond Darwin.

> I changed the C() macro to ASMNAME() just because I prefer helpful names and I
> decided to yank out all of the FUNC_BEGIN/FUNC_END macros from ms-sysv.c and
> just use #if directives directly in the string definition.  There's no sense 
> in
> maintaining a separate set of asm support macros dealing in strings when
> there's only one use site.

Fine with me.  The new names are certainly more expressive, while I'd
just ripped the definitions out of libffi to see if I could something
working that way at all.

> I also noticed a possible "gotcha" with the #if __x86_64__ and __SSE2__ -- not
> that I would expect necessarily expect it to happen.

I'm not sure this is even possible...

> In hopes of making your review easier, below is a delta between this new (v6)
> patch set and your last posted patches.

The new patch works fine for me on both x86_64-pc-linux-gnu (as
expected) and i386-pc-solaris2.12.

On x86_64-apple-darwin11.4.2, there are a couple of isues, some of which
I'd already resolved before you posted the revised patch.

* Initially all tests SEGVed like this (e.g. with -p0 and compiled with -O2):

Program received signal SIGSEGV, Segmentation fault.
0x00010004664d in regs_to_mem ()
1: x/i $pc
=> 0x10004664d :   movaps %xmm6,(%rax)
(gdb) where
#0  0x00010004664d in regs_to_mem ()
#1  0x0001000465df in do_test_body ()
#2  0x00010002f227 in do_tests_ ()
#3  0x0001000468e3 in main ()

  Here, %rax is 0x0.

  This happens because some setup happens between do_test_body0 and
  do_test_body, and do_test_aligned jumps directly to do_test_body:

.globl _do_test_body0
.no_dead_strip _do_test_body0
_do_test_body0:
movq_test_data@GOTPCREL(%rip), %rax

.globl _do_test_body
_do_test_body:

# Save registers.
lea (%rax), %rax
call_regs_to_mem

  By that jump, you bypass the setup of %rax and make the test FAIL.  I
  managed to avoid this by changing the jmp to do_test_body0 instead.
  This gets me past this failure, and works on Linux/x86_64, too.
  However, this makes the tests FAIL on Solaris/x86, supposedly due to
  the -fomit-frame-pointer/-fno-omit-frame-pointer difference (though I
  haven't looked more closely).

* With the do_test_body0 jump, I hit the next issue on Darwin with -O0:
  the test SEGVs here:

Program received signal SIGSEGV, Segmentation fault.
0x000100031c4e in do_test_body0 ()
at
/vol/gcc/src/hg/trunk/solaris/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c:163
163   __asm__ ("\n"
1: x/i $pc
=> 0x100031c4e :  mov%rax,0x2a8(%rdi)
(gdb) where
(gdb) p/x $rdi
$1 = 0x5dc3340b214ef45c

  which is no wonder since %rdi got clobbered just before.  Here's the
  assembler output:

.globl _do_test_body0
.no_dead_strip _do_test_body0
_do_test_body0:
pushq   %rbp
movq%rsp, %rbp
movq_test_data@GOTPCREL(%rip), %rax
movq_test_data@GOTPCREL(%rip), %rdx
movq_test_data@GOTPCREL(%rip), %rcx
movq_test_data@GOTPCREL(%rip), %rsi
movq_test_data@GOTPCREL(%rip), %rdi

.globl _do_test_body
_do_test_body:

# Save registers.
lea (%rax), %rax
call_regs_to_mem

# Load registers with random data.
lea 224(%rdx), %rax
call_mem_to_regs

# Save original return address.
pop %rax
movq%rax, 680(%rdi)

# Call the test function
call*672(%rsi)

# Restore the original return address.
movq680(%rdi), %rcx
push%rcx

  By clobbering %rdi (and %rsi), you cause the SEGV above.  To work
  around this, I've wrapped the save/restore of those regs in !__APPLE__
  which gets me a bit further.

* Now I hit another SEGV here:

Program received signal SIGSEGV, S

[Bug tree-optimization/80928] SLP vectorization does not handle induction in outer loop vectorization

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #20 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #18 from rguenther at suse dot de  ---
[...]
> I have not yet built a native i686 compiler with 64bit support but only
> tried a x86_64 -> i686 cross with 64bit support where it doesn't
> reproduce.

Now that you mention it, the ICE doesn't occur on both
x86_64-pc-linux-gnu and amd64-pc-solaris compilers, but only in the
i?86-*-* ones.

Rainer

[Bug bootstrap/81149] New: [8 Regression] profiledbootstrap failed with LTO

[hjl.tools at gmail dot com]

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

Bug ID: 81149
   Summary: [8 Regression] profiledbootstrap failed with LTO
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: mliska at suse dot cz
  Target Milestone: ---

On Linux/x86-64, r249367 caused profiledbootstrap to fail with LTO:

lto1: internal compiler error: in inline_small_functions, at ipa-inline.c:1891
0x7dff38 inline_small_functions
/export/project/git/gcc-regression/gcc/gcc/ipa-inline.c:1891
0x7dff38 ipa_inline
/export/project/git/gcc-regression/gcc/gcc/ipa-inline.c:2429
0x7dff38 execute
/export/project/git/gcc-regression/gcc/gcc/ipa-inline.c:2835
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error:
/export/project/git/gcc-regression-bootstrap/master/249367/bld/./prev-gcc/xg++
returned 1 exit status
compilation terminated.
/usr/local/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
/export/project/git/gcc-regression/gcc/gcc/fortran/Make-lang.in:97: recipe for
target 'f951' failed
make[3]: *** [f951] Error 1

when configured with

 --prefix=/export/project/git/gcc-regression-bootstrap/master/249367/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--enable-languages=c,c++,fortran --enable-bootstrap --with-fpmath=sse
--with-build-config=bootstrap-lto --disable-werror --disable-multilib
--disable-libcc1 --disable-libcilkrts --disable-libsanitizer

[Bug bootstrap/81149] [8 Regression] profiledbootstrap failed with LTO

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-21
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

[Bug bootstrap/81149] [8 Regression] profiledbootstrap failed with LTO

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
dup.

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

[Bug ipa/81133] [8 Regression] PGO/LTO bootstrap: ICE: in inline_small_functions, at ipa-inline.c:1891

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

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

[Bug c++/81130] [6/7/8 Regression] ICE OpenMP shared clause in gimplify_var_or_parm_decl, at gimplify.c:2584

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jun 21 10:58:00 2017
New Revision: 249445

URL: https://gcc.gnu.org/viewcvs?rev=249445&root=gcc&view=rev
Log:
PR c++/81130
* gimplify.c (omp_add_variable): Don't force GOVD_SEEN for types
with ctors/dtors if GOVD_SHARED is set.

* testsuite/libgomp.c++/pr81130.C: New test.

Added:
trunk/libgomp/testsuite/libgomp.c++/pr81130.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/libgomp/ChangeLog

[Bug bootstrap/81150] New: [8 Regression] GCC is miscompiled with -O3

[hjl.tools at gmail dot com]

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

Bug ID: 81150
   Summary: [8 Regression] GCC is miscompiled with -O3
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

On Linux/x86-64, I saw

20083 hjl   20   0   69400   1488   1340 R 199.7  0.0 505:16.72 fib.exe

 6288 hjl   20   0   64288   2652   2328 R 100.0  0.0 246:38.57
fib-opr-overloa  
21594 hjl   20   0   64284   2736   2416 R 100.0  0.0 278:27.75
fib-opr-overloa  
 1181 hjl   20   0   64288   1512   1368 R  99.7  0.0 223:01.07
fib-opr-overloa

Executing on host: /export/gnu/import/git/gcc-test/bld/gcc/xgcc
-B/export/gnu/import/git/gcc-test/bld/gcc/
/export/gnu/import/git/gcc-test/src-trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/fib.c
 -m32   
-B/export/gnu/import/git/gcc-test/bld/x86_64-pc-linux-gnu/32/libcilkrts/ 
-L/export/gnu/import/git/gcc-test/bld/x86_64-pc-linux-gnu/32/libcilkrts/.libs
-fno-diagnostics-show-caret -fdiagnostics-color=never   -g  -fcilkplus  -lm  -o
./fib.exe(timeout = 300)
spawn -ignore SIGHUP /export/gnu/import/git/gcc-test/bld/gcc/xgcc
-B/export/gnu/import/git/gcc-test/bld/gcc/
/export/gnu/import/git/gcc-test/src-trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/fib.c
-m32 -B/export/gnu/import/git/gcc-test/bld/x86_64-pc-linux-gnu/32/libcilkrts/
-L/export/gnu/import/git/gcc-test/bld/x86_64-pc-linux-gnu/32/libcilkrts/.libs
-fno-diagnostics-show-caret -fdiagnostics-color=never -g -fcilkplus -lm -o
./fib.exe

when running GCC testsuite with r249394 when configured with

--prefix=/usr/8.0.0 --enable-clocale=gnu --with-system-zlib --enable-shared
--with-demangler-in-ld --enable-libmpx --with-build-config='bootstrap-O3
bootstrap-debug' --disable-werror --with-fpmath=sse

[Bug ipa/81133] [8 Regression] PGO/LTO bootstrap: ICE: in inline_small_functions, at ipa-inline.c:1891

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-21
 Ever confirmed|0   |1

[Bug target/81142] Segmentation fault when using static __thread variables

[tomas_paukrt at conel dot cz]

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

--- Comment #6 from tomas_paukrt at conel dot cz ---
Created attachment 41595
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41595&action=edit
C source file without snprintf

[Bug bootstrap/81150] [8 Regression] GCC is miscompiled with -O3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug target/81142] Segmentation fault when using static __thread variables

[tomas_paukrt at conel dot cz]

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

--- Comment #7 from tomas_paukrt at conel dot cz ---
I attached another C source file that is even simpler.

Compiled program causes segmentation fault on AM335X (Cortex-A8) as well as on
SPEAr320S-2 (ARM926EJ-S).

Using option -ftls-model=initial-exec or -mtls-dialect=gnu2 leads to generating
different assembler code that do not cause segmentation fault.

[Bug inline-asm/70184] Explicit register variables holding function arguments overwritten by conversion libcall

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Target Milestone|--- |6.3

--- Comment #11 from Ramana Radhakrishnan  ---
Fixed in 6.3

[Bug sanitizer/81125] [7/8 Regression] -fsanitize=undefined ICE

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
Still fails on darwin

/opt/gcc/_clean/gcc/testsuite/g++.dg/ubsan/pr81125.C: In constructor 'A::A(long
int)':
/opt/gcc/_clean/gcc/testsuite/g++.dg/ubsan/pr81125.C:19:14: internal compiler
error: in make_decl_rtl, at varasm.c:1311
   long b = a % c;
~~^~~

[Bug c++/81151] New: -Wmaybe-uninitialized in insn-emit.c

[marxin at gcc dot gnu.org]

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

Bug ID: 81151
   Summary: -Wmaybe-uninitialized in insn-emit.c
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41596
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41596&action=edit
Test-case

Building current GCC with GCC 7.1 produces warning:

g++ insn-emit.ii -Wmaybe-uninitialized
insn-emit.c: In function ‘rtx_def* gen_roundv16sf2(rtx, rtx)’:
insn-emit.c:148125:14: warning: ‘operands[2]’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
 operand2 = operands[2];
 ~^
insn-emit.c: In function ‘rtx_def* gen_roundv8sf2(rtx, rtx)’:
insn-emit.c:148194:14: warning: ‘operands[2]’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
 operand2 = operands[2];
 ~^
insn-emit.c: In function ‘rtx_def* gen_roundv4sf2(rtx, rtx)’:
insn-emit.c:148263:14: warning: ‘operands[2]’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
 operand2 = operands[2];
 ~^
insn-emit.c: In function ‘rtx_def* gen_roundv8df2(rtx, rtx)’:
insn-emit.c:148332:14: warning: ‘operands[2]’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
 operand2 = operands[2];
 ~^
insn-emit.c: In function ‘rtx_def* gen_roundv4df2(rtx, rtx)’:
insn-emit.c:148401:14: warning: ‘operands[2]’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
 operand2 = operands[2];
 ~^
insn-emit.c: In function ‘rtx_def* gen_roundv2df2(rtx, rtx)’:
insn-emit.c:148470:14: warning: ‘operands[2]’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
 operand2 = operands[2];
 ~^

[Bug c++/81151] -Wmaybe-uninitialized in insn-emit.c

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2017-6-21
 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Started with r245840.

[Bug c++/46476] Missing Warning about unreachable code after return

[jg at jguk dot org]

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

--- Comment #13 from Jon Grant  ---
May be simpler to just implement these static analysis checkers outside of a
compiler.

[Bug c++/81134] C++ partial template specialization issue

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
To determine the type of the conditional expression it's necessary to know the
types of both GCD::value and GCD::value, which requires
instantiating both of GCD and GCD, which triggers the infinite
recursion.

[Bug c++/81152] New: False strict-aliasing warning

[rrrlasse at hotmail dot com]

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

Bug ID: 81152
   Summary: False strict-aliasing warning
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rrrlasse at hotmail dot com
  Target Milestone: ---

Version 8.0.0 20170620 (and also version 7.1) gives following false warning:


me@ubuntu:~$ g++ -Wall -Wextra -O3 -std=c++14 -fstrict-aliasing
-Wstrict-aliasing /mnt/hgfs/D/c.cpp
/mnt/hgfs/D/c.cpp: In constructor ‘BasicArray::BasicArray()’:
/mnt/hgfs/D/c.cpp:18:40: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
  char* p = reinterpret_cast(tmp.m_data);
^~

Below is a minimal code sample. I can't reduce it further - you need both the
inheritance and also the templates for it to trigger:


struct Array
{
char* m_data = nullptr;
};

template  struct BasicArray : public Array
{
BasicArray();
};

template  BasicArray::BasicArray()
{
BasicArray tmp;

// aliasing warning
char* p = reinterpret_cast(tmp.m_data);

// avoid unused variable warning
static_cast(p);
}

int main()
{
BasicArray f;
}

[Bug target/81151] -Wmaybe-uninitialized in insn-emit.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 CC||jakub at gcc dot gnu.org
  Component|c++ |target
 Ever confirmed|0   |1

[Bug target/81151] -Wmaybe-uninitialized in insn-emit.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 41597
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41597&action=edit
gcc8-pr81151.patch

Untested fix.

[Bug libstdc++/81138] std::money_put facet does not write '0' before decimal point

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-21
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
The patch is wrong, because we don't want to add the zero when frac_digits() is
not positive.

[Bug c++/81152] False strict-aliasing warning

[rrrlasse at hotmail dot com]

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

--- Comment #1 from Lasse Reinhold  ---
Created attachment 41598
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41598&action=edit
Non-stack overflowing version

[Bug tree-optimization/79489] Strange static branch prediction for n != 0

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Author: marxin
Date: Wed Jun 21 12:51:46 2017
New Revision: 249450

URL: https://gcc.gnu.org/viewcvs?rev=249450&root=gcc&view=rev
Log:
Make early return predictor more precise.

2017-06-21  Martin Liska  

PR tree-optimization/79489
* gimplify.c (maybe_add_early_return_predict_stmt): New
function.
(gimplify_return_expr): Call the function.
* predict.c (tree_estimate_probability_bb): Remove handling
of early return.
* predict.def: Update comment about early return predictor.
* gimple-predict.h (is_gimple_predict): New function.
* predict.def: Change default value of early return to 66.
* tree-tailcall.c (find_tail_calls): Skip GIMPLE_PREDICT
statements.
* passes.def: Put pass_strip_predict_hints to the beginning of
IPA passes.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-low.c
trunk/gcc/gimple-predict.h
trunk/gcc/gimplify.c
trunk/gcc/passes.def
trunk/gcc/predict.c
trunk/gcc/predict.def
trunk/gcc/tree-tailcall.c

[Bug c/81153] New: Incorrect annotation causes an internal compiler error at tree-ssanames.c line 375

[ernst.vanveenendaal at prismtech dot com]

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

Bug ID: 81153
   Summary: Incorrect annotation causes an internal compiler error
at tree-ssanames.c line 375
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ernst.vanveenendaal at prismtech dot com
  Target Milestone: ---

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

I encounted an internal compiler error:
test.c: In function ‘main’:
test.c:8:8: internal compiler error: in get_range_info, at tree-ssanames.c:375
  void *ptr2 = my_realloc(ptr,20);
^~~~

because the code I was trying to compile had an incorrect annotation for a
function prototype. Correction the annotation fixed the crash, but I don't
expect the compiler to crash on such an error.

GCC version is gcc-7 (SUSE Linux) 7.1.1 20170530 [gcc-7-branch revision 248621]
on OpenSuse thumbleweed

Reproducer (just build with gcc test.c):

test.c:
===
#include "test.h"
#include 
#include 

void main(void)
{
void *ptr = malloc(20);
void *ptr2 = my_realloc(ptr,20);
printf("ptr = %x, ptr2 = %x\n", ptr, ptr2);
}

void* my_realloc(void* ptr, int size) 
{
return realloc(ptr, size);
}

===
test.h
===
void *my_realloc(void*, int) 
__attribute__((alloc_size(1)));

===

Compiling this with gcc will result in an error:

test.c: In function ‘main’:
test.c:8:8: internal compiler error: in get_range_info, at tree-ssanames.c:375
  void *ptr2 = my_realloc(ptr,20);
^~~~

[Bug c/81153] Incorrect annotation causes an internal compiler error at tree-ssanames.c line 375

[ernst.vanveenendaal at prismtech dot com]

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

--- Comment #1 from ernst.vanveenendaal at prismtech dot com ---
Created attachment 41600
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41600&action=edit
reproducer

[Bug c/81153] Incorrect annotation causes an internal compiler error at tree-ssanames.c line 375

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
I fixed this in r247586 but seems I never backported the fix.

[Bug c/81153] Incorrect annotation causes an internal compiler error at tree-ssanames.c line 375

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Will do so.

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

[Bug tree-optimization/80612] [7 Regression] ICE in get_range_info, at tree-ssanames.c:375

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||ernst.vanveenendaal@prismte
   ||ch.com

--- Comment #9 from Marek Polacek  ---
*** Bug 81153 has been marked as a duplicate of this bug. ***

[Bug c++/67074] Name lookup ambiguity between namespace and its alias

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #3 from Nathan Sidwell  ---
Fixed r249408.

[Bug c++/12944] [meta-bug] C++ name-lookup problems

[nathan at gcc dot gnu.org]

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

Bug 67074 Summary: Name lookup ambiguity between namespace and its alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67074

   What|Removed |Added

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

[Bug c++/81154] New: OpenMP with shared variable in a template class crash

[mplaneta at os dot inf.tu-dresden.de]

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

Bug ID: 81154
   Summary: OpenMP with shared variable in a template class crash
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mplaneta at os dot inf.tu-dresden.de
  Target Milestone: ---

Created attachment 41601
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41601&action=edit
Minimal example

Code compilation fails when following clauses are met:

1. In instantiation of a template class
2. There is a function overload
3. Inside one of the function overloads there is an OpenMP parallel for pragma
4. Pragma uses reduction or shared clause
5. A variable name is a function name (erroneously)
6. Compilation happens with -fopenmp (obviously)

The code is incorrect, but instead of adequate error message the compiler
crashes.

Bug exists in many versions of GCC, not only 7.1.

[Bug c++/81154] OpenMP with shared variable in a template class crash

[mplaneta at os dot inf.tu-dresden.de]

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

mplaneta at os dot inf.tu-dresden.de changed:

   What|Removed |Added

 CC||mplaneta at os dot 
inf.tu-dresden.
   ||de

--- Comment #1 from mplaneta at os dot inf.tu-dresden.de ---
The log:

$ gcc a.cpp -fopenmp
a.cpp: In instantiation of ‘double C::overlap_prob(T) const [with T = int]’:
a.cpp:21:29:   required from here
a.cpp:8:9: internal compiler error: in tsubst_copy, at cp/pt.c:14634
 #pragma omp parallel for reduction(+:overlap_prob)
 ^~~
0x612260 tsubst_copy
/dev/shm/schmaik/gcc-7.1.0/gcc/cp/pt.c:14634
0x61bf4e tsubst_copy
/dev/shm/schmaik/gcc-7.1.0/gcc/cp/pt.c:14433
0x61bf4e tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/dev/shm/schmaik/gcc-7.1.0/gcc/cp/pt.c:17930
0x6107d7 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/dev/shm/schmaik/gcc-7.1.0/gcc/cp/pt.c:16468
0x6118a2 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/dev/shm/schmaik/gcc-7.1.0/gcc/cp/pt.c:15704
0x6118a2 tsubst_omp_clause_decl
/dev/shm/schmaik/gcc-7.1.0/gcc/cp/pt.c:15098
0x614f83 tsubst_omp_clauses
/dev/shm/schmaik/gcc-7.1.0/gcc/cp/pt.c:15196
0x610101 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/dev/shm/schmaik/gcc-7.1.0/gcc/cp/pt.c:16126
0x610685 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/dev/shm/schmaik/gcc-7.1.0/gcc/cp/pt.c:15719
0x61051b tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/dev/shm/schmaik/gcc-7.1.0/gcc/cp/pt.c:15945
0x60ecb2 instantiate_decl(tree_node*, bool, bool)
/dev/shm/schmaik/gcc-7.1.0/gcc/cp/pt.c:22897
0x62c5fb instantiate_pending_templates(int)
/dev/shm/schmaik/gcc-7.1.0/gcc/cp/pt.c:23018
0x64c2d0 c_parse_final_cleanups()
/dev/shm/schmaik/gcc-7.1.0/gcc/cp/decl2.c:4526
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/46476] Missing Warning about unreachable code after return

[manu at gcc dot gnu.org]

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

--- Comment #14 from Manuel López-Ibáñez  ---
(In reply to Jon Grant from comment #13)
> May be simpler to just implement these static analysis checkers outside of a
> compiler.

Or as a plugin to GCC (so that it reuses GCC internals) that is stored in GCC
source repository and build alongside. But the main barrier for this is not
technical or acceptance, it is leadership and human resources. Someone has to
take care of such a project, find developers and commit to maintain it. For
various (bad) reasons, people tend to prefer to develop their personal in-house
ad-hoc solution, rather than work with others with similar goals and with the
GCC community. The end result is that existing solutions are poor, not widely
used and often abandoned.

On the other hand, there are many examples to follow on how to approach such a
project. This includes all the enhancements to diagnostics done by non-core
developers, libcc1, the D front-end, every new target added by non-core
developers, etc.

[Bug sanitizer/81148] UBSAN: two more false positives

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Started with

commit 69693ea7b7ed45a12cbd505b2a66257fd4e81669
Author: rguenth 
Date:   Fri Jun 26 10:59:27 2015 +

2015-06-26  Richard Biener  

* fold-const.c (fold_binary_loc): Remove -A CMP -B -> A CMP B
and -A CMP CST -> A CMP -CST which is redundant with a pattern
in match.pd.
Move (A | C) == D where C & ~D != 0 -> 0, (X ^ Y) ==/!= 0 -> X
==/!= Y,
(X ^ Y) ==/!= {Y,X} -> {X,Y} ==/!= 0 and
(X ^ C1) op C2 -> X op (C1 ^ C2) to ...
* match.pd: ... patterns here.

* gcc.dg/tree-ssa/forwprop-25.c: Adjust.


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

it seems.

[Bug sanitizer/81148] UBSAN: two more false positives

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
It's the
(flag_sanitize & SANITIZE_SI_OVERFLOW) == 0
check in fold_negate_expr_1 that makes the difference w/ and w/o ubsan.

[Bug c++/81152] False strict-aliasing warning

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-21
 CC||jason at redhat dot com,
   ||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Started with r236221.

[Bug c++/46476] Missing Warning about unreachable code after return

[jg at jguk dot org]

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

--- Comment #15 from Jon Grant  ---
I saw Bjarne Stroustrup announced C++ Core Guidelines, as a gitproject which
includes a checker. At least it would all be in one place as a project.

[Bug debug/81155] New: Debug make check regressions in GCC 8.0

[andrey.y.guskov at intel dot com]

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

Bug ID: 81155
   Summary: Debug make check regressions in GCC 8.0
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.y.guskov at intel dot com
  Target Milestone: ---

Revision r249105 produces several new make check fails:

FAIL: gcc.dg/guality/pr43051-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 34 c == &a[0]
FAIL: gcc.dg/guality/pr43051-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 36 e == &a[1]
FAIL: gcc.dg/guality/pr43051-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 39 c == &a[0]
FAIL: gcc.dg/guality/pr43051-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 41 e == &a[1]
FAIL: gcc.dg/guality/pr43051-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 34 c == &a[0]
FAIL: gcc.dg/guality/pr43051-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 36 e == &a[1]
FAIL: gcc.dg/guality/pr43051-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 39 c == &a[0]
FAIL: gcc.dg/guality/pr43051-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 41 e == &a[1]
FAIL: gcc.dg/guality/pr45882.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 16 b == 7
FAIL: gcc.dg/guality/pr45882.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 16 c == 11
FAIL: gcc.dg/guality/pr45882.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 16 d == 112
FAIL: gcc.dg/guality/pr45882.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 16 e == 142
FAIL: gcc.dg/guality/pr45882.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 16 b == 7
FAIL: gcc.dg/guality/pr45882.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 16 c == 11

./configure line:
--enable-languages=c,c++ --enable-clocale=gnu --enable-cloog-backend=
isl --enable-shared --disable-libsanitizer --disable-bootstrap --disable-nls
--with-system-zlib --with-demangler-in-ld --with-arch=corei
7 --with-cpu=corei7 --with-fpmath=sse

[Bug sanitizer/81148] UBSAN: two more false positives

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
We basically have
-123 - (LONG_MIN + 1)
but it's being folded to
-LONG_MIN + -124
which is of course not correct.

[Bug tree-optimization/81136] [8 Regression] ICE: in vect_update_misalignment_for_peel, at tree-vect-data-refs.c:910

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

[Bug bootstrap/81150] [8 Regression] GCC is miscompiled with -O3

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #1 from H.J. Lu  ---
I can no longer reproduce it with r249449.

[Bug bootstrap/81037] Xcode 9 requires back ports on gcc-5-branch and gcc-6-branch for bootstrapping under Xcode 9

[mikestump at comcast dot net]

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

--- Comment #5 from Mike Stump  ---
Fixed in 6.4.  Leaving open for 5 backports.

[Bug bootstrap/81037] Xcode 9 requires back ports on gcc-5-branch and gcc-6-branch for bootstrapping under Xcode 9

[mrs at gcc dot gnu.org]

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

mrs at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-21
 CC||mrs at gcc dot gnu.org
  Known to work||6.3.1
 Ever confirmed|0   |1
  Known to fail||6.3.0

[Bug c++/81154] OpenMP with shared variable in a template class crash

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-06-21
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Created attachment 41602
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41602&action=edit
gcc8-pr81154.patch

Untested fix.

[Bug bootstrap/78251] config/gettext.m4 and config/iconv.m4 contaminate CPPFLAGS

[mikestump at comcast dot net]

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

--- Comment #3 from Mike Stump  ---
I've been avoiding this bug for years by just removing the unwind.h header. 
:-(

[Bug c/81156] New: GCC fails to compile a formula with tgmath.h

[equilibrium556 at gmx dot de]

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

Bug ID: 81156
   Summary: GCC fails to compile a formula with tgmath.h
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: equilibrium556 at gmx dot de
  Target Milestone: ---

Created attachment 41603
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41603&action=edit
C file that fails to compile with GCC

Hey, I ran into some problems compiling code that contained a specific formula.
I am using the type generic tgmath.h header because I am switching between
float and double for performance testing reasons.

If I include the tgmath.h header, the code doesn't compile, GCC ends up filling
up all my RAM and doesn't succeed to compile the file. It compiles using the
math.h header without a problem.

Here's the code in question (also in the attachment):
/* memory_leak.c */
#include 
#include 
#include 

#ifdef TEST_SP
typedef float test_float;
#else
typedef double test_float;
#endif

int main(int argc, char *argv[]) {
int b = -1;
test_float a, c, d, e, f, g, h, i;
a = c = d = e = f = g = h = i = 1;

a = 2*b/abs(b)*sqrt(pow(sqrt(pow(c, 2) - pow(d, 2)) -
e*f*cos(g)*cos(h)/abs(b)*(i - 1), 2) + pow(d/2, 2));

return 0;
}
/* END */

Compile with:
gcc -o memory_leak -DTEST_SP -std=c99 memory_leak.c -lm

It ends up eating all the memory there is.
Doesn't work on current GCC 7.1.1 on Arch nor on an RHEL6 distro with GCC
4.4.7.
Works with GCC 5.3 in Cygwin.
Clang and ICC compile without problems as well on Linux.

[Bug sanitizer/81148] UBSAN: two more false positives

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
So were in "associate:", where
lit0 = -123
lit1 = -1
which is associated to
lit0 = -124
and
var0 = null
var1 = -((long int) ~(x != 0) ^ 9223372036854775806)
which is associated to
var0 = -((long int) ~(x != 0) ^ 9223372036854775806)

Then
 9765   con0 = associate_trees (loc, con0, lit0, code, atype);
 9766   return
 9767 fold_convert_loc (loc, type, associate_trees (loc, var0,
con0,
 9768   code,
atype));

creates the bogus expression with overflow.

[Bug c++/81157] New: If constexpr does not support Short-circuit evaluation

[kmp53 at sina dot com]

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

Bug ID: 81157
   Summary: If constexpr does not support Short-circuit evaluation
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kmp53 at sina dot com
  Target Milestone: ---

template  concept bool Same=std::is_same_v;
template concept bool IsContainer=requires(T t){
  t.cnt();
  typename T::innerType;
};
struct Ct {
  void cnt(){;}
  using innerType=int;
};
template
requires IsContainer&&Same||Same void
fn(const V &a) {
void fn(const V &a) {
  if constexpr(IsContainer&&Same) ;//①
  //if constexpr(IsContainer)//②
//if constexpr(Same) ;
  else if (Same) ;
}
int main(int argc,char*argv[]){
  fn(1);//ill-formed
  fn(Ct());//OK
}
Concept supports short expressions, while if constexpr does not.
When I write ①, there is an error
'int' is not a class, struct, or union type
If it is written ②, there will be no problem. Is it a bug or a defect?

[Bug target/80718] GCC generates slow code for offsettable vec_duplicate

[meissner at gcc dot gnu.org]

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

--- Comment #5 from Michael Meissner  ---
Author: meissner
Date: Wed Jun 21 18:02:37 2017
New Revision: 249466

URL: https://gcc.gnu.org/viewcvs?rev=249466&root=gcc&view=rev
Log:
[gcc]
2017-06-21  Michael Meissner  

Back port from mainline
2017-05-19  Michael Meissner  

PR target/80718
* config/rs6000/vsx.md (vsx_splat_, VSX_D iterator): Prefer
VSX registers over GPRs, particularly on ISA 2.07 which does not
have the MTVSRDD instruction.

Back port from mainline
2017-05-18  Michael Meissner  

PR target/80510
* config/rs6000/predicates.md (simple_offsettable_mem_operand):
New predicate.

* config/rs6000/rs6000.md (ALTIVEC_DFORM): New iterator.
(define_peephole2 for Altivec d-form load): Add peepholes to catch
cases where the register allocator uses a move and an offsettable
memory operation to/from a FPR register on ISA 2.06/2.07.
(define_peephole2 for Altivec d-form store): Likewise.

Back port from mainline
2017-05-09  Michael Meissner  

PR target/68163
* config/rs6000/rs6000.md (f32_lr): Delete mode attributes that
are now unused after splitting mov{sf,sd}_hardfloat.
(f32_lr2): Likewise.
(f32_lm): Likewise.
(f32_lm2): Likewise.
(f32_li): Likewise.
(f32_li2): Likewise.
(f32_lv): Likewise.
(f32_sr): Likewise.
(f32_sr2): Likewise.
(f32_sm): Likewise.
(f32_sm2): Likewise.
(f32_si): Likewise.
(f32_si2): Likewise.
(f32_sv): Likewise.
(f32_dm): Likewise.
(f32_vsx): Likewise.
(f32_av): Likewise.
(mov_hardfloat): Split into separate movsf and movsd pieces.
For movsf, order stores so the VSX stores occur before the GPR
store which encourages the register allocator to use a traditional
FPR instead of a GPR.  For movsd, order the stores so that the GPR
store comes before the VSX stores to allow the power6 to work.
This is due to the power6 not having a 32-bit integer store
instruction from a FPR.
(movsf_hardfloat): Likewise.
(movsd_hardfloat): Likewise.

[gcc/testsuite]
2017-06-21  Michael Meissner  

Back port from mainline
2017-05-19  Michael Meissner  

PR target/80718
* gcc.target/powerpc/pr80718.c: New test.

Back port from mainline
2017-05-18  Michael Meissner  

PR target/80510
* gcc.target/powerpc/pr80510-1.c: New test.
* gcc.target/powerpc/pr80510-2.c: Likewise.

Back port from mainline
2017-05-09  Michael Meissner  

PR target/68163
* gcc.target/powerpc/pr68163.c: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr68163.c
  - copied unchanged from r249041,
trunk/gcc/testsuite/gcc.target/powerpc/pr68163.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr80510-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr80510-2.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr80718.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/predicates.md
branches/gcc-6-branch/gcc/config/rs6000/rs6000.md
branches/gcc-6-branch/gcc/config/rs6000/vsx.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/68163] GCC on power8 does not issue the stxsspx instruction on power8

[meissner at gcc dot gnu.org]

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

--- Comment #5 from Michael Meissner  ---
Author: meissner
Date: Wed Jun 21 18:02:37 2017
New Revision: 249466

URL: https://gcc.gnu.org/viewcvs?rev=249466&root=gcc&view=rev
Log:
[gcc]
2017-06-21  Michael Meissner  

Back port from mainline
2017-05-19  Michael Meissner  

PR target/80718
* config/rs6000/vsx.md (vsx_splat_, VSX_D iterator): Prefer
VSX registers over GPRs, particularly on ISA 2.07 which does not
have the MTVSRDD instruction.

Back port from mainline
2017-05-18  Michael Meissner  

PR target/80510
* config/rs6000/predicates.md (simple_offsettable_mem_operand):
New predicate.

* config/rs6000/rs6000.md (ALTIVEC_DFORM): New iterator.
(define_peephole2 for Altivec d-form load): Add peepholes to catch
cases where the register allocator uses a move and an offsettable
memory operation to/from a FPR register on ISA 2.06/2.07.
(define_peephole2 for Altivec d-form store): Likewise.

Back port from mainline
2017-05-09  Michael Meissner  

PR target/68163
* config/rs6000/rs6000.md (f32_lr): Delete mode attributes that
are now unused after splitting mov{sf,sd}_hardfloat.
(f32_lr2): Likewise.
(f32_lm): Likewise.
(f32_lm2): Likewise.
(f32_li): Likewise.
(f32_li2): Likewise.
(f32_lv): Likewise.
(f32_sr): Likewise.
(f32_sr2): Likewise.
(f32_sm): Likewise.
(f32_sm2): Likewise.
(f32_si): Likewise.
(f32_si2): Likewise.
(f32_sv): Likewise.
(f32_dm): Likewise.
(f32_vsx): Likewise.
(f32_av): Likewise.
(mov_hardfloat): Split into separate movsf and movsd pieces.
For movsf, order stores so the VSX stores occur before the GPR
store which encourages the register allocator to use a traditional
FPR instead of a GPR.  For movsd, order the stores so that the GPR
store comes before the VSX stores to allow the power6 to work.
This is due to the power6 not having a 32-bit integer store
instruction from a FPR.
(movsf_hardfloat): Likewise.
(movsd_hardfloat): Likewise.

[gcc/testsuite]
2017-06-21  Michael Meissner  

Back port from mainline
2017-05-19  Michael Meissner  

PR target/80718
* gcc.target/powerpc/pr80718.c: New test.

Back port from mainline
2017-05-18  Michael Meissner  

PR target/80510
* gcc.target/powerpc/pr80510-1.c: New test.
* gcc.target/powerpc/pr80510-2.c: Likewise.

Back port from mainline
2017-05-09  Michael Meissner  

PR target/68163
* gcc.target/powerpc/pr68163.c: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr68163.c
  - copied unchanged from r249041,
trunk/gcc/testsuite/gcc.target/powerpc/pr68163.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr80510-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr80510-2.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr80718.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/predicates.md
branches/gcc-6-branch/gcc/config/rs6000/rs6000.md
branches/gcc-6-branch/gcc/config/rs6000/vsx.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/80510] Optimize Power7/power8 Altivec load/stores

[meissner at gcc dot gnu.org]

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

--- Comment #4 from Michael Meissner  ---
Author: meissner
Date: Wed Jun 21 18:02:37 2017
New Revision: 249466

URL: https://gcc.gnu.org/viewcvs?rev=249466&root=gcc&view=rev
Log:
[gcc]
2017-06-21  Michael Meissner  

Back port from mainline
2017-05-19  Michael Meissner  

PR target/80718
* config/rs6000/vsx.md (vsx_splat_, VSX_D iterator): Prefer
VSX registers over GPRs, particularly on ISA 2.07 which does not
have the MTVSRDD instruction.

Back port from mainline
2017-05-18  Michael Meissner  

PR target/80510
* config/rs6000/predicates.md (simple_offsettable_mem_operand):
New predicate.

* config/rs6000/rs6000.md (ALTIVEC_DFORM): New iterator.
(define_peephole2 for Altivec d-form load): Add peepholes to catch
cases where the register allocator uses a move and an offsettable
memory operation to/from a FPR register on ISA 2.06/2.07.
(define_peephole2 for Altivec d-form store): Likewise.

Back port from mainline
2017-05-09  Michael Meissner  

PR target/68163
* config/rs6000/rs6000.md (f32_lr): Delete mode attributes that
are now unused after splitting mov{sf,sd}_hardfloat.
(f32_lr2): Likewise.
(f32_lm): Likewise.
(f32_lm2): Likewise.
(f32_li): Likewise.
(f32_li2): Likewise.
(f32_lv): Likewise.
(f32_sr): Likewise.
(f32_sr2): Likewise.
(f32_sm): Likewise.
(f32_sm2): Likewise.
(f32_si): Likewise.
(f32_si2): Likewise.
(f32_sv): Likewise.
(f32_dm): Likewise.
(f32_vsx): Likewise.
(f32_av): Likewise.
(mov_hardfloat): Split into separate movsf and movsd pieces.
For movsf, order stores so the VSX stores occur before the GPR
store which encourages the register allocator to use a traditional
FPR instead of a GPR.  For movsd, order the stores so that the GPR
store comes before the VSX stores to allow the power6 to work.
This is due to the power6 not having a 32-bit integer store
instruction from a FPR.
(movsf_hardfloat): Likewise.
(movsd_hardfloat): Likewise.

[gcc/testsuite]
2017-06-21  Michael Meissner  

Back port from mainline
2017-05-19  Michael Meissner  

PR target/80718
* gcc.target/powerpc/pr80718.c: New test.

Back port from mainline
2017-05-18  Michael Meissner  

PR target/80510
* gcc.target/powerpc/pr80510-1.c: New test.
* gcc.target/powerpc/pr80510-2.c: Likewise.

Back port from mainline
2017-05-09  Michael Meissner  

PR target/68163
* gcc.target/powerpc/pr68163.c: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr68163.c
  - copied unchanged from r249041,
trunk/gcc/testsuite/gcc.target/powerpc/pr68163.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr80510-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr80510-2.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr80718.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/predicates.md
branches/gcc-6-branch/gcc/config/rs6000/rs6000.md
branches/gcc-6-branch/gcc/config/rs6000/vsx.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/80718] GCC generates slow code for offsettable vec_duplicate

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #6 from Michael Meissner  ---
Fix back ported to gcc 7/6 branches.

[Bug target/68163] GCC on power8 does not issue the stxsspx instruction on power8

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #6 from Michael Meissner  ---
Patch applied to trunk, gcc 7, and gcc 6 branches.

[Bug target/81158] New: [8 regression] Many test case failures starting with r249424

[seurer at gcc dot gnu.org]

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

Bug ID: 81158
   Summary: [8 regression] Many test case failures starting with
r249424
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

The following tests are the ones that fail on powerpc64.  Most fail on just LE
but a few also fail on BE.

FAIL: gcc.c-torture/execute/pr51581-1.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gcc.c-torture/execute/pr51581-1.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/pr51581-2.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gcc.c-torture/execute/pr51581-2.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/pr53645.c   -O1  execution test
FAIL: gcc.c-torture/execute/pr53645.c   -O2  execution test
FAIL: gcc.c-torture/execute/pr53645.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.c-torture/execute/pr53645.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: gcc.c-torture/execute/pr53645.c   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gcc.c-torture/execute/pr53645.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/pr53645.c   -Os  execution test
FAIL: gcc.dg/vect/pr51581-1.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/pr51581-1.c execution test
FAIL: gcc.dg/vect/pr51581-2.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/pr51581-2.c execution test
FAIL: gcc.dg/vect/pr51581-3.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/pr51581-3.c execution test
FAIL: gcc.target/powerpc/builtins-3.c scan-assembler-times vmulesh 1
FAIL: gcc.target/powerpc/builtins-3.c scan-assembler-times vmuleuh 1
FAIL: gcc.target/powerpc/builtins-3.c scan-assembler-times vmulosh 1
FAIL: gcc.target/powerpc/builtins-3.c scan-assembler-times vmulouh 1
Note: builttin-3 also fails on BE
FAIL: libgomp.fortran/appendix-a/a.16.1.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test


>From looking at the failures it appears that array values are getting messed
up.


Looking at pr51581-1:

(gdb) run
Starting program: /home/seurer/gcc/build/gcc-test/pr51581-1.exe 

Program received signal SIGABRT, Aborted.
0x3fffb7d00a88 in __GI_raise (sig=) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) where
#0  0x3fffb7d00a88 in __GI_raise (sig=) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x3fffb7d0686c in __GI_abort () at abort.c:89
#2  0x1874 in main () at
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.c-torture/execute/pr51581-1.c:130


int
main ()
{
. . .
  for (i = 0; i < N; i++)
if (c[i] != a[i] / 3 || d[i] != b[i] / 3)
  abort ();  // line 130
. . .


Looking at pr53645:

(gdb) run
Starting program: /home/seurer/gcc/build/gcc-test/pr53645.exe 

Program received signal SIGABRT, Aborted.
0x3fffb7d00a88 in __GI_raise (sig=) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) where
#0  0x3fffb7d00a88 in __GI_raise (sig=) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x3fffb7d0686c in __GI_abort () at abort.c:89
#2  0x10001fc8 in main () at
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.c-torture/execute/pr53645.c:74



int
main ()
{
  UV ur, ur2;
  SV sr, sr2;
  int i;
#undef TEST
#define TEST(a, b, c, d)\
uq##a##b##c##d (&ur, u + i);\
if (ur[0] != u[i][0] / a || ur[3] != u[i][3] / d)   \
 abort ();  \
asm volatile ("" : : "r" (&ur) : "memory"); \
if (ur[2] != u[i][2] / c || ur[1] != u[i][1] / b)   \
 abort ();  \
asm volatile ("" : : "r" (&ur) : "memory"); \
ur##a##b##c##d (&ur, u + i);\
if (ur[0] != u[i][0] % a || ur[3] != u[i][3] % d)   \
 abort ();  \
asm volatile ("" : : "r" (&ur) : "memory"); \
if (ur[2] != u[i][2] % c || ur[1] != u[i][1] % b)   \
 abort ();  \
asm volatile ("" : : "r" (&ur) : "memory");
  for (i = 0; i < sizeof (u) / sizeof (u[0]); i++)
{
  TESTS  // Line 74
}




The last one fails with a segmentation fault:

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
FAIL: libgomp.fortran/appendix-a/a.16.1.f90   -O3 -g  execution test

[Bug c++/81154] OpenMP with shared variable in a template class crash

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jun 21 18:30:32 2017
New Revision: 249467

URL: https://gcc.gnu.org/viewcvs?rev=249467&root=gcc&view=rev
Log:
PR c++/81154
* semantics.c (handle_omp_array_sections_1, finish_omp_clauses):
Complain about t not being a variable if t is OVERLOAD even
when processing_template_decl.

* g++.dg/gomp/pr81154.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/gomp/pr81154.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/81094] -fsanitize=object-size does not instrument aggregate call arguments

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/46476] Missing Warning about unreachable code after return

[dcb314 at hotmail dot com]

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

--- Comment #16 from David Binderman  ---
(In reply to Manuel López-Ibáñez from comment #14)
> But the main barrier for this is not technical or acceptance, it is 
> leadership and human resources. 

And the usual time and money. There are plenty of static analysers out there.
Unless it is substantially better, why write another one ?

My favourite static analyser, cppcheck, says this for the original code:

$ ~/cppcheck/trunk/cppcheck --enable=all bug46476.cc
[bug46476.cc:5]: (style) Statements following return, break, continue, goto or
throw will never be executed.
[bug46476.cc:11]: (style) Statements following return, break, continue, goto or
throw will never be executed.
[bug46476.cc:8]: (style) The function 'bar' is never used.
[bug46476.cc:2]: (style) The function 'foo' is never used.
$

which pretty much does the job.

Running the same static analyser over the source code of a recent gcc
found 22 occurrences of this kind of problem.

Here they are:

$ fgrep "Statements following" cppcheck.20170617.out
[trunk/gcc/c/c-decl.c:3211]: (style) Statements following return, break,
continue, goto or throw will never be executed.
[trunk/gcc/fortran/arith.c:2009]: (style) Statements following return, break,
continue, goto or throw will never be executed.
[trunk/libbacktrace/dwarf.c:2709]: (style) Statements following return, break,
continue, goto or throw will never be executed.
[trunk/libbacktrace/dwarf.c:2758]: (style) Statements following return, break,
continue, goto or throw will never be executed.
[trunk/libbacktrace/dwarf.c:2892]: (style) Statements following return, break,
continue, goto or throw will never be executed.
[trunk/libbacktrace/dwarf.c:3025]: (style) Statements following return, break,
continue, goto or throw will never be executed.
[trunk/libbacktrace/elf.c:448]: (style) Statements following return, break,
continue, goto or throw will never be executed.
[trunk/libbacktrace/elf.c:493]: (style) Statements following return, break,
continue, goto or throw will never be executed.
[trunk/libbacktrace/elf.c:967]: (style) Statements following return, break,
continue, goto or throw will never be executed.
[trunk/libbacktrace/fileline.c:64]: (style) Statements following return, break,
continue, goto or throw will never be executed.
[trunk/libbacktrace/fileline.c:75]: (style) Statements following return, break,
continue, goto or throw will never be executed.
[trunk/libbacktrace/pecoff.c:499]: (style) Statements following return, break,
continue, goto or throw will never be executed.
[trunk/libbacktrace/pecoff.c:564]: (style) Statements following return, break,
continue, goto or throw will never be executed.
[trunk/libbacktrace/pecoff.c:931]: (style) Statements following return, break,
continue, goto or throw will never be executed.
[trunk/libcilkrts/runtime/cilk_fiber.cpp:968]: (style) Statements following
return, break, continue, goto or throw will never be executed.
[trunk/libcilkrts/runtime/scheduler.c:2468]: (style) Statements following
return, break, continue, goto or throw will never be executed.
[trunk/libcilkrts/runtime/scheduler.c:2550]: (style) Statements following
return, break, continue, goto or throw will never be executed.
[trunk/libcilkrts/runtime/scheduler.c:2439]: (style) Statements following
return, break, continue, goto or throw will never be executed.
[trunk/libffi/src/dlmalloc.c:3877]: (style) Statements following return, break,
continue, goto or throw will never be executed.
[trunk/libgomp/error.c:90]: (style) Statements following return, break,
continue, goto or throw will never be executed.
[trunk/libgomp/libgomp-plugin.c:79]: (style) Statements following return,
break, continue, goto or throw will never be executed.
[trunk/libobjc/error.c:41]: (style) Statements following return, break,
continue, goto or throw will never be executed.
$

Most of them seem to be in libbacktrace. I could look deeper into these
and generate some bug reports. That's the usual way to provoke gcc developers
into developing a new warning: show that the gcc source code would benefit
from it.

[Bug middle-end/78918] missing -Wrestrict on memcpy copying over self

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-21
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=35503
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
One reason for the missing warning in the test case in comment #0 is that GCC
built-ins aren't declared using the restrict qualifier.  In particular, both
memcpy and memmove are declared in builtins.def like so:

DEF_LIB_BUILTIN_CHKP   (BUILT_IN_MEMCPY, "memcpy",
BT_FN_PTR_PTR_CONST_PTR_SIZE, ATTR_RET1_NOTHROW_NONNULL_LEAF)
DEF_LIB_BUILTIN_CHKP   (BUILT_IN_MEMMOVE, "memmove",
BT_FN_PTR_PTR_CONST_PTR_SIZE, ATTR_RET1_NOTHROW_NONNULL_LEAF)

with BT_FN_PTR_PTR_CONST_PTR_SIZE specifying the same signature.  BT_PTR
expands to void_ptr_node, with no restrict qualifier.

The second reason is that the -Wrestrict warning is implemented in the
front-end, with no ability to determine relationships between distinct
pointers.  So while memcpy(p, p, n) is diagnosed (provided memcpy is declared
restrict), memcpy(p, q, n) is not.  That limitation limits the warning to just
the most basic and obvious cases, missing the more interesting problems.

Confirming on that basis.  Adding a reference to bug 35503 under which the
warning was implemented (in r242366).

[Bug middle-end/78918] missing -Wrestrict on memcpy copying over self

[fw at gcc dot gnu.org]

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

Florian Weimer  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=32667

--- Comment #3 from Florian Weimer  ---
PR32667 says that GCC itself uses memcpy with exact overlaps, so we probably
should not add restrict qualifiers until that is fixed.

[Bug ipa/81133] [8 Regression] PGO/LTO bootstrap: ICE: in inline_small_functions, at ipa-inline.c:1891

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #2 from Jan Hubicka  ---
I will take a look.

[Bug c++/81159] New: New warning idea: -Wself-move

[simon.marchi at polymtl dot ca]

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

Bug ID: 81159
   Summary: New warning idea: -Wself-move
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon.marchi at polymtl dot ca
  Target Milestone: ---

clang has this warning, -Wself-move, which warns about things like this:

  int a = 1;

  a = std::move (a);

I don't see any reason why code like this would be desirable, so any code that
ends up like this would likely be a mistake.  It would be nice to point it out.

Example output:

test.c:6:4: error: explicitly moving variable of type 'int' to itself
[-Werror,-Wself-move]
a = std::move(a);
~ ^   ~
1 error generated.

[Bug fortran/81160] New: arith.c:2009: bad statement order ?

[dcb314 at hotmail dot com]

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

Bug ID: 81160
   Summary: arith.c:2009: bad statement order ?
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

trunk/gcc/fortran/arith.c:2009]: (style) Statements following return, break,
continue, goto or throw will never be executed.

Source code is

static bool
wprecision_int_real (mpz_t n, mpfr_t r)
{
  mpz_t i;
  mpz_init (i);
  mpfr_get_z (i, r, GFC_RND_MODE);
  mpz_sub (i, i, n);
  return mpz_cmp_si (i, 0) != 0;
  mpz_clear (i);

}

Suggest either delete the mpz_clear or use it.

[Bug middle-end/81161] New: poor code concatenating bitfields

[nathan at gcc dot gnu.org]

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

Bug ID: 81161
   Summary: poor code concatenating bitfields
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at gcc dot gnu.org
  Target Milestone: ---

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

The example code is trying to use a set of adjacent single bit fields as a
wider value.  (Think TREE_LANG_FLAG_{N,N+2} to explain why I can't just make a
3-bit bitfield).  We don't spot this is just extrating a wider bitfield[*] 
here's the x86_64 code I get:
movzbl  (%rdi), %edx
movl%edx, %eax
movl%edx, %ecx
shrb$2, %dl
shrb$4, %al
shrb$3, %cl
andl$1, %edx
andl$1, %eax
andl$1, %ecx
sall$2, %eax
addl%ecx, %ecx
orl %ecx, %eax
orl %edx, %eax
ret

which is roughly doing:
   t1 = (val >> 2) & 1
   t2 = (val >> 3) & 1
   t3 = (val >> 4) & 1
   r = (t3 << 2) | (t2 + t1) | t1

optimal code would be something like:
   movzbl   (%rdi), %eax
   shrb $2,%al
   andl $7,%eax

this is similar to 68360, but looks sufficiently different to warrant a new
report.

[*] where bitfield packing was from the other end of the object, one might want
to swap the bitfields around to get a nice ordering.  Let's just assume
little-endian packing for the sake of argument.

[Bug fortran/81160] arith.c:2009: bad statement order ?

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-06-21
 CC||jvdelisle at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jerry DeLisle  ---
We probably should do:

static bool
wprecision_int_real (mpz_t n, mpfr_t r)
{
  bool result;
  mpz_t i;
  mpz_init (i);
  mpfr_get_z (i, r, GFC_RND_MODE);
  mpz_sub (i, i, n);
  result = mpz_cmp_si (i, 0) != 0;
  mpz_clear (i);
  return result;
}

I will check this further.

[Bug c/35503] Warning about restricted pointers?

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
I don't think the current implementation of the warning is prone to false
positives so it seems that it could safely be included it in -Wall. 
Unfortunately, the overly simplistic implementation makes it prone to many
false negatives (in fact, the warning detects only the most basic cases where
the pointer arguments are the same), making it useful for not much more than
demos.  To make it suitable for more than that it will need to be moved from
the front-end to the middle-end.

The request should probably also not be considered fully resolved until the
motivating example comment #0 (printf(buf, "%s-%s", buf, to_add)) is diagnosed.
 I think that should actually be fairly easily doable in the
gimple-ssa-sprintf.c pass.

[Bug libstdc++/80675] Incorrect implementation of LWG 2534

[ville at gcc dot gnu.org]

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

--- Comment #2 from ville at gcc dot gnu.org ---
Author: ville
Date: Wed Jun 21 19:53:26 2017
New Revision: 249468

URL: https://gcc.gnu.org/viewcvs?rev=249468&root=gcc&view=rev
Log:
PR libstdc++/80675, PR libstdc++/80940

* include/std/istream:
(__is_convertible_to_basic_istream_test(basic_istream<_Ch, _Up>*)): New.
(__do_is_convertible_to_basic_istream_impl): Likewise.
(__is_convertible_to_basic_istream_impl): Likewise.
(__is_convertible_to_basic_istream): Use the new base.
(__rvalue_istream_type): New.
(operator>>(_Istream&&, _Tp&&)): Use the new helper alias
for the SFINAE check, convert to the helper alias type before
doing the actual extraction.
* include/std/ostream:
(__is_convertible_to_basic_ostream_test(basic_ostream<_Ch, _Up>*)): New.
(__do_is_convertible_to_basic_ostream_impl): Likewise.
(__is_convertible_to_basic_ostream_impl): Likewise.
(__is_convertible_to_basic_ostream): Use the new base.
(__rvalue_ostream_type): New.
(operator<<(_Ostream&&, const _Tp&)): Use the new helper alias
for the SFINAE check, convert to the helper alias type before
doing the actual insertion.
* testsuite/27_io/rvalue_streams-2.cc: Add new tests.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/istream
trunk/libstdc++-v3/include/std/ostream
trunk/libstdc++-v3/testsuite/27_io/rvalue_streams-2.cc

[Bug libstdc++/80940] [7/8 Regression] Private inheritance from std::ostream - compilation error for custom operator <

[ville at gcc dot gnu.org]

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

--- Comment #2 from ville at gcc dot gnu.org ---
Author: ville
Date: Wed Jun 21 19:53:26 2017
New Revision: 249468

URL: https://gcc.gnu.org/viewcvs?rev=249468&root=gcc&view=rev
Log:
PR libstdc++/80675, PR libstdc++/80940

* include/std/istream:
(__is_convertible_to_basic_istream_test(basic_istream<_Ch, _Up>*)): New.
(__do_is_convertible_to_basic_istream_impl): Likewise.
(__is_convertible_to_basic_istream_impl): Likewise.
(__is_convertible_to_basic_istream): Use the new base.
(__rvalue_istream_type): New.
(operator>>(_Istream&&, _Tp&&)): Use the new helper alias
for the SFINAE check, convert to the helper alias type before
doing the actual extraction.
* include/std/ostream:
(__is_convertible_to_basic_ostream_test(basic_ostream<_Ch, _Up>*)): New.
(__do_is_convertible_to_basic_ostream_impl): Likewise.
(__is_convertible_to_basic_ostream_impl): Likewise.
(__is_convertible_to_basic_ostream): Use the new base.
(__rvalue_ostream_type): New.
(operator<<(_Ostream&&, const _Tp&)): Use the new helper alias
for the SFINAE check, convert to the helper alias type before
doing the actual insertion.
* testsuite/27_io/rvalue_streams-2.cc: Add new tests.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/istream
trunk/libstdc++-v3/include/std/ostream
trunk/libstdc++-v3/testsuite/27_io/rvalue_streams-2.cc

[Bug target/81151] -Wmaybe-uninitialized in insn-emit.c

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jun 21 20:02:00 2017
New Revision: 249469

URL: https://gcc.gnu.org/viewcvs?rev=249469&root=gcc&view=rev
Log:
PR target/81151
* config/i386/sse.md (round2): Renumber match_dup and
operands indexes to avoid gap between operands and match_dups.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md

[Bug c++/66639] declare __func__ , __FUNCTION__ & __PRETTY_FUNCTION__ as constexpr

[gcc at jonesmz dot com]

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

Michael Jones  changed:

   What|Removed |Added

 CC||gcc at jonesmz dot com

--- Comment #10 from Michael Jones  ---
Is there a work in progress patch available anywhere for this bug?

I have code that uses constexpr __PRETTY_FUNC__ with clang, and the equivalent
on Visual Studio 2015, and would like to patch my installation of GCC to
compile the same code.

[Bug middle-end/81161] poor code concatenating bitfields

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||18041

--- Comment #1 from Andrew Pinski  ---
More like PR 18041.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18041
[Bug 18041] OR of two single-bit bitfields is inefficient

[Bug middle-end/81161] poor code concatenating bitfields

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18041#c7 .

[Bug tree-optimization/35503] Warning about restricted pointers?

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|c   |tree-optimization

--- Comment #8 from Martin Sebor  ---
I'm testing a patch for the sprintf case.

[Bug target/80510] Optimize Power7/power8 Altivec load/stores

[meissner at gcc dot gnu.org]

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

--- Comment #5 from Michael Meissner  ---
Author: meissner
Date: Wed Jun 21 21:08:40 2017
New Revision: 249470

URL: https://gcc.gnu.org/viewcvs?rev=249470&root=gcc&view=rev
Log:
2017-06-21  Michael Meissner  

PR target/80510
* gcc.target/powerpc/pr80510-1.c: Restrict test to 64-bit until
32-bit support is added.  Change ITYPE size to 64-bit integer.
* gcc.target/powerpc/pr80510-2.c: Likewise.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/pr80510-1.c
trunk/gcc/testsuite/gcc.target/powerpc/pr80510-2.c

[Bug libstdc++/80940] [7/8 Regression] Private inheritance from std::ostream - compilation error for custom operator <

[ville at gcc dot gnu.org]

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

--- Comment #3 from ville at gcc dot gnu.org ---
Author: ville
Date: Wed Jun 21 21:09:46 2017
New Revision: 249471

URL: https://gcc.gnu.org/viewcvs?rev=249471&root=gcc&view=rev
Log:
PR libstdc++/80675, PR libstdc++/80940

Backport from mainline
2017-06-21  Ville Voutilainen  

PR libstdc++/80675
PR libstdc++/80940
* include/std/istream:
(__is_convertible_to_basic_istream_test(basic_istream<_Ch, _Up>*)): New.
(__do_is_convertible_to_basic_istream_impl): Likewise.
(__is_convertible_to_basic_istream_impl): Likewise.
(__is_convertible_to_basic_istream): Use the new base.
(__rvalue_istream_type): New.
(operator>>(_Istream&&, _Tp&&)): Use the new helper alias
for the SFINAE check, convert to the helper alias type before
doing the actual extraction.
* include/std/ostream:
(__is_convertible_to_basic_ostream_test(basic_ostream<_Ch, _Up>*)): New.
(__do_is_convertible_to_basic_ostream_impl): Likewise.
(__is_convertible_to_basic_ostream_impl): Likewise.
(__is_convertible_to_basic_ostream): Use the new base.
(__rvalue_ostream_type): New.
(operator<<(_Ostream&&, const _Tp&)): Use the new helper alias
for the SFINAE check, convert to the helper alias type before
doing the actual insertion.
* testsuite/27_io/rvalue_streams-2.cc: Add new tests.

Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/include/std/istream
branches/gcc-7-branch/libstdc++-v3/include/std/ostream
branches/gcc-7-branch/libstdc++-v3/testsuite/27_io/rvalue_streams-2.cc