Re: gcc m68k default optimization flag

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

mrg@ wrote:

> BTW, if you think that GCC 4.8 is working fine with this
> change, it's probably time to switch the default for it?

In my opinion, someone[tm] who will handle gcc48 migration
schedule should explicitly ask port-maintainers and users
to check MD binaries, especially kernels and bootloaders.

There was a developer who claimed we didn't need such announcement
in public, but as a Tier-II port maintainer, such strategy
"no announcement of migration but it's Tier-II users' responsibility"
seems quite inconsistent.


Anyway, we had several MD problem on gcc 4.1.x and 4.5.x migration
 http://mail-index.netbsd.org/source-changes/2009/01/06/msg214930.html
 http://mail-index.netbsd.org/source-changes/2012/07/26/msg035956.html
and that's why I've tried whole installation on my ports.

At least gcc 4.8.x seems no longer keep the order of const data
in ro section.  For example, gcc 4.8.3 make the following diff
on x68k/stand/boot_ustarfs:

% diff -u fdboot_ustar.gcc4?.dump
--- fdboot_ustar.gcc45.dump     2014-06-22 17:38:54.000000000 +0900
+++ fdboot_ustar.gcc48.dump     2014-06-22 17:38:58.000000000 +0900
@@ -59,6 +59,6 @@
 000003a0  2a 40 2c 40 4e d0 4e b9  00 00 22 ec 49 6c 6c 65  |*@,@N.N...".Ille|
 000003b0  67 61 6c 20 73 65 63 6f  6e 64 61 72 79 20 62 6f  |gal secondary bo|
 000003c0  6f 74 00 00 4e b9 00 00  22 ec 49 6e 76 61 6c 69  |ot..N...".Invali|
-000003d0  64 20 6d 61 67 69 63 00  31 2e 30 00 36 2e 39 39  |d magic.1.0.6.99|
-000003e0  2e 34 33 00                                       |.43.|
+000003d0  64 20 6d 61 67 69 63 00  36 2e 39 39 2e 34 33 00  |d magic.6.99.43.|
+000003e0  31 2e 30 00                                       |1.0.|
 000003e4
% cat obj.x68k/vers.c 
const char bootprog_rev[] = "1.0";
const char bootprog_kernrev[] = "6.99.43";
%
---

If there are bootloaders (and other standalone binaries) that assume
the order of data is the same as the C source layout, they would fail.

Atari's bootloader assumed that the first function in the C source
would be allocated at the top of the binary, and it failed on
gcc 4.1 migration, for example.


There are also more issue on gcc 4.8.x with -O2 on m68k:

- doc/HACKS says the following entry:
 ---
        hack    gcc-4.8.1
        cdate   Wed Nov  6 20:41:35 EST 2013
        who     christos
        file    src/external/gpl3/gcc/libstdc++-v3/Makefile : 1.6
        descr
                compile hashtable_c++0x.cc with -O2 instead of -Os to
                produce missing instantiation of std::lower_bound expansion
                for unsigned long.
        kcah
 ---
 but I can't find what's the hack.

- I'm trying whole build.sh release with gcc 4.8.3 and
  "-O2 -fno-reorder-blocks" but it looks more tweaks are needed
  around libgcc_s:
---
#     build  libgcc_s/libgcc_s.so.1.0
rm -f libgcc_s.so.1.0
/usr/local/src/obj.hp300/tooldir.Linux-2.6.32-042stab079.5-i686/bin/m68k--netbsdelf-gcc
 -nodefaultlibs -Wl,-x -shared -Wl,-soname,libgcc_s.so.1 
-Wl,--warn-shared-textrel -Wl,-Map=libgcc_s.so.1.map   
--sysroot=/usr/local/src/obj.hp300/destdir.hp300 -nodefaultlibs 
-Wl,--version-script=/usr/local/src/external/gpl3/gcc/lib/libgcc/libgcc_s/obj.hp300/libgcc.map
  -o libgcc_s.so.1.0  -Wl,-rpath,/lib  -L=/lib  -Wl,--whole-archive 
libgcc_s_pic.a  -Wl,--no-whole-archive  
libgcc_s_pic.a(_float.pico):(.text+0x8): relocation truncated to fit: 
R_68K_PC16 against symbol `$_exception_handler' defined in .text section in 
libgcc_s_pic.a(_floatex.pico)
libgcc_s_pic.a(_float.pico):(.text+0x18): relocation truncated to fit: 
R_68K_PC16 against symbol `$_exception_handler' defined in .text section in 
libgcc_s_pic.a(_floatex.pico)
libgcc_s_pic.a(_float.pico):(.text+0x22): relocation truncated to fit: 
R_68K_PC16 against symbol `$_exception_handler' defined in .text section in 
libgcc_s_pic.a(_floatex.pico)
libgcc_s_pic.a(_float.pico):(.text+0x2c): relocation truncated to fit: 
R_68K_PC16 against symbol `$_exception_handler' defined in .text section in 
libgcc_s_pic.a(_floatex.pico)
libgcc_s_pic.a(_float.pico):(.text+0x3c): relocation truncated to fit: 
R_68K_PC16 against symbol `$_exception_handler' defined in .text section in 
libgcc_s_pic.a(_floatex.pico)
/usr/local/src/obj.hp300/tooldir.Linux-2.6.32-042stab079.5-i686/lib/gcc/m68k--netbsdelf/4.8.3/../../../../m68k--netbsdelf/bin/ld:
 warning: creating a DT_TEXTREL in a shared object.
collect2: error: ld returned 1 exit status

*** Failed target:  libgcc_s.so.1.0
---
 I have not checked why this doesn't happen with -Os.

etc.

---
Izumi Tsutsui