PING SC members [was RE: RFA: GCC 4.2.1: Stabalizing coalesce_list's qsort]
On 23 August 2007 22:34, Mark Mitchell wrote: > I do think that generating the same code, independent of host system, is > a very important property of GCC's design, just like generating the same > code independent of whether or not we're compiling with -g. Hear, hear. I've always thought these principles were meant to be sacrosanct, but now I try to look it up, I don't see them explicitly listed in either the development methodology, the release criteria, or anywhere else likely-looking. Can the SC please consider adding these requirements explicitly to the list of "Design and Development Goals" in the mission statement? Or would it make more sense as part of the development methodology, or the portability section of the gcc-specific coding conventions? (Perhaps both; as a high-level goal in the mission statement, and with additions to the portability section of the coding conventions warning about issues like HOST_WIDE_INT size on 32-vs-64-bit hosts and not using pointers in hashes.) cheers, DaveK -- Can't think of a witty .sigline today
Issues with the constification patches
I was doing a merge from mainline into the tuples branch this morning when I found various conflicts due to the constification patches. I realized that not only there are some routines that take 'const_tree' instead of 'tree', but also that there are new API routines as well. I agree in general with trying to add const to functions that do not modify the argument. But I very strongly oppose the creation of new routines! We now have a whole bunch of new block_stmt_iterator routines (cbsi_*) besides the existing bsi_* routines. There are things like first_stmt and const_first_stmt. That is just plain ugly. I realize that this is probably needed because of the const changes, but I would like us to stop and thinking about polluting the whole API namespace so gratuitously. Our internal APIs are already confusing to begin with. This is not helping. Please consider reverting these API changes. Thanks.
[tuples] Merged with mainline
Some shuffling was needed due to the const patches, but things seem to be working.
Re: compiler chain on AIX
"Ed S. Peschko" <[EMAIL PROTECTED]> writes: > As I'm going through, yes I can make mods to work around these bugs, but it > sure is > a pain.. It would be much easier if gnu-ld simply *worked* on AIX (and of > course AIX > stopped shipping broken libraries) I did the initial GNU ld port to AIX. The basic problem is that the native AIX linker is documented very sketchily, they regularly add significant new features which the GNU linker must emulate, and they don't produce any documentation which describes the new features in sufficient detail to recreate them. And really, there is no reason they should; they're writing a linker, not writing specs for other people to implement. But the effect is that each significant new AIX release requires reverse engineering the new AIX linker to figure out what changed, and to implement that in th GNU linker. I did that for a few years in the mid-90s, but then I stopped bothering. So, while I'm certainly in favor of having the GNU linker support AIX, the reality is that somebody will have to devote the time to figuring out how to do that. And it's not going to be me. Ian
Build failure on ppc64
Hello, I get the following error on ppc64 with trunk r127835: c/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber../../gcc/gcc/regclass.c -o regclass.o ../../gcc/gcc/regclass.c: In function גinit_reg_autoincג: ../../gcc/gcc/regclass.c:1224: error: גforbidden_inc_dec_classesג undeclared (first use in this function) ../../gcc/gcc/regclass.c:1224: error: (Each undeclared identifier is reported only once ../../gcc/gcc/regclass.c:1224: error: for each function it appears in.) Thanks, Revital
Re: Issues with the constification patches
I've been solving conflicts left and right and ran into the same set of problems Diego describes independently. What's up with cbsi_last()/bsi_last(), and the rest of the functions that have been duplicated? We really shouldn't be changing APIs here, and if we absolutely need more than one routine, it should be done in some automagic way. The code duplicity throughout is silly at best. This is a maintenance nightmare. > Please consider reverting these API changes. I agree as well. Thanks. Aldy
use of ifndef inhibit_libc to disable the contents linux-unwind.h for targets with MD_UNWIND_SUPPORT
During the recent discussion about cross compilers I was told "bugs happen", so I went hunting. I have been digging into why building a cross compiler dies in different ways for different targets. As seen below, the Linux targets which use glibc define MD_UNWIND_SUPPORT and have a customized linux-unwind.h file. However, mips and i386 start and end those files with #ifndef inhibit_libc #endif statements which disable the entire contents of the file if inhibit_libc is set. Those are the only two such targets I can successfully build with inhibit_libc without the use of enable-sjlj-exceptions. Is there some reason that every instance of linux-unwind.h should not start and end with those same #ifndef inhibit_libc ... #endif statements? Or, alternatively, should setting of inhibit_libc force a #undef MD_UNWIND_SUPPORT at some suitably central place rather than doing things the way that mips and i386 currently handle it? Steve Kenton [EMAIL PROTECTED] gcc-4.2.1-stock]$ grep -r MD_UNWIND_SUPPORT gcc/config/* gcc/config/alpha/gnu.h:#undef MD_UNWIND_SUPPORT gcc/config/alpha/linux.h:#define MD_UNWIND_SUPPORT "config/alpha/linux-unwind.h" gcc/config/alpha/vms.h:#define MD_UNWIND_SUPPORT "config/alpha/vms-unwind.h" gcc/config/i386/gnu.h:#undef MD_UNWIND_SUPPORT gcc/config/i386/linux64.h:#define MD_UNWIND_SUPPORT "config/i386/linux-unwind.h" gcc/config/i386/linux.h:#define MD_UNWIND_SUPPORT "config/i386/linux-unwind.h" gcc/config/ia64/linux.h:#define MD_UNWIND_SUPPORT "config/ia64/linux-unwind.h" gcc/config/ia64/unwind-ia64.c:#ifdef MD_UNWIND_SUPPORT gcc/config/ia64/unwind-ia64.c:#include MD_UNWIND_SUPPORT gcc/config/mips/linux.h:#define MD_UNWIND_SUPPORT "config/mips/linux-unwind.h" gcc/config/pa/pa32-linux.h:#define MD_UNWIND_SUPPORT "config/pa/linux-unwind.h" gcc/config/pa/pa-hpux.h:#define MD_UNWIND_SUPPORT "config/pa/hpux-unwind.h" gcc/config/rs6000/linux64.h:#define MD_UNWIND_SUPPORT "config/rs6000/linux-unwind.h" gcc/config/rs6000/linux.h:#define MD_UNWIND_SUPPORT "config/rs6000/linux-unwind.h" gcc/config/rs6000/darwin.h:#define MD_UNWIND_SUPPORT "config/rs6000/darwin-unwind.h" gcc/config/s390/tpf.h:#define MD_UNWIND_SUPPORT "config/s390/tpf-unwind.h" gcc/config/s390/linux.h:#define MD_UNWIND_SUPPORT "config/s390/linux-unwind.h" gcc/config/sh/linux.h:#define MD_UNWIND_SUPPORT "config/sh/linux-unwind.h" gcc/config/sparc/linux64.h:#define MD_UNWIND_SUPPORT "config/sparc/linux-unwind.h" gcc/config/sparc/linux.h:#define MD_UNWIND_SUPPORT "config/sparc/linux-unwind.h" [EMAIL PROTECTED] gcc-4.2.1-stock]$ find gcc/config -name linux-unwind.h gcc/config/sparc/linux-unwind.h gcc/config/mips/linux-unwind.h gcc/config/i386/linux-unwind.h gcc/config/pa/linux-unwind.h gcc/config/ia64/linux-unwind.h gcc/config/sh/linux-unwind.h gcc/config/s390/linux-unwind.h gcc/config/rs6000/linux-unwind.h gcc/config/alpha/linux-unwind.h [EMAIL PROTECTED] gcc-4.2.1-stock]$ grep inhibit_libc `find gcc/config -name linux-unwind.h` gcc/config/mips/linux-unwind.h:#ifndef inhibit_libc gcc/config/i386/linux-unwind.h: Don't use this at all if inhibit_libc is used. */ gcc/config/i386/linux-unwind.h:#ifndef inhibit_libc gcc/config/i386/linux-unwind.h:#endif /* ifdef inhibit_libc */ [EMAIL PROTECTED] gcc-4.2.1-stock]$
Re: use of ifndef inhibit_libc to disable the contents linux-unwind.h for targets with MD_UNWIND_SUPPORT
On Mon, Aug 27, 2007 at 03:29:23PM -0500, Stephen M. Kenton wrote: > As seen below, the Linux targets which use glibc define MD_UNWIND_SUPPORT and > have > a customized linux-unwind.h file. However, mips and i386 start and end those > files with > #ifndef inhibit_libc #endif statements which disable the entire contents > of the file if inhibit_libc is set. > Those are the only two such targets I can successfully build with > inhibit_libc > without the use of enable-sjlj-exceptions. > Is there some reason that every instance of linux-unwind.h should not start > and > end with those same > #ifndef inhibit_libc ... #endif statements? Or, alternatively, should > setting > of inhibit_libc force > a #undef MD_UNWIND_SUPPORT at some suitably central place rather than doing > things the > way that mips and i386 currently handle it? FWIW, I've come to the opinion that we should just copy the relevant structure layouts from glibc into gcc and avoid this problem. If the layout ever changes, we're going to need to handle both in gcc anyway. -- Daniel Jacobowitz CodeSourcery
Re: use of ifndef inhibit_libc to disable the contents linux-unwind.h for targets with MD_UNWIND_SUPPORT
Stephen M. Kenton wrote: During the recent discussion about cross compilers I was told "bugs happen", so I went hunting. I have been digging into why building a cross compiler dies in different ways for different targets. As seen below, the Linux targets which use glibc define MD_UNWIND_SUPPORT and have a customized linux-unwind.h file. However, mips and i386 start and end those files with #ifndef inhibit_libc #endif statements which disable the entire contents of the file if inhibit_libc is set. Those are the only two such targets I can successfully build with inhibit_libc without the use of enable-sjlj-exceptions. You never state what you are trying to build. "cross compiler" does not really narrow it down. Also you don't state what errors you are experiencing. Is there some reason that every instance of linux-unwind.h should not start and end with those same #ifndef inhibit_libc ... #endif statements? In the case of mips, I believe that inhibit_libc is a surrogate for a check that signal.h and asm/unistd.h are usable. Or, alternatively, should setting of inhibit_libc force a #undef MD_UNWIND_SUPPORT at some suitably central place rather than doing things the way that mips and i386 currently handle it? I think Danial Jacobowitz is probably correct in that the structure definitions should just be copied into libgcc so that we are not dependent on libc. David Daney
Re: use of ifndef inhibit_libc to disable the contents linux-unwind.h for targets with MD_UNWIND_SUPPORT
David Daney wrote: You never state what you are trying to build. "cross compiler" does not really narrow it down. Also you don't state what errors you are experiencing. I'm experimenting with building a Linux based cross compiler/tool-chain for building the Kernel and Apps for every target in the kernel/arch directory. Following various sets of instructions I can just about do that, but the question arose in my mind, why, after reading the documentation and some research, that doing the obvious configure/make/install fails in so many cases. In this particular subset of failures involving inhibit_libc, MD_UNWIND_SUPPORT and linux-unwind.h the problem is attempting to include files which are not available. I know how to work around it, but it seems like something should be fixed so that other people won't have to work around it. Things should just work. Hence my question below. Is there some reason that every instance of linux-unwind.h should not start and end with those same #ifndef inhibit_libc ... #endif statements? In the case of mips, I believe that inhibit_libc is a surrogate for a check that signal.h and asm/unistd.h are usable. Exactly. Except for mips and i386, the compile fails with a "missing file" error if inhbit_libc is set in this situation. I hacked up a few of the other linux-unwind.h files and alpha just finished successfully. Steve
Re: Build failure on ppc64
On 8/27/07, Revital1 Eres <[EMAIL PROTECTED]> wrote: > > Hello, > > I get the following error on ppc64 with trunk r127835: This should be fixed by revision 127836. -- Pinski
gcc-4.1-20070827 is now available
Snapshot gcc-4.1-20070827 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070827/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 127840 You'll find: gcc-4.1-20070827.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20070827.tar.bz2 C front end and core compiler gcc-ada-4.1-20070827.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20070827.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20070827.tar.bz2 C++ front end and runtime gcc-java-4.1-20070827.tar.bz2 Java front end and runtime gcc-objc-4.1-20070827.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20070827.tar.bz2The GCC testsuite Diffs from 4.1-20070820 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Build failure on ppc64
On Mon, 2007-08-27 at 22:24 +0300, Revital1 Eres wrote: > Hello, > > I get the following error on ppc64 with trunk r127835: That failures is fixed in r127836. Janis
another build failure on ppc64-linux
Bootstrap of current trunk on powerpc64-linux fails in libstdc++ building system_error.lo. The code that fails was added a few days ago, but the failure seems to be the same as the one reported in PR 31490. I verified that the patch from comment #10 of that PR allows bootstrap of c,c++,fortran to succeed and now I'm doing a bootstrap and regtest of all languages but Ada. I'll report the results in the PR. Janis
Gcc error - configure: error: C compiler cannot create executables
I got this messages on the shell screen: COMP-BRUNO:/home/bruno/Programas/cups-1.4svn-r6852# ./configure checking for gawk... no checking for mawk... mawk checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. Attached I've send the config.log. I've read the message, but have no idea what could be the problem. Someone Could, please, help me??? thanks in advance. config.log Description: Binary data
Re: Gcc error - configure: error: C compiler cannot create executables
bruno steckelberg wrote: I got this messages on the shell screen: COMP-BRUNO:/home/bruno/Programas/cups-1.4svn-r6852# ./configure checking for gawk... no checking for mawk... mawk checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. Attached I've send the config.log. I've read the message, but have no idea what could be the problem. Someone Could, please, help me??? This is not the right list for this question but When you get this type of error, you need to really examine the config.log. It contains the error message from whatever configure tried to do. In this case, we see: configure:1840: gccconftest.c >&5 /usr/bin/ld: crt1.o: No such file: No such file or directory So my guess is you are missing some part of the development environment. Until you can compile and link a hello world program, you won't get past this point. --joel thanks in advance.
Re: recent troubles with float vectors & bitwise ops
tbp wrote:
On 8/23/07, Tim Prince <[EMAIL PROTECTED]> wrote:
Note that icc9 has a strong bias for pentium4, which had no stall
penalty for mistyped fp vectors as for Intel it came with the pentium
M line, so you see a pxor even if generating code for the core2.
# cat autoicc.cc
float foo(const float *a, int n) {
float sum = 0.f;
for (int i = 0; i 0.f)
sum += a[i];
return sum;
}
int main() { return 0; }
# /opt/intel/cce/9.1.051/bin/icpc -O3 -xT autoicc.cc
autoicc.cc(3) : (col. 2) remark: LOOP WAS VECTORIZED.
4007a9: pxor %xmm4,%xmm4
4007ad: cmpltps %xmm3,%xmm4
4007b1: andps %xmm3,%xmm4
# /opt/intel/cce/10.0.023/bin/icpc -O3 -xT autoicc.cc
autoicc.cc(3): (col. 2) remark: LOOP WAS VECTORIZED.
400b50: xorps %xmm3,%xmm3
400b53: cmpltps %xmm4,%xmm3
400b57: andps %xmm3,%xmm4
For what little it's worth, I found no measurable difference between
these choices on Core 2 Duo. People I know prefer to use the Intel -xW
option, or the gcc default, in the absence of clear evidence that
another option could improve performance without reducing the range of
supported targets.
---AV & Spam Filtering by M+Guardian - Risk Free Email (TM)---
