Re: The return of the bootstrap comparison failure on i386
On Fri, 11 Sep 2009 21:09:22 -0600 Ryan Hill wrote: > I haven't been able to bootstrap x86_64-unknown-linux-gnu at all since this > started. Latest attempt was with r151649. > Configured as: > > /var/tmp/portage/sys-devel/gcc-4.5.0_pre/work/gcc-4.5.0-/configure > --prefix=/usr --bindir=/usr/x86_64-unknown-linux-gnu/gcc-bin/4.5.0-pre > --includedir=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0-pre/include > --datadir=/usr/share/gcc-data/x86_64-unknown-linux-gnu/4.5.0-pre > --mandir=/usr/share/gcc-data/x86_64-unknown-linux-gnu/4.5.0-pre/man > --infodir=/usr/share/gcc-data/x86_64-unknown-linux-gnu/4.5.0-pre/info > --with-gxx-include-dir=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0-pre/include/g++-v4 > --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu > --disable-altivec --disable-fixed-point --with-ppl --with-cloog --disable-nls > --with-system-zlib --disable-checking --disable-werror --enable-secureplt > --enable-multilib --disable-libmudflap --disable-libssp --enable-libgomp > --enable-cld > --with-python-dir=/share/gcc-data/x86_64-unknown-linux-gnu/4.5.0-pre/python > --disable-libgcj --enable-languages=c,c++ --enable-shared > --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu > --with-bugurl="http://bugs.gentoo.org/"; --with-pkgversion="Gentoo SVN" I was able to build using --enable-checking. Should I file a new PR? -- fonts, Character is what you are in the dark. gcc-porting, wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: The return of the bootstrap comparison failure on i386
On Sat, 12 Sep 2009, Ryan Hill wrote: >> I haven't been able to bootstrap x86_64-unknown-linux-gnu at all since this >> started. Latest attempt was with r151649. >> Configured as: > I was able to build using --enable-checking. Should I file a new PR? If you are still seeing this, I think that would be appropriate. Gerald
Re: i370 port
It was dropped from GCC 4 when there was supposedly no
maintainer available. Actually, Dave Pitts and myself were
both maintaining it at that time, but we were both still working
on an old version of it (3.2). So gcc 3.4.6, circa 2004, was the
last time it was included in the normal GCC distribution.
(For reference, the port was removed in SVN revision 77216; before then it
had had various largely mechanical changes as part of changes to multiple
back ends or target-independent code, with r69086 as the last vaguely
i370-only change but no changes appearing to come from someone
specifically working and testing on i370 for some years before then. "svn
log svn://gcc.gnu.org/svn/gcc/trunk/gcc/config/i...@77215" shows the
history.)
I just took a look to see if there was anything changed on the head
that didn't make it into 3.4.6. Short answer: no.
Long answer:
C:\devel\gccoff>diff gccnew gcchead
Only in gcchead: .svn
diff gccnew/i370.h gcchead/i370.h
530,531c530
< #define INIT_CUMULATIVE_ARGS(CUM, FNTYPE, LIBNAME, INDIRECT, N_NAMED_ARGS)
\
< ((CUM) = 0)
---
#define INIT_CUMULATIVE_ARGS(CUM, FNTYPE, LIBNAME, INDIRECT) ((CUM) = 0)
I just need to delete that N_NAMED_ARGS when upgrading.
I'm sure that will be the least of my worries though. I'm more
worried about things like the below. :-)
Incidentally, 15 years of effort to get a hosted GCC compiler on
real MVS (not USS) came to realization on Jan 11, 2004:
http://osdir.com/ml/emulators.hercules390.mvs/2004-01/msg00031.html
(although it wasn't released until March 2004 when it was good
enough to self-compile.)
The revision that deleted i370 was made on Feb 4th, 2004. How's
that for timing?
Incidentally, while it may look from this angle like the i370 port
wasn't being worked on, it's actually had a huge amount of
effort put into it. The activity has just been in different forums
(like the one above). It wasn't just GCC though. A lot of
infrastructure was required. E.g. even the assembler didn't
support such a huge number of externals that was being
generated by GCC, so first I hacked around that in GCC
itself, mapping a whole lot of "unused" flags to be the same,
and then reversed that out when someone came up with a
modification to the assembler.
Then we needed to switch from 24-bit mode to 31-bit mode to
get the required memory for GCC to self-compile. Another
huge enterprise.
I would encourage going through all the changes made to the i370 port on
GCC mainline, after 3.1/3.2 branched and before the port was removed, to
see what should be merged into your version for mainline; ultimately it
would be up to you how you get it updated for all the mechanical changes
on mainline since 3.2, but those changes (see command above to get logs)
may be a useful guide to how to do some of the updates.
All the merging has already been done in the 3.4.6 effort. The only
thing that I know of that is still "at large" is someone else who was
working "offline" and made some changes. Specifically this:
http://osdir.com/ml/emulators.hercules390.mvs/2004-01/msg8.html
as I just discovered the same problem with both of these strict moves
now that I too am using 3.4.6.
The i370.md looks correct to me (this is the movstricthi one):
;(define_insn ""
; [(set (strict_low_part (match_operand:HI 0 "register_operand" "+d"))
; (match_operand:HI 1 "general_operand" "dSi"))]
; ""
; "*
;{
; check_label_emit ();
; if (REG_P (operands[1]))
;{
; mvs_check_page (0, 8, 0);
; return \"STH %1,\" CONVLO \"(,13)\;ICM %0,3,\" CONVLO
\"(13)\";
;}
; else if (GET_CODE (operands[1]) == CONST_INT)
;{
; mvs_check_page (0, 4, 2);
; return \"ICM %0,3,%H1\";
;}
; mvs_check_page (0, 4, 0);
; return \"ICM %0,3,%1\";
;}"
; [(set_attr "length" "8")]
;)
but I have had to comment it out, because otherwise I get code like
this generated:
L691 EQU *
SLR 2,2
IC2,0(8)
LA5,92(0,0)
CLR 2,5
BEL699
BHL702
ICM 5,3,=H'64'
BEL696
ICM 5,3,=H'78'
BEL694
B L701
ie the LA and CLR combination are what I would expect, but gcc 3.4.6
has decided to use an ICM to move a constant in, which seems an
awful waste to me instead of using LA, but the real problem is that
it hasn't generated a CLR afterwards (it needs to compare against
register 2), so isn't taking a branch it should be.
I didn't have this problem in 3.2.3, which has a virtually identical
machine definition. But I'd be really surprised to find a serious
compiler bug outside of the i370 code?! I assume I'm just looking
in the wrong spot.
But at least I'm making progress. :-)
BFN. Paul.
Re: Add my name to Write-after-Approval List
On Mon, 22 Jun 2009, Li Feng wrote: > This is the patch that add my name to Write-after-Approval List. Thanks for doing this, Li Feng. Sadly I realized that many other haven't done so in the past, and while I managed to resolve a number of those this year so far, the following are still open: The following accounts on gcc.gnu.org have primary group gcc, but their real names do not appear in the GCC MAINTAINERS file. Last commit #commits marekm (Marek Michalkiewicz )2005-03-20 57 zlaski (Ziemowit Laski )2005-09-29 429 gp (Graeme Peterson )2003-08-063 sgilbertson (Scott Gilbertson)2006-02-23 13 rodimina(Olga Rodimina )2005-01-06 59 victorlei (Victor Leikehman)2004-11-181 aluchko (Aaron Luchko)2005-07-149 rkidd (Robert Kidd )2007-09-10 11 olga(Olga Golovanevsky )2008-03-19 37 dalecki (Marcin Dalecki )2006-12-29 13 kgallowa(Kyle Galloway )2007-05-17 38 olegr (Oleg Ryjkov )2008-04-25 28 jfreeman(John Freeman)2009-08-29 118 yechiel (Yechiel Kimchi ) martin (Martin Schindewolf ) setton (Nicolas Setton ) jingyu (Jing Yu )2009-04-284 liao(Shih-wei Liao ) tglek (Taras Glek )2009-05-276 Hopefully the combined wisdom on this list can help getting this addressed (one way or the other). :-) Gerald
Re: Mirrors
On Fri, 28 Aug 2009, Yuriy Kolesnikov wrote: > Please provide more information, like here > https://launchpad.net/ubuntu/+archivemirrors This is a nice idea. Are you interested in working on it? As you may know, GCC is a volunteer project and we appreciate any help we can get also on the infrastructure side. Gerald
Re: Problems with lambda implementation
On 09/10/2009 03:45 PM, Sergey Sadovnikov wrote: 1. Lambda and template type deduction. A patch I've been holding off on committing happens to fix this bug. This is surprising, as I thought it was just a code cleanup. I guess I'll go ahead and commit it soon. 2. Lambdas and result_of or something similar. How I can determine return type of lambda in compile time? As far as I could understood there is no way to do so. Is it right? Use decltype? Jason
Re: Problems with lambda implementation
On 09/12/2009 08:11 PM, Jason Merrill wrote: On 09/10/2009 03:45 PM, Sergey Sadovnikov wrote: 1. Lambda and template type deduction. A patch I've been holding off on committing happens to fix this bug. This is surprising, as I thought it was just a code cleanup. I guess I'll go ahead and commit it soon. Done. Jason
Error in fortran/module.c
Hello, I get the following error while bootstrap on x86_64: Thanks, Revital /home/revitale/test_mainline_45/build/./prev-gcc/xgcc -B/home/revitale/test_mainline_45/build/./prev-gcc/ -B/home/revitale/test_mainline_45/build/x86_64-unknown-linux-gnu/bin/ -B/home/revitale/test_mainline_45/build/x86_64-unknown-linux-gnu/bin/ -B/home/revitale/test_mainline_45/build/x86_64-unknown-linux-gnu/lib/ -isystem /home/revitale/test_mainline_45/build/x86_64-unknown-linux-gnu/include -isystem /home/revitale/test_mainline_45/build/x86_64-unknown-linux-gnu/sys-include -c -O3 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -Ifortran -I../../gcc/gcc -I../../gcc/gcc/fortran -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I/usr/local//include -I/opt/cfarm/mpfr-2.3.1//include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid -I../libdecnumber../../gcc/gcc/fortran/module.c -o fortran/module.o cc1: warnings being treated as errors ../../gcc/gcc/fortran/module.c: In function גmio_f2k_derivedג: ../../gcc/gcc/fortran/module.c:3465:19: error: גopג may be used uninitialized in this function. make[3]: *** [fortran/module.o] Error 1 make[3]: Leaving directory `/home/revitale/test_mainline_45/build/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/home/revitale/test_mainline_45/build' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/home/revitale/test_mainline_45/build' make: *** [bootstrap] Error 2
