switching to Git - equivalent of svnmerge merge... [to merge trunk into MELT]?
Hello All,
I am switching to GIT for my GCC work (mostly the MELT branch, sometimes
submitting patches to trunk). A big thanks to Dodji Seketeli for his very
kind help. If I understand correctly, I am using the GCC git service.
But I have some issues. The GCC MELT branch has very localised changes
(almost all of them are in some files named *melt*). The difference between
MELT and trunk -on files existing in both- is very small usually (usually, a
few lines in toplevel.c). Most of the files are exactly the same.
Now, I am trying for the first time to merge trunk into MELT. In the old SVN
times (last week!), I just did svnmerge merge and most of the time I had no
conflict (because by design MELT is very close to the trunk) at all.
Now, I followed http://gcc.gnu.org/wiki/GitMirror and did
cd /usr/src/Lang/basile-melt-gcc
git merge --squash master
and now I am getting a lot of conflicts that I do not understand. A typical
one is:
Auto-merging gcc/ada/gcc-interface/gigi.h
CONFLICT (add/add): Merge conflict in gcc/ada/gcc-interface/gigi.h
% git status gcc/ada/gcc-interface/gigi.h
# On branch melt-branch
# Unmerged paths:
# (use "git reset HEAD ..." to unstage)
# (use "git add/rm ..." as appropriate to mark resolution)
#
# both added: gcc/ada/gcc-interface/gigi.h
#
no changes added to commit (use "git add" and/or "git commit -a")
I never in my life touched an y ada related file (neither in trunk, not in
the MELT branch).
And if I ask what is happenning; % git diff gcc/ada/gcc-interface/gigi.h
diff --cc gcc/ada/gcc-interface/gigi.h
index 67a7a47,e45cf13..000
--- a/gcc/ada/gcc-interface/gigi.h
+++ b/gcc/ada/gcc-interface/gigi.h
@@@ -6,7 -6,7 +6,11 @@@
* *
* C Header File *
* *
++<<< HEAD
+ * Copyright (C) 1992-2010, Free Software Foundation, Inc. *
++===
+ * Copyright (C) 1992-2011, Free Software Foundation, Inc. *
++>>> master
* *
* GNAT is free software; you can redistribute it and/or modify it under *
* terms of the GNU General Public License as published by the Free Soft- *
@@@ -861,10 -861,9 +865,16 @@@ extern tree build_allocator (tree type
Entity_Id gnat_proc, Entity_Id gnat_pool,
Node_Id gnat_node, bool);
++<<< HEAD
+/* Fill in a VMS descriptor for EXPR and return a constructor for it.
+ GNAT_FORMAL is how we find the descriptor record. GNAT_ACTUAL is how
+ we derive the source location on a C_E */
+extern tree fill_vms_descriptor (tree expr, Entity_Id gnat_formal,
++===
+ /* Fill in a VMS descriptor of GNU_TYPE for GNU_EXPR and return the result.
+GNAT_ACTUAL is the actual parameter for which the descriptor is built. */
+ extern tree fill_vms_descriptor (tree gnu_type, tree gnu_expr,
++>>> master
Node_Id gnat_actual);
/* Indicate that we need to take the address of T and that it therefore
I was expecting the git merge to copy all the changes from trunk into the
MELT branch. I don't feel the above as a "conflict" (and in the svnmerge
merge times, it was not one). I just want git to bring all the changes from
trunk into GCC MELT. And I expect conflicts -if any- only on the very files
that are common (ie exisiting in both), but different in the MELT branch and
in the trunk (like perhaops gcc/Makefile.in). I dont understand why there is
a conflict on an ada related file I never touched in my life.
What did I do wrong? What is the good way to merge the trunk back into my
MELT branch using git? How can I ask git to ignore such "conflicts" (as
svnmerge merge did)?
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: targetm.init_builtins and build_common_builtin_nodes ordering
On Mon, Feb 7, 2011 at 2:35 AM, Mike Stump wrote: > So, in c-common.c we have: > > targetm.init_builtins (); > build_common_builtin_nodes (); > > and in f95-1.c we have: > > build_common_builtin_nodes (); > targetm.init_builtins (); They are "unordered", thus, targetm.init_builtins is supposed to initialize target specific builtins only. > I would like to change c-common.c to match fortran, so that the target hook > can slightly alter (rename) the linkage name of some of the common builtin > nodes. If that answer is no, what's the best way to get __divdc3 renamed? I would say add a new hook that can be called from build_common_builtin_nodes instead. Richard.
Re: How to default to -fno-math-errno on all FreeBSD targets
On Mon, Feb 7, 2011 at 2:48 AM, Gerald Pfeifer wrote:
> David Schultz noticed that the FreeBSD libm does not set errno, never
> has done, and never will, and thus has made -fno-math-errno the default
> in the (old, GCC 4.2-based) system compiler:
>
> http://svn.freebsd.org/viewvc/base?view=revision&revision=181538
>
>
> We should also make this change for GCC 4.6 and possibly retroactively
> GCC 4.5 since we are giving away performance for nothing.
>
>
> Our documentation already notes that this is the case on Darwin
>
> On Darwin systems, the math library never sets @code{errno}. There is
> therefore no reason for the compiler to consider the possibility that
> it might, and @option{-fno-math-errno} is the default.
>
> which hacks config/i386/i386.c as follows:
>
> ix86_option_init_struct (struct gcc_options *opts)
> {
> if (TARGET_MACHO)
> /* The Darwin libraries never set errno, so we might as well
> avoid calling them when that's the only reason we would. */
> opts->x_flag_errno_math = 0;
>
> I guess I could just add a check for FSB_MAJOR there, but that would
> only address i386. Is there a better way to accomplish this?
A new target macro/hook would be needed for that I think. But see
also recent discussion about frontends wanting to change these defaults
(and that not working anymore).
Does FreeBSD ever set errno for malloc() calls? See PR47179 and
PR42944 - which means it might require splitting the flag into a
math piece and a general piece (or one covering just malloc & friends).
Richard.
Re: switching to Git - equivalent of svnmerge merge... [to merge trunk into MELT]?
Basile Starynkevitch writes: > I dont understand why there is a conflict on an ada related file I > never touched in my life. The problem is that git does not know anything about the svn merges (because svn does not know anything about merges itself). Thus the merge base between melt-branch and master is the point where melt-branch was created. $ git rev-list $(git merge-base melt-branch master)..melt-branch | wc -l 1246 $ git show melt-branch~1245 commit bf7f3deb8c4263d0f7d26f17f807d7ee7275b5f9 Author: bstarynk Date: Tue Feb 19 15:01:57 2008 + creating MELT branch git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/melt-branch@132434 138bc75d-0d04-0410-961f-82ee72b054a4 > What is the good way to merge the trunk back into my MELT branch using > git? How can I ask git to ignore such "conflicts" (as svnmerge merge > did)? The easiest way to get things going is to create a dummy merge in the melt-branch that records the last svn merge you made. To do that you need to find the last merged revision on the master branch and merge it using the ours strategy. Then you can merge the master branch as usual. $ git merge -s ours bd785057b42734e859f64428467a673ee3c00372 $ git merge master Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different."
Re: switching to Git - equivalent of svnmerge merge... [to merge trunk into MELT]?
On Mon, Feb 07, 2011 at 11:59:23AM +0100, Andreas Schwab wrote:
> Basile Starynkevitch writes:
> The easiest way to get things going is to create a dummy merge in the
> melt-branch that records the last svn merge you made. To do that you
> need to find the last merged revision on the master branch and merge it
> using the ours strategy. Then you can merge the master branch as usual.
>
> $ git merge -s ours bd785057b42734e859f64428467a673ee3c00372
> $ git merge master
Thanks a big lot. Apparently, something worked, but I cannot figure out how
you got that bd785057b42734e859f64428467a673ee3c00372 SHA1 key. I thought it
would appear in the git log output.
I'm trying hard to understand how to reliably and painlessly merge trunk
into the MELT branch. I am using the git mirror
git://gcc.gnu.org/git/gcc.git but I don't understand well if I should use
only it, or also git svn dcommit (which I do use).
I also cannot figure out how to reliably get the Svn id of the trunk gotten
by Git. With svnmerge, I had the information at the beginning of
svnmerge-*.txt
Regards, and many thanks.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: switching to Git - equivalent of svnmerge merge... [to merge trunk into MELT]?
Basile Starynkevitch writes: > Thanks a big lot. Apparently, something worked, but I cannot figure out how > you got that bd785057b42734e859f64428467a673ee3c00372 SHA1 key. I thought it > would appear in the git log output. Search for the svn revision in the log output. > I am using the git mirror git://gcc.gnu.org/git/gcc.git but I don't > understand well if I should use only it, or also git svn dcommit I don't know about dcommit, I was assuming you are going to use only git. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different."
Re: switching to Git - equivalent of svnmerge merge... [to merge trunk into MELT]?
On Mon, Feb 7, 2011 at 08:50, Basile Starynkevitch wrote: > I'm trying hard to understand how to reliably and painlessly merge trunk > into the MELT branch. I am using the git mirror > git://gcc.gnu.org/git/gcc.git but I don't understand well if I should use > only it, or also git svn dcommit (which I do use). You will use git svn dcommit to submit the final merge, once you fixed it in your local tree. > I also cannot figure out how to reliably get the Svn id of the trunk gotten > by Git. With svnmerge, I had the information at the beginning of > svnmerge-*.txt 'git log master' will show you the git-svn-id entries for every SVN commit in the log. The top one is the latest that you will merge against. Diego.
Re: targetm.init_builtins and build_common_builtin_nodes ordering
On Mon, Feb 07, 2011 at 11:51:55AM +0100, Richard Guenther wrote: > On Mon, Feb 7, 2011 at 2:35 AM, Mike Stump wrote: > > So, in c-common.c we have: > > > > targetm.init_builtins (); > > build_common_builtin_nodes (); > > > > and in f95-1.c we have: > > > > build_common_builtin_nodes (); > > targetm.init_builtins (); > > They are "unordered", thus, targetm.init_builtins is supposed to initialize > target specific builtins only. > > > I would like to change c-common.c to match fortran, so that the target hook > > can slightly alter (rename) the linkage name of some of the common builtin > > nodes. If that answer is no, what's the best way to get __divdc3 renamed? > > I would say add a new hook that can be called from build_common_builtin_nodes > instead. Richard, The workaround that Mike came up with for darwin is posted here... http://gcc.gnu.org/ml/gcc-testresults/2011-02/msg00726.html FYI, I tried inverting the order of targetm.init_builtins (); and build_common_builtin_nodes (); in c-common.c to match that in f95-1.c but it broke the bootstrap. Jack > > Richard.
Re: sparc-rtems recent test regressions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/02/11 07:19, Joel Sherrill wrote: > Hi, > > In the past few days, something has regressed > on the sparc. Revision 169143 only had 699 failures > and ~100 of those were LTO related. David Korn's > patch seems to have resolved those. Revision 169504 > has 2231 failures. Were you able to test whether or not the ira-costs.c patch was the cause of these problems? It's been problematical elsewhere and it wouldn't take much more than a nudge to for me to pull it given its ability to uncover latent problems. jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNUBBwAAoJEBRtltQi2kC7A38H/0xhcKeVjAZm1R2XL/t0W99K U21D+Rn+Un0NeO0KaVr8SrpZZ2Nfyfrt62TqvyCjK6UuvBPlu8NNK1C7GBcR1gZQ yZHVt99hyYChpBosFnRm/kef0736E9CNLzd1IQBWXTv9X0RJPyR8NdIUEnYNG9st hj2+xHDOUR4JFdWxaObZlzFcJkQOSfd1m0oe5uUHaCLG2XDhwvVGj6z7tBL22+XC J00oDcMPV/5Hm4xGv8rJ+rOezS7wvn1ifjAfy2NkhKqH5nR+wr6Z4l0o2VYb04kv LU8eNo5Z4bVSXHNXH/LPUXaBRbYxU1KyBp8Fx+oEyrh6P8PuaTb4IHK5Xi4MOlY= =sQGQ -END PGP SIGNATURE-
GCC 4.6.0 Status *-rtems
Hi There are currently 14 RTEMS targets with each target being a different CPU architecture. With three exceptions (avr, h8300, and m32c), we attempt to build and test C, C++, Ada, and Go for all of them. Test results are posted to the GCC and RTEMS test results lists. Thanks to the Google Summer of Code and Ian Taylor, gcc 4.6.0 will include Go support for a number of targets. The following summarizes which languages build or fail to build for *-rtems. All failures have PRs filed but there are a few patches in my local tree which remain to be merged. arm - BUILD: C, C++ FAIL: Ada and Go ICE avr - BUILD: NONE bfin- BUILD: C, C++, and Ada FAIL: Go because libffi does not support bfin h8300 - BUILD: C i386- BUILD: C, C++, Go FAIL: Ada ICE lm32- BUILD: NONE m32c- BUILD: C, C++ m32r- BUILD: C, C++, Ada, Go mips- BUILD: C, C++, Go FAIL: Ada (-G0 not processed) m68k- BUILD: C, C++, Ada FAIL: Go (ICE) powerpc - BUILD: C, C++, Ada, Go sh - C, C++, Go FAIL: Ada (SH2e single FP issue) sparc - C, C++, Ada, Go FAIL: NONE sparc64 - C, C++, Ada, Go FAIL: NONE We have a number of PRs outstanding but the ones we view as most critical and would love to see fixed by 4.6.0 are: + arm Frame issue - http://gcc.gnu.org/PR38644 + i386 Ada ICE (regression) - http://gcc.gnu.org/PR47481 There are two targets which cannot build C -- avr and lm32: + avr - http://gcc.gnu.org/PR47534 + lm32 - http://gcc.gnu.org/PR46898 We have other PRs which are regressions including: + arm Ada ICE - http://gcc.gnu.org/PR37440 + mips Ada -G0 - http://gcc.gnu.org/PR47500 Hopefully the PRs listed above can be resolved so 4.6.0 is at parity with 4.5 with the addition of Go. Thanks. -- 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
Broken bootstrap on Cygwin
Current trunk, rev. 169888, fails to bootstrap on Cygwin with this error: [...] /tmp/gcc-4.6-r169888/libgcc/config/libbid/bid_decimal_globals.c:47:18: fatal error: fenv.h: No such file or directory compilation terminated. make[2]: *** [bid_decimal_globals.o] Error 1 make[2]: *** Waiting for unfinished jobs make[2]: Leaving directory `/tmp/gcc-4.6-r169888/Work/i686-pc-cygwin/libgcc' make[1]: *** [all-target-libgcc] Error 2 make[1]: Leaving directory `/tmp/gcc-4.6-r169888/Work' make: *** [all] Error 2 usually I do weekly builds without any problem configuring with $ gcc-4.6 -v Using built-in specs. COLLECT_GCC=gcc-4.6 COLLECT_LTO_WRAPPER=/usr/local/gfortran/libexec/gcc/i686-pc-cygwin/4.6.0/lto-wrapper.exe Target: i686-pc-cygwin Configured with: /tmp/gcc-4.6-r169403/configure --prefix=/usr/local/gfortran --program-suffix=-4.6 --enable-languages=c,c++,fortran --enable-checking=release --enable-threads=posix --enable-libgomp --disable-bootstrap --disable-libmudflap --disable-shared Thread model: posix gcc version 4.6.0 20110130 (experimental) (GCC) Ciao, Angelo.
Re: Broken bootstrap on Cygwin
On 2/7/2011 1:41 PM, Angelo Graziosi wrote: > Current trunk, rev. 169888, fails to bootstrap on Cygwin with this error: > > [...] > /tmp/gcc-4.6-r169888/libgcc/config/libbid/bid_decimal_globals.c:47:18: > fatal error: fenv.h: No such file or directory > compilation terminated. > make[2]: *** [bid_decimal_globals.o] Error 1 > make[2]: *** Waiting for unfinished jobs > make[2]: Leaving directory > `/tmp/gcc-4.6-r169888/Work/i686-pc-cygwin/libgcc' > make[1]: *** [all-target-libgcc] Error 2 > make[1]: Leaving directory `/tmp/gcc-4.6-r169888/Work' > make: *** [all] Error 2 This was a deliberate choice: e.g. to require a development version of cygwin in order to bootstrap the 4.6 branch. Rationale: fenv.h support will be present in cygwin 1.7.8 which is due out any day now, and we didn't want to wait 6-8 months for the gcc-4.7 cycle in order to support decimal-floating-point stuff in cygwin/gcc. You can install one of the more recent cygwin snapshots, and the build should then work. -- Chuck
Re: sparc-rtems recent test regressions
On 02/07/2011 09:32 AM, Jeff Law wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/02/11 07:19, Joel Sherrill wrote: Hi, In the past few days, something has regressed on the sparc. Revision 169143 only had 699 failures and ~100 of those were LTO related. David Korn's patch seems to have resolved those. Revision 169504 has 2231 failures. Were you able to test whether or not the ira-costs.c patch was the cause of these problems? It's been problematical elsewhere and it wouldn't take much more than a nudge to for me to pull it given its ability to uncover latent problems. This is for revision 169231. So it looks like that caused the failures. === gcc Summary === # of expected passes67735 # of unexpected failures635 # of expected failures 227 # of unresolved testcases 50 # of unsupported tests 1233 jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNUBBwAAoJEBRtltQi2kC7A38H/0xhcKeVjAZm1R2XL/t0W99K U21D+Rn+Un0NeO0KaVr8SrpZZ2Nfyfrt62TqvyCjK6UuvBPlu8NNK1C7GBcR1gZQ yZHVt99hyYChpBosFnRm/kef0736E9CNLzd1IQBWXTv9X0RJPyR8NdIUEnYNG9st hj2+xHDOUR4JFdWxaObZlzFcJkQOSfd1m0oe5uUHaCLG2XDhwvVGj6z7tBL22+XC J00oDcMPV/5Hm4xGv8rJ+rOezS7wvn1ifjAfy2NkhKqH5nR+wr6Z4l0o2VYb04kv LU8eNo5Z4bVSXHNXH/LPUXaBRbYxU1KyBp8Fx+oEyrh6P8PuaTb4IHK5Xi4MOlY= =sQGQ -END PGP SIGNATURE- -- 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
AIX vs long double
AIX provides two versions of long double and declares all of the C99 long double symbols in math.h header file. One implementation aliases long double to IEEE double precision type and the other implementation aliases long double to IBM's paired double format. All of the C99 symbols for IEEE double precision are implemented in libm, but not all of the C99 symbols for the IBM long double format are implemented. IBM's proprietary XL compiler (cc, xlc) defaults to IEEE double precision and provides a special invocation to default to IBM long double (cc128, xlc128). GNU/Linux and GCC on GNU/Linux default to IEEE quad precision long double. Because the long double choice is an ABI change, GCC on AIX switched to GNU/Linux compatibility with support for AIX 6.1, before the incomplete implementation was noticed. This mostly worked until libgfortran started using additional C99 functions, causing GCC Bugzilla [target/47032] libgfortran references complex long double functions missing on AIX libstdc++-v3 on AIX builds with AIX long double support, although user programs that try to access the missing functions (copysign, nextafter, etc.) will experience link-time failures. libgfortran on AIX fails to build with AIX long double support because it accesses the missing functions in its implementation. I would like to solicit feedback about how to proceed: Should GCC on AIX revert back to 64 bit long double size, allowing all libraries to build and work, but breaking GCC/G++ ABI on AIX? Or should it continue to utilize 128 bit long double, building libstdc++-v3 that works if the user program does not utilize the missing symbols and fails to build libgfortran? Thanks, David
Re: sparc-rtems recent test regressions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/07/11 11:51, Joel Sherrill wrote: > On 02/07/2011 09:32 AM, Jeff Law wrote: > On 02/02/11 07:19, Joel Sherrill wrote: Hi, In the past few days, something has regressed on the sparc. Revision 169143 only had 699 failures and ~100 of those were LTO related. David Korn's patch seems to have resolved those. Revision 169504 has 2231 failures. > Were you able to test whether or not the ira-costs.c patch was the cause > of these problems? It's been problematical elsewhere and it wouldn't > take much more than a nudge to for me to pull it given its ability to > uncover latent problems. > >> This is for revision 169231. So it looks like that caused >> the failures. OK. I'm going to take a looksie. As long as it isn't something I've already fixed or some dumb bug elsewhere, the plan is to pull the ira-costs patch and revisit it in stage1. jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNUEv/AAoJEBRtltQi2kC7WPQH+QGJOYGd3xLGqj0tx7ObT2GZ 7xvwUc8xHdKhnp/ltLyl2mb4SUmnhD0OQ5UXEQPD6jtDJmS3Xh2RO/LnmD0vo9Nb TwvPvgq4ilR67hY2SvDAaHqHnclV4BAfVjhIKdRM3AZxO+a+ufTGJtTm7VZ8AiHO 531EDvrr7KCKTZRQqj2zqZWo/bO/Z1RjbX0BNV0B641OwP5Ng5md1XnGaNSPI3wq 4oSLfhFcm4YFYlxOqrmtJkHZHHOADNmpRHIRUbg/qC8quLr48v56wk4Bmn60x3/B w0ldVZJqGg5Y0tyvpAdgYAzsNI7cQledwRJyLC1wiQWs2JzIztaGN6VkIWxo/HU= =iM9P -END PGP SIGNATURE-
Re: sparc-rtems recent test regressions
On 02/07/2011 01:46 PM, Jeff Law wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/07/11 11:51, Joel Sherrill wrote: On 02/07/2011 09:32 AM, Jeff Law wrote: On 02/02/11 07:19, Joel Sherrill wrote: Hi, In the past few days, something has regressed on the sparc. Revision 169143 only had 699 failures and ~100 of those were LTO related. David Korn's patch seems to have resolved those. Revision 169504 has 2231 failures. Were you able to test whether or not the ira-costs.c patch was the cause of these problems? It's been problematical elsewhere and it wouldn't take much more than a nudge to for me to pull it given its ability to uncover latent problems. This is for revision 169231. So it looks like that caused the failures. OK. I'm going to take a looksie. As long as it isn't something I've already fixed or some dumb bug elsewhere, the plan is to pull the ira-costs patch and revisit it in stage1. If you need me to test something, just yell. --joel jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNUEv/AAoJEBRtltQi2kC7WPQH+QGJOYGd3xLGqj0tx7ObT2GZ 7xvwUc8xHdKhnp/ltLyl2mb4SUmnhD0OQ5UXEQPD6jtDJmS3Xh2RO/LnmD0vo9Nb TwvPvgq4ilR67hY2SvDAaHqHnclV4BAfVjhIKdRM3AZxO+a+ufTGJtTm7VZ8AiHO 531EDvrr7KCKTZRQqj2zqZWo/bO/Z1RjbX0BNV0B641OwP5Ng5md1XnGaNSPI3wq 4oSLfhFcm4YFYlxOqrmtJkHZHHOADNmpRHIRUbg/qC8quLr48v56wk4Bmn60x3/B w0ldVZJqGg5Y0tyvpAdgYAzsNI7cQledwRJyLC1wiQWs2JzIztaGN6VkIWxo/HU= =iM9P -END PGP SIGNATURE- -- 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: targetm.init_builtins and build_common_builtin_nodes ordering
On Feb 7, 2011, at 2:51 AM, Richard Guenther wrote: > I would say add a new hook that can be called from build_common_builtin_nodes > instead. Ok, thanks.
Re: GCC 4.6.0 Status *-rtems
2011/2/7 Joel Sherrill : > > There are two targets which cannot build C -- avr and lm32: > > + avr - http://gcc.gnu.org/PR47534 I have committed the fix r169896 Please somebody close the bug. I can't login to bugzilla. (Probably I forgot my login and password) Denis.
Re: How to default to -fno-math-errno on all FreeBSD targets
On Mon, Feb 7, 2011 at 2:55 AM, Richard Guenther wrote: > Does FreeBSD ever set errno for malloc() calls? See PR47179 and > PR42944 - which means it might require splitting the flag into a > math piece and a general piece (or one covering just malloc & friends). The option's documentation (and the name itself) says it is a math piece anyways. So I don't see why need to split it up? -- Pinski
Re: GCC 4.6.0 Status *-rtems
> + i386 Ada ICE (regression) - http://gcc.gnu.org/PR47481 I'll look into this one... > + mips Ada -G0 - http://gcc.gnu.org/PR47500 ...but a MIPS maintainer needs to take a preliminary look at this one. -- Eric Botcazou
Re: GCC 4.6.0 Status *-rtems
On 02/07/2011 02:27 PM, Denis Chertykov wrote: 2011/2/7 Joel Sherrill: There are two targets which cannot build C -- avr and lm32: + avr - http://gcc.gnu.org/PR47534 I have committed the fix r169896 Please somebody close the bug. I can't login to bugzilla. (Probably I forgot my login and password) I will close it when I can confirm it builds. Thanks. Denis. -- 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: Broken bootstrap on Cygwin
Il 07/02/2011 19.48, Charles Wilson ha scritto: On 2/7/2011 1:41 PM, Angelo Graziosi wrote: Current trunk, rev. 169888, fails to bootstrap on Cygwin with this error: [...] /tmp/gcc-4.6-r169888/libgcc/config/libbid/bid_decimal_globals.c:47:18: fatal error: fenv.h: No such file or directory compilation terminated. make[2]: *** [bid_decimal_globals.o] Error 1 make[2]: *** Waiting for unfinished jobs make[2]: Leaving directory `/tmp/gcc-4.6-r169888/Work/i686-pc-cygwin/libgcc' make[1]: *** [all-target-libgcc] Error 2 make[1]: Leaving directory `/tmp/gcc-4.6-r169888/Work' make: *** [all] Error 2 This was a deliberate choice: e.g. to require a development version of cygwin in order to bootstrap the 4.6 branch. Rationale: fenv.h support will be present in cygwin 1.7.8 which is due out any day now, and we didn't want to wait 6-8 months for the gcc-4.7 cycle in order to support decimal-floating-point stuff in cygwin/gcc. You can install one of the more recent cygwin snapshots, and the build should then work. I do not understand the logic here: break GCC trunk for something that hasn't been yet released. Often new Cygwin version was announced as imminent and the true release delayed for months.. (This time the announce was for 01 or 02 February.. and up today, 07, nothing happened.) GCC maintainers is this OK for your policy? Angelo
Re: GCC 4.6.0 Status *-rtems
On 02/07/2011 02:27 PM, Denis Chertykov wrote: 2011/2/7 Joel Sherrill: There are two targets which cannot build C -- avr and lm32: + avr - http://gcc.gnu.org/PR47534 I have committed the fix r169896 Thanks. avr-rtems now compiles. Please somebody close the bug. I can't login to bugzilla. (Probably I forgot my login and password) Denis. -- 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: Broken bootstrap on Cygwin
On 2/7/2011 3:50 PM, Angelo Graziosi wrote: > I do not understand the logic here: break GCC trunk for something that > hasn't been yet released. > > Often new Cygwin version was announced as imminent and the true release > delayed for months.. Never happened. Even the interminable 1.7.0 release was never announced as "coming by such-and-such-date"...until it was actually released. It is actually VERY rare for the cygwin maintainers to EVER give any sort of ETA on a new release. In a suprising move, they have done so for 1.7.8 -- specifically in response to a Q by Dave K about this exact fenv.h issue. http://cygwin.com/ml/cygwin/2011-01/msg00325.html "Early Feb is more likely. From my POV there's just that new issue with stdio blocking each other" > (This time the announce was for 01 or 02 February.. and up today, 07, > nothing happened.) "Early Feb" == 01 or 02, but not 03 or 07? > GCC maintainers is this OK for your policy? Seems like that would be up to the judgement of the (cygwin) platform maintainer for gcc...which boils down to Dave K. Since he's the guy that actually made the commit, you can probably assume he was ok with it. -- Chuck
Re: Broken bootstrap on Cygwin
> GCC maintainers is this OK for your policy? Personally, I don't think it's a good thing to do: a secondary platform that only supports the latest released version of said platform does not indicate high stability. But it's up to the cygwin maintainers to decide, of course. However, the fact should be documented on the installation notes (http://gcc.gnu.org/install/specific.html#x-x-cygwin) and probably on the release notes as well, with something like "The GCC 4.6 series requires Cygwin x.y.z or later". FX
Re: Proposal to move Valgrind annotations from "valgrind" to "misc" --enable-checking option
On Thu, 27 Jan 2011, Laurynas Biveinis wrote: > Thus I propose to separate the two. To avoid introducing another > --enable-checking option, let's move the annotations to the "misc" > checking and also enable "misc" too if "valgrind" is requested. Both > these options are disabled for releases, so no performance loss there. > > There are two drawbacks I can think of. First, if one wants Valgrind > annotations but does not have the required headers, then the compiler > will be built without them - silently (currently > --enable-checking=valgrind fails if headers are not found). Second, > the compiler binary will be built slightly different if "misc" is > enabled depending on the presence or absence of those headers. I > believe these are minor enough. > > I have a prototype patch which I've been using on gc-improv (not > committed there yet). > > What do you think? Sounds good to me (the original author of the --enable-checking=valgrind FWIW). I have no problems with your suggested changes, except I insist --enable-checking=valgrind still behave the same: actually running valgrind on all gcc invocations, adding annotations and failing if it doesn't find the headers. ;) If people want your "misc" changes but failing without headers, add "--enable-valgrind-annotations". Unfortunately, last I checked, the valgrind of Fedora 12 (or was it 10?) was compiled with too low limits to cope with bootstrapping and compiling the most troublesome insn-*.c file. brgds, H-P
