> Kai Tietz wrote:
>
> > See
> > http://www.nabble.com/-PING%5E2-PATCH-%3A-Preparations-for-SYSV-MS-ABI-attributes-in-backend-tf4414541.html
> > http://www.nabble.com/-PATCH-%3A-Implementation-for-SYSV-MS-ABI-attributes-in-i386-may-before-stage--3-tf4428449.html
>
> Thanks for letting me know. I
Lijuan Hai wrote:
Maybe you would find what you want at the following URL:
http://www.sun.com/download/products.xml?id=46448222
gccfss means 'GCC for SPARC System'
2007/9/12, Andrew Walrond <[EMAIL PROTECTED]>:
I have to make buying decisions, and having tested a Sun T1000 for a
while I am
On 9/12/07, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Tehila asked me a while ago to comment based on my experience with the
> RTL if convert pass and the discussions some of us had at the GCC
> summit. Sorry it took me so long to respond.
>
> The target I care about (Cell SPU) has some thing
From: Sunil Amitkumar Janki <[EMAIL PROTECTED]>
Date: Thu, 13 Sep 2007 11:16:00 +0200
> As far as I know, GCC for SPARC appears to be a front end
> to the Sun Studio compiler which happens to translate GCC
> flags to ones suitable for their own compiler.
That's correct, it's essentially GCC's lan
Would you like to work online from home and get paid weekly? Himage Holding
Ltd, Kowloon, Hong Kong.
Needs a book keeper, so we want to know if you will like to work online from
home and get paid weekly without leaving or affecting your present job? Himage
Holding Ltd., Kowloon, Hong Kong is an
Hi,
On Wed, 12 Sep 2007, [EMAIL PROTECTED] wrote:
> I haven't looked at the tree-SSA if-convert code yet, but based on what
> was described to me at the summit it seemed to be taking the same
> approach as the RTL pass. Recognize certain patterns and convert it.
>
> I would like to see an app
David Miller wrote:
>
> That's correct, it's essentially GCC's language front ends
> plugged into Sun's compiler backend.
> -
And presumably is solaris only doesn't work under gnu/linux?
Andrew Walrond
David Miller wrote:
>
> So no, Sun really isn't helping with any actual development.
>
Sun have some sort of deal with Ubuntu to support the Niagara, don't
they? Presumably the Canonical people have some developers working on
(and contributing to) the (sparc64) gnu toolchain and linux kernel as
> Sun have some sort of deal with Ubuntu to support the Niagara, don't
> they? Presumably the Canonical people have some developers working on
> (and contributing to) the (sparc64) gnu toolchain and linux kernel as
> part of that deal?
There have been essentially no contributions to the SPARC tool
Andrew Walrond wrote:
> David Miller wrote:
>> That's correct, it's essentially GCC's language front ends
>> plugged into Sun's compiler backend.
>> -
>
> And presumably is solaris only doesn't work under gnu/linux?
>
Sorry; that is thinko/typo/horrible. What I actually meant:
Presumably the gc
Andrew Walrond wrote:
Andrew Walrond wrote:
David Miller wrote:
That's correct, it's essentially GCC's language front ends
plugged into Sun's compiler backend.
-
And presumably is solaris only doesn't work under gnu/linux?
Sorry; that is thinko/typo/horrible. What I actu
Hello,
I looked at an inefficient code sequence for a simple program using
GCC's picochip port (not yet submitted to mainline). Basically, a
program like
long carray[10];
void fn (long c, int i)
{
carray[i] = c;
}
produces good assembly code. But, if i were to do
struct complex16
{
int re,i
Sunil Amitkumar Janki wrote:
GCC for SPARC is a front end to this compiler, which isn't available
for Linux/SPARC so not really useful at all. If Sun Studio were available
for GNU/Linux SPARC this front end would probably function the same as
on Solaris, maybe even without any changes at all.
Chris Newport wrote:
Sunil Amitkumar Janki wrote:
GCC for SPARC is a front end to this compiler, which isn't available
for Linux/SPARC so not really useful at all. If Sun Studio were
available
for GNU/Linux SPARC this front end would probably function the same as
on Solaris, maybe even witho
Is there any chance for a --march / --mcpu pair for intel core(duo)?
I'm currently running gentoo linux on a first generation mac book pro
equipped with a intel coreduo processor. Gentoo installation guide
states that --march=prescot is the best choice for my cpu.
But there are also some guides st
René Köcher wrote:
> Is there any chance for a --march / --mcpu pair for intel core(duo)?
>
> I'm currently running gentoo linux on a first generation mac book pro
> equipped with a intel coreduo processor. Gentoo installation guide
> states that --march=prescot is the best choice for my cpu.
> Bu
Eric Botcazou wrote:
>
> There have been essentially no contributions to the SPARC toolchain by Sun or
> Canonical people over the last few years.
>
So, Sun really _don't_ give a damn about gnu/linux on sparc64.
What a shame; for the first time in years they have a CPU which is
competitive (fo
I am porting gcc to a new architecture, and have yet another problem
that I've been staring at for far too long now.
Whenever I compile a program that calls malloc, GCC crashes with:
/cygdrive/c/home/risc/src/gcc-4.1.2/gcc/unwind-dw2-fde.c: In function
'__register_frame':
/cygdrive/c/home/risc/sr
> "Ollie" == Ollie Wild <[EMAIL PROTECTED]> writes:
Ollie> One quick question. When I updated the gcc info page, Mark
Ollie> Mitchell felt strongly that it shouldn't mention distcc or
Ollie> ccache directly. However, I think it's a good idea to give
Ollie> users some idea what the option is
Mark Mitchell wrote:
When I sent out the notice about GCC 4.2.2 RC1, I failed to note the GCC
4.2 branch should now be considered slushy; please get my explicit
approval before check-in. Obviously, there was no way anyone could have
known that, so if things have been checked in since the announc
Bob Wilson wrote:
> Mark Mitchell wrote:
>> When I sent out the notice about GCC 4.2.2 RC1, I failed to note the GCC
>> 4.2 branch should now be considered slushy; please get my explicit
>> approval before check-in. Obviously, there was no way anyone could have
>> known that, so if things have bee
Michael Meissner wrote:
> One patch that got dropped on the floor was my patch to remove the dependency
> in the back ends of the way arguments are encoded, so that eventually for LTO
> we can swtich to using a vector instead of linked list.
I think that could still goto 4.3, since it's already
Ramana Radhakrishnan wrote:
> I have a couple of patches that I submitted / intend to submit . One
> of them was submitted today regarding a small improvement to the
> auto-increment pass. I am not sure if this is suitable for stage3 if
> it is approved.
>
> http://gcc.gnu.org/ml/gcc-patches/2007
Jan Hubicka wrote:
>> Kai Tietz wrote:
>>
>>> See
>>> http://www.nabble.com/-PING%5E2-PATCH-%3A-Preparations-for-SYSV-MS-ABI-attributes-in-backend-tf4414541.html
>>> http://www.nabble.com/-PATCH-%3A-Implementation-for-SYSV-MS-ABI-attributes-in-i386-may-before-stage--3-tf4428449.html
>> Thanks for l
On Thu, Sep 13, 2007 at 10:45:56AM +0200, Jan Hubicka wrote:
> > Kai Tietz wrote:
> >
> > > See
> > > http://www.nabble.com/-PING%5E2-PATCH-%3A-Preparations-for-SYSV-MS-ABI-attributes-in-backend-tf4414541.html
> > > http://www.nabble.com/-PATCH-%3A-Implementation-for-SYSV-MS-ABI-attributes-in-i386
> -Original Message-
> From: Mark Mitchell [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 13, 2007 2:37 PM
> To: Meissner, Michael; Mark Mitchell; GCC
> Subject: Re: GCC 4.3.0 Status Report (2007-09-04)
>
> Michael Meissner wrote:
>
> > One patch that got dropped on the floor was m
Meissner, Michael wrote:
> I didn't hear back from you, so I checked in the machine independent and
> i386 parts in my SSE5 patch. Now, on to making the various ports still
> work with the change.
All right; sounds good.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
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?
> Note that the parameter is being written to the frame in the last 2
> instru
René Köcher <[EMAIL PROTECTED]> writes:
> Is there any chance for a --march / --mcpu pair for intel core(duo)?
It's there in the development sources. -march=core2.
It will be in the gcc 4.3.0 release.
Ian
"Tomas Svensson" <[EMAIL PROTECTED]> writes:
> I am porting gcc to a new architecture, and have yet another problem
> that I've been staring at for far too long now.
>
> Whenever I compile a program that calls malloc, GCC crashes with:
>
> /cygdrive/c/home/risc/src/gcc-4.1.2/gcc/unwind-dw2-fde.c
From: Andrew Walrond <[EMAIL PROTECTED]>
Date: Thu, 13 Sep 2007 15:02:08 +0100
> So, Sun really _don't_ give a damn about gnu/linux on sparc64.
That is a gross mischaracterization of the situation, don't
say this, it isn't true at all.
I have a full rack of Niagara systems that proves that Sun
c
On Thu, 13 Sep 2007, Michael Meissner wrote:
> In the first patch, I am somewhat uncomfortable with changing RETURN_IN_MEMORY
> and OUTGOING_REG_PARM_STACK_SPACE, by adding an additional parameter, and then
> changing all of the targets. It might be better to have new macros
> (RETURN_IN_MEMORY_A
On 9/13/07, Tom Tromey <[EMAIL PROTECTED]> wrote:
> > "Ollie" == Ollie Wild <[EMAIL PROTECTED]> writes:
>
> Ollie> One quick question. When I updated the gcc info page, Mark
> Ollie> Mitchell felt strongly that it shouldn't mention distcc or
> Ollie> ccache directly. However, I think it's a g
Ollie Wild wrote:
> On 9/13/07, Tom Tromey <[EMAIL PROTECTED]> wrote:
>>> "Ollie" == Ollie Wild <[EMAIL PROTECTED]> writes:
>> Ollie> One quick question. When I updated the gcc info page, Mark
>> Ollie> Mitchell felt strongly that it shouldn't mention distcc or
>> Ollie> ccache directly. Howe
On 9/13/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> I wouldn't characterize my objections as terribly strong. It's
> certainly nothing against distcc or ccache. But, I think these kinds of
> mentions are odd to put in our documentation. The manual should say
> what the options do. Referenci
On 9/7/07, Chris Lattner <[EMAIL PROTECTED]> wrote:
> It is unclear whether this is safe. Nothing in the standard AFAIK
> requires the operator new be implemented in terms of malloc, and
> users are allowed to override it.
I was looking for something else in the standard and found this (5.3.4/7)
"Andrew Pinski" <[EMAIL PROTECTED]> writes:
| On 9/7/07, Chris Lattner <[EMAIL PROTECTED]> wrote:
|
| > It is unclear whether this is safe. Nothing in the standard AFAIK
| > requires the operator new be implemented in terms of malloc, and
| > users are allowed to override it.
|
| I was looking
Ian Lance Taylor wrote:
> René Köcher <[EMAIL PROTECTED]> writes:
>
>> Is there any chance for a --march / --mcpu pair for intel core(duo)?
>
> It's there in the development sources. -march=core2.
>
> It will be in the gcc 4.3.0 release.
>
Could OP be assured that it won't do anything incompa
On 13 Sep 2007 19:37:27 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
> Do you believe that allocator is prohibited by the C++ standard?
Yes just because it points to another object at that point.
Now people do these tricks, I know but I guess most of them don't
understand C++ that much to k
On Thu, 13 Sep 2007, Andrew Pinski wrote:
| On 13 Sep 2007 19:37:27 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
| > Do you believe that allocator is prohibited by the C++ standard?
|
| Yes just because it points to another object at that point.
I'm afraid that is too dense for me. Please
On 9/13/07, David Miller <[EMAIL PROTECTED]> wrote:
> I have a full rack of Niagara systems that proves that Sun
Can I have one? :) :)
David Miller wrote:
> From: Andrew Walrond <[EMAIL PROTECTED]>
> Date: Thu, 13 Sep 2007 15:02:08 +0100
>
>> So, Sun really _don't_ give a damn about gnu/linux on sparc64.
>
> That is a gross mischaracterization of the situation, don't
> say this, it isn't true at all.
>
> I have a full rack of N
> That is a gross mischaracterization of the situation, don't
> say this, it isn't true at all.
>
> I have a full rack of Niagara systems that proves that Sun
> cares to some extent.
Right, and I should have said "essentially no direct contributions" to the
SPARC toolchain from Sun. There have b
Andrew Walrond wrote:
David Miller wrote:
From: Andrew Walrond <[EMAIL PROTECTED]>
Date: Thu, 13 Sep 2007 15:02:08 +0100
So, Sun really _don't_ give a damn about gnu/linux on sparc64.
That is a gross mischaracterization of the situation, don't
say this, it isn't true at all.
I have a full ra
44 matches
Mail list logo
