There was a bug introduced at trunk@254573 on (2017-11-09 Pascal Obry <obry@adacore.com>) Specifically, a macro condition was modified improperly, resulting in a broken build on gcc release 8.1 and trunk. The following (obvious) patch needs to be applied to fix it: --- gcc/ada/link.c.orig 2018-05-03 17:24:27 UTC +++ gcc/ada/link.c @@ -104,7 +104,7 @@ unsigned char __gnat_separate_run_path_o const char *__gnat_default_libgcc_subdir = "lib"; #elif defined (__FreeBSD__) || defined (__DragonFly__) \ - || defined (__NetBSD__) || defined (__OpenBSD__) + || defined (__NetBSD__) || defined (__OpenBSD__) \ || defined (__QNX__) const char *__gnat_object_file_option = "-Wl,@"; const char *__gnat_run_path_option = "-Wl,-rpath,";
To be precise, only {Free,Net,Open}BSD, QNX and DragonFly ada is broken.
I would think every condition after (e.g. __APPLE__, __linux__, _AIX) would fail as well. Wouldn't cpp abort on QNX before the __APPLE__ condition is evaluated?
> To be precise, only {Free,Net,Open}BSD, QNX and DragonFly ada is broken. Yes, the subject doesn't make any sense, people build & test Ada regularly...
Author: ebotcazou Date: Fri May 4 07:32:36 2018 New Revision: 259925 URL: https://gcc.gnu.org/viewcvs?rev=259925&root=gcc&view=rev Log: PR ada/85635 * link.c (BSD platforms): Add missing backslash. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/link.c
Author: ebotcazou Date: Fri May 4 07:32:48 2018 New Revision: 259926 URL: https://gcc.gnu.org/viewcvs?rev=259926&root=gcc&view=rev Log: PR ada/85635 * link.c (BSD platforms): Add missing backslash. Modified: branches/gcc-8-branch/gcc/ada/ChangeLog branches/gcc-8-branch/gcc/ada/link.c
Thanks for reporting the problem.
It's a condition ladder. The windows and hpux conditions are first on the ladder. The cpp bug would have been short-circuited on those platforms. For any platform that has the condition test fall to BSD first would be broken. E.g. __APPLE__, __linux__, etc. which come afterwards. All those conditions have to pass the BSD check; they would fail too. The subject should not be confusing once the code is seen. Thanks for fixing it though.
No, for non-BSD the preprocessor sees: #elif defined (__FreeBSD__) || defined (__DragonFly__) \ || defined (__NetBSD__) || defined (__OpenBSD__) and if not one of these 4, it skips all the tokens until the next #elif, so the || defined (__QNX__) tokens are skipped too. Several linux targets are tested daily by many people, if Ada would not bootstrap, it wouldn't go unnoticed.
Those "many" people don't build gnat. Very few people do according to the testsuite results page. link.c code was: #if defined (__WIN32) (block 1) #elif defined (__hpux__) (block 2) #elif defined (__FreeBSD__) || defined (__DragonFly__) \ || defined (__NetBSD__) || defined (__OpenBSD__) || defined (__QNX__) (block 3) #elif defined (__APPLE__) (block 4) #elif defined (__linux__) || defined (__GLIBC__) (block 5) #elif defined (_AIX) (block 6) #elif (HAVE_GNU_LD) (block 7) #elif defined (VMS) (block 8) #elif defined (__sun__) (block 9) #elif defined (__svr4__) && defined (__i386__) (block 10) #else (block 11) #endif I don't see how it would have compiled on linux. The cpp would have chocked on __QNX__ check on the __linux__ platform just as it would for any of the BSDs. It wasn't a BSD-only issue.
ah, i see you explained what technically happened in the comment above. I missed that at first. That's how the QNX line was visibly limited to the BSD platforms then. cpp didn't consider it a macro. got it.
Those many people do build gnat. I do it in all my bootstraps, many other people working on gcc do. And if you don't know how the C preprocessor works in this case, why don't you just try that out? #if defined (A) int a; #elif defined (B) || defined (C) \ || defined (D) || defined (E) || defined (F) int b; #elif defined (G) int c; #else int d; #endif $ gcc -P -E -DA /tmp/j.c int a; $ gcc -P -E -DB /tmp/j.c || defined (F) int b; This preprocesses fine, but is not valid C. $ gcc -P -E -DG /tmp/j.c int c; $ gcc -P -E -DH /tmp/j.c int d;
yeah, my problem is that I was thinking cpp was complaining this whole time, but it was actually the c compiler. Once I realized that, the misconception cleared up. My fault, should've known better. And I should have been building gcc trunk more frequently so it would've been caught before release.
> Those "many" people don't build gnat. Very few people do according to the > testsuite results page. That's a clear misconception. The Ada compiler is regularly built and tested on Linux, Darwin, Solaris and Windows. The story is indeed different for BSDs but they are not representative of the native platforms here.