[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 --- Comment #2 from Lawrence Velázquez --- (In reply to Jeremy Huddleston Sequoia from comment #1) > Larry said that he's working on a patch to fix this for gcc trunk, and I > suspect he's pretty close to having something since that was about a week > ago. I just completed the fix and will attach it as soon as I verify that GCC builds with it and that the tests I added pass.
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 --- Comment #3 from Lawrence Velázquez --- Created attachment 33968 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33968&action=edit patch against trunk for handling deployment targets correctly This is more of a rewrite than just a patch. I've divorced parsing of the version string from assembly of legacy macro values from assembly of modern macro values. It should hopefully be easier to make adjustments in the future, since this code is more than a crude DFA implementation.
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 --- Comment #4 from Lawrence Velázquez --- Created attachment 33969 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33969&action=edit patch against 4.9 branch for handling deployment targets correctly Patched GCC 4.9.2 matched the behavior of Apple LLVM Compiler 6.0 (clang-600.0.54) over 8,451 out of 8,464 test strings. The 13 mismatches are due to a bug in clang.
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 --- Comment #5 from Lawrence Velázquez --- Created attachment 33970 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33970&action=edit patch against 4.8 branch for handling deployment targets correctly This patch incorporates and supersedes attachment 33932 from bug 61407.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #52 from Lawrence Velázquez --- Attachment 33932 should be superseded by attachment 33970 from bug 63810.
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 --- Comment #7 from Lawrence Velázquez --- (In reply to howarth from comment #6) > ../../gcc-5-20141114/gcc/config/darwin-c.c: In function ‘const char* > version_as_modern_macro(const long unsigned int*)’: > ../../gcc-5-20141114/gcc/config/darwin-c.c:711:7: error: comparison between > signed and unsigned integer expressions [-Werror=sign-compare] >!= ((major > 9) ? sizeof "99" : sizeof "9") - 1) >^ Seriously?
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 Lawrence Velázquez changed: What|Removed |Added Attachment #33968|0 |1 is obsolete|| --- Comment #8 from Lawrence Velázquez --- Created attachment 33975 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33975&action=edit updated trunk patch that satisfies -Werror=sign-compare
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810
Lawrence Velázquez changed:
What|Removed |Added
Attachment #33975|updated trunk patch that|patch against trunk for
description|satisfies |handling deployment targets
|-Werror=sign-compare|correctly
--- Comment #9 from Lawrence Velázquez ---
Comment on attachment 33975
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33975
patch against trunk for handling deployment targets correctly
>diff --git a/gcc/config/darwin-c.c b/gcc/config/darwin-c.c
>index ffefa37..311cdd4 100644
>--- a/gcc/config/darwin-c.c
>+++ b/gcc/config/darwin-c.c
>@@ -590,42 +590,167 @@ find_subframework_header (cpp_reader *pfile, const char
>*header, cpp_dir **dirp)
> return 0;
> }
>
>-/* Return the value of darwin_macosx_version_min suitable for the
>- __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ macro, so '10.4.2'
>- becomes 1040 and '10.10.0' becomes 101000. The lowest digit is
>- always zero, as is the second lowest for '10.10.x' and above.
>- Print a warning if the version number can't be understood. */
>+/* Given a version string, return the version as a statically-allocated
>+array of three non-negative integers. If the version string is
>+invalid, return null.
>+
>+Version strings must consist of one, two, or three tokens, each
>+separated by a single period. Each token must contain only the
>+characters '0' through '9' and is converted to an equivalent
>+integer. Omitted tokens are treated as zeros. For example:
>+
>+"10" becomes {10,0,0}
>+"10.10" becomes {10,10,0}
>+"10.10.1" becomes {10,10,1}
>+"10.10.1" becomes {10,10,1}
>+"10.010.001" becomes {10,10,1}
>+"10.10.1" becomes {10,10,1} */
>+
>+enum version_components { MAJOR, MINOR, TINY };
>+
>+static const unsigned long *
>+parse_version (const char *version_str)
>+{
>+ size_t version_len;
>+ char *end;
>+ static unsigned long version_array[3];
>+
>+ if (! version_str)
>+return NULL;
>+
>+ version_len = strlen (version_str);
>+ if (version_len < 1)
>+return NULL;
>+
>+ /* Version string must consist of digits and periods only. */
>+ if (strspn (version_str, "0123456789.") != version_len)
>+return NULL;
>+
>+ if (! ISDIGIT (version_str[0]) || ! ISDIGIT (version_str[version_len - 1]))
>+return NULL;
>+
>+ version_array[MAJOR] = strtoul (version_str, &end, 10);
>+ version_str = end + ((*end == '.') ? 1 : 0);
>+
>+ /* Version string must not contain adjacent periods. */
>+ if (*version_str == '.')
>+return NULL;
>+
>+ version_array[MINOR] = strtoul (version_str, &end, 10);
>+ version_str = end + ((*end == '.') ? 1 : 0);
>+
>+ version_array[TINY] = strtoul (version_str, &end, 10);
>+
>+ /* Version string must contain no more than three tokens. */
>+ if (*end != '\0')
>+return NULL;
>+
>+ return version_array;
>+}
>+
>+/* Given a three-component version represented as an array of
>+non-negative integers, return a statically-allocated string suitable
>+for the legacy __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ macro.
>+If the version is invalid and cannot be coerced into a valid form,
>+return null.
>+
>+The legacy format is a four-character string -- two chars for the
>+major number and one each for the minor and tiny numbers. Major
>+numbers are zero-padded if necessary. Minor and tiny numbers from
>+10 through 99 are permitted but are clamped to 9 (for example,
>+{10,9,10} produces "1099"). Versions containing numbers greater
>+than 99 are rejected. */
>+
> static const char *
>-version_as_macro (void)
>+version_as_legacy_macro (const unsigned long *version)
> {
>- static char result[7] = "1000";
>- int minorDigitIdx;
>+ unsigned long major = version[MAJOR];
>+ unsigned long minor = version[MINOR];
>+ unsigned long tiny = version[TINY];
>+ static char result[sizeof ""];
>
>- if (strncmp (darwin_macosx_version_min, "10.", 3) != 0)
>+ if (major > 99 || minor > 99 || tiny > 99)
>+return NULL;
>+
>+ minor = ((minor > 9) ? 9 : minor);
>+ tiny = ((tiny > 9) ? 9 : tiny);
>+
>+ /* NOTE: Cast result of sizeof so that result of sprintf is not
>+ converted to an unsigned type. */
>+ if (sprintf (result, "%02lu%lu%lu", major, minor, tiny)
>+ != (int) sizeof "" - 1)
>+return NULL;
>+
>+ return result;
>+}
>+
>+/* Given a three-component version represented as an array of
>+non-negative integers, return a statically-allocated string suitable
>+for the modern __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ macro
>+or the __ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__ macro. If the
>+version is invalid, return null.
>+
>+The modern format is a five- or six-character
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 Lawrence Velázquez changed: What|Removed |Added Attachment #33969|0 |1 is obsolete|| --- Comment #10 from Lawrence Velázquez --- Created attachment 33976 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33976&action=edit patch against 4.9 branch for handling deployment targets correctly New 4.9 patch that should satisfy -Werror=sign-compare.
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 Lawrence Velázquez changed: What|Removed |Added Attachment #33970|0 |1 is obsolete|| --- Comment #11 from Lawrence Velázquez --- Created attachment 33977 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33977&action=edit patch against 4.8 branch for handling deployment targets correctly Updated patch that should satisfy -Werror=sign-compare.
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 Lawrence Velázquez changed: What|Removed |Added Attachment #33975|0 |1 is obsolete|| --- Comment #12 from Lawrence Velázquez --- Created attachment 34007 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34007&action=edit patch against trunk to handle deployment targets correctly Added some missing null checks; minor comment editing.
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 Lawrence Velázquez changed: What|Removed |Added Attachment #33977|0 |1 is obsolete|| --- Comment #14 from Lawrence Velázquez --- Created attachment 34009 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34009&action=edit patch against 4.8 branch to handle deployment targets correctly Added some missing null checks; minor comment editing.
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 Lawrence Velázquez changed: What|Removed |Added Attachment #33976|0 |1 is obsolete|| --- Comment #13 from Lawrence Velázquez --- Created attachment 34008 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34008&action=edit patch against 4.9 branch to handle deployment targets correctly Added some missing null checks; minor comment editing.
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 Lawrence Velázquez changed: What|Removed |Added Attachment #34007|0 |1 is obsolete|| --- Comment #15 from Lawrence Velázquez --- Created attachment 34010 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34010&action=edit patch against trunk to handle deployment targets correctly Forgot to fix a comment in the last update.
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 Lawrence Velázquez changed: What|Removed |Added Attachment #34008|0 |1 is obsolete|| --- Comment #16 from Lawrence Velázquez --- Created attachment 34011 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34011&action=edit patch against 4.9 branch to handle deployment targets correctly Forgot to fix a comment in the last update.
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 Lawrence Velázquez changed: What|Removed |Added Attachment #34009|0 |1 is obsolete|| --- Comment #17 from Lawrence Velázquez --- Created attachment 34012 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34012&action=edit patch against 4.8 branch to handle deployment targets correctly Forgot to fix a comment in the last update.
[Bug bootstrap/63703] [4.9 Regression] cc1: internal compiler error: in init_reg_sets, at reginfo.c:178
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63703 Lawrence Velázquez changed: What|Removed |Added CC||larryv at macports dot org --- Comment #5 from Lawrence Velázquez --- Some MacPorts users are now reporting this. https://trac.macports.org/ticket/45954
[Bug bootstrap/63703] [4.9.2/5 Regression] Bootstrap broken on powerpc-apple-darwin, cc1: internal compiler error: in init_reg_sets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63703 --- Comment #19 from Lawrence Velázquez --- I assume this didn't make it into a 4.8 release?
[Bug bootstrap/63703] [4.9.2/5 Regression] Bootstrap broken on powerpc-apple-darwin, cc1: internal compiler error: in init_reg_sets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63703 --- Comment #20 from Lawrence Velázquez --- (In reply to Lawrence Velázquez from comment #19) > I assume this didn't make it into a 4.8 release? That the bug didn't make it, I mean.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 Lawrence Velázquez changed: What|Removed |Added CC||larryv at macports dot org --- Comment #34 from Lawrence Velázquez --- (In reply to James Clarke from comment #33) > I was able to perform a complete clean bootstrap on my system, so I'm > curious as to what error(s) you got? I’m also seeing a build failure on 10.9.4 13E28 with Xcode 5.1.1 5B1008, with your mailing list patches applied. I'll attach the log in a moment; it was generated by MacPorts during a 64-bit build of our libgcc port. > I agree, the two are not equivalent, but the first one (!defined(X) || X) is > wrong in my opinion, as if the macro is not defined, the documentation for > dir(5) states that the 32-bit versions are used. I got the build to succeed by changing # if defined(_DARWIN_FEATURE_64_BIT_INODE) to # if ! defined(__DARWIN_64_BIT_INO_T) || __DARWIN_64_BIT_INO_T in your second patch.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #35 from Lawrence Velázquez --- Created attachment 33461 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33461&action=edit MacPorts log from a failed attempt to build libgcc @4.9.1_0 (x86_64) There’s a lot of text, I know. To see the environment and commands executed, search for "configure phase started" and "build phase started". As you might expect, the failure is near the end.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #36 from Lawrence Velázquez --- (In reply to Lawrence Velázquez from comment #34) > I got the build to succeed by changing > > # if defined(_DARWIN_FEATURE_64_BIT_INODE) > > to > > # if ! defined(__DARWIN_64_BIT_INO_T) || __DARWIN_64_BIT_INO_T > > in your second patch. Sorry, I might have gotten mixed up about precisely how I altered your patch. I'll do a couple of test builds and report back.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #37 from Lawrence Velázquez --- Okay, what I said initially was correct. This was the specific change I made. https://gist.github.com/larryv/9b1cd34a34733c10f734
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #38 from Lawrence Velázquez --- Created attachment 33464 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33464&action=edit Corrected dirent patch Couple of things: 1) The version of Sanitizer included with GCC 4.9.1 at least, and probably earlier, has the includes in the wrong order in sanitizer_platform_limits_posix.cc: #include "sanitizer_platform.h" #if SANITIZER_LINUX || SANITIZER_MAC #include "sanitizer_internal_defs.h" #include "sanitizer_platform_limits_posix.h" #include #include Since sanitizer_platform_limits_posix.h is included before the system headers, _DARWIN_FEATURE_64_BIT_INODE is *not* defined for the second hunk of your patch, and the 32-bit dirent is always used. However, it *is* defined for the first hunk, so CHECK_SIZE_AND_OFFSET does try to access d_seekoff (and predictably fails). The ordering is fixed in Sanitizer upstream, but it's more robust to directly include sys/cdefs.h in sanitizer_platform_limits_posix.h to avoid relying on include ordering. 2) You should report this bug upstream. http://compiler-rt.llvm.org
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #39 from Lawrence Velázquez --- (In reply to Lawrence Velázquez from comment #38) > 2) You should report this bug upstream. > > http://compiler-rt.llvm.org On second thought, they probably won't accept it because the patch is invalid. sanitizer_mac.cc explicitly defines _DARWIN_USE_64_BIT_INODE, which result in 64-bit dirents on all platforms that AddressSanitizer supports (Snow Leopard and newer). The correct fix is to disable the AddressSanitizer build entirely on platforms that don't support 64-bit inodes (Leopard and older).
