GNU Octave - Bugs: bug #41178, clang: ov-classdef.h: constructing...
bug #41178: clang: ov-classdef.h: constructing a map of an incomplete type
Submitter: | Michael C. Grant <mcgrant> | ||
Submitted: | Thu 09 Jan 2014 09:00:10 PM UTC | ||
Category: | Interpreter | Severity: | 3 - Normal |
Priority: | 5 - Normal | Item Group: | Build Failure |
Status: | Fixed | Assigned to: | None |
Originator Name: | Michael C. Grant | Open/Closed: | Closed |
Release: | dev | Operating System: | Any |
Fixed Release: | None | Planned Release: | None |
Discussion locked!
( Jump to the original submission )
Spam posted by shania | |
Spam posted by magalie | |
Fri 11 Dec 2015 04:36:08 PM UTC, comment #30: |
John W. Eaton <jwe>![]() |
Sat 12 Sep 2015 09:35:44 PM UTC, comment #29: Ok, finally pushed to the default branch:
|
Mike Miller <mtmiller>![]() |
Fri 21 Aug 2015 11:47:15 PM UTC, comment #28: Mike M, the patch works for me on Mac OS X.
|
Ben Abbott <bpabbott>![]() |
Fri 21 Aug 2015 10:01:30 PM UTC, comment #27: My reading of the C++ standard is that (as I said in my very first post) "C++ requires that all template parameters in the standard library containers be complete types, so this is non-compliant."
|
Michael C. Grant <mcgrant> |
Fri 21 Aug 2015 08:55:27 PM UTC, comment #26: Otherwise, I have no problem with the patch, so I'd say go ahead and add a comment and push it. |
John W. Eaton <jwe>![]() |
Fri 21 Aug 2015 08:54:30 PM UTC, comment #25: Is this a bug in clang or something that is not guaranteed to work but that GCC just happens to allow? In any case, it might be a good idea to put a comment above the function definition explaining why it is not defined in the header file even though it is apparently a trivial function. Otherwise, someone might have the urge to move it back there. |
John W. Eaton <jwe>![]() |
Fri 21 Aug 2015 05:27:24 PM UTC, comment #24: Attached, ready to push. Works for me with clang 3.5 on Debian. Almost identical to the previously attached patch, but please test anyway replacing the earlier ov-classdef.patch. |
Mike Miller <mtmiller>![]() |
Mon 17 Aug 2015 07:38:51 PM UTC, comment #23: Mike,
|
Ben Abbott <bpabbott>![]() |
Mon 17 Aug 2015 04:03:49 PM UTC, comment #22: I think the ov-classdef patch should definitely be applied, I planned to do this weeks ago but have been overworked. I will try to take care of it soon.
|
Mike Miller <mtmiller>![]() |
Mon 27 Jul 2015 12:43:25 PM UTC, comment #21: I think that the clang3.5-fix patch originates from https://savannah.gnu.org/bugs/?43298. Sadly the decision there was to not apply it because it's considered as a clang 3.5 bug.
|
Sebastian <sschoeps> |
Mon 27 Jul 2015 12:45:37 AM UTC, comment #20: Who should get credit for the clang3.5-fix.patch and include-fix.patch?
|
Ben Abbott <bpabbott>![]() |
Thu 23 Jul 2015 08:45:42 PM UTC, comment #19:
|
Anonymous |
Thu 23 Jul 2015 05:24:14 AM UTC, comment #18: Dear Ben,
|
Sebastian <sschoeps> |
Thu 23 Jul 2015 03:23:25 AM UTC, comment #17: The one change to ov-classdef.* fixes the build for me with clang 3.6, the equivalent of the attached ov-classdef.patch. I tested building with clang 3.6 on Debian both with gcc's libstdc++ and with llvm's libc++, both build successfully.
|
Mike Miller <mtmiller>![]() |
Thu 23 Jul 2015 12:43:17 AM UTC, comment #16: Sebastian,
|
Ben Abbott <bpabbott>![]() |
Wed 22 Jul 2015 10:24:19 PM UTC, comment #15: Hi, I'm the anonymoous.(akira noda )
|
Anonymous |
Wed 22 Jul 2015 01:35:51 PM UTC, comment #14: I am also able to test this on Debian with clang 3.6 (which had the same error as seen on OSX).
|
Mike Miller <mtmiller>![]() |
Wed 22 Jul 2015 01:12:39 PM UTC, comment #13: If someone can attach a complete patch (or set of patches), I can handle the initial testing and push the result to the default branch (assuming I'm successful with building on Yosemite).
|
Ben Abbott <bpabbott>![]() |
Wed 22 Jul 2015 09:41:50 AM UTC, comment #12: Thanks for sharing. I can confirm that this patch allows to compile octave 4.0 also on Yosemite with clang. Homebrew users may find a first formula at https://raw.githubusercontent.com/schoeps/homebrew-science/octave/octave.rb.
|
Sebastian <sschoeps> |
Wed 22 Jul 2015 01:48:31 AM UTC, comment #11: I can build with FreeBSD/clang3.4.1 with fllowing patch
|
Anonymous |
Sat 06 Jun 2015 11:57:33 PM UTC, comment #10: I still see this same error under MacPorts with octave 4.0.0 release vs. Apple clang (Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)) and MacPorts clang-3.6 (clang version 3.6.0 (tags/RELEASE_360/final)).
|
Marius Schamschula <mschamschula> |
Sun 12 Apr 2015 04:11:07 AM UTC, comment #9: I can confirm this bug is still present with clang 3.6 on Debian. |
Mike Miller <mtmiller>![]() |
Tue 03 Feb 2015 11:42:13 PM UTC, comment #8: As octave 4.0 is coming near, I am in the process of building a octave-devel Portfile under MacPorts. As the current Portfile for octave 3.8.2 blacklists clang-3.5 and -3.6, I left this unchanged. So I tried building tip under OS X 10.9.5, with Xcode 6.1.1 using clang-3.4 and ran into the same issue. |
Marius Schamschula <mschamschula> |
Mon 19 Jan 2015 08:44:18 AM UTC, comment #7: I tried to compile octave on OSX 10.10 with clang 3.5 yesterday. The bug seems to be still present. Has anyone looked at it in the mean time? Is there a fix? |
Sebastian <sschoeps> |
Sat 25 Jan 2014 04:39:58 AM UTC, comment #6: Confirmed on Debian GNU/Linux with clang 3.3 and libc++, roughly the same error messages. |
Mike Miller <mtmiller>![]() |
Sat 11 Jan 2014 05:28:28 PM UTC, comment #5: By the way I realized why I thought this was auto generated: because it's a new file not present in all the branches! Anyway, I'm focused on gui-release now, so this is not urgent from my perspective. Only those who need to compile the tip using clang will be affected by this. |
Michael C. Grant <mcgrant> |
Fri 10 Jan 2014 03:55:38 AM UTC, comment #4: I'm sorry for the mistake. Thank you for looking at this!
|
Michael C. Grant <mcgrant> |
Fri 10 Jan 2014 12:33:44 AM UTC, comment #3: For the record, ov-classdef.h is not generated, it's manually hand-written.
|
Michael Goffioul <goffioul> |
Thu 09 Jan 2014 09:15:32 PM UTC, comment #2: I should add that line 743 is also non-compliant, because it's declared within cdef_class itself. I know it sucks...
|
Michael C. Grant <mcgrant> |
Thu 09 Jan 2014 09:06:16 PM UTC, comment #1: FYI, here's the clang++ output for one example compile:
|
Michael C. Grant <mcgrant> |
Thu 09 Jan 2014 09:00:10 PM UTC, original submission:
I've been struggling to compile the dev sources on Mac OSX with the latest Xcode, and it has proven quite frustrating. But I think I've figured out why: you've got some code in there that technically is not standards compliant, and clang++ is deciding to be particularly strict about it.
|
Michael C. Grant <mcgrant> |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 12 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2017-02-13 | mtmiller | Discussion Lock | Unlocked | ![]() |
Locked |
2015-09-12 | mtmiller | Status | Patch Submitted | ![]() |
Fixed |
Open/Closed | Open | ![]() |
Closed | ||
2015-08-21 | mtmiller | Attached File | - | ![]() |
Added octave-clang-classdef.patch, #34691 |
2015-07-23 | mtmiller | Status | Confirmed | ![]() |
Patch Submitted |
2015-07-22 | sschoeps | Attached File | - | ![]() |
Added clang3.5-fix.patch, #34489 |
Attached File | - | ![]() |
Added ov-classdef.patch, #34490 | ||
Attached File | - | ![]() |
Added include-fix.patch, #34491 | ||
2015-06-18 | joetastic | Carbon-Copy | - | ![]() |
Added joetastic |
2015-04-12 | mtmiller | Summary | ov-classdef.h: constructing a map of an incomplete type | ![]() |
clang: ov-classdef.h: constructing a map of an incomplete type |
2015-02-09 | bpabbott | Carbon-Copy | - | ![]() |
Added -email is unavailable- |
2014-01-25 | mtmiller | Status | None | ![]() |
Confirmed |
This change was so trivial that I decided to graft it to stable for the 4.0.1 release.