summaryrefslogtreecommitdiffhomepage
path: root/auto/cc/test (follow)
AgeCommit message (Collapse)AuthorFilesLines
2024-03-09Compile with -fno-strict-overflowAndrew Clayton1-0/+4
This causes signed integer & pointer overflow to have a defined behaviour of wrapping according to two's compliment. I.e INT_MAX will wrap to INT_MIN and vice versa. This is mainly to cover existing cases, not an invitation to add more. Cc: Dan Callahan <d.callahan@f5.com> Suggested-by: Alejandro Colomar <alx@kernel.org> Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Disable strict-aliasing in clang by defaultAndrew Clayton1-2/+4
Aliasing is essentially when you access the same memory via different types. If the compiler knows this doesn't happen it can make some optimisations. There is however code in Unit, for example in the wasm language module and the websocket code that may fall foul of strict-aliasing rules. (For the wasm module I explicitly disable it there) In auto/cc/test for GCC we have NXT_CFLAGS="$NXT_CFLAGS -O" ... # -O2 enables -fstrict-aliasing and -fstrict-overflow. #NXT_CFLAGS="$NXT_CFLAGS -O2" #NXT_CFLAGS="$NXT_CFLAGS -Wno-strict-aliasing" So with GCC by default we effectively compile with -fno-strict-aliasing. For clang we have this NXT_CFLAGS="$NXT_CFLAGS -O" ... #NXT_CFLAGS="$NXT_CFLAGS -O2" ... NXT_CFLAGS="$NXT_CFLAGS -fstrict-aliasing" (In _clang_, -fstrict-aliasing is always enabled by default) So in clang we always build with -fstrict-aliasing. I don't think this is the best idea, building with something as fundamental as this disabled in one compiler and enabled in another. This patch adjusts the Clang side of things to match that of GCC. I.e compile with -fno-strict-aliasing. It also explicitly sets -fno-strict-aliasing for GCC, which is what we were getting anyway but lets be explicit about it. Cc: Dan Callahan <d.callahan@f5.com> Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Expand the comment about -Wstrict-overflow on GCCAndrew Clayton1-1/+3
Expand on the comment on why we don't enable -Wstrict-overflow=5 on GCC. Link: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96658> Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Remove -W from compiler flagsAndrew Clayton1-2/+2
This is what -Wextra used to be called, but any version of GCC or Clang in at least the last decade has -Wextra. Cc: Dan Callahan <d.callahan@f5.com> Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Remove support for Sun's Sun Studio/SunPro C compilerAndrew Clayton1-21/+0
We really only support building Unit with GCC and Clang. Cc: Dan Callahan <d.callahan@f5.com> Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Remove support for IBM's XL C compilerAndrew Clayton1-24/+0
We really only support building Unit with GCC and Clang. Cc: Dan Callahan <d.callahan@f5.com> Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Remove support for Intel's icc compilerAndrew Clayton1-11/+0
We only really support building Unit with GCC and Clang. Cc: Dan Callahan <d.callahan@f5.com> Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-09Remove support for Microsoft's Visual C++ compilerAndrew Clayton1-12/+0
We don't run on Windows and only really support compiling Unit with GCC and Clang. Cc: Dan Callahan <d.callahan@f5.com> Co-developed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2017-01-17Initial version.Igor Sysoev1-0/+209