Re: Solaris vtv port breaks x32 build
On 01.12.2015 03:58, Ulrich Drepper wrote: On Mon, Nov 30, 2015 at 9:14 PM, Jeff Law wrote: Right, but isn't AC_COMPILE_IFELSE a compile test, not a run test? The problem macro is _AC_COMPILER_EXEEXT_WORKS. The message is at the end. This macro *should* work for cross-compiling but somehow it doesn't work. In libvtv/configure $cross_compiling is not defined appropriately. I'm configuring with the following which definitely indicates that cross-compiling is selected. that might be another instance of https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02064.html Does something like this help? Index: libvtv/configure.ac === --- libvtv/configure.ac (revision 231050) +++ libvtv/configure.ac (working copy) @@ -6,6 +6,8 @@ #AC_INIT(package-unused, version-unused, libvtv) AC_CONFIG_SRCDIR([vtv_rts.h]) +AM_ENABLE_MULTILIB(, ..) + # --- # Options # --- @@ -73,7 +75,6 @@ AM_CONDITIONAL(ENABLE_VTABLE_VERIFY, test $use_vtable_verify = yes) AM_INIT_AUTOMAKE(foreign no-dist) -AM_ENABLE_MULTILIB(, ..) AM_MAINTAINER_MODE LIBVTV_CONFIGURE
Re: Solaris vtv port breaks x32 build
On Mon, Nov 30, 2015 at 9:14 PM, Jeff Law wrote: > Right, but isn't AC_COMPILE_IFELSE a compile test, not a run test? The problem macro is _AC_COMPILER_EXEEXT_WORKS. The message is at the end. This macro *should* work for cross-compiling but somehow it doesn't work. In libvtv/configure $cross_compiling is not defined appropriately. I'm configuring with the following which definitely indicates that cross-compiling is selected. ~/gnu/gcc/configure --prefix=/usr --enable-bootstrap --enable-shared --enable-host-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-tune=haswell --with-multilib-list=m32,m64,mx32 --build=x86_64-redhat-linux build_alias=x86_64-redhat-linux --enable-offload-targets=nvptx-none --with-cuda-driver-include=/usr/local/cuda/include --with-cuda-driver-lib=/usr/local/cuda/lib64 --host=x86_64-redhat-linux host_alias=x86_64-redhat-linux --enable-languages=c,c++,fortran,jit,lto --enable-libmpx --enable-gnu-indirect-function --with-system-zlib --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-vtable-verify configure:2863: checking for C compiler default output file name configure:2885: /home/drepper/local/gcc-builds/test-20151130/./gcc/xgcc -B/home/drepper/local/gcc-builds/test-20151130/./gcc/ -B/us r/x86_64-redhat-linux/bin/ -B/usr/x86_64-redhat-linux/lib/ -isystem /usr/x86_64-redhat-linux/include -isystem /usr/x86_64-redhat-li nux/sys-include -mx32 -g -O2 conftest.c >&5 configure:2889: $? = 0 configure:2926: result: a.out configure:2942: checking whether the C compiler works configure:2951: ./a.out /home/drepper/gnu/gcc/libvtv/configure: line 2953: ./a.out: cannot execute binary file: Exec format error
Re: Solaris vtv port breaks x32 build
On 11/30/2015 05:25 PM, Ulrich Drepper wrote: On Mon, Nov 30, 2015 at 6:57 PM, Jeff Law wrote: What part of this requires bits to run? I see AC_COMPILE_IFELSE, but not anything which obviously requires running the resulting code. Without AC_USE_SYSTEM_EXTENSIONS one gets: configure.ac:111: warning: AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS ../../lib/autoconf/specific.m4:332: AC_GNU_SOURCE is expanded from... configure.ac:111: the top level Right, but isn't AC_COMPILE_IFELSE a compile test, not a run test? jeff
Re: Solaris vtv port breaks x32 build
On Mon, Nov 30, 2015 at 6:57 PM, Jeff Law wrote: > What part of this requires bits to run? I see AC_COMPILE_IFELSE, but not > anything which obviously requires running the resulting code. Without AC_USE_SYSTEM_EXTENSIONS one gets: configure.ac:111: warning: AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS ../../lib/autoconf/specific.m4:332: AC_GNU_SOURCE is expanded from... configure.ac:111: the top level
Re: Solaris vtv port breaks x32 build
On 11/28/2015 08:42 AM, Ulrich Drepper wrote: After the Solaris vtv port was added my build of the x86 gcc with x32 support fails. The build is special since the kernel doesn't have x32 support and I cannot directly run x32 binaries (they are run in a kvm kernel). This is used to work well by configuring the tree with --build and --host etc. The changes to libvtv/configure.ac forced the execution of some code for all targets, specifically the AC_USE_SYSTEM_EXTENSIONS macro. Once I take this (and the code depending on it) out the build is once again fine. Below is the change I used. Can we revert the change until the Solaris port is correctly done? What part of this requires bits to run? I see AC_COMPILE_IFELSE, but not anything which obviously requires running the resulting code. jeff
Re: basic asm and memory clobbers - Proposed solution
> On Nov 29, 2015, at 6:53 PM, David Wohlferd wrote:
>
>
>
> On 11/28/2015 10:30 AM, paul_kon...@dell.com wrote:
>>> On Nov 28, 2015, at 2:02 AM, Bernd Edlinger
>>> wrote:
>>>
>>> ...
>>> Well, I start to think that Jeff is right, and we should treat a asm ("")
>>> as if it
>>> were asm volatile ("" ::: ) but if the asm ("nonempty with optional %") we
>>> should
>>> treat it as asm volatile ("nonempty with optional %%" ::: "memory").
>> I agree. Even if that goes beyond the letter of what the manual has
>> promised before, it is the cautious answer, and it matches expectations of a
>> lot of existing code.
>
> Trying to guess what people might have been expecting is a losing game.
> There is a way for people to be clear about what they want to clobber, and
> that's to use extended asm. The way to clear up the ambiguity is to start
> deprecating basic asm, not to add to the confusion by changing its behavior
> after all these years.
>
> And the first step to do that is to provide a means of finding them. That's
> what the patch at https://gcc.gnu.org/ml/gcc/2015-11/msg00198.html does.
>
> Once they are located, people can decide for themselves what to do. If they
> favor the 'cautious' approach, they can change their asms to use :::"memory"
> (or start clobbering registers too, to be *really* safe). For people who
> require maximum backward compatibility and/or minimum impact, they can use
> :::.
>
> Have you tried that patch? How many warnings does it kick out for your
> projects?
The trouble with warnings is that they only help with projects that are
currently maintained.
paul
Re: basic asm and memory clobbers - Proposed solution
On 11/29/2015 11:53 PM, David Wohlferd wrote: > > Trying to guess what people might have been expecting is a losing game. We have to do it all the time. > There is a way for people to be clear about what they want to clobber, > and that's to use extended asm. The way to clear up the ambiguity is to > start deprecating basic asm, not to add to the confusion by changing its > behavior after all these years. Well, I disagree. The warning is good, but so is the memory clobber. They're not exclusive. Andrew.
GCC 5.3 Release Candidate available from gcc.gnu.org
The first release candidate for GCC 5.3 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/5.3.0-RC-20151130 and shortly its mirrors. It has been generated from SVN revision 231055. I have sofar bootstrapped the release candidate on x86_64-suse-linux-gnu. Please test the release candidate and report any issues to bugzilla. If all goes well I'd like to release GCC 5.3 at the beginning of next week.
GCC 5 branch now frozen for GCC 5.3 RC1
The GCC 5 branch is now frozen for creating a first release candidate for GCC 5.3. All changes from now on require release manager approval. Thanks, Richard.
