Re: Problem with memory alignment for 64 byte moves
Hi Ian Thanks for the response. All of those flags are set correctly, though it is still emitting loads and stores 4 byte aligned and not 8. I'm trying to get the compiler to combine two 4 byte loads in to a single 8 byte load as it is more efficient on this architecture, so I'm guessing because the objects being loaded are actually 4 byte aligned, the compiler is matching for this alignment. There was a similar email about combining loads/stores which people seemed to suggest wasn't possible. Is there any way to do this other than writing a machine reorg pass which will split up loads and stores it notices are misaligned? On 3 December 2010 19:34, Ian Lance Taylor wrote: > Neil Hickey writes: > >> I'm porting gcc to a new architecture and I'm allowing use of movdi >> instructions as the processor allows 8 byte loads. The processor >> however requires 8 byte loads and stores to be naturally aligned, yet >> gcc seems to be emitting loads and stores that are 4 byte aligned. How >> can I make sure that gcc will only emit 8 byte loads and stores if it >> knows the address, which can be in a register, is 8 byte aligned? > > Define STRICT_ALIGNMENT to 1. > > Make sure that BIGGEST_ALIGNMENT, BIGGEST_FIELD_ALIGNMENT, > MAX_STACK_ALIGNMENT, DATA_ALIGNMENT, etc. are correct. > > Ian >
Question about long jump implementation
I'm trying to implement long jump and I'm using the call instruction
in the arm implementation as a reference.
The code looks like this:
rtx callee, pat;
callee = XEXP(operands[0], 0);
if (GET_CODE (callee) == SYMBOL_REF
? atdsp_is_long_call_p (SYMBOL_REF_DECL (callee))
: !REG_P (callee)) {
XEXP(operands[0], 0) = force_reg (SImode, callee);
}
pat = gen_call_internal (operands[0], operands[1]);
emit_call_insn(pat);
DONE;
What I want to happen is for the function name to be copied to a
register and then the compiler emit the instruction to call the
function, by jumping to the address held in that register.
The compiler emits instructions that copy the function name to a
register, then it loads from the value of this register, before
jumping to the loaded value. What I want it to do is copy the function
name to the register, then jump to the address held in this register.
Does anyone know what it is I've done wrong and how I can get this to work?
Thanks
Neil
relinking `libjvm.la' error when make install libjava
Hi, guys. I'm compiling gcc-4.4.2 on an Arm similar machine with Java enabled. Compilation is completed, but a failure comes out when make install, with the error of '"relink libgvm". Do anyone know the reason of the failure? I really appreciate your support. : make ; exec true "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CFLAGS=-g -O2 " "CXXFLAGS=-g -O2 -D_GNU_SOURCE " "CPPFLAGS=" "CFLAGS_FOR_BUILD=" "CFLAGS_FOR_TARGET=-g -O2" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c" "GCJFLAGS=-g -O2" "LDFLAGS=" "LIBCFLAGS=-g -O2 " "LIBCFLAGS_FOR_TARGET=-g -O2" "MAKE=make" "MAKEINFO=makeinfo --split-size=500 --split-size=500 " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "RUNTESTFLAGS=" "exec_prefix=/home/vhome/FengYi/pxx/install/usr" "datadir=/home/vhome/FengYi/pxx/install/usr/share" "infodir=/home/vhome/FengYi/pxx/install/usr/info" "libdir=/home/vhome/FengYi/pxx/install/usr/lib" "mandir=/home/vhome/FengYi/pxx/install/usr/man" "prefix=/home/vhome/FengYi/pxx/install/usr" "gxx_include_dir=/home/vhome/FengYi/pxx/install/usr/include/c++/4.4.2" "AR=/home/vhome/FengYi/pxx/build_cross/lib/gcc/unicore32-linux/4.4.2/../../../../unicore32-linux/bin/ar" "AS=/home/vhome/FengYi/pxx/build_cross/lib/gcc/unicore32-linux/4.4.2/../../../../unicore32-linux/bin/as" "LD=/home/vhome/FengYi/pxx/build_cross/lib/gcc/unicore32-linux/4.4.2/../../../../unicore32-linux/bin/ld" "LIBCFLAGS=-g -O2 " "NM=/home/vhome/FengYi/pxx/build_cross/lib/gcc/unicore32-linux/4.4.2/../../../../unicore32-linux/bin/nm" "PICFLAG=" "RANLIB=/home/vhome/FengYi/pxx/build_cross/lib/gcc/unicore32-linux/4.4.2/../../../../unicore32-linux/bin/ranlib" "DESTDIR=" "JAR=jar" DO=all multi-do make[4]: Entering directory `/home/vhome/FengYi/pxx/build_native/build_gcc/unicore32-linux/libjava' test -z "/home/vhome/FengYi/pxx/install/usr/bin" || mkdir -p -- "/home/vhome/FengYi/pxx/install/usr/bin" /bin/sh ./libtool --mode=install /usr/bin/install -c 'jv-convert' '/home/vhome/FengYi/pxx/install/usr/bin/jv-convert' libtool: install: warning: `libgcj.la' has not been installed in `/home/vhome/FengYi/pxx/install/usr/lib' libtool: install: /usr/bin/install -c .libs/jv-convert /home/vhome/FengYi/pxx/install/usr/bin/jv-convert /bin/sh ./libtool --mode=install /usr/bin/install -c 'gij' '/home/vhome/FengYi/pxx/install/usr/bin/gij' libtool: install: warning: `libgij.la' has not been installed in `/home/vhome/FengYi/pxx/install/usr/lib' libtool: install: warning: `/home/vhome/FengYi/pxx/build_native/build_gcc/unicore32-linux/libjava/libgcj.la' has not been installed in `/home/vhome/FengYi/pxx/install/usr/lib' libtool: install: /usr/bin/install -c .libs/gij /home/vhome/FengYi/pxx/install/usr/bin/gij /bin/sh ./libtool --mode=install /usr/bin/install -c 'grmic' '/home/vhome/FengYi/pxx/install/usr/bin/grmic' libtool: install: warning: `libgcj-tools.la' has not been installed in `/home/vhome/FengYi/pxx/install/usr/lib' libtool: install: /usr/bin/install -c .libs/grmic /home/vhome/FengYi/pxx/install/usr/bin/grmic /bin/sh ./libtool --mode=install /usr/bin/install -c 'grmiregistry' '/home/vhome/FengYi/pxx/install/usr/bin/grmiregistry' libtool: install: warning: `libgcj-tools.la' has not been installed in `/home/vhome/FengYi/pxx/install/usr/lib' libtool: install: /usr/bin/install -c .libs/grmiregistry /home/vhome/FengYi/pxx/install/usr/bin/grmiregistry /bin/sh ./libtool --mode=install /usr/bin/install -c 'gcj-dbtool' '/home/vhome/FengYi/pxx/install/usr/bin/gcj-dbtool' libtool: install: warning: `libgcj.la' has not been installed in `/home/vhome/FengYi/pxx/install/usr/lib' libtool: install: /usr/bin/install -c .libs/gcj-dbtool /home/vhome/FengYi/pxx/install/usr/bin/gcj-dbtool /bin/sh ./libtool --mode=install /usr/bin/install -c 'gappletviewer' '/home/vhome/FengYi/pxx/install/usr/bin/gappletviewer' libtool: install: warning: `libgcj-tools.la' has not been installed in `/home/vhome/FengYi/pxx/install/usr/lib' libtool: install: /usr/bin/install -c .libs/gappletviewer /home/vhome/FengYi/pxx/install/usr/bin/gappletviewer /bin/sh ./libtool --mode=install /usr/bin/install -c 'gjarsigner' '/home/vhome/FengYi/pxx/install/usr/bin/gjarsigner' libtool: install: warning: `libgcj-tools.la' has not been installed in `/home/vhome/FengYi/pxx/install/usr/lib' libtool: install: /usr/bin/install -c .libs/gjarsigner /home/vhome/FengYi/pxx/install/usr/bin/gjarsigner /bin/sh ./libtool --mode=install /usr/bin/install -c 'gkeytool' '/home/vhome/FengYi/pxx/install/usr/bin/gkeytool' libtool: install: warning: `libgcj-tools.la' has not been installed in `/home/vhome/FengYi/pxx/install/usr/lib' libtool: install: /usr/bin/install -c .libs/gkeytool /home/vhome/FengYi/pxx/install/usr/bin/gkeytool /bin/sh ./libtool --mode=install /usr/bin/install -c 'gjar' '/home/vhome/FengYi/pxx/install/usr/bin/gjar' libtool: install: warning: `libgcj-tools.la' has not been installed in `/home/vhome/FengYi/pxx/install/usr/lib' li
GCC 4.5.3 Status Report (2010-12-16)
Status == GCC 4.5.2 has been released, the release will be announced after mirrors have catched up. The branch is now open for regression and documentation fixes again. Quality Data Priority # Change from Last Report --- --- P10 P2 119 - 13 P39 + 8 --- --- Total 128 - 5 Previous Report === http://gcc.gnu.org/ml/gcc/2010-11/msg00604.html
Re: Using add_stmt in gimplify.c
Is there any change I should do to the Makefile.in or any other files? Is there any specific header files I should add ? (I have c-family/c-common.h). Regards, Bobby - Original Message From: Ian Lance Taylor To: Robert Stevenson Cc: g...@gnu.org Sent: Wed, December 15, 2010 11:19:44 PM Subject: Re: Using add_stmt in gimplify.c Robert Stevenson writes: > I am trying to add some information/instructions into loop statements in > GCC front-end. For this, in the previous gcc, I have used "add_stmt" to > insert > these instructions and they worked fine. When I do it in gcc 4.6 (snapshot > 2010/12/4) I get "undefined references to "add_stmt." > > One thing I found different in this 4.6 version of gcc is that the files > prefixed with "c-" have been stored in the c-family director. Is this the >reason > > why I am not able to use add_stmt in the gimplify.c function? What can I do > to > use "add_stmt" function? add_stmt is still there in the C and C++ frontends; I don't know why it doesn't work for you. But you shouldn't really call it from gimplify.c anyhow, as add_stmt adds statements to the wrong place. In gimplify.c you should use functions like gimplify_seq_add_stmt. There are many examples in that file. Ian
Is eliminate_regs_in_insn allowed to generate invalid instruction?
Hi,
I was hit by an ICE in reload. You know how difficult to debug it ☺.
My primary suspect is that eliminate_regs_in_insn transforms
(insn 680 679 681 84 src/weighted_prediction.c:729 (set (reg:DF 1 r1)
(mem:DF (plus:SI (mult:SI (reg:SI 596 [ ivtmp.474 ])
(const_int 8 [0x8]))
(reg/f:SI 1105)) [3 S8 A8])) 448 {*ldl_dfmode} (nil))
To:
(insn 680 679 681 84 src/weighted_prediction.c:729 (set (reg:DF 1 r1)
(mem:DF (plus:SI (plus:SI (mult:SI (reg:SI 596 [ ivtmp.474 ])
(const_int 8 [0x8]))
(reg/f:SI 57 r57))
(const_int 40 [0x28])) [3 S8 A8])) 448 {*ldl_dfmode} (nil))
The latter has illegal memory address mode, and r57 is our stack pointer.
Since reload part is still half mystery to me, I wonder whether this is an
wrong transformation and causes the following ICE. Is it allowed that
Eliminate_regs_in_insn to generate such illegal instruction?
Cheers,
Bingfeng Mei
Re: relinking `libjvm.la' error when make install libjava
Hello, * majia gm wrote on Thu, Dec 16, 2010 at 04:21:14PM CET: > I'm compiling gcc-4.4.2 on an Arm similar machine with Java enabled. > Compilation is completed, but a failure comes out when make install, > with the error of '"relink libgvm". > > Do anyone know the reason of the failure? > I really appreciate your support. Can you please open up a bugzilla entry with all the details asked for in http://gcc.gnu.org/bugs/ ? Esp. how you invoke configure, make, make install exactly. Thanks. It would be great if you could retry with 4.5.2 or trunk (or a nightly snapshot) to see whether the behavior is still present. This might be one of those issues where --with-sysroot is missing, or that is fixed by newer libtool, or both; I can't tell yet. Thanks, Ralf [...] > /bin/sh ./libtool --mode=install /usr/bin/install -c 'libjvm.la' > '/home/vhome/FengYi/pxx/install/usr/lib/gcj-4.4.2-10/libjvm.la' > libtool: install: warning: relinking `libjvm.la' > libtool: install: (cd > /home/vhome/FengYi/pxx/build_native/build_gcc/unicore32-linux/libjava; > /bin/sh > /home/vhome/FengYi/pxx/build_native/build_gcc/unicore32-linux/libjava/libtool > --tag CXX --mode=relink unicore32-linux-c++ -fno-rtti > -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum > -D_FILE_OFFSET_BITS=64 -Wextra -Wall -D_GNU_SOURCE > -DPREFIX=\"/home/vhome/FengYi/pxx/install/usr\" > -DTOOLEXECLIBDIR=\"/home/vhome/FengYi/pxx/install/usr/lib\" > -DJAVA_HOME=\"/home/vhome/FengYi/pxx/install/usr\" > -DBOOT_CLASS_PATH=\"/home/vhome/FengYi/pxx/install/usr/share/java/libgcj-4.4.2.jar\" > -DJAVA_EXT_DIRS=\"/home/vhome/FengYi/pxx/install/usr/share/java/ext\" > -DGCJ_ENDORSED_DIRS=\"/home/vhome/FengYi/pxx/install/usr/share/java/gcj-endorsed\" > -DGCJ_VERSIONED_LIBDIR=\"/home/vhome/FengYi/pxx/install/usr/lib/gcj-4.4.2-10\" > -DPATH_SEPARATOR=\":\" -DECJ_JAR_FILE=\"\" > -DLIBGCJ_DEFAULT_DATABASE=\"/home/vhome/FengYi/pxx/install/usr/lib/gcj-4.4.2-10/classmap.db\" > -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-4.4.2-10/classmap.db\" -g > -O2 -D_GNU_SOURCE -o libjvm.la -rpath > /home/vhome/FengYi/pxx/install/usr/lib/gcj-4.4.2-10 -avoid-version > -Wl,-Bsymbolic-functions jni-libjvm.lo > -L/home/vhome/FengYi/pxx/build_native/build_gcc/unicore32-linux/libjava/.libs > libgcj.la ) > libtool: relink: warning: > `/home/vhome/FengYi/pxx/build_cross/lib/gcc/unicore32-linux/4.4.2/../../../../unicore32-linux/lib/libstdc++.la' > seems to be moved > libtool: relink: unicore32-linux-c++ -shared -nostdlib > /home/vhome/FengYi/pxx/build_cross/lib/gcc/unicore32-linux/4.4.2/../../../../unicore32-linux/lib/crti.o > /home/vhome/FengYi/pxx/build_cross/lib/gcc/unicore32-linux/4.4.2/crtbeginS.o > .libs/jni-libjvm.o -Wl,-rpath > -Wl,/home/vhome/FengYi/pxx/install/usr/lib -Wl,-rpath > -Wl,/home/vhome/FengYi/pxx/build_cross/unicore32-linux/lib > -L/home/vhome/FengYi/pxx/build_native/build_gcc/unicore32-linux/libjava/.libs > -L/home/vhome/FengYi/pxx/install/usr/lib -lgcj > -L/home/vhome/FengYi/pxx/build_native/build_gcc/unicore32-linux/libjava > -L/home/vhome/FengYi/pxx/build_cross/lib/gcc/unicore32-linux/4.4.2/../../../../unicore32-linux/lib > -lpthread -lrt -ldl > -L/home/vhome/FengYi/pxx/build_cross/lib/gcc/unicore32-linux/4.4.2 > -L/home/vhome/FengYi/pxx/build_cross/unicore32-linux/lib -lstdc++ -lm > -lc -lgcc_s > /home/vhome/FengYi/pxx/build_cross/lib/gcc/unicore32-linux/4.4.2/crtendS.o > /home/vhome/FengYi/pxx/build_cross/lib/gcc/unicore32-linux/4.4.2/../../../../unicore32-linux/lib/crtn.o > -Wl,-Bsymbolic-functions -Wl,-soname -Wl,libjvm.so -o > .libs/libjvm.so > /home/vhome/FengYi/pxx/build_cross/lib/gcc/unicore32-linux/4.4.2/../../../../unicore32-linux/bin/ld: > skipping incompatible /lib/libpthread.so.0 when searching for > /lib/libpthread.so.0 > /home/vhome/FengYi/pxx/build_cross/lib/gcc/unicore32-linux/4.4.2/../../../../unicore32-linux/bin/ld: > cannot find /lib/libpthread.so.0 > collect2: ld returned 1 exit status > libtool: install: error: relink `libjvm.la' with the above command > before installing it > make[4]: *** [install-dbexecLTLIBRARIES] Error 1 > make[4]: Leaving directory > `/home/vhome/FengYi/pxx/build_native/build_gcc/unicore32-linux/libjava'
gcc-4.5-20101216 is now available
Snapshot gcc-4.5-20101216 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20101216/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 167957 You'll find: gcc-4.5-20101216.tar.bz2 Complete GCC (includes all of below) MD5=5fcea7a515739e6bf07c1186492f6d9c SHA1=d3a9a1ac97c230e3bf9c63786e1cb11cacb4d908 gcc-core-4.5-20101216.tar.bz2C front end and core compiler MD5=8c56658144ac3bbd13ac431ea2a3721f SHA1=02796b5b8268e1ac55503c2d763438547fc664c3 gcc-ada-4.5-20101216.tar.bz2 Ada front end and runtime MD5=13cf58703abff72ec2b547fe1477228e SHA1=20340cbfe169b6650a3bbdd7e3ba670f32365ee6 gcc-fortran-4.5-20101216.tar.bz2 Fortran front end and runtime MD5=766c4365d1e06f2f1f954f95e8bb549b SHA1=3de9c88d19086f7fe0cd7b062ae624ca4770b658 gcc-g++-4.5-20101216.tar.bz2 C++ front end and runtime MD5=bec5ef2806c2bfd642f69330b97a1529 SHA1=ce256b73e2fc45b0a239151f1b70e95f3405cec7 gcc-go-4.5-20101216.tar.bz2 Go front end and runtime MD5=aafeb46964e92dda37259617abe57401 SHA1=6496964dc191ed9e495dbf491cce33c78b21779c gcc-java-4.5-20101216.tar.bz2Java front end and runtime MD5=e7b883cca15ce6622b364d506af42155 SHA1=26ea5de3d0e5d4f4e9b088dd78accce1e44cbb62 gcc-objc-4.5-20101216.tar.bz2Objective-C front end and runtime MD5=0897d1818282535841f02baed87f453e SHA1=a9aa74b7d44a160cc2f915bcfb73bf9edb4d9945 gcc-testsuite-4.5-20101216.tar.bz2 The GCC testsuite MD5=c433d244ca4e0ec693283a19bb2e710a SHA1=ec79b3417de03d28cd760aaa48f3631bec3cd9ae Diffs from 4.5-20101209 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Question about long jump implementation
Neil Hickey writes:
> I'm trying to implement long jump and I'm using the call instruction
> in the arm implementation as a reference.
>
> The code looks like this:
>
> rtx callee, pat;
>
> callee = XEXP(operands[0], 0);
> if (GET_CODE (callee) == SYMBOL_REF
> ? atdsp_is_long_call_p (SYMBOL_REF_DECL (callee))
> : !REG_P (callee)) {
> XEXP(operands[0], 0) = force_reg (SImode, callee);
> }
> pat = gen_call_internal (operands[0], operands[1]);
> emit_call_insn(pat);
> DONE;
>
> What I want to happen is for the function name to be copied to a
> register and then the compiler emit the instruction to call the
> function, by jumping to the address held in that register.
>
> The compiler emits instructions that copy the function name to a
> register, then it loads from the value of this register, before
> jumping to the loaded value. What I want it to do is copy the function
> name to the register, then jump to the address held in this register.
>
> Does anyone know what it is I've done wrong and how I can get this to work?
I think it's impossible for us to say without more information.
Does the RTL look correct? If not, then you need to fix the RTL
generation, which will look more or less like the code above. If the
RTL does look correct, then you need to fix your MD file to generate
instructions which correctly represent the RTL.
Ian
Re: Using add_stmt in gimplify.c
Robert Stevenson writes: > Is there any change I should do to the Makefile.in or any other files? Is > there > any specific header files I should add ? (I have c-family/c-common.h). We're happy to answer specific questions but it's nearly impossible for us to answer general questions like the above. If you want to modify gcc, you need to be a reasonably skilled C programmer. If you can't answer questions like these yourself, or at least narrow them down into specific questions that you can ask us, then I think you may need to learn more before you work on modifying gcc. There is lots and lots of code in gcc which adds instructions to functions, so there are plenty of examples for you to look at. Ian
Re: Is eliminate_regs_in_insn allowed to generate invalid instruction?
"Bingfeng Mei" writes:
> I was hit by an ICE in reload. You know how difficult to debug it ☺.
>
> My primary suspect is that eliminate_regs_in_insn transforms
>
>
> (insn 680 679 681 84 src/weighted_prediction.c:729 (set (reg:DF 1 r1)
> (mem:DF (plus:SI (mult:SI (reg:SI 596 [ ivtmp.474 ])
> (const_int 8 [0x8]))
> (reg/f:SI 1105)) [3 S8 A8])) 448 {*ldl_dfmode} (nil))
>
>
> To:
> (insn 680 679 681 84 src/weighted_prediction.c:729 (set (reg:DF 1 r1)
> (mem:DF (plus:SI (plus:SI (mult:SI (reg:SI 596 [ ivtmp.474 ])
> (const_int 8 [0x8]))
> (reg/f:SI 57 r57))
> (const_int 40 [0x28])) [3 S8 A8])) 448 {*ldl_dfmode} (nil))
>
>
> The latter has illegal memory address mode, and r57 is our stack pointer.
>
> Since reload part is still half mystery to me, I wonder whether this is an
> wrong transformation and causes the following ICE. Is it allowed that
> Eliminate_regs_in_insn to generate such illegal instruction?
It's normal for reload to produce instructions with invalid operands
during its operation, with the expectation that the invalid operands
will be reloaded into registers before the pass is complete. I couldn't
see the specific ICE in your message, so I don't know if that is what is
happening here.
Ian
Re: The Linux binutils 2.21.51.0.4 is released
This release fixes the Linux relocatable kernel build:
http://sourceware.org/bugzilla/show_bug.cgi?id=12327
The follow Linux binutils releases are affected: 2.20.51.0.12,
2.21.51.0.1, 2.21.51.0.2 and 2.21.51.0.3. The FSF binutils 2.21
is also affected.
H.J.
---
This is the beta release of binutils 2.21.51.0.4 for Linux, which is
based on binutils 2010 1217 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been applied and
in what order they have been applied.
Starting from the 2.21.51.0.2 release, BFD linker has the working LTO
plugin support. It can be used with GCC 4.5 and above. For GCC 4.5, you
need to configure GCC with --enable-gold to enable LTO plugin support.
Starting from the 2.21.51.0.2 release, binutils fully supports compressed
debug sections. However, compressed debug section isn't turned on by
default in assembler. I am planning to turn it on for x86 assembler in
the future release, which may lead to the Linux kernel bug messages like
WARNING: lib/ts_kmp.o (.zdebug_aranges): unexpected non-allocatable section.
But the resulting kernel works fine.
Starting from the 2.20.51.0.4 release, no diffs against the previous
release will be provided.
You can enable both gold and bfd ld with --enable-gold=both. Gold will
be installed as ld.gold and bfd ld will be installed as ld.bfd. By
default, ld.bfd will be installed as ld. You can use the configure
option, --enable-gold=both/gold to choose gold as the default linker,
ld. IA-32 binary and X64_64 binary tar balls are configured with
--enable-gold=both/ld --enable-plugins --enable-threads.
Starting from the 2.18.50.0.4 release, the x86 assembler no longer
accepts
fnstsw %eax
fnstsw stores 16bit into %ax and the upper 16bit of %eax is unchanged.
Please use
fnstsw %ax
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections from being
equal to VMA (virtual memory address), to keeping the difference between
LMA and VMA the same as the previous output section in the same region.
For
.data.init_task : { *(.data.init_task) }
LMA of .data.init_task section is equal to its VMA with the old linker.
With the new linker, it depends on the previous output section. You
can use
.data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) }
to ensure that LMA of .data.init_task section is always equal to its
VMA. The linker script in the older 2.6 x86-64 kernel depends on the
old behavior. You can add AT (ADDR(section)) to force LMA of
.data.init_task section equal to its VMA. It will work with both old
and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and
above is OK.
The new x86_64 assembler no longer accepts
monitor %eax,%ecx,%edx
You should use
monitor %rax,%ecx,%edx
or
monitor
which works with both old and new x86_64 assemblers. They should
generate the same opcode.
The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,
movl (%eax),%ds
movl %ds,(%eax)
To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,
mov (%eax),%ds
mov %ds,(%eax)
should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.1 will also support
movw (%eax),%ds
movw %ds,(%eax)
without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are
available at
http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch
http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch
The ia64 assembler is now defaulted to tune for Itanium 2 processors.
To build a kernel for Itanium 1 processors, you will need to add
ifeq ($(CONFIG_ITANIUM),y)
CFLAGS += -Wa,-mtune=itanium1
AFLAGS += -Wa,-mtune=itanium1
endif
to arch/ia64/Makefile in your kernel source tree.
Please report any bugs related to binutils 2.21.51.0.4 to
hjl.to...@gmail.com
and
http://www.sourceware.org/bugzilla/
Changes from binutils 2.21.51.0.3:
1. Update from binutils 2010 1217.
2. Fix the Linux relocatable kernel build. PR 12327.
3. Improve mips support.
Changes from binutils 2.21.51.0.2:
1. Update from binutils 2010 1215.
2. Add BFD linker support for placing input .ctors/.dtors sections in
output .init_array/.fini_array section. Add SORT_BY_INIT_PRIORITY. The
benefits are
a. Avoid output .ctors/.dtors section in executables and shared
libraries.
b. Allow mixing input .ctors/.dtors sections with input
.init_array/.fini_array sectiobs. GCC PR 46770.
3. Add BFD linker support for "ld -r" on mixed IR/non-IR objects. Add
the new ELF section type SHT_GNU_OBJECT_ONLY (0x6ff8). See
http://sourceware.org/bugzilla/show_bug.c
Re: The Linux binutils 2.21.51.0.4 is released
On Fri, Dec 17, 2010 at 12:50 PM, H.J. Lu wrote: > This release fixes the Linux relocatable kernel build: > http://sourceware.org/bugzilla/show_bug.cgi?id=12327 > 1. binutils-2.21.51.0.4.tar.bz2. Source code. > The primary sites for the beta Linux binutils are: > 1. http://www.kernel.org/pub/linux/devel/binutils/ Did you forget to upload it? Thanks, Jeff
call for libstdc++ profile mode diagnostic ideas
Hello libstdc++ developers and users, (I cc-ed gcc@gcc.gnu.org for a larger audience as others may offer suggestions not as library developers but as C++ programmers. Sorry in advance if this is spam to you.) I'm planning to add a set of new performance diagnostics to the libstdc++ profile mode (http://gcc.gnu.org/onlinedocs/libstdc++/manual/profile_mode.html) and am trying to come up with a list of what diagnostics are most meaningful and most wanted. The profile mode currently gives diagnostics such as "use unordered_map instead of map at context ...". The full list is at http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt03ch19s07.html. At this (brainstorming) point I'm looking for any suggestions, including and not limited to: - container selection (e.g., replace list with deque). - container implementation selection (e.g., string implementation). - algorithm selection (e.g., sort implementation) - data structure or algorithm parameter selection (e.g., fixed string reserved size value for a particular context). Please reply to this message or email me privately (r...@google.com) if you have any suggestions for new diagnostics, or about the profile mode in general, or to express your support for a particular proposed diagnostic. For new diagnostics, it works best if you can provide: - A simple description, e.g., "replace vector with list". - (optional) The instrumentation points, even if vague, e.g., "instrument insertion, element access and iterators". - (optional) How the decision is made, e.g. "there are many inserts in the middle, there is no random access and it's not iterated through many times". Keep in mind that profile mode analysis is context sensitive (context = dynamic call stack), so it's OK to propose both "change list to vector" and "change vector to list", with different criteria sets as they may both be right in different contexts. To make sure the diagnostics are realistic, keep in mind that analysis is usually based on observing, at run time, container state before and after each operation on the container or on iterators of the container. Once I have a good pool of ideas and preferences, I will present a refined set to libstd...@gcc.gnu.org for discussion. Thank you, Silvius
