psmedley / gcc Goto Github PK

Hi/2.

Here is the patch for max_align_t on C++11. Review, please...

From 37fb62f22a735258af82bd3747704cc36d5e26ca Mon Sep 17 00:00:00 2001
From: KO Myung-Hun <[email protected]>
Date: Sat, 1 Oct 2016 23:32:19 +0900
Subject: [PATCH] OS/2: Define max_align_t on C++11

C++11 requires max_align_t which is a C11 stuff. However, OS/2 kLIBC
headers are not ready for C11.

So, define max_align_t in os_defines.h which is a OS-specefic header
on C++. By this, it's possible to remove _GCC_MAX_ALIGN_T guard of
cstddef, too.

    modified:   libstdc++-v3/config/os/os2/os_defines.h
    modified:   libstdc++-v3/include/c_global/cstddef

---
 libstdc++-v3/config/os/os2/os_defines.h | 8 ++++++++
 libstdc++-v3/include/c_global/cstddef   | 2 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/config/os/os2/os_defines.h b/libstdc++-v3/config/os/os2/os_defines.h
index 3bfe3ef..d9044a9 100644
--- a/libstdc++-v3/config/os/os2/os_defines.h
+++ b/libstdc++-v3/config/os/os2/os_defines.h
@@ -38,4 +38,12 @@
 #define _GLIBCXX_USE_C99_LONG_LONG_CHECK 1
 #define _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC (_GLIBCXX_USE_C99_DYNAMIC || !defined __LONG_LONG_SUPPORTED)

+// C++11 requires max_align_t of C11. See gcc/ginclude/stddef.h.
+#if __cplusplus >= 201103L
+typedef struct {
+  long long __max_align_ll __attribute__((__aligned__(__alignof__(long long))));
+  long double __max_align_ld __attribute__((__aligned__(__alignof__(long double))));
+} max_align_t;
+#endif
+
 #endif
diff --git a/libstdc++-v3/include/c_global/cstddef b/libstdc++-v3/include/c_global/cstddef
index b4cb538..1a87dd6 100644
--- a/libstdc++-v3/include/c_global/cstddef
+++ b/libstdc++-v3/include/c_global/cstddef
@@ -44,7 +44,7 @@
 #include <bits/c++config.h>
 #include <stddef.h>

-#if __cplusplus >= 201103L && defined(_GCC_MAX_ALIGN_T)
+#if __cplusplus >= 201103L
 namespace std
 {
   // We handle size_t, ptrdiff_t, and nullptr_t in c++config.h.
-- 
2.9.2

Somehow our GCC builds lack the built-in __sync functions described there: https://gcc.gnu.org/onlinedocs/gcc-4.4.5/gcc/Atomic-Builtins.html. We need to implement them as this will save us from doing that again and again in applications.

Hi/2.

C++11 std::thread support lacks.

// cxx11thread.cpp
#include <iostream>
#include <thread>

void func1()
{
    std::cout << __func__ << "\n";
}

void func2()
{
    std::cout << __func__ << "\n";
}

int main()
{
    std::thread th1( func1 );
    std::thread th2( func2 );

    th1.join();
    th2.join();

    std::cout << "Bye\n";

    return 0;
}

g++ -std=c++11 cxx11thread.cpp

cxx11thread.cpp: In function 'int main()':
cxx11thread.cpp:16:5: error: 'thread' is not a member of 'std'
     std::thread th1( func1 );
     ^
cxx11thread.cpp:17:5: error: 'thread' is not a member of 'std'
     std::thread th2( func2 );
     ^
cxx11thread.cpp:19:5: error: 'th1' was not declared in this scope
     th1.join();
     ^
cxx11thread.cpp:20:5: error: 'th2' was not declared in this scope
     th2.join();
     ^

There is a problem with emxomf when it comes to a source file containing too much debug info (i.e. compiled with the -g' command line switch): it will fail with theIndex too large` error on such a file.

All builds of gcc starting at least from GCC 4.4.2 and up to at least 4.9.0 have the same problem: for a function declared with the _System cconv modifier the __declspec(dllexport) attribute is ignored. As a result, it's impossible to create _System DLL exports w/o a .DEF file (this feature is used in many modern sources).

There is a known workaround to this issue: a patch to EMXOMF that drops the asterisk that GCC prepends to the function name when it's declared as _System and this cures generation of exports (more details are here). However, Knut claims here that this is too hackish. In particular
this asterisk is used in GCC for purpose (to suppress the leading underscore) and that GCC needs to be fixed instead, not EMXOMF.

Currently, std::acosh and friends are not part of std because our c++config.h lacks _GLIBCXX_USE_C99_MATH_TR1. Should be easily fixable but we also need to guard some imports (like log2, log2f and tgammaf) with #ifdef _GNU_SOURCE as they are not defined by math.h otherwise.

As a temporary solution, one may simply omit the std namespace so that C versions will be dragged right from the global C namespace.

While playing with libc066.logchk DLL, I found that GCC1.DLL causes an assertion (most likely through gcc_assert) during the forked child termination. The test program is attached. This is the call stack (EXCEPTQ install is needed together with LIBC_BREAKPOINT_ABORT=1 to see that, it's omitted in the test):

______________________________________________________________________

 Call Stack
______________________________________________________________________

   EBP     Address    Module     Obj:Offset    Nearest Public Symbol
 --------  ---------  --------  -------------  -----------------------
 Trap  ->  1F6EAC82   LIBC066   0001:0004AC82

 0012FE98  1F697EC1   GCC1      0001:00007EC1

 0012FEC8  1F697EF9   GCC1      0001:00007EF9

 0012FEE8  000114F2   TST-MSYN  0001:000014F2  emx-eh.c#40 ___ehTerm + 32 0001:000014C0 (emx-eh.obj)

 0012FF08  1D666038   LIBC066   0001:00036038  dtor1.c#18 ___ctordtorTerm1 + 90 0001:00035FA8 (dtor1.obj)

  Offset Name                 Type                         Hex Value
  ÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄ
   8     ptr                  pointer to 32 bit signed     201B4

 0012FF28  00011475   TST-MSYN  0001:00001475  emx-ctordtor.c#51 ___ctordtorTerm + 35 0001:00001440 (emx-ctordtor.obj)

 0012FF48  1D69AEA8   LIBC066   0001:0006AEA8  exit.c#69 __std_exit + C0 0001:0006ADE8 (exit.obj)

  Offset Name                 Type                         Hex Value
  ÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄ
   8     ret                  32 bit signed                0

 0012FF68  00010030   TST-MSYN  0001:00000030  crt0.s#94 __text + 30 0001:00000000 ({standard input})

 0012FF8C  1D628011   LIBCX0    0001:00008011  main.s#45 ___init_app + 11 0001:00008000 (D:\Temp\cctGx8Cw.s)

 0012FFE0  1D66945B   LIBC066   0001:0003945B  appinit.s#16 ___init_app + B 0001:00039450 (appinit.obj)


______________________________________________________________________

The above addresses in GCC1 are most likely __deregister_frame and __deregister_frame_info (which calls __deregister_frame_info_bases which calls gcc_assert which calls abort which issues int 3 if LIBC_BREAKPOINT_ABORT is set).

Although emx-ctordtor.c contains some fork callbacks, it looks like the constructor/destructor chain is not properly aligned in the forked child so it asserts on a NULL pointer (presumably, libgcc\unwind-dw2-fde.c line 216, a debug of GCC with symbols s necessary to tell more).

It seems that gcc 4.x.x for OS/2 causes functions to be declared using extern "C" semantics when they have __attribute__((__cdecl__)) attached to them. E.g. for this declaration in C++ context

void __attribute__((__cdecl__)) foo (void **v);

the resulting assembler name (signature) will be _foo instead of __Z3fooPPv (which is the case if _cdecl gets removed). This is not the case with gcc 3.x.x for OS/2 or with gcc 4.x.x on other platforms (e.g. OS X) and looks like a regression of my change that made functions declared as _System in C++ context imply extern "C" (for compatibility with IBM VAC).

Frankly saying there are not many places where it breaks things, but one known case is VirtualBox. The RTCALL calling convention there is defined as __cdecl on OS/2 which causes all functions declared with RTCALL (and with RTDECL which implicitly uses it) to get C signatures instead of C++ ones. For some functions defined in C++ context this brings obvious problems, e.g. for overloaded operators that have the same name by definition (like operator+) but different sets of arguments. This eventually results in several functions with the same signature and the following compiler error:

In file included from D:/Coding/vbox/trunk/src/VBox/Runtime/common/string/ministring.cpp:34:0:
D:/Coding/vbox/trunk/include/iprt/cpp/ministring.h:1024:79: error: conflicting declaration of C function 'const RTCString operator+(const RTCString&, const char*)'
 RTDECL(const RTCString) operator+(const RTCString &a_rstr1, const char *a_psz2);
                                                                               ^
D:/Coding/vbox/trunk/include/iprt/cpp/ministring.h:1013:25: note: previous declaration 'const RTCString operator+(const RTCString&, const RTCString&)'
 RTDECL(const RTCString) operator+(const RTCString &a_rstr1, const RTCString &a_rstr2);
                         ^
D:/Coding/vbox/trunk/include/iprt/cpp/ministring.h:1035:79: error: conflicting declaration of C function 'const RTCString operator+(const char*, const RTCString&)'
 RTDECL(const RTCString) operator+(const char *a_psz1, const RTCString &a_rstr2);
                                                                               ^
D:/Coding/vbox/trunk/include/iprt/cpp/ministring.h:1024:25: note: previous declaration 'const RTCString operator+(const RTCString&, const char*)'
 RTDECL(const RTCString) operator+(const RTCString &a_rstr1, const char *a_psz2);
                         ^
D:/Coding/vbox/trunk/include/iprt/cpp/ministring.h:1035:79: error: conflicting declaration of C function 'const RTCString operator+(const char*, const RTCString&)'
 RTDECL(const RTCString) operator+(const char *a_psz1, const RTCString &a_rstr2);
                                                                               ^
D:/Coding/vbox/trunk/include/iprt/cpp/ministring.h:1013:25: note: previous declaration 'const RTCString operator+(const RTCString&, const RTCString&)'
 RTDECL(const RTCString) operator+(const RTCString &a_rstr1, const RTCString &a_rstr2);

Here is the patch.

From 40ffb56019d5fc9ee21237b3bed78d8dc745c2c8 Mon Sep 17 00:00:00 2001
From: KO Myung-Hun <[email protected]>
Date: Sat, 26 May 2012 12:50:47 +0900
Subject: [PATCH 1/1] OS/2: Append $(exeext) to fixincl target

This fixes the problem that build process stops due to trying to generate
fixincl even though fixincl.exe was already made.

---
 gcc/Makefile.in | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 8f93bfb..8759fd4 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -2721,13 +2721,13 @@ s-fixinc_list : $(GCC_PASSES)
 # Because of CCACHE_HARDLINK, this will also update the timestamp in
 # the build tree, and so fixincl in the build tree will appear to be
 # out of date.  Yuck.
-../$(build_subdir)/fixincludes/fixincl: ; @ :
+../$(build_subdir)/fixincludes/fixincl$(exeext): ; @ :

 # Build fixed copies of system files.
 # Abort if no system headers available, unless building a crosscompiler.
 # FIXME: abort unless building --without-headers would be more accurate and less ugly
 stmp-fixinc: gsyslimits.h macro_list fixinc_list \
-  $(build_objdir)/fixincludes/fixincl \
+  $(build_objdir)/fixincludes/fixincl$(exeext) \
   $(build_objdir)/fixincludes/fixinc.sh
    rm -rf include-fixed; mkdir include-fixed
    -chmod a+rx include-fixed
-- 
1.9.5

-----

There is a bunch of built-in defines related to kLIBC:

Given that we rebrand kLIBC to LIBC Next after forking (see bitwiseworks/libc#17 for more info), we need to add a respective __LIBCN__ define here.

And we should also fix __KLIBC_PATCHLEVEL__ and __KLIBC_VERSION__ to match the point where we forked (i.e. kLIBC 0.6.6).

We have numerous cases when GCC (at least 4.9.2) implicitly generates SSE/SSE2 instructions (e.g. when using -O3 -march=pentium4) but doesn't align arguments for them on the 16-byte boundary as required by the x86 specification. In case of stack-based memory this can be forced globally with -mstackrealign but it's a clear abuse of this option and it also doesn't help when arguments are from the dynamic memory or from global data segments. Such memory may only be aligned on per-variable basis using special GCC variable attribute to force fixed alignment but this is usually not an acceptable solution either. Such an alignment should be done automatically whenever GCC generates SSE/SSE2 and not doing so looks like a bug in our port (as on other platforms it works w/o any additional hassle).

A good test case is FIrefox. See bitwiseworks/mozilla-os2#266 (comment) and below. But perhaps a simple test case for testing purposes should be written when working on this problem.

For some reason, GCC 4.7.3 adds a reference to __ehInit (defined in gcc/config/i386/emx-eh.c) to each and every generated C and C++ source file. There is no need to refer to it in regular object files. This is part of CRT startup code (whose job is to initialize exception handling and such).

The previous GCC versions (e.g. 4.4.6) don't put this symbol into object files.

This looks like a 4.7.3 regression then.

sh does not quit even if build is finished.

Here is the patch.

From b2862e82ee425ae93aff6a337d249f756885888b Mon Sep 17 00:00:00 2001
From: KO Myung-Hun <[email protected]>
Date: Fri, 3 Jul 2015 19:46:14 +0900
Subject: [PATCH] OS/2: do not pass write_fd to the child

This causes the server shell to be frozen even if kill()ed on OS/2.

---
 fixincludes/procopen.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fixincludes/procopen.c b/fixincludes/procopen.c
index 22d4f67..272eaff 100644
--- a/fixincludes/procopen.c
+++ b/fixincludes/procopen.c
@@ -189,6 +189,9 @@ proc2_open (t_fd_pair* p_pair, tCC** pp_args)
   if (pipe ((int *) p_pair) < 0)
     return NOPROCESS;

+  /* Do not pass write_fd to the child */
+  fcntl(p_pair->write_fd, F_SETFD, FD_CLOEXEC);
+
   p_pair->read_fd = chain_open (p_pair->read_fd, pp_args, &ch_id);
   if (ch_id == NOPROCESS)
     close (p_pair->write_fd);
-- 
1.9.5

Somehow it seems that our port is not thread safe when it comes to initializing static C++ objects. I.e. if two threads happen to initiate a static object initialization (e.g. by using local static objects) at the same time, a recursion is very likely which ends up with this exception:

PASS   : tst_QAbstractAnimation::avoidJumpAtStart()
terminate called after throwing an instance of '__gnu_cxx::recursive_init_error'
  what():  std::exception

Killed by SIGABRT
pid=0xb7cc ppid=0xb7cb tid=0x0003 slot=0x007f pri=0x0200 mc=0x0001 ps=0x0010
D:\CODING\QT5\QT5-DEV-BUILD\QTBASE\TESTS\AUTO\CORELIB\ANIMATION\QABSTRACTANIMATION\DEBUG\TST_QABSTRACTANIMATION.EXE

I found it out when debugging Qt tests, see bitwiseworks/qtbase-os2#29 (comment) for the full story. I guess we need a standalone test case but the problem described there is a good test case per se. At least, it can be used to model a standalone one.

Given that Qt has a workaround for this, I'm not going to invest any time in it right now. But it may affect other applications as well so it should be dealt with sooner or later.

Expected behavior:

# uname
Linux
# cat <<EOF | g++ -std=c++11 -x c++ -
> #include <string>
> #include <iostream>
> using namespace std;
> main(){ string s="42";
> cout<<stol(s)<<endl; }
> EOF
# ./a.out
42

Present behavior:

# uname
OS/2
# cat <<EOF | g++ -std=c++11 -x c++ -
> #include <string>
> #include <iostream>
> using namespace std;
> main(){ string s="42";
> cout<<stol(s)<<endl; }
> EOF
<stdin>: In function 'int main()':
<stdin>:5:13: error: 'stol' was not declared in this scope

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.

The GCC policy is that they put pre-generated autotools scripts (configure, libtool, Makefile.in, aclocal.m4 and so on) in the repository. Perhaps, they do it because they have quite a lot of sub-projects and these sub-projects are quite complex in their configure part so that one needs to have a lot of experience and good luck to generate proper configure and friends.

However, since the official versions of autotools lack many bits of OS/2 support, these pre-generated scripts lack it as well. This is a source of various build issues. Since we have relatively fresh versions of almost all autotools now, we should regenerate them in our repo to make them OS/2 friendly. Sometimes we also need to tailor configure scripts for OS/2 on their own but since we don't regenerate them ATM we have to e.g. change configure instead of its source, configure.ac (or Makefile.in instead of Makefile.am) which is inconsistent and error prone.

The problem is that GCC insists on the particular version of autoconf, 2.64 ATM, wile the version we have is 2.69 so it doesn't work out of the box. This issue to deal with this task.

The i386 target is really old and makes problems (some applications like Mozilla are simply cannot be built in this mode) so we should consider switching the default architecture to i686. See also #19 and http://trac.netlabs.org/rpm/ticket/151.

gcc492 is missing a patch for cstddef which is in gcc491. kLIBC does not support max_align_t.

And sorry about that this is not for a git repo, but a release.

diff -uNr  include/c++/4.9.2/cstddef.org include/c++/4.9.2/cstddef
--- include/c++/4.9.2/cstddef.org  2014-11-01 11:21:16.000000000 +0900
+++ include/c++/4.9.2/cstddef 2015-01-12 18:29:48.000000000 +0900
@@ -44,7 +44,7 @@
 #include <bits/c++config.h>
 #include <stddef.h>

-#if __cplusplus >= 201103L
+#if __cplusplus >= 201103L && !defined (__KLIBC__)
 namespace std
 {
   // We handle size_t, ptrdiff_t, and nullptr_t in c++config.h.

BSS sections are initialized with zeroes and specifying a non-zero value in .align directives causes latest binutils to barf with this on code generated by GCC:

Warning: ignoring fill value in section `.bss'

The related binutils for OS/2 ticket containing an example and a suggested solution is here: http://trac.netlabs.org/ports/ticket/165.

inet_makeaddr() crashes in gcc 4.9.2
the crash is like:
[E:\trees\tests]inet

Killed by SIGSEGV
pid=0x87b0 ppid=0x159b tid=0x0001 slot=0x00b1 pri=0x0200 mc=0x0001 ps=0x0010
E:\TREES\TESTS\INET.EXE
TCPIP32 0:0000cd70
cs:eip=005b:1f86cd70 ss:esp=0053:0012ff8c ebp=0012ffa0
ds=0053 es=0053 fs=150b gs=0000 efl=00010206
eax=00000000 ebx=0012ffa8 ecx=58e9fd00 edx=00000000 edi=00000000 esi=00000000
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.

this .c file demonstrates the issue
inet.txt

Currently, GCC will generate an A.OUT executable (or DLL) if it is given the -o option w/o specifying the extension of the output file and there is also no -Zomf option on the GCC command line. Can be easily reproduced with this:

echo "int main() { return 0; }" > test.c
gcc -o test test.c

First, it is a bit weird that changing the output file extension changes the binary format. Second, there is no point in generating A.OUT binaries at all on OS/2 (at least until we fix the A.OUT loader for the OS/2 kernel which frozen in its deep alpha stage). We should make GCC always generate LX binaries, regardless of the extension or -Zomf presence.

This bug affects all configure-based projects that compile conftest.c files not only to check for compiler errors but also to run them afterwards: an attempt to run an A.OUT conftest executable will end up in sh interpreting it as a shell script with a subsequent weird execution failure and configure abortion.

SSE2 builtins enabled with -msse2 use m128i (16-byte) variables to execute SSE2 instructions. This variables must be aligned on a 4 word boundary — otherwise the CPU will generate an access violation exception (SIGSEGV). However, GCC for OS/2 fails to do so — it doesn't perform any special alignment on them (which usually makes them aligned on a word (4 byte) boundary). This is wrong and needs to be fixed.

The version of GCC affected is at least 4.4.x. (including 4.4.6). More details are here http://trac.netlabs.org/qt4/ticket/187 and here bitwiseworks/mozilla-os2#29 (comment).

Hi/2.

gcc 4.9 introduced some C11 headers such as stdatomic.h. However, gcc distribution does not have them at all.

Fortunately, they seems to be are in /gcc/ginclude. Please distribute gcc with them.

In GCC 4.4.6 (and in all earlier versions of 4.x.x) the gcc4XX.dll file was built using the makefile from gcc/config/i386/t-emx.

In GCC 4.7.3 it is built using the makefile from libgcc/config/i386/t-emx.

These make files are slightly different. The one in libgcc seems to be made after the gcc/config/i386/t-emx file from the GCC 3 builds by Knut (a copy of this file is also here: http://trac.netlabs.org/libc/browser/branches/libc-0.6/src/gcc/gcc/config/i386/t-emx).

The one in gcc looks like a derivative of both of both or so (???).

This looks completely wrong to me, there should be only one source for gccXXX.dll.

Building python 2.7 with -O3 -march=pentium4 crashes the build after creating PYEXPAT.
-O3 for plain i386 is fine.
-O2 -march=pentium4 is fine too.

Also similar issues are present when building AOO connectivity and dbaccess code. In this case, -O0 is required to get working binaries.

The current work flow assumes that we do our OS/2 work on copies of official upstream branches. Each copy is started at some official release tag of the corresponding branch and then updates in that branch are periodically merged into our copy as the original project evolves. This is easier to explain with the picture:

I.e. our gcc-4_7-branch-os2 is a copy of the gcc-4_7-branch (that was started at the gcc-4_7_3-release tag), the gcc-4_9-branch-os2 is a copy of the gcc-4_9-branch (started at gcc-4_9_0-release). Since our changes are never pushed upstream, they have no chance to end up on master where new official branches originate from. This means that we must port our OS/2 changes to each new branch over and over again. On the picture above, this means that commits o1 and o2 are mostly duplicates of each other, incapsulating all OS/2 work plus a few patches specific to the given branch. Note that while this work is represented by a single commit on each branch (to simplify the graph), in reality it's a big number of separate commits. And as OS/2 development evolves, the number of commits we need to port to each new branch (e.g. to imaginary future gcc-4_10-branch and gcc-4_11-branch) will keep growing and will eventually make maintenance impossibly difficult and/or too error prone.

Instead, I suggest a different approach. We will create a special master branch for our OS/2 development, called master-os2. This branch will be started off from the original master branch to maintain proper ancestry and history information. The best place to start it is the next major release of gcc — or, more specifically, the place on master where a branch for the new major release will originate from (commit 8 on the picture). Then we will apply all our current OS/2 patches to master-os2 (commit o3) and do all further development on it as well. When it's time for a release, we will start an OS/2 specific branch (gcc-4_10-branch-os2) at our master-os2 branch and not at the original branch as we do now. Then we will merge any changes from the original branch we want in our release (this will most likely be an official release tag, like gcc-4_10_0-release, marked with commit 9 on the picture) with our OS/2 specific branch (commit o4) and here we are.

Then we will continue our future OS/2 work on our OS/2 master branch (not shown on the picture) back-porting it to branches we still support when necessary (not shown), as well as do some fixes right on the branches back-porting them back to our master when necessary (not shown).

When it's time to do a new major release, we will merge master changes to master-os2— again, at the point where the new major release branch starts off (commit 10 on the picture) which will result in commit o5 where the new OS/2-specific branch for that major release will originate from. Then we will merge changes from the original branch at the point of an official release we want to do (using the release tag, commit 11) to some release to our OS/2 branch (commit o6) and we are done again. And so on.

This new work flow will give us one significant benefit: all OS/2 patches (except a few very branch specific ones) will be done only ONCE, on master-os2, where they will be inherited by all our OS/2 branches in the future — w/o the need to port them again and again to each new branch. This will both significantly decrease the amount of work needed for each new release and make history much cleaner allowing to track history of OS/2 changes and their evolvement over time.

This issue is to discuss the suggested work flow and to track its implementation. Comments are welcome.

We should try to fix support for pre-compiled headers for GCC on OS/2 - this should speed up compilation time for QT as well as for other projects.

here is what Paul said some month ago:
I have already tried to implement this using the cygwin approach & using Yuri's mmap library - but seems it doesn't work for this stuff :( The stuff in host-cygwin.c is part of what was added back in GCC 3.4.6 days for pch support - if anyone has ideas on how to implement on OS/2 I'd be happy to accept a host-emx.c :)

In 2e73649 (with fixes in 2049c70 and 411dfe1) I made _System behave as if extern "C" was also specified: i.e. suppress C++ name mangling.

As turned out here, bitwiseworks/mozilla-os2#9 (comment), this has a side effect: if you declare a _System function within a namespace, it will actually be ignored and the function will get a global C-style name. In case if a function system with the same name is also defined in a different namespace, this will create a name conflict not expected by the programmer. This may eventually lead to unexpected behavior (as described in the link above).

The same will probably apply to situations where _System is used on class members (the class is also a namespace).

The current behavior is therefore wrong and should be fixed somehow. I need to check how IBM C/C++ behaves here and how GCC reacts on things like extern "C" inside C++ namespaces.

__STDC_CONSTANT_MACROS and __STDC_LIMIT_MACROS are defined as built-in
macros. This causes unnecessary warnings of redefinition of those
macros.

Instead, use wrapper headers for them.

Here is the patch. Review, please...

0001-OS-2-Use-wrapper-headers-for-stdint.h-instead-of-bui.patch.txt

Hi/2.

Some C99 features in C++11 are not enabled. For example, INT64_C() of stdint.h and long long stuffs. Especially, long long stuffs disables _GLIBCXX_USE_C99 feature of libstdc++-v3. As a result, many C99 functions such as lldiv() are missing in std namespace. #14 is releated to this.

Hi/2.

Currently, OS/2 uses general locale(ctype) support of libstdc++-v3. However, it crashes when using std::ctype::classic_table(), because it returns 0(NULL). The following are the test codes.

#include <iostream>
#include <vector>
#include <locale>
#include <sstream>

// This ctype facet classifies commas and endlines as whitespace
struct csv_whitespace : std::ctype<char> {
    static const mask* make_table()
    {
        // make a copy of the "C" locale table
        static std::vector<mask> v(classic_table(), classic_table() + table_size);
        v[','] |=  space;  // comma will be classified as whitespace
        v[' '] &= ~space;      // space will not be classified as whitespace
        return &v[0];
    }
    csv_whitespace(std::size_t refs = 0) : ctype(make_table(), false, refs) {}
};

int main()
{
    std::string in = "Column 1,Column 2,Column 3\n123,456,789";
    std::string token;

    std::cout << "default locale:\n";
    std::istringstream s1(in);
    while(s1 >> token)
            std::cout << "  " << token << '\n';

    std::cout << "locale with modified ctype:\n";
    std::istringstream s2(in);
    s2.imbue(std::locale(s2.getloc(), new csv_whitespace));
    while(s2 >> token)
            std::cout << "  " << token<< '\n';
}

Hi/2.

gcc-os2-492 misses some builtin macros.

Here are the builtin macros of gcc-mingw-491.

#define __UINT_LEAST8_TYPE__ unsigned char
#define __SIG_ATOMIC_TYPE__ int
#define __UINTMAX_TYPE__ long long unsigned int
#define __INT_FAST16_TYPE__ short int
#define __INT_FAST64_TYPE__ long long int
#define __UINT8_TYPE__ unsigned char
#define __INT_FAST32_TYPE__ int
#define __UINT_LEAST16_TYPE__ short unsigned int
#define __SIZE_TYPE__ unsigned int
#define __INT8_TYPE__ signed char
#define __INT_LEAST16_TYPE__ short int
#define __UINT_LEAST64_TYPE__ long long unsigned int
#define __UINT_FAST16_TYPE__ short unsigned int
#define __CHAR16_TYPE__ short unsigned int
#define __INT_LEAST64_TYPE__ long long int
#define __INT16_TYPE__ short int
#define __INT_LEAST8_TYPE__ signed char
#define __INTPTR_TYPE__ int
#define __UINT16_TYPE__ short unsigned int
#define __WCHAR_TYPE__ short unsigned int
#define __UINT_FAST64_TYPE__ long long unsigned int
#define __INT64_TYPE__ long long int
#define __WINT_TYPE__ short unsigned int
#define __UINT_LEAST32_TYPE__ unsigned int
#define __INT_LEAST32_TYPE__ int
#define __UINT64_TYPE__ long long unsigned int
#define __INT_FAST8_TYPE__ signed char
#define __UINT_FAST32_TYPE__ unsigned int
#define __CHAR32_TYPE__ unsigned int
#define __INT32_TYPE__ int
#define __INTMAX_TYPE__ long long int
#define __PTRDIFF_TYPE__ int
#define __UINT32_TYPE__ unsigned int
#define __UINTPTR_TYPE__ unsigned int
#define __UINT_FAST8_TYPE__ unsigned char

However, gcc-os2-492

#define __UINTMAX_TYPE__ long long unsigned int
#define __SIZE_TYPE__ unsigned int
#define __CHAR16_TYPE__ short unsigned int
#define __WCHAR_TYPE__ short unsigned int
#define __WINT_TYPE__ unsigned int
#define __CHAR32_TYPE__ unsigned int
#define __INTMAX_TYPE__ long long int
#define __PTRDIFF_TYPE__ int

You can get these macros with this,

g++ -E -dM - < nul | grep _TYPE__