gcc47 invoked explicitly on FreeBSD ?

[DanPartelly]

Is gcc47 hard coded somewhere in the make files as a C compiler now ? After wmake is built , the compilations stops complaining I don't have gcc47. (I use clang as a system compiler. Anyway, FreeBSD phases out GCC and land the GNU C++ lib starting with 10.0 which will be released in a couple of months.

[jmalak]

Yes, in build/mif/local.mif are appropriate macros which defined compilers for BSD host. I defined gcc 4.7 as minimum for freeBSD 9.1 because c++11 support is necessary. You can defined any other gcc version if you need. It should be also compilable by clang, but it will requre more up-to-date version probably 3.3 or higher, probably small options change will be necessary.

[DanPartelly]

Jiri, why is now C++11 support required? What was modified ? Watcom ought to be a self-compiling compiler, and it's C++ compiler is not even C++2003 feature complete (it misses a lot of things , from name look-up finer points to member templates, and the only thing which is working properly from c11 is static_assert). C support is not C99 complete in Watcom, so if it is to stay self-compiling (which is a good test for the C compiler itself) it shouldn't use any C+11 stuff.

[jmalak]

For porting to 64-bit hosts is necessary to build some C++ applications. For portability I used STL, but it looks like overkill now. Probably porting some OW C++ class will be safer, it will not require C++11 features.

[DanPartelly]

Which tools you modded to require C++11 ?

[jmalak]

dlgprs tool uses STL, but requirements for c++11 was from gcc STL implementation. This utility is compilable by OW without problem.

[DanPartelly]

But if you use STL without using any C+11 only containers or algorithms (unordered_set and unordered map ) any default compiler on the OS should doit. The default C++ STL and compiler are always matched on a system. You dont get for example Gcc 4.2.1 and a STL implementation which requires rvalues and other C++11 only stuff. So if you dont explicitly use C++11 only containers, algorithms or core language constructs, you are safe IMO.

[jmalak]

You are right, but gcc put message about some feature, which required C++11. There is also wipfc source code which require C++11 header files by example. Anyway, OW C++ code will require some review to be better portable.

[pchapin]

Jiri, do you happen to recall what C++11 features gcc was talking about? The Open Watcom library is a bit of a mixture of things and does include a few C++11 items. Perhaps wipfc is using one of those items and thus stimulating gcc to want the C++11 option.

If there were lots of people working on Open Watcom C++ right now I'd love to see it move directly toward C++11 and just skip C++98 (in other words, don't bother supporting both standards separately). However, considering our limited resources that policy might not be best. I'm not sure.

[jmalak]

Petr, yes OW C++ code is a little bit mismatch to any standard. I am not sure if C++11 is suitable for portability. I don't know how much is this standard implemented in current compilers. I was thinking to use STL for better C++ code portability, what do you think about it?

[pchapin]

My understanding is that gcc v4.8 and clang v3.3 implement the C++ 11 language fully (aside from the usual bugs, of course). I'm less sure about the status of their C++ 11 library support but I imagine it is good and getting better at the least. Visual Studio is relatively behind but I'm hoping it will catch up with the next release.

In any case whatever C++ 11 feature the Open Watcom code base is using, it can't be too exotic since Open Watcom supports it! Anyway I don't completely understand what you mean when you say you were thinking of using STL for better portability. The STL is part of C++ 11 also... the new standard just adds some things to it. I guess you mean the C++ 98 version of the STL.

[DanPartelly]

C++11 is not supported on OW at all. The only thing which works is static_assert. STL is part of the C++ standard, so if you want to be portable, do not use any C++ 11 features from STL. Atomic, threads, reg expressions, unordered_set unordered_map for example are out of limits for a pre C++11 STL.

[pchapin]

OW does have support for a few C++ 11 library components such as shared pointers and maybe some other stuff. There isn't much though. That's why I was curious about just what C++ 11 features gcc was complaining about.

[DanPartelly]

Also, I did some of tests of standard conformance on OW C++ , it misses even features for earlier standards, specially on member template support, some features are incomplete (2 phase loookup , Koenig lookup )

[pchapin]

Member templates do work if the body is inline. Some of the OWSTL components use them with that restriction. However, there is no doubt that OW is not 100% C++ 98 conformant.

[DanPartelly]

Thanks Peter. It's a shame Watcom has been abandoned, no release in 3 years, no clear calendar of future releases, no X64 and ARM support (those two rule the world at the moment) and the only development going on it's on sparse forks, like Jiri's excelllent work. One could make a 2.0 release only to streamline the code base and ideally drop the dead weight from it (OS2/DOS16/DOS32 support as both hosts and targets), and add solid support for Linuxes and BSDs. Watcom was the best, very conveniently packing almost all tools one needs for development, but I guess it will slowly die. Save for 3-4 enthusiasts no one cares about it anymore. It's CLANG/ LLVM's time to raise to glory. And maybe Watcom's only chance to survive is to embrace LLVM and use it as it;s back-end. The effort to add ARM and clean X64 support to existing code gens is far greater than making the front ends use LLVM. IMO, In the absence of modern CPU support, there is little reason to advance the front ends(save for pedagogical reasons, I learned a lot about compilers front ends from Watcom ). If the community would pull a switch to LLVM maybe, just maybe, we would get enough interest and man power to bring the front ends up to speed.

[ArmstrongJ]

I just wanted to chime in with some thoughts based on @DanPartelly's comment. While it is a shame that there hasn't been a release in 3 years, I think that the future might be a bit brighter. The shift to GitHub, which makes contributions significantly easier than asking people to install Perforce, and @jmalak's work towards 64-bit support are both very exciting developments. I originally came across Open Watcom because of its legacy support. Being the only supported DOS compiler left is important to more people than is perhaps obvious. Solid support of Windows, of course, kept me here.

Saying that there are very few people left that care about Open Watcom is a bit extreme. It's possibly the only open source C/C++ compiler with true Windows support (GCC's support via MinGW always seems almost like an afterthought). I'm not sure everyone on the project is aware, but Open Watcom is the only open source compiler supported by MATLAB at all on Windows. I've used it extensively in my scientific work under contract with NASA. It has always functioned reliably in that role.

I would never have any objection to changing backends, but keeping the current backends functioning is still important. While I mostly rely on Open Watcom for Windows development, including using the Linux-hosted compiler for building Windows 8 desktop applications, I do occasionally use it to build 8088-compatible programs for some vintage hardware. Have a look at the FreeDOS project, where I think OW remains the official compiler.

We shouldn't get too "down" on the state of Open Watcom. A lot of what's there "just works." I've been happy with the 1.9 release for years, and I'm excited about a possible 2.0 release.

[pchapin]

I'd like to echo that we shouldn't be too quick to abandon old back ends as dead weight. There are communities of DOS and OS/2 users, for example, that look to Open Watcom as one of the few (only?) compilers for their platform that is still being at least somewhat maintained. The one platform that might make sense to ditch is 16 bit Windows. It's hard to imagine anyone writing or maintaining code for that platform any more. Also Open Watcom's support for it gets essentially no testing.

I do agree that an LLVM back end would be a great addition to Open Watcom. It would be a bit of work, of course, to set it up but the advantages are clear. That said, I would advocate for supporting LLVM in addition to the current back ends. Of course talk is cheap. Without people to actually do the work maybe less lofty goals are appropriate.

I also agree with @ArmstrongJ that the move to GitHub is a positive step for Open Watcom. Despite the fact that this is an unofficial fork, I wonder if will become the defacto official one in the future. The greater access, if nothing else, will encourage that.

[jmalak]

I looked a little to LLVM home site and it looks like more POSIX/UNIX centric solution and GCC centric solution until Clang compiler will be available for wide range of platforms. OW is non-POSIX/non-UNIX oriented compiler that compilation of LLVM by OW will be very hard. It will require lot of effort to do port of LLVM to be buildable by OW and next maintain it, because my experience with similar projects is not including any "non-common" compilers into existing build system. By example building LLVM by MS Visual Studio is relatively new and is still experimental. On LLVM site is m inimal info. It could be usefull to use LLVM for some platforms non-common for OW, but it require somebody who know these platforms and is interested in this task. Documentation for porting LLVM is minimal, no much useful info.

[pchapin]

I agree that LLVM is Unix-centric. However, I don't think Open Watcom needs to build LLVM in order to use it (building it would be nice, but it would just be icing on the cake). Open Watcom could emit LLVM assembly language, or even LLVM bitcode files directly, and then the existing LLVM tools could take it from there. Open Watcom developers and users would need LLVM installed also, but that's the same situation as exists for Java developers and users with respect to the JVM.

I do think what you say, Jiri, is largely accurate, however. It's why I would advocate for LLVM being an additional back end option for Open Watcom and not a replacement for the current back ends.

[jmalak]

Petr you are right that we don't need recompile LLVM, but in this case we are limited to existing LLVM ports, only main UNIX platforms. OW is general cross-compiler and for this feature we need to recompile LLVM for all "our" platforms.

[DanPartelly]

LLVM works on Windows. It can be built on Windows with MSVC. In fact in medium term Clang will (already works to some degree ) also work perfectly on Windows, there is a lot work done towards this.

[ArmstrongJ]

While this discussion is interesting, I don't think much effort should be put towards supporting an LLVM backend at this time. From the sounds of it, plenty of work remains on coming up to speed on C and C++ standards (let alone supporting Fortran 90 or higher). Furthermore, one of OpenWatcom's big draws is the assortment of existing targets/backends. Complicating matters with LLVM support with limited developers as it is would be counter-productive. I suppose LLVM backend support would be "nice to have," but it's not something I'd be particularly excited to see in Open Watcom. This is simply my opinion, of course. I've always been pretty happy with the way things have progressed in Open Watcom.

[DanPartelly]

Watcom is my all time favorite compiler suite, but what is IMO a requirement nowadays for a C/C++ compiler is X64 and ARM 7/8 support. With an LLVM backend , you get those for basically for free. LLVM advances at very decent speeds, and has a very wide developer base. Intel, AMD, Apple and others contribute work to it. As far as I know, google supports strongly a Clang / LLVM on Windows. Just yesterday, Intel release an OpenMP runtime for LLVM, to gap de bridge to gcc in this area. Meanwhile, opposed sits Watcom, which has Jiri alone (and let me thank you for all your work Jiri)

There is no much sense to update the C/C++ compilers to support to latest standards IMO if all you get is back-end support for 386. 32bit Intel is dieying slowly. The world moved to 64 bit on Intel. Couple of years from now, ARM will also be 64 almost everywhere.

IMO, "nice to have" are compiler features. The support for up to date architectures is much more important. Anyway some front end features are trivial to implement. Support for hex floats in the C compiler took me 2 hours. Others are more complex but doable for the C compiler. Some are downright hairy. The C++ frontend is much more complex and adding support for most features requires a lot of digging into it. In the same time I understood a lot about Cfe, I understood almost nothing useful about the C++ fe. I would love the C compiler to become a world class compiler supporting C11, C is ATM more important for me than C++, but in my vision this requires X64 and ARM support.

[jmalak]

Now default compiler for BSD is Clang. You can switch to gcc, but it requires gcc version 4.7 or above (now version is not hardcoded). Tool chain configuration is done by OWTOOLS environment variable in your copy of setvars.sh script.

[ytrezq]

@DanPartelly : I would add that support for old platforms isn’t only something for legacy hardware and software.

With the embedded market there is resurgence in old instructions sets from the 80’s. This is true for the x86 instruction set where many FPGA codes feature compatibility below the 80386.

This is also not something for guys who ant to have fun. I have a commercial device manufactured last year featuring a NEC SOC which provide compatibility with the 80286 and it is using ROM-DOS from datalight : a specialized version of DOS targeting embedded systems.

OS/2 is more developed than openwatcom if you look at eComStation which got the original OS/2 source code from IBM. And peoples which use eComStation can run WIN16 programs natively but not WIN32. If Open Watcom drop this. It will mean such plateform will definitely never get C99/c++11 support.