Re: GCC and binutils dependencies
Gary Funck writes: > We recently ran into this 'as' bug running > tests with the GCC (4.5 pre-cursor) "trunk" compiler > on an x86_64 target running Ubuntu 8.04: > http://sourceware.org/bugzilla/show_bug.cgi?id=10255 > (the bug was marked fixed in June 2009). > > The issue was noted in this GCC PR: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40332 > > Since GCC 4.5 isn't out yet, I'm wondering what is > the policy, or general rule that is followed with > respect to a new version of GCC being dependent > upon a particular version of binutils, or some > important library? > > And, would it make sense in this case to have > a GCC test case that exercises this 'as' bug to > be able to detect that either the bug is there in > the version of 'as' that is being used to build > and test GCC, or that a regression occurred? I think it would be troubling if a gcc release required a very new binutils release on a popular platform like x86_64. I think we should work hard to avoid that. If I understand this issue correctly, it should be possible to modify the configure test for gcc_cv_as_cfi_directive to avoid the problem when using an older binutils. If that is true, then I think we should push PR 40332 up to P1 until gcc works correctly with binutils older than 2.20. Ian
Re: powerpc-eabi-gcc no implicit FPU usage
On 01/15/2010 05:42 PM, Robert Grimm wrote: Greetings all, I'm working with the powerpc-eabi architecture (specifically, the MPC563 processor). For some time we have been using GCC 3.4.3 and I noticed gcc generating code that makes use of the floating point registers for 64-bit integer loads and whatnot... which we don't want it to do as there are times when we disable the FPU. I'm aware of the -msoft-float option but we didn't want to use that as we only wanted it to not use FP registers in certain functions and not entire files. I was under the impression that a newer GCC wouldn't do this based on some old mailing posts I've read. I've just tried out GCC 4.4.2 and notice that the FP registers are still being used even though there is no explicit FPU usage going on in this particular part of the code. This is a long standing issue in the RTEMS community and we don't have a good solution. It needs GCC to only use the FPU when you meant to. This is dangerous in interrupt service routines. And I don't think mixing soft-float and hard-float in a single executable is a good idea. I recall that this is not a PowerPC specific issue. I think we have seem complaints on other architectures. When we had a HPPA port, I know it would do it there. Is there a way to get GCC to only use the FPU when we explicitly want to use it (i.e. when we use doubles/floats)? Is -msoft-float my only option here? Is there any sort of #pragma that could do the same thing as -msoft-float (I didn't see one)? We would love to see a way to not have implicit FPU usage. Regards, Rob Grimm --joel sherrill RTEMS
powerpc-eabi-gcc no implicit FPU usage
Greetings all, I'm working with the powerpc-eabi architecture (specifically, the MPC563 processor). For some time we have been using GCC 3.4.3 and I noticed gcc generating code that makes use of the floating point registers for 64-bit integer loads and whatnot... which we don't want it to do as there are times when we disable the FPU. I'm aware of the -msoft-float option but we didn't want to use that as we only wanted it to not use FP registers in certain functions and not entire files. I was under the impression that a newer GCC wouldn't do this based on some old mailing posts I've read. I've just tried out GCC 4.4.2 and notice that the FP registers are still being used even though there is no explicit FPU usage going on in this particular part of the code. Is there a way to get GCC to only use the FPU when we explicitly want to use it (i.e. when we use doubles/floats)? Is -msoft-float my only option here? Is there any sort of #pragma that could do the same thing as -msoft-float (I didn't see one)? Regards, Rob Grimm
GCC and binutils dependencies
We recently ran into this 'as' bug running tests with the GCC (4.5 pre-cursor) "trunk" compiler on an x86_64 target running Ubuntu 8.04: http://sourceware.org/bugzilla/show_bug.cgi?id=10255 (the bug was marked fixed in June 2009). The issue was noted in this GCC PR: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40332 Since GCC 4.5 isn't out yet, I'm wondering what is the policy, or general rule that is followed with respect to a new version of GCC being dependent upon a particular version of binutils, or some important library? And, would it make sense in this case to have a GCC test case that exercises this 'as' bug to be able to detect that either the bug is there in the version of 'as' that is being used to build and test GCC, or that a regression occurred? thanks.
Re: how to specify instruction size for optimization
cirrus75 writes: > I could not understand exactly how to specify instruction size to gcc (so it > can really optimize the code size when -Os is used). > > I would like to inform gcc that if some registers are used for certain > operations, the instruction will be smaller. For example, an add which > destination register is register 4 has lowest size if compared to all "add" > forms. > > What is the easiest way to give this information to gcc ? I took a long look > at the internals documentation and other ports but I'm not sure. You should add a "length" attribute to all your insns. However, the real way that gcc decides which insns to use is based on TARGET_RTX_COSTS. You can change what that returns based on the optimization mode. Ian
how to specify instruction size for optimization
Hi, I could not understand exactly how to specify instruction size to gcc (so it can really optimize the code size when -Os is used). I would like to inform gcc that if some registers are used for certain operations, the instruction will be smaller. For example, an add which destination register is register 4 has lowest size if compared to all "add" forms. What is the easiest way to give this information to gcc ? I took a long look at the internals documentation and other ports but I'm not sure. thank you for the help, Alex Prado
The Linux binutils 2.20.51.0.5 is released
This is the beta release of binutils 2.20.51.0.5 for Linux, which is
based on binutils 2010 0115 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.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.gold will be installed as ld. You can use the configure
option, --enable-gold=both/bfd to choose bfd ld as the default linker,
ld. IA-32 binary and X64_64 binary tar balls are configured with
--enable-gold=both/bfd --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.20.51.0.3 to
hjl.to...@gmail.com
and
http://www.sourceware.org/bugzilla/
Changes from binutils 2.20.51.0.4:
1. Update from binutils 2010 0115.
2. Optimize x86 assembler/disassembler.
3. Add a new program, elfedit, to edit ELF files. PR 11131.
4. Add --dyn-syms to readelf. PR 11146.
5. Remove "Warning: " from objcopy error message. PR 11130.
6. Fix linker --gc-sections with undefined __start_XXX/__stop_XXX symbols.
PR 11133.
7. Fix linker --gc-sections with SHT_NOTE section. PR 11143.
8. Fix a c++filt bug. PR 11137.
9. Fix assembler listing. PR 11122.
10. Improve gold. Change --enable-gold to --enable-gold=[both[/{gold,bfd}]].
11. Improve arm support.
12. Improve mips support.
13. Improve ppc support.
14. Improve MacOS support.
Changes from binutils 2.20.51.0.3:
1. Update from binutils 2009 1214.
2. Update x86 assembler to check lockable instructions for lock prefix.
3. Update x86 disassembler to display all prefixes.
4. Support AMD XOP new instructions.
5. Fix an x86 assembler regression on Intel syntax. PR 11037.
6. Improve ia64 linker relaxation. PR 10955.
7. Add --no-relax linker option.
8. Update readelf to dump .debug_pubtype sections.
9. Improve gold:
a. Support linking against STT_GNU_IFUNC symbols defined in
shared libraries.
b. Support linking with STB_GNU_UNIQUE symbols.
10. Improve arm support.
11. Improve m68k support.
12. Improve mips support.
13. Improve ppc support.
Changes from binutils 2.20.51.0.2:
1. Update from binutils 2009 1109.
2. Fix "ld -s -static" with STT_GNU_IFUNC symbols. PR 10911.
3. Fix file permission on PIE with objcopy. PR 10802.
4. Fix x86 Intel syntax assembler with relocation. PR 10856.
5. Fix x86 I
Re: Help-The possible places where insn is splitted in greg pass
2010/1/15 Ian Lance Taylor :
> There are many places where that insn could be generated, so it's
> pretty hard to answer your question as asked.
>
> I recommend setting a breakpoint on make_insn_raw if
> cfun->emit->x_cur_insn_uid == 479. Then a backtrace will show you
> what is creating the insn.
>
> Ian
>
That insn was generated in subst_reloads() called by reload_as_needed
in reload1.c.
In greg pass, the instruction#320 needs to be splitted. The cpu
supports the memory address mode mem(r1*4+r2).
(insn 320 308 309 19 a.c:381 (set (reg:SI 207 [ .wrData ])
(mem/s:SI (plus:SI (mult:SI (reg:SI 204)
(const_int 4 [0x4]))
(reg/f:SI 234)) [5 .wrData+0 S4 A32])) 3
{movsi} (expr_list:REG_DEAD (reg:SI 204)
(nil)))
In find_reloads() (called by reload_as_needed()), following reload
information was generated.
(insn 320 308 309 19 a.c:381 (set (reg:SI 14 a14 [orig:207
.wrData ] [207])
(mem/s:SI (plus:SI (mult:SI (reg:SI 9 a9 [204])
(const_int 4 [0x4]))
(plus:SI (reg/f:SI 16 SP)
(const_int 96 [0x60]))) [5 .wrData+0 S4
A32])) 3 {movsi} (expr_list:REG_DEAD (reg:SI 9 a9 [204])
(nil)))
Reload 0: reload_in (SI) = (plus:SI (reg/f:SI 16 SP)
(const_int 96 [0x60]))
GENERAL_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 1)
reload_in_reg: (plus:SI (reg/f:SI 16 SP)
(const_int 96 [0x60]))
reload_reg_rtx: (reg:SI 12 a12)
Reload 1: reload_in (SI) = (plus:SI (mult:SI (reg:SI 9 a9 [204])
(const_int 4 [0x4]))
(plus:SI (reg/f:SI 16 SP)
(const_int 96 [0x60])))
GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1), inc by 4
reload_in_reg: (plus:SI (mult:SI (reg:SI 9 a9 [204])
(const_int 4 [0x4]))
(plus:SI (reg/f:SI 16 SP)
(const_int 96 [0x60])))
reload_reg_rtx: (reg:SI 12 a12)
After find_reloads() called, emit_reload_insns() generated insns to
reload operands. Then subst_reloads() substituted the reload regs
using the replacement information.
The insn list after subst_reloads():
(insn 475 308 477 19 a.c:381 (set (reg:SI 12 a12)
(const_int 96 [0x60])) -1 (nil))
(insn 477 475 478 19 a.c:381 (set (reg:SI 12 a12)
(reg/f:SI 16 SP)) -1 (nil))
(insn 478 477 479 19 a.c:381 (set (reg:SI 12 a12)
(plus:SI (reg:SI 12 a12)
(const_int 96 [0x60]))) -1 (expr_list:REG_EQUIV (plus:SI
(reg/f:SI 16 SP)
(const_int 96 [0x60]))
(nil)))
(insn 479 478 320 19 a.c:381 (set (reg:SI 12 a12)
(plus:SI (mult:SI (reg:SI 9 a9 [204])
(const_int 4 [0x4]))
(reg:SI 12 a12))) -1 (nil))
(insn 320 479 481 19 a.c:381 (set (reg:SI 14 a14 [orig:207
.wrData ] [207])
(mem/s:SI (reg:SI 12 a12) [5 .wrData+0 S4 A32])) 3
{movsi} (expr_list:REG_DEAD (reg:SI 9 a9 [204])
(nil)))
But insn#479 is not recognized by recog() in insn-recog.c and the
compilation failed. (recog only recognizes RTL defined in md, right?)
Here the backtrace is
reload--->cleanup_subreg_operands--->extract_insn_cached--->extract_insn--->recog_memoized--->recog.
There is no machine instruction(r3=r1*4+r2) match the pattern of
insn#479. Though there is pattern r3=mem(r1*4+r2).
I don’t quite understand the generation of reload information.
What can I do next?
Thanks!
Qifei Fan
Re: Slightly offtpic: why svn stubbornly refuses to listen to ctrl-c?!?
Paolo Carlini wrote: > On 01/15/2010 05:05 PM, Adam Butcher wrote: If you're on a posix-compatible have you tried using SIGQUIT (CTRL-\ or CTRL-4) instead of SIGINT? >>> Or kill -9 of course, but beware; Vincent LeFevre reported sandboxes >>> corrupted beyond anything 'svn cleanup' could repair in one of the >>> links I posted in another reply. >> Sure, this is a last resort. I only mentioned SIGQUIT because its >> 'typeable' so you wouldn't have the annoyance of going to a new shell (or >> suspending svn), finding the pid and killing it (or use killall). That's >> providing svn doesn't implement the same best-effort cancellation >> checkpoints for SIGQUIT also of course. >> > Thanks to everybody who replied. At least now I know that the issue is > known and it *is* an issue ;) > > By the way, I find a bit funny the cautionary remarks about kill -9, etc: > what else one can do when it gets unrecoverably stuck? Just kill it and > hope for the best, I say. A lot of the time it's not really stuck, just taking a lo-o-ong slow time to do a big job, that's all. In those cases, leaving it run while you go for a coffee might still end up quicker than killing it and having to checkout a new sandbox. If it's really genuinely stuck, then yeah, of course: what you say. cheers, DaveK [ I'm ready to drop this thread now, think I've strayed far enough OT for one afternoon :) ]
Re: Slightly offtpic: why svn stubbornly refuses to listen to ctrl-c?!?
On 01/15/2010 05:05 PM, Adam Butcher wrote: >>> If you're on a posix-compatible have you tried using SIGQUIT (CTRL-\ or >>> CTRL-4) instead of SIGINT? >>> >> Or kill -9 of course, but beware; Vincent LeFevre reported sandboxes >> corrupted beyond anything 'svn cleanup' could repair in one of the links I >> posted in another reply. > Sure, this is a last resort. I only mentioned SIGQUIT because its > 'typeable' so you wouldn't have the annoyance of going to a new shell > (or suspending svn), finding the pid and killing it (or use killall). > That's providing svn doesn't implement the same best-effort cancellation > checkpoints for SIGQUIT also of course. > Thanks to everybody who replied. At least now I know that the issue is known and it *is* an issue ;) By the way, I find a bit funny the cautionary remarks about kill -9, etc: what else one can do when it gets unrecoverably stuck? Just kill it and hope for the best, I say. Paolo.
Re: Slightly offtpic: why svn stubbornly refuses to listen to ctrl-c?!?
On Fri, January 15, 2010 3:57 pm, Dave Korn wrote: > Adam Butcher wrote: >> On Fri, January 15, 2010 1:43 pm, Paolo Carlini wrote: >>> I mean, why a well designed application should refuse to listen to ctrl-c >>> when something goes wrong? Why every time for some reason it gets stuck, >>> I have to kill it from another shell? That's definitely annoying. >>> >> If you're on a posix-compatible have you tried using SIGQUIT (CTRL-\ or >> CTRL-4) instead of SIGINT? > > Or kill -9 of course, but beware; Vincent LeFevre reported sandboxes > corrupted beyond anything 'svn cleanup' could repair in one of the links I > posted in another reply. > Sure, this is a last resort. I only mentioned SIGQUIT because its 'typeable' so you wouldn't have the annoyance of going to a new shell (or suspending svn), finding the pid and killing it (or use killall). That's providing svn doesn't implement the same best-effort cancellation checkpoints for SIGQUIT also of course. Cheers, Adam
Re: Slightly offtpic: why svn stubbornly refuses to listen to ctrl-c?!?
Paul Koning wrote: >> Paolo Carlini wrote: >> guaranteeing atomicity/preventing corrupted sandbox? > > Not just crude, but wrong. You can't get atomicity (or rather, > transactional integrity) that way, because blocking ^C doesn't block > SIGKILL, or panics, or power failures, or (in the case of operations > involving the server) network failures. Yeah; as I discovered in that final URL, it's purely to try and protect your local sandbox from getting damaged. And sure, it's only a best effort. cheers, DaveK
Re: Slightly offtpic: why svn stubbornly refuses to listen to ctrl-c?!?
Adam Butcher wrote: > On Fri, January 15, 2010 1:43 pm, Paolo Carlini wrote: >> I mean, why a well designed application should refuse to listen to ctrl-c >> when something goes wrong? Why every time for some reason it gets stuck, >> I have to kill it from another shell? That's definitely annoying. >> > If you're on a posix-compatible have you tried using SIGQUIT (CTRL-\ or > CTRL-4) instead of SIGINT? Or kill -9 of course, but beware; Vincent LeFevre reported sandboxes corrupted beyond anything 'svn cleanup' could repair in one of the links I posted in another reply. cheers, DaveK
RE: Slightly offtpic: why svn stubbornly refuses to listen to ctrl-c?!?
> Paolo Carlini wrote: > > Hi, > > > > I mean, why a well designed application should refuse to listen to > > ctrl-c when something goes wrong? Why every time for some reason it > gets > > stuck, I have to kill it from another shell? That's definitely > annoying. > > > > Paolo. > ... > Looks like there's a read loop in libapr that is deliberately > designed to > continue if it gets EINTR. Perhaps a somewhat crude mechanism for > guaranteeing atomicity/preventing corrupted sandbox? Not just crude, but wrong. You can't get atomicity (or rather, transactional integrity) that way, because blocking ^C doesn't block SIGKILL, or panics, or power failures, or (in the case of operations involving the server) network failures. paul
Re: Slightly offtpic: why svn stubbornly refuses to listen to ctrl-c?!?
Paolo Carlini wrote: > Hi, > > I mean, why a well designed application should refuse to listen to > ctrl-c when something goes wrong? Why every time for some reason it gets > stuck, I have to kill it from another shell? That's definitely annoying. > > Paolo. Hmm, this is also Debian bug #50, 461873 and 266973 http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/f4768634a6043e7d also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461873 http://www.mail-archive.com/debian-bugs-clo...@lists.debian.org/msg19117.html Looks like there's a read loop in libapr that is deliberately designed to continue if it gets EINTR. Perhaps a somewhat crude mechanism for guaranteeing atomicity/preventing corrupted sandbox? Ah, http://subversion.open.collab.net/ds/viewMessage.do?dsForumId=4&viewType=browseAll&dsMessageId=817 says that there are cancellation-safe checkpoints in processing, and svn defers ctrl-c until the next one comes up. You probably need to talk to upstream if there are places where it's showing an unacceptably long delay between checkpoints. (Also, make sure you're using the latest version of svn available, as this behaviour has been worked on during 1.5 timeframe). cheers, DaveK
Re: Slightly offtpic: why svn stubbornly refuses to listen to ctrl-c?!?
On Fri, January 15, 2010 1:43 pm, Paolo Carlini wrote: > > I mean, why a well designed application should refuse to listen to > ctrl-c when something goes wrong? Why every time for some reason it gets > stuck, I have to kill it from another shell? That's definitely annoying. > If you're on a posix-compatible have you tried using SIGQUIT (CTRL-\ or CTRL-4) instead of SIGINT? Adam
Slightly offtpic: why svn stubbornly refuses to listen to ctrl-c?!?
Hi, I mean, why a well designed application should refuse to listen to ctrl-c when something goes wrong? Why every time for some reason it gets stuck, I have to kill it from another shell? That's definitely annoying. Paolo.
Re: Sibcall on recursive functions
On Fri, Jan 15, 2010 at 8:56 AM, Paulo De Oliveira Cantante De Matos wrote: > > >> -Original Message- >> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On >> Behalf Of Andrew Pinski >> Sent: 14 January 2010 17:08 >> To: Paulo J. Matos >> Cc: gcc@gcc.gnu.org >> Subject: Re: Sibcall on recursive functions >> >> >> Because it is not really sibcalled but rather turned into a loop >> via >> tail recursion. This is almost always profitable and never changes >> how many times the stack gets restored (unless there is an alloca >> in >> the function which is checked for inside the optimization). >> > > Can you please tell me which pass performs this optimization? > Found it in pass_tail_recursion, thanks! -- Paulo Jorge Matos - pocmatos at gmail.com http://www.pmatos.net
RE: Sibcall on recursive functions
> -Original Message- > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On > Behalf Of Andrew Pinski > Sent: 14 January 2010 17:08 > To: Paulo J. Matos > Cc: gcc@gcc.gnu.org > Subject: Re: Sibcall on recursive functions > > > Because it is not really sibcalled but rather turned into a loop > via > tail recursion. This is almost always profitable and never changes > how many times the stack gets restored (unless there is an alloca > in > the function which is checked for inside the optimization). > Can you please tell me which pass performs this optimization? > Thanks, > Andrew Pinski > > > To report this email as spam click > https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg== > tiLNkw7o1Ucyk7zCaZ!cAQ67dzg1qS30Zw0Y5ZKUUtXYzJog3g== . Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
