Re: GCC 4.3.3 Release Candidate available from gcc.gnu.org
On Sun, 18 Jan 2009, Richard Guenther wrote: > On Sun, 18 Jan 2009, H.J. Lu wrote: > > > On Sat, Jan 17, 2009 at 6:23 AM, Richard Guenther wrote: > > > > > > A release candidate for GCC 4.3.3 is available from > > > > > > ftp://gcc.gnu.org/pub/gcc/snapshots/4.3.3-RC-20090117/ > > > > > > and shortly its mirrors. It has been generated from SVN revision 143460. > > > > > > The branch is still frozen and all checkins until after the final > > > release of GCC 4.3.3 require explicit RM approval. > > > > > > > Gcc 4.3.3 miscompiled SPEC CPU 2006 on Linux/x86-64: > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38905 > > I am testing the following patch. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to the branch. I do not plan to do a new RC because of this. Richard.
Re: Cygwin support
> Brian Dessent : [snip! Access from plugins to every aspect of the compiler] > ... This means you'd have to move essentially everything into this > mega-DLL, leaving cc1 and friends as merely stubs that set a flag and > then call into the DLL never to return, since anything left in cc1 > would not be accessible from the plugin. FWIW this is not an uncommon situation for Win32 executables, especially for multiplatform application and/or applications ported from unix.
arm-elf-ld: undefined reference to 'xxx'
Hi everyone, I met an error when I'd like to execute arm-elf-ld. [condition] 1. main() is in main.o 2. func1() is in obj1.o 3. func2() is in obj2.o 4. main() refer to func2() 5. func2() refer to func1() The following command occurs an error(undefined reference to `func1'). arm-elf-ld ... -o test.elf main.o obj1.o obj2.o But if I exchange the place of obj1.o with obj2.o, then the command is successful without any error. I want to solve without exchanging objs. (Bcs, I have too many objs.) If arm-elf-ld has an option related to this problem, it will be possible. Is there the way to solve it? -- Prez Ahn (prezahn at gmail dot com)
Re: GCC 4.4.0 Status Report (2009-01-06)
Richard Guenther wrote: Status == The trunk remains Stage 4, so only fixes for regressions (and changes to documentation) are allowed. Any chance that PR 38587 might get some attention. psim is being miscompiled on x86_64. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38587 I am happy to do whatever I can to help narrow it down. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: arm-elf-ld: undefined reference to 'xxx'
> [cut] ... > But if I exchange the place of obj1.o with obj2.o, then the command is > successful without any error. > > I want to solve without exchanging objs. (Bcs, I have too many objs.) > If arm-elf-ld has an option related to this problem, it will be possible. > > Is there the way to solve it? I don't think this is the right mailing list to ask, but anyway, if those objects where grouped into an archive (via arm-elf-ar), you could try the --start-group and --end-group ld options. But AFAIK that doesn't work with object files. The object order dependency is a core feature in the way most linkers works, so generally you can't porbably cheat on it. Good luck, Alexandre
Re: Use longlong.h?
Joseph S. Myers wrote: > As code shared by GCC and glibc I would suggest the same license notice as > soft-fp (LGPL >= 2.1 + exception) to allow an identical file to be shared. > (Indeed, soft-fp uses this header.) The version in GMP diverged long ago > so sharing the file with that may not be feasible. I have suggested this change to the SC. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: We should backport gcc 4.4 regression testcases to gcc 4.3 branch
H.J. Lu wrote: > We can limit new testcases, which we backport to 4.3 branch, only > to those 4.4 regressions against 4.3 branch. They should always > pass on 4.3 branch by definition. There's nothing wrong with backporting testcases to an older release branch, but please make sure that they pass before committing them. Otherwise, we're creating noise. Bear in mind that some tests require features that weren't available in older versions. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GCC 4.3.3 Release Candidate available from gcc.gnu.org
On Mon, Jan 19, 2009 at 1:27 AM, Richard Guenther wrote: > On Sun, 18 Jan 2009, Richard Guenther wrote: > >> On Sun, 18 Jan 2009, H.J. Lu wrote: >> >> > On Sat, Jan 17, 2009 at 6:23 AM, Richard Guenther >> > wrote: >> > > >> > > A release candidate for GCC 4.3.3 is available from >> > > >> > > ftp://gcc.gnu.org/pub/gcc/snapshots/4.3.3-RC-20090117/ >> > > >> > > and shortly its mirrors. It has been generated from SVN revision 143460. >> > > >> > > The branch is still frozen and all checkins until after the final >> > > release of GCC 4.3.3 require explicit RM approval. >> > > >> > >> > Gcc 4.3.3 miscompiled SPEC CPU 2006 on Linux/x86-64: >> > >> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38905 >> >> I am testing the following patch. > > Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to the > branch. I do not plan to do a new RC because of this. > I think http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38902 is a critical bug since cc 4.3 may silently generate wrong-code on x86. We should backport http://gcc.gnu.org/ml/gcc-patches/2008-12/msg01131.html to 4.3 branch. -- H.J.
-fgraphite docs
Hi Sebastian While reading through the Graphite code on the trunk, I noticed that -fgraphite and -fgraphite-identity are no documented in doc/invoke.texi. Is this an oversight, or are these options deprecated? Ben -- Ben Elliston Australia Development Lab, IBM
Re: -fgraphite docs
On Mon, Jan 19, 2009 at 10:45 PM, Ben Elliston wrote: > Hi Sebastian > > While reading through the Graphite code on the trunk, I noticed that > -fgraphite and -fgraphite-identity are no documented in doc/invoke.texi. > Is this an oversight, or are these options deprecated? These options are intentionally not documented: they should not be used by programmers. Sebastian
Re: -fgraphite docs
> > Is this an oversight, or are these options deprecated? > > These options are intentionally not documented: they should not be > used by programmers. Perhaps we should add a comment to common.opt to explain this? Ben
Re: -fgraphite docs
On Mon, Jan 19, 2009 at 11:11 PM, Ben Elliston wrote: >> > Is this an oversight, or are these options deprecated? >> >> These options are intentionally not documented: they should not be >> used by programmers. > > Perhaps we should add a comment to common.opt to explain this? Yes, we could apply this patch. Sebastian Index: common.opt === --- common.opt (revision 143456) +++ common.opt (working copy) @@ -551,6 +551,7 @@ Common Report Var(flag_gcse_after_reload Perform global common subexpression elimination after register allocation has finished +; This option is not documented yet as its semantics will change. fgraphite Common Report Var(flag_graphite) Enable in and out of Graphite representation @@ -567,6 +568,7 @@ floop-block Common Report Var(flag_loop_block) Optimization Enable Loop Blocking transformation +; This option is not documented as it does not perform any useful optimization. fgraphite-identity Common Report Var(flag_graphite_identity) Optimization Enable Graphite Identity transformation
Re: -fgraphite docs
On Mon, 2009-01-19 at 23:20 -0600, Sebastian Pop wrote: > > Perhaps we should add a comment to common.opt to explain this? > > Yes, we could apply this patch. Looks good to me (and I think it qualifies as obvious) :-). Thanks, Ben
