amihud bruchim <[EMAIL PROTECTED]> writes:
> I found a memory leak on regcomp function - gcc-4.4.2 (i used Memory
> validator tool to confirm it) .
regcomp is part of glibc (or whatever C library you are using). It is
not part of gcc. For more information, including where to report
bugs, plea
Michael Meeks <[EMAIL PROTECTED]> writes:
> Since almost all function relocations of this type are inside vtables,
> I implemented a new way of relocating vtables. This is a new
> '.suse.vtrelocs' section.
It's an interesting idea. Some comments:
* Use GNU instead of SUSE, as this is for
Michael Meeks <[EMAIL PROTECTED]> writes:
> On Wed, 2008-04-02 at 07:56 -0700, Ian Lance Taylor wrote:
>> * Use GNU instead of SUSE, as this is for the GNU tools.
>
> Ah yes; you noticed the subliminal advertising ;-) If you're happy for
> me to trample on the
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> It is not necessary that a pattern with a single constrain will have
> only one instruction in the template.
> Say if the pattern A have two instructions in the template and pattern
> B has one instruction in the template and the target has only two
>
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> Say the target has two delay slots for call instructions.
> So we can have something like this
> (define_attr "slottable" "no,yes,has_slot" (const_string "yes"))
>
> (define_delay (eq_attr "slottable" "has_slot")
> [(eq_attr "slottable" "yes") (nil)
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> On Thu, Apr 3, 2008 at 7:35 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>> "Mohamed Shafi" <[EMAIL PROTECTED]> writes:
>>
>>
>> > Say the target has two delay slots for call instr
Kai Tietz <[EMAIL PROTECTED]> writes:
> While running testsuite for target x86_64-pc-mingw32, I noticed that the
> stack segement has for this target no execution permission. May somebody
> could help me, how to avoid the use of stack based trampoline code.
> Do you know how to avoid this HJ?
F
Kenneth Zadeck <[EMAIL PROTECTED]> writes:
> in reorg.c:3155 there is the following code:
>
> /* If we reach a CALL which is not calling a const function
> or the callee pops the arguments, then give up. */
> if (CALL_P (our_prev)
> && (! CONST_OR_PURE_CALL_P (our_prev)
>
"Andrew Pinski" <[EMAIL PROTECTED]> writes:
> On Mon, Apr 7, 2008 at 10:28 AM, Robert C. Seacord <[EMAIL PROTECTED]> wrote:
>> I believe the vulnerability is that gcc may *silently* discard the overflow
>> checks and that this is a recent change in behavior.
>
> No it is not recent, unless you co
Tom Truscott <[EMAIL PROTECTED]> writes:
> Here is an unintended bug I encountered recently, hopefully the "cert"
> warning will catch this one too.
>
>int okay_to_increment (int i)
>{
> if (i + 1 < i)
> return 0; /* adding 1 would cause overflow */
> return 1;/*
FX Coudert <[EMAIL PROTECTED]> writes:
>> That's true in the US as well, but what happens later on if your
>> employer
>> comes by later on and claims you DID use employer resources? Where
>> would
>> that leave the FSF? Very few employees have deep enough pockets to
>> indemnify the FSF from th
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> Like you said i tried to split the move_immediate pattern after
> reload. This is how i did this :
>
> (define_split
> [(set (match_operand:HI 0 "register_operand" "")
> (match_operand:HI 1 "immediate_operand" ""))]
> "reload_completed"
>
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> I got few doubts regarding the way in which scheduling works in gcc 4.1.2
>
> 1. Will barrier insns gets scheduled along with other instructions?
The scheduler works over regions. It doesn't look at barriers.
> 2. When there is an unconditional jump
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> I have noticed that when strict_low_part is used in a patten we need
> to use '+' as the constraint modifier if any constraints are used in
> the patterns.
> Why is this so?
Using strict_low_part implies that the register or memory location is
neither
"Robert C. Seacord" <[EMAIL PROTECTED]> writes:
>> What you really mean is,
>> "Use an older GCC or some other compiler that is known not to
>> take advantage of this optimization."
>>
> i think we mean what we say, which is "*Avoid newer versions of gcc"
> and *"avoiding the use of gcc versio
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> I have read in the internals that indirect_jump and jump pattern are
> necessary in any back-end for the compiler to be build and work
> successfully. For any back-end there will be some limitation as to how
> big the offset used in the jump instructio
Persson Håkan <[EMAIL PROTECTED]> writes:
> I'm having problem when making apache 2.0.63.
Wrong mailing list. gcc@gcc.gnu.org is about developing gcc.
[EMAIL PROTECTED] is about using gcc.
I don't know the answer to your question. It looks specific to your
distribution.
Ian
Florian Weimer <[EMAIL PROTECTED]> writes:
>> To me, dubious optimizations like this at the very least should
>> be optional and able to be turned off.
>
> Why is this optimization dubious? We would need to look at real-world
> code to tell, and so far, we haven't heard anything about the context
Robert Dewar <[EMAIL PROTECTED]> writes:
> An optimziation is dubious to me if
>
> a) it produces surprising changes in behavior (note the importance of
> the word surprising here)
>
> b) it does not provide significant performance gains (note the
> importance of the word significant here).
>
> I
Jim Wilson <[EMAIL PROTECTED]> writes:
> It seems odd that cfgrtl allows a conditional trap inside a basic block,
> but not an unconditional trap. The way things are now, it means we need
> to fix up the basic blocks after running combine or any other pass that
> might be able to simplify a condi
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> I have the following define_insn and define_splt pattern
>
> (define_insn "movhi_const"
> [(set (match_operand:HI 0 "register_operand" "=r,r,r,r,r")
> (match_operand:HI 1 "immediate_operand" "L,K,N,O,i"))]
>
> )
>
> (define_split
> [
"John Maddock" <[EMAIL PROTECTED]> writes:
> The crux of the issue is this: if gcc/g++ is configured with the pthread
> threading model, then are object files always binary compatible irrespective
> of whether they are compiled with the -pthread command line option or not?
Yes, modulo the #define
"Rodrigo Dominguez" <[EMAIL PROTECTED]> writes:
> I am looking for information on how GCC implements Structured Exception
> Handling (try/catch) in C++ programs. I would really appreciate any pointers
> that helped me understand the internals.
gcc does not implement Structured Exception Handling
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> Ok , looking at another reply from Jim
> (http://gcc.gnu.org/ml/gcc/2008-04/msg00311.html), where he suggests
> to use shorten_branhes in reorg and generate indirect branch, it looks
> like i will have to reserve a register. Am i right?
You will ha
Tim Josling <[EMAIL PROTECTED]> writes:
> 2. Most-Gimplified front-end: Allied to Q1, which front ends have been
> most thoroughly converted to GIMPLE?
They've all been converted to generate GENERIC, or they wouldn't work.
> 3. LANG_HOOKS: There has been some discussion about LANG_HOOKS being
>
Kunal Parmar <[EMAIL PROTECTED]> writes:
> I am working on porting GCC to a new RISC architecture. The ISA does
> not have a "Jump and Link Register" instruction. So I am simulating
> one by replacing
> jal [reg]
> by
> load ra, Lret
> jr reg
> Lret:
>
> in RTL.
> But my
"Bingfeng Mei" <[EMAIL PROTECTED]> writes:
> I noticed in some cases GCC 4.3.0 produces unnecessary long long data
> type in tree ssa form. It results in inefficient 64-bit arithmetic in
> our porting.
You neglected to mention the target. I assume that pointers are
64-bits. Otherwise this beha
Kunal Parmar <[EMAIL PROTECTED]> writes:
> Is this correct :
>ret_label = gen_label_rtx ();
>emit_move_insn (gen_rtx_REG (HImode, 7),
>gen_rtx_LABEL_REF (VOIDmode,
> ret_label));
>emit_call_insn (gen_brc_call_simulate (addr, args_size));
I'm happy to report that Google approved seven applications for Summer
of Code for the gcc project. The approved applications can be found
here: http://code.google.com/soc/2008/gcc/about.html .
Ian
Kunal Parmar <[EMAIL PROTECTED]> writes:
> I am porting GCC to a new 16 bit RISC architecture which does not have
> multiplication and division instructions. I figured that I have to provide
> emulation routines for the multiplication and division which will be
> inserted into libgcc2.a. But I am
"Kunal Parmar" <[EMAIL PROTECTED]> writes:
> On Tue, Apr 22, 2008 at 1:24 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>> It depends on UNITS_PER_WORD. If UNITS_PER_WORD is 4, you need
>> __mulsi3. If UNITS_PER_WORD is 2, you need __mulhi3, and, if y
"Kunal Parmar" <[EMAIL PROTECTED]> writes:
>> Yes, I think __mulsi3 will be built for you automatically.
>
> I gave a definition of __mulhi3 for my architecture. But I don't get
> __mulsi3 in libgcc.a. Do I have to enable some options for this ?
Looking at libgcc2.h, it seems like you might need
Martin Jambor <[EMAIL PROTECTED]> writes:
> I've been rebootstrapping my switch conversion patch (which is still
> waiting for review) to make sure it still works. Unfortunately, it
> did not. The error given was the following and I believe this is the
> warning introduced by Ian as a resp
"Robert C. Seacord" <[EMAIL PROTECTED]> writes:
> The original impetus for this came from a check in a sprint() function
> from Plan 9. Because of the API, there was no way to test if the len
> was out of bounds, but the developers wanted to make sure they weren't
> wrapping the stack on some a
Tim Josling <[EMAIL PROTECTED]> writes:
> On Thu, 2008-04-17 at 10:24 -0700, Ian Lance Taylor wrote:
>> Tim Josling <[EMAIL PROTECTED]> writes:
>
>> > 5. What is deprecated: Is there any time-effective way to identify
>> > constructs, header file
"Lijuan Hai" <[EMAIL PROTECTED]> writes:
> g++ always add "-lstdc++ -lm" before any other libraries at link
> time. I want to link the libraries after libc.so. but I haven't found
> where to change the order in gcc sources. so could you provide any
> helpful hints on it? thanks in advance.
gcc/
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> For the 16-bit target that i porting now to gcc 4.1.2 doesn't have any
> branch instructions. It only has jump instructions. For comparison
> operation it has this instruction:
>
> if cond Rx Ry
> execute this insn
>
> So compare and branch is impleme
"Robert C. Seacord" <[EMAIL PROTECTED]> writes:
> Once a new version or patch is available that will warn users that
> this optimization is taking place, I will recommend that we change the
> work around from "Avoid newer versions of gcc" to "Avoid effected
> versions of gcc" and/or recommend that
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> But it would of great help if you could tell the C statment that
> actually invoked this type of pattern .. Maybe wrt some back-end?
This type of pattern is only generated by if-conversion. Look at
cond_exec_process_insns in ifcvt.c.
Ian
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> For the 16 bit target that i am currently porting can have only
> positive offsets less than 0x100. (unsigned 8 bit) for offset
> addressing mode.
I would expect reload to be able to handle this kind of thing anyhow,
assuming you define GO_IF_LEGITIMA
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> Everything starts when cleanup_subreg_operands() is called from
> reload() for the following pattern.
>
> (set (subreg:HI (mem:SI (plus:HI (reg:HI 12 [SP]) (const_int 256)) 2)
>(reg:HI 3))
I think your movhi operand predicate may have to look
[EMAIL PROTECTED] writes:
> However, for a normal goto used inside a nested function, a
> different part of gcc creates the code to store frame pointer (not
> expand_builtin_setjmp_setup). I can't find this code.
I think you are looking for expand_builtin_nonlocal_goto in
builtins.c.
Ian
[EMAIL PROTECTED] writes:
> expand_builtin_nonlocal_goto is fine. This perform stack restore,
> extracts frame pointer value and does jump.
>
> reciever is fine - this jump destination does restore of frame pointer.
>
> The problem I have is with frame pointer value that is saved in by
> "setup" p
ANTHONY APPLEYARD <[EMAIL PROTECTED]> writes:
> I have a copy of the Gnu C/C++ compiler which is of about Jan/Feb 2000
> vintage. Please where can I download a current version? I have searched
> in http://www.gnu.org and its dependent page.
See http://gcc.gnu.org/
> (0) Please where is the emai
Andrew Haley <[EMAIL PROTECTED]> writes:
> Richard Guenther wrote:
>> On Fri, May 30, 2008 at 10:57 AM, Kai Tietz <[EMAIL PROTECTED]> wrote:
>>> Hi,
>>>
>>> as I noticed, most hash value calculations are trying to use pointer
>>> values for building the value and assume that a long/unsigned long s
Andrew Haley <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor wrote:
>> Andrew Haley <[EMAIL PROTECTED]> writes:
>>
>>> Richard Guenther wrote:
>>>> On Fri, May 30, 2008 at 10:57 AM, Kai Tietz <[EMAIL PROTECTED]> wrote:
>>>>> Hi,
Chris Lattner <[EMAIL PROTECTED]> writes:
> Is there a specific reason you don't use the LLVM LTO interface? It
> seems to be roughly the same as your proposed interface:
>
> a) it has a simple C interface like your proposed one
> b) it is already implemented in one system linker (Apple's), so GC
Diego Novillo <[EMAIL PROTECTED]> writes:
I have a feeling that the comments I wrote within Google about the
linker interface were lost. I am going to try to recreate them here.
> The linker, upon start, examines a configuration file at a known
> location relative to its own location. If this f
Kenneth Zadeck <[EMAIL PROTECTED]> writes:
> I think that one thing that the gcc community should understand is
> that to a great extent whopr is a google thing. All of the documents
> are drafted by google people, in meetings that are only open to google
> people and it is only after these docu
Kenneth Zadeck <[EMAIL PROTECTED]> writes:
> In particular, there are a lot of decisions that are being made in
> whopr to support very large applications that are done so at the
> expense of compiling modest and even large applications. I do not
> necessarily disagree with these decisions, but I
Chris Lattner <[EMAIL PROTECTED]> writes:
>> * The return value of lto_module_get_symbol_attributes is not
>> defined.
>
> Ah, sorry about that. Most of the details are actually in the public
> header. The result of this function is a 'lto_symbol_attributes'
> bitmask. This should be more usef
Kenneth Zadeck <[EMAIL PROTECTED]> writes:
> I do not want to imply that google's needs are not real and that they
> should not use gcc to fulfill them. I only want to raise the point
> that whopr is at one end of a spectrum in which REAL tradeoffs are
> being made in the quality of compilation
Uros Bizjak <[EMAIL PROTECTED]> writes:
> Is there something wrong with the connection to
> sshproxy.sourceware.org [1]? The host is unreachable for a couple of
> days.
I had to change the IP address. It should be working at the new IP
address (64.13.131.149). You can wait a few more hours, or
Nick Kledzik <[EMAIL PROTECTED]> writes:
> On Jun 4, 2008, at 12:44 PM, Ian Lance Taylor wrote:
>> Chris Lattner <[EMAIL PROTECTED]> writes:
>>
>>>> * The return value of lto_module_get_symbol_attributes is not
>>>> defined.
>>>
>&g
Nick Kledzik <[EMAIL PROTECTED]> writes:
> I don't claim our current implementation is bug free, but the lto
> interface
> matches the Apple linker internal model, so we don't expect and have
> not encountered any problems mixing mach-o and llvm bitcode files.
Hmmm, OK, how about this example:
a
Nick Kledzik <[EMAIL PROTECTED]> writes:
> On Jun 4, 2008, at 5:00 PM, Ian Lance Taylor wrote:
>> Nick Kledzik <[EMAIL PROTECTED]> writes:
>>
>>> I don't claim our current implementation is bug free, but the lto
>>> interface
>>> matc
[ trimming the CC list ]
Devang Patel <[EMAIL PROTECTED]> writes:
> If the optimizer can handle the symbol versioning case when one
> definition with version is defined in the same source file as the
> reference then you don't need new API.
>
> For example,
>
> a.o : refers to S and defines S at
Nick Kledzik <[EMAIL PROTECTED]> writes:
> In this case S is a regular symbol. So the previous trick won't
> work. Probably
> the best solution would be to add a new lto_ API to tell the LTO
> engine to
> ignore a definition is already has. It would make more sense to use
> this
> new API in t
"Rafael Espindola" <[EMAIL PROTECTED]> writes:
> Interesting. The use of lto_codegen_add_must_preserve_symbol is kind
> of the opposite of what I had understood. What do you do in this case:
>
> a.o: IL file that contains a reference to "f"
> b.o: IL file that has a weak def of "f"
>
> There is no
Chris Lattner <[EMAIL PROTECTED]> writes:
> I don't know how closely your plans follow this model. If you think
> this approach is reasonable, you really do need to reflect things like
> symbol versions in your IR somehow. This compiler must know about
> versions, and when it does, it is easy to
Chris Lattner <[EMAIL PROTECTED]> writes:
> On Jun 5, 2008, at 6:51 AM, Ian Lance Taylor wrote:
>
>> Chris Lattner <[EMAIL PROTECTED]> writes:
>>
>>> I don't know how closely your plans follow this model. If you think
>>> this approach is reas
Chris Lattner <[EMAIL PROTECTED]> writes:
> LLVM LTO handles this by marking symbols "internal" (aka static, aka
> not TREE_PUBLIC, whatever) when the symbol is not visible outside the
> LTO scope. This allows the optimizers to go crazy and hack away at
> the symbols, but only when safe.
How doe
Nick Kledzik <[EMAIL PROTECTED]> writes:
>> How does the linker tell LTO that a symbol may be inlined, but must
>> also be externally visible?
> The linker just tells LTO which symbols must remain. The LTO engine
> is free to inline anything that would improve codegen, with the
> exception
> that
Chris Lattner <[EMAIL PROTECTED]> writes:
> On Jun 5, 2008, at 2:03 PM, Ian Lance Taylor wrote:
>
>> Nick Kledzik <[EMAIL PROTECTED]> writes:
>>
>>>> How does the linker tell LTO that a symbol may be inlined, but must
>>>> also be externall
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
>> You can look into config/i386.md, how i.e. adddi3 is expanded and split in
>> case of !TARGET_64BIT.
>
> But is it scheduling safe?
> I mean you can't have addc executed before add. If i am right there
> will be no dependency between the two instructi
Joern Rennecke <[EMAIL PROTECTED]> writes:
> I have been using note_stores to modify selected assignments. Now when I
> try to move this code to gcc 4.4, I find that I get a warning because
> my walker function takes a non-const rtx - and if I make it take a const rtx,
> there will be a warning s
Joern Rennecke <[EMAIL PROTECTED]> writes:
> Having another copy of note_stores seems simpler and is certainly
> more portable.
> What do you think about the name walk_stores?
Following this approach strictly leads to considerable code
duplication, which makes people unhappy. If you want to make
Alan Mackenzie <[EMAIL PROTECTED]> writes:
> I'm thinking of things like
>
> foo (a < b, c > d);
>
> I think this is unambiguously a function call with 2 parameters, the
> expressions "a < b" and "c > d". It cannot be be one with 1 parameter
> beginning with the template invocation "a < b , c
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> Alan Mackenzie <[EMAIL PROTECTED]> writes:
>
>> I'm thinking of things like
>>
>> foo (a < b, c > d);
>>
>> I think this is unambiguously a function call with 2 parameters, the
>
Volker Reichelt <[EMAIL PROTECTED]> writes:
> since Manuel's patch http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00962.html
> a lot of C++ code is now accepted on mainline (when compiling without
> special flags like -fpermissive and -pedantic), that used to be rejected.
> Instead of getting closer
Diego Novillo <[EMAIL PROTECTED]> writes:
> I just finished going through the API document adding missing content
> and updating stale information. While there are various aspects of
> GIMPLE that are not covered in the document, it is probably complete
> enough for converting/adding gimple code.
DJ Delorie <[EMAIL PROTECTED]> writes:
>> I thought DJGPP was i[34567]86-pc-msdosdjgpp*. I do not think
>> having generic CPU-*-OBJFMT triplets that really refer to a
>> particular OS is a good idea. It's only certain generic triplets
>> I'm proposing to deprecate.
>
> DJGPP is ix86-pc-msdosdjgp
Karen Shaeffer <[EMAIL PROTECTED]> writes:
> int main(int argc, char * argv[]) {
> const int ic = 0;
> const int * cip;
> int * ip;
> cip =
> ip = (int *)cip;
> *ip = 5;
> printf("const int ic = %d *cip = %d *ip = %d\n", ic, *cip, *ip);
> printf("&ic = %pcip = %pip =
Karen Shaeffer <[EMAIL PROTECTED]> writes:
> I see your point. My sticking point is that the process is actually
> running on a physical machine. And the addresses, although virtual,
> do translate to a unique physical memory location. And, the value
> stored in that location cannot be 0 and 5 at
branch is maintained by Ian Lance Taylor.
+
Architecture-specific
[ I dropped gcc-patches from this reply. ]
Diego Novillo <[EMAIL PROTECTED]> writes:
> On 6/18/08 2:01 AM, Ian Lance Taylor wrote:
>> As I promised at the summit today, I have created the branch
>> gcc-in-cxx (I originally said gcc-in-c++, but I decided that it was
>&g
"Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes:
> I read through your slides and I'm interested in contributing. I didn't
> see the presentation itself so I don't know if this suggestion is
> redundant. However I believe some work could be done (maybe even on
> mainline) to activate -Wc++-compat du
[ Dropping gcc-patches. ]
"Gabriel Dos Reis" <[EMAIL PROTECTED]> writes:
>> I have not yet committed any patches to the branch--at present it is
>> just a copy of the trunk. I will start committing patches soon, and
>> anybody else may submit patches as well. The branch will follow the
>> usual
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> Before register renaming pass, callee registers was being used in the
> body of the code. Hence function prologue saved the register and
> epilogue restored the register. But register renaming pass removed
> this particular callee saved register.The ou
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> On Thu, 19 Jun 2008, Ian Lance Taylor wrote:
>
>> Yes. I'm working around that for now by editing toplev.h, to avoid
>> pushing libcpp and libiberty to C++ right away.
>
> I'm not convinced there
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
>> Which version of gcc? I was under the impression that this
>> longstanding buglet was cleaned up by the dataflow work.
>>
>
>I am doing a port in gcc 4.1.2. The register is actually replaced
> by register copy-propagation optimization pass.
I be
Andrew Haley <[EMAIL PROTECTED]> writes:
[ Java ]
> I wonder if some compromise less than disabling it as a default everywhere
> is possible.
Is it possible to only build and test a subset of libjava by default,
and still get useful coverage of Java? The issue I see is simply that
building libj
Jens-Michael Hoffmann <[EMAIL PROTECTED]> writes:
> Am Mittwoch, 18. Juni 2008 08:01:35 schrieb Ian Lance Taylor:
>
>> I have not yet committed any patches to the branch--at present it is
>> just a copy of the trunk. I will start committing patches soon, and
>> anyb
Jens-Michael Hoffmann <[EMAIL PROTECTED]> writes:
>> No. I've flipped the branch to start compiling the source files in
>> gcc with C++. Unfortunately a number of issues will need to be
>> addressed before all the code will compile in C++. Most of this work
>> can and will be contributed back t
"Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes:
> Okay, the patch to activate -Wc++-compat is installed on mainline. I'd
> like to clean up some of the new warnings, but it sounds like you've got
> some of this already done behind the scenes. E.g.:
> http://gcc.gnu.org/ml/gcc-patches/2008-06/msg012
Paweł Sikora <[EMAIL PROTECTED]> writes:
> there's also a http://www.aei.mpg.de/~peekas/tree/ that may be useful
> for modeling abstract trees used in compiler.
Thanks. I want to be clear that the initial goal of the gcc-in-cxx
branch will be to produce code which is quite close to mainline, but
Ivan Levashew <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor пишет:
>>
>> The other major TODO is to work out the details of using STL
>> containers with GC allocated objects. This means teaching gengtype
>> how to generate code to traverse STL containers, whic
Jakub Jelinek <[EMAIL PROTECTED]> writes:
> On Sat, Jun 21, 2008 at 08:58:05PM +0200, Laurent GUERBY wrote:
>> On Sat, 2008-06-21 at 08:10 -0400, Diego Novillo wrote:
>> > On Sat, Jun 21, 2008 at 05:21, Andrew Haley <[EMAIL PROTECTED]> wrote:
>> And for make -k check:
>>
>> -j1 2h18
>> -j2 1h11
>
Laurent GUERBY <[EMAIL PROTECTED]> writes:
> I noticed insn-attrtab compilation is about 5mn20s and probably
> explain about all of the not so perfect speedup: when I look at top it
> takes more than 1 minute per stage finishing alone. I've seen it up to 3
> minutes alone. There's a comment in the
Bruno Haible <[EMAIL PROTECTED]> writes:
> A comment regarding the GCC-in-C++ idea. In slide 16 you merely answer
>
> "C++ is too complicated!"
>
> with
>
> "Maintainers will ensure that gcc continues to be maintainable."
>
> C++ has, for example, 12 different ways to represent or invoke a fun
Ben Elliston <[EMAIL PROTECTED]> writes:
> On Sun, 2008-06-22 at 07:32 -0700, Ian Lance Taylor wrote:
>
>> I think it would only be a few days of work for somebody familiar with
>> Tcl to add -j support to DejaGNU. I think that would be a very useful
>> contributio
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> This feature could not be used when executing
> programs on a target board or when using DejaGNU to drive a compiler
> running on a different host; however, that is not the common case.
To be clear, when using an embedded ta
Bruno Haible <[EMAIL PROTECTED]> writes:
> What is the level of C++ that "new developers" need to master, in order to
> understand the code in general and to fix bugs in average areas?
I don't know. I think we will have to find out.
I expect that we will find it appropriate to use STL container
Ivan Levashew <[EMAIL PROTECTED]> writes:
>> Your comment makes little sense in context. Nobody could claim that
>> the existing gengtype code is simple. Not many people understand how
>> it works at all. In order to support STL containers holding GC
>> objects, it will need to be modified.
>
>
CC'ed to Eric. This may require some configury patches somewhere.
Ian
Angelo Graziosi <[EMAIL PROTECTED]> writes:
> The point isn't that to find workarounds.
>
> The point is, so as stand the things, unless a new Cygwin 1.5.25-16
> (or 1.5.26-1 ?), the build of GFortran-trunk and friends is
> *
x z <[EMAIL PROTECTED]> writes:
> I think an important point was missed in the discussion. Some seem
> to focus on the dishonest definition of __GNUC__ by non-GNU C
> compilers. That was not my point. My point is that if __GNUC__ is
> defined by CPP, not the GNU C compiler proper, (and this see
Vincent Lefevre <[EMAIL PROTECTED]> writes:
>> But that in turn does not matter, as if any non-gcc compiler *did* use
>> the gcc preprocessor, it would do so via gcc -E. In gcc, the
>> preprocessor is not a separate program.
>
> But in any case, there's a separate preprocessor: cpp. And perhaps c
John Freeman <[EMAIL PROTECTED]> writes:
> This is something I look into periodically, and each time I find a
> solution that's slightly better, but not what I want. I've looked at
> the wiki (http://gcc.gnu.org/wiki/DebuggingGCC) many times, so no need
> to refer me there. I am trying to debug
John Freeman <[EMAIL PROTECTED]> writes:
>> You need to configure with --disable-bootstrap if you want the C++
>> frontend built in "stage1". Also try make all-gcc instead (or just make
>> to also build the runtime).
>>
>
> I think this method is different in ways that will increase the build
> t
"Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes:
> 2008-07-03 Kaveh R. Ghazi <[EMAIL PROTECTED]>
>
> * alloc-pool.c (hash_descriptor, eq_descriptor,
> alloc_pool_descriptor): Fix -Wc++-compat warnings.
> * bitmap.c (hash_descriptor, eq_descriptor, bitmap_descriptor):
> Likewi
2701 - 2800 of 3176 matches
Mail list logo
