Michael Veksler <[EMAIL PROTECTED]> writes:
> I would like to find how to force gcc (and its optimizers):
>
>1. Not to move stuff across in_profiler=* assignments, for all
> optimizers. This was measured to skew profiling by 10-20% on x86
> Linux, and more than x2 on tiny functio
FX Coudert <[EMAIL PROTECTED]> writes:
> > Now I learned that there are currently no Fortran developers signed
> > up as SoC mentors for GCC. It would be really great if someone with
> > a decent knowledge of gfortran would be willing to be my mentor, so
> > I can work on this project. This really
Aldy Hernandez <[EMAIL PROTECTED]> writes:
> After doing the GIMPLE_MODIFY_STMT work, I've come to the conlusion that
> to continue overloading trees will be more work in the long run than doing the
> actual separation between tuples and trees. This business of "this is
> a tree, but not really",
"Andrew Pinski" <[EMAIL PROTECTED]> writes:
> On 29 Mar 2007 18:24:56 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> > Why will expressions have location? It seems to me preferable to save
> > the memory. After a few optimization passes many of the ex
Mayank Kumar <[EMAIL PROTECTED]> writes:
> 1: I am keen on understanding how does the offset of L32 from
> _GLOBAL_OFFSET_TABLE_ generated ? I mean if assembly is
>
> Movl [EMAIL PROTECTED](%ebx,%eax),%eax then how does is gets converted to mov
> 0xbd14(%eax,%ebx,1),%eax. I guessed that L3
"Andrew Pinski" <[EMAIL PROTECTED]> writes:
> Maybe one of the MIPS maintainers can explain why this option exists
> in the first place.
> As far as I can tell this has option has existed before the egcs/gcc
> split. I still say the back-end should not worry about this and
> divide by zero should
Mayank Kumar <[EMAIL PROTECTED]> writes:
> For Movl [EMAIL PROTECTED](%ebx,%eax),%eax > mov
> 0xbd14(%eax,%ebx,1),%eax
>
> I verified that data contained in .rdata section is all wrong in my case with
> both my gcc3.3 compiler as well gcc4.3 compiler.
> This is why the jump happens
Alexander Kabaev <[EMAIL PROTECTED]> writes:
> I also noticed that on Linux glibc implements some of the libgcc
> symbols, namely _Unwind_Find_FDE and __register_frame_info_bases family
> of functions. I wonder why it is done and if I missed something obvious
> here.
It seems to have to do with s
Matt Thomas <[EMAIL PROTECTED]> writes:
> Over the past several weeks, I've revamped the VAX backend:
>
> - fixed various bugs
> - improved 64bit move, add, subtract code.
> - added patterns for ffs, bswap16, bswap32, sync_lock_test_and_set,
> and
> sync_lock_release
> - modified it t
Zdenek Dvorak <[EMAIL PROTECTED]> writes:
> Proposal:
>
> For each memory reference, we remember the following information:
>
> -- base of the reference
> -- constant offset
> -- vector of indices
> -- type of the accessed location
> -- original tree of the memory reference (or another summary o
"Rob Quill" <[EMAIL PROTECTED]> writes:
> My problem is thus: When using GDB do debug the follow bit of code:
>
> int i = 0;
> int j = 2;
> int k = 3;
>
> If I set a breakpoint at the 3rd line, before int k = 3; has been
> executed, and check if k is in scope, I find that it is, when, of
> cours
"J.C. Pizarro" <[EMAIL PROTECTED]> writes:
> To optimize even more the x86, it still has to use:
> 1. Use imul instead of mul because it's little bit faster in cycles.
> 2. Use jns/js (sign's conditional jump) instead of jnc/jc (carry's
> conditional jump).
> 3. To modify the C-preprocessor and/or
Diego Novillo <[EMAIL PROTECTED]> writes:
> J.C. Pizarro wrote on 04/10/07 02:08:
>
> > However, they've appeared the "conditional moves" to don't jump
> > and consecuently to reduce the penalization of the conditional jump.
>
> We already have conditional moves. Notice that subcodes for GS_ASS
"J.C. Pizarro" <[EMAIL PROTECTED]> writes:
> /* Given X an unsigned of 32 bits, and Y a bool. Try to translate optimizing
> *
> * Y = X > 2147483647; to Y = ((signed)X) < 0;
> * Y = X >= 2147483648; to Y = ((signed)X) < 0;
> *
> * [ Another optimization is to Y = (X >> 31) ]
As far
Diego Novillo <[EMAIL PROTECTED]> writes:
> Following up on the recent discussion about GIMPLE tuples
> (http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html), we have summarized
> our main ideas and implementation proposal in the attached document.
>
> This should be enough to get the implementation
Diego Novillo <[EMAIL PROTECTED]> writes:
> Following up on the recent discussion about GIMPLE tuples
> (http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html), we have summarized
> our main ideas and implementation proposal in the attached document.
>
> This should be enough to get the implementation
Mike Stump <[EMAIL PROTECTED]> writes:
> On Apr 10, 2007, at 10:53 AM, Ian Lance Taylor wrote:
> > I seem to recall that at one point somebody worked on a gensimplify
> > program or something like that. Would it make sense to revive that
> > approach, and use it to gen
Richard Henderson <[EMAIL PROTECTED]> writes:
> On Tue, Apr 10, 2007 at 10:53:19AM -0700, Ian Lance Taylor wrote:
> > As you know, we have a lot of basic optimizations in fold-const.c that
> > operatee on trees. We also have a lot of basic optimizations in
> > simplif
"Rohit Arul Raj" <[EMAIL PROTECTED]> writes:
> I had a single movsf insn that accepts all alternatives for the reload to
> work.
>
> (define_insn "movsf"
> [(set (match_operand:SF 0 "nonimmediate_operand" "=f,m,f,f,d,d")
>(match_operand:SF 1 "general_operand" "m,f,f,d,f,i"))
>
A reminder. This will happen next week.
Several gcc developers are presenting at the Gelato conference in San
Jose this April. Google is inviting them and all other interested
parties to a gcc mini-summit at Google's Mountain View campus. The
mini-summit will be on Wednesday, April 18, in Googl
Paolo Bonzini <[EMAIL PROTECTED]> writes:
> > (define_insn "adddi3_internal_1"
> > [(set (match_operand:DI 0 "register_operand" "=d,&d")
> > (plus:DI (match_operand:DI 1 "register_operand" "0,d")
> > (match_operand:DI 2 "register_operand" "d,d")))
> >(clobber (match_
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> Depending on the machine mode the compiler will generate automatically
> the offset required for the stack operation i.e for a machine with
> word size is 32, for char type the offset is 1, for int type the
> offset is 2 and so on..
>
> Is there a way
"Paulo J. Matos" <[EMAIL PROTECTED]> writes:
> Is that any reference (paper, guide, whatever,) on how gcc is handling
> exceptions in intermediate code? Is it based on a known (published)
> method? Is it intuitive and explained somewhere?
I doubt it. But if you pull together some information, it
"Rohit Arul Raj" <[EMAIL PROTECTED]> writes:
> 1. In DIE for fun, with 3.4.6, the frame base is taken in terms of
> Frame Pointer (DW_OP_reg14), where is in 4.1.1, it is taken in terms
> of Stack Pointer (DW_OP_reg15).
>
> (For my backend, reg-no 14 is Frame Pointer and reg-no 15 is Stack Pointer
Dennis Weyland <[EMAIL PROTECTED]> writes:
> It's a pity that the application process has finished for some
> days... I was very motivated and have really good skills regarding
> efficient algorithms, complexity theory and compiler construction, but
> with not being accepted I would not have enoug
[ I sent this reply before I realized that Dennis also send the note
to [EMAIL PROTECTED] Dennis, sorry for the repeat. ]
Dennis Weyland <[EMAIL PROTECTED]> writes:
> That means GOOGLE did not approve my application? I thought it was
> GCC. How can I get to know why they did not approve me? As
Bernd Schmidt <[EMAIL PROTECTED]> writes:
> It would be nice to eliminate REG_NO_CONFLICT altogether, but a quick
> experiment with the i386 port showed that this idea is a non-starter
> for now (i386 still has insns operating on DImode, hence in some
> functions not all DImode registers get lower
Paolo Bonzini <[EMAIL PROTECTED]> writes:
> > I suppose we could add a target macro to let individual ports turn
> > off REG_NO_CONFLICT generation? Any other ideas?
>
> A pass to reorder insns so that live ranges are shortened and register
> pressure is relieved.
I think you could do this with
Dennis Weyland <[EMAIL PROTECTED]> writes:
> I was a little bit disappointed that the first reply on this newsgroup
> took so long. I just wanted to know which problems can be tackled and
> completed in the SoC timeframe...
> And i wonder why i only got 2 responses in the last two weeks in
> contr
Dennis Weyland <[EMAIL PROTECTED]> writes:
> I was a little bit disappointed that the first reply on this newsgroup
> took so long. I just wanted to know which problems can be tackled and
> completed in the SoC timeframe...
> And i wonder why i only got 2 responses in the last two weeks in
> contr
Kenneth Hoste <[EMAIL PROTECTED]> writes:
> * When using -falign-loops or -fno-align-loops the corresponding
> internal variable 'align-loops' should be set to 0 (= use default
> setting) or 1 (= no aligning) resp. When parsing the various flags, a
> variable 'value' is used to set (value=1) or un
Eric Weddington <[EMAIL PROTECTED]> writes:
> "Also, as you mention the target code has a chance to tune this ..., can you
> give me a hint about
> where to look for these knobs? I might give it a try to see whether I
> can find a more optimal set of parameters."
>
> This was in response to your
Joerg Wunsch <[EMAIL PROTECTED]> writes:
> As Ian Lance Taylor wrote:
>
> > If the code size increases for AVR, when using -Os, when comparing an
> > older release to mainline or 4.2 branch, you should report that as a
> > regression in bugzilla. Thanks.
&g
"Dave Korn" <[EMAIL PROTECTED]> writes:
> Sorry for butting in, but I just can't follow the reasoning here. Unless a
> function is only ever used once and is inlined at the single callsite, or
> unless the prolog and epilog are several times the size of the function body,
> isn't inlining /alwa
We held a GCC mini-summit at Google on Wednesday, April 18. About 40
people came. This is my very brief summary of what we talked about.
Corrections and additions very welcome.
The goal of the mini-summit was just to let gcc developers meet face
to face and talk. There was no goal of actually m
Kenneth Hoste <[EMAIL PROTECTED]> writes:
> A related question: how is decided which priority a bug gets?
In general the release manager, Mark Mitchell, sets the priorities of
bugs in the bug database. He follows general guidelines where
wrong-code is more important, primary platforms are more i
Richard Sandiford <[EMAIL PROTECTED]> writes:
> I realise no-one else has spoken out in support of me, so perhaps
> I'm in a minority of one here. But it does seem to me that in the
> Tree-SSA world, it makes less sense to duplicate standard optabs
> in the backend purely for the reason of keepin
Richard Sandiford <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > Richard Sandiford <[EMAIL PROTECTED]> writes:
> >> I realise no-one else has spoken out in support of me, so perhaps
> >> I'm in a minority of one h
"Dave Korn" <[EMAIL PROTECTED]> writes:
> Although I'm seeing this on 3.3.3, it appears to be determined by the
> backend, so I think it's still reasonable to ask:
>
> I have some code that calls __builtin_ffs, but entirely on compile-time
> constants. When I compile it (using an inhouse cus
Paul Brook <[EMAIL PROTECTED]> writes:
> > > .file ""
> > > foo.global _ffs
> >
> > Is this really a reference? It just looks like a declaration. A
> > typical ELF assembler will not generate an undefined symbol merely
> > because it sees a .global pseudo-op.
>
> I think gas 2.17
Rask Ingemann Lambertsen <[EMAIL PROTECTED]> writes:
> I just got
>
> /home/rask/cvssrc/gcc/gcc/testsuite/gcc.c-torture/compile/complex-3.c:17:
> error: unrecognizable insn:
> (insn 69 67 70 5 (set (mem:SC (pre_dec:HI (reg/f:HI 12 sp)) [0 S8 A8])
> (concat:SC (reg:SF 36)
> (re
Joerg Wunsch <[EMAIL PROTECTED]> writes:
> What's that test suite that has been mentioned here, and how to run
> it?
http://www.inf.u-szeged.hu/csibe/
Ian
"Sjodin, Jan" <[EMAIL PROTECTED]> writes:
> Hi I am new to GCC development and I have a few questions about LTO.
> What has been done since the last status report in January? I would
> also like to know what is most important to work on right now to make
> progress on LTO (e.g. type system, int
"Aaron W. LaFramboise" <[EMAIL PROTECTED]> writes:
> I discovered PR29365 today while testing 4.2.0 RC2 on a client's
> codebase. This causes some of my code, based on the popular pimpl
> idiom, to generate warnings, even with no warning flags specified. If
> there's a way to turn it off without
"anshul goel" <[EMAIL PROTECTED]> writes:
> i am not getting in which file tokens are generated in c - gcc.
> Please send me file name with complete path , as soon as possible.
Please do not send e-mail to both [EMAIL PROTECTED] and
[EMAIL PROTECTED] This kind of question is appropriate for
As originally proposed here:
http://gcc.gnu.org/ml/gcc/2005-01/msg00031.html
I propose switching the ChangeLogs to use year-based names rather than
numeric indexes.
Specifically, I propose adding these files:
ChangeLog-1997: from last part of ChangeLog.0
ChangeLog-1998: from first part of Ch
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> On Sun, 6 Mar 2005, Ian Lance Taylor wrote:
>
> > look at the ChangeLog for the appropriate year. This is also how some
> > other GNU programs organize their ChangeLog files, including libhava
> > and libs
Zack Weinberg <[EMAIL PROTECTED]> writes:
> So, the plan: Step 1 introduces - one at a time - target hooks
> corresponding to each of the above macros. All callers are changed to
> use the hooks. The default definitions of the hooks invoke the
> existing macros. The hardest part of this is work
As noted in PR 14316, collect2 doesn't build on Windows due to the use
of vfork. There have been at least two patches to address this, one
of them from me, one from Zack.
My patch is here:
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01445.html
Zack had some comments:
http://gcc.gnu.org/m
"E. Weddington" <[EMAIL PROTECTED]> writes:
> Thanks for taking a look at this again. A solution is badly needed.
> Would this be targeted for 4.0, perhaps?
No promises from me on that front. Let's get it into mainline first.
After it is working on mainline, it would be reasonable to propose
mo
Zack Weinberg <[EMAIL PROTECTED]> writes:
> The interface looks sound to me with one exception: it's not safe to
> conflate !-pipe with -save-temps, because that opens up the
> possibility of a tempfile race -- if an attacker sees that the
> compiler is producing /tmp/ccQWERTY.s, then they should
James E Wilson <[EMAIL PROTECTED]> writes:
> On Fri, 2005-03-11 at 16:01, Joe Buck wrote:
> > [EMAIL PROTECTED] works just as well, since it's the same machine by
> > a different name. On this list we should be advertising the gcc.gnu.org
> > name, I think.
>
> True. But if you want to look at
James E Wilson <[EMAIL PROTECTED]> writes:
> On Fri, 2005-03-11 at 17:48, Ian Lance Taylor wrote:
> > All true, but I want to note that the preferred non-GNU name is
> > sourceware.org.
>
> What about the trademark status? Last I heard, the trademark holder had
> a
Miles Bader <[EMAIL PROTECTED]> writes:
> I've defined SECONDARY_*_RELOAD_CLASS (and PREFERRED_* to try to help
> things along), and am now running into more understandable reload
> problems: "unable to find a register to spill in class" :-/
>
> The problem, as I understand, is that reload does
We would like to eliminate cc0 and the associated machinery from the
compiler, because it is complicated and not supported on popular or
modern processors. Here is a plan which I think could accomplish that
without unreasonable effort.
1) Modify the programs which read the .md file to look for an
[EMAIL PROTECTED] (Richard Kenner) writes:
> 3) Write a new optimization pass enabled on targets which define
>NOTICE_UPDATE_CC. I think this pass would be run just before
>machine dependent reorg, although perhaps there is a better place
>for it. Walk through the ins
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> >2a) Define the clobbercc attribute to be "yes" for each insn which
> >changes the condition codes unpredictably. Typically the
> >default would be "yes", and then either clobbercc would be
> >written to use cond to select
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> On Mar 23, 2005, Ian Lance Taylor wrote:
>
> > Of course, correctly modeling the effect on the condition codes
> > really means putting the information in the RTL so that it is
> > exposed to the RTL optimizers.
>
Ian Lance Taylor writes:
> Looking at your suggestion makes me realize that my suggestion is too
> complicated. It's not necessary to generate the combinatorial
> explosion at all. We can always keep cc0 setters and cc0 users in
> separate instructions. The key is to keep
OK, here is a different approach toward eliminating cc0, based on a
combination of my earlier proposal and what Alex described. I'm
looking for comments from anybody.
1) Modify the programs which read the .md file to look for an
attribute named clobbercc. If such an attribute exists, then for
Richard Henderson <[EMAIL PROTECTED]> writes:
> Note that there's no longer any insn that *sets* cc_reg. I think
> that's a bit dangerous.
Hmmm, good point.
> One solution to this is to convert the new setter to
>
> [(set (reg 1) (plus (reg 1) (reg 2)))
>(set (reg cc_reg) (unspe
Zack Weinberg <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor writes:
>
> > 3) Write a new CC0 collapse pass. This pass is run immediately
> > after RTL expansion. It walks the instruction stream looking for
> > instructions which set and use CC_REG. At this poi
<[EMAIL PROTECTED]> writes:
> It will generate a lot of redundant moves to/from the accumulator because
> the accumulator is exposed much too late.
>
> Consider the 3AC code:
>
> add i,j,k
> add k,l,m
>
> it will be broken down into:
>
> mov i,a
> add j,a
> mov a,k
> mov k,a
> add l,a
> mov a,
Paul Schlie <[EMAIL PROTECTED]> writes:
> Does GCC truley need to identify/treat condition state registers uniquely
> from any other value produced as a result of a calculation?
No, it doesn't. The change I am proposing removes the unique handling
of condition state registers, and treats them li
Paul Schlie <[EMAIL PROTECTED]> writes:
> Is there any convenient way to reference the newly set register by an
> instruction, as opposed to otherwise needing to redundantly re-specify
> the operation producing it's value again?
>
> Thereby enabling something like:
>
> (insn xxx [(set (reg: A) (
"Aaron W. LaFramboise" <[EMAIL PROTECTED]> writes:
> This is due to this code:
>
> #if !HAVE_DECL_GETOPT
> #if defined (__GNU_LIBRARY__) || defined (HAVE_DECL_GETOPT)
> /* Many other libraries have conflicting prototypes for getopt, with
>differences in the consts, in unistd.h. To avoid comp
Paul Schlie <[EMAIL PROTECTED]> writes:
> > 1) Many of the optimizers analyze instructions by first calling
> >single_set and working with the results of that. For example,
> >combine won't work with any insn for which single_set returns NULL.
> >And single_set will normally return NU
BjÃrn Haase <[EMAIL PROTECTED]> writes:
> Imagine, you are having a clean md with a consistent "double set"
> representation for all the patterns that actually alter the condition code. I
> understood, that the problem for the optimization passes (e.g. combine) then
> shows up only for instruct
Paul Schlie <[EMAIL PROTECTED]> writes:
> I presume that "code" can/should be optimally generated once by initially
> optimally covering the rtl representing a basic block (with minimal cost
> in either storage, cycles or some hybrid of both); where there's then no
> need to ever subsequen
Paul Schlie <[EMAIL PROTECTED]> writes:
> Might this likely work? And if so, possibly be worthy of consideration to
> enable the more efficient description and optimization of traditional cc0
> target machines (and possibly be beneficial for other ISA's as well)?
It seems like it might work to m
Rajkishore Barik <[EMAIL PROTECTED]> writes:
> Can someone tell me why are the "REG_VALUE_PROFILE" notes
> dropped in "combine.c"? I am using these notes to carry some values to
> back-end (reg-alloc)
> and it seems to get lost somewhere. "combine.c" looked to me as the
> potential place.
When
Hans-Peter Nilsson <[EMAIL PROTECTED]> writes:
> > 4) For each target which uses cc0:
> ...
> >4b) For insn patterns for which some alternatives clobber CC and
> >some do not, split the instruction after reload into one
> >variant which clobbers the CC and one variant which doe
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> The following is from libibtery.h
>
>/* HAVE_DECL_* is a three-state macro: undefined, 0 or 1. If it is
> undefined, we haven't run the autoconf check so provide the
> declaration without arguments. If it is 0, we checked and failed
Richard Sandiford <[EMAIL PROTECTED]> writes:
> Huh. For the record: it can't. get_attr_length() returns 0
> for ADDR_VECs regardless of JUMP_IN_TEXT_SECTION. I'll update
> the comment when applying the bug-fix patch to mainline.
shorten_branches handles JUMP_TABLES_IN_TEXT_SECTION correctly.
Mark Mitchell <[EMAIL PROTECTED]> writes:
> If you are willing to help, please download the release candidate,
> build it on appropriate platforms, and post testresults by using
> contrib/test_summary. Please use the release candidate itself, *not*
> the CVS 4.0 release branch, as part of the goa
Richard Sandiford <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor writes:
> > Richard Sandiford <[EMAIL PROTECTED]> writes:
> >> Huh. For the record: it can't. get_attr_length() returns 0
> >> for ADDR_VECs regardless of JUMP_IN_TEXT_SECTION. I'
Peter Barada <[EMAIL PROTECTED]> writes:
> This is driving me up a tree. I have a fix for 18421(on mainline &
> gcc-3.4.3) that uses HARD_REGNO_MODE_OK to prevent bytes into address
> registers, and modified movqi for ColdFire to drop the '*a' in
> d*a/di*a constraint, as well as modified addsi3_
Peter Barada <[EMAIL PROTECTED]> writes:
> Which debugging dump has the output from "local-alloc"? If its
> pp_pack.c.24.lreg, then that is the output I supplied in the original
> message which contains(for all bits regarding register 1420 up until
> the compilation fails):
Sorry, guess I missed
Peter Barada <[EMAIL PROTECTED]> writes:
> >So register 1420 is being assigned to a data register. The
> >constraints for addsi3_5200 permit the following alternatives:
> >mem += datareg
> >addrreg = addrreg + reg|constant
> >addrreg = reg|constant + addrreg
> >reg += mem|reg|cons
Peter Barada <[EMAIL PROTECTED]> writes:
> >> The problem is that there is no valid QImode instruction that can move
> >> values in/out of an address register
> >
> >I know. I'm suggesting that QImode values have to move in and out of
> >address registers via data registers, so you just put t
Sachin Vijay Sonawane <[EMAIL PROTECTED]> writes:
> In .md file, while writing Function-unit specifications, we have to
> define an attribute called "simultaneity". I am still confused to get
> the correct meaning it. Can anyone plz elaborate on it? I have found
> the following definition from G
Peter Barada <[EMAIL PROTECTED]> writes:
> I've got a "Using and Porting GNU CC" manual for rev 2.95, and am
> looking around for a newer one and can't find it anywhere. Does
> anyone know if a newer printed manual is available(and if so, where I
> can find it)?
At the risk of stating the dreadf
Ãystein Johansen <[EMAIL PROTECTED]> writes:
> As I have written in an earlier post here, I'm trying to vectorize
> some loops with intrinsics and I have also got a gcc 4.1 snapshot
> (20050410). However when I try to compile my code with the gcc-4.1
> snapshot I get:
>
> /msys/1.0/home/mingw/bin
The description of tcc_statement in tree.h says "A statement
expression, which have side effects but usually no interesting value."
There are a number of entries in cp/cp-tree.def which are marked as
tcc_expression, although they seem to me to be better described as
tcc_statement, to wit:
IF_STMT
Matt Thomas <[EMAIL PROTECTED]> writes:
> Running the libstdc++ testsuite on NetBSD/sparc or NetBSD/sparc64
> results in most tests failing like:
>
> :1: fatal error: had to relocate PCH
> compilation terminated.
> compiler exited with status 1
>
> This is due to a misassumption in ggc-common.c:
Rajkishore Barik <[EMAIL PROTECTED]> writes:
> > Hmm, let me rephrase your question:
> > "I did some GCC hacking that I'm not showing, and it doesn't work,
> > please help me fix it."
>
> This is not what I meant. I meant if similar problem has been reported by
> anyone else before.
Everybody w
Matt Thomas <[EMAIL PROTECTED]> writes:
> I have a 50MHz 68060 with 96MB of memory (MVME177) approaching 100 hours
> (48 hours just to exit stage3 and start on the libraries) doing a bootstrap
> knowing that it's going to die when doing the ranlib of libjava. The kernel
> for the 060 isn't config
Andrew Haley <[EMAIL PROTECTED]> writes:
> If ld can't accept a list of files from a stream but is instead
> limited by command line length, then that *is* the fault of ld.
GNU ld won't currently read a list of files from stdin, but it will
read a list of files from a file.
For example, look at
Matt Thomas <[EMAIL PROTECTED]> writes:
> When I see the native stage2 m68k compiler spend 30+ minutes compute bound
> with no paging activity compiling a single source file, I believe
> that is an accurate term. Compiling stage3 on a 50MHz 68060 took 18 hours.
> (That 30 minutes was for fold-con
Andrew Haley <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor writes:
> >
> > And, yes, we clearly need to do something about the libjava build.
>
> OK, I know nothing about libtool so this might not be possible, but
> IMO the easiest way of making a dramatic diffe
Andreas Schwab <[EMAIL PROTECTED]> writes:
> > Try putting
> >
> > enable_shared=no
> >
> > in configure.ac somewhere before AC_PROG_LIBTOOL.
>
> I think you rather want AC_DISABLE_STATIC.
Even better. Thanks.
Ian
Jason Thorpe <[EMAIL PROTECTED]> writes:
> Except it's not just bootstrapping GCC. It's everything. When the
> NetBSD Project switched from 2.95.3 to 3.3, we had a noticeably
> increase in time to do the "daily" builds because the 3.3 compiler
> was so much slower at compiling the same OS source
Andrew Haley <[EMAIL PROTECTED]> writes:
> > >> OK, I know nothing about libtool so this might not be possible, but
> > >> IMO the easiest way of making a dramatic difference is to cease to
> > >> compile every file twice, once with PIC and once without. There would
> > >> be a small performa
Andrew Haley <[EMAIL PROTECTED]> writes:
> That's not the problem I have: the link is slow, but it's not the
> dominant thing. Maybe it depends how much RAM you have? I have 1 Gbyte.
Probably. I pay for my own machines, and it's three years old, and I
have 256M.
Ian
Joe Buck <[EMAIL PROTECTED]> writes:
> I think you need to talk to the binutils people. It should be possible
> to make ar and ld more memory-efficient.
And here I thought I had dug myself out of that swamp several years
ago. I once spent a month making the linker more memory efficient,
includi
R Lokesh babu <[EMAIL PROTECTED]> writes:
> My application (COMMERCIAL SOFTWARE) links to
> libstdc++, By default Solaris OS
> does not install the libstdc++ package
> (libgcc-3.3-sol9-sparc-local.gz).
> Can I re-distribute the lib-gcc package and install it
> along with my application
> installat
Andrew Walrond <[EMAIL PROTECTED]> writes:
> If I have a gcc configured for i686-* target system and I use that compiler
> to
> build a package without any -m submodel options , is the generated code
> 1) only suitable for i686 and better, or
> 2) tuned for i686 and better but still OK for i38
Diego Novillo <[EMAIL PROTECTED]> writes:
> GENERIC
> GOMP_PARALLEL
>
> GIMPLE
> GOMP_PARALLEL
> L1:
> g_body
> L2:
I personally find it kind of baffling to have the same tree code act
differently in GENERIC and GIMPLE, a la SWITCH_EXPR. It seems to add
c
Diego Novillo <[EMAIL PROTECTED]> writes:
> > I personally find it kind of baffling to have the same tree code act
> > differently in GENERIC and GIMPLE, a la SWITCH_EXPR. It seems to add
> > confusion for minimal benefit. If you are suggesting that the single
> > tree code GOMP_PARALLEL have di
Joe Buck <[EMAIL PROTECTED]> writes:
> So the basic issue is this: why the hell does the linker need so much
> memory? Sure, if you have tons available, it pays to trade memory for
> time, mmap everything, then build all the hashes you want to look up
> relationships in every direction. But if i
301 - 400 of 3176 matches
Mail list logo
