Re: Inconsistency in runtime target tool search
As an aside, the cross compiler successfully builds and links target libraries because it uses: [EMAIL PROTECTED]:~/gcc-build$ cat gcc/as #!/bin/sh exec /opt/odcctools/bin/i386-apple-darwin8.4.1-as "$@" [EMAIL PROTECTED]:~/gcc-build$ cat gcc/collect-ld #!/bin/sh exec /opt/odcctools/bin/i386-apple-darwin8.4.1-ld "$@" [EMAIL PROTECTED]:~/gcc-build$ I guess I'm asking for the driver to have parity with gcc's build system, which prepends the target name for these tools h... the configure scripts try to match the driver and collect2, in order to test the same assembler and linker that the installed compiler uses. But it looks like it fails for cross-compilation, when using tools different from GNU binutils. A workaround is to install the assembler, linker, etc. in /opt/odcctools/i386-apple-darwin8.4.1/bin (for example by hard-linking them to the tools you installed in /opt/odcctools/bin). This is what GNU binutils do during installation. Paolo
What do these mean?
Hi , Can someone please let me know what the extensions t02 & original mean in the filename test.c.t02.original after compiling test.c using the option fdump-tree-original-raw, generating an AST? Darth -- View this message in context: http://www.nabble.com/What-do-these-mean--t1046908.html#a2720645 Sent from the gcc - Dev forum at Nabble.com.
Re: What do these mean?
Darthrader (sent by Nabble.com) wrote: > Can someone please let me know what the extensions t02 & original > mean in the filename test.c.t02.original after compiling test.c using > the option fdump-tree-original-raw, generating an AST? > t02 = tree dump #2. original = dump of the original source code before any transformations.
Re: What do these mean?
Thanx for ur reply Diego. Got a few more queries... What does the number '02' signify? Can I change that ? How? Darthrader -- View this message in context: http://www.nabble.com/What-do-these-mean--t1046908.html#a2720928 Sent from the gcc - Dev forum at Nabble.com.
Re: What do these mean?
Darthrader (sent by Nabble.com) wrote: > What does the number '02' signify? > Please read my message again. It's the 2nd dump file in the tree optimization pipeline. > Can I change that ? How? > No. It depends on pass ordering. See init_optimization_passes in passes.c.
Machine Dependance
Is the AST[Abstract Syntax Tree] machine dependent? I read some where that it should be machine independent but when i compiled a c program and generated its AST using -fdump-tree-original-raw on gcc-4.0.0 , there were certain node values ,which were diifferent on different machines like algn,why ? Also what does algn : mean? Darthrader -- View this message in context: http://www.nabble.com/Machine-Dependance-t1047440.html#a2722136 Sent from the gcc - Dev forum at Nabble.com.
AST
Can someone give a good link to any information about the Abstract Syntax Tree. Any help will be appreciated. TIA, Darthrader -- View this message in context: http://www.nabble.com/AST-t1047504.html#a2722321 Sent from the gcc - Dev forum at Nabble.com.
Re: Machine Dependance
Darthrader (sent by Nabble.com) wrote: Is the AST[Abstract Syntax Tree] machine dependent? The nodes that are generated for the program as it is parsed are machine independent. However: 1) this can only be true if your source code is already preprocessed. Otherwise, the source code that GCC really sees it is different. If you use the "--save-temps" option, you will find a .i file which is what GCC has built the parse tree from. 2) Some tree nodes are implicit in the compiler, and are always created even if the program does not mention them. You can imagine that every program had on top of it something like: typedef void __attribute__ ((mode (QI))) char; typedef void __attribute__ ((mode (HI))) short; typedef void __attribute__ ((mode (SI))) int; typedef void __attribute__ ((mode (__word__))) long; typedef void __attribute__ ((mode (DI))) long long; (which is not really valid C code, of course!) and so on. GCC's syntax tree nodes are heavily annotated with information on the nodes, and the information for these implicit nodes can be machine dependent: for example, long may have 4 bytes on some machines and 8 bytes on others. In your case, "algn" was the alignment required by the type. 3) Some of the information percolates from the types to other tree nodes, such as the variables. So your "original" dump could contain some differences in the tree nodes for variables: these come from the machine dependent nodes I just described. 4) Finally, some minor optimizations in fold-const.c that are performed before the ".original" dump is emitted, so you could see differences because of that. You probably know that a compiler is roughly divided in front-ends (reads source code), middle-end (works on an intermediate representation), and back-end (uses the intermediate representation to emit assembly). Very roughly speaking, GCC's middle-end starts in fold-const.c. GCC's middle-end uses more or less four intermediate representation: GENERIC (a standardized form of syntax trees), GIMPLE (an even more standardized and simplified form of syntax trees), RTL, and "strict" RTL (where each instruction and each operand has an almost 1-1 mapping with the assembly language instructions and operands). In practice it is a bit more complicated because GENERIC is transformed to GIMPLE "slowly" and gradually. GCC's syntax trees are pretty well machine independent, enough independent that they work well as a machine independent intermediate representation for many optimization passes at the beginning in the compiler pipeline. As GCC switches from tree nodes to RTL and to strict RTL, more and more machine dependent pieces creep into its intermediate representation. In the end, things are so machine dependent that most non-trivial changes to the RTL middle-end had better be tested on more than one machine: they can work like a charm on i686 and break, say, powerpc or arm or s390 or all of these. Paolo
ECCN Request - GCC
Hi - I'm trying to determine if we can export the GNU GCC product. Can you please let me know if it contains any encryption? Thank you, Collette 8
Re: ECCN Request - GCC
> I'm trying to determine if we can export the GNU GCC product. Can you > please let me know if it contains any encryption? > You mean besides the documentation itself which is cryptic at times? No. IIRC, there some one way hashes used, but no encryption. Your question is amusing considering everyone in the entire world has access to the source code. You do realize that, right? -Steve
Re: ECCN Request - GCC
> "Steve" == sjhill <[EMAIL PROTECTED]> writes: >> I'm trying to determine if we can export the GNU GCC product. Can you >> please let me know if it contains any encryption? Steve> You mean besides the documentation itself which is cryptic at times? No. Steve> IIRC, there some one way hashes used, but no encryption. There is encryption code in libgcj. Tom
RE: ECCN Request - GCC
On 02 February 2006 17:29, [EMAIL PROTECTED] wrote: >> I'm trying to determine if we can export the GNU GCC product. Can you >> please let me know if it contains any encryption? >> > You mean besides the documentation itself which is cryptic at times? No. > IIRC, there some one way hashes used, but no encryption. Your question is > amusing considering everyone in the entire world has access to the source > code. You do realize that, right? > > -Steve Well, that doesn't actually stop governments from bringing prosecutions (cf 'Spycatcher') even though they may be pointless in terms of suppressing the information. Collette, whatever advice you get from this list does not come from lawyers and comes with no guarantees as to its correctness or validity. If you want to know if your plans would be in compliance with the law, you should ask a lawyer, not a bunch of geeks! You work for a huge corporation, they must have a legal department who would be the right people to take this up with. And what does 'ECCN request' mean? cheers, DaveK -- Can't think of a witty .sigline today
RE: ECCN Request - GCC
On Thu, 2 Feb 2006, Dave Korn wrote: > On 02 February 2006 17:29, [EMAIL PROTECTED] wrote: > > >> I'm trying to determine if we can export the GNU GCC product. Can you > >> please let me know if it contains any encryption? > >> > > You mean besides the documentation itself which is cryptic at times? No. > > IIRC, there some one way hashes used, but no encryption. Your question is > > amusing considering everyone in the entire world has access to the source > > code. You do realize that, right? > > > > -Steve > > > Well, that doesn't actually stop governments from bringing prosecutions (cf > 'Spycatcher') even though they may be pointless in > terms of suppressing the information. > > Collette, whatever advice you get from this list does not come from lawyers > and comes with no guarantees as to its correctness or > validity. If you want to know if your plans would be in compliance with the > law, you should ask a lawyer, not a bunch of geeks! > You work for a huge corporation, they must have a legal department who would > be the right people to take this up with. > > And what does 'ECCN request' mean? google knows: http://www.census.gov/foreign-trade/faq/gen/gen0014.html > cheers, > DaveK -- ~Randy
Re: ECCN Request - GCC
On Feb 2, 2006, at 11:28 AM, [EMAIL PROTECTED] wrote: I'm trying to determine if we can export the GNU GCC product. Can you please let me know if it contains any encryption? You mean besides the documentation itself which is cryptic at times? No. IIRC, there some one way hashes used, but no encryption. Your question is amusing considering everyone in the entire world has access to the source code. You do realize that, right? As a "customer", I consider your documentation spectacular...
Re: ECCN Request - GCC
On Thu, Feb 02, 2006 at 10:34:35AM -0700, Tom Tromey wrote: > > "Steve" == sjhill <[EMAIL PROTECTED]> writes: > > >> I'm trying to determine if we can export the GNU GCC product. Can you > >> please let me know if it contains any encryption? > > Steve> You mean besides the documentation itself which is cryptic at times? > No. > Steve> IIRC, there some one way hashes used, but no encryption. > > There is encryption code in libgcj. However, US export law has changed; you can still export open source software that contains cryptography provided that you follow the rules correctly. Please consult your attorney for the details.
Re: Machine Dependance
Thanx for ur reply.I have a few more questions below: Paolo Bonzini-2 wrote: > > Darthrader (sent by Nabble.com) wrote: >> Is the AST[Abstract Syntax Tree] machine dependent? > > The nodes that are generated for the program as it is parsed are machine > independent. However: > > 1) this can only be true if your source code is already preprocessed. > Otherwise, the source code that GCC really sees it is different. If you > use the "--save-temps" option, you will find a .i file which is what GCC > has built the parse tree from. > > I saw the .i file but i could not make any sense out of it.Its the program > code (mine was a very simple 4 line code) but in the part before main() it > contains : > > # 1 "test.c" > # 1 " " > # 1 " " > # 1 "test.c" > > What do these represent? > > > 2) Some tree nodes are implicit in the compiler, and are always created > even if the program does not mention them. You can imagine that every > program had on top of it something like: > > typedef void __attribute__ ((mode (QI))) char; > typedef void __attribute__ ((mode (HI))) short; > typedef void __attribute__ ((mode (SI))) int; > typedef void __attribute__ ((mode (__word__))) long; > typedef void __attribute__ ((mode (DI))) long long; > > (which is not really valid C code, of course!) and so on. GCC's > syntax tree nodes are heavily annotated with information on the nodes, > and the information for these implicit nodes can be machine dependent: > for example, long may have 4 bytes on some machines and 8 bytes on > others. In your case, "algn" was the alignment required by the type. > > - > Kindly elaborate on algn.The alignment required by the type relative to what > and why? > - > > 3) Some of the information percolates from the types to other tree > nodes, such as the variables. So your "original" dump could contain > some differences in the tree nodes for variables: these come from the > machine dependent nodes I just described. > > 4) Finally, some minor optimizations in fold-const.c that are performed > before the ".original" dump is emitted, so you could see differences > because of that. > > You probably know that a compiler is roughly divided in front-ends > (reads source code), middle-end (works on an intermediate > representation), and back-end (uses the intermediate representation to > emit assembly). > > Very roughly speaking, GCC's middle-end starts in fold-const.c. GCC's > middle-end uses more or less four intermediate representation: GENERIC > (a standardized form of syntax trees), GIMPLE (an even more standardized > and simplified form of syntax trees), RTL, and "strict" RTL (where each > instruction and each operand has an almost 1-1 mapping with the assembly > language instructions and operands). In practice it is a bit more > complicated because GENERIC is transformed to GIMPLE "slowly" and gradually. > > GCC's syntax trees are pretty well machine independent, enough > independent that they work well as a machine independent intermediate > representation for many optimization passes at the beginning in the > compiler pipeline. As GCC switches from tree nodes to RTL and to strict > RTL, more and more machine dependent pieces creep into its intermediate > representation. In the end, things are so machine dependent that most > non-trivial changes to the RTL middle-end had better be tested on more > than one machine: they can work like a charm on i686 and break, say, > powerpc or arm or s390 or all of these. > > Paolo > > > -- View this message in context: http://www.nabble.com/Machine-Dependance-t1047440.html#a2725013 Sent from the gcc - Dev forum at Nabble.com.
Re: Machine Dependance
Sorry if I am more terse this time. Also, these questions are now more suited for the gcc-help list, rather than this one which is for development of GCC itself. # 1 "test.c" # 1 " " # 1 " " # 1 "test.c" What do these represent? Try "info cpp", and search for "Preprocessor Output". Kindly elaborate on algn.The alignment required by the type relative to what and why? Google gives wonderful answers (try these keywords: data alignment) Paolo
Re: Reconsidering gcjx
Andrew Haley dixit: > > Thorsten> Why not keep enough support in jc1 to bootstrap ecj? > > > > We don't know how much of the language that would be. > >And we can't tell _a priori_. As I understand it, the intention is to >use upstream sources, and they will change. Just keep the current state then - maybe in a separate frontend only used for bootstrapping, sharing some code with the final, class-only, frontend. And expand it if needed for ecj. bye, //mirabile -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt
Re: Machine Dependance
Hey Paolo thanx a lot.I got the info I required. Can u mention any links that i can use as a reference to understand the dump output of -fdump-tree-original-raw as AST? Thanx a lot. Darthrader -- View this message in context: http://www.nabble.com/Machine-Dependance-t1047440.html#a2725614 Sent from the gcc - Dev forum at Nabble.com.
i386-rtems does not build on head
This is a breakage in about the past week. I built a native compiler from the same source. Does this look familiar to anyone? home/joel/gcc-work/head/b-i386-rtems4.7/./gcc/xgcc -B/home/joel/gcc-work/head/b-i386-rtems4.7/./gcc/ -nostdinc -B/ho me/joel/gcc-work/head/b-i386-rtems4.7/i386-rtems4.7/newlib/ -isystem /home/joel/gcc-work/head/b-i386-rtems4.7/i386-rt ems4.7/newlib/targ-include -isystem /home/joel/gcc-work/head/gcc/newlib/libc/include -B/home/joel/gcc-head-test//i386 -rtems4.7/bin/ -B/home/joel/gcc-head-test//i386-rtems4.7/lib/ -isystem /home/joel/gcc-head-test//i386-rtems4.7/includ e -isystem /home/joel/gcc-head-test//i386-rtems4.7/sys-include -DPACKAGE_NAME=\"libgcc-math\" -DPACKAGE_TARNAME=\"lib gcc-math\" -DPACKAGE_VERSION=\"1.0\" "-DPACKAGE_STRING=\"libgcc-math 1.0\"" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"libg cc-math\" -DVERSION=\"1.0\" -DHAVE_HIDDEN_VISIBILITY=1 -I. -I../../../../gcc/libgcc-math/i386 -I../../../../gcc/libgc c-math/i386/../include -include ../../../../gcc/libgcc-math/i386/sse2.h -Wall -O2 -g -msse2 -msseregparm -mfpmath=sse -march=pentium3 -fno-math-errno -fno-trapping-math -ffinite-math-only -fno-rounding-math -fno-signaling-nans -D__NO_ MATH_INLINES -O2 -g -O2 -MT libsse2_la-e_acosf.lo -MD -MP -MF .deps/libsse2_la-e_acosf.Tpo -c ../../../../gcc/libgcc- math/i386/../flt-32/e_acosf.c -o libsse2_la-e_acosf.o In file included from ../../../../gcc/libgcc-math/i386/../flt-32/e_acosf.c:21: ../../../../gcc/libgcc-math/i386/../include/math_private.h:182: error: expected '=', ',', ';', 'asm' or '__attribute_ _' before '__ieee754_rem_pio2' ../../../../gcc/libgcc-math/i386/../include/math_private.h:190: warning: type defaults to 'int' in declaration of 'in t32_t' ../../../../gcc/libgcc-math/i386/../include/math_private.h:190: error: expected ';', ',' or ')' before '*' token ../../../../gcc/libgcc-math/i386/../include/math_private.h:225: error: expected '=', ',', ';', 'asm' or '__attribute_ _' before '__ieee754_rem_pio2f' ../../../../gcc/libgcc-math/i386/../include/math_private.h:233: warning: type defaults to 'int' in declaration of 'int32_t' ../../../../gcc/libgcc-math/i386/../include/math_private.h:233: error: expected ';', ',' or ')' before '*' token ../../../../gcc/libgcc-math/i386/../flt-32/e_acosf.c: In function '__libm_sse2_acosf': ../../../../gcc/libgcc-math/i386/../flt-32/e_acosf.c:51: error: 'int32_t' undeclared (first use in this function) ../../../../gcc/libgcc-math/i386/../flt-32/e_acosf.c:51: error: (Each undeclared identifier is reported only once ../../../../gcc/libgcc-math/i386/../flt-32/e_acosf.c:51: error: for each function it appears in.) ../../../../gcc/libgcc-math/i386/../flt-32/e_acosf.c:51: error: expected ';' before 'hx' ../../../../gcc/libgcc-math/i386/../flt-32/e_acosf.c:52: error: 'hx' undeclared (first use in this function) ../../../../gcc/libgcc-math/i386/../flt-32/e_acosf.c:53: error: 'ix' undeclared (first use in this function) ../../../../gcc/libgcc-math/i386/../flt-32/e_acosf.c:76: error: expected ';' before 'idf' ../../../../gcc/libgcc-math/i386/../flt-32/e_acosf.c:80: error: 'idf' undeclared (first use in this function) ../../../../gcc/libgcc-math/i386/../flt-32/e_acosf.c:89: warning: control reaches end of non-void function make[3]: *** [libsse2_la-e_acosf.lo] Error 1 --joel
Re: i386-rtems does not build on head
If this help, I'd like to add that I succesfully compiled gcc-4.2-20060128.tar.bz2 for the same configuration. Cheers, Karel On Thu, 2 Feb 2006, Joel Sherrill wrote: This is a breakage in about the past week. I built a native compiler from the same source. Does this look familiar to anyone? -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: i386-rtems does not build on head
Karel Gardas wrote: If this help, I'd like to add that I succesfully compiled gcc-4.2-20060128.tar.bz2 for the same configuration. I think my last SVN update that built for me was a couple of days before that. --joel Cheers, Karel On Thu, 2 Feb 2006, Joel Sherrill wrote: This is a breakage in about the past week. I built a native compiler from the same source. Does this look familiar to anyone? -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
[Lee Millward <[EMAIL PROTECTED]>] Re: Request from Lee Millward
Can someone help Lee with SSH and SVN checking issues? He has a read+write access to GCC sources. -- Gaby --- Begin Message --- I'm following the instructions from this page on settnig up your local tree for write access - http://gcc.gnu.org/svnwrite.html The command I issue is: svn switch --relocate svn://gcc.gnu.org/svn/gcc svn+ssh://[EMAIL PROTECTED]/svn/gcc on my already local source tree as those instructions say to do, after a pause of about 5-6 seconds I get a "permission denied" followed by a "connection closed unexpectedly" from SVN. The username is the same as the one I entered on the registration form, it doesn't ask me for any password/passphrase. Even attempting a "normal" checkout using svn checkout svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk gcc fails with the same error. --- End Message --- -- Gabriel Dos Reis [EMAIL PROTECTED]
Re: [Lee Millward <[EMAIL PROTECTED]>] Re: Request from Lee Millward
On Feb 2, 2006, at 1:04 PM, Gabriel Dos Reis wrote: Can someone help Lee with SSH and SVN checking issues? I'd recommend contacting [EMAIL PROTECTED] He has a read+write access to GCC sources. Apparently not.
Re: [HELP take two] GCC 4.1 branch Ada status on powerpc-darwin?
On Wed, 2006-02-01 at 22:00 +0100, Eric Botcazou wrote: > > Could someone with powerpc-darwin access check wether Ada is now working > > or not, if not populate bugzilla? > > The compiler bootstraps fine but all ACATS tests fail to link. You need to > manually pass -static-libgcc at link time. When this is done, ACATS results are as expected: === acats Summary === # of expected passes2315 # of unexpected failures1 *** FAILURES: c250002 c250002 is PR ada/20974 and is without consequence. Laurent
Re: Thoughts on imposing a 100k per-comment limit
On Wed, Feb 01, 2006 at 12:42:35AM -0500, Daniel Berlin wrote: > Would anyone object to me just telling bugzilla to reject comments > > 100k in length? Nope. Tell the user to use the attachment feature. > (i've chosen 100k to keep arguments about what the "right" length is. I > believe *everyone* can agree that 100k is over that length :P ) Waaay over. ;-) r~
gcc-4.0-20060202 is now available
Snapshot gcc-4.0-20060202 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060202/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch revision 110521 You'll find: gcc-4.0-20060202.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20060202.tar.bz2 C front end and core compiler gcc-ada-4.0-20060202.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20060202.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20060202.tar.bz2 C++ front end and runtime gcc-java-4.0-20060202.tar.bz2 Java front end and runtime gcc-objc-4.0-20060202.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20060202.tar.bz2The GCC testsuite Diffs from 4.0-20060126 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: [Lee Millward <[EMAIL PROTECTED]>] Re: Request from Lee Millward
Mike Stump <[EMAIL PROTECTED]> writes: | On Feb 2, 2006, at 1:04 PM, Gabriel Dos Reis wrote: | > Can someone help Lee with SSH and SVN checking issues? | | I'd recommend contacting [EMAIL PROTECTED] I'll send it there. | > He has a read+write access to GCC sources. | | Apparently not. I said that because I got a copy of the confirmation of his account..., now the account may very well not exist :-) -- Gaby
svn funniness?
When bulk merging trunk to local release branch, svn reports whole file conflicts as 'A'. :-( svn status after the merge is necessary to find the conflicts. I'm using svn client: mrs $ svn --version svn, version 1.3.0 (r17949) compiled Jan 4 2006, 12:42:53 and the server was either the same, or possibly and older version. Have others seen this behavior? If you're curious, I was doing something like: svn merge svn+ssh://gnu.gnu.org/svn/gcc/tags/gcc_4_0_1_release svn +ssh://gcc.gnu.org/svn/gcc/[EMAIL PROTECTED] into apple/trunk, something like that, as I'm using a local svn mirror for the branch.
Re: svn funniness?
Mike Stump wrote: > When bulk merging trunk to local release branch, svn reports whole file > conflicts as 'A'. :-( > If you can give me a way to reproduce it, i can fix it. I've never seen such behavior. AFAIK, all conflicts should be flagged as C, whole file or not.
Use predicates for RTL objects
Do people still want (GET_CODE (rtx) == XXX) cleaned up to XXX_P(RTX). If so I notice that there are quite a few of the following: 200 of GET_CODE(rtx) == PLUS ---> PLUS_P(rtx) 50 of GET_CODE(rtx) == MINUS > MINUS_P(rtx) 550 of GET_CODE(rtx) == CONST_INT ---> CONST_INT_P(rtx) 70 of GET_CODE(rtx) == CONST_DOUBLE > CONST_DOUBLE_P(rtx) 150 of GET_CODE(rtx) == PARALLEL > CONST_PARALLEL_P(rtx) I would probably do all the plus/minus stuff first. Submit that as a patch. Nathan Bullock ps. Do I just send the diff file to this mailing list?
Re: Use predicates for RTL objects
> Do people still want (GET_CODE (rtx) == XXX) cleaned up to XXX_P(RTX). I would think so -- did you get that from the beginner's project list? > I would probably do all the plus/minus stuff first. Submit that as a patch. Sure. Please read the patch submission guidelines before starting. > ps. Do I just send the diff file to this mailing list? No, gcc-patches. Cheers, Ben
