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 fi
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.
> 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
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.
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?
A
> 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 possibl
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.
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} (in
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 -gna
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 woul
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
> 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 com
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.
> 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
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
> 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
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 asse
> 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 de
> 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
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, t
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
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
> >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
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
> 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 n
>>>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 pe
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
> 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 fo
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 der
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
fragment
> 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 AI
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
> 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
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
[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
> entir
> 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
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 commi
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 st
[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 W
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
CodeSo
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 op
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
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
> 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 reasonab
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:
628
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é, cliq
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.
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
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 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.
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 n
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
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
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
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 r
<[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
56 matches
Mail list logo
