bubblestrap and gnat: is gnat always rebuilt whenever I bubblestrap gcc?
Is it just me...or? I get the feeling that if I first bootstrap gcc, then update some files, then bubblestrap to check again... that gnat and friends get rebuilt? I really like bubblestrap, it gets me a shorter time to test a patch or so. However, if gnat and friends somehow are more sensitively dependent on source changes... I am hesitant to bootstrap with Ada... Is there anyone else that can confirm my feeling with some in depth facts... or am I simply misguided by my feeling? -- Cheers, /ChJ
Re: [gfortran] add ISATTY and TTYNAM intrinsics
FX,
I forgot to mention that since the gcc cvs I built last night now
contains your ISATTY and TTYNAM intrinsics patch, I regressed the
portion of the xplor.patch which worked around the prior absence
of the ISATTY intrinsic in gfortran. The resulting xplor-nih build
works fine.
One other question. Do you know much c++? I had to make one change
to some buggy c++ code to allow gcc 4.0 and main branch to compile
xplor-nih...
--- xplor-nih-2.11.2.1/intVar/dint-loop.cc 2004-04-16 18:06:07.0 -0
400
+++ xplor-nih-2.11.2.1.g95/intVar/dint-loop.cc 2005-07-24 17:41:11.0 -0
400
@@ -50,6 +50,8 @@
tip1(tip1), tip2(tip2)
{} /* Loop::Loop */
+class LoopWNodes;
+
static int compareLevel(const LoopWNodes& l1,//forward declarations
const LoopWNodes& l2);
//static bool sameBranch(const HingeNode* tip,
...to work around the problem described in...
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159445
With that change, all of the c++ code in xplor-nih compiles against
gcc 4.0 branch, however I find that gcc main branch yields another
compilation error...
g++-4 -fstack-protector-all -c _cdsVector.cc -O3 -fPIC -mtune=970 -g
-DX_MMAP_FLAGS=0 -DFORTRAN_INIT -fno-common -DDARWIN -D_REENTRANT -
DNDEBUG -I/Users/howarth/Desktop/xplor-nih-2.11.2.1/python/ -I/Users/
howarth/Desktop/xplor-nih-2.11.2.1/arch/Darwin_8/include -I/Users/
howarth/Desktop/xplor-nih-2.11.2.1/python/swig_wrappers -DCPLUSPLUS -
DUSE_CDS_NAMESPACE -I/Users/howarth/Desktop/xplor-nih-2.11.2.1/
python/ -I/Users/howarth/Desktop/xplor-nih-2.11.2.1/arch/Darwin_8/
include -DSWIGPY_GLOBAL -I. -I/System/Library/Frameworks/
Python.framework/Versions/2.3/include/python2.3 -I/Users/howarth/
Desktop/xplor-nih-2.11.2.1/CDSlib -I/Users/howarth/Desktop/xplor-
nih-2.11.2.1/common -I/Users/howarth/Desktop/xplor-nih-2.11.2.1/
intVar -I/Users/howarth/Desktop/xplor-nih-2.11.2.1/nmrPot -I/Users/
howarth/Desktop/xplor-nih-2.11.2.1/vmd -I/Users/howarth/Desktop/xplor-
nih-2.11.2.1/devel -DNIHXPLOR_VERSION='"2.11.2.1-custom"' -
DSWIGPY_NOINCLUDE )
_cdsVector.cc: In function 'CDSVector
CDSVector_Sl_int_Sgpow__(CDSVector*,
const float_type&)':
_cdsVector.cc:1155: warning: converting to 'int' from 'double'
/Users/howarth/Desktop/xplor-nih-2.11.2.1/CDSlib/cdsVector.hh: In
member function 'CDSVectorBase& CDSVectorBase::operator*=(const T1&) [with T1 = double, T = int, ALLOC =
CDS::DefaultAlloc]':
_cdsVector.cc:1159: instantiated from here
/Users/howarth/Desktop/xplor-nih-2.11.2.1/CDSlib/cdsVector.hh:239:
warning: converting to 'int' from 'double'
_cdsVector.cc: In function 'T sum(const CDSVector&) [with T = int]':
_cdsVector.cc:2408: instantiated from here
_cdsVector.cc:913: warning: converting to 'int' from 'double'
_cdsVector.cc: In function 'CDSVector
sqrt(const CDSVector&) [with T = int]':
_cdsVector.cc:2457: instantiated from here
_cdsVector.cc:924: error: no matching function for call to 'norm
(const int&)'
_cdsVector.cc: In function 'CDSVector
norm(const CDSVector&) [with T = int]':
_cdsVector.cc:2510: instantiated from here
_cdsVector.cc:933: error: no matching function for call to 'norm
(const int&)'
_cdsVector.cc: In function 'CDSVector
sqrt(const CDSVector&) [with T = double]':
_cdsVector.cc:3945: instantiated from here
_cdsVector.cc:924: error: no matching function for call to 'norm
(const double&)'
_cdsVector.cc: In function 'CDSVector
norm(const CDSVector&) [with T = double]':
_cdsVector.cc:3998: instantiated from here
_cdsVector.cc:933: error: no matching function for call to 'norm
(const double&)'
which compares to gcc 4.0 branch that just yields some warnings on
the same file...
_cdsVector.cc: In function 'CDSVector
CDSVector_Sl_int_Sgpow__(CDSVector*, const
float_type&)':
_cdsVector.cc:1155: warning: converting to 'int' from 'double'
./cdsVector.hh: In member function 'CDSVectorBase& CDSVectorBase::operator*=(const T1&) [with T1 = double, T = int, ALLOC = CDS::
DefaultAlloc]':
_cdsVector.cc:1159: instantiated from here
./cdsVector.hh:239: warning: converting to 'int' from 'double'
_cdsVector.cc: In function 'T sum(const CDSVector&)
[with T = int]':
_cdsVector.cc:2408: instantiated from here
_cdsVector.cc:913: warning: converting to 'int' from 'double'
I am trying to figure out if this is catching some new buggy c++ which
is no longer accepted by the g++ compiler in gcc 4.1 or if this is a
regression in that branch.
Jack
Re: [gfortran] add ISATTY and TTYNAM intrinsics
One other question. Do you know much c++? I had to make one change to some buggy c++ code to allow gcc 4.0 and main branch to compile xplor-nih... I'm sorry but i don't know anything more about c++ than its name. About your problem, i'd guess that you could try to create a reduced preprocessed testcase and file this regression in bugzilla. FX
PATCH: Enable FTZ/DAZ for SSE via fast math
On Tue, Aug 09, 2005 at 02:58:51PM -0700, Richard Henderson wrote:
> On Tue, Aug 09, 2005 at 02:30:46PM -0700, H. J. Lu wrote:
> > There is a minor problem. How can I add crtfastmath.o for SSE targets
> > only?
>
> You don't. You either add code to detect sse, or you make the
> spec depend on -mfpmath=sse.
>
Here is the patch to enable FTZ/DAZ for SSE via fast math. There are
no regressions on Linux/x86_64 nor Linux/ia32. The performance of one
FP benchmark on EM64T is more than doubled with -ffast-math.
H.J.
---
2005-08-09 H.J. Lu <[EMAIL PROTECTED]>
* config.gcc (i[34567]86-*-linux*): Add i386/t-crtfm to tm-file.
(x86_64-*-linux*): Likewise.
* config/i386/crtfastmath.c: New file.
* config/i386/t-crtfm: Likewise.
* config/i386/linux.h (ENDFILE_SPEC): New.
* config/i386/linux64.h (ENDFILE_SPEC): Likewise.
* config/i386/t-linux64 (EXTRA_MULTILIB_PARTS): Add
crtfastmath.o.
--- gcc/config.gcc.sse 2005-08-06 07:22:06.0 -0700
+++ gcc/config.gcc 2005-08-09 15:09:16.313927259 -0700
@@ -1001,7 +1001,7 @@ i[34567]86-*-linux* | i[34567]86-*-kfree
i[34567]86-*-knetbsd*-gnu) tm_file="${tm_file} knetbsd-gnu.h
i386/knetbsd-gnu.h" ;;
i[34567]86-*-kfreebsd*-gnu) tm_file="${tm_file} kfreebsd-gnu.h
i386/kfreebsd-gnu.h" ;;
esac
- tmake_file="${tmake_file} i386/t-crtstuff"
+ tmake_file="${tmake_file} i386/t-crtstuff i386/t-crtfm"
;;
x86_64-*-linux* | x86_64-*-kfreebsd*-gnu | x86_64-*-knetbsd*-gnu)
tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h svr4.h
linux.h \
@@ -1010,7 +1010,7 @@ x86_64-*-linux* | x86_64-*-kfreebsd*-gnu
x86_64-*-kfreebsd*-gnu) tm_file="${tm_file} kfreebsd-gnu.h" ;;
x86_64-*-knetbsd*-gnu) tm_file="${tm_file} knetbsd-gnu.h" ;;
esac
- tmake_file="${tmake_file} i386/t-linux64"
+ tmake_file="${tmake_file} i386/t-linux64 i386/t-crtfm"
;;
i[34567]86-*-gnu*)
;;
--- gcc/config/i386/crtfastmath.c.sse 2005-08-09 15:09:39.634095529 -0700
+++ gcc/config/i386/crtfastmath.c 2005-08-09 15:29:01.796141023 -0700
@@ -0,0 +1,52 @@
+/*
+ * Copyright (C) 2005 Free Software Foundation, Inc.
+ *
+ * This file is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2, or (at your option) any
+ * later version.
+ *
+ * In addition to the permissions in the GNU General Public License, the
+ * Free Software Foundation gives you unlimited permission to link the
+ * compiled version of this file with other programs, and to distribute
+ * those programs without any restriction coming from the use of this
+ * file. (The General Public License restrictions do apply in other
+ * respects; for example, they cover modification of the file, and
+ * distribution when not linked into another program.)
+ *
+ * This file is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; see the file COPYING. If not, write to
+ * the Free Software Foundation, 59 Temple Place - Suite 330,
+ * Boston, MA 02111-1307, USA.
+ *
+ *As a special exception, if you link this library with files
+ *compiled with GCC to produce an executable, this does not cause
+ *the resulting executable to be covered by the GNU General Public License.
+ *This exception does not however invalidate any other reasons why
+ *the executable file might be covered by the GNU General Public License.
+ */
+
+#define MXCSR_DAZ (1 << 6) /* Enable denormals are zero mode */
+#define MXCSR_FTZ (1 << 15)/* Enable flush to zero mode */
+
+static void __attribute__((constructor))
+set_fast_math (void)
+{
+ /* Check if SSE is available. */
+ unsigned int eax, ebx, ecx, edx;
+ asm volatile ("xchgl %%ebx, %1; cpuid; xchgl %%ebx, %1"
+ : "=a" (eax), "=r" (ebx), "=c" (ecx), "=d" (edx)
+ : "0" (1));
+
+ if (edx & (1 << 25))
+{
+ unsigned int mxcsr = __builtin_ia32_stmxcsr ();
+ mxcsr |= MXCSR_DAZ | MXCSR_FTZ;
+ __builtin_ia32_ldmxcsr (mxcsr);
+}
+}
--- gcc/config/i386/linux.h.sse 2004-11-28 17:04:42.0 -0800
+++ gcc/config/i386/linux.h 2005-08-09 14:22:44.554244342 -0700
@@ -121,6 +121,12 @@ Boston, MA 02111-1307, USA. */
%{!dynamic-linker:-dynamic-linker %(dynamic_linker)}} \
%{static:-static}}}"
+/* Similar to standard Linux, but adding -ffast-math support. */
+#undef ENDFILE_SPEC
+#define ENDFILE_SPEC \
+ "%{ffast-math|funsafe-math-optimizations:crtfastmath.o%s} \
+ %{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s"
+
/* A C statement (sans semicolon) to output to the st
Re: PATCH: Enable FTZ/DAZ for SSE via fast math
On Wed, Aug 10, 2005 at 07:09:04AM -0700, H. J. Lu wrote:
> On Tue, Aug 09, 2005 at 02:58:51PM -0700, Richard Henderson wrote:
> > On Tue, Aug 09, 2005 at 02:30:46PM -0700, H. J. Lu wrote:
> > > There is a minor problem. How can I add crtfastmath.o for SSE targets
> > > only?
> >
> > You don't. You either add code to detect sse, or you make the
> > spec depend on -mfpmath=sse.
> >
>
> Here is the patch to enable FTZ/DAZ for SSE via fast math. There are
> no regressions on Linux/x86_64 nor Linux/ia32. The performance of one
> FP benchmark on EM64T is more than doubled with -ffast-math.
Not all i?86 CPUs support cpuid instruction.
Please look at
gcc/testsuite/gcc.dg/i386-cpuid.h
for the ugly details.
> +static void __attribute__((constructor))
> +set_fast_math (void)
> +{
> + /* Check if SSE is available. */
> + unsigned int eax, ebx, ecx, edx;
> + asm volatile ("xchgl %%ebx, %1; cpuid; xchgl %%ebx, %1"
> + : "=a" (eax), "=r" (ebx), "=c" (ecx), "=d" (edx)
> + : "0" (1));
> +
> + if (edx & (1 << 25))
> +{
> + unsigned int mxcsr = __builtin_ia32_stmxcsr ();
> + mxcsr |= MXCSR_DAZ | MXCSR_FTZ;
> + __builtin_ia32_ldmxcsr (mxcsr);
> +}
> +}
Jakub
Re: PATCH: Enable FTZ/DAZ for SSE via fast math
On Wed, Aug 10, 2005 at 10:18:41AM -0400, Jakub Jelinek wrote: > On Wed, Aug 10, 2005 at 07:09:04AM -0700, H. J. Lu wrote: > > On Tue, Aug 09, 2005 at 02:58:51PM -0700, Richard Henderson wrote: > > > On Tue, Aug 09, 2005 at 02:30:46PM -0700, H. J. Lu wrote: > > > > There is a minor problem. How can I add crtfastmath.o for SSE targets > > > > only? > > > > > > You don't. You either add code to detect sse, or you make the > > > spec depend on -mfpmath=sse. > > > > > > > Here is the patch to enable FTZ/DAZ for SSE via fast math. There are > > no regressions on Linux/x86_64 nor Linux/ia32. The performance of one > > FP benchmark on EM64T is more than doubled with -ffast-math. > > Not all i?86 CPUs support cpuid instruction. > Please look at > gcc/testsuite/gcc.dg/i386-cpuid.h > for the ugly details. > Ok. Also all x86_64 supports SSE. There is no need to check that in 64bit. H.J.
Re: PATCH: Enable FTZ/DAZ for SSE via fast math
On Wed, Aug 10, 2005 at 08:13:17AM -0700, H. J. Lu wrote:
> On Wed, Aug 10, 2005 at 10:18:41AM -0400, Jakub Jelinek wrote:
> > On Wed, Aug 10, 2005 at 07:09:04AM -0700, H. J. Lu wrote:
> > > On Tue, Aug 09, 2005 at 02:58:51PM -0700, Richard Henderson wrote:
> > > > On Tue, Aug 09, 2005 at 02:30:46PM -0700, H. J. Lu wrote:
> > > > > There is a minor problem. How can I add crtfastmath.o for SSE targets
> > > > > only?
> > > >
> > > > You don't. You either add code to detect sse, or you make the
> > > > spec depend on -mfpmath=sse.
> > > >
> > >
> > > Here is the patch to enable FTZ/DAZ for SSE via fast math. There are
> > > no regressions on Linux/x86_64 nor Linux/ia32. The performance of one
> > > FP benchmark on EM64T is more than doubled with -ffast-math.
> >
> > Not all i?86 CPUs support cpuid instruction.
> > Please look at
> > gcc/testsuite/gcc.dg/i386-cpuid.h
> > for the ugly details.
> >
>
> Ok. Also all x86_64 supports SSE. There is no need to check that in
> 64bit.
>
>
Here is the updated patch.
H.J.
---
2005-08-10 H.J. Lu <[EMAIL PROTECTED]>
* config.gcc (i[34567]86-*-linux*): Add i386/t-crtfm to tm-file.
(x86_64-*-linux*): Likewise.
* config/i386/crtfastmath.c: New file.
* config/i386/t-crtfm: Likewise.
* config/i386/linux.h (ENDFILE_SPEC): New.
* config/i386/linux64.h (ENDFILE_SPEC): Likewise.
* config/i386/t-linux64 (EXTRA_MULTILIB_PARTS): Add
crtfastmath.o.
--- gcc/config.gcc.sse 2005-08-09 16:18:14.0 -0700
+++ gcc/config.gcc 2005-08-09 16:18:15.0 -0700
@@ -1006,7 +1006,7 @@ i[34567]86-*-linux* | i[34567]86-*-kfree
i[34567]86-*-knetbsd*-gnu) tm_file="${tm_file} knetbsd-gnu.h
i386/knetbsd-gnu.h" ;;
i[34567]86-*-kfreebsd*-gnu) tm_file="${tm_file} kfreebsd-gnu.h
i386/kfreebsd-gnu.h" ;;
esac
- tmake_file="${tmake_file} i386/t-crtstuff"
+ tmake_file="${tmake_file} i386/t-crtstuff i386/t-crtfm"
;;
x86_64-*-linux* | x86_64-*-kfreebsd*-gnu | x86_64-*-knetbsd*-gnu)
tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h svr4.h
linux.h \
@@ -1015,7 +1015,7 @@ x86_64-*-linux* | x86_64-*-kfreebsd*-gnu
x86_64-*-kfreebsd*-gnu) tm_file="${tm_file} kfreebsd-gnu.h" ;;
x86_64-*-knetbsd*-gnu) tm_file="${tm_file} knetbsd-gnu.h" ;;
esac
- tmake_file="${tmake_file} i386/t-linux64"
+ tmake_file="${tmake_file} i386/t-linux64 i386/t-crtfm"
;;
i[34567]86-*-gnu*)
;;
--- gcc/config/i386/crtfastmath.c.sse 2005-08-09 16:18:15.0 -0700
+++ gcc/config/i386/crtfastmath.c 2005-08-10 08:47:24.207266245 -0700
@@ -0,0 +1,72 @@
+/*
+ * Copyright (C) 2005 Free Software Foundation, Inc.
+ *
+ * This file is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2, or (at your option) any
+ * later version.
+ *
+ * In addition to the permissions in the GNU General Public License, the
+ * Free Software Foundation gives you unlimited permission to link the
+ * compiled version of this file with other programs, and to distribute
+ * those programs without any restriction coming from the use of this
+ * file. (The General Public License restrictions do apply in other
+ * respects; for example, they cover modification of the file, and
+ * distribution when not linked into another program.)
+ *
+ * This file is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; see the file COPYING. If not, write to
+ * the Free Software Foundation, 59 Temple Place - Suite 330,
+ * Boston, MA 02111-1307, USA.
+ *
+ *As a special exception, if you link this library with files
+ *compiled with GCC to produce an executable, this does not cause
+ *the resulting executable to be covered by the GNU General Public License.
+ *This exception does not however invalidate any other reasons why
+ *the executable file might be covered by the GNU General Public License.
+ */
+
+#define MXCSR_DAZ (1 << 6) /* Enable denormals are zero mode */
+#define MXCSR_FTZ (1 << 15)/* Enable flush to zero mode */
+
+static void __attribute__((constructor))
+set_fast_math (void)
+{
+#ifndef __x86_64__
+ /* SSE is the part of 64bit. Only need to check it for 32bit. */
+ unsigned int eax, ebx, ecx, edx;
+
+ /* See if we can use cpuid. */
+ asm volatile ("pushfl; pushfl; popl %0; movl %0,%1; xorl %2,%0;"
+ "pushl %0; popfl; pushfl; popl %0; popfl"
+ : "=&r" (eax), "=&r" (ebx)
+ : "i" (0x0020));
+
+ if (((eax ^ ebx) & 0x0020) == 0)
+return;
+
+ /* Check the highest input
Re: [patch] Fix i386-mingw32 build failure
Christopher Faylor wrote: This would conflict with my proposed changes to pex-win32.c . It seems like getting '#!' functioning on mingw would be a better solution than relying on $(LN) on mingw. FWIW, I'm opposed to the "#!" change to MinGW. It just seems hackish to me, and it means that we'll pay an additional cost on all normal uses of pex-* on MinGW, even after the compiler is installed. The correct solution to this is to install the assemblers and linkers before building the compiler, in places that the compiler expects to find them, on all systems, in all configurations, and then totally avoid the symlinks/copies/etc. out of the main tree. I realize that people who do one-tree builds will object, but my answer to that is just that there should be an installation stage between building binutils and building gcc. The even more correct solution is to not build anything with the compiler (including libgcc) until after it is installed. Then, it will just look where it would normally look, and all will be well. However, I also recognize that we need to do something before 4.1 to fix this problem and that we need something simple enough to be viable in that timeframe. But, if Paolo can fix this without having to add #!, I think that would be great. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: PATCH: Enable FTZ/DAZ for SSE via fast math
On Wed, Aug 10, 2005 at 08:48:44AM -0700, H. J. Lu wrote: > * config.gcc (i[34567]86-*-linux*): Add i386/t-crtfm to tm-file. > (x86_64-*-linux*): Likewise. > > * config/i386/crtfastmath.c: New file. > * config/i386/t-crtfm: Likewise. > > * config/i386/linux.h (ENDFILE_SPEC): New. > * config/i386/linux64.h (ENDFILE_SPEC): Likewise. > > * config/i386/t-linux64 (EXTRA_MULTILIB_PARTS): Add > crtfastmath.o. Ok. r~
Re: [patch] Fix i386-mingw32 build failure
On Wed, Aug 10, 2005 at 10:05:26AM -0700, Mark Mitchell wrote: > Christopher Faylor wrote: > > >This would conflict with my proposed changes to pex-win32.c . It seems > >like getting '#!' functioning on mingw would be a better solution than > >relying on $(LN) on mingw. > > FWIW, I'm opposed to the "#!" change to MinGW. It just seems hackish to > me, and it means that we'll pay an additional cost on all normal uses of > pex-* on MinGW, even after the compiler is installed. Not if it's implemented after CreateProcess fails, we won't. I don't think your argument applies. -- Daniel Jacobowitz CodeSourcery, LLC
Re: [patch] Fix i386-mingw32 build failure
Daniel Jacobowitz wrote: On Wed, Aug 10, 2005 at 10:05:26AM -0700, Mark Mitchell wrote: Christopher Faylor wrote: This would conflict with my proposed changes to pex-win32.c . It seems like getting '#!' functioning on mingw would be a better solution than relying on $(LN) on mingw. FWIW, I'm opposed to the "#!" change to MinGW. It just seems hackish to me, and it means that we'll pay an additional cost on all normal uses of pex-* on MinGW, even after the compiler is installed. Not if it's implemented after CreateProcess fails, we won't. I don't think your argument applies. Good point! I still think it's a bad solution, though; it's imposing special semantics for process execution in libiberty, rather than the normal ones that you would expect from the OS. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: [patch] Fix i386-mingw32 build failure
On Wed, Aug 10, 2005 at 10:38:26AM -0700, Mark Mitchell wrote: >Daniel Jacobowitz wrote: >>On Wed, Aug 10, 2005 at 10:05:26AM -0700, Mark Mitchell wrote: >> >>>Christopher Faylor wrote: >>> >>> This would conflict with my proposed changes to pex-win32.c . It seems like getting '#!' functioning on mingw would be a better solution than relying on $(LN) on mingw. >>> >>>FWIW, I'm opposed to the "#!" change to MinGW. It just seems hackish to >>>me, and it means that we'll pay an additional cost on all normal uses of >>>pex-* on MinGW, even after the compiler is installed. >> >> >>Not if it's implemented after CreateProcess fails, we won't. I don't >>think your argument applies. > >Good point! > >I still think it's a bad solution, though; it's imposing special >semantics for process execution in libiberty, rather than the normal >ones that you would expect from the OS. Aren't the pex* functions designed to provide a uniform interface where "uniform" means "like unix"? cgf
Re: [patch] Fix i386-mingw32 build failure
> I still think it's a bad solution, though; it's imposing special > semantics for process execution in libiberty, rather than the normal > ones that you would expect from the OS. Doing that is part of the purpose of libiberty. If the OS does something unusual, we try to make it act in a conforming way, so that the rest of the tools need not worry about the OS differences. Adding support for #! scripts is one of the ways we can make MinGW more conforming (Cygwin and DJGPP already support #!) to the norm.
Re: [patch] Fix i386-mingw32 build failure
> Aren't the pex* functions designed to provide a uniform interface > where "uniform" means "like unix"? Uniform, yes. "Like Unix" is a coincidence, not a goal. Sometimes we hide a unix-specific feature because we can't mimic it elsewhere (like simultaneous multithreading) but we prefer to add or wrap functionality (like #! support).
Re: [patch] Fix i386-mingw32 build failure
Christopher Faylor wrote: Aren't the pex* functions designed to provide a uniform interface where "uniform" means "like unix"? I guess I'm not the right person to answer that... I think they are designed to provide a uniform interface to process creation, etc. that is a lowest-common-denominator across systems. Running scripts seems to me outside of scope. I certainly think that this is a topic on which people could reasonably disagree. Part of my concern is that we seem to be adding to the complexity of our already baroque build process, in lieu of just attacking the problem head-on. Even a new driver option for additional directories to search seems better to me. However, by the time I write this, I see that DJ -- who is a right person to answer to talk about the purpose of libiberty -- thinks #! is a good idea. So, consider me the loyal opposition; let's get on with the fix you and DJ like. :-) -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: [patch] Fix i386-mingw32 build failure
On Wed, Aug 10, 2005 at 02:35:41PM -0400, DJ Delorie wrote: > > > I still think it's a bad solution, though; it's imposing special > > semantics for process execution in libiberty, rather than the normal > > ones that you would expect from the OS. > > Doing that is part of the purpose of libiberty. If the OS does > something unusual, we try to make it act in a conforming way, so that > the rest of the tools need not worry about the OS differences. Adding > support for #! scripts is one of the ways we can make MinGW more > conforming (Cygwin and DJGPP already support #!) to the norm. I'm inclined to agree that this seems like a natural use of libiberty; the purpose all along has been to isolate OS differences, fill in missing functions, etc. Mark, can you think of any specific negative consequences?
Re: [patch] Fix i386-mingw32 build failure
> I think they are designed to provide a uniform interface to process > creation, etc. that is a lowest-common-denominator across systems. I think a better term is "highest common denominator". We *do* want to enhance systems when we can, because that makes it easier for the application developers. It's only the cases where we *can't* enhance a system that we have to limit everyone else. In the case of #!, since *all* process creation goes through libiberty, it's trivially easy to have libiberty look for the #! and support it on *any* platform that doesn't already support it. Why make app developers suffer without shell scripts when it's easy to make them globally supported? > Part of my concern is that we seem to be adding to the complexity of > our already baroque build process, in lieu of just attacking the > problem head-on. Well, if everyone supports shell scripts, that's less configury and Makefile madness outside of libiberty. > Even a new driver option for additional directories to search seems > better to me. Supporting #! in libiberty doesn't have to stop you from enhancing gcc anyway ;-)
Re: [patch] Fix i386-mingw32 build failure
On Wed, Aug 10, 2005 at 11:41:30AM -0700, Mark Mitchell wrote: >However, by the time I write this, I see that DJ -- who is a right >person to answer to talk about the purpose of libiberty -- thinks #! is >a good idea. So, consider me the loyal opposition; let's get on with >the fix you and DJ like. :-) Not to beat a dead horse, but this was all decided two weeks ago between DJ as the libiberty/configury maintainer and Danny Smith and I as the windows maintainers. So, I would submit that the right people had already made the decision. I wouldn't have volunteered to make a change to libiberty without DJ's blessing of the idea. I'm building a compiler now to check out my changes. cgf
[RFC] - Regression exposed by recent change to compress_float_constant
Following patch has exposed an optimization shortcoming:
2005-07-12 Dale Johannesen <[EMAIL PROTECTED]>
* expr.c (compress_float_constant): Add cost check.
* config/rs6000.c (rs6000_rtx_cost): Adjust FLOAT_EXTEND cost.
This patch results in generating worse code for the following test case:
1) Test case:
struct S {
float d1, d2, d3;
};
S ms()
{
struct S s = {0,0,0};
return s;
}
With: -O1 -mdynamic-no-pic -march=pentium4 -mtune=prescott, gcc now
generates
pxor%xmm0, %xmm0
movsd %xmm0, (%eax)
...
Instead of:
movl$0, (%eax)
movl$0, 4(%eax)
This is because change to compress_float_constant has changed the RTL
pattern which cse cannot optimize:
Before above patch compress_float_constant generated:
(insn 12 7 13 0 (set (reg:SF 59)
(mem/u/i:SF (symbol_ref/u:SI ("*LC0") [flags 0x2]) [0 S4
A32])) -1 (nil)
(nil))
(insn 13 12 14 0 (set (mem/s/j:DF (reg/f:SI 58 [ D.1929 ]) [0
.d1+0 S8 A32])
(float_extend:DF (reg:SF 59))) -1 (nil)
(nil))
Which cse was then able to constant propagate double 0.0, resulting
in the following pattern:
(insn 13 7 15 0 (set (mem/s/j:DF (reg/f:SI 58 [ D.1929 ]) [0
.d1+0 S8 A32])
(const_double:DF 0.0 [0x0.0p+0])) 64 {*movdf_nointeger} (nil)
(nil))
With the latest gcc (which includes above patch):
compress_float_constant's new cost computation disallows generation
of float_extend:DF. cse is then faced with the new pattern:
(insn 12 11 13 0 s.C:7 (set (reg:DF 59)
(mem/u/i:DF (symbol_ref/u:SI ("*LC0") [flags 0x2]) [0 S8
A64])) -1 (nil)
(nil))
(insn 13 12 14 0 s.C:7 (set (mem/s/j:DF (reg/f:SI 58 [ D.1929 ]) [0
.d1+0 S8 A32])
(reg:DF 59)) -1 (nil)
(nil))
As soon as it sees a REG node as source, it gives up.
What is the right way to restore this optimization again:
1) Can cse be taught to constant propagate when source is a REG rtl?
Why this was never attempted before. Fixing up cse seems to fix both
the double float as well as single float case (which is not impacted
by above patch).
2) For the double float case (as illustrated by above test case), can
we twik compress_float_constant to not use the cost computation of
RHS when LHS is store to a memory. This fixes the performance
regressions and caused no regression. Attached patch is what I tried.
3) Any other approrach?
- Thanks, fariborz
Index: expr.c
===
RCS file: /cvs/gcc/gcc/gcc/expr.c,v
retrieving revision 1.778.4.5
diff -c -p -r1.778.4.5 expr.c
*** expr.c 13 Jul 2005 01:07:47 - 1.778.4.5
--- expr.c 10 Aug 2005 18:55:49 -
*** compress_float_constant (rtx x, rtx y)
*** 3187,3196
the extension. */
if (! (*insn_data[ic].operand[1].predicate) (trunc_y,
srcmode))
continue;
! /* This is valid, but may not be cheaper than the original. */
! newcost = rtx_cost (gen_rtx_FLOAT_EXTEND (dstmode,
trunc_y), SET);
! if (oldcost < newcost)
! continue;
}
else if (float_extend_from_mem[dstmode][srcmode])
{
--- 3187,3199
the extension. */
if (! (*insn_data[ic].operand[1].predicate) (trunc_y,
srcmode))
continue;
! if (!MEM_P (x))
! {
! /* This is valid, but may not be cheaper than the
original. */
! newcost = rtx_cost (gen_rtx_FLOAT_EXTEND (dstmode,
trunc_y), SET);
! if (oldcost < newcost && (!MEM_P (x)) )
! continue;
! }
}
else if (float_extend_from_mem[dstmode][srcmode])
{
Re: [RFC] - Regression exposed by recent change to compress_float_constant
> > Following patch has exposed an optimization shortcoming: > > 2005-07-12 Dale Johannesen <[EMAIL PROTECTED]> > > * expr.c (compress_float_constant): Add cost check. > * config/rs6000.c (rs6000_rtx_cost): Adjust FLOAT_EXTEND cost. I think this is the same problem as PR 23098 which shows we fail to optimizate it from before that change. -- Pinski
Re: [patch] Fix i386-mingw32 build failure
DJ Delorie wrote: >Supporting #! in libiberty doesn't have to stop you from enhancing gcc >anyway ;-) Well, it's stopping a real fix for the MinGW build failure being made. Adding #! support to libiberty won't work because the problem scripts have MSYS/Cygwin paths for the shell (eg. "/bin/sh") that aren't likely to be valid to plain Windows. Ross Ridge
Re: [patch] Fix i386-mingw32 build failure
> Well, it's stopping a real fix for the MinGW build failure being made. > Adding #! support to libiberty won't work because the problem scripts > have MSYS/Cygwin paths for the shell (eg. "/bin/sh") that aren't likely > to be valid to plain Windows. DJGPP solves this thusly: /* If INTERP is a Unix-style pathname, like "/bin/sh", we will try it with the usual extensions and, if that fails, will further search for the basename of the shell along the PATH; this allows to run Unix shell scripts without editing their first line. */
Re: [RFC] - Regression exposed by recent change to compress_float_constant
On Aug 10, 2005, at 12:43 PM, Fariborz Jahanian wrote:
Following patch has exposed an optimization shortcoming:
2005-07-12 Dale Johannesen <[EMAIL PROTECTED]>
* expr.c (compress_float_constant): Add cost check.
* config/rs6000.c (rs6000_rtx_cost): Adjust FLOAT_EXTEND cost.
This patch results in generating worse code for the following test case:
1) Test case:
struct S {
float d1, d2, d3;
I believe you mean double not float; the RTL snippets you give indicate this.
(insn 12 7 13 0 (set (reg:SF 59)
(mem/u/i:SF (symbol_ref/u:SI ("*LC0") [flags 0x2]) [0 S4 A32])) -1 (nil)
(nil))
(insn 13 12 14 0 (set (mem/s/j:DF (reg/f:SI 58 [ D.1929 ]) [0 .d1+0 S8 A32])
(float_extend:DF (reg:SF 59))) -1 (nil)
(nil))
However, if you try your example with float as given, you see it does not do a
direct store of constant 0 with or without the compress_float patch. IMO the
compress_float patch does not really have anything to do with this problem;
before this patch the double case was working well by accident, my patch
exposed a problem farther downstream, which was always there for the float
case.
When I put that patch in, rth remarked:
While I certainly wouldn't expect fold_rtx to find out about this
all by itself, I'd have thought that there would have been a
REG_EQUIV or REG_EQUAL note that indicates that the end result is
the constant (const_double:DF 1.0), and use that in any simplification.
Indeed there is no such note, and I suspect adding it somewhere (expand?) would fix this.
Re: [patch] Fix i386-mingw32 build failure
On 2005-08-10, at 19:05, Mark Mitchell wrote: The even more correct solution is to not build anything with the compiler (including libgcc) until after it is installed. Then, it will just look where it would normally look, and all will be well. install host != build host Most of the time if you do deilver software... You just don't want the fresh instalation to involve trashing a working tool chain too. However, I also recognize that we need to do something before 4.1 to fix this problem and that we need something simple enough to be viable in that timeframe. But, if Paolo can fix this without having to add #!, I think that would be great.
Re: Old machine cluster for GCC compile/testing
That's a very nice offer. I think the idea of an automated patch boostrap & regtester is of much interest, and i can volunteer to set up the systems (if need be, i can move to the machines since i live in Paris). Furthermore, it would be interesting if we could install, on some of those, a rather different OS than the typical linux or freebsd where developpers usually test their patches. I was thinking of Solaris, but the FSF might not want it install on this hardware (though i don't think it being non free is a relevant issue). FX
Re: [patch] Fix i386-mingw32 build failure
Mark Mitchell <[EMAIL PROTECTED]> writes: > The even more correct solution is to not build anything with the > compiler (including libgcc) until after it is installed. Then, it will > just look where it would normally look, and all will be well. You sure don't want to overwrite a compiler that is known to work with a compiler that is incomplete, never tested, and perhaps completely broken. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [patch] Fix i386-mingw32 build failure
Marcin Dalecki wrote: On 2005-08-10, at 19:05, Mark Mitchell wrote: The even more correct solution is to not build anything with the compiler (including libgcc) until after it is installed. Then, it will just look where it would normally look, and all will be well. install host != build host Most of the time if you do deilver software... You just don't want the fresh instalation to involve trashing a working tool chain too. I'm not sure what your point is -- but I'm quite familiar with building cross and Canadian cross toolchains. If the GCC you're building can't run on the host system, then the whole discussion doesn't matter; you're not going to run the GCC in the build directory, in which case the symlinks we're talking about don't matter. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: [patch] Fix i386-mingw32 build failure
Andreas Schwab wrote: Mark Mitchell <[EMAIL PROTECTED]> writes: The even more correct solution is to not build anything with the compiler (including libgcc) until after it is installed. Then, it will just look where it would normally look, and all will be well. You sure don't want to overwrite a compiler that is known to work with a compiler that is incomplete, never tested, and perhaps completely broken. I certainly didn't mean to suggest that -- but that doesn't mean you can't install the compiler somewhere. That's part of why people have worked hard to make it relocatable. We've had this entire discussion before, and as far as I can tell, there's agreement-in-principle: you build things, install them in a staging area, and then copy/reinstall into a final location when you're done. That avoids all the complicated symlinks/-B/-L/-I options -- which are not only complex, but also have been known to mask problems in the installed compiler. (Things work at build time, but not at install time.) -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: [gfortran] add ISATTY and TTYNAM intrinsics
On Aug 10, 2005, at 8:54 AM, Jack Howarth wrote:
FX,
I forgot to mention that since the gcc cvs I built last night now
contains your ISATTY and TTYNAM intrinsics patch, I regressed the
portion of the xplor.patch which worked around the prior absence
of the ISATTY intrinsic in gfortran. The resulting xplor-nih build
works fine.
One other question. Do you know much c++? I had to make one change
to some buggy c++ code to allow gcc 4.0 and main branch to compile
xplor-nih...
I am trying to figure out if this is catching some new buggy c++ which
is no longer accepted by the g++ compiler in gcc 4.1 or if this is a
regression in that branch.
The code is invalid C++ as "friend class" does not define a forward
declaration. Also for 4.1, the function norm is not considered as it
is declared after the use as 4.1
Both are invalid C++.
The example for the second issue is:
template class FixedVector;
template void norm(const FixedVector& v);
template T g(void);
template void f(void) { norm(g()); }
double norm(const double& v) {}
static void _wrap_sqrt__SWIGPY_1(){f();}
there is only one norm before f, so the overloaded set of norm in the
template f is
just that one norm. If you move the other norm before the f, it works
as expected in
both GCC 4.1.0 and ICC in strict mode.
Thanks,
Andrew Pinski
Re: Old machine cluster for GCC compile/testing
On Thu, Aug 11, 2005 at 12:12:30AM +0200, FX Coudert wrote: > That's a very nice offer. I think the idea of an automated patch > boostrap & regtester is of much interest, and i can volunteer to set up > the systems (if need be, i can move to the machines since i live in Paris). > > Furthermore, it would be interesting if we could install, on some of > those, a rather different OS than the typical linux or freebsd where > developpers usually test their patches. I was thinking of Solaris, but > the FSF might not want it install on this hardware (though i don't think > it being non free is a relevant issue). Please check with the FSF about what's OK to install on a machine that is under their control. Maybe Solaris is now "free enough", but that's for them to decide (the kernel has been freed, but perhaps there are proprietary components elsewhere in the OS?). The BSDs or GNU/Darwin should be acceptable choices, since they are free software, and it would be nice to have better relations with the BSD world.
Question of the DFA scheduler
I'm porting gcc 4.0.1 to a new VLIW architecture.
Some of its function units doesn't have internal hardware pipeline forwarding,
so I need to insert "nop" instructions in order to resovle the data hazard.
I used the automata based pipeline description for my ports,
I described the data latency time by `define_insn_reservation',
and I'm trying to insert the "nop" in the hook TARGET_MACHINE_DEPENDENT_REORG.
The implementation of this hook is simple.
I just run the DFA scheduler again manually,
and I just let the insns to be issued as well as 2nd sched pass.
The following codes are my implementation:
[TOP]---
void unicore_reorg(void)
{
bool func_start = true;
int stalls;
rtx insn = NULL, new_insn;
state_t dfa_state = alloca(state_size());
dfa_start();
state_reset(dfa_state);
for(insn = get_insns(); insn ; insn = NEXT_INSN(insn)) {
if(!executable_insn_p(insn)) continue;
if(!func_start && GET_MODE(insn) == TImode) state_transition(dfa_state, NULL);
stalls = state_transition(dfa_state, insn);
if(stalls == 1) {
state_transition(dfa_state, NULL);
state_transition(dfa_state, insn);
}
if(stalls > 1) {
while(--stalls) {
new_insn = emit_insn_before(gen_nop(), insn);
if(flag_schedule_insns_after_reload)
PUT_MODE(new_insn, TImode);
recog_memoized(new_insn);
state_transition(dfa_state, NULL);
}
state_transition(dfa_state, NULL);
state_transition(dfa_state, insn);
}
func_start = false;
}
dfa_finish();
}
[END]---
But I still saw that the two instructions can be issued in the continuous
cycles:
[TOP]---
@(insn:TI 48 50 49 (set (reg:SI 32 d0 [134])
@(minus:SI (reg:SI 6 r6 [orig:135 FLAG ] [135])
@(reg:SI 33 d1))) 48 {*subsi3} (insn_list:REG_DEP_TRUE 175 (nil))
@(expr_list:REG_EQUAL (neg:SI (reg:SI 3 r3 [orig:122 D.1804 ] [122]))
@(nil)))
sub .m0 d0, r6, d1 @ 48*subsi3/4 [length = 4]
@(insn:TI 49 48 176 (set (reg:SI 32 d0 [136])
@(smax:SI (reg:SI 3 r3 [orig:122 D.1804 ] [122])
@(reg:SI 32 d0 [134]))) 66 {smaxsi3} (insn_list:REG_DEP_TRUE 48
(insn_list:REG_DEP_TRUE 42 (nil)))
@(expr_list:REG_DEAD (reg:SI 3 r3 [orig:122 D.1804 ] [122])
@(nil)))
max .m0 d0, r3, d0 @ 49smaxsi3/2 [length = 4]
[END]---
The destination operand of the `sub' instruction, d0, will be written back in
the 4th cycle,
and the instruction `max' will use it as source operand (i.e., there is a true
data dependency).
I figured out that the state_transition() returns -1 when I issuing the `max'
instruction,
and I figured out it only returns > 0 when "hardware structural hazard" occured.
Are there any solutions for me to insert 4 nops between the 2 insns?
Thanks a lot.
Re: Ada character types : tree code and DW_AT_encoding
Jerome Guitton wrote: Two solutions : we can either change the tree code to CHAR_TYPE or add a test to detect Ada character types in the INTEGER_TYPE case, like it is done for C: ... The first solution would probably be cleaner, but it would mean that Ada would be the only supported langage to use CHAR_TYPE. The second one would be safer. Belatedly following up on this... Java uses CHAR_TYPE. So Ada would not be the only supported language using it if you switched to it. The C support isn't quite right. There is no attempt to handle wchar_t here, which is obviously a character type. We would need more exceptions to get this right. I think it would be better if the language front ends switched to using CHAR_TYPE for character types. Otherwise the debug output routines need a lot of code to tell which integer types are actually character types, and this is going to be hard to get right. It is easier if the language front ends choose the right type to begin with. This still may not solve the C front end problem though, as the C language doesn't actually have distinct character types separate from integer types. We don't need the C hacks here for gdb, as gdb knows that single byte integer types are sometimes used for holding characters. This stuff still might be useful for other debuggers though. Looking at the gdb code in dwarf2read.c, it looks like the distinction between DW_ATE_unsigned and DW_ATE_unsigned_char is irrelevant as it handles them the same. So unless you are planning to do some gdb work, it doesn't matter which one gcc emits. Or maybe you are using a different debugger that does care? -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: Ada character types : tree code and DW_AT_encoding
> "Jim" == James E Wilson <[EMAIL PROTECTED]> writes: Jim> Java uses CHAR_TYPE. So Ada would not be the only supported language Jim> using it if you switched to it. I was under the impression that CHAR_TYPE was deprecated, so I purposely avoided it in gcjx. I'm not sure where I got that impression though. Jim> I think it would be better if the language front ends switched to Jim> using CHAR_TYPE for character types. Otherwise the debug output Jim> routines need a lot of code to tell which integer types are actually Jim> character types, and this is going to be hard to get right. Interesting. Good thing to document somewhere. Tom
gcc 4.0.1 on mac os x tiger
powerpc-apple-darwin8.2.0 Using built-in specs. Target: powerpc-apple-darwin8.2.0 Configured with: ../gcc-4.0.1/configure --enable-languages=c,c+ +,f95,java --program-suffix=-4.0.1 --with-gmp=/sw --with-mpfr=/sw Thread model: posix gcc version 4.0.1
Re: [patch] Fix i386-mingw32 build failure
> DJGPP solves this thusly: > > /* If INTERP is a Unix-style pathname, like "/bin/sh", we will try > it with the usual extensions and, if that fails, will further > search for the basename of the shell along the PATH; this > allows to run Unix shell scripts without editing their first line. */ It's likely to work in this case, but it doesn't guarantee that the shell that gets executed uses the same MSYS/Cygwin enviroment as the rest of the build process. Ross Ridge -- l/ // Ross Ridge -- The Great HTMU [oo][oo] [EMAIL PROTECTED] -()-/()/ http://www.csclub.uwaterloo.ca/u/rridge/ db //
