On Jul 19, 2010, at 1:57 PM, Tom Tromey wrote:
> Dave> But yes, OP, it's a long-term project.
>
> Apple implemented fix-and-continue in their toolchain. They spoke about
> it a little bit on the gdb list, it is in the archives. My take-away
> was that the feature is a lot of work for not muc
> "Dave" == Dave Korn writes:
Dave> I think you're probably assuming too much. Tom T. is working on an
Dave> incremental compiler, isn't he?
I was, but I was asked to work on gdb a couple of years ago, so that
work is suspended.
Dave> But yes, OP, it's a long-term project.
Apple impleme
On Sun, Jul 18, 2010 at 14:37, Ian Lance Taylor wrote:
> This idea is related to Tom Tromey's incremental compiler work
> (http://gcc.gnu.org/wiki/IncrementalCompiler) and to Per Bothner's
> compiler server work
> (http://per.bothner.com/papers/GccSummit03-slides/index.html). Neither
> project i
Rick,
You are seeking perfection while I am suggesting a technique that
doesn't capture all
cases but is useful:
1) change only the body of a function
2) compile the new function into a shared library which the
debugger dlopen's
into the target process.
3) replace the entr
Tim Prince wrote:
On 7/19/2010 4:13 PM, IceColdBeer wrote:
Hi,
I'm building a project using GNU gcc, but the command line used to build
each source file sometimes exceeds 8191 characters, which is the maximum
supported command line length under Win XP.Even worst under Win 2000,
where the ma
On 7/19/2010 4:13 PM, IceColdBeer wrote:
Hi,
I'm building a project using GNU gcc, but the command line used to build
each source file sometimes exceeds 8191 characters, which is the maximum
supported command line length under Win XP.Even worst under Win 2000,
where the maximum command line
Hi,
I'm building a project using GNU gcc, but the command line used to build
each source file sometimes exceeds 8191 characters, which is the maximum
supported command line length under Win XP.Even worst under Win 2000,
where the maximum command line length is limited to 2047 characters.
Can
On Mon, Jul 19, 2010 at 11:12 AM, Ian Lance Taylor wrote:
> "Amker.Cheng" writes:
>
>> I found although there are standard pattern names such as "ceilm2/floorm2",
>> there is no insn pattern in mips.md for such float insns on mips target.
>> further more, there is no ceil/floor rtl code in rtl.
Hi.
Thank you for the modified patch.
I have applied the patch to gcc-4.5 sources and checking the regression
for SH[1234].
I will run some more tests on the modified (patched) toolchain.
I will share the test results after the regression and other tests are
complete.
Regards,
Naveen
"Amker.Cheng" writes:
> I found although there are standard pattern names such as "ceilm2/floorm2",
> there is no insn pattern in mips.md for such float insns on mips target.
> further more, there is no ceil/floor rtl code in rtl.def either.
>
> based on these facts, I assuming those float insn
It's "just" a warning, no "real" affects seen.
I patched my copy to say
hwi = ((hwi >> (shift - 1)) >> 1);
Thanks,
- Jay
> From: i...@google.com
> To: jay.kr...@cornell.edu
> CC: gcc@gcc.gnu.org
> Subject: Re: suggest assert wide_int larger than hashva
Hi:
I found although there are standard pattern names such as "ceilm2/floorm2",
there is no insn pattern in mips.md for such float insns on mips target.
further more, there is no ceil/floor rtl code in rtl.def either.
based on these facts, I assuming those float insns are not supported by gcc,
b
Jay K writes:
> I get this in 4.3.5:
>
> ../../gcc/gcc/varasm.c: In function `const_rtx_hash_1':
> ../../gcc/gcc/varasm.c:3387: warning: right shift count >= width of type
>
> ./include/hashtab.h:typedef unsigned int hashval_t;
>
> unsigned HOST_WIDE_INT hwi;
> hashval_t h, *hp;
> ...
>
Hm, it seems on some 32bit systems, where there is no -m64, wideint can be a
mere 32bits.
In which case the code should probably say:
hwi = ((hwi >> (shift - 1)) >> 1);
This was targeting OpenBSD/x86.
Maybe I should just stick need_64bit_hwint = yes on config.gcc for that and
move along?
Assu
14 matches
Mail list logo
