Traffic Server
  1. Traffic Server
  2. TS-125

Cannot use user-defined types in typedef of template function

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.1.0
    • Fix Version/s: 2.1.0
    • Component/s: Portability
    • Labels:
      None
    • Environment:

      OpenSolaris with SunStudio (gcc on opensolaris fails the same code with a different error; same workaround fixes it)

      Description

      This appears to be related to Sun bug http://bugs.sun.com/view_bug.do?bug_id=6906118
      but is sufficiently different that the workaround suggested there doesn't apply.

      Compiling DAllocator.h produces the following fatal error:

      "DAllocator.h", line 86: Error: Unexpected type name "AllocPoolDescriptor" encountered.
      "DAllocator.h", line 87: Error: Unexpected type name "AllocDescriptor" encountered.

      It can be worked around by reverting:

      @@ -83,8 +83,8 @@
      int alignment;
      int el_size;

      • SList(AllocPoolDescriptor,link) pools;
      • Que(AllocDescriptor,link) free_list;
        + SLL<AllocPoolDescriptor> pools;
        + Queue<AllocDescriptor> free_list;

      Expanding that with the -E option to CC reveals that this loses an offsetof argument, so if we could fix the offset to zero then the problem goes away. If at all possible, it would be good to make "link" the first element of AllocDescriptor and AllocPoolDescriptor so the need for offsetof goes away.

      1. 0001-TS125_offsetof_jp_v2.diff.patch
        105 kB
        George Paul
      2. ts-125-offsetof-jp-v1.patch
        79 kB
        John Plevyak

        Issue Links

          Activity

          Hide
          John Plevyak added a comment -

          Looks good to me, check it in

          Show
          John Plevyak added a comment - Looks good to me, check it in
          Hide
          George Paul added a comment -

          Update jplevyak's original patch with '0001-TS125_offsetof_jp_v2.diff.patch' for more fixes with the Sun Studio compiler suite. Retested on OSX(10.5), Linux(Ubuntu904) and FreeBSD(7.2).

          The one remaining issue on OpenSolaris w/ Sun Studio is that the atomic operations need to be provided/ported to 64 bit. Jira Ticket TS-226 has been opened for this.

          Please review,

          -George

          Show
          George Paul added a comment - Update jplevyak's original patch with '0001-TS125_offsetof_jp_v2.diff.patch' for more fixes with the Sun Studio compiler suite. Retested on OSX(10.5), Linux(Ubuntu904) and FreeBSD(7.2). The one remaining issue on OpenSolaris w/ Sun Studio is that the atomic operations need to be provided/ported to 64 bit. Jira Ticket TS-226 has been opened for this. Please review, -George
          Hide
          John Plevyak added a comment -

          This patch converts the use of offsetof in List.h into the
          use of a template argument to handle specialization
          of SLL/DLL/Queue wrt the Link field.

          This should address the problem with compilation using SunCC
          and other truely lame compilers that insist on throwing errors
          on otherwise perfectly good code just because the spec permits
          them to.

          With GCC 4.4 at least, this change produces exactly the same efficient code
          on test_List.cc.

          Show
          John Plevyak added a comment - This patch converts the use of offsetof in List.h into the use of a template argument to handle specialization of SLL/DLL/Queue wrt the Link field. This should address the problem with compilation using SunCC and other truely lame compilers that insist on throwing errors on otherwise perfectly good code just because the spec permits them to. With GCC 4.4 at least, this change produces exactly the same efficient code on test_List.cc.
          Hide
          John Plevyak added a comment -

          Yes, there was a time before g++ threw a warning.

          Show
          John Plevyak added a comment - Yes, there was a time before g++ threw a warning.
          Hide
          Leif Hedstrom added a comment -

          If I recall, please correct me if I'm wrong, I ended up having to add the following option to gcc, for it to function properly:

          -Wno-invalid-offsetof

          This was done 4+ years ago, so I might be completely off topic .

          Show
          Leif Hedstrom added a comment - If I recall, please correct me if I'm wrong, I ended up having to add the following option to gcc, for it to function properly: -Wno-invalid-offsetof This was done 4+ years ago, so I might be completely off topic .
          Hide
          John Plevyak added a comment -

          Just checked the C++ spec, and it sees that a conformant
          compiler need only give the correct result for offset of
          for POD types despite the fact that only a few features,
          virtual base classes in particular, cause problems for
          it.

          g++ was kind enough to not be pedantic about
          it and just make it work for all the normal cases.

          SunCC seems to have decided to take advantage
          of the spec (and developers) and just throw an
          error even if it could deliver the offset at compile time.

          This could be worked around via some C++/template
          hijinks which would encoded the offset via a template
          parameter class with a single functions, yada yada,
          thus moving the constant into a function call which
          presumably the optimizer would inline and which
          would result in the same code.

          I suppose it is too much to hope that the C++ committee
          will pull their head out and realize that if folks really
          wanted to use a high level language they would be using
          scala or F# or something and that they should leave the
          low level functionality in C++ alone

          Show
          John Plevyak added a comment - Just checked the C++ spec, and it sees that a conformant compiler need only give the correct result for offset of for POD types despite the fact that only a few features, virtual base classes in particular, cause problems for it. g++ was kind enough to not be pedantic about it and just make it work for all the normal cases. SunCC seems to have decided to take advantage of the spec (and developers) and just throw an error even if it could deliver the offset at compile time. This could be worked around via some C++/template hijinks which would encoded the offset via a template parameter class with a single functions, yada yada, thus moving the constant into a function call which presumably the optimizer would inline and which would result in the same code. I suppose it is too much to hope that the C++ committee will pull their head out and realize that if folks really wanted to use a high level language they would be using scala or F# or something and that they should leave the low level functionality in C++ alone
          Hide
          John Plevyak added a comment -

          It is, in general, not possible to ensure that the link field is first,
          if for no other reason than that some classes have more than
          one link field.

          A correct C++ compiler should not have any problem with
          the code, but some compilers are buggy and (for example)
          do not treat offsetof() expressions as constants are required
          by the C++ standard.

          The dev branch is known to compile on opensolaris with
          g++ version 4.3.2, and I would suggest you try that version.

          Show
          John Plevyak added a comment - It is, in general, not possible to ensure that the link field is first, if for no other reason than that some classes have more than one link field. A correct C++ compiler should not have any problem with the code, but some compilers are buggy and (for example) do not treat offsetof() expressions as constants are required by the C++ standard. The dev branch is known to compile on opensolaris with g++ version 4.3.2, and I would suggest you try that version.
          Hide
          George Paul added a comment -

          Nick K,

          Couple of quick questions.

          1. What version of GCC toolchain are you using? Is it available via pkg?
          2. What version of OpenSolaris (osol906?)
          3. What version of Sun Studio?

          thanks,

          -George

          Show
          George Paul added a comment - Nick K, Couple of quick questions. 1. What version of GCC toolchain are you using? Is it available via pkg? 2. What version of OpenSolaris (osol906?) 3. What version of Sun Studio? thanks, -George
          Hide
          Nick Kew added a comment -

          Those bullets in the patch snippet should of course be "-". Jira mangled my input!

          Show
          Nick Kew added a comment - Those bullets in the patch snippet should of course be "-". Jira mangled my input!

            People

            • Assignee:
              John Plevyak
              Reporter:
              Nick Kew
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development