5.21.8 fails compiling with icc #14503
Comments
From rehsack@gmail.comCreated by rehsack@gmail.comTo prove my XS code with additional compilers, I retry compiling dev-perl using icc. Unfortunately, I got: icc -c -DPERL_CORE -fno-common -DPERL_DARWIN -O3 sv.c sv.c(11300): error: expression must be an integral constant expression sv.c(12284): error: expression must be an integral constant expression compilation aborted for sv.c (code 2) Perl Info |
From rehsack@gmail.comFollowing patch solves the issue locally: $ git diff Inline Patchdiff --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))
Cheers,
-- |
From @jkeenanOn Sat Feb 14 03:05:51 2015, rehsack@gmail.com wrote:
Were you able to compile perl with the ICC compiler on this platform *before* 44b62df? In other words, was 44b62df a breaking commit for a compiler-platform combination on which you previously were successful? Thank you very much. -- |
|
The RT System itself - Status changed from 'new' to 'open' |
From rehsack@gmail.com
I'm able _since_ 44b62df compiling perl using icc. That's why my follow-up saying git diff Inline Patchdiff --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))
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 |
From @LeontOn Sun, Feb 15, 2015 at 10:18 AM, Jens Rehsack <rehsack@gmail.com> wrote:
Yeah, that whole logic stinks, it really should be replaced by a more Leon |
From @tonycozOn Sat Feb 14 03:40:51 2015, rehsack@gmail.com wrote:
The linux hints pass -no-gcc to ICC, does that help here? Tony |
From greg@blekko.comOn Sun, Feb 15, 2015 at 10:18:09AM +0100, Jens Rehsack wrote:
Did you consider reporting it as a bug? If a compiler defines __GNUC__ -- greg |
From greg@blekko.comOn Fri, Feb 20, 2015 at 08:53:44PM -0800, Greg Lindahl wrote:
To Intel, I mean. -- greg |
From rehsack@gmail.com
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" So no, I don't think it'll help here ;) -- |
From rehsack@gmail.com
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. So yes, when I file the feedback to Intel and ask for renewal of the noncom-license Cheers |
From rehsack@gmail.com
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" |
From rehsack@gmail.com0001-Explicitely-exclude-icc-from-unused-result-improve.patchFrom b525b197136240b9c8d62196a7f75998d8afade3 Mon Sep 17 00:00:00 2001
From: Jens Rehsack <sno@netbsd.org>
Date: Sun, 22 Feb 2015 14:08:28 +0100
Subject: [PATCH 1/2] Explicitely exclude icc from unused result improve
Since Apple designed the system includes and libraries working with CLang
and special versions of gcc > 4 (see quote in $SDK_PATH/usr/include/sys/cdefs.h
line 78 ff), it is eager a workaround and should result in testing for the
availablity of the __typeof__ extension (mind the big base of platform
specific gcc's out there, eg. Caium's gcc suite for Octeon Processors or
here found Apple's patchsets to their own gcc).
Signed-off-by: Jens Rehsack <sno@netbsd.org>
---
perl.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/perl.h b/perl.h
index b3b77ba..9c2629c 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))
--
1.9.3 (Apple Git-50)
|
From rehsack@gmail.com0002-very-first-step-to-tidy-up-mess-around-sdk-to-use.patchFrom 832beb9955b992afa044daafc502f790bb49f874 Mon Sep 17 00:00:00 2001
From: Jens Rehsack <sno@netbsd.org>
Date: Sun, 22 Feb 2015 14:23:33 +0100
Subject: [PATCH 2/2] very first step to tidy up mess around sdk to use
According to [1] and how Perl and most XS modules are implemented, none of
them are using conditionals to prove API availability. Therefore, it's
reasonable to rely on the sdk available for the system.
For future improvements, this hint's file should distinguish between SDKROOT
for the base-sdk to use and MACOSX_DEPLOYMENT_SDK for weak linking following
[2]. But it's important to add appropriate environment variables to $cc
invocation, either.
1) https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html
2) http://stackoverflow.com/questions/13964742/sdkroot-path-for-latest-sdk
Signed-off-by: Jens Rehsack <sno@netbsd.org>
---
hints/darwin.sh | 37 +++++++++++++++++++++++++++++++++++--
1 file changed, 35 insertions(+), 2 deletions(-)
diff --git a/hints/darwin.sh b/hints/darwin.sh
index fec05fd..9437fc2 100644
--- a/hints/darwin.sh
+++ b/hints/darwin.sh
@@ -3,6 +3,26 @@
# Wilfredo Sanchez <wsanchez@wsanchez.net>
##
+# table from pkgsrc/mk/platform/Darwin.mk
+# OS, Kernel, Xcode Version
+# Note that Xcode gets updates on older systems sometimes.
+# pkgsrc generally expects that the most up-to-date xcode available for
+# an OS version is installed
+#
+# Codename OS Kernel Xcode
+# Cheetah 10.0.x 1.3.1
+# Puma 10.1 1.4.1
+# 10.1.x 5.x.y
+# Jaguar 10.2.x 6.x.y
+# Panther 10.3.x 7.x.y
+# Tiger 10.4.x 8.x.y 2.x (gcc 4.0, 4.0.1 from 2.2)
+# Leopard 10.5.x 9.x.y 3.x (gcc 4.0.1, 4.0.1 and 4.2.1 from 3.1)
+# Snow Leopard 10.6.x 10.x.y 3.2+ (gcc 4.0.1 and 4.2.1)
+# Lion 10.7.x 11.x.y 4.1 (llvm gcc 4.2.1)
+# Mountain Lion 10.8.x 12.x.y 4.5 (llvm gcc 4.2.1)
+# Mavericks 10.9.x 13.x.y 6 (llvm clang 6.0)
+# Yosemite 10.10.x 14.x.y 6 (llvm clang 6.0)
+
##
# Paths
##
@@ -205,8 +225,21 @@ case "$osvers" in
# https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html
lddlflags="${ldflags} -bundle -undefined dynamic_lookup"
case "$ld" in
- *MACOSX_DEVELOPMENT_TARGET*) ;;
- *) ld="env MACOSX_DEPLOYMENT_TARGET=10.3 ${ld}" ;;
+ *MACOSX_DEPLOYMENT_TARGET*) ;;
+ *)
+ if test -x /usr/bin/xcrun; then
+ SDK_VERSION="`/usr/bin/xcrun --show-sdk-version 2>/dev/null`"
+ else
+ # one with ppc mac and/or *Leopard x86 should add patterns for both
+ # if ccflags/ldflags contain "-m32", appropriate fallback should be chosen either
+ # otherwise: packaging people could provide suitable ld command
+ case "`uname -m`" in
+ *x86_64*) SDK_VERSION="10.7" ;;
+ *) SDK_VERSION="10.3" ;;
+ esac
+ fi
+ ld="env MACOSX_DEPLOYMENT_TARGET=${SDK_VERSION} ${ld}"
+ ;;
esac
;;
esac
--
1.9.3 (Apple Git-50)
|
From rehsack@gmail.com$ make 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 ;)) -- |
From @jhiFirslyt, 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) I would say the choice is between (1) backward compatibility: building a binary that will work in all the releases since 10.x 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. |
From rehsack@gmail.com
I agree a prove for __typeof__ is the right way to do it. But likely for 5.24 :(
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. Cheers |
From @tonycozOn Sun Mar 08 10:20:11 2015, rehsack@gmail.com wrote:
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 |
From rehsack@gmail.com
Intel's documentation says, it doesn't work at all. My tests confirm that. A simple __typeof__ test in Configure.sh should prove whether the compiler Cheers |
From @jkeenanLast 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. |
From @jkeenanOn Wed Oct 14 04:51:32 2015, jkeenan wrote:
TonyC et al: Would it be possible to get an update on the status of this RT? Thank you very much. -- |
From rehsack@gmail.comWith the recent update of xcode - maybe the p5p are willing to rethink their decision wrt. attached patches ...
-- |
Migrated from rt.perl.org#123831 (status was 'open')
Searchable as RT123831$
The text was updated successfully, but these errors were encountered: