Re: When was decimal floating point added to gcc?
On Sat, 2007-06-02 at 18:48 -0700, H. J. Lu wrote: > > > When was decimal floating point added to gcc? I couldn't find it > > > in any gcc changes.html. Shouldn't it be mentioned somewhere? > Are they mentioned in any gcc changes.html? No, they're not. They probably should be. Ben
Re: When was decimal floating point added to gcc?
On Sun, 3 Jun 2007, Ben Elliston wrote: >> Are they mentioned in any gcc changes.html? > No, they're not. They probably should be. Do you think we could talk the submitters/maintainers into donating a patch? :-) Gerald
Help in understanding ccp propagator
Hello, I will greatly appreciate any suggestions regarding the following problem I have with the ccp propagator. I am testing the new store ccp patch which propagates constants by walking the virtual use-def chain (http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00055.html) and I encountered the following problem while testing tree_join.cc file which is under libstdc++-v3 testsuite: The final propagator replaces the right operand (D.65705_98) in the following if condition with a constant zero which causes the program to be aborted as i0_62 is not always zero: # i0_62 = PHI :; D.61410.first = i0_62; ... D.65705_98 = D.61410.first; - if (D.65704_96 >= 0) + if (D.65704_96 >= D.65705_98) goto ; else goto ; Tracing the execution of the propagator it seems that the if statement is first been propogated with zero after simulating the execution; but not updated after the lattice value of the variables it depends on changed. Here is the scenario of the propagator: 1) D.61410.first is been updated to zero: 19921 Visiting PHI node: i0_62 = PHI 19922 Argument #0 (29 -> 4 not executable) 19923 19924 Argument #1 (3 -> 4 executable) 19925 0 Value: CONSTANT 0 19926 19927 PHI node value: CONSTANT 0 19928 19929 Lattice value changed to CONSTANT 0. Adding SSA edges to worklist. 19930 19931 Visiting statement: 19932 D.61410.first = i0_62; 19933 19934 Lattice value changed to CONSTANT 0. Adding SSA edges to worklist. 19935 2) D.65705_98 is been upadted to zero: 20235 Visiting statement: 20236 D.65705_98 = D.61410.first; 20237 20238 Lattice value changed to CONSTANT 0. Adding SSA edges to worklist. 20239 20240 Visiting statement: 20241 if (D.65704_96 >= D.65705_98) 3) D.61410.first latice value changed to VARYING. 20360 Simulating statement (from ssa_edges): D.61410.first = i0_62; 20361 20362 Visiting statement: 20363 D.61410.first = i0_62; 20364 20365 Lattice value changed to VARYING. Adding SSA edges to worklist. 4) if D.65705_98 is been replaced to zero: 25422 Substituing values and folding statements 25423 25424 Folded statement Folded statement: if (D.65704_96 >= D.65705_98) 25425 into: if (D.65704_96 >= 0) I am not sure why after the lattice value of D.61410.first has been changed to VARYING D.65705_98 and the if statement is not been updated as well. Thanks, Revital
Re: How to enable Mudflap in gcc 4.x?
"Deepen Mantri" <[EMAIL PROTECTED]> writes: > [...] > To enable libmudflap library, I am passing the "--enable-libmudflap" > option in the gcc configure script But I get the following error > during final gcc building: > "configure error: none of the known symbol names works > [configure-target-libmudflap] Error 1" libmudflap needs to know the know the name of the entry point symbol, to enable one of its heuristics. See the ENTRY_POINT area in configure.ac, and update it for your own runtime. Be aware that libmduflap's libc-wrapper functions may need porting for your libc. - FChE
Re: Help in understanding ccp propagator
On 6/3/07, Revital1 Eres <[EMAIL PROTECTED]> wrote: Hello, I will greatly appreciate any suggestions regarding the following problem I have with the ccp propagator. I am testing the new store ccp patch which propagates constants by walking the virtual use-def chain (http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00055.html) and I encountered the following problem while testing tree_join.cc file which is under libstdc++-v3 testsuite: BTW, a lot of these will be caught with the new VN i posted, whicih should be reviewed and go in soon. That said, ... The final propagator replaces the right operand (D.65705_98) in the following if condition with a constant zero which causes the program to be aborted as i0_62 is not always zero: # i0_62 = PHI :; D.61410.first = i0_62; ... D.65705_98 = D.61410.first; - if (D.65704_96 >= 0) + if (D.65704_96 >= D.65705_98) goto ; else goto ; Tracing the execution of the propagator it seems that the if statement is first been propogated with zero after simulating the execution; but not updated after the lattice value of the variables it depends on changed. Does your store CPP properly say the vdefs have changed when a statement's lattice value changes?
Re: [OT] Re: Git repository with full GCC history
On Fri, Jun 01, 2007 at 11:57:36AM -0400, Bernardo Innocenti wrote: > Gabriel Paubert wrote: > >On Fri, Jun 01, 2007 at 11:00:29AM -0400, Bernardo Innocenti wrote: > >>Gabriel Paubert wrote: > >> > >>>I just upgraded my git to 1.5.2 and repacked the git repository > >>>with git-gc --aggressive. It is quite impressive: the size of > >>>the pack file was almost cut in half, from ~23MB to ~12MB! > >>The --aggressive option is undocumented in 1.5.2. What > >>is it supposed to do? > > > >It is documented in my freshly compiled and installed git: > > In the source, I see it just passes "-f" to git-repack, which > I already did manually, with no improvement. > > So there must be something strange in your repository if > it packs that much better than mine. Could you please > publish it somewhere so I can make some tests? Well, actually the GCC repository does not pack better here than yours. It's even worse after having tested on 3 different machines just in case. In all cases I get about 1.4 GB for the pack with the default depth and window parameters. I don't know what Harvey is up to, he claimed his tree was between 400 and 500 MB. There are 50% more objects than in the Linux kernel, but with the same packing parameters the pack file is almost 10 times larger. It's true that many kernel patches are little more than one-liners, but even taking this into account, I'm surprised. Gabriel
Re: [OT] Re: Git repository with full GCC history
On 6/3/07, Gabriel Paubert <[EMAIL PROTECTED]> wrote: Well, actually the GCC repository does not pack better here than yours. It's even worse after having tested on 3 different machines just in case. In all cases I get about 1.4 GB for the pack with the default depth and window parameters. The defaults changed significantly somewhere near version 1.5.1 I believe with the delta caching mechanism making it much less expensive to use a deeper delta depth. I don't know what Harvey is up to, he claimed his tree was between 400 and 500 MB. Sorry, my mistake, the repo I was looking at only contained a clone of trunk. There are 50% more objects than in the Linux kernel, but with the same packing parameters the pack file is almost 10 times larger. It's true that many kernel patches are little more than one-liners, but even taking this into account, I'm surprised. I'm starting to pull the rest of the branches now, but I am also a little surprised at the difference. Harvey
Re: [OT] Re: Git repository with full GCC history
Harvey Harrison wrote: I get about 1.4 GB for the pack with the default depth and window parameters. I forgot to mention that I obtained an ~800MB repository with git 1.5.0.x after increasing the window size to 20. The defaults changed significantly somewhere near version 1.5.1 I believe with the delta caching mechanism making it much less expensive to use a deeper delta depth. Did you enable UseDeltaBaseOffset perhaps? Or any of the git-gc configuration parameters? I suspecet I may have huge loose objects created by git-svn because of how it does branching and rebasing. I don't know what Harvey is up to, he claimed his tree was between 400 and 500 MB. Sorry, my mistake, the repo I was looking at only contained a clone of trunk. Mine too. I have not cloned the branches. I'm starting to pull the rest of the branches now, but I am also a little surprised at the difference. Please, make your tree available for inspection. -- // Bernardo Innocenti \X/ http://www.codewiz.org/
Re: [OT] Re: Git repository with full GCC history
On 6/3/07, Bernardo Innocenti <[EMAIL PROTECTED]> wrote: Harvey Harrison wrote: >> I get about 1.4 GB for the pack with the default >> depth and window parameters. I forgot to mention that I obtained an ~800MB repository with git 1.5.0.x after increasing the window size to 20. Now I don't know what is going on, I tried to reproduce my packfile and get a 1.4GB packfile. But I'm sure I redid the same operations? I'd just disregard my size numbers until I can figure out what I've done wrong. > The defaults changed significantly somewhere near version 1.5.1 I > believe with the delta caching mechanism making it much less expensive > to use a deeper delta depth. Did you enable UseDeltaBaseOffset perhaps? Or any of the git-gc configuration parameters? I did recently upgrade to the tip of 'next' branch of git, will go back to my previous version. I have set [core] legacyheaders = false [repack] usedeltabaseoffset = true in my .gitconfig. Please, make your tree available for inspection. If I can reproduce it I'll see if I can find some webspace. Harvey
Libjava is broken again
This patch
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00151.html
breaks libjava. One problem is it modifies
libjava/classpath/m4/acinclude.m4
without ChangeLog entry. I believe this one
- if test "x${GCJ}" = x && test "x${JIKES}" = x && test
"x${user_specified_javac}" != xkjc && test "x${user_specified_javac}" != xgcjx
&& test "x${user_specified_javac}" != xecj; then
- AC_MSG_ERROR([cannot find javac, try --with-gcj, --with-jikes,
--with-kjc, --with-ecj, or --with-gcjx])
+dnl if test "x${GCJ}" = x && test "x${JIKES}" = x && test
"x${user_specified_javac}" != xkjc; then
+ if test "x${ECJ}" = x && test "x${JAVAC}" = x && test
"x${user_specified_javac}" != xecj; then
changes to check ${ECJ} instead of ${GCJ}, which breaks libjava
build.
H.J.
---
Index: m4/acinclude.m4
===
--- m4/acinclude.m4 (revision 125301)
+++ m4/acinclude.m4 (working copy)
@@ -8,23 +8,25 @@
CLASSPATH_WITH_GCJ
CLASSPATH_WITH_JIKES
CLASSPATH_WITH_KJC
- CLASSPATH_WITH_GCJX
CLASSPATH_WITH_ECJ
+ CLASSPATH_WITH_JAVAC
if test "x${user_specified_javac}" = x; then
AM_CONDITIONAL(FOUND_GCJ, test "x${GCJ}" != x)
AM_CONDITIONAL(FOUND_JIKES, test "x${JIKES}" != x)
AM_CONDITIONAL(FOUND_ECJ, test "x${ECJ}" != x)
+AM_CONDITIONAL(FOUND_JAVAC, test "x${JAVAC}" != x)
else
AM_CONDITIONAL(FOUND_GCJ, test "x${user_specified_javac}" = xgcj)
AM_CONDITIONAL(FOUND_JIKES, test "x${user_specified_javac}" = xjikes)
AM_CONDITIONAL(FOUND_ECJ, test "x${user_specified_javac}" = xecj)
+AM_CONDITIONAL(FOUND_JAVAC, test "x${user_specified_javac}" = xjavac)
fi
AM_CONDITIONAL(FOUND_KJC, test "x${user_specified_javac}" = xkjc)
- AM_CONDITIONAL(FOUND_GCJX, test "x${user_specified_javac}" = xgcjx)
- if test "x${GCJ}" = x && test "x${JIKES}" = x && test
"x${user_specified_javac}" != xkjc && test "x${user_specified_javac}" != xgcjx
&& test "x${user_specified_javac}" != xecj; then
- AC_MSG_ERROR([cannot find javac, try --with-gcj, --with-jikes,
--with-kjc, --with-ecj, or --with-gcjx])
+dnl if test "x${GCJ}" = x && test "x${JIKES}" = x && test
"x${user_specified_javac}" != xkjc; then
+ if test "x${ECJ}" = x && test "x${JAVAC}" = x && test
"x${user_specified_javac}" != xecj; then
+ AC_MSG_ERROR([cannot find javac, try --with-ecj])
fi
])
@@ -184,41 +186,6 @@
])
dnl ---
-AC_DEFUN([CLASSPATH_WITH_GCJX],
-[
- AC_ARG_WITH([gcjx],
- [AS_HELP_STRING(--with-gcjx,bytecode compilation with gcjx)],
- [
-if test "x${withval}" != x && test "x${withval}" != xyes && test
"x${withval}" != xno; then
- CLASSPATH_CHECK_GCJX(${withval})
-else
- if test "x${withval}" != xno; then
-CLASSPATH_CHECK_GCJX
- fi
-fi
-user_specified_javac=gcjx
- ],
- [
-CLASSPATH_CHECK_GCJX
- ])
- AC_SUBST(GCJX)
-])
-
-dnl ---
-AC_DEFUN([CLASSPATH_CHECK_GCJX],
-[
- if test "x$1" != x; then
-if test -f "$1"; then
- GCJX="$1"
-else
- AC_PATH_PROG(GCJX, "$1")
-fi
- else
-AC_PATH_PROG(GCJX, "gcjx")
- fi
-])
-
-dnl ---
AC_DEFUN([CLASSPATH_WITH_JAVAH],
[
AC_ARG_WITH([javah],
@@ -471,3 +438,38 @@
esac
AC_SUBST(toolexeclibdir)
])
+
+dnl ---
+AC_DEFUN([CLASSPATH_WITH_JAVAC],
+[
+ AC_ARG_WITH([javac],
+ [AS_HELP_STRING(--with-javac,bytecode compilation with javac)],
+ [
+if test "x${withval}" != x && test "x${withval}" != xyes && test
"x${withval}" != xno; then
+ CLASSPATH_CHECK_JAVAC(${withval})
+else
+ if test "x${withval}" != xno; then
+CLASSPATH_CHECK_JAVAC
+ fi
+fi
+user_specified_javac=javac
+ ],
+ [
+CLASSPATH_CHECK_JAVAC
+ ])
+ AC_SUBST(JAVAC)
+])
+
+dnl ---
+AC_DEFUN([CLASSPATH_CHECK_JAVAC],
+[
+ if test "x$1" != x; then
+if test -f "$1"; then
+ JAVAC="$1"
+else
+ AC_PATH_PROG(JAVAC, "$1")
+fi
+ else
+AC_PATH_PROG(JAVAC, "javac")
+ fi
+])
