Name Date Size #Lines LOC

..--

dist/H--6,772,7355,215,679

lib/H--215,32784,417

usr.bin/H--261,652174,954

MakefileH A D20-Feb-2023134 83

Makefile.gcc_pathH A D20-Feb-2023406 197

Makefile.hooksH A D20-Feb-2023841 2919

README.gcc10H A D20-Feb-20233.5 KiB120100

README.warningsH A D14-Jul-20234 KiB13383

README.gcc10

1$NetBSD: README.gcc10,v 1.2 2023/02/20 02:11:03 mrg Exp $
2
3
4new stuff:
5	libmpx
6	liboffloadmic
7	libvtv
8	libcet
9	libphobos
10	d
11	gfortran
12	libbacktrace: +dwarf5_CFLAGS = $(libbacktrace_TEST_CFLAGS) -gdwarf-5
13
14
15todo:
16	- audit all uses of new warning-disable variables and
17	  convert some from -Wno- to -Wno-error=
18
19arch/feature list.
20
21tools:		does build.sh tools work?
22kernels:	does a kernel run?  y (yes), b (builds/ready), ? (not ready)
23libgcc:		does libgcc build?
24native-gcc:	does a full mknative-gcc complete?
25make release:	does build.sh release complete?
26runs:		does the system boot with a full world?
27atf:		does atf run / compare well
28switched:	has port switched?  y (yes), n (no/ready), ? (not ready)
29
30
31architecture	tools	kernels	libgcc	native-gcc	make release	runs	atf	switched
32------------	-----	-------	------	----------	------------	----	---	--------
33aarch64		y	y	y	y		y		y	y	y
34aarch64eb	y	y	y	y		y		y	y	y
35alpha		y	y	y	y		y		y	y	y
36earmv4		y	y	y	y		y		y	?	y
37earmv4eb	y	b	y	y		y		?	?	y
38earmv5		y	b	y	y		y		y	y	y
39earmv5eb	y	b	y	y		y		?	?	y
40earmv5hf	y	y	y	y		y		?	?	y
41earmv5hfeb	y	b	y	y		y		?	?	y
42earmv6		y	b	y	y		y		y	y	y
43earmv6eb	y	b	y	y		y		y	y	y
44earmv6hf	y	y	y	y		y		y	y	y
45earmv6hfeb	y	y	y	y		y		y	y	y
46earmv7		y	b	y	y		y		y	y	y
47earmv7eb	y	b	y	y		y		y	y	y
48earmv7hf	y	y	y	y		y		y	y	y
49earmv7hfeb	y	y	y	y		y		y	y	y
50hppa		y	y	y	y		y		y	y	y
51i386		y	y	y	y		y		y	n[8]	y
52ia64		y	y	y	y		y		?	N/A	y
53m68000		y	b	y	y		y		n[1]	?	y
54m68k		y	y	y	y		y		y	?	y
55mipseb		y	y	y	y		y		y	?	y
56mipsel		y	y	y	y		y		y	?	y
57mips64eb	y	y	y	y		y		y	y	y
58mips64el	y	b	y	y		y		y	?	y
59powerpc		y	b	y	y		y		y	y	y
60powerpc64	y	b	y	y		y		N/A	N/A	y
61sh3eb		y	b	y	y		y		?[2]	?	y
62sh3el		y	y	y	y		y		y	y[7]	y
63sparc		y	y	y	y		y		y	y	y
64sparc64		y	y	y	y		y		y	y	y
65vax		y	y	y	y		y		y	n[6]	y
66x86_64		y	y	y	y		y		y	y	y
67riscv32		y	N/A	y	y		y		N/A	N/A	y
68riscv64		y	N/A	y	y		y		N/A	N/A	y
69--
70coldfire	?	N/A	?	?		?		N/A	N/A
71------------	-----	-------	------	----------	------------	----	---
72architecture	tools	kernels	libgcc	native-gcc	make release	runs	atf
73
74[1] - kernel may be too large, does not boot.  GCC 9 is the same, though.
75[2] - failed to find any sh3-eb systems to test.
76[6] - vax vs c++ exceptions issue, same as it ever was
77[7] - fails just as poorly in gxemul/landisk as GCC 9
78[8] - i386 seems to have a signal delivery issue.  pthread tests hang and then
79      complain with eg:
80	  threads_and_exec: q[ 627.6700846] sorry, pid 3154 was killed: orphaned traced process
81      this problem occurs with GCC 9 as well.  works in qemu?
82
83
84CPU vs platform test table (for CPUs with multiple ports).  this is "make release" or just kernels.
85values:		y (yes), k (kernels only), n (failed), r (running), ? (not attempted), nx (yes, no x11)
86
87CPU		platform list
88---		-------- ----
89		acorn32		cats	epoc32	evbarm-eb	evbarm-el	hpcarm		iyonix		netwinder	shark 		zaurus
90earmv4:		y		y	y	y		y		y		 		y		y
91earm:		 		 	 	y		y		 		y		 		 		y
92earmhf:		 		 	 	y		y
93earmv6:		 		 	 	y		y
94earmv6hf:	 		 	 	y		y
95earmv7:		 		 	 	y		y
96earmv7hf:	 		 	 	y		y
97
98		amiga		atari	cesfic	hp300		luna68k		mac68k		mvme68k		news68k		next68k		sun3	x68k
99m68k:		y		y	y	y		y		y		y		y		y		y 	y
100
101		evbmips		emips		ews4800mips	mipsco		newsmips	sgimips
102mipseb:		y		y		y		y		y		y
103
104		evbmips		algor		arc		cobalt		hpcmips		pmax
105mipsel:		y		y		y		y		y		y
106
107		algor		evbmips		pmax
108mips64eb:	 		y
109mips64el:	y		y		y
110
111		amigappc	bebox	evbppc	ibmnws		macppc		mvmeppc		ofppc		prep		rs6000		sandpoint
112powerpc:	y		y	y	y		y		y		y		y		y		y
113
114		evbppc		macppc		ofppc
115powerpc64:	y		y		y
116
117		dreamcast	evbsh3		hpcsh		landisk		mmeye
118sh3eb:		 		y		 		 		y
119sh3el:		y		y		y		y
120

README.warnings

1$NetBSD: README.warnings,v 1.5 2023/07/14 19:46:25 mrg Exp $
2
3What to do about GCC warnings and NetBSD.
4
5
6New GCC releases always come with a host of new warnings and
7each new warning can find real bugs, find odd code, or simply
8be a pain of new useless warnings, or all three and more.
9
10As each warning has its own set of issues they each have their
11own section and it is expected that this document will be
12modified for updates to warnings and new warnings.
13
14
15<bsd.own.mk> provides several variables for use in Makefiles:
16   COPTS.foo.c += ${CC_WNO_FORMAT_TRUNCATION}
17   COPTS.foo.c += ${CC_WNO_FORMAT_OVERFLOW}
18   COPTS.foo.c += ${CC_WNO_STRINGOP_OVERFLOW}
19   COPTS.foo.c += ${CC_WNO_STRINGOP_TRUNCATION}
20   COPTS.foo.c += ${CC_WNO_CAST_FUNCTION_TYPE}
21   COPTS.foo.c += ${CC_WNO_IMPLICIT_FALLTHROUGH}
22   COPTS.foo.c += ${CC_WNO_ADDRESS_OF_PACKED_MEMBER}
23   COPTS.foo.c += ${CC_WNO_MAYBE_UNINITIALIZED}
24   COPTS.foo.c += ${CC_WNO_RETURN_LOCAL_ADDR}
25
26
27new GCC 10 warnings:
28
29  GCC 10 switched the default from "-fcommon" to "-fno-common",
30  which can cause multiply defined symbol issues.  Ideally we
31  fix all of these, but "-fcommon" can be used otherwise.
32
33  -Wno-maybe-uninitialized
34
35      This warning was introduced in an ancient GCC but was
36      significantly enhanced in GCC 10, unfortunately, many of
37      the new instances are incorrect.
38
39      bsd.own.mk variable: ${CC_WNO_MAYBE_UNINITIALIZED}
40
41  -Wno-return-local-addr
42
43      This warning was introduced in GCC 5 and was enhanced in GCC
44      10.  Unfortunately, the new instances are failing to correctly
45      analyze code flow and miss that most of the are handled.
46
47      bsd.own.mk variable: ${CC_WNO_RETURN_LOCAL_ADDR}
48
49
50new GCC 9 warnings:
51
52  -Wno-address-of-packed-member
53
54      This warning was introduced in GCC 8.
55      This warning is similar to -Wformat-truncation, but for the
56      general family of string functions (str*(), etc.), and has
57      similar issues of false positives.
58
59      bsd.own.mk variable: ${CC_WNO_ADDRESS_OF_PACKED_MEMBER}
60
61
62new GCC 8 warnings:
63
64  -Wstringop-truncation
65
66      This warning was introduced in GCC 8.
67      This warning is similar to -Wformat-truncation, but for the
68      general family of string functions (str*(), etc.), and has
69      similar issues of false positives.
70
71      bsd.own.mk variable: ${CC_WNO_STRINGOP_TRUNCATION}
72
73
74  -Wcast-function-type
75
76      This warning was introduced in GCC 8.
77      This warning can find real problems.  Most instances are
78      false positives, and hopefully this warning will become
79      more useful in the future.  See __FPTRCAST().
80
81      bsd.own.mk variable: ${CC_WNO_CAST_FUNCTION_TYPE}
82
83
84new GCC 7 warnings:
85
86  -Wstringop-overflow
87
88      This warning was introduced in GCC 7.
89      This warning can find issues where source length is
90      passed as destination length (eg, strncpy() where the
91      length is strlen(src)) that are potential buffer overflow
92      cases and should always be inspected, but false positives
93      are also seen.
94
95      bsd.own.mk variable: ${CC_WNO_STRINGOP_OVERFLOW}
96
97
98  -Wformat-truncation
99
100    This warning was introduced in GCC 7.
101    This warning has many false positives where truncation is
102    either expected or unavoidable, but also finds several real
103    code bugs.
104
105    Code should always be manually inspected for this warning
106    as it does pick up real issues.
107
108    bsd.own.mk variable: ${CC_WNO_FORMAT_TRUNCATION}
109
110
111  -Wformat-overflow
112
113    This warning was introduced in GCC 7.
114    This warning typically identifies a real problem, but it may
115    fail to notice the code handles this case.
116
117    Code should always be manually inspected for this warning
118    as it does pick up real issues.
119
120    bsd.own.mk variable: ${CC_WNO_FORMAT_OVERFLOW}
121
122
123  -Wimplicit-fallthrough
124
125    This warning was introduced in GCC 7.
126    This warning has many false positives in GCC 7, and many are
127    fixed in newer GCC 10.  Old uses should be checked occasionally.
128
129    Code should always be manually inspected for this warning
130    as it does pick up real issues.
131
132    bsd.own.mk variable: ${CC_WNO_IMPLICIT_FALLTHROUGH}
133