Ieraksts kādas brīnišķīgas sievietes dienasgrāmatā:
Otrdiena.
Es piecēlos ar sūrstošu sajūtu kājstarpē. Apjautu kaut ko līdzīgu tukšumam
sevī.
Man savajadzējās krānu. Lielu, stingru un kārdinošu. Ļoti gribējās šim loceklim
uzsēsties.
Es to nodarīju: http://www.klep.us
"Kamble, Nitin A" writes:
> Is there any information on when next releases of gcc are planned to be
> released ?
Only guesses.
Why do you ask?
Ian
Hi there,
Is there any information on when next releases of gcc are planned to be
released ?
Thanks,
Nitin
Yoctoproject.otg
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> gccad...@gcc.gnu.org
> Sent: Friday, April 01, 2011 4:01 PM
> To:
Hi,
I'm sending this email describing the set of patches also to the gcc
mailing list because quite a few people do not follow the gcc-patches
mailing list (where I am sending the individual patches).
The patch set changes the interface of call graph and tries to avoid
lazy call graph node creati
On Wed, 6 Apr 2011, Paul Koning wrote:
> On Apr 6, 2011, at 4:56 PM, Joseph S. Myers wrote:
>
> > On Wed, 6 Apr 2011, Paul Koning wrote:
> >
> >> In i386-gcc 4.5.1, --target-help says that "generic32" and "generic64"
> >> are valid values for -march= and -mtune. In fact, those values are
> >>
On Apr 6, 2011, at 4:56 PM, Joseph S. Myers wrote:
> On Wed, 6 Apr 2011, Paul Koning wrote:
>
>> In i386-gcc 4.5.1, --target-help says that "generic32" and "generic64"
>> are valid values for -march= and -mtune. In fact, those values are
>> rejected (even though there seems to be code in i386
On Wed, 6 Apr 2011, Paul Koning wrote:
> In i386-gcc 4.5.1, --target-help says that "generic32" and "generic64"
> are valid values for -march= and -mtune. In fact, those values are
> rejected (even though there seems to be code in i386.c to handle those
> values).
See PR 45731. This is help
In i386-gcc 4.5.1, --target-help says that "generic32" and "generic64" are
valid values for -march= and -mtune. In fact, those values are rejected (even
though there seems to be code in i386.c to handle those values).
paul
On Wed, 6 Apr 2011, Basile Starynkevitch wrote:
> On Wed, 6 Apr 2011 20:49:32 +0500
> "Levon Haykazyan" wrote:
> > Thank you for your answer. I though I should ask GSoC related questions
> > here. Anyhow, I am interested, and for me that's enough to implement it.
> > But I decided to write the en
On Wed, 06 Apr 2011 19:07:26 +
"Levon Haykazyan" wrote:
[citing me Basile]
> >
> > You probably could write the front-end part of your compiler in Oberon,
> > and generate Gimple representation (perhaps even in textual form, since
> > some people are working on a Gimple "front-end"). You then
> - Original Message -
> From: Basile Starynkevitch
> To: "Levon Haykazyan"
> Cc: "Ian Lance Taylor" , gcc@gcc.gnu.org
> Subject: Re: Oberon-2 front-end as a GSoC project
> Date: Wed, 6 Apr 2011 18:57:00 +0200
>
>
> On Wed, 6 Apr 2011 20:49:32 +0500
> "Levon Haykazyan" wrote:
> > Than
"Levon Haykazyan" writes:
>> "Levon Haykazyan" writes:
>>
>> > Since I didn't get much feedback, I concluded that this idea does not
>> > interest anybody. So I will not pursue this any further.
>>
>> To be honest, you are asking the wrong set of people. Today, gcc does
>> not support Oberon-
On Wed, 6 Apr 2011 20:49:32 +0500
"Levon Haykazyan" wrote:
> Thank you for your answer. I though I should ask GSoC related questions
> here. Anyhow, I am interested, and for me that's enough to implement it.
> But I decided to write the entire compiler from scratch. I couldn't
> resist writing a c
> - Original Message -
> From: Ian Lance Taylor
> To: "Levon Haykazyan"
> Cc: gcc@gcc.gnu.org
> Subject: Re: Oberon-2 front-end as a GSoC project
> Date: Wed, 06 Apr 2011 06:25:34 -0700
>
>
> "Levon Haykazyan" writes:
>
> > Since I didn't get much feedback, I concluded that this idea
On 04/06/2011 05:08 PM, Richard Earnshaw wrote:
>
> On Tue, 2011-04-05 at 15:34 +0200, Sebastian Huber wrote:
[...]
>> The EABI makes the VFP floating point architecture mandatory and enables us
>> to
>> use hardware floating point support in the future. RTEMS has currently no
>> support for har
On Tue, 2011-04-05 at 15:34 +0200, Sebastian Huber wrote:
> Hello,
>
> there were several requests for ARM Cortex-M support on RTEMS recently. The
> first step towards this is a suitable ARM tool chain. I want to use this
> event
> to clean up the multilibs and switch to the EABI version 5. T
On Wed, Apr 6, 2011 at 7:48 AM, Richard Earnshaw wrote:
>
> On Tue, 2011-04-05 at 08:26 +0200, Steven Bosscher wrote:
>> On Tue, Apr 5, 2011 at 3:14 AM, Bernd Schmidt
>> wrote:
>>
>> > For i686-linux bootstraps it's hard to argue against it, but in general
>> > I find it easier to cope with the
On Wed, Apr 6, 2011 at 7:45 AM, Richard Earnshaw wrote:
>
> On Tue, 2011-04-05 at 08:58 -0600, Jeff Law wrote:
>> And what precisely does "immediately" mean in this context? 1 hour, 3
>> hours? If the breakage happens on a Friday evening, does the
>> developer
>> have until Monday morning to at
On Tue, 2011-04-05 at 08:26 +0200, Steven Bosscher wrote:
> On Tue, Apr 5, 2011 at 3:14 AM, Bernd Schmidt wrote:
>
> > For i686-linux bootstraps it's hard to argue against it, but in general
> > I find it easier to cope with the occasional broken tree than with
> > getting patches reverted when
On Tue, 2011-04-05 at 08:58 -0600, Jeff Law wrote:
> And what precisely does "immediately" mean in this context? 1 hour, 3
> hours? If the breakage happens on a Friday evening, does the
> developer
> have until Monday morning to at least take a looksie?
I don't think developers should be comm
"Levon Haykazyan" writes:
> Since I didn't get much feedback, I concluded that this idea does not
> interest anybody. So I will not pursue this any further.
To be honest, you are asking the wrong set of people. Today, gcc does
not support Oberon-2. So the people who develop gcc today are not v
Richard Sandiford schrieb:
> Georg-Johann Lay writes:
>> With new versions of gcc from trunk (like last snapshot SVN 171894), I
>> observe very bad code from register allocator.
>
> Could you check whether:
>
> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02053.html
>
> fixes the problem?
> - Original Message -
> From: "Levon Haykazyan"
> To: gcc@gcc.gnu.org
> Subject: Oberon-2 front-end as a GSoC project
> Date: Sun, 3 Apr 2011 15:01:08 +0500
>
>
> Hi all,
>
> I want to propose to implement Oberon-2 front-end to gcc on GSoC. I know
> that Oberon-2 is not the most popul
On Wed, Apr 6, 2011 at 1:30 AM, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 04/05/11 16:49, DJ Delorie wrote:
>>> What type of *proof* would you accept?
>>>
>>> o Bisecting the commit history until it doesn't fail any more?
>>
>> That isn't even *evidence* that the pat
Hello David,
did you solve the problem of reverse endian of data ? if so, I am interested
to have some knowledge.
I am new in these arena. Would you please give me some suggestion regarding
this?
-Konica
David Brown-4 wrote:
>
> Would it be possible to use the named address space syntax to
25 matches
Mail list logo
