[Bug c/76732] Improve Woverride-init

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

Summary|GCC should warn on repeated |Improve Woverride-init
   |initializer for same array  |
   |element / struct member.|
   Severity|normal  |enhancement

--- Comment #7 from Manuel López-Ibáñez  ---
> Surprised -Wall doesn't set -Woverride-init then; presume this was a
> conscious decision?

It is enabled by -Wextra. You can find the rationale here: PR24010

Clang warns by default.

[Bug c/76732] GCC should warn on repeated initializer for same array element / struct member.

[rusty at rustcorp dot com.au]

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

--- Comment #6 from rusty at rustcorp dot com.au ---
"manu at gcc dot gnu.org"  writes:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76732
>
> Manuel López-Ibáñez  changed:
>
>What|Removed |Added
> 
>  CC||manu at gcc dot gnu.org
>
> --- Comment #3 from Manuel López-Ibáñez  ---
> GCC already warns for this (for C)
>
> test.c:1:32: warning: initialized field overwritten [-Woverride-init]
>  int x[] = { [0] = 1, +3, [1] = 1 };

Ah, thanks!

Surprised -Wall doesn't set -Woverride-init then; presume this was a
conscious decision?

I'll add it to my CFLAGS.

Thanks again!
Rusty.

[Bug c++/77277] -fdiagnostics-color=always disabled on _WIN32

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-17
 CC||manu at gcc dot gnu.org
   Host||windows
Summary|-fdiagnostics-color=always  |-fdiagnostics-color=always
   |disabled on _WIN32 for no   |disabled on _WIN32
   |discernible reason  |
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
(In reply to Michael Bruck from comment #0)
> diagnostic-color.c completely disables colorization for the _WIN32 platform. 

The reason is that nobody among the current developers is using Windows AFAIK,
thus nobody so far has been interested in implementing (and testing) this.

If you are, please see: 

https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps

[Bug c++/77277] New: -fdiagnostics-color=always disabled on _WIN32 for no discernible reason

[bruck.michael at googlemail dot com]

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

Bug ID: 77277
   Summary: -fdiagnostics-color=always disabled on _WIN32 for no
discernible reason
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruck.michael at googlemail dot com
  Target Milestone: ---

diagnostic-color.c completely disables colorization for the _WIN32 platform. 

However both the most recent Windows 10 cmd.exe terminal as well as existing
terminal emulators available on older Windows versions fully support the Escape
sequences generated by gcc.

Proposal:
-fdiagnostics-color=always should always emit color codes

If isatty() is not reliable or unavailable on _WIN32 then should_colorize()
could be short-circuited to return false on _WIN32.

[Bug target/77276] New: strlen expanded inline with -Os, emits larger code than with -O2

[msebor at gcc dot gnu.org]

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

Bug ID: 77276
   Summary: strlen expanded inline with -Os, emits larger code
than with -O2
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

On x86_64 (but not on powerpc64le, for example), a call to __builtin_strlen
with a non-constant argument is expanded inline at -Os (as well as -Og and
-O1), but not at -O2 even though the size of the code emitted at -O2 is less
than that at -Os.

$ (set -x && cat xyz.c && for o in s 2; do /build/gcc-trunk-svn/gcc/xgcc -B
/build/gcc-trunk-svn/gcc -O$o -Wall -Wextra -c xyz.c && objdump -d xyz.o; done)
+ cat xyz.c
static const char* volatile s = "123";

unsigned f (void)
{
  return __builtin_strlen (s);
}
+ for o in s 2
+ /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -Os -Wall -Wextra
-c xyz.c
+ objdump -d xyz.o

xyz.o: file format elf64-x86-64


Disassembly of section .text:

 :
   0:   48 8b 3d 00 00 00 00mov0x0(%rip),%rdi# 7 
   7:   31 c0   xor%eax,%eax
   9:   48 83 c9 ff or $0x,%rcx
   d:   f2 ae   repnz scas %es:(%rdi),%al
   f:   48 89 c8mov%rcx,%rax
  12:   48 f7 d0not%rax
  15:   48 ff c8dec%rax
  18:   c3  retq   
+ for o in s 2
+ /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -O2 -Wall -Wextra
-c xyz.c
+ objdump -d xyz.o

xyz.o: file format elf64-x86-64


Disassembly of section .text:

 :
   0:   48 83 ec 08 sub$0x8,%rsp
   4:   48 8b 3d 00 00 00 00mov0x0(%rip),%rdi# b 
   b:   e8 00 00 00 00  callq  10 
  10:   48 83 c4 08 add$0x8,%rsp
  14:   c3  retq

[Bug fortran/67496] trans-array.c sanitizer runtime error: load of value 124, which is not a valid value for type 'bool'

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

Version|5.2.0   |7.0
   Severity|normal  |minor

[Bug fortran/67496] trans-array.c sanitizer runtime error: load of value 124, which is not a valid value for type 'bool'

[zeccav at gmail dot com]

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

--- Comment #11 from Vittorio Zecca  ---
Still in trunk 7.0

gcc-trunk-239276/gcc/fortran/trans-array.c:2243:27: runtime error: load of
value 48, which is not a valid value for type 'bool'

[Bug debug/67482] dwarf2out.c sanitizer detects undefined behaviour negation of -9223372036854775808

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

[Bug c++/77271] flag -std=c++98 cannot set _GLIBCXX_USE_CXX11_ABI properly

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|WONTFIX |INVALID

--- Comment #2 from Jonathan Wakely  ---
This isn't WONTFIX, it's just INVALID. The macro _GLIBCXX_USE_CXX11_ABI and the
-std option are supposed to be entirely independent.

This is documented at
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html

[Bug web/77275] Description of -l option refers only to static libraries, not dynamic/shared libraries

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Tom Payerle from comment #0)
> These should be corrected to include shared libraries, which may also be
> specified by the -l option.  It would probably be good to add something
> along the lines of how the compiler selects if multiple files matching ---

The compiler doesn't select anything, the linker does. GCC just passes the
option directly to the linker.

> my experience is .so files are preferred to .a, but not sure if all library
> directories are searched for .so, then all searched for .a, or if each
> library directory in order is searched for .so then .a.  Assuming the
> latter, something like
> 
> The linker searches a standard list of directories, in order, for the first
> matching shared library (actually a file named liblibrary.so) or standard
> library (actually a file named liblibrary.a) that is found.  If a matching
> shared library and static library are found in the same directory, the
> shared library is preferred.
> 

That's not entirely accurate, the precise semantics depend on the linker, which
is not part of GCC and varies from platform to platform.

> The second line could be changed to something like
> 
> The only difference between using an -l option and specifying a file name is
> that -l surrounds library with ‘lib’ and either '.so' and ‘.a’  and searches
> several directories
> 

Or .dylib, or other OS-specific extensions.

I think it would be better to just say the details depend on the linker.

[Bug tree-optimization/72817] [7 Regression] wrong code at -O3 on x86_64-linux-gnu (in both 32-bit and 64-bit modes)

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Tue Aug 16 22:06:45 2016
New Revision: 239514

URL: https://gcc.gnu.org/viewcvs?rev=239514=gcc=rev
Log:
PR tree-optimization/72817
* gcc.dg/tree-ssa/pr72817.c (a): Change type from char to signed char.

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

[Bug libgcc/77265] Casting an extended precision long double "inf" to __float128 results in "nan"

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #5 from Joseph S. Myers  ---
Fixed for GCC 7.

[Bug libgcc/77265] Casting an extended precision long double "inf" to __float128 results in "nan"

[jsm28 at gcc dot gnu.org]

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

--- Comment #4 from Joseph S. Myers  ---
Author: jsm28
Date: Tue Aug 16 21:30:56 2016
New Revision: 239513

URL: https://gcc.gnu.org/viewcvs?rev=239513=gcc=rev
Log:
Update soft-fp from glibc (PR libgcc/77265).

This patch updates soft-fp from glibc, bringing in the fix for PR
libgcc/77265, XFmode extension to TFmode wrongly turning an infinity
into a NaN.  A test for that bug is added.

Bootstrapped with no regressions on x86_64-pc-linux-gnu.

PR libgcc/77265
gcc/testsuite:
* gcc.dg/torture/float128-extend-inf.c: New test.

libgcc:
* soft-fp/adddf3.c: Update from glibc.
* soft-fp/addsf3.c: Likewise.
* soft-fp/addtf3.c: Likewise.
* soft-fp/divdf3.c: Likewise.
* soft-fp/divsf3.c: Likewise.
* soft-fp/divtf3.c: Likewise.
* soft-fp/double.h: Likewise.
* soft-fp/eqdf2.c: Likewise.
* soft-fp/eqsf2.c: Likewise.
* soft-fp/eqtf2.c: Likewise.
* soft-fp/extenddftf2.c: Likewise.
* soft-fp/extended.h: Likewise.
* soft-fp/extendsfdf2.c: Likewise.
* soft-fp/extendsftf2.c: Likewise.
* soft-fp/extendxftf2.c: Likewise.
* soft-fp/fixdfdi.c: Likewise.
* soft-fp/fixdfsi.c: Likewise.
* soft-fp/fixdfti.c: Likewise.
* soft-fp/fixsfdi.c: Likewise.
* soft-fp/fixsfsi.c: Likewise.
* soft-fp/fixsfti.c: Likewise.
* soft-fp/fixtfdi.c: Likewise.
* soft-fp/fixtfsi.c: Likewise.
* soft-fp/fixtfti.c: Likewise.
* soft-fp/fixunsdfdi.c: Likewise.
* soft-fp/fixunsdfsi.c: Likewise.
* soft-fp/fixunsdfti.c: Likewise.
* soft-fp/fixunssfdi.c: Likewise.
* soft-fp/fixunssfsi.c: Likewise.
* soft-fp/fixunssfti.c: Likewise.
* soft-fp/fixunstfdi.c: Likewise.
* soft-fp/fixunstfsi.c: Likewise.
* soft-fp/fixunstfti.c: Likewise.
* soft-fp/floatdidf.c: Likewise.
* soft-fp/floatdisf.c: Likewise.
* soft-fp/floatditf.c: Likewise.
* soft-fp/floatsidf.c: Likewise.
* soft-fp/floatsisf.c: Likewise.
* soft-fp/floatsitf.c: Likewise.
* soft-fp/floattidf.c: Likewise.
* soft-fp/floattisf.c: Likewise.
* soft-fp/floattitf.c: Likewise.
* soft-fp/floatundidf.c: Likewise.
* soft-fp/floatundisf.c: Likewise.
* soft-fp/floatunditf.c: Likewise.
* soft-fp/floatunsidf.c: Likewise.
* soft-fp/floatunsisf.c: Likewise.
* soft-fp/floatunsitf.c: Likewise.
* soft-fp/floatuntidf.c: Likewise.
* soft-fp/floatuntisf.c: Likewise.
* soft-fp/floatuntitf.c: Likewise.
* soft-fp/gedf2.c: Likewise.
* soft-fp/gesf2.c: Likewise.
* soft-fp/getf2.c: Likewise.
* soft-fp/ledf2.c: Likewise.
* soft-fp/lesf2.c: Likewise.
* soft-fp/letf2.c: Likewise.
* soft-fp/muldf3.c: Likewise.
* soft-fp/mulsf3.c: Likewise.
* soft-fp/multf3.c: Likewise.
* soft-fp/negdf2.c: Likewise.
* soft-fp/negsf2.c: Likewise.
* soft-fp/negtf2.c: Likewise.
* soft-fp/op-1.h: Likewise.
* soft-fp/op-2.h: Likewise.
* soft-fp/op-4.h: Likewise.
* soft-fp/op-8.h: Likewise.
* soft-fp/op-common.h: Likewise.
* soft-fp/quad.h: Likewise.
* soft-fp/single.h: Likewise.
* soft-fp/soft-fp.h: Likewise.
* soft-fp/subdf3.c: Likewise.
* soft-fp/subsf3.c: Likewise.
* soft-fp/subtf3.c: Likewise.
* soft-fp/truncdfsf2.c: Likewise.
* soft-fp/trunctfdf2.c: Likewise.
* soft-fp/trunctfsf2.c: Likewise.
* soft-fp/trunctfxf2.c: Likewise.
* soft-fp/unorddf2.c: Likewise.
* soft-fp/unordsf2.c: Likewise.
* soft-fp/unordtf2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/torture/float128-extend-inf.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgcc/ChangeLog
trunk/libgcc/soft-fp/adddf3.c
trunk/libgcc/soft-fp/addsf3.c
trunk/libgcc/soft-fp/addtf3.c
trunk/libgcc/soft-fp/divdf3.c
trunk/libgcc/soft-fp/divsf3.c
trunk/libgcc/soft-fp/divtf3.c
trunk/libgcc/soft-fp/double.h
trunk/libgcc/soft-fp/eqdf2.c
trunk/libgcc/soft-fp/eqsf2.c
trunk/libgcc/soft-fp/eqtf2.c
trunk/libgcc/soft-fp/extenddftf2.c
trunk/libgcc/soft-fp/extended.h
trunk/libgcc/soft-fp/extendsfdf2.c
trunk/libgcc/soft-fp/extendsftf2.c
trunk/libgcc/soft-fp/extendxftf2.c
trunk/libgcc/soft-fp/fixdfdi.c
trunk/libgcc/soft-fp/fixdfsi.c
trunk/libgcc/soft-fp/fixdfti.c
trunk/libgcc/soft-fp/fixsfdi.c
trunk/libgcc/soft-fp/fixsfsi.c
trunk/libgcc/soft-fp/fixsfti.c
trunk/libgcc/soft-fp/fixtfdi.c
trunk/libgcc/soft-fp/fixtfsi.c
trunk/libgcc/soft-fp/fixtfti.c
trunk/libgcc/soft-fp/fixunsdfdi.c
trunk/libgcc/soft-fp/fixunsdfsi.c
trunk/libgcc/soft-fp/fixunsdfti.c
trunk/libgcc/soft-fp/fixunssfdi.c

[Bug tree-optimization/72817] [7 Regression] wrong code at -O3 on x86_64-linux-gnu (in both 32-bit and 64-bit modes)

[seurer at linux dot vnet.ibm.com]

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

Bill Seurer  changed:

   What|Removed |Added

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

--- Comment #5 from Bill Seurer  ---
The new test case pr72817.c hangs on powerpc both BE and LE

Executing on host: /home/seurer/gcc/build/gcc-trunk/gcc/xgcc
-B/home/seurer/gcc/build/gcc-trunk/gcc/
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/pr72817.c 
-fno-diagnostics-show-caret -fdiagnostics-color=never   -O3  -lm-o
./pr72817.exe(timeout = 300)
spawn /home/seurer/gcc/build/gcc-trunk/gcc/xgcc
-B/home/seurer/gcc/build/gcc-trunk/gcc/
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/pr72817.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O3 -lm -o ./pr72817.exe
PASS: gcc.dg/tree-ssa/pr72817.c (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/build/gcc-trunk/gcc::/home/seurer/gcc/build/gcc-trunk/gcc:/home/wschmidt/gcc/install/gcc-5_1/lib64
spawn [open ...]
WARNING: program timed out.
FAIL: gcc.dg/tree-ssa/pr72817.c execution test
testcase /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/tree-ssa/tree-ssa.exp
completed in 301 seconds

[Bug web/77275] New: Description of -l option refers only to static libraries, not dynamic/shared libraries

[payerle at umd dot edu]

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

Bug ID: 77275
   Summary: Description of -l option refers only to static
libraries, not dynamic/shared libraries
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: payerle at umd dot edu
  Target Milestone: ---

Referring to
https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#Link-Options
and all the other places that occurs.  Issue seems to go back to at least to
gcc 4.4.7

In particular, in the description of the -l option, there is text


The linker searches a standard list of directories for the library, which is
actually a file named liblibrary.a
 

and


The only difference between using an -l option and specifying a file name is
that -l surrounds library with ‘lib’ and ‘.a’ and searches several directories.


These should be corrected to include shared libraries, which may also be
specified by the -l option.  It would probably be good to add something along
the lines of how the compiler selects if multiple files matching --- my
experience is .so files are preferred to .a, but not sure if all library
directories are searched for .so, then all searched for .a, or if each library
directory in order is searched for .so then .a.  Assuming the latter, something
like

The linker searches a standard list of directories, in order, for the first
matching shared library (actually a file named liblibrary.so) or standard
library (actually a file named liblibrary.a) that is found.  If a matching
shared library and static library are found in the same directory, the shared
library is preferred.


The second line could be changed to something like

The only difference between using an -l option and specifying a file name is
that -l surrounds library with ‘lib’ and either '.so' and ‘.a’  and searches
several directories


The text re handling archive files probably also needs to be updating to
mentioned shared object files, but my lack of expertise makes me reluctant to
even attempt to fix that.

[Bug c++/77274] New: GCC uses copy constructor in member initializer list instead of simple initialization

[yanp.bugz at gmail dot com]

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

Bug ID: 77274
   Summary: GCC uses copy constructor in member initializer list
instead of simple initialization
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yanp.bugz at gmail dot com
  Target Milestone: ---

Code example:

struct C{
static int count;
C(int, int) {count++;}
};

#define BUG

struct C1{
static int count;
explicit C1() {count++;}
C1(const C1& ) 
#ifdef BUG
= delete;
#else
{
cout<<"copy ctor\n";
count++;
}
C1(C1&& ) {
cout<<"move ctor\n";
count++;
}
#endif
};

struct D{
D() : c(C(2,3)), cc(3,4) c1(C1()) {}
C c, cc;
C1 c1;
};

Compiler gives you error:
new.cxx: In constructor ‘D::D()’:
new.cxx:79:35: error: use of deleted function ‘C1::C1(const C1&)’
  D() : c(C(2,3)), cc(3,4), c1(C1()) {}
   ^
new.cxx:63:2: note: declared here
  C1(const C1& ) 
  ^

However if you undef BUG you will notice that none of copy/move ctors were
called

[Bug middle-end/68733] [6/7 Regression] FAIL: libgomp.c/target-29.c (internal compiler error)

[deller at gmx dot de]

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

deller at gmx dot de changed:

   What|Removed |Added

 CC||deller at gmx dot de

--- Comment #5 from deller at gmx dot de ---
Seems the problem still exists with gcc-6.1:
https://buildd.debian.org/status/fetch.php?pkg=cdo=hppa=1.7.2%2Bdfsg.1-1=1471364161

[Bug fortran/77260] bogus warning with ENTRY in a function

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-16
 Ever confirmed|0   |1
   Severity|normal  |minor

--- Comment #1 from kargl at gcc dot gnu.org ---
Patch submitted.

[Bug c++/72104] Inner templated class with stream operator fails to compile

[romain.geissler at amadeus dot com]

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

Romain Geissler  changed:

   What|Removed |Added

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

--- Comment #4 from Romain Geissler  ---
Ok, thanks for the reply.

[Bug rtl-optimization/71336] Suboptimal x86 code generated for "(a & 1) ? (CST1 + CST2) : CST1"

[ppalka at gcc dot gnu.org]

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

--- Comment #4 from Patrick Palka  ---
On a related note I noticed the final code for

int test(int a) {
return (a & CST) * 4 + 3;
}

is not optimal when CST is a power of two, e.g. when CST=8:

_Z4testi:
.LFB0:
.cfi_startproc
andl$8, %edi
leal0(,%rdi,4), %eax
addl$3, %eax
ret

The leal and the addl could be combined into a single leal.  When CST is not a
power of two then there is no addl.

[Bug middle-end/77270] Flag -mprftchw is shared with 3dnow for -march=k8

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
The problem is in the fact that for -march=native, the driver will pass
-mno-prfchw, since the relevant bit is not present in cpuid flags.

Following code in i386.c:

  /* Enable prefetch{,w} instructions for -m3dnow and -mprefetchwt1.  */
  if (TARGET_3DNOW_P (opts->x_ix86_isa_flags)
  || TARGET_PREFETCHWT1_P (opts->x_ix86_isa_flags))
opts->x_ix86_isa_flags
  |= OPTION_MASK_ISA_PRFCHW & ~opts->x_ix86_isa_flags_explicit;

will then try to set the option, but it won't succeed, due to the above
handling of explicit compile flags.

[Bug c/72857] incorrect caret location in -Wformat for width and precision given by asterisk

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Should be fixed as of r239510.

[Bug c/72857] incorrect caret location in -Wformat for width and precision given by asterisk

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Author: dmalcolm
Date: Tue Aug 16 18:19:34 2016
New Revision: 239510

URL: https://gcc.gnu.org/viewcvs?rev=239510=gcc=rev
Log:
Fix caret locations in format_type_warning (PR c/72857)

gcc/c-family/ChangeLog:
PR c/72857
* c-common.c (substring_loc::get_range): Rename to...
(substring_loc::get_location): ...this, converting param from a
source_range * to a location_t *.  Call
get_source_location_for_substring rather than
get_source_range_for_substring, and pass in m_caret_idx.
* c-common.h (substring_loc::substring_loc): Add param "caret_idx".
(substring_loc::get_range): Replace with...
(substring_loc::get_location): ...this.
(substring_loc::set_caret_index): New method.
(substring_loc): Add field m_caret_idx.
* c-format.c (format_warning_va): Update for above changes.
Rename local "substring_loc" to "fmt_substring_loc" to avoid
clashing with type name.
(format_warning_at_char): Add caret_idx param to substring_loc ctor.
(check_argument_type): Likewise.
(format_type_warning): Rename param "fmt_loc" to "whole_fmt_loc"
Use a copy when emitting warnings, setting the caret index from TYPE.

gcc/ChangeLog:
PR c/72857
* input.c (get_source_range_for_substring): Rename to...
(get_source_location_for_substring): ...this, adding param
"caret_idx", and converting output param from source_range * to
location_t *.
(get_source_range_for_char): New function.
(get_num_source_ranges_for_substring): Update comment to reflect
above renaming.
(assert_char_at_range): Update to use get_source_range_for_char
rather than get_source_range_for_substring.
(test_lexer_string_locations_concatenation_2): Likewise.
* substring-locations.h (get_source_range_for_substring): Rename
to...
(get_source_location_for_substring): ...this, and adding param
"caret_idx", and converting output param from source_range * to
location_t *.

gcc/testsuite/ChangeLog:
PR c/72857
* gcc.dg/format/asm_fprintf-1.c: Restore column numbers
for embedded NUL.
* gcc.dg/format/c90-printf-1.c: Restore column numbers.
* gcc.dg/format/diagnostic-ranges.c (test_hex): Update expected
caret placement.
(test_oct): Likewise.
(test_multiple): Likewise.
(test_field_width_specifier): Likewise.
(test_field_width_specifier_2): New function.
(test_field_precision_specifier): New function.
(test_embedded_nul): Update expected caret placement.
(test_non_contiguous_strings): Update line number.
* gcc.dg/plugin/diagnostic-test-string-literals-1.c
(__emit_string_literal_range): Add "caret_idx" param.
(test_simple_string_literal): Add value for new param, updating
expected output..
(test_concatenated_string_literal): Likewise.
(test_multiline_string_literal): Likewise.
(test_hex): Likewise.
(test_oct): Likewise.
(test_multiple): Likewise.
(test_ucn4): Likewise.
(test_ucn8): Likewise.
(test_u8): Likewise.
(test_u): Likewise; update expected message, from "range" to
"location".
(test_U): Likewise.
(test_L): Likewise.
(test_macro): Add value for new param.
* gcc.dg/plugin/diagnostic-test-string-literals-2.c
(__emit_string_literal_range): Add "caret_idx" param.
(test_stringified_token_1): Add value for new param.  Update
expected message, from "range" to "location".
(test_stringized_token_2): Likewise, adding param to macro.
(test_stringified_token_3): Likewise.
* gcc.dg/plugin/diagnostic_plugin_test_string_literals.c
(emit_warning): Convert param from source_range to location_t.
(test_string_literals): Add caret_idx param, and use it when
constructing a substring_loc.  Update error message, from
"range" to "location".


Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-common.h
trunk/gcc/c-family/c-format.c
trunk/gcc/input.c
trunk/gcc/substring-locations.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/format/asm_fprintf-1.c
trunk/gcc/testsuite/gcc.dg/format/c90-printf-1.c
trunk/gcc/testsuite/gcc.dg/format/diagnostic-ranges.c
trunk/gcc/testsuite/gcc.dg/plugin/diagnostic-test-string-literals-1.c
trunk/gcc/testsuite/gcc.dg/plugin/diagnostic-test-string-literals-2.c
trunk/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_test_string_literals.c

[Bug libgcc/77273] New: 1 << 31 is undefined in gcc/config/i386/cpuid.h:93

[zeccav at gmail dot com]

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

Bug ID: 77273
   Summary: 1 << 31 is undefined in gcc/config/i386/cpuid.h:93
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

While compiling gcc itself, the sanitizer complains as follows:

gcc-trunk-239276/libgcc/config/i386/cpuinfo.c:346:17: runtime error: left shift
of 1 by 31 places cannot be represented in type 'int'

cpuinfo.c:346 is "if (ebx & bit_AVX512VL)"

bit_AVX512VL is defined in cpuid.h:249 as

#define bit_AVX512VL(1 << 31)

I believe 1 << 31 is undefined, because "1" is int,
it should be 1u << 31 or 1U << 31

cpuid.h:66 is "#define bit_3DNOW   (1 << 31)" by the way

[Bug c++/77271] flag -std=c++98 cannot set _GLIBCXX_USE_CXX11_ABI properly

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Andrew Pinski  ---
This is expected and was a known breakage in the abi. It was designed so that
libstdc++ abi would backwards compatible but not libraries which used the newer
gcc.

[Bug middle-end/77270] Flag -mprftchw is shared with 3dnow for -march=k8

[nightstrike at gmail dot com]

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

nightstrike  changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #1 from nightstrike  ---
This should trigger the prefetchw instruction with -march=k8 -O3:

void f() {
extern int size;
int i;

float * fvec;
float * fptr = (float *) get();
for(i = 0; i < size; ++i)
fvec[i] = fptr[i];

int * ivec;
int * iptr = (int *) get();
for(i = 0; i < size; ++i)
ivec[i] = iptr[i];
}


If I give an "extern void * get()" prototype for get, if there's only one
vector loop, or if size is local, the prefetchw instruction goes away.

$ gcc -fverbose-asm -S a.c -march=k8 -O3; grep prefetchw a.s
prefetchw   464(%rcx)   #
prefetchw   (%rdx)  # ivtmp.37

[Bug c++/77271] New: flag -std=c++98 cannot set _GLIBCXX_USE_CXX11_ABI properly

[frast at mail dot spbnit.ru]

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

Bug ID: 77271
   Summary: flag -std=c++98 cannot set _GLIBCXX_USE_CXX11_ABI
properly
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frast at mail dot spbnit.ru
  Target Milestone: ---

I have a library compiled by previous version of G++ with default -std=c++98

Building an executable with default flags for 4.8.5 produces unresolved
symbols:
. undefined reference to
`libebml::EbmlString::operator=(std::__cxx11::basic_string const&)'

The problem has been resolved by adding -std=c++98 flag.

The same problem has been detected with gcc version 5.4.0 20160609 (Ubuntu
5.4.0-6ubuntu1~16.04.2)

My investigation of the problem shows, that the problem in the file
/usr/include/x86_64-linux-gnu/c++/5.4.0/bits/c++config.h
lines 194-234
=== cut ===
namespace std
{
  typedef __SIZE_TYPE__ size_t;
  typedef __PTRDIFF_TYPE__  ptrdiff_t;

#if __cplusplus >= 201103L
  typedef decltype(nullptr) nullptr_t;
#endif
}

# define _GLIBCXX_USE_DUAL_ABI 1

#if ! _GLIBCXX_USE_DUAL_ABI
// Ignore any pre-defined value of _GLIBCXX_USE_CXX11_ABI
# undef _GLIBCXX_USE_CXX11_ABI
#endif

#ifndef _GLIBCXX_USE_CXX11_ABI
# define _GLIBCXX_USE_CXX11_ABI 1
#endif

#if _GLIBCXX_USE_CXX11_ABI
namespace std
{
  inline namespace __cxx11 __attribute__((__abi_tag__ ("cxx11"))) { }
}
namespace __gnu_cxx
{
  inline namespace __cxx11 __attribute__((__abi_tag__ ("cxx11"))) { }
}
# define _GLIBCXX_NAMESPACE_CXX11 __cxx11::
# define _GLIBCXX_BEGIN_NAMESPACE_CXX11 namespace __cxx11 {
# define _GLIBCXX_END_NAMESPACE_CXX11 }
# define _GLIBCXX_DEFAULT_ABI_TAG _GLIBCXX_ABI_TAG_CXX11
#else
# define _GLIBCXX_NAMESPACE_CXX11
# define _GLIBCXX_BEGIN_NAMESPACE_CXX11
# define _GLIBCXX_END_NAMESPACE_CXX11
# define _GLIBCXX_DEFAULT_ABI_TAG
#endif
=== end cut ===

Independent of the key '-std=' this file sets to _GLIBCXX_USE_CXX11_ABI = 1

I have fixed this problem by using '-std=c++98 -D_GLIBCXX_USE_CXX11_ABI=0'

But probably it will be better apply a patch for all comunity

=== cut ===
***
***
*** 207,215 
  // Ignore any pre-defined value of _GLIBCXX_USE_CXX11_ABI
  # undef _GLIBCXX_USE_CXX11_ABI
  #endif

! #ifndef _GLIBCXX_USE_CXX11_ABI
  # define _GLIBCXX_USE_CXX11_ABI 1
  #endif

  #if _GLIBCXX_USE_CXX11_ABI
--- 207,217 
  // Ignore any pre-defined value of _GLIBCXX_USE_CXX11_ABI
  # undef _GLIBCXX_USE_CXX11_ABI
  #endif

! #if __cplusplus < 201103L
! # define _GLIBCXX_USE_CXX11_ABI 0
! #elif ! defined(_GLIBCXX_USE_CXX11_ABI)
  # define _GLIBCXX_USE_CXX11_ABI 1
  #endif
=== end cut ===

Thanks.

[Bug fortran/71902] [5/6/7 Regression] Unneeded temporary on reallocatable character assignment

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2016-08/msg01076.ht
   ||ml

--- Comment #8 from Thomas Koenig  ---
Patch at https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01076.html .

[Bug target/71910] ICE on valid OpenMP code

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Tue Aug 16 16:50:47 2016
New Revision: 239508

URL: https://gcc.gnu.org/viewcvs?rev=239508=gcc=rev
Log:
PR target/71910
* tree-cfg.c (execute_fixup_cfg): Add node variable, use it.  Before
inlining,
add cgraph edge for the added __builtin_unreachable call.

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

Added:
trunk/gcc/testsuite/g++.dg/gomp/pr71910.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfg.c

[Bug middle-end/67485] expmed.c sanitizer detects overflow

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Aug 16 16:48:16 2016
New Revision: 239507

URL: https://gcc.gnu.org/viewcvs?rev=239507=gcc=rev
Log:
PR middle-end/67485
* expmed.c (expand_mult_const): Change val_so_far's type to UHWI,
only cast it to SHWI for the final comparison.

* gcc.c-torture/compile/pr67485.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr67485.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expmed.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/77270] New: Flag -mprftchw is shared with 3dnow for -march=k8

[nightstrike at gmail dot com]

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

Bug ID: 77270
   Summary: Flag -mprftchw is shared with 3dnow for -march=k8
   Product: gcc
   Version: 6.1.0
   URL: https://gcc.gnu.org/ml/gcc/2016-05/msg0.html
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
CC: ubizjak at gmail dot com, venkataramanan.kumar at amd dot 
com
  Target Milestone: ---

See https://gcc.gnu.org/ml/gcc/2016-05/msg0.html

Using -march=native on a k8 platform does not add -mprfchw to the options list,
while using -march=k8 on a different platform does add the switch.

From Venkataramanan:

>   3DNow! instruction extensions = true
>   3DNow! instructions   = true

It has 3Dnow support.  "prefetchw" is available with 3dnow.

>   misaligned SSE mode= false
>   3DNow! PREFETCH/PREFETCHW instructions = false

It does not have 3DNowprefetch enabling ISA flag -mprftchw is not correct for
-march=k8.

>   OS visible workaround  = false
>   instruction based sampling = false

I think  we need to file bug for this.  Need to check with Uros why the flag
-mprfchw is shared with 3dnow.

To work around this issue you can use -mno-prfchw when building with -march=k8.

[Bug target/72867] SSE/AVX/AVX512: incorrect optimization of VMINPS/VMAXPS at compile time

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Aug 16 16:23:46 2016
New Revision: 239505

URL: https://gcc.gnu.org/viewcvs?rev=239505=gcc=rev
Log:
PR target/72867
* gcc.target/i386/pr72867.c: Add -msse to dg-options.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr72867.c

[Bug tree-optimization/77269] New: __builtin_isinf_sign does not work for __float128

[jsm28 at gcc dot gnu.org]

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

Bug ID: 77269
   Summary: __builtin_isinf_sign does not work for __float128
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: murphyp at linux dot vnet.ibm.com
  Target Milestone: ---

The __builtin_isinf_sign folding does

tree signbit_fn = mathfn_built_in_1
  (TREE_TYPE (arg), CFN_BUILT_IN_SIGNBIT, 0);

which only works for float, double and long double.  This means that despite
both __builtin_isinf and (since the fix for bug 36757) __builtin_signbit being
type-generic and so working for other floating-point types such as __float128
without needing any type-specific variants of the built-in functions to exist
for those types, __builtin_isinf_sign does not; instead, you get undefined
references to __builtin_isinf_sign at link time if you call it for __float128
arguments.

E.g., on x86_64,

int f (__float128 a) { return __builtin_isinf_sign (a); }

generates a call to __builtin_isinf_sign, when it should be expanded inline
even for -O0 (and glibc currently expects to be able to use
__builtin_isinf_sign in defining the isinf macro).

[Bug libstdc++/77268] Vector erase call destructor for last element twice and doesn't call destructor for eased element.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Your test is completely broken, you need to define copy assignment operator to
prevent two objects referring to the same pointer (and deleting it twice).

[Bug libstdc++/77268] New: Vector erase call destructor for last element twice and doesn't call destructor for eased element.

[jdinardo at nycap dot rr.com]

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

Bug ID: 77268
   Summary: Vector erase call destructor for last element twice
and doesn't call destructor for eased element.
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jdinardo at nycap dot rr.com
  Target Milestone: ---

Created attachment 39465
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39465=edit
Small  33 line program which shows the problem.

Vector erase is asked to erase 3rd element of 5 element vector. The
destructor for the last(fifth) element is called twice and the destructor
for the 3rd element is not called. The 3rd element is erased but the malloced
memory is never freed. BUG 47305 seems to imply that this is ok. If that is the
case, then pleas ignore this.

VERSION - g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr
--libdir=/usr/li
Thread model: posix
gcc version 6.1.1 20160802 (GCC)

System is Arch Linux

MAKEFILE
CPPFLAGS=-g -Wall -lfltk
ALL:hello t1 v1

MAKEFILE OUTPUT - no warnings or errors
g++  -g -Wall -lfltk   v1.cc   -o v1

COMMAND LINE
v1

SMALL 33 LINE TEST PROGRAM 
Included as attachment

[Bug target/32187] Complex __float128 is rejected

[emsr at gcc dot gnu.org]

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

--- Comment #10 from emsr at gcc dot gnu.org ---
Author: emsr
Date: Tue Aug 16 14:56:55 2016
New Revision: 239504

URL: https://gcc.gnu.org/viewcvs?rev=239504=gcc=rev
Log:
Commit Joseph Myers Implement C _FloatN, _FloatNx types [version 5] to the
branch.
This is to test impact on my use of __float128 and comlex.
gcc:
2016-07-22  Joseph Myers  

PR c/32187
* tree-core.h (TI_COMPLEX_FLOAT16_TYPE)
(TI_COMPLEX_FLOATN_NX_TYPE_FIRST, TI_COMPLEX_FLOAT32_TYPE)
(TI_COMPLEX_FLOAT64_TYPE, TI_COMPLEX_FLOAT128_TYPE)
(TI_COMPLEX_FLOAT32X_TYPE, TI_COMPLEX_FLOAT64X_TYPE)
(TI_COMPLEX_FLOAT128X_TYPE, TI_FLOAT16_TYPE, TI_FLOATN_TYPE_FIRST)
(TI_FLOATN_NX_TYPE_FIRST, TI_FLOAT32_TYPE, TI_FLOAT64_TYPE)
(TI_FLOAT128_TYPE, TI_FLOATN_TYPE_LAST, TI_FLOAT32X_TYPE)
(TI_FLOATNX_TYPE_FIRST, TI_FLOAT64X_TYPE, TI_FLOAT128X_TYPE)
(TI_FLOATNX_TYPE_LAST, TI_FLOATN_NX_TYPE_LAST): New enum
tree_index values.
(NUM_FLOATN_TYPES, NUM_FLOATNX_TYPES, NUM_FLOATN_NX_TYPES): New
macros.
(struct floatn_type_info): New structure type.
(floatn_nx_types): New variable declaration.
* tree.h (FLOATN_TYPE_NODE, FLOATN_NX_TYPE_NODE)
(FLOATNX_TYPE_NODE, float128_type_node, float64x_type_node)
(COMPLEX_FLOATN_NX_TYPE_NODE): New macros.
* tree.c (floatn_nx_types): New variable.
(build_common_tree_nodes): Initialize _FloatN, _FloatNx and
corresponding complex types.
* target.def (floatn_mode): New hook.
* targhooks.c: Include "real.h".
(default_floatn_mode): New function.
* targhooks.h (default_floatn_mode): New prototype.
* doc/extend.texi (Floating Types): Document _FloatN and _FloatNx
types.
* doc/sourcebuild.texi (float@var{n}, float@var{n}x): Document new
effective-target keywords.
* doc/tm.texi.in (TARGET_FLOATN_MODE): New @hook.
* doc/tm.texi: Regenerate.
* ginclude/float.h (LDBL_DECIMAL_DIG): Define to
__LDBL_DECIMAL_DIG__, not __DECIMAL_DIG__.
[__STDC_WANT_IEC_60559_TYPES_EXT__]: Define macros from TS
18661-3.
* real.h (struct real_format): Add field ieee_bits.
* real.c (ieee_single_format, mips_single_format)
(motorola_single_format, spu_single_format, ieee_double_format)
(mips_double_format, motorola_double_format)
(ieee_extended_motorola_format, ieee_extended_intel_96_format)
(ieee_extended_intel_128_format)
(ieee_extended_intel_96_round_53_format, ibm_extended_format)
(mips_extended_format, ieee_quad_format, mips_quad_format)
(vax_f_format, vax_d_format, vax_g_format, decimal_single_format)
(decimal_double_format, decimal_quad_format, ieee_half_format)
(arm_half_format, real_internal_format: Initialize ieee_bits
field.
* config/i386/i386.c (ix86_init_builtin_types): Do not initialize
float128_type_node.  Set float80_type_node to float64x_type_node
if appropriate and long_double_type_node not appropriate.
* config/ia64/ia64.c (ia64_init_builtins): Likewise.
* config/pdp11/pdp11.c (pdp11_f_format, pdp11_d_format):
Initialize ieee_bits field.
* config/rs6000/rs6000.c (TARGET_FLOATN_MODE): New macro.
(rs6000_init_builtins): Set ieee128_float_type_node to
float128_type_node.
(rs6000_floatn_mode): New function.

gcc/c:
2016-07-22  Joseph Myers  

PR c/32187
* c-tree.h (cts_floatn_nx): New enum c_typespec_keyword value.
(struct c_declspecs): Add field floatn_nx_idx.
* c-decl.c (declspecs_add_type, finish_declspecs): Handle _FloatN
and _FloatNx type specifiers.
* c-parser.c (c_keyword_starts_typename, c_token_starts_declspecs)
(c_parser_declspecs, c_parser_attribute_any_word)
(c_parser_objc_selector): Use CASE_RID_FLOATN_NX.
* c-typeck.c (c_common_type): Handle _FloatN and _FloatNx types.
(convert_arguments): Avoid promoting _FloatN and _FloatNx types
narrower than double.

gcc/c-family:
2016-07-22  Joseph Myers  

PR c/32187
* c-common.h (RID_FLOAT16, RID_FLOATN_NX_FIRST, RID_FLOAT32)
(RID_FLOAT64, RID_FLOAT128, RID_FLOAT32X, RID_FLOAT64X)
(RID_FLOAT128X): New enum rid values.
(CASE_RID_FLOATN_NX): New macro.
* c-common.c (c_common_reswords): Add _FloatN and _FloatNx
keywords.
(c_common_type_for_mode): Check for _FloatN and _FloatNx and
corresponding complex types.
(c_common_nodes_and_builtins): For non-C++, register _FloatN and
_FloatNx and corresponding complex types.
(keyword_begins_type_specifier): Use CASE_RID_FLOATN_NX.
* c-cppbuiltin.c (builtin_define_float_constants): Check _FloatN
   

[Bug tree-optimization/72824] [5/6 Regression] Signed floating point zero semantics broken at optimization level -O3 (tree-loop-distribute-patterns)

[mwahab at gcc dot gnu.org]

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

mwahab at gcc dot gnu.org changed:

   What|Removed |Added

 CC||mwahab at gcc dot gnu.org

--- Comment #11 from mwahab at gcc dot gnu.org ---
The new test-case gcc.c-torture/execute/ieee/pr72824-2.c is failing for
arm-none-linux-gnueabihf with gcc-6 and trunk.

I'm still looking into why.
Matthew

[Bug web/72856] Trottle bug creation for newly created accounts (to limit spam)

[LpSolit at netscape dot net]

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

--- Comment #10 from Frédéric Buclin  ---
(In reply to Frank Ch. Eigler from comment #6)
> Per-account rate limits seem so easy to overcome, with spammers already
> creating numerous verified junk accounts with ease.

I banned several ranges of IP addresses, and also permanently banned some
domain names. Logs show that all evil attempts made today have been
successfully blocked (for how long?).


> I would suggest focusing on spam-prevention content analysis (spamassassin
> style), and post-spam cleanup (blacklisting, history editing, bug hiding?)
> efforts.

Content analysis has been (partially) implemented today. If the bug report is
considered to be spam, the bug report is automatically rejected and the user
account automatically disabled.

[Bug gcov-profile/36412] gcov -l -p exceeds maximum file name length

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
Fixed on trunk.

[Bug gcov-profile/36412] gcov -l -p exceeds maximum file name length

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Tue Aug 16 14:14:18 2016
New Revision: 239503

URL: https://gcc.gnu.org/viewcvs?rev=239503=gcc=rev
Log:
gcov: add new option (--hash-filenames) (PR

PR gcov-profile/36412
* doc/gcov.texi: Document --hash-filenames(-x).
* gcov.c (print_usage): Add the option.
(process_args): Process the option, sort options alphabetically.
(md5sum_to_hex): New function.
(make_gcov_file_name): Do the md5sum and append it to a
filename.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/gcov.texi
trunk/gcc/gcov.c

[Bug libgcc/77265] Casting an extended precision long double "inf" to __float128 results in "nan"

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
The natural fix is to the extended precision unpacking, to make it clear 
the high bit so everything else can treat it like a normal IEEE format.  
I'll test a patch.

[Bug target/41880] CONSTANT_ADDRESS_P undefined.

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 CC||olegendo at gcc dot gnu.org

--- Comment #3 from Oleg Endo  ---
This doesn't occur with GCC 5+, right?  I have never hit this problem ...

[Bug debug/69073] internal compiler error: in maybe_record_trace_start

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 CC||olegendo at gcc dot gnu.org

--- Comment #5 from Oleg Endo  ---
Maybe PR 71109?

[Bug target/77267] New: MPX does not work in a presence of "-Wl,-as-needed" option (Ubuntu default)

[aivchenk at gmail dot com]

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

Bug ID: 77267
   Summary: MPX does not work in a presence of "-Wl,-as-needed"
option (Ubuntu default)
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aivchenk at gmail dot com
  Target Milestone: ---

When compiling with -Wl,-as-needed libmpx.so and libmpxwrappers.so are not
linked:
>gcc -fcheck-pointer-bounds -mmpx any_mpx_test.c -Wl,-as-needed
> ldd a.out 
linux-vdso.so.1 (0x7ffc687a)
libc.so.6 => /lib64/libc.so.6 (0x0035c8c0)
/lib64/ld-linux-x86-64.so.2 (0x55e88586f000)

And hence, MPX does not work.

(In a working scenario it should be like that:
> ldd a.out 
linux-vdso.so.1 (0x7fff53fe7000)
libmpx.so.0 => /lib64/libmpx.so.0 (0x7f135ac34000)
libmpxwrappers.so.0 => /lib64/libmpxwrappers.so.0 (0x7f135aa31000)
libc.so.6 => /lib64/libc.so.6 (0x0035c8c0)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0035c940)
/lib64/ld-linux-x86-64.so.2 (0x55861968)
)

This case is important because on Debian/Ubuntu -no-as-needed option is always
implicitly added while linking.

[Bug fortran/67419] gfortran.dg/large_real_kind_2.F90 FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #13 from Rainer Orth  ---
I had bug

21787172 _Q_sqrt returns Nan

filed.  The issue has been fixed in a later build of Solaris 12, so closing.

  Rainer

[Bug libgcc/77265] Casting an extended precision long double "inf" to __float128 results in "nan"

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||joseph at codesourcery dot com

--- Comment #2 from Uroš Bizjak  ---
CCs added.

[Bug target/76774] atomics on PPC: inconsistent widths for an _Atomic(_Bool) and for atomic_compare_exchange_strong on it

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Andrew Pinski  ---
(In reply to Peter Sewell from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > What code were you expecting anyways?
> 
> I hadn't noticed how recent the other-size LL/SC were.  But then I would
> have expected a 4-byte representation for _Atomic(_Bool) on the older
> machines, to minimise the amount of code between the lwarx and stwcx; would
> that have some other disadvantage?

Yes that would break Abis. In that power7 compiled code would be incompatible
with power9 one. 

> 
> I don't think the code you've got is functionally wrong on normal h/w.  We
> noticed this running in a semantics-based emulator that's very picky about
> reading from uninitialised memory, but on normal h/w the extra memory will
> AFAICS always be mapped and be within the same reservation granule.

Sorry but there is nothing that can be done here. This is a similar issue on
mips too.

[Bug tree-optimization/69848] poor vectorization of a loop from SPEC2006 464.h264ref

[amker at gcc dot gnu.org]

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

--- Comment #16 from amker at gcc dot gnu.org ---
Author: amker
Date: Tue Aug 16 13:09:40 2016
New Revision: 239502

URL: https://gcc.gnu.org/viewcvs?rev=239502=gcc=rev
Log:
PR tree-optimization/69848
* config/aarch64/aarch64-simd.md (vcond): Invert NE
and swtich operands to avoid additional NOT instruction.
(vcond): Ditto.
(vcondu, vcondu): Ditto.

gcc/testsuite
* gcc.target/aarch64/simd/vcond-ne-bit.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/aarch64/simd/vcond-ne-bit.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64-simd.md
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/77264] [7 Regression] std::string's replace gives wrong results with C++17, works with C++11

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
The patch at https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01179.html would fix
it, but I'll wait a bit to see if the committee agrees with that solution.

[Bug libgcc/77265] Casting an extended precision long double "inf" to __float128 results in "nan"

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-16
  Component|c   |libgcc
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
__extendxftf does not convert (clear) explicit lead bit to an implicit.
extended-precision does not utilize implicit/hidden bit.

So, 0x7fff80..0 that represents extended-precision infinity gets converted
directly to 0x7fff800 that represents quad-precision NaN.

Confirmed, soft-fp should be fixed.

[Bug middle-end/77262] [7 regression] Several libjava tests FAIL on 32-bit Solaris/x86

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> It's indeed suspicious that exactly the same set of tests is affected,
> but my reghunt (and previous testresults) point at a totally different
> patch.

Well, I have r237556 reverted in my working tree to silence the failures. This
revision only changes PRED_LOOP_EXIT.

[Bug libstdc++/77264] [7 Regression] std::string's replace gives wrong results with C++17, works with C++11

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||ville.voutilainen at gmail dot 
com

--- Comment #5 from Ville Voutilainen  ---
Well, it seems that disambiguating with a properly exclusive sfinae constraint
should do the trick.

[Bug c++/77263] comment /* */ is ignored in some cases

[bremende55 at gmail dot com]

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

--- Comment #4 from Jo  ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Jo from comment #2)
> >  /* and */ as part of a C-string literal should not interfere with /* */ in
> > the code.
> 
> They are no part of a string-literal, they are part of a comment, and the
> comment is terminated by the first */ token.

ok, I got it. Thank you.

[Bug libstdc++/77264] [7 Regression] std::string's replace gives wrong results with C++17, works with C++11

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #2)
> We end up in the new replace() overload when we should be in the const char*
> one here:
> 
> basic_string&
> replace(size_type __pos, size_type __n, const basic_string& __str)
> { return this->replace(__pos, __n, __str._M_data(), __str.size()); }

We could fix Tobias's example by changing this to use c_str() instead of
_M_data(), which would pass a const char* and so call the desired overload.

That wouldn't help comment 3 though, where a (non-const) char* is passed
directly, which requires a conversion to call the overload for const char*, and
so the new overload taking a string_view is chosen by overload resolution.

With the new overload str.replace(0, 1, , 1) is equivalent to str.replace(0,
1, string_view{, 1}, 1) which replaces the specified substring with
string_view{, 1}.substr(1) rather than string_view{, 1}.

[Bug libstdc++/77264] [7 Regression] std::string's replace gives wrong results with C++17, works with C++11

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Reduced:

#include 

int main () {
  std::string str("xyz");
  char c = 'Y';
  str.replace(1, 1, , 1);
  if (str[1] != 'Y')
__builtin_abort();
}

[Bug web/77266] test mark_spam.py

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Created attachment 39464
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39464=edit
test1

test2

[Bug web/77266] test mark_spam.py

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Next comment.

[Bug web/77266] New: test mark_spam.py

[marxin at gcc dot gnu.org]

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

Bug ID: 77266
   Summary: test mark_spam.py
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Please do not mark this issue. I'll remove it eventually.

[Bug c++/77264] [7 Regression] std::string's replace gives wrong results with C++17, works with C++11

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
We end up in the new replace() overload when we should be in the const char*
one here:

basic_string&
replace(size_type __pos, size_type __n, const basic_string& __str)
{ return this->replace(__pos, __n, __str._M_data(), __str.size()); }

[Bug c/77265] New: Casting an extended precision long double "inf" to __float128 results in "nan"

[sisyphus1 at optusnet dot com.au]

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

Bug ID: 77265
   Summary: Casting an extended precision long double "inf" to
__float128 results in "nan"
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sisyphus1 at optusnet dot com.au
  Target Milestone: ---

Created attachment 39463
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39463=edit
Demonstrates the bug that I've described

Hi,

First up ... I've nominated that this is "A problem with the C compiler front
end".
My apologies if that assessment is incorrect.

Attached is the demo program (bug492.c) which I've built on Ubuntu-16.04LTS
(gcc-5.4.0) with the command:

$ gcc -Wall -Wextra -fno-strict-aliasing -fwrapv -o bug492 bug492.c -lquadmath

The output of that program is:

inf inf
Looks like we have a NaN instead of Inf
inf nan

and I take it that demonstrates that an extended precision (80-bit) long double
+infinity, when cast to a __float128, is transformed into a NaN.


I originally reported this as a mingw-w64 bug (over a year ago) at:
https://sourceforge.net/p/mingw-w64/bugs/479/

It's only recently that I've encountered the same behaviour with gcc on linux.
(I think this might be because I generally use more modern versions of gcc on
Windows than I do on linux.)

I guess it might be considered as a somewhat minor quibble ... but it has
actually become quite a PITA for me.

Can something be done ? ... or do I just need to keep implementing workarounds
?

Thank you all for your excellent work.

Cheers,
Rob

[Bug c++/77263] comment /* */ is ignored in some cases

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jo from comment #2)
>  /* and */ as part of a C-string literal should not interfere with /* */ in
> the code.

They are no part of a string-literal, they are part of a comment, and the
comment is terminated by the first */ token.

[Bug c++/77263] comment /* */ is ignored in some cases

[bremende55 at gmail dot com]

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

Jo  changed:

   What|Removed |Added

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

--- Comment #2 from Jo  ---
(In reply to Andreas Schwab from comment #1)
> Multiline comments do not nest.

There is only ONE multiline comment, so there is nothing to nest. The other /*
resp. */ character sequences are within literals, enclosed with double qoutes.
 /* and */ as part of a C-string literal should not interfere with /* */ in the
code.

[Bug libstdc++/72847] vector copy-assignment basic exception safety

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #2 from Jonathan Wakely  ---
Fixed, thanks for the report.

[Bug rtl-optimization/74585] powerpc64: Very poor code generation for homogeneous vector aggregates passed in registers

[wschmidt at gcc dot gnu.org]

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

--- Comment #14 from Bill Schmidt  ---
(In reply to Richard Biener from comment #13)
> 
> You mean stores like the following?
> 
> (insn 13 12 14 2 (set (mem/c:V4SI (plus:DI (reg/f:DI 150 virtual-stack-vars)
> (const_int 112 [0x70])) [1 a+48 S16 A128])
> (vec_select:V4SI (reg:V4SI 190)
> (parallel [
> (const_int 2 [0x2])
> (const_int 3 [0x3])
> (const_int 0 [0])
> (const_int 1 [0x1])
> ]))) t.c:14 -1
>  (nil))
> 
> I wonder why dse can't simply force the rhs to a register?  Of course if
> power really has stores that do this vec_select but no non-store with
> the operation then this might not be valid ...

Right, the problem is our limited selection of vector stores on POWER8.  We can
either use stvx, which requires that the address be 16-byte aligned, or we can
use stxvd2x (what you see here), which has the odd property of being a
big-endian store even on a little-endian system.  We can't force the rhs to a
register because that would have the unwanted side effect of converting an
unaligned load to a forcibly aligned load (masking off the low-order 4 bits).

Now, for parameters, this is legal because the stack slots are 16-byte aligned,
but DSE doesn't know that.  I don't think we want to pollute DSE with extra
logic for this architectural anomaly, so it's probably best if we do some more
work to figure out when we can safely use the aligning store.  (Something
that's been on the back burner for a while, but this discovery makes it more
important.)

For POWER9, we have unaligned stores with proper endian behavior, so it won't
be a problem except for POWER8.

> 
> Now, in the end this example just shows that lowering register passing
> only at RTL expansion leads to a load of missed optimizations regarding
> to parameter setup ... some scheme to apply the lowering on GIMPLE already
> would be interesting to explore (but albeit quite a bit of work).  We'd
> have a second set of "parameter decls" somewhere, like in struct function,
> and use that when the IL is on lowered form.  Same for DECL_RESULT of course.
> And then the interesting part is whether to expose the stack in some way or
> restrict the lowering to decomposition/combining to registers.

Right...lots of work here, and of course some added complexity to ABI
implementation for new and existing targets.  But small structures/arrays
passed entirely in registers is a not-uncommon ABI feature, and even just
exposing those early could be helpful.  (Complications set in when you run out
of registers halfway through a structure and so forth, so even just lowering
that sort of thing early would not be trivial.)

[Bug libstdc++/72847] vector copy-assignment basic exception safety

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Tue Aug 16 11:33:16 2016
New Revision: 239497

URL: https://gcc.gnu.org/viewcvs?rev=239497=gcc=rev
Log:
PR 72847 Prevent double-free in std::vector

PR libstdc++/72847
* include/bits/stl_bvector.h (_Bvector_base::_M_deallocate): Zero
pointers to start and end of storage.
* testsuite/23_containers/vector/bool/72847.cc: New test.
* include/bits/vector.tcc (vector::_M_reallocate): Only update
_M_finish after deallocating.
(vector::_M_fill_insert): Likewise.
(vector::_M_insert_range): Likewise.
(vector::_M_insert_aux): Likewise.

Added:
trunk/libstdc++-v3/testsuite/23_containers/vector/bool/72847.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_bvector.h
trunk/libstdc++-v3/include/bits/vector.tcc

[Bug middle-end/77262] [7 regression] Several libjava tests FAIL on 32-bit Solaris/x86

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from Dominique d'Humieres  ---
> Duplicate of/related to pr71682?

It's indeed suspicious that exactly the same set of tests is affected,
but my reghunt (and previous testresults) point at a totally different
patch.

Rainer

[Bug c++/71885] Incorrect code generated with -01, memset() function call is missing

[trippels at gcc dot gnu.org]

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

--- Comment #26 from Markus Trippelsdorf  ---
For future reference here is a nice, short example from Bernd Edlinger:

markus@x4 tmp % cat lifetime-dse.cpp
#include 
#include 
#include 

struct A {
  A() {}
  void *operator new(size_t s) {
void *ptr = malloc(s);
memset(ptr, 0xFF, s);
return ptr;
  }
  int value;
};

int main() {
  A *a = new A;
  assert(a->value == -1); /* Use of uninitialized value */
}

markus@x4 tmp % g++ -O2 -flifetime-dse=1 lifetime-dse.cpp
markus@x4 tmp % ./a.out

markus@x4 tmp % g++ -O2 -flifetime-dse=2 lifetime-dse.cpp
markus@x4 tmp % ./a.out
a.out: lifetime-dse.cpp:17: int main(): Assertion `a->value == -1' failed.
[1]21394 abort  ./a.out

[Bug c/76783] [7 Regression] wrong code with conditional vector assignment @ -Og

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Component|tree-optimization   |c
 Resolution|--- |FIXED

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

[Bug c/76783] [7 Regression] wrong code with conditional vector assignment @ -Og

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Component|tree-optimization   |c
 Resolution|--- |FIXED

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Tue Aug 16 11:22:47 2016
New Revision: 239496

URL: https://gcc.gnu.org/viewcvs?rev=239496=gcc=rev
Log:
2016-08-16  Richard Biener  

PR tree-optimization/76783
* tree-ssa-propagate.c (ssa_prop_init): Use RPO order.  Clear
BB visited flags at start.

* gcc.dg/pr76783.c: New testcase.
* gcc.dg/tree-ssa/pr69270-2.c: Adjust.

Added:
trunk/gcc/testsuite/gcc.dg/pr76783.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr69270-2.c
trunk/gcc/tree-ssa-propagate.c

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

[Bug tree-optimization/76783] [7 Regression] wrong code with conditional vector assignment @ -Og

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Tue Aug 16 11:22:47 2016
New Revision: 239496

URL: https://gcc.gnu.org/viewcvs?rev=239496=gcc=rev
Log:
2016-08-16  Richard Biener  

PR tree-optimization/76783
* tree-ssa-propagate.c (ssa_prop_init): Use RPO order.  Clear
BB visited flags at start.

* gcc.dg/pr76783.c: New testcase.
* gcc.dg/tree-ssa/pr69270-2.c: Adjust.

Added:
trunk/gcc/testsuite/gcc.dg/pr76783.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr69270-2.c
trunk/gcc/tree-ssa-propagate.c

[Bug target/73350] AVX512: GCC optimizes away rounding flags

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 39462
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39462=edit
gcc7-pr73350-wip.patch

Untested patch with what I had in mind for the mask operands.  Perhaps some
extra arch specific pass that would optimize the VEC_MERGE with -1 mask into
non-VEC_MERGE would be helpful too (or do it in stv pass?), otherwise it will
sometimes be folded in cse, sometimes in combine, but with no guarantees.

[Bug middle-end/77262] [7 regression] Several libjava tests FAIL on 32-bit Solaris/x86

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  ---
Duplicate of/related to pr71682?

[Bug c++/77264] [7 Regression] std::string's replace gives wrong results with C++17, works with C++11

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||ville at gcc dot gnu.org
   Target Milestone|--- |7.0

--- Comment #1 from Tobias Burnus  ---
Looks as if r239370 is the culprit as it works when reverting the patch:

+2016-08-11  Ville Voutilainen  
+
+   Implement LWG 2758.
+   * include/bits/basic_string.h
+   (append(__sv_type, size_type, size_type)): Turn into a template,
+   change parameter type, constrain, add a conversion to __sv_type
+   from the dependent parameter type.
+   (assign(__sv_type, size_type, size_type)): Likewise.
+   (insert(size_type, __sv_type, size_type, size_type)): Likewise.
+   (replace(size_type, size_type, __sv_type, size_type, size_type)):
+   Likewise.
+   (compare(size_type, size_type,__sv_type, size_type, size_type)):
+   Likewise.
+   * testsuite/21_strings/basic_string/lwg2758.cc: New.

[Bug c++/77264] New: [7 Regression] std::string's replace gives wrong results with C++17, works with C++11

[burnus at gcc dot gnu.org]

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

Bug ID: 77264
   Summary: [7 Regression] std::string's replace gives wrong
results with C++17, works with C++11
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

Running
  g++ -std=c++11 test.cc && ./a.out > working
  g++ -std=c++17 test.cc && ./a.out > failing
  diff -U0 working failing
shows:
  --- working 2016-08-16 12:50:40.318596035 +0200
  +++ failing 2016-08-16 12:50:40.870592038 +0200
  @@ -1 +1 @@
  -RESULT: Running 
  +RESULT: Running <>

Namely, the replace call does not work with --std=c++17, but only with
--std++11. I think it worked two weeks ago. It definitely worked a month ago.


// --- test.cc 
#include 

std::string&
string_replace (std::string& str, const std::string& old_str,
const std::string& new_str)
{
  size_t pos = 0;

  while ((pos = str.find(old_str, pos)) != std::string::npos)
{
  str.replace (pos, old_str.length (), new_str);
  pos += new_str.length ();
}

  return str;
}

int main () {
  std::string str("Running ");
  std::string old_str("PROGRAM_NAME");
  std::string new_str("This_Program");

  __builtin_printf ("RESULT: %s\n",
string_replace(str, old_str, new_str).c_str());
  return 0;
}

[Bug target/76774] atomics on PPC: inconsistent widths for an _Atomic(_Bool) and for atomic_compare_exchange_strong on it

[Peter.Sewell at cl dot cam.ac.uk]

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

--- Comment #4 from Peter Sewell  ---
(In reply to Andrew Pinski from comment #3)
> What code were you expecting anyways?

I hadn't noticed how recent the other-size LL/SC were.  But then I would have
expected a 4-byte representation for _Atomic(_Bool) on the older machines, to
minimise the amount of code between the lwarx and stwcx; would that have some
other disadvantage?  

I don't think the code you've got is functionally wrong on normal h/w.  We
noticed this running in a semantics-based emulator that's very picky about
reading from uninitialised memory, but on normal h/w the extra memory will
AFAICS always be mapped and be within the same reservation granule.

[Bug sanitizer/71042] libtsan requires __pointer_chk_guard@GLIBC_PRIVATE (6)

[LpSolit at netscape dot net]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #13 from Jakub Jelinek  ---
Should be fixed now.

[Bug sanitizer/71042] libtsan requires __pointer_chk_guard@GLIBC_PRIVATE (6)

[LpSolit at netscape dot net]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #13 from Jakub Jelinek  ---
Should be fixed now.

[Bug c/67410] [5 Regression] c/c-typeck.c references out of bounds array

[LpSolit at netscape dot net]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6/7 Regression]  |[5 Regression] c/c-typeck.c
   |c/c-typeck.c references out |references out of bounds
   |of bounds array |array

--- Comment #7 from Jakub Jelinek  ---
Fixed for 6.2+ so far.

[Bug fortran/50406] ld undefined reference to __MOD_str

[LpSolit at netscape dot net]

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

Vittorio Zecca  changed:

   What|Removed |Added

Version|4.8.0   |7.0

--- Comment #4 from Vittorio Zecca  ---
Still there in gfortran 7.0 trunk 239276

[Bug c++/77263] comment /* */ is ignored in some cases

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

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
Multiline comments do not nest.

[Bug c++/77263] New: comment /* */ is ignored in some cases

[bremende55 at gmail dot com]

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

Bug ID: 77263
   Summary: comment /* */ is ignored in some cases
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bremende55 at gmail dot com
  Target Milestone: ---

The following code compiles and gives the correct result:
#include 
#include 
#include 

int main() {
  std::string astring("// x /*  meaningless comment start  ");
  // /*
  std::string result = std::regex_replace(
astring, std::regex("//[^\n]*/\\*"),  "ZZ ");
  std::cout << "result = " << result << '\n';
  // expected: ZZ   meaningless comment start
  // */
  std::cout << "astring = " << astring << '\n';
}

BUT when I comment out the lines in the middle, i.e. 
#include 
#include 
#include 

int main() {
  std::string astring("// x /*  meaningless comment start  ");
  /*
  std::string result = std::regex_replace(
astring, std::regex("//[^\n]*/\\*"),  "ZZ ");
  std::cout << "result = " << result << '\n';
  // expected: ZZ   meaningless comment start
  */
  std::cout << "astring = " << astring << '\n';
}

the compile detects errors in the out-commented code.
g++ -v 
yields:
Es werden eingebaute Spezifikationen verwendet.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/lib/gcc/x86_64-pc-linux-gnu/6.1.0/lto-wrapper
Ziel: x86_64-pc-linux-gnu
Konfiguriert mit: ../gcc-6.1.0/configure --enable-languages=c,c++
Thread-Modell: posix
gcc-Version 6.1.0 (GCC)

[Bug middle-end/77259] [6/7 Regression] ICE in emit_move_insn since r232167

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 39461
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39461=edit
gcc7-pr77259.patch

Untested fix.

[Bug libstdc++/72847] vector copy-assignment basic exception safety

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug middle-end/77262] [7 regression] Several libjava tests FAIL on 32-bit Solaris/x86

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug middle-end/77262] New: [7 regression] Several libjava tests FAIL on 32-bit Solaris/x86

[ro at gcc dot gnu.org]

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

Bug ID: 77262
   Summary: [7 regression] Several libjava tests FAIL on 32-bit
Solaris/x86
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
  Target Milestone: ---
  Host: i386-pc-solaris2.*
Target: i386-pc-solaris2.*
 Build: i386-pc-solaris2.*

Between 20160805 and 20160811, several libjava tests started to FAIL (mostly
timeouts) on 32-bit Solaris/x86 (both in i386-pc-solaris2.* and
amd64-pc-solaris2.*
configurations):

WARNING: program timed out.
FAIL: InvokeReturn execution - source compiled test
WARNING: program timed out.
FAIL: InvokeReturn -findirect-dispatch execution - source compiled test
WARNING: program timed out.
FAIL: InvokeReturn -O3 execution - source compiled test
WARNING: program timed out.
FAIL: InvokeReturn -O3 -findirect-dispatch execution - source compiled test
WARNING: program timed out.
FAIL: PR3096 execution - source compiled test
WARNING: program timed out.
FAIL: PR3096 -findirect-dispatch execution - source compiled test
WARNING: program timed out.
FAIL: PR3096 -O3 execution - source compiled test
WARNING: program timed out.
FAIL: PR3096 -O3 -findirect-dispatch execution - source compiled test
FAIL: Serialization execution - source compiled test
FAIL: Serialization -findirect-dispatch execution - source compiled test
FAIL: Serialization -O3 execution - source compiled test
FAIL: Serialization -O3 -findirect-dispatch execution - source compiled test
WARNING: program timed out.
FAIL: md5test execution - source compiled test
WARNING: program timed out.
FAIL: md5test -findirect-dispatch execution - source compiled test
WARNING: program timed out.
FAIL: md5test -O3 execution - source compiled test
WARNING: program timed out.
FAIL: md5test -O3 -findirect-dispatch execution - source compiled test
FAIL: negzero execution - source compiled test
FAIL: negzero -findirect-dispatch execution - source compiled test
FAIL: negzero -O3 execution - source compiled test
FAIL: negzero -O3 -findirect-dispatch execution - source compiled test
WARNING: program timed out.
FAIL: pr21785 execution - source compiled test
WARNING: program timed out.
FAIL: pr21785 -findirect-dispatch execution - source compiled test
WARNING: program timed out.
FAIL: pr21785 -O3 execution - source compiled test
WARNING: program timed out.
FAIL: pr21785 -O3 -findirect-dispatch execution - source compiled test
FAIL: pr25676 output - source compiled test
FAIL: pr25676 -findirect-dispatch output - source compiled test
FAIL: pr25676 -O3 output - source compiled test
FAIL: pr25676 -O3 -findirect-dispatch output - source compiled test
WARNING: program timed out.
FAIL: shatest execution - source compiled test
WARNING: program timed out.
FAIL: shatest -findirect-dispatch execution - source compiled test
WARNING: program timed out.
FAIL: shatest -O3 execution - source compiled test
WARNING: program timed out.
FAIL: shatest -O3 -findirect-dispatch execution - source compiled test

A reghunt identified the following patch as the culprit:

2016-08-07  Jan Hubicka  

   * tree-ssa-threadbackward.c: Include tree-inline.h
   (profitable_jump_thread_path): Use estimate_num_insns to estimate
   size of copied block; for cold paths reduce duplication.
   (find_jump_threads_backwards): Remove redundant tests.
   (pass_thread_jumps::gate): Enable for -Os.

I've not yet determinded what exactly is going wrong.

  Rainer

[Bug libstdc++/75402] std::condition_variable::wait_until wakes up constantly

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
I can't reproduce this with any version of GCC, so either you have a weird
config, or a weird kernel, or something else that is impossible to tell without
the requested info.

I see a single futex wait and the expected output:

futex(0x7ffc8707f5d4, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1,
{1471338875, 919280648}, ) = -1 ETIMEDOUT (Connection timed out)
fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 2), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f0fb8b88000
write(1, "new_now - now = 2000 ms\n", 24new_now - now = 2000 ms
) = 24
write(1, "Done.\n", 6Done.
)  = 6
futex(0x7ffc8707f600, FUTEX_WAKE_PRIVATE, 1) = 0
exit_group(0)   = ?

[Bug c/73450] [7 Regression] wrong code at -Os and above on x86_64-linux-gnu in both 32-bit and 64-bit modes (executable hangs)

[amker at gcc dot gnu.org]

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

--- Comment #4 from amker at gcc dot gnu.org ---
Author: amker
Date: Tue Aug 16 09:13:50 2016
New Revision: 239494

URL: https://gcc.gnu.org/viewcvs?rev=239494=gcc=rev
Log:
PR tree-optimization/72817
PR tree-optimization/73450
* tree-ssa-loop-niter.c (number_of_iterations_ne): Check
multiple_of_p for adjusted IV.base.

gcc/testsuite
* gcc.dg/tree-ssa/pr72817.c: New test.
* gcc.dg/tree-ssa/pr73450.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr72817.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr73450.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-niter.c

[Bug tree-optimization/72817] [7 Regression] wrong code at -O3 on x86_64-linux-gnu (in both 32-bit and 64-bit modes)

[amker at gcc dot gnu.org]

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

--- Comment #4 from amker at gcc dot gnu.org ---
Author: amker
Date: Tue Aug 16 09:13:50 2016
New Revision: 239494

URL: https://gcc.gnu.org/viewcvs?rev=239494=gcc=rev
Log:
PR tree-optimization/72817
PR tree-optimization/73450
* tree-ssa-loop-niter.c (number_of_iterations_ne): Check
multiple_of_p for adjusted IV.base.

gcc/testsuite
* gcc.dg/tree-ssa/pr72817.c: New test.
* gcc.dg/tree-ssa/pr73450.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr72817.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr73450.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-niter.c

[Bug libstdc++/75402] std::condition_variable::wait_until wakes up constantly

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-08-16
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
Please provide the missing information requested by https://gcc.gnu.org/bugs/
including at least the output of gcc -v

[Bug libfortran/77261] New: gfortran.dg/random_3.f90 FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 77261
   Summary: gfortran.dg/random_3.f90 FAILs
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: jb at gcc dot gnu.org
  Target Milestone: ---
  Host: sparc*-sun-solaris2.*
Target: sparc*-sun-solaris2.*
 Build: sparc*-sun-solaris2.*

Between 20160805 and 20160811, the gfortran.dg/random_3.f90 test started to
FAIL
on Solaris/SPARC (both 32 and 64-bit):

+FAIL: gfortran.dg/random_3.f90   -O0  execution test
+FAIL: gfortran.dg/random_3.f90   -O1  execution test
+FAIL: gfortran.dg/random_3.f90   -O2  execution test
+FAIL: gfortran.dg/random_3.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
+FAIL: gfortran.dg/random_3.f90   -O3 -g  execution test
+FAIL: gfortran.dg/random_3.f90   -Os  execution test

and according to gcc-testresults a couple of other targets are affected as
well:

at least aarch64, powerpc64*, and s390x.

This must be due to

2016-08-11  Janne Blomqvist  

* intrinsics/random.c: Replace KISS with xorshift1024* using
per-thread state.
* runtime/main.c (init): Don't call random_seed_i4.

On Solaris/SPARC, I find

Thread 2 received signal SIGABRT, Aborted.
[Switching to Thread 1 (LWP 1)]
0xfef5b288 in __lwp_sigqueue () from /lib/libc.so.1
(gdb) where
#0  0xfef5b288 in __lwp_sigqueue () from /lib/libc.so.1
#1  0xfee97184 in raise () from /lib/libc.so.1
#2  0xfee6a170 in abort () from /lib/libc.so.1
#3  0xff2cec5c in _gfortrani_sys_abort ()
at /vol/gcc/src/hg/trunk/local/libgfortran/runtime/error.c:182
#4  0xff368930 in _gfortran_abort ()
at /vol/gcc/src/hg/trunk/local/libgfortran/intrinsics/abort.c:33
#5  0x000114a0 in random_4 ()
at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/random_3.f90:28
#6  0x000114e4 in main (argc=1, argv=0xffbffa38)
at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/random_3.f90:29
#7  0x00010ef0 in _start ()

#5  0x000114a0 in random_4 ()
at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/random_3.f90:28
28if (any ((r8 - r10) .gt. delta)) call abort
(gdb) p r8
$1 = (0.33531091697986526, 0.49560326111744801, 0.27202821216533879,
0.14310502215036824, 0.52840260117005033, 0.40848924836193379,
0.99531496953458853, 0.27001843112503765, 0.95295363932045984,
0.14316668825144485)
(gdb) p r10
$2 = (0.33531091697986526218176681400279274,
0.27202821216533887067191155296717697, 0.5284026011700503506437776191974859,
0.99531496953458854300698251805465629, 0.95295363932045989983140359118424494,
0.14316668825144487670941584544780525, 0.6092459765628781765258926440263291,
0.54591083895721370176324787139563687, 0.059215945881747894214465842169322417,
0.49226030310682212563454955026951127)

  Rainer

[Bug c++/76262] list-initialization prefers initializer_list over copy constructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Jonathan Wakely  ---
OK so G++ already matches the post-2137 behaviour - thanks!

[Bug fortran/77260] New: bogus warning with ENTRY in a function

[mar...@mpa-garching.mpg.de]

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

Bug ID: 77260
   Summary: bogus warning with ENTRY in a function
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mar...@mpa-garching.mpg.de
  Target Milestone: ---

Created attachment 39460
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39460=edit
test case

When compiling the test case below, current trunk gfortran warns about "f2"
being unused:

martin@martin-Latitude-E7450 ~/tmp $ gfortran -std=f2008 -W -Wall entry.f90 
entry.f90:11:8:

 entry f2
1
Warning: Fortran 2008 obsolescent feature: ENTRY statement at (1)
entry.f90:9:10:

 integer f2
  1
Warning: Unused variable ‘f2’ declared at (1) [-Wunused-variable]

However, if I comment out the "integer f2" statement, gfortran produces an
error (as I would expect):
martin@martin-Latitude-E7450 ~/tmp $ gfortran -std=f2008 -W -Wall entry.f90 
entry.f90:11:8:

 entry f2
1
Warning: Fortran 2008 obsolescent feature: ENTRY statement at (1)
entry.f90:4:12:

 public f1,f2
1
Error: Contained function ‘f2’ at (1) has no IMPLICIT type
entry.f90:17:4:

 use foo
1
Fatal Error: Can't open module file ‘foo.mod’ for reading at (1): No such file
or directory
compilation terminated.

I think the warning is bogus ... the entry somehow must be given an explicit
return type.
This behaviour happens on trunk and 5.4; I haven't tested other branches so
far.

[Bug c++/76262] list-initialization prefers initializer_list over copy constructor

[rs2740 at gmail dot com]

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

--- Comment #3 from TC  ---
(In reply to Jonathan Wakely from comment #2)
> In which case both EDG and Clang get this wrong, as they print "12"

I know that Clang 3.7+ implemented DR1467 without 2137 (in which case "12"
would be the right output) - that led to
https://llvm.org/bugs/show_bug.cgi?id=23812.

I'm not familiar with EDG.

[Bug middle-end/77259] [6/7 Regression] ICE in emit_move_insn since r232167

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-08-16
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |6.2
 Ever confirmed|0   |1

[Bug middle-end/77259] New: [6/7 Regression] ICE in emit_move_insn since r232167

[jakub at gcc dot gnu.org]

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

Bug ID: 77259
   Summary: [6/7 Regression] ICE in emit_move_insn since r232167
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

template  class A;
template  struct A
{
  A (A &&);
};
template 
A operator+(S *, const A &);
template 
void operator+(const A &, S *);
struct B
{
  template  B (V);
};
template  V foo (B) {}
class C;
template  struct D
{
  C *operator->() { return d; }
  C *d;
};
struct C
{
  virtual A bar ();
};
struct E
{
  ~E ();
  virtual A bar (const B &) const;
};
template  struct F : E
{
};
template  class F : E
{
  typedef D f;
  A bar (const B &) const try
{
  f a = baz ();
}
  catch (int)
{
}
  f baz () const
  {
D b = foo(0);
"" + b->bar () + "";
  }
};
struct G : F
{
  G (int);
};
void test () { G (0); }

ICEs starting with r232167 in emit_move_insn.

[Bug c++/76262] list-initialization prefers initializer_list over copy constructor

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
In which case both EDG and Clang get this wrong, as they print "12"

[Bug rtl-optimization/74585] powerpc64: Very poor code generation for homogeneous vector aggregates passed in registers

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
(In reply to Bill Schmidt from comment #11)
> With the original test case, -mcpu=power8 is problematic because of the use
> of the "swapping stores," whose RHS is a vec_select rather than a register
> or subreg.  This prevents us from saving the RHS of the store for use in
> replacing subsequent loads, running afoul of this logic in
> dse.c:record_store ():
> 
>   if (GET_CODE (body) == SET
>   /* No place to keep the value after ra.  */
>   && !reload_completed
>   && (REG_P (SET_SRC (body))   <= this part
>   || GET_CODE (SET_SRC (body)) == SUBREG
>   || CONSTANT_P (SET_SRC (body)))
>   && !MEM_VOLATILE_P (mem)
>   /* Sometimes the store and reload is used for truncation and  
> 
>  rounding.  */
>   && !(FLOAT_MODE_P (GET_MODE (mem)) && (flag_float_store)))
> 
> We can circumvent this if we can use stvx to force the parameters to the
> stack, which is legal since the stack slots are properly aligned.
> 
> However, even using -mcpu=power9, we don't handle removing the stores and
> replacing the partial loads with register logic.

You mean stores like the following?

(insn 13 12 14 2 (set (mem/c:V4SI (plus:DI (reg/f:DI 150 virtual-stack-vars)
(const_int 112 [0x70])) [1 a+48 S16 A128])
(vec_select:V4SI (reg:V4SI 190)
(parallel [
(const_int 2 [0x2])
(const_int 3 [0x3])
(const_int 0 [0])
(const_int 1 [0x1])
]))) t.c:14 -1
 (nil))

I wonder why dse can't simply force the rhs to a register?  Of course if
power really has stores that do this vec_select but no non-store with
the operation then this might not be valid ...

Now, in the end this example just shows that lowering register passing
only at RTL expansion leads to a load of missed optimizations regarding
to parameter setup ... some scheme to apply the lowering on GIMPLE already
would be interesting to explore (but albeit quite a bit of work).  We'd
have a second set of "parameter decls" somewhere, like in struct function,
and use that when the IL is on lowered form.  Same for DECL_RESULT of course.
And then the interesting part is whether to expose the stack in some way or
restrict the lowering to decomposition/combining to registers.

[Bug tree-optimization/76957] FAIL: gcc.dg/graphite/scop-dsyr2k.c scan-tree-dump-times graphite "number of SCoPs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Confirmed.  As said in patch submission this is a niter analysis missed
optimization.  Same for the also failing gcc.dg/graphite/scop-dsyrk.c

[Bug testsuite/77034] [6.2RC regression] g++.dg/init/elide5.C fails on powerpc64-unknown-linux-gnu with -m32

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Should be fixed now.

[Bug testsuite/77034] [6.2RC regression] g++.dg/init/elide5.C fails on powerpc64-unknown-linux-gnu with -m32

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Tue Aug 16 07:15:00 2016
New Revision: 239493

URL: https://gcc.gnu.org/viewcvs?rev=239493=gcc=rev
Log:
PR testsuite/77034
Backported from mainline
2016-07-25  Jason Merrill  

* g++.dg/init/elide5.C (operator new): Use decltype(sizeof(1)) instead
of unsigned long.

Modified:
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/g++.dg/init/elide5.C