FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=master 2020-02-20T21:29:59Z 2020-02-20T21:29:59Z Rebecca Cran bcran@FreeBSD.org 2020-02-20T21:29:59Z urn:sha1:1631f217456127bc1c7f14d4aa2eb3ad448c0049 Since we don't set opterr to 0, getopt prints a message when it encounters an unknown/invalid option. We therefore don't need to print our own message in the default handler. Reviewed by: kevans, theraven Differential Revision: https://reviews.freebsd.org/D23662 2020-02-14T18:50:03Z Kyle Evans kevans@FreeBSD.org 2020-02-14T18:50:03Z urn:sha1:d16c90f51c0ef389ed7ef7d823acc9812ce165ad I missed in final review of r357923's diff that these ones hadn't yet been sent upstream and inadvertently reverted them. =-( Re-apply now. 2020-02-14T18:46:34Z Kyle Evans kevans@FreeBSD.org 2020-02-14T18:46:34Z urn:sha1:aac4229aac3b59dedd160793faf21e18cf85bdfc This includes a small battery of /memreserve/ fixes to make sure dtc is properly writing these regions into the output file and reading them back out. As of this update, dtc will now also assume common defaults for -I/-O if only one is specified; namely, dts for one implies dtb for the other and vice versa (Requested by: jhibbits, preserves GPL dtc behavior too). MFC after: 1 week 2019-10-26T17:10:27Z Emmanuel Vadot manu@FreeBSD.org 2019-10-26T17:10:27Z urn:sha1:c571e05c2caf6c8c5366805eaf0b682fba480322 Some dts are including dtsi that also contain a /dts-v1/ tag at the top. GNU DTC doesn't seems to have a problem with that so fix our dtc to behave the same. Reviewed by: kevans MFC after: 1 week 2019-10-23T19:23:31Z Warner Losh imp@FreeBSD.org 2019-10-23T19:23:31Z urn:sha1:dd376a963c425dabad6a5ea22d32716408d6661c FreeBSD 10.3 requires this, and dtc is a bootstrap tool so it needs to compile there. 2019-05-10T17:05:40Z Leandro Lupori luporl@FreeBSD.org 2019-05-10T17:05:40Z urn:sha1:8edae83905d0a4eb1472d7b9def7d07195ced5a6 The algorithm header is needed to use std::remove_if 2019-04-22T18:38:54Z Enji Cooper ngie@FreeBSD.org 2019-04-22T18:38:54Z urn:sha1:1109b774513f471d3b62ea220243c8e14d482f03 This change allows the user to once again override the C++ standard, restoring high-level pre-r345708 behavior. This also unbreaks building lib/ofed/libibnetdisc/Makefile with a non-C++11 capable compiler, e.g., g++ 4.2.1, as the library supported being built with older C++ standards. MFC after: 2 weeks MFC with: r345708 Reviewed by: emaste Reported by: jbeich Differential Revision: https://reviews.freebsd.org/D19895 (as part of a larger change) 2019-04-21T01:58:42Z Kyle Evans kevans@FreeBSD.org 2019-04-21T01:58:42Z urn:sha1:7251c2d8bc77a592ff71cfcf5ae66c444cca4553 Specifically, parse errors within a node would lead to a segfault due to an unconditional dereference after emitting the error. Obtained from: https://github.com/davidchisnall/dtc/commit/e5ecf9319fd3f MFC after: 3 days 2019-03-29T18:45:27Z Enji Cooper ngie@FreeBSD.org 2019-03-29T18:45:27Z urn:sha1:e8067928ff5f819ef78ad4acfb12124415ea2fff CXXSTD was added as the C++ analogue to CSTD. CXXSTD defaults to `-std=c++11` with supporting compilers; `-std=gnu++98`, otherwise for older versions of g++. This change standardizes the CXXSTD variable, originally added to googletest.test.inc.mk as part of r345203. As part of this effort, convert all `CXXFLAGS+= -std=*` calls to use `CXXSTD`. Notes: This value is not sanity checked in bsd.sys.mk, however, given the two most used C++ compilers on FreeBSD (clang++ and g++) support both modes, it is likely to work with both toolchains. This method will be refined in the future to support more variants of C++, as not all versions of clang++ and g++ (for instance) support C++14, C++17, etc. Any manual appending of `-std=*` to `CXXFLAGS` should be replaced with CXXSTD. Example: Before this commit: ``` CXXFLAGS+= -std=c++14 ``` After this commit: ``` CXXSTD= c++14 ``` Reviewed by: asomers Approved by: emaste (mentor) MFC after: 1 month MFC with: r345203, r345704, r345705 Relnotes: yes Tested with: make tinderbox Differential Revision: https://reviews.freebsd.org/D19732 2019-03-29T18:43:46Z Enji Cooper ngie@FreeBSD.org 2019-03-29T18:43:46Z urn:sha1:bdbf3440cef44fdda6b975e29805df1c88b1c9f6 When a review is closed via Phabricator it updates the patch attached to the review. I downloaded the raw patch from Phabricator, applied it, and repeated my mistake from r345704 by accident mixing content from D19732 and D19738. For my own personal sanity, I will try not to mix reviews like this in the future. MFC after: 1 month MFC with: r345706 Approved by: emaste (mentor, implicit)