[src/trunk]: src/external/gpl3/gcc update for more reality.

[mrg <mrg%NetBSD.org@localhost>]

details:   https://anonhg.NetBSD.org/src/rev/189243360d1b
branches:  trunk
changeset: 335505:189243360d1b
user:      mrg <mrg%NetBSD.org@localhost>
date:      Sat Jan 10 22:58:38 2015 +0000

description:
update for more reality.

diffstat:

 external/gpl3/gcc/README.gcc48 |  15 +++------------
 1 files changed, 3 insertions(+), 12 deletions(-)

diffs (39 lines):

diff -r fcca307a5f68 -r 189243360d1b external/gpl3/gcc/README.gcc48
--- a/external/gpl3/gcc/README.gcc48    Sat Jan 10 22:19:26 2015 +0000
+++ b/external/gpl3/gcc/README.gcc48    Sat Jan 10 22:58:38 2015 +0000
@@ -1,4 +1,4 @@
-$Id: README.gcc48,v 1.5 2014/07/28 22:12:16 mrg Exp $
+$Id: README.gcc48,v 1.6 2015/01/10 22:58:38 mrg Exp $
 
 usr.bin:
        note:
@@ -16,8 +16,6 @@
 
        - what is libitm?
 
-       - asan/libsanitizer
-
 x86_64 port:
 - copied manually i386-builtin-types.inc instead of generating it.
 
@@ -26,18 +24,11 @@
 
 architecture   tools   kernels libgcc  native-gcc      make release    runs    atf
 ------------   -----   ------- ------  ----------      ------------    ----    ---
-coldfire       yes     N/A[9]  yes     yes             yes[7]          ?       ?
+coldfire       yes     N/A[9]  yes     yes             yes             ?       ?
 m68000         yes     ?       yes     no[3]           
-m68k           yes     yes     yes     yes             no[7]
-powerpc                yes     yes[1]  yes     yes             yes             yes     yes
+m68k           yes     yes     yes     yes             yes
 powerpc64      yes[4]
 
-[1] ofppc/pegasos has issues with symtab loading.
-    sandpoint works fine in multi-user, found an annoyance by com(4) change.
 [3] relocations fail in libgcc
 [4] cc1 gets segv compiling libgcc.
-[7] m68k/vax/sh3 gcc seem to randomly get -fstack-protector/-Wstack-protector
-    wrong, for example m68k flags alarm() as unprotected in
-    libc/gen/alarm.c:53, vax ifinit() in sbin/routed/if.c:680.
-   --> hacked around, now fixed?
 [9] no kernels in evbcf port yet