On 07/13/2010 12:20 PM, Mingming Sun wrote:
On Tue, Jul 13, 2010 at 12:17 PM, Jie Zhang wrote:
On 07/13/2010 11:56 AM, Mingming Sun wrote:
I want to submit a patch about loongson 3A, a new architecture
different from loongson 2E&2F.
My patch is based on Gcc4.4.0.
If I want to submit my pat
Do you mean I must submit it to the main brach?
On Tue, Jul 13, 2010 at 12:17 PM, Jie Zhang wrote:
> On 07/13/2010 11:56 AM, Mingming Sun wrote:
>>
>> Hi,
>>
>> I want to submit a patch about loongson 3A, a new architecture
>> different from loongson 2E& 2F.
>> My patch is based on Gcc4.4.0.
>>
On 07/13/2010 11:56 AM, Mingming Sun wrote:
Hi,
I want to submit a patch about loongson 3A, a new architecture
different from loongson 2E& 2F.
My patch is based on Gcc4.4.0.
If I want to submit my patch, which branch shoud I submit to, gcc4.4.0
branch or I should change the patch to
suite with
Hi,
I want to submit a patch about loongson 3A, a new architecture
different from loongson 2E & 2F.
My patch is based on Gcc4.4.0.
If I want to submit my patch, which branch shoud I submit to, gcc4.4.0
branch or I should change the patch to
suite with the main branch.
Thanks,
Mingming Sun
I got this when trying to access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44921
Software error:
Can't rename data/versioncache.Xg5KN to versioncache at globals.pl line 306.
For help, please send mail to the webmaster (sourcemas...@sourceware.org),
giving this error message and the time an
33 minutes to 39 second? that sounds a drastic improvement.
The performance improvement is also amazing.
You can try to divide your program into subphases and measure
the biggest change in time and then focus on parts that contribute
to the most improvement. Sometimes it is can be done quickly
Hello,
I did a quick search on "gcc internal" document and cannot find any
explanation about the field meaning of struct tree_type. I am trying to use
typedef to introduce some new aggregrate types that my gcc can handle. And I
want to mark these types so that I can handle these types sp
I am looking at PR 44787 where IA64 HP-UX (in 32 bit mode) is failing to
compile this test case:
class e {
public:
e(void* __e);
e(const e&);
};
void * v() { }
e foo() { return e(v()); }
This test dies trying to copy an SImode register to a DImode register
and emit_move_ins
Richard Earnshaw wrote:
>> Why not fix this? For example, it could also give back configure
>> options (--with-float=hard) that should be implicitly assumed to have
>> been provided.
>
> That would be useful for GCC perhaps, but not for other projects that
> use config.guess (which is part of th
> > It really does seem like a hack to use triplets in this way; I think
> > Paul's point that anything that depends on the toolchain triplet to
> > determine ABI is inherently busted is pretty persuasive.
>
> Which means the whole GNU way of doing this has always been busted,
> since that's essen
On Mon, 2010-07-12 at 09:19 -0700, Mark Mitchell wrote:
> Richard Earnshaw wrote:
>
> > The reason why a new triplet is required is that config.guess needs to
> > generate it when running native. Config.guess is the only way to
> > communicate the information needed for a native compiler when no
Richard Earnshaw wrote:
> The reason why a new triplet is required is that config.guess needs to
> generate it when running native. Config.guess is the only way to
> communicate the information needed for a native compiler when no other
> information is communicated on the command line, and it on
> .../configure --prefix=...
>
> must build a native compiler that conforms to the native ABI of the
> machine.
By my reading at least ppc, mips and sparc allow the default ABI to be changed
via --with-float, but none of them have a separate target triplet for this
purpose.
> > It's wort
On 12/07/10 15:51, Richard Earnshaw wrote:
if we could turn back the clock, I'd even prefer
arm-linux_gnu_hf_eabi to get back to a single '-'-parsed OS string, but
the linux-gnu stuff is now entrenched, so trying to change back would only
cause more disruption.
quadruplets, quintuplets and eve
On Mon, 2010-07-12 at 16:03 +0100, Paul Brook wrote:
> > Both Linaro and Debian are considering supporting the ARM hard-float
> > variant of the EABI, at least as an unofficial port. This ABI is not
> > compatible with the gnueabi currently in use for most ARM Linux distros,
> > but has a number o
> Both Linaro and Debian are considering supporting the ARM hard-float
> variant of the EABI, at least as an unofficial port. This ABI is not
> compatible with the gnueabi currently in use for most ARM Linux distros,
> but has a number of performance advantages.
>
> This means that we need to choo
On Mon, 2010-07-12 at 10:23 -0400, Joern Rennecke wrote:
> Quoting Andrew Stubbs :
>
> > Hi All,
>
> Hi, long time no see...
>
> > So here are my suggestions:
> >
> > arm-linux-gnueabihf
> >or maybe
> > arm-linux-gnueabi-hf
>
> I don't like the inflation of dashes - it breaks scripts t
> So my next question is what support is there in the various formats,
> technologies and runtime libraries to provide a backwards compatible
> solution, such that a binary from one system when put on another can
> have any hardware incompatibilities detected at the soonest opportunity,
> for examp
Quoting Andrew Stubbs :
Hi All,
Hi, long time no see...
So here are my suggestions:
arm-linux-gnueabihf
or maybe
arm-linux-gnueabi-hf
I don't like the inflation of dashes - it breaks scripts that want to
parse the host triplet / quadruplet (IMO having a quadruplets was already
a st
Hi All,
Both Linaro and Debian are considering supporting the ARM hard-float
variant of the EABI, at least as an unofficial port. This ABI is not
compatible with the gnueabi currently in use for most ARM Linux distros,
but has a number of performance advantages.
This means that we need to ch
>
> Is there a document or standard (or group of standards) that define the
> collective ABIs of GNU/Linux systems using ELF binary formats of various
> CPU architectures, including at least:
> IA32 (i386/i686/AMD64/EMT64/etc...)
> ARM (v5, v5t, v7, etc...)
x86_64 ABI is at www.x86-64.org/do
Is there a document or standard (or group of standards) that define the
collective ABIs of GNU/Linux systems using ELF binary formats of various
CPU architectures, including at least:
IA32 (i386/i686/AMD64/EMT64/etc...)
ARM (v5, v5t, v7, etc...)
What is the policy of the GNU toolchain, does
Sean Hunt writes:
> On 07/10/2010 03:56 PM, Ian Lance Taylor wrote:
>> Sean Hunt writes:
>>
>>> void foo () __attribute__((noreturn)); // right per spec
>>> void foo __attribute__((noreturn)) (); // works
>>> __attribute__((noreturn)) void foo (); // works
>>>
>>> It's obvious tha
Uros Bizjak schrieb:
> Hello!
>
> During the macroization of x86 RTX patterns, it became clear that
> certain patterns can't be macroized due to mode-dependant (const_int
> N) RTXes, where the value of X depends on current mode. As an example,
> here are two insn patterns from i386/i386.md:
>
> (
24 matches
Mail list logo
