[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 --- Comment #27 from Jürgen Reuter juergen.reuter at desy dot de --- And Example #2 is: module foo type :: t integer :: n character(32), dimension(:), allocatable :: md5 contains procedure :: init = t_init end type t contains subroutine t_init (this) class(t), intent(inout) :: this character(32), dimension(:), allocatable :: md5 allocate (md5 (this%n), source=this%md5) end subroutine t_init end module foo $ gfortran -c bar.f90 bar.f90:14:0: allocate (md5 (this%n), source=this%md5) 1 internal compiler error: Segmentation fault: 11 dreck.f90:14:0: internal compiler error: Abort trap: 6 gfortran: internal compiler error: Abort trap: 6 (program f951)
[Bug libstdc++/65861] libstdc++ is silently generating wrong code when its std::search is given an input iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65861 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- And even if they don't read the libstdc++ documentation, std::search doesn't work with input iterators, that's always been true: https://www.sgi.com/tech/stl/search.html http://en.cppreference.com/w/cpp/algorithm/search The code is simply broken and should be fixed.
[Bug libstdc++/65861] New: libstdc++ is silently generating wrong code when its std::search is given an input iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65861
Bug ID: 65861
Summary: libstdc++ is silently generating wrong code when its
std::search is given an input iterator
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: howarth.at.gcc at gmail dot com
While porting rstudio 0.98.1103 to build under clang/libc++, I uncovered a
defect in the libstdc++ handling of input iterators by std::search
(https://llvm.org/bugs/show_bug.cgi?id=23307). The reduced test case is
silently generating wrong code when its std::search is given an input iterator
(it assumes it can save the iterator position and backtrack).
#include string
#include iterator
#include algorithm
void f(std::istream s, std::string x) {
std::istreambuf_iteratorchar eod;
std::search(std::istreambuf_iteratorchar(s),
eod,
x.begin(),
x.end());
}
Clang with libc++ properly rejects this with the error...
In file included from test3.cpp:1:
In file included from
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/string:439:
In file included from
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/algorithm:628:
In file included from
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:604:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/iterator:849:22:
error:
implicit instantiation of undefined template
'std::__1::basic_istreamchar, std::__1::char_traitschar '
: __sbuf_(__s.rdbuf()) {}
^
test3.cpp:6:19: note: in instantiation of member function
'std::__1::istreambuf_iteratorchar,
std::__1::char_traitschar ::istreambuf_iterator' requested here
std::search(std::istreambuf_iteratorchar(s),
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/iosfwd:109:33:
note:
template is declared here
class _LIBCPP_TYPE_VIS_ONLY basic_istream;
^
In file included from test3.cpp:1:
In file included from
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/string:439:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/algorithm:1572:12:
error:
no matching function for call to '__search'
return _VSTD::__searchtypename
add_lvalue_reference_BinaryPredicate::type
^~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__config:358:15:
note:
expanded from macro '_VSTD'
#define _VSTD std::_LIBCPP_NAMESPACE
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/algorithm:1586:19:
note:
in instantiation of function template specialization
'std::__1::searchstd::__1::istreambuf_iteratorchar,
std::__1::char_traitschar , std::__1::__wrap_iterchar *,
std::__1::__equal_tochar, char ' requested here
return _VSTD::search(__first1, __last1, __first2, __last2, __equal_to__v1,
__v2());
^
test3.cpp:6:12: note: in instantiation of function template specialization
'std::__1::searchstd::__1::istreambuf_iteratorchar,
std::__1::char_traitschar , std::__1::__wrap_iterchar *
' requested here
std::search(std::istreambuf_iteratorchar(s),
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/algorithm:1456:1:
note:
candidate function [with _BinaryPredicate = std::__1::__equal_tochar,
char , _RandomAccessIterator1 =
std::__1::istreambuf_iteratorchar, std::__1::char_traitschar ,
_RandomAccessIterator2 =
std::__1::__wrap_iterchar *] not viable: no known conversion from
'typename
std::iterator_traitsistreambuf_iteratorchar, char_traitschar
::iterator_category'
(aka 'std::__1::input_iterator_tag') to
'std::__1::random_access_iterator_tag' for 6th argument
__search(_RandomAccessIterator1 __first1, _RandomAccessIterator1 __last1,
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/algorithm:1419:1:
note:
candidate function [with _BinaryPredicate = std::__1::__equal_tochar,
char , _ForwardIterator1 =
std::__1::istreambuf_iteratorchar, std::__1::char_traitschar ,
_ForwardIterator2 = std::__1::__wrap_iterchar
*] not viable: no known conversion from 'typename
std::iterator_traitsistreambuf_iteratorchar, char_traitschar
[Bug inline-asm/65859] Optimizes out TLS variable called in a child function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65859 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- You need to mark the variable as used by using the used attribute as the compiler has no way seeing the variable as being used in the inline-asm.
[Bug preprocessor/65860] New: Stringification of User Defined Literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65860 Bug ID: 65860 Summary: Stringification of User Defined Literals Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: marcin.konarski at codestation dot org Sample session explaining problem with stringification of UDLs. As you can see if preprocessor is run with -std=c++11 switch it fails to properly stringify tokens that semantically are user defined literals. [amok@vegeta](2/3)~/$ cat s.cxx #define sr( x ) #x #define s( x ) sr( x ) s( 13_udl ); #define SR( ... ) # __VA_ARGS__ #define S( ... ) SR( __VA_ARGS__ ) S( aaa, 7 x, 13_udl, foo( 13 ), bbb ); [amok@vegeta](2/3)~/$ cpp -E s.cxx # 1 s.cxx # 1 built-in # 1 command-line # 1 /usr/include/stdc-predef.h 1 3 4 # 1 command-line 2 # 1 s.cxx \13\_udl; \aaa\, 7 x, \13\_udl, foo( 13 ), \bbb\; [amok@vegeta](2/3)~/$ cpp -E -std=c++11 s.cxx # 1 s.cxx # 1 built-in # 1 command-line # 1 /usr/include/stdc-predef.h 1 3 4 # 1 command-line 2 # 1 s.cxx 13_udl; \aaa\, 7 x, 13_udl, foo( 13 ), \bbb\; [amok@vegeta](2/3)~/$ I would expect both outputs to be the same.
[Bug libstdc++/65861] libstdc++ is silently generating wrong code when its std::search is given an input iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65861 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- This is user error, std::search() requires forward iterators and the library is not required to diagnose it. Defining _GLIBCXX_CONCEPT_CHECKS causes it to be rejected.
[Bug libstdc++/65861] libstdc++ is silently generating wrong code when its std::search is given an input iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65861 --- Comment #4 from Jack Howarth howarth.at.gcc at gmail dot com --- (In reply to Jonathan Wakely from comment #2) This is user error, std::search() requires forward iterators and the library is not required to diagnose it. Defining _GLIBCXX_CONCEPT_CHECKS causes it to be rejected. Also, is there a simple fix to the test case which avoids the user error or does the code have to be rewritten in a major way.
[Bug c++/50800] Internal compiler error in finish_member_declarations, possibly related to may_alias attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50800 --- Comment #13 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Apr 23 15:55:21 2015 New Revision: 222377 URL: https://gcc.gnu.org/viewcvs?rev=222377root=gccview=rev Log: PR c++/50800 * tree.c (strip_typedefs): Add remove_attributes parm. (strip_typedefs_expr): Likewise. (apply_identity_attributes): New subroutine of strip_typedefs. * pt.c (canonicalize_type_argument): Let strip_typedefs handle attrs. (convert_nontype_argument, unify): Likewise. * cp-tree.h: Adjust. Added: trunk/gcc/testsuite/g++.dg/ext/attrib50.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c trunk/gcc/cp/tree.c trunk/gcc/testsuite/g++.dg/abi/mangle40.C trunk/gcc/testsuite/g++.dg/ext/alias-canon2.C trunk/gcc/testsuite/g++.dg/ext/alias-mangle.C
[Bug target/26702] .size is not emitted for BSS variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26702 --- Comment #11 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Author: ramana Date: Thu Apr 23 14:49:45 2015 New Revision: 222371 URL: https://gcc.gnu.org/viewcvs?rev=222371root=gccview=rev Log: Fix PR target/26702 For Kwok Cheung Yeung. Added: trunk/gcc/testsuite/gcc.target/arm/pr26702.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/unknown-elf.h trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/65861] libstdc++ is silently generating wrong code when its std::search is given an input iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65861 --- Comment #3 from Jack Howarth howarth.at.gcc at gmail dot com --- (In reply to Jonathan Wakely from comment #2) This is user error, std::search() requires forward iterators and the library is not required to diagnose it. Defining _GLIBCXX_CONCEPT_CHECKS causes it to be rejected. Is the use of _GLIBCXX_CONCEPT_CHECKS well enough advertised in the documentation that we can expect the average developer to know to invoke it?
[Bug preprocessor/65860] Stringification of User Defined Literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65860 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-23 CC||emsr at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 --- Comment #28 from Dominique d'Humieres dominiq at lps dot ens.fr --- And Example #2 is: ... Confirmed too, but no ICE under debugger.
[Bug rtl-optimization/65862] [MIPS] IRA/LRA issue: integers spilled to floating-point registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65862 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- The kernel should have been compiled with -msoft-float and I thought it was.
[Bug c++/65646] [5 Regression] ICE in invalid syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65646 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Apr 23 15:55:11 2015 New Revision: 222376 URL: https://gcc.gnu.org/viewcvs?rev=222376root=gccview=rev Log: PR c++/65646 * pt.c (check_explicit_specialization): Don't SET_DECL_TEMPLATE_SPECIALIZATION for a variable with no template headers. * decl.c (grokvardecl): Revert earlier fix. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/pt.c
[Bug rtl-optimization/65862] New: [MIPS] IRA/LRA issue: integers spilled to floating-point registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65862
Bug ID: 65862
Summary: [MIPS] IRA/LRA issue: integers spilled to
floating-point registers
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: robert.suchanek at imgtec dot com
CC: matthew.fortune at imgtec dot com, vmakarov at redhat dot
com,
wdijkstr at arm dot com
Following up the following thread:
https://gcc.gnu.org/ml/gcc/2015-04/msg00239.html
Here is a reduced testcase from the Linux kernel:
$ cat sort.c
int a, c;
int *b;
void
fn1(int p1, int *p2(void *, void *), void *p3(void *, void *, int)) {
int n = c;
for (;;) {
a = 1;
for (; a n;) {
p1 p2(0, (int *) (p1 + 1));
p3(0, b + p1, 0);
}
}
}
Spill/reload to/from FP reg should be triggerable with (tested on SVN rev.
57):
$ mips-img-linux-gnu -mips32r6 -O2 sort.c
Because of ALL_REGS assigned to most of allocnos, LRA uses FP regs freely. The
class is preferred because of the equal cost between registers and memory. This
likely happened because of the following fix:
2011-12-20 Vladimir Makarov vmaka...@redhat.com
PR target/49865
* ira-costs.c (find_costs_and_classes): Prefer registers even
if the memory cost is the same.
As Matthew already pointed out, one way to prevent this is through increasing
the cost of moving between GP and FP registers for integral modes.
I briefly tested out Wilco's patch but it did not appear to have the same
effect as changing the cost and I've seen a few ICEs when building the kernel.
[Bug target/26702] .size is not emitted for BSS variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26702 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||ramana at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #12 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Fixed -
[Bug libstdc++/65861] libstdc++ is silently generating wrong code when its std::search is given an input iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65861 --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- https://gcc.gnu.org/onlinedocs/libstdc++/manual/ext_compile_checks.html
[Bug c++/65856] -Wsuggest-override shall not report a warning on final method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65856 --- Comment #8 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Helfer Thomas from comment #7) can you give me the rationale of this usage ? Performance. See also -Wsuggest-final-types -Wsuggest-final-methods in the gcc manual. Although Stroustrup recommends to not use final blindly, without prior measurements (20.3.4.2., TC++PL 4th edition).
[Bug bootstrap/65863] GCC does not compile with weird error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65863 --- Comment #1 from Victor Porton porton at narod dot ru --- Linux victor.local 3.10-2-amd64 #1 SMP Debian 3.10.7-1 (2013-08-17) x86_64 GNU/Linux with 32 bit userland
[Bug bootstrap/65865] [6 Regression] Bootstrap failure on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65865 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-23 CC||jason at redhat dot com Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- It is caused by r222377.
[Bug c++/65856] -Wsuggest-override shall not report a warning on final method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65856 --- Comment #7 from Helfer Thomas thomas.helfer at cea dot fr --- can you give me the rationale of this usage ?
[Bug rtl-optimization/65862] [MIPS] IRA/LRA issue: integers spilled to floating-point registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65862 --- Comment #2 from Robert Suchanek robert.suchanek at imgtec dot com --- That's correct. It was just easier to expose this problem by compiling the kernel.
[Bug bootstrap/65865] New: [6 Regression] Bootstrap failure on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65865
Bug ID: 65865
Summary: [6 Regression] Bootstrap failure on x86
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
On Linux/x86, r222380 gave
libtool: compile: /export/build/gnu/gcc/build-x86_64-linux/./gcc/xgcc
-shared-libgcc -B/export/build/gnu/gcc/build-x86_64-linux/./gcc -nostdinc++
-L/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libstdc++-v3/src
-L/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs
-L/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/.libs
-B/usr/gcc-6.0.0/x86_64-unknown-linux-gnu/bin/
-B/usr/gcc-6.0.0/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/gcc-6.0.0/x86_64-unknown-linux-gnu/include -isystem
/usr/gcc-6.0.0/x86_64-unknown-linux-gnu/sys-include -m32 -D_GNU_SOURCE -D_DEBUG
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-DHAVE_RPC_XDR_H=1 -DHAVE_TIRPC_RPC_XDR_H=0 -I.
-I/export/gnu/import/git/sources/gcc/libsanitizer/sanitizer_common -I.. -I
/export/gnu/import/git/sources/gcc/libsanitizer/include -isystem
/export/gnu/import/git/sources/gcc/libsanitizer/include/system -Wall -W
-Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC
-fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables
-fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include
-I../../libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/export/gnu/import/git/sources/gcc/libsanitizer/../libstdc++-v3/libsupc++
-std=gnu++11 -DSANITIZER_LIBBACKTRACE -DSANITIZER_CP_DEMANGLE -I
/export/gnu/import/git/sources/gcc/libsanitizer/../libbacktrace -I
../libbacktrace -I /export/gnu/import/git/sources/gcc/libsanitizer/../include
-include
/export/gnu/import/git/sources/gcc/libsanitizer/libbacktrace/backtrace-rename.h
-O2 -g -D_GNU_SOURCE -m32 -MT sanitizer_linux_libcdep.lo -MD -MP -MF
.deps/sanitizer_linux_libcdep.Tpo -c
/export/gnu/import/git/sources/gcc/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc
-fPIC -DPIC -o .libs/sanitizer_linux_libcdep.o
/export/gnu/import/git/sources/gcc/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:
In function ‘void __sanitizer::InitTlsSize()’:
/export/gnu/import/git/sources/gcc/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:173:29:
error: invalid conversion from ‘get_tls_func {aka void (__attribute__((stdcall,
regparm(3))) *)(unsigned int*, unsigned int*)}’ to ‘void (*)(unsigned int*,
unsigned int*)’ [-fpermissive]
IndirectExternCall(get_tls)(tls_size, tls_align);
^
In file included from
/export/gnu/import/git/sources/gcc/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:16:0:
/export/gnu/import/git/sources/gcc/libsanitizer/sanitizer_common/sanitizer_common.h:529:3:
note: initializing argument 1 of ‘F __sanitizer::IndirectExternCall(F) [with
F = void (*)(unsigned int*, unsigned int*)]’
F IndirectExternCall(F f) {
^
make[8]: *** [sanitizer_linux_libcdep.lo] Error 1
[Bug c/65864] Consider emitting -Wswitch-bool less aggressively?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65864 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- I think they should simply cast the controlling expression to int--that should quash the warning. Does this workaround sound reasonable to them?
[Bug ipa/65858] ICE in varpool_node::get_constructor during chromium build on arm-linux-gnueabihf with LTO during LINK chrome
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65858 --- Comment #1 from Jan Hubicka hubicka at gcc dot gnu.org --- Those two bugs seems to be caused by same issue. Unforutnately it is bit hard to guess what it is coming from - it seems that we manage to store error_mark_node into the LTO object file. If you can patch your GCC tree, the following (untested) patch should bring the ICE from link time to compile time making it easier to reproduce (I build chromium on x86_64 and did not see this crash) Index: lto-streamer-out.c === --- lto-streamer-out.c (revision 222160) +++ lto-streamer-out.c (working copy) @@ -2149,6 +2149,7 @@ /* Output DECL_INITIAL for the function, which contains the tree of lexical scopes. */ stream_write_tree (ob, DECL_INITIAL (var), true); + gcc_assert (DECL_INITIAL (var) != error_mark_node); /* Create a section to hold the pickled output of this function. */ produce_asm (ob, var);
[Bug c/65864] New: Consider emitting -Wswitch-bool less aggressively?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65864
Bug ID: 65864
Summary: Consider emitting -Wswitch-bool less aggressively?
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org
Consider the following function from the linux kernel (fs/nfs/nfs4proc.c):
int nfs4_proc_get_rootfh(struct nfs_server *server, struct nfs_fh *fhandle,
struct nfs_fsinfo *info,
bool auth_probe)
{
int status;
switch (auth_probe) {
case false:
status = nfs4_lookup_root(server, fhandle, info);
if (status != -NFS4ERR_WRONGSEC)
break;
default:
status = nfs4_do_find_root_sec(server, fhandle, info);
}
if (status == 0)
status = nfs4_server_capabilities(server, fhandle);
if (status == 0)
status = nfs4_do_fsinfo(server, fhandle, info);
return nfs4_map_errors(status);
}
The kernel guys have reported that the new -Wswitch-bool warns on this code
and, while ugly, it was a deliberate decision to write it that way (they make
'creative' use of the fall-through in the switch).
I wonder whether it makes sense to restrict the -Wswitch-bool warning to the
cases where the switch condition becomes a boolean from a complex expression
(i.e. a 0xff, instead of the probably intended a 0xff) and not warn when
the switch variable is a simple boolean var.
what do you think?
[Bug bootstrap/65863] GCC does not compile with weird error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65863 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Victor Porton from comment #1) Linux victor.local 3.10-2-amd64 #1 SMP Debian 3.10.7-1 (2013-08-17) x86_64 GNU/Linux with 32 bit userland Try configure GCC with ./configure --prefix=/usr/local/stow/gcc-5.1.0 --enable-libada --enable-languages=c,c++,java,lto,objc,ada i686-linux
[Bug c/65345] ICE with _Generic selection on _Atomic int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345 --- Comment #10 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Thu Apr 23 14:35:12 2015 New Revision: 222370 URL: https://gcc.gnu.org/viewcvs?rev=222370root=gccview=rev Log: PR c/65345 * c-decl.c (set_labels_context_r): New function. (store_parm_decls): Call it via walk_tree_without_duplicates. * c-typeck.c (convert_lvalue_to_rvalue): Use create_tmp_var_raw instead of create_tmp_var. Build TARGET_EXPR instead of COMPOUND_EXPR. (build_atomic_assign): Use create_tmp_var_raw instead of create_tmp_var. Build TARGET_EXPRs instead of MODIFY_EXPR. * gcc.dg/pr65345-1.c: New test. * gcc.dg/pr65345-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr65345-1.c trunk/gcc/testsuite/gcc.dg/pr65345-2.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/65861] libstdc++ is silently generating wrong code when its std::search is given an input iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65861 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Jack Howarth from comment #3) Is the use of _GLIBCXX_CONCEPT_CHECKS well enough advertised in the documentation that we can expect the average developer to know to invoke it? It's documented three times! :-) https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_macros.html https://gcc.gnu.org/onlinedocs/libstdc++/manual/ext_compile_checks.html https://gcc.gnu.org/onlinedocs/libstdc++/manual/concept_checking.html (In reply to Jack Howarth from comment #4) Also, is there a simple fix to the test case which avoids the user error or does the code have to be rewritten in a major way. Don't try to std::search in a streambuf, copy the data elsewhere and search in the copy.
[Bug bootstrap/65863] New: GCC does not compile with weird error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65863 Bug ID: 65863 Summary: GCC does not compile with weird error messages Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: porton at narod dot ru I can't compile gcc-5.1.0 with gcc-4.9.2. ./configure --prefix=/usr/local/stow/gcc-5.1.0 --enable-libada --enable-languages=c,c++,java,lto,objc,ada make[3]: Entering directory '/home/porton/build/gcc-5.1.0/host-x86_64-unknown-linux-gnu/gcc' /home/porton/build/gcc-5.1.0/host-x86_64-unknown-linux-gnu/prev-gcc/xg++ -B/home/porton/build/gcc-5.1.0/host-x86_64-unknown-linux-gnu/prev-gcc/ -B/usr/local/stow/gcc-5.1.0/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/home/porton/build/gcc-5.1.0/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/home/porton/build/gcc-5.1.0/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/home/porton/build/gcc-5.1.0/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/home/porton/build/gcc-5.1.0/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/porton/build/gcc-5.1.0/libstdc++-v3/libsupc++ -L/home/porton/build/gcc-5.1.0/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/porton/build/gcc-5.1.0/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -c -g -O2 -gtoggle -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../.././gcc -I../.././gcc/build -I../.././gcc/../include -I../.././gcc/../libcpp/include \ -o build/genmddeps.o ../.././gcc/genmddeps.c In file included from ./bconfig.h:3:0, from ../.././gcc/genmddeps.c:18: ./auto-host.h:2188:16: error: declaration does not declare anything [-fpermissive] #define rlim_t long ^ In file included from ../.././gcc/genmddeps.c:19:0: ../.././gcc/system.h:465:23: error: conflicting declaration of C function ‘void* sbrk(int)’ extern void *sbrk (int); ^ In file included from ../.././gcc/system.h:277:0, from ../.././gcc/genmddeps.c:19: /usr/include/unistd.h:1043:14: note: previous declaration ‘void* sbrk(intptr_t)’ extern void *sbrk (intptr_t __delta) __THROW; ^ In file included from ../.././gcc/genmddeps.c:19:0: ../.././gcc/system.h:469:48: error: ambiguating new declaration of ‘char* strstr(const char*, const char*)’ extern char *strstr (const char *, const char *); ^ In file included from /home/porton/build/gcc-5.1.0/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/cstring:42:0, from ../.././gcc/system.h:219, from ../.././gcc/genmddeps.c:19: /usr/include/string.h:335:1: note: old declaration ‘const char* strstr(const char*, const char*)’ strstr (const char *__haystack, const char *__needle) __THROW ^ In file included from ../.././gcc/genmddeps.c:19:0: ../.././gcc/system.h:521:34: error: conflicting declaration of C function ‘const char* strsignal(int)’ extern const char *strsignal (int); ^ In file included from /home/porton/build/gcc-5.1.0/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/cstring:42:0, from ../.././gcc/system.h:219, from ../.././gcc/genmddeps.c:19: /usr/include/string.h:564:14: note: previous declaration ‘char* strsignal(int)’ extern char *strsignal (int __sig) __THROW; ^ In file included from ./bconfig.h:5:0, from ../.././gcc/genmddeps.c:18: ../.././gcc/../include/ansidecl.h:171:64: error: ambiguating new declaration of ‘char* basename(const char*)’ # define ATTRIBUTE_NONNULL(m) __attribute__ ((__nonnull__ (m))) ^ ../.././gcc/../include/libiberty.h:112:64: note: in expansion of macro ‘ATTRIBUTE_NONNULL’ extern char *basename (const char *) ATTRIBUTE_RETURNS_NONNULL ATTRIBUTE_NONNULL(1); ^ In file included from /home/porton/build/gcc-5.1.0/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/cstring:42:0, from ../.././gcc/system.h:219, from ../.././gcc/genmddeps.c:19: /usr/include/string.h:601:26: note: old declaration ‘const char* basename(const char*)’ extern C++ const char *basename (const char *__filename) ^ Makefile:2422: recipe for target 'build/genmddeps.o' failed make[3]: *** [build/genmddeps.o] Error 1 make[3]: Leaving directory '/home/porton/build/gcc-5.1.0/host-x86_64-unknown-linux-gnu/gcc' Makefile:4411: recipe for target 'all-stage2-gcc' failed make[2]:
[Bug target/65296] [avr] fix various issues with specs file generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65296 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Keywords||link-failure Status|ASSIGNED|RESOLVED URL||https://savannah.nongnu.org ||/bugs/?44574 Resolution|--- |FIXED --- Comment #11 from Georg-Johann Lay gjl at gcc dot gnu.org --- Fixed in 5.2. Please keep in mind hat this issue is related to https://savannah.nongnu.org/bugs/?44574
[Bug c++/65866] New: Wrong warning when using list-initialization: operation on 'b' may be undefined [-Wsequence-point]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65866
Bug ID: 65866
Summary: Wrong warning when using list-initialization:
operation on 'b' may be undefined [-Wsequence-point]
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: o_kniemeyer at maxon dot net
This is related to Bug 51253: While that bug was about wrong compiled code and
is reported to be fixed, GCC 5.1.0 still produces a warning in code like
struct X
{
template typename... ARGS X(ARGS...);
};
void test()
{
bool b = false;
X{b = true, b = true};
}
warning: operation on 'b' may be undefined [-Wsequence-point]
Because list-initialization has to be done from left to right, the warning is
wrong.
[Bug ada/65868] cannot find -lstdc++ for GNAT compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65868 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Severity|blocker |normal --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Don't build in the source directory. Use an object directory to build gcc.
[Bug target/65867] New: [5 Regression] bootstrap fails for mingw32 due to missing header in ssp.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65867 Bug ID: 65867 Summary: [5 Regression] bootstrap fails for mingw32 due to missing header in ssp.c Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: daniel.f.starke at freenet dot de Created attachment 35392 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35392action=edit patch Bootstrapping gcc 5.1 with ming32 (not mingw32-w64) fails due to missing include of wincrypt.h within ssp.c. See attachment for a possible patch.
[Bug bootstrap/65863] GCC does not compile with weird error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65863 Victor Porton porton at narod dot ru changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Victor Porton porton at narod dot ru --- H.J. Lu: It seems that after changing configure options as you suggested compilation passes after this error. However compilation fails later. I will report another bug.
[Bug fortran/52251] Nonadvancing I/O and the t edit descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52251 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #5 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Working on it.
[Bug c++/65866] Wrong warning when using list-initialization: operation on 'b' may be undefined [-Wsequence-point]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65866 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-23 Ever confirmed|0 |1
[Bug ada/65868] New: cannot find -lstdc++ for GNAT compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65868 Bug ID: 65868 Summary: cannot find -lstdc++ for GNAT compilation Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: porton at narod dot ru Compiling GCC 5.1.0 with GCC 4.9.2. Debian jessie Linux victor.local 3.10-2-amd64 #1 SMP Debian 3.10.7-1 (2013-08-17) x86_64 GNU/Linux with 32 bit userland ./configure --prefix=/usr/local/stow/gcc-5.1.0 --enable-libada --enable-languages=c,c++,java,lto,objc,ada i686-linux make[5]: Leaving directory '/home/porton/build/gcc-5.1.0/i686-linux/libstdc++-v3' make[4]: Leaving directory '/home/porton/build/gcc-5.1.0/i686-linux/libstdc++-v3' make[3]: Leaving directory '/home/porton/build/gcc-5.1.0/i686-linux/libstdc++-v3' make[2]: Leaving directory '/home/porton/build/gcc-5.1.0/i686-linux/libstdc++-v3' make[2]: Entering directory '/home/porton/build/gcc-5.1.0/host-i686-linux/gnattools' # gnattools1 make -C ../gcc/ada/tools -f ../Makefile \ CC=../../xgcc -B../../ CXX=../../xg++ -B../../ -B../../../i686-linux/libstdc++-v3/src/.libs -B../../../i686-linux/libstdc++-v3/libsupc++/.libs -L../../../i686-linux/libstdc++-v3/src/.libs -L../../../i686-linux/libstdc++-v3/libsupc++/.libs CFLAGS=-g -O2 -W -Wall LDFLAGS=-static-libstdc++ -static-libgcc ADAFLAGS=-gnatpg -gnata ADA_CFLAGS= INCLUDES=-I. -I.. -I../.. -I/home/porton/build/gcc-5.1.0/gcc/ada -I/home/porton/build/gcc-5.1.0/gcc/config -I/home/porton/build/gcc-5.1.0/gcc/../include -I/home/porton/build/gcc-5.1.0/gcc ADA_INCLUDES=-I- -I../rts -I. -I/home/porton/build/gcc-5.1.0/gcc/ada exeext= fsrcdir=/home/porton/build/gcc-5.1.0/gcc srcdir=/home/porton/build/gcc-5.1.0/gcc GNATMAKE=../../gnatmake GNATLINK=../../gnatlink GNATBIND=../../gnatbind TOOLSCASE=native \ ../../gnatmake ../../gnatlink make[3]: Entering directory '/home/porton/build/gcc-5.1.0/host-i686-linux/gcc/ada/tools' ../../xg++ -B../../ -B../../../i686-linux/libstdc++-v3/src/.libs -B../../../i686-linux/libstdc++-v3/libsupc++/.libs -L../../../i686-linux/libstdc++-v3/src/.libs -L../../../i686-linux/libstdc++-v3/libsupc++/.libs -static-libstdc++ -static-libgcc -I- -I../rts -I. -I/home/porton/build/gcc-5.1.0/gcc/ada -static-libstdc++ -static-libgcc -DIN_GCC -g -O2 -W -Wall -o ../../gnatmake b_gnatm.o a-except.o ali.o ali-util.o aspects.o s-casuti.o alloc.o atree.o binderr.o butil.o casing.o csets.o debug.o elists.o einfo.o errout.o erroutc.o errutil.o err_vars.o fmap.o fname.o fname-uf.o fname-sf.o gnatmake.o gnatvsn.o hostparm.o interfac.o i-c.o i-cstrin.o krunch.o lib.o make.o makeusg.o makeutl.o mlib.o mlib-fil.o mlib-prj.o mlib-tgt.o mlib-tgt-specific.o mlib-utl.o namet.o nlists.o opt.o osint.o osint-m.o output.o prj.o prj-attr.o prj-attr-pm.o prj-com.o prj-dect.o prj-env.o prj-conf.o prj-pp.o prj-err.o prj-ext.o prj-nmsc.o prj-pars.o prj-part.o prj-proc.o prj-strt.o prj-tree.o prj-util.o restrict.o rident.o s-exctab.o s-secsta.o s-stalib.o s-stoele.o scans.o scng.o sdefault.o sfn_scan.o s-purexc.o s-htable.o scil_ll.o sem_aux.o sinfo.o sinput.o sinput-c.o sinput-p.o snames.o stand.o stringt.o styleg.o stylesw.o system.o validsw.o switch.o switch-m.o table.o targparm.o tempdir.o tree_io.o types.o uintp.o uname.o urealp.o usage.o widechar.o ../link.o ../targext.o ../../ggc-none.o ../../libcommon-target.a ../../libcommon.a ../../../libcpp/libcpp.a ../rts/libgnat.a ../../../libbacktrace/.libs/libbacktrace.a ../../../libiberty/libiberty.a /usr/bin/ld: cannot find -lstdc++ collect2: error: ld returned 1 exit status ../gcc-interface/Makefile:2585: recipe for target '../../gnatmake' failed make[3]: *** [../../gnatmake] Error 1 make[3]: Leaving directory '/home/porton/build/gcc-5.1.0/host-i686-linux/gcc/ada/tools' Makefile:190: recipe for target 'gnattools-native' failed make[2]: *** [gnattools-native] Error 2 make[2]: Leaving directory '/home/porton/build/gcc-5.1.0/host-i686-linux/gnattools' Makefile:11898: recipe for target 'all-gnattools' failed make[1]: *** [all-gnattools] Error 2 make[1]: Leaving directory '/home/porton/build/gcc-5.1.0' Makefile:902: recipe for target 'all' failed make: *** [all] Error 2
[Bug rtl-optimization/65805] [5 Regression] Chromium gets miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65805 --- Comment #6 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Author: vmakarov Date: Thu Apr 23 19:07:52 2015 New Revision: 222383 URL: https://gcc.gnu.org/viewcvs?rev=222383root=gccview=rev Log: 2015-04-23 Vladimir Makarov vmaka...@redhat.com Backport from trunk r23. 2015-04-19 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/65805 * lra-eliminations.c (lra_eliminate_regs_1): Add new assert. Don't use difference of offset and previous offset if update_sp_offset is non-zero. (eliminate_regs_in_insn): Ditto. * lra-spills.c (remove_pseudos): Exchange 4th and 6th args in lra_eliminate_regs_1 call. * lra-constraints.c (get_equiv_with_elimination): Ditto. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/lra-constraints.c branches/gcc-5-branch/gcc/lra-eliminations.c branches/gcc-5-branch/gcc/lra-spills.c
[Bug bootstrap/65865] [6 Regression] Bootstrap failure on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65865
--- Comment #2 from H.J. Lu hjl.tools at gmail dot com ---
[hjl@gnu-6 gcc]$ cat /tmp/x.cc
extern unsigned long indirect_call_wrapper;
typedef unsigned long size_t;
template typename F
F IndirectExternCall(F f) {
typedef F (*WrapF)(F);
return indirect_call_wrapper ? ((WrapF)indirect_call_wrapper)(f) : f;
}
typedef void (*get_tls_func)(size_t*, size_t*) __attribute__((regparm(3),
stdcall));
void
foo (void *get_tls_static_info_ptr)
{
get_tls_func get_tls;
__builtin_memcpy (get_tls, get_tls_static_info_ptr,
sizeof(get_tls_static_info_ptr));
size_t tls_size = 0;
size_t tls_align = 0;
IndirectExternCall (get_tls)(tls_size, tls_align);
}
[hjl@gnu-6 gcc]$ ./xgcc -B./ -S -m32 -O2 /tmp/x.cc
/tmp/x.cc: In function ‘void foo(void*)’:
/tmp/x.cc:21:30: error: invalid conversion from ‘get_tls_func {aka void
(__attribute__((stdcall, regparm(3))) *)(long unsigned int*, long unsigned
int*)}’ to ‘void (*)(long unsigned int*, long unsigned int*)’ [-fpermissive]
IndirectExternCall (get_tls)(tls_size, tls_align);
^
/tmp/x.cc:6:3: note: initializing argument 1 of ‘F IndirectExternCall(F)
[with F = void (*)(long unsigned int*, long unsigned int*)]’
F IndirectExternCall(F f) {
^
[hjl@gnu-6 gcc]$
[Bug bootstrap/65865] [6 Regression] Bootstrap failure on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65865 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- OK, reverted temporarily.
[Bug libquadmath/65757] gfortran gives incorrect result for anint with real*16 argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65757 --- Comment #8 from dhbbugs bugs at dhbailey dot com --- Jerry DeLisl'e output is certainly not correct -- anint should invariably return the nearest whole number. It should be the equivalent of this code: if (x = 0.0) then anint = aint (x + 0.5) else anint = aint (x - 0.5) endif Here aint is the truncated whole number function (a Fortran intrinsic).
[Bug c++/65870] New: Explicit function instantiation with default valued lambda causes duplicate symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65870
Bug ID: 65870
Summary: Explicit function instantiation with default valued
lambda causes duplicate symbol
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: w.shane.grant at gmail dot com
When explicitly instantiating functions with default lambda parameters, g++
generates multiple versions of the lambda with the same symbol names.
I've created a minimal example:
struct Any
{
template class T
Any( T const ){}
};
template class T
void func( T t, Any a = [](){} ){}
template void funcint( int, Any );
template void funcdouble( double, Any );
int main()
{
func( 3 );
func( 3.0 );
return 0;
}
Compiled with g++ -std=c++11 (4.7.4, 4.8.3, and 4.9.1) , this causes the error:
/tmp/ccND7XlM.s:104: Error: symbol `_ZN3AnyC2IUlvE_EERKT_' is already defined
If this is indeed incorrect behavior (I don't know enough about the spec to
confirm this), I believe the problem is that the name mangling for the lambda
is not taking the parent template into account.
[Bug target/65456] powerpc64le autovectorized copy loop missed optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65456
--- Comment #18 from Bill Schmidt wschmidt at gcc dot gnu.org ---
Author: wschmidt
Date: Thu Apr 23 21:03:40 2015
New Revision: 222386
URL: https://gcc.gnu.org/viewcvs?rev=222386root=gccview=rev
Log:
[gcc]
2015-04-23 Bill Schmidt wschm...@linux.vnet.ibm.com
Backport from mainline r222349
2015-04-22 Bill Schmidt wschm...@linux.vnet.ibm.com
PR target/65456
* config/rs6000/rs6000.c (rs6000_option_override_internal): For
VSX + POWER8, enable TARGET_ALLOW_MOVMISALIGN and
TARGET_EFFICIENT_UNALIGNED_VSX if not selected by command line
option.
(rs6000_builtin_mask_for_load): Return 0 for targets with
efficient unaligned VSX accesses so that the vectorizer will use
direct unaligned loads.
(rs6000_builtin_support_vector_misalignment): Always return true
for targets with efficient unaligned VSX accesses.
(rs6000_builtin_vectorization_cost): Cost of unaligned loads and
stores on targets with efficient unaligned VSX accesses is almost
always the same as the cost of an aligned load or store, so model
it that way.
* config/rs6000/rs6000.h (SLOW_UNALIGNED_ACCESS): Return 0 for
unaligned vectors if we have efficient unaligned VSX accesses.
* config/rs6000/rs6000.opt (mefficient-unaligned-vector): New
undocumented option.
[gcc/testsuite]
2015-04-23 Bill Schmidt wschm...@linux.vnet.ibm.com
Backport from mainline r222349
2015-04-22 Bill Schmidt wschm...@linux.vnet.ibm.com
PR target/65456
* gcc.dg/vect/bb-slp-24.c: Exclude test for POWER8.
* gcc.dg/vect/bb-slp-25.c: Likewise.
* gcc.dg/vect/bb-slp-29.c: Likewise.
* gcc.dg/vect/bb-slp-32.c: Replace vect_no_align with
vect_no_align { ! vect_hw_misalign }.
* gcc.dg/vect/bb-slp-9.c: Likewise.
* gcc.dg/vect/costmodel/ppc/costmodel-slp-33.c: Exclude test for
vect_hw_misalign.
* gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c: Likewise.
* gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c: Adjust tests to
account for POWER8, where peeling for alignment is not needed.
* gcc.dg/vect/costmodel/ppc/costmodel-vect-outer-fir.c: Replace
vect_no_align with vect_no_align { ! vect_hw_misalign }.
* gcc.dg.vect.if-cvt-stores-vect-ifcvt-18.c: Likewise.
* gcc.dg/vect/no-scevccp-outer-6-global.c: Likewise.
* gcc.dg/vect/no-scevccp-outer-6.c: Likewise.
* gcc.dg/vect/no-vfa-vect-43.c: Likewise.
* gcc.dg/vect/no-vfa-vect-57.c: Likewise.
* gcc.dg/vect/no-vfa-vect-61.c: Likewise.
* gcc.dg/vect/no-vfa-vect-depend-1.c: Likewise.
* gcc.dg/vect/no-vfa-vect-depend-2.c: Likewise.
* gcc.dg/vect/no-vfa-vect-depend-3.c: Likewise.
* gcc.dg/vect/pr16105.c: Likewise.
* gcc.dg/vect/pr20122.c: Likewise.
* gcc.dg/vect/pr33804.c: Likewise.
* gcc.dg/vect/pr33953.c: Likewise.
* gcc.dg/vect/pr56787.c: Likewise.
* gcc.dg/vect/pr58508.c: Likewise.
* gcc.dg/vect/slp-25.c: Likewise.
* gcc.dg/vect/vect-105-bit-array.c: Likewise.
* gcc.dg/vect/vect-105.c: Likewise.
* gcc.dg/vect/vect-27.c: Likewise.
* gcc.dg/vect/vect-29.c: Likewise.
* gcc.dg/vect/vect-33.c: Exclude unaligned access test for
POWER8.
* gcc.dg/vect/vect-42.c: Replace vect_no_align with vect_no_align
{ ! vect_hw_misalign }.
* gcc.dg/vect/vect-44.c: Likewise.
* gcc.dg/vect/vect-48.c: Likewise.
* gcc.dg/vect/vect-50.c: Likewise.
* gcc.dg/vect/vect-52.c: Likewise.
* gcc.dg/vect/vect-56.c: Likewise.
* gcc.dg/vect/vect-60.c: Likewise.
* gcc.dg/vect/vect-72.c: Likewise.
* gcc.dg/vect/vect-75-big-array.c: Likewise.
* gcc.dg/vect/vect-75.c: Likewise.
* gcc.dg/vect/vect-77-alignchecks.c: Likewise.
* gcc.dg/vect/vect-77-global.c: Likewise.
* gcc.dg/vect/vect-78-alignchecks.c: Likewise.
* gcc.dg/vect/vect-78-global.c: Likewise.
* gcc.dg/vect/vect-93.c: Likewise.
* gcc.dg/vect/vect-95.c: Likewise.
* gcc.dg/vect/vect-96.c: Likewise.
* gcc.dg/vect/vect-cond-1.c: Likewise.
* gcc.dg/vect/vect-cond-3.c: Likewise.
* gcc.dg/vect/vect-cond-4.c: Likewise.
* gcc.dg/vect/vect-cselim-1.c: Likewise.
* gcc.dg/vect/vect-multitypes-1.c: Likewise.
* gcc.dg/vect/vect-multitypes-3.c: Likewise.
* gcc.dg/vect/vect-multitypes-4.c: Likewise.
* gcc.dg/vect/vect-multitypes-6.c: Likewise.
* gcc.dg/vect/vect-nest-cycle-1.c: Likewise.
* gcc.dg/vect/vect-nest-cycle-2.c: Likewise.
* gcc.dg/vect/vect-outer-3a-big-array.c: Likewise.
* gcc.dg/vect/vect-outer-3a.c: Likewise.
* gcc.dg/vect/vect-outer-5.c: Likewise.
* gcc.dg/vect/vect-outer-fir-big-array.c: Likewise.
* gcc.dg/vect/vect-outer-fir-lb-big-array.c: Likewise.
* gcc.dg/vect/vect-outer-fir-lb.c: Likewise.
* gcc.dg/vect/vect-outer-fir.c: Likewise.
* gcc.dg/vect/vect-peel-3.c: Likewise.
* gcc.dg/vect/vect-peel-4.c: Likewise.
* gcc.dg/vect/vect-pre-interact.c: Likewise.
* gcc.target/powerpc/pr65456.c: New
[Bug c++/65869] New: Incorrect overload resolution in function return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65869
Bug ID: 65869
Summary: Incorrect overload resolution in function return
statement
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: botond at mozilla dot com
GCC accepts the following code:
struct Base {};
struct Derived : Base {
Derived();
explicit Derived(const Derived);
explicit Derived(Derived);
explicit Derived(const Base);
Derived(Base);
};
Derived foo() {
Derived result;
return result;
}
int main() {
Derived result = foo();
}
I believe this code is invalid. Here's why:
- [class.copy] p32 specifies that overload resolution
to select the constructor for the copy in the return
statement is to be performed in two stages.
- First, it's performed treating the object to be copied
('result' here) as an rvalue.
- Here, the 'Derived(Base)' constructor is selected.
(The explicit constructors are not candidates in this
context.)
- However, p32 says that if the type of the first
parameter of the selected constructor is not an rvalue
reference to the object's type, then overload
resolution is performed again, treating the object as
an rvalue.
- Here, the type of the first parameter of the
selected constructor is 'Base'. This is an rvalue
reference, but it's not to the object's type
(the object's type being 'Derived'). Therefore,
this provision is activated.
- The second overload resolution fails, because the only
candidate (again, the explicit constructors are not
candidates) has an rvalue reference parameter, which
cannot bind to the lvalue that we're not treating the
object as being.
A more detailed and better-formatted explanation can be found here [1].
Clang rejects this code, showing the error from the failure
of the second overload resolution:
test.cpp:13:10: error: no matching constructor for initialization of 'Derived'
return result;
^~
test.cpp:8:5: note: candidate constructor not viable: no known conversion from
'Derived' to 'Base ' for 1st argument
Derived(Base);
^
test.cpp:4:5: note: candidate constructor not viable: requires 0 arguments, but
1 was provided
Derived();
^
[1] http://stackoverflow.com/a/29834426/141719
[Bug c/64918] invalid (?) warning when initializing structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64918 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-04-23 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- Patch posted.
[Bug c++/65856] -Wsuggest-override shall not report a warning on final method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65856 Helfer Thomas thomas.helfer at cea dot fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Helfer Thomas thomas.helfer at cea dot fr --- I must say that your example seems very artificial : to me, the only case where final specifier may not imply the override one is when you create a virtual method and immediately declare it final : in this case what is the meaning of declaring the method virtual ? I can't find any good reason for this but I admit that, as this is allowed by the standard, my enhancement proposition can't be accepted. So I am closing the report. Thank you for your reply. Sincerly, Helfer Thomas
[Bug c++/65856] -Wsuggest-override shall not report a warning on final method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65856 --- Comment #6 from Markus Trippelsdorf trippels at gcc dot gnu.org --- If you want some real life examples, grep e.g. the Firefox source tree for final override or override final.
[Bug c++/65854] [c++-concepts] Type constraint satisfaction error for type aliases; regression from r211591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65854 Tom Honermann tom at honermann dot net changed: What|Removed |Added Summary|[c++-concepts] Type |[c++-concepts] Type |constraint satisfaction |constraint satisfaction |error for type aliases; |error for type aliases; |regression from r211824 |regression from r211591 --- Comment #1 from Tom Honermann tom at honermann dot net --- A correction. I've been reading the svn info details incorrectly. The old gcc build I have that accepts this code is r211591, not r211824. Updated the summary.
[Bug c/52085] incomplete enum not completed correctly if packed was used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52085 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |6.0 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Testing a patch.
[Bug ada/65868] cannot find -lstdc++ for GNAT compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65868 --- Comment #2 from Victor Porton porton at narod dot ru --- Your suggestion to build in a separate directory helped. It compiled completely.
[Bug ada/62042] Missing optimization of copying non-limited objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62042 Victor Porton porton at narod dot ru changed: What|Removed |Added Version|4.9.0 |5.1.0 --- Comment #2 from Victor Porton porton at narod dot ru --- Not fixed in 5.1.0.
[Bug c++/61022] [C++11] Bogus error: parameter packs not expanded with '...'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61022 --- Comment #2 from Paul Pluzhnikov ppluzhnikov at google dot com --- Still fails with trunk @r222386
[Bug other/53313] Add warning levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53313 --- Comment #8 from David Stone david at doublewise dot net --- I have changed my opinion on this and agree that warning levels are probably not the way to go. The two things from this that I do still want are -Weverything-and-I-really-mean-it-this-time All warnings either warn for exactly one type of thing or they turn on other warnings that themselves can be individually turned on or off.
[Bug ada/62235] segmentation fault on Ada 2012 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62235 Victor Porton porton at narod dot ru changed: What|Removed |Added Version|4.9.2 |5.1.0 --- Comment #5 from Victor Porton porton at narod dot ru --- Not fixed in 5.1.0 (however the exact error message is somehow different).
[Bug c/64918] invalid (?) warning when initializing structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64918 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Øystein Schønning-Johansen from comment #2) Really insightful, Joseph. I do understand the warning a bit better now. I have not looked into the GCC parsing code, but based on your description and my (limited) understanding of the problem, I guess a fix is not trivial? Can I suppress this warning in any way? I haven't looked at the code, but my guess is that at the time of the warning, it should be possible to check the overriden initializer, if it is a compound literal, recur on its initializers and check for side-effects again.
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |NEW --- Comment #26 from Dominique d'Humieres dominiq at lps dot ens.fr --- Compiling the test in comment 25 gives the following ICE pr65548_2.f90:17:0: allocate (int (0:this%n-1), source=this%get_int()) 1 internal compiler error: in gfc_conv_procedure_call, at fortran/trans-expr.c:5755 even with the patch in comment in comment 13.
[Bug inline-asm/65859] New: Optimizes out TLS variable called in a child function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65859 Bug ID: 65859 Summary: Optimizes out TLS variable called in a child function Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: inline-asm Assignee: unassigned at gcc dot gnu.org Reporter: mike at cchtml dot com Created attachment 35391 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35391action=edit test case When compiled with -O0 the test case compiles. When compiled with -O1 the test case will not compile with an error for an undefined reference to the TLS variable. If you move the THREAD_VAR_OFFSET macro call to main() gcc will compile without error. Enabling -O1 and turning off optimizations by hand does not change the result. I see the same issue with gcc 4.8, 4.9, and 5.0.
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 --- Comment #21 from Jürgen Reuter juergen.reuter at desy dot de --- (In reply to vehre from comment #20) Juergen, could you meanwhile check, that the patch fixes the issue? Damn, it seems my text didn't get posted. Being in Japan at the moment, and sometimes not having the best connection. NO, it doesn't fix the issue. The one I posted yes, but there are two other cases where it fails.
[Bug fortran/58754] [4.8/4.9/5/6 Regression] ICE on allocating character array with source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58754 Bug 58754 depends on bug 57456, which changed state. Bug 57456 Summary: [OOP] CLASS + CHARACTER ALLOCATE with typespec: For arrays, the typespec is ignored https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57456 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/51976] [F2003] Support deferred-length character components of derived types (allocatable string length)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51976 Bug 51976 depends on bug 57456, which changed state. Bug 57456 Summary: [OOP] CLASS + CHARACTER ALLOCATE with typespec: For arrays, the typespec is ignored https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57456 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/57456] [OOP] CLASS + CHARACTER ALLOCATE with typespec: For arrays, the typespec is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57456 vehre at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #7 from vehre at gcc dot gnu.org --- Fixed with commit r221621.
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 --- Comment #22 from Jürgen Reuter juergen.reuter at desy dot de --- One thing is: allocate (foo (0:this%dim-1), source=this%get_integral()) where this is some derived type with integer component dim and TBP get_integral which is a function generic :: get_integral = get_integral_array, get_integral_1 procedure :: get_integral_array procedure :: get_integral_1 subroutine get_integral_array (this, integral) class(t) :: this real, intent(out), dimension(:) :: integral integral = this%integral end subroutine get_integral_array subroutine get_integral_1 (this, integral) class(t) :: this real, intent(out) :: integral integral = this%integral(1) end subroutine get_integral_1
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 --- Comment #23 from Jürgen Reuter juergen.reuter at desy dot de --- The other failure occurs for allocate (foo (this%n), source=this%bar) where n is integer, foo has type character(32), dimension(:), allocatable and bar as well.
[Bug ipa/65858] New: ICE in varpool_node::get_constructor during chromium build on arm-linux-gnueabihf with LTO during LINK chrome
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65858 Bug ID: 65858 Summary: ICE in varpool_node::get_constructor during chromium build on arm-linux-gnueabihf with LTO during LINK chrome Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: prathamesh3492 at gcc dot gnu.org Created attachment 35390 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35390action=edit disable LTO in Webkit/Source/core/core.gyp and Webkit/Source/web/web.gyp Hi, This seems related to PR65776. During building chromium on arm-linux-gnueabihf, I disabled LTO for lib/libblink_web.so (PR65776), but got ICE in varpool_node::get_cosntructor() during LINK chrome Full command line used for linking: http://pastebin.com/fuq4y7QY [19024/19024] LINK chrome lto1: internal compiler error: in get_constructor, at varpool.c:331 0xc6abf3 varpool_node::get_constructor() /home/prathamesh.kulkarni/gnu-toolchain/src/gcc.git~gcc-chromium/gcc/varpool.c:331 0xc6bb33 varpool_node::assemble_decl() /home/prathamesh.kulkarni/gnu-toolchain/src/gcc.git~gcc-chromium/gcc/varpool.c:602 0xc6c675 symbol_table::output_variables() /home/prathamesh.kulkarni/gnu-toolchain/src/gcc.git~gcc-chromium/gcc/varpool.c:758 0x5d8953 symbol_table::compile() /home/prathamesh.kulkarni/gnu-toolchain/src/gcc.git~gcc-chromium/gcc/cgraphunit.c:2385 0x549e99 lto_main() /home/prathamesh.kulkarni/gnu-toolchain/src/gcc.git~gcc-chromium/gcc/lto/lto.c:3496 I have attached patch for disabling LTO for Webkit (to prevent ICE in linking libblink_web.so). Thank you, Prathamesh
[Bug libquadmath/65757] gfortran gives incorrect result for anint with real*16 argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65757 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||burnus at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr --- CCing libquadmath maintainers.
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2015-04-23 Resolution|INVALID |--- Ever confirmed|0 |1 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Not really - it's supported with GCC 5 that way as it uses target attributes.
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
--- Comment #6 from rguenther at suse dot de rguenther at suse dot de ---
On Wed, 22 Apr 2015, prathamesh3492 at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
--- Comment #3 from prathamesh3492 at gcc dot gnu.org ---
Hi,
I tried to reproduce the error with a reduced test-case:
#include arm_neon.h
float32x2_t a, b, c, e;
int main()
{
e = __builtin_neon_vmls_lanev2sf (a, b, c, 0);
return 0;
}
arm-linux-gnueabihf-gcc -mfpu=neon test.c -flto test.c -c
arm-linux-gnueabihf-gcc test.o -flto -o test
lto1: fatal error: target specific builtin not available
compilation terminated.
lto-wrapper: fatal error:
/home/prathamesh.kulkarni/gnu-toolchain/gcc-chromium-arm-linux-gnueabihf/builds/destdir/x86_64-unknown-linux-gnu/bin/arm-linux-gnueabihf-gcc
returned 1 exit status
compilation terminated.
However passing -mfpu=neon for linking works:
arm-linux-gnueabihf-gcc -mfpu=neon test.o -flto -o test
I suppose similar thing must be happening during linking
libshared_memory_support.so for chromium build ?
I couldn't see -mfpu=neon in the command line used for linking
libshared_memory_support.so
What needs to happen is that -mfpu=neon should be enabled for
main() via TARGET_OPTION_NODE streaming. And switching to main()
the needs to initialize the builtins enabled by -mfpu=neon.
Should be reproducible without LTO with
int __attribute__((target(fpu=neon))) main()
{
...
}
and compiling without -mfpu=neon.
Richard.
[Bug tree-optimization/65850] [5 Regression] [graphite]: isl_constraint.c:625: expecting integer value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65850 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Component|c++ |tree-optimization Target Milestone|--- |5.2 Summary|5.1 regression [graphite]: |[5 Regression] [graphite]: |isl_constraint.c:625: |isl_constraint.c:625: |expecting integer value |expecting integer value
[Bug libstdc++/60936] [4.9/5/6 Regression] Binary code bloat with std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936
--- Comment #11 from __vic d.v.a at ngs dot ru ---
Main problem hides in src/c++11/cow-string-inst.cc here:
namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
// These came from c++98/misc-inst.cc, repeat them for COW string
// string related to iostreams.
template
basic_istreamchar
operator(basic_istreamchar, string);
template
basic_ostreamchar
operator(basic_ostreamchar, const string);
template
basic_istreamchar
getline(basic_istreamchar, string, char);
template
basic_istreamchar
getline(basic_istreamchar, string);
_GLIBCXX_END_NAMESPACE_VERSION
} // namespace
It pulls all iostream + locale.
On the whole, dependences between objects within libstdc++ a organized
terribly. When I just use std::string almost all lib will be linked into my
binary!!! If I remove snippet mentioned above + apply fix from Comment 9 this
set of objects is linked:
condition_variable.o
cow-stdexcept.o
cow-string-inst.o
eh_throw.o
functexcept.o
functional.o
futex.o
future.o
ios_failure.o
regex.o
stdexcept.o
string-inst.o
system_error.o
WHY?! I just want std::string!
I use no futures, no regex, no ios::failure, etc... Is all this stuff realy
necessary for my trivial program?
[Bug c++/65856] -Wsuggest-override shall not report a warning on final method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65856
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org ---
I think the following may be used as a test case.
struct A
{
virtual void f ();
};
struct B : A
{
virtual void f () final;
};
[Bug middle-end/65855] missing optimization: triangular numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65855
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2015-04-23
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
For some reason we can't compute the number of iterations of this loop which is
because we have to assume that
(long unsigned int) n_3(D) != 18446744073709551615
and for some reason we couldn't simplify that to true!?
if (!exit_must_be_taken !POINTER_TYPE_P (type))
{
if (integer_nonzerop (iv0-step))
assumption = fold_build2 (NE_EXPR, boolean_type_node,
iv1-base, TYPE_MAX_VALUE (type));
if we fix that we fail in the following way:
(chrec_apply
(varying_loop = 1
)
(chrec = {1, +, {2, +, 1}_1}_1)
(x = (long unsigned int) n_3(D) + 18446744073709551615)
(res = scev_not_known))
not replacing:
t_4 = PHI t_5(3)
because we can't compute the final result expression.
[Bug c++/65856] -Wsuggest-override shall not report a warning on final method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65856 --- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org --- I forgot to add with -Wall -Wextra. gcc needs explicit -Woverloaded-virtual.
[Bug c++/65851] ice in set_lattice_value at tree-ssa-cc p.c:535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65851 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- We are transitioning from known-bits (likely alignment) to an invariant (thus constant). Most of the cases this happens because of too weak UNDEFINED handling. I suppose we should finally punt in making that correct and simply drop that lattice transition... (we already to sth similar for known-bits to known-bits). The assert is really there to catch this kind of missed optimizations, in theory we can just reject invalid transitions...
[Bug c++/65856] -Wsuggest-override shall not report a warning on final method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65856 --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- And BTW both clang and EDG warn for the first example: foo.cpp:6:16: warning: 'B::f' hides overloaded virtual function [-Woverloaded-virtual] virtual void f() final; ^ foo.cpp:2:16: note: hidden overloaded virtual function 'A::f' declared here: different number of parameters (1 vs 0) virtual void f(int); ^ 1 warning generated. foo.cpp(6): warning #1125: function A::f(int) is hidden by B::f -- virtual function override intended? virtual void f() final; ^
[Bug fortran/65841] Seg fault on intrinsic assignment to allocatable derived type with allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65841 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||vehre at gcc dot gnu.org --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- This PR is fixed by Andre's patch for pr59678 (all tests). Note that the last test in comment 1 segfault with only the [fist patch] for pr65792 + the one for pr59678. So this is another conflict between the two patches.
[Bug c++/65856] New: -Wsuggest-override shall not report a warning on final method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65856 Bug ID: 65856 Summary: -Wsuggest-override shall not report a warning on final method Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: thomas.helfer at cea dot fr Hi, first of all, as this is my first report, I wish to thank all gcc developpers for their work. I tried the -Wsuggest-override flag. I found that it suggests adding override to methods marked final. I think that this shall not be as final methods are already meant to override a method. This is only a suggestion. Maybe something in the standard makes it logical to mark a method as both override and final, but this would seem weird to my understanding. Example: ‘virtual const char* tfel::math::InvalidTimeStepException::what() const’ can be marked override [-Wsuggest-override] virtual const char* what() const noexcept final;
[Bug c++/65851] ice in set_lattice_value at tree-ssa-cc p.c:535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65851 Martin Liška marxin at gcc dot gnu.org changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška marxin at gcc dot gnu.org --- Running creduce and isolating culprit commit.
[Bug c++/65856] -Wsuggest-override shall not report a warning on final method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65856
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
I think override and final are orthogonal. And it might make sense to use both.
e.g.:
struct A {
virtual void f(int);
};
struct B : A {
virtual void f() final;
};
is valid.
But:
struct A {
virtual void f(int);
};
struct B : A {
virtual void f() final override;
};
would of course error out.
[Bug c++/65851] ice in set_lattice_value at tree-ssa-cc p.c:535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65851 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-04-23 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Mine. Waiting for a reduced testcase though.
[Bug c++/65851] ice in set_lattice_value at tree-ssa-cc p.c:535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65851 --- Comment #4 from Martin Liška marxin at gcc dot gnu.org --- Created attachment 35389 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35389action=edit reduced test case
[Bug c/47701] separate warning to detect c99 enum constraint violation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47701
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||mpolacek at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org ---
The compiler now says
t.c:1:12: warning: ISO C restricts enumerator values to range of ‘int’
[-Wpedantic]
enum { a = 0x10001LL };
^
t.c: In function ‘main’:
t.c:2:25: warning: overflow in implicit constant conversion [-Woverflow]
int main(void) { return a; }
^
So I suppose we can close this as fixed now. Please reopen if you want
something else.
[Bug rtl-optimization/65857] New: combine won't generate zero-extend from HImode memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65857
Bug ID: 65857
Summary: combine won't generate zero-extend from HImode memory
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
Target: x86
Following testcase:
--cut here--
extern unsigned char *a;
int test (void)
{
return (unsigned char) a[0] | (unsigned char) a[1] 8;
}
--cut here--
compiles (-O2 )nicely to:
movqa(%rip), %rax
movzwl (%rax), %eax
ret
However, combine will not combine HImode load with zero-extend:
(insn 5 2 6 2 (set (reg/f:DI 92 [ a ])
(mem/f/c:DI (symbol_ref:DI (a) [flags 0x40] var_decl 0x2b006b8dfc60
a) [1 a+0 S8 A64])) 85 {*movdi_internal}
(nil))
(insn 6 5 11 2 (set (reg:SI 91 [ D.1849 ])
(zero_extend:SI (mem:HI (reg/f:DI 92 [ a ]) [0 MEM[(unsigned char
*)_2]+0 S2 A8]))) ins.c:5 135 {*zero_extendhisi2}
(expr_list:REG_DEAD (reg/f:DI 92 [ a ])
(nil)))
It just chickens out with:
Trying 5 - 6:
Failed to match this instruction:
(set (reg:SI 91 [ D.1849 ])
(zero_extend:SI (mem:HI (mem/f/c:DI (symbol_ref:DI (a) [flags 0x40]
var_decl 0x2b006b8dfc60 a) [1 a+0 S8 A64]) [0 MEM[(unsigned char *)_2]+0 S2 A
8])))
Come on, combine ... the pattern is defined as:
(define_insn *zero_extendmodesi2
[(set (match_operand:SI 0 register_operand =r)
(zero_extend:SI
(match_operand:SWI12 1 nonimmediate_operand rm)))]
!(TARGET_ZERO_EXTEND_WITH_AND optimize_function_for_speed_p (cfun))
movz{imodesuffixl|x}\t{%1, %0|%0, %1}
[(set_attr type imovx)
(set_attr mode SI)])
[Bug c/61534] Wlogical-op should not warn when either operand comes from macro expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61534 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- *** Bug 53131 has been marked as a duplicate of this bug. ***
[Bug c/53131] -Wlogical-op: ready for prime time in -Wall ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53131 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #9 from Marek Polacek mpolacek at gcc dot gnu.org --- So I think we can close this as a dup; PR61534 has detailed info what needs to be fixed. *** This bug has been marked as a duplicate of bug 61534 ***
[Bug rtl-optimization/65857] combine won't generate zero-extend from HImode memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65857 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- The pattern it tries has the load of a in it. Not sure what you are expecting...
[Bug c++/65851] ice in set_lattice_value at tree-ssa-cc p.c:535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65851 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Ok, so it goes like Visiting PHI node: f_12 = PHI 0B(2), f_8(5) Argument #0 (2 - 6 executable) 0B Value: CONSTANT 0B Argument #1 (5 - 6 not executable) PHI node value: CONSTANT 0B ... Visiting statement: _15 = (long unsigned int) _14; which is likely CONSTANT Lattice value changed to CONSTANT 0x0 (0x0fff0). Adding SSA edges to worklist. Visiting statement: _3 = f_12 + _15; which is likely CONSTANT Applying pattern match.pd:54, gimple-match.c:9714 Applying pattern match.pd:54, generic-match.c:4594 Lattice value changed to CONSTANT 0x0 (0x0fff0). Adding SSA edges to worklist. (should have simplified to _15 ...? Ah, no - to (ptrtype)_15!) ... Visiting PHI node: f_12 = PHI 0B(2), f_8(5) Argument #0 (2 - 6 executable) 0B Value: CONSTANT 0B Argument #1 (5 - 6 executable) f_8 Value: VARYING PHI node value: VARYING ... Visiting statement: _15 = (long unsigned int) _14; which is likely CONSTANT Lattice value changed to VARYING. Adding SSA edges to worklist. Now we can look at both defs when combining stmts during simplification: Visiting statement: _3 = f_12 + _15; which is likely CONSTANT Applying pattern match.pd:413, gimple-match.c:9792 Match-and-simplified f_12 + _15 to e ICE. e.4_11 = (long int) e; f.5_13 = (long int) f_12; _14 = e.4_11 - f.5_13; _15 = (long unsigned int) _14; _3 = f_12 + _15; and yes - that combines to e. The interesting thing here is that our safety net for tuning down combining stmts is too conservative (again), because we can very well look at stmt definitions as long as we don't valueize anything for stmts we want to re-visit again. That's of course not so trivial to implement ... (ideally we'd have applied the simplification earlier - this is after all unfolded IL)
[Bug lto/65844] [5/6 Regression] ICE (verify_cgraph_node failed) on i686-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65844
Martin Liška marxin at gcc dot gnu.org changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #1 from Martin Liška marxin at gcc dot gnu.org ---
Hello.
Is it possible to reproduce the ICE on x86_64 by adding '-m32' to {C,LD}FLAGS.
I face following SEGFAULT (with -fprofile-generate -lto -m32) in:
gdb --args ./Programs/_freeze_importlib ./Lib/importlib/_bootstrap.py
Python/importlib.h
(gdb) r
Starting program:
/home/marxin/Programming/Python-3.5.0a4/Programs/_freeze_importlib
./Lib/importlib/_bootstrap.py Python/importlib.h
Got object file from memory but can't read symbols: File truncated.
Missing separate debuginfos, use: zypper install
glibc-32bit-debuginfo-2.19-16.9.1.x86_64
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib64/libthread_db.so.1.
Program received signal SIGSEGV, Segmentation fault.
va_build_value (flags=0, va=0xcb34 :\321\071\bt_9\bt_9\b\340\215T\b,
format=0x839d142 (szz)) at Python/modsupport.c:455
455Py_VA_COPY(lva, va);
Missing separate debuginfos, use: zypper install
libgcc_s1-32bit-debuginfo-4.8.3+r212056-2.2.4.x86_64
(gdb) bt
#0 va_build_value (flags=0, va=0xcb34 :\321\071\bt_9\bt_9\b\340\215T\b,
format=0x839d142 (szz)) at Python/modsupport.c:455
#1 Py_BuildValue (format=0x839d142 (szz)) at Python/modsupport.c:420
#2 0x0814c1d7 in _PySys_Init () at ./Python/sysmodule.c:1713
#3 0x0819dad0 in _Py_InitializeEx_Private (install_sigs=1,
install_importlib=0) at Python/pylifecycle.c:377
#4 0x08365fee in main (argc=3, argv=0xcd74) at
Programs/_freeze_importlib.c:83
Thanks,
Martin
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
--- Comment #10 from prathamesh3492 at gcc dot gnu.org ---
(In reply to Richard Biener from comment #9)
(In reply to prathamesh3492 from comment #3)
Hi,
I tried to reproduce the error with a reduced test-case:
#include arm_neon.h
float32x2_t a, b, c, e;
int main()
{
e = __builtin_neon_vmls_lanev2sf (a, b, c, 0);
return 0;
}
arm-linux-gnueabihf-gcc -mfpu=neon test.c -flto test.c -c
arm-linux-gnueabihf-gcc test.o -flto -o test
this should still work according to my experiments. -mfpu=neon should
be passed to lto1 at link time - can you verify it's in the lto option
section in test.o and on lto1 (by adding -v)?
-fmpu=neon is present, however it seems it's overriden by -mfpu=vfpv3-d16 in
the test.o file
arm-linux-gnueabihf-gcc -v -flto test.o
COLLECT_GCC_OPTIONS='-c' '-fmath-errno' '-fsigned-zeros' '-ftrapping-math'
'-fno-trapv' '-fno-strict-overflow' '-fno-openmp' '-fno-openacc' '-mfpu=neon'
'-march=armv7-a' '-mtune=cortex-a9' '-mfloat-abi=hard' '-mthumb'
'-mtls-dialect=gnu' '-v' '-march=armv7-a' '-mtune=cortex-a9' '-mfloat-abi=hard'
'-mfpu=vfpv3-d16' '-mthumb' '-mtls-dialect=gnu'
'-fltrans-output-list=/tmp/cc43ypaC.ltrans.out' '-fwpa'
'-fresolution=/tmp/ccmDzd6z.res'
/home/prathamesh.kulkarni/gcc-linaro-6.0/bin/../lib/gcc/../../libexec/gcc/arm-linux-gnueabihf/6.0.0/lto1
-quiet -dumpbase test.o -mfpu=neon -march=armv7-a -mtune=cortex-a9
-mfloat-abi=hard -mthumb -mtls-dialect=gnu -march=armv7-a -mtune=cortex-a9
-mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb -mtls-dialect=gnu -auxbase test
-version -fmath-errno -fsigned-zeros -ftrapping-math -fno-trapv
-fno-strict-overflow -fno-openmp -fno-openacc
-fltrans-output-list=/tmp/cc43ypaC.ltrans.out -fwpa
-fresolution=/tmp/ccmDzd6z.res @/tmp/ccus6SMC
adding -mfpu=neon in the command line, only has -mfpu=neon
arm-linux-gnueaihf-gcc -v -mfpu=neon -flto test.o
COLLECT_GCC_OPTIONS='-c' '-fmath-errno' '-fsigned-zeros' '-ftrapping-math'
'-fno-trapv' '-fno-strict-overflow' '-fno-openmp' '-fno-openacc' '-mfpu=neon'
'-march=armv7-a' '-mtune=cortex-a9' '-mfloat-abi=hard' '-mthumb'
'-mtls-dialect=gnu' '-v' '-mfpu=neon' '-march=armv7-a' '-mtune=cortex-a9'
'-mfloat-abi=hard' '-mthumb' '-mtls-dialect=gnu'
'-fltrans-output-list=/tmp/ccCo0pAW.ltrans.out' '-fwpa'
'-fresolution=/tmp/ccRqEsoP.res'
/home/prathamesh.kulkarni/gcc-linaro-6.0/bin/../lib/gcc/../../libexec/gcc/arm-linux-gnueabihf/6.0.0/lto1
-quiet -dumpbase test.o -mfpu=neon -march=armv7-a -mtune=cortex-a9
-mfloat-abi=hard -mthumb -mtls-dialect=gnu -mfpu=neon -march=armv7-a
-mtune=cortex-a9 -mfloat-abi=hard -mthumb -mtls-dialect=gnu -auxbase test
-version -fmath-errno -fsigned-zeros -ftrapping-math -fno-trapv
-fno-strict-overflow -fno-openmp -fno-openacc
-fltrans-output-list=/tmp/ccCo0pAW.ltrans.out -fwpa
-fresolution=/tmp/ccRqEsoP.res @/tmp/ccArRJjW
Thanks,
Prathamesh
lto1: fatal error: target specific builtin not available
compilation terminated.
lto-wrapper: fatal error:
/home/prathamesh.kulkarni/gnu-toolchain/gcc-chromium-arm-linux-gnueabihf/
builds/destdir/x86_64-unknown-linux-gnu/bin/arm-linux-gnueabihf-gcc returned
1 exit status
compilation terminated.
However passing -mfpu=neon for linking works:
arm-linux-gnueabihf-gcc -mfpu=neon test.o -flto -o test
I suppose similar thing must be happening during linking
libshared_memory_support.so for chromium build ?
I couldn't see -mfpu=neon in the command line used for linking
libshared_memory_support.so
Thank you,
Prathamesh
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
--- Comment #11 from rguenther at suse dot de rguenther at suse dot de ---
On Thu, 23 Apr 2015, prathamesh3492 at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
--- Comment #10 from prathamesh3492 at gcc dot gnu.org ---
(In reply to Richard Biener from comment #9)
(In reply to prathamesh3492 from comment #3)
Hi,
I tried to reproduce the error with a reduced test-case:
#include arm_neon.h
float32x2_t a, b, c, e;
int main()
{
e = __builtin_neon_vmls_lanev2sf (a, b, c, 0);
return 0;
}
arm-linux-gnueabihf-gcc -mfpu=neon test.c -flto test.c -c
arm-linux-gnueabihf-gcc test.o -flto -o test
this should still work according to my experiments. -mfpu=neon should
be passed to lto1 at link time - can you verify it's in the lto option
section in test.o and on lto1 (by adding -v)?
-fmpu=neon is present, however it seems it's overriden by -mfpu=vfpv3-d16 in
the test.o file
arm-linux-gnueabihf-gcc -v -flto test.o
COLLECT_GCC_OPTIONS='-c' '-fmath-errno' '-fsigned-zeros' '-ftrapping-math'
'-fno-trapv' '-fno-strict-overflow' '-fno-openmp' '-fno-openacc' '-mfpu=neon'
'-march=armv7-a' '-mtune=cortex-a9' '-mfloat-abi=hard' '-mthumb'
'-mtls-dialect=gnu' '-v' '-march=armv7-a' '-mtune=cortex-a9'
'-mfloat-abi=hard'
'-mfpu=vfpv3-d16' '-mthumb' '-mtls-dialect=gnu'
'-fltrans-output-list=/tmp/cc43ypaC.ltrans.out' '-fwpa'
'-fresolution=/tmp/ccmDzd6z.res'
Huh. Can you see where that comes from?
Richard.
/home/prathamesh.kulkarni/gcc-linaro-6.0/bin/../lib/gcc/../../libexec/gcc/arm-linux-gnueabihf/6.0.0/lto1
-quiet -dumpbase test.o -mfpu=neon -march=armv7-a -mtune=cortex-a9
-mfloat-abi=hard -mthumb -mtls-dialect=gnu -march=armv7-a -mtune=cortex-a9
-mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb -mtls-dialect=gnu -auxbase test
-version -fmath-errno -fsigned-zeros -ftrapping-math -fno-trapv
-fno-strict-overflow -fno-openmp -fno-openacc
-fltrans-output-list=/tmp/cc43ypaC.ltrans.out -fwpa
-fresolution=/tmp/ccmDzd6z.res @/tmp/ccus6SMC
adding -mfpu=neon in the command line, only has -mfpu=neon
arm-linux-gnueaihf-gcc -v -mfpu=neon -flto test.o
COLLECT_GCC_OPTIONS='-c' '-fmath-errno' '-fsigned-zeros' '-ftrapping-math'
'-fno-trapv' '-fno-strict-overflow' '-fno-openmp' '-fno-openacc' '-mfpu=neon'
'-march=armv7-a' '-mtune=cortex-a9' '-mfloat-abi=hard' '-mthumb'
'-mtls-dialect=gnu' '-v' '-mfpu=neon' '-march=armv7-a' '-mtune=cortex-a9'
'-mfloat-abi=hard' '-mthumb' '-mtls-dialect=gnu'
'-fltrans-output-list=/tmp/ccCo0pAW.ltrans.out' '-fwpa'
'-fresolution=/tmp/ccRqEsoP.res'
/home/prathamesh.kulkarni/gcc-linaro-6.0/bin/../lib/gcc/../../libexec/gcc/arm-linux-gnueabihf/6.0.0/lto1
-quiet -dumpbase test.o -mfpu=neon -march=armv7-a -mtune=cortex-a9
-mfloat-abi=hard -mthumb -mtls-dialect=gnu -mfpu=neon -march=armv7-a
-mtune=cortex-a9 -mfloat-abi=hard -mthumb -mtls-dialect=gnu -auxbase test
-version -fmath-errno -fsigned-zeros -ftrapping-math -fno-trapv
-fno-strict-overflow -fno-openmp -fno-openacc
-fltrans-output-list=/tmp/ccCo0pAW.ltrans.out -fwpa
-fresolution=/tmp/ccRqEsoP.res @/tmp/ccArRJjW
Thanks,
Prathamesh
lto1: fatal error: target specific builtin not available
compilation terminated.
lto-wrapper: fatal error:
/home/prathamesh.kulkarni/gnu-toolchain/gcc-chromium-arm-linux-gnueabihf/
builds/destdir/x86_64-unknown-linux-gnu/bin/arm-linux-gnueabihf-gcc
returned
1 exit status
compilation terminated.
However passing -mfpu=neon for linking works:
arm-linux-gnueabihf-gcc -mfpu=neon test.o -flto -o test
I suppose similar thing must be happening during linking
libshared_memory_support.so for chromium build ?
I couldn't see -mfpu=neon in the command line used for linking
libshared_memory_support.so
Thank you,
Prathamesh
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 vehre at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|WAITING --- Comment #20 from vehre at gcc dot gnu.org --- Juergen, could you meanwhile check, that the patch fixes the issue?
[Bug c++/65721] [4.8/4.9/5/6 Regression] Internal compiler error segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65721 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Apr 23 13:20:08 2015 New Revision: 222363 URL: https://gcc.gnu.org/viewcvs?rev=222363root=gccview=rev Log: PR c++/65721 * name-lookup.c (do_class_using_decl): Complain about specifying the current class even if there are dependent bases. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/lookup/using55.C Modified: branches/gcc-4_8-branch/gcc/cp/ChangeLog branches/gcc-4_8-branch/gcc/cp/name-lookup.c
[Bug c++/65727] [4.8/4.9/5/6 Regression] Segfault With Decltype In Lambda Expression Used To Initialize Static Class Member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65727 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Apr 23 13:20:14 2015 New Revision: 222364 URL: https://gcc.gnu.org/viewcvs?rev=222364root=gccview=rev Log: PR c++/65727 * semantics.c (maybe_resolve_dummy): Handle null return. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-decltype2.C Modified: branches/gcc-4_8-branch/gcc/cp/ChangeLog branches/gcc-4_8-branch/gcc/cp/semantics.c branches/gcc-4_8-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice3.C
[Bug c++/65695] [4.9/5/6 Regression] NSDMI calling constexpr constructor with pointer-to-member is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65695 --- Comment #14 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Apr 23 13:21:17 2015 New Revision: 222367 URL: https://gcc.gnu.org/viewcvs?rev=222367root=gccview=rev Log: PR c++/65695 * cvt.c (cp_fold_convert): Avoid wrapping PTRMEM_CST in NOP_EXPR. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-ptrmem4.C Modified: branches/gcc-4_9-branch/gcc/cp/ChangeLog branches/gcc-4_9-branch/gcc/cp/cvt.c
[Bug c++/65727] [4.8/4.9/5/6 Regression] Segfault With Decltype In Lambda Expression Used To Initialize Static Class Member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65727 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Apr 23 13:21:22 2015 New Revision: 222368 URL: https://gcc.gnu.org/viewcvs?rev=222368root=gccview=rev Log: PR c++/65727 * lambda.c (maybe_resolve_dummy): Handle null return. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-decltype2.C Modified: branches/gcc-4_9-branch/gcc/cp/ChangeLog branches/gcc-4_9-branch/gcc/cp/lambda.c branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice3.C
[Bug c++/59766] c++1y: declaring friend function with 'auto' return type deduction is rejected with bogus reason
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59766 --- Comment #14 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Apr 23 13:21:06 2015 New Revision: 222365 URL: https://gcc.gnu.org/viewcvs?rev=222365root=gccview=rev Log: PR c++/59766 * decl.c (grokdeclarator): Do not flag friends with deduced return. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp1y/auto-fn26.C Modified: branches/gcc-4_9-branch/gcc/cp/ChangeLog branches/gcc-4_9-branch/gcc/cp/decl.c
[Bug c++/65721] [4.8/4.9/5/6 Regression] Internal compiler error segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65721 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jason Merrill jason at gcc dot gnu.org --- Fixed for 4.8.5/4.9.3/5.2/6.
[Bug c++/65848] [c++-concepts] High memory usage and compilation times for subsuming concept chains; regression from r211824
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65848 --- Comment #4 from Andrew Sutton andrew.n.sutton at gmail dot com --- I think that is actually not so unfortunate. Statically asserting concept models has helped me find numerous issues in my own code. I'm glad to hear the proposal is being extended to cover this. Unfortunate in the sense that we missed the features that would allow that usage. But to be fair, it wasn't exactly a primary use case when we were considering the design.
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
--- Comment #13 from prathamesh3492 at gcc dot gnu.org ---
(In reply to Ramana Radhakrishnan from comment #12)
(In reply to rguent...@suse.de from comment #11)
On Thu, 23 Apr 2015, prathamesh3492 at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
--- Comment #10 from prathamesh3492 at gcc dot gnu.org ---
(In reply to Richard Biener from comment #9)
(In reply to prathamesh3492 from comment #3)
Hi,
I tried to reproduce the error with a reduced test-case:
#include arm_neon.h
float32x2_t a, b, c, e;
int main()
{
e = __builtin_neon_vmls_lanev2sf (a, b, c, 0);
return 0;
}
arm-linux-gnueabihf-gcc -mfpu=neon test.c -flto test.c -c
arm-linux-gnueabihf-gcc test.o -flto -o test
this should still work according to my experiments. -mfpu=neon should
be passed to lto1 at link time - can you verify it's in the lto option
section in test.o and on lto1 (by adding -v)?
-fmpu=neon is present, however it seems it's overriden by -mfpu=vfpv3-d16
in
the test.o file
arm-linux-gnueabihf-gcc -v -flto test.o
COLLECT_GCC_OPTIONS='-c' '-fmath-errno' '-fsigned-zeros' '-ftrapping-math'
'-fno-trapv' '-fno-strict-overflow' '-fno-openmp' '-fno-openacc'
'-mfpu=neon'
'-march=armv7-a' '-mtune=cortex-a9' '-mfloat-abi=hard' '-mthumb'
'-mtls-dialect=gnu' '-v' '-march=armv7-a' '-mtune=cortex-a9'
'-mfloat-abi=hard'
'-mfpu=vfpv3-d16' '-mthumb' '-mtls-dialect=gnu'
'-fltrans-output-list=/tmp/cc43ypaC.ltrans.out' '-fwpa'
'-fresolution=/tmp/ccmDzd6z.res'
Huh. Can you see where that comes from?
Yeah that's odd - it's almost like the command line options passed to the TU
precede the defaults of the compiler.
Prathamesh, can you dig further - it sounds like we have a real issue here.
Hi,
Is it okay if I start investigating this tomorrow ? I am busy with something
else at the moment, sorry about that.
Regards,
Prathamesh
Ramana
Richard.
/home/prathamesh.kulkarni/gcc-linaro-6.0/bin/../lib/gcc/../../libexec/gcc/arm-linux-gnueabihf/6.0.0/lto1
-quiet -dumpbase test.o -mfpu=neon -march=armv7-a -mtune=cortex-a9
-mfloat-abi=hard -mthumb -mtls-dialect=gnu -march=armv7-a -mtune=cortex-a9
-mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb -mtls-dialect=gnu -auxbase test
-version -fmath-errno -fsigned-zeros -ftrapping-math -fno-trapv
-fno-strict-overflow -fno-openmp -fno-openacc
-fltrans-output-list=/tmp/cc43ypaC.ltrans.out -fwpa
-fresolution=/tmp/ccmDzd6z.res @/tmp/ccus6SMC
adding -mfpu=neon in the command line, only has -mfpu=neon
arm-linux-gnueaihf-gcc -v -mfpu=neon -flto test.o
COLLECT_GCC_OPTIONS='-c' '-fmath-errno' '-fsigned-zeros' '-ftrapping-math'
'-fno-trapv' '-fno-strict-overflow' '-fno-openmp' '-fno-openacc'
'-mfpu=neon'
'-march=armv7-a' '-mtune=cortex-a9' '-mfloat-abi=hard' '-mthumb'
'-mtls-dialect=gnu' '-v' '-mfpu=neon' '-march=armv7-a' '-mtune=cortex-a9'
'-mfloat-abi=hard' '-mthumb' '-mtls-dialect=gnu'
'-fltrans-output-list=/tmp/ccCo0pAW.ltrans.out' '-fwpa'
'-fresolution=/tmp/ccRqEsoP.res'
/home/prathamesh.kulkarni/gcc-linaro-6.0/bin/../lib/gcc/../../libexec/gcc/arm-linux-gnueabihf/6.0.0/lto1
-quiet -dumpbase test.o -mfpu=neon -march=armv7-a -mtune=cortex-a9
-mfloat-abi=hard -mthumb -mtls-dialect=gnu -mfpu=neon -march=armv7-a
-mtune=cortex-a9 -mfloat-abi=hard -mthumb -mtls-dialect=gnu -auxbase test
-version -fmath-errno -fsigned-zeros -ftrapping-math -fno-trapv
-fno-strict-overflow -fno-openmp -fno-openacc
-fltrans-output-list=/tmp/ccCo0pAW.ltrans.out -fwpa
-fresolution=/tmp/ccRqEsoP.res @/tmp/ccArRJjW
Thanks,
Prathamesh
lto1: fatal error: target specific builtin not available
compilation terminated.
lto-wrapper: fatal error:
/home/prathamesh.kulkarni/gnu-toolchain/gcc-chromium-arm-linux-gnueabihf/
builds/destdir/x86_64-unknown-linux-gnu/bin/arm-linux-gnueabihf-gcc
returned
1 exit status
compilation terminated.
However passing -mfpu=neon for linking works:
arm-linux-gnueabihf-gcc -mfpu=neon test.o -flto -o test
I suppose similar thing must be happening during linking
libshared_memory_support.so for chromium build ?
I couldn't see -mfpu=neon in the command line used for linking
libshared_memory_support.so
Thank you,
Prathamesh
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 --- Comment #25 from Jürgen Reuter juergen.reuter at desy dot de --- Example 1: module foo type :: t integer :: n real, dimension(:,:), allocatable :: val contains procedure :: make = t_make generic :: get_int = get_int_array, get_int_element procedure :: get_int_array = t_get_int_array procedure :: get_int_element = t_get_int_element end type t contains subroutine t_make (this) class(t), intent(inout) :: this real, dimension(:), allocatable :: int allocate (int (0:this%n-1), source=this%get_int()) end subroutine t_make pure function t_get_int_array (this) result (array) class(t), intent(in) :: this real, dimension(this%n) :: array array = this%val (0:this%n-1, 4) end function t_get_int_array pure function t_get_int_element (this, set) result (element) class(t), intent(in) :: this integer, intent(in) :: set real :: element element = this%val (set, 4) end function t_get_int_element end module foo
