Somewhere in the codesourcery changes there was a yacc regeneration of intl/plural.c. This serves no purpose I can find, except to balloon the diff. It should be dropped

For reasons that aren't state, CodeSourcery caused sol2-c.c to avoid the use of the %< and %> characters in error and warning messaging, instead using literal single quotes.

No other file was touched in this manner, and as best as I can tell this merely serves to balloon the diffs

Now that we really do have a libdwarf which processes relocations, there's a really great chance that this option is useless now (it existed solely to try to prevent relocations in DWARF sections from being generated).

Thought I'd give this a run as a standard compiler, but after unpacking to /opt I noticed the following:

~$ /opt/gcc/4.4.4/bin/cpp -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../../configure --prefix=/opt/gcc/4.4.4 --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/bin/ld --without-gnu-ld --enable-languages=c,c++,objc --enable-shared --with-mpfr-include=/usr/include/mpfr --with-gmp-include=/usr/include/gmp --with-pkgversion='Illumos tags/gcc-4.4.4-il-2' --with-bugurl=http://github.com/richlowe/gcc/issues
Thread model: posix
gcc version 4.4.4 (Illumos tags/gcc-4.4.4-il-2)
COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=i386'
/opt/gcc/4.4.4/libexec/gcc/i386-pc-solaris2.11/4.4.4/cc1 -E -quiet -v - -mtune=i386
ignoring nonexistent directory "/opt/gcc/4.4.4/lib/gcc/i386-pc-solaris2.11/4.4.4/../../../../i386-pc-solaris2.11/include"

include "..." search starts here:

include <...> search starts here:

/usr/local/include
/opt/gcc/4.4.4/include
/opt/gcc/4.4.4/lib/gcc/i386-pc-solaris2.11/4.4.4/include
/opt/gcc/4.4.4/lib/gcc/i386-pc-solaris2.11/4.4.4/include-fixed
/usr/include
End of search list.
^C

Did I do something wrong?

The warnings about the 2nd argument to va_start() not being the last formal paramater are troubling, and possibly indicative of incorrect code being generated. Patching around them with a flag to disable the warning is the wrong way to approach the problem.

Hi,

I'd like to start work on an illumos gcc 9.2.0 branch, ready for when the gcc8/9 cleanup work is at the point where we want to start running gcc9 as a shadow, and to make sure that that same cleanup work is being done under a compiler with the right values stuff.

To that end, please could somebody create a new il-9_2_0 branch based on upstream's gcc-9_2_0-release tag, and then I can raise some PRs against it to rebase Rich's work from the il-9_1_0 branch, and to add some more commits that we have in the OOCE branch.

Thanks

@richlowe @jclulow

Weirdly, we have a typo in gcc/config/sparc.c

#include "expr.h"l

Which has parsed, worked, and completely gone unnoticed.

How embarrassing

On SPARC Codesourcery patched in a -no-integer-ldd-std flag to avoid generating ldd and std instructions of unaligned integer operands. It didn't merge pleasantly into 4.x because of the change to use RTL for the SPARC prologue. It should be plucked from the codesourcery/* branches and merged.

During some investigation, we noticed that the illumos gcc 8 and 9 may not be
choosing to link values-xpg[46].c in the same way as our earlier versions.

We should investigate this and fix the specs files as needed. We definitely do not want to be accidentally including xpg4 everywhere.

Initial work for 9.1.0 is here:
https://github.com/illumos/gcc/compare/3defceaa1a29...richlowe:il-9_1_0?expand=1

I'd like to bring this into illumos/gcc, following IPD 7's path of putting works-in-progress in illumos/gcc.

This is a straight rebase of the 8.3 branch, with changes fixed upstream (mapfile v2) dropped, and a place holder disabling libsanitizer until we fix it.

Test changes look like:

Tests that now fail, but worked before:

unix//-m64: gcc.target/i386/pr57193.c scan-assembler-times movdqa 2
unix/: gcc.target/i386/pr57193.c scan-assembler-times movdqa 2
unix/: gcc.target/i386/pr81563.c scan-assembler-times movl[\\t ]*-4\\(%ebp\\),[\\t ]*%edi 1
unix/: gcc.target/i386/pr81563.c scan-assembler-times movl[\\t ]*-8\\(%ebp\\),[\\t ]*%esi 1

New tests that FAIL:

unix//-m64: g++.dg/lto/pr89335 cp_lto_pr89335_0.o assemble, -O2 -flto -Wsuggest-final-methods
unix//-m64: g++.dg/pr80481.C  -std=gnu++17  scan-assembler-not vmovaps
unix//-m64: gcc.dg/ipa/ipa-icf-38.c scan-ltrans-tree-dump-not optimized "Function bar"
unix//-m64: gcc.target/i386/ipa-stack-alignment-2.c scan-assembler sub.*%.sp
unix//-m64: gcc.target/i386/ipa-stack-alignment.c scan-assembler sub.*%.sp
unix//-m64: gcc.target/i386/pr34256.c scan-assembler-times mov 3
unix//-m64: gcc.target/i386/pr90178.c scan-assembler-times xorl[\\t ]*\\%eax,[\\t ]*%eax 1
unix//-m64: gcc.target/i386/vartrack-1.c scan-rtl-dump-times vartrack "[0-9][0-9]*: {\\[argp:DI-0x10\\]=bx:DI;sp:DI=argp:DI-0x10;}" 1
unix//-m64: gcc.target/i386/vartrack-1.c scan-rtl-dump-times vartrack "[0-9][0-9]*: {bx:DI=\\[argp:DI-0x10\\];sp:DI=argp:DI-0x8;}" 1
unix/: g++.dg/lto/pr89335 cp_lto_pr89335_0.o assemble, -O2 -flto -Wsuggest-final-methods
unix/: gcc.dg/ipa/ipa-icf-38.c scan-ltrans-tree-dump-not optimized "Function bar"
unix/: gcc.target/i386/pr18041-2.c scan-assembler-times and 1
unix/: gcc.target/i386/pr18041-2.c scan-assembler-times or 1
unix/: gcc.target/i386/pr89676.c scan-assembler-times movl 2
unix/: gcc.target/i386/pr90178.c scan-assembler-times xorl[\\t ]*\\%eax,[\\t ]*%eax 1

@jclulow @jlevon @citrus-it @alarcher

It would seem that libstdc++.so.0.6.28 does not end up built with -D_TS_ERRNO defined (e.g., via -D_REENTRANT). This results in errno checks in, for example, std::filesystem::status() looking at the global errno rather than using *___errno() as it should to local the thread-specific error number.

This was noticed when trying to use Clickhouse, a large C++ program that makes heavy use of threads. The std::filesystem::exists() call would throw unexpectedly for files or directories that did not exist -- but it would report "Error 0" as the reason.

It's possible to pass -D_TS_ERRNO in via CFLAGS and CXXFLAGS while building GCC -- but I expect we should enable this by default and always in the source itself, in order to ensure correct binaries are always created.

Although the unwillingness for the patched-for-illumos gcc to omit frame pointers is useful nearly all of the time, there are occasions when it is unacceptable. There is a small body of software (such as BIOSes and JITs) where forcefully including frame pointers can negatively impact the correctness of the compiled artifacts. We should include an escape hatch -fforce-omit-frame-pointer for use in such situations.

In gcc7 there is support for a number of different functions which are called thunks. These thunks may fire at function entry, return, or be used for indirect calls, among other things. The way that gcc7 names these depends on whether or not it believes that the general system supports what it considers hidden, link-once capabilities. This is summarized in the USE_HIDDEN_LINKONCE macro. Unfortunately, for a confluence or reasons, gcc7 does not currently believe that our environment supports the use of USE_HIDDEN_LINKONCE. Thew ay that gcc7 names the thunks depends on support for this feature. Without this feature, the thunks are named in ways that aren't very usable.

Unfortunately, to properly mitigate Spectre v2 in software, we are opting to use retpolines on systems that don't have enhanced IBRS. To do that, one needs to pass the following two options to gcc7: -mindirect-branch=thunk-extern -mindirect-branch-register. These cause us not to emit retpolines inline, but rather to a centralized point. This is important beacuse we need to patch all of those points and we don't want to have introduce a new reolcation type to krtld (and the surrounding toolchain) at this time for that.

@richlowe put together a patch for this which basically forces us to name indirect extern thunk types such as those used by retpolines regardless of the USE_HIDDEN_LINKONCE capabilities. The way that gcc7 works here is that there are two different types of ways that the various thunks are compiled:

1. In the context of various functions.
2. At the end of a compilation unit to emit various thunks noted as being required.

When using the retpoline configuration described above, the only thunks that are present are the ones emitted via 1. However, because the compiler comes back for others in case two, that is why cfun may or may not be valid in the patch. Further, because of these different types and uses, it seems reasonable that we can override the naming issue when dealing with indirect extern thunks, because they need to refer to a single external name and the implementation will never be part of the compilation unit itself, hence the fact that we force the external name makes sense.

To test this, I've put together a couple different things. First, I built illumos and did a wsdiff between the version with these changes and without it, changing nothing else in illumos. The wsdiff only had noise based on changes in CTF. Next, I did a bunch of testing of the actual retpoline implementation. While I haven't finished the verification that no more non-indirect calls remain, I have confirmed that we properly are always building with the right names in this case.

Finally, I went through and ran the gcc test suite. The results I had before were:

                === gcc Summary ===

# of expected passes            117266
# of unexpected failures        71
# of unexpected successes       1
# of expected failures          371
# of unresolved testcases       1
# of unsupported tests          2089

                === g++ Summary ===

# of expected passes            105204
# of unexpected failures        3
# of expected failures          394
# of unsupported tests          4054

After, I had:

                === gcc Summary ===

# of expected passes            117276
# of unexpected failures        61
# of unexpected successes       1
# of expected failures          371
# of unresolved testcases       1
# of unsupported tests          2089


                === g++ Summary ===

# of expected passes            105204
# of unexpected failures        3
# of expected failures          394
# of unsupported tests          4054

Going through the differences between the tests, I was able to observe that the indirect-extern thunk tests now passed. The other thunk tests failed in the same way as before, which was part of the goal -- to make sure that they weren't impacted.

A mismerge against CodeSourcery diffs causes us to use

TREE_CODE_CLASS (TREE_CODE (decl)) == 'd'

Rather than the more obvious

DECL_P(decl)

This has the unfortunate side effect of causing us to treat these pragmas slightly differently (always as if they must be delayed waiting for the named symbol to exist)

We implement -fconstant-pools as part of a scheme to avoid GOT-relative relocations. While cw uses this flag to translate Studio -Wu,no_got_relocs, that flag is never used by the build, so we're just carrying these changes as noise.

It is possible, if unlikely, that the actual bug here is the lack of use of -Wu,no_got_relocs. I am presuming everyone surviving so long without it, to either compiler, makes this the least likely of the options.

Illumos bug 2757 outlines a problem with 32bit processes making system calls to the 64bit kernel on SPARC. While I'd love to fix this in the OS, and we should fix this in the OS, it turns out that the vast majority of our ioctl entry points are broken (not casting pointers to caddr32_t, or the like), so we'd have to fix all those, or fix every copy* routine to ignore the high 32bits of addresses.

It's easier, and better (short term) to patch the compiler to do what we need and buy ourselves some time. Let's do that.

We patch #pragma align such that it may be applied to variables following their definition. Something which GCC would normally disallow.

It is just as tractable for us to fix our code to stop trying to align things after their definition, and to then drop the patch.

As documented here (http://gcc.gnu.org/onlinedocs/gcc-3.2.1/gccint/Misc.html), I'd like to request adding HANDLE_PRAGMA_PACK_PUSH_POP. Gcc's future (post 4.4) is that this will become the default when HANDLE_PRAGMA_PACK is defined.

HANDLE_PRAGMA_PACK_PUSH_POP
    Define this macro (to a value of 1) if you want to support the Win32 style pragmas #pragma pack(push,n) and #pragma pack(pop). The pack(push,n) pragma specifies the maximum alignment (in bytes) of fields within a structure, in much the same way as the __aligned__ and __packed__ __attribute__s do. A pack value of zero resets the behavior to the default. Successive invocations of this pragma cause the previous values to be stacked, so that invocations of #pragma pack(pop) will return to the previous value.

Currently, only HANDLE_PRAGMA_PACK_WITH_EXPANSION is defined in gcc/config/sol2.h.

HANDLE_PRAGMA_PACK_PUSH_POP could be defined there, or perhaps in sol2-10.h

To do a quick and dirty test without patching, I built oi-userland/components/illumos-gcc with the following:

richard@devzone:~/src/oi-userland/components/illumos-gcc$ git diff .
diff --git a/components/illumos-gcc/Makefile b/components/illumos-gcc/Makefile
index df86dd8..e984f21 100644
--- a/components/illumos-gcc/Makefile
+++ b/components/illumos-gcc/Makefile
@@ -26,6 +26,7 @@ include $(WS_TOP)/make-rules/configure.mk
 include $(WS_TOP)/make-rules/ips.mk

 CC_BITS=
+CPPFLAGS=      -DHANDLE_PRAGMA_PACK_PUSH_POP
 CFLAGS=                -g -O2
 CONFIG_SHELL=  /bin/sh

@@ -51,6 +52,7 @@ CONFIGURE_OPTIONS +=  --with-pkgversion="Illumos $(ILLUMOS_VER
 CONFIGURE_OPTIONS +=   --with-bugurl="http://github.com/illumos/gcc/issues"

 COMPONENT_BUILD_ENV=           SHELL=$(CONFIG_SHELL) CFLAGS="$(CFLAGS)" STAGE1_
+COMPONENT_BUILD_ENV+=          CPPFLAGS="$(CPPFLAGS)" STAGE1_CPPFLAGS="$(CPPFLA
 COMPONENT_BUILD_GMAKE_ARGS=    -j8
 COMPONENT_BUILD_TARGETS=       bootstrap

The motivation to add this concerns acpica-unix2-20140214 integration, where (the following is an extract from changes.txt):

ACPICA headers: Deployed the use of #pragma pack(push) and #pragma 
pack(pop) directives to ensure that the ACPICA headers are independent of 
compiler settings or other host headers.

And a build produces the following:

/home/richard/ws/illumos-gate/usr/src/common/acpica/include/actypes.h:47: error: #pragma pack(push[, id], <n>) is not supported on this target [-Wpragmas]
/home/richard/ws/illumos-gate/usr/src/common/acpica/include/actypes.h:1320: error: #pragma pack(pop[, id], <n>) is not supported on this target [-Wpragmas]
/home/richard/ws/illumos-gate/usr/src/common/acpica/include/acexcep.h:48: error: #pragma pack(push[, id], <n>) is not supported on this target [-Wpragmas]
/home/richard/ws/illumos-gate/usr/src/common/acpica/include/acexcep.h:350: error: #pragma pack(pop[, id], <n>) is not supported on this target [-Wpragmas]
/home/richard/ws/illumos-gate/usr/src/common/acpica/include/actbl.h:48: error: #pragma pack(push[, id], <n>) is not supported on this target [-Wpragmas]
/home/richard/ws/illumos-gate/usr/src/common/acpica/include/actbl1.h:48: error: #pragma pack(push[, id], <n>) is not supported on this target [-Wpragmas]
/home/richard/ws/illumos-gate/usr/src/common/acpica/include/actbl1.h:1146: error: #pragma pack(pop[, id], <n>) is not supported on this target [-Wpragmas]
/home/richard/ws/illumos-gate/usr/src/common/acpica/include/actbl2.h:48: error: #pragma pack(push[, id], <n>) is not supported on this target [-Wpragmas]
/home/richard/ws/illumos-gate/usr/src/common/acpica/include/actbl2.h:1421: error: #pragma pack(pop[, id], <n>) is not supported on this target [-Wpragmas]
/home/richard/ws/illumos-gate/usr/src/common/acpica/include/actbl3.h:48: error: #pragma pack(push[, id], <n>) is not supported on this target [-Wpragmas]
/home/richard/ws/illumos-gate/usr/src/common/acpica/include/actbl3.h:737: error: #pragma pack(pop[, id], <n>) is not supported on this target [-Wpragmas]
/home/richard/ws/illumos-gate/usr/src/common/acpica/include/actbl.h:445: error: #pragma pack(pop[, id], <n>) is not supported on this target [-Wpragmas]
/home/richard/ws/illumos-gate/usr/src/common/acpica/include/acoutput.h:47: error: #pragma pack(push[, id], <n>) is not supported on this target [-Wpragmas]
/home/richard/ws/illumos-gate/usr/src/common/acpica/include/acoutput.h:469: error: #pragma pack(pop[, id], <n>) is not supported on this target [-Wpragmas]
/home/richard/ws/illumos-gate/usr/src/common/acpica/include/acrestyp.h:48: error: #pragma pack(push[, id], <n>) is not supported on this target [-Wpragmas]
/home/richard/ws/illumos-gate/usr/src/common/acpica/include/acrestyp.h:702: error: #pragma pack(pop[, id], <n>) is not supported on this target [-Wpragmas]
/home/richard/ws/illumos-gate/usr/src/common/acpica/include/acpiosxf.h:53: error: #pragma pack(push[, id], <n>) is not supported on this target [-Wpragmas]
/home/richard/ws/illumos-gate/usr/src/common/acpica/include/acpiosxf.h:556: error: #pragma pack(pop[, id], <n>) is not supported on this target [-Wpragmas]
/home/richard/ws/illumos-gate/usr/src/common/acpica/include/acconfig.h:48: error: #pragma pack(push[, id], <n>) is not supported on this target [-Wpragmas]
/home/richard/ws/illumos-gate/usr/src/common/acpica/include/acconfig.h:239: error: #pragma pack(pop[, id], <n>) is not supported on this target [-Wpragmas]
/home/richard/ws/illumos-gate/usr/src/common/acpica/include/acbuffer.h:48: error: #pragma pack(push[, id], <n>) is not supported on this target [-Wpragmas]
/home/richard/ws/illumos-gate/usr/src/common/acpica/include/acbuffer.h:249: error: #pragma pack(pop[, id], <n>) is not supported on this target [-Wpragmas]
/home/richard/ws/illumos-gate/usr/src/common/acpica/include/acpixf.h:57: error: #pragma pack(push[, id], <n>) is not supported on this target [-Wpragmas]
/home/richard/ws/illumos-gate/usr/src/common/acpica/include/acpixf.h:836: error: #pragma pack(pop[, id], <n>) is not supported on this target [-Wpragmas]

Although I have requested upstream ACPICA to reconsider using only the #pragma pack([n]) syntax, there are no garantees it will be respun.

Again, recent gcc versions, have this by default and clang does as well.