r117741
Geoff, I noticed that the automake maintainers accepted your patch for fixing the multilib issues in automake. However they also seemed to indicate that there would be no more 1.9.x automake releases. Is the r117741 svn checkin related to this issue? I ask because it was unclear to me how the multilib issues with gcc could be resolved until a new automake was released with the required patch (so that it could be used to regenerate the necessary configure files in gcc trunk). Thanks in advance for any clarifications. Jack
Re: r117741
Geoff, Should gcc/doc/install.texi be changed now to require automake version 1.10 or later rather than the current 1.9.3? Jack On Tue, Oct 17, 2006 at 12:36:21PM -0700, Geoffrey Keating wrote: > > Hi Jack, > > I believe all this was covered in my message to gcc-patches relating > to that checkin. >
Re: r117741
Geoff, The repost answers my questions. I was wondering if the changes required the new automake and if so whether they could be undone if someone regenerated those configure files with a version of automake before 1.10? It would appear that's not the case. Jack
how to disable multilib for libffi and libjava only?
On Darwin PPC and intel, we don't have proper libffi and
libjava support at 64-bit. However we would still like to build
the other compilers with multilib support. I noticed that RedHat
was building their gcc 4.1.1 with the following
# Hack to avoid building multilib libjava
perl -pi -e 's/^all: all-redirect/ifeq (\$(MULTISUBDIR),)\nall:
all-redirect\nelse\nall:\n\techo Multilib libjava build disabled\nendif/'
libjava/Makefile.in
perl -pi -e 's/^install: install-redirect/ifeq (\$(MULTISUBDIR),)\ninstall:
install-redirect\nelse\ninstall:\n\techo Multilib libjava install
disabled\nendif/' libjava/Makefile.in
perl -pi -e 's/^check: check-redirect/ifeq (\$(MULTISUBDIR),)\ncheck:
check-redirect\nelse\ncheck:\n\techo Multilib libjava check disabled\nendif/'
libjava/Makefile.in
perl -pi -e 's/^all: all-recursive/ifeq (\$(MULTISUBDIR),)\nall:
all-recursive\nelse\nall:\n\techo Multilib libjava build disabled\nendif/'
libjava/Makefile.in
perl -pi -e 's/^install: install-recursive/ifeq (\$(MULTISUBDIR),)\ninstall:
install-recursive\nelse\ninstall:\n\techo Multilib libjava install
disabled\nendif/' libjava/Makefile.in
perl -pi -e 's/^check: check-recursive/ifeq (\$(MULTISUBDIR),)\ncheck:
check-recursive\nelse\ncheck:\n\techo Multilib libjava check disabled\nendif/'
libjava/Makefile.in
gcc41-java-nomulti.patch
--- libjava/configure.ac.jj 2004-08-16 21:13:29.0 +0200
+++ libjava/configure.ac2004-08-21 11:44:59.020755542 +0200
@@ -367,6 +367,10 @@ use_gtk_awt=""
TOOLKIT=
AC_SUBST(TOOLKIT)
+if test -n "${with_multisubdir}"; then
+ peerlibs=no
+fi
+
for peer in $peerlibs ; do
case $peer in
xlib)
--- libjava/configure.jj2004-08-16 21:22:14.0 +0200
+++ libjava/configure 2004-08-21 11:45:16.260738060 +0200
@@ -4118,6 +4118,9 @@ use_gtk_awt=""
# The default toolkit to use is the first one specified.
TOOLKIT=
+if test -n "${with_multisubdir}"; then
+ peerlibs=no
+fi
for peer in $peerlibs ; do
case $peer in
Is there a better way then this to try to disable the multilib build in
gcc 4.2 for just libffi and libjava?
Thanks in advance for any advice.
Jack
Re: [Fwd: gcc-4.3-20061023 is now available]
Mark, What happened to the gcc 4.2 snapshot tarball for this week? Jack
regenerating configure in gcc
I am having difficulty getting configure properly regenerated in libjava so that Geoff's multilib changes will take effect. What versions of automake and libtool is required by the current gcc 4.2 branch? I have been trying automake 1.10 and libtool 1.5.22. However whenever I use autoreconf -I ../config in libjava to regenerate configure, the resulting build mangles the linkage of shared libraries in libjava. The linkage of the shared libraries fail due to a missing main symbol. Jack ps Is there any way to fake out the gcc build so that one can selectively introduce --disable-multilib for certain subdirectories? If I could force libffi, boehm-gc and libjava to run their configure with --disable-multilib that should allow me to avoid regenerating their configure related files.
Re: regenerating configure in gcc
Ben, I believe I have puzzled out my problem. Geoff's multilib changes needs a patch for the zlib and libjava configure.ac (matching what he did for that file in libobjc). I have been able to obtain a complete build for c, c++, objc and fortran now on a G4 under Darwin8 after patching the configure.ac in zlib... http://gcc.gnu.org/ml/gcc-bugs/2006-11/msg00170.html http://gcc.gnu.org/ml/gcc-bugs/2006-11/msg00171.html I am now testing a similar patch for the configure.ac in libjava with a build including the java language. Jack On Fri, Nov 03, 2006 at 02:52:02PM +1100, Ben Elliston wrote: > > The safest thing to do is to always look at the top of the file you're > trying to regenerate. The comment at the top will tell you what > version was used previously. You should use the same version. > > Ben
multilib fixes for libjava
Could anyone comment on the following? Geoff introduced
fixes in r117741 to allow multilib builds on 32-bit PowerPC
processors on Darwin PPC. However the necessary changes for the
libjava subdirectory were never introduced. I have been
attempting to fix this by modelling a patch after the changes
done for configure.ac and Makefile.in in the libobjc directory...
http://gcc.gnu.org/viewcvs/trunk/libobjc/configure.ac?r1=110182&r2=117741
http://gcc.gnu.org/viewcvs/trunk/libobjc/Makefile.in?r1=117618&r2=117741
and regenerating the configure files with...
cd libjava
aclocal -I . -I .. -I ../config
autoconf -I . -I .. -I ../config
automake -a
cd classpath
aclocal -I m4 -I ../.. -I ../../config
autoconf -I m4 -I ../.. -I ../../config
automake -a
cd ../libltdl
aclocal -I ../.. -I ../../config
autoconf -I ../.. -I ../../config
automake -a
cd ..
cd ..
So far the patch looks like...
--- gcc/libjava/configure.ac.org2006-11-04 08:49:05.0 -0500
+++ gcc/libjava/configure.ac2006-11-04 09:25:25.0 -0500
@@ -15,27 +15,8 @@
# We may get other options which we don't document:
# --with-target-subdir, --with-multisrctop, --with-multisubdir
-# When building with srcdir == objdir, links to the source files will
-# be created in directories within the target_subdir. We have to
-# adjust toplevel_srcdir accordingly, so that configure finds
-# install-sh and other auxiliary files that live in the top-level
-# source directory.
-if test "${srcdir}" = "."; then
- if test -z "${with_target_subdir}"; then
-toprel=".."
- else
-if test "${with_target_subdir}" != "."; then
- toprel="${with_multisrctop}../.."
-else
- toprel="${with_multisrctop}.."
-fi
- fi
-else
- toprel=".."
-fi
-
-libgcj_basedir=$srcdir/$toprel/./libjava
-AC_SUBST(libgcj_basedir)
+# Find the rest of the source tree framework.
+AM_ENABLE_MULTILIB(, ..)
AC_CANONICAL_SYSTEM
_GCC_TOPLEV_NONCANONICAL_BUILD
@@ -74,16 +55,6 @@
[version_specific_libs=no]
)
-# Default to --enable-multilib
-AC_ARG_ENABLE(multilib,
- AS_HELP_STRING([--enable-multilib],
- [build many library versions (default)]),
-[case "${enableval}" in
- yes) multilib=yes ;;
- no) multilib=no ;;
- *) AC_MSG_ERROR(bad value ${enableval} for multilib option) ;;
- esac], [multilib=yes])dnl
-
AC_ARG_ENABLE(plugin,
AS_HELP_STRING([--enable-plugin],
[build gcjwebplugin web browser plugin]),
@@ -905,7 +876,7 @@
AM_CONDITIONAL(USING_GCC, test "$GCC" = yes)
# We're in the tree with gcc, and need to include some of its headers.
-GCC_UNWIND_INCLUDE='-I$(libgcj_basedir)/../gcc'
+GCC_UNWIND_INCLUDE='-I$(multi_basedir)/./libjava/../gcc'
if test "x${with_newlib}" = "xyes"; then
# We are being configured with a cross compiler. AC_REPLACE_FUNCS
@@ -1518,7 +1489,7 @@
case " $CONFIG_FILES " in
*" Makefile "*)
LD="${ORIGINAL_LD_FOR_MULTILIBS}"
- ac_file=Makefile . ${libgcj_basedir}/../config-ml.in
+ ac_file=Makefile . ${multi_basedir}/./libjava/../config-ml.in
;;
esac
for ac_multi_file in $CONFIG_FILES; do
@@ -1534,7 +1505,7 @@
with_multisubdir=${with_multisubdir}
ac_configure_args="${multilib_arg} ${ac_configure_args}"
CONFIG_SHELL=${CONFIG_SHELL-/bin/sh}
-libgcj_basedir=${libgcj_basedir}
+multi_basedir=${multi_basedir}
CC="${CC}"
CXX="${CXX}"
ORIGINAL_LD_FOR_MULTILIBS="${ORIGINAL_LD_FOR_MULTILIBS}"
--- gcc/libjava/Makefile.in.org 2006-11-04 09:16:49.0 -0500
+++ gcc/libjava/Makefile.in 2006-11-04 09:18:12.0 -0500
@@ -665,7 +665,7 @@
install_sh = @install_sh@
libdir = @libdir@
libexecdir = @libexecdir@
-libgcj_basedir = @libgcj_basedir@
+multi_basedir = @multi_basedir@
mandir = @mandir@
With these changes, the multilib build on a G4 dies at...
checking for dladdr in -ldl... yes
checking for /proc/self/exe... configure: error: cannot check for file
existence when cross compiling
Do any of you see anything obiviously wrong in the configure.ac and Makefile.in
changes? It wasn't
straightforward how I should map Geoff's changes to libjava since you use
libgcj_basedir instead of
toplevel_srcdir. Thanks in advance for any advice as I am pretty much stuck at
this point.
Jack
ps I also patch...
--- gcc-4.2-20061031/libjava/libltdl/Makefile.am.org2006-11-03
18:10:46.0 -0500
+++ gcc-4.2-20061031/libjava/libltdl/Makefile.am2006-11-03
18:11:12.0 -0500
@@ -2,6 +2,8 @@
AUTOMAKE_OPTIONS = no-dependencies foreign
+ACLOCAL_AMFLAGS = -I ../.. -I ../../config
+
INCLUDES = $(GCINCS)
if INSTALL_LTDL
to make sure that the ACLOCAL_AMFLAGS is properly set for finding the new
multi.m4 file Geoff added.
Re: Problem with listing i686-apple-darwin as a Primary Platform
I would more worried about the second issue if gcc 4.2 was remotely close to release. However at the rate regressions are being fixed (or not) in gcc 4.2 branch, I wouldn't hold my breath as to which is released first (gcc 4.2 or Leopard). Once Leopard is released, Darwin8 will become the 'previous' release and the problem on Darwin PPC will go away. Jack On Mon, Nov 06, 2006 at 07:49:59PM -0800, Andrew Pinski wrote: > Hi, > Right now after patches by the Apple folks causes you to need a newer > dwarfutils which don't exist outside of Apple so the community of Free > Source and GCC is not helped by making Darwin a primary platform. > Maybe we should list a specific version of darwin which changes the > confusion of which darwin (Mac OS X) version is supposed to be able to > compile right out of the box. Right now on the PowerPC side, Darwin > before 8 (so Panther and before) are broken bootstrapping the mainline > and is also broken on the 4.2 branch. > > We should request that the Apple [EMAIL PROTECTED] support the latest > release version of their OS and the previous version or we should remove > Darwin from being a primary/secondary platform until they are able to. > > Thanks, > Andrew Pinski
gmp/mpfr and multilib
Does anyone know how the changes for gcc to require gmp/mpfr will effect the multilib builds? In the past, gmp/mpfr in gfortran appeared to only be linked into the compiler itself so that a 32-bit/64-bit multilib build on Darwin PPC only required gmp/mpfr for 32-bit to be installed. Will any of the libraries in gcc now require gmp/mpfr such that both 32-bit and 64-bit versions of gmp/mpfr must be installed? If that is the case, will the multilib build look for both a lipo 32-bit/64-bit combined shared library in $prefix/lib as well as individual versions in lib and lib64 subdirectories? Jack
libffi on Macintel?
Can anyone confirm that the libffi shared libraries are properly built in gcc 4.2 branch (or trunk) on i386-apple-darwin8? I have had a report that the most recent snapshot of gcc 4.2 doesn't build libffi on Macintel boxes. This is rather disturbing since I assumed that Sandro's patches were all properly checked into gcc trunk before gcc 4.2 branched. Unfortunately I don't have a Macintel machine to test this one and no one seems to be submitting testresults for i386-apple-darwin8 (which is rather bad form for a putative primary platform). Jack
Re: libffi on Macintel?
Mike, The problem is that the Geoff rejected the configure.in patch that removes libgcj from noconfigdirs... http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00642.html ...as being too invasive for gcc 4.2. If you manually apply that, it should build java fine with --disable-multilib on Intel Darwin. Why don't you try to get that patch into gcc trunk now that gcc 4.2 has branched? Jack On Tue, Nov 14, 2006 at 02:26:11PM -0800, Mike Stump wrote: > On Nov 12, 2006,@3:21 PM, Jack Howarth wrote: > >Can anyone confirm that the libffi shared libraries are properly > >built in gcc 4.2 branch (or trunk) > > No, they aren't built: > > The following languages will be built: c,c++,java > *** This configuration is not supported in the following subdirectories: > target-libmudflap target-libffi target-zlib target-libjava > target-libada gnattools target-libgfortran target-libobjc target-boehm- > gc > (Any other directories should still work fine.) > > :-( > > >This is rather disturbing since I assumed that Sandro's patches were > >all properly checked into gcc trunk before gcc 4.2 branched. > > :-( > > >no one seems to be submitting testresults for i386-apple-darwin8 > > http://gcc.gnu.org/ml/gcc-testresults/2006-11/msg00621.html
Re: gfortran testsuite failures with 4.3.0 on powerpc64-apple-darwin8.8.0
Steve, That comment isn't quite fair. Currently on MacOS X 10.4.8, we only have 32 failures for both -m32 and -m64 in the fortran testsuite. Three quarters of those are definitely due to the problem with the long double system calls not being mapped and the other ones (due to isfinite breakage) may be related as well since it only happens with long doubles. Bradley tends to push the envelope by using non-standard flags in his build plus he is using the newly added powerpc64-*-darwin* target instead of powerpc-*-darwin*. Perhaps it would help if Bradley repeated his build without the -mcpu=970 to see if that eliminates the problems. Also I assume Bradley remembered to install the build before running make check. I see lots of libgomp failures I believe those could be due to that. Also, Bradley, did you remember to patch the prune.exp scripts in the testsuite? You will get a huge number of false failures due to linker warnings at -m64 with -g if you don't. Jack On Wed, Dec 06, 2006 at 10:24:33AM -0800, Steve Kargl wrote: > > Can you make testsuite/gfortran/gfortran.log available? > I suspect that this is yet another Darwin is a broken > OS problem. > > Have you ever thought about replacing darwin with something > that actually is functional? > > -- > Steve >
why no boehm-gc tests?
I noticed that boehm-gc check doesn't work from within the dejagnu framework. According to the notes in PR11412, this was going to be fixable once the multi-lib stuff was moved to the top level. I assume this has happened by now so can we fix this for gcc 4.2? Jack
should fastjar be built?
I noticed that fastjar no longer appears to be built and installed on darwin in gcc 4.2 branch or trunk. What is the status of this utility for gcc? Looking at the RedHat gcc 4.1 packaging for clues, I was surprised to find that they have a build requires for /usr/bin/fastjar while they package it in their libgcj rpm. While I noticed that configure.in lists fastjar as a host utility, it seems really odd to have a circular dependency that requires the fastjar to pre-exist before it can be built. I should also add that on darwin I see lines like when configure runs... checking for user supplied fastjar... /sw/src/fink.build/gcc42-4.1.-20061226/darwin_objdir/powerpc-apple-darwin8/ppc64/libjava/scripts/jar that indicate the jar script is being used in place of fastjar. This is odd since on Fedora Linux, the gcc 4.1.1 has a compiled binary for fastjar instead of a simple script like that in libjava/scripts for jar. Thanks in advance for any clarifications on this. Jack
does zlib really need to build multilib?
I noticed that in gcc trunk and gcc 4.2 branch that multilib builds of zlib occur. Does gcc actually use the multlib zlib? For instance on x86_64 linux does the 32-bit zlib get used or on Darwin does the 64-bit zlib get used? We are considering using the --with-system-zlib option when building gcc 4.2 but MacOS X 10.4 and earlier lacks a 64-bit zlib support library. Thanks in advance for any clarifications. Jack
fat binaries for FSF gcc on Darwin?
I noticed that Apple's gcc compiler in MacOS X 10.4 creates fat binaries in /usr/lib rather than using a ppc64 or x86_64 subdirectory like FSF gcc. Do the Darwin gcc developers ever intend to replicate the use of fat binaries for FSF gcc (in gcc 4.3 perhaps) or will we always use separate subdirectories for 32-bit and 64-bit shared libraries? Jack
Re: fat binaries for FSF gcc on Darwin?
Eric, So will FSF gcc on Darwin maintain the current 64-bit subdirectory or will it eventually migrate to using fat binaries as Apple gcc does? Jack On Sat, Jan 13, 2007 at 07:02:10AM -0800, Eric Christopher wrote: > > All of that is done by a script that calls configure and post-processes > the resultant builds with the exception of libgcc which is built fat > in either place. > > -eric
incorrect symlink on Darwin
I noticed today that gcc 4.2 branch seems to create a bogus symlink on Darwin PPC. A symlink for libgcc_s_x86_64.1.dylib is created that points at libgcc_s.1.dylib. However libgcc_s.1.dylib is not a quad binary... file libgcc_s.1.dylib libgcc_s.1.dylib: Mach-O fat file with 2 architectures libgcc_s.1.dylib (for architecture ppc):Mach-O dynamically linked shared library ppc libgcc_s.1.dylib (for architecture ppc64): Mach-O 64-bit dynamically linked shared library ppc64 Is anyone else seeing this? Jack
gcc 4.2 branch build failure on powerpc-apple-darwin8
The current gcc 4.2 branch (revision 122824) fails to build on powerpc-apple-darwin8 with the error... gcc -g -no-cpp-precomp -DHAVE_DESIGNATED_INITIALIZERS=0 -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -o cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o c-objc-common.o c-dump.o c-pch.o c-parser.o darwin-c.o rs6000-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o dummy-checksum.o \ main.o tree-browser.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a -lintl -L/sw/lib -liconv ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a /usr/bin/ld: Undefined symbols: _decl_readonly_section_1 collect2: ld returned 1 exit status make[3]: *** [cc1-dummy] Error 1 make[2]: *** [all-stage1-gcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 Hopefully we can get this fixed before the RC release is made from gcc 4.2 branch. Jack
RE: gcc 4.2 branch build failure on powerpc-apple-darwin8
The breakage on powerpc-apple-darwin8 seems to be due to revision 122782... PR target/26090 * target.h (targetm.asm.out.reloc_rw_mask): New. * target-def.h (TARGET_ASM_RELOC_RW_MASK): New. (TARGET_ASM_OUT): Use it. * targhooks.c, targhooks.h (default_reloc_rw_mask): New. * varasm.c (categorize_decl_for_section): Remove shlib argument; use the new reloc_rw_mask target hook instead. (default_section_type_flags_1): Merge into... (default_section_type_flags): ... here. (decl_readonly_section_1): Merge into... (decl_readonly_section): ... here. (default_elf_select_section_1): Merge into... (default_elf_select_section): ... here. (default_unique_section_1): Merge into... (default_unique_section): ... here. (compute_reloc_for_rtx_1, compute_reloc_for_rtx): New. (default_select_rtx_section): Use it. (default_elf_select_rtx_section): Likewise. * output.h: Update to match. * doc/tm.texi (TARGET_ASM_RELOC_RW_MASK): New. * config/alpha/alpha.c (alpha_elf_reloc_rw_mask): New. (TARGET_ASM_RELOC_RW_MASK): New. * config/i386/i386.c (x86_64_elf_select_section): Adjust call to categorize_decl_for_section. (x86_64_elf_unique_section): Likewise. * config/ia64/hpux.h (TARGET_ASM_SELECT_SECTION, TARGET_ASM_UNIQUE_SECTION, TARGET_ASM_SELECT_RTX_SECTION): Remove. (TARGET_ASM_RELOC_RW_MASK): New. * config/ia64/ia64.c (ia64_rwreloc_select_section, ia64_rwreloc_unique_section, ia64_rwreloc_select_rtx_section): Remove. (ia64_hpux_reloc_rw_mask, ia64_reloc_rw_mask): New. (TARGET_RWRELOC): Remove. (ia64_section_type_flags): Adjust call to default_section_type_flags. * config/ia64/sysv4.h (TARGET_ASM_RELOC_RW_MASK): New. * config/rs6000/rs6000.c (rs6000_elf_section_type_flags): Remove. (rs6000_elf_select_section, rs6000_elf_unique_section): Remove. (rs6000_elf_reloc_rw_mask, rs6000_xcoff_reloc_rw_mask): New. (rs6000_xcoff_select_section): Use decl_readonly_section. (rs6000_xcoff_section_type_flags): Use default_section_type_flags. * config/rs6000/sysv4.h (TARGET_ASM_RELOC_RW_MASK): New. (TARGET_ASM_SELECT_SECTION, TARGET_ASM_UNIQUE_SECTION): Remove. (TARGET_SECTION_TYPE_FLAGS): Remove. * config/rs6000/xcoff.h (TARGET_ASM_RELOC_RW_MASK): New. Jack
RE: gcc 4.2 branch build failure on powerpc-apple-darwin8
It would seem we need to change... Index: gcc/config/darwin.c === /usr/local/bin/gccdiff: line 1: i#!/bin/bash: No such file or directory --- gcc/config/darwin.c (revision 122839) +++ gcc/config/darwin.c (working copy) @@ -1112,7 +1112,7 @@ machopic_select_section (tree exp, int r else base_section = weak_p ? darwin_sections[text_coal_section] : text_section; } - else if (decl_readonly_section_1 (exp, reloc, MACHOPIC_INDIRECT)) + else if (decl_readonly_section (exp, reloc)) base_section = weak_p ? darwin_sections[const_coal_section] : darwin_sections[const_section]; else if (TREE_READONLY (exp) || TREE_CONSTANT (exp)) base_section = weak_p ? darwin_sections[const_data_coal_section] : darwin_sections[const_data_section]; to cope with the removal of decl_readonly_section_1 by revision 122782. Jack
new gcc 4.2 testsuite failures on powerpc-apple-darwin8
The current gcc 4.2 branch is exhibiting some new testsuite failures in the gcc testsuite on powerpc-apple-darwin8. Specifically I now see... Running /sw/src/fink.build/gcc42-4.1.-20070312/gcc-4.2-20070312/gcc/testsuite/gcc.dg/vmx/vmx.exp ... FAIL: gcc.dg/vmx/dct.c -O0 (test for excess errors) FAIL: gcc.dg/vmx/dct.c -O1 (test for excess errors) FAIL: gcc.dg/vmx/dct.c -O2 (test for excess errors) FAIL: gcc.dg/vmx/dct.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.dg/vmx/dct.c -O3 -g (test for excess errors) FAIL: gcc.dg/vmx/dct.c -Os (test for excess errors) FAIL: gcc.dg/vmx/fft.c -O0 (test for excess errors) FAIL: gcc.dg/vmx/fft.c -O1 (test for excess errors) FAIL: gcc.dg/vmx/fft.c -O2 (test for excess errors) FAIL: gcc.dg/vmx/fft.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.dg/vmx/fft.c -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gcc.dg/vmx/fft.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gcc.dg/vmx/fft.c -O3 -g (test for excess errors) FAIL: gcc.dg/vmx/fft.c -Os (test for excess errors) which all seem to fail as follows... Executing on host: /sw/src/fink.build/gcc42-4.1.-20070312/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc42-4.1.-20070312/darwin_objdir/gcc/ /sw/src/fink.build/gcc42-4.1.-20070312/gcc-4.2-20070312/gcc/testsuite/gcc.dg/vmx/dct.c -O0 -maltivec -mabi=altivec -std=gnu99 -fno-show-colu mn -S -m32 -o dct.s(timeout = 300) /sw/src/fink.build/gcc42-4.1.-20070312/gcc-4.2-20070312/gcc/testsuite/gcc.dg/vmx/dct.c:6: warning: C99 inline functions are not supported; using GNU89 /sw/src/fink.build/gcc42-4.1.-20070312/gcc-4.2-20070312/gcc/testsuite/gcc.dg/vmx/dct.c:6: warning: to disable this warning use -fgnu89-inline or the gnu_inline function attribute output is: /sw/src/fink.build/gcc42-4.1.-20070312/gcc-4.2-20070312/gcc/testsuite/gcc.dg/vmx/dct.c:6: warning: C99 inline functions are not supported; using GNU89 /sw/src/fink.build/gcc42-4.1.-20070312/gcc-4.2-20070312/gcc/testsuite/gcc.dg/vmx/dct.c:6: warning: to disable this warning use -fgnu89-inline or the gnu_inline function attribute FAIL: gcc.dg/vmx/dct.c -O0 (test for excess errors) Any idea why we are the only target seeing these failures with gcc 4.2 branch? Jack
libgomp failures on powerpc-apple-darwin8
I am noticing one other issue with current gcc 4.2 branch on powerpc-apple-darwin8. We seem to have failures for the following libgomp testsuite tests... FAIL: libgomp.c++/pr30703.C -O0 (test for excess errors) WARNING: libgomp.c++/pr30703.C -O0 compilation failed to produce executable FAIL: libgomp.c++/pr30703.C -O1 (test for excess errors) WARNING: libgomp.c++/pr30703.C -O1 compilation failed to produce executable FAIL: libgomp.c++/pr30703.C -O2 (test for excess errors) WARNING: libgomp.c++/pr30703.C -O2 compilation failed to produce executable FAIL: libgomp.c++/pr30703.C -O3 -fomit-frame-pointer (test for excess errors) WARNING: libgomp.c++/pr30703.C -O3 -fomit-frame-pointer compilation failed to produce executable FAIL: libgomp.c++/pr30703.C -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) WARNING: libgomp.c++/pr30703.C -O3 -fomit-frame-pointer -funroll-loops compilation failed to produce executable FAIL: libgomp.c++/pr30703.C -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) WARNING: libgomp.c++/pr30703.C -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions compilation failed to produce executable FAIL: libgomp.c++/pr30703.C -O3 -g (test for excess errors) WARNING: libgomp.c++/pr30703.C -O3 -g compilation failed to produce executable FAIL: libgomp.c++/pr30703.C -Os (test for excess errors) WARNING: libgomp.c++/pr30703.C -Os compilation failed to produce executable which appear to be of the form... Executing on host: /sw/src/fink.build/gcc42-4.1.-20070312/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc42-4.1.-20070312/darwin_objdir/gcc/ /sw/src/fink .build/gcc42-4.1.-20070312/gcc-4.2-20070312/libgomp/testsuite/libgomp.c++/pr30703.C -B/sw/src/fink.build/gcc42-4.1.-20070312/darwin_objdir/powerpc-apple -darwin8/./libgomp/ -I/sw/src/fink.build/gcc42-4.1.-20070312/darwin_objdir/powerpc-apple-darwin8/./libgomp -I/sw/src/fink.build/gcc42-4.1.-20070312/gcc-4 .2-20070312/libgomp/testsuite/.. -fmessage-length=0 -fopenmp -O0 -L/sw/src/fink.build/gcc42-4.1.-20070312/darwin_objdir/powerpc-apple-darwin8/./libgomp/ .libs -lgomp -L/sw/src/fink.build/gcc42-4.1.-20070312/darwin_objdir/powerpc-apple-darwin8/./libgomp/../libstdc++-v3/src/.libs -lstdc++ -lm -m32 -o ./pr3070 3.exe(timeout = 300) /usr/bin/ld: Undefined symbols: __Unwind_Resume collect2: ld returned 1 exit status compiler exited with status 1 output is: /usr/bin/ld: Undefined symbols: __Unwind_Resume collect2: ld returned 1 exit status FAIL: libgomp.c++/pr30703.C -O0 (test for excess errors) Excess errors: /usr/bin/ld: Undefined symbols: __Unwind_Resume WARNING: libgomp.c++/pr30703.C -O0 compilation failed to produce executable Is anyone else seeing this problem? Jack ps I see this symbol in libgcc_s.1.dylib, libgcc_s.10.4.dylib and libgcc_s.10.5.dylib... nm libgcc_s.1.dylib | grep __Unwind_Resume 8bb0 T __Unwind_Resume bc68 s __Unwind_Resume.eh 8b10 T __Unwind_Resume_or_Rethrow bbc4 s __Unwind_Resume_or_Rethrow.eh nm libgcc_s.10.4.dylib | grep __Unwind_Resume 8bb0 T __Unwind_Resume 8b10 T __Unwind_Resume_or_Rethrow nm libgcc_s.10.5.dylib | grep __Unwind_Resume 8bb0 T __Unwind_Resume 8b10 T __Unwind_Resume_or_Rethrow and undefined in libstdc++.dylib... nm libstdc++.dylib | grep __Unwind_Resume U __Unwind_Resume U __Unwind_Resume_or_Rethrow So I'm a tad confused why the linker isn't resolving it.
RE: libgomp failures on powerpc-apple-darwin8
Interestingly, while... gcc-4 pr30703.C -fmessage-length=0 -fopenmp -O0 -L/sw/lib/gcc4.2/lib -lgomp -lstdc++ -lm -m32 -o ./pr30703.exe /usr/bin/ld: Undefined symbols: __Unwind_Resume collect2: ld returned 1 exit status fails on powerpc-apple-darwin8 gcc-4 pr30703.C -fmessage-length=0 -fopenmp -O0 -L/sw/lib/gcc4.2/lib -lgomp -lstdc++ -lm -m32 -shared-libgcc -o ./pr30703.exe ...links fine. On powerpc-apple-darwin8, libgcc.a is missing __Unwind_Resume. I wonder why this doesn't show up on any other architectures? Jack
Re: libgomp failures on powerpc-apple-darwin8
Jakub, So shouldn't we either XFAIL pr30703.C on *-apple-darwin* or specify that the -shared-libgcc flag should be used on that target for pr30703.C? Jack On Wed, Mar 14, 2007 at 10:11:35AM +0100, Jakub Jelinek wrote: > On Tue, Mar 13, 2007 at 10:28:41PM -0400, Jack Howarth wrote: > > Interestingly, while... > > > > gcc-4 pr30703.C -fmessage-length=0 -fopenmp -O0 -L/sw/lib/gcc4.2/lib -lgomp > > -lstdc++ -lm -m32 -o ./pr30703.exe > > /usr/bin/ld: Undefined symbols: > > __Unwind_Resume > > collect2: ld returned 1 exit status > > > > fails on powerpc-apple-darwin8 > > > > gcc-4 pr30703.C -fmessage-length=0 -fopenmp -O0 -L/sw/lib/gcc4.2/lib -lgomp > > -lstdc++ -lm -m32 -shared-libgcc -o ./pr30703.exe > > > > ...links fine. On powerpc-apple-darwin8, libgcc.a is missing > > __Unwind_Resume. I wonder why this doesn't show up > > on any other architectures? > > Because libstdc++.so links against libgcc_s.so.1 which exports that symbol > (was linked with -shared-libgcc). Or, on ELFish targets that use recent > binutils when neither -shared-libgcc nor -static-libgcc is used, > libgcc_s.so.1 is linked in --as-needed. > libgcc.a doesn't contain the unwinder on purpose, it is only in libgcc_s.so > and libgcc_eh.a, so that every binary or library doesn't have its own copy > of the unwinder (which causes severe problems). > > Jakub
Re: libgomp failures on powerpc-apple-darwin8
It looks like modifying the testsuite scripts for libgomp
to properly compile c++ files with g++ will be pretty messy.
Can we just fix PR30703 for now with the simple change...
Index: libgomp/testsuite/libgomp.c++/pr30703.C
===
/usr/local/bin/gccdiff: line 1: i#!/bin/bash: No such file or directory
--- libgomp/testsuite/libgomp.c++/pr30703.C (revision 122939)
+++ libgomp/testsuite/libgomp.c++/pr30703.C (working copy)
@@ -1,5 +1,6 @@
// PR c++/30703
// { dg-do run }
+// { dg-options "-shared-libgcc" }
#include
which at least suppresses the problem on Darwin. I'll file a PR later that
c++.exp in the libgomp/testsuite/libgomp.c++ needs to use g++ for compiling
(right now it calls gfortran-dg-runtest.exp).
Jack
gcc 4.2.0 RC1 darwin warnings...
I am a seeing the following warnings in the initial bootstrap of gcc 4.2.0 RC1 on powerpc-apple-darwin8... gcc -c -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -DHAVE_CONFIG_H -I. -I../../../gcc-4.2.0-20070316/fixincludes -I../include -I../../../gcc-4.2.0-20070316/fixincludes/../include ../../../gcc-4.2.0-20070316/fixincludes/fixincl.c In file included from ../../../gcc-4.2.0-20070316/fixincludes/fixincl.c:101: ../../../gcc-4.2.0-20070316/fixincludes/fixincl.x:77: warning: string length '4756' is greater than the length '509' ISO C89 compilers are required to support ../../../gcc-4.2.0-20070316/fixincludes/fixincl.x:229: warning: string length '552' is greater than the length '509' ISO C89 compilers are required to support ../../../gcc-4.2.0-20070316/fixincludes/fixincl.x:274: warning: string length '532' is greater than the length '509' ISO C89 compilers are required to support ../../../gcc-4.2.0-20070316/fixincludes/fixincl.x:318: warning: string length '808' is greater than the length '509' ISO C89 compilers are required to support ../../../gcc-4.2.0-20070316/fixincludes/fixincl.x:404: warning: string length '5139' is greater than the length '509' ISO C89 compilers are required to support ../../../gcc-4.2.0-20070316/fixincludes/fixincl.x:2504: warning: string length '729' is greater than the length '509' ISO C89 compilers are required to support ../../../gcc-4.2.0-20070316/fixincludes/fixincl.x:7597: warning: string length '575' is greater than the length '509' ISO C89 compilers are required to support Are these expected? Jack
using test suite outside of build directory
I am wondering if it is at all possible to coax the gcc 4.0 testsuite to run cleanly with a binary installation of gcc 4.0? That is does the testsuite absolutely have to be run from within the gcc build directory structure or can one run it standalone (to see where a given gcc 4.0 distribution sits relative to the current tests)? Jack
Re: GCC 4.0 Freeze
Even if there were complete g77 compatibility in g95, folks may want to stick with the g77 version from gcc 3.4 for awhile purely for performance reasons. In doing some test runs of the APBS Adaptive Poisson-Boltzmann Solver program, I discovered that the g95 built binary runs 60% slower than the g77 built version. This was on MacOS X 10.3.8 using the version from Feb 24, 2005. Jack
mixing gcc-4.0 and g++-3.3 generated code
The Fink project has adopted the use of the g++-3.3 compiler as their default for compiling fink packages under MacOS X 10.4. However they are allowing the default gcc compiler to remain as gcc-4.0. Are there likely to be any odd issues with mixing code from the two compiler generations? In particular, I wonder if there are likely to be any symbols in gcc-4.0 generated code that the g++-3.3 compiler would have problems resolving if it were used to do the final linking of such mixed object code. Thanks in advance for any advice. Jack
should mixed buffered i/o be indeterminant?
I have run across a problem building xplor-nih with the g95
compiler from www.g95.org from which I understand gfortran is
derived. Xplor-nih is a mix of c, c++ and fortran code. The
main calling program a c shell which call the fortran subroutines.
These fortran subroutines in turn can call the c++ code through
a c interface call. The problem I am having is that when one
redirects the output from the xplor-nih program to a file, the
buffers from the different langauges purge at different times
so that output doesn't occur sequentially as it does to a terminal.
For example, I can demonstrate this with the following code...
hello.f
--
SUBROUTINE HELLO
INTEGER CPLUS_OUTPUT
EXTERNAL CPLUS_OUTPUT
INTEGER SHELL
WRITE(6,'(A)') ' before output from c++ code'
SHELL=CPLUS_OUTPUT()
WRITE(6,'(A)') ' after output from c++ code'
RETURN
END
cplus_output.cc
#include
#define FORTRAN(x) (x ## _)
extern "C" void
FORTRAN(cplus_output)()
{
for (int i=0 ; i<1 ; i++)
cout << "Ouput from c++ of line number: " << i << "\n";
}
-
main.c
-
#include
#define FORTRAN(x) (x ## _)
void g95_runtime_stop(void);
void FORTRAN(hello)();
main()
{
FORTRAN(hello)();
g95_runtime_stop();
return 0;
}
--
If I build the above...
g95 -o hello.o -fno-second-underscore -c hello.f
g++ -o cplus_output.o -c cplus_output.cc
gcc main.c hello.o cplus_output.o ./libf95.a libf95.a
and then execute it...
./a.out > outputfile
I find that instead of having the c++ output in front and after the
fortran output, the c++ output randomly appears in the fortran output.
Andy Vaught tells me...
> If you're outputting from both the fortran and c++ side, the result is
>not determinate. It will depend on when the fortran and C libraries
>decide to flush output. That would very easily account for interleaved
>lines.
However xplor-nih has been built on at least seven different operating
systems with a number of different compilers (gnu, Intel, IBM, Portland,
SGI and Sun) and none of these have suffered this lack of synchronization
in the mixed language i/o. Can anyone clarify what the standard should
really be and if g95's i/o buffering is simply broken at the moment?
Jack
could gfortran be tested on Darwin regress builds of 4.1?
Since gfortran is making such good progress at this point, it would seem like a really good idea for Apple to add the gfortran build to its builds on regress. It would make is easier for Mac users to tell what the expected status is of gfortran on Darwin. Thanks in advance for considering this. Jack
Re: could gfortran be tested on Darwin regress builds of 4.1?
Geoffrey, Well the gcc4.info for the package containing gfortran in fink has... Depends: gmp-shlibs (>= 4.1.3-11), cctools (>= 576-1) | odcctools (>= 576-200503 27), %N-shlibs, libiconv BuildDepends: gmp (>= 4.1.3-11), libiconv-dev which is a tad confusing since I guess it implies that cctools isn't needed to build gcc4/gfortran but is needed to use it. That seems weird since to build it and do a make check is to effectively use it. Jack
strange error on gcc 4.1.0
I am trying to build xplor-nih on MacOS X 10.4 using gcc 4.1.0 branch's gcc and g++ instead of Apple's and am running into a really strange error. I find the following linkage fails... g++-4 -bundle -flat_namespace -undefined suppress _xplorWrap.o libswigpy-xplor.dylib -o _xplorWrap.so -L/Users/howarth/Desktop/xplor-nih-2.11.2.1/bin.Darwin_8/ -lcommon -lnmrPot -lintVar -lvmd -lpy -lswigpy-xplor \ -lcrypto -L/Users/howarth/Desktop/xplor-nih-2.11.2.1/bin.Darwin_8/ g++-4: couldn't run 'undle-gcc-4.1.0': No such file or directory I can't find any evidence of a undle-gcc-4.1.0 file in my build directory for the current gcc main trunk cvs from which I built the installed gcc 4.1.0 compiler. Shouldn't the stock gcc 4.1.0 support the -bundle flag? Any idea why this flag isn't working? Jack
Re: strange error on gcc 4.1.0
Andreas, Are you sure gnu gcc shouldn't support this? I see -bundle under the Machine Dependent Options under Darwin options which are not marked as APPLE-ONLY. I understood that to mean that it should be present in the gnu gcc compiler (like -all_load which is in the same list and is supported). Fortunately MacOS X 10.4 now supports a more linux-like dyload that can use standard dynamic libraries .so files instead of just bundles for shared library modules. Jack
Re: strange error on gcc 4.1.0
I can't find a patch either using google but I did find the following posting which describes the problem and a workaround... http://www.mail-archive.com/fink-devel@lists.sourceforge.net/msg10604.html Jack
Re: strange error on gcc 4.1.0
Here is another posting which describes the problem a little clearer... http://lists.apple.com/archives/darwin-development/2003/Jun/msg0.html So gcc needs to be fixed to not misparse -bundle, when it is the first argument to gcc, as being the "-b Machine" target option. Shouldn't the fix be fairly simple? Just requiring that the code that recognizes the -b flag require a trailing space after the -b flag...otherwise it passes over it so that -bundle could be recognized? Jack
Re: strange error on gcc 4.1.0
Thanks. It applies with offsets to the current 4.0 branch. Hopefully we can get it in both branches soon. Currently everyone on Darwin is just hacking their Makefiles around the problem. Jack
-b vs -bundle
In compiling xplor-nih under the gcc/g++ of 4.1 branch instead of Apple's gcc/g++ 4.0 compilers from Xcode 2.1, I noticed that the gnu gcc compiler doesn't gracefully handle the -bundle flag. On Apple's compiler I can have a Makefile entry like... createSharedModule = $(CXX) -bundle \ -flat_namespace -undefined suppress $^ -o $@ and it compiles the shared module without error. However I see the error... g++-4 -bundle -flat_namespace -undefined suppress _xplorWrap.o libswigpy-xplor.dylib -o _xplorWrap.so -L/Users/howarth/Desktop/xplor-nih-2.11.2.1/bin.Darwin_8/ -lcommon -lnmrPot -lintVar -lvmd -lpy -lswigpy-xplor \ -lcrypto -L/Users/howarth/Desktop/xplor-nih-2.11.2.1/bin.Darwin_8/ g++-4: couldn't run 'undle-gcc-4.1.0': No such file or directory with the gnu gcc compiler. I noticed that you rejected a proposed patch a few years ago... http://gcc.gnu.org/ml/gcc-patches/2002-12/msg00655.html http://gcc.gnu.org/ml/gcc-patches/2002-10/msg01961.html Could you revisit this issue and see if something could be done for 4.0 and 4.1 branch? I would think that either the compiler should require the -b flag to have a space before the machine name. Alternatively if the gnu gcc compiler mustn't allow -bundle to be the first argument passed to the compiler, it should at least treat that as a defined error rather than producing the cryptic one it does now. Thanks in advance for looking at this again. Jack
Re: -b vs -bundle
Geoff, What I don't understand is how Apple's compiler can parse the -bundle as the first argument and the gnu gcc compiler can't. Shouldn't the same mechanism Apple uses to allow this to work be backportable into gnu gcc? Jack
Re: -b vs -bundle
Geoff, The problem is that I haven't ever submitted any paperwork so anything I touch will be tainted. If you could post a revised patch that applies to gcc main trunk, I'll test it locally and confirm that it works. Jack
does -fstack-protector work for gcc 4.1 on Darwin 8?
Does anyone know if the -fstack-protector option in gcc 4.1 branch works on Darwin 8 (Tiger)? I can compile binaries with it but I'm not sure how to test its functionality. Also, this is based on IBM's ProPolice code, right? Jack
Re: does -fstack-protector work for gcc 4.1 on Darwin 8?
Eric, Well what I have is a gfortran 4.1 branch fink package built using the 20050728 cvs with the new cray pointer patches donated by LANL. What I am trying to do is the following. I have been trying to build xplor-nih (which is a mix of c, c++ and fortran) with gfortran (it works okay with g77 or xlf). The new problem I have run into is some stack and heap corruption with both gfortran from 4.0 and 4.1 branch. The current suspect is the new cray pointer patches for Fortran which provide the necessary LOC intrinsic. My hope is that if compile xplor-nih with -fstack-protector on the fortran code when the stack is going to be corrupted it will throw a runtime error thus identify the culprit. Does this sound like a valid use of -fstack-protector? Jack ps As a test I built the cp_test.f90 cray pointer test program under gfortran with -fstack-protector. The resulting program passed its tests but I have no idea if that means the stack protector code itself was functional.
Re: does -fstack-protector work for gcc 4.1 on Darwin 8?
Richard, Do you think I should be able to build gcc itself with the -fstack-protector flag and what is the most appropriate way to achieve that (ie brute force using a CFLAG or some configure flag)? I am interested in doing this so that I can have a libgfortran built with -fstack-protector to try to track down a potential stack corruption problem. Thanks in advance for any advice. Jack
Re: does -fstack-protector work for gcc 4.1 on Darwin 8?
Richard, Is there some sample code that one can use to test the functionality of the code generated by -fstack-protector? Also, if one has a buggy program that is corrupting the stack, what is the expected behavior of this program when compiled with the stack protection code? Should it always abort at runtime with a userful error message or will it manage to suppress the stack corruption and keep on running. I was hoping to use the stack protection code as way to flag the position of offending code that was corrupting the stack rather than mask the corruption itself. Thanks in advance for any clarifications. Jack
can -fstack-protector-all be used to find leaks
Is it possible to leverage the new -fstack-protector-all feature in gcc 4.1 branch to discover the origin of memory leaks that are clobbering the stack? I have a fortran program which segfaults in the next write it attempts after a particular read. I have compiled this fortran code with -fstack-protector-all and the segfault is suppressed and replaced with a runtime error 02 exit of the program. Since the problem seems to occur during a fortran read call, I have rebuilt the gcc 4.1 branch libgfortran using the -fstack-protector-all option and will try debugging the fortran program with that library in place. What I am uncertain about is exactly what behavior I should expect from the code generated by -fstack-protector-all. My hope is that I will see a runtime error generated by the stack protector code in libgfortran's io routines when the stack gets clobbered. Is this scenario reasonable or am I expecting too much from the stack protector code? Thanks in advance for any insights on this issue. Jack
Re: [gfortran] add ISATTY and TTYNAM intrinsics
FX,
I forgot to mention that since the gcc cvs I built last night now
contains your ISATTY and TTYNAM intrinsics patch, I regressed the
portion of the xplor.patch which worked around the prior absence
of the ISATTY intrinsic in gfortran. The resulting xplor-nih build
works fine.
One other question. Do you know much c++? I had to make one change
to some buggy c++ code to allow gcc 4.0 and main branch to compile
xplor-nih...
--- xplor-nih-2.11.2.1/intVar/dint-loop.cc 2004-04-16 18:06:07.0 -0
400
+++ xplor-nih-2.11.2.1.g95/intVar/dint-loop.cc 2005-07-24 17:41:11.0 -0
400
@@ -50,6 +50,8 @@
tip1(tip1), tip2(tip2)
{} /* Loop::Loop */
+class LoopWNodes;
+
static int compareLevel(const LoopWNodes& l1,//forward declarations
const LoopWNodes& l2);
//static bool sameBranch(const HingeNode* tip,
...to work around the problem described in...
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159445
With that change, all of the c++ code in xplor-nih compiles against
gcc 4.0 branch, however I find that gcc main branch yields another
compilation error...
g++-4 -fstack-protector-all -c _cdsVector.cc -O3 -fPIC -mtune=970 -g
-DX_MMAP_FLAGS=0 -DFORTRAN_INIT -fno-common -DDARWIN -D_REENTRANT -
DNDEBUG -I/Users/howarth/Desktop/xplor-nih-2.11.2.1/python/ -I/Users/
howarth/Desktop/xplor-nih-2.11.2.1/arch/Darwin_8/include -I/Users/
howarth/Desktop/xplor-nih-2.11.2.1/python/swig_wrappers -DCPLUSPLUS -
DUSE_CDS_NAMESPACE -I/Users/howarth/Desktop/xplor-nih-2.11.2.1/
python/ -I/Users/howarth/Desktop/xplor-nih-2.11.2.1/arch/Darwin_8/
include -DSWIGPY_GLOBAL -I. -I/System/Library/Frameworks/
Python.framework/Versions/2.3/include/python2.3 -I/Users/howarth/
Desktop/xplor-nih-2.11.2.1/CDSlib -I/Users/howarth/Desktop/xplor-
nih-2.11.2.1/common -I/Users/howarth/Desktop/xplor-nih-2.11.2.1/
intVar -I/Users/howarth/Desktop/xplor-nih-2.11.2.1/nmrPot -I/Users/
howarth/Desktop/xplor-nih-2.11.2.1/vmd -I/Users/howarth/Desktop/xplor-
nih-2.11.2.1/devel -DNIHXPLOR_VERSION='"2.11.2.1-custom"' -
DSWIGPY_NOINCLUDE )
_cdsVector.cc: In function 'CDSVector
CDSVector_Sl_int_Sgpow__(CDSVector*,
const float_type&)':
_cdsVector.cc:1155: warning: converting to 'int' from 'double'
/Users/howarth/Desktop/xplor-nih-2.11.2.1/CDSlib/cdsVector.hh: In
member function 'CDSVectorBase& CDSVectorBase::operator*=(const T1&) [with T1 = double, T = int, ALLOC =
CDS::DefaultAlloc]':
_cdsVector.cc:1159: instantiated from here
/Users/howarth/Desktop/xplor-nih-2.11.2.1/CDSlib/cdsVector.hh:239:
warning: converting to 'int' from 'double'
_cdsVector.cc: In function 'T sum(const CDSVector&) [with T = int]':
_cdsVector.cc:2408: instantiated from here
_cdsVector.cc:913: warning: converting to 'int' from 'double'
_cdsVector.cc: In function 'CDSVector
sqrt(const CDSVector&) [with T = int]':
_cdsVector.cc:2457: instantiated from here
_cdsVector.cc:924: error: no matching function for call to 'norm
(const int&)'
_cdsVector.cc: In function 'CDSVector
norm(const CDSVector&) [with T = int]':
_cdsVector.cc:2510: instantiated from here
_cdsVector.cc:933: error: no matching function for call to 'norm
(const int&)'
_cdsVector.cc: In function 'CDSVector
sqrt(const CDSVector&) [with T = double]':
_cdsVector.cc:3945: instantiated from here
_cdsVector.cc:924: error: no matching function for call to 'norm
(const double&)'
_cdsVector.cc: In function 'CDSVector
norm(const CDSVector&) [with T = double]':
_cdsVector.cc:3998: instantiated from here
_cdsVector.cc:933: error: no matching function for call to 'norm
(const double&)'
which compares to gcc 4.0 branch that just yields some warnings on
the same file...
_cdsVector.cc: In function 'CDSVector
CDSVector_Sl_int_Sgpow__(CDSVector*, const
float_type&)':
_cdsVector.cc:1155: warning: converting to 'int' from 'double'
./cdsVector.hh: In member function 'CDSVectorBase& CDSVectorBase::operator*=(const T1&) [with T1 = double, T = int, ALLOC = CDS::
DefaultAlloc]':
_cdsVector.cc:1159: instantiated from here
./cdsVector.hh:239: warning: converting to 'int' from 'double'
_cdsVector.cc: In function 'T sum(const CDSVector&)
[with T = int]':
_cdsVector.cc:2408: instantiated from here
_cdsVector.cc:913: warning: converting to 'int' from 'double'
I am trying to figure out if this is catching some new buggy c++ which
is no longer accepted by the g++ compiler in gcc 4.1 or if this is a
regression in that branch.
Jack
many libgcc in MacOS X 10.4 build
What exactly are all of the new libgcc versions created when building the current gcc cvs on MacOS X 10.4. I find that I have... -rw-r--r-- 1 root admin 20732 Oct 13 23:08 libgcc_s.10.4.dylib -rw-r--r-- 1 root admin 20968 Oct 13 23:08 libgcc_s.10.5.dylib -rw-r--r-- 1 root admin 240636 Oct 13 23:08 libgcc_s_ppc64.1.dylib -rw-r--r-- 1 root admin 209796 Oct 13 23:08 libgcc_s.1.dylib Particularly curious is the libgcc_s.10.5.dylib. Is there some specific feature that won't be functional in gcc until MacOS X 10.5? Jack
gcc 4.1 release showstopper on darwin
In case folks haven't noticed, there has been major breakage of the gfortran in gcc 4.1 on Darwin. The problem appears to be due to the fact that weakrefs aren't properly honored in the Darwin linker. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24991 This apparently is the same issue causing the attr-weakref-1.c and weak-14.c test failures in the gcc testsuite. Unfortunately, libgfortran now relies on weakrefs properly working and thus severely breaks gfortran on Darwin. My question is whether the gcc 4.1 release would be held to fix this or will the Darwin target just be marked as broken for that release? Jack
Re: gcc 4.1 release showstopper on darwin
David, Thanks for the clarification. While one could argue that the breakage was due to an aggressive introduction of changes into gfortran of the gcc 4.1 branch, it is definitely is more honest to say that the Darwin target has been broken for sometime now with the weakref failures in the gcc testsuite. Jack
new c++ restrictions?
For the last few months, gcc 4.1 has had problems compling
the following code in posRMSDPot.cc in xplor-nih...
IStringStream iNoComments( stripped );
// read NOEPot table
CDSStringStreamBuf dum;
while ( !iNoComments.eof() && !iNoComments.fail() ) {
String word; iNoComments >> word;
if ( word.glob("assi*",1) ) {
PosRMSDPot_Restraint* restraint = new PosRMSDPot_Restraint(this);
iNoComments >> *restraint;
if ( restraint->ok() ) {
restraints_.append( restraint );
if (verbose())
cout << "PosRMSDPot::addRestraints: added restraint: "
<< *restraint << '\n';
} else {
cout << "PosRMSDPot::addRestraints: error adding restraint.\n";
delete restraint;
which generates an error...
posRMSDPot.cc: In member function 'void PosRMSDPot::addRestraints(const
String&)':
posRMSDPot.cc:145: error: no match for 'operator>>' in 'iNoComments >> *
restraint'
/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin8/4.1.0/../../../../include/c++/4.1.0/istream:131:
note: candidates are: std::basic_istream<_CharT, _Traits>&
std::basic_istream<_CharT, _Traits>::operator>>(std::basic_istream<_CharT,
_Traits>& (*)(std::basic_istream<_CharT, _Traits>&)) [with _CharT = char,
_Traits = std::char_traits]
/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin8/4.1.0/../../../../include/c++/4.1.0/istream:134:
note: std::basic_istream<_CharT, _Traits>&
std::basic_istream<_CharT, _Traits>::operator>>(std::basic_ios<_CharT,
_Traits>& (*)(std::basic_ios<_CharT, _Traits>&)) [with _CharT = char, _Traits =
std::char_traits]
etc...
which is the line "iNoComments >> *restraint;". There also is a compile error
at...
posRMSDPot.cc:150: error: no match for 'operator<<' in 'std::operator<< [with
_Traits = std::char_traits](((std::basic_ostream >&)(& std::cout)), ((const
char*)"PosRMSDPot::addRestraints: added restraint: ")) << * restraint'
/sw/lib/gcc4/lib/gcc/powerpc-apple-darwin8/4.1.0/../../../../include/c++/4.1.0/bits/ostream.tcc:67:
note: candidates are: std::basic_ostream<_CharT, _Traits>&
std::basic_ostream<_CharT, _Traits>::operator<<(std::basic_ostream<_CharT,
_Traits>& (*)(std::basic_ostream<_CharT, _Traits>&)) [with _CharT = char,
_Traits = std::char_traits]
which is the line " << *restraint << '\n';". Any ideas why this breakage has
occured and what the proper workaround is? GCC 4.0.2 doesn't have a problem
with this source as did GCC 4.1 until a few months back.
Jack
new gcc/g++ 4.1.0 flags?
Where exactly are the compiler flags new to gcc 4.1.0 described. I now understand that -ffriend-injection can be used with g++ to overcome the new strictness about the scope of friends. However, I am seeing another compile error in xplor-nih of the form... cdsVector.cc: In function 'CDSVector CDSVector_Sl_int_Sgpow__(CDSVector*, const float_type&)': _cdsVector.cc:1173: warning: converting to 'int' from 'double' /Users/howarth/Desktop/xplor-nih-2.12/CDSlib/cdsVector.hh: In member function 'CDSVectorBase& CDSVectorBase::operator*=(const T1&) [with T1 = double, T = int, ALLOC = CDS::DefaultAlloc]': _cdsVector.cc:1177: instantiated from here /Users/howarth/Desktop/xplor-nih-2.12/CDSlib/cdsVector.hh:242: warning: converting to 'int' from 'double' _cdsVector.cc: In function 'T sum(const CDSVector&) [with T = int]': _cdsVector.cc:2426: instantiated from here _cdsVector.cc:913: warning: converting to 'int' from 'double' _cdsVector.cc: In function 'float_type norm(const CDSVector&) [with T = double]': _cdsVector.cc:6004: instantiated from here _cdsVector.cc:942: error: no matching function for call to 'norm(const double&)' which -ffriend-injection doesn't solve. It would be nice if gcc 4.1.0 clearly listed the new areas of c++ strictness and which compile flag can be used to override the new behavior. Thanks in advance for any clarifications. Jack
identifying c++ aliasing violations
In compiling xplor-nih under gcc 4.1 (it is a mix of c, c++ and fortran) I discovered one of its c++ source files causes segfaults at optimization levels higher than -O1 unless I add -fno-strict-aliasing to the compile flags. In that case, there program passes all of its testsuite without any segfaults. Unfortunately, the offending source file, dint-node.cc, doesn't result in any warnings with -Wstrict-aliasing. Is there any documentation on how to debug aliasing rule violations in such cases where g++ is unable to produce any warnings? Are there any tutorials or documentation on how to debug such situations? Thanks in advance for any advice. Jack
c++ speed 3.3/4.0/4.1
In benchmarking a build of xplor-nih (which is a mix of c++,c, and fortran) built entirely under gcc 4.1 or built using gcc 4.1's gfortran and either Apple's gcc 4.0.1 or gcc 3.3, I have noticed that there was a significant speed regression in the c++ code generation between gcc 3.3 and gcc 4.0.x. The 4.0 binaries execute 15% slower (which is why the xplor-nih developer still builds his distributions against g++-3.3 instead of g++-4.0). I was happy to see some recovery in the c++ code generation with gcc 4.1. Now xplor-nih only exhibits a 7% speed loss using g++-4.1 compared to g++-3.3. I assume this is due to the total rewrite of the optimizers in gcc > 4.0. Is there any tricks on can use to coax the c++ performance from the g++ 4.1 to be equivalent to that seen in g++-3.3 or will we have to wait for later versions of gcc for that? Jack
Re: identifying c++ aliasing violations
Richard, I built current gcc 4.2 branch under MacOS X 10.4.3 and unfortunately while -Wstrict-aliasing does catch the error from PR 14024, it doesn't catch whatever strict aliasing error exists in dint-node.cc of xplor-nih. Is there a list somewhere of all those strict aliasing violations which aren't checked for yet in gcc 4.2? Jack
Re: identifying c++ aliasing violations
Richard, Actually, while the currently offending file, dint-node.cc which must be built with -fno-strict-aliasing, doesn't report any strict aliasing violations in gcc 4.2, I do find that the rest of xplor-nih is filled with them. I will report these upstream. They seem to all be of the form.. swigpy.cc: In function 'int SWIGPY_Python_ConvertPtr(PyObject*, void**, swig_typ e_info*, int)': swigpy.cc:620: warning: dereferencing type-punned pointer will break strict-alia sing rules swigpy.cc: In function 'PyObject* SWIGPY_Python_NewPointerObj(void*, swig_type_i nfo*, int)': swigpy.cc:707: warning: dereferencing type-punned pointer will break strict-alia sing rules What exactly is the implication of having a hundred or more of this in an application being built with gcc/g++ 4.x at -O3? Does it only risk random crashes in the generated code or does it also impact the quality of the generated code in terms of execution speed? Jack
Re: identifying c++ aliasing violations
Giovanni, I'll see what I can do in terms of profiling the xplor-nih code with Shark on MacOS X. However in the near term, I would strongly urge the gcc developers to backport the changes necessary to have -Wstrict-aliasing issue warnings for c++ in gcc 4.1. I rebuilt xplor-nih under gcc trunk (4.2) last night and the python and tcl interface modules (built using SWIG 1.3.22) are filled with literally hundreds of warnings that are not shown when the swig c++ code is compiled with gcc 4.0/4.1. It seems a shame to not provide developers upstream with that sort of information until gcc 4.2 is released. Jack
more strict-aliasing questions
Is there some place where all the existing forms of strict-aliasing warnings are documented? So far I have only seen the error... dereferencing type-punned pointer will break strict-aliasing rules when building c++ code with gcc trunk (4.2). I am wondering how many other types of warnings can -Wstrict-aliasing issue besides this one for gcc and of those how many of those are currently checked in the g++ compiler? My second question is how univeral are the strict-aliasing rules used by gcc? In other words, is it safe to say that by correcting source code upstream to not violate any of the strict-aliasing rules in gcc trunk that such code might achieve stability benefits as well on other third party compilers? Or are these strict-aliasing rules pretty much gcc-specific? Thanks in advance for any clarifications. Jack
Re: c++ speed 3.3/4.0/4.1
Mike, Do you mean using -fno-threadsafe-statics or do you have any other inlining changes in mind? Jack
Re: c++ speed 3.3/4.0/4.1
Well I tried a few different builds of xplor-nih tonight with the following optimization flags for the gcc and g++ compilers... testsuite in seconds xplorpython tcl -O3 -ffastmath -mtune=970 137.5454 128.7770 48.0390 -O3 -ffastmath -mtune=970 -fno-threadsafe-statics 137.0741 127.4653 48.0205 -O3 -ffastmath -mtune=970 -finline-limit=1200135.4462 127.5790 48.3680 As you can see the c/c++ code (mostly c++) in xplor-nih is immune to improvement in gcc 4.2.0 with the -fno-threadsafe-statics and -finline-limit=1200. The same build using Apple's gcc 3.3 would execute about 7% faster. Is there anything not usually enabled in -O3 that might help? I am rather confused by the options... -ftree-vectorize -fipa-cp and the rest as to which ones are part of -O3 in gcc 4.2.0 and which require enabling (as well as which are incompatible with each other). I would be interested in trying to squeeze some more performance out of the gcc 4.2.0 compiles but am at a loss for the logical approach to doing this (short of resorting to -fprofile-use). Thanks in advance for any other advice. Jack
_Pragma3.c failure on gcc 4.1 branch for darwin 8.4.0
I am seeing a new failure in the gcc testsuite for the gcc 4.1 branch built on MacOS X 10.4.4... Running /sw/src/fink.build/gcc4-4.1.0-20060114/gcc-4.1-20060114/gcc/testsuite/gcc.dg/cpp/cpp.exp ... FAIL: gcc.dg/cpp/_Pragma3.c (test for excess errors) Is this expected? None of the other architectures seem to be showing this and no one is posting test results for the 4.1 branch on MacOS X these days. Jack
Re: _Pragma3.c failure on gcc 4.1 branch for darwin 8.4.0
Joseph, Thanks for the hint. Correcting the timestamps with... contrib/gcc_update --touch ...eliminated the failure in _Pragma.c. However I am still baffled as to why this was necessary since I was building from a clean svn pull of the gcc 4.1 branch using svn 1.3.0. Is svn that broken that I need to manually correct the timestamps after every pull? Jack
Bug 66848 - boehm-gc fails test suite on x86_64-apple-darwin15
Does anyone know which upstream boehm-gc release FSF gcc's copy was last synchronized against? The system libunwinder.dylib (providing the compatibility unwinder on darwin) has been recompiled, without source changes, in OS X 10.11 El Capitan. This recompilation with the newer Apple clang 7.0 compiler has broken the boehm-gc test suite on darwin15... https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66848 as demonstrated by the fact that substituting the libunwind.dylib from darwin14 on darwin15 eliminates the boehm-gc test suite failures. Apple considers the optimization changes made by the Clang 7.0 compiler to the compatibility unwinder in libunwind.dylib to be safe and believes that it tickles a latent bug in FSF gcc's boehm-gc. The upstream release for boehm-gc 7.2 through 7.4.2 all build fine and pass their test suite on darwin15. Looking at the sources, it seems that the current boehm-gc is based on upstream gc 7.1 or earlier so perhaps updating the FSF gcc's boehm-gc to 7.2 or later may help resolve this issue. Jack
Re: LLVM to get massive GPU support with Fortran
On Mon, Nov 16, 2015 at 2:14 PM, Toon Moene wrote: > On 11/16/2015 12:58 AM, Steve Kargl wrote: > >> On Mon, Nov 16, 2015 at 12:04:06AM +0100, Thomas Koenig wrote: > > >>> See >>> >>> >>> http://arstechnica.com/information-technology/2015/11/llvm-to-get-fortran-compiler-that-targets-parallel-gpus-in-clusters/ >>> >>> It is not entirely clear on what they plan to do. >>> >>> Use gfortran via dragonegg? > > >> The 3 DOE labs in the USA have contracted PGI to port >> (some of) there Fortran FE to LLVM and open source the >> result. >> >> http://lists.llvm.org/pipermail/llvm-dev/2015-November/092404.html > > > To put this in a (timeline) perspective: > > On the 18th of March, 2000, I announced Andy Vaught's work on the g95 > front-end to the gcc-patches mailing list. > > In 2004 (!) we merged the resulting compiler and run-time library into the > gcc (cvs) repository (obviously, after the tree-ssa infrastructure went in - > 2004-05-17, but before the creation of the 4.0 release branch - 2005-02-25). > Then it took another 2 months for 4.0 to be released. > > Unless PGI manages to summon massively large (parallel) working groups to > accomplish this, it might take a few years to fruition. > On the other hand, the llvm-dev posting implies that PGI will be starting from an existing fortran front-end. If they only need to code the middle-/back-end integration of llvm into a pre-existing mature fortran front-end, the promised late 2016 release date might not be so unlikely. > -- > Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 > Saturnushof 14, 3738 XG Maartensdijk, The Netherlands > At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ > Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: LLVM to get massive GPU support with Fortran
On Mon, Nov 16, 2015 at 4:19 PM, Toon Moene wrote: > On 11/16/2015 10:11 PM, Jack Howarth wrote: > >> On Mon, Nov 16, 2015 at 2:14 PM, Toon Moene wrote: > > >>> To put this in a (timeline) perspective: >>> >>> On the 18th of March, 2000, I announced Andy Vaught's work on the g95 >>> front-end to the gcc-patches mailing list. >>> >>> In 2004 (!) we merged the resulting compiler and run-time library into >>> the >>> gcc (cvs) repository (obviously, after the tree-ssa infrastructure went >>> in - >>> 2004-05-17, but before the creation of the 4.0 release branch - >>> 2005-02-25). >>> Then it took another 2 months for 4.0 to be released. >>> >>> Unless PGI manages to summon massively large (parallel) working groups to >>> accomplish this, it might take a few years to fruition. >>> >> >> On the other hand, the llvm-dev posting implies that PGI will be >> starting from an existing fortran front-end. If they only need to code >> the middle-/back-end integration of llvm into a pre-existing mature >> fortran front-end, the promised late 2016 release date might not be so >> unlikely. > > > The g95 front-end I mentioned in my 2000-03-18 post to the gcc-patches > mailing list was "an existing front-end" by virtue of the fact that Andy > Vaught mailed it to me and it did the work. > > Between 2000 and 2004, this front-end was coupled to the rest of the > infrastructure of the GNU Compiler Collection. This was not trivial (just as > it will not be trivial to couple the PGI front-end to the LLVM > infrastructure). > > We'll see how many years it'll take, but don't count me in on holding my > breath. > Of course one unknown is whether PGI had already done any work internally with the llvm middle-/back-end. If so, they might not be starting from scratch. > > -- > Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 > Saturnushof 14, 3738 XG Maartensdijk, The Netherlands > At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ > Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: LLVM to get massive GPU support with Fortran
On Mon, Nov 16, 2015 at 4:35 PM, Toon Moene wrote: > On 11/16/2015 10:33 PM, Jack Howarth wrote: > >> Of course one unknown is whether PGI had already done any work >> internally with the llvm middle-/back-end. If so, they might not be >> starting from scratch. > > > Perhaps it helps if I repost the following from 12 years ago: > > https://gcc.gnu.org/ml/fortran/2003-11/msg00052.html > > Kind regards, > FYI, this posting has a bit more detail on the actual implementation... http://lists.llvm.org/pipermail/llvm-dev/2015-November/092438.html > > -- > Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 > Saturnushof 14, 3738 XG Maartensdijk, The Netherlands > At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ > Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: LLVM to get massive GPU support with Fortran
On Mon, Nov 16, 2015 at 5:24 PM, Andrew Pinski wrote: > On Mon, Nov 16, 2015 at 2:09 PM, Toon Moene wrote: >> On 11/16/2015 11:02 PM, Jack Howarth wrote: >> >>> FYI, this posting has a bit more detail on the actual implementation... >>> >>> http://lists.llvm.org/pipermail/llvm-dev/2015-November/092438.html >> >> >> That surely helps - thanks. > > > Basically NVIDIA bought PGI and now is open source their fortran > front-end. Nothing magical really. > Basically NVIDIA is trying to have the "community" do more of their > development for them. > This is an anti-open/free source way of doing things. > Well, if Nvidia/PGI wanted to shift their fortran compiler to use llvm for its GPU support, they were bound to open source it. The whole model for llvm is based on vendors wanting to work within the open source tree because of the pain involved in maintaining independent forks based on llvm (due to the heavy upstream churn). > Thanks, > Andrew > >> >> >> -- >> Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 >> Saturnushof 14, 3738 XG Maartensdijk, The Netherlands >> At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ >> Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: Second GCC 6.1 Release Candidate available from gcc.gnu.org
Shouldn't there also be a back port of...
r235231 | bje | 2016-04-19 20:44:21 -0400 (Tue, 19 Apr 2016) | 2 lines
Attach PR number to most recent entry.
r235222 | bje | 2016-04-19 17:08:47 -0400 (Tue, 19 Apr 2016) | 3 lines
* testsuite/lib/libjava.exp (libjava_arguments): Use 'file
normalize' rather than the defunct DejaGnu 'absolute' proc.
and perhaps...
r235372 | clyon | 2016-04-22 15:28:58 -0400 (Fri, 22 Apr 2016) | 7 lines
[testsuite] gcc-dg: handle all return values when shouldfail is set
2016-04-22 Christophe Lyon
* lib/gcc-dg.exp (${tool}_load): Add default return value handler.
for dejagnu 1.6 compatibility?
On Sat, Apr 23, 2016 at 11:20 AM, Jakub Jelinek wrote:
> The second release candidate for GCC 6.1 is available from
>
> ftp://gcc.gnu.org/pub/gcc/snapshots/6.0.1-RC-20160423
>
> and shortly its mirrors. It has been generated from SVN revision 235378.
>
> I have so far bootstrapped and tested the release candidate on
> x86_64-linux and i686-linux. Please test it and report any issues to
> bugzilla.
>
> We have a P1 AIX bootstrap issue reported, but I haven't managed to
> reproduce it, so this release candidate does not deal with that.
>
> If all goes well, I'd like to release 6.1 next week.
Re: libgomp on 32-bit darwin
FX, No problem here x86_64-apple-darwin15 with a build using... $ gcc-fsf-6 -v Using built-in specs. COLLECT_GCC=gcc-fsf-6 COLLECT_LTO_WRAPPER=/sw/lib/gcc6/libexec/gcc/x86_64-apple-darwin15.5.0/6.1.0/lto-wrapper Target: x86_64-apple-darwin15.5.0 Configured with: ../gcc-6.1.0/configure --prefix=/sw --prefix=/sw/lib/gcc6 --mandir=/sw/share/man --infodir=/sw/lib/gcc6/info --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-mpc=/sw --with-system-zlib --program-suffix=-fsf-6 Thread model: posix gcc version 6.1.0 (GCC) $ file /sw/lib/gcc6/lib/i386/libgomp.1.dylib /sw/lib/gcc6/lib/i386/libgomp.1.dylib: Mach-O dynamically linked shared library i386 Jack On Tue, May 3, 2016 at 4:13 AM, FX wrote: > Hi all, > > It seems that, by default, a build of GCC on x86_64-apple-darwin15 will build > 64-bit libgomp but not 32-bit libgomp. Is that intended? What should one do > to explicitly enable libgomp on 64-bit? > > my configure is simply: ../gcc-6.1.0/configure --prefix=/usr/local/gfortran > --with-gmp=/Users/fx/devel/gcc/deps-static/x86_64 > --enable-languages=c,c++,fortran,objc,obj-c++ --build=x86_64-apple-darwin15 > > Thanks, > FX >
Re: Legal paperwork for GCC contributions
On Sun, Nov 23, 2014 at 06:48:53PM -0500, Lawrence Velázquez wrote: > Hi, > > I recently contributed some fixes against GCC trunk, gcc-4_9-branch, and > gcc-4_8-branch for which I need the requisite legal paperwork. > > However, I'd like to backport these particular fixes to the MacPorts > Project's ports of Apple GCC 4.2 and LLVM-GCC 4.2, which are licensed > under "version 2, or (at your option) any later version" of the GPL. We > would like the software provided by these ports to remain > GPLv2-licensed. > > Given this, what would be the best way for me to handle copyright? > > Thanks, > vq Lawrence, Is this even an issue considering that MacPorts is only applying these fixes as patches on final source releases of the Apple GCC 4.2 and LLVM-GCC 4.2 compilers and there is zero chance of those ever making their way into an actively maintained source tree for either compiler? Jack
Serious Regressions tables on https://gcc.gnu.org
Is there a reason why the Serious Regressions tables, displayed by the links in the 'Release Series and Status' section at https://gcc.gnu.org, no longer have a column for the priority (importance) of each bug? We used to have that and it was quite nice to be able to click on the priority column header to regenerate the table sorted by bug priority (to quickly see how many P1s are open). Any chance of getting that functionality back? Jack
Re: Serious Regressions tables on https://gcc.gnu.org
On Fri, Feb 13, 2015 at 3:16 PM, Marek Polacek wrote: > On Fri, Feb 13, 2015 at 03:12:22PM -0500, Jack Howarth wrote: >> Is there a reason why the Serious Regressions tables, displayed by >> the links in the 'Release Series and Status' section at >> https://gcc.gnu.org, no longer have a column for the priority >> (importance) of each bug? We used to have that and it was quite nice >> to be able to click on the priority column header to regenerate the >> table sorted by bug priority (to quickly see how many P1s are open). >> Any chance of getting that functionality back? > > You probably need to enable the Priority column in Change Columns at > the bottom of the page. > > Marek That works but we used to have the Priority column listed in the GCC Bugzilla default column listing. Jack
Re: Serious Regressions tables on https://gcc.gnu.org
On Fri, Feb 13, 2015 at 3:38 PM, Jakub Jelinek wrote: > On Fri, Feb 13, 2015 at 03:31:22PM -0500, Jack Howarth wrote: >> On Fri, Feb 13, 2015 at 3:16 PM, Marek Polacek wrote: >> > On Fri, Feb 13, 2015 at 03:12:22PM -0500, Jack Howarth wrote: >> >> Is there a reason why the Serious Regressions tables, displayed by >> >> the links in the 'Release Series and Status' section at >> >> https://gcc.gnu.org, no longer have a column for the priority >> >> (importance) of each bug? We used to have that and it was quite nice >> >> to be able to click on the priority column header to regenerate the >> >> table sorted by bug priority (to quickly see how many P1s are open). >> >> Any chance of getting that functionality back? >> > >> > You probably need to enable the Priority column in Change Columns at >> > the bottom of the page. >> > >> > Marek >> >> That works but we used to have the Priority column listed in the GCC >> Bugzilla default column listing. > > What columns do you get in the standard queries is what you've configured, > in the sorting order you've configured. > > Jakub Yes, after you have set them once in "Change Columns". However if you use a different browser where you have never visited those "Serious regressions" links before, the first visit will reveal that the default columns shown are "ID, Product, Assignee, Status, Resolution, Summary and Changed" which are exactly the same ones produced by clicking the "Reset to GCC Bugzilla defaults. What I am saying is that we must have include "Priority" in the GCC Bugzilla defaults in the past. Jack
future versions
What was the final decision concerning future versioning of FSF gcc post-5.0? In particular, I am confused about the designation of maintenance releases of 5.0. Will the next maintenance release be 5.1 or 5.0.1? I assume if it is 5.1, then after branching for release of 5.0, trunk will become 6.0, no? Jack
Re: future versions
On Sat, Mar 21, 2015 at 1:45 AM, Markus Trippelsdorf wrote: > On 2015.03.20 at 20:08 -0400, Jack Howarth wrote: >> What was the final decision concerning future versioning of FSF >> gcc post-5.0? In particular, I am confused about the designation of >> maintenance releases of 5.0. Will the next maintenance release be 5.1 >> or 5.0.1? I assume if it is 5.1, then after branching for release of >> 5.0, trunk will become 6.0, no? > > http://gcc.gnu.org/develop.html#num_scheme So according to that webpage, trunk becomes 6.0 and the first maintenance release of 5.0 becomes 5.1 (with 5.0.1 being the pre-release state of the gcc-5_0-branch prior to the actual 5.1 maintenance release). What is confusing me is all of these references in the mailing list to postponing bug fixes until 5.2 instead of 5.1 (https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01129.html for example). What is that all about? > > -- > Markus
Re: future versions
Is this the policy going forward for the 6.0 release as well? If it is being done just to avoid the stigma of a .0 release, it really smacks of being too cute by half. On Sat, Mar 21, 2015 at 1:27 PM, Markus Trippelsdorf wrote: > On 2015.03.21 at 12:11 -0400, Jack Howarth wrote: >> On Sat, Mar 21, 2015 at 1:45 AM, Markus Trippelsdorf >> wrote: >> > On 2015.03.20 at 20:08 -0400, Jack Howarth wrote: >> >> What was the final decision concerning future versioning of FSF >> >> gcc post-5.0? In particular, I am confused about the designation of >> >> maintenance releases of 5.0. Will the next maintenance release be 5.1 >> >> or 5.0.1? I assume if it is 5.1, then after branching for release of >> >> 5.0, trunk will become 6.0, no? >> > >> > http://gcc.gnu.org/develop.html#num_scheme >> >> So according to that webpage, trunk becomes 6.0 and the first >> maintenance release of 5.0 becomes 5.1 (with 5.0.1 being the >> pre-release state of the gcc-5_0-branch prior to the actual 5.1 >> maintenance release). What is confusing me is all of these references >> in the mailing list to postponing bug fixes until 5.2 instead of 5.1 >> (https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01129.html for >> example). What is that all about? > > The first release of gcc-5 will be 5.1.0. There will be no 5.0.0 > release... > > -- > Markus
Re: future versions
So effectlvely the old usage of the major version has been discarded with the previous usage of the minor version mapped to it. Likewise for the previous usage of the patch version now mapped to the minor version. I am just trying to clarify this as I have to adjust my packaging of FSF gcc in the fink project. For example, previously we used -program-suffix=-fsf-4.9 but now this will have to be -program-suffix=-fsf-5. Likewise we buried the release with --prefix=%p/lib/gcc4.9 but now this will have to be --prefix=%p/lib/gcc5 for the gcc 5 release series. On Sun, Mar 22, 2015 at 1:57 PM, Jonathan Wakely wrote: > On 22 March 2015 at 17:28, Jack Howarth wrote: >> Is this the policy going forward for the 6.0 release as well? > > Yes, as it says on that webpage. > >> If it is >> being done just to avoid the stigma of a .0 release, it really smacks >> of being too cute by half. > > That's not the reason, there's a rationale on the webpage too. > > If someone says they have 4.9.0 it could be the final release or a > trunk build from 9 months earlier, which would be a very different > compiler. Similarly, 4.9.1 would be the final release or a build on > the branch from the day after 4.9.0 was released. > > With the new scheme the __GNUC_PATCHLEVEL__ component is different for > final releases and snapshots.
-Wno-c++11-extensions addition
Does anyone remember which FSF gcc release first added the -Wno-c++11-extensions option for g++? I know it exists in 4.6.3 but am not having much luck Googling for the original submission in the gcc-patches archives. According to https://gcc.gnu.org/projects/cxx0x.html, the initial c++-11 support goes back to 4.3 but this specific warning isn't mentioned in the documentation for 4.6.3 which supports -Wno-c++11-extensions (https://gcc.gnu.org/onlinedocs/gcc-4.6.3/gcc/Warning-Options.html).
Re: -Wno-c++11-extensions addition
On Wed, Mar 25, 2015 at 12:41 PM, Jonathan Wakely wrote: > On 25 March 2015 at 16:16, Jack Howarth wrote: >> Does anyone remember which FSF gcc release first added the >> -Wno-c++11-extensions option for g++? I know it exists in 4.6.3 > > Are you sure? It doesn't exist for 4.6.4 or anything later. > > Are you thinking of -Wc++0x-compat ? On x86_64 Fedora 15... $ /usr/bin/g++ --version g++ (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2) Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ /usr/bin/g++ -Wno-c++11-extensions hello.cc $ So gcc 4.6.3 appears to at least tolerate that warning without claiming that it is unknown.
gcc 4.9.3 schedule
What is the current schedule for the gcc 4.9.3 maintenance release? Isn't it due this month? Jack
Re: GCC 5.5 Status Report (2017-09-16)
On Sat, Sep 16, 2017 at 3:03 PM, Jakub Jelinek wrote: > Status > == > > The GCC 5 branch is still open for regression and documentation fixes > but it's about time to close the branch with a last release from it. > Thus at the end of the next week I plan to do a RC for GCC 5.5 following > with a release and the branch closing game. Jakub, Darwin still needs to have the proposed backports posted as... https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00476.html https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00478.html https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00477.html committed so that gcc-5-branch will build against Xcode 9's clang compiler. Jack > > Please consider backporting of important fixes (wrong-code, rejects-valid) > but err on the side of caution. > > > Quality Data > > > Priority # Change from last report > --- --- > P10 > P2 229 + 91 > P3 12 - 8 > P4 99 + 23 > P5 27 - 1 > --- --- > Total P1-P3 241 + 83 > Total 367 + 105 > > > Previous Report > === > > https://gcc.gnu.org/ml/gcc/2016-06/msg00019.html
pb05 results at rr169776
Sebastian, Below are the results for the Polyhedron 2005 benchmarks on x86_64-apple-darwin10 using -O3 -ffast-math -funroll-loops under gcc trunk at r169776, with -fgraphite-identity and with -fgraphite-identity -ftree-loop-linear. I am surprised at the absence of any impact from -ftree-loop-linear in either run-time or executable size. The increase in compile time on some of the benchmarks suggested it was in effect. Is this a poor combination of optimizations for -ftree-loop-linear or is fortran less effective in using that optimization? Jack ps Hopefully when the remaining loop regressions in -fgraphite-identity are solved, the graphite results will improve a bit more. Using built-in specs. COLLECT_GCC=gcc-4 COLLECT_LTO_WRAPPER=/sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin10.7.0/4.6.0/lto-wrapper Target: x86_64-apple-darwin10.7.0 Configured with: ../gcc-4.6-20110202/configure --prefix=/sw --prefix=/sw/lib/gcc4.6 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.6/info --with-build-config=bootstrap-lto --enable-stage1-languages=c,lto --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.6 --enable-checking=yes --enable-cloog-backend=isl Thread model: posix gcc version 4.6.0 20110203 (experimental) (GCC) command=gfortran -O3 -ffast-math -funroll-loops Run-time stock -fgraphite-identity -fgraphite-identity -ftree-loop-linear ac8.80 8.80 8.80 aermod 17.3217.43 17.43 air 5.48 5.43 5.44 capacita 32.4532.52 32.53 channel 1.84 1.84 1.84 doduc28.3026.28 26.28 fatigue 8.13 8.09 8.09 gas_dyn 4.30 4.32 4.31 induct 13.0712.51 12.51 linpk15.4715.41 15.41 mdbx 11.2111.21 11.21 nf 29.9130.20 30.01 protein 32.8632.21 32.20 rnflow 23.9424.18 24.17 test_fpu 8.02 8.05 8.04 tfft 1.87 1.87 1.87 Compile-time stock -fgraphite-identity -fgraphite-identity -ftree-loop-linear ac2.12 2.12 2.12 aermod 57.45 59.22 59.30 air 3.84 4.37 4.93 capacita 2.82 2.94 3.07 channel 1.00 1.20 1.33 doduc 8.57 8.92 8.95 fatigue 3.19 3.17 3.17 gas_dyn 5.38 5.57 5.57 induct6.59 6.77 8.81 linpk 1.08 1.33 1.31 mdbx 2.83 2.92 2.92 nf3.09 3.08 3.10 protein 8.51 8.70 8.67 rnflow9.94 10.09 10.09 test_fpu 7.22 7.24 7.28 tfft 0.81 0.88 0.83 Executable size stock -fgraphite-identity -fgraphite-identity -ftree-loop-linear ac 50976 50976 50976 aermod 1264832 1268928 1268928 air 73984 82184 82184 capacita 77976 77976 77976 channel 34792 34792 34792 doduc 193096193096193096 fatigue 86032 86032 86032 gas_dyn 119704115608115608 induct 174848174848174848 linpk38648 38648 38648 mdbx 82072 82072 82072 nf 75912 71816 71816 protein 131992131992131992 rnflow 181080181080181080 test_fpu155048150952150952 tfft 30760 30760 30760
Re: pb05 results at rr169776
On Thu, Feb 03, 2011 at 11:08:09AM +0100, Richard Guenther wrote: > On Thu, Feb 3, 2011 at 6:43 AM, Jack Howarth wrote: > > Sebastian, > > Below are the results for the Polyhedron 2005 benchmarks on > > x86_64-apple-darwin10 using -O3 -ffast-math -funroll-loops under gcc > > trunk at r169776, with -fgraphite-identity and with -fgraphite-identity > > -ftree-loop-linear. I am surprised at the absence of any impact from > > -ftree-loop-linear in either run-time or executable size. The increase > > in compile time on some of the benchmarks suggested it was in effect. > > Is this a poor combination of optimizations for -ftree-loop-linear or > > is fortran less effective in using that optimization? > > Well, I don't know of any bogously nested (hot) loop in polyhedron, do you? > > Richard. > Richard, In that case, I guess the most interesting observation from the data would be that the increased compile times for the induct benchmark makes it a good candidate for profiling -floop-interchange for hot spots that could be improved. Jack > > induct 6.59 6.77 8.81
enum built_in_function and divdc3
Richard,
The ___divdc3 symbol on Snow Leopard in libSystem is less accurate
than that in FSF libgcc (PR42333). We plan to use DECLARE_LIBRARY_RENAMES
to provide an alternative symbol ___ieee_divdc3 to access the FSF libgcc
___divdc3 symbol when libSystem.dylib is linked first and
!flag_unsafe_math_optimization.
We originally planned to use a darwin_patch_divdc3() modelled directly on
darwin_patch_builtin() in gcc/config/darwin.c, however the absence of a listing
of divdc3 in gcc/builtins.def makes the syntax...
tree fn = built_in_decls[BUILT_IN_DIVDC3];
impossible. I noticed you did the original commit for the current complex
division functions...
2005-02-11 Richard Henderson
* tree-complex.c (expand_complex_libcall): New.
(expand_complex_multiplication): Use it for c99 compliance.
(expand_complex_division): Likewise.
* fold-const.c (fold_complex_add, fold_complex_mult): New.
(fold): Call them.
* builtins.c (built_in_names): Remove const.
* tree.c (build_common_builtin_nodes): Build complex arithmetic
builtins.
* tree.h (BUILT_IN_COMPLEX_MUL_MIN, BUILT_IN_COMPLEX_MUL_MAX): New.
(BUILT_IN_COMPLEX_DIV_MIN, BUILT_IN_COMPLEX_DIV_MAX): New.
(built_in_names): Remove const.
* c-common.c (c_common_type_for_mode): Handle complex modes.
* flags.h, toplev.c (flag_complex_method): Rename from
flag_complex_divide_method.
* libgcc2.c (__divsc3, __divdc3, __divxc3, __divtc3,
__mulsc3, __muldc3, __mulxc3, __multc3): New.
* libgcc2.h: Declare them.
* libgcc-std.ver: Export them.
* mklibgcc.in (lib2funcs): Build them.
I also noticed...
#define DEF_BUILTIN(ENUM, N, C, T, LT, B, F, NA, AT, IM, COND) ENUM,
enum built_in_function
{
#include "builtins.def"
/* Complex division routines in libgcc. These are done via builtins
because emit_library_call_value can't handle complex values. */
BUILT_IN_COMPLEX_MUL_MIN,
BUILT_IN_COMPLEX_MUL_MAX
= BUILT_IN_COMPLEX_MUL_MIN
+ MAX_MODE_COMPLEX_FLOAT
- MIN_MODE_COMPLEX_FLOAT,
BUILT_IN_COMPLEX_DIV_MIN,
BUILT_IN_COMPLEX_DIV_MAX
= BUILT_IN_COMPLEX_DIV_MIN
+ MAX_MODE_COMPLEX_FLOAT
- MIN_MODE_COMPLEX_FLOAT,
/* Upper bound on non-language-specific builtins. */
END_BUILTINS
};
#undef DEF_BUILTIN
what is the correct value is use for the enum entry of the ___divdc3
symbol? Is it END_BUILTINS-1 or END_BUILTINS-2? Thanks in advance for
any clarifications.
Jack
Re: enum built_in_function and divdc3
On Sun, Feb 06, 2011 at 09:40:41AM -0800, Richard Henderson wrote: > On 02/06/2011 08:12 AM, Jack Howarth wrote: > > what is the correct value is use for the enum entry of the ___divdc3 > > symbol? Is it END_BUILTINS-1 or END_BUILTINS-2? Thanks in advance for > > any clarifications. > > See build_common_builtin_modes: > > dcode = ((enum built_in_function) > (BUILT_IN_COMPLEX_DIV_MIN + mode - MIN_MODE_COMPLEX_FLOAT)); So for divc3 in libgcc2.c... #elif defined(L_muldc3) || defined(L_divdc3) # define MTYPE DFtype # define CTYPE DCtype # define MODE dc I assume that BUILT_IN_COMPLEX_DIV_MIN and MIN_MODE_COMPLEX_FLOAT will be available to me in darwin.c but where is dc defined? I am looking to be able to execute... tree fn = built_in_decls[BUILT_IN_COMPLEX_DIV_MIN + sc - MIN_MODE_COMPLEX_FLOAT]; or is MODE not the same as mode? Jack > > > r~
Re: targetm.init_builtins and build_common_builtin_nodes ordering
On Mon, Feb 07, 2011 at 11:51:55AM +0100, Richard Guenther wrote: > On Mon, Feb 7, 2011 at 2:35 AM, Mike Stump wrote: > > So, in c-common.c we have: > > > > targetm.init_builtins (); > > build_common_builtin_nodes (); > > > > and in f95-1.c we have: > > > > build_common_builtin_nodes (); > > targetm.init_builtins (); > > They are "unordered", thus, targetm.init_builtins is supposed to initialize > target specific builtins only. > > > I would like to change c-common.c to match fortran, so that the target hook > > can slightly alter (rename) the linkage name of some of the common builtin > > nodes. If that answer is no, what's the best way to get __divdc3 renamed? > > I would say add a new hook that can be called from build_common_builtin_nodes > instead. Richard, The workaround that Mike came up with for darwin is posted here... http://gcc.gnu.org/ml/gcc-testresults/2011-02/msg00726.html FYI, I tried inverting the order of targetm.init_builtins (); and build_common_builtin_nodes (); in c-common.c to match that in f95-1.c but it broke the bootstrap. Jack > > Richard.
Re: GCC bootstrap mismatch on OS X 10.4
On Sun, Feb 13, 2011 at 05:27:37PM +, Jonathan Wakely wrote: > On 13 February 2011 09:01, Csaba Raduly wrote: > > > > Any idea what could be the problem and how to fix it? Should I just > > run a simple "make"? > > Questions about using or building gcc should be sent to > gcc-h...@gcc.gnu.org, not this list, please follow up there instead, > thanks. > > I don't know if it will solve your problem, but yes, you just build > gcc with 'make' these days, not 'make bootstrap' I suspect his problems will be solved by adding --with-dwarf2 to the configure options. We don't seem to have a specific PR for this but I believe there are bootstrap comparision failures in libgomp for darwin8 using stabs. We don't get a lot of testing on darwin8 theses days since the regress Apple tester is now on darwin9 (plus this could be intel specific). Both Mike and Iain have access to darwin8 so we hopefully can get a PR opened. Jack ps I had suggested awhile back that we default darwin8 to dwarf2 but Mike thinks the dwarf2 support is too immature in the Xcode for darwin8 to safely do that.
Re: PATCH committed: 64-bit Apple Objective-C runtime support
On Thu, Feb 17, 2011 at 06:21:17PM -0800, Mike Stump wrote: > On Feb 17, 2011, at 4:09 PM, Nicola Pero wrote: > > This patch is not me - it's by Iain Sandoe. :-) > > Thanks for chipping in and helping out. I'm excited at having a Objective-C > compiler that works again on darwin. > > That said, if people have any Objective-C codes, feel free to beat on them > and let us know what you find. We're interested in regressions first and > foremost, after that functionality on 64-bit darwin. We know about PCH not > working well in some situations, so, be prepared to turn that off. Did Iain see these failures in his testing at -m64? FAIL: objc/execute/exceptions/foward-1.m execution, -O0 -fnext-runtime FAIL: objc/execute/exceptions/foward-1.m execution, -O1 -fnext-runtime FAIL: objc/execute/exceptions/foward-1.m execution, -O2 -fnext-runtime FAIL: objc/execute/exceptions/foward-1.m execution, -O3 -fomit-frame-pointer -fnext-runtime FAIL: objc/execute/exceptions/foward-1.m execution, -O3 -fomit-frame-pointer -funroll-loops -fnext-runtime FAIL: objc/execute/exceptions/foward-1.m execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions -fnext-runtime FAIL: objc/execute/exceptions/foward-1.m execution, -O3 -g -fnext-runtime FAIL: objc/execute/exceptions/foward-1.m execution, -Os -fnext-runtime I am seeing those on x86_64-apple-darwin10. Jack
Re: Parma Polyhedra Library 0.11.1
On Sun, Feb 20, 2011 at 06:32:30PM +0100, Prof. Roberto Bagnara wrote:
>
> We announce the availability of PPL 0.11.1, a new release of the Parma
> Polyhedra Library. This release includes several important bug fixes
> and performance improvements.
Roberto,
Have you had any reports of installation problems? After installing
doxygen, texlive for pdflatex and graphviz for dot, I am still running into
installation failures for the documentation. These currently appear as...
Writing index file refman.idx
No file refman.aux.
(/sw/share/texmf-dist/tex/latex/base/ts1cmr.fd)
(/sw/share/texmf-dist/tex/latex/psnfss/t1ptm.fd)
(/sw/share/texmf-dist/tex/context/base/supp-pdf.mkii
[Loading MPS to PDF converter (version 2006.09.02).]
) (/sw/share/texmf-dist/tex/latex/oberdiek/epstopdf-base.sty
(/sw/share/texmf-dist/tex/latex/oberdiek/grfext.sty)
(/sw/share/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg))
(/sw/share/texmf-dist/tex/latex/graphics/color.sty
(/sw/share/texmf-dist/tex/latex/latexconfig/color.cfg))
(/sw/share/texmf-dist/tex/latex/hyperref/nameref.sty
(/sw/share/texmf-dist/tex/latex/oberdiek/refcount.sty)
(/sw/share/texmf-dist/tex/generic/oberdiek/gettitlestring.sty))
(/sw/share/texmf-dist/tex/latex/amsfonts/umsa.fd)
(/sw/share/texmf-dist/tex/latex/amsfonts/umsb.fd)
(/sw/share/texmf-dist/tex/latex/stmaryrd/Ustmry.fd) [1{/sw/var/lib/texmf/fonts/
map/pdftex/updmap/pdftex.map}] (/sw/share/texmf-dist/tex/latex/psnfss/ts1ptm.fd
) (/sw/share/texmf-dist/tex/latex/psnfss/t1pcr.fd) (./main.texpdfTeX warning (e
xt4): destination with the same identifier (name{page.1}) has been already used
, duplicate ignored
\relax
l.17 ...ry.Parma\_\-Polyhedra\_\-Library}};\item S
tarting from version 0.11,...
[1]
Underfull \hbox (badness 1337) in paragraph at lines 26--26
[]\T1/ptm/m/n/10 boxes which con-sist of Int8_-Box, Int16_-Box, Int32_-Box, Int
64_-Box, Uint8_-Box,
) (/sw/src/fink.build/ppl9-0.11.1-0/ppl-0.11.1/build/../doc/GPL.tex
! LaTeX Error: Can be used only in preamble.
See the LaTeX manual or LaTeX Companion for explanation.
Type H for immediate help.
...
l.1 \documentclass
[a4paper,12pt]{article}
?
>
> The precise list of user-visible changes is available at
>
> http://www.cs.unipr.it/ppl/Download/ftp/releases/0.11.1/NEWS
>
> For more information, please come and visit the PPL web site at
>
> http://www.cs.unipr.it/ppl/
>
> On behalf of all the past and present developers listed at
> http://www.cs.unipr.it/ppl/Credits/ and in the file CREDITS,
>
> Abramo Bagnara Roberto Bagnara Patricia M. Hill Enea Zaffanella
>
> --
> Prof. Roberto Bagnara CEO & CTO
> Applied Formal Methods Laboratory BUGSENG srl
> Department of Mathematics Parco Area delle Scienze 53/A
> University of Parma, ItalyI-43124 Parma, Italy
> http://www.cs.unipr.it/~bagnara/ http://bugseng.com/
> mailto:bagn...@cs.unipr.itmailto:roberto.bagn...@bugseng.com
Re: Parma Polyhedra Library 0.11.1
On Mon, Feb 21, 2011 at 12:10:03PM +0100, Roberto Bagnara wrote:
> On 02/21/2011 04:42 AM, Jack Howarth wrote:
>> On Sun, Feb 20, 2011 at 06:32:30PM +0100, Prof. Roberto Bagnara wrote:
>>>
>>> We announce the availability of PPL 0.11.1, a new release of the Parma
>>> Polyhedra Library. This release includes several important bug fixes
>>> and performance improvements.
>>
>> Roberto,
>> Have you had any reports of installation problems?
>
> Hi Jack.
>
> No, your report was the first one.
Roberto,
The problems seems to stem from the absence of pre-generated files for...
ppl-user-java-interface-0.11.1-html.tar.gz
ppl-user-java-interface-0.11.1.pdf
ppl-user-java-interface-0.11.1.ps.gz
in the doc directory of the source tarball. The fink ppl9 package builds
using --with-java="$JAVA_HOME" so that those missing files are autogenerated
by make install. Can you post a new tarball with those missing files added?
Jack
ps Those missing files are present in the ppl-0.11 tarball.
>
>> After installing
>> doxygen, texlive for pdflatex and graphviz for dot, I am still running into
>> installation failures for the documentation. These currently appear as...
>>
>> Writing index file refman.idx
>> No file refman.aux.
>> (/sw/share/texmf-dist/tex/latex/base/ts1cmr.fd)
>> (/sw/share/texmf-dist/tex/latex/psnfss/t1ptm.fd)
>> (/sw/share/texmf-dist/tex/context/base/supp-pdf.mkii
>> [Loading MPS to PDF converter (version 2006.09.02).]
>> ) (/sw/share/texmf-dist/tex/latex/oberdiek/epstopdf-base.sty
>> (/sw/share/texmf-dist/tex/latex/oberdiek/grfext.sty)
>> (/sw/share/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg))
>> (/sw/share/texmf-dist/tex/latex/graphics/color.sty
>> (/sw/share/texmf-dist/tex/latex/latexconfig/color.cfg))
>> (/sw/share/texmf-dist/tex/latex/hyperref/nameref.sty
>> (/sw/share/texmf-dist/tex/latex/oberdiek/refcount.sty)
>> (/sw/share/texmf-dist/tex/generic/oberdiek/gettitlestring.sty))
>> (/sw/share/texmf-dist/tex/latex/amsfonts/umsa.fd)
>> (/sw/share/texmf-dist/tex/latex/amsfonts/umsb.fd)
>> (/sw/share/texmf-dist/tex/latex/stmaryrd/Ustmry.fd)
>> [1{/sw/var/lib/texmf/fonts/
>> map/pdftex/updmap/pdftex.map}]
>> (/sw/share/texmf-dist/tex/latex/psnfss/ts1ptm.fd
>> ) (/sw/share/texmf-dist/tex/latex/psnfss/t1pcr.fd) (./main.texpdfTeX warning
>> (e
>> xt4): destination with the same identifier (name{page.1}) has been already
>> used
>> , duplicate ignored
>>
>> \relax
>> l.17 ...ry.Parma\_\-Polyhedra\_\-Library}};\item S
>>tarting from version
>> 0.11,...
>> [1]
>> Underfull \hbox (badness 1337) in paragraph at lines 26--26
>> []\T1/ptm/m/n/10 boxes which con-sist of Int8_-Box, Int16_-Box, Int32_-Box,
>> Int
>> 64_-Box, Uint8_-Box,
>
> Hmmm... this is very strange. I would like to reproduce the issue:
> which version of Doxygen are you using?
>
>> ) (/sw/src/fink.build/ppl9-0.11.1-0/ppl-0.11.1/build/../doc/GPL.tex
>>
>> ! LaTeX Error: Can be used only in preamble.
>>
>> See the LaTeX manual or LaTeX Companion for explanation.
>> Type H for immediate help.
>> ...
>>
>> l.1 \documentclass
>>[a4paper,12pt]{article}
>> ?
>
> This is even stranger: the file name should be `gpl.tex', not `GPL.tex'
> Can you please double check in the `doc' subdirectory?
> Cheers,
>
>Roberto
>
> --
> Prof. Roberto Bagnara CEO & CTO
> Applied Formal Methods Laboratory BUGSENG srl
> Department of Mathematics Parco Area delle Scienze 53/A
> University of Parma, ItalyI-43124 Parma, Italy
> http://www.cs.unipr.it/~bagnara/ http://bugseng.com/
> mailto:bagn...@cs.unipr.itmailto:roberto.bagn...@bugseng.com
new libjava bootstrap failure
Is anyone else building java with lto-bootstrap? At r170606 I am seeing a bootstrap failure which appears as... /bin/sh ./libtool --tag=CXX --mode=compile /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc/xgcc -shared-libgcc -B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc -nostdinc++ -L/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/libstdc++-v3/src -L/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/libstdc++-v3/src/.libs -B/sw/lib/gcc4.6/x86_64-apple-darwin10.7.0/bin/ -B/sw/lib/gcc4.6/x86_64-apple-darwin10.7.0/lib/ -isystem /sw/lib/gcc4.6/x86_64-apple-darwin10.7.0/include -isystem /sw/lib/gcc4.6/x86_64-apple-darwin10.7.0/sys-include-DHAVE_CONFIG_H -I. -I../../../gcc-4.6-20110301/libjava -I./include -I./gcj -I../../../gcc-4.6-20110301/libjava -Iinclude -I../../../gcc-4.6-20110301/libjava/include -I../../../gcc-4.6-20110301/libjava/classpath/include -Iclasspath/include -I../../../gcc-4.6-20110301/libjava/classpath/native/fdlibm -I../../../gcc-4.6-20110301/libjava/../boehm-gc/include -I../boehm-gc/include -I../../../gcc-4.6-20110301/libjava/libltdl -I../../../gcc-4.6-20110301/libjava/libltdl -I../../../gcc-4.6-20110301/libjava/.././libjava/../gcc -I../../../gcc-4.6-20110301/libjava/../libffi/include -I../libffi/include -I/sw/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -fomit-frame-pointer -Wextra -Wall -D_GNU_SOURCE -DPREFIX="\"/sw/lib/gcc4.6\"" -DTOOLEXECLIBDIR="\"/sw/lib/gcc4.6/lib\"" -DJAVA_HOME="\"/sw/lib/gcc4.6\"" -DBOOT_CLASS_PATH="\"/sw/lib/gcc4.6/share/java/libgcj-4.6.0.jar\"" -DJAVA_EXT_DIRS="\"/sw/lib/gcc4.6/share/java/ext\"" -DGCJ_ENDORSED_DIRS="\"/sw/lib/gcc4.6/share/java/gcj-endorsed\"" -DGCJ_VERSIONED_LIBDIR="\"/sw/lib/gcc4.6/lib/gcj-4.6.0-12\"" -DPATH_SEPARATOR="\":\"" -DECJ_JAR_FILE="\"/sw/lib/gcc4.6/share/java/ecj.jar\"" -DLIBGCJ_DEFAULT_DATABASE="\"/sw/lib/gcc4.6/lib/gcj-4.6.0-12/classmap.db\"" -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL="\"gcj-4.6.0-12/classmap.db\"" -g -O2 -MT jni-libjvm.lo -MD -MP -MF $depbase.Tpo -c -o jni-libjvm.lo ../../../gcc-4.6-20110301/libjava/jni-libjvm.cc &&\ mv -f $depbase.Tpo $depbase.Plo make[4]: *** No rule to make target `.deps/gij.Plo'. Stop. make[3]: *** [all-multi] Error 2 make[3]: *** Waiting for unfinished jobs Could this be related to the recent lto-streamer changes? I am using... ../gcc-4.6-20110301/configure --prefix=/sw --prefix=/sw/lib/gcc4.6 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.6/info --with-build-config=bootstrap-lto --enable-stage1-languages=c,lto --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --enable-build-with-cxx --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.6 --enable-checking=yes --enable-cloog-backend=isl on x86_64-apple-darwin10 with 'make -j 8'. Oddly, after the failed bootstrap, if I just use 'make' the build completes successfully. Jack
Re: new libjava bootstrap failure
On Wed, Mar 02, 2011 at 04:58:41AM +, Dave Korn wrote: > On 02/03/2011 03:23, Jack Howarth wrote: > >Is anyone else building java with lto-bootstrap? At r170606 I am seeing > > a bootstrap > > failure which appears as... > > > make[4]: *** No rule to make target `.deps/gij.Plo'. Stop. > > make[3]: *** [all-multi] Error 2 > > make[3]: *** Waiting for unfinished jobs > > > > Could this be related to the recent lto-streamer changes? > > Seems more likely something went wrong earlier, while making > configure-target-libjava; config.status is supposed to create blank dummy > dependency files to get the build going. > > Any trace of that earlier failure? Does running "rm .deps/gij.Plo && > ./config.status Makefile depfiles" in the failing directory regenerate > .deps/gij.Plo with the content "# dummy"? > > > on x86_64-apple-darwin10 with 'make -j 8'. Oddly, after the failed > > bootstrap, if I just use 'make' > > the build completes successfully. > > The .Plo files are generated as a side-effect of compiling the .o files, so > one of the "unfinished jobs" was presumably busy compiling gij.lo which is a > target that there is a separate pattern rule to cause to build. So next time > you compiled, the required .Plo file was already there. > > cheers, > DaveK Dave, I tried again without --enable-build-with-cxx and it worked. I'll see if I can reproduce it again with --enable-build-with-cxx. Jack
Re: new libjava bootstrap failure
On Wed, Mar 02, 2011 at 07:16:19AM +0100, Ralf Wildenhues wrote: > Hello Dave, > > * Dave Korn wrote on Wed, Mar 02, 2011 at 06:28:15AM CET: > > http://mad-scientist.net/make/autodep.html > > > > although note that where that recommends using "-include" (under > > "Avoiding ``No rule to make target ...'' Errors") to ignore would-be > > errors from trying to include non-existent files, we use an unprefixed > > include directive to read them in our Makefiles, and rely on > > config.status to generate empty ones first time round. I'm not sure > > why we do that differently. > > That's because non-GNU makes don't have facilities to include a file > only if it is present, and with the current machinery, a non-present > file always indicates a bug (or previous error) and having errors be > loud is a good thing for debugging. > > Jack, the actual issue you're seeing might well be the result of some > missing dependency. With parallel build failures, it is most important > to see output from make, back to at least the first error that happened. > That can be arbitrarily far back, and in GCC it is not uncommon to have > it happen a few thousand lines before the end of the log. Please save > such logs for future reports. > > Thanks, > Ralf Ralf, A second repetition of the original build with --enable-build-with-cxx completed without errors. FYI, I do all of my builds on darwin10 with lto-bootstrap and 'make -j 8'. This is the first time that I have seen this particular failure crop up. Jack
darwin LTO broken under Xcode 3.2.6/4.0
With release of Xcode 3.2.6/4.0 this week, an unfortunate change was made to the darwin assembler which effectively breaks LTO support for darwin. The design of LTO on darwin was based on the fact that mach-o object files tolerated additional sections as long as they didin't contain symbols. With Xcode 3.2.6/4.0, the assembler appears to be strictly counting sections and objecting when these exceed 255. This breaks huge sections of the lto testsuite and prevents larger projects like xplor-nih to compile if Xcode 3.2.6/4.0 is installed. I am afraid that unless Apple reverts this change, our only recourse would be to resort to an elf object container for the lto sections within the mach-o files (introducing an undesired dependency on libelf for FSF gcc on darwin). My understanding was that the lto design did not allow the number of sections required in the lto files to be reduced. Jack
Re: darwin LTO broken under Xcode 3.2.6/4.0
On Sat, Mar 12, 2011 at 09:34:01PM -0800, Chris Lattner wrote: > > On Mar 12, 2011, at 8:17 PM, Jack Howarth wrote: > > > With release of Xcode 3.2.6/4.0 this week, an unfortunate change was made > > to > > the darwin assembler which effectively breaks LTO support for darwin. The > > design > > of LTO on darwin was based on the fact that mach-o object files tolerated > > additional > > sections as long as they didin't contain symbols. With Xcode 3.2.6/4.0, the > > assembler > > appears to be strictly counting sections and objecting when these exceed > > 255. This > > breaks huge sections of the lto testsuite and prevents larger projects like > > xplor-nih > > to compile if Xcode 3.2.6/4.0 is installed. I am afraid that unless Apple > > reverts this > > change, our only recourse would be to resort to an elf object container for > > the lto > > sections within the mach-o files (introducing an undesired dependency on > > libelf for > > FSF gcc on darwin). My understanding was that the lto design did not allow > > the number > > of sections required in the lto files to be reduced. > > Hi Jack, > > Please file a bug against the apple bug tracker explaining exactly what you > need to work with some example .o files. > > -Chris Chris, I have already opened Problem ID: 9126174 on radar and uploaded the builtin-attr-1.s assembly file from the failed... /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/ /sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20110311/gcc/testsuite/gcc.dg/torture/builtin-attr-1.c -O2 -flto -flto-partition=none -ffast-math -lm --save-temps -v -m32 -o builtin-attr-1.exe linkage. The failure occurs as... builtin-attr-1.s:12528:FATAL:too many sections (maximum 255) when 'as -arch i386 -force_cpusubtype_ALL -o builtin-attr-1.o builtin-attr-1.s' is executed. This same assembly file works fine with 'as' from Xcode 3.2.5. Also the 12528th line happens to be just after the 253rd GNU_LTO section which makes sense as there is a __TEXT,__text_startup and __TEXT,__eh_frame section as well. If I truncate the assembly file at 253 GNU_LTO sections it is assembled without complaint. Nick believed that the assembler was looking for symbols in each section and verifying the section count that way. I don't believe that is true and that a simple count of all sections is being done instead. If true, it prohibits us from using the current approach of placing all of the GNU_LTO sections at the end of the assembly. Since they don't contain symbols this has never been a problem in the past. Jack
Re: darwin LTO broken under Xcode 3.2.6/4.0
On Sun, Mar 13, 2011 at 12:39:26PM +0100, Jan Hubicka wrote: > >With release of Xcode 3.2.6/4.0 this week, an unfortunate change was > > made to > > the darwin assembler which effectively breaks LTO support for darwin. The > > design > > of LTO on darwin was based on the fact that mach-o object files tolerated > > additional > > sections as long as they didin't contain symbols. With Xcode 3.2.6/4.0, the > > assembler > > appears to be strictly counting sections and objecting when these exceed > > 255. This > > breaks huge sections of the lto testsuite and prevents larger projects like > > xplor-nih > > to compile if Xcode 3.2.6/4.0 is installed. I am afraid that unless Apple > > reverts this > > change, our only recourse would be to resort to an elf object container for > > the lto > > sections within the mach-o files (introducing an undesired dependency on > > libelf for > > FSF gcc on darwin). My understanding was that the lto design did not allow > > the number > > of sections required in the lto files to be reduced. > > If the problem is not fixed, we could always pack all the LTO sections into > one section containing > our own subsections. > > Honza Jan, If this could be done without resorting to other container types (like elf), it might be the wisest approach for the long run. I've read through the mach-o documentation and it seems rather vague on the section limits. Even if Apple fixes Xcode (which likley won't happen for 6-9 months at best), we always we have to worry that they will break this 'feature' somewhere else in their tool chain. Better to follow the strictest possible reading of mach-o object format to protect ourselves from overzealous Apple interns. > > Jack
Re: darwin LTO broken under Xcode 3.2.6/4.0
On Sun, Mar 13, 2011 at 11:19:13AM -0700, Chris Lattner wrote: > > On Mar 13, 2011, at 8:38 AM, Jack Howarth wrote: > > > On Sun, Mar 13, 2011 at 12:39:26PM +0100, Jan Hubicka wrote: > >>> With release of Xcode 3.2.6/4.0 this week, an unfortunate change was > >>> made to > >>> the darwin assembler which effectively breaks LTO support for darwin. The > >>> design > >>> of LTO on darwin was based on the fact that mach-o object files tolerated > >>> additional > >>> sections as long as they didin't contain symbols. With Xcode 3.2.6/4.0, > >>> the assembler > >>> appears to be strictly counting sections and objecting when these exceed > >>> 255. This > >>> breaks huge sections of the lto testsuite and prevents larger projects > >>> like xplor-nih > >>> to compile if Xcode 3.2.6/4.0 is installed. I am afraid that unless Apple > >>> reverts this > >>> change, our only recourse would be to resort to an elf object container > >>> for the lto > >>> sections within the mach-o files (introducing an undesired dependency on > >>> libelf for > >>> FSF gcc on darwin). My understanding was that the lto design did not > >>> allow the number > >>> of sections required in the lto files to be reduced. > >> > >> If the problem is not fixed, we could always pack all the LTO sections > >> into one section containing > >> our own subsections. > >> > >> Honza > > > > Jan, > > If this could be done without resorting to other container types (like > > elf), it might be > > the wisest approach for the long run. I've read through the mach-o > > documentation and it > > seems rather vague on the section limits. Even if Apple fixes Xcode (which > > likley won't > > happen for 6-9 months at best), we always we have to worry that they will > > break this > > 'feature' somewhere else in their tool chain. Better to follow the > > strictest possible reading > > of mach-o object format to protect ourselves from overzealous Apple interns. > > Yes, I agree that this is a better solution. This error was put into the > linker to detect some overflow conditions for part of the code that expected > the section number to only be a byte. It is likely that "things worked" only > out of luck before. > > -Chris Chris, Is there any documentation or example code on how to properly use subsections in mach-o? My fear is that we are moving from one poorly documented technique to another which may well have it own slate of hidden bugs. Jack
Re: darwin LTO broken under Xcode 3.2.6/4.0
On Sun, Mar 13, 2011 at 12:39:26PM +0100, Jan Hubicka wrote: > >With release of Xcode 3.2.6/4.0 this week, an unfortunate change was > > made to > > the darwin assembler which effectively breaks LTO support for darwin. The > > design > > of LTO on darwin was based on the fact that mach-o object files tolerated > > additional > > sections as long as they didin't contain symbols. With Xcode 3.2.6/4.0, the > > assembler > > appears to be strictly counting sections and objecting when these exceed > > 255. This > > breaks huge sections of the lto testsuite and prevents larger projects like > > xplor-nih > > to compile if Xcode 3.2.6/4.0 is installed. I am afraid that unless Apple > > reverts this > > change, our only recourse would be to resort to an elf object container for > > the lto > > sections within the mach-o files (introducing an undesired dependency on > > libelf for > > FSF gcc on darwin). My understanding was that the lto design did not allow > > the number > > of sections required in the lto files to be reduced. > > If the problem is not fixed, we could always pack all the LTO sections into > one section containing > our own subsections. > > Honza Jan, It appears this change is highly unlikely to be fixed. Chris Lattner said... > Jack, various datastructures in the toolchain and the .o file only store the > section number as a byte. > Allowing it to overflow just masks bugs because section id's will be silently > truncated. You > should fix the GCC LTO model to store one big section with its own > subcontents if you want more granularity. So lto-object.c needs a rewrite to use only a single section for GNU_LTO with subsections. Unfortunately I can't find any documentation for using subsections in mach-o which may imply we will be forced to use an elf container to obtain those, no? Jack > > Jack
Re: darwin LTO broken under Xcode 3.2.6/4.0
On Sun, Mar 13, 2011 at 11:55:02AM -0700, Chris Lattner wrote: > > On Mar 13, 2011, at 11:26 AM, Jack Howarth wrote: > > >> Yes, I agree that this is a better solution. This error was put into the > >> linker to detect some overflow conditions for part of the code that > >> expected the section number to only be a byte. It is likely that "things > >> worked" only out of luck before. > >> > >> -Chris > > > > Chris, > > Is there any documentation or example code on how to properly use > > subsections in mach-o? > > My fear is that we are moving from one poorly documented technique to > > another which may well > > have it own slate of hidden bugs. > > I'm not sure what you mean here Jack. ld64 is open source on the darwin > page, and if you have all the developer bits installed, the format is > "documented" in /usr/include/mach-o/. It's pretty clear all around that you > can only have 256 sections. > > -Chris Chris, The mach-o reference has a cryptic mention of MH_SUBSECTIONS_VIA_SYMBOLS in http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html MH_SUBSECTIONS_VIA_SYMBOLS—The sections of the object file can be divided into individual blocks. These blocks are dead-stripped if they are not used by other code. See Linking for details. Although I don't think this helps us at all because none of the GNU_LTO sections contain symbols. This is why I am still perplexed by this assembler change. We followed the rules Nick suggested of placing all of these GNU_LTO sections at the end of the file and none contain symbols. In that case, it would really seem that the assembler is now blindly counting sections without respect to whether any of them actually contain symbols. Jack
