On Thu, Aug 11, 2005 at 11:27:42PM +0100, Nix wrote:
> On 10 Aug 2005, H. J. Lu said:
> > + /* SSE is the part of 64bit. Only need to check it for 32bit. */
>
> Grammar nit: this should probably be
>
> + /* All 64-bit targets have SSE; only check it explicitly for 32-bit ones.
> */
>
> or s
Snapshot gcc-4.0-20050811 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050811/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 CVS branch
with the following options: -rgcc-ss-4_0-20050811
You'll
On 10 Aug 2005, H. J. Lu said:
> + /* SSE is the part of 64bit. Only need to check it for 32bit. */
Grammar nit: this should probably be
+ /* All 64-bit targets have SSE; only check it explicitly for 32-bit ones. */
or something like that.
> + : "i" (0x0020));
> + if (((eax
Could you please check what's going on there? Is this a general problem
with gcc-gnats processing or a problem parsing that particular message?
Dunno. Grepping mail logs older than an hour takes a while on
sourceware, because they are large. Can you resend it and notify me when
you do?
gc
On Thu, Aug 11, 2005 at 08:12:57AM +0800, Ling-hua Tseng wrote:
> I used the automata based pipeline description for my ports,
> I described the data latency time by `define_insn_reservation',
> and I'm trying to insert the "nop" in the hook
> TARGET_MACHINE_DEPENDENT_REORG.
It is possible to emi
Andrew Haley wrote:
Tom Tromey writes:
> I was under the impression that CHAR_TYPE was deprecated, so I
> purposely avoided it in gcjx. I'm not sure where I got that
> impression though.
I can't remember the context either, but I agree with your memory. I
think it was discussed a little whil
> Hmm. You know, I probably should just steal the code from DJGPP...
You could, if you feel like weeding out all the DPMI calls and dos-isms ;-)
It's in DJGPP's src/libc/dos/process/dosexec.c. Search for
"script_exec".
On Wed, Aug 10, 2005 at 05:30:03PM -0400, DJ Delorie wrote:
>> Well, it's stopping a real fix for the MinGW build failure being made.
>> Adding #! support to libiberty won't work because the problem scripts
>> have MSYS/Cygwin paths for the shell (eg. "/bin/sh") that aren't likely
>> to be valid to
Fariborz is having trouble with his mailer and has asked me to forward his response.
On Aug 10, 2005, at 2:35 PM, Dale Johannesen wrote:
On Aug 10, 2005, at 12:43 PM, Fariborz Jahanian wrote:
Following patch has exposed an optimization shortcoming:
2005-07-12 Dale Johannesen <[EMAIL PROTECTED]>
Ling-hua Tseng wrote:
> I'm porting gcc 4.0.1 to a new VLIW architecture.
> Some of its function units doesn't have internal hardware pipeline
> forwarding,
> so I need to insert "nop" instructions in order to resovle the data
> hazard.
>
> I used the automata based pipeline description for my por
Hi,
PR22543 has a testcase in which we fail with:
error: definition in block 1 does not dominate use in block 3
for SSA_NAME: SFT.3_39 in statement:
# VUSE ;
lsm_tmp.35_36 = D.2625.j;
In this testcase block 3 is a loop exit block, and block 1 is a loop header
block. During vectorization th
I figured out that the insn_latency(insn1, insn2) is always returning a
constant value in any states
(i.e., it's a static value, not be determined dynamically).
It seems to cost much time complexity if I impelemented the `nop inserting' in
the reorg pass.
Because the `nop inserting' algorithm ma
Wu Zhou <[EMAIL PROTECTED]> writes:
> I am reading <> and found two typoes. Here is a patch to
> fix them.
Thanks! I've applied it under the obviously-correct rule after testing
with "make dvi" and "make info".
> Is this the correct mail-list for this kind of patch. Thanks.
Not quite: there's
"Ling-hua Tseng" <[EMAIL PROTECTED]> writes:
> The destination operand of the `sub' instruction, d0, will be written
> back in the 4th cycle, and the instruction `max' will use it as source
> operand (i.e., there is a true data dependency).
>
> I figured out that the state_transition() returns -1 w
Tom Tromey writes:
> > "Jim" == James E Wilson <[EMAIL PROTECTED]> writes:
>
> Jim> Java uses CHAR_TYPE. So Ada would not be the only supported language
> Jim> using it if you switched to it.
>
> I was under the impression that CHAR_TYPE was deprecated, so I
> purposely avoided it in
Mark Mitchell <[EMAIL PROTECTED]> writes:
> We've had this entire discussion before, and as far as I can tell,
> there's agreement-in-principle: you build things, install them in a
> staging area, and then copy/reinstall into a final location when you're
> done.
Sorry, I didn't think of that. No
Jim,
Thank you for your answer !
James E Wilson ([EMAIL PROTECTED]):
> I think it would be better if the language front ends switched to using
> CHAR_TYPE for character types. Otherwise the debug output routines need
> a lot of code to tell which integer types are actually character types,
>
Hello Maintainers,
I am reading <> and found two typoes. Here is a patch to
fix them. Is this the correct mail-list for this kind of patch. Thanks.
Index: doc/rtl.texi
===
RCS file: /cvsroot/gcc/gcc/gcc/doc/rtl.texi,v
retrieving
18 matches
Mail list logo
