Re: Support for the MPC5554 in gcc ?
Hello, To: > Can GCC 4.X be used to generate code running properly on a MPC5554 > processor ? [...] > What are the GCC 3.4 capabilities on the same account ? David Edelsohn replied: << The base PowerPC Book-E UISA generated by GCC should work on the MPC5554. I am not sure about the difference between the 5554 e200 core and the 8540 e500 core. Kumar Gala at Freescale probably can provide more details about compatibility with GCC's e500 support and support in previous GCC releases. >> Then Clemens Koller: << I've just compiled and installed the official gcc-3.4.4 release as a native compiler on an MPC8540 like that: [...] >> and << Oh, i've just seen that: http://www.freescale.com/files/32bit/doc/white_paper/POWRPCARCPRMRM.pdf The e200z6, implemented in the MPC5556 microcontroller, is code-compatible with +e500 core (including isel, SPE, and single-precision floating-point APUs). >> This all was very useful feeback, much appreciated, thanks a lot :) With Kind Regards, Olivier
software floating point & machine descriptions
Hi, gcc I have to send the new mail again for the software floating point problem. I need more details about it. 1) If I use software floating point, does I need implement float mode insns in md file? Such as movsf, movdf. 2)How to generate correct object files of libgcc2 of floating point operations? Such as _floatdidf. Thank you very much. Eric.
failed to build libgfortran gcc-4.0.1 on mips-sgi-irix6.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 /SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.0.1-test/gcc-4.0.1-test/gcc/xgcc - -B/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.0.1-test/gcc-4.0.1-test/gcc/ - -B/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/mips-sgi-irix6.5/bin/ - -B/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/mips-sgi-irix6.5/lib/ - -isystem /SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/mips-sgi-irix6.5/include - -isystem /SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/mips-sgi-irix6.5/sys-include - -DHAVE_CONFIG_H -I. - -I/raid/tecosim/it/devel/projects/develtools/src/gcc-4.0.1-test/libgfortran - -I. - -iquote/raid/tecosim/it/devel/projects/develtools/src/gcc-4.0.1-test/libgfortran/io - -std=gnu99 -Wall -O2 -g -O2 -mabi=32 -c /raid/tecosim/it/devel/projects/develtools/src/gcc-4.0.1-test/libgfortran/generated/exp_c8.c - -o exp_c8.o /raid/tecosim/it/devel/projects/develtools/src/gcc-4.0.1-test/libgfortran/generated/exp_c8.c:38: error: conflicting types for 'cabs' /SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.0.1-test/gcc-4.0.1-test/gcc/include/math.h:676: error: previous declaration of 'cabs' was here configured with: /raid/tecosim/it/devel/projects/develtools/src/gcc-4.0.1-test/configure - --prefix=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install - --with-gnu-as - --with-as=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/bin/as - --with-gnu-ld - --with-ld=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/bin/ld - --disable-shared --enable-threads=single --enable-haifa --disable-nls - --disable-libmudflap --enable-languages=c,ada,c++,f95,objc - --with-gmp=/appl/shared/gnu/IRIX64/mips-sgi-irix6.5 - --with-mpfr=/appl/shared/gnu/IRIX64/mips-sgi-irix6.5 - -- Rainer Emrich TECOSIM GmbH Im Eichsfeld 3 65428 Rüsselsheim Phone: +49(0)6142/8272 12 Mobile: +49(0)163/56 949 20 Fax.: +49(0)6142/8272 49 Web: www.tecosim.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDJUuZ3s6elE6CYeURAvphAJ41Q+V9wtWZG70nNPfgsTZu5UlKdgCgx2WI AILkpLglpO1tFjNc5VkQWEI= =tJPb -END PGP SIGNATURE-
Re: sh64 support deteriorating
Richard Henderson wrote: On Fri, Sep 09, 2005 at 04:58:50PM +0100, Joern RENNECKE wrote: The lack of a debugger that works reliably with recent gcc versions has led to an increasing backlog of uninvestigated execution failures. Do you think it's the debugger or the compiler that's at fault? The debugger crashes when certain (recently pretty much any) debug information is enclosed. Thus, the debugger is at fault, for crashing. But for all I know, the compiler might also be at fault, for emitting invalid debug information; however it is more likely newer debug information that my vintage gdb can't understand. The execution failures are most likely gcc bugs, except when prefetching unmapped memory is involved; the simulator had a bug there.
Re: zero sized initializers with side effects discarded
Andrew Pinski wrote: > > FWIW, I think part of the problem is that TREE_SIDE_EFFECTS is not > > set on the constructor, despite the presence of a function call in > > the components. > No, that is not the problem. The problem is that we gimplify the > expression for side effects but don't actually add the expression if > the gimplify put it back in the same expression. > Any ways, the following patch fixes the issue correctly. > > If you could test and post the patch, that would be nice? Will look into it as a separate change (from the init_ctor that I'm about to submit). Thanks.
SH patch applied (Was: Re: sh64 support deteriorating)
Kaz Kojima wrote:
some compile time errors in c/c++ test for sh64-unknown-linux-elf
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00466.html
3 tests
gcc.c-torture/compile/simd-4.c
gcc.c-torture/execute/20050604-1.c
gcc.dg/torture/pr21817-1.c
fail with the similar ICE:
gcc/gcc/testsuite/gcc.c-torture/compile/simd-4.c: In function 'tempf':
gcc/gcc/testsuite/gcc.c-torture/compile/simd-4.c:15: error: unable to find a
register to spill in class 'GENERAL_REGS'
gcc/gcc/testsuite/gcc.c-torture/compile/simd-4.c:15: error: this is the insn:
(insn 53 52 54 0 (set (subreg:DI (reg:V4SF 68 fr4 [196]) 0)
(and:DI (subreg:DI (reg:V4SF 68 fr4 [196]) 0)
(const_int -4294967296 [0x]))) 85 {anddi3} (nil)
(nil))
Yes, these appeared also in the simulator tests.
It seems odd that the DImode subregs of V4SFmode registers are used
as the operands of logical operations, though I don't understand why
reload complains as above.
reload complained because HARD_REGNO_MODE_OK disallowed
V4SFmode in GENERAL_REGS. Allowing that also causes register
allocation to use GENERAL_REGS in the first place. An and with a
J16 constraint can also be done with FP_REGS using mov.ls from r63.
A natural way to implement this would use an fr (or rf) constraint in
one of the alternatives. While looking at this I also found that we were
missing a register class for an fr constraint. I've tested the attached
patch over the weekend for sh-elf and sh64-elf, and checked it in now.
2005-09-12 J"orn Rennecke <[EMAIL PROTECTED]>
* sh.h (HARD_REGNO_MODE_OK): Allow V4SFmode in general purpose
registers for TARGET_SHMEDIA.
(enum reg_class, REG_CLASS_NAMES, REG_CLASS_CONTENTS): Rename
GENERAL_FP_REGS to GENERAL_DF_REGS. Add GENERAL_FP_REGS as union
of GENERAL_REGS and FP_REGS.
Index: sh.h
===
RCS file: /cvs/gcc/gcc/gcc/config/sh/sh.h,v
retrieving revision 1.276
diff -p -r1.276 sh.h
*** sh.h6 Aug 2005 13:26:24 - 1.276
--- sh.h12 Sep 2005 13:21:53 -
*** extern char sh_additional_register_names
*** 1152,1158
|| GENERAL_REGISTER_P (REGNO)) \
: (MODE) == V4SFmode \
? ((FP_REGISTER_P (REGNO) && ((REGNO) - FIRST_FP_REG) % 4 == 0) \
! || (! TARGET_SHMEDIA && GENERAL_REGISTER_P (REGNO))) \
: (MODE) == V16SFmode \
? (TARGET_SHMEDIA \
? (FP_REGISTER_P (REGNO) && ((REGNO) - FIRST_FP_REG) % 16 == 0) \
--- 1152,1158
|| GENERAL_REGISTER_P (REGNO)) \
: (MODE) == V4SFmode \
? ((FP_REGISTER_P (REGNO) && ((REGNO) - FIRST_FP_REG) % 4 == 0) \
! || GENERAL_REGISTER_P (REGNO)) \
: (MODE) == V16SFmode \
? (TARGET_SHMEDIA \
? (FP_REGISTER_P (REGNO) && ((REGNO) - FIRST_FP_REG) % 16 == 0) \
*** enum reg_class
*** 1341,1346
--- 1341,1347
DF_REGS,
FPSCR_REGS,
GENERAL_FP_REGS,
+ GENERAL_DF_REGS,
TARGET_REGS,
ALL_REGS,
LIM_REG_CLASSES
*** enum reg_class
*** 1365,1370
--- 1366,1372
"DF_REGS", \
"FPSCR_REGS", \
"GENERAL_FP_REGS", \
+ "GENERAL_DF_REGS", \
"TARGET_REGS", \
"ALL_REGS", \
}
*** enum reg_class
*** 1402,1408
/* FPSCR_REGS: */\
{ 0x, 0x, 0x, 0x, 0x0080 }, \
/* GENERAL_FP_REGS: */
\
! { 0x, 0x, 0x, 0x, 0x0102ff00 }, \
/* TARGET_REGS: */ \
{ 0x, 0x, 0x, 0x, 0x00ff }, \
/* ALL_REGS: */ \
--- 1404,1412
/* FPSCR_REGS: */\
{ 0x, 0x, 0x, 0x, 0x0080 }, \
/* GENERAL_FP_REGS: */
\
! { 0x, 0x, 0x, 0x, 0x0302 }, \
! /* GENERAL_DF_REGS: */
\
! { 0x, 0x, 0x, 0x, 0x0302ff00 }, \
/* TARGET_REGS: */ \
{ 0x, 0x, 0x, 0x, 0x00ff }, \
/* ALL_REGS: */ \
Re: Retested: RFA: fix PR middle-end/23290
Thanks for the review. Richard Henderson wrote: Though I'll state again for the record that any ABI that bases its decisions on modes instead of tree codes is broken. The specific mode that was tested against was BLKmode. If we want to make ports impervious to random use of BLKmode, we should declare the practice of FUNCTION_ARG yielding a REG rtx as obsolete, i.e. everything but a plain stack argument has to be expressed with a PARALLEL. At the moment, tm.texi still states that a value not passes on the stack is usually expressed with a REG rtx, and these can't handle BLKmode.
New port contribution - picoChip
Hi all, For the past 4 years or so I have maintained a port of gcc for the range of embedded processors developed by picoChip Designs Ltd. I would now like to formally contribute this port. Key points to note are: Assignment forms have been filed with the FSF. I have obtained cvs-write permission. All work listed in `Anatomy of a Target Back End' has been completed, with the exception of web page updates. The linker and assembler used by the port are proprietary, and can't be made publicly available at this point. The port will have to be assembler output only. Custom test procedures are used, which don't currently work with DejaGNU. This will be fixed at some point. The port is almost independent of any other changes to gcc. When my port was based upon 3.4.0 it relied on a patch in sched-deps.c, but the patch was never applied to mainline (http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00598.html). I have now upgraded my port to the current mainline (4.1.0 20050912), and all of my regression tests which exposed the original bug now pass, with no need for the patch. From inspecting the code, I believe that another bug fix I recently applied to my port (http://gcc.gnu.org/ml/gcc/2005-09/msg00088.html) fixes the problem indirectly. Assuming that my port doesn't require a patch in sched-deps.c, can I submit this port to gcc in time for the 4.1 branch, or must I wait until afterwards? If I was allowed to submit before the branch, what would the deadline be? Thanks, dan. = Daniel Towner picoChip Designs Ltd., Riverside Buildings, 108, Walcot Street, BATH, BA1 5BG [EMAIL PROTECTED] http://www.picochip.com +44 (0) 7786 702589
Re: New port contribution - picoChip
> Daniel Towner writes: Daniel> Assuming that my port doesn't require a patch in sched-deps.c, can I Daniel> submit this port to gcc in time for the 4.1 branch, or must I wait Daniel> until afterwards? If I was allowed to submit before the branch, what Daniel> would the deadline be? GCC development allows a lot of leeway to new ports and port-specific changes that do not require changes to the common parts of the compiler. The GCC development plan would allow the port to be accepted for GCC 4.1, the new port needs to be reviewed by a GWP maintainer. David
Any plan to support Windows/x86-64?
Is there any plan to support Windows/x86-64? What are needed for the port? H.J.
Re: New port contribution - picoChip
Daniel Towner <[EMAIL PROTECTED]> wrote: > The linker and assembler used by the port are proprietary, and can't > be made publicly available at this point. The port will have to be > assembler output only. I suppose this means that nobody but you will ever be able to run/test your backend. If you are fine with this, I don't think anybody will object. > Custom test procedures are used, which don't currently work with > DejaGNU. This will be fixed at some point. Are you still able to produce mails which resemble the DejaGNU output (for gcc-testresults@ mailing list)? It is common to watch status reports in that mailing list to understand "how much live" a port is. I suggest you to regurarly post reports to show that the port is not bitrotting. You will also have to officially volunteer to be the maintainer of the port. I suppose this was implicit in your mail. I suggest you to double check also the list present in this mail: http://gcc.gnu.org/ml/gcc-patches/2004-06/msg01625.html This was never publically approved, but it reflects views of many GCC maintainers. Surely it does not hurt to follow those guidelines, even if they are (yet) not showstoppers for a backend inclusion. -- Giovanni Bajo
Re: New port contribution - picoChip
On Monday 12 September 2005 18:55, Giovanni Bajo wrote: > Daniel Towner <[EMAIL PROTECTED]> wrote: > > The linker and assembler used by the port are proprietary, and can't > > be made publicly available at this point. The port will have to be > > assembler output only. > > I suppose this means that nobody but you will ever be able to run/test your > backend. If you are fine with this, I don't think anybody will object. I think people should object. What is the point in having a free software compiler if e.g. users can't use a complete free toolchain; or gcc developers not being able to test changes when some patch needs changes in every port. Gr. Steven
RE: New port contribution - picoChip
Original Message >From: Steven Bosscher >Sent: 12 September 2005 18:01 > On Monday 12 September 2005 18:55, Giovanni Bajo wrote: >> Daniel Towner wrote: >>> The linker and assembler used by the port are proprietary, and can't >>> be made publicly available at this point. The port will have to be >>> assembler output only. >> >> I suppose this means that nobody but you will ever be able to run/test >> your backend. If you are fine with this, I don't think anybody will >> object. > > I think people should object. What is the point in having a free > software compiler if e.g. users can't use a complete free toolchain; > or gcc developers not being able to test changes when some patch > needs changes in every port. > > Gr. > Steven I second that. I'd feel differently if there was at least a FOSS simulator around that people could directly run the assembler output on, but as it stands it seems like adding this backend is a burden to the community for zero benefit. I have to ask Dan: *Why* do you want to contribute this port? Cui bono? cheers, DaveK -- Can't think of a witty .sigline today
Re: New port contribution - picoChip
Daniel Towner <[EMAIL PROTECTED]> wrote: > > The linker and assembler used by the port are proprietary, and can't > > be made publicly available at this point. The port will have to be > > assembler output only. On Mon, Sep 12, 2005 at 06:55:28PM +0200, Giovanni Bajo wrote: > I suppose this means that nobody but you will ever be able to run/test your > backend. If you are fine with this, I don't think anybody will object. Daniel wrote "at this point". Presumably they will eventually be made available. Even if they are forever proprietary, others would be able to port the GNU assembler and linker at a later time.
Re: New port contribution - picoChip
Steven Bosscher <[EMAIL PROTECTED]> wrote: >>> The linker and assembler used by the port are proprietary, and can't >>> be made publicly available at this point. The port will have to be >>> assembler output only. >> >> I suppose this means that nobody but you will ever be able to run/test your >> backend. If you are fine with this, I don't think anybody will object. > > I think people should object. What is the point in having a free > software compiler if e.g. users can't use a complete free toolchain; > or gcc developers not being able to test changes when some patch > needs changes in every port. You can still test compilation, at least. I think it makes sense as an intermediate step, assuming the port of binutils is in the works. Usually first binutils is contributed, but hey. -- Giovanni Bajo
Re: New port contribution - picoChip
A similar issue was raised last Spring and discussed by the GCC Steering Committee. Mark Mitchell summarized the response, including Richard Stallman's comment: http://gcc.gnu.org/ml/gcc/2005-06/msg00134.html There is no need to resurrect that debate. David
RE: New port contribution - picoChip
Original Message >From: David Edelsohn >Sent: 12 September 2005 19:00 > A similar issue was raised last Spring and discussed by the GCC > Steering Committee. Mark Mitchell summarized the response, including > Richard Stallman's comment: > > http://gcc.gnu.org/ml/gcc/2005-06/msg00134.html " There is no need to have a uniform policy about it. There is no compelling reason to treat all such cases alike. " > There is no need to resurrect that debate. I will not post to this thread again. Everyone else can do as they please AFAIC. cheers, DaveK -- Can't think of a witty .sigline today
Re: Introduction of GCC improvement work for Itanium via Gelato Federation
Vladimir N. Makarov wrote: > The ORC backend optimizations proven to work for Itanium could be > rewritten for RTL with usage of existing gcc infrastructure, added to > gcc and could be used for other ports. I think it is more right way to do. I strongly agree, except that I would generalize "RTL" to "tree-ssa and RTL". In fact, I have personally encouraged some of the people involved in this new effort to approach the problem from the point of view of taking the best of the ORC algorithms and incorporating them into GCC, rather than trying to get the community to switch to the ORC back-end. I've advocated that position for several years, to some of the key decision-makers, including as recently as a couple of weeks ago. I've been told by at least some ORC people that the long-term plan is to do as I've suggested, but that they can't do it in the short term. >From my conversations, I've been lead to think that there are two considerations that are causing the ORC people to want to stay separate. The first is that they believe that the ORC performance on the target platforms of interest is sufficiently better than FSF GCC that their time-to-solution using ORC is quicker than using GCC. I don't know how to counter this point, as it may very well be true. I've made the long-term argument about maintenance, forking, support for many architectures, etc., but I was told that time-to-solution is the paramount consideration. There are plausible business reasons for the parties involved to feel that way. The second is a not-invented-here attitude towards trees and RTL. Some ORC people claim that WHIRL is *so* much better than trees/RTL that things just can't be fixed tractably in GCC. I disbelieve this argument; I think it's similar to saying that you can't write good code in TCL. I don't disbelieve that WHIRL has advantages, but I do disbelieve that those advantages are so great, or that GCC's IR is so inherently bad, that GCC's optimizers are truly an unsatisfactory place to start. In summary, I think that splitting GCC optimization efforts between FSF and ORC back-ends is unfortunate. I would far rather that the free software community be united behind a single optimizer. But, fundamentally, I don't see much that we can do about it -- unless someone is sitting on a patch for making Itanium performance dramatically better. I think the best that we can do is to try to help identify what it is that makes ORC perform better and adopt those same strategies for FSF GCC. I'm happy that we're collectively spending a lot of time looking at benchmark performance. I think that, for good or ill, SPEC numbers are incredibly important to people. Making those numbers good is a key aspect of making FSF GCC competitive. I'm not suggesting we ignore "real" code, but I am suggesting that benchmark performance is one of the ways GCC is going to be judged, and that we should care about that. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: uncaught exception in g++ 3.4 and 4.0
Andrew Haley wrote:
> There's a thread at
> http://groups.google.co.uk/group/gnu.gcc.help/tree/browse_frm/thread/e85dce7d69fb7dc1
> which looks odd. It seems that the exception filter is not being
> correctly processed.
>
> I can't find a Bugzilla entry for this. Is it really a bug?
>
> Andrew.
>
> quoted message
> From: "Mark Nelson" <[EMAIL PROTECTED]>
> Newsgroups: gnu.gcc.help
> Subject: uncaught exception in g++ 3.4 and 4.0
> Date: 13 Aug 2005 08:35:46 -0700
>
> I have a case where an exception in the constructor of class with a
> virtual base leads to termination:
>
> struct vbase {};
>
> struct foo : virtual vbase {
> foo() {
> throw "exception in foo ctor";
> }
>
> };
>
> main()
> {
> struct bar : public foo {};
> try {
> bar a;
> }
> catch ( ... ) {
> }
> return 0;
>
> };
>
> This program demonstrates the problem in g++ 3.4 a 4.0.0. Instead of
> catching
> the exception, the program terminates. The base dtor gets called as
> expected, but upon return, there is some generated code that I can't
> decipher, which jumps to some termination code at bad_alloc + 80.
>
> That should be a clue... but I'm unable to catch it.
The exception should be caught. The destructor for vbase should be run,
but the destructors for foo and bar should not be, as foo was never
completely constructed. Then, the catch-clause should run, and the
program should return 0.
I suspect the bug is in the logic for computing the exception
specification for the implicitly-defined bar::bar() constructor. It
should allow all exceptions, since the base class constructor does.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Re: New port contribution - picoChip
On Sep 12, 2005, at 8:32 AM, Daniel Towner wrote: I would now like to formally contribute this port. The way to do that is to send an email to gcc-patches, with the port. :-) You can also volunteer to maintain the port at the same time, if you so choose.
Re: New port contribution - picoChip
On 12 Sep 2005, Steven Bosscher gibbered uncontrollably: > I think people should object. What is the point in having a free > software compiler if e.g. users can't use a complete free toolchain; > or gcc developers not being able to test changes when some patch > needs changes in every port. Well, that kills HP-UX and Tru64 and many other targets. A *lot* of targets don't have free-software linkers, in particular. -- `One cannot, after all, be expected to read every single word of a book whose author one wishes to insult.' --- Richard Dawkins
Separating c++ parser
Hi all, I intend to use gcc's C++ parser and the intermediate representation it creates for use in source browsing, etc. I have a few questions regarding this: firstly, is it possible to plug out the parser and intermediate representation code (presumably only in the front-end?) relatively easily? If so, can somebody offer hints on where I could start? I am currently looking into the gcc/cp front-end subdirectory, but clearly, there are a number of dependencies inside the main gcc code as well. The other question is: the build process for gcc is quite hairy - stage1, etc. etc. Since I am not concerned with code generation or optimization at all, I don't think I would need this. How would I begin simplifying the auto* and Makefile.in's to allow building the parser as a stand-alone entity? Thanks in advance for any help or pointers! Ashwin -- Ashwin Bharambe, Ph.D. Candidate, Carnegie Mellon University. Office: 412-268-7555Web: http://www.cs.cmu.edu/~ashu
Re: Separating c++ parser
On 09/12/05 15:30, Ashwin Bharambe wrote: is it possible to plug out the parser and intermediate representation code (presumably only in the front-end?) relatively easily? Not really. Though we have been re-designing the internal architecture to be more modular, all the components are meant to be used together. At most, you could plug your own transformation/analysis inside the compiler.
Re: Separating c++ parser
Hmm. Ok fine, I can live with having to keep all extraneous code lying around. But it seems like there must be a way to: - stop gcc once the cp frontend parses the code and generates the parse tree structure. - disable the stage1,stage2 compilation etc. during the build process? Or, is there something I am still missing? :) Thanks, Ashwin On 9/12/05, Diego Novillo <[EMAIL PROTECTED]> wrote: > On 09/12/05 15:30, Ashwin Bharambe wrote: > > >is it possible to plug out the parser and intermediate representation code > >(presumably only in the front-end?) relatively easily? > > > Not really. Though we have been re-designing the internal architecture > to be more modular, all the components are meant to be used together. > > At most, you could plug your own transformation/analysis inside the > compiler. > -- Ashwin Bharambe, Ph.D. Candidate, Carnegie Mellon University. Office: 412-268-7555Web: http://www.cs.cmu.edu/~ashu
Re: Separating c++ parser
You can start off by looking into how -fsyntax-only option is implemented. - fariborz On Sep 12, 2005, at 12:55 PM, Ashwin Bharambe wrote: Hmm. Ok fine, I can live with having to keep all extraneous code lying around. But it seems like there must be a way to: - stop gcc once the cp frontend parses the code and generates the parse tree structure. - disable the stage1,stage2 compilation etc. during the build process? Or, is there something I am still missing? :) Thanks, Ashwin On 9/12/05, Diego Novillo <[EMAIL PROTECTED]> wrote: On 09/12/05 15:30, Ashwin Bharambe wrote: is it possible to plug out the parser and intermediate representation code (presumably only in the front-end?) relatively easily? Not really. Though we have been re-designing the internal architecture to be more modular, all the components are meant to be used together. At most, you could plug your own transformation/analysis inside the compiler. -- Ashwin Bharambe, Ph.D. Candidate, Carnegie Mellon University. Office: 412-268-7555Web: http://www.cs.cmu.edu/~ashu
Re: Separating c++ parser
On Mon, 12 Sep 2005, Ashwin Bharambe wrote: - disable the stage1,stage2 compilation etc. during the build process? IIRC cross-compilers do not use stage1/2/3 as it is not possible to execute produced target binary on the host platform. And for compiling cross-compiler simple `make' is used. So I would recommend the same instead of `make bootstrap' Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: Separating c++ parser
On 09/12/05 15:55, Ashwin Bharambe wrote: - stop gcc once the cp frontend parses the code and generates the parse tree structure. Check -fsyntax-only. - disable the stage1,stage2 compilation etc. during the build process? just do 'make all' instead of 'make bootstrap'.
Re: software floating point & machine descriptions
Eric Fisher <[EMAIL PROTECTED]> writes: > I have to send the new mail again for the software floating point problem. > I need more details about it. 1) If I use software floating point, does I > need > implement float mode insns in md file? Such as movsf, movdf. You do have to implement movsf and movdf, yes. You do not have to implement insns for floating point operations. > 2)How to > generate correct object files of libgcc2 of floating point operations? Such > as _floatdidf. Look at, e.g., config/mips/t-mips. Ian
Re: Minimum/maximum operators are deprecated?
"Giovanni Bajo" <[EMAIL PROTECTED]> writes: > Steven Bosscher <[EMAIL PROTECTED]> wrote: > > > It was an ill-defined and poorly maintained language extension that > > was broken in many cases. > That's an overstatement. I've been using it for years without any > problem, and was very deprived by its removal, though I can > understand the "we don't want extensions" reason. But that's really > the only compelling one that prompted its removal. It's quite common that extensions "work just fine" except maybe for "a few rare cases" for some people and "are horribly broken" with "severe design flaws" for other people. This follows the 99% rule of compiler design, which is that if a design 99% works, you'll get 100% more bug reports from 1% of your users.
Adding debug symbols causes segmentation faults with GCC-4.1 and MIPS...
Greetings. I attempted to search through Bugzilla, but I did not find anything that matched my query. When using the options '-O0' and '-g' together with GCC-4.1.0, I get an executable that will segfault. If I use all the other optimizations of -O1, -O2 or -Os I do not have this problem. I am using binutils-2.16.1, a checkout of gcc-4.1 from 20050604 and uClibc. Has anyone else seen something like this? My compile and link lines look like the following: /build/buildroot-nptl-debug/build_mips/staging_dir/bin/mips-linux-uclibc-gcc -Wall -Wstrict-prototypes -O0 -mno-split-addresses -g -c clone.c -o clone.o /build/buildroot-nptl-debug/build_mips/staging_dir/bin/mips-linux-uclibc-gcc -g -Wl,-warn-common -static clone.o -o clone I can post binaries if desired. Thanks. -Steve
Re: Adding debug symbols causes segmentation faults with GCC-4.1 and MIPS...
On Sep 12, 2005, at 7:17 PM, Steven J. Hill wrote: Greetings. I attempted to search through Bugzilla, but I did not find anything that matched my query. When using the options '-O0' and '-g' together with GCC-4.1.0, I get an executable that will segfault. If I use all the other optimizations of -O1, -O2 or -Os I do not have this problem. I am using binutils-2.16.1, a checkout of gcc-4.1 from 20050604 and uClibc. Has anyone else seen something like this? My compile and link lines look like the following: /build/buildroot-nptl-debug/build_mips/staging_dir/bin/mips-linux- uclibc-gcc -Wall -Wstrict-prototypes -O0 -mno-split-addresses -g - c clone.c -o clone.o /build/buildroot-nptl-debug/build_mips/staging_dir/bin/mips-linux- uclibc-gcc -g -Wl,-warn-common -static clone.o -o clone I've not seen it, but do you see it with, say, those options and the simulator testsuite? (I don't have one built at the moment or I'd check myself.) Otherwise, what's the code look like where they segfault? -eric
Re: Adding debug symbols causes segmentation faults with GCC-4.1 and MIPS...
Eric Christopher wrote: I've not seen it, but do you see it with, say, those options and the simulator testsuite? (I don't have one built at the moment or I'd check myself.) I assume you mean using the gdb simulator, or what? Sorry for my ignorance. Otherwise, what's the code look like where they segfault? Let me quantify that and I will post a tarball tomorrow. Thanks. -Steve
Re: Adding debug symbols causes segmentation faults with GCC-4.1 and MIPS...
I assume you mean using the gdb simulator, or what? Sorry for my ignorance. Yup. Otherwise, what's the code look like where they segfault? Let me quantify that and I will post a tarball tomorrow. Thanks. OK. I don't have any mips hardware at the moment, but I should be able to help you anyhow :) -eric
Re: Adding debug symbols causes segmentation faults with GCC-4.1 and MIPS...
On Mon, Sep 12, 2005 at 09:17:57PM -0500, Steven J. Hill wrote: > I attempted to search through Bugzilla, but I did not find anything that > matched my query. When using the options '-O0' and '-g' together with > GCC-4.1.0, > I get an executable that will segfault. If I use all the other > optimizations of > -O1, -O2 or -Os I do not have this problem. While it is possible that the toolchain is at fault, it is also possible that it is a program bug. Sometimes memory corruption can look like this: if you have an uninitialized pointer, trash the heap, etc. it can have different effects depending on optimization level. Even the size of your environment can have an effect. You might want to first make sure that your program has no memory access errors. You could try building it for x86 and debugging with valgrind, to see if that catches anything.
Loop information
Can someone please help me getting the following information? 1) I would like to obtain the loop bounds (constant case) of all nested loops of a RTL insn. Is there a data structure over which I can iterate to get bounds for each nested loop of a RTL insn? 2) Is there a way of determining sequences as mentioned in the paper "Beyond Induction Variables: Detecting and Classifying Sequences Using a Demand-Driven SSA From" by Gerlek, Stoltz and Wolfe? 3) Can I determine if a pseudo register (RTX) is an induction variable (linear) or not? Which data structure gives me this information? 4) At RTL level, array accesses convert to MEM expressions. I was wondering if I can obtain the source level array name from the MEM expression. If it does not exist already, can I annotate the MEM rtl with the array name while the RTL is being generated? I am performing an analysis at RTL level which needs to know the array that I am accessing and treats them independently. Which module would I have to modify to handle this case? --R
