Re: CSE removing a load that is necessary
Hi, > Or perhaps this could be another manifestation of the "cse gets confused by > reg_equal notes on subparts of dimode pseudos if no movdi pattern is defined > in the backend" bug[*]? Pranav, is there a movdi pattern in your backend? > There needs to be one, gcc does get it wrong if you rely on it to break > everything down to si-sized movs. Yes, It looks like a similar problem, but there seems to be no consensus on a correct solution to this problem. I couldnt find the bug number but this thread describes the exact same problem ( but with REG_EQUIV notes). http://gcc.gnu.org/ml/gcc/2001-02/msg01372.html Thanks, Pranav
Bootstrap error on i686-pc-linux-gnu
Hello, bootstrapping with GCC 4.3. from today is not successfull on my computer i686-pc-linux-gnu. configure flags: --enable-languages=ada,c,c++,fortran,java,objc,obj-c++,treelang --with-mpfr=/usr/local Here is the error message: make[5]: Leaving directory `/data/usr_local/xx/gccobj/i686-pc-linux-gnu/libgcc' make[4]: Leaving directory `/data/usr_local/xx/gccobj/i686-pc-linux-gnu/libgcc' make[3]: Leaving directory `/data/usr_local/xx/gccobj/i686-pc-linux-gnu/libgcc' make[2]: Leaving directory `/data/usr_local/xx/gccobj' make "DESTDIR=" "RPATH_ENVVAR=LD_LIBRARY_PATH" "TARGET_SUBDIR=i686-pc-linux-gnu" "bindir=/usr/local/bin" "datadir=/usr/local/share" "exec_prefix=/usr/local" "includedir=/usr/local/include" "datarootdir=/usr/local/share" "docdir=/usr/local/share/doc" "infodir=/usr/local/info" "pdfdir=/usr/local/share/doc" "htmldir=/usr/local/share/doc" "libdir=/usr/local/lib" "libexecdir=/usr/local/libexec" "lispdir=" "localstatedir=/usr/local/var" "mandir=/usr/local/man" "oldincludedir=/usr/include" "prefix=/usr/local" "sbindir=/usr/local/sbin" "sharedstatedir=/usr/local/com" "sysconfdir=/usr/local/etc" "tooldir=/usr/local/i686-pc-linux-gnu" "build_tooldir=/usr/local/i686-pc-linux-gnu" "target_alias=i686-pc-linux-gnu" "BISON=bison" "CC_FOR_BUILD=gcc" "CFLAGS_FOR_BUILD=-g -O2" "CXX_FOR_BUILD=g++" "EXPECT=expect" "FLEX=flex" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c" "LEX=flex" "M4=m4" "MAKE=make" "RUNTEST=runtest" "RUNTESTFLAGS=" "SHELL=/bin/sh" "YACC=bison -y" "`echo 'ADAFLAGS=' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "AR_FLAGS=rc" "`echo 'BOOT_ADAFLAGS=' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "BOOT_CFLAGS=-g -O2 -fomit-frame-pointer" "BOOT_LDFLAGS=" "CFLAGS=-g -O2" "CXXFLAGS=-g -O2" "LDFLAGS=" "LIBCFLAGS=-g -O2" "LIBCXXFLAGS=-g -O2 -fno-implicit-templates" "STAGE1_CFLAGS=-g -fkeep-inline-functions" "STAGE1_CHECKING=--enable-checking=types" "STAGE1_LANGUAGES=c,ada" "GNATBIND=gnatbind" "GNATMAKE=gnatmake" "AR_FOR_TARGET=ar" "AS_FOR_TARGET=as" "CC_FOR_TARGET=/home/xx/ul/gccobj/./gcc/xgcc -B/home/xx/ul/gccobj/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include" "CFLAGS_FOR_TARGET=-O2 -g -O2 " "CPPFLAGS_FOR_TARGET=" "CXX_FOR_TARGET=/home/xx/ul/gccobj/./gcc/g++ -B/home/xx/ul/gccobj/./gcc/ -nostdinc++ -L/home/xx/ul/gccobj/i686-pc-linux-gnu/libstdc++-v3/src -L/home/xx/ul/gccobj/i686-pc-linux-gnu/libstdc++-v3/src/.libs -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include" "CXXFLAGS_FOR_TARGET=-g -O2 -D_GNU_SOURCE" "DLLTOOL_FOR_TARGET=dlltool" "GCJ_FOR_TARGET=/home/xx/ul/gccobj/./gcc/gcj -B/home/xx/ul/gccobj/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include" "GFORTRAN_FOR_TARGET=/home/xx/ul/gccobj/./gcc/gfortran -B/home/xx/ul/gccobj/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include" "LD_FOR_TARGET=/usr/lib/gcc/i586-suse-linux/4.1.0/../../../../i586-suse-linux/bin/ld" "LIPO_FOR_TARGET=lipo" "LDFLAGS_FOR_TARGET=" "LIBCFLAGS_FOR_TARGET=-O2 -g -O2 " "LIBCXXFLAGS_FOR_TARGET=-g -O2 -D_GNU_SOURCE -fno-implicit-templates" "NM_FOR_TARGET=nm" "OBJDUMP_FOR_TARGET=objdump" "RANLIB_FOR_TARGET=ranlib" "STRIP_FOR_TARGET=strip" "WINDRES_FOR_TARGET=windres" "WINDMC_FOR_TARGET=windmc" "`echo 'LANGUAGES=' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "LEAN=false" "CONFIG_SHELL=/bin/sh" "MAKEINFO=makeinfo --split-size=500 --split-size=500" compare make[2]: Entering directory `/data/usr_local/xx/gccobj' make[3]: Entering directory `/data/usr_local/xx/gccobj' rm -f stage_current make[3]: Leaving directory `/data/usr_local/xx/gccobj' Comparing stages 2 and 3 warning: ./cc1plus-checksum.o differs warning: ./cc1obj-checksum.o differs warning: ./cc1-checksum.o differs warning: ./cc1objplus-checksum.o differs Bootstrap comparison failure! ./ada/exp_aggr.o differs make[2]: *** [compare] Fehler 1 make[2]: Leaving directory `/data/usr_local/xx/gccobj' make[1]: *** [stage3-bubble] Fehler 2 make[1]: Leaving directory `/data/usr_local/xx/gccobj' make: *** [all] Fehler 2 Greetings Andreas Meier -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
Re: RFC: Rename Non-Autpoiesis maintainers category
On 7/27/07 9:58 AM, Zdenek Dvorak wrote: > Hello, > >> I liked the idea of 'Reviewers' more than any of the other options. >> I would like to go with this patch, unless we find a much better >> option? > > to cancel this category of maintainers completely? An interesting idea, but let's discuss that issue separately. In this thread I'm only interested in changing the name of this category. Not discuss whether the category should exist at all. Since I have not heard any strong opposition to changing the category name to 'Reviewers', I will go ahead with this patch later this week. Index: MAINTAINERS === --- MAINTAINERS (revision 126951) +++ MAINTAINERS (working copy) @@ -231,7 +231,7 @@ maintainers need approval to check in algorithmic changes or changes outside of the parts of the compiler they maintain. - Non-Autopoiesis Maintainers + Reviewers dataflow Daniel Berlin [EMAIL PROTECTED] dataflow Paolo Bonzini [EMAIL PROTECTED] @@ -251,10 +251,9 @@ FortranPaul Thomas [EMAIL PROTECTED] -Note that individuals who maintain parts of the compiler as -non-autopoiesis maintainers need approval changes outside of the parts -of the compiler they maintain and also need approval for their own -patches. +Note that individuals who maintain parts of the compiler as reviewers +need approval for changes outside of the parts of the compiler they +maintain and also need approval for their own patches. Write After Approval(last name alphabetical order)
gcj-4.3.0-9
I noticed while building test gcc43 fink packaging that the gcj-4.3.0 subdirectory in the gcc installation directory has been suddenly changed to gcj-4.3.0-9. Is this intentional or a typo in one of the patches? Jack
Re: Bootstrap error on i686-pc-linux-gnu
"Andreas Meier" <[EMAIL PROTECTED]> writes: > bootstrapping with GCC 4.3. from today is not successfull on my computer > i686-pc-linux-gnu. Does it help to revert this patch? 2007-07-26 Zdenek Dvorak <[EMAIL PROTECTED]> * dominance.c (dom_computed, n_bbs_in_dom_tree): Removed. * function.h (dom_computed, n_bbs_in_dom_tree): New macros. * basic-block.h (struct control_flow_graph): Added x_dom_computed and x_n_bbs_in_dom_tree fields. 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."
Re: "Proceedings of the GCC Developers' Summit" now available
On 7/28/07 5:38 PM, Gerald Pfeifer wrote: > Currently I only see the 2003 and 2004 proceedings at > ftp://gcc.gnu.org/pub/gcc/summit/ Huh. I didn't know those existed. I've always used the links from the wiki. > How about moving everything to one consistent place? Any preferences > on what that place should be? Well, we have all of them attached to the wiki now. I've added links to the individual papers on the the FTP server. If somebody is interested in splitting the other years into individual papers, they could be added as links from the wiki.
Re: Overload resolution compilation error
Dave Korn escreveu:
Thanks, and do drop a note back with a summary of what you find out over
there when you're done; if there's definitely a bug in gcc's understanding of
the resolution rules, obviously we'd like to open a PR and get it fixed.
I think we have finally a consensus at
http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/52087a72bdc5de5a
Since the template parameter of the template function cannot be deduced,
the only valid function for taking its address is the non-template one,
so g++ should accept the code without error nor ambiguity.
During this week I've come along with another possibly related error:
template void foo(A0, A1) {}
void bar()
{
&foo;
}
g++ signals an error, saying:
teste.cpp: In function ‘void bar()’:
teste.cpp:4: error: statement cannot resolve address of overloaded function
I'm trying to get the address of a correctly specialized template
function, but g++ cannot resolve it. And there's no overload situation
there, just void foo(int, char) is being involved. I've not
tested it with other compilers, but this bug is less subtle then the
first one.
delete LIBCALL note after split
Hi, I'm working on GCC 4.1.1 on spu target and get following problem: After splitting an insn with a note REG_LIBCALL, the insn is replaced by some other insns, which don't attach REG_LIBCALL note any more, and the original one is then deleted. While the insn REG_RETVAL still points to the LIBCALL insn, which doesn't exist after the split. After reload it tries to delete the LIBCALL insn referenced by RETVAL, but it has been deleted already. The question is how to avoid deleting the LIBCALL note twice? Is it possible to have RETVAL note point to the new insn split from LIBCALL note? Any idea to solve this problem would be appreciated... Thanks! Sa
Dumping tree with no opt flag
Hi all, I try to develop a tool that get the final CFG of gcc by passing the -fdump-tree-final_cleanup-lineno option and parsing the file dumped by gcc. I noticed that this flag does create an output only if at least the '-O1' (or more) is in the command line. I just would like to know if it would be possible to get the final_cleanup target even though no optimization flag has been given in the command line (for now, I'm just forcing '-O1' to be present if no other optimization flag has been detected in the command line). A final remark, not really significant, I noticed that since gcc 4.2, the name of the dumped tree files have slightly changed. Indeed before, I was used to .t<#id>. where in 4.2 it is more like .<#id>t.. I agree that this change is nothing but is there a reason for changing the position of the 't' character ? Regards -- Emmanuel Fleury There are only 10 types of people in the world. Those who understand binary and those who don't -- Unknown
Re: Dumping tree with no opt flag
On 7/30/07 11:15 AM, Emmanuel Fleury wrote: > I just would like to know if it would be possible to get the > final_cleanup target even though no optimization flag has been given in > the command line (for now, I'm just forcing '-O1' to be present if no > other optimization flag has been detected in the command line). No, because the final_cleanup pass is only executed when optimizing. For -O0, you need to determine what's the last phase executed and request a dump to that phase. Also, future versions of GCC may not have this phase as the final phase, or the dump file name may change, or both. Dump files are merely debugging aids. We make no guarantees as to their content or naming convention. > A final remark, not really significant, I noticed that since gcc 4.2, > the name of the dumped tree files have slightly changed. Indeed before, > I was used to .t<#id>. where in 4.2 it is more like > .<#id>t.. We amalgamated the dumping mechanism for trees and RTL. The 't' denotes a 'tree' dump, 'r' an RTL dump and 'i' an IPA dump.
Re: Dumping tree with no opt flag
Wow, that was quick. :) Diego Novillo wrote: > On 7/30/07 11:15 AM, Emmanuel Fleury wrote: > >> I just would like to know if it would be possible to get the >> final_cleanup target even though no optimization flag has been given in >> the command line (for now, I'm just forcing '-O1' to be present if no >> other optimization flag has been detected in the command line). > > No, because the final_cleanup pass is only executed when optimizing. > For -O0, you need to determine what's the last phase executed and > request a dump to that phase. Ok, this is more or less what I though. I guess that nobody want unoptimized code in his final build, so I think I can go with my hack (adding -O1 when needed). > Also, future versions of GCC may not have > this phase as the final phase, or the dump file name may change, or both. > > Dump files are merely debugging aids. We make no guarantees as to their > content or naming convention. Hum, I'm coding a tool for static and (symbolic) dynamic analysis of code, would you recommend me a way to get the most final CFG you get inside GCC (other than the -fdump-tree-) ??? It would be very helpful for me to get a GENERIC/GIMPLE CFG (with SSA and so on) of the source code so that I can analyze all the languages that go through a gimplifier. :-/ >> A final remark, not really significant, I noticed that since gcc 4.2, >> the name of the dumped tree files have slightly changed. Indeed before, >> I was used to .t<#id>. where in 4.2 it is more like >> .<#id>t.. > > We amalgamated the dumping mechanism for trees and RTL. The 't' denotes > a 'tree' dump, 'r' an RTL dump and 'i' an IPA dump. Damn, you also have inter-procedural analysis dumps ! More I know about GCC, more I love it ! I'll dig this. :) Actually, I know that these dumps are here, as you said, just for debugging purpose but why not making them 'permanent' and kind-of 'standardized' (I mean, not changing it too frequently), so that code analysis tools could plug on GCC ? (I know I'm asking a lot... sorry) Regards -- Emmanuel Fleury The memory management on the PowerPC can be used to frighten small children. -- Linus Torvalds
Re: RFC: Rename Non-Autpoiesis maintainers category
On 7/30/07, Diego Novillo <[EMAIL PROTECTED]> wrote: > On 7/27/07 9:58 AM, Zdenek Dvorak wrote: > > Hello, > > > >> I liked the idea of 'Reviewers' more than any of the other options. > >> I would like to go with this patch, unless we find a much better > >> option? > > > > to cancel this category of maintainers completely? > > An interesting idea, but let's discuss that issue separately. In this > thread I'm only interested in changing the name of this category. Not > discuss whether the category should exist at all. > > Since I have not heard any strong opposition to changing the category > name to 'Reviewers', I will go ahead with this patch later this week. > > > Index: MAINTAINERS > === > --- MAINTAINERS (revision 126951) > +++ MAINTAINERS (working copy) > @@ -231,7 +231,7 @@ > maintainers need approval to check in algorithmic changes or changes > outside of the parts of the compiler they maintain. > > - Non-Autopoiesis Maintainers > + Reviewers > > dataflow Daniel Berlin [EMAIL PROTECTED] > dataflow Paolo Bonzini [EMAIL PROTECTED] > @@ -251,10 +251,9 @@ > FortranPaul Thomas [EMAIL PROTECTED] > > > -Note that individuals who maintain parts of the compiler as > -non-autopoiesis maintainers need approval changes outside of the parts > -of the compiler they maintain and also need approval for their own > -patches. > +Note that individuals who maintain parts of the compiler as reviewers > +need approval for changes outside of the parts of the compiler they > +maintain and also need approval for their own patches. Now that the name has been changed to reviewer, I think the following wording is slightly better: While reviewers can approve the changes in the parts of the compiler they maintain, they still need approval of their own patches from other maintainers or reviewers. > Write After Approval(last name alphabetical > order) -- #pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
Re: Dumping tree with no opt flag
On 7/30/07 11:34 AM, Emmanuel Fleury wrote: > Actually, I know that these dumps are here, as you said, just for > debugging purpose but why not making them 'permanent' and kind-of > 'standardized' (I mean, not changing it too frequently), so that code > analysis tools could plug on GCC ? (I know I'm asking a lot... sorry) Because that's not their goal. The suggested way of doing this kind of analyses is to implement them in GCC directly. This way, instead of parsing the text output, you can access the data structures directly. That will be faster and easier to maintain in the future. We also realize that dealing with GCC's code base is time consuming and even difficult at first. You may be interested in a couple of recent projects to add plug-in functionality to future versions of GCC. You can read about them in the proceedings for this year's GCC Summit (http://gcc.gnu.org/wiki/HomePage?action=AttachFile&do=get&target=GCC2007-Proceedings.pdf)
Re: RFC: Rename Non-Autpoiesis maintainers category
On 7/30/07 12:08 PM, Seongbae Park (¹Ú¼º¹è, ÚÓà÷ÛÆ) wrote: > While reviewers can approve the changes in the parts of the compiler > they maintain, > they still need approval of their own patches from other maintainers > or reviewers. Sounds good to me. Thanks.
Re: delete LIBCALL note after split
Sa Liu <[EMAIL PROTECTED]> writes: > I'm working on GCC 4.1.1 on spu target and get following problem: > > After splitting an insn with a note REG_LIBCALL, the insn is replaced by > some other insns, which don't attach REG_LIBCALL note any more, and the > original one is then deleted. While the insn REG_RETVAL still points to > the LIBCALL insn, which doesn't exist after the split. After reload it > tries to delete the LIBCALL insn referenced by RETVAL, but it has been > deleted already. > > The question is how to avoid deleting the LIBCALL note twice? Is it > possible to have RETVAL note point to the new insn split from LIBCALL > note? Any idea to solve this problem would be appreciated... If the compiler splits an insn with a REG_LIBCALL note, it needs to remove the corresponding REG_RETVAL note, or it needs to relink the insns. This looks like a compiler bug, in that try_split doesn't handle REG_LIBCALL notes at all. It's quite unusual to be able to split a libcall insn, so it's not surprising that this has not been noticed previously. Ian
Re: Bootstrap error on i686-pc-linux-gnu
Hello, this doesn't help. Andreas Andreas Schwab schrieb: "Andreas Meier" <[EMAIL PROTECTED]> writes: bootstrapping with GCC 4.3. from today is not successfull on my computer i686-pc-linux-gnu. Does it help to revert this patch? 2007-07-26 Zdenek Dvorak <[EMAIL PROTECTED]> * dominance.c (dom_computed, n_bbs_in_dom_tree): Removed. * function.h (dom_computed, n_bbs_in_dom_tree): New macros. * basic-block.h (struct control_flow_graph): Added x_dom_computed and x_n_bbs_in_dom_tree fields. Andreas.
Re: Should gcc/DEV-PHASE in gcc 4.2 branch be updated?
H.J. Lu wrote: > According to gcc/ChangeLog, gcc 4.2.1 was released on 2007-07-19. > Shouldn't gcc/DEV-PHASE in gcc 4.2 branch be marked as prerelease? I've now updated BASE-VER and DEV-PHASE. Good catch, thanks! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: AMD64 ABI compatibility
Hi Kai,
so, could you resolve the remaining issues? Or have you kind of
paused the project?
Cheers,
Nicolas
On Jul 12, 2007, at 2:14 , Kai Tietz wrote:
Hi,
I am nearly through :) The remaining macros left to be ported are
REGPARM_MAX and SSE_REGPARM_MAX. The sysv_abi uses 6 regs and 8 sses,
ms_abi uses 4 regs and 4 sse registers. The problem is for example
the use
in i386.md of SSE_REGPARM_MAX without any hint, how to choose the
required
abi. Do you have an idea how this could be done ?
Cheers,
i.A. Kai Tietz
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
--
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 -
www.OneVision.com
Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
Handelsregister: HRA 6744, Amtsgericht Regensburg
Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg
Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer:
Ulrike Döhler, Manuela Kluger
gcc-4.1-20070730 is now available
Snapshot gcc-4.1-20070730 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070730/ 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 127073 You'll find: gcc-4.1-20070730.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20070730.tar.bz2 C front end and core compiler gcc-ada-4.1-20070730.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20070730.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20070730.tar.bz2 C++ front end and runtime gcc-java-4.1-20070730.tar.bz2 Java front end and runtime gcc-objc-4.1-20070730.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20070730.tar.bz2The GCC testsuite Diffs from 4.1-20070723 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.
Semicolons at the end of member function definitions
Hi,
I just stumbled over the patch
2007-03-26 Dirk Mueller <[EMAIL PROTECTED]>
* parser.c (cp_parser_member_declaration): Pedwarn
about stray semicolons after member declarations.
which was approved by Gaby here:
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01456.html
and made it into the trunk here:
http://gcc.gnu.org/ml/gcc-cvs/2007-03/msg00841.html
It makes
struct A
{
void foo() {};
}
a hard error with -pedantic.
The 1998 version of the standard (sorry, I don't have the 2003 version
available) contains in [class.mem]:
member-declaration:
...
function-definition ;opt
...
Therefore, IMHO the patch is wrong and should be reverted.
Or am I missing something?
Regards,
Volker
test message
test message. delete before reading. Ben White
