Skip Menu |
Report information
Id: 123831
Status: open
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: rehsack [at] gmail.com
Cc:
AdminCc:

Operating System: darwin
PatchStatus: (no value)
Severity: medium
Type: core
Perl Version: 5.20.1
Fixed In: (no value)



Subject: 5.21.8 fails compiling with icc
Date: Sat, 14 Feb 2015 12:05:31 +0100 (CET)
To: perlbug [...] perl.org
CC: rehsack [...] gmail.com
From: rehsack [...] gmail.com
Download (untitled) / with headers
text/plain 4.3k
This is a bug report for perl from rehsack@gmail.com, generated with the help of perlbug 1.40 running under perl 5.20.1. ----------------------------------------------------------------- [Please describe your issue here] To prove my XS code with additional compilers, I retry compiling dev-perl using icc. I hoped get improved results since 44b62df7 ... Unfortunately, I got: icc -c -DPERL_CORE -fno-common -DPERL_DARWIN -O3 util.c util.c(4556): warning #69: integer conversion resulted in truncation u += SEED_C5 * (U32)PTR2UV(&when); ^ icc -c -DPERL_CORE -fno-common -DPERL_DARWIN -O3 sv.c sv.c(3162): error: expression must be an integral constant expression SNPRINTF_G(SvNVX(sv), s, SvLEN(sv), NV_DIG); ^ sv.c(11300): error: expression must be an integral constant expression SNPRINTF_G(nv, ebuf, size, digits); ^ sv.c(12284): error: expression must be an integral constant expression SNPRINTF_G(fv, PL_efloatbuf, PL_efloatsize, precis); ^ compilation aborted for sv.c (code 2) [Please do not change anything below this line] ----------------------------------------------------------------- --- Flags: category=core severity=medium --- Site configuration information for perl 5.20.1: Configured by sno at Mon Dec 8 12:39:24 CET 2014. Summary of my perl5 (revision 5 version 20 subversion 1) configuration: Platform: osname=darwin, osvers=13.4.0, archname=darwin-2level uname='darwin ernie.muppets.liwing.de 13.4.0 darwin kernel version 13.4.0: sun aug 17 19:50:11 pdt 2014; root:xnu-2422.115.4~1release_x86_64 x86_64 ' config_args='-de -Dprefix=/Users/sno/perl5/perlbrew/perls/perl-5.20.1 -Aeval:scriptdir=/Users/sno/perl5/perlbrew/perls/perl-5.20.1/bin' hint=recommended, useposix=true, d_sigaction=define useithreads=undef, usemultiplicity=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe -fstack-protector', optimize='-O3', cppflags='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe -fstack-protector' ccversion='', gccversion='4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.56)', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' -fstack-protector' libpth=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0/lib /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib /usr/lib libs=-ldbm -ldl -lm -lutil -lc perllibs=-ldl -lm -lutil -lc libc=, so=dylib, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup -fstack-protector' --- @INC for perl 5.20.1: /Users/sno/perl5/perlbrew/perls/perl-5.20.1/lib/site_perl/5.20.1/darwin-2level /Users/sno/perl5/perlbrew/perls/perl-5.20.1/lib/site_perl/5.20.1 /Users/sno/perl5/perlbrew/perls/perl-5.20.1/lib/5.20.1/darwin-2level /Users/sno/perl5/perlbrew/perls/perl-5.20.1/lib/5.20.1 . --- Environment for perl 5.20.1: DYLD_LIBRARY_PATH (unset) HOME=/Users/sno LANG=de_DE.UTF-8 LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/Users/sno/perl5/perlbrew/bin:/Users/sno/perl5/perlbrew/perls/perl-5.20.1/bin:/Users/sno/bin:/opt/pkg/bin:/opt/pkg/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin PERLBREW_BASHRC_VERSION=0.54 PERLBREW_HOME=/Users/sno/.perlbrew PERLBREW_MANPATH=/Users/sno/perl5/perlbrew/perls/perl-5.20.1/man PERLBREW_PATH=/Users/sno/perl5/perlbrew/bin:/Users/sno/perl5/perlbrew/perls/perl-5.20.1/bin PERLBREW_PERL=perl-5.20.1 PERLBREW_ROOT=/Users/sno/perl5/perlbrew PERLBREW_VERSION=0.64 PERL_BADLANG (unset) SHELL=/bin/bash
From: Jens Rehsack <rehsack [...] gmail.com>
Date: Sat, 14 Feb 2015 12:40:12 +0100
To: perlbug-followup [...] perl.org
Subject: Re: [perl #123831] perlbug AutoReply: 5.21.8 fails compiling with icc
Download (untitled) / with headers
text/plain 2.6k
Following patch solves the issue locally: $ git diff diff --git a/perl.h b/perl.h index 9976f86..0b2dfa8 100644 --- a/perl.h +++ b/perl.h @@ -378,7 +378,7 @@ * __typeof__ and nothing else. */ #ifndef PERL_UNUSED_RESULT -# if defined(__GNUC__) && defined(HASATTRIBUTE_WARN_UNUSED_RESULT) +# if defined(__GNUC__) && !defined(__INTEL_COMPILER) && defined(HASATTRIBUTE_WARN_UNUSED_RESULT) # define PERL_UNUSED_RESULT(v) STMT_START { __typeof__(v) z = (v); (void)sizeof(z); } STMT_END # else # define PERL_UNUSED_RESULT(v) ((void)(v)) It is very likely that xlc in GNU mode has same issues - Tux, can you verify that? Cheers, Jens Show quoted text
> Am 14.02.2015 um 12:05 schrieb perlbug-followup@perl.org: > > Greetings, > > This message has been automatically generated in response to the > creation of a perl bug report regarding: > "5.21.8 fails compiling with icc". > > There is no need to reply to this message right now. Your ticket has been > assigned an ID of [perl #123831]. > > You can view your ticket at > https://rt.perl.org/Ticket/Display.html?id=123831 > > Within the next 24 to 72 hours, your message will be posted to the Perl 5 Porters mailing list. Please be patient! > > Please include the string: > > [perl #123831] > > in the subject line of all future correspondence about this issue. To do so, > you may reply to this message (please delete unnecessary quotes and text.) > > Thank you, > perlbug-followup@perl.org > > ------------------------------------------------------------------------- > Return-Path: <rehsack@gmail.com> > Reply-To: rehsack@gmail.com > From rehsack@gmail.com Sat Feb 14 11:05:43 2015 > Subject: 5.21.8 fails compiling with icc > Date: Sat, 14 Feb 2015 12:05:31 +0100 (CET) > Message-ID: <5.20.1_21867_1423911577@ernie.muppets.liwing.de> > Delivered-To: rt-perl5@rt.perl.org > Delivered-To: perlbug@perl.org > To: perlbug@perl.org > Received: (qmail 4350 invoked by uid 225); 14 Feb 2015 11:05:41 -0000 > Received: (qmail 4346 invoked by alias); 14 Feb 2015 11:05:41 -0000 > Received: from p578b540c.dip0.t-ipconnect.de (HELO ernie.muppets.liwing.de) (87.139.84.12) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Sat, 14 Feb 2015 03:05:37 -0800 > Received: by ernie.muppets.liwing.de (Postfix, from userid 501) id 6F6747132CF7; Sat, 14 Feb 2015 12:05:31 +0100 (CET) > CC: rehsack@gmail.com > From: rehsack@gmail.com > X-Spam-Status: No, hits=-4.3 required=8.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED,PERLBUG_CONF,SPF_SOFTFAIL > X-Spam-Check-BY: la.mx.develooper.com > X-RT-Original-Encoding: ascii > content-type: text/plain; charset="utf-8" > X-RT-Interface: Email
-- Jens Rehsack rehsack@gmail.com
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 712b
On Sat Feb 14 03:05:51 2015, rehsack@gmail.com wrote: Show quoted text
> > This is a bug report for perl from rehsack@gmail.com, > generated with the help of perlbug 1.40 running under perl 5.20.1. > > > ----------------------------------------------------------------- > [Please describe your issue here] > > To prove my XS code with additional compilers, I retry compiling dev- > perl using icc. > I hoped get improved results since 44b62df7 ... >
Were you able to compile perl with the ICC compiler on this platform *before* 44b62df7? In other words, was 44b62df7 a breaking commit for a compiler-platform combination on which you previously were successful? Thank you very much. -- James E Keenan (jkeenan@cpan.org)
CC: perl5-porters [...] perl.org
From: Jens Rehsack <rehsack [...] gmail.com>
Date: Sun, 15 Feb 2015 10:18:09 +0100
To: perlbug-followup [...] perl.org
Subject: Re: [perl #123831] 5.21.8 fails compiling with icc
Download (untitled) / with headers
text/plain 1.8k
Show quoted text
> Am 15.02.2015 um 00:30 schrieb James E Keenan via RT <perlbug-followup@perl.org>: > > On Sat Feb 14 03:05:51 2015, rehsack@gmail.com wrote:
>> >> This is a bug report for perl from rehsack@gmail.com, >> generated with the help of perlbug 1.40 running under perl 5.20.1. >> >> >> ----------------------------------------------------------------- >> [Please describe your issue here] >> >> To prove my XS code with additional compilers, I retry compiling dev- >> perl using icc. >> I hoped get improved results since 44b62df7 ... >>
> > Were you able to compile perl with the ICC compiler on this platform *before* 44b62df7? > > In other words, was 44b62df7 a breaking commit for a compiler-platform combination on which you previously were successful? > > Thank you very much.
I'm able _since_ 44b62df7 compiling perl using icc. But compared to earlier attempts, b469f1e0f break it. That's why my follow-up saying git diff diff --git a/perl.h b/perl.h index 9976f86..0b2dfa8 100644 --- a/perl.h +++ b/perl.h @@ -378,7 +378,7 @@ * __typeof__ and nothing else. */ #ifndef PERL_UNUSED_RESULT -# if defined(__GNUC__) && defined(HASATTRIBUTE_WARN_UNUSED_RESULT) +# if defined(__GNUC__) && !defined(__INTEL_COMPILER) && defined(HASATTRIBUTE_WARN_UNUSED_RESULT) # define PERL_UNUSED_RESULT(v) STMT_START { __typeof__(v) z = (v); (void)sizeof(z); } STMT_END # else # define PERL_UNUSED_RESULT(v) ((void)(v)) fixes the compile issue. You have to compile perl using ./Configure -de -Dcc=icc -Doptimize="-O3 -xHost" -Dld="env MACOSX_DEPLOYMENT_TARGET=10.9 icc -L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib" -Dusedevel -Dprefix=... The handling of ld is kind-of unfortunate (Configure determines "env MACOSX_DEPLOYMENT_TARGET=10.3 env MACOSX_DEPLOYMENT_TARGET=10.9 icc ..." Cheers -- Jens Rehsack rehsack@gmail.com
Date: Sun, 15 Feb 2015 12:26:41 +0100
CC: Father Chrysostomos via RT <perlbug-followup [...] perl.org>, Perl5 Porters <perl5-porters [...] perl.org>
From: Leon Timmermans <fawaka [...] gmail.com>
Subject: Re: [perl #123831] 5.21.8 fails compiling with icc
To: Jens Rehsack <rehsack [...] gmail.com>
Download (untitled) / with headers
text/plain 321b
On Sun, Feb 15, 2015 at 10:18 AM, Jens Rehsack <rehsack@gmail.com> wrote:
Show quoted text
The handling of ld is kind-of unfortunate (Configure determines "env MACOSX_DEPLOYMENT_TARGET=10.3 env MACOSX_DEPLOYMENT_TARGET=10.9 icc ..."

Yeah, that whole logic stinks, it really should be replaced by a more sensible default :-/

Leon

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 702b
On Sat Feb 14 03:40:51 2015, rehsack@gmail.com wrote: Show quoted text
> Following patch solves the issue locally: > > $ git diff > diff --git a/perl.h b/perl.h > index 9976f86..0b2dfa8 100644 > --- a/perl.h > +++ b/perl.h > @@ -378,7 +378,7 @@ > * __typeof__ and nothing else. > */ > #ifndef PERL_UNUSED_RESULT > -# if defined(__GNUC__) && defined(HASATTRIBUTE_WARN_UNUSED_RESULT) > +# if defined(__GNUC__) && !defined(__INTEL_COMPILER) && > defined(HASATTRIBUTE_WARN_UNUSED_RESULT) > # define PERL_UNUSED_RESULT(v) STMT_START { __typeof__(v) z = (v); > (void)sizeof(z); } STMT_END > # else > # define PERL_UNUSED_RESULT(v) ((void)(v))
The linux hints pass -no-gcc to ICC, does that help here? Tony
To: Jens Rehsack <rehsack [...] gmail.com>
Subject: Re: [perl #123831] 5.21.8 fails compiling with icc
From: Greg Lindahl <greg [...] blekko.com>
CC: perlbug-followup [...] perl.org, perl5-porters [...] perl.org
Date: Fri, 20 Feb 2015 20:53:44 -0800
Download (untitled) / with headers
text/plain 384b
On Sun, Feb 15, 2015 at 10:18:09AM +0100, Jens Rehsack wrote: Show quoted text
> -# if defined(__GNUC__) && defined(HASATTRIBUTE_WARN_UNUSED_RESULT) > +# if defined(__GNUC__) && !defined(__INTEL_COMPILER) && defined(HASATTRIBUTE_WARN_UNUSED_RESULT)
Did you consider reporting it as a bug? If a compiler defines __GNUC__ and then doesn't behave like it, they'll probably fix it as a bug. -- greg
Subject: Re: [perl #123831] 5.21.8 fails compiling with icc
To: Jens Rehsack <rehsack [...] gmail.com>
Date: Fri, 20 Feb 2015 20:54:24 -0800
CC: perlbug-followup [...] perl.org, perl5-porters [...] perl.org
From: Greg Lindahl <greg [...] blekko.com>
Download (untitled) / with headers
text/plain 479b
On Fri, Feb 20, 2015 at 08:53:44PM -0800, Greg Lindahl wrote: Show quoted text
> On Sun, Feb 15, 2015 at 10:18:09AM +0100, Jens Rehsack wrote: >
> > -# if defined(__GNUC__) && defined(HASATTRIBUTE_WARN_UNUSED_RESULT) > > +# if defined(__GNUC__) && !defined(__INTEL_COMPILER) && defined(HASATTRIBUTE_WARN_UNUSED_RESULT)
> > Did you consider reporting it as a bug? If a compiler defines __GNUC__ > and then doesn't behave like it, they'll probably fix it as a bug.
To Intel, I mean. -- greg
Date: Sun, 22 Feb 2015 13:42:05 +0100
From: Jens Rehsack <rehsack [...] gmail.com>
CC: perl5-porters [...] perl.org
Subject: Re: [perl #123831] 5.21.8 fails compiling with icc
To: perlbug-followup [...] perl.org
Download (untitled) / with headers
text/plain 2.2k
Show quoted text
> Am 17.02.2015 um 01:49 schrieb Tony Cook via RT <perlbug-followup@perl.org>: > > On Sat Feb 14 03:40:51 2015, rehsack@gmail.com wrote:
>> Following patch solves the issue locally: >> >> $ git diff >> diff --git a/perl.h b/perl.h >> index 9976f86..0b2dfa8 100644 >> --- a/perl.h >> +++ b/perl.h >> @@ -378,7 +378,7 @@ >> * __typeof__ and nothing else. >> */ >> #ifndef PERL_UNUSED_RESULT >> -# if defined(__GNUC__) && defined(HASATTRIBUTE_WARN_UNUSED_RESULT) >> +# if defined(__GNUC__) && !defined(__INTEL_COMPILER) && >> defined(HASATTRIBUTE_WARN_UNUSED_RESULT) >> # define PERL_UNUSED_RESULT(v) STMT_START { __typeof__(v) z = (v); >> (void)sizeof(z); } STMT_END >> # else >> # define PERL_UNUSED_RESULT(v) ((void)(v))
> > The linux hints pass -no-gcc to ICC, does that help here?
I gave it a shot: $ sh Configure -de -Dusedevel -Dprefix=$PERLBREW_ROOT/perls/perl-5.21.8 -Dcc="icc -no-gcc" -Dld="icc" -Doptimize="-O3 -xHost" Checking to see how big your file offsets are... In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/sys/types.h(75), from try.c(1): /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/sys/cdefs.h(81): warning #1224: #warning directive: "Unsupported compiler detected" #warning "Unsupported compiler detected" ^ In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/sys/_endian.h(130), from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/i386/endian.h(99), from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/machine/endian.h(35), from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/sys/types.h(81), from try.c(3): /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/libkern/_OSByteOrder.h(113): error: identifier "uint64_t" is undefined uint64_t ^ So no, I don't think it'll help here ;) -- Jens Rehsack rehsack@gmail.com
To: perlbug-followup [...] perl.org
Subject: Re: [perl #123831] 5.21.8 fails compiling with icc
From: Jens Rehsack <rehsack [...] gmail.com>
Date: Sun, 22 Feb 2015 13:46:59 +0100
Download (untitled) / with headers
text/plain 984b
Show quoted text
> Am 21.02.2015 um 05:54 schrieb greg@blekko.com via RT <perlbug-followup@perl.org>: > > On Fri, Feb 20, 2015 at 08:53:44PM -0800, Greg Lindahl wrote:
>> On Sun, Feb 15, 2015 at 10:18:09AM +0100, Jens Rehsack wrote: >>
>>> -# if defined(__GNUC__) && defined(HASATTRIBUTE_WARN_UNUSED_RESULT) >>> +# if defined(__GNUC__) && !defined(__INTEL_COMPILER) && defined(HASATTRIBUTE_WARN_UNUSED_RESULT)
>> >> Did you consider reporting it as a bug? If a compiler defines __GNUC__ >> and then doesn't behave like it, they'll probably fix it as a bug.
> > To Intel, I mean.
And how does this position helps out getting Perl compiled on OS X using icc? My position is very easy: even two gcc's might support different extensions. Wanna use an extension, probe for it. So yes, when I file the feedback to Intel and ask for renewal of the noncom-license for continuing work, eg. for MoarVM to improve Perl6, I will definitively name this issue. Cheers -- Jens Rehsack rehsack@gmail.com
Date: Sun, 22 Feb 2015 14:34:46 +0100
From: Jens Rehsack <rehsack [...] gmail.com>
CC: Father Chrysostomos via RT <perlbug-followup [...] perl.org>, Perl5 Porters <perl5-porters [...] perl.org>
Subject: Re: [perl #123831] 5.21.8 fails compiling with icc
To: Leon Timmermans <fawaka [...] gmail.com>
Download (untitled) / with headers
text/plain 796b
Show quoted text
> Am 15.02.2015 um 12:26 schrieb Leon Timmermans <fawaka@gmail.com>: > > On Sun, Feb 15, 2015 at 10:18 AM, Jens Rehsack <rehsack@gmail.com> wrote: > The handling of ld is kind-of unfortunate (Configure determines "env MACOSX_DEPLOYMENT_TARGET=10.3 env MACOSX_DEPLOYMENT_TARGET=10.9 icc ..." > > Yeah, that whole logic stinks, it really should be replaced by a more sensible default :-/
Following https://software.intel.com/en-us/articles/performance-tools-for-software-developers-compatibility-of-intel-compiler-for-mac-os-x-and-xcode I updated my icc to 2015 Update 2, which reduces a lot of extra parameters. So now, with both attached patches, it'll compiles and tests fine using: $ sh Configure -de -Dusedevel -Dprefix=$PERLBREW_ROOT/perls/... -Dcc=icc -Dld=icc -Doptimize="-O3 -xHost"

Message body is not shown because sender requested not to inline it.

Message body is not shown because sender requested not to inline it.

Download (untitled) / with headers
text/plain 319b
$ make $ make test Failed 1 test out of 2265, 99.96% okay. opbasic/arith.t Since on Linux a lot more compilers are jumping around, I strongly suggest adding a probe whether __typeof__(x) is supported by compiler or not (Config::AutoConf provides a compile_if_else() for that ;)) -- Jens Rehsack rehsack@gmail.com
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 2.1k
Firslyt, regarding the ICC vs __typeof__ part: As Tony said, proper Configure scan for a correctly working __typeof__ would be the right fix. (Because the problem is that icc claims to be gcc-like, but doesn't seem to have similarly functioning __typeof__.) However, there are two snags in that plan: (1) what constitutes a correctly working __typeof__? I quickly tried basic use of __typeof__ in couple of iccs I could get my hands into and they worked as expected. So there are degrees to workingness. (2) the closeness of 5.22 makes me dubious to starting to iterate on Configure, in general, and in particular for __typeof__ since there seems to be degrees of functionality (see the previous item), and because there seems to be many releases of ICC to test (not to mention other compilers on other platforms). Summary: in short term, I would support applying the not-ICC test for the use of __typeof__. However, since that doesn't seem to fully resolve the problems with ICC on * Secondly, regarding the darwin hints part of this change. Disclaimer: I'm not really an OSX programmer either, except in the role of compiling opensource UNIXy stuff on it... but after re-reading https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html (mentioned in hints/darwin.sh) http://stackoverflow.com/questions/2923502/what-does-macosx-version-min-imply http://stackoverflow.com/questions/25352389/difference-between-macosx-deployment-target-and-mmacosx-version-min-compiler-op I would say the choice is between (1) backward compatibility: building a binary that will work in all the releases since 10.x (2) new shininess: building a binary that will work with the currently installed SDK, and releases thereafter I would lean towards the keeping existing state of things, backward compatibility, for the default. If packagers / people building their own want the new shiny, they can specify a different OS level. That being said, the suggested patch for this looks like a nice start for automatically doing the "new shiny". It just needs to be made somehow optional.
Subject: Re: [perl #123831] 5.21.8 fails compiling with icc
To: perlbug-followup [...] perl.org
Date: Sun, 8 Mar 2015 18:19:39 +0100
From: Jens Rehsack <rehsack [...] gmail.com>
Download (untitled) / with headers
text/plain 2.5k
Show quoted text
> Am 08.03.2015 um 15:00 schrieb Jarkko Hietaniemi via RT <perlbug-followup@perl.org>: > > Firslyt, regarding the ICC vs __typeof__ part: > > As Tony said, proper Configure scan for a correctly working __typeof__ would be the right fix. (Because the problem is that icc claims to be gcc-like, but doesn't seem to have similarly functioning __typeof__.) However, there are two snags in that plan: (1) what constitutes a correctly working __typeof__? I quickly tried basic use of __typeof__ in couple of iccs I could get my hands into and they worked as expected. So there are degrees to workingness. (2) the closeness of 5.22 makes me dubious to starting to iterate on Configure, in general, and in particular for __typeof__ since there seems to be degrees of functionality (see the previous item), and because there seems to be many releases of ICC to test (not to mention other compilers on other platforms). > > Summary: in short term, I would support applying the not-ICC test for the use of __typeof__. However, since that doesn't seem to fully resolve the problems with ICC on *
I agree a prove for __typeof__ is the right way to do it. But likely for 5.24 :( Show quoted text
> Secondly, regarding the darwin hints part of this change. > > Disclaimer: I'm not really an OSX programmer either, except in the role of compiling opensource UNIXy stuff on it... but after re-reading > > https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html (mentioned in hints/darwin.sh) > http://stackoverflow.com/questions/2923502/what-does-macosx-version-min-imply > http://stackoverflow.com/questions/25352389/difference-between-macosx-deployment-target-and-mmacosx-version-min-compiler-op > > I would say the choice is between > > (1) backward compatibility: building a binary that will work in all the releases since 10.x > (2) new shininess: building a binary that will work with the currently installed SDK, and releases thereafter > > I would lean towards the keeping existing state of things, backward compatibility, for the default. If packagers / people building their own want the new shiny, they can specify a different OS level. > > That being said, the suggested patch for this looks like a nice start for automatically doing the "new shiny". It just needs to be made somehow optional.
It is "optional" when one who want (1) simply defines MACOSX_DEPLOYMENT_TARGET=10.3 and the really correct -arch values in ccflags and ldflags. I fear, (1) is much farther away than it looks like ;) Cheers -- Jens Rehsack rehsack@gmail.com
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.5k
On Sun Mar 08 10:20:11 2015, rehsack@gmail.com wrote: Show quoted text
>
> > Am 08.03.2015 um 15:00 schrieb Jarkko Hietaniemi via RT <perlbug- > > followup@perl.org>: > > > > Firslyt, regarding the ICC vs __typeof__ part: > > > > As Tony said, proper Configure scan for a correctly working > > __typeof__ would be the right fix. (Because the problem is that icc > > claims to be gcc-like, but doesn't seem to have similarly functioning > > __typeof__.) However, there are two snags in that plan: (1) what > > constitutes a correctly working __typeof__? I quickly tried basic > > use of __typeof__ in couple of iccs I could get my hands into and > > they worked as expected. So there are degrees to workingness. (2) > > the closeness of 5.22 makes me dubious to starting to iterate on > > Configure, in general, and in particular for __typeof__ since there > > seems to be degrees of functionality (see the previous item), and > > because there seems to be many releases of ICC to test (not to > > mention other compilers on other platforms). > > > > Summary: in short term, I would support applying the not-ICC test for > > the use of __typeof__. However, since that doesn't seem to fully > > resolve the problems with ICC on *
> > I agree a prove for __typeof__ is the right way to do it. But likely > for 5.24 :(
Do you have simple sample __typeof__ code that fails for Intel C but succeeds for gcc? From Jarkko's comment above basic use of __typeof__ seems to work ok in the icc he tried, so I suspect we need more than just a basic __typeof__ test. Tony
Subject: Re: [perl #123831] 5.21.8 fails compiling with icc
Date: Wed, 2 Sep 2015 07:42:35 +0200
To: perlbug-followup [...] perl.org
From: Jens Rehsack <rehsack [...] gmail.com>
Download (untitled) / with headers
text/plain 1.9k
Show quoted text
> Am 02.09.2015 um 04:05 schrieb Tony Cook via RT <perlbug-followup@perl.org>: > > On Sun Mar 08 10:20:11 2015, rehsack@gmail.com wrote:
>>
>>> Am 08.03.2015 um 15:00 schrieb Jarkko Hietaniemi via RT <perlbug- >>> followup@perl.org>: >>> >>> Firslyt, regarding the ICC vs __typeof__ part: >>> >>> As Tony said, proper Configure scan for a correctly working >>> __typeof__ would be the right fix. (Because the problem is that icc >>> claims to be gcc-like, but doesn't seem to have similarly functioning >>> __typeof__.) However, there are two snags in that plan: (1) what >>> constitutes a correctly working __typeof__? I quickly tried basic >>> use of __typeof__ in couple of iccs I could get my hands into and >>> they worked as expected. So there are degrees to workingness. (2) >>> the closeness of 5.22 makes me dubious to starting to iterate on >>> Configure, in general, and in particular for __typeof__ since there >>> seems to be degrees of functionality (see the previous item), and >>> because there seems to be many releases of ICC to test (not to >>> mention other compilers on other platforms). >>> >>> Summary: in short term, I would support applying the not-ICC test for >>> the use of __typeof__. However, since that doesn't seem to fully >>> resolve the problems with ICC on *
>> >> I agree a prove for __typeof__ is the right way to do it. But likely >> for 5.24 :(
> > Do you have simple sample __typeof__ code that fails for Intel C but succeeds for gcc? > > From Jarkko's comment above basic use of __typeof__ seems to work ok in the icc he tried, so I suspect we need more than just a basic __typeof__ test.
Intel's documentation says, it doesn't work at all. My tests confirm that. But I didn't retry with most recent update and my license ends. A simple __typeof__ test in Configure.sh should prove whether the compiler is able to support __typeof__ - and the #ifdef should distinguish between HAVE__TYPEOF_ and don't. Cheers -- Jens Rehsack - rehsack@gmail.com
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 239b
Last night Tony C. asked me on IRC to try out the second of the two patches in this ticket on my older Darwin system. Perl built successfully and passed all tests with this patch EXCEPT t/porting/authors.t Thank you very much. Jim Keenan
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 438b
On Wed Oct 14 04:51:32 2015, jkeenan wrote: Show quoted text
> Last night Tony C. asked me on IRC to try out the second of the two > patches in this ticket on my older Darwin system. Perl built > successfully and passed all tests with this patch EXCEPT > t/porting/authors.t > > Thank you very much. > Jim Keenan
TonyC et al: Would it be possible to get an update on the status of this RT? Thank you very much. -- James E Keenan (jkeenan@cpan.org)
From: Jens Rehsack <rehsack [...] gmail.com>
CC: Perl5 Porters <perl5-porters [...] perl.org>
To: perlbug-followup [...] perl.org
Date: Wed, 7 Nov 2018 16:02:45 +0100
Subject: Re: [perl #123831] 5.21.8 fails compiling with icc
Download (untitled) / with headers
text/plain 1.4k
With the recent update of xcode - maybe the p5p are willing to rethink their decision wrt. attached patches ...

Show quoted text
Am 22.02.2015 um 14:34 schrieb Jens Rehsack <rehsack@gmail.com>:


Am 15.02.2015 um 12:26 schrieb Leon Timmermans <fawaka@gmail.com>:

On Sun, Feb 15, 2015 at 10:18 AM, Jens Rehsack <rehsack@gmail.com> wrote:
The handling of ld is kind-of unfortunate (Configure determines "env MACOSX_DEPLOYMENT_TARGET=10.3 env MACOSX_DEPLOYMENT_TARGET=10.9 icc ..."

Yeah, that whole logic stinks, it really should be replaced by a more sensible default :-/

Following https://software.intel.com/en-us/articles/performance-tools-for-software-developers-compatibility-of-intel-compiler-for-mac-os-x-and-xcode I updated my icc to 2015 Update 2, which reduces a lot of extra parameters. So now, with both attached patches, it'll compiles and tests fine using:

$ sh Configure -de -Dusedevel -Dprefix=$PERLBREW_ROOT/perls/... -Dcc=icc -Dld=icc -Doptimize="-O3 -xHost"

<0001-Explicitely-exclude-icc-from-unused-result-improve.patch><0002-very-first-step-to-tidy-up-mess-around-sdk-to-use.patch>
$ make
$ make test
Failed 1 test out of 2265, 99.96% okay.
opbasic/arith.t

Since on Linux a lot more compilers are jumping around, I strongly suggest adding a probe whether __typeof__(x) is supported by compiler or not (Config::AutoConf provides a compile_if_else() for that ;))

--
Jens Rehsack
rehsack@gmail.com


-- 
Jens Rehsack - rehsack@gmail.com

Download signature.asc
application/pgp-signature 833b

Message body not shown because it is not plain text.



This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org