Question about compilation details
Hi. I'm using the arm-elf-gcc compiler to compile some files to a ARM9 (Freescale i.MX27, ARM926EJ-S core). What I would like to know is how can I visualize/change the address specifications made by the linker to the output file? I heard gcc can generate a file (.lst) that contains such information, but I also don't know how to create this file. Thanks in advance. Best regards, Eduardo
GCC 4.0.1 build succeeded using Fedora Core 4
GCC 4.0.1 has been succesfully built on Fedora Core 4 - hardware: Intel Celeron 2.0 GHz 512 MB RAM - download: gcc-4.0.1.tar.bz2 - installation steps configure make bootstrap make install - output from running config.guess i686-pc-linux-gnu - output of gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/gcc-4.0.1/configure Thread model: posix gcc version 4.0.1 - languages: default - Linux - distribution Fedora Core 4 - uname -a Linux localhost.localdomain 2.6.11-1.1369_FC4 #1 Thu Jun2 22:55:56 EDT 2005 i686 i686 i386 GNU/Linux - glibc glibc-2.3.5-10 -- Eduardo Restuccia www.handsoft.com.uy Montevideo - Uruguay
gcc c grammar
Hello, my name is Eduardo Cruz. I am an studen.t of Computer Science at the State University of Maringa, in Brazil. One of our teachers gave us a work in wich we are supposed to modify the c language to support some parallel programming stuff. I want to modify the gcc c frontend to support these features. I thought gcc used bison as a syntax analyser, but when I saw the gcc c-parser source code I realized that it didn't use bison. I read in the gcc mailist that gcc now has a recursive descent parser. Do you have any document that contains the grammar implemented in gcc c-parser? If you have, can you send it? It would be easier to make the proprer changes in the grammar if I have this document, because I won't have to understand the grammar reading the source code. Thank you very much for your atention
Re: GCC C FRONT END EXPLANATION
hey, could you guys explain me something?
in c-parser.c
in c_parser_direct_declarator, when a function name is being parsed, this if:
if (c_parser_next_token_is (parser, CPP_OPEN_PAREN))
is true, and inside this if:
c_parser_consume_token (parser);
attrs = c_parser_attributes (parser);
so it consumes the token "(", and then calls c_parser_attributes to
check the parameters of the function
but in c_parser_attributes this is made in the beggining of the loop:
c_parser_consume_token (parser);
if (!c_parser_require (parser, CPP_OPEN_PAREN, "expected %<(%>"))
{
parser->lex_untranslated_string = false;
return attrs;
}
I don't understand, after the consumed token "(" there will be a
variable type right?
why it consumed the token without checking it?
and why does it require the token "(" ? aren't we inside the function
parameters list?
that's all for a while
thanks
2009/3/20 Dave Korn :
> Guilherme Puglia wrote:
>
>> But thanks to everybody.
>> I'll read the gcc docs in the source code!
>
>
> The C parser starts in gcc/c-parser.c. There are a bunch of lexing routines
> at the top, then you'll see a whole bunch of c_parser_X routines which
> handle the individual grammar constructs. Each one has a commnent at the top
> describing the syntax elements it parses and referring to the paragraph of the
> C standard where they're defined. (If you don't have a copy of the C standard
> handy, google "n1256.pdf"). Good luck!
>
> cheers,
> DaveK
>
>
lookup_name
does the function lookup_name distinguish the identifier between
different contexts?
for example
void func1()
{
int foo;
}
void func2()
{
int foo;
}
if I call lookup_name with the foo ident-tree while parsing these
functions, will it return different decl-tree nodes?
thanks
Re: lookup_name
> I assume you mean the function in the C frontend, in c-decl.c. thats correct! thanks a lot! 2009/4/7 Ian Lance Taylor : > Eduardo Cruz writes: > >> does the function lookup_name distinguish the identifier between >> different contexts? > > I assume you mean the function in the C frontend, in c-decl.c. That > function looks up the name in the current scope, so, yes, it will return > different DECL nodes when appropriate. > > Ian >
Re: [rvskmbr...@gmail.com: Re: Type-in programs using BASH]
> I am proposing this as a possible alternative or complement to publication > on the Internet to take into account those without Internet access, though > those *with* Internet access also get the benefit. So you want to publish stuff on the Internet for people that don't have access to the Internet? Right. This all sounds like a waste of time. Don't type machine code. Also, in the remote case that people will type machine code into their terminal, what does heredocs have to do with that? Bash doesn't understand machine code.
GSoC proposal - LTO incremental linking optimization
Hi! My name is Carlos Barbosa, and I would like to participate in this year's GSoC with GCC. I'm a brazilian undergraduate student and I've been passionate about free software ever since I first heard of it. I'm most interested in OS level programming, language development, optimization and, of course, compiler development. I'm actually only starting to contribute to free software code now, but I have been active in other ways at local FOSS communities for a couple of years now. About the GSoC proposal, the LTO now re-processes everything from scratch, for any changes in the code, no matter how small. So, the project idea is to make it work incrementally, avoiding unnecessary re-processing. In order to do so, I thought about focusing the most at WPA, first verifying and mapping still valid parts of the old ELF code, then building the new optimization_summary with them and with new code. Then, if LTRANS can't determine which files have been modified, this "diff" might be passed in the IPA to it, so only the modified files get re-optimized. During LTRANS, would using an analogous approach, trying to make local optimizations incremental too, be interesting? Do you have any suggestions about how to improve this approach idea? I apologize already if I misunderstood something in the docs and/or didn't make sense at some point. Regards, Carlos Barbosa
GSoC proposal - LTO incremental linking
Hi! My name is Carlos Barbosa, and I would like to participate in this year's GSoC with GCC. I'm a brazilian undergraduate student and I've been passionate about free software ever since I first heard of it. I'm most interested in OS level programming, language development, optimization and, of course, compiler development. I'm actually only starting to contribute to free software code now, but I have been active in other ways at local FOSS communities for a couple of years now. About the GSoC proposal, the LTO now re-processes everything from scratch, for any changes in the code, no matter how small. So, the project idea is to make it work incrementally, avoiding unnecessary re-processing. In order to do so, I thought about focusing the most at WPA, first verifying and mapping still valid parts of the old ELF code, then building the new optimization_summary with them and with new code. Then, if LTRANS can't determine which files have been modified, this "diff" might be passed in the IPA to it, so only the modified files get re-optimized. During LTRANS, would using an analogous approach, trying to make local optimizations incremental too, be interesting? Do you have any suggestions about how to improve this approach idea? I apologize already if I misunderstood something in the docs and/or didn't make sense at some point. Regards, Carlos Barbosa
