On Sat, 12 Jul 2008, Gerald Pfeifer wrote:
> Hi Joseph,
>
> On Fri, 4 Jul 2008, Joseph S. Myers wrote:
> > The GCC 4.1 branch is now closed and should have no further commits. All
> > open bugs at the 4.1.3 milestone, or marked as [4.1/4.2/4.3/4.4
> > Regression] or similar, have been updated
Hi Joseph,
On Fri, 4 Jul 2008, Joseph S. Myers wrote:
> The GCC 4.1 branch is now closed and should have no further commits. All
> open bugs at the 4.1.3 milestone, or marked as [4.1/4.2/4.3/4.4
> Regression] or similar, have been updated accordingly.
I wonder, could/should this also become a
On Wed, 28 May 2008, Joe Buck wrote:
> > Ah. Then the DATESTAMP change shouldn't happen if there is no
> > modification to the branch since the last DATESTAMP.
On Thu, May 29, 2008 at 11:48:31PM +, Joseph S. Myers wrote:
> The snapshots know nothing of whether there were any changes on the b
On Wed, 28 May 2008, Joe Buck wrote:
> On Wed, May 28, 2008 at 08:15:20PM +0200, Richard Guenther wrote:
> > On Wed, May 28, 2008 at 7:13 PM, Joe Buck <[EMAIL PROTECTED]> wrote:
> > > On Tue, May 27, 2008 at 09:11:18PM -0400, NightStrike wrote:
> > >> On 5/27/08, Joe Buck <[EMAIL PROTECTED]> wrote
On Wed, May 28, 2008 at 08:15:20PM +0200, Richard Guenther wrote:
> On Wed, May 28, 2008 at 7:13 PM, Joe Buck <[EMAIL PROTECTED]> wrote:
> > On Tue, May 27, 2008 at 09:11:18PM -0400, NightStrike wrote:
> >> On 5/27/08, Joe Buck <[EMAIL PROTECTED]> wrote:
> >> > A third alternative is to issue a sna
On Wed, May 28, 2008 at 7:13 PM, Joe Buck <[EMAIL PROTECTED]> wrote:
> On Tue, May 27, 2008 at 09:11:18PM -0400, NightStrike wrote:
>> On 5/27/08, Joe Buck <[EMAIL PROTECTED]> wrote:
>> > A third alternative is to issue a snapshot (at whatever time interval
>> > is chosen) iff there's been a checki
On Tue, May 27, 2008 at 09:11:18PM -0400, NightStrike wrote:
> On 5/27/08, Joe Buck <[EMAIL PROTECTED]> wrote:
> > A third alternative is to issue a snapshot (at whatever time interval
> > is chosen) iff there's been a checkin on the branch.
>
> I thought that's how it worked already.
No, a new 4
Gerald Pfeifer wrote:
At this point, we have three open release branches (4.1, 4.2, and 4.3)
and trunk. Currently we are generating weekly snapshots for all four
of these.
I agree that turning off the 4.1 snapshots makes sense. If you're
sufficiently motivated to do the automatic
snapshot-o
On 5/27/08, Joe Buck <[EMAIL PROTECTED]> wrote:
> A third alternative is to issue a snapshot (at whatever time interval
> is chosen) iff there's been a checkin on the branch.
I thought that's how it worked already.
On Tue, May 27, 2008 at 10:48 PM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> > My recommendation in my very unoffical role as "carer of the snapshots"
> > is to stop doing those weekly snapshots for the 4.1 branch, and I will
> > be happy to roll a new snapshot upon request in case someone (like
On Tue, May 27, 2008 at 10:48 PM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> At this point, we have three open release branches (4.1, 4.2, and 4.3)
> and trunk. Currently we are generating weekly snapshots for all four
> of these.
>
> A while ago we agreed, for a number of reasons, not to do any
On 3/19/08, Kaveh R. Ghazi <[EMAIL PROTECTED]> wrote:
> I haven't heard anything that changes my opinion, I still think we should
> relicense the 4.1 branch and do one last release before closing it.
>
> Am I alone here, or does anyone else agree with me? :-/
FWIW, I vote on releasing another vers
From: "Mark Mitchell" <[EMAIL PROTECTED]>
Kaveh R. GHAZI wrote:
My understanding is that *users* of GCC are not impacted by the license
change.
Some users certainly are impacted by the license change -- there are in
fact quite a few companies that disallow their users using any GPLv3
softw
Dave Korn wrote:
> Jakub Jelinek wrote on 17 March 2008 12:00:
>
>> On Mon, Mar 17, 2008 at 10:27:17AM -, Dave Korn wrote:
>>> Eric Botcazou wrote on :
>>>
> fixincludes/fixincl.x changed to GPLv3 on 4.1 branch a month ago.
By accident I presume?
>>>
>>> As an epiphenonmenal side-ef
On Mon, Mar 17, 2008 at 5:54 AM, Dave Korn <[EMAIL PROTECTED]> wrote:
> Dave Korn wrote on :
>
>
> > Jakub Jelinek wrote on 17 March 2008 12:00:
>
>
> > > The fixincl.x change on 4.1 branch should be IMNSHO reverted.
> >
>
> > I tend to agree. I'll revert this change under the own-patches rule
Kaveh R. GHAZI wrote:
My understanding is that *users* of GCC are not impacted by the license
change.
Some users certainly are impacted by the license change -- there are in
fact quite a few companies that disallow their users using any GPLv3
software!
I think you're right that GPLv3 has
On Mon, Mar 17, 2008 at 02:41:18PM -0400, Kaveh R. GHAZI wrote:
> My understanding is that *users* of GCC are not impacted by the license
> change. When users compile their code, they only care about the runtime
> licenses as written into the GPL+exception clauses. These pieces of text
> are stil
> My understanding is that *users* of GCC are not impacted by the license
> change. When users compile their code, they only care about the runtime
> licenses as written into the GPL+exception clauses.
You mean they only *should* care about that. But in practice, many
corporate legal departmen
On Mon, 17 Mar 2008, Mark Mitchell wrote:
> Kaveh R. GHAZI wrote:
>
> >> I too think that it would be a bad idea to switch the 4.1 branch to
> >> GPLv3,
> >
> > Can you please elabortate why?
>
> I think it's a bad idea to change the license on a release branch in
> deep maintenance mode. That wo
Dave Korn wrote on :
> Jakub Jelinek wrote on 17 March 2008 12:00:
> > The fixincl.x change on 4.1 branch should be IMNSHO reverted.
>
> I tend to agree. I'll revert this change under the own-patches rule.
Done: http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01004.html
Apologies for the i
Jakub Jelinek wrote on 17 March 2008 12:00:
> On Mon, Mar 17, 2008 at 10:27:17AM -, Dave Korn wrote:
> > Eric Botcazou wrote on :
> >
> > > > fixincludes/fixincl.x changed to GPLv3 on 4.1 branch a month ago.
> > >
> > > By accident I presume?
> >
> >
> > As an epiphenonmenal side-effect
On Mon, Mar 17, 2008 at 10:27:17AM -, Dave Korn wrote:
> Eric Botcazou wrote on :
>
> > > fixincludes/fixincl.x changed to GPLv3 on 4.1 branch a month ago.
> >
> > By accident I presume?
>
>
> As an epiphenonmenal side-effect of being regenerated with the latest
> version of autogen rathe
On Mon, Mar 17, 2008 at 9:07 AM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Kaveh R. GHAZI wrote:
>
> >> I too think that it would be a bad idea to switch the 4.1 branch to
> >> GPLv3,
> >
> > Can you please elabortate why?
>
> I think it's a bad idea to change the license on a release branch
Eric Botcazou wrote on :
> > fixincludes/fixincl.x changed to GPLv3 on 4.1 branch a month ago.
>
> By accident I presume?
As an epiphenonmenal side-effect of being regenerated with the latest
version of autogen rather than an older one. It could always be reverted
and/or re-regenerated with
Kaveh R. GHAZI wrote:
I too think that it would be a bad idea to switch the 4.1 branch to
GPLv3,
Can you please elabortate why?
I think it's a bad idea to change the license on a release branch in
deep maintenance mode. That would be a surprise to users. The idea of
such branches has al
On Sun, 16 Mar 2008, Kaveh R. GHAZI wrote:
> However there is a class of users who don't get their compiler from
> distributors, but who also want the safety of using official releases and
> not some random svn checkout. These users are missing one year's worth of
> bugfixes. They may not want to
On Sun, 16 Mar 2008, Mark Mitchell wrote:
> Richard Guenther wrote:
>
> >> I support the final-release-then-close approach. But can we get a
> >> volunteer to convert that branch to GPLv3... ?
> >
> > I strongly object to moving the 4.1 brach to GPLv3.
>
> I too think that it would be a bad ide
NightStrike wrote:
> What exactly is the downside to upgrading the license? I'm not
> familiar with the implications of doing so.
As I understand it, the concern is that many distros use the 4.1 branch
as the base for their main gcc system compiler. If suddenly the branch
gets upgraded to GPLv3
On 3/16/08, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>
> >> I support the final-release-then-close approach. But can we get a
> >> volunteer to convert that branch to GPLv3... ?
> >
> > I strongly object to moving the 4.1 brach to GPLv3.
>
> I too think that it would be
Richard Guenther wrote:
I support the final-release-then-close approach. But can we get a
volunteer to convert that branch to GPLv3... ?
I strongly object to moving the 4.1 brach to GPLv3.
I too think that it would be a bad idea to switch the 4.1 branch to
GPLv3, and, therefore, I think
On Sun, Mar 16, 2008 at 9:33 AM, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > I understand and can support (up to a point) the desire of distributors to
> > continue working within GPLv2 and I know that's why the 4.1 branch is in
> > this situation. However IMHO this position is in tension with
On 3/15/08, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> On Sat, 15 Mar 2008, NightStrike wrote:
>
> > On 3/15/08, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> > > I support the final-release-then-close approach. But can we get a
> > > volunteer to convert that branch to GPLv3... ?
> >
> > How compl
On 3/16/08, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > I understand and can support (up to a point) the desire of distributors to
> > continue working within GPLv2 and I know that's why the 4.1 branch is in
> > this situation. However IMHO this position is in tension with the
> > interests of us
> I understand and can support (up to a point) the desire of distributors to
> continue working within GPLv2 and I know that's why the 4.1 branch is in
> this situation. However IMHO this position is in tension with the
> interests of users who don't get gcc from distributors (think
> non-linux-gn
On Sat, 15 Mar 2008, Eric Botcazou wrote:
> > I think we agreed to _not_ move the 4.1 branch to GPLv3.
>
> FWIW that was my understanding as well.
>
> > So, if the FSF says we may not release as GPLv2 then we should not do
> > a 4.1.3 release. The branch is simply open as 4.1 is widely adopted
>
On Sat, 15 Mar 2008, NightStrike wrote:
> On 3/15/08, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> > I support the final-release-then-close approach. But can we get a
> > volunteer to convert that branch to GPLv3... ?
>
> How complicated is the task?
It's not complicated, but perhaps it is tediou
Kaveh Ghazi wrote:
From: "Richard Guenther" <[EMAIL PROTECTED]>
I support the final-release-then-close approach. But can we get a
volunteer to convert that branch to GPLv3... ?
I strongly object to moving the 4.1 brach to GPLv3.
Richard.
Because... ?
--
Kaveh R. Ghazi
I thought every
From: "Richard Guenther" <[EMAIL PROTECTED]>
I support the final-release-then-close approach. But can we get a
volunteer to convert that branch to GPLv3... ?
I strongly object to moving the 4.1 brach to GPLv3.
Richard.
Because... ?
--
Kaveh R. Ghazi
> If there is too much confusion about this (unset) policy to keep 4.1 GPLv2
> I propose to close the branch and branch a gcc-4_1-gplv2-branch off the
> top.
My vague recollection from the last GCC summit is that there was no plan to
move the 4.1 branch to GPLv3 and that everyone was OK with this
On Sat, Mar 15, 2008 at 1:12 PM, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > fixincludes/fixincl.x changed to GPLv3 on 4.1 branch a month ago.
>
> By accident I presume?
If there is too much confusion about this (unset) policy to keep 4.1 GPLv2
I propose to close the branch and branch a gcc-4_1-
> fixincludes/fixincl.x changed to GPLv3 on 4.1 branch a month ago.
By accident I presume?
--
Eric Botcazou
> I think we agreed to _not_ move the 4.1 branch to GPLv3.
FWIW that was my understanding as well.
> So, if the FSF says we may not release as GPLv2 then we should not do
> a 4.1.3 release. The branch is simply open as 4.1 is widely adopted
> and distributors ship from the top of the branch and
On Sat, 15 Mar 2008, Richard Guenther wrote:
> I think we agreed to _not_ move the 4.1 branch to GPLv3. So, if
fixincludes/fixincl.x changed to GPLv3 on 4.1 branch a month ago.
--
Joseph S. Myers
[EMAIL PROTECTED]
On Sat, Mar 15, 2008 at 5:09 AM, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
>
> On Fri, 14 Mar 2008, Joe Buck wrote:
>
> > On Fri, Mar 14, 2008 at 05:58:12PM -0500, Gabriel Dos Reis wrote:
> > > On Sat, Mar 8, 2008 at 7:36 PM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> > > > On Mon, 3 Mar 2008,
On Sat, Mar 15, 2008 at 1:31 AM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>
> "Gabriel Dos Reis" <[EMAIL PROTECTED]> writes:
>
> > On Sat, Mar 8, 2008 at 7:36 PM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> >> On Mon, 3 Mar 2008, Gabriel Dos Reis wrote:
> >> > Do we still want to keep this b
On 3/15/08, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> I support the final-release-then-close approach. But can we get a
> volunteer to convert that branch to GPLv3... ?
How complicated is the task?
On Fri, 14 Mar 2008, Joe Buck wrote:
> On Fri, Mar 14, 2008 at 05:58:12PM -0500, Gabriel Dos Reis wrote:
> > On Sat, Mar 8, 2008 at 7:36 PM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> > > On Mon, 3 Mar 2008, Gabriel Dos Reis wrote:
> > > > Do we still want to keep this branch alive?
> > >
> > >
On Fri, Mar 14, 2008 at 7:31 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>
> "Gabriel Dos Reis" <[EMAIL PROTECTED]> writes:
>
> > On Sat, Mar 8, 2008 at 7:36 PM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> >> On Mon, 3 Mar 2008, Gabriel Dos Reis wrote:
> >> > Do we still want to keep this b
On Fri, Mar 14, 2008 at 05:58:12PM -0500, Gabriel Dos Reis wrote:
> On Sat, Mar 8, 2008 at 7:36 PM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> > On Mon, 3 Mar 2008, Gabriel Dos Reis wrote:
> > > Do we still want to keep this branch alive?
> >
> > Looking at the changes that were made in the last
On Fri, Mar 14, 2008 at 05:58:12PM -0500, Gabriel Dos Reis wrote:
> On Sat, Mar 8, 2008 at 7:36 PM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> > On Mon, 3 Mar 2008, Gabriel Dos Reis wrote:
> > > Do we still want to keep this branch alive?
> >
> > Looking at the changes that were made in the last
"Gabriel Dos Reis" <[EMAIL PROTECTED]> writes:
> On Sat, Mar 8, 2008 at 7:36 PM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
>> On Mon, 3 Mar 2008, Gabriel Dos Reis wrote:
>> > Do we still want to keep this branch alive?
>>
>> Looking at the changes that were made in the last three months still,
>
On Sat, Mar 8, 2008 at 7:36 PM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> On Mon, 3 Mar 2008, Gabriel Dos Reis wrote:
> > Do we still want to keep this branch alive?
>
> Looking at the changes that were made in the last three months still,
> it seems the branch is still surprisingly alive, so
On Mon, 3 Mar 2008, Gabriel Dos Reis wrote:
> Do we still want to keep this branch alive?
Looking at the changes that were made in the last three months still,
it seems the branch is still surprisingly alive, so it may not yet be
the time to close it. Personally I don't have a preference either w
On 3 Mar 2008 22:40:21 -, <[EMAIL PROTECTED]> wrote:
> Snapshot gcc-4.1-20080303 is now available on
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20080303/
> and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
>
> This snapshot has been generated from the GCC 4.1 SVN bran
On Mon, 16 Jul 2007, Jonathan Wakely wrote:
> The link on gcc.gnu.org for the GCC 4.1 status refers to an email about
> GCC 4.2
Thanks for this report. I did some digging (to find the correct link),
and it seems this was introduced with revision 1.619 of index.html.
This patch restores the lat
> Sure, that would be an alternative compared to always removing the
> REG_EQUAL notes when hoisting an insn and it would fix my particular
> testcase as well.
Then it's pre-approved for the branch if your testcase exhibits a regression.
> But I don't see why this can't happen with unconditional
Hi,
> OK. Then would it be enough to weaken the condition of the removal test to
>
> if (loop_invariant_p (loop, ...) != 1)
>
> in order to solve your problem?
Sure, that would be an alternative compared to always removing the
REG_EQUAL notes when hoisting an insn and it would fix my particul
> The register replacement is done by gcse but the cse pass invoked from gcse
> modifies the REG_EQUAL note. The limited scope of cse compared to gcse is
> probably the reason why the information put into the insn note isn't
> helpful. The REG_EQUAL note added to insn 2308 seems to be particularly
Hi Eric,
> The note doesn't look particularly helpful in this case, given that gcse
> has replaced r974 with r1218 in the insn. How is it created?
The register replacement is done by gcse but the cse pass invoked from gcse
modifies the REG_EQUAL note. The limited scope of cse compared to gcse i
> After gcse1 a loop body contains the following two insns. Note that gcse
> has already replaced r974 with r1218 in insn 1743 and has attached a
> REG_EQUAL note. Insn 2308 stays as a dead store - maybe thats what confuses
> the loop optimizer.
>
> (insn 2308 1740 1743 111 (set (reg/f:DI 974)
>
Joseph S. Myers wrote:
> On Tue, 30 Jan 2007, Mark Mitchell wrote:
>
>>>PR target/30370 (powerpc-unknown-eabispe can't build libgcc2) is a
>>> regression from 4.1.1. A patch was posted earlier this month at
>>> http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00600.html>. I have
>>> regrettably fo
On Tue, 30 Jan 2007, Mark Mitchell wrote:
> >PR target/30370 (powerpc-unknown-eabispe can't build libgcc2) is a
> > regression from 4.1.1. A patch was posted earlier this month at
> > http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00600.html>. I have
> > regrettably forgotten to ping this patch
Rask Ingemann Lambertsen wrote:
> On Sun, Jan 28, 2007 at 11:53:41AM -0800, Mark Mitchell wrote:
>> I plan to create GCC 4.1.2 RC1 sometime this afternoon, US/Pacific time.
>>
>> Therefore, please do not make any checkins to the 4.1 branch after 2PM
>> PST. Once RC1 is uploaded, the branch will be
On Sun, Jan 28, 2007 at 11:53:41AM -0800, Mark Mitchell wrote:
> I plan to create GCC 4.1.2 RC1 sometime this afternoon, US/Pacific time.
>
> Therefore, please do not make any checkins to the 4.1 branch after 2PM
> PST. Once RC1 is uploaded, the branch will be open only for changes
> which have m
On Jun 30, 2006, at 12:40 AM, Mike Stump wrote:
On Jun 29, 2006, at 8:27 PM, Rajkishore Barik wrote:
I am trying to complie GCC 4.1 on an AIX 5.3 machine having 2 power5
processors.
Then this is the wrong list... You'd want gcc-help.
They also might want to read: http://gcc.gnu.org/insta
On Jun 29, 2006, at 8:27 PM, Rajkishore Barik wrote:
I am trying to complie GCC 4.1 on an AIX 5.3 machine having 2 power5
processors.
Then this is the wrong list... You'd want gcc-help.
On May 15, 2006, at 8:56 AM, Igor Bukanov wrote:
Consider the following code that starting with GCC 4.1.0 generates
'dereferencing type-punned pointer will break strict-aliasing rules'
warning:
Yup. Kinda does seem a flaw in the C language. You could switch to C
++. :-)
~> cat test.c
str
On Fri, May 12, 2006 at 08:40:07PM +0200, Etienne Lorrain wrote:
> But when I tried (replacing in Gujin some calll by lcallw based on which
> function
> is called) it did not work as I expected it. For instance, -fno-function-cse
> seem
> ignored here:
What are you expecting to happen here?
On Tue, Apr 25, 2006 at 05:41:18PM +0100, Andrew Haley wrote:
> Rene Rebe writes:
> > On Tuesday 25 April 2006 14:21, Andrew Haley wrote:
> > > Rene Rebe writes:
> > > > jackd: error while loading shared libraries: /usr/lib64/libjack.so.0:
> > > > R_PPC64_ADDR32 4056b70 for symbol `' out
Rene Rebe writes:
> On Tuesday 25 April 2006 14:21, Andrew Haley wrote:
> > Rene Rebe writes:
> > > Hi,
> > >
> > > not such an high priority, but testing the latest gcc 4.1.0 in
> > > "whole system builds" I stumble over:
> > >
> > > jackd: error while loading shared libraries: /usr/
On Tuesday 25 April 2006 14:21, Andrew Haley wrote:
> Rene Rebe writes:
> > Hi,
> >
> > not such an high priority, but testing the latest gcc 4.1.0 in
> > "whole system builds" I stumble over:
> >
> > jackd: error while loading shared libraries: /usr/lib64/libjack.so.0:
> > R_PPC64_ADDR32 40
Hi,
On Tuesday 25 April 2006 14:21, Andrew Haley wrote:
> Rene Rebe writes:
> > Hi,
> >
> > not such an high priority, but testing the latest gcc 4.1.0 in
> > "whole system builds" I stumble over:
> >
> > jackd: error while loading shared libraries: /usr/lib64/libjack.so.0:
> > R_PPC64_ADDR
Rene Rebe writes:
> Hi,
>
> not such an high priority, but testing the latest gcc 4.1.0 in
> "whole system builds" I stumble over:
>
> jackd: error while loading shared libraries: /usr/lib64/libjack.so.0:
> R_PPC64_ADDR32 4056b70 for symbol `' out of range
>
> There only R_PPC64_AD
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Patricia Bittencourt Sampaio wrote:
>And if so, does it support -openmp option so as to
> compile openmp applications?
>
No. -fopenmp will only be available starting with GCC 4.2. If you are
running Fedora Core 5, it has a special version of gc
On Sun, Apr 16, 2006 at 02:04:10PM -0700, Mark Mitchell wrote:
> I've now reviewed the open regressions against the GCC 4.1 branch.
> There are 101 "serious" (P3 or higher) regressions against GCC 4.1, the
> vast majority of which also apply to 4.2. Therefore, fixing these
> regressions provides a
On 14. Mrz 2006, at 01:53 Uhr, Mike Stump wrote:
Am I the only one who gets those:
DOMElement.m:283: warning: pointer type mismatch in conditional
expression
I doubt it.
;-)
For stuff like:
objs[1] = _ns ? _ns : (id)null;
or
return [pathes isNotNull] ? pathes : nil;
And here all in
On Mar 13, 2006, at 2:05 PM, Lars Sonchocky-Helldorf wrote:
The appropriate place for such stuff is gcc@gcc.gnu.org
No, not really. gcc-help is more appropriate.
Am I the only one who gets those:
DOMElement.m:283: warning: pointer type mismatch in conditional
expression
I doubt it.
F
The appropriate place for such stuff is gcc@gcc.gnu.org
Am Montag, 13.03.06 um 17:19 Uhr schrieb Helge Hess:
Hi,
new gcc release, new warnings ;-)
Am I the only one who gets those:
DOMElement.m:283: warning: pointer type mismatch in conditional
expression
For stuff like:
objs[1] = _ns
Greg Schafer wrote:
> Remove the -j3 and all is well. I suppose most folks never run `make
> install' in parallel.. but sometimes it's convenient to just simply:
>
> export MAKEFLAGS=-j3
>
> for big compile jobs.
I'm not aware of anything parallel-make unfriendly about my patch, but I
can beli
Mark Mitchell wrote:
> This will be the final patch for GCC 4.1.0. I plan to work through the
> release checklist tonight. As always, the official announcement will
> follow after the release has had time to make it to the mirrors.
Just a word of warning about this patch for unsuspecting travel
> GCC 4.1 RC2 is now available from:
>
> ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.0-20060223
Still OK on SPARC/Solaris:
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01558.html
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01557.html
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01556.htm
Mark Mitchell wrote:
> Joseph thinks these should go in $libsubdir; I'm going to try that now.
With much help from Daniel and Joseph, I have a patch for this problem,
which I am now testing.
This will be the final patch for GCC 4.1.0. I plan to work through the
release checklist tonight. As al
Mark Mitchell wrote:
> My current expectation is that I will apply your patch, test locally,
> but not produce an RC3.
I built a native compiler with the patch. I
The ssp include files ended up in $prefix/lib/include/ssp. There are no
other files in $prefix/lib/include. The C++ header files a
Ralf Corsepius wrote:
>> I've just attached a patch that seems to solve this issue for me.
> Thinking about this once more, I think my patch is equally wrong.
> These headers shouldn't be installed to includedir at all, but should be
> installed into gcc's internal include dir
> ($libdir/gcc/$targ
On Fri, Feb 24, 2006 at 09:00:25AM -0800, Mark Mitchell wrote:
> GCC 4.1 RC2 is now available from:
>
> ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.0-20060223
Looks good on s390-ibm-linux and s390x-ibm-linux
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01489.html
http://gcc.gnu.org/ml/gcc-testre
On Mon, 2006-02-27 at 15:17 +0100, Ralf Corsepius wrote:
> On Mon, 2006-02-27 at 08:08 -0600, Joel Sherrill wrote:
> > Ralf Corsepius wrote:
> >
> > >On Sun, 2006-02-26 at 18:29 -0500, Frank Ch. Eigler wrote:
> > >
> > >
> > >>Hi -
> > >>
> > >>On Sun, Feb 26, 2006 at 10:54:09PM +0100, Gerald Pf
On Mon, 2006-02-27 at 08:08 -0600, Joel Sherrill wrote:
> Ralf Corsepius wrote:
>
> >On Sun, 2006-02-26 at 18:29 -0500, Frank Ch. Eigler wrote:
> >
> >
> >>Hi -
> >>
> >>On Sun, Feb 26, 2006 at 10:54:09PM +0100, Gerald Pfeifer wrote:
> >>
> >>
> >>>On Sun, 26 Feb 2006, Ralf Corsepius wrote:
Ralf Corsepius wrote:
On Sun, 2006-02-26 at 18:29 -0500, Frank Ch. Eigler wrote:
Hi -
On Sun, Feb 26, 2006 at 10:54:09PM +0100, Gerald Pfeifer wrote:
On Sun, 26 Feb 2006, Ralf Corsepius wrote:
Cross building and installing gcc-4.1.0 rc2 (--prefix=/usr/local)
installs these hea
Hallo,
this is now bug 26481
i have attached the build log
On Mon, 27 Feb 2006, Andreas Conz wrote:
>
> now there is a problem building the POWER part of libstdc++ :
>
> -->8-
> -->8-
>
> I a
Thanks for the help,
On Fri, 24 Feb 2006, David Edelsohn wrote:
> If you are building on a 32-bit only system, you need to configure
> with --disable-aix64 so that it does not try to build 64-bit libraries.
> GCC currently expects to be able to run executables in all multilib modes
> when b
On Sun, 2006-02-26 at 18:29 -0500, Frank Ch. Eigler wrote:
> Hi -
>
> On Sun, Feb 26, 2006 at 10:54:09PM +0100, Gerald Pfeifer wrote:
> > On Sun, 26 Feb 2006, Ralf Corsepius wrote:
> > > Cross building and installing gcc-4.1.0 rc2 (--prefix=/usr/local)
> > > installs these headers:
> > > [...]
> >
Hi -
On Sun, Feb 26, 2006 at 10:54:09PM +0100, Gerald Pfeifer wrote:
> On Sun, 26 Feb 2006, Ralf Corsepius wrote:
> > Cross building and installing gcc-4.1.0 rc2 (--prefix=/usr/local)
> > installs these headers:
> > [...]
> Related problems include Bugzilla #23935 ($PREFIX/include/ffi.h),
> #25938
On Sun, 26 Feb 2006, Ralf Corsepius wrote:
> Cross building and installing gcc-4.1.0 rc2 (--prefix=/usr/local)
> installs these headers:
>
> /usr/local/include/ssp/unistd.h
> /usr/local/include/ssp/string.h
> /usr/local/include/ssp/ssp.h
> /usr/local/include/ssp/stdio.h
>
> Is this behavior corre
Thanks
I was mostly trying to give Andreas a way to determine what type of
system he has (via kdb).
On Feb 24, 2006, at 6:07 PM, David Edelsohn wrote:
Perry Smith writes:
Perry> You can build 64 bit libraries in 32 bit mode.
You are answering a different question. AIX supports
> Perry Smith writes:
Perry> You can build 64 bit libraries in 32 bit mode.
You are answering a different question. AIX supports building
64-bit executables on 32-bit systems. It does not depend on the
processor.
The question is about bootstrapping GCC. GCC bootstrap want
On Feb 24, 2006, at 4:34 PM, David Edelsohn wrote:
Andreas Conz writes:
Andreas> Hello to all and thank you for the good work,
Andreas> I was trying to build GCC 4.1 RC1 on AIX 5.1 _32bit_.
Andreas> The machine is not very fast and I made some mistakes in
the beginning.
Andreas> Now my bu
> Andreas Conz writes:
Andreas> Hello to all and thank you for the good work,
Andreas> I was trying to build GCC 4.1 RC1 on AIX 5.1 _32bit_.
Andreas> The machine is not very fast and I made some mistakes in the beginning.
Andreas> Now my build stops while configuring libstdc++-v3 :
Andreas>
Hello to all and thank you for the good work,
I was trying to build GCC 4.1 RC1 on AIX 5.1 _32bit_.
The machine is not very fast and I made some mistakes in the beginning.
Now my build stops while configuring libstdc++-v3 :
-->8-
checking f
Paolo Bonzini wrote:
> Mark Mitchell wrote:
>> I will spin GCC 4.1 RC2 tonight.
>>
>> The only patch I plan to apply, relative to current sources, is Paolo
>> Bonzini's Ada patch.
>
> ... which is revision 108058. I gather that you want to apply it yourself?
Already done.
Thanks!
--
Mark Mitc
Mark Mitchell wrote:
I will spin GCC 4.1 RC2 tonight.
The only patch I plan to apply, relative to current sources, is Paolo
Bonzini's Ada patch.
... which is revision 108058. I gather that you want to apply it yourself?
r108058 | bonzini | 2005-12-05 15:40:27 +0100 (Mon, 05 Dec 2005)
libada
1 - 100 of 522 matches
Mail list logo