Re: GCC 4.1.1 Status Report (2006-05-15)
On 5/16/06, Mark Mitchell <[EMAIL PROTECTED]> wrote: Andrew Pinski wrote: > Mark, > >> Therefore, effective midnight tonight (i.e., 12:00AM May 17th in >> California), the 4.1 branch will be frozen. (I previously announced May >> 15th as a target release date.) After that point, all changes, >> including previously approved patches, need my explicit approval. I'll >> create 4.1.1 RC1 tomorrow. > > Just for clearification, is the freeze time tonight, the 15th or Wednesday, > the 17th? Shucks, that's a mess. I meant tonight, the 15th. > This is a backport of a patch that went in last week. Let's get that done then -- unless we think the backport is unreasonably dangerous. I'm happy to make that call, if pointed at the patch, and if the original submitter is uncomfortable making the decision. >> 27603cri P1 NEW [4.1/4.2 Regression] wrong code, apparently due >> to bad VR... > This patch just went on the mainline but has not gone on the 4.1 branch yet. Similarly. Applied to the 4.1 branch. Hope I didn't miss the deadline. Thanks, Richard.
Re: mips: -G0 vs __dso_handle
DJ Delorie <[EMAIL PROTECTED]> writes:
>> I'll pre-approve that change, but I'll also defer to any other
>> maintainer who has a solution they prefer.
>
> How about this one?
>
> 2006-05-15 DJ Delorie <[EMAIL PROTECTED]>
>
> * crtstuff.c (__dso_handle): Set section from
> TARGET_LBIGCC_SDATA_SECTION if defined.
> * doc/tm.text (TARGET_LIBGCC_SDATA_SECTION): Document.
> * config/mips/mips.h (TARGET_LIBGCC_SDATA_SECTION): Define.
Doesn't build. Obvious patch installed.
Andreas.
2006-05-16 Andreas Schwab <[EMAIL PROTECTED]>
* doc/tm.texi (TARGET_LIBGCC_SDATA_SECTION): Add missing @end
defmac.
Index: tm.texi
===
--- tm.texi (revision 113820)
+++ tm.texi (working copy)
@@ -1,5 +1,5 @@
@c Copyright (C) 1988,1989,1992,1993,1994,1995,1996,1997,1998,1999,2000,2001,
[EMAIL PROTECTED] 2002, 2003, 2004, 2005 Free Software Foundation, Inc.
[EMAIL PROTECTED] 2002, 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
@c This is part of the GCC manual.
@c For copying conditions, see the file gcc.texi.
@@ -6228,6 +6228,7 @@ MIPS), you could compile crtstuff with @
require small data support from your application, but use this macro
to put small data into @code{.sdata} so that your application can
access these variables whether it uses small data or not.
[EMAIL PROTECTED] defmac
@defmac FORCE_CODE_SECTION_ALIGN
If defined, an ASM statement that aligns a code section to some
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
C front-end - GCC 4.1
Hello , I am currently extending the existing C front-end of GCC 4.1. Basically, I add new keywords into the set of the C language. I have already done a big part of the lexical and syntax analysis of each new keywords. I work on the files "c-common.h", "c-parser.c", "c-tree.h", "c-decl.c", "c-typeck.c" located in the directory '/gcc'. I am confused about also extending the Abstract Syntax Tree of GCC and also the GENERIC form. I would be grateful if someone can explain me which files are used for the operations on the AST and the code generation of the GENERIC form. Cheers, Thomas
Re: RFD: Integrate shorten_branches, machine-dependent constant pool placement and small-scale hot/cold partitioning
On Sun, 2006-05-14 at 17:09, Joern RENNECKE wrote: > The constant pool placement that sh_reorg does has somewhat hapazard > results. It does not take execution frequencies into account, so if > you are unlucky, you can end up with a constant table wedged into some > hoit spot of the code, which not only adds an extra jump into the > critical path, but can also cause conditional branches to go out of > range, which are then converted into branches around jumps or branches > to jumps. A related problem is that branch splitting does not take > into account the branch probabilities, and the placement of jumps - > and if necessary, constants for these jumps - is also rather ad-hoc. > Moreover, when you think about optimal placement of individual jumps, > it is only a little step further to think about small basic blocks > ending with a jump which are branched over by a likely taken branch. > Or if the branched-around code is very seldom executed, we can also > consider it even if it falls through at the end to merge with the > destination of the branch. On architectures where a not-taken branch > is cheaper than a taken branch, it makes sense to move this code out > of the way - not far away like the large-scale hot/cold partitioning > does, but rather within the range of conditional branches. For the SH, > this means within -252..+258 bytes. That fits nicely with the range > of of 16-bit constants, which are in a range of 4..514 bytes. 32-bit > constants can be a bit farther, in the range 4..1024 bytes. > > In order to do the constant and jump / cold code placement sensibly, I > need to be able to determine which branches go out of range beause of a > particular. With the current separation of branch shortening and > constant table placement, there are no useful estimates - before > constant placements, we estimate that no single conditional branch is > in range. The problem here is that we have to assume that a maximum > sized constant pool of 1020 bytes might be inserted anywhere, even > though in practice most constant pools are much smaller. The length of > the branches themselves is estimated at 6 when it should be 2. > > I'e realized now that I can take the code of shorten_branches, add two > lookup arrays and a bit of code (which won't change the time complexity > of shorten_branches), I can calculate much better estimates for > instruction sizes for indeterminate constant pool placement - simply > by keeping track of the maximum amount of constants that could be > inserted into any one place. The informationj calculated by such a > modifed shorten_branches pass would also allow to determine when a > short branch is possible in the absence of a cosntant pool table, and > at what table size inserted it will go out of range. > > I wonder now if I should keep this as SH-specific code, or does it make > sense to write this a bit more generic - i.e. a variable number of > constant ranges, configurable size of small cold blocks, and the range > of branches selectable - and provide this as a new piece of gcc > infrastructure. > > Do other port maintainers see similar issues with their ports? Yes, the problem on Thumb-1 is the same in almost all respects: 1) Conditional branches have limited range 2) Pools (sometimes) have to be inserted in the middle of the the instruction flow (if we can't find a suitable branch to hide the pool behind). 3) Pool placement and branch shortening both affect each other, making it hard to find the global optimum. With the Thumb code there is an additional problem that I'd like to try and solve: - Small functions all get their own constant pool, even if they could reach further to allow pool merging. Given the distinct similarities here, I think it is worth investigating whether some common solution can be found. It's silly for both backends to be maintaining code that does substantially the same thing. R.
can't run C compiled programs
hello, I got a serious problem with my linux system( specifications bellow) , In fact I can't launch C programs compiled with gcc. this is what I got when trying to do so : ~/wormux-0.7.1 $ /bin/bash ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking whether NLS is requested... yes checking for msgfmt... /usr/bin/msgfmt checking for gmsgfmt... /usr/bin/gmsgfmt checking for xgettext... /usr/bin/xgettext checking for msgmerge... /usr/bin/msgmerge checking for style of include used by make... GNU checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. --->Also when I compile a simple program by myself I got : ~ $ ./testaz bash: ./testaz: Permission denied However the portage is working fine , it can compile C and c++ programs ---> my system is : Gentoo linux 2.6.15-r1, most the packages are stable sudo gcc-config -l [1] i686-pc-linux-gnu-3.4.4 * [2] i686-pc-linux-gnu-3.4.4-hardened [3] i686-pc-linux-gnu-3.4.4-hardenednopie [4] i686-pc-linux-gnu-3.4.4-hardenednopiessp [5] i686-pc-linux-gnu-3.4.4-hardenednossp --> the glibc version is: 2.4.6-r3 Thank you
Basic block profiling support in recent GCCs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there is basic block profiling being dropped out from recent GCCs (i mean compiling with "-g -pg -a")? If it is still supported in any of the GCC development branches please let me know. thanks in advance Nikolaos Kavvadias -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEacDUMPiy0tCWlz4RAi8vAJoD1201Wg3fTGDx5JfxS2+zFuxJCwCghs4O YPCxeXICoQfhBzec+zlrW8I= =uLed -END PGP SIGNATURE-
RE: can't run C compiled programs
On 16 May 2006 12:12, Mohamed Boukaa wrote: > checking for C compiler default output file name... a.out > checking whether the C compiler works... configure: error: cannot run C > compiled programs. > If you meant to cross compile, use `--host'. > See `config.log' for more details. > > --->Also when I compile a simple program by myself I got : > > ~ $ ./testaz > bash: ./testaz: Permission denied > However the portage is working fine , it can compile C and c++ programs What happens if you "chmod a+x ./testaz"? You may have your UMASK set wrong. cheers, DaveK -- Can't think of a witty .sigline today
Re: RFD: Integrate shorten_branches, machine-dependent constant pool placement and small-scale hot/cold partitioning
Richard Earnshaw wrote: > Yes, the problem on Thumb-1 is the same in almost all respects: I had Joern's mail in my reply-to queue, and was going to say basically the same things as Richard, so I'll just echo the fact that I'd like to see some generic infrastructure built. > With the Thumb code there is an additional problem that I'd like to try > and solve: > - Small functions all get their own constant pool, even if they could > reach further to allow pool merging. Now that Richard has given us proper data structures for sections, perhaps we could solve this last problem relatively simply. In particular, have cgraph sort functions so that functions appearing in the same section are emitted together. Then, the back end could just not reset the distance counters when starting a new function, so long as there was no change in section. We do need to account for the prologue/epilogue code, which, the last time I looked, wasn't counted. I guess we could do this even without sorting the functions, either by conservatively resetting at every section switch, or by storing the counters in a machine-specific part of the section data structure. Of course, we have to have a way of knowing if the compiler has dumped a random variable of asm() output into a section, but we must have solved that for section anchors as well. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
RE: can't run C compiled programs
On 16 May 2006 15:15, Mohamed Boukaa wrote: > Dave Korn wrote: > >> On 16 May 2006 12:12, Mohamed Boukaa wrote: >> >>> checking for C compiler default output file name... a.out >>> checking whether the C compiler works... configure: error: cannot run C >>> compiled programs. If you meant to cross compile, use `--host'. >>> See `config.log' for more details. >>> >>> --->Also when I compile a simple program by myself I got : >>> >>> ~ $ ./testaz >>>bash: ./testaz: Permission denied >>>However the portage is working fine , it can compile C and c++ programs >>> >>> >> >> What happens if you "chmod a+x ./testaz"? You may have your UMASK set >> wrong. >> > It gives the same thing, my umask is set at 022 . > Has it something to do with the udpate of gcc from 3.4.4 to 3.4.5 ( any > library issue) , I returned to 3.4.4 and the problem remains. It should not be a problem. Every gcc version X.Y.* should remain compatible, so all compilers from 3.4.* series should not cause any compatibility problem. If portage is working, perhaps you have more than one compiler/version installed? What does "file ./testaz" say? Can you find out which one portage is using and how it invokes it? Does portage have different path settings when it runs? cheers, DaveK -- Can't think of a witty .sigline today
Successful gcc 4.0.3 build on alphaev68-dec-osf5.1bTru64(c,c++,f95,objc,java,treelang)
[EMAIL PROTECTED]:~#gcc -v Using built-in specs. Target: alphaev68-dec-osf5.1b Configured with: ../configure --host=alphaev68-dec-osf5.1b --enable-threads=posix --enable-languages=c,c++,f95,objc,java,treelang --prefix=/usr/local --enable-version-specific-runtime-libs --enable-shared --enable-libgcj --enable-nls --enable-interpreter Thread model: posix gcc version 4.0.3 see my previous email: http://gcc.gnu.org/ml/gcc/2005-07/msg00601.html for f95 and java compilation. Sincerely, Stefano Curtarolo -- Prof. Stefano Curtarolo Assistant Professor of Materials Science Duke University, Dept. Mechanical Engineering and Materials Science 144 Hudson Hall, Box 90300, Durham, NC 27708-0300 phone 919-660-5506 [EMAIL PROTECTED] http://alpha.mems.duke.edu -- -- If possible, please avoid sending me Word or PowerPoint attachments. http://www.gnu.org/philosophy/no-word-attachments.html [This email was composed with renewable energy. When you are done reading this email, please dispose of it in an environmentally friendly manner, such as electronic composting.] --
mainline problems?
I *just* checked out mainline, and it is failing to build like so: (x86 with checking enabled) libbackend.a(print-rtl.o): In function `print_decl_name': /src/gcc/2006-05-16/gcc/gcc/print-rtl.c:73: multiple definition of `flag_dump_unnumbered' libbackend.a(options.o):(.bss+0x1ac): first defined here libbackend.a(rtlanal.o): In function `rtx_unstable_p': /src/gcc/2006-05-16/gcc/gcc/rtlanal.c:94: multiple definition of `target_flags' libbackend.a(options.o):(.bss+0x28): first defined here libbackend.a(toplev.o): In function `set_src_pwd': /src/gcc/2006-05-16/gcc/gcc/toplev.c:408: multiple definition of `flag_pcc_struct_return' libbackend.a(options.o):(.bss+0x25c): first defined here libbackend.a(toplev.o): In function `set_src_pwd': /src/gcc/2006-05-16/gcc/gcc/toplev.c:411: multiple definition of `flag_var_tracking' libbackend.a(options.o):(.bss+0x350): first defined here collect2: ld returned 1 exit status make[3]: *** [cc1-dummy] Error 1 rm fsf-funding.pod gcov.pod gfdl.pod cpp.pod gpl.pod gcc.pod make[3]: Leaving directory `/build/gcc/2006-05-16/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/build/gcc/2006-05-16' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/build/gcc/2006-05-16' make: *** [all] Error 2 Andrew
Re: RFD: Integrate shorten_branches, machine-dependent constant pool placement and small-scale hot/cold partitioning
On May 16, 2006, at 3:13 AM, Richard Earnshaw wrote: I wonder now if I should keep this as SH-specific code, or does it make sense to write this a bit more generic - i.e. a variable number of constant ranges, configurable size of small cold blocks, and the range of branches selectable - and provide this as a new piece of gcc infrastructure. Yes, the problem on Thumb-1 is the same in almost all respects Given the distinct similarities here, I think it is worth investigating whether some common solution can be found. It's silly for both backends to be maintaining code that does substantially the same thing. I think sharing of port common code is worthwhile.
Re: Basic block profiling support in recent GCCs
On May 16, 2006, at 5:08 AM, Nikolaos Kavvadias wrote: is basic block profiling being dropped out Please use gcov instead. No, gcov isn't going away.
Re: mainline problems?
On Tue, 2006-05-16 at 11:50 -0400, Andrew MacLeod wrote: > I *just* checked out mainline, and it is failing to build like so: > > (x86 with checking enabled) > > libbackend.a(print-rtl.o): In function `print_decl_name': > /src/gcc/2006-05-16/gcc/gcc/print-rtl.c:73: multiple definition of > `flag_dump_unnumbered' > libbackend.a(options.o):(.bss+0x1ac): first defined here > libbackend.a(rtlanal.o): In function `rtx_unstable_p': > /src/gcc/2006-05-16/gcc/gcc/rtlanal.c:94: multiple definition of > `target_flags' > libbackend.a(options.o):(.bss+0x28): first defined here > libbackend.a(toplev.o): In function `set_src_pwd': > /src/gcc/2006-05-16/gcc/gcc/toplev.c:408: multiple definition of > `flag_pcc_struct_return' > libbackend.a(options.o):(.bss+0x25c): first defined here > libbackend.a(toplev.o): In function `set_src_pwd': > /src/gcc/2006-05-16/gcc/gcc/toplev.c:411: multiple definition of > `flag_var_tracking' > libbackend.a(options.o):(.bss+0x350): first defined here > collect2: ld returned 1 exit status > make[3]: *** [cc1-dummy] Error 1 > rm fsf-funding.pod gcov.pod gfdl.pod cpp.pod gpl.pod gcc.pod > make[3]: Leaving directory `/build/gcc/2006-05-16/gcc' > make[2]: *** [all-stage1-gcc] Error 2 > make[2]: Leaving directory `/build/gcc/2006-05-16' > make[1]: *** [stage1-bubble] Error 2 > make[1]: Leaving directory `/build/gcc/2006-05-16' > make: *** [all] Error 2 Compilation appears to be find if I back out the latest change: Andrew 2006-05-16 H.J. Lu <[EMAIL PROTECTED]> PR driver/26885 * Makefile.in (GCC_OBJS): New. (OBJS-common): Add opts-common.o. (xgcc$(exeext)): Replace gcc.o with $(GCC_OBJS). (cpp$(exeext)): Likewise. (gcc.o): Also depend on opts.h. (opts-common.o): New. * common.opt (gcoff): Add Negative(gdwarf-2). (gdwarf-2): Add Negative(gstabs). (gstabs): Add Negative(gstabs+). (gstabs+): Add Negative(gvms). (gvms): Add Negative(gxcoff). (gxcoff): Add Negative(gxcoff+). (gxcoff+): Add Negative(gcoff). * config/i386/i386.opt (m32): Add Negative(m64). (m64): Add Negative(m32). * doc/options.texi: Document the Negative option. * gcc.c: Include "opts.h". (main): Call prune_options after expandargv. * optc-gen.awk: Generate common declarations for all flag variables in options.c. Output the neg_index field. * opts.c (find_opt): Moved to ... * opts-common.c: Here. New file. * opts.h (cl_option): Add a neg_index field. (find_opt): New. (prune_options): Likewise.
Re: Basic block profiling support in recent GCCs
On Tue, May 16, 2006 at 03:08:52PM +0300, Nikolaos Kavvadias wrote: > is basic block profiling being dropped out from recent GCCs (i mean > compiling with "-g -pg -a")? > If it is still supported in any of the GCC development branches please > let me know. Support for -a was dropped in GCC 3.1 Basic block profiling with gcov uses different options; check the documentation for the version of GCC you are using to see what options to use. Janis
Re: mainline problems?
On Tue, May 16, 2006 at 12:49:13PM -0400, Andrew MacLeod wrote: > On Tue, 2006-05-16 at 11:50 -0400, Andrew MacLeod wrote: > > I *just* checked out mainline, and it is failing to build like so: > > > > (x86 with checking enabled) > > > > libbackend.a(print-rtl.o): In function `print_decl_name': > > /src/gcc/2006-05-16/gcc/gcc/print-rtl.c:73: multiple definition of > > `flag_dump_unnumbered' > > libbackend.a(options.o):(.bss+0x1ac): first defined here I have [EMAIL PROTECTED] prev-gcc]$ readelf -s print-rtl.o| grep flag_dump_unnumbered 24: 4 OBJECT GLOBAL DEFAULT5 flag_dump_unnumbered [EMAIL PROTECTED] prev-gcc]$ readelf -s options.o| grep flag_dump_unnumbered 181: 0004 4 OBJECT GLOBAL DEFAULT COM flag_dump_unnumbered Does this work on your platform? [EMAIL PROTECTED] tmp]$ cat x.c int x = 1; [EMAIL PROTECTED] tmp]$ gcc -c x.c [EMAIL PROTECTED] tmp]$ cat y.c int x; [EMAIL PROTECTED] tmp]$ gcc -c y.c [EMAIL PROTECTED] tmp]$ ld -r x.o y.o [EMAIL PROTECTED] tmp]$ ld -r y.o x.o H.J.
Re: mainline problems?
On May 16, 2006, at 10:20 AM, H. J. Lu wrote: On Tue, May 16, 2006 at 12:49:13PM -0400, Andrew MacLeod wrote: On Tue, 2006-05-16 at 11:50 -0400, Andrew MacLeod wrote: I *just* checked out mainline, and it is failing to build like so: (x86 with checking enabled) libbackend.a(print-rtl.o): In function `print_decl_name': /src/gcc/2006-05-16/gcc/gcc/print-rtl.c:73: multiple definition of `flag_dump_unnumbered' libbackend.a(options.o):(.bss+0x1ac): first defined here -fno-common is supplied while building. -- Pinski
Re: mainline problems?
On Tue, May 16, 2006 at 10:23:37AM -0700, Andrew Pinski wrote: > > On May 16, 2006, at 10:20 AM, H. J. Lu wrote: > > >On Tue, May 16, 2006 at 12:49:13PM -0400, Andrew MacLeod wrote: > >>On Tue, 2006-05-16 at 11:50 -0400, Andrew MacLeod wrote: > >>>I *just* checked out mainline, and it is failing to build like so: > >>> > >>>(x86 with checking enabled) > >>> > >>>libbackend.a(print-rtl.o): In function `print_decl_name': > >>>/src/gcc/2006-05-16/gcc/gcc/print-rtl.c:73: multiple definition > >>>of `flag_dump_unnumbered' > >>>libbackend.a(options.o):(.bss+0x1ac): first defined here > > -fno-common is supplied while building. I assume that -fno-common is added by hand since I didn't see it in my build logs on Linux/x86, Linux/x86-64 and Linux/ia64. H.J.
Re: mainline problems?
On Tue, 2006-05-16 at 10:20 -0700, H. J. Lu wrote: > On Tue, May 16, 2006 at 12:49:13PM -0400, Andrew MacLeod wrote: > > On Tue, 2006-05-16 at 11:50 -0400, Andrew MacLeod wrote: > > > I *just* checked out mainline, and it is failing to build like so: > > > > > > (x86 with checking enabled) > > > Does this work on your platform? > > [EMAIL PROTECTED] tmp]$ cat x.c > int x = 1; > [EMAIL PROTECTED] tmp]$ gcc -c x.c > [EMAIL PROTECTED] tmp]$ cat y.c > int x; > [EMAIL PROTECTED] tmp]$ gcc -c y.c > [EMAIL PROTECTED] tmp]$ ld -r x.o y.o > [EMAIL PROTECTED] tmp]$ ld -r y.o x.o > Sure. The platform is FC5 x86 linux, so i686-pc-linux-gnu Andrew
Re: mainline problems?
On May 16, 2006, at 10:39 AM, H. J. Lu wrote: I assume that -fno-common is added by hand since I didn't see it in my build logs on Linux/x86, Linux/x86-64 and Linux/ia64. No it is not added by hand. It is used when checking is turned on. Now I see you did not have checking on which is wrong for development. -- Pinski
Re: Basic block profiling support in recent GCCs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Stump wrote: > On May 16, 2006, at 5:08 AM, Nikolaos Kavvadias wrote: > >> is basic block profiling being dropped out > > > Please use gcov instead. No, gcov isn't going away. > > Thank you Mike and Janis for your responses. I'll have a look at the capabilities of gcov. Do you know if when building the gcc for cross (different) target (e.g. sparc-elf-gcc) the gcov does get built as well? I mean my intention is to use gcov for a cross target on a simulation environment based on SystemC (http://www.systemc.org). Thanks again Kind regards Nikolaos Kavvadias PS: I'm forwarding this message to the crossgcc list as well. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEag9tMPiy0tCWlz4RAmP6AKDF6g93PHwTLwW2MabW6lc0AilSUgCfR9hZ hfg759SvuCZXF8icutM1Cf4= =zZ1C -END PGP SIGNATURE-
PATCH: Compile options.c with -fcommon
On Tue, May 16, 2006 at 10:41:22AM -0700, Andrew Pinski wrote: > > On May 16, 2006, at 10:39 AM, H. J. Lu wrote: > > > > >I assume that -fno-common is added by hand since I didn't see it > >in my build logs on Linux/x86, Linux/x86-64 and Linux/ia64. > > No it is not added by hand. It is used when checking is turned on. > Now I see you did not have checking on which is wrong for development. > Here is a patch to force commoncommon symbols in options.o. H.J. --- 2006-05-16 H.J. Lu <[EMAIL PROTECTED]> * Makefile.in (options.o-warn): New. Add -fcommon if needed. --- gcc/Makefile.in.common 2006-05-16 09:26:43.0 -0700 +++ gcc/Makefile.in 2006-05-16 10:57:24.0 -0700 @@ -199,6 +199,11 @@ VALGRIND_DRIVER_DEFINES = @valgrind_path build-warn = $(STRICT_WARN) GCC_WARN_CFLAGS = $(LOOSE_WARN) $($(@D)-warn) $(NOCOMMON_FLAG) $([EMAIL PROTECTED]) +ifeq ($(NOCOMMON_FLAG),-fno-common) +# options.c needs to define compiler options as common symbols. +options.o-warn = -fcommon +endif + # These files are to have specific diagnostics suppressed, or are not to # be subject to -Werror: # Bison-1.75 output often yields (harmless) -Wtraditional warnings
Re: PATCH: Compile options.c with -fcommon
> > On Tue, May 16, 2006 at 10:41:22AM -0700, Andrew Pinski wrote: > > > > On May 16, 2006, at 10:39 AM, H. J. Lu wrote: > > > > > > > >I assume that -fno-common is added by hand since I didn't see it > > >in my build logs on Linux/x86, Linux/x86-64 and Linux/ia64. > > > > No it is not added by hand. It is used when checking is turned on. > > Now I see you did not have checking on which is wrong for development. > > > > Here is a patch to force commoncommon symbols in options.o. This is wrong. -- Pinski
Re: Basic block profiling support in recent GCCs
On May 16, 2006, at 10:44 AM, Nikolaos Kavvadias wrote: Do you know if when building the gcc for cross (different) target (e.g. sparc-elf-gcc) the gcov does get built as well? It should. I mean my intention is to use gcov for a cross target on a simulation environment based on SystemC (http://www.systemc.org). You might have to write a little code, worse case, to dump the data out to whatever you can dump it out to.
Re: PATCH: Compile options.c with -fcommon
> > > > > On Tue, May 16, 2006 at 10:41:22AM -0700, Andrew Pinski wrote: > > > > > > On May 16, 2006, at 10:39 AM, H. J. Lu wrote: > > > > > > > > > > >I assume that -fno-common is added by hand since I didn't see it > > > >in my build logs on Linux/x86, Linux/x86-64 and Linux/ia64. > > > > > > No it is not added by hand. It is used when checking is turned on. > > > Now I see you did not have checking on which is wrong for development. > > > > > > > Here is a patch to force commoncommon symbols in options.o. > > This is wrong. Please read: http://gcc.gnu.org/ml/gcc-patches/2002-08/msg01057.html What you need is a options.c that is only for the driver. I think both patches should be revert and went back to the drawning boards. -- Pinski
Re: PATCH: Compile options.c with -fcommon
On Tue, May 16, 2006 at 02:08:13PM -0400, Andrew Pinski wrote:
> >
> > >
> > > On Tue, May 16, 2006 at 10:41:22AM -0700, Andrew Pinski wrote:
> > > >
> > > > On May 16, 2006, at 10:39 AM, H. J. Lu wrote:
> > > >
> > > > >
> > > > >I assume that -fno-common is added by hand since I didn't see it
> > > > >in my build logs on Linux/x86, Linux/x86-64 and Linux/ia64.
> > > >
> > > > No it is not added by hand. It is used when checking is turned on.
> > > > Now I see you did not have checking on which is wrong for development.
> > > >
> > >
> > > Here is a patch to force commoncommon symbols in options.o.
> >
> > This is wrong.
>
> Please read:
> http://gcc.gnu.org/ml/gcc-patches/2002-08/msg01057.html
>
> What you need is a options.c that is only for the driver.
>
> I think both patches should be revert and went back to the drawning boards.
>
Here is a patch to compile gcc-options.o from options.c. I have to
update gcc/java/lang.opt since flag_emit_class_files isn't defined
in any files.
H.J.
gcc/
2006-05-16 H.J. Lu <[EMAIL PROTECTED]>
* Makefile.in (GCC_OBJS): Replace options.o with gcc-options.o.
(gcc-options.o): New rule.
* optc-gen.awk: Protect variables for gcc-options.o with
#ifdef GCC_DRIVER/#endif.
gcc/java/
2006-05-16 H.J. Lu <[EMAIL PROTECTED]>
* lang.opt(femit-class-file): Remove VarExists.
--- gcc/Makefile.in.common 2006-05-16 09:26:43.0 -0700
+++ gcc/Makefile.in 2006-05-16 11:53:20.0 -0700
@@ -961,7 +961,7 @@ [EMAIL PROTECTED]@
[EMAIL PROTECTED]@
# Object files for gcc driver.
-GCC_OBJS = gcc.o opts-common.o options.o
+GCC_OBJS = gcc.o opts-common.o gcc-options.o
# Language-specific object files for C and Objective C.
C_AND_OBJC_OBJS = attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o \
@@ -1767,6 +1767,9 @@ s-options-h: optionlist $(srcdir)/opt-fu
options.o: options.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) opts.h intl.h
+gcc-options.o: options.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) opts.h
intl.h
+ $(CC) -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(OUTPUT_OPTION) -DGCC_DRIVER
options.c
+
dumpvers: dumpvers.c
version.o: version.c version.h $(REVISION) $(DATESTAMP) $(BASEVER) $(DEVPHASE)
--- gcc/java/lang.opt.common2006-04-25 18:49:30.0 -0700
+++ gcc/java/lang.opt 2006-05-16 12:08:34.0 -0700
@@ -119,7 +119,7 @@ fcompile-resource=
Java Joined RejectNegative
femit-class-file
-Java Var(flag_emit_class_files) VarExists
+Java Var(flag_emit_class_files)
Output a class file
femit-class-files
--- gcc/optc-gen.awk.common 2006-05-16 09:23:04.0 -0700
+++ gcc/optc-gen.awk2006-05-16 11:57:46.0 -0700
@@ -62,7 +62,9 @@ for (i = 1; i <= n_headers; i++)
print "#include " quote "opts.h" quote
print "#include " quote "intl.h" quote
print ""
+print "#ifdef GCC_DRIVER"
print "int target_flags;"
+print "#endif /* GCC_DRIVER */"
print ""
for (i = 0; i < n_opts; i++) {
@@ -75,6 +77,7 @@ for (i = 0; i < n_opts; i++) {
if (name in var_seen)
continue;
init = ""
+ gcc_driver = 1
}
else {
init = opt_args("Init", flags[i])
@@ -82,11 +85,16 @@ for (i = 0; i < n_opts; i++) {
init = " = " init;
else if (name in var_seen)
continue;
+ gcc_driver = 0
}
+ if (gcc_driver == 1)
+ print "#ifdef GCC_DRIVER"
print "/* Set by -" opts[i] "."
print " " help[i] " */"
print var_type(flags[i]) name init ";"
+ if (gcc_driver == 1)
+ print "#endif /* GCC_DRIVER */"
print ""
var_seen[name] = 1;
Re: GCC SC request about ecj
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: Tom> So, could the SC please discuss the ecj plan and let us know whether Tom> it is acceptable? It would also be helpful to have some idea of how Tom> long the discussion might take. Ping. Any progress to report? Since I still think this is the best way forward, I started work on it. I've got a prototype working here. I'd like to commit it to a branch on gcc.gnu.org. But, I don't want to offend the SC any more than I have to ;-). So, please also let me know if this is unacceptable and if so, why. I suppose in the absence of a response I'll just consider it a maintainer's prerogative and go ahead. Tom
Re: intl directory: gcc vs. src
> > What do people who build in a combined tree do with intl? Do they use > > the GCC version or the src tree version? Is there any consensus about > > whether or not there should be a single version of intl, and if so, > > which one should be used? > > Yes, there should be a single version of intl. I don't think anybody > cares which version is used, as long as it works. If you have taken > the time to test a unified intl, and are prepared to fix any problems, > I think your patch would be great. > > Ian OK, I can sign up for that. While looking at the changes needed for the text in the MAINTAINERS file, I saw the following entry for libiberty: | libiberty/; libiberty's part of include/ |gcc: http://gcc.gnu.org |Changes need to be done in tandem with the official GCC |sources or submitted to the master file maintainer and brought |in via a merge. Note: approved patches in gcc's libiberty |are automatically approved in this libiberty also; feel free |to merge them yourself if needed sooner than the next merge. |Otherwise, changes are automatically merged, usually within |a day. Can someone tell me about this automatic merge? I was going to submit a formal patch to change the contents of src/intl but it seems that if we have an automatic merge to copy libiberty from gcc to src, we could do the same for intl (and src/config.rhost) and then I wouldn't need to do any actual checkins for those changes. If we can do that then the only thing I would need to change by hand would be the intl text that is in the MAINTAINERS file. Who maintains this automatic merge process? Steve Ellcey [EMAIL PROTECTED]
Re: intl directory: gcc vs. src
On Tue, May 16, 2006 at 03:36:22PM -0700, Steve Ellcey wrote: > Can someone tell me about this automatic merge? I was going to submit a > formal patch to change the contents of src/intl but it seems that if we > have an automatic merge to copy libiberty from gcc to src, we could do > the same for intl (and src/config.rhost) and then I wouldn't need to do > any actual checkins for those changes. If we can do that then the only > thing I would need to change by hand would be the intl text that is in > the MAINTAINERS file. > > Who maintains this automatic merge process? The man to ask about this is DJ Delorie. I'm not sure how much work it is on his part, though. Either way it would probably be best to do the initial sync by hand. And is it really plausible that nothing in src would need updating for the new intl? -- Daniel Jacobowitz CodeSourcery
Re: intl directory: gcc vs. src
> Who maintains this automatic merge process? Me. I have a cron job that checks out gcc's and src's libiberty and include, compares them, copies any differing files to src, and sends me email. I then run a "do it" script to do the actual commit. There's not much advantage in using this setup for an initial merge (it would take as much effort to set it up as it would to just do the merge). It's much more useful as an ongoing merge system.
Re: GCC SC request about ecj
On Tue, May 16, 2006 at 04:28:50PM -0600, Tom Tromey wrote: > Tom> So, could the SC please discuss the ecj plan and let us know whether > Tom> it is acceptable? It would also be helpful to have some idea of how > Tom> long the discussion might take. > > Ping. Any progress to report? I answered Tom privately; the short answer is that this is really an RMS decision, not an SC decision, since it involves legal issues, copyright ownership, etc.
Re: intl directory: gcc vs. src
DJ Delorie wrote: Who maintains this automatic merge process? Me. I have a cron job that checks out gcc's and src's libiberty and include, compares them, copies any differing files to src, and sends me email. I then run a "do it" script to do the actual commit. There's not much advantage in using this setup for an initial merge (it would take as much effort to set it up as it would to just do the merge). It's much more useful as an ongoing merge system. Was there not a way to combine the two (gcc and src) via console commands? I recall doing this a long time ago, back when Mumitt was around. He had a web page describing how to build the tool chain for cygwin/mingw/linux. There was another one on sourceware. i have not done this in years. (5). Bobby
Re: intl directory: gcc vs. src
> Was there not a way to combine the two (gcc and src) via console commands? We're not talking about combining source trees for a build, we're talking about making sure both source trees happen to have the same sources in them to start with.
Re: intl directory: gcc vs. src
> > Who maintains this automatic merge process? > > The man to ask about this is DJ Delorie. I'm not sure how much work it > is on his part, though. > > Either way it would probably be best to do the initial sync by hand. > And is it really plausible that nothing in src would need updating for > the new intl? > > -- > Daniel Jacobowitz > CodeSourcery If something in src is going to need updating I don't know what it is. I built binutils, gas, and gdb on HP-UX platforms using the gcc intl directory and had no problems. When I built on Linux the intl directory was basically ignored because it used the system gettext stuff. I'm sure something might need updating after this change and I am willing to try and fix anything I break, but I am not sure what other testing I can do with the platforms I have available. Do you have any suggestions as to what products or platforms might cause problems? I did get one reply from a combined-tree user who said they used the gcc version of intl when building things in a combined-tree. Steve Ellcey [EMAIL PROTECTED]
Re: intl directory: gcc vs. src
On Tue, May 16, 2006 at 04:06:29PM -0700, Steve Ellcey wrote: > I'm sure something might need updating after this change and I am > willing to try and fix anything I break, but I am not sure what other > testing I can do with the platforms I have available. Do you have any > suggestions as to what products or platforms might cause problems? No; I'm just surprised that it worked. -- Daniel Jacobowitz CodeSourcery
Re: PATCH: Compile options.c with -fcommon
Ping? I think this fixes a current bootstrap problem. Looks safe and reasonable to me. On May 16, 2006, at 1:09 PM, H. J. Lu wrote: Here is a patch to compile gcc-options.o from options.c. 2006-05-16 H.J. Lu <[EMAIL PROTECTED]> * Makefile.in (GCC_OBJS): Replace options.o with gcc-options.o. (gcc-options.o): New rule. * optc-gen.awk: Protect variables for gcc-options.o with #ifdef GCC_DRIVER/#endif.
Re: GCC SC request about ecj
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: Tom> Since I still think this is the best way forward, I started work on Tom> it. I've got a prototype working here. Tom> I'd like to commit it to a branch on gcc.gnu.org. But, I don't want Tom> to offend the SC any more than I have to ;-). So, please also let me Tom> know if this is unacceptable and if so, why. I suppose in the absence Tom> of a response I'll just consider it a maintainer's prerogative and go Tom> ahead. Just to clarify a bit -- My current changes don't involve ecj to the tree. They are mostly modifications to java/lang-specs.h and a few other related things. IMO there's nothing legally questionable about this really, it is analogous to a patch that adds support for a system 'ld' or the like. Tom
need help on analysis config.log in MAC OS X 7.9, gcc-5250
Dear gcc and/or apple OS X 7.9 users: Union-Souths-Computer:~/gcc-5250 UnionSouth$ cat config.log This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. configure:595: checking host system type configure:616: checking target system type configure:634: checking build system type configure:689: checking for a BSD compatible install configure:742: checking whether ln works configure:766: checking whether ln -s works please help to fix these configure mistakes to install cc or gcc in my MAC OS X 7.9, thanks in advance, eric
configure error : libffi has not been por ted to mipsel-unkown-linux-gnu
Hi, I am building the cross-toolchain for mipsel on x86 redhat pc. Now I can build the gcc for c using following configuration. ./configure --prefix=/opt/xuelian-toolchain/mipsel-linux-glibc --target=mipsel-linux --enable-shared --enable-threads --enable-languages=c --with-headers=/opt/xuelian-toolchain/mipsel-linux-glibc/mipsel-linux/include make make install But if I want to build it for C++, it failed. ./configure --prefix=/opt/xuelian-toolchain/mipsel-linux-glibc --target=mipsel-linux --enable-shared --enable-threads --enable-languages=c,c++ --with-headers=/opt/xuelian-toolchain/mipsel-linux-glibc/mipsel-linux/include make make install The error is: configure error: libffi has not been ported to mipsel-unknown-linux-gnu How should I do to solve this problem. Thanks a lot! Polestar
Re: PATCH: Compile options.c with -fcommon
H. J. Lu wrote: > 2006-05-16 H.J. Lu <[EMAIL PROTECTED]> > > * Makefile.in (GCC_OBJS): Replace options.o with gcc-options.o. > (gcc-options.o): New rule. > > * optc-gen.awk: Protect variables for gcc-options.o with > #ifdef GCC_DRIVER/#endif. OK. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: PATCH: Compile options.c with -fcommon
> > Ping? I think this fixes a current bootstrap problem. Looks safe > and reasonable to me. It was already APPROVED in the bug report about the orginal issue. Mike, next time please look at what is going on before replying. -- Pinski
wang mingxin wants to chat
I've been using Google Talk and thought you might like to try it out. We can use it to call each other for free over the internet. Here's an invitation to download Google Talk. Give it a try! --- wang mingxin wants to stay in better touch using some of Google's coolest new products. If you already have Gmail or Google Talk, visit: http://mail.google.com/mail/b-2232fb92ec-877437c3b3-7322bf08db6209b5 You'll need to click this link to be able to chat with wang mingxin. To get Gmail - a free email account from Google with over 2,600 megabytes of storage - and chat with wang mingxin, visit: http://mail.google.com/mail/a-2232fb92ec-877437c3b3-2c99060195 Gmail offers: - Powerful spam protection - Built-in search for finding your messages and a helpful way of organizing emails into "conversations" - No pop-up ads or untargeted banners - just text ads and related information that are relevant to the content of your messages - Instant messaging capabilities right inside Gmail All this, and its yours for free. But wait, there's more! You can also get Google Talk: http://www.google.com/talk/ Its a small Windows* download that lets you make free calls to your friends through your computer. It's simple and clutter-free, and it works with any computer speaker and microphone. Gmail and Google Talk are still in beta. We're working hard to add new features and make improvements, so we might also ask for your comments and suggestions periodically. We appreciate your help in making our products even better! Thanks, The Google Team To learn more about Gmail and Google Talk, visit: http://mail.google.com/mail/help/about.html http://www.google.com/talk/about.html (If clicking the URLs in this message does not work, copy and paste them into the address bar of your browser). * Not a Windows user? No problem. You can also connect to the Google Talk service from any platform using third-party clients (http://www.google.com/talk/otherclients.html).
