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
-
[perl #133495] perl-5.28.0 fails to build on Solaris 10
by Fabian Groffen via RT