GCC 4.1 Status Report (2005-12-19)
It's now been a month since we created the 4.1 branch. We've still got 90 open PRs against 4.1, including about 20 P1s. So, we have our work cut out for us, if we're going to get to a release near the nominal scheduled date of January 19th. Let's knock 'em down. My intention is to create the first 4.1 release candidate when (a) we've eliminated the P1s, and (b) it's at least January 19th. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (650) 331-3385 x713
Bootstrap failure on Linux/x86-64 in Ada
Today bootstrap fails for me with: gcc -c -g -I- -I. -Iada -I/cvs/gcc-svn/trunk/gcc/ada /cvs/gcc-svn/trunk/gcc/ada/ada.ads -o ada/ada.o ada.ads:16:01: language defined units may not be recompiled make[3]: *** [ada/ada.o] Error 1 This worked 24 hours ago - with the same bootstrap compiler. I'm trying to hunt down the change now, Andreas -- Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgpogpU0hSmxd.pgp Description: PGP signature
Re: Bootstrap failure on Linux/x86-64 in Ada
> gcc -c -g -I- -I. -Iada -I/cvs/gcc-svn/trunk/gcc/ada > /cvs/gcc-svn/trunk/gcc/ada/ada.ads -o ada/ada.o > ada.ads:16:01: language defined units may not be recompiled > make[3]: *** [ada/ada.o] Error 1 > > This worked 24 hours ago - with the same bootstrap compiler. > > I'm trying to hunt down the change now, This must be a Makefile/configure change, since -gnatpg must be passed to each Ada file compiled as part of ADAFLAGS (see ada/Makefile.in) Arno
A question about the global variables initialization.
Hi, I guess it's about the gcc version. Gcc 3.4.4 does put the zero'd variables into bss section. But I'd like to know if the older one does it too. Say 2.95.2 19991024 (release)? Thanks again. Eric.
Re: Bootstrap failure on Linux/x86-64 in Ada
Hi Andreas, this should be related to the fixes to AIX toplevel bootstrap. My apologies if it is the cause. Can you try adding these lines to the toplevel Makefile.tpl? ADAFLAGS = -W -Wall -gnatpg -gnata ADAFLAGS_FOR_TARGET = -W -Wall -gnatpg -gnata and changing = to += in config/mt-ppc-aix? Arnaud, it seems strange that "required" flags like -gnatpg are on ADAFLAGS rather than the makefile rules. -c is not in CFLAGS, for example. Is it possible that you don't want -gnatpg in some cases? Paolo
Re: Bootstrap failure on Linux/x86-64 in Ada
> ADAFLAGS = -W -Wall -gnatpg -gnata > ADAFLAGS_FOR_TARGET = -W -Wall -gnatpg -gnata > > and changing = to += in config/mt-ppc-aix? > > Arnaud, it seems strange that "required" flags like -gnatpg are on > ADAFLAGS rather than the makefile rules. -c is not in CFLAGS, for > example. Is it possible that you don't want -gnatpg in some cases? Yes, -gnatp is certainly not required in all cases (e.g. for debugging). Of course that does not change the fact that we want a reasonable default value for ADAFLAGS, that is *not* overriden by default by the top-level Makefiles, only by users and build scripts. And I'd rather keep this default in ada/Makefile.in rather than moving it to the top level. Arno
Re: Add revision number to gcc version?
Okay, I see. Yes, there really ought to be an easy way to provide enough information to reproduce the tree, and $Revision$ isn't it.
RFC: combine simplification change: 2-for-2-with-lesser-cost
I'd like for combine to perform the following simplification:
(insn 14 13 16 0 /home/hp/combined/combined/gcc/config/cris/arit.c:228
(parallel [
(set (reg/v:SI 27 [ b.67 ])
(abs:SI (reg/v:SI 47 [ b ])))
(clobber (reg:CC 19 dccr))
]) 158 {abssi2} (insn_list:REG_DEP_TRUE 7 (nil))
(expr_list:REG_UNUSED (reg:CC 19 dccr)
(nil)))
(jump_insn 17 16 19 0 /home/hp/combined/combined/gcc/config/cris/arit.c:178
(parallel [
(set (pc)
(if_then_else (ge (abs:SI (reg/v:SI 47 [ b ]))
(const_int 0 [0x0]))
(label_ref 24)
(pc)))
(clobber (reg:CC 19 dccr))
]) 1 {cris_cbranchsi4} (insn_list:REG_DEP_TRUE 14 (nil))
(expr_list:REG_UNUSED (reg:CC 19 dccr)
(expr_list:REG_BR_PROB (const_int 7900 [0x1edc])
(nil
into:
(insn 14 13 16 0 /home/hp/combined/combined/gcc/config/cris/arit.c:228
(parallel [
(set (reg/v:SI 27 [ b.67 ])
(abs:SI (reg/v:SI 47 [ b ])))
(clobber (reg:CC 19 dccr))
]) 158 {abssi2} (insn_list:REG_DEP_TRUE 7 (nil))
(expr_list:REG_UNUSED (reg:CC 19 dccr)
(nil)))
(jump_insn 17 16 19 0 /home/hp/combined/combined/gcc/config/cris/arit.c:178
(set (pc) (label_ref 24)) 1 {jump}
(insn_list:REG_DEP_TRUE 14 (nil)))
(beware, edited RTL.) However, it doesn't, as trading two for
two-with-a-lesser-cost is currently not done; comments mention
fear of recursion or oscillation. That shouldn't happen if the
rtx cost is considered and is nearly sane.
If you think this optimization is misplaced, I see no pass
*after* combine, that is expected to this perform
simplification. Maybe the SSA optimizations before this pass
should cover it, but they don't, at least not with 108225
compiling libgcc/_divsi3.o for cris-axis-linux-gnu (there's an
abs in a caller, with a < 0 test in an inlined function). This
function is the top pessimized for my non-cc0 CRIS wip. Anyway,
arguments like "no, do it in SSA" miss the point and will be
ignored; things have different shape at the RTL level and may
not be apparent in SSA. (Yes, SSA might have a flow exposed
here, if so, it should probably be fixed *too*.)
Note also that the cc0-equivalent of the above is simplified by
combine:
(insn 14 13 16 0 /home/hp/combined/combined/gcc/config/cris/arit.c:228 (set
(reg/v:SI 27 [ b.67 ])
(abs:SI (reg/v:SI 47 [ b ]))) 148 {abssi2} (insn_list:REG_DEP_TRUE 7
(nil))
(nil))
(insn 17 16 18 0 /home/hp/combined/combined/gcc/config/cris/arit.c:178 (set
(cc0)
(reg/v:SI 27 [ b.67 ])) 1 {tstsi} (insn_list:REG_DEP_TRUE 14 (nil))
(nil))
(jump_insn 18 17 20 0 /home/hp/combined/combined/gcc/config/cris/arit.c:178
(set (pc)
(if_then_else (ge (abs:SI (reg/v:SI 47 [ b ]))
(const_int 0 [0x0]))
(label_ref 26)
(pc))) 162 {bge} (nil)
(expr_list:REG_BR_PROB (const_int 7900 [0x1edc])
(nil)))
is simplified to:
(insn 14 13 16 0 /home/hp/combined/combined/gcc/config/cris/arit.c:228 (set
(reg/v:SI 27 [ b.67 ])
(abs:SI (reg/v:SI 47 [ b ]))) 148 {abssi2} (insn_list:REG_DEP_TRUE 7
(nil))
(nil))
(jump_insn 18 17 20 0 /home/hp/combined/combined/gcc/config/cris/arit.c:178
(set (pc)
(label_ref 26)) 162 {bge} (nil)
(expr_list:REG_BR_PROB (const_int 7900 [0x1edc])
(nil)))
(right after substitutions) and combine allows this, being a
three-for-two (with-lesser-cost) transformation.
The actual code should be simple; I just want to check that
there's consensus on the actual change before doing it.
Thoughts?
brgds, H-P
Re: Bootstrap failure on Linux/x86-64 in Ada
Bonzini <[EMAIL PROTECTED]> writes: > Hi Andreas, this should be related to the fixes to AIX toplevel > bootstrap. My apologies if it is the cause. > > Can you try adding these lines to the toplevel Makefile.tpl? > > ADAFLAGS = -W -Wall -gnatpg -gnata > ADAFLAGS_FOR_TARGET = -W -Wall -gnatpg -gnata > > and changing = to += in config/mt-ppc-aix? I changed Makefile.in as well, below is the diff. This seems to fix that issue. But now it stops with my parallel bootstrap at: ln: creating symbolic link `x86_64-suse-linux-gnu/stage1-x86_64-suse-linux-gnu' to `stage1-x86_64-suse-linux-gnu': File exists make[3]: *** [stage1-start] Error 1 make[3]: Leaving directory `/builds/gcc/misc' make[2]: *** Waiting for unfinished jobs make[2]: *** [configure-build-fixincludes] Error 2 make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/builds/gcc/misc' make: *** [bootstrap] Error 2 Andreas Index: Makefile.in === --- Makefile.in (revision 108851) +++ Makefile.in (working copy) @@ -338,6 +338,8 @@ LIBCFLAGS_FOR_TARGET = $(CFLAGS_FOR_TARG LIBCXXFLAGS_FOR_TARGET = $(CXXFLAGS_FOR_TARGET) -fno-implicit-templates LDFLAGS_FOR_TARGET = PICFLAG_FOR_TARGET = +ADAFLAGS = -W -Wall -gnatpg -gnata +ADAFLAGS_FOR_TARGET = -W -Wall -gnatpg -gnata # # Miscellaneous targets and flag lists Index: Makefile.tpl === --- Makefile.tpl(revision 108851) +++ Makefile.tpl(working copy) @@ -258,6 +258,10 @@ BOOT_CFLAGS= -g -O2 BOOT_ADAFLAGS= BOOT_LDFLAGS= +ADAFLAGS = -W -Wall -gnatpg -gnata +ADAFLAGS_FOR_TARGET = -W -Wall -gnatpg -gnata + + BISON = @BISON@ YACC = @YACC@ FLEX = @FLEX@ Index: config/mt-ppc-aix === --- config/mt-ppc-aix (revision 108851) +++ config/mt-ppc-aix (working copy) @@ -3,4 +3,4 @@ # that the library does not use nearly the entire TOC of applications # until gnatlib is built as a shared library on AIX. Compiling the # compiler with -mminimal-toc does not cause any harm. -ADAFLAGS_FOR_TARGET = -mminimal-toc +ADAFLAGS_FOR_TARGET += -mminimal-toc -- Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgpWYQT5QRqmp.pgp Description: PGP signature
Re: RFC: combine simplification change: 2-for-2-with-lesser-cost
On Dec 20, 2005 10:50 AM, Hans-Peter Nilsson <[EMAIL PROTECTED]> wrote: > The actual code should be simple; I just want to check that > there's consensus on the actual change before doing it. > > Thoughts? You really have to wonder if cleaning up this jump is a job combine should be doing. I would have thought we'd clean this up _before_ combine (and no, I don't mean the tree optimizers, but e.g. CSE, or jump bypassing (even though the latter doesn't work for critical edges)). Are there other cases, you think, where we fail to combine 2 insns into 2 cheaper ones?? Gr. Steven
Why is this C++ code incorrect?
Hi,
Compiling the following code with g++ will report error:`static void
A::operator delete(void*)' is protected. It's correct If B is derived from
A without "virtual". Why does the "new B" expression need to check the
delete operator's accessibility when B is virutally derived from A?
class A
{
protected:
static void operator delete( void * ) {}
};
class B : public virtual A {};
void f()
{
new B;
}
Re: RFC: combine simplification change: 2-for-2-with-lesser-cost
> Date: Tue, 20 Dec 2005 11:13:06 +0100 (CET) > From: Steven Bosscher <[EMAIL PROTECTED]> > You really have to wonder if cleaning up this jump is a job combine > should be doing. I want it done there *only* because that's what it does for the similar but even more complex cc0 code and because combine does multi-insn simplifications in general. I suggest not being hung up on it being a jump that's simplified. Anyhow, I'd like to disconnect the un-cc0-ification of the CRIS port while retaining performance, from overhaul of GCC passes as much as possible, please, however TRT the overhaul may be. > I would have thought we'd clean this up _before_ > combine Me too... Might be a simple oversight somewhere. I'll have a closer look; seems at a glance that gcse thinks it does this. > (and no, I don't mean the tree optimizers, but e.g. CSE, or jump > bypassing (even though the latter doesn't work for critical > edges)). FWIW, jump bypassing doesn't do anything transformationwise but calling the usual cfgcleanup things. CFG apparently doesn't perform the necessary kind of simplifications. See rest_of_handle_jump2. > Are > there other cases, you think, where we fail to combine 2 insns into 2 > cheaper ones?? I don't know, but as combine seems to be the only pass performing inter-insn simplifications, I'd guess so. brgds, H-P
Re: Bootstrap failure on Linux/x86-64 in Ada
Yes, -gnatp is certainly not required in all cases (e.g. for debugging). Sorry if I don't understand. How is a debugging option related to the error Andreas reported, which is: gcc -c -g -I- -I. -Iada -I/cvs/gcc-svn/trunk/gcc/ada /cvs/gcc-svn/trunk/gcc/ada/ada.ads -o ada/ada.o ada.ads:16:01: language defined units may not be recompiled Paolo
Re: Bootstrap failure on Linux/x86-64 in Ada
> Sorry if I don't understand. How is a debugging option related to the > error Andreas reported, which is: No relation, but that was not the question you were asking ;-) > >gcc -c -g -I- -I. -Iada -I/cvs/gcc-svn/trunk/gcc/ada > >/cvs/gcc-svn/trunk/gcc/ada/ada.ads -o ada/ada.o > >ada.ads:16:01: language defined units may not be recompiled Here you are missing "-gnatpg gnata" in your line, although that could be "-gnatg" or "-gnatpgn" Arno
Re: Bootstrap failure on Linux/x86-64 in Ada
gcc -c -g -I- -I. -Iada -I/cvs/gcc-svn/trunk/gcc/ada /cvs/gcc-svn/trunk/gcc/ada/ada.ads -o ada/ada.o ada.ads:16:01: language defined units may not be recompiled Here you are missing "-gnatpg gnata" in your line, although that could be "-gnatg" or "-gnatpgn" So you need a -gnat option, or compilation fails? Paolo
Re: Bootstrap failure on Linux/x86-64 in Ada
> So you need a -gnat option, or compilation fails? You need at the very least -gnatg, although -gnatpg is highly recommended, and -gnata is highly desirable for development. Arno
Re: Bootstrap failure on Linux/x86-64 in Ada
Arnaud Charlet wrote: So you need a -gnat option, or compilation fails? You need at the very least -gnatg, although -gnatpg is highly recommended, and -gnata is highly desirable for development Ok. For now I'd stick with the patch I proposed to Andreas, but please tell me if these assertions are right or wrong: -gnatpg is equivalent to -gnatg -gnatp. -gnatg is necessary for compilation, and it could be moved out of ADAFLAGS into the rule. ADAFLAGS would then mention only -gnatp -gnata. Paolo
Re: Bootstrap failure on Linux/x86-64 in Ada
> Ok. For now I'd stick with the patch I proposed to Andreas, but please > tell me if these assertions are right or wrong: Note that this patch is really kludgy, since it duplicates the default value of ADAFLAGS in several (at least 3) places, which means that if/when we decide to change this default setting, that will be a pain. Could you please find a more elegant solution ? Thanks in advance. > -gnatpg is equivalent to -gnatg -gnatp. Yes. > -gnatg is necessary for compilation, and it could be moved out of > ADAFLAGS into the rule. ADAFLAGS would then mention only -gnatp -gnata. Yes, although that would be of little value, and given that many existing scripts and makefiles are depending on existing settings, this change would only bring confusion and would not solve anything. Actually it would remove a useful check: here, it was very easy to find that the ADAFLAGS were completely removed due to an error in the Makefile changes. If you move -gnatg to the Ada compilation rules, it means that the next time someone will break ADAFLAGS, if will be harder to detect. So please don't move it, thanks. Arno
Re: Bootstrap failure on Linux/x86-64 in Ada
> Could you please find a more elegant solution ? Thanks in advance. See e.g. setting of EXTRA_GCC_FLAGS in Makefile.tpl for a way to handle that: EXTRA_GCC_FLAGS = \ [...] "`echo 'LANGUAGES=$(LANGUAGES)' | sed -e s'/[^=][^=]*=$$/XFOO=/'`" \ Arno
Re: Bootstrap failure on Linux/x86-64 in Ada
Arnaud Charlet wrote: Could you please find a more elegant solution ? Thanks in advance. See e.g. setting of EXTRA_GCC_FLAGS in Makefile.tpl for a way to handle that: EXTRA_GCC_FLAGS = \ [...] "`echo 'LANGUAGES=$(LANGUAGES)' | sed -e s'/[^=][^=]*=$$/XFOO=/'`" \ Unfortunately, there is no really easy and elegant solution. This one, for example, would really oblige targets that want to specify Ada-only flags to also include -Wall -W -gnatpg -gnata. So you would not save a place where to change the defaults. Putting it into gcc/ada only, would not only prevent targets from specifying Ada-only flags. It would also prevent people from building a compiler with strange flags by typing for example "make ADAFLAGS="-O2 -ftree-sra -Wall -W -gnatpg -gnata". My patch will also fix that (once the compiler builds again of course). I think that the real kludge is that you cannot run "make" with ADAFLAGS set to an empty value. It will catch mistakes, granted, but the real problem is that Ada does too many things specially (and I'm not blaming the Ada people -- it's to same extent true that you don't want to fix what ain't really broken). But as we proceed to remove these special treatments, the need for cleanups (and the chance of mistakes) will get lower and lower. Paolo
Re: Bootstrap failure on Linux/x86-64 in Ada
ln: creating symbolic link `x86_64-suse-linux-gnu/stage1-x86_64-suse-linux-gnu' to `stage1-x86_64-suse-linux-gnu': File exists make[3]: *** [stage1-start] Error 1 make[3]: Leaving directory `/builds/gcc/misc' make[2]: *** Waiting for unfinished jobs make[2]: *** [configure-build-fixincludes] Error 2 make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/builds/gcc/misc' make: *** [bootstrap] Error 2 I believe I have a fix for this race condition as part of unrelated changes (which I have to test a bit more). Paolo
An odd behavior of dynamic_cast
Hi all,
This is my first post. :-)
# I could not find a mailing list dedicated to c++ at
gcc.gnu.org.
# So I post this mailing list.
Recently, I found an odd behavior about dynamic_cast
across shared libraries.
This is my box:
linux kernel-2.4.21
gcc-3.4.3
(Check out my test_case.tar.bz2 for complete source
codes.)
I defined these classes and functions in libbase.so:
struct Base; // <- polymorphic
struct Tag; // <- non-polymorphic
struct VirtualTag; // <- polymorphic
Tag* getTag(Base* base)
{
return dynamic_cast(base);
}
VirtualTag* getVirtualTag(Base*)
{
return dynamic_cast(base);
}
I also defined these derived classes in
libderived.so:
struct Derived0 : Base, Tag;
struct Derived1 : Base, VirtualTag;
Then I tested getTag() and getVirtualTag()
in two ways:
test0: linked to libderived.so (and libbase.so)
at build time.
test1: dynamically loads libbase.so and
libderived.so
by using dlopen() at runtime.
These two test cases basically does the same thing:
1. create Derived(0|1) instance.
2. do dynamic_cast by using get[Virtual]Tag()
function.
In test0, both getTag() and getVirtual() are ok
(returns non-NULL value).
But in test1, getTag() returns NULL
while getVirtualTag() returns non-NULL.
I expected that I got the same results
in both cases...
In test1, typeid(Tag) is not unique.
Could anyone tell which behavior is right or bug?
Thanks.
--
STOP HIV/AIDS.
Yahoo! JAPAN Redribbon Campaign 2005
http://pr.mail.yahoo.co.jp/redribbon/
test_cast.tar.bz2
Description: test_cast.tar.bz2
Re: Bootstrap failure on Linux/x86-64 in Ada
> >EXTRA_GCC_FLAGS = \ > >[...] > > "`echo 'LANGUAGES=$(LANGUAGES)' | sed -e s'/[^=][^=]*=$$/XFOO=/'`" \ > > > > > Unfortunately, there is no really easy and elegant solution. This one, > for example, would really oblige targets that want to specify Ada-only > flags to also include -Wall -W -gnatpg -gnata. Why is that so ? I do not understand, could you clarify ? And for instance give an example of what you have in mind ? Arno
Re: Bootstrap failure on Linux/x86-64 in Ada
Arnaud Charlet wrote: EXTRA_GCC_FLAGS = \ [...] "`echo 'LANGUAGES=$(LANGUAGES)' | sed -e s'/[^=][^=]*=$$/XFOO=/'`" \ Unfortunately, there is no really easy and elegant solution. This one, for example, would really oblige targets that want to specify Ada-only flags to also include -Wall -W -gnatpg -gnata. Why is that so ? I do not understand, could you clarify ? And for instance give an example of what you have in mind ? Because the line above, as you know, does not pass LANGUAGES if it is not set. But if it is set, the value is reset completely, rather than combined with the value in the subdirectory. So, the AIX makefile fragments config/mh-ppc-aix and config/mt-ppc-aix could not just do ADAFLAGS += -mminimal-toc ADAFLAGS_FOR_TARGET += -mminimal-toc but would have to say ADAFLAGS = -mminimal-toc -Wall -W -gnatpg -gnata ADAFLAGS_FOR_TARGET = -mminimal-toc -Wall -W -gnatpg -gnata Paolo
Re: Bootstrap failure on Linux/x86-64 in Ada
> Because the line above, as you know, does not pass LANGUAGES if it is > not set. But if it is set, the value is reset completely, rather than > combined with the value in the subdirectory. Right, as intended. > So, the AIX makefile fragments config/mh-ppc-aix and config/mt-ppc-aix > could not just do > > ADAFLAGS += -mminimal-toc > ADAFLAGS_FOR_TARGET += -mminimal-toc But this approach is wrong to start with, so you cannot use this argument based on a wrong approach to start with, otherwise you will end up patching and covering work arounds over work arounds. The Ada Makefile already takes into account $(X_ADAFLAGS) and $(T_ADAFLAGS) It sounds like T_ADAFLAGS would probably be appropriate to solve the AIX specific issue. Although I would need to see the entire issue we're trying to solve under AIX, since it's not clear at all to me that forcing -mminimal-toc systematically is a good idea to start with. Could you point to a detailed discussion on the AIX issue ? Arno
Re: Bootstrap failure on Linux/x86-64 in Ada
>>>gcc -c -g -I- -I. -Iada -I/cvs/gcc-svn/trunk/gcc/ada >>>/cvs/gcc-svn/trunk/gcc/ada/ada.ads -o ada/ada.o >>>ada.ads:16:01: language defined units may not be recompiled So you need a -gnat option, or compilation fails? Yes, because, as it says, the Ada standard does not permit recompilation of language-defined units. Obviously, we have to compile them as part of building the compiler and library, so -gnatg says to ignore that particular validity check.
Re: Bootstrap failure on Linux/x86-64 in Ada
So, the AIX makefile fragments config/mh-ppc-aix and config/mt-ppc-aix could not just do ADAFLAGS += -mminimal-toc ADAFLAGS_FOR_TARGET += -mminimal-toc The Ada Makefile already takes into account $(X_ADAFLAGS) and $(T_ADAFLAGS) Yes, but it provides no way to set them globally. That means, if something is written in Ada, it has to be in gcc/ada, and if you want to change some parameter you more or less have to invoke `make' from the gcc/ada directory. I think this is too difficult to clean up, so I am quite inclined to revert this part of the patch. Paolo
Re: Bootstrap failure on Linux/x86-64 in Ada
> Yes, but it provides no way to set them globally. That means, if > something is written in Ada, it has to be in gcc/ada, and if you want to > change some parameter you more or less have to invoke `make' from the > gcc/ada directory. Well, I'm afraid you've lost me... What is T_ADAFLAGS used for if as you say there is no way to set it globally ? > I think this is too difficult to clean up, so I am quite inclined to > revert this part of the patch. Which part exactly are you referring to ? Would there still be a way to specify ADAFLAGS and BOOT_ADAFLAGS if you revert your change (that's an important capability that has been broken back and forth in the past) for instance ? Arno
Re: Why is this C++ code incorrect?
Jiutao Nie wrote: Hi, Compiling the following code with g++ will report error:`static void A::operator delete(void*)' is protected. It's correct If B is derived from A without "virtual". Why does the "new B" expression need to check the delete operator's accessibility when B is virutally derived from A? 5.3.4 paras 8, 17 and 18 say so. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Bootstrap failure on Linux/x86-64 in Ada
What is T_ADAFLAGS used for if as you say there is no way to set it globally ? You can set it for gcc/ada only, not for the benefit of the entire tree. It makes it hard, for example, to make libada really its own toplevel directory, because T_ADAFLAGS is set within the gcc target fragments. I think this is too difficult to clean up, so I am quite inclined to revert this part of the patch. Which part exactly are you referring to ? The part to pass ADAFLAGS down from the toplevel. Would there still be a way to specify ADAFLAGS and BOOT_ADAFLAGS if you revert your change (that's an important capability that has been broken back and forth in the past) for instance ? No, that would probably require a more complex patch, probably using the same trick as in EXTRA_GCC_FLAGS. I don't consider such a patch obvious, especially because I don't know myself how to write it, so I would ask the build maintainers to come in and say what they think about the subject of this discussion. Personally, I think that the way ADAFLAGS is specified is too error-prone. I understood that Kenner said, -gnatg is necessary on the language components, but is actually removing a legitimate warning for other files such as the compiler. I believe that -gnatg should be set manually on the files that need it (within gcc/ada/Makefile.in). Similarly, -gnatp -gnata should be in some way linked to gcc's --enable-checking mechanism. Since I don't understand really if what I'm saying makes sense, I think the best solution is to revert because it is also affecting people that use --disable-bootstrap (whom I cannot blame at all). Paolo
Re: Bootstrap failure on Linux/x86-64 in Ada
> Arnaud Charlet writes: Arnaud> Although I would need to see the entire issue we're trying to solve under Arnaud> AIX, since it's not clear at all to me that forcing -mminimal-toc Arnaud> systematically is a good idea to start with. Could you point to a detailed Arnaud> discussion on the AIX issue ? AIX has a limit on the size of the TOC (similar to ELF GOT). The TOC provides global PIC addressibility and is used for global variables, static variables, and constants. The data sections patch will improve this situation by creating a local pool for constants and static variables, as IBM XLC has done from its initial implementation. -mminimal-toc instructs GCC to generate one TOC entry per function and use a side table for all addressibility in the function, reducing the size of the TOC to the number of functions in the executable or shared object, instead of the number of variables and constants. One can intermix object files compiled with and without the option. One also can fixup the TOC overflow in the linker, which is reasonably efficient for a small number of extra entries, but inefficient for a large overflow. When Ada builds on AIX, libada contains a very large number of TOC entries. Even the smallest, simplest executable overflows because the entire TOC is consumed by libada. Using this option when building libada compacts the library so that applications encounter TOC overflow less often. When the data section patch is merged into GCC, this may not be necessary, so maybe we should just declare GNU Ada unusable on AIX until that patch is committed. David
Re: Bootstrap failure on Linux/x86-64 in Ada
When the data section patch is merged into GCC, this may not be necessary, so maybe we should just declare GNU Ada unusable on AIX until that patch is committed. Didn't you mention it is already broken for other reasons? Paolo
Re: Bootstrap failure on Linux/x86-64 in Ada
> You can set it for gcc/ada only, not for the benefit of the entire > tree. It makes it hard, for example, to make libada really its own > toplevel directory, because T_ADAFLAGS is set within the gcc target > fragments. Well, so you're saying there will be, in the future, a potential problem with T_ADAFLAGS. Fine, but this is not a problem today. I do not think it is a good idea to try to fix everything at the same time. > Personally, I think that the way ADAFLAGS is specified is too > error-prone. I understood that Kenner said, -gnatg is necessary on the > language components, but is actually removing a legitimate warning for > other files such as the compiler. No, that's a misunderstanding. -gnatg is necessary for language components, and also required for all GNAT files, for various reasons. > I believe that -gnatg should be set > manually on the files that need it (within gcc/ada/Makefile.in). Well possibly but as I said, that wouldn't fix any particular problem. > Similarly, -gnatp -gnata should be in some way linked to gcc's > --enable-checking mechanism. That's confused (as you had guessed). -gnata could indeed be linked to --enable-checking, but -gnatp not. -gnatp is also highly recommended by default (and certainly when --disable-checking), and should only be removed in very special circumstances, which probably do not justify a configure option (and in any case, configure option are a pain, since they are too static), so using ADAFLAGS or BOOT_ADAFLAGS on the command line is indeed the good mechanism in terms of frequency of needs and flexibility. > Since I don't understand really if what I'm saying makes sense, I think > the best solution is to revert because it is also affecting people that > use --disable-bootstrap (whom I cannot blame at all). That would certainly be better than the current situation, although if you look at Makefile.tpl and EXTRA_GCC_FLAGS, you'll see that we already apply this treatment to BOOT_ADAFLAGS and this worked as expected, so why treating ADAFLAGS (using e.g. for cross compilers) differently ? Arno
Re: Bootstrap failure on Linux/x86-64 in Ada
Since I don't understand really if what I'm saying makes sense, I think the best solution is to revert because it is also affecting people that use --disable-bootstrap (whom I cannot blame at all). That would certainly be better than the current situation, although if you look at Makefile.tpl and EXTRA_GCC_FLAGS, you'll see that we already apply this treatment to BOOT_ADAFLAGS and this worked as expected, so why treating ADAFLAGS (using e.g. for cross compilers) differently ? I'm not saying I don't like the idea, but I'm not prepared to do it and I surely don't want to "slip it under the door" as obvious. Paolo
Re: Bootstrap failure on Linux/x86-64 in Ada
[thanks for the general info on what minimal-toc is about, I should have mentioned I am familiar with the general issue and with this option] > When Ada builds on AIX, libada contains a very large number of TOC > entries. Even the smallest, simplest executable overflows because the > entire TOC is consumed by libada. That on ther other hand I would like to better understand, since that's clearly news to me. Do you have more details ? A PR reference maybe ? > When the data section patch is merged into GCC, this may not be > necessary, so maybe we should just declare GNU Ada unusable on AIX until > that patch is committed. Or less drastically, document in install.texi that GNATLIBCFLAGS needs to include -mminimal-toc on AIX. Arno
Re: Bootstrap failure on Linux/x86-64 in Ada
> I'm not saying I don't like the idea, but I'm not prepared to do it and > I surely don't want to "slip it under the door" as obvious. Well if that's your criteria then sure, your previous change was also not in the obvious category ;-) Arno
Re: Bootstrap failure on Linux/x86-64 in Ada
Well if that's your criteria then sure, your previous change was also not
in the obvious category ;-)
Well, the `obvious' part of it was
flags_to_pass = { flag = ADAFLAGS };
flags_to_pass = { flag = BOOT_ADAFLAGS };
flags_to_pass = { flag = BOOT_LDFLAGS };
which I admit should not have committed without building Ada. :-(
Paolo
Re: Bootstrap failure on Linux/x86-64 in Ada
Personally, I think that the way ADAFLAGS is specified is too error-prone. I understood that Kenner said, -gnatg is necessary on the language components, but is actually removing a legitimate warning for other files such as the compiler. No, because -gnatg also imposes strict style checking and conformance with coding conventions. I was saying why it was *required* to be specified, not *why* we specify it.
re: An odd behavior of dynamic_cast
[EMAIL PROTECTED] wrote: > [ Why doesn't dynamic_cast work when I dlopen a shared library? ] I think the right place for this question might have been gcc-help (http://gcc.gnu.org/ml/gcc-help/). Nevertheless, I think http://gcc.gnu.org/faq.html#dso should answer your question. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: Bootstrap failure on Linux/x86-64 in Ada
On Tue, Dec 20, 2005 at 03:52:23PM +0100, Paolo Bonzini wrote: > So, the AIX makefile fragments config/mh-ppc-aix and config/mt-ppc-aix > could not just do > > ADAFLAGS += -mminimal-toc > ADAFLAGS_FOR_TARGET += -mminimal-toc We can't use += in the top level, can we? -- Daniel Jacobowitz CodeSourcery, LLC
Re: Why is this C++ code incorrect?
On 12/20/05, Nathan Sidwell <[EMAIL PROTECTED]> wrote: > > Compiling the following code with g++ will report error:`static void > > A::operator delete(void*)' is protected. It's correct If B is derived from > > A without "virtual". Why does the "new B" expression need to check the > > delete operator's accessibility when B is virutally derived from A? > > 5.3.4 paras 8, 17 and 18 say so. I don't see how the below is affected by the use of a virtual base class, rather than an ordinary base class. 8 A new-expression obtains storage for the object by calling an allocation function (3.7.3.1). If the new- expression terminates by throwing an exception, it may release storage by calling a deallocation function (3.7.3.2). If the allocated type is a non-array type, the allocation function's name is operator new and the deallocation function's name is operator delete. If the allocated type is an array type, the alloca- tion function's name is operator new[] and the deallocation function's name is operator delete[]. [Note: an implementation shall provide default definitions for the global alloca- tion functions (3.7.3, 18.4.1.1, 18.4.1.2). A C++ program can provide alternative definitions of these func- tions (17.4.3.4) and/or class-specific versions (12.5). ] ... 17 If any part of the object initialization described above71) terminates by throwing an exception and a suitable deallocation function can be found, the deallocation function is called to free the memory in which the object was being constructed, after which the exception continues to propagate in the context of the new- expression. If no unambiguous matching deallocation function can be found, propagating the exception does not cause the object's memory to be freed. [Note: This is appropriate when the called allocation func- tion does not allocate memory; otherwise, it is likely to result in a memory leak. ] 18 If the new-expression begins with a unary :: operator, the deallocation function's name is looked up in the global scope. Otherwise, if the allocated type is a class type T or an array thereof, the deallocation function's name is looked up in the scope of T. If this lookup fails to find the name, or if the allocated type is not a class type or array thereof, the deallocation function's name is looked up in the global scope.
RE: Why is this C++ code incorrect?
The 5.3.4 para 16 is also important. 16 If the newexpression creates an object or an array of objects of class type, access and ambiguity control are done for the allocation function, the deallocation function (12.5), and the constructor (12.1). If the new expression creates an array of objects of class type, access and ambiguity control are done for the destructor (12.4). According to it, when calling new operator for a class, access and ambiguity control should also be done for the delete operator. This is because when the class's constructor failed by throwing an exception, the delete must be called to free the memory. I dumped the generic tree generated by g++ and found that when using a original base class, there is no try-catch generated for the trivial constructor of B, so no delete calling are generated, while for virtual base class, the implicit constructor of B is not trivial, so the try-catch and delete calling are generated and the access control is also done for it. It seems that the essential problem is whether the constructor is trivial rather than whether it has a virtual base class. However, I don't know whether the passing of compilation for original base class violates the standard. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jim Blandy Sent: Wednesday, December 21, 2005 1:25 AM To: Nathan Sidwell Cc: Jiutao Nie; gcc@gcc.gnu.org Subject: Re: Why is this C++ code incorrect? On 12/20/05, Nathan Sidwell <[EMAIL PROTECTED]> wrote: > > Compiling the following code with g++ will report error:`static > > void A::operator delete(void*)' is protected. It's correct If B is > > derived from A without "virtual". Why does the "new B" expression > > need to check the delete operator's accessibility when B is virutally derived from A? > > 5.3.4 paras 8, 17 and 18 say so. I don't see how the below is affected by the use of a virtual base class, rather than an ordinary base class. 8 A new-expression obtains storage for the object by calling an allocation function (3.7.3.1). If the new- expression terminates by throwing an exception, it may release storage by calling a deallocation function (3.7.3.2). If the allocated type is a non-array type, the allocation function's name is operator new and the deallocation function's name is operator delete. If the allocated type is an array type, the alloca- tion function's name is operator new[] and the deallocation function's name is operator delete[]. [Note: an implementation shall provide default definitions for the global alloca- tion functions (3.7.3, 18.4.1.1, 18.4.1.2). A C++ program can provide alternative definitions of these func- tions (17.4.3.4) and/or class-specific versions (12.5). ] ... 17 If any part of the object initialization described above71) terminates by throwing an exception and a suitable deallocation function can be found, the deallocation function is called to free the memory in which the object was being constructed, after which the exception continues to propagate in the context of the new- expression. If no unambiguous matching deallocation function can be found, propagating the exception does not cause the object's memory to be freed. [Note: This is appropriate when the called allocation func- tion does not allocate memory; otherwise, it is likely to result in a memory leak. ] 18 If the new-expression begins with a unary :: operator, the deallocation function's name is looked up in the global scope. Otherwise, if the allocated type is a class type T or an array thereof, the deallocation function's name is looked up in the scope of T. If this lookup fails to find the name, or if the allocated type is not a class type or array thereof, the deallocation function's name is looked up in the global scope.
RE: porting gcc/binutils
When I used to work for Cygnus Solutions (and then Red Hat after they bought Cygnus in 1999), the general port to an embedded target was typically done in parallel by 3 people (or 3 groups for large ports). Before starting out, somebody would design the ABI (either customer paying for the port, the person doing the compiler port, or some combination of the two). Also, the object file and debug formats were chosen, ELF and Dwarf was the default choice, unless there was some overriding reason to use something else. The first parallel part of the port was porting gas and then ld. You need to look at the machine and determine what object file relocations are needed. If you were using ELF, in theory you would reserve the appropriate magic numbers with SCO so that there would be no conflicts, but a lot of ports didn't do that. I may have been one of the last people to get an official E_xxx number (E_SEP) before SCO started on its current self destructive path. As the assembler/linker work is started, the compiler person/team would begin work. Most ports are done by cloning another port, and often times you can find places where the original comments were not modified. When I did my second port from scratch, I set out to write a generic backend that had all of the options as comments. Unfortunately, the port had decayed since it was not kept up to date, and is probably less than useful, even if it had been released outside of Cygnus/Red Hat. Obviously, after the initial definition, you will need the assembler and linker to complete the compiler. After the assembler/linker is done, the person/team doing that usually would work on the simulator, and the simulator will be needed for the second stage of compiler debugging (once everything builds). If you have the machine available in silicon form, then you can skip this step. If your target is a regular target like a RISC platform, the CGEN system can be used to simplify building the instruction tables: http://sourceware.org/cgen/ The compiler team does all of the initial work. By the time the compiler can build stuff, either the compiler or binutils team will create the system specific parts of newlib to handle I/O, etc. on the simulator or hardware. Once programs can be built and linked, the debugger team does whatever is needed to bring up gdb. Often times, the debugger would trail the compiler, and the initial part of debugging the compiler was done via simulator traces. Running hello world is a milestone. First you write it using the write system call, and in the second iteration you rewrite it using printf. The next milestone is running a full make check on each of the tools, adding specific machine support for the assembler, linker, etc. Usually after the compiler system is up and running, you start looking into adding shared library support, new optimizations, etc. For a lot of embedded chips, the next step is porting Linux or BSD to the chip. By then you need to start porting the applications that will be run on the target, and fixing bugs, adding new optimizations, etc. If you are the only person doing the project, I would do assembler, linker, simulator, compiler, newlib, debugger, finish compiler port, port Linux If you intend to have the port contributed to the FSF, be sure you start your paperwork early. If you are being paid for the work, you will need signatures from the appropriate corporate officers to verify that you are legally allowed to contribute the code. If you are doing this in your spare time, make sure you know what your legal status is for code that you write. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrija Radicevic Sent: Wednesday, December 14, 2005 6:31 PM To: [EMAIL PROTECTED] Subject: porting gcc/binutils Hi, I'm trying to port gcc and binutils to a new target and I hoped to find a brief procedure on that matter on the net, but was unsuccessful. OK, the GCC internals is quite a resourceful document and one can learn a lot by examining the source tree, but It would be very helpful if there would be a brief procedure description (HOWTO). Like what to do first, port gas I guess, and what to do (like create your directory(s), write ISA file(s), machine descriptions, coff/elf generation etc.). I'd be really grateful if someone could help me out. best regards Andrija Radicevic
Re: RFC: combine simplification change: 2-for-2-with-lesser-cost
> Date: Tue, 20 Dec 2005 12:34:30 +0100 > From: Hans-Peter Nilsson <[EMAIL PROTECTED]> > I want it done there *only* because that's what it does for the > similar but even more complex cc0 code and because combine does > multi-insn simplifications in general. Never mind, I think I have a reasonably small and simple patch for cse.c:find_comparison_args that lets it do what everybody expects it to do. brgds, H-P
GCC 4.1 ICE during CPU2000/177.mesa build
GCC 4.1 is getting ICE in ' refers_to_regno_for_reload_p' while compiling CPU2000/177.mesa on ia32 Linux. Is that a known issue? This is what I got: triangle.c: In function 'simple_z_textured_triangle': triangle.c:461: internal compiler error: in refers_to_regno_for_reload_p, at reload.c: 6285 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. specmake: *** [mesa] Error 1 Thanks! - Grigory
Important
Salut ! Royal Contact a maintenant décidé d'orienter sa clientèle dans la tranche d'âge entre 18 et 40 ans. Une publicité sera faite dans les CEGEPS et Universités pour recrutter du nouveau monde. Si vous êtes dans cette tranche d'âge, Faites-vous une fiche sur le site et une fois entré, cliquez le lien pour contacter l'administration. Inscrivez votre nick et dites que vous aimeriez être membre privilège. Si votre profil comporte une photo, toutes les options y compris la salle video vous seront offertes gratuitement pour toute la période de la promotion de départ. Profitez-en pendant que ça passe. Joyeux Noel et au plaisir de vous voir sur Royal Contact. www.royalcontact.com
Re: GCC 4.1 ICE during CPU2000/177.mesa build
On Tue, Dec 20, 2005 at 11:04:11PM +0300, Grigory Zagorodnev wrote: > GCC 4.1 is getting ICE in ' refers_to_regno_for_reload_p' while > compiling CPU2000/177.mesa on ia32 Linux. > > Is that a known issue? > This is what I got: > > triangle.c: In function 'simple_z_textured_triangle': > triangle.c:461: internal compiler error: in > refers_to_regno_for_reload_p, at reload.c: > 6285 > Please submit a full bug report, > with preprocessed source if appropriate. > See http://gcc.gnu.org/bugs.html> for instructions. > specmake: *** [mesa] Error 1 See http://gcc.gnu.org/PR24982 Just svn update and try again. Jakub
Will there be a GCC 4.0.3 ?
Sorry if this has already been answered, but I couldn't find any status on the site and mailing-list and it's been almost 3 months since the 4.0.2 release. Will there be a 4.0.3 or the next will be 4.1 ? -- How to contact me - http://www.pervalidus.net/contact.html
RE: porting gcc/binutils
Hi Michael, first, thanks for your detailed instructions > If your target is a regular target like a RISC platform, the CGEN system > can be used to simplify building the instruction tables: > http://sourceware.org/cgen/ > I have already stumbled over cgen on the net and skimmed the manual. I have noticed that it uses RTL CPU descriptions, I hope this code can be reused for gcc machine description file. > If you intend to have the port contributed to the FSF, be sure you start > your paperwork early. If you are being paid for the work, you will need > signatures from the appropriate corporate officers to verify that you > are legally allowed to contribute the code. If you are doing this in > your spare time, make sure you know what your legal status is for code > that you write. > I'd be happy to contribute to the FSF, so thanks for reminding me on the legal stuff. But, since all the tools are under GPL, should't the company be obliged to make the code public, i.e. fall under GPL automatically ? Andrija
Re: porting gcc/binutils
> I have already stumbled over cgen on the net and skimmed the > manual. I have noticed that it uses RTL CPU descriptions, I hope > this code can be reused for gcc machine description file. Nope. The only thing cgen's RTL and gcc's RTL share is the acronym.
RE: porting gcc/binutils
The original intention was that CGEN would eventually be able to generate the MD file for GCC. When I last used CGEN 2 years ago, it was not able to do that at the time, and I suspect the problem is very complex for real machines, because often times you have to have various tweaks that don't necessarily fit in the CGEN framework (errata, timing changes, etc.). In terms of paperwork, if a company does not distribute GNU code, it does not have make the changes available (and if it does distribute the compiler, it only has to make the changes available to the people it distributes the compiler binaries to). Obviously it is the best if the code is contributed back to the FSF, but there are machine ports out there that haven't been contributed for various reasons. -Original Message- From: Andrija Radičević [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 20, 2005 5:43 PM To: Meissner, Michael Cc: [EMAIL PROTECTED] Subject: RE: porting gcc/binutils Hi Michael, first, thanks for your detailed instructions > If your target is a regular target like a RISC platform, the CGEN system > can be used to simplify building the instruction tables: > http://sourceware.org/cgen/ > I have already stumbled over cgen on the net and skimmed the manual. I have noticed that it uses RTL CPU descriptions, I hope this code can be reused for gcc machine description file. > If you intend to have the port contributed to the FSF, be sure you start > your paperwork early. If you are being paid for the work, you will need > signatures from the appropriate corporate officers to verify that you > are legally allowed to contribute the code. If you are doing this in > your spare time, make sure you know what your legal status is for code > that you write. > I'd be happy to contribute to the FSF, so thanks for reminding me on the legal stuff. But, since all the tools are under GPL, should't the company be obliged to make the code public, i.e. fall under GPL automatically ? Andrija
Re: GCC 4.1 ICE during CPU2000/177.mesa build
On Tuesday 20 December 2005 21:04, Grigory Zagorodnev wrote: > GCC 4.1 is getting ICE in ' refers_to_regno_for_reload_p' while > compiling CPU2000/177.mesa on ia32 Linux. > > Is that a known issue? You could have asked bugzilla before asking here ;-) Gr. Steven
gcc-3.4-20051220 is now available
Snapshot gcc-3.4-20051220 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20051220/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 3.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-3_4-branch revision 108871 You'll find: gcc-3.4-20051220.tar.bz2 Complete GCC (includes all of below) gcc-core-3.4-20051220.tar.bz2 C front end and core compiler gcc-ada-3.4-20051220.tar.bz2 Ada front end and runtime gcc-g++-3.4-20051220.tar.bz2 C++ front end and runtime gcc-g77-3.4-20051220.tar.bz2 Fortran 77 front end and runtime gcc-java-3.4-20051220.tar.bz2 Java front end and runtime gcc-objc-3.4-20051220.tar.bz2 Objective-C front end and runtime gcc-testsuite-3.4-20051220.tar.bz2The GCC testsuite Diffs from 3.4-20051213 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-3.4 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.
The Linux binutils 2.16.91.0.5 is released
This is the beta release of binutils 2.16.91.0.5 for Linux, which is based on binutils 2005 1219 in CVS on sources.redhat.com plus various changes. It is purely for Linux. The new x86_64 assembler no longer accepts monitor %eax,%ecx,%edx You should use monitor %rax,%ecx,%edx or monitor which works with both old and new x86_64 assemblers. They should generate the same opcode. The new i386/x86_64 assemblers no longer accept instructions for moving between a segment register and a 32bit memory location, i.e., movl (%eax),%ds movl %ds,(%eax) To generate instructions for moving between a segment register and a 16bit memory location without the 16bit operand size prefix, 0x66, mov (%eax),%ds mov %ds,(%eax) should be used. It will work with both new and old assemblers. The assembler starting from 2.16.90.0.1 will also support movw (%eax),%ds movw %ds,(%eax) without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are available at http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch The ia64 assembler is now defaulted to tune for Itanium 2 processors. To build a kernel for Itanium 1 processors, you will need to add ifeq ($(CONFIG_ITANIUM),y) CFLAGS += -Wa,-mtune=itanium1 AFLAGS += -Wa,-mtune=itanium1 endif to arch/ia64/Makefile in your kernel source tree. Please report any bugs related to binutils 2.16.91.0.5 to [EMAIL PROTECTED] and http://www.sourceware.org/bugzilla/ If you don't use # rpmbuild -ta binutils-xx.xx.xx.xx.xx.tar.bz2 to compile the Linux binutils, please read patches/README in source tree to apply Linux patches if there are any. Changes from binutils 2.16.91.0.4: 1. Update from binutils 2005 1219. 2. Fix a MIPS linker regression (PR 1932). 3. Fix an objcopy bug for ia64 (PR 1991). 4. Fix a linker crash on bad input (PR 2008). 5. Fix 64bit monitor and mwait (PR 1874). Changes from binutils 2.16.91.0.3: 1. Update from binutils 2005 . 2. Fix ELF orphan section handling (PR 1467) 3. Fix ELF section attribute handleing (PR 1487). 4. Fix IA64 unwind info dump for relocatable files. (PR 1436). 5. Add DWARF info dump to objdump. 6. Fix SHF_LINK_ORDER handling (PR 1321). 7. Don't allow "ld --just-symbols" on DSO (PR 1263). 8. Fix a "ld -u" crash on TLS symbol (PR 1301). 9. Fix an IA64 linker crash (PR 1247). 10. Fix a MIPS linker bug (PR 1150). 11. Fix a M68K linker bug (PR 1775). 12. Fix an ELF symbol versioning linker bug (PR 1540). 13. Improve linker error handling (PR 1208). 14. Add new SPARC processors to SunOS for objcopy (PR 1472). 15. Add "@file" to read options from a file. Changes from binutils 2.16.91.0.2: 1. Update from binutils 2005 0821. 2. Support x86-64 medium model. 3. Fix "objdump -S --adjust-vma=xxx" (PR 1179). 4. Reduce R_IA64_NONE relocations from R_IA64_LDXMOV relaxation. 5. Fix x86 linker regression for dosemu. 6. Add "readelf -t/--section-details" to display section details. 7. Fix "as -al=file" regression (PR 1118). Changes from binutils 2.16.91.0.1: 1. Update from binutils 2005 0720. 2. Add Intel VMX support. 3. Add AMD SVME support. 4. Add x86-64 new relocations for medium model. 5. Fix a PIE regression (PR 975). 6. Fix an x86_64 signed 32bit displacement regression. 7. Fix PPC PLT (PR 1004). 8. Improve empty section removal. Changes from binutils 2.16.90.0.3: 1. Update from binutils 2005 0622. 2. Fix a linker versioning bug exposed by gcc 4 (PR 1022/1023/1025). 3. Optimize ia64 br->brl relaxation (PR 834). 4. Improve linker empty section removal. 5. Fix DWARF 2 line number reporting (PR 990). 6. Fix DWARF 2 line number reporting regression on assembly file (PR 1000). Changes from binutils 2.16.90.0.2: 1. Update from binutils 2005 0510. 2. Update ia64 assembler to support comdat group section generated by gcc 4 (PR 940). 3. Fix a linker crash on bad input (PR 939). 4. Fix a sh64 assembler regression (PR 936). 5. Support linker script on executable (PR 882). 6. Fix the linker -pie regression (PR 878). 7. Fix an x86_64 disassembler bug (PR 843). 8. Fix a PPC linker regression. 9. Misc speed up. Changes from binutils 2.16.90.0.1: 1. Update from binutils 2005 0429. 2. Fix an ELF linker regression (PR 815). 3. Fix an empty section removal related bug. 4. Fix an ia64 linker regression (PR 855). 5. Don't allow local symbol to be equated common/undefined symbols (PR 857). 6. Fix the ia64 linker to handle local dynamic symbol error reporting. 7. Make non-debugging reference to discarded section an error (PR 858). 8. Support Sparc/TLS. 9. Support rpm build with newer rpm. 10. Fix an alpha linker regression. 11. Fix the non-gcc build regression. Changes from binutils 2.15.94.0.2.2: 1. Update from binutils 2005 0408. 2. The i386/x86_64 assemblers no longer accept instructions for moving between a segment register and a 32bit memory location. 3. The x86_64 assembler now allow
Re: Will there be a GCC 4.0.3 ?
Frédéric L. W. Meunier wrote: > Sorry if this has already been answered, but I couldn't find any status > on the site and mailing-list and it's been almost 3 months since the > 4.0.2 release. Will there be a 4.0.3 or the next will be 4.1 ? There will be a GCC 4.0.3. I plan to begin work on that release shortly. The GCC 4.0.x branch is stable, so it's relatively easy to make a release. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (650) 331-3385 x713
Re: porting gcc/binutils
<[EMAIL PROTECTED]> writes: > The original intention was that CGEN would eventually be able to > generate the MD file for GCC. When I last used CGEN 2 years ago, it > was not able to do that at the time, and I suspect the problem is > very complex for real machines [...] There exists a CGEN/SID/GCC port where cgen rtl instructions are automagically turned into suitable gcc builtins. This port has some other unusual capabilities (arbitrary relocation expressions for evaluation at link time, rich parallelism, VLIW), but might not end up in mainline. - FChE
