trunk: bootstrap comparison failure
I believe, something broke the trunk tip build recently: Comparing stages 2 and 3 warning: gcc/cc1plus-checksum.o differs warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/wlocale-inst.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/future.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/locale-inst.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/system_error.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/parallel_settings.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/bitmap_allocator.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/wlocale-inst.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/locale-inst.o differs x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/eh_alloc.o differs make[2]: *** [compare] Error 1 -stage2-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/wlocale-inst.o: file format elf64-x86-64 -stage2-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/wlocale-inst.o +stage3-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/wlocale-inst.o: file format elf64-x86-64 +stage3-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/wlocale-inst.o architecture: i386:x86-64, flags 0x0011: HAS_RELOC, HAS_SYMS start address 0x @@ -1399,7 +1399,7 @@ CONTENTS, ALLOC, LOAD, READONLY, DATA 695 .text._ZNKSt7num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE6do_getES3_S3_RSt8ios_baseRSt12_Ios_IostateRy 0038 00011540 2**4 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE -696 .text.startup._GLOBAL__sub_I_.._.._.._.._gccgo_git_libstdc___v3_src_wlocale_inst.cc_76D38880_14146711 00b6 00011580 2**4 +696 .text.startup._GLOBAL__sub_I_.._.._.._.._gccgo_git_libstdc___v3_src_wlocale_inst.cc_76D38880_EB7C2B89 00b6 00011580 2**4 ... - ld .text.startup._GLOBAL__sub_I_.._.._.._.._gccgo_git_libstdc___v3_src_wlocale_inst.cc_76D38880_14146711 .text.startup._GLOBAL__sub_I_.._.._.._.._gccgo_git_libstdc___v3_src_wlocale_inst.cc_76D38880_14146711 - l F .text.startup._GLOBAL__sub_I_.._.._.._.._gccgo_git_libstdc___v3_src_wlocale_inst.cc_76D38880_14146711 00b6 _GLOBAL__sub_I_.._.._.._.._gccgo_git_libstdc___v3_src_wlocale_inst.cc_76D38880_14146711 + ld .text.startup._GLOBAL__sub_I_.._.._.._.._gccgo_git_libstdc___v3_src_wlocale_inst.cc_76D38880_EB7C2B89 .text.startup._GLOBAL__sub_I_.._.._.._.._gccgo_git_libstdc___v3_src_wlocale_inst.cc_76D38880_EB7C2B89 + l F .text.startup._GLOBAL__sub_I_.._.._.._.._gccgo_git_libstdc___v3_src_wlocale_inst.cc_76D38880_EB7C2B89 00b6 _GLOBAL__sub_I_.._.._.._.._gccgo_git_libstdc___v3_src_wlocale_inst.cc_76D38880_EB7C2B89 ...
Re: trunk: bootstrap comparison failure
> -696 > .text.startup._GLOBAL__sub_I_.._.._.._.._gccgo_git_libstdc___v3_src_wlocale_inst.cc_76D38880_14146711 > 00b6 00011580 2**4 > +696 > .text.startup._GLOBAL__sub_I_.._.._.._.._gccgo_git_libstdc___v3_src_wlocale_inst.cc_76D38880_EB7C2B89 > 00b6 00011580 2**4 Those are differences in random seed. I think this might be caused by my patch to avoid collect2 recognizable names. Aren't the comparsion tests supposed to ignore them? I don't seem to be able to find the script responsible for comparing at the moment. Honza
Re: trunk: bootstrap comparison failure
Hi,
the problem is that we special case constructors and avoid random seed on them
on targets that have global ctors.
I think bootstrap with C++ or GO is broken for a while on targets not having
ctor support, but now it broke
on targets with ctor support as a result of my patch renaming some of the ctors
from GLOBAL__I into GLOBAL__sub_I.
The other is no longer special cased and thus get random seed. I am testing
the following patch and will commit
it as obvious if it passes.
Can someone, please, confirm that it fixes the reported bootstrap miscompare? I
don't see it on my setup as everything
gets inlined for me in the testcases pointed out and the functions disappear.
Index: tree.c
===
--- tree.c (revision 167819)
+++ tree.c (working copy)
@@ -8518,8 +8518,12 @@ get_file_function_name (const char *type
p = q = ASTRDUP (first_global_object_name);
/* If the target is handling the constructors/destructors, they
will be local to this file and the name is only necessary for
- debugging purposes. */
- else if ((type[0] == 'I' || type[0] == 'D') && targetm.have_ctors_dtors)
+ debugging purposes.
+ We also assign sub_I and sub_D sufixes to constructors called from
+ the global static constructors. These are always local. */
+ else if (((type[0] == 'I' || type[0] == 'D') && targetm.have_ctors_dtors)
+ || (type[0] == 's' && type[1]=='u' && type[2]=='b' && type[3]=='_'
+ && (type[4] == 'I' || type[4] == 'D')))
{
const char *file = main_input_filename;
if (! file)
Re: trunk: bootstrap comparison failure
On Wed, 2010-12-15 at 13:57 +0100, Jan Hubicka wrote:
> Hi,
> the problem is that we special case constructors and avoid random seed on
> them on targets that have global ctors.
> I think bootstrap with C++ or GO is broken for a while on targets not having
> ctor support, but now it broke
> on targets with ctor support as a result of my patch renaming some of the
> ctors from GLOBAL__I into GLOBAL__sub_I.
> The other is no longer special cased and thus get random seed. I am testing
> the following patch and will commit
> it as obvious if it passes.
> Can someone, please, confirm that it fixes the reported bootstrap miscompare?
> I don't see it on my setup as everything
> gets inlined for me in the testcases pointed out and the functions disappear.
A clean c,c++,go build just successfully passed through.
Thanks,
Martin
>
> Index: tree.c
> ===
> --- tree.c(revision 167819)
> +++ tree.c(working copy)
> @@ -8518,8 +8518,12 @@ get_file_function_name (const char *type
> p = q = ASTRDUP (first_global_object_name);
>/* If the target is handling the constructors/destructors, they
> will be local to this file and the name is only necessary for
> - debugging purposes. */
> - else if ((type[0] == 'I' || type[0] == 'D') && targetm.have_ctors_dtors)
> + debugging purposes.
> + We also assign sub_I and sub_D sufixes to constructors called from
> + the global static constructors. These are always local. */
> + else if (((type[0] == 'I' || type[0] == 'D') && targetm.have_ctors_dtors)
> +|| (type[0] == 's' && type[1]=='u' && type[2]=='b' && type[3]=='_'
> +&& (type[4] == 'I' || type[4] == 'D')))
> {
>const char *file = main_input_filename;
>if (! file)
Help with reloading
Hi,
I am doing a port in GCC 4.5.1.
The target supports storing immediate values into memory location
represented by a symbolic address. So in the move pattern i have given
constraints to represent this.
(define_insn "movqi_op"
[(set (match_operand:QI 0 "nonimmediate_operand" "=!Q,!Q,d,d,d,d,d,d,d,Q,R,S")
(match_operand:QI 1 "general_operand" "I,J,i,W,J,d,Q,R,S,d,d,d"))]
""
"@
st.s32\t%0, %1;
st.u32\t%0, %1;
set\t%0, %1;
set.u32\t%0, %1;
set.u32\t%0, %1;
move\t%0, %1;
ld%u0\t%0, %1;
ld%u0\t%0, %1;
ld%u0\t%0, %1;
st%u0\t%0, %1;
st%u0\t%0, %1;
st%u0\t%0, %1;"
)
where
Q represents symbolic address,
R represents all address formed using SP
S represents all address formed using address registers
I, J,W,i represents various const_ints
d represents general registers.
Whenever reload get a pattern to store const_int to a memory that is
scheduled for reloading, the reload pass will match it with Q
constraints. So to avoid those i added the constrain modifier '!' to
'Q'. But even then there is one particular case that causes trouble.
This happens when reload pass gets a pattern where the destination is
an illegal address and source is a pesudo register (no register
allocated) for which reg_equiv_constant[regno] != 0.
Before IRA pass:
(insn 27 25 33 4 pr23848-3.c:12 (set (mem/s/j:QI (reg/f:PQI 69) [0 S1 A32])
(reg:QI 93)) 7 {movqi_op} (expr_list:REG_DEAD (reg/f:PQI 69)
(expr_list:REG_EQUAL (const_int 49 [0x31])
(nil
Just before reloading phase:
(insn 27 25 33 4 pr23848-3.c:12 (set (mem/s/j:QI (reg/f:PQI 12 as0
[69]) [0 S1 A32])
(reg:QI 93)) 7 {movqi_op} (expr_list:REG_DEAD (reg/f:PQI 12 as0 [69])
(expr_list:REG_EQUAL (const_int 0 [0x0])
(nil
Since reg93 is not allocated with any register, its replaced with
reg_equiv_constant[regno], and this combination wins the (Q, I)
constraint pair and in that process 'losers' (variable in loop over
alternatives) becomes 0 and hence breaks out and returns. Due to this
compiler crashes with "insn does not satisfy its constraints:" error.
Any pointers in fixing this?
Regards,
Shafi
P.S. When can we merge constraints? What are the criteria to decide
which all constraints to merge
Re: trunk: bootstrap comparison failure
Jan Hubicka writes: > I think bootstrap with C++ or GO is broken for a while on targets not having > ctor support, but now it broke > on targets with ctor support as a result of my patch renaming some of the > ctors from GLOBAL__I into GLOBAL__sub_I. I didn't know you were making that change. There are a several tools which recognize _GLOBAL__ specially, including examining the next character. Have you updated the demangler? Have you updated the GNU linker--see ctor_prio in ld/ldlang.c? Ian
Re: trunk: bootstrap comparison failure
> Jan Hubicka writes: > > > I think bootstrap with C++ or GO is broken for a while on targets not > > having ctor support, but now it broke > > on targets with ctor support as a result of my patch renaming some of the > > ctors from GLOBAL__I into GLOBAL__sub_I. > > I didn't know you were making that change. There are a several tools > which recognize _GLOBAL__ specially, including examining the next > character. Have you updated the demangler? Have you updated the GNU > linker--see ctor_prio in ld/ldlang.c? I changed name only for functions that are produced internally in GCC. These are functions that are not constructors, but are called from constructors called GLOBAL__I/GLOBAL__D as usually. Most of time they are inlined, but in some cases they don't. Honza > > Ian
Re: trunk: bootstrap comparison failure
> > Jan Hubicka writes:
> >
> > > I think bootstrap with C++ or GO is broken for a while on targets not
> > > having ctor support, but now it broke
> > > on targets with ctor support as a result of my patch renaming some of the
> > > ctors from GLOBAL__I into GLOBAL__sub_I.
> >
> > I didn't know you were making that change. There are a several tools
> > which recognize _GLOBAL__ specially, including examining the next
> > character. Have you updated the demangler? Have you updated the GNU
> > linker--see ctor_prio in ld/ldlang.c?
>
> I changed name only for functions that are produced internally in GCC. These
> are functions
> that are not constructors, but are called from constructors called
> GLOBAL__I/GLOBAL__D as usually.
> Most of time they are inlined, but in some cases they don't.
Hi,
I've commited the attached patch after testing.
What I wrote above is however correct only for targets not having ctors/dtors.
For targets having ctors/dtors
we can end up inserting GLOBAL__sub_I and GLOBAL__sub_D into .ctor/.dtor
setions.
If this breaks logic in linker, we need to do something about it.
The problem is that GCC produce constructors/destructors at various places and
they all used to be called GLOBAL__I
and GLOBAL__D. Then in some cases (on targets that don't have global
ctors/dtors or with LTO and ctor/dtor merging)
it actually collect them into single constructor function called also
GLOBAL__I and GLOBAL__D.
Since the first ones are static functions called by the actual constructor, we
get problem on targets not having
ctors/dtors because collect2 collects even static symbols and attempts to call
them from main(). This is reason why
I renamed them to be no longer recognized specially.
This previously worked because ctor merging added always_inline flag to the
contructors. I am convinced this is unsafe
WRT uninlinable functoins.
Now if this breaks other logic in ld & friends on have_cdtor targets, I guess
we could
1) du _sub_I/sub_D mangling only on targets not having ctors/dtors where
merged constructor is always produced
2) make constructor merging to discover those specially named functions and
actually rename those specially called functions.
3) update collect2 to not collect static symbols
4) update the tools to also deal with sub_? variant.
I guess the order is also order how difficult is to implement the thing...
Honza
Index: ChangeLog
===
--- ChangeLog (revision 167857)
+++ ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2010-12-14 Jan Hubicka
+
+ * tree.c (get_file_function_name): Avoid using random seed on
GLOBAL_sub_I
+ and GLOBAL_sub_D.
+
2010-12-15 Martin Jambor
PR tree-optimization/46053
Index: tree.c
===
--- tree.c (revision 167819)
+++ tree.c (working copy)
@@ -8518,8 +8518,12 @@ get_file_function_name (const char *type
p = q = ASTRDUP (first_global_object_name);
/* If the target is handling the constructors/destructors, they
will be local to this file and the name is only necessary for
- debugging purposes. */
- else if ((type[0] == 'I' || type[0] == 'D') && targetm.have_ctors_dtors)
+ debugging purposes.
+ We also assign sub_I and sub_D sufixes to constructors called from
+ the global static constructors. These are always local. */
+ else if (((type[0] == 'I' || type[0] == 'D') && targetm.have_ctors_dtors)
+ || (strncmp (type, "sub_", 4) == 0
+ && (type[4] == 'I' || type[4] == 'D')))
{
const char *file = main_input_filename;
if (! file)
Re: trunk: bootstrap comparison failure
> Now if this breaks other logic in ld & friends on have_cdtor targets, I guess > we could 0) return to always inlining on non_have_cdtors targets and hope for the best :) > 1) du _sub_I/sub_D mangling only on targets not having ctors/dtors where > merged constructor is always produced > 2) make constructor merging to discover those specially named functions and > actually rename those specially called functions. > 3) update collect2 to not collect static symbols > 4) update the tools to also deal with sub_? variant. Honza
Re: trunk: bootstrap comparison failure
Jan Hubicka writes: >> Jan Hubicka writes: >> >> > I think bootstrap with C++ or GO is broken for a while on targets not >> > having ctor support, but now it broke >> > on targets with ctor support as a result of my patch renaming some of the >> > ctors from GLOBAL__I into GLOBAL__sub_I. >> >> I didn't know you were making that change. There are a several tools >> which recognize _GLOBAL__ specially, including examining the next >> character. Have you updated the demangler? Have you updated the GNU >> linker--see ctor_prio in ld/ldlang.c? > > I changed name only for functions that are produced internally in GCC. These > are functions > that are not constructors, but are called from constructors called > GLOBAL__I/GLOBAL__D as usually. > Most of time they are inlined, but in some cases they don't. It seems likely to cause confusion if these names wind up in the symbol table. Ian
Re: trunk: bootstrap comparison failure
> Jan Hubicka writes: > > > The problem is that GCC produce constructors/destructors at various places > > and they all used to be called GLOBAL__I > > and GLOBAL__D. Then in some cases (on targets that don't have global > > ctors/dtors or with LTO and ctor/dtor merging) > > it actually collect them into single constructor function called also > > GLOBAL__I and GLOBAL__D. > > Since the first ones are static functions called by the actual constructor, > > we get problem on targets not having > > ctors/dtors because collect2 collects even static symbols and attempts to > > call them from main(). This is reason why > > I renamed them to be no longer recognized specially. > > If I understand you, it sounds like they could have any name at all. > Just give them a name which doesn't start with _GLOBAL__. Then there > won't be any problem. Although you should still update the demangler to > do something sensible with them. Hmm, this is so anoying :( I would suggest to wait few days to see if targets arrived into good shape with what we have right now. Based on the discussion I guess we have to either 1) return to always inlining and expect that no inlinable stuff ever lands into constructor (this is I guess easy to disprove with user defined ctor containing named label or something similar) We might also give up on merging unlinlinable ctors at LTO time and lose optimization. We will get no worse on non-have-cdtors targets then 2) Do the actual renaming of _GLOBAL__I into something else (fully local name like static_ctor.1234 at a time it is being inserted into merged ctor. We can't avoid producing these names early since on target that havecdtors we avoid producing merged cdtors to avoid need for inlining (and the extra function when inlining fails) We can't keep them in symbol table static when they are not constructors as collect2 is probably not only tool to explode. Right? I wonder how hard renaming function is to implement 2)... Honza > > Ian
Re: trunk: bootstrap comparison failure
Jan Hubicka writes: > 2) Do the actual renaming of _GLOBAL__I into something else (fully local > name like static_ctor.1234 at a time it is being inserted > into merged ctor. > > We can't avoid producing these names early since on target that havecdtors > we avoid producing merged cdtors to avoid need for inlining (and the extra > function when inlining fails) > > We can't keep them in symbol table static when they are not constructors > as > collect2 is probably not only tool to explode. > Right? I don't understand this at all. I thought you were saying that these are static functions, and that gcc gathers them all together into a single global constructor. Are there cases where gcc does not gather them together? Why would that be? Ian
GCC 4.5.2 ?
It is Wed now. Will we see a official release this week ? -- Dennis
Re: trunk: bootstrap comparison failure
> I don't understand this at all. > > I thought you were saying that these are static functions, and that gcc > gathers them all together into a single global constructor. Are there > cases where gcc does not gather them together? Why would that be? At the moment we don't gather when there is only one constructor of given priority and target has ctors/dtors support. This is prettier WRT user defined constructors and also to avoid need to do inlining (that does not happen at -O0). I guess gathering the ctors/dtors always is also an option. Other option that just came to my mind is to recognize the specially named ctors/dtors and always inline them only. Those should be all compiler produced and thus inlinable. Honza
Re: trunk: bootstrap comparison failure
Jan Hubicka writes: > The problem is that GCC produce constructors/destructors at various places > and they all used to be called GLOBAL__I > and GLOBAL__D. Then in some cases (on targets that don't have global > ctors/dtors or with LTO and ctor/dtor merging) > it actually collect them into single constructor function called also > GLOBAL__I and GLOBAL__D. > Since the first ones are static functions called by the actual constructor, > we get problem on targets not having > ctors/dtors because collect2 collects even static symbols and attempts to > call them from main(). This is reason why > I renamed them to be no longer recognized specially. If I understand you, it sounds like they could have any name at all. Just give them a name which doesn't start with _GLOBAL__. Then there won't be any problem. Although you should still update the demangler to do something sensible with them. Ian
secondary reload with ALL_REGS
Hi,
I am facing a strange behaviour with secondary reload in gcc43.
I have a type of register that can load and store from virtually anything
else, lets call the class CHIP_REGS, meaning it has no need for reload.
However, if I get an input reload for ALL_REGS then I assume the worst
case scenario and provide reload code for operations in a certain mode.
So my secondary reload has the following shape:
if(rclass == CHIP_REGS)
return NO_REGS;
else if(...)
{
}
else if(mode == HImode)
{
if(in_p)
sri->icode = CODE_FOR_movhi_via_chipreg_in;
else
sri->icode = CODE_FOR_movhi_via_chipreg_out;
return NO_REGS;
}
...
The movhi_via_chipreg_in assumes with constraints that neither source nor
destination of the move is CHIP_REGS because that doesn't need a reload.
However, I get a reload_in for ALL_REGS, I assume worst case scenario and
forward secondary reload to movhi_via_chipreg_in and then the register is
allocated to a CHIP_REGS and fails to match constraints of
movhi_via_chipreg_in. Here's what I get in gregs:
Reloads for insn # 164
Reload 0: CHIP_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 0), can't combine,
secondary_reload_p
reload_reg_rtx: (reg:QI 1 AL)
Reload 1: reload_in (HI) = (reg/v:HI 32 [ hx ])
ALL_REGS, RELOAD_FOR_INPUT (opnum = 0)
reload_in_reg: (reg/v:HI 32 [ hx ])
reload_reg_rtx: (reg:HI 0 AH)
secondary_in_reload = 0
secondary_in_icode = movhi_via_chipreg_in
AH is a register in CHIP_REG. Then I get the following in output:
e_fmod.i:80: error: insn does not satisfy its constraints:
(insn 677 548 164 8 e_fmod.i:33 (parallel [
(set (reg:HI 0 AH)
(mem/c:HI (plus:QI (reg/f:QI 6 Y)
(const_int 16 [0x10])) [0 hx+0 S2 A16]))
(clobber (reg:QI 1 AL))
]) 10 {movhi_via_chipreg_in} (nil))
e_fmod.i:80: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:395
The insn
(set (reg:HI 0 AH)
(mem/c:HI (plus:QI (reg/f:QI 6 Y)
(const_int 16 [0x10])) [0 hx+0 S2 A16]))
doesn't need a scratch register at all.
I wonder what's the best way to deal with it. Any suggestions?
Cheers,
--
PMatos
The Linux binutils 2.21.51.0.3 is released
This is the beta release of binutils 2.21.51.0.3 for Linux, which is
based on binutils 2010 1215 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.3 to
hjl.to...@gmail.com
and
http://www.sourceware.org/bugzilla/
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.cgi?id=12291
4. Update BFD linker to accept -flto and -flto-partition= for GCC LTO
option compatibility.
5. Fix BFD linker to avoid touching uncompressed section content when
relocating DWARF debug sections for errror reporting.
6. Mark .gnu.lto_* sections with SHF_EXCLUDE.
7. Add --target option to ar.
8. Improve gold.
9. Improve AIX support.
10. Improve Windows support.
11. Improve mips support.
Changes from bi
[pph] wiki page set up
I finally found some time to write some documentation for the branch. I've created http://gcc.gnu.org/wiki/pph with some initial documentation on the pre-tokenization and pre-parsing work we are doing on the branch. The big missing piece is a more detailed design document that Lawrence will be posting in the next few days. Lawrence, Ben, Jason, could you take a look and make sure things make sense? I've also updated svn.html with the location of the branch. Thanks. Diego.
Re: "ld -r" on mixed IR/non-IR objects (
On Thu, Dec 9, 2010 at 6:29 PM, H.J. Lu wrote: > The initial implementation of my proposal is available on hjl/lto-mixed > branch at > > http://git.kernel.org/?p=devel/binutils/hjl/x86.git;a=summary I don't know how to separate this idea from the other work on that branch. I'm concerned that this idea appears to deeply embeds knowledge about LTO into the linker proper. One of the goals of the plugin approach was to have a clean separation, to give us more flexibility going forward. I say "appears to" because I'm not sure I entirely understand the proposal. The text is rather sketchy and I haven't seen the patch. For example, I think it would be a mistake for the linker to know the magic names that we currently use for LTO sections, and it would definitely be a mistake for the linker to know anything about the format of the data they contain. Ian
Using add_stmt in gimplify.c
Hello Everyone, 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? Any form of help is truly appreciated! I have not subscribed to gcc mailing list, so please copy me when you reply. Regards, Bobby.
Re: "ld -r" on mixed IR/non-IR objects (
On Wed, Dec 15, 2010 at 5:23 PM, Ian Lance Taylor wrote: > On Thu, Dec 9, 2010 at 6:29 PM, H.J. Lu wrote: > >> The initial implementation of my proposal is available on hjl/lto-mixed >> branch at >> >> http://git.kernel.org/?p=devel/binutils/hjl/x86.git;a=summary > > I don't know how to separate this idea from the other work on that branch. It is implemented on top of 2 stage linking infrastructure. > I'm concerned that this idea appears to deeply embeds knowledge about > LTO into the linker > proper. One of the goals of the plugin approach was to have a clean > separation, to give us > more flexibility going forward. I say "appears to" because I'm not > sure I entirely understand > the proposal. The text is rather sketchy and I haven't seen the patch. If you have specific questions, please just ask. > For example, I think it would be a mistake for the linker to know the > magic names that > we currently use for LTO sections, and it would definitely be a > mistake for the linker to > know anything about the format of the data they contain. Linker knows nothing about the magic names. * Linker action: o Classify each input object file: * If there is a ".gnu_object_only" section, it is a mixed object file. * If there is a IR section, it is an IR object file. Linker checks if an object is claimed by the plugin. If yes, it has an IR section. Otherwise, it has no IR. * Otherwise, it is a non-IR object file. -- H.J.
Re: "ld -r" on mixed IR/non-IR objects (
"H.J. Lu" writes: > On Wed, Dec 15, 2010 at 5:23 PM, Ian Lance Taylor wrote: >> On Thu, Dec 9, 2010 at 6:29 PM, H.J. Lu wrote: >> >>> The initial implementation of my proposal is available on hjl/lto-mixed >>> branch at >>> >>> http://git.kernel.org/?p=devel/binutils/hjl/x86.git;a=summary >> >> I don't know how to separate this idea from the other work on that branch. > > It is implemented on top of 2 stage linking infrastructure. Yes, which makes it hard to separate. The idea is distinct from 2 stage linking, as far as I can tell. I'm sure you saw my alternative proposal to 2 stage linking. > Linker knows nothing about the magic names. > > * Linker action: > o Classify each input object file: > * If there is a ".gnu_object_only" section, it is a mixed object file. > * If there is a IR section, it is an IR object file. > > Linker checks if an object is claimed by the plugin. If yes, > it has an IR section. Otherwise, it has no IR. > > * Otherwise, it is a non-IR object file. Thanks for the clarification. I will try again to understand the proposal. Ian
Re: "ld -r" on mixed IR/non-IR objects (
On Wed, Dec 15, 2010 at 6:27 PM, Ian Lance Taylor wrote: > "H.J. Lu" writes: > >> On Wed, Dec 15, 2010 at 5:23 PM, Ian Lance Taylor wrote: >>> On Thu, Dec 9, 2010 at 6:29 PM, H.J. Lu wrote: >>> The initial implementation of my proposal is available on hjl/lto-mixed branch at http://git.kernel.org/?p=devel/binutils/hjl/x86.git;a=summary >>> >>> I don't know how to separate this idea from the other work on that branch. >> >> It is implemented on top of 2 stage linking infrastructure. > > Yes, which makes it hard to separate. The idea is distinct from 2 stage > linking, as far as I can tell. I'm sure you saw my alternative proposal That is true. It happens to need similar book keeping as 2 stage linking. > to 2 stage linking. I saw it. Gold and ld can use different approaches to support plugin as long as they work with the same GCC driver binary. > >> Linker knows nothing about the magic names. >> >> * Linker action: >> o Classify each input object file: >> * If there is a ".gnu_object_only" section, it is a mixed object file. >> * If there is a IR section, it is an IR object file. >> >> Linker checks if an object is claimed by the plugin. If yes, >> it has an IR section. Otherwise, it has no IR. >> >> * Otherwise, it is a non-IR object file. > > Thanks for the clarification. I will try again to understand the > proposal. > I will update my proposal. Any feedbacks/comments are welcom/ Thanks. -- H.J.
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
