Re: i read that i should send here email
Piotr Marasz wrote: I try compile example program gcc.exe -I"c:\gcc\include" -L"c:\gcc\lib" c:\gcc\bin\program.c gcc.exe: Internal error: (null) (program as) Please submit bug report. First the bug report should not go here but to http://gcc.gnu.org/bugzilla (this is a list for development of gcc). Second, you need to tell which version you are using of gcc, where did you get it from, what system you are on, and what program you are compiling. All information that http://gcc.gnu.org/bugs.html (found on google by searching for "report gcc bug") tells you we need. Free is bad? Several thousands (million?) users of gcc don't agree, but everybody can of course make his own opinion. Paolo
Question about build error
hi, When I build gcc-3.2.2 for mips target, there's an error. What's the problem? Thanks Eirc ake[1]: Leaving directory `/home/cii/qwang_gcc/libiberty' xgcc: specs file malformed after 4096 characters xgcc: specs file malformed after 4096 characters xgcc: specs file malformed after 4096 characters make[1]: Entering directory `/home/cii/qwang_gcc/gcc' (cd intl && make all) make[2]: Entering directory `/home/cii/qwang_gcc/gcc/intl' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/cii/qwang_gcc/gcc/intl' echo "int xxy_us_dummy;" >tmp-dum.c /home/cii/qwang_gcc/gcc/xgcc -B/home/cii/qwang_gcc/gcc/ -B/opt/qwang-toolchain/m ipsel-linux/bin/ -B/opt/qwang-toolchain/mipsel-linux/lib/ -isystem /opt/qwang-to olchain/mipsel-linux/include -S tmp-dum.c xgcc: specs file malformed after 4096 characters make[1]: *** [s-under] Error 1 make[1]: Leaving directory `/home/cii/qwang_gcc/gcc' make: *** [all-gcc] Error 2
RE: Question about build error
On 12 April 2006 10:14, Eric Fisher wrote: > hi, > When I build gcc-3.2.2 for mips target, there's an error. What's the > problem? > > Thanks > Eirc > > ake[1]: Leaving directory `/home/cii/qwang_gcc/libiberty' > xgcc: specs file malformed after 4096 characters > xgcc: specs file malformed after 4096 characters > xgcc: specs file malformed after 4096 characters > make[1]: Entering directory `/home/cii/qwang_gcc/gcc' > (cd intl && make all) > make[2]: Entering directory `/home/cii/qwang_gcc/gcc/intl' > make[2]: Nothing to be done for `all'. > make[2]: Leaving directory `/home/cii/qwang_gcc/gcc/intl' > echo "int xxy_us_dummy;" >tmp-dum.c > /home/cii/qwang_gcc/gcc/xgcc -B/home/cii/qwang_gcc/gcc/ > -B/opt/qwang-toolchain/m ipsel-linux/bin/ > -B/opt/qwang-toolchain/mipsel-linux/lib/ -isystem /opt/qwang-to > olchain/mipsel-linux/include -S tmp-dum.c > xgcc: specs file malformed after 4096 characters > make[1]: *** [s-under] Error 1 > make[1]: Leaving directory `/home/cii/qwang_gcc/gcc' > make: *** [all-gcc] Error 2 Are you possibly using a shell that has a command-line length limitation of 4096 chars? See if you can find the part of the logfile where the 'specs' file is generated and look for errors there. cheers, DaveK -- Can't think of a witty .sigline today
Re: Reloading Problems and Memory Addressing
On Wed, Apr 12, 2006 at 07:47:32AM +0200, Frank Riese wrote: > On Monday 10 April 2006 19:48, you wrote: > > Can it at least add (small) immediates to registers? > > Nope, sry. The only instructions that take other arguments than registers are > the aforementioned LDL/LDH (load low/high), branch instructions (they take a > memory address) and four bit operations which can mask, invert, set or delete > a bit in a register. This will increase the probability of reload failures when storing through a pointer, because of the need for an extra register to hold the offset in some cases. For example int x, *p; p[15] = x; /* p not used after this */ LDL R[4], 30 LDH R[4], 0 ADD R[3], R[3], R[4] STO R[3], R[2] > > #define GO_IF_LEGITIMATE_ADDRESS(XMODE, X, LABEL) \ > > if (REG_P (X)) \ > > goto LABEL; > > I tried that out today. I wasn't sure about the exact contexts in which this > macro is used. It seems to work fine, though. Various parts of GCC (combine and reload, for example) build memory addresses and will use this macro to verify that they are supported. Predicates such as memory_operand, nonimmediate_operand and general_operand use it to check memory operands for supported addresses. For example, combine might try to generate an insn such as (set (reg:HI 20) (mem:HI (plus:HI (reg:HI 21) (reg:HI 22 out of (set (reg:HI 23) (plus:HI (reg:HI 21) (reg:HI 22))) (set (reg:HI 20) (mem:HI (reg:HI 23))) but this will be rejected by GO_IF_LEGITIMATE_ADDRESS() in your case. > $ gcc function1.c > > [...] > function1.c: In function 'main': > function1.c:10: internal compiler error: Segmentation fault > > (gdb) bt > #0 0x0829028f in htab_find_slot (htab=0x5b52202c, element=0xbf805284, > insert=INSERT) at ../../gcc-4.0.2/libiberty/hashtab.c:707 I have no idea. I haven't seen such a failure before. > > 1) Does BP really have to be fixed? You are sufficiently desparate for > > registers than you'll not fix BP unless the hardware itself mandates this. > > I thought it needs to be fixed if I want to set it aside as the frame > pointer. See the macros FRAME_POINTER_REQUIRED and ELIMINABLE_REGS. You want the former to be 0 and the latter to contain an elimination of FRAME_POINTER_REGNUM into STACK_POINTER_REGNUM. Also check CAN_DEBUG_WITHOUT_FP. [not making BP fixed] > Can I do the same thing with SP? I don't know. The difficulty is somewhere between nontrivial and impossible. Don't try this at first. -- Rask Ingemann Lambertsen
RE: Reloading Problems and Memory Addressing
On 12 April 2006 06:48, Frank Riese wrote: > Yes, you're right. When I started writing this backend I didn't have much > experience with it. I took the smallest backend I could find and tried to > adjust it to me needs. The number of macros in the internals docs was a bit > overwhelming at first and GCC kept segfaulting on me - something I'm > definately not used to from GCC. So, I was happy when I had something > working to start with. But now I think it would have been cleaner to start > from scratch. Or you could track down the segfaults to bugs in the modifications you've made; these are very often a sign that you've made a false assumption about what's in an rtx and as a consequence used the wrong kind of accessors (XINT, XEXP, etc) on it or its operands. Get used to the habit of adding lots of calls to print_rtl - under the control of a target flag, for preference! It is still easier to start with an existing backend that's similar to your target than to build one from complete scratch. >> #define GO_IF_LEGITIMATE_ADDRESS(XMODE, X, LABEL) \ >> if (REG_P (X)) \ >> goto LABEL; > > I tried that out today. I wasn't sure about the exact contexts in which this > macro is used. [ I'll try and answer this, because I've just been studying this area of the compiler myself, and the revision will do me good. Please bear in mind that what I say is not authoritative as it's fairly new to me and so I may have some errors in the details, but the outline is right. E&OE, caveat lector! ] It's used when gcc needs to form a (mem X) rtx and wants to know what kind of rtxen can be used (as the 'X') to represent the cpu's natural addressing modes as understood by the assembler. Whatever forms of rtx are accepted by G_I_L_A will be the forms of rtx passed to PRINT_OPERAND_ADDRESS when they crop up as the operands matched by the constraints in an insn pattern; when code generation matches some rtl with a bunch of operands against a define_insn pattern with operand constraints, it starts outputting the output template from the define insn and calls P_O_A with the relevant operand when it performs an operand substitution. So, e.g. if your CPU had register, register+offset, and immediate addressing modes, G_I_L_A would accept 1) a (reg ...) rtx 2) a (plus (reg ...) (const_int ...)) rtx and 3) a (const_int ...) rtx. Then, in P_O_A, you might use sprintf (STREAM, "[r%d]", REGNO(X)) if X had code REG, or sprintf (STREAM, "[0x%x, r%d]", INTVAL(XEXP(X, 1)), REGNO(XEXP(X, 0))); for the PLUS or just sprintf (STREAM, "[0x%x]", INTVAL(X)) for the CONST_INT that represents your immediate addressing mode. (Note that I might have the form of the (plus) rtx slightly wrong there w.r.t. insn canonicalisation and I'm not sure whether you might not also see any (minus) rtxen likewise). cheers, DaveK -- Can't think of a witty .sigline today
[gomp] EH problems with OpenMP
Hi, OpenMP is currently more or less unusable with the C++ front-end because of EH issues (see PR26823). This unfortunate situation is dragging on for more than two months now and makes further testing impossible. Some of the problems were fixed in PR26084, some still remain: The original (unreduced) testcase from PR26084 still causes an ICE. This is probably the same problem as in PR26823. We also have a third PR about an EH problem (PR26913) which has probably the same cause. Alas there seems to be no activity in that direction since PR26084 was closed. Could somebody of the gomp-maintainers please have a look? Thanks a lot in advance, Volker
Re: R_PPC_REL24 overflow
I suppose I should summarize what this problem was in case it's useful to anyone else searching the archives. A buggy cross-build process did not create libc.so. The static linker didn't find libc.so so it silently used libc.a instead. Libc.a is not built with -fPIC so the load problem showed up. Thanks for your comments. Jim. -- Jim Lemke [EMAIL PROTECTED] Orillia, Ontario
Catching up on status reports
I'm behind on two RM duties: bug priorities and status reports. Fortunately, I'm not traveling this week, so I'll get caught up shortly. I just wanted to let everyone know that I'd not forgotten there's stuff to be done... Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
[Ada] multilibbed implementation?
It's that time again... I just want to ask if there's any progress on Ada being multilibbed? -- Cheers, /ChJ
Question about gcc-lib and building on SPARC
Hello - this is definitely a newbie question, so bear with me... We've been using gcc under Solaris on SPARC hardware for some time now. The guy who was here before me set up the previous version (gcc-3.3.3) and now I'm trying to get gcc-3.4.4 to build. In the old gcc-3.3.3 install tree, I have the following directory: $prefix/lib/gcc-lib/sparc-sun-solaris2.9/3.3.3 gcc 3.3.3 was compiled with the following configure flags: [EMAIL PROTECTED] mark]$ gcc -v Reading specs from /cdl/apps/.software/sun/gcc-3.3.3/lib/gcc-lib/sparc-sun-solaris2.9/3.3.3/specs Configured with: configure --with-gnu-as --with-as=/cdl/apps/bin/sun/as --with-gnu-ld --with-ld=/cdl/apps/bin/sun/ld --enable-langauges=c,c++ --disable-shared --prefix=/cdl/apps/.software/sun/gcc-3.3.3 Thread model: posix gcc version 3.3.3 [EMAIL PROTECTED] mark]$ I've successfully built and installed gcc-3.4.4 with the following configure flags: [EMAIL PROTECTED] bin]$ ./gcc -v Reading specs from /cdl/apps/.software/sun/gcc-3.4.4/bin/../lib/gcc/sparc-sun-solaris2.9/3.4.4/specs Configured with: /cdl/apps/.software/sun/build/gcc-3.4.4-build/gcc-3.4.4/configure --disable-shared --prefix=/cdl/apps/.software/sun/gcc-3.4.4/ --enable-languages=c,c++ Thread model: posix gcc version 3.4.4 [EMAIL PROTECTED] bin]$ However, in this case, I don't have the "gcc-lib" directory anymore. When I try to build stuff with this compiler (a simple helloworld), the linker returns symbol errors, likely because the Sun-supplied ld and not the GNU ld is being used (even though a GNU ld exists in my PATH) The obvious answer is that I didn't specify --with-gnu-ld and --with-ld= in my gcc-3.4.4 configure. I would have done this, but our Developers need to use Purify Plus on Sun, and if I do this, it breaks Purify because it somehow uses it's own linker at buld time. The solution from Purify tech support was to go into $prefix/lib/gcc-lib/sparc-sun-solaris2.9/ and drop in symbolic links to the GNU ld and as. When I attempted to do this though, I realized this directory doesn't seem to exist under gcc-3.4.4 So, to make a painfully long story short, I need to know how gcc 3.4.4 decides upon which linker / assembler it uses. I read the configure instructions and found that when the compiler is built is uses a whole bunch of rules to find as and ld, and it seems apparent that I'm using the Sun ld and as instead of the GNU one. However, the old trick of putting symlinks in $prefix/lib/gcc-lib/sparc-sun-solaris2.9/ doesn't work anymore. Could someone please point a newbie in the right direction? Thanks in advance, Mark Mark Cuss, B. Sc. Software Developer Systems Administrator CDL Systems Ltd. Suite 220 3553 31 Street NW Calgary, AB, Canada T2L 2K7 Phone 403 289 1733 ext 226 Fax 403 289 3967 [EMAIL PROTECTED] www.cdlsystems.com
Problem in function in-lining
We had ported gcc-3.4.2 to our own RISC, and meet a strange
case in optimization level 3 (-O3).
The compiler produce wrong assembly code in O3 and
correct result if we add -fno-inline flag.
It seems that there some problem in function in-lining.
What can I do and what should I do to solve this problem ?
Source : xyz.c
...
... skip
...
#undef errno
int errno;
int _write (int fd, char *buf, int nbytes);
#ifdef REENTRANT_SYSCALLS_PROVIDED
volatile
int
_write_r (struct _reent *r, int fd, char *buf, int nbytes)
{
return _write(fd, buf, nbytes);
}
#endif
/*
* write -- write bytes to the serial port. Ignore fd, since
* stdout and stderr are the same. Since we have no filesystem,
* open will only return an error.
*/
int
_write (int fd, char *buf, int nbytes)
{
__asm__ volatile ("li r8,2"
:::"r8");
SemiHostedSyscall ();
}
Assembly file genereated with O3 optimization
==
.text
.align2
.globl_write
.ent_write
_write:
.framer0,0,r3, 1# vars= 0, regs= 0,
args= 0, gp= 0
.mask0x,0
#APP
.set volatile
li r8,2
sdbbp 0xb
mv r4, r4
mv r5, r11
#NO_APP
.set optimize
swr5,errno
br!r3
.end_write
.align2
.globl_write_r
.ent_write_r
_write_r:
.framer0,0,r3, 1# vars= 0, regs= 0,
args= 0, gp= 0
.mask0x,0
#APP
.set volatile
li r8,2
sdbbp 0xb ==> inline function call _write with worng arguments
mv r4, r4
mv r5, r11
#NO_APP
.set optimize
swr5,errno
br!r3
.end_write_r
.commerrno,4,4
Assembly file genereated with O3 and -fno-inline flag
==
.text
.align2
.globl_write
.ent_write
_write:
.framer0,0,r3, 1# vars= 0, regs= 0,
args= 0, gp= 0
.mask0x,0
#APP
.set volatile
li r8,2
sdbbp 0xb
mv r4, r4
mv r5, r11
#NO_APP
.set optimize
swr5,errno
br!r3
.end_write
.align2
.globl_write_r
.ent_write_r
_write_r:
.framer0,0,r3, 1# vars= 0, regs= 0,
args= 0, gp= 0
.mask0x,0
mv! r4, r5
mv! r5, r6
mv! r6, r7
j_write
.end_write_r
.commerrno,4,4
Re: GCC Compiler Engineer job (I am not a recruiter)
Gerald Pfeifer wrote: > On Mon, 10 Apr 2006, Mark Mitchell wrote: >> It seems like we're getting consensus around that approach, despite the >> initial sentiment in the other direction from Mike and Joe. Mike, Joe, >> do either of you care to argue the point? If not, I'll volunteer to >> write some text for the web pages, and ask Gerald to find a place to put it. > > http://gcc.gnu.org/lists.html probably would be the best place for such > a note. I applied the following patch. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713 Index: lists.html === RCS file: /cvs/gcc/wwwdocs/htdocs/lists.html,v retrieving revision 1.94 diff -c -5 -p -r1.94 lists.html *** lists.html 28 Oct 2005 19:58:26 - 1.94 --- lists.html 13 Apr 2006 05:46:06 - *** as well as in *** 38,47 --- 38,53 http://gcc.gnu.org/ml/gcc/";>gcc is a high volume list for general development discussions about GCC. Anything relevant to the development or testing of GCC and not covered by other mailing lists is suitable for discussion here. + Recruiting postings, including recruiting for GCC or other + free software jobs, are not permitted on this list, or on any of the + other GCC mailing lists. If you are interested in hiring a GCC + developer, please visit the http://www.fsf.org/jobs";>FSF + jobs page. + All major decisions and changes, like abandoning ports or front ends, should be announced and discussed here. Ideally, this list should be sufficient to follow the major trends and important news in GCC's development process.
