octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gcc7 build error with recent tip


From: Daniel J Sebald
Subject: Re: gcc7 build error with recent tip
Date: Sat, 24 Jun 2017 11:39:29 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0

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
<address@hidden <mailto:address@hidden>> wrote:

    On Fri, Jun 23, 2017 at 4:38 PM, Mike Miller <address@hidden
    <mailto:address@hidden>> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]