Naren KN wrote:
Hi Nathan,
Please copy the gcc list on these things.
I was asking this question and didn't get much reply.. regarding the
c++ frontend ... After calling the c_parse_file(), I wish to walk
through the list of namespaces, inturn all the classes and functions
inside them... c
Naren KN wrote:
Hi Nathan,
I was unable to find such a function in my source tree. I'm using the
4.0.2 version. Are you talking about the trunk version?
sorry, walk_namespaces in cp/decl.c
nathan
--
Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery
[EMAIL PROTEC
Well,
/usr/local/src/trunk/objdir/./prev-gcc/xgcc
-B/usr/local/src/trunk/objdir/./prev-gcc/
-B/usr/local/i686-pc-cygwin/bin/ -c -g -O2 -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-d
* Mark Mitchell <[EMAIL PROTECTED]> [2006-05-18 15:33]:
> GCC 4.1.1 RC1 is available from:
> ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.1-20060517
Running make check after make gives me:
| Newly fixed header: ia64/sys/getppdp.h
|
| There were fixinclude test FAILURES
--
Martin Michlmayr
[EMAIL
Richard, Roger --
Roger, would you please revert your MIPS MIN_UNITS_PER_WORD change for
MIPS on the GCC 4.1 branch?
(My brain failed to digest the fact that the patch was on 4.1 as well as
on mainline, perhaps in part because there doesn't seem to be a PR;
Richard indicated to me that he would l
Mark Mitchell <[EMAIL PROTECTED]> writes:
> (My brain failed to digest the fact that the patch was on 4.1 as well as
> on mainline, perhaps in part because there doesn't seem to be a PR;
> Richard indicated to me that he would locate or open one now.)
Opened as 27681. (And Roger: sorry for all th
OK, Here is an official patch proposal to replace the contents of the
src/intl tree with the bits from gcc/intl.
I tested the change on HPPA and IA64 HP-UX and on IA64 Linux. The Linux
build didn't prove much because it used the system gettext bits but the
HP-UX builds built and used the new intl
Hi Steve,
OK, Here is an official patch proposal to replace the contents of the
src/intl tree with the bits from gcc/intl.
2006-05-19 Steve Ellcey <[EMAIL PROTECTED]>
* MAINTAINERS: Change intl updating instructions.
* config.rpath: Copy from GCC tree.
* intl: Repla
On Fri, May 19, 2006 at 04:54:17PM +0100, Nick Clifton wrote:
> Hi Steve,
>
> >OK, Here is an official patch proposal to replace the contents of the
> >src/intl tree with the bits from gcc/intl.
>
> >2006-05-19 Steve Ellcey <[EMAIL PROTECTED]>
> >
> > * MAINTAINERS: Change intl updating ins
Bootstrap failure in gnattools for ia64-unknown-linux-gnu. Complaining on
missing libunwind.so.7
gmake[3]: Entering directory
`/disk1/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/gcc-4.1.1-RC1/gcc-4.1.1-RC1/gnattools'
rm -rf ../gcc/ada/tools
mkdir -p ../gcc/ada/tools
(cd ../gcc/ada/tools; ln -s
Hi Mark and Richard,
On Fri, 19 May 2006, Mark Mitchell wrote:
> Roger, would you please revert your MIPS MIN_UNITS_PER_WORD change
> for MIPS on the GCC 4.1 branch?
>
> (My brain failed to digest the fact that the patch was on 4.1 as well as
> on mainline, perhaps in part because there doesn't s
Hi Richard,
On Fri, 19 May 2006, Richard Sandiford wrote:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
> > (My brain failed to digest the fact that the patch was on 4.1 as well as
> > on mainline, perhaps in part because there doesn't seem to be a PR;
> > Richard indicated to me that he would loca
On Fri, 19 May 2006, Roger Sayle wrote:
> Indeed, no good deed ever goes unpunished. In fact, isn't it the MIPS
> backend's use of the GOFAST libraries which is one of the major blockers
The GOFAST support is almost certainly unused and can probably be removed;
at least, no-one has cared enough
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Michlmayr wrote:
> * Mark Mitchell <[EMAIL PROTECTED]> [2006-05-18 15:33]:
>> GCC 4.1.1 RC1 is available from:
>> ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.1-20060517
>
> Running make check after make gives me:
>
> | Newly fixed header: ia64
Roger Sayle wrote:
> Hi Mark and Richard,
>
> On Fri, 19 May 2006, Mark Mitchell wrote:
>> Roger, would you please revert your MIPS MIN_UNITS_PER_WORD change
>> for MIPS on the GCC 4.1 branch?
>>
>> (My brain failed to digest the fact that the patch was on 4.1 as well as
>> on mainline, perhaps in
On May 19, 2006, at 9:59 AM, Mark Mitchell wrote:
Am I correct PR 22209 is "only" a Fortran problem? This is not a
rhetorical question; I'm trying to gather data
No, you can invoke it via using the attribute mode(TI), yes people
are not going to do that but who knows.
-- Pinski
Andrew Pinski wrote:
>
> On May 19, 2006, at 9:59 AM, Mark Mitchell wrote:
>
>>
>> Am I correct PR 22209 is "only" a Fortran problem? This is not a
>> rhetorical question; I'm trying to gather data
>
> No, you can invoke it via using the attribute mode(TI)
Sure, but I'm not worried about that
On May 19, 2006, at 10:12 AM, Mark Mitchell wrote:
Andrew Pinski wrote:
On May 19, 2006, at 9:59 AM, Mark Mitchell wrote:
Am I correct PR 22209 is "only" a Fortran problem? This is not a
rhetorical question; I'm trying to gather data
No, you can invoke it via using the attribute mode(TI
On Fri, 19 May 2006, Mark Mitchell wrote:
> > No, you can invoke it via using the attribute mode(TI)
> Sure, but I'm not worried about that case.
That would be the only class of C or C++ failures that I could easily
construct by hand. Although the RTL optimizers will introduce TImode
moves and t
> ! intl/; config.rhost; libiberty/; libiberty's part
> ! ...
> ! merge. Otherwise, changes are automatically merged, usually
> ! within a day.
Who signed up to do the automatic merge?
Andrew Pinski wrote:
> Also why revert a patch which obvious works in the default configurations?
It eliminates a Fortran problem, but causes a C problem.
I'm evaluating the options. It would be helpful if someone has time to
apply and test Richard's patch on 4.1, as that would let us know whet
> > ! intl/; config.rhost; libiberty/; libiberty's part
> > ! ...
> > ! merge. Otherwise, changes are automatically merged, usually
> > ! within a day.
>
> Who signed up to do the automatic merge?
I will unless you want to add this to the libiberty merge you do now.
intl changes even less t
On Fri, May 19, 2006 at 06:00:09PM +0200, Rainer Emrich wrote:
> Bootstrap failure in gnattools for ia64-unknown-linux-gnu. Complaining on
> missing libunwind.so.7
>
It is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17464
H.J.
>
> Andrew Pinski wrote:
>
> > Also why revert a patch which obvious works in the default configurations?
>
> It eliminates a Fortran problem, but causes a C problem.
I thought it only caused the problem with C code when supplying -msoft-float
which is not a default configuration?
It eliminate
Andrew Pinski wrote:
>> Andrew Pinski wrote:
>>
>>> Also why revert a patch which obvious works in the default configurations?
>> It eliminates a Fortran problem, but causes a C problem.
>
> I thought it only caused the problem with C code when supplying -msoft-float
> which is not a default confi
With the memory SSA patches we fail gcc.dg/noncompile/920507-1.c:
int *
x(void)
{
register int *a asm("unknown_register"); /* { dg-error "invalid
register" } */
int *v[1] = {a};
return v[1];
}
The expected error message on the invalid register used for 'a' does not
trigger because the store
>
>
> With the memory SSA patches we fail gcc.dg/noncompile/920507-1.c:
>
> int *
> x(void)
> {
> register int *a asm("unknown_register"); /* { dg-error "invalid
> register" } */
> int *v[1] = {a};
> return v[1];
> }
This should fail in the front-end really.
Thanks,
Andrew Pinski
Diego Novillo wrote:
> With the memory SSA patches we fail gcc.dg/noncompile/920507-1.c:
>
> int *
> x(void)
> {
> register int *a asm("unknown_register"); /* { dg-error "invalid
> register" } */
> int *v[1] = {a};
> return v[1];
> }
>
> The expected error message on the invalid register used
Mark Mitchell wrote on 05/19/06 14:54:
> Yes, this test case is valid; the code is ill-formed GNU C, since the
> machine in question know not have a register named "unknown register".
> ^
I can't parse this.
> Yes, I think the c
> I will unless you want to add this to the libiberty merge you do now.
I don't mind adding it to my script, if people agree that's what they
want. It's just that nobody asked :-P
Some basic blocks may represent a (self) loop, but GCC's internal basic
block representation won't show such information explicitly (i.e., it won't
store a self-loop edge).
My question is, when I walk through basic blocks, can I identify then
easily?
E.g., Let's say,
--demo.c--
sean yang wrote:
> Some basic blocks may represent a (self) loop, but GCC's internal basic
> block representation won't show such information explicitly (i.e., it won't
> store a self-loop edge).
> My question is, when I walk through basic blocks, can I identify then
> easily?
>
> E.g., Let's s
Although "BASIC_BLOCK array contains BBs in an unspecified order" as the GCC
internal doc says, can I assume that the final virtual address for an
instruction in BB_m is always higher than the virtual address for an
instruction in BB_n, when m < n. (Let's assume the linker for the target
machi
On May 19, 2006, at 12:48 PM, sean yang wrote:
Although "BASIC_BLOCK array contains BBs in an unspecified order"
as the GCC internal doc says, can I assume that the final virtual
address for an instruction in BB_m is always higher than the
virtual address for an instruction in BB_n, when m
From: Daniel Berlin <[EMAIL PROTECTED]>
To: sean yang <[EMAIL PROTECTED]>
CC: gcc@gcc.gnu.org, [EMAIL PROTECTED]
Subject: Re: identifying a BB representing a self-loop
Date: Fri, 19 May 2006 15:41:30 -0400
sean yang wrote:
> Some basic blocks may represent a (self) loop, but GCC's internal basic
On May 19, 2006, at 6:57 AM, Christian Joensson wrote:
../../gcc/gcc/objc/objc-act.c:5573: warning: implicit declaration of
function 'default_conversion'
Update and build again... :-)
On May 19, 2006, at 12:01 PM, Diego Novillo wrote:
Mark Mitchell wrote on 05/19/06 14:54:
Yes, this test case is valid; the code is ill-formed GNU C, since the
machine in question know not have a register named "unknown
register".
From: Dale Johannesen <[EMAIL PROTECTED]>
To: sean yang <[EMAIL PROTECTED]>
CC: Dale Johannesen <[EMAIL PROTECTED]>, gcc@gcc.gnu.org
Subject: Re: address order and BB numbering
Date: Fri, 19 May 2006 12:54:56 -0700
On May 19, 2006, at 12:48 PM, sean yang wrote:
Although "BASIC_BLOCK array c
sean yang wrote on 05/19/06 15:48:
> can I assume that the final virtual address for
> an instruction in BB_m is always higher than the virtual address for an
> instruction in BB_n, when m < n.
>
No. Think code insertion.
> Then this must be a very dummy question. How the compiler keep the
> instruction order in the RTL IR format in a function? By the information
> like "insn 50 56 51" ? e.g.,
> (insn 50 56 51 4 (clobber (reg/i:SI 0 ax)) -1 (nil) )
It's a linked list. The 56 and 51 link to the previous and nex
Diego Novillo wrote:
> Mark Mitchell wrote on 05/19/06 14:54:
>
>> Yes, this test case is valid; the code is ill-formed GNU C, since the
>> machine in question know not have a register named "unknown register".
>> ^
> I can't par
Roger Sayle <[EMAIL PROTECTED]> writes:
> Indeed, no good deed ever goes unpunished. In fact, isn't it the MIPS
> backend's use of the GOFAST libraries which is one of the major blockers
> of adding -msoft-float tests to the testsuite? :-)
No. As I've explained earlier this week, -msoft-float c
Andrew Pinski <[EMAIL PROTECTED]> writes:
> If the back-end was not lying to the front-ends, this would never
> have been a problem, hint hint.
I'm not sure what you mean here. In what way is the back end lying
to the front end?
Richard
Snapshot gcc-4.1-20060519 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060519/
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
DJ Delorie wrote:
>> I will unless you want to add this to the libiberty merge you do now.
>
> I don't mind adding it to my script, if people agree that's what they
> want. It's just that nobody asked :-P
I hereby request that you add automatic intl/ merging to your script. :-)
--
Mark Mitchel
On 5/2/06, Christian Joensson <[EMAIL PROTECTED]> wrote:
On 5/1/06, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > Any ideas?
>
> Re-run the testsuite, they most likely will disappear.
right... I somehow had memory kernel related issues... A new one now... c9a011b
there is something weird about
46 matches
Mail list logo
