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
> 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
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
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? :) :)
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 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
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
"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
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)
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
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, 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
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
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
"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
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
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
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
> -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
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
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
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
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
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
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
> "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
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
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
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
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
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.
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
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
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
> 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
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
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
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
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
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
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
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
> 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
44 matches
Mail list logo
