develooper Front page | perl.perl5.porters | Postings from May 2015

Re: [perl #125096] perl 5.20.2 fails to compile with gcc 5.1.0-flto -O2

Thread Previous | Thread Next
From:
H.Merijn Brand
Date:
May 7, 2015 06:34
Subject:
Re: [perl #125096] perl 5.20.2 fails to compile with gcc 5.1.0-flto -O2
Message ID:
20150507083426.2ad15a92@pc09.procura.nl
On Wed, 6 May 2015 17:49:27 -0700, "Tony Cook via RT"
<perlbug-followup@perl.org> wrote:

> On Mon May 04 03:02:16 2015, steffen@hauihau.de wrote:
> > Compiling perl 5.20.2 with GCC 5.1.0 reintroduced the issue reported
> > in bug #113022. I was told, that you should use "__attribute__
> > ((used))" to check for the availability of functions. This small patch
> > fixes the issue:
> > 
> > --- a/Configure.orig    2015-05-04 11:51:34.170517546 +0200
> > +++ b/Configure 2015-05-04 11:51:58.025516693 +0200
> > @@ -7954,13 +7954,13 @@
> >                 if $contains $tlook $tf >/dev/null 2>&1; then
> >                         tval=true;
> >                 elif $test "$mistrustnm" = compile -o "$mistrustnm" =
> > run; then
> > -                       echo "$extern_C void *$1$tdc; void
> > *(*(p()))$tdc { return &$1; } int main() { if(p() && p() != (void
> > *)main) return(0); else return(1); }"> try.c;
> > +                       echo "$extern_C void *$1$tdc; __attribute__
> > ((used)) void *(*(p()))$tdc { return &$1; } int main() { if(p() && p()
> > != (void *)main) return(0); else return(1); }"> try.c;
> >                         $cc -o try $optimize $ccflags $ldflags try.c
> > >/dev/null 2>&1 $libs && tval=true;
> >                         $test "$mistrustnm" = run -a -x try && { $run
> > ./try$_exe >/dev/null 2>&1 || tval=false; };
> >                         $rm_try;
> >                 fi;
> >         else
> > -               echo "$extern_C void *$1$tdc; void *(*(p()))$tdc {
> > return &$1; } int main() { if(p() && p() != (void *)main) return(0);
> > else return(1); }"> try.c;
> > +               echo "$extern_C void *$1$tdc; __attribute__ ((used))
> > void *(*(p()))$tdc { return &$1; } int main() { if(p() && p() != (void
> > *)main) return(0); else return(1); }"> try.c;
> >                 $cc -o try $optimize $ccflags $ldflags try.c $libs
> > >/dev/null 2>&1 && tval=true;
> >                 $rm_try;
> >         fi;
> 
> Not every compiler supports gcc's extensions, so we need to probe for
> __attribute__ ((used)) before we use it.
> 
> The attached patch is against bleadperl, detected __attribute__((used)), and if
> found uses it in the csym code.
> 
> If you want to test this againt 5.20 you should be able to copy Configure from blead and apply that patch to it, or copy Configure from:
> 
>  http://perl5.git.perl.org/perl.git/blob_plain/refs/heads/tonyc/attribute-used:/Configure
> 
> I couldn't reproduce the problem you were having however - with your options with gcc 5.1.0 malloc_size wasn't being detected (Debian oldstable.)
> 
> Tony

[ Not high priority, as this involves *A LOT* of work ]

There are plans to move the meta/dist framework towards a newer version
As perl has modified quite a lot of the underlying meta-units, this may
cause hundreds of units to change *and check* before such an
integration can be accepted.

That said, here's the feedback from the future :)

--8<---
The current dist (SVN version, not yet found the time / inclination
to migrate to git) has switched to compile-time tests whenever
possible since 2008.

In particular, the current intsize.U unit uses "static asserts"
to detect through compile-time errors whether an assertion holds.
This allows to compute the size of all types via compile tests,
without having to run anything.

Even IEEE float endianness is now determined without running a program.
No static assert here however: look at d_ieee754.U.

The rationale for moving out of run-tests is that it prevents
cross-compilation to occur.  But when you cross-compile, you
always have a compiler handy...  Since at some point I had to
cross-compile gtk-gnutella with MinGW, I had to move away from
run-tests as much as possible!
-->8---

As I do not have unlimited resources, and if I had they were to be
shared amongst several other areas of interest, this might take some
time to settle.

In summary, Yes, moving to compile-only is a good plan and certainly an
improvement once done, but I rather start from upriver and pick piece
by piece, giving feedback upriver so future differences stay low and
maintenance cost are not raised by every change.

-- 
H.Merijn Brand  http://tux.nl   Perl Monger  http://amsterdam.pm.org/
using perl5.00307 .. 5.21   porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/        http://www.test-smoke.org/
http://qa.perl.org   http://www.goldmark.org/jeff/stupid-disclaimers/

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