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

Re: Interesting - [drow@mvista.com: Re: A user's experiences with GCC-3.4 snapshots]

Thread Previous | Thread Next
From:
Marcus Holland-Moritz
Date:
September 16, 2003 17:03
Subject:
Re: Interesting - [drow@mvista.com: Re: A user's experiences with GCC-3.4 snapshots]
Message ID:
00f401c37caf$13812e60$0c2f1fac@R2D2
> Daniel Jacobowitz <drow@mvista.com>:
> > To: Art Haas <ahaas@airmail.net>
> > Cc: gcc@gcc.gnu.org
> > Subject: Re: A user's experiences with GCC-3.4 snapshots
> > Message-ID: <20030916194819.GA11060@nevyn.them.org>
> > Mail-Followup-To: Art Haas <ahaas@airmail.net>, gcc@gcc.gnu.org
> > References: <20030916193158.GB1420@artsapartment.org>
> > Mime-Version: 1.0
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> > In-Reply-To: <20030916193158.GB1420@artsapartment.org>
> > User-Agent: Mutt/1.5.1i
> > 
> > On Tue, Sep 16, 2003 at 02:31:58PM -0500, Art Haas wrote:
> > > $ cat try.c
> > > #include <stdio.h>
> > > int main() { extern void *setproctitle(); if(&setproctitle) return(0); else return(1); }
> > 
> > This is not a valid way to test the existence of a function, and GCC is
> > correct.  You are declaring that there is an external symbol named
> > setproctitle, and asking for its address.  The C standard guarantees
> > that the address of a function will never compare equal to NULL.
> > 
> > So Perl needs to be fixed.
> 
> I thought the idea of this sort of test was that if there is no
> setproctitle, the attempt to link the 'try' program will fail; the
> 'if' test isn't important, and the program, if it compiles and links,
> will always return 0.
> 
> If I understand correctly, gcc-3.4 is smart enough to optimize out the
> reference to 'setproctitle', so the resulting .o file doesn't refer to
> 'setproctitle', and the linker always succeeds.  If that's what's

This also seems to be the case with Intel's ICC compiler. I recently
tried to build perl with ICC and the Configure run was just a mess.
I reported this to Intel support, because IMHO it should be a linker
error if a symbol cannot be resolved. (And interestingly it is when
the same code is compiled as C++... :-)

> going on, then something like this should be enough to defeat the
> optimization and fix the problem:
> 
> #include <stdio.h>
> int main() { extern void *setproctitle(); if(setproctitle == main) return(0); else return(1); }

Almost any modification of the condition forces a linker error with
ICC, e.g.:

  int main() { extern void *setproctitle(); if(&setproctitle+0) return(0); else return(1); }

or

  int main() { extern void *setproctitle(); if((int)&setproctitle) return(0); else return(1); }

-- Marcus


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