* I give up.
@ 2003-10-22 14:15 Jonathan Wilson
2003-10-22 14:16 ` Andrew Haley
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: Jonathan Wilson @ 2003-10-22 14:15 UTC (permalink / raw)
To: gcc
I cant find anything on google about the various RTL functions (like
gen_rtx_UNSPEC).
I cant find anything in the GCC docs.
And I cant find anything in the source code for these specific functions (I
cant even FIND their code)
^ permalink raw reply [flat|nested] 14+ messages in thread* I give up. 2003-10-22 14:15 I give up Jonathan Wilson @ 2003-10-22 14:16 ` Andrew Haley 2003-10-22 14:41 ` Jonathan Wilson 2003-10-22 14:44 ` Bernd Jendrissek 2003-10-23 1:53 ` I give up Mike Stump 2 siblings, 1 reply; 14+ messages in thread From: Andrew Haley @ 2003-10-22 14:16 UTC (permalink / raw) To: Jonathan Wilson; +Cc: gcc Jonathan Wilson writes: > I cant find anything on google about the various RTL functions (like > gen_rtx_UNSPEC). > I cant find anything in the GCC docs. > And I cant find anything in the source code for these specific functions (I > cant even FIND their code) It's generated automagically from the .md file. Look at build/gcc/genrtl.h. Andrew. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: I give up. 2003-10-22 14:16 ` Andrew Haley @ 2003-10-22 14:41 ` Jonathan Wilson 0 siblings, 0 replies; 14+ messages in thread From: Jonathan Wilson @ 2003-10-22 14:41 UTC (permalink / raw) To: Andrew Haley; +Cc: gcc ok, that tells me where the code is. But that still doesnt tell me what any of the 1000s of different functions that relate to RTL actually DO. What I need to output is something like this: mov rega, dword ptr ds:__tls_index mov regb, dword ptr fs:__tls_array mov regc, [rega+regb*4] then to get the address itself (ready to insert into the instruction), you do: dword ptr ds:var[regc] rega,regb,regc are registers var is the address of the thread-local variable relative to the start of the segment that it resides in (and of course will be modified by the linker when all the segments are combined) BTW, pre-calculating the value for regc isnt possible (because __tls_index can be changed at any time) I have looked in all the code, all the manuals, all the documentation and all the resources that turn up on google but I still cant figure out how to do what I need :(. I suspect that, since its target specific, someone that knows the i?86 backend is going to need to help me. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: I give up. 2003-10-22 14:15 I give up Jonathan Wilson 2003-10-22 14:16 ` Andrew Haley @ 2003-10-22 14:44 ` Bernd Jendrissek 2003-10-22 14:58 ` Jonathan Wilson 2003-10-23 1:53 ` I give up Mike Stump 2 siblings, 1 reply; 14+ messages in thread From: Bernd Jendrissek @ 2003-10-22 14:44 UTC (permalink / raw) To: Jonathan Wilson; +Cc: gcc -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Oct 22, 2003 at 06:55:06PM +0800, Jonathan Wilson wrote: > I cant find anything on google about the various RTL functions (like > gen_rtx_UNSPEC). gcc/rtl.def: /* A machine-specific operation. 1st operand is a vector of operands being used by the operation so that any needed reloads can be done. 2nd operand is a unique value saying which of a number of machine-specific operations is to be performed. (Note that the vector must be the first operand because of the way that genrecog.c record positions within an insn.) This can occur all by itself in a PATTERN, as a component of a PARALLEL, or inside an expression. */ DEF_RTL_EXPR(UNSPEC, "unspec", "Ei", 'x') So an UNSPEC can be anything you want it to be. > I cant find anything in the GCC docs. > And I cant find anything in the source code for these specific functions (I > cant even FIND their code) Such as... (yesterday) gen_rtx_REG? That's in emit-rtl.c. As for gen_rtx_UNSPEC, I don't know. Bear in mind that there are about a dozen or so C files that are *generated* during the build. Sometimes what you're looking for is in there instead, or in the generator program. Don't give up! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE/lnio/FmLrNfLpjMRAiKBAJ0ZxY41Eg5KpV3LI7wRWtwhPWqLAACfWXsJ dIS+dcl+1mbyURkgMkExaDw= =puZp -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: I give up. 2003-10-22 14:44 ` Bernd Jendrissek @ 2003-10-22 14:58 ` Jonathan Wilson 2003-10-22 15:08 ` Andrew Haley 2003-10-22 16:29 ` Grokking GCC [Was: Re: I give up.] Bernd Jendrissek 0 siblings, 2 replies; 14+ messages in thread From: Jonathan Wilson @ 2003-10-22 14:58 UTC (permalink / raw) To: Bernd Jendrissek; +Cc: gcc > Such as... (yesterday) gen_rtx_REG? That's in emit-rtl.c. As for > gen_rtx_UNSPEC, I don't know. Bear in mind that there are about a dozen > or so C files that are *generated* during the build. Sometimes what > you're looking for is in there instead, or in the generator program. I did finally find all the bits of code (for example in genrtl.c). But all that has done is made me even more confused as to just WTF all these functions are actually for. What I am looking for is a "guide to emitting RTL in GCC on i?86 processors". Or if such a thing doesnt exist, someone out there who knows how to do what it is that I am trying to do and can tell me. Because after staring at the code, the docs, the (in this case) usless google search results and the back-postings to this list, I am still no closer to figuring out how functions like gen_rtx_UNSPEC, gen_rtx_CONST, gen_reg_rtx, gen_subsi3, emit_insn, gen_rtx_SET and so on actually transfer to the x86 assembler instructions that appear in the output thats fed to GAS :'( Normally, the usual response to "the docs, google and list archives" didnt help (when it comes to open source projects) is "go read the code". However in this case, what is one supposed to do when you have already read the code and even that didnt help? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: I give up. 2003-10-22 14:58 ` Jonathan Wilson @ 2003-10-22 15:08 ` Andrew Haley 2003-10-22 16:29 ` Grokking GCC [Was: Re: I give up.] Bernd Jendrissek 1 sibling, 0 replies; 14+ messages in thread From: Andrew Haley @ 2003-10-22 15:08 UTC (permalink / raw) To: Jonathan Wilson; +Cc: Bernd Jendrissek, gcc Jonathan Wilson writes: > > Such as... (yesterday) gen_rtx_REG? That's in emit-rtl.c. As for > > gen_rtx_UNSPEC, I don't know. Bear in mind that there are about a dozen > > or so C files that are *generated* during the build. Sometimes what > > you're looking for is in there instead, or in the generator program. > I did finally find all the bits of code (for example in genrtl.c). > But all that has done is made me even more confused as to just WTF all > these functions are actually for. > > What I am looking for is a "guide to emitting RTL in GCC on i?86 > processors". Or if such a thing doesnt exist, someone out there who knows > how to do what it is that I am trying to do and can tell me. > Because after staring at the code, the docs, the (in this case) usless > google search results and the back-postings to this list, I am still no > closer to figuring out how functions like gen_rtx_UNSPEC, gen_rtx_CONST, > gen_reg_rtx, gen_subsi3, emit_insn, gen_rtx_SET and so on actually transfer > to the x86 assembler instructions that appear in the output thats fed to > GAS :'( Look at i386.c. There's a ton of examples there, such as this one in ix86_expand_epilogue : rtx tmp, sa = EH_RETURN_STACKADJ_RTX; if (frame_pointer_needed) { tmp = gen_rtx_PLUS (Pmode, hard_frame_pointer_rtx, sa); tmp = plus_constant (tmp, UNITS_PER_WORD); emit_insn (gen_rtx_SET (VOIDmode, sa, tmp)); tmp = gen_rtx_MEM (Pmode, hard_frame_pointer_rtx); emit_move_insn (hard_frame_pointer_rtx, tmp); emit_insn (gen_pro_epilogue_adjust_stack (stack_pointer_rtx, sa, const0_rtx)); } else { tmp = gen_rtx_PLUS (Pmode, stack_pointer_rtx, sa); tmp = plus_constant (tmp, (frame.to_allocate + frame.nregs * UNITS_PER_WORD)); emit_insn (gen_rtx_SET (VOIDmode, stack_pointer_rtx, tmp)); } } which generates code to adjust registers, read and write memory, and so on. emit_insn() pushes an insn into the insn stream, which is then optimized and converted to assembler. Segment registers are a bit tricky. > Normally, the usual response to "the docs, google and list archives" didnt > help (when it comes to open source projects) is "go read the code". > However in this case, what is one supposed to do when you have already read > the code and even that didnt help? That's still true. Andrew. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Grokking GCC [Was: Re: I give up.] 2003-10-22 14:58 ` Jonathan Wilson 2003-10-22 15:08 ` Andrew Haley @ 2003-10-22 16:29 ` Bernd Jendrissek 1 sibling, 0 replies; 14+ messages in thread From: Bernd Jendrissek @ 2003-10-22 16:29 UTC (permalink / raw) To: Jonathan Wilson; +Cc: gcc -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Oct 22, 2003 at 09:11:35PM +0800, Jonathan Wilson wrote: > >Such as... (yesterday) gen_rtx_REG? That's in emit-rtl.c. As for > >gen_rtx_UNSPEC, I don't know. Bear in mind that there are about a dozen > >or so C files that are *generated* during the build. Sometimes what > >you're looking for is in there instead, or in the generator program. > I did finally find all the bits of code (for example in genrtl.c). > But all that has done is made me even more confused as to just WTF all > these functions are actually for. I think I empathise with your predicament... > What I am looking for is a "guide to emitting RTL in GCC on i?86 > processors". Or if such a thing doesnt exist, someone out there who knows > how to do what it is that I am trying to do and can tell me. > Because after staring at the code, the docs, the (in this case) usless ... but I think the solution is to stare at the code a little (much) longer. I feel like only now, after 3 years of on-and-off looking and lurking am I beginning to understand some of the pieces. More importantly, I feel I know which parts I can ignore as being "some compiler guru obviously knows what's going on here; I don't, so I'll just leave it". Don't let my "3 years" quote discourage you: if I didn't have a Real Job (tm) it'd probably be much, much less than that. Oh, and BTW, actually *messing around* has helped me tremendously: I've been working on a 16-bit x86 port with lots of tips and links from other people. A bit of a learning-through-immersion thing, I think. > google search results and the back-postings to this list, I am still no > closer to figuring out how functions like gen_rtx_UNSPEC, gen_rtx_CONST, > gen_reg_rtx, gen_subsi3, emit_insn, gen_rtx_SET and so on actually transfer > to the x86 assembler instructions that appear in the output thats fed to > GAS :'( AFAICT there's some heavy magic going on in GCC, practically having a built-in LISP interpreter. I think you generate that LISP-like RTL with all those gen_rtx_* functions (that may themselves be generated), which the "instruction recogniser" then matches to the patterns in the machine description. Those instruction patterns then specify what the assembly output will be. I'm not sure why you (think you) need to fret over all that RTL generation if you just want to implement TLS on mingw? Okay, a bit, but I can't imagine it'd be all that much... Oh, another hint I've found useful: this is all GPL'ed stuff. Copy and paste with gay abandon, then edit. You can try to understand it all later. (Disclaimer: this is probably bad advice.) Then fill in asignment form(s). There is no "their code/my code" dichotomy I perceive in the evil proprietary software development world in which I work. :) > Normally, the usual response to "the docs, google and list archives" didnt > help (when it comes to open source projects) is "go read the code". > However in this case, what is one supposed to do when you have already read > the code and even that didnt help? Oh, don't mean to sound arrogant, but have you tried "info gccint" (a *separate* manual for GCC internals)? Between it, the code and the mailing list I don't find life too hard. Women are much harder to hack. Read the code some more, I think. Repeat if necessary. bernd -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE/lprG/FmLrNfLpjMRApaQAJ93SvXzNseCrqWo4gL2B/m6x/LDVACgpla6 UgeCJStzLfKRgBxajmit9Ew= =nCeT -----END PGP SIGNATURE----- P.S. BTW, is all of Oz going nuts with Thugby like they are here in South Africa? What with the world cup being there and all... ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: I give up. 2003-10-22 14:15 I give up Jonathan Wilson 2003-10-22 14:16 ` Andrew Haley 2003-10-22 14:44 ` Bernd Jendrissek @ 2003-10-23 1:53 ` Mike Stump 2 siblings, 0 replies; 14+ messages in thread From: Mike Stump @ 2003-10-23 1:53 UTC (permalink / raw) To: Jonathan Wilson; +Cc: gcc On Wednesday, October 22, 2003, at 03:55 AM, Jonathan Wilson wrote: > I cant find anything on google about the various RTL functions (like > gen_rtx_UNSPEC). google isn't quite the right tool for this. > I cant find anything in the GCC docs. Read an memorize them all, that way, you will trivially know everything in them, and you won't have to find much. Seriously though, M-x grep, then '\<unspec\>' doc/*.texi finds 6 hits in 1/2 second or less. And from that, we can read up on unspec and what it does. After you step around in code you want to work in, you start noticing things, like function that start with gen_ usually generate things, what what they generate is given by the rest of the name (and maybe in the arguments). What you see this pattern, you will just know that gen_unspec generates an unspec, and a quick glace at the texi file tells you in rough terms what an unspec is. Think of them as self-contained black boxes, into which the compiler doesn't peer. > And I cant find anything in the source code for these specific > functions (I cant even FIND their code) Standard technique 3: Just fire up emacs, type M-x gdb, then gdb cc1, then set a breakpoint just before the area you are interested in, then type step and you can watch it go into the routine you're interested in. Emacs will just pull up the source code for you automagically. handy gcc specific knowledge: In time, you realize all source code is in gcc/*.[ch] gcc/config/*.[ch] gcc/config/*/*.[ch] and in the build directory in gcc/*.[ch], and that make TAGS will build an index for you, and M-. in emacs will take you to just about any of them, though not things in the build tree like gen_rtx_UNSPEC. ^ permalink raw reply [flat|nested] 14+ messages in thread
* I give up
@ 2001-12-27 23:24 Finny Merrill
2001-12-27 23:53 ` Andris Pavenis
2001-12-28 13:05 ` Phil Edwards
0 siblings, 2 replies; 14+ messages in thread
From: Finny Merrill @ 2001-12-27 23:24 UTC (permalink / raw)
To: gcc
What in hell does this piece of greek mean? I have NO idea what it means,
it only happens when I compile in release mode, with all optimizations
turned on.
gcc -Dstricmp=strcasecmp -g -mpentiumpro -O6 -ffast-math -funroll-loops
-fomit-frame-pointer -fexpensive-optimizations -fPIC -o
releasei386-glibc/game/p_client.o -c ../game/p_client.c
../game/p_client.c: In function `ClientThink':
../game/p_client.c:1754: Insn does not satisfy its constraints:
(insn:TI 1970 2078 1971 (parallel[
(set (mem:HI (plus:SI (reg:SI 6 ebp)
(const_int -274 [0xfffffeee])) 0)
(fix:HI (reg:SF 8 st(0))))
(clobber (mem:SI (plus:SI (reg:SI 6 ebp)
(const_int -272 [0xfffffef0])) 0))
(clobber (mem:HI (plus:SI (reg:SI 6 ebp)
(const_int -274 [0xfffffeee])) 0))
(clobber (reg:SI 6 ebp))
] ) 97 {*fix_trunchi_1} (insn_list 1734 (insn_list:REG_DEP_ANTI
1961 (insn_list:REG_DEP_ANTI 567 (insn_list:REG_DEP_ANTI 559
(insn_list:REG_DEP_ANTI 561 (insn_list:REG_DEP_ANTI 563
(insn_list:REG_DEP_ANTI 1962 (insn_list:REG_DEP_ANTI 1821
(insn_list:REG_DEP_ANTI 1824 (insn_list:REG_DEP_ANTI 576
(insn_list:REG_DEP_ANTI 1705 (insn_list 1827 (insn_list:REG_DEP_ANTI 1704
(insn_list:REG_DEP_ANTI 1964 (insn_list:REG_DEP_ANTI 1965
(insn_list:REG_DEP_ANTI 1708 (insn_list:REG_DEP_ANTI 1710
(insn_list:REG_DEP_ANTI 1966 (insn_list:REG_DEP_ANTI 1967
(insn_list:REG_DEP_ANTI 1713 (insn_list:REG_DEP_ANTI 1727
(insn_list:REG_DEP_ANTI 1968 (insn_list:REG_DEP_ANTI 1969
(insn_list:REG_DEP_ANTI 1731 (insn_list:REG_DEP_ANTI 1733
(nil))))))))))))))))))))))))))
(expr_list:REG_DEAD (reg:SF 8 st(0))
(nil)))
../game/p_client.c:1754: confused by earlier errors, bailing out
99% sure it's an assembler error
but that looks like LISP!!
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: I give up 2001-12-27 23:24 Finny Merrill @ 2001-12-27 23:53 ` Andris Pavenis 2001-12-28 0:16 ` Finny Merrill 2001-12-28 13:05 ` Phil Edwards 1 sibling, 1 reply; 14+ messages in thread From: Andris Pavenis @ 2001-12-27 23:53 UTC (permalink / raw) To: Finny Merrill, gcc On Friday 28 December 2001 08:51, Finny Merrill wrote: > What in hell does this piece of greek mean? I have NO idea what it means, > it only happens when I compile in release mode, with all optimizations > turned on. Which gcc version? Does the problem go away if command line options -fomit-frame-pointer or/and (possibly some other one) is removed? If You're using gcc-3.0, 3.0.1 or 3.0.2 then please try gcc-3.0.3 as earlier gcc-3.0.X versions had problems with option -fomit-frame-pointer (PR#4529, PR#4763 and maybe some others in GCC GNATS database) > > gcc -Dstricmp=strcasecmp -g -mpentiumpro -O6 -ffast-math -funroll-loops > -fomit-frame-pointer -fexpensive-optimizations -fPIC -o > releasei386-glibc/game/p_client.o -c ../game/p_client.c > ../game/p_client.c: In function `ClientThink': > ../game/p_client.c:1754: Insn does not satisfy its constraints: > (insn:TI 1970 2078 1971 (parallel[ > (set (mem:HI (plus:SI (reg:SI 6 ebp) > (const_int -274 [0xfffffeee])) 0) > (fix:HI (reg:SF 8 st(0)))) > (clobber (mem:SI (plus:SI (reg:SI 6 ebp) > (const_int -272 [0xfffffef0])) 0)) > (clobber (mem:HI (plus:SI (reg:SI 6 ebp) > (const_int -274 [0xfffffeee])) 0)) > (clobber (reg:SI 6 ebp)) > ] ) 97 {*fix_trunchi_1} (insn_list 1734 (insn_list:REG_DEP_ANTI > 1961 (insn_list:REG_DEP_ANTI 567 (insn_list:REG_DEP_ANTI 559 > (insn_list:REG_DEP_ANTI 561 (insn_list:REG_DEP_ANTI 563 > (insn_list:REG_DEP_ANTI 1962 (insn_list:REG_DEP_ANTI 1821 > (insn_list:REG_DEP_ANTI 1824 (insn_list:REG_DEP_ANTI 576 > (insn_list:REG_DEP_ANTI 1705 (insn_list 1827 (insn_list:REG_DEP_ANTI 1704 > (insn_list:REG_DEP_ANTI 1964 (insn_list:REG_DEP_ANTI 1965 > (insn_list:REG_DEP_ANTI 1708 (insn_list:REG_DEP_ANTI 1710 > (insn_list:REG_DEP_ANTI 1966 (insn_list:REG_DEP_ANTI 1967 > (insn_list:REG_DEP_ANTI 1713 (insn_list:REG_DEP_ANTI 1727 > (insn_list:REG_DEP_ANTI 1968 (insn_list:REG_DEP_ANTI 1969 > (insn_list:REG_DEP_ANTI 1731 (insn_list:REG_DEP_ANTI 1733 > (nil)))))))))))))))))))))))))) > (expr_list:REG_DEAD (reg:SF 8 st(0)) > (nil))) > ../game/p_client.c:1754: confused by earlier errors, bailing out > > 99% sure it's an assembler error > but that looks like LISP!! ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: I give up 2001-12-27 23:53 ` Andris Pavenis @ 2001-12-28 0:16 ` Finny Merrill 2001-12-28 1:49 ` Andris Pavenis 2001-12-28 4:25 ` Jakub Jelinek 0 siblings, 2 replies; 14+ messages in thread From: Finny Merrill @ 2001-12-28 0:16 UTC (permalink / raw) To: Andris Pavenis; +Cc: gcc On Fri, 28 Dec 2001, Andris Pavenis wrote: > On Friday 28 December 2001 08:51, Finny Merrill wrote: > > What in hell does this piece of greek mean? I have NO idea what it means, > > it only happens when I compile in release mode, with all optimizations > > turned on. > > Which gcc version? > [griever@linux linux]$ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98) [griever@linux linux]$ > Does the problem go away if command line options -fomit-frame-pointer > or/and (possibly some other one) is removed? Yes, omit-frame-pointer is the cause > > If You're using gcc-3.0, 3.0.1 or 3.0.2 then please try gcc-3.0.3 as earlier > gcc-3.0.X versions had problems with option -fomit-frame-pointer > (PR#4529, PR#4763 and maybe some others in GCC GNATS database) > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: I give up 2001-12-28 0:16 ` Finny Merrill @ 2001-12-28 1:49 ` Andris Pavenis 2001-12-28 4:25 ` Jakub Jelinek 1 sibling, 0 replies; 14+ messages in thread From: Andris Pavenis @ 2001-12-28 1:49 UTC (permalink / raw) To: Finny Merrill; +Cc: gcc On Friday 28 December 2001 10:06, Finny Merrill wrote: > On Fri, 28 Dec 2001, Andris Pavenis wrote: > > On Friday 28 December 2001 08:51, Finny Merrill wrote: > > > What in hell does this piece of greek mean? I have NO idea what it > > > means, it only happens when I compile in release mode, with all > > > optimizations turned on. > > > > Which gcc version? > > [griever@linux linux]$ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs > gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98) > [griever@linux linux]$ > > > Does the problem go away if command line options -fomit-frame-pointer > > or/and (possibly some other one) is removed? > > Yes, omit-frame-pointer is the cause > > > If You're using gcc-3.0, 3.0.1 or 3.0.2 then please try gcc-3.0.3 as > > earlier gcc-3.0.X versions had problems with option -fomit-frame-pointer > > (PR#4529, PR#4763 and maybe some others in GCC GNATS database) You may try to look whether it is possible to apply fix (one line only) to RedHat versions of GCC (I don't know as I'm not using RedHat distribution). See: http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=4529&database=gcc for details. Andris ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: I give up 2001-12-28 0:16 ` Finny Merrill 2001-12-28 1:49 ` Andris Pavenis @ 2001-12-28 4:25 ` Jakub Jelinek 1 sibling, 0 replies; 14+ messages in thread From: Jakub Jelinek @ 2001-12-28 4:25 UTC (permalink / raw) To: Finny Merrill; +Cc: Andris Pavenis, gcc On Fri, Dec 28, 2001 at 02:06:24AM -0600, Finny Merrill wrote: > On Fri, 28 Dec 2001, Andris Pavenis wrote: > > > On Friday 28 December 2001 08:51, Finny Merrill wrote: > > > What in hell does this piece of greek mean? I have NO idea what it means, > > > it only happens when I compile in release mode, with all optimizations > > > turned on. > > > > Which gcc version? > > > [griever@linux linux]$ gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs > gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98) > [griever@linux linux]$ Then you shouldn't report it to gcc mailing list, but to Red Hat instead. Please file a bug at http://bugzilla.redhat.com/bugzilla/, include preprocessed source and gcc options. Thanks. Jakub ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: I give up 2001-12-27 23:24 Finny Merrill 2001-12-27 23:53 ` Andris Pavenis @ 2001-12-28 13:05 ` Phil Edwards 1 sibling, 0 replies; 14+ messages in thread From: Phil Edwards @ 2001-12-28 13:05 UTC (permalink / raw) To: Finny Merrill; +Cc: gcc On Fri, Dec 28, 2001 at 12:51:48AM -0600, Finny Merrill wrote: > What in hell does this piece of greek mean? I have NO idea what it means, > it only happens when I compile in release mode, with all optimizations > turned on. [an ICE occurs] > > 99% sure it's an assembler error > but that looks like LISP!! Welcome to the guts of GCC. I say that because GCC just puked its guts onto your lap. :-) That's how GCC represents its internal state when the state needs to be displayed on-screen, and yes, it was deliberately designed to resemble LISP. It's not an assembler error because your build never made it that far; it's an internal compiler error. Normally GCC will print something useful like "Internal Compiler Error" before printing the guts, but earlier versions like the one that Red Hat shipped didn't always do so. Phil -- If ye love wealth greater than liberty, the tranquility of servitude greater than the animating contest for freedom, go home and leave us in peace. We seek not your counsel, nor your arms. Crouch down and lick the hand that feeds you; and may posterity forget that ye were our countrymen. - Samuel Adams ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2003-10-22 22:12 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-10-22 14:15 I give up Jonathan Wilson 2003-10-22 14:16 ` Andrew Haley 2003-10-22 14:41 ` Jonathan Wilson 2003-10-22 14:44 ` Bernd Jendrissek 2003-10-22 14:58 ` Jonathan Wilson 2003-10-22 15:08 ` Andrew Haley 2003-10-22 16:29 ` Grokking GCC [Was: Re: I give up.] Bernd Jendrissek 2003-10-23 1:53 ` I give up Mike Stump -- strict thread matches above, loose matches on Subject: below -- 2001-12-27 23:24 Finny Merrill 2001-12-27 23:53 ` Andris Pavenis 2001-12-28 0:16 ` Finny Merrill 2001-12-28 1:49 ` Andris Pavenis 2001-12-28 4:25 ` Jakub Jelinek 2001-12-28 13:05 ` Phil Edwards
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).