Re: RFC: Update top level libtool files
On 10/10/2017 04:04 PM, David Edelsohn wrote: > On Tue, Oct 10, 2017 at 7:45 AM, Nick Clifton wrote: >> Hi Guys, >> >> I would like to update the top level libtool files (libtool.m4, >> ltoptions.m4, ltsugar.m4, ltversion.m4 and lt~obsolete.m4) used by >> gcc, gdb and binutils. Currently we have version 2.2.7a installed in >> the source trees and I would like to switch to the latest official >> version: 2.4.6. >> >> The motivation for doing this is an attempt to reduce the number of >> patches being carried round by the Fedora binutils releases. >> Currently one of the patches there is to fix a bug in the 2.2.7a >> libtool which causes it to select /lib and /usr/lib as the system >> library search paths even for 64-bit hosts. Rather than just bring >> this patch into the sources however, I thought that it would be better >> to upgrade to the latest official libtool release and use that >> instead. >> >> I have successfully run an x86_64 gcc bootstrap, built and tested lots >> of different binutils configurations, and built and run an x86_64 gdb. >> One thing that worries me though, is why hasn't this been done before? >> Ie is there a special reason for staying with the old 2.2.7a libtool ? >> If not, then does anyone object to my upgrading the gcc, gdb and >> binutils mainline sources ? > > AIX is another target that will need to be tested carefully for such a change. FWIW: There's at least this one approved libtool patch with commit pending (I don't have commit access to libtool myself): http://lists.gnu.org/archive/html/libtool-patches/2016-03/msg00030.html Additionally, I've recognized - but not double-checked - that symbols within anonymous namespace (and maybe static symbols too) have _GLOBAL__ in the middle of their symbol name, which should not be exported too I believe. Thanks! /haubi/
Re: AIX vs long double
On 01/-10/-28163 08:59 PM, David Edelsohn wrote:
> AIX provides two versions of long double and declares all of the C99
> long double symbols in math.h header file. One implementation aliases
> long double to IEEE double precision type and the other implementation
> aliases long double to IBM's paired double format. All of the C99
> symbols for IEEE double precision are implemented in libm, but not all
> of the C99 symbols for the IBM long double format are implemented.
>
> IBM's proprietary XL compiler (cc, xlc) defaults to IEEE double
> precision and provides a special invocation to default to IBM long
> double (cc128, xlc128).
>
> GNU/Linux and GCC on GNU/Linux default to IEEE quad precision long double.
Just to make sure I got the type names for the different bitwidths right:
IEEE double precision: 64bit
IEEE quad precision: 128bit
IBM's paired double: 128bit, identical to IEEE quad precision?
> Because the long double choice is an ABI change, GCC on AIX switched
> to GNU/Linux compatibility with support for AIX 6.1, before the
> incomplete implementation was noticed. This mostly worked until
Well, even that change still is incomplete within gcc, as it should link
against libc128 before libc, because even printf("%Lf") is broken right
now when not explicitly adding '-lc128' to the linkline.
Reading bug [target/19115], the reason for that switch seems not to have
been Linux compatibility at all, but AIX libc providing 128bit math functions
frexpl, ldexpl and modfl before they went into C99 standard, and including
might have been missing somewhere within libstdc++ to get their
correct implementation for the selected long double bitwidth.
> libgfortran started using additional C99 functions, causing GCC
> Bugzilla
>
> [target/47032] libgfortran references complex long double functions
> missing on AIX
>
> libstdc++-v3 on AIX builds with AIX long double support,
IMO, long double bitwidth should be another multilib criterion on AIX,
selected by -mlong-double-64 and -mlong-double-128.
As there are a bunch of multilib criterions on AIX already:
Even on AIX 5.3 I get the impression that there is no need for "pthread"
being a multilib criterion any more, as /usr/lib/threads/libc.a is a symlink
to /usr/ccs/lib/libc.a - but I may be wrong here wrt STARTFILE_SPEC.
> although user
> programs that try to access the missing functions (copysign,
> nextafter, etc.) will experience link-time failures. libgfortran on
> AIX fails to build with AIX long double support because it accesses
> the missing functions in its implementation.
>
> I would like to solicit feedback about how to proceed: Should GCC on
> AIX revert back to 64 bit long double size, allowing all libraries to
> build and work, but breaking GCC/G++ ABI on AIX? Or should it continue
> to utilize 128 bit long double, building libstdc++-v3 that works if
> the user program does not utilize the missing symbols and fails to
> build libgfortran?
Please remember that even printf is broken on AIX 6.1 now. I doubt
people (know to) add '-lc128' when building with gcc on AIX 6.1 at all.
And not having the gcc-libraries with long-double-64 support available
prevents mixing gcc-built libraries with xlc-built libraries.
FWIW: For C++, AIX 6.1 defines public inline functions to rename math
functions (except frexpl, ldexpl, modfl) to the __FFl128 variant. This does
not work with gcc when building with -O0, as they result in weak symbols, being
ignored at linktime due to static symbols from libm.a with original name and
using 64bit long double. This is reported to IBM and I got confirmation last
week that they're working on how to fix it.
Thank you!
/haubi/
Re: # of unexpected failures 768 ?
On 10/31/11 19:20, Jonathan Wakely wrote: > On 31 October 2011 17:38, Rainer Orth wrote: >> Dennis Clarke writes: >> > I'm uncertain if Solaris 8/x86 still supports bare i386 machines, so it > might be better to keep the default of pentiumpro instead. Solaris 8 won't run on anything less than pentium, I recently convinced someone else to stop building GCC for i386 on Solaris: http://gcc.gnu.org/ml/gcc-help/2011-10/msg5.html > > Quite. In fact there are *very* good reasons not to configure for > 80386: libstdc++'s configure uses the default arch being configured > for, and disables a number of features on i386 because it doesn't > support the required atomic ops. > > So by configuring for i386 you will distribute a GCC package that is > missing useful features, but supports an ancient architecture that > Solaris doesn't even run on. > > You should configure for pentium-pc-solaris2.8 or use --with-arch-32=pentium When not configuring with '--host=i386-pc-solaris2.8', it is config.guess that detects 'i386-pc-solaris2.8', just tried here with most recent config.guess on i86pc Solaris2.10, result is 'i386-pc-solaris2.10'. Actually, it is uname showing the 'i386' on Solaris: $ uname -p # Prints the current host's ISA or processor type. i386 $ uname -i # Prints the name of the platform. i86pc So I'd wonder if '--host=i386-pc-solaris2.8' actually does make any difference here. Just my 2 cents. /haubi/
Re: # of unexpected failures 768 ?
On 11/02/11 12:41, Jonathan Wakely wrote: > On 2 November 2011 06:52, Michael Haubenwallner wrote: >> >> On 10/31/11 19:20, Jonathan Wakely wrote: >>> On 31 October 2011 17:38, Rainer Orth wrote: >>>> Dennis Clarke writes: >>>> >>>>>>> I'm uncertain if Solaris 8/x86 still supports bare i386 machines, so it >>>>>>> might be better to keep the default of pentiumpro instead. >>>>>> >>>>>> Solaris 8 won't run on anything less than pentium, I recently >>>>>> convinced someone else to stop building GCC for i386 on Solaris: >>>>>> >>>>>> http://gcc.gnu.org/ml/gcc-help/2011-10/msg5.html >>> >>> Quite. In fact there are *very* good reasons not to configure for >>> 80386: libstdc++'s configure uses the default arch being configured >>> for, and disables a number of features on i386 because it doesn't >>> support the required atomic ops. >>> >>> So by configuring for i386 you will distribute a GCC package that is >>> missing useful features, but supports an ancient architecture that >>> Solaris doesn't even run on. >>> >>> You should configure for pentium-pc-solaris2.8 or use --with-arch-32=pentium >> >> When not configuring with '--host=i386-pc-solaris2.8', it is config.guess >> that detects 'i386-pc-solaris2.8', just tried here with most recent >> config.guess on i86pc Solaris2.10, result is 'i386-pc-solaris2.10'. >> >> Actually, it is uname showing the 'i386' on Solaris: >> $ uname -p # Prints the current host's ISA or processor type. >> i386 >> $ uname -i # Prints the name of the platform. >> i86pc >> >> So I'd wonder if '--host=i386-pc-solaris2.8' actually does make any >> difference here. > > It's redundant if you *want* to build for that host, but the whole > point is that building for i386 is usually a very bad idea, so > --host=i586-pc-solaris2.8 would be better. Erm - what I want to say is that I would really wonder if it does have /any/ influence (binary-wise) to gcc on Solaris (unlike Linux) whether to configure for i386 or i586 (via '--host' or even '--target'). /haubi/
Re: # of unexpected failures 768 ?
On 11/02/11 18:10, Jonathan Wakely wrote: > On 2 November 2011 13:52, Michael Haubenwallner wrote: >> >> Erm - what I want to say is that I would really wonder if it does have /any/ >> influence (binary-wise) to gcc on Solaris (unlike Linux) whether to configure >> for i386 or i586 (via '--host' or even '--target'). > > http://gcc.gnu.org/gcc-4.5/changes.html#x86 doesn't say it only > happens on GNU/Linux. Oh my dear... thank you! But still: given that x86-solaris started with some Pentium, I just can't believe gcc can "optimize" for real 80386 CPU on Solaris now. Especially as i386 (from config.guess) is the default too. /haubi/
Re: # of unexpected failures 768 ?
On 11/02/11 19:07, Rainer Orth wrote: > Michael Haubenwallner writes: > >> Especially as i386 (from config.guess) is the default too. > > No, it's not, you're confusing the configure triplet with the default > 32-bit arch. Since GCC 4.6, the default for Solaris/x86 is pentiumpro > for Solaris 8/9 and pentium4 for Solaris 10 and beyond > (cf. gcc/config.gcc). I've meant the default "i386-pc-solaris2.*" target triplet from config.guess, not the default 32bit arch - which always is some pentium as I've expected (and tried to say before). Reading [1], it really doesn't make any difference on Solaris to configure for "i386-pc-solaris2.*" or (up to) "i786-pc-solaris2.*" target triplet, the 32bit arch default is controlled by the solaris version (and '--with-arch-32') only. But yes, for platforms not explicitly specifying a default $with_arch_32, that default value is calculated [2] from the cpu-part of the target-triplet. [1] http://gcc.gnu.org/viewcvs/trunk/gcc/config.gcc?view=markup&pathrev=180775#l1312 [2] http://gcc.gnu.org/viewcvs/trunk/gcc/config.gcc?view=markup&pathrev=180775#l2831 /haubi/
Re: dse2 remove wrong insn
On 12/12/11 14:48, BELBACHIR Selim wrote: > Everything seems good when I use a union instead of "*((int *)(&af))". This casting variant rings a bell here, especially when it breaks with optimization but works as union: Does it make a difference when you compile with "-fno-strict-aliasing" ? /haubi/
Re: Deprecate 32-bits HP-PA for GCC 4.8?
On 05/07/2012 07:33 PM, Steven Bosscher wrote: > I think it's reasonable to assume that most users of HP-UX10 on > machines with PA-RISC 2.0 support will have upgraded to HP-UX 11.11 or > later. While this may be true indeed, ... > 4. 32-bits HP-PA uses the SOM binary object format, i.e. it is a > non-ELF target (64-bits HP-PA is ELF). ... 32bit (SOM) still is the default output of HP-cc with HP-UX 11.31 on HP-PA. Actually, end of support for HP-UX 11.31 on HP 9000 is planned for end of 2020 now [1]. [1] http://www.hp.com/go/hpuxsupportmatrix /haubi/
Re: AIX trunk build fail #3
On 10/22/2012 03:49 PM, Perry Smith wrote: > In stage 3, libatomic's configure fails. The config.log file is here: > https://gist.github.com/3931504 > > I've recreated the conftest.c and ran the same command. The output is fine > and executes with a 0 status. > > The clue (that I can't figure out) is cc1 is a 32 bit program but it tried to > load the 64 bit version of libstdc++. > I can't figure out why it tried to do that and I can't recreate it. This one is (similar to) http://gcc.gnu.org/PR52623 /haubi/
Re: AIX trunk build fail #3
On 10/22/2012 06:03 PM, David Edelsohn wrote: > On Mon, Oct 22, 2012 at 9:49 AM, Perry Smith wrote: >> In stage 3, libatomic's configure fails. The config.log file is here: >> https://gist.github.com/3931504 >> >> I've recreated the conftest.c and ran the same command. The output is fine >> and executes with a 0 status. >> >> The clue (that I can't figure out) is cc1 is a 32 bit program but it tried >> to load the 64 bit version of libstdc++. >> I can't figure out why it tried to do that and I can't recreate it. >> >> I also added the output of dump -H /usr/work/build/gcc.git/./gcc/cc1 to the >> gist. >> >> Any suggestions? > > I do not know why you specifically are experiencing this problem. We > need to provide a version of libstdc++ for cc1 to use before the > multilib directory. AFAICT, this does happen since the C++ switch in stage1, as libstdc++ was not needed at all during bootstrap before. > Do you have a copy of libstdc++.a installed in the same directory as > gmp, mpfr, mpc? Maybe that occurs earlier in the search path. > Unfortunately all of the libraries have the same name and AIX tries > the first library with the name it finds, regardless of 32/64 mode. Also, I've wondered when AIX started to listen to LD_LIBRARY_PATH at all (in addition to LIBPATH). /haubi/
Re: CPATH, LIBRARY_PATH, and cross-compilers
On 02/14/2013 04:37 PM, Ralf Corsepius wrote: >> At any rate, there’s a need for similar env. vars for cross-compilers. WDYT? > I am having difficulties to imagine such a need. Indeed: I've experienced that environment variables are fine to test something out, but open a can of worms when used in production. It turned out to be much saner to have some wrappers around the compiler/linker which add the additional include- and library-paths - even for native toolchains. /haubi/
