4.3 build failure in driver-i386.c
Hi,
driver-i386.s: Assembler messages:
driver-i386.s:2454: Error: invalid character '{' in mnemonic
driver-i386.s:2455: Error: invalid character '{' in mnemonic
driver-i386.s:2456: Error: invalid character '{' in mnemonic
driver-i386.s:2457: Error: invalid character '{' in mnemonic
driver-i386.s:2458: Error: invalid character '{' in mnemonic
driver-i386.s:2459: Error: invalid character '{' in mnemonic
driver-i386.s:2460: Error: invalid character '{' in mnemonic
driver-i386.s:2461: Error: invalid character '{' in mnemonic
driver-i386.s:2462: Error: invalid character '{' in mnemonic
driver-i386.s:2463: Error: invalid character '{' in mnemonic
This is on an ancient distro (don't ask..) i.e. RedHat 6.2. (4.2.3 builds
fine so this is somewhat of a regression...)
Looking at the -save-temps output, it seems the old assembler is choking
on this syntax from __get_cpuid_max() in cpuid.h:
.stabn 68,0,91,.LM210-__get_cpuid_max
.LM210:
#APP
pushf{l|d}
pushf{l|d}
pop{l} %eax
mov{l} {%eax, %edx|%edx, %eax}
xor{l} {$2097152, %eax|%eax, $2097152}
push{l} %eax
popf{l|d}
pushf{l|d}
pop{l} %eax
popf{l|d}
#NO_APP
It's kind of unfortunate for the build to break in this way. Is there any
hope for some kind of fix or workaround? I realize ancient distros are not
a priority, but still
Thanks
Greg
Re: 4.3 build failure in driver-i386.c
On Feb 17, 2008 10:40 AM, Richard Guenther <[EMAIL PROTECTED]> wrote:
>
> On Feb 17, 2008 9:38 AM, Greg Schafer <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > driver-i386.s: Assembler messages:
> > driver-i386.s:2454: Error: invalid character '{' in mnemonic
> > driver-i386.s:2455: Error: invalid character '{' in mnemonic
> > driver-i386.s:2456: Error: invalid character '{' in mnemonic
> > driver-i386.s:2457: Error: invalid character '{' in mnemonic
> > driver-i386.s:2458: Error: invalid character '{' in mnemonic
> > driver-i386.s:2459: Error: invalid character '{' in mnemonic
> > driver-i386.s:2460: Error: invalid character '{' in mnemonic
> > driver-i386.s:2461: Error: invalid character '{' in mnemonic
> > driver-i386.s:2462: Error: invalid character '{' in mnemonic
> > driver-i386.s:2463: Error: invalid character '{' in mnemonic
> >
> > This is on an ancient distro (don't ask..) i.e. RedHat 6.2. (4.2.3 builds
> > fine so this is somewhat of a regression...)
> >
> > Looking at the -save-temps output, it seems the old assembler is choking
> > on this syntax from __get_cpuid_max() in cpuid.h:
> >
> > .stabn 68,0,91,.LM210-__get_cpuid_max
> > .LM210:
> > #APP
> > pushf{l|d}
> > pushf{l|d}
> > pop{l} %eax
> > mov{l} {%eax, %edx|%edx, %eax}
> > xor{l} {$2097152, %eax|%eax, $2097152}
> > push{l} %eax
> > popf{l|d}
> > pushf{l|d}
> > pop{l} %eax
> > popf{l|d}
> >
> > #NO_APP
> >
> >
> > It's kind of unfortunate for the build to break in this way. Is there any
> > hope for some kind of fix or workaround? I realize ancient distros are not
> > a priority, but still
>
> The problem is that your host GCC doesn't recognize the inline asm correctly
> (the above should not reach the assembler), GCC 3.3.x handles the above fine.
> This probably also breaks build with non-GCC host compilers.
>
> Rask, you introduced this change - any idea on how to fix this? Can we please
> revert the cpuid.h change for 4.3.0 if this is too hard to fix in a short
> time?
I see the use of cpuid.h is wrapped inside #ifdef __GNUC__, so the issue is only
using old GCC as the host compiler (I checked 2.95 which chokes on the asm).
Can we change this guard to only allow GCC >= 3.3 which would also fix this?
Thanks,
Richard.
Re: Optimizations documentation
Hi,
Dorit Nuzman/Haifa/IBM wrote on 14/02/2008 17:02:45:
> This is an old debt: A while back Tim had sent me a detailed report
> off line showing which C++ tests (originally from the Dongara loops
> suite) were vectorized by current g++ or icpc, or both, as well as
> when the vectorization by icpc required a pragma, or was partial. I
> went over the loops that were reported to be vectorized by icc but
> not by gcc, to see which features we are missing. There are 23 such
> loops (out of a total of 77). They fall into the following 7 categories:
>
> (1) scalar evolution analysis fails with "evolution of base is not
affine".
> This happens in the 3 loops in lines 4267, 4204 and 511.
> Here an example:
> for (i__ = 1; i__ <= i__2; ++i__)
> {
> a[i__] = (b[i__] + b[im1] + b[im2]) * .333f;
> im2 = im1;
> im1 = i__;
> }
> Missed optimization PR to be opened.
I opened PR35224.
>
> (2) Function calls inside a loop. These are calls to the math
> functions sin/cos, which I expect would be vectorized if the proper
> simd math lib was available.
> This happens in the loop in line 6932.
> I think there's an open PR for this one (at least for
> powerpc/Altivec?) - need to look/open.
There is PR6.
>
> (3) This one is the most dominant missed optimization: if-conversion
> is failing to if-convert, most likely due to the very limited
> handling of loads/stores (i.e. load/store hoisting/sinking is required).
> This happens in the 13 loops in lines 4085, 4025, 3883, 3818, 3631,
> 355, 3503, 2942, 877, 6740, 6873, 5191, 7943.
> There is on going work towards addressing this issue - see http:
> //gcc.gnu.org/ml/gcc/2007-07/msg00942.html, http://gcc.gnu.
> org/ml/gcc/2007-09/msg00308.html. (I think Victor Kaplansky is
> currently working on this).
>
> (4) A scalar variable, whose address is taken outside the loop (in
> an enclosing outer-loop) is analyzed by the data-references
> analysis, which fails because it is invariant.
> Here's an example:
> for (nl = 1; nl <= i__1; ++nl)
> {
> sum = 0.f;
> for (i__ = 1; i__ <= i__2; ++i__)
> {
> a[i__] = c__[i__] + d__[i__];
> b[i__] = c__[i__] + e[i__];];
> sum += a[i__] + b[i__];];];
> }
> dummy_ (ld, n, &a[1], &b[1], &c__[1], &d__[1], &e[1], &aa
[aa_offset],
> &bb[bb_offset], &cc[cc_offset], &sum);
> }
> (Analysis of 'sum' fails with "FAILED as dr address is invariant".
> This happens in the 2 loops in lines 5053 and 332.
> I think there is a missed optimization PR for this one already. need
> to look/open.
>
The related PRs are PR33245 and PR33244. Also there is a FIXME comment in
tree-data-ref.c before the failure with "FAILED as dr address is invariant"
error:
/* FIXME -- data dependence analysis does not work correctly for
objects with
invariant addresses. Let us fail here until the problem is fixed.
*/
> (5) Reduction and induction that involve multiplication (i.e. 'prod
> *= CST' or 'prod *= a[i]') are currently not supported by the
> vectorizer. It should be trivial to add support for this feature
> (for reduction, it shouldn't be much more than adding a case for
> MULT_EXPR in tree-vectorizer.c:reduction_code_for_scalar_code, I think).
> This happens in the 2 loops in lines 4921 and 4632.
> A missed-optimization PR to be opened.
Opened PR35226.
>
> (6) loop distribution is required to break a dependence. This may
> already be handled by Sebastian's loop-distribution pass that will
> be incorporated in 4.4.
> Here is an example:
> for (i__ = 2; i__ <= i__2; ++i__)
> {
> a[i__] += c__[i__] * d__[i__];
> b[i__] = a[i__] + d__[i__] + b[i__ - 1];
> }
> This happens in the loop in line 2136.
> Need to check if we need to open a missed optimization PR for this.
I don't think that this is a loop distribution issue. The dependence
between the store to a[i] and the load from a[i] doesn't prevent
vectorization. The problematic one is between the store to b[i] and the
load from b[i-1] in the second statement.
>
> (7) A dependence, similar to such that would be created by
> predictive commoning (or even PRE), is present in the loop:
> for (i__ = 1; i__ <= i__2; ++i__)
> {
> a[i__] = (b[i__] + x) * .5f;
> x = b[i__];
> }
> This happens in the loop in line 3003.
> The vectorizer needs to be extended to handle such cases.
> A missed optimization PR to be opened (if doesn't exist already).
I opened a new PR - 35229. (PR33244 is somewhat related).
Ira
Re: 4.3 build failure in driver-i386.c
On Feb 17, 2008 9:38 AM, Greg Schafer <[EMAIL PROTECTED]> wrote:
> Hi,
>
> driver-i386.s: Assembler messages:
> driver-i386.s:2454: Error: invalid character '{' in mnemonic
> driver-i386.s:2455: Error: invalid character '{' in mnemonic
> driver-i386.s:2456: Error: invalid character '{' in mnemonic
> driver-i386.s:2457: Error: invalid character '{' in mnemonic
> driver-i386.s:2458: Error: invalid character '{' in mnemonic
> driver-i386.s:2459: Error: invalid character '{' in mnemonic
> driver-i386.s:2460: Error: invalid character '{' in mnemonic
> driver-i386.s:2461: Error: invalid character '{' in mnemonic
> driver-i386.s:2462: Error: invalid character '{' in mnemonic
> driver-i386.s:2463: Error: invalid character '{' in mnemonic
>
> This is on an ancient distro (don't ask..) i.e. RedHat 6.2. (4.2.3 builds
> fine so this is somewhat of a regression...)
>
> Looking at the -save-temps output, it seems the old assembler is choking
> on this syntax from __get_cpuid_max() in cpuid.h:
>
> .stabn 68,0,91,.LM210-__get_cpuid_max
> .LM210:
> #APP
> pushf{l|d}
> pushf{l|d}
> pop{l} %eax
> mov{l} {%eax, %edx|%edx, %eax}
> xor{l} {$2097152, %eax|%eax, $2097152}
> push{l} %eax
> popf{l|d}
> pushf{l|d}
> pop{l} %eax
> popf{l|d}
>
> #NO_APP
>
>
> It's kind of unfortunate for the build to break in this way. Is there any
> hope for some kind of fix or workaround? I realize ancient distros are not
> a priority, but still
The problem is that your host GCC doesn't recognize the inline asm correctly
(the above should not reach the assembler), GCC 3.3.x handles the above fine.
This probably also breaks build with non-GCC host compilers.
Rask, you introduced this change - any idea on how to fix this? Can we please
revert the cpuid.h change for 4.3.0 if this is too hard to fix in a short time?
Thanks,
Richard.
Re: Ada: building 4.3 cross-gnattools with gcc-4.2.1
> 1) Is it supposed to work? (i.e. building an Ada cross compiler 4.3 by a > 4.2 compiler) No, as documented, you need a matching native compiler to build a cross Ada compiler (e.g. build from the same 4.3 sources a native compiler first, and then use it to build the cross compiler). > 2) does it work to build 4.3 cross-gnattools with the current 4.3 Ada > compiler? It does in general. I do not know for avr in particular. > 3) Would a patch be accepted that makes the 4.3 gnattols be compilable > by 4.2 compiler? In general, no. On a case by case basis, assuming the patch is simple and does not make the code worse in terms of maintenance, then it can be OK. Arno
Re: 4.3 build failure in driver-i386.c
"Richard Guenther" <[EMAIL PROTECTED]> writes: > I see the use of cpuid.h is wrapped inside #ifdef __GNUC__, so the issue is > only > using old GCC as the host compiler (I checked 2.95 which chokes on the asm). > Can we change this guard to only allow GCC >= 3.3 which would also fix this? Won't those host dependent parameters cause bootstrap comparison failures? If the stage1 compiler doesn't use the same detection routines as the stage2 compiler then the stage2 compiler is compiled with different options than the stage3 compiler. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
gcc hangs ! (version 4.1.2, Ubuntu 4.1.2-0ubuntu4)
hello,
I encounter a strange gcc behavior - it hangs ! this is not happening always.
It can hang sometimes, and sometimes not, with the exact same source
file and gcc command line.
My command is simple, i use several -I parameters (include folders),
-c and -o.. that's it..
gcc -I -I -I -I -I
-c -o folder6/output.o folder6/source.c
Attached is the end of the strace output, the last line just hangs.. (waitpid).
my gcc version:
$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release
i486-linux-gnu
Thread model: posix
gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)
any ideas ?
thank you
sunzir
...
close(3)= 0
munmap(0xb7eed000, 4096)= 0
open("/usr/lib/locale/en_US.UTF-8/LC_CTYPE", O_RDONLY) = -1 ENOENT (No
such file or directory)
open("/usr/lib/locale/en_US.utf8/LC_CTYPE", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=238336, ...}) = 0
mmap2(NULL, 238336, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7d61000
close(3)= 0
open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=25460, ...}) = 0
mmap2(NULL, 25460, PROT_READ, MAP_SHARED, 3, 0) = 0xb7ee7000
close(3)= 0
open("/usr/lib/locale/en_US.UTF-8/LC_MESSAGES", O_RDONLY) = -1 ENOENT
(No such file or directory)
open("/usr/lib/locale/en_US.utf8/LC_MESSAGES", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
close(3)= 0
open("/usr/lib/locale/en_US.utf8/LC_MESSAGES/SYS_LC_MESSAGES", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=52, ...}) = 0
mmap2(NULL, 52, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7ee6000
close(3)= 0
open("/usr/share/locale/en_US/LC_MESSAGES/gcc-4.1.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/gcc-4.1.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en_US/LC_MESSAGES/gcc-4.1.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en/LC_MESSAGES/gcc-4.1.mo", O_RDONLY)
= -1 ENOENT (No such file or directory)
rt_sigaction(SIGINT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGINT, {0x804f8d0, [INT], SA_RESTART}, {SIG_IGN}, 8) = 0
rt_sigaction(SIGHUP, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGHUP, {0x804f8d0, [HUP], SA_RESTART}, {SIG_IGN}, 8) = 0
rt_sigaction(SIGTERM, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGTERM, {0x804f8d0, [TERM], SA_RESTART}, {SIG_IGN}, 8) = 0
rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGPIPE, {0x804f8d0, [PIPE], SA_RESTART}, {SIG_IGN}, 8) = 0
rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_DFL}, 8) = 0
access("/usr/local/sbin/gcc", X_OK) = -1 ENOENT (No such file or directory)
access("/usr/local/bin/gcc", X_OK) = -1 ENOENT (No such file or directory)
access("/usr/sbin/gcc", X_OK) = -1 ENOENT (No such file or directory)
access("/usr/bin/gcc", X_OK)= 0
lstat64("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/usr/bin", {st_mode=S_IFDIR|0755, st_size=65536, ...}) = 0
lstat64("/usr/bin/gcc", {st_mode=S_IFLNK|0777, st_size=16, ...}) = 0
readlink("/usr/bin/gcc", "/usr/bin/gcc-4.1", 4096) = 16
lstat64("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/usr/bin", {st_mode=S_IFDIR|0755, st_size=65536, ...}) = 0
lstat64("/usr/bin/gcc-4.1", {st_mode=S_IFREG|0755, st_size=183904, ...}) = 0
access("/usr/local/sbin/gcc", X_OK) = -1 ENOENT (No such file or directory)
access("/usr/local/bin/gcc", X_OK) = -1 ENOENT (No such file or directory)
access("/usr/sbin/gcc", X_OK) = -1 ENOENT (No such file or directory)
access("/usr/bin/gcc", X_OK)= 0
lstat64("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/usr/bin", {st_mode=S_IFDIR|0755, st_size=65536, ...}) = 0
lstat64("/usr/bin/gcc", {st_mode=S_IFLNK|0777, st_size=16, ...}) = 0
readlink("/usr/bin/gcc", "/usr/bin/gcc-4.1", 4096) = 16
lstat64("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/usr/bin", {st_mode=S_IFDIR|0755, st_size=65536, ...}) = 0
lstat64("/usr/bin/gcc-4.1", {st_mode=S_IFREG|0755, st_size=183904, ...}) = 0
access("/usr/lib/gcc/i486-linux-gnu/4.1.2/", X_OK) = 0
access("/usr/lib/gcc/i486-linux-gnu/4.1.2/", X_OK) = 0
access("uart/bthal_uart.c", F_OK) = 0
access("/usr/lib/gcc/i486-linux-gnu/4.1.2/specs", R_OK) = -1 ENOENT
(No such file or directory)
access("/usr/lib/gcc/i486-linux-gnu/4.1.2/specs", R_OK) = -1 ENOENT
(No such file or directory)
access("/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../i486-linux-gnu/lib/i486-linux-gnu/4.1.2/s
Re: 4.3 build failure in driver-i386.c
On Feb 17, 2008 10:54 AM, Andreas Schwab <[EMAIL PROTECTED]> wrote: > "Richard Guenther" <[EMAIL PROTECTED]> writes: > > > I see the use of cpuid.h is wrapped inside #ifdef __GNUC__, so the issue is > > only > > using old GCC as the host compiler (I checked 2.95 which chokes on the asm). > > Can we change this guard to only allow GCC >= 3.3 which would also fix this? > > Won't those host dependent parameters cause bootstrap comparison > failures? If the stage1 compiler doesn't use the same detection > routines as the stage2 compiler then the stage2 compiler is compiled > with different options than the stage3 compiler. If you bootstrap with BOOT_CFLAGS="-march=native" yes, otherwise no. Maybe we should build i386-driver.c with the stage1 compiler and not the host compiler, which of course causes a chicken and egg problem... Richard.
Re: 4.3 build failure in driver-i386.c
"Richard Guenther" <[EMAIL PROTECTED]> writes: > On Feb 17, 2008 10:54 AM, Andreas Schwab <[EMAIL PROTECTED]> wrote: >> "Richard Guenther" <[EMAIL PROTECTED]> writes: >> >> > I see the use of cpuid.h is wrapped inside #ifdef __GNUC__, so the issue >> > is only >> > using old GCC as the host compiler (I checked 2.95 which chokes on the >> > asm). >> > Can we change this guard to only allow GCC >= 3.3 which would also fix >> > this? >> >> Won't those host dependent parameters cause bootstrap comparison >> failures? If the stage1 compiler doesn't use the same detection >> routines as the stage2 compiler then the stage2 compiler is compiled >> with different options than the stage3 compiler. > > If you bootstrap with BOOT_CFLAGS="-march=native" yes, otherwise no. Ok, I knew I was missing something. :-) Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
bootstrap broken on mingw (was: Re: AVR port broken on 4.3 20080215 snapshot)
Hi all, I also see this failure on a native build for i386-pc-mingw32, so this is probably a mingw issue. Since i686-pc-mingw32 is a seconday platform, this makes it a release blocker (I've marked it as such in bugzilla, and gave it P1 status; I hope that was the right thing to do). The error here is the same: ../../trunk/gcc/doc//invoke.texi:1243: @include `/home/FX/ibin/ gcc/../../trunk/gcc/../libiberty/at-file.texi': No such file or sdirectory. What's interesting is that the file actually exists: $ wc -l /home/FX/ibin/gcc/../../trunk/gcc/../libiberty/at-file.texi 15 /home/FX/ibin/gcc/../../trunk/gcc/../libiberty/at-file.texi Thus, I suspect some sort of absolute vs. relative path issue, to which mingw (and especially the MSYS environment) is often very sensitive. For example, bootstrap only work if you use a relative path to configure. FX -- François-Xavier Coudert http://www.homepages.ucl.ac.uk/~uccafco/
Re: bootstrap broken on mingw (was: Re: AVR port broken on 4.3 20080215 snapshot)
On Feb 17, 2008 12:41 PM, FX Coudert <[EMAIL PROTECTED]> wrote: > Hi all, > > I also see this failure on a native build for i386-pc-mingw32, so > this is probably a mingw issue. Since i686-pc-mingw32 is a seconday > platform, this makes it a release blocker (I've marked it as such in > bugzilla, and gave it P1 status; I hope that was the right thing to do). > > The error here is the same: > > > ../../trunk/gcc/doc//invoke.texi:1243: @include `/home/FX/ibin/ > > gcc/../../trunk/gcc/../libiberty/at-file.texi': No such file or > > sdirectory. > > What's interesting is that the file actually exists: > > > $ wc -l /home/FX/ibin/gcc/../../trunk/gcc/../libiberty/at-file.texi > > 15 /home/FX/ibin/gcc/../../trunk/gcc/../libiberty/at-file.texi > > Thus, I suspect some sort of absolute vs. relative path issue, to > which mingw (and especially the MSYS environment) is often very > sensitive. For example, bootstrap only work if you use a relative > path to configure. Actually there seems to be a recent change "backward" to that logic: 2008-02-13 Ralf Wildenhues <[EMAIL PROTECTED]> PR other/35148 * Makefile.in (gcc-vers.texi): Use abs_srcdir for the value of srcdir. and we have PR35218 which seems to be the same issue? Richard.
Re: bootstrap broken on mingw (was: Re: AVR port broken on 4.3 20080215 snapshot)
Actually there seems to be a recent change "backward" to that logic: 2008-02-13 Ralf Wildenhues <[EMAIL PROTECTED]> PR other/35148 * Makefile.in (gcc-vers.texi): Use abs_srcdir for the value of srcdir. Doesn't look too good for mingw. and we have PR35218 which seems to be the same issue? Yes, it is exactly, it was open by Eric and I added my information. I should have given the PR number in my mail. FX -- François-Xavier Coudert http://www.homepages.ucl.ac.uk/~uccafco/
Re: gcc hangs ! (version 4.1.2, Ubuntu 4.1.2-0ubuntu4)
followup:
After a considerabale amount of time (e.g. 15 seconds), something is suddenly
freed, and the compilation completes successfully. afterwards trying
to recompile
the file completes immediately (it is not a big file, so it takes
fraction of a second).
I don't know what is the cause of the hang.. I can tell that while it is hung,
the cpu is not working (gcc doesn't even show in top..).
On Feb 17, 2008 12:03 PM, Sunzir Deepur <[EMAIL PROTECTED]> wrote:
> hello,
>
> I encounter a strange gcc behavior - it hangs ! this is not happening always.
> It can hang sometimes, and sometimes not, with the exact same source
> file and gcc command line.
> My command is simple, i use several -I parameters (include folders),
> -c and -o.. that's it..
> gcc -I -I -I -I -I
> -c -o folder6/output.o folder6/source.c
>
> Attached is the end of the strace output, the last line just hangs..
> (waitpid).
>
> my gcc version:
> $ gcc -v
> Using built-in specs.
> Target: i486-linux-gnu
> Configured with: ../src/configure -v
> --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
> --enable-shared --with-system-zlib --libexecdir=/usr/lib
> --without-included-gettext --enable-threads=posix --enable-nls
> --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-mpfr --enable-checking=release
> i486-linux-gnu
> Thread model: posix
> gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)
>
>
> any ideas ?
>
> thank you
> sunzir
>
>
> ...
>
> close(3)= 0
> munmap(0xb7eed000, 4096)= 0
> open("/usr/lib/locale/en_US.UTF-8/LC_CTYPE", O_RDONLY) = -1 ENOENT (No
> such file or directory)
> open("/usr/lib/locale/en_US.utf8/LC_CTYPE", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=238336, ...}) = 0
> mmap2(NULL, 238336, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7d61000
> close(3)= 0
> open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=25460, ...}) = 0
> mmap2(NULL, 25460, PROT_READ, MAP_SHARED, 3, 0) = 0xb7ee7000
> close(3)= 0
> open("/usr/lib/locale/en_US.UTF-8/LC_MESSAGES", O_RDONLY) = -1 ENOENT
> (No such file or directory)
> open("/usr/lib/locale/en_US.utf8/LC_MESSAGES", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> close(3)= 0
> open("/usr/lib/locale/en_US.utf8/LC_MESSAGES/SYS_LC_MESSAGES", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=52, ...}) = 0
> mmap2(NULL, 52, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7ee6000
> close(3)= 0
> open("/usr/share/locale/en_US/LC_MESSAGES/gcc-4.1.mo", O_RDONLY) = -1
> ENOENT (No such file or directory)
> open("/usr/share/locale/en/LC_MESSAGES/gcc-4.1.mo", O_RDONLY) = -1
> ENOENT (No such file or directory)
> open("/usr/share/locale-langpack/en_US/LC_MESSAGES/gcc-4.1.mo",
> O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/share/locale-langpack/en/LC_MESSAGES/gcc-4.1.mo", O_RDONLY)
> = -1 ENOENT (No such file or directory)
> rt_sigaction(SIGINT, {SIG_IGN}, {SIG_DFL}, 8) = 0
> rt_sigaction(SIGINT, {0x804f8d0, [INT], SA_RESTART}, {SIG_IGN}, 8) = 0
> rt_sigaction(SIGHUP, {SIG_IGN}, {SIG_DFL}, 8) = 0
> rt_sigaction(SIGHUP, {0x804f8d0, [HUP], SA_RESTART}, {SIG_IGN}, 8) = 0
> rt_sigaction(SIGTERM, {SIG_IGN}, {SIG_DFL}, 8) = 0
> rt_sigaction(SIGTERM, {0x804f8d0, [TERM], SA_RESTART}, {SIG_IGN}, 8) = 0
> rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0
> rt_sigaction(SIGPIPE, {0x804f8d0, [PIPE], SA_RESTART}, {SIG_IGN}, 8) = 0
> rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_DFL}, 8) = 0
> access("/usr/local/sbin/gcc", X_OK) = -1 ENOENT (No such file or
> directory)
> access("/usr/local/bin/gcc", X_OK) = -1 ENOENT (No such file or
> directory)
> access("/usr/sbin/gcc", X_OK) = -1 ENOENT (No such file or
> directory)
> access("/usr/bin/gcc", X_OK)= 0
> lstat64("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat64("/usr/bin", {st_mode=S_IFDIR|0755, st_size=65536, ...}) = 0
> lstat64("/usr/bin/gcc", {st_mode=S_IFLNK|0777, st_size=16, ...}) = 0
> readlink("/usr/bin/gcc", "/usr/bin/gcc-4.1", 4096) = 16
> lstat64("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat64("/usr/bin", {st_mode=S_IFDIR|0755, st_size=65536, ...}) = 0
> lstat64("/usr/bin/gcc-4.1", {st_mode=S_IFREG|0755, st_size=183904, ...}) = 0
> access("/usr/local/sbin/gcc", X_OK) = -1 ENOENT (No such file or
> directory)
> access("/usr/local/bin/gcc", X_OK) = -1 ENOENT (No such file or
> directory)
> access("/usr/sbin/gcc", X_OK) = -1 ENOENT (No such file or
> directory)
> access("/usr/bin/gcc", X_OK)= 0
> lstat64("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat64("/usr/bin", {st_mode=S_IFDIR|0755, st_size=65536, ...}) = 0
> lstat64("/usr/bin/gcc", {st_mode=S_IFLNK|0777, st_size=16, ...}) = 0
> readlink("/usr/bin/gcc", "/usr/bin/gcc-4.1",
Re: bootstrap broken on mingw
* FX Coudert wrote on Sun, Feb 17, 2008 at 12:54:05PM CET:
> >Actually there seems to be a recent change "backward" to that logic:
> >
> >2008-02-13 Ralf Wildenhues <[EMAIL PROTECTED]>
> >
> >PR other/35148
> >* Makefile.in (gcc-vers.texi): Use abs_srcdir for the value of
> >srcdir.
>
> Doesn't look too good for mingw.
>
> >and we have PR35218 which seems to be the same issue?
>
> Yes, it is exactly, it was open by Eric and I added my information. I
> should have given the PR number in my mail.
I see two possibilities: revert above patch, and list texinfo 4.11 as
prerequisite for building the pdf/dvi (I tried this version with the
current tree and above patch reverted). One alternative is to hack path
replacement into Makefile.in for MinGW. Ugly and error-prone, so I will
not recommend it at this point.
One question I have, Eric and FX: do you both have self-built texinfo on
MinGW? Because the specially-built one in /usr/bin should be able to
handle the file names just fine. I don't remember though which version
mingw.org provides, probably an older one only. If not, another
possibility would be to just require users on MinGW to update their
system texinfo installation.
Proposed patch for the first alternative (trunk and 4.2) below. OK?
Thanks, and sorry for the breakage.
Ralf
gcc/ChangeLog:
2008-02-17 Ralf Wildenhues <[EMAIL PROTECTED]>
* Makefile.in (gcc-vers.texi): revert 2008-02-13 change.
* doc/install.texi (Prerequisites, Final install): Texinfo 4.11
is required for DVI and PDF.
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 9c91fb5..7553dcb 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -3653,7 +3653,7 @@ gcc-vers.texi: $(BASEVER) $(DEVPHASE)
then echo "@set DEVELOPMENT"; \
else echo "@clear DEVELOPMENT"; \
fi) > [EMAIL PROTECTED]
- echo "@set srcdir $(abs_srcdir)" >> [EMAIL PROTECTED]
+ echo "@set srcdir $(srcdir)" >> [EMAIL PROTECTED]
if [ -n "$(PKGVERSION)" ]; then \
echo "@set VERSION_PACKAGE $(PKGVERSION)" >> [EMAIL PROTECTED]; \
fi
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 8411f44..4b3a421 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -397,7 +397,7 @@ files to test your changes.
Necessary for running @command{make dvi} or @command{make pdf} to
create printable documentation in DVI or PDF format. Texinfo version
-4.8 or later is required for @command{make pdf}.
+4.11 or later is required for @command{make dvi} and @command{make pdf}.
Necessary to build GCC documentation during development because the
generated output files are not included in the SVN repository. They are
@@ -2321,8 +2321,8 @@ and @TeX{} installed. This creates a number of
@file{.dvi} files in
subdirectories of @[EMAIL PROTECTED]; these may be converted for
printing with programs such as @command{dvips}. Alternately, by using
@samp{make pdf} in place of @samp{make dvi}, you can create documentation
-in the form of @file{.pdf} files; this requires @command{texi2pdf}, which
-is included with Texinfo version 4.8 and later. You can also
+in the form of @file{.pdf} files; this requires @command{texi2pdf} from
+Texinfo version 4.11 and later. You can also
@uref{http://www.gnu.org/order/order.html,,buy printed manuals from the
Free Software Foundation}, though such manuals may not be for the most
recent version of [EMAIL PROTECTED]
Re: bootstrap broken on mingw
On Sun, 17 Feb 2008, Ralf Wildenhues wrote: > I see two possibilities: revert above patch, and list texinfo 4.11 as > prerequisite for building the pdf/dvi I'm not in favor of making texinfo 4.11 a requirement. As far as I can see it was released less than half a year ago and even recent releases of popular systems such as openSUSE 10.3 or FreeBSD 6.3, both released a few months ago do not have this yet, though admittedly Fedora 8 does. No objection to make this a requirement for MinGW only, of course. Gerald
Re: bootstrap broken on mingw
[ adding gcc-patches ] * Gerald Pfeifer wrote on Sun, Feb 17, 2008 at 02:46:45PM CET: > On Sun, 17 Feb 2008, Ralf Wildenhues wrote: > > I see two possibilities: revert above patch, and list texinfo 4.11 as > > prerequisite for building the pdf/dvi > > I'm not in favor of making texinfo 4.11 a requirement. As far as I can > see it was released less than half a year ago and even recent releases of > popular systems such as openSUSE 10.3 or FreeBSD 6.3, both released a few > months ago do not have this yet, though admittedly Fedora 8 does. Note that it would be a requirement for `make dvi pdf' only. > No objection to make this a requirement for MinGW only, of course. That doesn't help, though, as the 4.11 requirement would be the alternative fix for PR 35148. So, here's another alternative: fix the MinGW issue only, while not regressing on any of the other reported bug (famous last words): One way for path translation on MinGW would be to use CMD //c echo "@set srcdir" "$(abs_srcdir)" as in the patch below. I need somebody to test this patch on MinGW, all I've done is ensure build_file_translate expands to empty on i686-pc-linux-gnu. Thanks, Ralf gcc/ChangeLog: 2008-02-17 Ralf Wildenhues <[EMAIL PROTECTED]> PR bootstrap/35218 * Makefile.in (build_file_translate): New. * config.build (build_file_translate): Set to `CMD //c' on MinGW. * configure.ac (build_file_translate): Substitute it. * configure: Regenerate. diff --git a/gcc/Makefile.in b/gcc/Makefile.in index 9c91fb5..022208a 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -253,6 +253,8 @@ POD2MAN = pod2man --center="GNU" --release="gcc-$(version)" # do not correctly set the timestamp due to buggy versions of `utime' # in the kernel. So, we use `echo' instead. STAMP = echo timestamp > +# Translate absolute file names to w32 paths. +build_file_translate = @build_file_translate@ # Make sure the $(MAKE) variable is defined. @SET_MAKE@ @@ -3653,7 +3655,7 @@ gcc-vers.texi: $(BASEVER) $(DEVPHASE) then echo "@set DEVELOPMENT"; \ else echo "@clear DEVELOPMENT"; \ fi) > [EMAIL PROTECTED] - echo "@set srcdir $(abs_srcdir)" >> [EMAIL PROTECTED] + $(build_file_translate) echo "@set srcdir" "$(abs_srcdir)" >> [EMAIL PROTECTED] if [ -n "$(PKGVERSION)" ]; then \ echo "@set VERSION_PACKAGE $(PKGVERSION)" >> [EMAIL PROTECTED]; \ fi diff --git a/gcc/config.build b/gcc/config.build index 4f5421b..62486db 100644 --- a/gcc/config.build +++ b/gcc/config.build @@ -47,6 +47,7 @@ build_xm_file= build_xm_defines= build_exeext= build_install_headers_dir=install-headers-tar +build_file_translate= # System-specific settings. case $build in @@ -79,6 +80,7 @@ case $build in i[34567]86-*-mingw32* | x86_64-*-mingw*) build_xm_file=i386/xm-mingw32.h build_exeext=.exe +build_file_translate="CMD //C" ;; i[34567]86-pc-msdosdjgpp*) build_xm_file=i386/xm-djgpp.h diff --git a/gcc/configure.ac b/gcc/configure.ac index f3bc7b3..bb7c056 100644 --- a/gcc/configure.ac +++ b/gcc/configure.ac @@ -3727,6 +3727,7 @@ AC_SUBST(build_install_headers_dir) AC_SUBST(build_xm_file_list) AC_SUBST(build_xm_include_list) AC_SUBST(build_xm_defines) +AC_SUBST(build_file_translate) AC_SUBST(check_languages) AC_SUBST(cpp_install_dir) AC_SUBST(xmake_file)
Re: Bootstrap is broken for i386-darwin8.10.1
On Sat, Feb 16, 2008 at 07:42:16PM +0100, Richard Guenther wrote: > On Feb 16, 2008 7:18 PM, Andrew Pinski <[EMAIL PROTECTED]> wrote: > > Hi, > > Even though darwin9 works, dariwn 8.10 is broken while build libjava: > > > > /Users/apinski/src/local/gcc/objdir/i386-apple-darwin8.10.1/libjava/.libs/libgcj.dylib(single > > module) definition of java resource sun/rmi/rmic/messages.properties > > ./.libs/libgcj-tools.dylib(single module) definition of java resource > > sun/rmi/rmic/messages.properties > > /usr/bin/ld: multiple definitions of symbol java resource > > com/sun/tools/javac/messages.properties > > > > > > Should I file a bug and will this be a blocker for the release? > > We list i686-apple-darwin as a primary platform, so this sort-of > blocks the release > as java is a default language. Please make sure a bugzilla exists for > this problem. Doesn't http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00265.html fix this? Don't have access to darwin to test that there myself... Jakub
Re: gcc hangs ! (version 4.1.2, Ubuntu 4.1.2-0ubuntu4)
Sunzir Deepur wrote: followup: After a considerabale amount of time (e.g. 15 seconds), something is suddenly freed, and the compilation completes successfully. afterwards trying to recompile the file completes immediately (it is not a big file, so it takes fraction of a second). I don't know what is the cause of the hang.. I can tell that while it is hung, the cpu is not working (gcc doesn't even show in top..). It's waiting on I/O. This delay is either network related or a disk is going to die. It almost certainly isn't a gcc bug. Andrew.
Re: Is anyone testing for a (cross-) target (board) with dynlinking?
On Tue 12 Feb 2008 13:47, Hans-Peter Nilsson pondered: > > From: Ian Lance Taylor <[EMAIL PROTECTED]> > > Date: 12 Feb 2008 07:48:51 -0800 > > Thanks to all. I no longer think there's anything that needs > fixing in the gcc testsuite regarding copying of libraries or in > particular libgcc_s.so.1; I just need my baseboard-file to copy > over every *.so* from ld_library_path or make them otherwise > accessible. It seems dejagnu deliberately leaves this to the > target, as it's not done for any other library either, and > ld_library_path is the blessed variable (no, not in the dejagnu > *documentation*; just used in the dejagnu sources with the same > use as in gcc. ;) This is what we do when we test via rsh/rcp on the Blackfin. (bfin-linux-uclibc- ) Have a peek at out our large shell script which builds and optionally tests everything. http://blackfin.uclinux.org/gf/project/toolchain/scmsvn/?action=browse&path=%2Ftrunk%2Fbuildscript%2FBuildToolChain&annotate=2175 What you are looking for is around lines 1354-1427 (prepare_target()) -Robin
Re: Bootstrap is broken for i386-darwin8.10.1
On Feb 17, 2008 3:17 PM, Jakub Jelinek <[EMAIL PROTECTED]> wrote: > > On Sat, Feb 16, 2008 at 07:42:16PM +0100, Richard Guenther wrote: > > On Feb 16, 2008 7:18 PM, Andrew Pinski <[EMAIL PROTECTED]> wrote: > > > Hi, > > > Even though darwin9 works, dariwn 8.10 is broken while build libjava: > > > > > > /Users/apinski/src/local/gcc/objdir/i386-apple-darwin8.10.1/libjava/.libs/libgcj.dylib(single > > > module) definition of java resource sun/rmi/rmic/messages.properties > > > ./.libs/libgcj-tools.dylib(single module) definition of java resource > > > sun/rmi/rmic/messages.properties > > > /usr/bin/ld: multiple definitions of symbol java resource > > > com/sun/tools/javac/messages.properties > > > > > > > > > Should I file a bug and will this be a blocker for the release? > > > > We list i686-apple-darwin as a primary platform, so this sort-of > > blocks the release > > as java is a default language. Please make sure a bugzilla exists for > > this problem. > > Doesn't http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00265.html > fix this? Don't have access to darwin to test that there myself... As it hasn't been applied yet (and I can't test darwin myself), Andrew, can you confirm the above patch fixes the bootstrap failure? Andrew, can you look at the above patch? Thanks, Richard.
API for callgraph and IPA passes for whole program optimization
Hi, since it seems that we are getting ready with LTO, I think it is time to write updated design document for callgraph and implementation of whole program optimizer as outlined in Whopr document http://gcc.gnu.org/wiki/whopr As usual, all comments or ideas are welcome ;) Basic organization == As described in whopr document, to have linktime optimizer scalable for whole programs of reasonable size, we need to: A) Push as much as possible into compilation stage, including preparing of "summary" information for interprocedural optimization and write that on disk. B) At linktime stage do all interprocedural optimization decisions based solely on the callgraph, variable pool and the summaries present in object files without actually needing to examine all function bodies. We have to expect that all function bodies won't fit in memory or take long to load. C) Final compilation should apply the decisions of interprocedural optimization and do local optimization and should be possible to distribute it. So every interprocedural optimization pass should be split into 3 phases: 1) local analysis producing simple and small function summary based on the function body analyzed alone. 2) global execution that based on the function summaries, callgraph and variable pool do the optimization decisions, note them in callgraph and varpool and somehow possibly update the local information of later IPA passes. The optimization summaries produced should be again small, simple and possible to save on disk. 3) local modification that takes the function body or variable initializer and applies changes based on optimization summary produced in 2). This is just rough outline: in real implementation we will probably want to do some limited interprocedural optimization at compilation stage (especially early inlining that enables a lot more optimization in C++) and we also will probably want to do some late interprocedural optimization on fragments of the whole program, such as IPA register allocation, that can't use summary produced so early in optimization. Current implementation status and short term plans == The IPA organized into separate analyze/execution/modify passes was part of original cgraph design. The design was outlined in 2004 GCC summit paper http://www.gccsummit.org/2004/2004-GCC-Summit-Proceedings.pdf Inliner was organized this way, later passes wasn't organized and enforcing this organization was difficult given the fact that linktime optimization wasn't in sight http://gcc.gnu.org/ml/gcc/2004-11/msg00694.html so the code was partly removed from mainline. Since inliner is one of more interesting passes in this point of view, reorganizing rest of optimizer should be that difficult at all. I planned to open IPA branch and do transition back to the organization, however it now seems that it is better done form part at stage1 directly on mainline (most changes was prototyped on IPA branch and worked well) and by part on LTO branch that now offer way to actually test the whole framework. This way the amount of changes at LTO branch remains localized and we won't run into conflict where IPA branch would need to be based on LTO branch to progress and vice versa. The plan would be to update passmanager first and transit main IPA passes (inliner, constant propagation, alias analysis) on mainline. The more advanced IPA stuff, as struct reorg can go later since it is not a showstopper for first incarnation of whole program optimizer anyway. On LTO branch we can do changes related to memory management and overall pass queue organization. Basic datastructure organization The callgraph and variable pool nodes are now split into the generic parts (such as callgraph edges) and the per-optimization summaries. Those all should be split into local and global parts: - local containing the function summary computed by stage A, - global part containing the result of computation. Temporary storage needed by the pass itself should be allocated in on-side array based on cgraph UIDs or in aux pointers. The local and global data are available via cgraph_local_info / cgraph_global_info accessors since the plan is to un-embed them from cgraph nodes once the memory consumption will justify it and also the functions perform an sanity checking. So implementation plan here would be just to enforce this split for all passes that wasn't exactly implemented this way. Basic passmanager changes = At the moment passmanager operates in two modes: 1) IPA mode for toplevel passes: those passes are executed in sequence once for compilation. 2) local mode for nested passes: those passes are executed in sequence (that is all nested passes in sequence up to next IPA pass) in topological order of callgraph on each function. I would like to (re)-add the following hooks
omp_get_num_procs() not working on macintosh?
Hi,
I'm not able to detect the number of processors using
omp_get_num_procs() on
a macintosh.
I've installed gcc/g++ v4.3 from hpc.sourceforge.net (the "Tiger"
version)
[Url 1 below]. (Installed = extracted to /)
$ g++ --version
g++ (GCC) 4.3.0 20080125 (experimental)
I compile the code below with no problems.
$ g++ -fopenmp main.cpp -o openmpTest
When the code executes omp_get_num_procs() detects 1 processor.
$ ./openmpTest
num procs 1
thread 0 i: 0
thread 0 i: 1
thread 0 i: 2
thread 0 i: 3
thread 0 i: 4
thread 0 i: 5
thread 0 i: 6
thread 0 i: 7
thread 0 i: 8
thread 0 i: 9
This macintosh has two physical chips and 2 cores per chip.
$ sysctl hw
[...]
hw.ncpu: 4
hw.activecpu: 4
[...]
Does anybody know why omp_get_num_procs() is returning 1 on this
machine?
Let me know if you need more info!
Thanks,
C.
[1]http://prdownloads.sourceforge.net/hpc/gcc-intel-bin.tar.gz?download
-
// "g++ -fopenmp main.cpp -o openmpTest"
#include
#ifdef _OPENMP // defined at compile time by -fopenmp
#include
#endif
using namespace std;
int main (int argc, char **argv) {
int n_iters = 10;
#ifdef OMP_H// defined in header omp.h
cout<<"num procs "<
Re: gcc hangs ! (version 4.1.2, Ubuntu 4.1.2-0ubuntu4)
On Feb 17, 2008 3:55 PM, Andrew Haley <[EMAIL PROTECTED]> wrote: > Sunzir Deepur wrote: > > followup: > > > > After a considerabale amount of time (e.g. 15 seconds), something is > > suddenly > > freed, and the compilation completes successfully. afterwards trying > > to recompile > > the file completes immediately (it is not a big file, so it takes > > fraction of a second). > > I don't know what is the cause of the hang.. I can tell that while it is > > hung, > > the cpu is not working (gcc doesn't even show in top..). > > It's waiting on I/O. This delay is either network related or a disk is > going to die. It almost certainly isn't a gcc bug. Thank you. Any idea how can I further scrutinize this ? > > Andrew. >
Re: bootstrap broken on mingw
* FX Coudert wrote on Sun, Feb 17, 2008 at 06:59:49PM CET: > > >If not, another > >possibility would be to just require users on MinGW to update their > >system texinfo installation. > > Weeks before the release? That doesn't give much time to anyone for > getting it working and actually testing the release candidates. OK. The latest patch that I posted should solve the MinGW issues (but is still untested). Cheers, Ralf
Re: bootstrap broken on mingw
gcc/ChangeLog: 2008-02-17 Ralf Wildenhues <[EMAIL PROTECTED]> PR bootstrap/35218 * Makefile.in (build_file_translate): New. * config.build (build_file_translate): Set to `CMD //c' on MinGW. * configure.ac (build_file_translate): Substitute it. * configure: Regenerate. I'm willing to try, but running "autoconf" doesn't regenerate the configure file, what am I missing? FX -- François-Xavier Coudert http://www.homepages.ucl.ac.uk/~uccafco/
Re: bootstrap broken on mingw
One question I have, Eric and FX: do you both have self-built texinfo on MinGW? Yes, because the one provided with MSYS is from texinfo 4.3, which GCC finds too old. Apparently, MSYS-1.0.11 will come with texinfo 4.11, but it's still labeled "technology preview" for now. Because the specially-built one in /usr/bin should be able to handle the file names just fine. mingw doesn't have texinfo, and the one from MSYS is too old... or maybe you're refering to MSYS-1.0.10? If not, another possibility would be to just require users on MinGW to update their system texinfo installation. Weeks before the release? That doesn't give much time to anyone for getting it working and actually testing the release candidates. -- François-Xavier Coudert http://www.homepages.ucl.ac.uk/~uccafco/
RE: bootstrap broken on mingw
> -Original Message- > From: FX Coudert [mailto:[EMAIL PROTECTED] > Sent: Sunday, February 17, 2008 11:00 AM > To: Ralf Wildenhues > Cc: Richard Guenther; Joerg Wunsch; GCC Development; > Weddington, Eric; Denis Chertykov; Anatoly Sokolov; Lamo, Jo Inge > Subject: Re: bootstrap broken on mingw > > > One question I have, Eric and FX: do you both have self-built > > texinfo on > > MinGW? > > Yes, because the one provided with MSYS is from texinfo 4.3, which > GCC finds too old. Apparently, MSYS-1.0.11 will come with texinfo > 4.11, but it's still labeled "technology preview" for now. > I'm in the same boat here, msys-1.0.10, texinfo 4.3. Eric Weddington
RE: bootstrap broken on mingw
> -Original Message- > From: Ralf Wildenhues [mailto:[EMAIL PROTECTED] > Sent: Sunday, February 17, 2008 11:05 AM > To: FX Coudert > Cc: Richard Guenther; Joerg Wunsch; GCC Development; > Weddington, Eric; Denis Chertykov; Anatoly Sokolov; Lamo, Jo Inge > Subject: Re: bootstrap broken on mingw > > * FX Coudert wrote on Sun, Feb 17, 2008 at 06:59:49PM CET: > > > > >If not, another > > >possibility would be to just require users on MinGW to update their > > >system texinfo installation. > > > > Weeks before the release? That doesn't give much time to > anyone for > > getting it working and actually testing the release candidates. > > OK. The latest patch that I posted should solve the MinGW issues > (but is still untested). > With that patch I'm now getting: (echo "@set version-GCC 4.3.0"; \ if [ "experimental" = "experimental" ]; \ then echo "@set DEVELOPMENT"; \ else echo "@clear DEVELOPMENT"; \ fi) > gcc-vers.texiT /bin/sh: build_file_translate@: command not found make[1]: *** [gcc-vers.texi] Error 127 make[1]: Leaving directory `/c/avrdev/gcc/build/gcc' make: *** [all-gcc] Error 2 Eric Weddington
RE: bootstrap broken on mingw
> -Original Message- > From: FX Coudert [mailto:[EMAIL PROTECTED] > Sent: Sunday, February 17, 2008 11:06 AM > To: Ralf Wildenhues > Cc: Gerald Pfeifer; Richard Guenther; Joerg Wunsch; GCC > Development; Weddington, Eric; Denis Chertykov; Anatoly > Sokolov; Lamo, Jo Inge; [EMAIL PROTECTED] > Subject: Re: bootstrap broken on mingw > > > gcc/ChangeLog: > > 2008-02-17 Ralf Wildenhues <[EMAIL PROTECTED]> > > > > PR bootstrap/35218 > > * Makefile.in (build_file_translate): New. > > * config.build (build_file_translate): Set to `CMD //c' > on MinGW. > > * configure.ac (build_file_translate): Substitute it. > > * configure: Regenerate. > > I'm willing to try, but running "autoconf" doesn't regenerate the > configure file, what am I missing? > I do: aclocal autoconf At the top level. aclocal 1.9.6, autoconf 2.59. Eric Weddington
Re: bootstrap broken on mingw
* Weddington, Eric wrote on Sun, Feb 17, 2008 at 08:41:02PM CET: > > > > I'm willing to try, but running "autoconf" doesn't regenerate the > > configure file, what am I missing? > > I do: > > aclocal > autoconf > > At the top level. aclocal 1.9.6, autoconf 2.59. You need to run autoconf in the gcc/ subdirectory. Sorry for not mentioning that right away.
Re: omp_get_num_procs() not working on macintosh?
On Sun, Feb 17, 2008 at 12:00:51PM -0500, CSights wrote: > I'm not able to detect the number of processors using > omp_get_num_procs() on > a macintosh. > I've installed gcc/g++ v4.3 from hpc.sourceforge.net (the "Tiger" > version) > [Url 1 below]. (Installed = extracted to /) > $ g++ --version > g++ (GCC) 4.3.0 20080125 (experimental) > I compile the code below with no problems. > $ g++ -fopenmp main.cpp -o openmpTest > When the code executes omp_get_num_procs() detects 1 processor. > $ ./openmpTest > num procs 1 > thread 0 i: 0 > thread 0 i: 1 > thread 0 i: 2 > thread 0 i: 3 > thread 0 i: 4 > thread 0 i: 5 > thread 0 i: 6 > thread 0 i: 7 > thread 0 i: 8 > thread 0 i: 9 > > This macintosh has two physical chips and 2 cores per chip. > $ sysctl hw > [...] > hw.ncpu: 4 > hw.activecpu: 4 > [...] > > Does anybody know why omp_get_num_procs() is returning 1 on this > machine? > Let me know if you need more info! Perhaps Darwin doesn't define _SC_NPROCESSORS_ONLN or sysconf (_SC_NPROCESSORS_ONLN) doesn't work properly on Darwin? If so, someone familiar with Darwin needs to provide (a tested) darwin specific proc.c implementation which can be added to libgomp/config/darwin/proc.c to replace the libgomp/config/posix/proc.c version. Jakub
Re: bootstrap broken on mingw
* Weddington, Eric wrote on Sun, Feb 17, 2008 at 08:32:26PM CET: > > With that patch I'm now getting: > > (echo "@set version-GCC 4.3.0"; \ > if [ "experimental" = "experimental" ]; \ > then echo "@set DEVELOPMENT"; \ > else echo "@clear DEVELOPMENT"; \ > fi) > gcc-vers.texiT > /bin/sh: build_file_translate@: command not found > make[1]: *** [gcc-vers.texi] Error 127 > make[1]: Leaving directory `/c/avrdev/gcc/build/gcc' > make: *** [all-gcc] Error 2 This happens when gcc/configure is not regenerated.
RE: bootstrap broken on mingw
> -Original Message-
> From: Ralf Wildenhues [mailto:[EMAIL PROTECTED]
> Sent: Sunday, February 17, 2008 1:18 PM
> To: Weddington, Eric
> Cc: FX Coudert; Gerald Pfeifer; Richard Guenther; Joerg
> Wunsch; GCC Development; Denis Chertykov; Anatoly Sokolov;
> Lamo, Jo Inge; [EMAIL PROTECTED]
> Subject: Re: bootstrap broken on mingw
>
> * Weddington, Eric wrote on Sun, Feb 17, 2008 at 08:41:02PM CET:
> > >
> > > I'm willing to try, but running "autoconf" doesn't
> regenerate the
> > > configure file, what am I missing?
> >
> > I do:
> >
> > aclocal
> > autoconf
> >
> > At the top level. aclocal 1.9.6, autoconf 2.59.
>
> You need to run autoconf in the gcc/ subdirectory. Sorry for not
> mentioning that right away.
Ok. I did the above and ran autoconf in the /gcc subdir. I got this
error:
if [ xinfo = xinfo ]; then \
makeinfo --split-size=500 --split-size=500 --no-split -I
. -I ../../gcc-4.3-20080215/gcc/doc \
-I ../../gcc-4.3-20080215/gcc/doc/include -o
doc/gcc.info ../../gcc-4.3-20080215/gcc/doc/gcc.texi; \
fi
../../gcc-4.3-20080215/gcc/doc//invoke.texi:1244: warning: undefined
flag: srcdir.
../../gcc-4.3-20080215/gcc/doc//invoke.texi:1243: @include `{No value
for `srcdir'}/../libiberty/at-file.texi': No such file or directory.
makeinfo: Removing output file `doc/gcc.info' due to errors; use --force
to preserve.
make[2]: *** [doc/gcc.info] Error 2
make[2]: Leaving directory `/c/avrdev/gcc/build/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/c/avrdev/gcc/build'
make: *** [all] Error 2
Is there any reason why we can't revert the patch that caused this?
Eric Weddington
Re: 4.3 build failure in driver-i386.c
Richard Guenther wrote:
> On Feb 17, 2008 9:38 AM, Greg Schafer <[EMAIL PROTECTED]> wrote:
>> .stabn 68,0,91,.LM210-__get_cpuid_max
>> .LM210:
>> #APP
>> pushf{l|d}
>> pushf{l|d}
>> pop{l} %eax
>> mov{l} {%eax, %edx|%edx, %eax}
>> xor{l} {$2097152, %eax|%eax, $2097152}
>> push{l} %eax
>> popf{l|d}
>> pushf{l|d}
>> pop{l} %eax
>> popf{l|d}
>>
>> #NO_APP
> The problem is that your host GCC doesn't recognize the inline asm correctly
> (the above should not reach the assembler), GCC 3.3.x handles the above fine.
> This probably also breaks build with non-GCC host compilers.
Ahh, OK. Then the problem is much more serious than I first thought. I
just tried GCC-2.95.3 and you are right, that fails too. I've filed a PR
so this issue doesn't get forgotten:
http://gcc.gnu.org/PR35239
Thanks
Greg
Re: omp_get_num_procs() not working on macintosh?
> Perhaps Darwin doesn't define _SC_NPROCESSORS_ONLN It is defined on Darwin9: [ibook-dhum] f90/bug% grep _SC_NPROCESSORS_ONLN /usr/include/* /usr/include/unistd.h:#define _SC_NPROCESSORS_ONLN58 but apparently not for Darwin8. Dominique
Re: bootstrap broken on mingw
* Ralf Wildenhues wrote on Sun, Feb 17, 2008 at 10:59:07PM CET: > * Weddington, Eric wrote on Sun, Feb 17, 2008 at 10:30:24PM CET: > > Is there any reason why we can't revert the patch that caused this? > > Well if we do then we need to reopen PR 35148 which would be equivalent > to requiring texinfo 4.11 (on all systems), which was not deemed > desirable earlier in this thread. Hmm. An alternative would be: revert the patch that caused this, document that users with texinfo older than 4.11 need to configure with an absolute path (/path/to/gcc/configure ...) if they want to be able to build DVI and PDF. Hmm, I suppose that will still not make things work with MinGW, as I doubt building like 'C:/path/to/gcc/configure ...' will work. Cheers, Ralf
RE: bootstrap broken on mingw
> -Original Message- > From: Ralf Wildenhues [mailto:[EMAIL PROTECTED] > Sent: Sunday, February 17, 2008 3:05 PM > To: Weddington, Eric; FX Coudert; Gerald Pfeifer; Richard > Guenther; Joerg Wunsch; GCC Development; Denis Chertykov; > Anatoly Sokolov; Lamo, Jo Inge; [EMAIL PROTECTED] > Subject: Re: bootstrap broken on mingw > > * Ralf Wildenhues wrote on Sun, Feb 17, 2008 at 10:59:07PM CET: > > * Weddington, Eric wrote on Sun, Feb 17, 2008 at 10:30:24PM CET: > > > Is there any reason why we can't revert the patch that > caused this? > > > > Well if we do then we need to reopen PR 35148 which would > be equivalent > > to requiring texinfo 4.11 (on all systems), which was not deemed > > desirable earlier in this thread. > > Hmm. An alternative would be: revert the patch that caused this, > document that users with texinfo older than 4.11 need to > configure with > an absolute path (/path/to/gcc/configure ...) if they want to > be able to > build DVI and PDF. > > Hmm, I suppose that will still not make things work with MinGW, as I > doubt building like 'C:/path/to/gcc/configure ...' will work. > No it wouldn't. I don't understand why reverting the patch would cause havoc. The 20080208 snapshot built just fine, even with an old texinfo version. I'd rather go back to that behaviour. I'm tyring out your new patch now... Eric Weddington
Re: bootstrap broken on mingw
* Weddington, Eric wrote on Sun, Feb 17, 2008 at 10:30:24PM CET:
>
> Ok. I did the above and ran autoconf in the /gcc subdir. I got this
> error:
>
> if [ xinfo = xinfo ]; then \
> makeinfo --split-size=500 --split-size=500 --no-split -I
> . -I ../../gcc-4.3-20080215/gcc/doc \
> -I ../../gcc-4.3-20080215/gcc/doc/include -o
> doc/gcc.info ../../gcc-4.3-20080215/gcc/doc/gcc.texi; \
> fi
> ../../gcc-4.3-20080215/gcc/doc//invoke.texi:1244: warning: undefined
> flag: srcdir.
> ../../gcc-4.3-20080215/gcc/doc//invoke.texi:1243: @include `{No value
> for `srcdir'}/../libiberty/at-file.texi': No such file or directory.
> makeinfo: Removing output file `doc/gcc.info' due to errors; use --force
> to preserve.
> make[2]: *** [doc/gcc.info] Error 2
> Is there any reason why we can't revert the patch that caused this?
Well if we do then we need to reopen PR 35148 which would be equivalent
to requiring texinfo 4.11 (on all systems), which was not deemed
desirable earlier in this thread.
What are the contents of your $builddir/gcc/gcc-vers.texi file? Too
much quoting? In that case, could you please delete that file and try
this patch instead (changes to configure included)? All I changed now
was remove quoting from the Makefile rule.
Sorry again for all the trouble.
Thanks,
Ralf
gcc/ChangeLog:
2008-02-17 Ralf Wildenhues <[EMAIL PROTECTED]>
PR bootstrap/35218
* Makefile.in (build_file_translate): New.
(gcc-vers.texi): Use it for translating $(abs_srcdir).
* config.build (build_file_translate): Set to `CMD //c' on MinGW.
* configure.ac (build_file_translate): Substitute it.
* configure: Regenerate.
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 9c91fb5..be9faaa 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -253,6 +253,8 @@ POD2MAN = pod2man --center="GNU" --release="gcc-$(version)"
# do not correctly set the timestamp due to buggy versions of `utime'
# in the kernel. So, we use `echo' instead.
STAMP = echo timestamp >
+# Translate absolute file names to w32 paths.
+build_file_translate = @build_file_translate@
# Make sure the $(MAKE) variable is defined.
@SET_MAKE@
@@ -3653,7 +3655,7 @@ gcc-vers.texi: $(BASEVER) $(DEVPHASE)
then echo "@set DEVELOPMENT"; \
else echo "@clear DEVELOPMENT"; \
fi) > [EMAIL PROTECTED]
- echo "@set srcdir $(abs_srcdir)" >> [EMAIL PROTECTED]
+ $(build_file_translate) echo @set srcdir $(abs_srcdir) >> [EMAIL
PROTECTED]
if [ -n "$(PKGVERSION)" ]; then \
echo "@set VERSION_PACKAGE $(PKGVERSION)" >> [EMAIL PROTECTED]; \
fi
diff --git a/gcc/config.build b/gcc/config.build
index 4f5421b..62486db 100644
--- a/gcc/config.build
+++ b/gcc/config.build
@@ -47,6 +47,7 @@ build_xm_file=
build_xm_defines=
build_exeext=
build_install_headers_dir=install-headers-tar
+build_file_translate=
# System-specific settings.
case $build in
@@ -79,6 +80,7 @@ case $build in
i[34567]86-*-mingw32* | x86_64-*-mingw*)
build_xm_file=i386/xm-mingw32.h
build_exeext=.exe
+build_file_translate="CMD //C"
;;
i[34567]86-pc-msdosdjgpp*)
build_xm_file=i386/xm-djgpp.h
diff --git a/gcc/configure b/gcc/configure
index ed7bba1..0347f38 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -309,7 +309,7 @@ ac_includes_default="\
# include
#endif"
-ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME
PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix
program_transform_name bindir sbindir libexecdir datadir sysconfdir
sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir
build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS build
build_cpu build_vendor build_os host host_cpu host_vendor host_os target
target_cpu target_vendor target_os target_noncanonical build_libsubdir
build_subdir host_subdir target_subdir GENINSRC CC CFLAGS LDFLAGS CPPFLAGS
ac_ct_CC EXEEXT OBJEXT NO_MINUS_C_MINUS_O OUTPUT_OPTION CPP EGREP loose_warn
cxx_compat_warn strict_warn warn_cflags nocommon_flag TREEBROWSER valgrind_path
valgrind_path_defines valgrind_command coverage_flags enable_multilib
enable_decimal_float enable_fixed_point enable_shared TARGET_SYSTEM_ROOT
TARGET_SYSTEM_ROOT_DEFINE CROSS_SYSTEM_HEADER_DIR onestep PKGVERSION
REPORT_BUGS_TO REPORT_BUGS_TEXI datarootdir docdir htmldir SET_MAKE AWK LN_S LN
RANLIB ac_ct_RANLIB ranlib_flags INSTALL INSTALL_PROGRAM INSTALL_DATA
make_compare_target have_mktemp_command MAKEINFO BUILD_INFO GENERATED_MANPAGES
FLEX BISON NM AR COLLECT2_LIBS GNAT_LIBEXC LDEXP_LIB TARGET_GETGROUPS_T
LIBICONV LTLIBICONV LIBICONV_DEP manext objext gthread_flags extra_modes_file
extra_opt_files USE_NLS LIBINTL LIBINTL_DEP INCINTL XGETTEXT GMSGFMT POSUB
CATALOGS DATADIRNAME INSTOBJEXT GENCAT CATOBJEXT host_cc_for_libada CROSS ALL
SYSTEM_HEADER_DIR inhibit_libc CC_FOR_BUILD BUILD_CFLAGS STMP_FIXINC
STMP_FIXPROTO collect2 gcc_cv_as ORIGINAL_AS_FOR_TARGE
Re: bootstrap broken on mingw
* Weddington, Eric wrote on Sun, Feb 17, 2008 at 11:08:58PM CET: > > No it wouldn't. I don't understand why reverting the patch would cause > havoc. The 20080208 snapshot built just fine, even with an old texinfo > version. I'd rather go back to that behaviour. It didn't for me, with texinfo 4.8, nor for the reporter of PR 35148, as 'make pdf' failed. I have not investigated the cause of that bug further, but I suppose it's a texinfo issue (that maybe exists only in some texinfo releases?) > I'm tyring out your new patch now... Thanks. BTW, if it works, OK for trunk and 4.2? If that does not work, then I will revert the breaking patch first thing tomorrow morning (UTC). Cheers, Ralf
Re: 4.3 build failure in driver-i386.c
On Sun, Feb 17, 2008 at 11:07:54AM +0100, Richard Guenther wrote: > On Feb 17, 2008 10:54 AM, Andreas Schwab <[EMAIL PROTECTED]> wrote: > > "Richard Guenther" <[EMAIL PROTECTED]> writes: > > > > > I see the use of cpuid.h is wrapped inside #ifdef __GNUC__, so the issue > > > is only > > > using old GCC as the host compiler (I checked 2.95 which chokes on the > > > asm). > > > Can we change this guard to only allow GCC >= 3.3 which would also fix > > > this? > > > > Won't those host dependent parameters cause bootstrap comparison > > failures? If the stage1 compiler doesn't use the same detection > > routines as the stage2 compiler then the stage2 compiler is compiled > > with different options than the stage3 compiler. > > If you bootstrap with BOOT_CFLAGS="-march=native" yes, otherwise no. > Maybe we should build > i386-driver.c with the stage1 compiler and not the host compiler, > which of course > causes a chicken and egg problem... Or we can just duplicate the 2 inline asms for __GNUC__ < 3 or what is the oldest GCC that can handle the alternatives correctly. The __cpuid asm is short and the other one, while long, doesn't need changing too often. Jakub
Re: bootstrap broken on mingw
On Sun, 17 Feb 2008, Ralf Wildenhues wrote: > So, here's another alternative: fix the MinGW issue only, while not > regressing on any of the other reported bug (famous last words): > One way for path translation on MinGW would be to use > CMD //c echo "@set srcdir" "$(abs_srcdir)" If the abs_srcdir value is not usable by the host tools on some platform, shouldn't that be fixed in the code setting abs_srcdir, and not for an individual use of abs_srcdir? Or is it not feasible to fix the abs_srcdir setting without changing Autoconf itself? -- Joseph S. Myers [EMAIL PROTECTED]
procedure to make MELT branch on GCC SVN?
Hello All,
I am a bit confused about how to make a branch on GCC SVN.
I've got some sources (see my home page) but it is buggy. Diego Novillo
told me gently (in private email) that I should make the branch (thanks
Diego).
I started a wiki page: http://gcc.gnu.org/wiki/MiddleEndLispTranslator
Legal stuff is done long time ago: I have "write after approval" status!
(thanks to Manuel López-Ibáñez for his editions on the wiki)
In http://gcc.gnu.org/ml/gcc/2008-02/msg00255.html I announced it.
In http://gcc.gnu.org/ml/gcc/2008-02/msg00256.html Gerald Pfeifer
suggested to announce it (but I thought already did) and to update the
web pages.
I am quite scared about messing up the CVS; I am much more easy with the
SVN.
Can I just start my branch with
svn cp svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk \
svn+ssh://[EMAIL PROTECTED]/svn/gcc/melt-branch
and then do the usual svn stuff (addition, etc...)
or is there some (either social or technical) step that I missed?
While I do make lot of bugs (and I am not entirely proud of my current
code), I really do not want to upset the GCC community!
I am a bit confused about this "making a branch" thing; I thought that
by definition it is some informal experiment, but I'm beginning to think
that it might be much more formal... and I don't grasp all the details!
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: procedure to make MELT branch on GCC SVN?
> "Basile" == Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes: Basile> Can I just start my branch with Basile> svn cp svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk \ Basile> svn+ssh://[EMAIL PROTECTED]/svn/gcc/melt-branch Basile> and then do the usual svn stuff (addition, etc...) Basile> or is there some (either social or technical) step that I missed? I'd recommend the instructions on the wiki: http://gcc.gnu.org/wiki/SvnBranch In particular you might consider the svnmerge thing. Basile> While I do make lot of bugs (and I am not entirely proud of my Basile> current code), I really do not want to upset the GCC Basile> community! It is a bit scary but it'll turn out ok :). I'm looking forward to seeing your code. Tom
Re: procedure to make MELT branch on GCC SVN?
On Feb 17, 2008 11:41 PM, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote: > Hello All, > > I am a bit confused about how to make a branch on GCC SVN. > > I've got some sources (see my home page) but it is buggy. Diego Novillo > told me gently (in private email) that I should make the branch (thanks > Diego). > > I started a wiki page: http://gcc.gnu.org/wiki/MiddleEndLispTranslator > > Legal stuff is done long time ago: I have "write after approval" status! > > (thanks to Manuel López-Ibáñez for his editions on the wiki) > > In http://gcc.gnu.org/ml/gcc/2008-02/msg00255.html I announced it. > In http://gcc.gnu.org/ml/gcc/2008-02/msg00256.html Gerald Pfeifer > suggested to announce it (but I thought already did) and to update the > web pages. > > I am quite scared about messing up the CVS; I am much more easy with the > SVN. > > Can I just start my branch with >svn cp svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk \ > svn+ssh://[EMAIL PROTECTED]/svn/gcc/melt-branch svn+ssh://[EMAIL PROTECTED]/svn/gcc/branches/melt-branch (note /branches/), otherwise this is all you need to to. Richard.
Re: procedure to make MELT branch on GCC SVN?
On 17/02/2008, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote: > > I am a bit confused about this "making a branch" thing; I thought that > by definition it is some informal experiment, but I'm beginning to think > that it might be much more formal... and I don't grasp all the details! As far as I know, for an existing contributor (legal stuff sorted out and write-privileges in subversion) there are 3 steps: 1. Announce it. I think you already did that. 2. Update http://gcc.gnu.org/svn.html#devbranches. This is easier than it seems. http://gcc.gnu.org/cvs.html explains all but basically you will do: cvs -z 9 -d :ext:[EMAIL PROTECTED]:/cvs/gcc co wwwdocs cd wwwdocs emacs htdocs/svn.html cvs -q diff (to check your changes) cvs up cvs ci htdocs/svn.html 3. Create the branch: http://gcc.gnu.org/wiki/SvnBranch These 3 steps may be performed in any order. Cheers, Manuel.
RE: bootstrap broken on mingw
> -Original Message- > From: Ralf Wildenhues [mailto:[EMAIL PROTECTED] > Sent: Sunday, February 17, 2008 3:39 PM > To: Weddington, Eric > Cc: FX Coudert; Gerald Pfeifer; Richard Guenther; Joerg > Wunsch; GCC Development; Denis Chertykov; Anatoly Sokolov; > Lamo, Jo Inge; [EMAIL PROTECTED] > Subject: Re: bootstrap broken on mingw > > * Weddington, Eric wrote on Sun, Feb 17, 2008 at 11:08:58PM CET: > > > I'm tyring out your new patch now... > > Thanks. BTW, if it works, OK for trunk and 4.2? If that > does not work, > then I will revert the breaking patch first thing tomorrow > morning (UTC). Success! With your last patch. Built for host=mingw, target=avr. Thanks for fixing this! Eric Weddington
Re: 4.3 build failure in driver-i386.c
On Sun, Feb 17, 2008 at 11:44:18PM +0100, Jakub Jelinek wrote: > > Or we can just duplicate the 2 inline asms for __GNUC__ < 3 > or what is the oldest GCC that can handle the alternatives correctly. > The __cpuid asm is short and the other one, while long, doesn't need > changing too often. I'll try to fix it that way. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year
Re: bootstrap broken on mingw
* Joseph S. Myers wrote on Sun, Feb 17, 2008 at 11:42:34PM CET: > On Sun, 17 Feb 2008, Ralf Wildenhues wrote: > > > So, here's another alternative: fix the MinGW issue only, while not > > regressing on any of the other reported bug (famous last words): > > One way for path translation on MinGW would be to use > > CMD //c echo "@set srcdir" "$(abs_srcdir)" > > If the abs_srcdir value is not usable by the host tools on some platform, > shouldn't that be fixed in the code setting abs_srcdir, and not for an > individual use of abs_srcdir? Or is it not feasible to fix the abs_srcdir > setting without changing Autoconf itself? First, since Autoconf code sets abs_srcdir, a clean change of the code should be inside Autoconf. That could be overridden in configure.ac, for GCC only. This path translation is really necessary on MinGW only for programs that have not been provided by mingw.org and thus do not live below /bin, and that also receive paths via means other than the command line. IIRC, the tools below /bin are compiled in a way that they don't need path translation, and for tools placed elsewhere, the system translates command line arguments that somehow look like absolute paths. Blanket abs_srcdir translation for a system whose very reason of existence is to allow to run configure scripts (unmodified?), is to be weighed against the danger that abs_srcdir uses may not be prepared for a C: directory prefix. Thus my proposal to limit the translation to the places where it's absolutely necessary. I would further suggest to plan to remove the use of abs_srcdir for gcc-vers.texi at all again as soon as fixed texinfo 4.11 can be required. Should I note this alongside the Makefile rule? OK for trunk and 4.2? Thanks, Ralf
Re: 4.3 build failure in driver-i386.c
On Mon, Feb 18, 2008 at 03:58:26AM +0100, Rask Ingemann Lambertsen wrote: > On Sun, Feb 17, 2008 at 11:44:18PM +0100, Jakub Jelinek wrote: > > > > Or we can just duplicate the 2 inline asms for __GNUC__ < 3 > > or what is the oldest GCC that can handle the alternatives correctly. > > The __cpuid asm is short and the other one, while long, doesn't need > > changing too often. > >I'll try to fix it that way. BTW, I've just tested gcc 3.2.x and 2.96-RH (the oldest I could find around) and both handle the alternatives in asm just fine. >From what I can see in SVN, ASSEMBLER_DIALECT is defined in config/i386.h since the merge of the "new" i386 backend by rth in September 1999. As 2.96-RH wasn't an official FSF release and nobody probably used it in Intel mode anyway, I think __GNUC__ < 3 is the right test. Jakub
Re: Optimizations documentation
Thanks a lot for tracking down / opening the relevant PRs.
about:
> > (6) loop distribution is required to break a dependence. This may
> > already be handled by Sebastian's loop-distribution pass that will
> > be incorporated in 4.4.
> > Here is an example:
> > for (i__ = 2; i__ <= i__2; ++i__)
> > {
> > a[i__] += c__[i__] * d__[i__];
> > b[i__] = a[i__] + d__[i__] + b[i__ - 1];
> > }
> > This happens in the loop in line 2136.
> > Need to check if we need to open a missed optimization PR for this.>
>
> I don't think that this is a loop distribution issue. The dependence
> between the store to a[i] and the load from a[i] doesn't prevent
> vectorization.
right,
> The problematic one is between the store to b[i] and
> the load from b[i-1] in the second statement.
...which is exactly why loop distribution could make this loop (partially)
vectorizable - separating the first and second statements into separate
loops would allow vectorizing the first of the two resulting loops (which
is probably what icc does - icc reports that this loop is partially
vectrizable).
dorit
Ira Rosen/Haifa/IBM wrote on 17/02/2008 11:42:55:
> Hi,
>
> Dorit Nuzman/Haifa/IBM wrote on 14/02/2008 17:02:45:
>
> > This is an old debt: A while back Tim had sent me a detailed report
> > off line showing which C++ tests (originally from the Dongara loops
> > suite) were vectorized by current g++ or icpc, or both, as well as
> > when the vectorization by icpc required a pragma, or was partial. I
> > went over the loops that were reported to be vectorized by icc but
> > not by gcc, to see which features we are missing. There are 23 such
> > loops (out of a total of 77). They fall into the following 7
categories:
> >
> > (1) scalar evolution analysis fails with "evolution of base is
notaffine".
> > This happens in the 3 loops in lines 4267, 4204 and 511.
> > Here an example:
> > for (i__ = 1; i__ <= i__2; ++i__)
> > {
> > a[i__] = (b[i__] + b[im1] + b[im2]) * .333f;
> > im2 = im1;
> > im1 = i__;
> > }
> > Missed optimization PR to be opened.
>
> I opened PR35224.
>
> >
> > (2) Function calls inside a loop. These are calls to the math
> > functions sin/cos, which I expect would be vectorized if the proper
> > simd math lib was available.
> > This happens in the loop in line 6932.
> > I think there's an open PR for this one (at least for
> > powerpc/Altivec?) - need to look/open.
>
> There is PR6.
>
> >
> > (3) This one is the most dominant missed optimization: if-conversion
> > is failing to if-convert, most likely due to the very limited
> > handling of loads/stores (i.e. load/store hoisting/sinking is
required).
> > This happens in the 13 loops in lines 4085, 4025, 3883, 3818, 3631,
> > 355, 3503, 2942, 877, 6740, 6873, 5191, 7943.
> > There is on going work towards addressing this issue - see http:
> > //gcc.gnu.org/ml/gcc/2007-07/msg00942.html, http://gcc.gnu.
> > org/ml/gcc/2007-09/msg00308.html. (I think Victor Kaplansky is
> > currently working on this).
> >
> > (4) A scalar variable, whose address is taken outside the loop (in
> > an enclosing outer-loop) is analyzed by the data-references
> > analysis, which fails because it is invariant.
> > Here's an example:
> > for (nl = 1; nl <= i__1; ++nl)
> > {
> > sum = 0.f;
> > for (i__ = 1; i__ <= i__2; ++i__)
> > {
> > a[i__] = c__[i__] + d__[i__];
> > b[i__] = c__[i__] + e[i__];];
> > sum += a[i__] + b[i__];];];
> > }
> > dummy_ (ld, n, &a[1], &b[1], &c__[1], &d__[1], &e[1], &aa
[aa_offset],>
> > &bb[bb_offset], &cc[cc_offset], &sum);
> > }
> > (Analysis of 'sum' fails with "FAILED as dr address is invariant".
> > This happens in the 2 loops in lines 5053 and 332.
> > I think there is a missed optimization PR for this one already. need
> > to look/open.
> >
>
> The related PRs are PR33245 and PR33244. Also there is a FIXME
> comment in tree-data-ref.c before the failure with "FAILED as dr
> address is invariant" error:
>
> /* FIXME -- data dependence analysis does not work correctly
> for objects with
> invariant addresses. Let us fail here until the problem
isfixed. */
>
>
> > (5) Reduction and induction that involve multiplication (i.e. 'prod
> > *= CST' or 'prod *= a[i]') are currently not supported by the
> > vectorizer. It should be trivial to add support for this feature
> > (for reduction, it shouldn't be much more than adding a case for
> > MULT_EXPR in tree-vectorizer.c:reduction_code_for_scalar_code, I
think).
> > This happens in the 2 loops in lines 4921 and 4632.
> > A missed-optimization PR to be opened.
>
> Opened PR35226.
>
> >
> > (6) loop distribution is required to break a dependence. This may
> > already be handled by Sebastian's loop-distribution pass that will
> > be incorporated in 4.4.
> > Here is an example:
> > for (i__ = 2; i__ <= i__2; ++i__)
> > {
> >
Re: Optimizations documentation
Dorit Nuzman/Haifa/IBM wrote on 18/02/2008 09:40:37:
> Thanks a lot for tracking down / opening the relevant PRs.
>
> about:
>
> > > (6) loop distribution is required to break a dependence. This may
> > > already be handled by Sebastian's loop-distribution pass that will
> > > be incorporated in 4.4.
> > > Here is an example:
> > > for (i__ = 2; i__ <= i__2; ++i__)
> > > {
> > > a[i__] += c__[i__] * d__[i__];
> > > b[i__] = a[i__] + d__[i__] + b[i__ - 1];
> > > }
> > > This happens in the loop in line 2136.
> > > Need to check if we need to open a missed optimization PR for this.
> >
> > I don't think that this is a loop distribution issue. The dependence
> > between the store to a[i] and the load from a[i] doesn't prevent
> > vectorization.
>
> right,
>
> > The problematic one is between the store to b[i] and
> > the load from b[i-1] in the second statement.
>
> ...which is exactly why loop distribution could make this loop
> (partially) vectorizable - separating the first and second
> statements into separate loops would allow vectorizing the first of
> the two resulting loops (which is probably what icc does - icc
> reports that this loop is partially vectrizable).
Yes, I see now.
I applied Sebastian's patch (
http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00215.html) and got
"FIXME: Loop 1 not distributed: failed to build the RDG."
Ira
>
> dorit
>
