Re: gcc on IA64 platform
Hello, Tadas V wrote: I am a computer science student and currently I am preparing my master degree final work on "Compiler optimization on IA64 platforms". So could you provide some information to me what is the the current situation with gcc and IA64 platfrom - I mean what are open optimization issues and so on. After googling a while I found this document http://gcc.gnu.org/projects/ia64.html and I would like to know if this information is up-to-date. Looking forward to hearing from you. Thank you in advance. As you can see from the above page, it comes from the 2001 mini summit, so most of the projects mentioned there are already done. Moreover, GCC infrastructure has been dramatically improved since then. The current state can be summarized as follows: o Alias analysis improvements mentioned on the page are done long ago. There are two unfinished IA-64 inspired patches concerning alias analysis: improvements of Sanjiv Gupta's patch tracking base+offset calculations on RTL done by Alexander Monakov, which we didn't manage to submit (see http://gcc.gnu.org/ml/gcc/2007-03/msg00148.html), and the patch propagating alias information from Tree SSA to RTL, which produced too few disambiguations and should be improved by Alexander Monakov during this year's Google Summer of Code. o Data prefetching is now reimplemented on trees instead of RTL. There was a project by Canqun Yang on tuning the old RTL data prefetching for IA-64, but AFAIK it was never ported to the new implementation. o DFA scheduler was implemented by Vladimir Makarov and checked in long ago. Bundling is now performed using DFA too, see bundling () in config/ia64/ia64.c. o Profile-directed block ordering and inlining is already supported AFAIK. o Control and data speculation are supported since GCC 4.2 as a result of a project of ISP RAS. The implementation was done by Maxim Kuvyrkov. o Extended basic block scheduling is implemented and works as a second scheduling pass on IA-64. Superblock formation was also implemented on RTL and fairly recently moved to Tree SSA by Robert Kidd. There is also a treegion scheduling patch on the treegion branch, but it was never committed to mainline. o Modulo scheduling is implemented by IBM Haifa team. It started working on IA-64 since GCC 4.3 after some small bugfixes (sorry I didn't mention that in changes.html). Also, there is a patch that does propagation of data dependency information to RTL done by Alexander Monakov. It wasn't committed because there was a stage3 at that time, and I think it will be unified with the analogous aliasing patch mentioned above. o We (ISP RAS) are currently preparing selective scheduling implementation, also inspired by IA64, for merge with mainline. The actual code is in sel-sched-branch in the SVN repository. o Rotating registers are not yet supported. o Link time optimizations (LTO) is an ongoing work, you can take a look at LTO branch. Also, there was a meeting of Gelato GCC group in 2006, and some information can be found in the minutes at http://gcc.gelato.org/MeetingNotes. You can also search mailing list archives for similar discussions happened in the past. Hope this helps, Andrey
Re: gmon.out creation procedure
Dear Shafi Thanks you very much for the clear details. Definitely your inputs are helpful. 1) I am sure that in gcc-4.0 I found there is file gmon.c in the path gcc-4.0.0/gcc/gmon.c. Anyhow let me concentrate on gmon.c of glibc. 2) Next thing I would like to know is to better understand the gmon.c of glibc I would like to degug glibc. since glibc is linked with gcc, I built gcc and glibc separately. while debugging gcc is referring shared glib library, but not the one I built freshly for debugging purpose. To make this happen, where I need to change the path to like both gcc and glibc ? 3) Please correct me If I am wrong a. for every function mcount() function is called to collect the caller and callee address. where this collected info is placed ? b. the flow of monstartup() function monstartup()-->moncontrol() --> profil() who will call the monstartup() ? is it gcrt0 ? before calling the main() function of our routine ? c. write_profiling() ---> write_gmon() functions calls write_hist(), write_call_graph() and write_bb_counts(). here who calls the write_profiling() ? d. mcleanup() calls write_gmon(). who calls the mcleanup() ? is it gcrt0 ? after control return from main() function ? Thanks and Regards Raja > 2008/5/19 <[EMAIL PROTECTED]>: >> Hi, >> >> I am Raja, I need a favor on understand how the gmon.out file is >> created. >> Please help me. >> >> 1. gmon.c is available in both gcc and glibc. Which is the one used to >> create gmon.out ? > > I don't think gcc has gmon.c. Only glibc has it. You can also find > gmon in newlib for some targets. But this will be customized for the > target > >> >> 2. Can you brief how profile information required to create gmon.out is >> captured?���"B"BWhich are the functions are responsible for this ? > > These days gmon.c is used only to get histogram records(time related > infomation). All the other information is now produced by gcc itself, > than can be analyzed using gcov. (You will get gcov when you build > gcc). > For histogram records, gmon.c code primarily uses 'profil' system > call. You can get more information about this in man pages. And of > course you will get to know how this is used if you go through the > code in gmon.c > > When -pg switch is enabled all complier does is inserting a call to > the function mcount, usually after the function prologue. This is the > function the collects all the needed information. For profiling > information about caller address and callee address is necessary. If > this information cannot be obtained using __bultin_return_address then > this is calculated by mcount in a target specific manner and passed > onto another function that takes these address as the arguments and > gathers the profiling information. > >> >> 3. Suppose assume that executable is built without ��Cpg option, but >> want >> to create gmon.out at run-time. Is there any way or guidelines to >> implement? > > A call to the profiling function (mcount) should be there to generate > profiling information. Without that you won't be able to generate > gmon.out > > Hope this helps, > > Regards, > Shafi > >> >> Thanks and Regards >> Raja Saleru >> >> >
Re: Whats going on with the conversion warning?
2008/5/20 Andy H <[EMAIL PROTECTED]>:
>
> I came across this odd issue with testsuite test Wconversion-5.c and AVR
> target.
> I should get warning going from a unsigned value that is wider than signed
> result.
>
Yes. You should also get a warning from a unsigned value converted to
a same-width signed type.
> void foo(void)
> {
> signed char sc;
> signed char xi;
>
> xi = (int) (unsigned short int) sc;/* testcase NO WARNING - think this
> is bug*/
I may be wrong but I think (unsigned short int) sc is zero-extended,
then (int)(unsigned short int) sc is again zero extended. This means
that the complete conversion results in an integer value that when
converted to signed char gives back the original signed char. So the
assignment is actually equivalent to xi = sc. Ergo, no conversion
warning.
> xi = (unsigned short int) sc; /* NO WARNING - think this is bug*/
The same applies here. Zero-extending to a wider type and then
conversion to the original type does not change the value. So now
warning. (That is, Wconversion can see whether the casts actually
affect the result or not.)
So I think this is not a bug. There are bugs in Wconversion, nonetheless.
http://gcc.gnu.org/PR35635
http://gcc.gnu.org/PR35701
http://gcc.gnu.org/PR34389
http://gcc.gnu.org/PR35852
Cheers,
Manuel.
Re: GCC Compile Farm News: two new bi-quad core machines available
On Mon, May 19, 2008 at 8:50 PM, Laurent GUERBY <[EMAIL PROTECTED]> wrote: > Hi, > > The GCC Compile Farm project is pleased to announce that two bi-quad > core machines with the latest Opteron 8354 "Barcelona B3" processor and > 16GB of RAM donated by AMD are now available online in datacenter space > kindly donated by INRIA Saclay. > > All in all, gcc11 to gcc17 provide 38 64-bits cores to GCC and Free > Software developpers including 3 octo-core machines with GCC trunk > bootstrap times for all languages including Ada in the 20 minutes range. > > Procedure to apply for an account on the GCC Compile Farm is available > here: > > http://gcc.gnu.org/wiki/CompileFarm > > Feel free to pass the word to other free software projects as well, > there are currently 39 accounts on the farm. > > Many thanks to the following people and organisation who made > this setup possible: > > - Sebastian Pop and Christophe Harle of AMD for donating the two > machines > > - Albert Cohen, Sylvain Girbal and Philippe Lubrano of INRIA Saclay > for donating hosting and setup help > > - Loic Dachary and Eva Mathieu of FSF France for handling orders of > various equipment including an UPS. > > Sincerely, Isn't this worth an entry on the GCC news page? Richard.
Re: GCC 4.3.1 Status Report (2008-05-19)
On Mon, 19 May 2008, Uros Bizjak wrote: > Hello! > > > GCC 4.3.1 is still not ready for release as the x86 direction flag > > issue (36079) needs to be resolved. We have reached consensus to > > add a new flag -mcld to allow to work around the kernel bug and to > > add a configure option to enable/disable this by default. > > > > The patch from Uros is implementing the -mcld parts but lacks the > > configure option part for which no patch exists yet. > > > > http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00417.html > > > > The plan is to create a release candidate for 4.3.1 once the direction > > flag issue is resolved and 4.2.4 was released. I will announce a > > freeze of the 4.3 branch once the release process starts. > > > > IIRC, the final word was that the impact of this issue is not high enough to > warrant adding a separate flag [1] ? > > [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36079 It turns out to be more a political and marketing issue than a technical issue, so it was decided that we should provide -mcld and a configure option. Richard.
Re: gcc on IA64 platform
On Tue, 20 May 2008, Andrey Belevantsev wrote: > As you can see from the above page, it comes from the 2001 mini summit, > so most of the projects mentioned there are already done. Any chance you could make a pass through that page and remove those items that you know have already been done, or separate those that are still open and those that have been done into two different sections? And thanks for the summary mail, the list of changes certainly looks quite impressive. :-) Gerald
Uninitialized data on Darwin/MacOS (gcc 4.3)
I noticed that GCC 4.3 seems to put unitialized data like predefined one into the data segment, leading to unnecessarily huge object files and binaries. The GCC 4.01 bundled with MacOS 10.5 seems to handle it in a better way. GCC 4.3 stores uninitialized data as "(__DATA,__data) external", while 4.01 uses "(__DATA,__common) external". Using "-fconserve-space" seems to be the only workaround for GCC 4.3 on Darwin at the moment (storing as "(common) (alignment 2^5) external"). I'm more used to the ELF format, but from what I've found on the web the Mach-0 file format should be well able of defining BSS type data. Is there a configuration switch or compiler flag I overlooked? Should this behavior be regarded as a bug and be reported? Regards, Markus
Re: gcc on IA64 platform
Gerald Pfeifer wrote: Any chance you could make a pass through that page and remove those items that you know have already been done, or separate those that are still open and those that have been done into two different sections? Sure, I would make a note to do this somewhere during stage2. Andrey
Re: [RFC] Adjust output for strings in tree-pretty-print.c
> To me too, but I still maintain that it's better to print in UTF-8 (which > would make the langhook more useful). The recent Unicode patches for C > possibly could use the langhook too. OK, I need to focus on making progress and fix the current behaviour, which is broken for gfortran (ie doesn't allow us to use tree dumps at all). So, if people want to deal with Unicode tree dumps, that's fine (though, as a matter of taste, I'd still prefer having the bit pattern), but that's not the object of this patch. To deal with the difference in behaviour between the C family and Fortran, a langhook function is a bit overkill (it needs a callback function which in turns calls pp_character to actually display things, in order to be generic and usable in various parts of the middle-end), I just added a flag (null_terminated_strings): it defaults to true, but Fortran sets it to false. Depending on this value, tree-pretty-print.c will behave the right way. I attach the preliminary patch here, to know if it's OK to go ahead. If so, I'll add documentation and submit for proper review. Also, I'd like to know if it's deemed suitable to use that flag in tree-dump.c (look for TREE_STRING_POINTER in that file). Currently, calling debug_tree() on a STRING_CST will display null characters, like "This is a string.\0", which is apparently unsuitable for C. So, should I use the new flag here also? > But for testing you want a standardized endianness. Otherwise some targets > will need to scan "I\0\0\0" and others will need to scan "\0\0\0I". That's debatable. I prefer being able to see the byte sequence in the tree dumps to make sure it's as expected. FX -- FX Coudert http://www.homepages.ucl.ac.uk/~uccafco/
Build broken on gcc-4.3 branch?
Hello! Does anybody else see build failure on 4_3 branch? My build from a clean dir (./configure --with-mpfr=/usr/local) dies with gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc-svn/branches/gcc-4_3-branch/gcc -I../../gcc-svn/branches/gcc-4_3-branch/gcc/build -I../../gcc-svn/branches/gcc-4_3-branch/gcc/../include -I../../gcc-svn/branches/gcc-4_3-branch/gcc/../libcpp/include -I/usr/local/include -I../../gcc-svn/branches/gcc-4_3-branch/gcc/../libdecnumber -I../../gcc-svn/branches/gcc-4_3-branch/gcc/../libdecnumber/bid -I../libdecnumber-o build/errors.o ../../gcc-svn/branches/gcc-4_3-branch/gcc/errors.c build/genmodes -h > tmp-modes.h /bin/sh: build/genmodes: No such file or directory gmake[3]: *** [s-modes-h] Error 127 Uros.
Re: Build broken on gcc-4.3 branch?
On Tue, May 20, 2008 at 3:57 PM, Uros Bizjak <[EMAIL PROTECTED]> wrote: > Hello! > > Does anybody else see build failure on 4_3 branch? My build from a > clean dir (./configure --with-mpfr=/usr/local) dies with > > gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall > -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes > -Wold-style-definition -Wmissing-format-attribute -pedantic > -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings > -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild > -I../../gcc-svn/branches/gcc-4_3-branch/gcc > -I../../gcc-svn/branches/gcc-4_3-branch/gcc/build > -I../../gcc-svn/branches/gcc-4_3-branch/gcc/../include > -I../../gcc-svn/branches/gcc-4_3-branch/gcc/../libcpp/include > -I/usr/local/include > -I../../gcc-svn/branches/gcc-4_3-branch/gcc/../libdecnumber > -I../../gcc-svn/branches/gcc-4_3-branch/gcc/../libdecnumber/bid > -I../libdecnumber-o build/errors.o > ../../gcc-svn/branches/gcc-4_3-branch/gcc/errors.c > build/genmodes -h > tmp-modes.h > /bin/sh: build/genmodes: No such file or directory > gmake[3]: *** [s-modes-h] Error 127 It works for me. Maybe you have a too high -j and some dependencies are missing? What make version do you use? I use make-3.81. Richard.
Re: Build broken on gcc-4.3 branch?
On Tue, May 20, 2008 at 4:52 PM, Richard Guenther <[EMAIL PROTECTED]> wrote: >> Does anybody else see build failure on 4_3 branch? My build from a >> clean dir (./configure --with-mpfr=/usr/local) dies with > It works for me. Maybe you have a too high -j and some dependencies > are missing? What make version do you use? I use make-3.81. No, just "-j 2" with make 3.80. I'll investigate this a bit more, as it is obviously problem at my site. Thanks, Uros.
How to legitimize the reload address?
Hello all, For the 16 bit target that i am currently porting can have only positive offsets less than 0x100. (unsigned 8 bit) for offset addressing mode. During reload i am getting ICE because the address created is not legitimate. So i guess i have to define the macro LEGITIMIZE_RELOAD_ADDRESS. But i am not sure how to do this? With this will i be able to convert load Rd, Rb[offset] into li Rs, offset add Rs,Rb load Rd, Rs where Rs is a reserved register. Or the only way is to do this like the other targets say in rs6000 >From rs6000_legitimize_reload_address() /* Reload the high part into a base reg; leave the low part in the mem directly. */ x = gen_rtx_PLUS (GET_MODE (x), gen_rtx_PLUS (GET_MODE (x), XEXP (x, 0), GEN_INT (high)), GEN_INT (low)); push_reload (XEXP (x, 0), NULL_RTX, &XEXP (x, 0), NULL, BASE_REG_CLASS, GET_MODE (x), VOIDmode, 0, 0, opnum, (enum reload_type)type); *win = 1; return x; I guess this will generate something like add Rs, Rb, excess_offset load Rd, Rs[legitimate_offset]; Regards, Shafi
Re: How to legitimize the reload address?
"Mohamed Shafi" <[EMAIL PROTECTED]> writes: > For the 16 bit target that i am currently porting can have only > positive offsets less than 0x100. (unsigned 8 bit) for offset > addressing mode. I would expect reload to be able to handle this kind of thing anyhow, assuming you define GO_IF_LEGITIMATE_ADDRESS correctly. reload should automatically try loading an out of range offset into a register. Ian
Re: How to legitimize the reload address?
2008/5/20 Ian Lance Taylor <[EMAIL PROTECTED]>: > "Mohamed Shafi" <[EMAIL PROTECTED]> writes: > >> For the 16 bit target that i am currently porting can have only >> positive offsets less than 0x100. (unsigned 8 bit) for offset >> addressing mode. > > I would expect reload to be able to handle this kind of thing anyhow, > assuming you define GO_IF_LEGITIMATE_ADDRESS correctly. reload should > automatically try loading an out of range offset into a register. No. Reload can't do it in any cases. Reload can do it in many cases but not in all. Mohamed look to: - avr/avr.h: LEGITIMIZE_RELOAD_ADDRESS - avr/avr.md: *movqi - avr/avr.c: out_movqi_mr_r Here I have emulated infinite displacement. Bad things happened while many reloads occurs on insn with big displacement (0xff,0xfe). Also, while reload generate local variable (spill to stack slot) and you have an insn with address like [SP+0xff]. Denis.
Re: How to legitimize the reload address?
Ian Lance Taylor wrote: "Mohamed Shafi" <[EMAIL PROTECTED]> writes: For the 16 bit target that i am currently porting can have only positive offsets less than 0x100. (unsigned 8 bit) for offset addressing mode. I would expect reload to be able to handle this kind of thing anyhow, assuming you define GO_IF_LEGITIMATE_ADDRESS correctly. reload should automatically try loading an out of range offset into a register. Agreed. Typically if there are problems in this area it is because the port hasn't properly defined secondary reloads, or the valid offsets are not consistent within a machine mode. Mohamed, without more details, there's not much we can do to help you. Jeff
Re: splitting const_int's
Richard Sandiford wrote:
> Also, you need to beware of cases in which operands[1] overlaps
> operands[0]. The splitter says:
>
> [(set (match_dup 2) (match_dup 4))
> (set (match_dup 3) (match_dup 5))]
>
> and operands[2] is always the highpart:
>
>operands[2] = gen_highpart(QImode, operands[0]);
>
> but consider the case in which operands[1] (and thus operands[4])
> is a memory reference that uses the high part of operands[0] as
> a base register. In that case, the base register will be modified
> by the first split instruction and have the wrong value in the
> second split instruction. See other ports for the canonical way
> of handling this.
>
> Richard
By looking at other ports, I learned that I can detect when this happens
by using the reg_overlap_mentioned_p(). Here is one case:
(insn 43 115 74 (set (reg:HI 7 %i0h)
(mem/s/j:HI (plus:HI (reg/f:HI 7 %i0h [orig:39 source ] [39])
(const_int 2 [0x2])) [0 .r+0 S2 A8])) 3
{*movhi} (nil)
(nil))
I need to tell the compiler not to use as destination the same base
register when doing index operations. Any suggestions on how do I that?
Thanks for your help.
-Omar
Re: splitting const_int's
On Tue, May 20, 2008 at 2:30 PM, Omar Torres <[EMAIL PROTECTED]> wrote:
> By looking at other ports, I learned that I can detect when this happens
> by using the reg_overlap_mentioned_p(). Here is one case:
> (insn 43 115 74 (set (reg:HI 7 %i0h)
> (mem/s/j:HI (plus:HI (reg/f:HI 7 %i0h [orig:39 source ] [39])
> (const_int 2 [0x2])) [0 .r+0 S2 A8])) 3
> {*movhi} (nil)
> (nil))
>
> I need to tell the compiler not to use as destination the same base
> register when doing index operations. Any suggestions on how do I that?
Early clobber, that is using "=&r" as the constraint. Though may I
suggest that you split before reload/ra.
-- Pinski
Re: splitting const_int's
On Tuesday 20 May 2008, Andrew Pinski wrote:
> On Tue, May 20, 2008 at 2:30 PM, Omar Torres <[EMAIL PROTECTED]> wrote:
> > By looking at other ports, I learned that I can detect when this happens
> > by using the reg_overlap_mentioned_p(). Here is one case:
> > (insn 43 115 74 (set (reg:HI 7 %i0h)
> > (mem/s/j:HI (plus:HI (reg/f:HI 7 %i0h [orig:39 source ] [39])
> > (const_int 2 [0x2])) [0 .r+0 S2 A8])) 3
> > {*movhi} (nil)
> > (nil))
> >
> > I need to tell the compiler not to use as destination the same base
> > register when doing index operations. Any suggestions on how do I that?
>
> Early clobber, that is using "=&r" as the constraint.
Does this work reliably for straight mov patterns and during reload? Sounds
like in the general case it would need secondary reloads, which is a whole
lot of extra magic.
I remember having similar problems with ARM doubleword loads and ended up
having to hack round the restriction in the asm output routines, and outlaw
some of the more problematic problematic autoincrement modes.
Paul
Re: splitting const_int's
On Tue, May 20, 2008 at 2:47 PM, Paul Brook <[EMAIL PROTECTED]> wrote: > Does this work reliably for straight mov patterns and during reload? Sounds > like in the general case it would need secondary reloads, which is a whole > lot of extra magic. Hmm, right. Maybe something like what rs6000 does: ; List r->r after r->"o<>", otherwise reload will try to reload a ; non-offsettable address by using r->r which won't make progress. (define_insn "*movdi_internal32" [(set (match_operand:DI 0 "nonimmediate_operand" "=o<>,r,r,*f,*f,m,r") (match_operand:DI 1 "input_operand" "r,r,m,f,m,f,IJKnGHF"))] And then in the split it does: /* Move register range backwards, if we might have destructive overlap. */ in rs6000_split_multireg_move. -- Pinski
Re: Whats going on with the conversion warning?
Thanks for explanation and help
But this leave me with the conclusion that one of the following must be
wrong:
signed char xi;
xi = (int) (unsigned short int) sc;/* testcase NO WARNING - think
this is bug*/
xi = (long) (unsigned short int) sc;/* warning: conversion to
'signed char' from 'short unsigned int' may alter its value - correct*/
Following your logic, (long) appears to be wrong. Yet for i686 the
first case (int). generates PASS with expected warning and that
would seem similar.
So I'm still completely stuck knowing how I can patch testcase
correctly for AVR or post a bug.
best regards
Andy
Manuel López-Ibáñez wrote:
2008/5/20 Andy H <[EMAIL PROTECTED]>:
I came across this odd issue with testsuite test Wconversion-5.c and AVR
target.
I should get warning going from a unsigned value that is wider than signed
result.
Yes. You should also get a warning from a unsigned value converted to
a same-width signed type.
void foo(void)
{
signed char sc;
signed char xi;
xi = (int) (unsigned short int) sc;/* testcase NO WARNING - think this
is bug*/
I may be wrong but I think (unsigned short int) sc is zero-extended,
then (int)(unsigned short int) sc is again zero extended. This means
that the complete conversion results in an integer value that when
converted to signed char gives back the original signed char. So the
assignment is actually equivalent to xi = sc. Ergo, no conversion
warning.
xi = (unsigned short int) sc; /* NO WARNING - think this is bug*/
The same applies here. Zero-extending to a wider type and then
conversion to the original type does not change the value. So now
warning. (That is, Wconversion can see whether the casts actually
affect the result or not.)
So I think this is not a bug. There are bugs in Wconversion, nonetheless.
http://gcc.gnu.org/PR35635
http://gcc.gnu.org/PR35701
http://gcc.gnu.org/PR34389
http://gcc.gnu.org/PR35852
Cheers,
Manuel.
Re: Whats going on with the conversion warning?
2008/5/21 Andy H <[EMAIL PROTECTED]>: > Thanks for explanation and help > > But this leave me with the conclusion that one of the following must be > wrong: > > signed char xi; > > xi = (int) (unsigned short int) sc;/* testcase NO WARNING - think this > is bug*/ > xi = (long) (unsigned short int) sc;/* warning: conversion to 'signed > char' from 'short unsigned int' may alter its value - correct*/ > > Following your logic, (long) appears to be wrong. Yet for i686 the first > case (int). generates PASS with expected warning and that would seem > similar. My logic may be wrong. There may be something I am missing here. Although I tried all possible values of signed char and both sc and xi appear to end up with the same value (no matter whether you use int or long, since by the text of the warning, it seems it is dropped anyway). I would call it a bug, perhaps it is one of the bugs I mentioned before. To know what is really going on you would have to step in c-common.c (conversion_warning) and see why the cast is not dropped. Perhaps get_unwidened() is not the function that should be used there. Perhaps we should use get_narrower() somehow. Or perhaps the whole expression has been transformed and folded into something different before it reaches that point. I am sorry but I don't have time to look deeply into this. Please, open a bug report and add a testcase (better if it can be tested in i686). I hope somebody else can take a look at it. Thanks, Manuel.
Re: gmon.out creation procedure
On Tue, May 20, 2008 at 1:54 PM, <[EMAIL PROTECTED]> wrote: > Dear Shafi > > Thanks you very much for the clear details. Definitely your inputs are > helpful. > > 1) I am sure that in gcc-4.0 I found there is file gmon.c in the path > gcc-4.0.0/gcc/gmon.c. Anyhow let me concentrate on gmon.c of glibc. > I am not sure why this is found in gcc. It is not available in other versions. > 2) Next thing I would like to know is to better understand the gmon.c of > glibc I would like to degug glibc. since glibc is linked with gcc, I built > gcc and glibc separately. while debugging gcc is referring shared glib > library, but not the one I built freshly for debugging purpose. To make > this happen, where I need to change the path to like both gcc and glibc ? IIRC by passing -static to linker you can link with the static glibc. To make sure that your glibc is picked up maybe you can hide the other glibc from the PATH variable. > > 3) Please correct me If I am wrong > a. for every function mcount() function is called to collect the caller > and callee address. where this collected info is placed ? > b. the flow of monstartup() function >monstartup()-->moncontrol() --> profil() > > who will call the monstartup() ? is it gcrt0 ? before calling the > main() function of our routine ? Thats right. Thats the other thing that happen when -pg option is provided. A different startup files is used. This will have a call to the monstartup. monstartup will initialize all the data structures required for collecting profile data and invokes profil system call. > > c. write_profiling() ---> write_gmon() functions calls write_hist(), > write_call_graph() and write_bb_counts(). here who calls the > write_profiling() ? > > d. mcleanup() calls write_gmon(). who calls the mcleanup() ? is it > gcrt0 ? after control return from main() function ? IIRC it is mcleanup that calls the output function write_gmon, which in turn calls the other functions. mcleanup will be called from the startup file after main returns. mcleanup dumps all the information in the output file. Hope this helps. Regards, Shafi > > Thanks and Regards > Raja > > > > > > > > >> 2008/5/19 <[EMAIL PROTECTED]>: >>> Hi, >>> >>> I am Raja, I need a favor on understand how the gmon.out file is >>> created. >>> Please help me. >>> >>> 1. gmon.c is available in both gcc and glibc. Which is the one used to >>> create gmon.out ? >> >> I don't think gcc has gmon.c. Only glibc has it. You can also find >> gmon in newlib for some targets. But this will be customized for the >> target >> >>> >>> 2. Can you brief how profile information required to create gmon.out is >>> captured?���"B"BWhich are the functions are > responsible for this ? >> >> These days gmon.c is used only to get histogram records(time related >> infomation). All the other information is now produced by gcc itself, >> than can be analyzed using gcov. (You will get gcov when you build >> gcc). >> For histogram records, gmon.c code primarily uses 'profil' system >> call. You can get more information about this in man pages. And of >> course you will get to know how this is used if you go through the >> code in gmon.c >> >> When -pg switch is enabled all complier does is inserting a call to >> the function mcount, usually after the function prologue. This is the >> function the collects all the needed information. For profiling >> information about caller address and callee address is necessary. If >> this information cannot be obtained using __bultin_return_address then >> this is calculated by mcount in a target specific manner and passed >> onto another function that takes these address as the arguments and >> gathers the profiling information. >> >>> >>> 3. Suppose assume that executable is built without ��Cpg > option, but >>> want >>> to create gmon.out at run-time. Is there any way or guidelines to >>> implement? >> >> A call to the profiling function (mcount) should be there to generate >> profiling information. Without that you won't be able to generate >> gmon.out >> >> Hope this helps, >> >> Regards, >> Shafi >> >>> >>> Thanks and Regards >>> Raja Saleru >>> >>> >> > >
