Bug 1464612
Summary: | gcc 7.1.1 cannot compile recent octave code | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dmitri A. Sergatskov <dasergatskov> | ||||||
Component: | gcc | Assignee: | Jakub Jelinek <jakub> | ||||||
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 26 | CC: | dasergatskov, davejohansen, fweimer, jakub, jason, jwakely, law, mpolacek | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | x86_64 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | gcc-7.1.1-4.fc26 | Doc Type: | If docs needed, set a value | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2017-07-20 08:06:54 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Dmitri A. Sergatskov
2017-06-23 23:03:23 UTC
Created attachment 1291287 [details]
failing symtab.cc file
Setting CXXFLAGS to "-std=c++1z" allows compile to finish successfully. with either "-std=c++11" or "-std=c++14" it fails. Though this provides a workaround the problem is still there. Dmitri. (In reply to Dmitri A. Sergatskov from comment #1) > Created attachment 1291287 [details] > failing symtab.cc file symtab.cc is not really useful, can you please attach preprocessed source (e.g. add -save-temps to the above command and attach symtab.ii)? Thanks. Created attachment 1291482 [details]
symtab.ii
I believe this has changed with http://gcc.gnu.org/PR42329 , at least the preprocessed source started to ICE with http://gcc.gnu.org/r243870 and no longer ICEs, but rejects the testcase starting with http://gcc.gnu.org/r243890 . I believe this is when trying to unify the Container template template param of template<typename T> template<template <typename...> class Container> Array<T>::Array (const Container<T>& a, const dim_vector& dv) : dimensions (dv), rep (new typename Array<T>::ArrayRep (dv.safe_numel ())), slice_data (rep->data), slice_len (rep->len) Whether G++ is correct on this octave testcase or not I'd like to defer to our C++ folks. Sorry, the above Array ctor is just the first spot where the template template param unification does something. Somewhat reduced testcase that also was accepted in r243869 and is rejected in r243890 is: #include <string> #include <map> #include <set> template <typename V, template <typename...> class C> void bar (const std::map<std::string, C<V>>& x) { } void foo (std::map<std::string, std::set<std::string>> &x) { bar (x); } Note ICC 17 rejects it too. Wonder if this isn't because std::set template actually doesn't have one template argument, but 3, and std::list doesn't have one template argument, but 2. #include <string> #include <list> #include <map> #include <set> template <typename V, typename... W, template <typename...> class C> void bar (const std::map<std::string, C<V, W...>>& x) { } void foo (std::map<std::string, std::set<std::string>>& x, std::map<std::string, std::list<std::string>>& y) { bar (x); bar (y); } works with both g++ 6 and g++ 7, so perhaps you should just add the parameter pack to dump_container_map. Either: @@ -99784,9 +99784,9 @@ symbol_table::find_submethod (const std: return fcn; } -template <typename V, template <typename...> class C> +template <typename V, typename... W, template <typename...> class C> static octave_value -dump_container_map (const std::map<std::string, C<V>>& container_map) +dump_container_map (const std::map<std::string, C<V, W...>>& container_map) { if (container_map.empty ()) return octave_value (Matrix ()); @@ -99796,7 +99796,7 @@ dump_container_map (const std::map<std:: for (const auto& nm_container : container_map) { std::string nm = nm_container.first; - const C<V>& container = nm_container.second; + const C<V, W...>& container = nm_container.second; info_map[nm] = Cell (container); } or template <typename... V, template <typename...> class C> static octave_value dump_container_map (const std::map<std::string, C<V...>>& container_map) { ... const C<V...>& container = nm_container.second; ... } Reduced further: template<typename U> struct X { }; template<typename T, typename U = void> struct set { }; template <typename V, template <typename...> class C> void bar (const X<C<V>>&) { } void foo (X<set<int>>& x) { bar (x); } The octave's code has been changed. See: http://octave.1599824.n4.nabble.com/gcc7-build-error-with-recent-tip-tp4683876p4683911.html and http://hg.savannah.gnu.org/hgweb/octave/rev/93371ce5378d But the question remains if this is a bug in g++ or not. Dmitri. Looks like a bug, yes. Fixed upstream. Should be fixed in gcc-7.1.1-4.fc{26,27} and above. |