hang in acats testsuite test cxg2014 on hppa2.0w-hp-hpux11.00
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 acats test cxg2014 hangs forever on hppa2.0w-hp-hpux11.00. Killing the process terminates the acats testsuite. The directory gcc/testsuite/ada/acats/tests/cxg/cxg2014 contains a cyg2014.log file: ,.,. CXG2014 ACATS 2.5 06-02-10 18:02:32 - CXG2014 Check the accuracy of the SINH and COSH functions. * CXG2014 sinh(1) actual: 7.49632E-01 expected: 1.17520119364380146E+00 difference: -4.25201193643801825E-01 max err: 1.01932454980493402E-18. * CXG2014 cosh(1) actual: 1.24978E+00 expected: 1.54308063481524378E+00 difference: -2.93080634815243999E-01 max err: 1.33840910126959890E-18. * CXG2014 sinh(2) actual: 3.937499761E+00 expected: 3.62686040784701877E+00 difference: 3.10639592152978846E-01 max err: 3.14579994679152033E-18. * CXG2014 cosh(2) actual: 4.062499768E+00 expected: 3.76219569108363146E+00 difference: 3.00304308916366227E-01 max err: 3.26318459327078156E-18. * CXG2014 sinh(-1) actual: -7.49632E-01 expected: -1.17520119364380146E+00 difference: 4.25201193643801825E-01 max err: 1.01932454980493402E-18. /raid/tecosim/it/devel/projects/develtools/src/gcc-4.1/gcc/testsuite/ada/acats/run_all.sh: 7295 Terminated I tried to use tusc to see what's going on: tusc cxg2014 Last lines written: write(1, " ", 1) . = 1 1.01932454980493402E-18. write(1, "1 . 0 1 9 3 2 4 5 4 9 8 0 4 9 3 ".., 25) = 25 In user-mode .. [running] and then hanging forever. Any Ideas ? - -- Rainer Emrich TECOSIM GmbH Im Eichsfeld 3 65428 Rüsselsheim Phone: +49(0)6142/8272 12 Mobile: +49(0)163/56 949 20 Fax.: +49(0)6142/8272 49 Web: www.tecosim.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD8EuG3s6elE6CYeURAhI+AJ9b6y2y4785aoOmIyFApf3dTLCPMgCfT3a9 OdKKDNFXDqu1TE4lDv8DyA4= =kK0n -END PGP SIGNATURE-
CAN_ELIMINATE question
Hi All. While I have debugging AVR target bug I found that something wrong in port code or in reload. Is it right to use of get_frame_size() inside CAN_ELIMINATE macro valid ? If yes then reload have a bug. If no then AVR and probably MIPS ports have invalid definitions of CAN_ELIMINATE. Denis.
Status for releases, etc.
I've had both a lot of work and a lot of travel to get done over the past week; unfortunately, that's not permitted me to spend as much time as I would have liked doing RM stuff. Although I've not been saying much, I have been watching carefully, and I'm glad to see that progress has been made for some of the key PRs. Getting proper status reports out for 4.1 and mainline is on my must-do list for today -- although today may end some time early Tuesday morning GMT - 8. I hope to be announcing freeze/release-candidate dates, but that will depend on a review of the various outstanding issues. Thanks for being patient. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: CAN_ELIMINATE question
On Feb 13, 2006, at 7:43 AM, Denis Chertykov wrote: Hi All. While I have debugging AVR target bug I found that something wrong in port code or in reload. Is it right to use of get_frame_size() inside CAN_ELIMINATE macro valid ? If yes then reload have a bug. If no then AVR and probably MIPS ports have invalid definitions of CAN_ELIMINATE. Can you point to where you think reload is getting this wrong? -eric
Re: CAN_ELIMINATE question
Eric Christopher <[EMAIL PROTECTED]> writes:
> On Feb 13, 2006, at 7:43 AM, Denis Chertykov wrote:
>
> > Hi All.
> >
> > While I have debugging AVR target bug I found that something wrong in
> > port code or in reload.
> >
> > Is it right to use of get_frame_size() inside CAN_ELIMINATE macro
> > valid ?
> > If yes then reload have a bug.
> > If no then AVR and probably MIPS ports have invalid definitions of
> > CAN_ELIMINATE.
>
> Can you point to where you think reload is getting this wrong?
Yes.
Code fragment from reload1.c: reload()
if (caller_save_needed)
setup_save_areas ();
/* If we allocated another stack slot, redo elimination bookkeeping. */
if (starting_frame_size != get_frame_size ())
continue;
if (caller_save_needed)
{
save_call_clobbered_regs ();
/* That might have allocated new insn_chain structures. */
reload_firstobj = obstack_alloc (&reload_obstack, 0);
}
calculate_needs_all_insns (global);
Call to setup_save_areas () can change frame size but only offsets on
eliminable registers will be changed before call to calculate_needs_all_insns.
calculate_needs_all_insns will calculate wrong needs for elimination.
Example for AVR:
avr target can eliminate fp -> sp only if get_frame_size () == 0.
Before call to setup_save_areas() frame size was 0 (CAN_ELIMINATE (FP,SP) != 0)
setup_save_areas() increase frame size.
set_initial_elim_offsets() correct offsets but can_eliminate isn't changed.
save_call_clobbered_regs () emit save insn
(insn 659 161 162 16 (set (mem/c:HI (plus:HI (reg/f:HI 28 r28) # it's FP
(const_int 1 [0x1])) [29 S2 A8])
(reg:HI 24 r24)) 12 {*movhi} (nil)
(nil))
calculate_needs_all_insns() try to eliminate (reg/f:HI 28 r28) to SP.
It's wrong because get_frame_size () != 0 and CAN_ELIMINATE (FP,SP) == 0
I think that better to call update_eliminables() somewhere after
setup_save_areas()
Denis.
Re: "cscope" type functionality
Gabriel Dos Reis wrote: > Tom Tromey <[EMAIL PROTECTED]> writes: > > [...] > > | I think it would be more advisable to design something with AST > | database generation as an explicit goal. > > I believe that is a sensible approach, one that I thought a by-product > of the "Link Time Optimization" proposal. Such a format will be > tremendously useful. Yes, that was part of the motivation for the LTO design that Kenny, I, and others developed: such a database "falls out" of that design, with relatively minimal additional effort. However, whether or not that proposal will be implemented is still an open question, dependent on demand, technological evaluation relative to other approaches for link-time optimization (notably, LLVM), and available resources. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
bool or bitfield ?
Hi, looking into gcc source code, I noticed that in some structure definition 'bool' was used and in other ones bitfields were used. In some other cases there is also a mix of the two ! (for exemple in 'dwarf2out.c' - struct dw_fde_struct). Finaly, some even defined a BOOL_BITFIELD which looks like a bool but is an unsigned int ! In most common cases I think that bool or bitfield have the same functionality. Bitfields take less memory than bool but I think that bool are faster *in theory* (i.e. no masking needed but may also use more cache memory and result in slower code...) Is there a prefered version ? Do you think that looking deeper into would be interesting and would impove gcc ? Is there an *easy* way to compare memory consuption and execution time to figure out which version should be prefered ? Christophe Jaillet
Re: http://gcc.gnu.org/ml/gcc/2006-02/msg00212.html
> acats test cxg2014 hangs forever on hppa2.0w-hp-hpux11.00. This is PR ada/13408. I see that I opened this back in 2003. It probably has something to do with the IEEE quad support. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Re: pruning unused debugging types (enums/PR23336)
Aldy Hernandez wrote: > So far the way I've envisioned (correct me if I'm wrong please), is to > add 2 entries to struct function: one for a hash table which will be > freed when we're done parsing the function, and one containing the > vector of used types. I was hoping you could use a union of the two, to avoid adding two entries. > Problem number two... I'm apparently GTY clueless, and have been > unable to declare a vector of trees as a field of struct function. I always have a hard time with this too; I'm sorry, but I don't know the right incantation either. A simpler way to do this would be to just maintain a single global hash table of types-used-in-casts. I'm concerned that might result in writing out a lot of types you wouldn't otherwise need, because you'd be writing out types used in casts in functions that were themselves never written out. That might be particularly bad in C++; #include probably gives you a lot of such casts. You could combine the two ideas: a global hash table of types used in casts, where each entry had a list of functions using those types. That should take up no more storage than the per-function vectors. Then, you'd have to walk the entire hash table, writing out each type for which at least one of the associated functions was written out, including being inlined into another function. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
a question about pc-relative branch and function call
Hi, Happy Valentine's Day. Suppose I have only pc-relative branch instructions such as 'b offset' and don't have pc-region branch instructions such as 'j target'. So what the function call should be translated? Do I have to always use two instructions such as 'la reg, func' and 'b reg'? Especially when call a shared pic object file. The problem I've got is that when I link with a shared pic object file, there is a 'relocation truncated to fit' error. Thanks :-) Eric
Re: a question about pc-relative branch and function call
On Feb 13, 2006, at 7:28 PM, Eric Fisher wrote: Suppose I have only pc-relative branch instructions such as 'b offset' and don't have pc-region branch instructions such as 'j target'. So what the function call should be translated? Do I have to always use two instructions such as 'la reg, func' and 'b reg'? Especially when call a shared pic object file. The problem I've got is that when I link with a shared pic object file, there is a 'relocation truncated to fit' error. If you're a user, gcc-help is the appropriate list. If not, then usually naming the chip, the options used, the rtl generated and assembly used and so on would make the question easier to answer and make the answer more accurate. The general answer is that -fPIC and -mlong-call should generate code that uses the full width of a pointer without overflowing any fields, getting relocation errors and so on. A port maintainer then can choose _when_ to flip from medium code to large code, and that will then drive what size objects one can link without -mlong-call. How many bits can you go in medium mode on your port? How far did the linker want to go? If less then the first, then, it's an as or linker bug, if farther and you're not compiling with -mlong-call, then, you'll need to. If you are, then you have a bug in -mlong-call mode, you have to generate instructions that operate on the full width of a pointer.
Re: a question about pc-relative branch and function call
Thanks. I'm working to port gcc to our chip. I use mips-elf as the start. Yet, we don't have pc-region branch instructions such as 'j target'. So I'm confused how to solve the function call translation. Thanks again. Eric. 2006/2/14, Mike Stump <[EMAIL PROTECTED]>: > On Feb 13, 2006, at 7:28 PM, Eric Fisher wrote: > > Suppose I have only pc-relative branch instructions such as 'b offset' > > > > and don't have pc-region branch instructions such as 'j target'. So > > what the function call should be translated? Do I have to always use > > two instructions such as 'la reg, func' and 'b reg'? Especially when > > call a shared pic object file. > > > > The problem I've got is that when I link with a shared pic object > > file, there is a 'relocation truncated to fit' error. > > If you're a user, gcc-help is the appropriate list. If not, then > usually naming the chip, the options used, the rtl generated and > assembly used and so on would make the question easier to answer and > make the answer more accurate. > > The general answer is that -fPIC and -mlong-call should generate code > that uses the full width of a pointer without overflowing any fields, > getting relocation errors and so on. A port maintainer then can > choose _when_ to flip from medium code to large code, and that will > then drive what size objects one can link without -mlong-call. How > many bits can you go in medium mode on your port? How far did the > linker want to go? If less then the first, then, it's an as or > linker bug, if farther and you're not compiling with -mlong-call, > then, you'll need to. If you are, then you have a bug in -mlong-call > mode, you have to generate instructions that operate on the full > width of a pointer. > >
Re: a question about pc-relative branch and function call
On Feb 13, 2006, at 8:31 PM, Eric Fisher wrote: Thanks. I'm working to port gcc to our chip. I use mips-elf as the start. Yet, we don't have pc-region branch instructions such as 'j target'. So I'm confused how to solve the function call translation. Thanks again. If you don't have a jump to the full 4 gig address space take a look at the ppc port. It's probably best to use a branch stub in the linker (as is done in binutils) instead of the gcc work in the ppc backend, but that'll give you a place to start. Ideally you'll just emit "branch foo" to get to a label and then have the linker fix up anything else. Best of luck. -eric
Re: a question about pc-relative branch and function call
On Feb 13, 2006, at 8:31 PM, Eric Fisher wrote: Thanks. I'm working to port gcc to our chip. I use mips-elf as the start. Most chips have this same issue, you can copy from ppc for example, or arm, if your chip is more like it (hope not). we don't have pc-region branch instructions such as 'j target'. So I'm confused how to solve the function call translation. I am sorry you didn't understand my answer to your question. I'd be happy to try and help you, but I am limited in what help I can provide if you cannot answer my questions. There are a multitude of possible questions you could be asking and I'd need help in narrowing down which answer you seek. Also are you doing pic code or non-pic code? Is your chip a mips clone? Anyway, to try and answer part of your question, no, you don't have to generate: la reg, func b reg there are other possibilities, for example, you can train as/ld to extend them by inserting code to jump to the right place, and then jump to that code, but, this is harder than just generating the above and can require that your abi reserve a register so that the code that as/ld generates can use that reserved register. On ppc darwin, we have code to generate branch islands and then we have an instruction that will do a short jump, if it is in range otherwise it will jump to the other label which will be in range and the code there (generated by the compiler) will do the above type sequence. Statistically, this works out well, as 98% of the time, you get the nice code with a short branch and in rare cases you get a jump to an indirect jump. It looks like this: b func, func_stub func_stub: la reg, func b reg when then can dead code strip out the func_stubs is there are no surviving references to them. The only problem, we have to burn a register anyway. The _solution_ to this problem would be a link time optimizer, it's an open project for gcc at this time. The branch island code is a port feature.
The Linux binutils 2.16.91.0.6 is released
This is the beta release of binutils 2.16.91.0.6 for Linux, which is based on binutils 2006 0212 in CVS on sources.redhat.com plus various changes. It is purely for Linux. 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.16.91.0.6 to [EMAIL PROTECTED] and http://www.sourceware.org/bugzilla/ If you don't use # rpmbuild -ta binutils-xx.xx.xx.xx.xx.tar.bz2 to compile the Linux binutils, please read patches/README in source tree to apply Linux patches if there are any. Changes from binutils 2.16.91.0.5: 1. Update from binutils 2006 0212. 2. Correct Linux linker search order for DT_NEEDED entries (PR 2290). 3. Fix the x86-64 disassembler for control/debug register moves. 4. Properly handle ELF strip/objcopy with unmodified program header (PR 2258). 5. Improve ELF linker error handling when there are not enough room for program headers (PR 2322). 6. Properly handle weak undefined symbols in PIE (PR 2218). 7. Support new i386/x86-64 TLS relocations. 8. Fix addr2line for linux kernel (PR 2096). 9. Fix an assembler memory leak with --statistics. 10. Avoid an ia64 assembler regression (PR 2117). Changes from binutils 2.16.91.0.4: 1. Update from binutils 2005 1219. 2. Fix a MIPS linker regression (PR 1932). 3. Fix an objcopy bug for ia64 (PR 1991). 4. Fix a linker crash on bad input (PR 2008). 5. Fix 64bit monitor and mwait (PR 1874). Changes from binutils 2.16.91.0.3: 1. Update from binutils 2005 . 2. Fix ELF orphan section handling (PR 1467) 3. Fix ELF section attribute handleing (PR 1487). 4. Fix IA64 unwind info dump for relocatable files. (PR 1436). 5. Add DWARF info dump to objdump. 6. Fix SHF_LINK_ORDER handling (PR 1321). 7. Don't allow "ld --just-symbols" on DSO (PR 1263). 8. Fix a "ld -u" crash on TLS symbol (PR 1301). 9. Fix an IA64 linker crash (PR 1247). 10. Fix a MIPS linker bug (PR 1150). 11. Fix a M68K linker bug (PR 1775). 12. Fix an ELF symbol versioning linker bug (PR 1540). 13. Improve linker error handling (PR 1208). 14. Add new SPARC processors to SunOS for objcopy (PR 1472). 15. Add "@file" to read options from a file. 16. Add assembler weakref support. Changes from binutils 2.16.91.0.2: 1. Update from binutils 2005 0821. 2. Support x86-64 medium model. 3. Fix "objdump -S --adjust-vma=xxx" (PR 1179). 4. Reduce R_IA64_NONE relocations from R_IA64_LDXMOV relaxation. 5. Fix x86 linker regression for dosemu. 6. Add "readelf -t/--section-details" to display section details. 7. Fix "as -al=file" regression (PR 1118). Changes from binutils 2.16.91.0.1: 1. Update from binutils 2005 0720. 2. Add Intel VMX support. 3. Add AMD SVME support. 4. Add x86-64 new relocations for medium model. 5. Fix a PIE regression (PR 975). 6. Fix an x86_64 signed 32bit displacement regression. 7. Fix PPC PLT (PR 1004). 8. Improve empty section removal. Changes from binutils 2.16.90.0.3: 1. Update from binutils 2005 0622. 2. Fix a linker versioning bug exposed by gcc 4 (PR 1022/1023/1025). 3. Optimize ia64 br->brl relaxation (PR 834). 4. Improve linker empty section removal. 5. Fix DWARF 2 line number reporting (PR 990). 6. Fix DWARF 2 line number reporting regression on assembly file (PR 1000). Changes from binutils 2.16.90.0.2: 1. Update from binutils 2005 0510. 2. Update ia64 assembler to support comdat group section generated by gcc 4 (PR 940). 3. Fix a linker crash on bad input (PR 939). 4. Fix a sh64 assembler regression (PR 936). 5. Support linker script on executable (PR 882). 6. Fix the linker -pie regression (PR 878). 7. Fix an x86_64 disassembler bug (PR 843). 8. Fix a PPC linker regression. 9. Misc speed up. Changes from binutils 2.16.90.0.1: 1. Update from binutils 2005 0429. 2. Fix an ELF linker regression (PR 815). 3. Fi
Re: a question about pc-relative branch and function call
> Also are you doing pic code or non-pic code? Is your chip a mips clone? Both pic and non-pic codes are supported. The chip has some features from arm, such as conditional execution, scaled immediate, pc-relative branch. I choose mips-elf as start just because we are familiar with mips and that seems easy to do. I modified the bfd relocation type and used the pc-relative branch to implement function call. It worked with non-pic codes, but failed with pic code. The error is just about 'relocation truncated to fit' as I said. So with your suggestion, I think I need a register to hold the function address anyway. Whatever we do with gcc backend or as/ld. I see. Thanks Eric 2006/2/14, Mike Stump <[EMAIL PROTECTED]>: > On Feb 13, 2006, at 8:31 PM, Eric Fisher wrote: > > Thanks. I'm working to port gcc to our chip. I use mips-elf as the > > start. > > Most chips have this same issue, you can copy from ppc for example, > or arm, if your chip is more like it (hope not). > > > we don't have pc-region branch instructions such as 'j target'. So I'm > > confused how to solve the function call translation. > > I am sorry you didn't understand my answer to your question. I'd be > happy to try and help you, but I am limited in what help I can > provide if you cannot answer my questions. > > There are a multitude of possible questions you could be asking and > I'd need help in narrowing down which answer you seek. > > Also are you doing pic code or non-pic code? Is your chip a mips clone? > > Anyway, to try and answer part of your question, no, you don't have > to generate: > > la reg, func > b reg > > there are other possibilities, for example, you can train as/ld to > extend them by inserting code to jump to the right place, and then > jump to that code, but, this is harder than just generating the above > and can require that your abi reserve a register so that the code > that as/ld generates can use that reserved register. > > On ppc darwin, we have code to generate branch islands and then we > have an instruction that will do a short jump, if it is in range > otherwise it will jump to the other label which will be in range and > the code there (generated by the compiler) will do the above type > sequence. Statistically, this works out well, as 98% of the time, > you get the nice code with a short branch and in rare cases you get a > jump to an indirect jump. It looks like this: > > b func, func_stub > > func_stub: > la reg, func > b reg > > when then can dead code strip out the func_stubs is there are no > surviving references to them. The only problem, we have to burn a > register anyway. The _solution_ to this problem would be a link time > optimizer, it's an open project for gcc at this time. The branch > island code is a port feature. >
