gcc7 build error with recent tip

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

gcc7 build error with recent tip

Dmitri A. Sergatskov
see:

http://buildbot.octave.org:8010/builders/gcc-fedora/builds/554/steps/compile/logs/stdio


libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../src -Iliboctave -I../src/liboctave -I../src/liboctave/array -Iliboctave/numeric -I../src/liboctave/numeric -Iliboctave/operators -I../src/liboctave/operators -I../src/liboctave/system -I../src/liboctave/util -I../src/libinterp/octave-value -Ilibinterp -I../src/libinterp -I../src/libinterp/operators -Ilibinterp/parse-tree -I../src/libinterp/parse-tree -Ilibinterp/corefcn -I../src/libinterp/corefcn -I../src/liboctave/wrappers -I/usr/include/GraphicsMagick -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libpng16 -fPIC -pthread -fopenmp -Wall -W -Wshadow -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -g -O2 -MT libinterp/corefcn/libinterp_corefcn_libcorefcn_la-tril.lo -MD -MP -MF libinterp/corefcn/.deps/libinterp_corefcn_libcorefcn_la-tril.Tpo -c ../src/libinterp/corefcn/tril.cc -fPIC -DPIC -o libinterp/corefcn/.libs/libinterp_corefcn_libcorefcn_la-tril.o
../src/libinterp/corefcn/symtab.cc: In member function ‘octave_value symbol_table::dump() const’: ../src/libinterp/corefcn/symtab.cc:1446:73: error: no matching function for call to ‘dump_container_map(const std::map<std::__cxx11::basic_string<char>, std::set<std::__cxx11::basic_string<char> > >&)’ {"precedence_table", dump_container_map (m_class_precedence_table)}, ^ ../src/libinterp/corefcn/symtab.cc:1424:1: note: candidate: template<class V, template<class ...> class C> octave_value dump_container_map(const std::map<std::__cxx11::basic_string<char>, C<V> >&) dump_container_map (const std::map<std::string, C<V>>& container_map) ^~~~~~~~~~~~~~~~~~ ../src/libinterp/corefcn/symtab.cc:1424:1: note: template argument deduction/substitution failed: ../src/libinterp/corefcn/symtab.cc:1446:73: note: candidate expects 1 argument, 3 provided {"precedence_table", dump_container_map (m_class_precedence_table)}, ^ ../src/libinterp/corefcn/symtab.cc:1447:59: error: no matching function for call to ‘dump_container_map(const std::map<std::__cxx11::basic_string<char>, std::__cxx11::list<std::__cxx11::basic_string<char> > >&)’ {"parent_classes", dump_container_map (m_parent_map)}}; ^ ../src/libinterp/corefcn/symtab.cc:1424:1: note: candidate: template<class V, template<class ...> class C> octave_value dump_container_map(const std::map<std::__cxx11::basic_string<char>, C<V> >&) dump_container_map (const std::map<std::string, C<V>>& container_map) ^~~~~~~~~~~~~~~~~~ ../src/libinterp/corefcn/symtab.cc:1424:1: note: template argument deduction/substitution failed: ../src/libinterp/corefcn/symtab.cc:1447:59: note: candidate expects 1 argument, 2 provided {"parent_classes", dump_container_map (m_parent_map)}}; ^ ../src/libinterp/corefcn/symtab.cc:1447:61: error: could not convert ‘{{"function_info", symbol_table::dump_fcn_table_map() const()}, {"precedence_table", <expression error>}, {"parent_classes", <expression error>}}’ from ‘<brace-enclosed initializer list>’ to ‘std::map<std::__cxx11::basic_string<char>, octave_value>’ {"parent_classes", dump_container_map (m_parent_map)}}; ^ make[2]: *** [Makefile:18264: libinterp/corefcn/libinterp_corefcn_libcorefcn_la-symtab.lo] Error 1 make[2]: *** Waiting for unfinished jobs....
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gcc7 build error with recent tip

Mike Miller-4
On Thu, Jun 22, 2017 at 18:04:25 -0500, Dmitri A. Sergatskov wrote:
> see:
>
> http://buildbot.octave.org:8010/builders/gcc-fedora/builds/554/steps/compile/logs/stdio

Do you know why that is? Please file a bug if this persists, this post
will probably quickly be forgotten.

--
mike

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gcc7 build error with recent tip

Dmitri A. Sergatskov
On Fri, Jun 23, 2017 at 3:54 PM, Mike Miller <[hidden email]> wrote:
On Thu, Jun 22, 2017 at 18:04:25 -0500, Dmitri A. Sergatskov wrote:
> see:
>
> http://buildbot.octave.org:8010/builders/gcc-fedora/builds/554/steps/compile/logs/stdio

Do you know why that is? Please file a bug if this persists, this post
will probably quickly be forgotten.


​It failing the same way on few computers (all with Fedora 26-beta). Perhaps it is
a compiler issue (clang does not have problem with it). It persists

 

--
mike


​Dmitri.
--

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gcc7 build error with recent tip

Mike Miller-4
On Fri, Jun 23, 2017 at 16:03:00 -0500, Dmitri A. Sergatskov wrote:
> It failing the same way on few computers (all with Fedora 26-beta).
> Perhaps it is
> a compiler issue (clang does not have problem with it). It persists
> (see fedora builds on http://buildbot.octave.org:8010/waterfall)

I get the same error with gcc-snapshot in Debian (gcc trunk r249349).
Next stop bug tracker.

--
mike

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gcc7 build error with recent tip

Dmitri A. Sergatskov
On Fri, Jun 23, 2017 at 4:38 PM, Mike Miller <[hidden email]> wrote:
On Fri, Jun 23, 2017 at 16:03:00 -0500, Dmitri A. Sergatskov wrote:
> It failing the same way on few computers (all with Fedora 26-beta).
> Perhaps it is
> a compiler issue (clang does not have problem with it). It persists
> (see fedora builds on http://buildbot.octave.org:8010/waterfall)

I get the same error with gcc-snapshot in Debian (gcc trunk r249349).
Next stop bug tracker.


​It compiles if I set CXXFLAGS to -std=c++1z or -std=c++14
and fails again with -std=c++11

 
--
mike


​Dmitri.
--
 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gcc7 build error with recent tip

Dmitri A. Sergatskov


On Fri, Jun 23, 2017 at 4:58 PM, Dmitri A. Sergatskov <[hidden email]> wrote:
On Fri, Jun 23, 2017 at 4:38 PM, Mike Miller <[hidden email]> wrote:
On Fri, Jun 23, 2017 at 16:03:00 -0500, Dmitri A. Sergatskov wrote:
> It failing the same way on few computers (all with Fedora 26-beta).
> Perhaps it is
> a compiler issue (clang does not have problem with it). It persists
> (see fedora builds on http://buildbot.octave.org:8010/waterfall)

I get the same error with gcc-snapshot in Debian (gcc trunk r249349).
Next stop bug tracker.


​It compiles if I set CXXFLAGS to -std=c++1z or -std=c++14
and fails again with -std=c++11

​I managed to confuse myself with all those flags -- it compiles with ​ -std=c++1z
fails with either -std=c++11 or std=c++14:

<<<<
HG ID for this build is "6fe13cd3543c"
​....
​__octave_config_info__ ("CXXFLAGS")
ans = -O2 -std=c++1z
===========================

/bin/sh ./libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. -I..  -Iliboctave -I../liboctave -I../liboctave/array -Iliboctave/numeric -I../liboctave/numeric -Iliboctave/operators -I../liboctave/operators -I../liboctave/system -I../liboctave/util -I../libinterp/octave-value -Ilibinterp -I../libinterp -I../libinterp/operators -Ilibinterp/parse-tree -I../libinterp/parse-tree -Ilibinterp/corefcn -I../libinterp/corefcn -I../liboctave/wrappers  -I/usr/include/GraphicsMagick   -I/usr/include/freetype2 -I/usr/include/libpng16  -I/usr/include/freetype2 -I/usr/include/libpng16      -fPIC -pthread -fopenmp -Wall -W -Wshadow -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual  -O2 -std=c++14 -MT libinterp/corefcn/libinterp_corefcn_libcorefcn_la-symtab.lo -MD -MP -MF libinterp/corefcn/.deps/libinterp_corefcn_libcorefcn_la-symtab.Tpo -c -o libinterp/corefcn/libinterp_corefcn_libcorefcn_la-symtab.lo `test -f 'libinterp/corefcn/symtab.cc' || echo '../'`libinterp/corefcn/symtab.cc
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I.. -Iliboctave -I../liboctave -I../liboctave/array -Iliboctave/numeric -I../liboctave/numeric -Iliboctave/operators -I../liboctave/operators -I../liboctave/system -I../liboctave/util -I../libinterp/octave-value -Ilibinterp -I../libinterp -I../libinterp/operators -Ilibinterp/parse-tree -I../libinterp/parse-tree -Ilibinterp/corefcn -I../libinterp/corefcn -I../liboctave/wrappers -I/usr/include/GraphicsMagick -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libpng16 -fPIC -pthread -fopenmp -Wall -W -Wshadow -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -O2 -std=c++14 -MT libinterp/corefcn/libinterp_corefcn_libcorefcn_la-symtab.lo -MD -MP -MF libinterp/corefcn/.deps/libinterp_corefcn_libcorefcn_la-symtab.Tpo -c ../libinterp/corefcn/symtab.cc  -fPIC -DPIC -o libinterp/corefcn/.libs/libinterp_corefcn_libcorefcn_la-symtab.o
../libinterp/corefcn/symtab.cc: In member function ‘octave_value symbol_table::dump() const’:
../libinterp/corefcn/symtab.cc:1446:73: error: no matching function for call to ‘dump_container_map(const std::map<std::__cxx11::basic_string<char>, std::set<std::__cxx11::basic_string<char> > >&)’
        {"precedence_table", dump_container_map (m_class_precedence_table)},
                                                                         ^
../libinterp/corefcn/symtab.cc:1424:1: note: candidate: template<class V, template<class ...> class C> octave_value dump_container_map(const std::map<std::__cxx11::basic_string<char>, C<V> >&)
 dump_container_map (const std::map<std::string, C<V>>& container_map)
 ^~~~~~~~~~~~~~~~~~
../libinterp/corefcn/symtab.cc:1424:1: note:   template argument deduction/substitution failed:
../libinterp/corefcn/symtab.cc:1446:73: note:   candidate expects 1 argument, 3 provided
        {"precedence_table", dump_container_map (m_class_precedence_table)},
                                                                         ^
../libinterp/corefcn/symtab.cc:1447:59: error: no matching function for call to ‘dump_container_map(const std::map<std::__cxx11::basic_string<char>, std::__cxx11::list<std::__cxx11::basic_string<char> > >&)’
        {"parent_classes", dump_container_map (m_parent_map)}};
                                                           ^
../libinterp/corefcn/symtab.cc:1424:1: note: candidate: template<class V, template<class ...> class C> octave_value dump_container_map(const std::map<std::__cxx11::basic_string<char>, C<V> >&)
 dump_container_map (const std::map<std::string, C<V>>& container_map)
 ^~~~~~~~~~~~~~~~~~
../libinterp/corefcn/symtab.cc:1424:1: note:   template argument deduction/substitution failed:
../libinterp/corefcn/symtab.cc:1447:59: note:   candidate expects 1 argument, 2 provided
        {"parent_classes", dump_container_map (m_parent_map)}};
                                                           ^
../libinterp/corefcn/symtab.cc:1447:61: error: could not convert ‘{{"function_info", symbol_table::dump_fcn_table_map() const()}, {"precedence_table", <expression error>}, {"parent_classes", <expression error>}}’ from ‘<brace-enclosed initializer list>’ to ‘std::map<std::__cxx11::basic_string<char>, octave_value>’
        {"parent_classes", dump_container_map (m_parent_map)}};
                                                             ^
make[2]: *** [Makefile:18264: libinterp/corefcn/libinterp_corefcn_libcorefcn_la-symtab.lo] Error 1


 

 
--
mike


​Dmitri.
--

​Dmitri.
 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gcc7 build error with recent tip

John W. Eaton
Administrator
On 06/23/2017 06:39 PM, Dmitri A. Sergatskov wrote:

>
>
> On Fri, Jun 23, 2017 at 4:58 PM, Dmitri A. Sergatskov
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     On Fri, Jun 23, 2017 at 4:38 PM, Mike Miller <[hidden email]
>     <mailto:[hidden email]>> wrote:
>
>         On Fri, Jun 23, 2017 at 16:03:00 -0500, Dmitri A. Sergatskov wrote:
>         > It failing the same way on few computers (all with Fedora 26-beta).
>         > Perhaps it is
>         > a compiler issue (clang does not have problem with it). It persists
>         > (see fedora builds on http://buildbot.octave.org:8010/waterfall
>         <http://buildbot.octave.org:8010/waterfall>)
>
>         I get the same error with gcc-snapshot in Debian (gcc trunk
>         r249349).
>         Next stop bug tracker.
>
>
>     ​It compiles if I set CXXFLAGS to -std=c++1z or -std=c++14
>     and fails again with -std=c++11
>
>
> ​I managed to confuse myself with all those flags -- it compiles with ​
> -std=c++1z
> fails with either -std=c++11 or std=c++14:
>
> <<<<
> HG ID for this build is "6fe13cd3543c"

I admit this code is a bit tricky.  I was trying to come up with a way
to use a single template that would cover both of these cases:

   static octave_value
   dump_container_map (const std::map<std::string, std::list<std::string>>&)

   static octave_value
   dump_container_map (const std::map<std::string, std::map<std::string>>&)

It works for me with gcc version 6.3.0 20170516 (Debian 6.3.0-18).

Does it help to add statements to explicitly instantiate these forms for
the initializer list?  Or to provide non-template wrapper functions?

jwe



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gcc7 build error with recent tip

Dmitri A. Sergatskov
On Sat, Jun 24, 2017 at 10:59 AM, John W. Eaton <[hidden email]> wrote:

I admit this code is a bit tricky.  I was trying to come up with a way to use a single template that would cover both of these cases:

  static octave_value
  dump_container_map (const std::map<std::string, std::list<std::string>>&)

  static octave_value
  dump_container_map (const std::map<std::string, std::map<std::string>>&)

It works for me with gcc version 6.3.0 20170516 (Debian 6.3.0-18).

​It is quite possible this is a bug in gcc7.1.1.
would like to see what Jakub has to say about it.
 
jwe




​Dmitri.
--

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gcc7 build error with recent tip

Daniel Sebald
In reply to this post by John W. Eaton
On 06/24/2017 10:59 AM, John W. Eaton wrote:

> On 06/23/2017 06:39 PM, Dmitri A. Sergatskov wrote:
>>
>>
>> On Fri, Jun 23, 2017 at 4:58 PM, Dmitri A. Sergatskov
>> <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>     On Fri, Jun 23, 2017 at 4:38 PM, Mike Miller <[hidden email]
>>     <mailto:[hidden email]>> wrote:
>>
>>         On Fri, Jun 23, 2017 at 16:03:00 -0500, Dmitri A. Sergatskov
>> wrote:
>>         > It failing the same way on few computers (all with Fedora
>> 26-beta).
>>         > Perhaps it is
>>         > a compiler issue (clang does not have problem with it). It
>> persists
>>         > (see fedora builds on http://buildbot.octave.org:8010/waterfall
>>         <http://buildbot.octave.org:8010/waterfall>)
>>
>>         I get the same error with gcc-snapshot in Debian (gcc trunk
>>         r249349).
>>         Next stop bug tracker.
>>
>>
>>     ​It compiles if I set CXXFLAGS to -std=c++1z or -std=c++14
>>     and fails again with -std=c++11
>>
>>
>> ​I managed to confuse myself with all those flags -- it compiles with ​
>> -std=c++1z
>> fails with either -std=c++11 or std=c++14:
>>
>> <<<<
>> HG ID for this build is "6fe13cd3543c"
>
> I admit this code is a bit tricky.  I was trying to come up with a way
> to use a single template that would cover both of these cases:
>
>   static octave_value
>   dump_container_map (const std::map<std::string, std::list<std::string>>&)
>
>   static octave_value
>   dump_container_map (const std::map<std::string, std::map<std::string>>&)
>
> It works for me with gcc version 6.3.0 20170516 (Debian 6.3.0-18).
>
> Does it help to add statements to explicitly instantiate these forms for
> the initializer list?  Or to provide non-template wrapper functions?

Yeah, that is tricky, i.e., trying to pass a pointer to the template
reference as part of the template declaration/definition.  One would
have to go to the C++ definition for various versions to determine if
that is or isn't a compiler bug.

Hmm, is it possible to do some kind of typedef ahead of the template
definition, a technique that often solves the same kind of referencing
issues with C?

Dan

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gcc7 build error with recent tip

John W. Eaton
Administrator
On 06/24/2017 12:39 PM, Daniel J Sebald wrote:

> Hmm, is it possible to do some kind of typedef ahead of the template
> definition, a technique that often solves the same kind of referencing
> issues with C?

I couldn't find one that worked.  I checked in the following changeset
to get around the problem for now:

http://hg.savannah.gnu.org/hgweb/octave/rev/a94ed7424d63

jwe



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gcc7 build error with recent tip

Daniel Sebald
In reply to this post by Dmitri A. Sergatskov
On 06/24/2017 11:21 AM, Dmitri A. Sergatskov wrote:

> On Sat, Jun 24, 2017 at 10:59 AM, John W. Eaton <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>     I admit this code is a bit tricky.  I was trying to come up with a
>     way to use a single template that would cover both of these cases:
>
>       static octave_value
>       dump_container_map (const std::map<std::string,
>     std::list<std::string>>&)
>
>       static octave_value
>       dump_container_map (const std::map<std::string,
>     std::map<std::string>>&)
>
>     It works for me with gcc version 6.3.0 20170516 (Debian 6.3.0-18).
>
>
> ​It is quite possible this is a bug in gcc7.1.1.
> I filled a bug:
>
> ​https://bugzilla.redhat.com/show_bug.cgi?id=1464612
>
> would like to see what Jakub has to say about it.

Yes, that is quite possible, based upon the error message.  The compiler
identifies the proper candidate, but it is telling us that the candidate
expects only one argument.  I.e.,

../src/libinterp/corefcn/symtab.cc:1424:1: note: candidate:
template<class V, template<class ...> class C> octave_value
dump_container_map(const std::map<std::__cxx11::basic_string<char>, C<V> >&)
  dump_container_map (const std::map<std::string, C<V>>& container_map)
  ^~~~~~~~~~~~~~~~~~
../src/libinterp/corefcn/symtab.cc:1424:1: note:   template argument
deduction/substitution failed:
../src/libinterp/corefcn/symtab.cc:1446:73: note:   candidate expects 1
argument, 3 provided
         {"precedence_table", dump_container_map
(m_class_precedence_table)},

but I don't understand where the compiler is getting those number 3
from.  Here's the definition of m_class_precedence_table:

std::map<std::string, std::set<std::string>> m_class_precedence_table;

That would be either 1 (m_class_precedence_table consider one argument)
or 2 (expanded m_class_precedence_table).  I think the compiler in this
case is truncating the template when it sees the word "template" again.
That would be "1" and perhaps something strange in the compiler expands
the second "template" into 2 arguments, hence creating 1 + 2 = 3 arguments.

Dan

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gcc7 build error with recent tip

Daniel Sebald
In reply to this post by John W. Eaton
On 06/24/2017 01:12 PM, John W. Eaton wrote:

> On 06/24/2017 12:39 PM, Daniel J Sebald wrote:
>
>> Hmm, is it possible to do some kind of typedef ahead of the template
>> definition, a technique that often solves the same kind of referencing
>> issues with C?
>
> I couldn't find one that worked.  I checked in the following changeset
> to get around the problem for now:
>
> http://hg.savannah.gnu.org/hgweb/octave/rev/a94ed7424d63

I suppose, but the new template code isn't being used for any compilers
now with the "#if 0".  Is using template qualifier in a nested way
unconventional?  Probably not.  Some alternatives would be:

1) If GCC7 developers decide this is a compiler bug, use the new
template syntax without the two separate implementations, and place a
restriction in "configure" disabling the use of GCC7 prior to the
version associated with the fix.

2) Perhaps some alternate syntax, given the GCC7 compiler must have some
means of doing such a construct.  Dimitri, in your bug report, please
ask if there is some alternate syntax for achieving the nested construct
that GCC developers know works for GCC7.

Dan

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gcc7 build error with recent tip

Daniel Sebald
On 06/24/2017 01:58 PM, Daniel J Sebald wrote:

> On 06/24/2017 01:12 PM, John W. Eaton wrote:
>> On 06/24/2017 12:39 PM, Daniel J Sebald wrote:
>>
>>> Hmm, is it possible to do some kind of typedef ahead of the template
>>> definition, a technique that often solves the same kind of referencing
>>> issues with C?
>>
>> I couldn't find one that worked.  I checked in the following changeset
>> to get around the problem for now:
>>
>> http://hg.savannah.gnu.org/hgweb/octave/rev/a94ed7424d63
>
> I suppose, but the new template code isn't being used for any compilers
> now with the "#if 0".  Is using template qualifier in a nested way
> unconventional?  Probably not.  Some alternatives would be:
>
> 1) If GCC7 developers decide this is a compiler bug, use the new
> template syntax without the two separate implementations, and place a
> restriction in "configure" disabling the use of GCC7 prior to the
> version associated with the fix.
>
> 2) Perhaps some alternate syntax, given the GCC7 compiler must have some
> means of doing such a construct.  Dimitri, in your bug report, please
> ask if there is some alternate syntax for achieving the nested construct
> that GCC developers know works for GCC7.

I was thinking GCC7 was legacy compiler (confused with the number of
C++11, etc.), but it is the latest:

http://fedoraproject.org/wiki/Changes/GCC7

How about making the

#if 0

case to something like conditioning on GCC_CXX='no' or GCC_VERSION <
7.x.x?  That would continue getting some feedback (in the short term,
i.e., non-release) on other compilers that might have similar issues.

Dan

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gcc7 build error with recent tip

John W. Eaton
Administrator
In reply to this post by Daniel Sebald
On 06/24/2017 02:23 PM, Daniel J Sebald wrote:

> On 06/24/2017 11:21 AM, Dmitri A. Sergatskov wrote:
>> On Sat, Jun 24, 2017 at 10:59 AM, John W. Eaton <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>
>>     I admit this code is a bit tricky.  I was trying to come up with a
>>     way to use a single template that would cover both of these cases:
>>
>>       static octave_value
>>       dump_container_map (const std::map<std::string,
>>     std::list<std::string>>&)
>>
>>       static octave_value
>>       dump_container_map (const std::map<std::string,
>>     std::map<std::string>>&)
>>
>>     It works for me with gcc version 6.3.0 20170516 (Debian 6.3.0-18).
>>
>>
>> ​It is quite possible this is a bug in gcc7.1.1.
>> I filled a bug:
>>
>> ​https://bugzilla.redhat.com/show_bug.cgi?id=1464612
>>
>> would like to see what Jakub has to say about it.
>
> Yes, that is quite possible, based upon the error message.  The compiler
> identifies the proper candidate, but it is telling us that the candidate
> expects only one argument.  I.e.,
>
> ../src/libinterp/corefcn/symtab.cc:1424:1: note: candidate:
> template<class V, template<class ...> class C> octave_value
> dump_container_map(const std::map<std::__cxx11::basic_string<char>, C<V>
>>&)
>  dump_container_map (const std::map<std::string, C<V>>& container_map)
>  ^~~~~~~~~~~~~~~~~~
> ../src/libinterp/corefcn/symtab.cc:1424:1: note:   template argument
> deduction/substitution failed:
> ../src/libinterp/corefcn/symtab.cc:1446:73: note:   candidate expects 1
> argument, 3 provided
>         {"precedence_table", dump_container_map
> (m_class_precedence_table)},
>
> but I don't understand where the compiler is getting those number 3
> from.  Here's the definition of m_class_precedence_table:

The template substitution that is failing is for std::set which takes 1,
2, or 3 template parameters.  The other, for std::list, takes 1 or 2.

I checked in the following changeset and the problem seems to be fixed
for both GCC 6 and 7:

   http://hg.savannah.gnu.org/hgweb/octave/rev/93371ce5378d

Now I'm not sure whether this is a bug in GCC 7 or if it was a bug in
previous versions to accept the template without the "A..." argument.

jwe





Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gcc7 build error with recent tip

Daniel Sebald
On 06/24/2017 02:58 PM, John W. Eaton wrote:

> On 06/24/2017 02:23 PM, Daniel J Sebald wrote:
>> On 06/24/2017 11:21 AM, Dmitri A. Sergatskov wrote:
>>> On Sat, Jun 24, 2017 at 10:59 AM, John W. Eaton <[hidden email]
>>> <mailto:[hidden email]>> wrote:
>>>
>>>
>>>     I admit this code is a bit tricky.  I was trying to come up with a
>>>     way to use a single template that would cover both of these cases:
>>>
>>>       static octave_value
>>>       dump_container_map (const std::map<std::string,
>>>     std::list<std::string>>&)
>>>
>>>       static octave_value
>>>       dump_container_map (const std::map<std::string,
>>>     std::map<std::string>>&)
>>>
>>>     It works for me with gcc version 6.3.0 20170516 (Debian 6.3.0-18).
>>>
>>>
>>> ​It is quite possible this is a bug in gcc7.1.1.
>>> I filled a bug:
>>>
>>> ​https://bugzilla.redhat.com/show_bug.cgi?id=1464612
>>>
>>> would like to see what Jakub has to say about it.
>>
>> Yes, that is quite possible, based upon the error message.  The compiler
>> identifies the proper candidate, but it is telling us that the candidate
>> expects only one argument.  I.e.,
>>
>> ../src/libinterp/corefcn/symtab.cc:1424:1: note: candidate:
>> template<class V, template<class ...> class C> octave_value
>> dump_container_map(const std::map<std::__cxx11::basic_string<char>, C<V>
>>> &)
>>  dump_container_map (const std::map<std::string, C<V>>& container_map)
>>  ^~~~~~~~~~~~~~~~~~
>> ../src/libinterp/corefcn/symtab.cc:1424:1: note:   template argument
>> deduction/substitution failed:
>> ../src/libinterp/corefcn/symtab.cc:1446:73: note:   candidate expects 1
>> argument, 3 provided
>>         {"precedence_table", dump_container_map
>> (m_class_precedence_table)},
>>
>> but I don't understand where the compiler is getting those number 3
>> from.  Here's the definition of m_class_precedence_table:
>
> The template substitution that is failing is for std::set which takes 1,
> 2, or 3 template parameters.  The other, for std::list, takes 1 or 2.

Oh.  Looking at the second error in Dmitri's original email, I see now
that one says "2 provided" as opposed to "3 provided" from the first
error.  The error message points directly at dump_container_map() which
made me think that was the source of error when in fact it is the
expansion inside the template.

Well, that works then.


> I checked in the following changeset and the problem seems to be fixed
> for both GCC 6 and 7:
>
>   http://hg.savannah.gnu.org/hgweb/octave/rev/93371ce5378d
>
> Now I'm not sure whether this is a bug in GCC 7 or if it was a bug in
> previous versions to accept the template without the "A..." argument.

Or maybe that is a difference between C++11 and its predecessors, i.e.,
more explicit definition of templates rather than leaving it to
interpretation.  (I see ::__cxx11:: in some variable names in the error
messages so I assume the compiler is doing C++11.)

Dan

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gcc7 build error with recent tip

Stefan Husmann
In reply to this post by Dmitri A. Sergatskov
"Dmitri A. Sergatskov" <[hidden email]> writes:

> On Fri, Jun 23, 2017 at 4:58 PM, Dmitri A. Sergatskov <
> [hidden email]> wrote:
>
>> On Fri, Jun 23, 2017 at 4:38 PM, Mike Miller <[hidden email]> wrote:
>>
>>> On Fri, Jun 23, 2017 at 16:03:00 -0500, Dmitri A. Sergatskov wrote:
>>> > It failing the same way on few computers (all with Fedora 26-beta).
>>> > Perhaps it is
>>> > a compiler issue (clang does not have problem with it). It persists
>>> > (see fedora builds on http://buildbot.octave.org:8010/waterfall)
>>>
>>> I get the same error with gcc-snapshot in Debian (gcc trunk r249349).
>>> Next stop bug tracker.
>>>
>>>
>> ​It compiles if I set CXXFLAGS to -std=c++1z or -std=c++14
>> and fails again with -std=c++11
>>
>
Hello,

I got the same error under Arch Linux, but -std=c++11 did not change
this here. Using clang (i.e. adding CC=clang CXX=clang++ to the
configure call) was a working workaround here.

So I think this error is related to gcc 7.1 itself, not to the version shipped
with Fedora or Debian.

Best Regards

Stefan Husmann

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gcc7 build error with recent tip

Dmitri A. Sergatskov
In reply to this post by John W. Eaton


On Sat, Jun 24, 2017 at 2:58 PM, John W. Eaton <[hidden email]> wrote:

I checked in the following changeset and the problem seems to be fixed for both GCC 6 and 7:

  http://hg.savannah.gnu.org/hgweb/octave/rev/93371ce5378d

Now I'm not sure whether this is a bug in GCC 7 or if it was a bug in previous versions to accept the template without the "A..." argument.

​Jakub Jelinek has some suggestions (see comment #10)
https://bugzilla.redhat.com/show_bug.cgi?id=1464612

​Just fyi.​


 

jwe


​Dmitri.
--
 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gcc7 build error with recent tip

Daniel Sebald
On 06/26/2017 07:49 AM, Dmitri A. Sergatskov wrote:

>
>
> On Sat, Jun 24, 2017 at 2:58 PM, John W. Eaton <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>     I checked in the following changeset and the problem seems to be
>     fixed for both GCC 6 and 7:
>
>       http://hg.savannah.gnu.org/hgweb/octave/rev/93371ce5378d
>     <http://hg.savannah.gnu.org/hgweb/octave/rev/93371ce5378d>
>
>     Now I'm not sure whether this is a bug in GCC 7 or if it was a bug
>     in previous versions to accept the template without the "A..." argument.
>
>
> ​Jakub Jelinek has some suggestions (see comment #10)
> ​
> https://bugzilla.redhat.com/show_bug.cgi?id=1464612

J.W. in comment 11 makes a suggestion sort of along the lines of the
typedef-strategy, i.e., defining smaller templates to use within the
broader template:

https://bugzilla.redhat.com/show_bug.cgi?id=1464612#c11

Templates are open for creativity, for sure.

Dan

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gcc7 build error with recent tip

Dmitri A. Sergatskov

​This has been reported upstream:

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

FYI.

Dmitri.
--


Loading...