Re: how to get the field_id for member of structure in gcc front end
but it's my be too aggressive. as you said, you mean "base,ofst" rule is enough, a more safe method is "base,ofst, lenght" rule. p still can point to pair.b if p is update by assignment or other ways. we should ensure *p will never exceed the length, otherwilse it will fail to do alias analysis. our compiler will use "base,ofst,lenght" rule for every indirect memop to do alias analysis. now we can only set the lenght to the size of structure. for example, int *p = &pair.a int *q = &pair.a;; p = p+1; *p = 1; *q = 2; (*p) and (*q) are not aliased because of p = p +1; now p points to pair.b. any way, I will think over your "base,ofst" rule. tianwei On 3/29/06, Mike Stump <[EMAIL PROTECTED]> wrote: > 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. >
Lot's of ICEs with Polyhedron and -ftree-vectorize with mainline
Has anyone gone through Polyhedron ICEs with -ftree-vectorize? I see aermod, air, doduc, linpk, mdbx, rnflow and test_fpu ICE on i686 and additionally induct and tfft on x86_64. (-O3 -ffast-math -funroll-loops otherwise) Richard.
Re: how to get the field_id for member of structure in gcc front end
On Mar 29, 2006, at 12:15 AM, Tianwei Sheng wrote: but it's my be too aggressive. as you said, you mean "base,ofst" rule is enough, a more safe method is "base,ofst, lenght" rule. Right. I didn't mean to exclude length, just that I didn't expound on the idea, as I wanted to get the simple concept across; there are any small details that have to be perfect for it to work, length is but one of them. int *p = &pair.a int *q = &pair.a;; p = p+1; *p = 1; *q = 2; (*p) and (*q) are not aliased because of p = p +1; now p points to pair.b. Right. a + 0 != a + 0 + 8 (or so) I just didn't want you to do: &pair.a + 1 != &pair.b because .a != .b because the `names' don't match. By comparing the offset, we `know' that the bytes in positions 0-3 can't be the same as the bytes if positions 4-7, it just isn't possible.
SH: Should libgcc_s.so not be actually linker script ?
Hi, For sh4-unknown-linux target, libgcc_s.so is not symbolic link but linker script that is GROUP ( libgcc_s.so.1 libgcc.a ) I hear this is because some functions are not included in libgcc_s.so.1 and they are only in libgcc.a. But now, "gcc -v -o hello hello.c" gives following output on linking phase. /usr/libexec/gcc/sh4-unknown-linux/4.1.0/collect2 --eh-frame-hdr -m shlelf_linux -dynamic-linker /lib/ld-linux.so.2 -o hello /usr/lib/gcc/sh4-unknown-linux/4.1.0/../../../crt1.o /usr/lib/gcc/sh4-unknown-linux/4.1.0/../../../crti.o /usr/lib/gcc/sh4-unknown-linux/4.1.0/crtbegin.o -L/usr/lib/gcc/sh4-unknown-linux/4.1.0 -L/usr/lib/gcc/sh4-unknown-linux/4.1.0 -L/usr/lib/gcc/sh4-unknown-linux/4.1.0/../../.. /tmp/ccer52C9.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/sh4-unknown-linux/4.1.0/crtend.o /usr/lib/gcc/sh4-unknown-linux/4.1.0/../../../crtn.o It seems that libgcc.a is linked automatically, so it would be work if libgcc_s.so is a symbolic link to libgcc_s.so.1. If libgcc_s.so were symbolic link, unneeded dependency on libgcc_s.so.1 would not be written to the executable. ( '--as-needed' seems not work for linker script ) SUGIOKA Toshinobu
Re: SH: Should libgcc_s.so not be actually linker script ?
SUGIOKA Toshinobu <[EMAIL PROTECTED]> wrote: > But now, "gcc -v -o hello hello.c" gives following output on linking phase. > > /usr/libexec/gcc/sh4-unknown-linux/4.1.0/collect2 --eh-frame-hdr -m > shlelf_linux -dynamic-linker /lib/ld-linux.so.2 -o hello > /usr/lib/gcc/sh4-unknown-linux/4.1.0/../../../crt1.o > /usr/lib/gcc/sh4-unknown-linux/4.1.0/../../../crti.o > /usr/lib/gcc/sh4-unknown-linux/4.1.0/crtbegin.o > -L/usr/lib/gcc/sh4-unknown-linux/4.1.0 -L/usr/lib/gcc/sh4-unknown-linux/4.1.0 > -L/usr/lib/gcc/sh4-unknown-linux/4.1.0/../../.. /tmp/ccer52C9.o -lgcc > --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s > --no-as-needed /usr/lib/gcc/sh4-unknown-linux/4.1.0/crtend.o > /usr/lib/gcc/sh4-unknown-linux/4.1.0/../../../crtn.o > > It seems that libgcc.a is linked automatically, so it would be work if > libgcc_s.so is a symbolic link to libgcc_s.so.1. > > If libgcc_s.so were symbolic link, unneeded dependency on libgcc_s.so.1 would > not be written to the executable. > ( '--as-needed' seems not work for linker script ) Thanks for pointing it out. Could you propose the patch for it on trunk to gcc-patches? Regards, kaz
Re: GCC 4.1.0 build error (as doesn't like code produced by xgcc)
On Tue, Mar 28, 2006 at 03:10:30PM +0200, Clifford Wolf wrote:
> /tmp/cc9Aywrx.s: Assembler messages:
> /tmp/cc9Aywrx.s:1256: Error: can't resolve `.text.unlikely' {.text.unlikely
> section} - `.LCFI70' {.text section}
The assembly is wrong. File a GCC bug. Two subtracted symbols should
generally be in the same section.
> 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?
It's just a quirk of the error message. The relocation has been made
relative to the section symbol, which has the same name as the
containing section.
--
Daniel Jacobowitz
CodeSourcery
Re: how to get the field_id for member of structure in gcc front end
On Wed, 2006-03-29 at 15:03 +0800, 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. We already do this in 4.2 see access_can_touch_variable and overlap_subvar in tree-ssa-operands.c. Also, since 4.1, the pointer analysis at the tree level is field sensitive, so knows these things. See tree-ssa-structalias.c
Does --as-needed work for linker script ?
On Wed, Mar 29, 2006 at 10:18:31PM +0900, SUGIOKA Toshinobu wrote: > Hi, > > For sh4-unknown-linux target, libgcc_s.so is not symbolic link but linker > script > that is > > GROUP ( libgcc_s.so.1 libgcc.a ) > > I hear this is because some functions are not included in libgcc_s.so.1 and > they are > only in libgcc.a. > > But now, "gcc -v -o hello hello.c" gives following output on linking phase. > > /usr/libexec/gcc/sh4-unknown-linux/4.1.0/collect2 --eh-frame-hdr -m > shlelf_linux -dynamic-linker /lib/ld-linux.so.2 -o hello > /usr/lib/gcc/sh4-unknown-linux/4.1.0/../../../crt1.o > /usr/lib/gcc/sh4-unknown-linux/4.1.0/../../../crti.o > /usr/lib/gcc/sh4-unknown-linux/4.1.0/crtbegin.o > -L/usr/lib/gcc/sh4-unknown-linux/4.1.0 -L/usr/lib/gcc/sh4-unknown-linux/4.1.0 > -L/usr/lib/gcc/sh4-unknown-linux/4.1.0/../../.. /tmp/ccer52C9.o -lgcc > --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s > --no-as-needed /usr/lib/gcc/sh4-unknown-linux/4.1.0/crtend.o > /usr/lib/gcc/sh4-unknown-linux/4.1.0/../../../crtn.o > > It seems that libgcc.a is linked automatically, so it would be work if > libgcc_s.so is a symbolic link to libgcc_s.so.1. > > If libgcc_s.so were symbolic link, unneeded dependency on libgcc_s.so.1 would > not be written to the executable. > ( '--as-needed' seems not work for linker script ) It sounds like a linker bug. I will look int it. H.J.
Re: Building the whole Debian archive with GCC 4.1: a summary
Hi,
well too bad some news sites pick this mail up as rather bad news for
the GCC compiler and project as it.
However the opposite is the truth, I'm a long term system integrator
contributing to ROCK Linux since 1998 and nowadays leading the
T2 SDE fork of it. It is a development environment allowing the
automated build including cross compilation, including C++
cross compilation (a bit like Gentoo, just for professional developers).
http://www.t2-project.org/
In this time I experienced the big 2.95 -> 3.{0,1} and the other
but not that big 3.4, 4.0 migrations. I can only say never was
a major GCC release that pleasing. With GCC 4.1 the ill-formed
code of the _packages_ compiled with GCC that has been uncovered
was rather just minor - just a few compared to e.g. the 2.95 -> 3.0
migration or update within the 3.x series.
Even as one having to do a lot patching for each of the GCC
releases I appreciate the stricter language checking even if
not as long warned about as the friend injection or the extra
qualificatoin. Those are rather trivial changes anyway.
That said with the over 2400 packages in T2 (no -devel packages
thus not directly comparable to others with tons of -devel and
other split packages) including modular X11R7 and a lot of
custom cross build stuf,f GCC 4.1 is already the default compiler in
the T2 development trunk to be released as a stable series in the next
weeks.
Best regards,
PS: If some company has too much money the T2 project
also always happy to find some sponsors, e.g. to regularly
rebuild the whole source repository one a week or so with
GCC trunk:HEAD, including cross builds if interesting.
On Saturday 25 March 2006 22:56, Martin Michlmayr wrote:
> Over the last 2.5 weeks I have built the complete Debian archive
> on a quad-core MIPS machine donated by Broadcom using the recently
> released version 4.1 of GCC. In parallel, I have done the same
> on an EM64T box donated to Debian by Intel.
>
> The purpose of this exercise was three-fold:
> - Find out about compiler problems in GCC 4.1 itself as well
>as in packages that may fail with the new version *before*
>GCC 4.1 is uploaded to Debian.
> - Find out about MIPS specific problems in GCC 4.1 and to answer
>the question of Matthias Klose, Debian's GCC maintainer, [1]
>as to which platforms can move to GCC 4.1 as the default compiler.
> - Find MIPS specific assembler warnings and create a list of all
>users of xgot (a MIPS specific toolchain problem).
>
> I thought I'd summarize my findings for the GCC developers so you know
> what kind of broken code is out there in the wild. Given that Debian
> is a fairly large distribution, we probably have a better coverage of
> the "typical free software" project (i.e. not just the successful
> projects everyone talks about) than most other distros.
>
>
> Executive summary
> -
>
> GCC 4.1 itself appears to be very stable, both on MIPS and AMD64.
> There are, however, a large number of packages using code (especially
> C++) which GCC 4.1 treats as errors. Fortunately, most of them are
> trivial to fix. By compiling about 6200 software packages (see [2]
> for the list), over 500 new bugs have been discovered and submitted:
> 280 of which are specific to the increased strictness of GCC 4.1.
> Patches for 2/3 of those GCC 4.1 specific bugs have been submitted.
>
>
> Detailed summary of problems
>
>
> Basically, it all boils down to broken C++ code. There were a few
> bugs in C code, but the majority was in C++. The most common
> errors I found (and some *approximate* numbers) are:
>
> - extra qualification: about 187 bugs
> - reliance on friend injection: 26 bugs
> - wrong escape characters (e.g. "\."; most commonly seen in regular
>expressions): 6 bugs
> - iterator problems (such as assigning 0 or NULL to an iterator): 3
> - template specialisation in wrong namespace
> - template reliance on a function declared later
> - use of template's base class members, unqualified, where the base class
>is dependent
> - use of "assert" without #include : 5 bugs
> - dereferencing type-punned pointer will break strict-aliasing rules
>together with -Werror: 6 bugs
> - the use of "mips" as a variable name when GCC on mips defines it
>as a constant (arg!) and you end up with: const 1 = -1: 1 bug
>
> A list of all GCC 4.1 specific bugs in packages can be found at [3].
> The single biggest syntax error found is the use of extra qualification,
> which fortunately are trivial to fix.
>
>
> Compiler bugs in GCC 4.1
>
>
> I've found a number of GCC bugs in this process (the # bug numbers refer
> to bugs in the Debian bug tracker, please use http://bugs.debian.org/nnn):
>
> - gcc ICE: #356231 (when building gnubik_2.2-5)
>http://gcc.gnu.org/PR26672 - fixed
>
> - g++ ICE: #356569 (when building 3ddesktop_0.2.9-5.1)
>http://gcc.gnu.org/PR26757 - test case needs f
R_PPC_REL24 overflow
I'm confused... While working with tools for a PowerPC 8xx I've run into a problem loading SO's: /bin/hello.x: error while loading shared libraries: /lib/libgcc_s.so.1: R_PPC_REL24 relocation at 0x0ff6c384 for symbol `__pthread_mutex_lock' out of range I'm using gcc-4.0.2+ (i686-pc-linux-gnu x powerpc-823-linux) and glibc-2.3.6. Googling for similar problems suggests that this relocation is not used when building with -fPIC, and that all PowerPC SO's should be built with -fPIC. Objdump -dR shows the reference is from gcc_personality_v0(), which is defined in gcc/unwind-c.c. gcc/Makefile.in creates libgcc.mk which is used to compile unwind-c.c with -fPIC. The generated asm makes the reference as: bl [EMAIL PROTECTED] # 141 *call_value_nonlocal_sysv/1 [length = 4] And for this, gas generates: R_PPC_REL24 __pthread_mutex_lock Can anyone help clarify what is / should be going on here? Jim. -- Jim Lemke [EMAIL PROTECTED] Orillia, Ontario
Front end best practice in GCC 4.1.0?
I'm fiddling around with a GCC 4 front-end tutorial that would be more detailed and hands-on than anything I've found so far on the web. It's a bit like the blind leading the blind, but it makes me learn better and while I'm learning it I don't mind writing it up, but after I learn it I've got better things to do. At the moment I'm just working on understanding the GCC build system, which appears to merit a book in itself (I, however, won't be writing it. :-) The question is, which front ends are regarded as being good exemplars of style in GCC 4 and which are burdened with legacy code that shouldn't be duplicated in a new project? I gather that at one time the obvious choice, treelang, wasn't all that pretty and the fortran front end was suggested as better, but that was somewhat dated news. All suggestions welcome. Dustin pgpvoJM37NlW4.pgp Description: PGP signature
Re: Front end best practice in GCC 4.1.0?
On 3/29/06, Dustin Laurence <[EMAIL PROTECTED]> wrote: > I'm fiddling around with a GCC 4 front-end tutorial that would be more > detailed and hands-on than anything I've found so far on the web. It's > a bit like the blind leading the blind, but it makes me learn better and > while I'm learning it I don't mind writing it up, but after I learn it > I've got better things to do. Two friends and I have started to write a toy scheme front end. As a sub product, we have create a hello world front end and a small tutorial. You may find them at http://svn.gna.org/viewcvs/gsc/branches/hello-world/. Depending on what you want, maybe you can write some patches instead of a full tutorial :-) > The question is, which front ends are regarded as being good exemplars > of style in GCC 4 and which are burdened with legacy code that shouldn't > be duplicated in a new project? I gather that at one time the obvious > choice, treelang, wasn't all that pretty and the fortran front end was > suggested as better, but that was somewhat dated news. I think that fortran is a better option. Treelang has the parser mixed up with the rest of the front end. > All suggestions welcome. > > Dustin Best Regards, Rafael
Re: gcc project
On Tue, 2006-03-28 at 17:23, Diego Novillo wrote: > 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 see. The plugin approach you're sketching is very general, through which anyone could write virtually any check, provided that it learns (1) the AST structure and (2) the API to manipulate it. I took a quite different approach, much more lightweight, which lets really anyone write a restricted class of checks without knowing the AST, nor any API. Nevertheless, this light approach could be combined with the API-based approach, by complementing the (declarative) code patterns with (executable) predicates using the API, and loaded as dynamic libraries. Thus, the two approaches can complement each other, leaving unexperienced users to write simple checks, and advanced users to write more complex checks. The more general idea is that compiling and (simple) checking can be fused together with a lot of advantages. I also wrote some papers on the subject (that I would have loved to submit to the gcc summit but I didn't learn soon enough about it, that's too bad :(( ). > 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. > Ok, I'll take a few days to install subversion, figure how to use it, port my stuff to the current 4.2 mainline, etc, and I'll get back. Note that I'm doing everything on my spare time, so it's not that predictable :°). Regards, Nic.
Re: Ada subtypes and base types
> "Duncan" == Duncan Sands <[EMAIL PROTECTED]> writes: Duncan> That still leaves the problem of how the Ada front-end tells the Duncan> middle-end that a variable is known to be in a certain range. Due Duncan> to the way the language works, the front-end often does know a useful Duncan> range, helpful for optimisation. If using types with strange ranges Duncan> is out, and ASSERT_EXPRs aren't appropriate, what is left? Yeah, there's got to be something. On irc today we were discussing handling 'this' in gcj. We can add an attribute to the argument to mark it as non-null... but strangely there doesn't seem to be a way to mark other local variables as known-non-null -- a curious deficiency. Tom
Re: R_PPC_REL24 overflow
On Wed, Mar 29, 2006 at 01:53:31PM -0500, James Lemke wrote: > The generated asm makes the reference as: > bl [EMAIL PROTECTED] # 141 *call_value_nonlocal_sysv/1 [length = 4] > > And for this, gas generates: > R_PPC_REL24 __pthread_mutex_lock > > Can anyone help clarify what is / should be going on here? All fine so far. Then, ld should resolve the branch to point to a PLT entry - you want to figure out why that isn't happening and the branch is being output into the shared library. -- Daniel Jacobowitz CodeSourcery
Re: Front end best practice in GCC 4.1.0?
> "Dustin" == Dustin Laurence <[EMAIL PROTECTED]> writes: Dustin> The question is, which front ends are regarded as being good Dustin> exemplars of style in GCC 4 and which are burdened with legacy Dustin> code that shouldn't be duplicated in a new project? I gather Dustin> that at one time the obvious choice, treelang, wasn't all that Dustin> pretty and the fortran front end was suggested as better, but Dustin> that was somewhat dated news. This is kind of vague... what kinds of things do you want to know? I advocate the overall approach taken by gcjx: 1. Write the front end as a separate library, with its own representation of the program. In particular, don't use the GCC tree structure to model the program. This makes it easier to reuse the front end in other situations. gcjx has several back ends: java class files, header files (for CNI and JNI), GCC trees, LLVM was in the works. You could also add analysis "back ends", etc. 2. Put the front end into its own top-level directory in the source tree. This removes the temptation to let GCC-isms sneak in. 3. Write a thin layer of glue to convert the front end's internal representation to GENERIC. Avoid having your own tree codes and the like (e.g., use build_common_tree_nodes -- don't do like gcj and roll your own... if you need your own integral types, define them separately). In gcjx this glue layer is just one back end among many, and they are all simply implementations of a code generation interface. In particular I think the representation choice is critical. The "old" gcj has had many silly bugs directly traceable to its use of trees; using a statically typed representation (as in gcjx... the entire model is C++ classes) eliminates whole classes of bugs. Oh, yeah, one more thing: write it in C++. GCC's internals are fairly friendly to C++ these days, and IME it is markedly better than C. At least, if you try to work at a high level, use the STL, etc. Tom
Re: [FYI] Building the whole Debian archive with GCC 4.1: a summary
Matthias Klose wrote: > Summary: > > GCC 4.1 itself appears to be very stable, both on MIPS and AMD64. Thank you for doing this, and for reporting the results, and for filing the bugs! This is, in my opinion, pretty good news for GCC. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Front end best practice in GCC 4.1.0?
On Wed, Mar 29, 2006 at 05:10:25PM -0300, Rafael Espíndola wrote: > Two friends and I have started to write a toy scheme front end. You know, I've always wondered why there wasn't a lisp-family front end for GCC, the roots of GNU and RMS being where they are (and didn't RMS promise way back when to make lisp suitable for unix systems programming?). I'm just not connected enough to the lisp world to know the answer I guess. I hope none of that turns out to be flamewar fodder that was long ago made taboo for this list. =8-O > ...As a > sub product, we have create a hello world front end and a small > tutorial. That's pretty much *exactly* what I had in mind--minimal front end that produces a useless, do-nothing, but "correct" front end. Even the motivation is the same, since as you might expect this was a preface to a language project. :-) > Depending on what you want, maybe you can write some patches instead > of a full tutorial :-) I'd be happy to cooperate as much as possible. The goal was to write the document I needed myself and didn't find, and in so doing learn the knowledge I'd have gotten from it. It wasn't to write for writing's sake. If you've done everything I wanted, so much the better. :-) That said, I haven't actually looked at your docs in detail. It took me a while to install svn, figure out how to do a checkout and what URL to use, find the system docbook stylesheets, and put their path in the makefile (not too bad for someone who has never seen docbook or used XML before, I thought), and learn enough about docbook to find an alternative to fop (I am not eager to install it because I'm trying to keep this machine not-too-dependent on a jvm. :-) ) A quick look suggests that what you wrote is very like what I wanted to end up with. The main difference is that I suspect I was going for a bit more exhaustive detail--whether that's a good or bad thing is a separate issue. Were you thinking hosting the html version somewhere eventually? > I think that fortran is a better option. Treelang has the parser mixed > up with the rest of the front end. Thanks, that's the sort of comments I was hoping for. Dustin pgp3CDLfKipKy.pgp Description: PGP signature
