GCC 4.1.0 build error (as doesn't like code produced by xgcc)
Hi,
I have an interesting problem with compiling gcc 4.1.0 on
i386-unknown-linux-gnu. Building xgcc (with gcc 3.4.3) works fine.
But rebuilding the compiler with xgcc the 2nd time (with -fprofile-use)
fails with an assembler error:
$ stage1/xgcc -Bstage1/ -B/usr/i386-unknown-linux-gnu/bin/ -c -O2 -g
-fomit-frame-pointer -fprofile-use -freorder-blocks-and-partition -DIN_GCC -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic
-Wno-long-long -Wno-variadic-macros -Wold-style-definition
-Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I../../gcc
-I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include
../../gcc/attribs.c -o attribs.o
/tmp/cc9Aywrx.s: Assembler messages:
/tmp/cc9Aywrx.s:1256: Error: can't resolve `.text.unlikely' {.text.unlikely
section} - `.LCFI70' {.text section}
The assembler code generated by xgcc can be found here:
http://www.clifford.at/priv/gcc410-attribs.s.gz
My assembler is a GNU as, version 2.16.91.0.7 (i.e. HJLs linux binutils).
I've also tried it with the bit older 2.16.91.0.3 and got the same error.
It can be easily reproduced by calling `as' directly on the assembler code:
$ as --traditional-format attribs.s
attribs.s: Assembler messages:
attribs.s:1256: Error: can't resolve `.text.unlikely' {.text.unlikely
section} - `.LCFI70' {.text section}
Is this a known problem? I (better said: google) was unable to find
anything about it.
I also do not really understand the error message. The assembler is trying
to look up a symbol `.text.unlikely' in the .text.unlikely section? Sounds
strange to me and according to the assember code it should try to look up
`.LCFI71' instead. Is this a bug in binutils or gcc? Or am I doing
something wrong?
yours,
- clifford
--
bash -c "gcc -o mysdldemo -Wall -O2 -lSDL -lm -pthread -x c <( echo -e '
#include \n#include \nint main(){SDL_Surface*s;SDL_Event
e;int x,y,n;SDL_Init(SDL_INIT_VIDEO);s=SDL_SetVideoMode(640,480,32,0);for(x=0;
x<640;x++)for(y=0;y<480;y++){float _Complex z=0, c=((x-400)/200.0) + ((y-240)/
200.0)*1.0fi;for(n=1;n<64;n++){z=z*z+c;if(cabsf(z)>2){((Uint32*)s->pixels)[x+y
*640]=n<<3;n=99;}}}SDL_UpdateRect(s,0,0,s->w,s->h);do SDL_WaitEvent(&e); while
(e.type!=SDL_QUIT&&e.type!=SDL_KEYDOWN);SDL_Quit();return 0;}' ); ./mysdldemo"
A: No.
Q: Should I include quotations after my reply?
pgpumZfvmaMsZ.pgp
Description: PGP signature
Re: Qemu and GCC-3.4 on powerpc
On Tue, Mar 28, 2006 at 12:56:13AM +0200, Dieter Schuster wrote:
> Hello,
>
> the version 0.8.0 of qemu in the Debian-pool will not compile on
> PowerPC with GCC 3.4. The following patch will fix it:
And suck performance wise with exploding code size. Without
speaking of potential atomicity issues (although all architectures
using the byte per byte generic code may hit the problem).
>
> --- cpu-all.h~2005-12-19 23:51:53.0 +0100
> +++ cpu-all.h 2006-03-27 22:47:54.291613000 +0200
> @@ -249,15 +249,11 @@
>
> static inline void stl_le_p(void *ptr, int v)
> {
> -#ifdef __powerpc__
> -__asm__ __volatile__ ("stwbrx %1,0,%2" : "=m" (*(uint32_t *)ptr) : "r"
> (v), "r" (ptr));
> -#else
> uint8_t *p = ptr;
> p[0] = v;
> p[1] = v >> 8;
> p[2] = v >> 16;
> p[3] = v >> 24;
> -#endif
> }
>
> static inline void stq_le_p(void *ptr, uint64_t v)
>
>
> If I use GCC 3.3, then qemu compiles with the assembler instruction in
> the patch above, but qemu does not work correctly (tested with Knoppix V5.0).
Interesting, could it be an aliasing problem?
Try to compile with -fno-strict-aliasing, although
I doubt it will change anything.
>
> If I try to compile qemu with GCC 3.4 without the patch I get the following
> error:
>
> qemu-0.8.0/linux-user/elfload.c: In function `load_elf_binary':
> qemu-0.8.0/cpu-all.h:253: error: inconsistent operand constraints in an `asm'
> qemu-0.8.0/cpu-all.h:253: error: inconsistent operand constraints in an `asm'
Weird. CC'ed to gcc list despite the fact that the 3.4 branch
is definitely closed. I've not found anything remotely similar
from bugzilla.
>
> But if I copy the function stl_le_p to a seperate file, the function
> will compile with GCC 3.4.
Which gcc-3.4 (gcc -v)?
>
> Is this a bug in qemu, or is it a bug in GCC 3.4?
It looks like a compiler bug. But you should
provide an environment independent test case,
i.e., the preprocessed source. Please try
also to provide a minimal failing test case
(it may be hard given the symptoms).
Regards,
Gabriel
Re: The GCC Wiki and the AddComment Plug-in
On Tue, 2006-03-28 at 10:22 +0530, Ranjit Mathew wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hello, > > I subscribe to the "RecentEdits" RSS feed of the GCC > Wiki. Of late, there have been a lot of "AddComment Plug-in" > entries in the feed, with no apparent way of finding out which > entry in the Wiki the comment refers to, and many filled > with bogus comments that are links to online casinos and > the like. > > Can we please have a way of telling which entry a > comment refers to or disable the AddComment plug-in > altogether? > > Thanks, I'll disable AddComment. I'm still trying to find time to move us to new wiki software :)
Re: Ada subtypes and base types
On Tue, 2006-03-28 at 01:03 +0200, Duncan Sands wrote:
> Hi Jeff,
>
> On Monday 27 March 2006 21:00, Jeffrey A Law wrote:
> > On Sat, 2006-03-25 at 10:35 -0500, Diego Novillo wrote:
> >
> > > Start by looking at tree-vrp.c:infer_value_range.
> > I'm not so sure this is the best place to start.
>
> it seems a good place for adding ASSERT_EXPRs on function return
> values though.
No. For assignments you really want to discover the range in
visit_assignment.
infer_value_range is really best suited for discovering ranges
that are implicit in the statement. For example, if a statement
dereferences a pointer, then you can infer that the pointer must
not be null. A conditional or switch statement allows you to
infer a value on one or more outgoing edges from the block
containing the conditional/switch.
> I agree, however I don't yet know how to walk the parameter list, so
> any hints would be welcome :)
Search for loops which iterate over DECL_ARGUMENTS. Here's an example
from function.c:
/* Process all parameters of the function. */
for (decl = DECL_ARGUMENTS (fndecl); decl; decl = TREE_CHAIN (decl))
{
instantiate_decl (DECL_RTL (decl));
instantiate_decl (DECL_INCOMING_RTL (decl));
if (DECL_HAS_VALUE_EXPR_P (decl))
{
tree v = DECL_VALUE_EXPR (decl);
walk_tree (&v, instantiate_expr, NULL, NULL);
}
}
But again, I would caution against going down this path without
first determining what we're going to do about the representational
issues we need to resolve. In fact, resolving those issues will
make insertion of ASSERT_EXPRs for the arguments a pointless exercise.
> I agree that this kind of special casing by the middle-end is all
> wrong - the front-end should do it.
I'd disagree. While it may at first seem useful to have ASSERT_EXPRs
live through the entire optimization pipeline, they're actually going
to get in the way of a fair amount of simple optimizations, specifically
copy propagation and the secondary optimizations exposed by
copy propagation.
>
>
> Personally I think the Ada frontend should never pass types with
> a restricted range to the middle-end (in Ada terms, this means
> that the middle-end would only ever see base types).
I certainly do agree with this -- I've been pretty vocal about
that already :-)
> Also, I now think it would be a mistake to initialise all
> variable ranges to [TYPE_MIN, TYPE_MAX]. I implemented this,
> and got great optimisation - a bit too much optimisation in fact!
> For example, you can't test whether a variable is in range using
> the obvious "if" statement anymore, since VRP will eliminate it
> (after all, it "knows" the variable is in range already, because
> it was told so).
Right, but that's exactly what you'd expect and exactly what
other optimizations in GCC already do. And if you've got such
a conditional, then it's clearly useless (which usually means
it's testing the wrong thing).
> Do the Ada people want this level of optimisation? I'm pretty sure
> they don't: I've heard Robert Dewar say that he considers exactly this
> optimisation (eliminating an "if" on an uninitialised variable based
> on the range given in the type definition) to be a bad idea.
There's definitely a corner case with Ada's uninitialized variables
which is unresolved (I didn't follow the discussion closely, so
perhaps they did come up with a solution).
> So that means that initialising variables to [TYPE_MIN,TYPE_MAX]
> is likely not acceptable in general.
No, the problems referenced above are latent bugs that need to
be fixed. They do not argue that initializing to [TYPE_MIN, TYPE_MAX]
is the wrong direction.
What needs to drive the representational solution is the ability to
get the optimizations we want without paying a hefty compile-time
or maintenance penalty.
Jeff
Re: gcc project
On 03/27/06 16:35, Nic Volanschi wrote: > The checks are specified using a new option --tree-check, and are > powerful enough to express user-defined memory leaks, null pointer > dereferences, unreleased locks, etc., but also more basic checks such > as using an unsafe construct. > Oh, excellent. Coincidentally, we have been thinking about developing some kind of plugin/extension framework to allow these classes of analyses. One of the goals is to provide an extensibility mechanism that will not require rebuilding GCC nor adding code that may not be often used. Some of these checks are only interesting in very specific cases, so they may not be something that we want to add to the compiler itself. So, the idea is to have a generic .so plugin mechanism with a relatively stable API that lets you hook into the compilation pipeline and do your analysis/transformation. This would have the double advantage of allowing people to write ad-hoc passes and/or analyses that may not be suitable for the core compiler. It would also allow users to extend GCC without having to get into the source code itself (assuming we get the abstractions and exports right, of course). I have not thought too much about this beyond these obvious generalities. While I believe that we have most of the abstractions that we would want to export (CFG, iterators, operand interface, SSA and IL discovery mechanisms), I am particularly concerned about our ability to maintain a stable enough API across multiple versions of the compiler. We do tend to make lots of arbitrary internal changes that may shatter the API. I'd be very interested in taking a look at what you've done. Perhaps the best approach for you now is to get this code into a branch. We already are in a "no new features" stage for 4.2.
Re: .data and .bss section
On Mar 27, 2006, at 11:39 PM, mohanlal jangir wrote:
Why does gcc put initialized data in .data section and
uninitialized data in bss section? Does it provide any
optimization? Also, normally gcc initializes global data to zero
then what kinds of data go to .bass section? An example would be
appreciated.
This question is off-topic for this list. You want a book on UNIX or
google around, or just try it out and observe the results. The
answers are roughly, optimization, yes, global data that is zero.
int i; in C++ is an example. As to why this is advantageous, try int
i[1]; in C++ and compare to int i[10] = { 1 };. If you
don't see an advantage, add another 0.
Re: CAN_ELIMINATE question
Denis Chertykov <[EMAIL PROTECTED]> writes: > Ian Lance Taylor writes: > > > Denis Chertykov <[EMAIL PROTECTED]> writes: > > > > > > > I think that better to call update_eliminables() somewhere after > > > > > setup_save_areas() > > > > > > > > Exactly. We do that. About 15 lines after the lines you quoted > > > > above. > > > > > > > > What am I missing? > > > > > > I'm (exactly AVR port) need in call to update_eliminables() somewhere > > > between setup_save_areas() and calculate_needs_all_insns() > > > (Not "about 15 lines after" ;) because all bad things happened inside > > > calculate_needs_all_insns(). > > > > > > calculate_needs_all_insns() collect wrong reloads because > > > reg_eliminate structure for FP->SP have wrong can_eliminate field. > > > > But then we go around the loop again, so everything should get > > recalculated based on the new assumptions. Doesn't that happen for > > you? > > If you mean the "continue" here: > if (caller_save_needed) > setup_save_areas (); > > /* If we allocated another stack slot, redo elimination bookkeeping. */ > if (starting_frame_size != get_frame_size ()) > continue; > ---^ > then answer no because only set_initial_elim_offsets() will be called. > set_initial_elim_offsets() doesn't change reg_eliminate[].can_eliminate > flag. > > If you mean a call update_eliminables() after > calculate_needs_all_insns() then answer no (again :) because all wrong > things already happened inside calculate_needs_all_insns() and > compiler will call > select_reload_regs() -> find_reload_regs() -> spill_failure() Can somebody comment the problem, please ? Denis.
incompatible implicit declaration of built-in function 'exit'
I am trying to compile some fairly old legacy c code with gcc 4.1 in FC5 and have been able to eliminate all the compiler warnings save one... warning: incompatible implicit declaration of built-in function 'exit' ...which is repeated through the compilation of the sources. I can google lots of build logs with this warning but haven't been able to get any hits on patches or fixes to eliminate the warning. Thanks in advance for any hints. Jack
Re: incompatible implicit declaration of built-in function 'exit'
On Tuesday 28 March 2006 21:32, Jack Howarth wrote: >I am trying to compile some fairly old legacy c code with gcc 4.1 > in FC5 and have been able to eliminate all the compiler warnings save > one... > > warning: incompatible implicit declaration of built-in function 'exit' > > ...which is repeated through the compilation of the sources. I can > google lots of build logs with this warning but haven't been able > to get any hits on patches or fixes to eliminate the warning. Thanks > in advance for any hints. #include is by far the best solution. If you really must disable the warning without fixing your code try -fno-builtin-exit. Paul
Re: incompatible implicit declaration of built-in function 'exit'
Jack Howarth wrote: I am trying to compile some fairly old legacy c code with gcc 4.1 in FC5 and have been able to eliminate all the compiler warnings save one... warning: incompatible implicit declaration of built-in function 'exit' It should be defined in . Is there a missing #include for that? ...which is repeated through the compilation of the sources. I can google lots of build logs with this warning but haven't been able to get any hits on patches or fixes to eliminate the warning. Thanks in advance for any hints. Jack
Re: incompatible implicit declaration of built-in function 'exit'
Paul, Thanks. I had been trying stdlib.h but didn't realize it had to occur before the other headers like stdio.h. Placing it first solved the problem. Jack
executables in gcc4.0.2
If we do a search of main function in gcc4..0.2/gcc directory, we can find several. I understand collect2.c-->collect2, main.c (wrapper of toplev.c) -->cc1, gcov.c-->gcov. Can someone give a brief introduction what gen*() is ued for? For example, genattr is compiled to destgcc/gcc/build/genattr, but I don't see anything else calls this executable. Thanks, Sean gcc> grep "main (int " *.c collect2.c:main (int argc, char **argv) fix-header.c:main (int argc, char **argv) gcc.c:main (int argc, const char **argv) gcov.c:main (int argc, char **argv) gcov-dump.c:main (int argc ATTRIBUTE_UNUSED, char **argv) gcov-iov.c:main (int argc ATTRIBUTE_UNUSED, char **argv ATTRIBUTE_UNUSED) genattr.c:main (int argc, char **argv) genattrtab.c:main (int argc, char **argv) gencheck.c:main (int argc, char ** ARG_UNUSED (argv)) gencodes.c:main (int argc, char **argv) genconditions.c:main (int argc, char **argv) genconfig.c:main (int argc, char **argv) genconstants.c:main (int argc, char **argv) genemit.c:main (int argc, char **argv) genextract.c:main (int argc, char **argv) genflags.c:main (int argc, char **argv) gengenrtl.c:main (int argc, char **argv) gengtype.c:extern int main (int argc, char **argv); genmddeps.c:main (int argc, char **argv) genopinit.c:main (int argc, char **argv) genoutput.c:main (int argc, char **argv) genpeep.c:main (int argc, char **argv) genpreds.c:main (int argc, char **argv) gen-protos.c:main (int argc ATTRIBUTE_UNUSED, char **argv) genrecog.c:main (int argc, char **argv) main.c:int main (int argc, char **argv); main.c:main (int argc, char **argv) mips-tdump.c:main (int argc, char **argv) mips-tfile.c:main (int argc, char **argv) protoize.c:main (int argc, char **const argv) _ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
warning: initialization makes integer from pointer without a cast
I do have one other issue to resolve in this legacy c code which I
am unclear on. The code uses structures of the form..
struct bound_description {
int type;
WORDdescr;
} bnddescr[] = {
BNDTYP_NULL,"null",
BNDTYP_BOND,"bond",
BNDTYP_ANGLE, "angle",
BNDTYP_FIXED, "fixed",
BNDTYP_DIHED, "dihed",
BNDTYP_CTLIM, "ctlim",
BNDTYP_BOUND, "bound",
BNDTYP_DIST,"dist",
BNDTYP_EXP, "exp",
BNDTYP_OTHER, "other",
BNDTYP_TRIANGLE,"triang",
NULL
};
where the compiler issuing the warning of...
warning: initialization makes integer from pointer without a cast
...for the line with a NULL. My immediate inclination was to
substitute '0' for the NULL which does indeed eliminate the
warning. Is there a more appropriate fix?
Jack
Re: Ada subtypes and base types
Hi Jeff, thanks for the info. > > I agree that this kind of special casing by the middle-end is all > > wrong - the front-end should do it. > I'd disagree. While it may at first seem useful to have ASSERT_EXPRs > live through the entire optimization pipeline, they're actually going > to get in the way of a fair amount of simple optimizations, specifically > copy propagation and the secondary optimizations exposed by > copy propagation. > > > > > > > > Personally I think the Ada frontend should never pass types with > > a restricted range to the middle-end (in Ada terms, this means > > that the middle-end would only ever see base types). > I certainly do agree with this -- I've been pretty vocal about > that already :-) That still leaves the problem of how the Ada front-end tells the middle-end that a variable is known to be in a certain range. Due to the way the language works, the front-end often does know a useful range, helpful for optimisation. If using types with strange ranges is out, and ASSERT_EXPRs aren't appropriate, what is left? After further thought, I'm not so against the use of these ranges as I was... > > So that means that initialising variables to [TYPE_MIN,TYPE_MAX] > > is likely not acceptable in general. > No, the problems referenced above are latent bugs that need to > be fixed. They do not argue that initializing to [TYPE_MIN, TYPE_MAX] > is the wrong direction. You are right. > What needs to drive the representational solution is the ability to > get the optimizations we want without paying a hefty compile-time > or maintenance penalty. I'm playing with the code right now, getting rid of VR_VARYING. Do you have any suggestions for benchmarking it? Ciao, Duncan.
Re: executables in gcc4.0.2
On Mar 28, 2006, at 12:59 PM, sean yang wrote: If we do a search of main function in gcc4..0.2/gcc directory, we can find several. I understand collect2.c-->collect2, main.c (wrapper of toplev.c) -- >cc1, gcov.c-->gcov. Can someone give a brief introduction what gen* () is ued for? For example, genattr is compiled to destgcc/gcc/ build/genattr, but I don't see anything else calls this executable. I'd refer you to the documentation and source code. In general, this list isn't set up for such questions. We kinda expect that you can read a make file and see lines like: insn-attr.h: s-attr ; @true s-attr : $(MD_DEPS) build/genattr$(build_exeext) $(RUN_GEN) build/genattr$(build_exeext) $(md_file) > tmp-attr.h $(SHELL) $(srcdir)/../move-if-change tmp-attr.h insn-attr.h $(STAMP) s-attr and understand what that says and read comments like: /* Generate attribute information (insn-attr.h) from machine description. and get a feel for that the file might do.
Re: warning: initialization makes integer from pointer without a cast
On Mar 28, 2006, at 1:41 PM, Jack Howarth wrote: I do have one other issue to resolve in this legacy c code which I am unclear on. Wrong list. This list is for the development of gcc, not other software. warning: initialization makes integer from pointer without a cast Yup. ...for the line with a NULL. My immediate inclination was to substitute '0' for the NULL which does indeed eliminate the warning. Ick. Is there a more appropriate fix? int i = NULL; should be written as: int i = 0; but, I don't know why that wasn't obvious.
Re: executables in gcc4.0.2
The gen* family of executables is used during the build process to make various .h files from the .md files for the chosen target (and nowhere else AFAIK) sean yang wrote: If we do a search of main function in gcc4..0.2/gcc directory, we can find several. I understand collect2.c-->collect2, main.c (wrapper of toplev.c) -->cc1, gcov.c-->gcov. Can someone give a brief introduction what gen*() is ued for? For example, genattr is compiled to destgcc/gcc/build/genattr, but I don't see anything else calls this executable. Thanks, Sean gcc> grep "main (int " *.c collect2.c:main (int argc, char **argv) fix-header.c:main (int argc, char **argv) gcc.c:main (int argc, const char **argv) gcov.c:main (int argc, char **argv) gcov-dump.c:main (int argc ATTRIBUTE_UNUSED, char **argv) gcov-iov.c:main (int argc ATTRIBUTE_UNUSED, char **argv ATTRIBUTE_UNUSED) genattr.c:main (int argc, char **argv) genattrtab.c:main (int argc, char **argv) gencheck.c:main (int argc, char ** ARG_UNUSED (argv)) gencodes.c:main (int argc, char **argv) genconditions.c:main (int argc, char **argv) genconfig.c:main (int argc, char **argv) genconstants.c:main (int argc, char **argv) genemit.c:main (int argc, char **argv) genextract.c:main (int argc, char **argv) genflags.c:main (int argc, char **argv) gengenrtl.c:main (int argc, char **argv) gengtype.c:extern int main (int argc, char **argv); genmddeps.c:main (int argc, char **argv) genopinit.c:main (int argc, char **argv) genoutput.c:main (int argc, char **argv) genpeep.c:main (int argc, char **argv) genpreds.c:main (int argc, char **argv) gen-protos.c:main (int argc ATTRIBUTE_UNUSED, char **argv) genrecog.c:main (int argc, char **argv) main.c:int main (int argc, char **argv); main.c:main (int argc, char **argv) mips-tdump.c:main (int argc, char **argv) mips-tfile.c:main (int argc, char **argv) protoize.c:main (int argc, char **const argv) _ FREE pop-up blocking with the new MSN Toolbar – get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
how to profile application in between 2 triggers
Hi, I want to profile an application in linux. Now I am using -pg option with gcc for generating the profile data. Then used gprof for getting profiles. In this profiling, it starts from first function (main()) to ending function. Actually I want to profile functions with in 2 events (triggers), which they happen inside the program while execution happening. Is it possible with any open source tools in linux. Jayaraj
Re: how to profile application in between 2 triggers
On Wed, Mar 29, 2006 at 09:35:21AM +0530, jayaraj wrote: > I want to profile an application in linux. Now I am using -pg option > with gcc for generating the profile data. Then used gprof for getting > profiles. In this profiling, it starts from first function (main()) to > ending function. Actually I want to profile functions with in 2 events > (triggers), which they happen inside the program while execution > happening. Is it possible with any open source tools in linux. Sorry, wrong list. This is the development list for the gcc compiler; it is not a "how to program" list.
Re: [RFC] removal of the convert callback
On Mon, 27 Mar 2006, [UTF-8] Rafael Esp??ndola wrote: > I have put toghether a hack to remove the convert callback. It consists in > 1) adding a lang prefix to the implementations of convert (cxx_, c_, >gfc_, etc) > 2) defining a convert2 function that is basically a copy of c_convert > 3) converting the calls to convert to calls to the lang specif >implementations or convert2 I've a number of patches to clean-up the use of "convert" in GCC myself. If you'll give me a week or so to submit/commit them to the tree, it'll make your life much easier. My patches aim to remove all uses of "convert" from libbackend.a (simplifying the interface between the front-end and the middle-end). Once this is done, your task of renaming the functions gets much simpler. The trick is that not all of the "convert" functions behave identically, which is why basing convert2 on c_convert fails for g++, which really needs cp_convert. Instead of a new convert2, the middle-end should be using the existing fold_convert which performs the common language-independent conversions. Finally, I suspect that some front-ends, probably java, fortran and treelang, only define "convert" for use by the middle-end, which means once the middle-end is cleaned up these functions can be removed from their respective front-ends entirely. I hope this makes sense. Sorry for not noticing your post earlier. I tend to read the gcc list less frequently than gcc-patches. Roger --
how to get the field_id for member of structure in gcc front end
Hi all:
for the following statement, how can I get the field_id info for
the structure member
struct{
int a;
int b;
} pair;
int main()
{
int * p = &pair.a;
}
It seems that we can't get the field_id info because of address taken
operator. it treats the "&pair.a" as "&pair + ofset of a".
I am not familiar with the gcc tree. any one know this?
thanks.
tianwei
Re: how to get the field_id for member of structure in gcc front end
I need the field_info to help in alias analysis. for example:
int *p = &pair.a;
int *q = &pair.b;
then if I can set length of "*p" to 4,ofset is '0' . for "*q" to
"8,4". also I know that p definitly points to pair.a and q points to
pair.b, then i can say "*p" and "*q" are not aliased with each other.
thanks.
tianwei
On 3/29/06, Tianwei Sheng <[EMAIL PROTECTED]> wrote:
> Hi all:
>for the following statement, how can I get the field_id info for
> the structure member
> struct{
> int a;
> int b;
> } pair;
> int main()
> {
> int * p = &pair.a;
> }
>
> It seems that we can't get the field_id info because of address taken
> operator. it treats the "&pair.a" as "&pair + ofset of a".
> I am not familiar with the gcc tree. any one know this?
>
> thanks.
>
> tianwei
>
--
Sheng, Tianwei
Inst. of High Performance Computing
Dept. of Computer Sci. & Tech.
Tsinghua Univ.
Re: how to get the field_id for member of structure in gcc front end
On Mar 28, 2006, at 11:03 PM, Tianwei Sheng wrote: I need the field_info to help in alias analysis. for example: int *p = &pair.a; int *q = &pair.b; then if I can set length of "*p" to 4,ofset is '0' . for "*q" to "8,4". also I know that p definitly points to pair.a and q points to pair.b, then i can say "*p" and "*q" are not aliased with each other. My take, a + 0 != a + 8, so they point to different areas. Since you already have the offset information, you already have the information you need. Kinda like &a[4] != &a[5], even though the type is the same.
