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

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

From:
Fabian Groffen via RT
Date:
January 30, 2019 02:18
Subject:
[perl #133495] perl-5.28.0 fails to build on Solaris 10
Message ID:
rt-4.0.24-18276-1548758063-415.133495-15-0@perl.org
On Mon, 21 Jan 2019 01:26:47 -0800, grobian@gentoo.org 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?
> 
> The results are the same, unfortunately.

I've replaced, however, the stack allocated buf with a simple

 buf = malloc(sizeof(U8) * 8);

and now gcc-8.2 returns 4 with -O2, but -O3 still is too clever and returning 0.  So I decided to complicate matters a bit more by getting the buffer offset no longer statically known:

 data = malloc(sizeof(U8) * 32);
 bte = rand() % 24;
 buf = data + bte;

I chose rand because it lives in stdlib.h, but I'm aware this might be a porting problem.  Alternative would be time, or parsing argv[1], just to ensure the compiler doesn't know what the offset is going to be.  With this change gcc-8.2 -O3 returns 4, as the test expects.

Fabian

> > > 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.
> 
> It seems you're correct about that (code from original test):
> 
> /usr/sfw/bin/gcc -O3 -> 4
> gcc-6.4.0 -O3 -> 0
> gcc-7.3.0 -O3 -> 0
> gcc-8.2.0 -O3 -> 0
> /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
> 
> Fabian



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



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