develooper Front page | perl.perl5.porters | Postings from August 2018

Re: Issues cross-building Perl for apm821xx (flavor of ppc 464fp)

Thread Previous | Thread Next
From:
Tony Cook
Date:
August 1, 2018 00:23
Subject:
Re: Issues cross-building Perl for apm821xx (flavor of ppc 464fp)
Message ID:
20180801002259.iyw4k6h7rh3e6z52@mars.tony.develop-help.com
On Tue, Jul 31, 2018 at 05:32:19PM -0600, Philip Prindeville wrote:
> Hi.
> 
> I’m just now getting eyes on this bug report downstream:
> 
> https://bugs.openwrt.org/index.php?do=details&task_id=1464
> 
> where it’s said that the additional CFLAGS "-fwrapv -fno-strict-aliasing” are required to get Perl5 to not SEGV.
> 
> This is easy enough to reproduce.
> 
> I’m thinking that it’s odd that all other packages build without these flags, but somehow only Perl fails.
> 
> The gcc 7.3 manual says:
> 
> -fwrapv
> 
> This option instructs the compiler to assume that signed arithmetic overflow of addition, subtraction and multiplication wraps around using twos-complement representation. This flag enables some optimizations and disables others.
> 
> Isn’t that the default model of the underlying machine for the C language?

The C language says (C11 6.5 p3):

 If an exceptional condition occurs during the evaluation of an expression (that is, if the
 result is not mathematically defined or not in the range of representable values for its
 type), the behavior is undefined.

Unsigned types are an exception to that (C11 6.2.5 p9):

 The range of nonnegative values of a signed integer type is a subrange of the
 corresponding unsigned integer type, and the representation of the same value in each
 type is the same.41) A computation involving unsigned operands can never overflow,
 because a result that cannot be represented by the resulting unsigned integer type is
 reduced modulo the number that is one greater than the largest value that can be
 represented by the resulting type.

The -fwrapv ensures the compiler assumes that overflow with signed
integers wraps using 2's complement representation, which historically
the perl implementation has depended on.

Ideally we'd remove such dependencies (which in some cases are just
cases whether the author hasn't considered overflow), but there's only
so much effort put into perl.

> Anyone seen anything remotely similar?

Not that I recall.

Tony

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About