bitwiseworks / gcc-os2 Goto Github PK

Port of GCC compiler to OS/2

License: GNU General Public License v2.0

Emacs Lisp 0.01% Makefile 1.13% Shell 0.32% M4 0.59% Python 0.16% Perl 0.05% C 54.38% C++ 17.66% Awk 0.06% HTML 0.90% Vim Script 0.01% Smarty 0.01% Logos 0.16% Objective-C 0.59% Ada 19.27% TeX 0.13% GCC Machine Description 4.59% OCaml 0.01% Standard ML 0.01% Lex 0.01%

gcc-os2's Introduction

GCC for OS/2

This repository contains the GCC source code with patches needed to build it on the OS/2 operating system. One day all patches will be merged upstream but currently it is more convenient for the OS/2 developers to track them separately.

Note that this repository is a successor of the previous repository located at https://github.com/psmedley/gcc which is not maintained any more. All patches from that repository have been applied here preserving their original authors when possible.

Installation

The easiest and the only officially supported way to install GCC for OS/2 is to use binary builds provided by bitwiseworks. This requires the RPM/YUM environment for OS/2 to be installed. Note that all recent distributions of ArcaOS already have it, so nothing needs to be done if you have one of these. Then simply type the following on the command line prompt to install GCC (together with WLINK used for linking object files generated by GCC into OS/2 executables):

yum install gcc gcc-wlink gcc-wrc

If you also need to install the C++ part of GCC, type the following:

yum install gcc-c++

Help and Support

You will find a lot of useful information about GCC for OS/2 on the Wiki pages of the project's GitHub repository. There you may also watch the progress of our work on this port. Please read these pages carefully if you need any help or want to report a problem.

Build Instructions

Please refer to build instructions on GitHub.

Credits

We thank Knut St. Osmundsen for maintaining the OS/2 port of GCC version 3 which was used as a base for this port. We also thank Paul Smedley for his continued OS/2 contribution to GCC 4 and further versions over these years.

bww bitwiseworks GmbH
January, 2020

gcc-os2's People

Contributors

Stargazers

Watchers

Forkers

aventer-ug psmedley

gcc-os2's Issues

Fix BLDLEVEL for gcc1.dll

The new release of RPMs for GCC version 9 from #6 contains DLLs with a nice BLDLEVEL string thanks to this libtool fix: bitwiseworks/libtool-os2@6084903. However, gcc1.dll isn't built using Libtool and hence it didn't get a proper BLDLEVEL string but instead just a textual description. In order to do so, we need to fix its makefiles (to use the LT_BUILDLEVEL environment variable manually).

The place where it is set now is this:

gcc-os2/libgcc/config/i386/t-emx

Line 16 in ee72211

-v pe_def="GNU GCC Runtime Version $(gcc_version)-$(RPM_PACKAGE_RELEASE)"

Note that Yuri unconditionally refers to RPM_PACKAGE_RELEASE there which is only defined under rpmbuild. This produces weird description in non-rpmbiuld development builds and should have been done conditionally. At least this is how we will make LT_BUILDLEVEL used here.

Note that the presence of RPM_PACKAGE_VENDOR, RPM_PACKAGE_VERSION and RPM_PACKAGE_RELEASE environment variables with the respective values under rpmbuild could let us avoid introducing LT_BUILDLEVEL (see bitwiseworks/libtool-os2#1) at all. But still, this would require to patch Makefile.am for each and every DLL we build in order to incorporate conditional RPM_PACKAGE_* usage on OS/2 there which is much more work than just define LT_BUILDLEVEL once in a .spec file (and not touch Makefile.am at all).

Suport ELF as object format

Currently, GCC for OS/2 compiles sources into a.out object files. Which are then converted to OMF with emxomf.exe and linked to an OS/2 LX executable (EXE or DLL) using wlink from OpenWatcom or ilink from IBM VisualAge C (not actually suitable for modern C++ and therefore not supported by us, mainly because it's very dead).

Such a pipeline has many drawbacks. First, it's very slow as includes a separate step of converting A.OUT to OMF. Second, A.OUT is very old and is not suitable for some applications per se. See #11 for one example. Third, there are lots of limitations on the debug information in both A.OUT and OMF (both are very old).

We need to find a way to link ELF objects to LX executables. Then we will be able to configure GCC so that it will generate ELF on OS/2 and we are done. There are rumors that wlink already supports linking ELF to LX. This needs checking.

namespace

Hi
When compiling fluidsynth i get this errors:
C:/usr/lib/gcc/i686-pc-os2-emx/9/include-fixed/stdlib.h:107:19: error: expected initializer before '__dead2'
107 | void abort(void) __dead2;
| ^~~~~~~
C:/usr/lib/gcc/i686-pc-os2-emx/9/include-fixed/stdlib.h:108:15: error: expected initializer before '__pure2'
108 | int abs(int) __pure2;

and:

C:/usr/include/c++/9/cstdlib:130:11: error: '::abort' has not been declared
130 | using ::abort;
| ^~~~~
C:/usr/include/c++/9/cstdlib:145:11: error: '::div' has not been declared
145 | using ::div;
| ^~~
C:/usr/include/c++/9/cstdlib:146:11: error: '::exit' has not been declared
146 | using ::exit;

I ask Ko about this and he tell me:

namespace problem, c++ headers expect those functions to be in global namespace

wregex support missing?

I get errors: "wregex is not a member of std", "regexp not declared", etc.

I compile with latest gcc 9.2.xx from experimental repository. I have C++17 standard enabled by appropriate switch.

Specifically compilling https://github.com/martinrotter/textosaurus with these steps:

cd C:\usr\bin
cp lupdate-qt5.exe lupdate.exe
cp lrelease-qt5.exe lrelease.exe
cd C:
git clone https://github.com/martinrotter/textosaurus
git submodule update --init --remote
mkdir build
cd build
qmake-qt5 ../ -r
make

Out of memory of cc1plus.exe

Hi/2.

I'm trying to build VLC with gcc 9.2.0. However, compilation fails due to out of memory.

make[4]: Entering directory 'F:/lang/work/vlc/vlc.git/modules'
  CXX      gui/qt/dialogs/libqt_plugin_la-dialogs_provider.lo

cc1plus.exe: out of memory allocating 65536 bytes after a total of 284622848 bytes
make[4]: *** [Makefile:31764: gui/qt/dialogs/libqt_plugin_la-dialogs_provider.lo] Error 1

Any ideas ?

Conflicts between libc includes and GCC 9.2.0 fixed_includes

Attempting to compile Firefox 45ESR with the latest GCC 9.2, I've come to the following build break.

make[3]: Entering directory `Y:/work/cc45-git/mozilla/obj-fb/ipc/chromium'
c++ -o string_util_os2.obj -c -IY:/work/cc45-git/mozilla/obj-fb/dist/stl_wrappers  -DHAVE_CONFIG_H -DOS_POSIX=1 -DOS_OS2=1 -DSTATIC_EXPORTABLE_JS_API -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -IY:/work/cc45-git/mozilla/ipc/chromium -I. -IY:/work/cc45-git/mozilla/ipc/chromium/src/third_party/libevent -IY:/work/cc45-git/mozilla/ipc/chromium/src/third_party/libevent/include -IY:/work/cc45-git/mozilla/ipc/chromium/src/third_party/libevent/os2 -IY:/work/cc45-git/mozilla/ipc/chromium/src/third_party/libevent/os2 -I../../ipc/ipdl/_ipdlheaders -IY:/work/cc45-git/mozilla/ipc/chromium/src -IY:/work/cc45-git/mozilla/ipc/glue -I../../dist/include  -I/@unixroot/usr/include/nspr4 -I/@unixroot/usr/include/nss3    -I/@unixroot/usr/include/pixman-1     -DMOZILLA_CLIENT -include ../../mozilla-config.h -Uunix -U__unix -U__unix__ -MD -MP -MF .deps/string_util_os2.obj.pp -idirafter K:/usr/include/os2tk45 -Wall -Wempty-body -Woverloaded-virtual -Wsign-compare -Wwrite-strings -Wno-invalid-offsetof -Wcast-align -Zomf -fno-exceptions -fno-strict-aliasing -Zomf -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x -pthread  -DNDEBUG -DTRIMMED -g -march=i686 -O2 -fomit-frame-pointer     Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc
In file included from ../../dist/include/mozilla/throw_gcc.h:13,
                 from Y:/work/cc45-git/mozilla/obj-fb/dist/stl_wrappers/cstdlib:76,
                 from O:/usr/include/c++/9/stdlib.h:36,
                 from O:/usr/include/sys/fmutex.h:11,
                 from Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc:55:
O:/usr/lib/gcc/i686-pc-os2-emx/9/include-fixed/stdio.h:218:9: error: '_fmutex' does not name a type
  218 |         _fmutex   __fsem;
      |         ^~~~~~~
In file included from Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc:66:
O:/usr/include/emx/io.h: In function 'int stream_lock(__sFILE*)':
O:/usr/include/emx/io.h:246:43: error: 'union __sFILE::<unnamed>' has no member named '__fsem'
  246 |         || !_fmutex_is_owner(&stream->__u.__fsem))
      |                                           ^~~~~~
O:/usr/include/emx/io.h:248:42: error: 'union __sFILE::<unnamed>' has no member named '__fsem'
  248 |         if (_fmutex_request(&stream->__u.__fsem, _FMR_IGNINT) != 0)
      |                                          ^~~~~~
O:/usr/include/emx/io.h: In function 'int stream_trylock(__sFILE*)':
O:/usr/include/emx/io.h:265:43: error: 'union __sFILE::<unnamed>' has no member named '__fsem'
  265 |         || !_fmutex_is_owner(&stream->__u.__fsem))
      |                                           ^~~~~~
O:/usr/include/emx/io.h:267:42: error: 'union __sFILE::<unnamed>' has no member named '__fsem'
  267 |         if (_fmutex_request(&stream->__u.__fsem, _FMR_NOWAIT) != 0)
      |                                          ^~~~~~
O:/usr/include/emx/io.h: In function 'int stream_unlock(__sFILE*)':
O:/usr/include/emx/io.h:297:41: error: 'union __sFILE::<unnamed>' has no member named '__fsem'
  297 |         && _fmutex_release(&stream->__u.__fsem) != 0)
      |                                         ^~~~~~
In file included from Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc:68:
O:/usr/include/InnoTekLIBC/locale.h: At global scope:
O:/usr/include/InnoTekLIBC/locale.h:130:16: error: redefinition of 'struct __libc_localeWCType'
  130 | typedef struct __libc_localeWCType
      |                ^~~~~~~~~~~~~~~~~~~
In file included from O:/usr/lib/gcc/i686-pc-os2-emx/9/include-fixed/wchar.h:87,
                 from ../../dist/include/mozilla/TypeTraits.h:20,
                 from ../../dist/include/mozilla/TemplateLib.h:23,
                 from ../../dist/include/mozilla/mozalloc.h:23,
                 from Y:/work/cc45-git/mozilla/obj-fb/dist/stl_wrappers/cmath:62,
                 from O:/usr/include/c++/9/math.h:36,
                 from Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc:62:
O:/usr/include/_ctype.h:65:21: note: previous definition of 'struct __libc_localeWCType'
   65 | extern const struct __libc_localeWCType
      |                     ^~~~~~~~~~~~~~~~~~~
In file included from Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc:68:
O:/usr/include/InnoTekLIBC/locale.h:242:37: error: conflicting declaration '__LIBC_LOCALECTYPE __libc_GLocaleCtype'
  242 | extern __LIBC_LOCALECTYPE           __libc_GLocaleCtype;
      |                                     ^~~~~~~~~~~~~~~~~~~
In file included from O:/usr/lib/gcc/i686-pc-os2-emx/9/include-fixed/wchar.h:87,
                 from ../../dist/include/mozilla/TypeTraits.h:20,
                 from ../../dist/include/mozilla/TemplateLib.h:23,
                 from ../../dist/include/mozilla/mozalloc.h:23,
                 from Y:/work/cc45-git/mozilla/obj-fb/dist/stl_wrappers/cmath:62,
                 from O:/usr/include/c++/9/math.h:36,
                 from Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc:62:
O:/usr/include/_ctype.h:46:3: note: previous declaration as '<unnamed struct> __libc_GLocaleCtype'
   46 | } __libc_GLocaleCtype;
      |   ^~~~~~~~~~~~~~~~~~~
In file included from Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc:68:
O:/usr/include/InnoTekLIBC/locale.h:244:37: error: conflicting declaration 'const __LIBC_LOCALECTYPE __libc_GLocaleCtypeDefault'
  244 | extern const __LIBC_LOCALECTYPE     __libc_GLocaleCtypeDefault;
      |                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from O:/usr/lib/gcc/i686-pc-os2-emx/9/include-fixed/wchar.h:87,
                 from ../../dist/include/mozilla/TypeTraits.h:20,
                 from ../../dist/include/mozilla/TemplateLib.h:23,
                 from ../../dist/include/mozilla/mozalloc.h:23,
                 from Y:/work/cc45-git/mozilla/obj-fb/dist/stl_wrappers/cmath:62,
                 from O:/usr/include/c++/9/math.h:36,
                 from Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc:62:
O:/usr/include/_ctype.h:59:3: note: previous declaration as 'const<unnamed struct> __libc_GLocaleCtypeDefault'
   59 | } __libc_GLocaleCtypeDefault;
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc:68:
O:/usr/include/InnoTekLIBC/locale.h:246:37: error: conflicting declaration '__LIBC_LOCALEWCTYPE __libc_GLocaleWCtype'
  246 | extern __LIBC_LOCALEWCTYPE          __libc_GLocaleWCtype;
      |                                     ^~~~~~~~~~~~~~~~~~~~
In file included from O:/usr/lib/gcc/i686-pc-os2-emx/9/include-fixed/wchar.h:87,
                 from ../../dist/include/mozilla/TypeTraits.h:20,
                 from ../../dist/include/mozilla/TemplateLib.h:23,
                 from ../../dist/include/mozilla/mozalloc.h:23,
                 from Y:/work/cc45-git/mozilla/obj-fb/dist/stl_wrappers/cmath:62,
                 from O:/usr/include/c++/9/math.h:36,
                 from Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc:62:
O:/usr/include/_ctype.h:77:3: note: previous declaration as 'const __libc_localeWCType __libc_GLocaleWCtype'
   77 | } __libc_GLocaleWCtype;
      |   ^~~~~~~~~~~~~~~~~~~~
Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc: In function 'int out_pad(olocal*, wchar_t, int)':
Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc:288:9: warning: comparison of integer expressions of different signedness: 'int' and 'unsigned int' [-Wsign-compare]
  288 |   if (n > SIZEOF_ARRAY (buf))
      |         ^
Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc: In function 'int _output_wchar(FILE*, const wchar_t*, char*)':
Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc:990:7: warning: unused variable 'mbn' [-Wunused-variable]
  990 |   int mbn, shift;
      |       ^~~
Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc: In function 'int vswprintf(wchar_t*, size_t, const wchar_t*, va_list)':
Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc:1335:28: error: 'union __sFILE::<unnamed>' has no member named '__fsem'
 1335 |   _fmutex_dummy(&trick.__u.__fsem);
      |                            ^~~~~~
make[3]: *** [string_util_os2.obj] Error 1
make[3]: Leaving directory `Y:/work/cc45-git/mozilla/obj-fb/ipc/chromium'
make[2]: *** [ipc/chromium/target] Error 2

Build RPMs for version 9

We need a new set of GCC RPMs. They will be independent of the gcc4 set because a lot has been changed and we're taking a fresh Fedora .spec for GCC 9.

Make -fstack-protector work w/o passing it in LDFLAGS

if -fstack-protection is used while compiling I guess -lssp should automatically be added to the LDFLAGS. IIRC it was the case with gcc4.

Cross compile on Linux/Unix

How can I build an emx toolchain for OS/2 on Linux or some Unix variants?

Decide which GCC version to port

Our current port (i.e. the one maintaned by bww) is 4.9.2. This is a very old version (back from 2014). More and more projects refuse to build with that due to newer C++ features they need. One example is Chromium (see bitwiseworks/qtwebengine-os2#3). The other one is poppler.

The 4.9.2 source code with our OS/2 patches lives here: https://github.com/psmedley/gcc/tree/gcc-4_9-branch-os2. That repository has a number of problems:

It's a fork so it contains quite a huge upstream development history which we don't need. It only bloats the respository size and distracts attention from OS/2-specific tasks.
It's not controlled by bww so may disappear at any moment (which will break our development and deployment environment).

For this reason, we need a new repository. And given 1. above, we will use the same upstream source import technique we used for our port of Qt to OS/2. It's described well here: https://github.com/bitwiseworks/qt5-os2/wiki/Developers.

We also need to decide which version to go. There are two candidates: 8.x and 9.x (check https://www.gnu.org/software/gcc/develop.html for the official development plan). 8.x is a bit more stable as it's a bit older. And 9.x is the latest stable release which will most likely get important updates soon. Also, 8.x has been already successfully built on OS/2 by Paul Smedley (https://os2ports.smedley.id.au/index.php?page=gcc-v8.x) so chances are higher that we won't experience any major problems when porting it rather than with 9.x. However, there is also a chance that if we go for 8.x now then we might end up porting some things twice when later moving to 9.x which I'd like to avoid. Some more investigation is needed.

libstdc++ DLL binary incompatibility

While working on #6, I discovered the following. Given that we use our standard toolchain for our GCC 9.x build, the C++ DLL is now called stdc++6.dll — just like on all other platforms. However, we provide it as stdcpp6.dll in the current set of 4.x RPMs (it was @ydario's decision — perhaps because + chars are something special that sometimes needs to be quoted). And this DLL is used by all C++ apps recently built using our RPM tool chain. So we need a forwarder for it.

Creating forwarders is easy per se but we've got a problem with missing symbols. The following ones from stdcpp6.dll (which is GCC 4.9.2) are missing from the new GCC 9.x DLL:

__ZN11__gnu_debug17_S_debug_messagesE
__ZNKSt11__use_cacheISt18__moneypunct_cacheIcLb0EEEclERKSt6locale
__ZNKSt11__use_cacheISt18__moneypunct_cacheIcLb1EEEclERKSt6locale
__ZNKSt19istreambuf_iteratorIcSt11char_traitsIcEE6_M_getEv
__ZNKSt5ctypeIcE2isEjc
__ZNSt12__basic_fileIcEC1EP7_fmutex
__ZNSt12__basic_fileIcEC2EP7_fmutex

Feeding it to c++filt gives this:

__gnu_debug::_S_debug_messages
std::__use_cache<std::__moneypunct_cache<char, false> >::operator()(std::locale const&) const
std::__use_cache<std::__moneypunct_cache<char, true> >::operator()(std::locale const&) const
std::istreambuf_iterator<char, std::char_traits<char> >::_M_get() const
std::ctype<char>::is(unsigned int, char) const
std::__basic_file<char>::__basic_file(_fmutex*)
std::__basic_file<char>::__basic_file(_fmutex*)

Re __gnu_debug::_S_debug_messages, I have to figure that out. The rest looks related to these changes by @komh: 203e99b (native C++11 thread support) and 2eafb76 (native C++ locale support). I will try to look on how we can still provide these symbols in the forwarder but that will definitely take some time. If we fail to do so, we will have to use our legacy RPM machinery and provide a binary build of stdcpp6.dll from 4.9.2 RPMs instead of a forwarder. I don't like this solution very much because it will double memory usage occupied by C++ classes when two apps using different DLLs are up and running.

More over, there is another problem. Even before stdcpp6.dll it was named just stdcpp.dll. This was for GCC RPMs for version 4.4.6. And there are still some apps built with GCC 4.4.6 and therefore using this DLL. Creating a forwarder for it is even harder as there are much more missing symbols. Currently, I don't know why as ABI should still be the same (see here) — perhaps the reason is that Yuri built these DLLs manually instead of letting the GCC makefie system do it. And that's not the only problem. The other one is that the package providing it is named libstdc++ (as opposed to libstdc++6 which provides stdcpp6.dll in 4.9.2 RPMs). And libstdc++ is the canonical name of the package. Our new 9.x RPMs (as well as all other platforms) have it like that. This means that it won't be possible to have both libstdc++ packages (4.4.2 one and 9.x one) to be installed at the same time. I will also try to create a forwarder (which means resolve all missing symbols) and then decide. If I fail, we will use the legacy RPM machinery as well here.

Anyway, it will take a few days to sort that out.

GCC 9.2.0 fails to link xul.dll

After trials and tribulations, I've got as far as linking xul.dll using the latest netlabs.exp stuff.
Linking fails pretty quick with this error,

92:34.46 emxomfld: _abspath failed on '@K:\var\temp/cc0sIIGI.'!!!
92:34.46 make.EXE[5]: *** [xul.dll] Error 1

Running make with a 4.9.2 GCC environment in $OBJDIR/toolkit/library works as well as expected, eventually dying due to unresolved symbols as expected as we're using different libgcc and stdc++.
To me it appears a failure of GCC writing the correct response file before calling emxomfld
While linking with 4.9.2, I find in $TMPDIR grsp0001.tmp containing the expected command line broken up on a per line basis.

Fix compiler warnings in EMX code

It's a continuation of #2 to some extent. There are lots of warnings in the EMX code. Some may be potentially dangerous and lead to bugs which are then quite hard to find. So it's better to fix them now. And document those we can't/won't fix (if any).

add "mapsym.cmd" to the gcc distribution

In order for the -Zsym switch to actually work, gcc is invoking the script "mapsym.cmd". However, that script is not part of the gcc distribution.
Obviously, that script was part of Odin, see also here:

http://trac.netlabs.org/libc/ticket/47

That ticket also has "mapsym.cmd" as an attachment, so it could be taken from there. I can confirm that that script still works.

Sort out alignof for 64 bit types

Currently, the following test program

#include <stdio.h>

int main ()
{
  printf ("%d %d\n", sizeof(unsigned long long), alignof(unsigned long long));
  return 0;
}

yields the following output

8 4

I.e. alignment of a 64 bit integer is 4 bytes. This freaks out e.g. a Qt5 QtBase test (tst_QGlobal::qAlignOf()) which expects alignment for it to be 8 bytes as well. Same story for double.

I wonder what our GCC should really return in such a case given that 32-bit Linux and Windows compilers return 8 (at least, according to the Qt test case).

Found when doing bitwiseworks/qt5-os2#16.

Conflicts between libc includes and GCC fixed_includes

Attempting to compile Firefox 45ESR with the latest GCC 9.2, I've come to the following build break.

make[3]: Entering directory `Y:/work/cc45-git/mozilla/obj-fb/ipc/chromium'
c++ -o string_util_os2.obj -c -IY:/work/cc45-git/mozilla/obj-fb/dist/stl_wrappers  -DHAVE_CONFIG_H -DOS_POSIX=1 -DOS_OS2=1 -DSTATIC_EXPORTABLE_JS_API -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -IY:/work/cc45-git/mozilla/ipc/chromium -I. -IY:/work/cc45-git/mozilla/ipc/chromium/src/third_party/libevent -IY:/work/cc45-git/mozilla/ipc/chromium/src/third_party/libevent/include -IY:/work/cc45-git/mozilla/ipc/chromium/src/third_party/libevent/os2 -IY:/work/cc45-git/mozilla/ipc/chromium/src/third_party/libevent/os2 -I../../ipc/ipdl/_ipdlheaders -IY:/work/cc45-git/mozilla/ipc/chromium/src -IY:/work/cc45-git/mozilla/ipc/glue -I../../dist/include  -I/@unixroot/usr/include/nspr4 -I/@unixroot/usr/include/nss3    -I/@unixroot/usr/include/pixman-1     -DMOZILLA_CLIENT -include ../../mozilla-config.h -Uunix -U__unix -U__unix__ -MD -MP -MF .deps/string_util_os2.obj.pp -idirafter K:/usr/include/os2tk45 -Wall -Wempty-body -Woverloaded-virtual -Wsign-compare -Wwrite-strings -Wno-invalid-offsetof -Wcast-align -Zomf -fno-exceptions -fno-strict-aliasing -Zomf -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x -pthread  -DNDEBUG -DTRIMMED -g -march=i686 -O2 -fomit-frame-pointer     Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc
In file included from ../../dist/include/mozilla/throw_gcc.h:13,
                 from Y:/work/cc45-git/mozilla/obj-fb/dist/stl_wrappers/cstdlib:76,
                 from O:/usr/include/c++/9/stdlib.h:36,
                 from O:/usr/include/sys/fmutex.h:11,
                 from Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc:55:
O:/usr/lib/gcc/i686-pc-os2-emx/9/include-fixed/stdio.h:218:9: error: '_fmutex' does not name a type
  218 |         _fmutex   __fsem;
      |         ^~~~~~~
In file included from Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc:66:
O:/usr/include/emx/io.h: In function 'int stream_lock(__sFILE*)':
O:/usr/include/emx/io.h:246:43: error: 'union __sFILE::<unnamed>' has no member named '__fsem'
  246 |         || !_fmutex_is_owner(&stream->__u.__fsem))
      |                                           ^~~~~~
O:/usr/include/emx/io.h:248:42: error: 'union __sFILE::<unnamed>' has no member named '__fsem'
  248 |         if (_fmutex_request(&stream->__u.__fsem, _FMR_IGNINT) != 0)
      |                                          ^~~~~~
O:/usr/include/emx/io.h: In function 'int stream_trylock(__sFILE*)':
O:/usr/include/emx/io.h:265:43: error: 'union __sFILE::<unnamed>' has no member named '__fsem'
  265 |         || !_fmutex_is_owner(&stream->__u.__fsem))
      |                                           ^~~~~~
O:/usr/include/emx/io.h:267:42: error: 'union __sFILE::<unnamed>' has no member named '__fsem'
  267 |         if (_fmutex_request(&stream->__u.__fsem, _FMR_NOWAIT) != 0)
      |                                          ^~~~~~
O:/usr/include/emx/io.h: In function 'int stream_unlock(__sFILE*)':
O:/usr/include/emx/io.h:297:41: error: 'union __sFILE::<unnamed>' has no member named '__fsem'
  297 |         && _fmutex_release(&stream->__u.__fsem) != 0)
      |                                         ^~~~~~
In file included from Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc:68:
O:/usr/include/InnoTekLIBC/locale.h: At global scope:
O:/usr/include/InnoTekLIBC/locale.h:130:16: error: redefinition of 'struct __libc_localeWCType'
  130 | typedef struct __libc_localeWCType
      |                ^~~~~~~~~~~~~~~~~~~
In file included from O:/usr/lib/gcc/i686-pc-os2-emx/9/include-fixed/wchar.h:87,
                 from ../../dist/include/mozilla/TypeTraits.h:20,
                 from ../../dist/include/mozilla/TemplateLib.h:23,
                 from ../../dist/include/mozilla/mozalloc.h:23,
                 from Y:/work/cc45-git/mozilla/obj-fb/dist/stl_wrappers/cmath:62,
                 from O:/usr/include/c++/9/math.h:36,
                 from Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc:62:
O:/usr/include/_ctype.h:65:21: note: previous definition of 'struct __libc_localeWCType'
   65 | extern const struct __libc_localeWCType
      |                     ^~~~~~~~~~~~~~~~~~~
In file included from Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc:68:
O:/usr/include/InnoTekLIBC/locale.h:242:37: error: conflicting declaration '__LIBC_LOCALECTYPE __libc_GLocaleCtype'
  242 | extern __LIBC_LOCALECTYPE           __libc_GLocaleCtype;
      |                                     ^~~~~~~~~~~~~~~~~~~
In file included from O:/usr/lib/gcc/i686-pc-os2-emx/9/include-fixed/wchar.h:87,
                 from ../../dist/include/mozilla/TypeTraits.h:20,
                 from ../../dist/include/mozilla/TemplateLib.h:23,
                 from ../../dist/include/mozilla/mozalloc.h:23,
                 from Y:/work/cc45-git/mozilla/obj-fb/dist/stl_wrappers/cmath:62,
                 from O:/usr/include/c++/9/math.h:36,
                 from Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc:62:
O:/usr/include/_ctype.h:46:3: note: previous declaration as '<unnamed struct> __libc_GLocaleCtype'
   46 | } __libc_GLocaleCtype;
      |   ^~~~~~~~~~~~~~~~~~~
In file included from Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc:68:
O:/usr/include/InnoTekLIBC/locale.h:244:37: error: conflicting declaration 'const __LIBC_LOCALECTYPE __libc_GLocaleCtypeDefault'
  244 | extern const __LIBC_LOCALECTYPE     __libc_GLocaleCtypeDefault;
      |                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from O:/usr/lib/gcc/i686-pc-os2-emx/9/include-fixed/wchar.h:87,
                 from ../../dist/include/mozilla/TypeTraits.h:20,
                 from ../../dist/include/mozilla/TemplateLib.h:23,
                 from ../../dist/include/mozilla/mozalloc.h:23,
                 from Y:/work/cc45-git/mozilla/obj-fb/dist/stl_wrappers/cmath:62,
                 from O:/usr/include/c++/9/math.h:36,
                 from Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc:62:
O:/usr/include/_ctype.h:59:3: note: previous declaration as 'const<unnamed struct> __libc_GLocaleCtypeDefault'
   59 | } __libc_GLocaleCtypeDefault;
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc:68:
O:/usr/include/InnoTekLIBC/locale.h:246:37: error: conflicting declaration '__LIBC_LOCALEWCTYPE __libc_GLocaleWCtype'
  246 | extern __LIBC_LOCALEWCTYPE          __libc_GLocaleWCtype;
      |                                     ^~~~~~~~~~~~~~~~~~~~
In file included from O:/usr/lib/gcc/i686-pc-os2-emx/9/include-fixed/wchar.h:87,
                 from ../../dist/include/mozilla/TypeTraits.h:20,
                 from ../../dist/include/mozilla/TemplateLib.h:23,
                 from ../../dist/include/mozilla/mozalloc.h:23,
                 from Y:/work/cc45-git/mozilla/obj-fb/dist/stl_wrappers/cmath:62,
                 from O:/usr/include/c++/9/math.h:36,
                 from Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc:62:
O:/usr/include/_ctype.h:77:3: note: previous declaration as 'const __libc_localeWCType __libc_GLocaleWCtype'
   77 | } __libc_GLocaleWCtype;
      |   ^~~~~~~~~~~~~~~~~~~~
Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc: In function 'int out_pad(olocal*, wchar_t, int)':
Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc:288:9: warning: comparison of integer expressions of different signedness: 'int' and 'unsigned int' [-Wsign-compare]
  288 |   if (n > SIZEOF_ARRAY (buf))
      |         ^
Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc: In function 'int _output_wchar(FILE*, const wchar_t*, char*)':
Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc:990:7: warning: unused variable 'mbn' [-Wunused-variable]
  990 |   int mbn, shift;
      |       ^~~
Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc: In function 'int vswprintf(wchar_t*, size_t, const wchar_t*, va_list)':
Y:/work/cc45-git/mozilla/ipc/chromium/src/base/string_util_os2.cc:1335:28: error: 'union __sFILE::<unnamed>' has no member named '__fsem'
 1335 |   _fmutex_dummy(&trick.__u.__fsem);
      |                            ^~~~~~
make[3]: *** [string_util_os2.obj] Error 1
make[3]: Leaving directory `Y:/work/cc45-git/mozilla/obj-fb/ipc/chromium'
make[2]: *** [ipc/chromium/target] Error 2

Crash when using 9.2.0 forwarder DLL

This has become a blocker for the ArcaOS 5.0.5 release.

The testcase involves Paul's MediaTomb 0.12.0 port, which relies on gcc442.dll. Attempting to start mediatomb.exe after the gcc 9.2.0 forwarders have been installed (libgcc-fwd-9.2.0) results in:

MediaTomb UPnP Server version 0.12.0 - http://mediatomb.cc/

===============================================================================
Copyright 2005-2008 Gena Batsyan, Sergey Bostandzhyan, Leonhard Wimmer.
MediaTomb is free software, covered by the GNU General Public License version 2

2020-05-06 16:54:43    INFO: Loading configuration from: /mediatomb/home/.mediatomb/config.xml
2020-05-06 16:54:43    INFO: Checking configuration...
terminate called after throwing an instance of 'zmm::Exception'
terminate called recursively

Killed by SIGABRT
pid=0x0043 ppid=0x0040 tid=0x0001 slot=0x0019 pri=0x0200 mc=0x0001 ps=0x0010
F:\MEDIATOMB\BIN\MEDIATOMB.EXE
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.

Backleveling to libgcc-fwd-4.9.2.1 allows the program to start.

Make sure special wchar_t support is enabled

From psmedley/gcc#30:

IIRC this is disabled by configure now because kLIBC doesn't implement all necessary wide character functions (so the respective configure test fails).

When enabled, gcc defines _GLIBCXX_USE_WCHAR_T which enables special code for wide characters. This code includes e.g. a std::is_integral<wchar_t> specialization returning true instead of false and a lot of other things.

The problem was found while working on the QTypeInfo<wchar_t> specialization for Qt 5 within bitwiseworks/qtbase-os2#29.

Note that we may force such support with --enable-wchar_t but a test build needs to be done to check if it will work with our kLIBC.

Investigate why alignas(8) doesn't always work

As Chromium tests show (see bitwiseworks/qtwebengine-chromium-os2#20 (comment)), alignas(8) is not always respected by GCC when allocating variables on the stack. Most of the time it works (i.e. variables get stack addresses ending with either 0x0 or 0x8) but occasionally something breaks and variables end up at "odd" addresses ending with 0x4 or 0xC. The Mojo component in Chromium is pretty strict about that and crashes the application on alignment mismatch.

Cmake crash

All 9.2.0 builds of STDCPP6.DLL cause cmake --version to crash like this:

D:>cmake --version
cmake version 3.10.3

CMake suite maintained and supported by Kitware (kitware.com/cmake).
Assertion failed: h->magic == _UM_MAGIC_HEAP, file D:/Users/dmik/rpmbuild/BUILD/libc-0.1.3/src/emx/src/lib/malloc/umalloc.c, line 19

Killed by SIGABRT
pid=0x4e2d ppid=0x4dc8 tid=0x0001 slot=0x0090 pri=0x0200 mc=0x0001 ps=0x0010
C:\USR\BIN\CMAKE.EXE
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.

Doing set LIBC_BREAKPOINT_ABORT=1 to cause LIBC generate a full .TRP instead of issuing a meaningless message results into the following report (thanks Elbert): https://pastebin.com/h1GqQ649

stdcpp6 update breaks DOSBox.

As discussed on os2world, https://www.os2world.com/forum/index.php/topic,2455.0.html it appears that a stdcpp6 update broke DOSBox, or perhaps the SDL file required by DOSBox.

[C:\Programs\DOSBOX]dosbox
DOSBox version SVN
Copyright 2002-2019 DOSBox Team, published under GNU GPL.
---

Killed by SIGSEGV
pid=0x00c7 ppid=0x00c4 tid=0x0001 slot=0x00db pri=0x0200 mc=0x0001 ps=0x0010
C:\PROGRAMS\DOSBOX\DOSBOX.EXE
STDCPP6 0:0001b26d
cs:eip=005b:1e24b26d      ss:esp=0053:0289fb20      ebp=0289fb38
 ds=0053      es=0053      fs=150b      gs=0000     efl=00012287
eax=0289fe2c ebx=00000000 ecx=199b5f00 edx=199b5f00 edi=0289feb8 esi=0289fb5c
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.

I don't use DOSBox and suggested users file this report but they didn't.
In this case, as the OS/2 patches were committed upstream, I rebuilt DOSBox. But if one program gets broken by an update, others may well also break and the source isn't always available.

round() lround()

round() and lround() are not members of std namespace. I faced some ports which want them in the std namespace. So I guess (nope I didn't a research) it's wrong.

#include <cfenv> fails with multiple errors

Test case:

#include <cfenv>
 
int main()
{
  return 0;
}

Output:

[11 Sep 2020 22:51:14, g++ -Zomf test.cpp]

In file included from C:/usr/include/c++/9/cfenv:41,
                 from test.cpp:3:
C:/usr/include/c++/9/fenv.h:58:11: error: '::fenv_t' has not been declared
   58 |   using ::fenv_t;
      |           ^~~~~~
C:/usr/include/c++/9/fenv.h:59:11: error: '::fexcept_t' has not been declared
   59 |   using ::fexcept_t;
      |           ^~~~~~~~~
C:/usr/include/c++/9/fenv.h:62:11: error: '::feclearexcept' has not been declared
   62 |   using ::feclearexcept;
      |           ^~~~~~~~~~~~~
C:/usr/include/c++/9/fenv.h:63:11: error: '::fegetexceptflag' has not been declared
   63 |   using ::fegetexceptflag;
      |           ^~~~~~~~~~~~~~~
C:/usr/include/c++/9/fenv.h:64:11: error: '::feraiseexcept' has not been declared
   64 |   using ::feraiseexcept;
      |           ^~~~~~~~~~~~~
C:/usr/include/c++/9/fenv.h:65:11: error: '::fesetexceptflag' has not been declared
   65 |   using ::fesetexceptflag;
      |           ^~~~~~~~~~~~~~~
C:/usr/include/c++/9/fenv.h:66:11: error: '::fetestexcept' has not been declared
   66 |   using ::fetestexcept;
      |           ^~~~~~~~~~~~
C:/usr/include/c++/9/fenv.h:68:11: error: '::fegetround' has not been declared
   68 |   using ::fegetround;
      |           ^~~~~~~~~~
C:/usr/include/c++/9/fenv.h:69:11: error: '::fesetround' has not been declared
   69 |   using ::fesetround;
      |           ^~~~~~~~~~
C:/usr/include/c++/9/fenv.h:71:11: error: '::fegetenv' has not been declared
   71 |   using ::fegetenv;
      |           ^~~~~~~~
C:/usr/include/c++/9/fenv.h:72:11: error: '::feholdexcept' has not been declared
   72 |   using ::feholdexcept;
      |           ^~~~~~~~~~~~
C:/usr/include/c++/9/fenv.h:73:11: error: '::fesetenv' has not been declared
   73 |   using ::fesetenv;
      |           ^~~~~~~~
C:/usr/include/c++/9/fenv.h:74:11: error: '::feupdateenv' has not been declared
   74 |   using ::feupdateenv;
      |           ^~~~~~~~~~~
In file included from test.cpp:3:
C:/usr/include/c++/9/cfenv:61:11: error: '::fenv_t' has not been declared
   61 |   using ::fenv_t;
      |           ^~~~~~
C:/usr/include/c++/9/cfenv:62:11: error: '::fexcept_t' has not been declared
   62 |   using ::fexcept_t;
      |           ^~~~~~~~~
C:/usr/include/c++/9/cfenv:65:11: error: '::feclearexcept' has not been declared
   65 |   using ::feclearexcept;
      |           ^~~~~~~~~~~~~
C:/usr/include/c++/9/cfenv:66:11: error: '::fegetexceptflag' has not been declared
   66 |   using ::fegetexceptflag;
      |           ^~~~~~~~~~~~~~~
C:/usr/include/c++/9/cfenv:67:11: error: '::feraiseexcept' has not been declared
   67 |   using ::feraiseexcept;
      |           ^~~~~~~~~~~~~
C:/usr/include/c++/9/cfenv:68:11: error: '::fesetexceptflag' has not been declared
   68 |   using ::fesetexceptflag;
      |           ^~~~~~~~~~~~~~~
C:/usr/include/c++/9/cfenv:69:11: error: '::fetestexcept' has not been declared
   69 |   using ::fetestexcept;
      |           ^~~~~~~~~~~~
C:/usr/include/c++/9/cfenv:71:11: error: '::fegetround' has not been declared
   71 |   using ::fegetround;
      |           ^~~~~~~~~~
C:/usr/include/c++/9/cfenv:72:11: error: '::fesetround' has not been declared
   72 |   using ::fesetround;
      |           ^~~~~~~~~~
C:/usr/include/c++/9/cfenv:74:11: error: '::fegetenv' has not been declared
   74 |   using ::fegetenv;
      |           ^~~~~~~~
C:/usr/include/c++/9/cfenv:75:11: error: '::feholdexcept' has not been declared
   75 |   using ::feholdexcept;
      |           ^~~~~~~~~~~~
C:/usr/include/c++/9/cfenv:76:11: error: '::fesetenv' has not been declared
   76 |   using ::fesetenv;
      |           ^~~~~~~~
C:/usr/include/c++/9/cfenv:77:11: error: '::feupdateenv' has not been declared
   77 |   using ::feupdateenv;
      |           ^~~~~~~~~~~

[11 Sep 2020 22:51:15, exit code 0, took 1.13s]

It's unclear why it happens as LIBC fenv.h contains all declarations that are needed here. Looks like # include_next <fenv.h> in /usr/include/c++/9/fenv.h for some reason has no effect... This header is simply not included. Weird.

Compiling 'master/intl/osdep.c' breaks

It seems gcc automatically enables the __EMX__ macro.
The osdep.c source tries to conditionally include os2compat.c, which is not there.
Could not find os2compat.c in Paul's old repo either.
...?

Make C++ thread interface thread-safe

There is C++ thread support added by @komh in 203e99b. However, __gthread_create and other functions dealing with shared thread data (like the thread list) are not thread-safe. This means that if two threads call __gthread_create (i.e. instantiate an std::thread object) at the same time, data corruption is likely to occur.

We should make this interface thread-safe. One way to do so is to use the Posix code, i.e. switch to using our PTHREAD library (whose pthread_create and other APIs are already thread-safe). This has also a benefit of bringing pthread key destructor support to all C++ threads (see bitwiseworks/pthread-os2#1).

Regression in libgcc, missing functionality of libgcc1 4.9.2

Describe the bug
Attempted to upgrade my working gcc 4.9.2 configuration. Executed through ANPM, the process failed, found the following in the anpm.log:

=== START ===
----------[ 10 Feb 2020 19:53:25 ]----------
Executing: @python G:\UTIL\ANPM\scripts\yum_update.py gcc
Enabling temporary repository arcanoae-exp
Package libgcc1 is obsoleted by libgcc, but obsoleting package does not provide for requirements
Package libgcc1 is obsoleted by libgcc, but obsoleting package does not provide for requirements
Package libgcc1 is obsoleted by libgcc, but obsoleting package does not provide for requirements
Package libgcc1 is obsoleted by libgcc, but obsoleting package does not provide for requirements
Package libgcc1 is obsoleted by libgcc, but obsoleting package does not provide for requirements
Package libgcc1 is obsoleted by libgcc, but obsoleting package does not provide for requirements
Package libgcc1 is obsoleted by libgcc, but obsoleting package does not provide for requirements
Package libgcc1 is obsoleted by libgcc, but obsoleting package does not provide for requirements
Package libgcc1 is obsoleted by libgcc, but obsoleting package does not provide for requirements
Running Transaction Check
YumRPMCheckError(): [u'ERROR with transaction check vs depsolve:', 'libgcc1 is needed by (installed) libaio-0.0.1-5.oc00.pentium4', 'libgcc1 is needed by (installed) libvncserver-0.9.10-4.oc00.pentium4', 'libgcc1 is needed by (installed) libidl-0.8.14-6.oc00.pentium4', u'Please report this error at http://yum.baseurl.org/report']
Error: ERROR with transaction check vs depsolve:libgcc1 is needed by (installed) libaio-0.0.1-5.oc00.pentium4libgcc1 is needed by (installed) libvncserver-0.9.10-4.oc00.pentium4libgcc1 is needed by (installed) libidl-0.8.14-6.oc00.pentium4Please report this error at http://yum.baseurl.org/report
YumRPMCheckError()
Return code: 0
=== STOP ===

Looks like there are a number of other RPM packages which I installed on my system that require functionality provided in libgcc1, unfortunately that functionality is no longer available in libgcc that is part of 9.2.0 release.

Cannot start Firefox 45.9.0 with libgcc 9.2.0-3 or 9.2.0-4

Unfortunately, when attempting to start the last Firefox build submitted to AN (firefox-45.9.0-2), the exe exits immediately, with no TRP file. Downgrading 9.2.0-4 (or 9.2.0-3) gcc packages to 9.2.0-2 allows the program to start. I have installed libc-debuginfo, firefox-debug, gcc-debuginfo. Luckily, this package was not widely distributed, However, it is unknown what other applications may be similarly affected with the new gcc build.

I'm happy to try to get some useful data out of this, but right now, all I get is a quick program exit (almost immediately). The TRP file (with exceptq=Z) is a standard process termination notice, and as exceptq traps, it's hard to know what may be useful.

Edit2: Confirming my original findings. 9.2.0-3 does not work, either. Attempting (again) to gather debug info.

@rspfile

When building something with
gcc -Zomf -Zexe -Zlinker "DISABLE 1121" test.c
all works w/o issues.
But when we use a rspfile like the following:
gcc -Zomf -Zexe -Zlinker "DISABLE 1121" @object1.rsp
we get an error
Error! E30033: file ld6JgbBQ.: lie(10): directive error near 'DISABLE\'

Support C aligned and C++ alignas attributes

There is a GCC __aligned__ attribute and its C++11 alignas counterpart. In short, they allow to specify the alignment (in bytes) for a variable or struct. This thing is basically ignored in our port of GCC now. I.e. given the following aligned.c:

char not_aligned_char;
int not_aligned_int;
char __attribute__ ((aligned (64))) aligned_char_at_64_B;
int __attribute__ ((aligned (128))) aligned_int_at_128_B;

the command gcc -S aligned.c will generate the following assembly:

    .file   "aligned.c"
    .text
    .comm   _not_aligned_char, 8    # 1
    .comm   _not_aligned_int, 16    # 4
    .comm   _aligned_char_at_64_B, 16   # 1
    .comm   _aligned_int_at_128_B, 16   # 4
    .ident  "GCC: (GNU) 9.2.0 20190812 (OS/2 RPM build 9.2.0-5.oc00)"

If we feed it to GCC under Linux, we will get this:

        .file   "aligned.c"
        .text
        .comm   not_aligned_char,1,1
        .comm   not_aligned_int,1,1
        .comm   aligned_char_at_64_B,1,64
        .comm   aligned_int_at_128_B,4,128
        .ident  "GCC: (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008"

You may notice that the .comm directive, along with the second argument which is the variable size, also gets a third argument which specifies its desired alignment from the aligned attribute.

When such an assembly is then linked on OS/2, variables remain unaligned (or, to be exact, aligned at some default alignment which doesn't match the request). As a result, some applications that require strict alignment (e.g. because they use SSE2 instructions that require 128 byte alignment) break.

The reason for that is that the object format used on OS/2 is a.out. And gas supports alignment only for elf and PE formats — simply because a.out is just very old and doesn't support per-symbol alignment specification. So generation of the third .comm option is disabled for it.

Besides, there is also a similar problem in the OMF object file format which all a.out files need to be converted to (by emxomf.exe) before they can be linked into an OS/2 (LX) executable. OMF only supports per-segment alignment which may be word (2 bytes), dword (4 bytes), para (16 bytes) and 64 KBytes. Such per-segment alignment doesn't allow to satisfy all possible alignment requests (especially those which are greater than 16 bytes) in an effective way. It could do so, if using 64K alignment for all segments, but this would be a big waste of program address space, especially in case of a large amount of translation units (object files). So it's not practically possible.

The only solution here is to use something else instead of a.out for object files. For example, the elf format. And then link it with some custom linker to an OS/2 executable. There are rumors that wlink from OpenWatcom (which we already use as a main, and the only supported linker for GCC on OS/2) can link elf object files into LX executables but this needs checking.

error: unsupported size for integer register

GCC 9.2.0 fails to compile the following C++ code (a minimal example so far):

#include <sys/builtin.h>

typedef struct 
{
  signed char volatile done;
  signed char volatile started;
} foo_t;

static inline int
foo (foo_t *once, void (*func) (void))
{
  if (__cxchg (&once->started, 1) == 0)
    {
      func ();
      __cxchg (&once->done, 1);
    }
  do {}  while (!once->done);
  return 0;
}

template<typename _Callable>
void bar(foo_t& __once, _Callable&& __f)
{
  foo(&__once, __f);
}

template void bar(foo_t&, void (*&&)());

using the following command:

g++ -O2 -std=c++11 -c test.cpp

with the following error message:

test.cpp: In function 'void bar(foo_t&, _Callable&&) [with _Callable = void (*)()]'
test.cpp:25:1: error: unsupported size for integer register!!
   25 | }
      | ^

GCC 4.9.2 from RPM also fails but with a different error:

C:/usr/include/386/builtin.h: Assembler messages:
C:/usr/include/386/builtin.h:18: Error: bad register name `%sil'

The full story is here: #2 (comment).

genautomata: out of memory

There is a bunch of build tools in gcc/build used to generate various stuff for GCC. One of these tools is genautomata.exe. It generates a source file from a machine definition (.md) file.

It is run as follows during make process in the gcc subdirectory of the output tree:

build/genautomata.exe ../../master/gcc/common.md ../../master/gcc/config/i386/i386.md \
  insn-conditions.md > tmp-automata.c

If it is built using GCC 4.9.2 and its libstdc++, all is fine. The resulting file is quite big though — 11 MB (as designed). However, if it is built using GCC 9.2.0 and its libstdc++, it exits with the following error message:

out of memory allocating 4064 bytes after a total of 4262222764 bytes

Sometimes a popup message box about SYS0147 is also shown (see #6 (comment)).

Note that I can't try out the binary built with GCC 9.2.0 with a libstdc++ DLL from GCC 4.9.2 because operator delete(void*, unsigned int) (__ZdlPvj) was never exported back then (which is also strange and needs some checking). So I'm not sure yet if it's the new GCC itself or just the new libstdc++ DLL which is guilty here.

Netlabs-rel update broken.

Seems the new updated GCC that was recently moved to netlabs-rel is missing some files. Tail of yum update,

--> Finished Dependency Resolution
Error: Package: gcc-9.2.0-4.oc00.i686 (netlabs-rel)
           Requires: mpc3.dll
Error: Package: cpp-9.2.0-4.oc00.i686 (netlabs-rel)
           Requires: mpc3.dll
Error: Package: gcc-9.2.0-4.oc00.i686 (netlabs-rel)
           Requires: mpfr6.dll
Error: Package: gcc-c++-9.2.0-4.oc00.i686 (netlabs-rel)
           Requires: mpfr6.dll
Error: Package: gcc-c++-9.2.0-4.oc00.i686 (netlabs-rel)
           Requires: mpc3.dll
Error: Package: cpp-9.2.0-4.oc00.i686 (netlabs-rel)
           Requires: mpfr6.dll

Apply OS/2 patches

Since #1 is done, it's time to apply OS/2 patches.

We will take everything from https://github.com/psmedley/gcc/tree/gcc-4_9-branch-os2, plus Paul Smedley kindly offered us his latest patch set for his own build of GCC 9.2.0 (which should also include all from GitHub).

Broken local variable offsets in debug info

By @StevenLevine from https://mantis.arcanoae.com/view.php?id=573#c21690:

I spent some time understanding why some automatic variables have positive and some have negative offsets. The esp/ebp usage seems to affected by the function name. The testcase that reported positive offsets and esp usage seems have done so because the function was named main. Changing the function name to xmain resulted in negative offsets and ebp relative offsets with correct offsets because there were no registers to save an the stack. I built shared.s using a couple of different optimization options and ebp was used to access the local variables. As long as the generated code uses ebp to access the local variables we have a change to get debug data working.

My current guess is if we can figure how to get gcc to account for the extra saved registers when generating .stabs, can get usable local variable displays in the debugger. Here are the .stabs for touch_pages:

.stabs "touch_pages:F25",36,0,1648,_touch_pages
.stabs "buf:p69",160,0,1648,8
.stabs "len:p906",160,0,1648,12
.stabs "dos_len:59",128,0,1651,-20
.stabs "dos_flags:59",128,0,1652,-16
.stabs "buf_addr:1270=B59",128,0,1654,-12
.stabs "buf_end:r59",64,0,1655,3
.stabs "buf:r69",64,0,1648,0

.stabs says that dos_len is at -20 (14h), but we know from inspection that it is at -24h. 14h is correct relative to the esp value after the ebx, esi and ebx registers are pushed on the stack. If we could convince gcc to take these pushes into account when generating the .stabs offsets the HLL debug data would be correct.

I guess we miss some target platform specific declarations in the .stabs generation code that accounts for how GCC actually generates code on OS/2. This might be related to some regressions of merging rather complex patches of our quite old OS/2 code (back from GCC 3 times) into newer versions.

IBM debuggers can't show variable content

With code generated by gcc 4.x, the variable content is not visible most of the times.

Hand editing an assembly file generated from gcc 4.9.2 (using gcc3 output), showed that the only real difference is access to variables: gcc 4 uses ESP to access stack vars, gcc3 uses EBP.
Changing gcc4 assembly to use EBP makes debuggers to work again.

Access with ESP seems a OS/2 only feature, gcc 9.2 on linux still uses EBP.

Also assembly of function start is not correctly aligned.

stab1.gcc4A.txt
stab1.gcc3.txt

std::nearbyint returns `nan` for any argument

std::nearbyint is a modern rounding function in C++.

This following program:

#include <iostream>
#include <cmath>
 
int main()
{
  double d1 = 127.00000;
  std::cout << d1 << ' ' << std::nearbyint(d1) << '\n';
  return 0;
}

outputs 127 nan instead of 127 127 for some reason.

Note that any other double instead of 127 results in nan as well.

Spotted here: bitwiseworks/qtwebengine-chromium-os2#21 (comment).

The build-script example does not work out-of-the-paste

The build-script at:
https://github.com/bitwiseworks/gcc-os2/wiki/Developers#building-gcc
tries to run 'master/autogen.sh' while the curdir is assumed 'gcc' (the toplevel dir).
Should be something like: 'cd master && ./autogen.sh && cd -' ?

Very cool to have this updated GCC btw !
Ben.