Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Mar 2018 16:03:44 +0100
From:      Dimitry Andric <dim@FreeBSD.org>
To:        Ian FREISLICH <ian.freislich@capeaugusta.com>
Cc:        current <current@freebsd.org>
Subject:   Re: Clang-6 and GNUisms.
Message-ID:  <E03C5179-E64D-4491-B30F-9BA02A048361@FreeBSD.org>
In-Reply-To: <4ea06b48-d451-f2b3-4c20-4963f829333b@capeaugusta.com>
References:  <4ea06b48-d451-f2b3-4c20-4963f829333b@capeaugusta.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--Apple-Mail=_081480D5-A9BF-4C44-BDA0-3AE8472A949B
Content-Type: multipart/mixed;
	boundary="Apple-Mail=_003D66FC-E7F2-4BDA-A929-8668F2F7EF5E"


--Apple-Mail=_003D66FC-E7F2-4BDA-A929-8668F2F7EF5E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On 12 Mar 2018, at 00:56, Ian FREISLICH <ian.freislich@capeaugusta.com> =
wrote:
>=20
> There's been some fallout in ports land since clang-6 around null
> pointer arithmetic and casts.  I cannot think of a good reason for =
doing
> the following but then I've not dabbled in the arcane much:
>=20
> # define __INT_TO_PTR(P) ((P) + (char *) 0)

The idea of this construct is to store integers in pointers, and vice
versa.  This could also be done with unions, but those have their own
portability issues.

However, arithmetic on a null pointer is undefined according to the C
and C++ standards, though this particular use case is a GNU extension.

It would be safer and more portable to use intptr_t (or a custom integer
type that is exactly as large as a pointer), then cast the pointer to
that type, and vice versa.

E.g.:

#define __INT_TO_PTR(i) ((char *)(intptr_t)(i))
#define __PTR_TO_INT(p) ((intptr_t)(char *)(p))

That said, -Wno-null-pointer-arithmetic can of course be used to
suppress the warnings, but unfortunately this not only applies to the
GNU extension, but also to real undefined behavior.


> So far I've encountered these in lang/v8 and devel/avr-gcc.  I know it
> just generates warnings, but GNUisms and -Werror abound.  Adding
> -Wno-null-pointer-arithmetic and -Wno-vexing-parse to CFLAGS/CXXFLAGS
> provides some relief but V8 still fails:
>=20
> =
/usr/ports/lang/v8/work/v8-3.18.5/out/native/obj.target/v8_base.x64/src/ty=
pe-info.o../src/stub-cache.cc:1477:33:
> error: reinterpret_cast from 'nullptr_t' to 'char *' is not allowed
>       : GetCodeWithFlags(flags, reinterpret_cast<char*>(NULL));
>=20
>                                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In this case, the casting is unnecessary, and can simply be removed.

The "vexing parse" warning is caused by unnecessary (and confusing)
parentheses, which can also be removed.

See the attached patch, which fixes both issues, and suppresses the
null pointer arithmetic warnings.


> I haven't got avr-gcc to compile yet.

No idea about this, is it very different from regular gcc's?  As those
all compile fine now.

-Dimitry

--Apple-Mail=_003D66FC-E7F2-4BDA-A929-8668F2F7EF5E
Content-Disposition: attachment;
	filename=lang__v8-fix-clang6-build-1.diff
Content-Type: application/octet-stream;
	x-unix-mode=0644;
	name="lang__v8-fix-clang6-build-1.diff"
Content-Transfer-Encoding: 7bit

Index: lang/v8/Makefile
===================================================================
--- lang/v8/Makefile	(revision 463967)
+++ lang/v8/Makefile	(working copy)
@@ -39,9 +39,12 @@ CXXFLAGS+=	-Wno-unused-const-variable
 CXXFLAGS+=	-Wno-tautological-undefined-compare
 .if ${COMPILER_VERSION} >= 36
 CXXFLAGS+=	-Wno-unused-local-typedef
+.if ${COMPILER_VERSION} >= 60
+CXXFLAGS+=	-Wno-null-pointer-arithmetic
 .endif
 .endif
 .endif
+.endif
 .else
 MAKE_ARGS+=	strictaliasing=off
 USE_GCC=	any
Index: lang/v8/files/patch-src_objects.cc
===================================================================
--- lang/v8/files/patch-src_objects.cc	(nonexistent)
+++ lang/v8/files/patch-src_objects.cc	(working copy)
@@ -0,0 +1,11 @@
+--- src/objects.cc.orig	2013-05-01 12:56:29 UTC
++++ src/objects.cc
+@@ -2494,7 +2494,7 @@ MaybeObject* Map::GeneralizeRepresentation(int modify_
+       // Create a handle for the last created map to ensure it stays alive
+       // during GC. Its descriptor array is too large, but it will be
+       // overwritten during retry anyway.
+-      Handle<Map>(new_map);
++      Handle<Map> new_map;
+     }
+   }
+ 

Property changes on: lang/v8/files/patch-src_objects.cc
___________________________________________________________________
Added: fbsd:nokeywords
## -0,0 +1 ##
+yes
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at end of property
Index: lang/v8/files/patch-src_stub-cache.cc
===================================================================
--- lang/v8/files/patch-src_stub-cache.cc	(nonexistent)
+++ lang/v8/files/patch-src_stub-cache.cc	(working copy)
@@ -0,0 +1,11 @@
+--- src/stub-cache.cc.orig	2013-05-01 12:56:29 UTC
++++ src/stub-cache.cc
+@@ -1474,7 +1474,7 @@ Handle<Code> StubCompiler::GetCodeWithFlags(Code::Flag
+                                             Handle<Name> name) {
+   return (FLAG_print_code_stubs && !name.is_null() && name->IsString())
+       ? GetCodeWithFlags(flags, *Handle<String>::cast(name)->ToCString())
+-      : GetCodeWithFlags(flags, reinterpret_cast<char*>(NULL));
++      : GetCodeWithFlags(flags, NULL);
+ }
+ 
+ 

Property changes on: lang/v8/files/patch-src_stub-cache.cc
___________________________________________________________________
Added: fbsd:nokeywords
## -0,0 +1 ##
+yes
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at end of property

--Apple-Mail=_003D66FC-E7F2-4BDA-A929-8668F2F7EF5E--

--Apple-Mail=_081480D5-A9BF-4C44-BDA0-3AE8472A949B
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.2

iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWqaW0AAKCRCwXqMKLiCW
oytmAKDIGxXtHUFyekASpDcUCQ0d6emitgCfQPQRDR68zzJMqNUYPOeyntRgHh4=
=buKI
-----END PGP SIGNATURE-----

--Apple-Mail=_081480D5-A9BF-4C44-BDA0-3AE8472A949B--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E03C5179-E64D-4491-B30F-9BA02A048361>