Michiel de Bondt wrote:
Using strings to show my point was not a good idea. You can add a field
"int number" to the struct and perform similar operations (with =
instead of strcpy).
But even with strings, gcc should give an error like: "strcpy(const
char*, const char*) does not exists". In c
For quite some time now, I've been getting bootstrap comparison
failures with trunk on sparc64/sparc linux
I kind of guess that they might be related to other big endian
bootstrap comparison failures. Would you benefit from me posting
something specific from my failures or do you suggest that
Ian Lance Taylor wrote:
Hariharan Sandanagobalane <[EMAIL PROTECTED]> writes:
I looked at an inefficient code sequence for a simple program using
GCC's picochip port (not yet submitted to mainline).
Are you working with mainline sources?
I was not. I tried the same with gcc 4.3 branch and
On 19 Sep 2007 07:54:14 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> gcse will never convert a recognizable insn into an unrecognizable
> insn.
Ok. Do you know of any other reasons why this particular optimization
switch would cause this problem?
> You still haven't showed us the actual i
On 20 September 2007 20:30, Peter A. Felvegi wrote:
> i'd like to hear your comments.
Is va_list a typedef for char* on your system, then? What ever happened to
it being an alias for __builtin_va_list via __gnuc_va_list?
cheers,
DaveK
--
Can't think of a witty .sigline today
>> i'd like to hear your comments.
>
> Is va_list a typedef for char* on your system, then? What ever happened to
> it being an alias for __builtin_va_list via __gnuc_va_list?
i don't know what happened, but it seems like a char*. my system is a
debian i636 etch, here are compiler versions:
$
On Fri, Sep 21, 2007 at 04:53:38PM +0200, Tomas Svensson wrote:
> (define_expand "bleu"
> [(use (match_operand 0 "" ""))]
> ""
> "expand_branch (LEU, operands[0]); DONE;")
>
> which is heavily inspired by the or32 port of version 3.4.4, as is
> expand_branch().
> But this should not need a ma
On Tue, Sep 18, 2007 at 12:54:17PM +0200, Tomas Svensson wrote:
>
> I have looked at it in gdb and it fails on reaching the
> gcc_unreachable() in add_clobbers, which happens because add_clobbers
> is called (at combine.c:9576) with an insn_code_number that it does
> not recognize.
Odd, since
In http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01702.html I describe
tools to generate sets of GCC command-line options used to find
combinations that don't work together. Using those tools and a setup
to build and run (with short test input) individual tests from SPEC
CPU2000, I've found the fol
On 9/21/07, Janis Johnson <[EMAIL PROTECTED]> wrote:
> # gap, gcc, vortex run fails; -m64
> -fpack-struct
> # eon build fails with (valid?) error; -m32/-m64
> -fpack-struct
These above failures are kinda of expected as -fpack-struct does change the ABI.
Thanks,
Andrew Pinski
Snapshot gcc-4.3-20070921 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070921/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Tomas Svensson wrote:
On 19 Sep 2007 07:54:14 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
gcse will never convert a recognizable insn into an unrecognizable
insn.
Ok. Do you know of any other reasons why this particular optimization
switch would cause this problem?
There are millions o
12 matches
Mail list logo
