develooper Front page | perl.perl5.porters | Postings from September 2019

[perl #133495] perl-5.28.0 fails to build on Solaris 10

Thread Previous
From:
Karl Williamson via RT
Date:
September 7, 2019 19:57
Subject:
[perl #133495] perl-5.28.0 fails to build on Solaris 10
Message ID:
rt-4.0.24-6119-1567886244-868.133495-15-0@perl.org
On Wed, 04 Sep 2019 22:12:06 -0700, mattst88@gmail.com wrote:
> On Thu, 17 Jan 2019 07:36:42 -0800, LeonT wrote:
> > On Thu, Jan 17, 2019 at 9:26 AM Fabian Groffen via RT
> > <perlbug-followup@perl.org> wrote:
> > > I think that the GCC compiler is actually doing "too smart" things
> > > here when optimisations are enabled.
> > >
> > > /usr/sfw/bin/gcc -O2 -> 4
> > > gcc-6.4.0 -O2 -> 4
> > > gcc-7.3.0 -O2 -> 4
> > > gcc-8.2.0 -O2 -> 0
> > > /usr/sfw/bin/gcc -g -> 4
> > > gcc-6.4.0 -g -> 4
> > > gcc-7.3.0 -g -> 4
> > > gcc-8.2.0 -g -> 4
> > >
> > > Behaviour seems to be pretty much limited to gcc-8.2 while
> > > optimising
> > > at the moment.
> >
> > Yeah. I guess that means we need a better test that confuses the
> > compiler a little bit more. One would expect volatile to take care of
> > that but apparently not; The C standard is notoriously fuzzy on
> > volatiles (C99 6.7.6).
> >
> > What happens if you put the array outside the function?
> >
> > > Yes, including the fact that at the time I compiled 5.26.2, I used
> > > GCC-7.3, which produced the correct result for the unaligned check.
> > >
> > > This makes me wonder what the problem of OP is, though.  His env
> > > seems to suggest using GCC-4.9, which I don't have anymore for
> > > verification of the results.
> >
> > They did use -O3, so I guess that always enabled that optimization.
> >
> > Leon
> 
> 
> We filed a GCC bug upstream
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91197). They closed as
> INVALID because the C code in the test is provoking undefined
> behavior. Namely, that it is accessing data through an unaligned
> pointer. So GCC is within its rights to do what it is doing,
> frustratingly so.
> 
> See https://stackoverflow.com/questions/46790550/c-undefined-behavior-
> strict-aliasing-rule-or-incorrect-alignment for citations in the C11
> spec for the claim that accessing data through unaligned pointers is
> undefined behavior.
> 
> Digging into the code more, it's not just that the test in Configure
> provokes undefined behavior, but actually that the code it enables (in
> the little-endian && unaligned-ok paths) is potentially provoking
> undefined behavior. For example, in cpan/Digest-MD5/MD5.xs where buf
> is const U8* buf:
> 
> #ifndef U32_ALIGNMENT_REQUIRED
>     const U32 *x = (U32*)buf;  /* really just type casting */
> #endif
> 
> Throughout the code base it looks like we go out of our way to
> optimize byte swaps and hit the little-endian && unaligned-ok path if
> possible, but I don't think that's necessary at all. Comments like
> "Without a known fast bswap32 we're just as well off doing this"
> followed by an open-coded shift and OR implementation of bswap
> indicate to me that the authors didn't realize that compilers can
> easily recognize this pattern (or wrote the code when they couldn't).
> Regardless, today compilers can easily see through this and generate a
> bswap/movbe instruction on x86. And in fact, it's not clear to me that
> even using GCC __builtin_bswap* is better or worse than the open-coded
> implementations (see
> https://gitlab.freedesktop.org/xorg/xserver/merge_requests/176)
> 
> Similarly, while what the C code is doing in accessing unaligned
> pointers is undefined behavior, x86 instruction certainly can do that.
> But again, the compiler is perfectly capable of making that decision
> on its own.
> 
> So, I propose that we just cut all of that code out and use what is
> currently the alignment-required path today.
> 
> Please review the attached patches. I have never contributed to Perl
> before, and I stepped on quite a few landmines during the development
> of these patches (md5sum of MD5.xs goes in the test case; make regen;
> BYTEORDER is 0x1234 vs 0x12345678), so some help getting the patches
> in would be extremely appreciated.
> 
> Passes the perl test suite when applied to 5.30.0 on Gentoo/Linux on
> amd64, 32-bit userland sparc, and 64-bit userland sparc.

This did not make it to perl5-porters yet.  I'm replying to it to see if that thaws it.
-- 
Karl Williamson

---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=133495

Thread Previous


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