[Bug c++/77912] [C++17 feature] class template deduction fails in template functions and generic lambdas

2016-10-09 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77912

Markus Trippelsdorf  changed:

   What|Removed |Added

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

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

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

[Bug c++/77890] class template type deduction fails for lambda functions

2016-10-09 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77890

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

[Bug go/77910] [7 Regression] go: open zversion.go: no such file or directory

2016-10-09 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77910

--- Comment #4 from Markus Trippelsdorf  ---
Created attachment 39779
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39779=edit
strace bad

[Bug go/77910] [7 Regression] go: open zversion.go: no such file or directory

2016-10-09 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77910

--- Comment #3 from Markus Trippelsdorf  ---
Created attachment 39778
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39778=edit
strace good

[Bug libstdc++/77913] error building bits/locale_conv.h: expected primary-expression before ',' token

2016-10-09 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77913

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> This is a bug in libgtop11dotnet:
> 
> 
> ./cardmod.h:#define __out
> ./cardmod.h:#define __out_bcount_part_opt(x, y)
> ./cardmod.h:#define __out_bcount(x)
> ./cardmod.h:#define __out_opt
> 
> 
> __ is in the implementation namespace but they are abusing it.

Basically they are trying to compile the sources under both MSVC++ and GCC but
default to MSVC++'s source style in a way it is undefined for other compilers.

[Bug libstdc++/77913] error building bits/locale_conv.h: expected primary-expression before ',' token

2016-10-09 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77913

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
This is a bug in libgtop11dotnet:


./cardmod.h:#define __out
./cardmod.h:#define __out_bcount_part_opt(x, y)
./cardmod.h:#define __out_bcount(x)
./cardmod.h:#define __out_opt


__ is in the implementation namespace but they are abusing it.

[Bug libstdc++/77913] error building bits/locale_conv.h: expected primary-expression before ',' token

2016-10-09 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77913

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> Who is defining __out ?

Which you can find out by -dD (or -g3).  I suspect this is not a bug in
libstdc++ but the headers of the program that is being compiled.

[Bug libstdc++/77913] error building bits/locale_conv.h: expected primary-expression before ',' token

2016-10-09 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77913

--- Comment #1 from Andrew Pinski  ---
Who is defining __out ?

[Bug go/77910] [7 Regression] go: open zversion.go: no such file or directory

2016-10-09 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77910

--- Comment #2 from Markus Trippelsdorf  ---
(In reply to Ian Lance Taylor from comment #1)
> Do you have a copy of the gc toolchain on your computer?

No.

> Is the environment variable GOROOT set?

No.
 % env | grep GO
GOPATH=/var/tmp/go
 %

[Bug libstdc++/77913] New: error building bits/locale_conv.h: expected primary-expression before ',' token

2016-10-09 Thread doko at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77913

Bug ID: 77913
   Summary: error building bits/locale_conv.h: expected
primary-expression before ',' token
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

[forwarded from https://bugs.debian.org/839995]

The Debian issue has an unreduced test case, and a proposed fix.

$ g++ -c MiniDriverContainerpreprocess.cpp In file included from
/usr/include/c++/6/locale:43:0,
 from /usr/include/c++/6/iomanip:43,
 from Log.hpp:31,
 from MiniDriverContainer.hpp:33,
 from MiniDriverContainer.cpp:22:
/usr/include/c++/6/bits/locale_conv.h: In member function
'std::__cxx11::wstring_convert<_Codecvt, _Elem, _Wide_alloc,
_Byte_alloc>::wide_string std::__cxx11::wstring_convert<_Codecvt, _Elem,
_Wide_alloc, _Byte_alloc>::from_bytes(const char*, const char*)':
/usr/include/c++/6/bits/locale_conv.h:250:40: error: expected
primary-expression before ',' token
  if (__str_codecvt_in(__first, __last, __out, *_M_cvt, _M_state,
^
/usr/include/c++/6/bits/locale_conv.h:252:4: error: return-statement with no
value, in function returning 'std::__cxx11::wstring_convert<_Codecvt, _Elem,
_Wide_alloc, _Byte_alloc>::wide_string' [-fpermissive]
return __out;
^~
/usr/include/c++/6/bits/locale_conv.h: In member function
'std::__cxx11::wstring_convert<_Codecvt, _Elem, _Wide_alloc,
_Byte_alloc>::byte_string std::__cxx11::wstring_convert<_Codecvt, _Elem,
_Wide_alloc, _Byte_alloc>::to_bytes(const _Elem*, const _Elem*)':
/usr/include/c++/6/bits/locale_conv.h:286:41: error: expected
primary-expression before ',' token
  if (__str_codecvt_out(__first, __last, __out, *_M_cvt, _M_state,
 ^
/usr/include/c++/6/bits/locale_conv.h:288:4: error: return-statement with no
value, in function returning 'std::__cxx11::wstring_convert<_Codecvt, _Elem,
_Wide_alloc, _Byte_alloc>::byte_string' [-fpermissive]
return __out;
^~
In file included from /usr/include/c++/6/locale:43:0,
 from /usr/include/c++/6/iomanip:43,
 from Log.hpp:31,
 from MiniDriverContainer.hpp:33,
 from MiniDriverContainer.cpp:22:
/usr/include/c++/6/bits/locale_conv.h: In member function 'typename
std::wbuffer_convert<_Codecvt, _Elem, _Tr>::_Wide_streambuf::int_type
std::wbuffer_convert<_Codecvt, _Elem, _Tr>::overflow(typename
std::wbuffer_convert<_Codecvt, _Elem, _Tr>::_Wide_streambuf::int_type)':
/usr/include/c++/6/bits/locale_conv.h:382:29: error: expected
primary-expression before ',' token
  else if (!_Tr::eq_int_type(__out, _Tr::eof()))
 ^

[Bug c++/59900] isnan signals FPE invalid operation when given a NaN

2016-10-09 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59900

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Andrew Pinski  ---
Dup of bug 66462.

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

[Bug middle-end/66462] GCC isinf/isnan/... builtins cause sNaN exceptions

2016-10-09 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66462

Andrew Pinski  changed:

   What|Removed |Added

 CC||cam888eron at yahoo dot com

--- Comment #3 from Andrew Pinski  ---
*** Bug 59900 has been marked as a duplicate of this bug. ***

[Bug c++/77912] [C++17 feature] class template deduction fails in template functions and generic lambdas

2016-10-09 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77912

Andrew Pinski  changed:

   What|Removed |Added

Summary|class template deduction|[C++17 feature] class
   |fails in template functions |template deduction fails in
   |and generic lambdas |template functions and
   ||generic lambdas

--- Comment #1 from Andrew Pinski  ---
This feature was only added to C++ in C++17 :).  Now wonder this is the first
time I heard about it :).

[Bug c++/77912] New: class template deduction fails in template functions and generic lambdas

2016-10-09 Thread jeff.mirwaisi at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77912

Bug ID: 77912
   Summary: class template deduction fails in template functions
and generic lambdas
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeff.mirwaisi at gmail dot com
  Target Milestone: ---

//deduction for the template type parameter of the simple class template below 
//fails when used in a generic context
template struct S{S(T){}}; 

//error: invalid use of template type parameter 'S'
template auto f(T t){return S(t);}

int main()
{
  //fails
  f(42);

  //fails
  //error: invalid use of template type parameter 'S'
  [](auto a){return S(a);}(42); 

  //works
  [](int a){return S(a);}(42);
}

[Bug go/77910] [7 Regression] go: open zversion.go: no such file or directory

2016-10-09 Thread ian at airs dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77910

--- Comment #1 from Ian Lance Taylor  ---
Works for me.

Do you have a copy of the gc toolchain on your computer?  Is the environment
variable GOROOT set?

[Bug ipa/77905] [5/6/7 Regression] ICE at -Os and above in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: in ipa_comdats, at ipa-comdats.c:352)

2016-10-09 Thread marxin at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77905

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-09
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
  Known to work||4.9.4
   Target Milestone|7.0 |5.5
Summary|[7 Regression] ICE at -Os   |[5/6/7 Regression] ICE at
   |and above in both 32-bit|-Os and above in both
   |and 64-bit modes on |32-bit and 64-bit modes on
   |x86_64-linux-gnu (internal  |x86_64-linux-gnu (internal
   |compiler error: in  |compiler error: in
   |ipa_comdats, at |ipa_comdats, at
   |ipa-comdats.c:352)  |ipa-comdats.c:352)
 Ever confirmed|0   |1
  Known to fail||5.1.0

--- Comment #2 from Martin Liška  ---
Confirmed, started with r234267.

[Bug fortran/25829] [F2003] Asynchronous IO support

2016-10-09 Thread jb at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829

Janne Blomqvist  changed:

   What|Removed |Added

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

--- Comment #24 from Janne Blomqvist  ---
Unassigning myself.

[Bug libfortran/67585] Retry system calls failing with EINTR

2016-10-09 Thread jb at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67585

Janne Blomqvist  changed:

   What|Removed |Added

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

--- Comment #4 from Janne Blomqvist  ---
Fixed on trunk, closing.

[Bug libfortran/67585] Retry system calls failing with EINTR

2016-10-09 Thread jb at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67585

--- Comment #3 from Janne Blomqvist  ---
Author: jb
Date: Sun Oct  9 18:05:56 2016
New Revision: 240902

URL: https://gcc.gnu.org/viewcvs?rev=240902=gcc=rev
Log:
PR 67585 Handle EINTR

Many POSIX systems have the bad habit of not restarting interrupted
syscalls. On these systems it's up to the user to check for an error
with errno == EINTR and restart manually. This patch does this for
libgfortran, so that GFortran users don't have to do it.

2016-10-09  Janne Blomqvist  

PR libfortran/67585
* io/io.h: TEMP_FAILURE_RETRY: Define macro if not found.
* io/unix.c (raw_read): Handle EINTR.
(raw_write): Check for return value -1.
(raw_seek): Handle EINTR.
(raw_tell): Likewise.
(raw_size): Likewise.
(raw_truncate): Likewise.
(raw_close): Likewise.
(buf_flush): Call raw_seek instead of lseek.
(buf_read): Likewise.
(buf_write): Likewise.
(fd_to_stream): Handle EINTR.
(tempfile_open): Likewise.
(regular_file2): Likewise.
(compare_file_filename): Likewise.
(find_file): Likewise.
(inquire_sequential): Likewise.
(inquire_direct): Likewise.
(inquire_formatted): Likewise.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/io.h
trunk/libgfortran/io/unix.c

[Bug c++/77896] Object vtable lookups are not hoisted out of loops

2016-10-09 Thread redi at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77896

--- Comment #6 from Jonathan Wakely  ---
(In reply to Ryan Johnson from comment #4)
>puts("\nWorks ok-ish:");
>Jekyl* x = new Jekyl;
>whatami(x);
>puts("\nJekyl?");
>delete x;

I think this would be OK if it did "delete (AlterEgo*)x" ... as written, I'm
not sure.

>puts("\nBad idea:");
>Jekyl j;
>j.toggle();
>j.toggle();
>whatami();

This is undefined, because ~Jekyl is going to run on the stack object at the
end of the scope, but it's not a Jekyl at that point.

The bound member functions extension can be used to avoid repeated vtable
lookups for the same function:
https://gcc.gnu.org/onlinedocs/gcc/Bound-member-functions.html

[Bug c++/77911] Comparing function pointers in a constexpr function can produce an error.

2016-10-09 Thread yhueotnk at pokemail dot net 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77911

--- Comment #1 from Dr Hilbert Swan  ---
Created attachment 39777
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39777=edit
Version that compiles.

[Bug c++/77911] New: Comparing function pointers in a constexpr function can produce an error.

2016-10-09 Thread yhueotnk at pokemail dot net 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77911

Bug ID: 77911
   Summary: Comparing function pointers in a constexpr function
can produce an error.
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yhueotnk at pokemail dot net
  Target Milestone: ---

Created attachment 39776
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39776=edit
Compiler .ii output to reproduce.

I'm attaching two .ii files one that compiles and one one that fails to
compile. There is only one difference between the two files, which is the line:

constexpr unsigned int loc = FindMatchingIdx(, 0);

in the file that compiles, and the file that doesn't compile has:

constexpr unsigned int loc = FindMatchingIdx(, 0);

The difference being  vs 

The code snippet has a constexpr array of function pointers, and then tries to
find a function's index in the array at compile time using the constexpr
function FindMatchingIdx. For some reason the code compiles when
FindMatchingIdx is called with the first element in the array, but fails when
called with any other function in the array.

I've tested this code also on clang and MSVC, where it compiles.

I've used gcc.godbolt.org (https://godbolt.org/g/vunD7M) to test various GCC
builds, and it appears to compile on 4.9.4 but fails on 5.1 and all later
builds.


GCC Version: 6.2.0 20160901 (Ubuntu 6.2.0-3ubuntu11~14.04)
Command line: gcc-6 -v -save-temps -std=c++14 doesnt_compile.cpp


Full gcc output:

swan@pond:/test$ gcc-6 -v -save-temps -std=c++14 doesnt_compile.cpp
Using built-in specs.
COLLECT_GCC=gcc-6
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
6.2.0-3ubuntu11~14.04' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=gcc4-compatible --disable-libstdcxx-dual-abi
--enable-gnu-unique-object --disable-vtable-verify --enable-libmpx
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.2.0 20160901 (Ubuntu 6.2.0-3ubuntu11~14.04)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++14' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/6/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE doesnt_compile.cpp -mtune=generic -march=x86-64
-std=c++14 -fpch-preprocess -fstack-protector -Wformat -Wformat-security -o
doesnt_compile.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/6"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/6/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/6
 /usr/include/x86_64-linux-gnu/c++/6
 /usr/include/c++/6/backward
 /usr/lib/gcc/x86_64-linux-gnu/6/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/6/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++14' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/6/cc1plus -fpreprocessed doesnt_compile.ii
-quiet -dumpbase doesnt_compile.cpp -mtune=generic -march=x86-64 -auxbase
doesnt_compile -std=c++14 -version -fstack-protector -Wformat -Wformat-security
-o doesnt_compile.s
GNU C++14 (Ubuntu 6.2.0-3ubuntu11~14.04) version 6.2.0 20160901
(x86_64-linux-gnu)
compiled by GNU C version 6.2.0 20160901, GMP version 5.1.3, MPFR
version 3.1.3, MPC version 1.0.1, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (Ubuntu 6.2.0-3ubuntu11~14.04) version 6.2.0 20160901
(x86_64-linux-gnu)
compiled by GNU C version 6.2.0 20160901, GMP version 5.1.3, MPFR
version 3.1.3, MPC version 1.0.1, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum:

[Bug go/77910] New: [7 Regression] go: open zversion.go: no such file or directory

2016-10-09 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77910

Bug ID: 77910
   Summary: [7 Regression] go: open zversion.go: no such file or
directory
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: trippels at gcc dot gnu.org
CC: cmang at google dot com
  Target Milestone: ---

I cannot use "go build" anymore on trunk, e.g.:

markus@x4 demangle % go build -gccgoflags "-O2" -x c++filt.go
WORK=/tmp/go-build321763336
go: open zversion.go: no such file or directory

If I comment out the code in libgo/go/cmd/go/pkg.go in computeBuildID() I get:

markus@x4 demangle % go build -gccgoflags "-O2" -x c++filt.go
WORK=/tmp/go-build762259913
panic: runtime error: slice bounds out of range

goroutine 16 [running]:
main.disallowInternal
../../gcc/gotools/../libgo/go/cmd/go/pkg.go:545
main.loadImport
../../gcc/gotools/../libgo/go/cmd/go/pkg.go:385
main.load.pN12_main.Package
../../gcc/gotools/../libgo/go/cmd/go/pkg.go:955
main.loadImport
../../gcc/gotools/../libgo/go/cmd/go/pkg.go:378
main.load.pN12_main.Package
../../gcc/gotools/../libgo/go/cmd/go/pkg.go:955
main.loadImport
../../gcc/gotools/../libgo/go/cmd/go/pkg.go:378
main.load.pN12_main.Package
../../gcc/gotools/../libgo/go/cmd/go/pkg.go:955
main.goFilesPackage
../../gcc/gotools/../libgo/go/cmd/go/build.go:838
main.packagesAndErrors
../../gcc/gotools/../libgo/go/cmd/go/pkg.go:1698
main.packagesForBuild
../../gcc/gotools/../libgo/go/cmd/go/pkg.go:1730
main.runBuild
../../gcc/gotools/../libgo/go/cmd/go/build.go:448
main.main
../../gcc/gotools/../libgo/go/cmd/go/main.go:181

goroutine 18 [finalizer wait]:
created by
../../../gcc/libgcc/config/i386/morestack.S:544

goroutine 19 [syscall]:
goroutine in C code; stack unavailable
created by os_signal..import
../../../gcc/libgo/go/os/signal/signal_unix.go:26
markus@x4 demangle % 

gcc-6 works fine.

[Bug c/77909] New: -Wimplicit-fallthrough: accept more comment variants

2016-10-09 Thread marc.mutz at kdab dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77909

Bug ID: 77909
   Summary: -Wimplicit-fallthrough: accept more comment variants
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marc.mutz at kdab dot com
  Target Milestone: ---

In QtBase, we have several unrecognised forms of fall-through comments, which
are quite common, and probably should be recognized, too:

- interpunctation: "fall through" followed by [;:!]

- prefix with "else", "otherwise", or "intentionl(ly)"

- "no break" instead of "fall through"

[Bug lto/77821] C++ binary size increase or LTO not working?

2016-10-09 Thread tulipawn at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77821

--- Comment #8 from PeteVine  ---
Nah, the whole issue's just some sort of build-system artifact, namely,
switching to cmake:

$ du ufo*cmake*
2076ufo-gcc4.9-lto-cmake
2140ufo-gcc4.9-nonlto-cmake
2064ufo-gcc7-lto-cmake
2124ufo-gcc7-nonlto-cmake

Note how the binaries got smaller but 4.9 was not able to match the previously
smallest size. Due to the different build system could be apples and oranges,
though. (-O2 seems to be enforced here, just noticed)

[Bug fortran/38592] eliminate some string comparisons

2016-10-09 Thread tkoenig at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38592

--- Comment #7 from Thomas Koenig  ---
We still do the comparison, although with memcmp now.

More interesting question is if we could/should do
forward propagation of values in the front end,
or if this is something that the middle-end should,
in principle, do.

[Bug tree-optimization/77901] ICE in tree-sse-reassoc,c:2881

2016-10-09 Thread jakub at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77901

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Sun Oct  9 11:18:53 2016
New Revision: 240899

URL: https://gcc.gnu.org/viewcvs?rev=240899=gcc=rev
Log:
PR tree-optimization/77901
* tree-ssa-reassoc.c (optimize_range_tests_var_bound): Only optimize
if ranges[i].exp is SSA_NAME when looking for >= and only when
ranges[i].exp is NULL or SSA_NAME when looking for the other
comparison.

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

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr77901.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-reassoc.c

[Bug fortran/77908] Array operation fails for arrays with "long" indices

2016-10-09 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77908

--- Comment #2 from Dominique d'Humieres  ---
The diff between the original dump with -m32 and -m64 gives

--- pr77908.f90.003t.original   2016-10-09 11:54:56.0 +0200
+++ pr77908.f90_64.003t.original2016-10-09 11:53:59.0 +0200
@@ -14,13 +14,12 @@ error_index_long ()
 _gfortran_st_write_done (_parm.0);
   }
   {
-integer(kind=4) S.1;
+integer(kind=8) S.1;

-S.1 = -11;
+S.1 = 9223372036854775797;
 while (1)
   {
-if (S.1 >= 0) goto L.1;
-value[S.1 + 11] = 1;
+value[S.1 + -9223372036854775797] = 1;
 S.1 = S.1 + 1;
   }
 L.1:;
@@ -40,11 +39,11 @@ error_index_long ()
   struct array1_integer(kind=4) parm.3;

   parm.3.dtype = 265;
-  parm.3.dim[0].lbound = -11;
-  parm.3.dim[0].ubound = -1;
+  parm.3.dim[0].lbound = 9223372036854775797;
+  parm.3.dim[0].ubound = 9223372036854775807;
   parm.3.dim[0].stride = 1;
   parm.3.data = (void *) [0];
-  parm.3.offset = 11;
+  parm.3.offset = -9223372036854775797;
   _gfortran_transfer_array_write (_parm.2, , 4, 0);
 }
 _gfortran_st_write_done (_parm.2);

Note that the exit condition

if (S.1 >= 0) goto L.1;

is missing when the test is compiled with -m64.

[Bug c++/77907] [6/7 Regression] Add "const" to argument of constexpr constructor causes the object to be left in unconstructed state

2016-10-09 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77907

--- Comment #3 from Markus Trippelsdorf  ---
Here's a runnable testcase:

struct SomeClass {
  int someFunction() { return 1; }
};

struct SomeFunctor {
  using MemberFunction = int (SomeClass::*)();

  constexpr explicit SomeFunctor(const MemberFunction memberFunction)
  : memberFunction_{memberFunction} {}

  MemberFunction memberFunction_;
};

SomeFunctor functor{::someFunction};

int main() {
  if (!functor.memberFunction_)
__builtin_abort();
}


Interestingly the issue was fixed for -std=c++1z on trunk only yesterday:

commit c821ae1a57320c4b1ba47afef6136b534f830351
Author: jason 
Date:   Sat Oct 8 16:23:26 2016 +

Further P0135 refinement.

[Bug fortran/77908] Array operation fails for arrays with "long" indices

2016-10-09 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77908

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed on x86_64-apple-darwin15 from 4.8 up to trunk (7.0) when the test is
compiled with -m64

 Running ...

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

I get the expected results if I compile the test with -m32.

[Bug fortran/77908] New: Array operation fails for arrays with "long" indices

2016-10-09 Thread arjen.markus895 at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77908

Bug ID: 77908
   Summary: Array operation fails for arrays with "long" indices
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arjen.markus895 at gmail dot com
  Target Milestone: ---

Experimenting with array indices of non-default kind - "long" or "large"
integers - I happened to stumble on the following problem:

array operations on such arrays cause the program to stop prematurely.

Here is a minimal program that exhibits this behaviour:



! error_index_long --
! Using "long" integers as indices fails
!
program error_index_long
implicit none

integer, parameter :: long =
selected_int_kind(range(1)+1)
integer(kind=long), parameter  :: bignumber = huge(1_long)

integer, dimension(bignumber-10:bignumber) :: value

write(*,*) 'Running ...'

value = 1

write(*, '(a,11i5)') 'Values: ', value

write(*,*) 'Done'

end program error_index_long



Using Cygwin on Windows 7, I see the following behaviour:
- The program is accepted by the compiler
- The program starts and prints "Running ..." but then it stops. The final text
is not printed.

If I turn the array operation "value = 1" into a loop, it does work.

[Bug c++/77907] [6/7 Regression] Add "const" to argument of constexpr constructor causes the object to be left in unconstructed state

2016-10-09 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77907

Markus Trippelsdorf  changed:

   What|Removed |Added

 Target|x86_64-pc-linux-gnu,|
   |arm-none-eabi   |
 Status|UNCONFIRMED |NEW
  Known to work||5.3.0
   Keywords||wrong-code
   Last reconfirmed||2016-10-09
 CC||jason at gcc dot gnu.org,
   ||trippels at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|Add "const" to argument of  |[6/7 Regression] Add
   |constexpr constructor   |"const" to argument of
   |causes the object to be |constexpr constructor
   |left in unconstructed state |causes the object to be
   ||left in unconstructed state
  Known to fail||6.2.1, 7.0
   Severity|critical|normal

--- Comment #2 from Markus Trippelsdorf  ---
Started with r230365:

commit d2c638268e30dea7631ca2ee9b7489da2317526b
Author: jason 
Date:   Sat Nov 14 00:08:05 2015 +

Merge C++ delayed folding branch.

[Bug c/77817] -Wimplicit-fallthrough: cpp directive renders FALLTHRU comment ineffective

2016-10-09 Thread marc.mutz at kdab dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77817

Marc Mutz  changed:

   What|Removed |Added

 CC||marc.mutz at kdab dot com

--- Comment #8 from Marc Mutz  ---
I see the same in conditional code. Example fix that I applied to Qt locally,
but won't push, because the next compiler will warn that the *comment is
bogus*: 

   case QVariant::Bool:
   return qulonglong(d->data.b);
   #ifndef QT_BOOTSTRAPPED
   case QMetaType::QJsonValue:
   if (!v_cast(d)->isDouble())
   break;
  -// fall through
   #endif
  +// fall through
   case QVariant::Double:

We have about a dozen of those in QtBase alone, and while Qt 5.8 has a macro
for the attribute, the 5.6 LTS version does not, and still has >2 years of
support ahead of it, so a comment solution would be strongly preferred, and it
would *really* help if this was fixed before this version of the compiler went
into production.

[Bug c++/77907] Add "const" to argument of constexpr constructor causes the object to be left in unconstructed state

2016-10-09 Thread freddie_chopin at op dot pl 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77907

--- Comment #1 from Freddie Chopin  ---
Maybe it is important to add, that it doesn't matter whether
SomeClass::someFunction() is const or not - it behaves identically in both
cases.

[Bug c++/77907] New: Add "const" to argument of constexpr constructor causes the object to be left in unconstructed state

2016-10-09 Thread freddie_chopin at op dot pl 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77907

Bug ID: 77907
   Summary: Add "const" to argument of constexpr constructor
causes the object to be left in unconstructed state
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: freddie_chopin at op dot pl
  Target Milestone: ---
Target: x86_64-pc-linux-gnu, arm-none-eabi

Failing test case:

--- 8< --- 8< --- 8< --- 8< --- 8< --- 8< ---
$ cat test.cpp 
struct SomeClass
{
void someFunction() {}
};

struct SomeFunctor
{
using MemberFunction = void(SomeClass::*)();

constexpr explicit SomeFunctor(const MemberFunction memberFunction) :
memberFunction_{memberFunction}
{

}

MemberFunction memberFunction_;
};

extern SomeFunctor functor;
SomeFunctor functor {::someFunction};
$ g++ test.cpp -c -O2 -std=c++11
$ objdump -SD --demangle test.o

test.o: file format elf64-x86-64


Disassembly of section .bss:

 :
...

Disassembly of section .comment:

 <.comment>:
   0:   00 47 43add%al,0x43(%rdi)
   3:   43 3a 20rex.XB cmp (%r8),%spl
   6:   28 47 4esub%al,0x4e(%rdi)
   9:   55  push   %rbp
   a:   29 20   sub%esp,(%rax)
   c:   36 2e 31 2e ss xor %ebp,%cs:(%rsi)
  10:   31 20   xor%esp,(%rax)
  12:   32 30   xor(%rax),%dh
  14:   31 36   xor%esi,(%rsi)
  16:   30 36   xor%dh,(%rsi)
  18:   30 32   xor%dh,(%rdx)
...
--- 8< --- 8< --- 8< --- 8< --- 8< --- 8< ---

As you can see the object get's placed in .bss section and no constructor is
generated - the object will have only zeroes in the program. The thing that
causes the problem here is the "const" added to the "memberFunction" argument
of the constructor. If I remove it, then I get the properly constructed object
in .data section.

--- 8< --- 8< --- 8< --- 8< --- 8< --- 8< ---
$ cat test.cpp 
struct SomeClass
{
void someFunction() {}
};

struct SomeFunctor
{
using MemberFunction = void(SomeClass::*)();

constexpr explicit SomeFunctor(/*const*/ MemberFunction memberFunction)
:
memberFunction_{memberFunction}
{

}

MemberFunction memberFunction_;
};

extern SomeFunctor functor;
SomeFunctor functor {::someFunction};
$ g++ test.cpp -c -O2 -std=c++11
$ objdump -SD --demangle test.o

test.o: file format elf64-x86-64


Disassembly of section .group:

 <.group>:
   0:   01 00   add%eax,(%rax)
   2:   00 00   add%al,(%rax)
   4:   06  (bad)  
   5:   00 00   add%al,(%rax)
...

Disassembly of section .data:

 :
...

Disassembly of section .text._ZN9SomeClass12someFunctionEv:

 :
   0:   f3 c3   repz retq 

Disassembly of section .comment:

 <.comment>:
   0:   00 47 43add%al,0x43(%rdi)
   3:   43 3a 20rex.XB cmp (%r8),%spl
   6:   28 47 4esub%al,0x4e(%rdi)
   9:   55  push   %rbp
   a:   29 20   sub%esp,(%rax)
   c:   36 2e 31 2e ss xor %ebp,%cs:(%rsi)
  10:   31 20   xor%esp,(%rax)
  12:   32 30   xor(%rax),%dh
  14:   31 36   xor%esi,(%rsi)
  16:   30 36   xor%dh,(%rsi)
  18:   30 32   xor%dh,(%rdx)
...

Disassembly of section .eh_frame:

 <.eh_frame>:
   0:   14 00   adc$0x0,%al
   2:   00 00   add%al,(%rax)
   4:   00 00   add%al,(%rax)
   6:   00 00   add%al,(%rax)
   8:   01 7a 52add%edi,0x52(%rdx)
   b:   00 01   add%al,(%rcx)
   d:   78 10   js 1f <.eh_frame+0x1f>
   f:   01 1b   add%ebx,(%rbx)
  11:   0c 07   or $0x7,%al
  13:   08 90 01 00 00 14   or %dl,0x1401(%rax)
  19:   00 00   add%al,(%rax)
  1b:   00 1c 00add%bl,(%rax,%rax,1)
  1e:   00 00   add%al,(%rax)
  20:   00 00   add%al,(%rax)
  22:   00 00   add%al,(%rax)
  24:   02 00   add(%rax),%al
...
--- 8< --- 8< --- 8< --- 8< --- 8< --- 8< ---

If I remove "constexpr" from the

[Bug rtl-optimization/60818] ICE in validate_condition_mode on powerpc*-linux-gnu*

2016-10-09 Thread segher at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60818

--- Comment #11 from Segher Boessenkool  ---
It's on my radar.  All bugs can be fixed during stage3.

[Bug c++/77434] warn about suspicious precedence of ternary operator (?:)

2016-10-09 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77434

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #13 from Andrew Pinski  ---
Fixed.

[Bug c++/77906] ICE at -Os and above in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: in ipa_comdats, at ipa-comdats.c:352)

2016-10-09 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77906

--- Comment #3 from Andrew Pinski  ---
(In reply to Chengnian Sun from comment #2)
> Sorry for the duplicate. I got a gateway error during the submission, thus
> resubmitting the bug. But it turned out that both reports went through.

It is ok, I have been having issues with bugzilla today also.

[Bug c++/77906] ICE at -Os and above in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: in ipa_comdats, at ipa-comdats.c:352)

2016-10-09 Thread chengniansun at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77906

Chengnian Sun  changed:

   What|Removed |Added

 CC||chengniansun at gmail dot com

--- Comment #2 from Chengnian Sun  ---
Sorry for the duplicate. I got a gateway error during the submission, thus
resubmitting the bug. But it turned out that both reports went through.