On 7/12/07, Michael Eager <[EMAIL PROTECTED]> wrote:
Eric Botcazou wrote:
>> How does this work for 32-bit hosts and 64-bit targets?
>
> Some (most?) 64-bit targets require a 64-bit HOST_WIDE_INT.
Meaning that I can't build gcc-ppc64 on an IA32 host?
No, he said they require a 64 bit HOST_WIDE
Hello,
I wanted to update the status of the first patch that
Vladimir had posted to improve modulo-schedualing.
(http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01468.html).
I tested this patch on ppc64 and currently there is one difference in
one of the fortran's testcases (forall_10.f90); this te
On 7/12/07, Michael Eager <[EMAIL PROTECTED]> wrote:
Meaning that I can't build gcc-ppc64 on an IA32 host?
HUH? Yes you can, HWI is a64bit integer type there (aka long long).
-- Pinski
Eric Botcazou wrote:
How does this work for 32-bit hosts and 64-bit targets?
Some (most?) 64-bit targets require a 64-bit HOST_WIDE_INT.
Meaning that I can't build gcc-ppc64 on an IA32 host?
Yuck! So much for cross-platform tools.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo
> Sorry: I guess my information is dated. What changed so that it's now
> required?
I presume the reasons you gave + the usual nasty bugs prompted someone to
decide that it was not worth the troubles after all.
--
Eric Botcazou
I extracted the MFPGPR hunks from Peter Bergner's "[PATCH] Add POWER6
machine description", posted on 2006-11-01 and dropped them into
gcc-4.0.3, but the result fails with "error: insn does not satisfy its
constraints":
.../src/gcc-4.0.3/gcc/config/rs6000/darwin-ldouble.c: In function
'__gcc_
> > They don't REQUIRE it, but just miss a lot of optimization if that isn't
> > the case (since things that would otherwise be CONST_INT will now be
> > CONST_DOUBLE and folding will be harder).
>
> # need_64bit_hwint Set to yes if HOST_WIDE_INT must be 64 bits wide
> # for
> They don't REQUIRE it, but just miss a lot of optimization if that isn't
> the case (since things that would otherwise be CONST_INT will now be
> CONST_DOUBLE and folding will be harder).
# need_64bit_hwint Set to yes if HOST_WIDE_INT must be 64 bits wide
# for this ta
DJ Delorie wrote:
I read these as "4.2.1 is the last 4.2 release". Pulling a 4.3.3 from
that branch is, IMHO, stupid and confusing. If 4.2.1 is the last 4.2
release, the 4.2 branch is DEAD (svn topology notwithstanding). The
next release cannot be 4.3.3, that makes no sense. The next release
> > How does this work for 32-bit hosts and 64-bit targets?
>
> Some (most?) 64-bit targets require a 64-bit HOST_WIDE_INT.
They don't REQUIRE it, but just miss a lot of optimization if that isn't
the case (since things that would otherwise be CONST_INT will now be
CONST_DOUBLE and folding will b
> How does this work for 32-bit hosts and 64-bit targets?
Some (most?) 64-bit targets require a 64-bit HOST_WIDE_INT.
--
Eric Botcazou
> HOST_WIDE_INT is the wide integer type used throughout the compiler.
I haven't looked at the definition.
Is it guaranteed to hold all target integer sizes?
No.
How does this work for 32-bit hosts and 64-bit targets?
Often we use "long long" for HOST_WIDE_INT, but in other c
On 7/12/07, John David Anglin <[EMAIL PROTECTED]> wrote:
> The next scheduled GCC 4.2.x release is GCC 4.2.1 on July 13th.
PR 32199 is a regression in behavior from 4.2.0. Although a libjava
build regression is probably not sufficient justification to block
the scheduled release, the change tha
Ian Lance Taylor wrote:
If they don't get onboard with GPLv3, then they are stuck with
previously released versions of gcc, and they will be forced to
develop any patches independently. That is not ideal but does not
seem to be avoidable. There are competing contradictory requirements.
The FSF
Eric Botcazou wrote:
Why would the RTL represent target CONST_INT as HOST_WIDE_INT?
HOST_WIDE_INT is the wide integer type used throughout the compiler.
I haven't looked at the definition.
Is it guaranteed to hold all target integer sizes? How
does this work for 32-bit hosts and 64-bit targ
On 7/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Ian Lance Taylor wrote:
>>> The only people who may be discomfited by that choice are distributors
>>> of gcc who are unwilling to distribute code licensed under GPLv3.
>> And anyone using any past release.
>
> Incorrect. It only matters for
> Why would the RTL represent target CONST_INT as HOST_WIDE_INT?
HOST_WIDE_INT is the wide integer type used throughout the compiler.
--
Eric Botcazou
Mike Stump wrote:
On Jul 12, 2007, at 9:23 AM, Michael Eager wrote:
I was looking through dwarf2out.c, tracking down the
cause for different assembly code being generated
when gcc was run on 32-bit and 64-bit hosts.
When QAing, it is very useful to be able to compare two .s files. This
means
Ian Lance Taylor wrote:
Michael Eager <[EMAIL PROTECTED]> writes:
It seems to me that the same assembly code should be generated
independent of whether gcc is run on a 32-bit or 64-bit
host and all of these HOST_* tests should actually be
target domain parameters, like BITS_PER_WORD.
It is sa
On Jul 12, 2007, at 9:23 AM, Michael Eager wrote:
I was looking through dwarf2out.c, tracking down the
cause for different assembly code being generated
when gcc was run on 32-bit and 64-bit hosts.
When QAing, it is very useful to be able to compare two .s files.
This means that we should st
I've been wanting to contribute code to gcc, but since i don't know it
too much i thought of starting from this bug (which, btw recreates on
my machine with gcc 4.2).
I've found out this bug and begun working it.
I've started writing code in maybe_process_partial_specialization
after push_templa
> The next scheduled GCC 4.2.x release is GCC 4.2.1 on July 13th.
PR 32199 is a regression in behavior from 4.2.0. Although a libjava
build regression is probably not sufficient justification to block
the scheduled release, the change that triggered this regression
has nothing to do the java/libj
Michael Eager <[EMAIL PROTECTED]> writes:
> Here's an alternative:
>
> Since copyright is owned by FSF, they (via the steering committee)
> can license them under different licenses.
>
> Patches applied to gcc-4. are licensed under GPLv3.
> Patches applied to previous versions are licensed under
Hi *,
when compiling crafty-20.14 with
CFLAGS='$(CFLAGS) -Wall -pipe -D_REENTRANT -march=i686 -O3 \
-fprofile-use -fbranch-probabilities -fomit-frame-pointer \
-ftree-vectorize -ftree-vectorizer-verbose=1 -msse2 \
-fno-gcse -mpreferred-stack-
On 12/07/2007, at 8:30 AM, Steve Ellcey wrote:
Feel free to either (a) #ifdef out the first part of the test on
IA64,
or (b) delete the first part of the test altogether.
Since it fails on other platforms (b) seems like the better
alternative.
OK to checkin this patch?
OK.
2007-07-12
Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes:
> Also (and I am too young to know) how (and when and if) was the GPLv1
> -> GPLv2 transition handled? Or is GCC older than GPLv1 (I am just
> asking, maybe past history could help).
I believe gcc 2.0 was the first GPLv2 version of gcc. There were
Michael Eager <[EMAIL PROTECTED]> writes:
> I was looking through dwarf2out.c, tracking down the
> cause for different assembly code being generated
> when gcc was run on 32-bit and 64-bit hosts.
>
> In dwarf2out.c, there are several places where decisions
> about what to generate in the .s file
Serge Belyshev wrote:
Personally, I think that bumping version number is the worst possible solution
of all proposed.
To me it seems essential to change the version number when changing the
license. Technical compiler folk may not regard the license change as a
significant one, but for the use
On Thu, 2007-07-12 at 18:47 +0100, Dave Korn wrote:
> On 12 July 2007 18:42, Janis Johnson wrote:
>
> > On Thu, 2007-07-12 at 09:58 -0700, Ian Lance Taylor wrote:
> >> If you want to release gcc 4.2.2, and then release gcc 4.3.0 from the
> >> gcc 4.2 branch, and make mainline gcc the eventual gcc
On 12 July 2007 18:42, Janis Johnson wrote:
> On Thu, 2007-07-12 at 09:58 -0700, Ian Lance Taylor wrote:
>> If you want to release gcc 4.2.2, and then release gcc 4.3.0 from the
>> gcc 4.2 branch, and make mainline gcc the eventual gcc 4.4.0, I'm on
>> board with that. That is easy enough to unde
Mark Mitchell wrote:
David Edelsohn wrote:
Let me try to stop some confusion and accusations right here. RMS
*did not* request or specify GCC 4.3.3 following GCC 4.2.2. That was a
proposal from a member of the GCC SC. The numbering of the first GPLv3
release was not a requirement from
Brooks Moses wrote:
Diego Novillo wrote:
On 7/12/07 11:43 AM, Richard Kenner wrote:
My personal preference would be to acknowledge that for our users
there is no significant difference between GPLv2 and GPLv3.
I agree with this. I think renaming 4.2.2 to 4.3.3 will result in
lots of unnecess
Ian Lance Taylor wrote:
Michael Eager <[EMAIL PROTECTED]> writes:
Ian Lance Taylor wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
2. GCC 4.2.1 will be the last GPLv2 release. The FSF will permit
backports from mainline to GCC 4.2.1, if necessary, to be downlicensed
to GPLv2, as part of th
On Thu, 2007-07-12 at 09:58 -0700, Ian Lance Taylor wrote:
> If you want to release gcc 4.2.2, and then release gcc 4.3.0 from the
> gcc 4.2 branch, and make mainline gcc the eventual gcc 4.4.0, I'm on
> board with that. That is easy enough to understand and not too
> difficult to implement. What
$.02 from a user who has been following the discussion:
1. Don't jack with the version numbers. This is confusing.
2. Turn off public access to the code while changing license text in the
source.
3. Backports to current stuff should stay under current licence, i.e. a
gcc 4.2.1 containing bits
Michael Eager wrote:
Ian Lance Taylor wrote:
I believe that we should make a clear statement with that release that
any future backport from a later gcc release requires relicensing the
changed files to be GPLv3 or later. I believe this is consistent with
the two different licensing requirement
Diego Novillo wrote:
On 7/12/07 11:43 AM, Richard Kenner wrote:
My personal preference would be to acknowledge that for our users
there is no significant difference between GPLv2 and GPLv3.
I agree with this. I think renaming 4.2.2 to 4.3.3 will result in
lots of unnecessary confusion.
Like
David Edelsohn wrote:
> Let me try to stop some confusion and accusations right here. RMS
> *did not* request or specify GCC 4.3.3 following GCC 4.2.2. That was a
> proposal from a member of the GCC SC. The numbering of the first GPLv3
> release was not a requirement from RMS or the FSF.
On 12 July 2007 17:59, Ian Lance Taylor wrote:
> If you want to release gcc 4.2.2, and then release gcc 4.3.0 from the
> gcc 4.2 branch, and make mainline gcc the eventual gcc 4.4.0, I'm on
> board with that. That is easy enough to understand and not too
> difficult to implement. What I'm disag
I rarely de-lurk, but:
It seems to have been suggested that (with at least some new patches
being "GPLv2 or later" in some lawful way acceptable to FSF):
0. Bump no version numbers to reflect license changes.
It seems to me that there have been proposed (with all new patches being
"GPLv3 or
> Ian Lance Taylor writes:
Ian> Samba is simply bumping to 3.2.0. They aren't moving from 3.0.26 to
Ian> 3.2.27.
Ian> If you want to release gcc 4.2.2, and then release gcc 4.3.0 from the
Ian> gcc 4.2 branch, and make mainline gcc the eventual gcc 4.4.0, I'm on
Ian> board with that. That is
Ian Lance Taylor wrote:
>>> The only people who may be discomfited by that choice are distributors
>>> of gcc who are unwilling to distribute code licensed under GPLv3.
>> And anyone using any past release.
>
> Incorrect. It only matters for distributors, not users.
> Again, I am just the messe
On 12 July 2007 17:51, Andrew Pinski wrote:
> On 7/12/07, Dave Korn <[EMAIL PROTECTED]> wrote:
>> On 12 July 2007 17:23, Michael Eager wrote:
>>
>> Sounds right to me. Basing codegen decisions on HOST_ is just plain
>> wrong and has been an ongoing source of bugs down the years.
>
> Exce
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
[...]
> My personal preference would be to acknowledge that for our users
> there is no significant difference between GPLv2 and GPLv3. And we
> should acknowledge that people backporting patches from later releases
> are already going to have to relic
David Edelsohn <[EMAIL PROTECTED]> writes:
> > Ian Lance Taylor writes:
>
> Ian> To pile on after my earlier message, I would say that the change in
> Ian> license does not matter at all, not even a tiny bit, for gcc *users*.
> Ian> It only matters for gcc *distributors*. And I think the vas
Michael Eager <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor wrote:
> > Mark Mitchell <[EMAIL PROTECTED]> writes:
> >
> >> 2. GCC 4.2.1 will be the last GPLv2 release. The FSF will permit
> >> backports from mainline to GCC 4.2.1, if necessary, to be downlicensed
> >> to GPLv2, as part of that re
Mark Mitchell <[EMAIL PROTECTED]> writes:
> 1. The compiler proper (e.g., files used only in cc1, cc1plus, the
> driver, etc.) should all be converted to GPLv3 ASAP.
I'll note that libiberty is not used "only" in gcc. We still need to
coordinate that change separately.
> 2. GCC 4.2.1 will be th
I would prefer the following numbering:
4.2.1 last full patchlevel release of gcc under GPLv2
4.2.1.x patch releases to gcc 4.2.1 where only patches with GPLv2 license
are applied
4.2.2 The first GPLv3 patchlevel release of gcc 4.2
Rationale: Because some people want to stay with GPLv2 fo
On 7/12/07, Dave Korn <[EMAIL PROTECTED]> wrote:
On 12 July 2007 17:23, Michael Eager wrote:
Sounds right to me. Basing codegen decisions on HOST_ is just plain
wrong and has been an ongoing source of bugs down the years.
Except in this case, the code gen is the same, just the assembly
On 12 July 2007 17:23, Michael Eager wrote:
> I was looking through dwarf2out.c, tracking down the
> cause for different assembly code being generated
> when gcc was run on 32-bit and 64-bit hosts.
>
> In dwarf2out.c, there are several places where decisions
> about what to generate in the .s fil
Is anyone else seeing failures on the gcc.dg/matrix tests? I am getting
the following failures on IA64 HP-UX:
FAIL: gcc.dg/matrix/matrix-1.c scan-ipa-dump-times Flattened 3 dimensions 1
FAIL: gcc.dg/matrix/matrix-2.c scan-ipa-dump-times Flattened 2 dimensions 1
FAIL: gcc.dg/matrix/matrix-3.c scan
Nick Clifton wrote:
> Hi Mark,
>
>> Will someone (or someones) please volunteer to change the various files
>> that mention GPLv2 to mention GPLv3 instead, to change the COPYING file
>> in the gcc/ directory, and to look for other things that need to change?
>
> I volunteer.
Thank you!
>> It ha
I was looking through dwarf2out.c, tracking down the
cause for different assembly code being generated
when gcc was run on 32-bit and 64-bit hosts.
In dwarf2out.c, there are several places where decisions
about what to generate in the .s file are based on
HOST_BITS_PER_WIDE_INT or HOST_BITS_PER_W
On Wed, Jul 11, 2007 at 09:58:51PM -0700, Mark Mitchell wrote:
> The GCC SC is still discussing a few of the finer points of the
> transition to GPLv3.
>
> However, here are the things that have now been decided:
>
> 1. The compiler proper (e.g., files used only in cc1, cc1plus, the
> driver, etc
Ian Lance Taylor wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
2. GCC 4.2.1 will be the last GPLv2 release. The FSF will permit
backports from mainline to GCC 4.2.1, if necessary, to be downlicensed
to GPLv2, as part of that release.
I believe that we should make a clear statement with th
On Thu, Jul 12, 2007 at 05:53:52PM +0200, Bernd Schmidt wrote:
> I don't think that's true. Given that all copyrights are assigned to the
> FSF,
> the FSF could license these changes as GPLv2+ (in 4.2) and GPLv3+ (in 4.3 and
> up) without a problem. The original author's wishes do not come int
David Edelsohn wrote:
Bernd Schmidt writes:
Bernd> I don't think that's true. Given that all copyrights are assigned to
Bernd> the FSF, the FSF could license these changes as GPLv2+ (in 4.2) and
Bernd> GPLv3+ (in 4.3 and up) without a problem. The original author's wishes
Bernd> do not com
Mark Mitchell wrote:
The GCC SC is still discussing a few of the finer points of the
transition to GPLv3.
3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3.
What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to
emphasize the GPLv3 switch. The GCC mainline
> Bernd> I don't think that's true. Given that all copyrights are assigned to
> Bernd> the FSF, the FSF could license these changes as GPLv2+ (in 4.2) and
> Bernd> GPLv3+ (in 4.3 and up) without a problem. The original author's
> Bernd> wishes do not come into play.
>
> Wrong. The origi
> Bernd Schmidt writes:
Bernd> I don't think that's true. Given that all copyrights are assigned to
Bernd> the FSF, the FSF could license these changes as GPLv2+ (in 4.2) and
Bernd> GPLv3+ (in 4.3 and up) without a problem. The original author's wishes
Bernd> do not come into play.
> Bernd Schmidt writes:
Bernd> I don't think that's true. Given that all copyrights are assigned to
Bernd> the FSF, the FSF could license these changes as GPLv2+ (in 4.2) and
Bernd> GPLv3+ (in 4.3 and up) without a problem. The original author's wishes
Bernd> do not come into play.
David Edelsohn wrote:
Leaving released branches as GPLv2 is not an option.
Dave> What, even *closed* release branches?
The comment referred to GCC 4.2. GCC 4.2 branch may not remain
under GPLv2. GCC 4.1 branch may not remain under GPLv2. Closing the GCC
4.2 branch is impractical -- w
David Edelsohn <[EMAIL PROTECTED]> writes:
| > Doug Gregor writes:
|
| Doug> Could we ask the SC to reconsider the change in the GCC major version
| Doug> numbering for GPLv3? Or, at the very least, explain why it is
| Doug> important to change the major version number for a mere license
| Do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Edelsohn wrote:
>> Benjamin Smedberg writes:
>
> Doug> It seems obvious to me that it would be easiest to just move today's
> Doug> mainline over to GPLv3, and have every GCC release >= 4.3 be GPLv3. We
> Doug> could then either cut off the
> Richard Kenner writes:
>> Because the FSF says it is not an option. The FSF holds the
>> copyright and decides on the licensing.
Richard> True, but RMS has been known to change his mind when people point out
to him
Richard> the consequences of a decision.
The GCC SC has not been
> Because the FSF says it is not an option. The FSF holds the
> copyright and decides on the licensing.
True, but RMS has been known to change his mind when people point out to him
the consequences of a decision.
> This sounds ideal, but I'm concerned a little bit about how this interacts
> with the copyright assignment to FSF. When a contributor assigns copyright
> to FSF, do they still have the right to license their changes separately?
Yes.
> Any patches backported to a release branch from mainline after
> mainline is relicensed to GPLv3 will cause the branch to be subject to
> GPLv3, unless the original author explicitly contributes the patch to the
> branch under GPLv2.
That doesn't seem an unreasonable requirement and if that's al
On 7/12/07 11:43 AM, Richard Kenner wrote:
>> My personal preference would be to acknowledge that for our users
>> there is no significant difference between GPLv2 and GPLv3.
>
> I agree with this. I think renaming 4.2.2 to 4.3.3 will result in
> lots of unnecessary confusion.
>
Likewise. As w
>> It has not yet been decided what to do about files that are part of
>> run-time libraries and are covered by GPL/LGPL + exception.
>> Therefore, no changes to
>I find this truncated sentence to be slightly ominous as I believe
>there is only one plausible choice for those files: we must convert
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Richard Guenther wrote:
>> | It has also not yet been decided whether backports of bug-fixes from
>> | GPLv3 versions of GCC to older GPLv2 versions of GCC (e.g., GCC 4.1)
>>
>> We can make a final release from GCC-4.1.x and close it definitely.
>> We
> My personal preference would be to acknowledge that for our users
> there is no significant difference between GPLv2 and GPLv3.
I agree with this. I think renaming 4.2.2 to 4.3.3 will result in
lots of unnecessary confusion.
> Benjamin Smedberg writes:
Doug> It seems obvious to me that it would be easiest to just move today's
Doug> mainline over to GPLv3, and have every GCC release >= 4.3 be GPLv3. We
Doug> could then either cut off the GCC 4.2 branch entirely or leave it
Doug> GPLv2. Then there are no surprises f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Edelsohn wrote:
>> Doug Gregor writes:
>
> Doug> It seems obvious to me that it would be easiest to just move today's
> Doug> mainline over to GPLv3, and have every GCC release >= 4.3 be GPLv3. We
> Doug> could then either cut off the GCC 4.
> Feel free to either (a) #ifdef out the first part of the test on IA64,
> or (b) delete the first part of the test altogether.
Since it fails on other platforms (b) seems like the better alternative.
OK to checkin this patch?
Steve Ellcey
[EMAIL PROTECTED]
2007-07-12 Steve Ellcey <[EMAIL P
On 12 July 2007 16:26, Mayank Kumar wrote:
> I want to know the major differences between gcc4.2 and gcc3.3. Can some
> one point to a document/page where I can find this information.
It doesn't exist in one nice document, but you can gather the cumulative
changes from the per-release-series c
I want to know the major differences between gcc4.2 and gcc3.3. Can some one
point to a document/page where I can find this information.
On 12 July 2007 16:06, Dave Korn wrote:
> On 12 July 2007 15:54, David Edelsohn wrote:
>
>>> Doug Gregor writes:
>>
>> Doug> It seems obvious to me that it would be easiest to just move today's
>> Doug> mainline over to GPLv3, and have every GCC release >= 4.3 be GPLv3.
>> We Doug> could the
> Dave Korn writes:
Doug> could then either cut off the GCC 4.2 branch entirely or leave it
Doug> GPLv2. Then there are no surprises for anyone.
>> Leaving released branches as GPLv2 is not an option.
Dave> What, even *closed* release branches?
The comment referred to GCC 4.2. GCC
Dave Korn wrote:
On 12 July 2007 15:29, Doug Gregor wrote:
On 7/12/07, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote:
Mark Mitchell wrote:
3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3.
What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to
emphasize t
On 7/12/07, Dave Korn <[EMAIL PROTECTED]> wrote:
On 12 July 2007 15:29, Doug Gregor wrote:
> I had the same reaction. A new major release of GCC
Ok, hadn't you better both stop right there. "Major" release?
"significantly" affect the version numbering? We're going from 4.2 to 4.3.
That's the
On 12 July 2007 15:54, David Edelsohn wrote:
>> Doug Gregor writes:
>
> Doug> It seems obvious to me that it would be easiest to just move today's
> Doug> mainline over to GPLv3, and have every GCC release >= 4.3 be GPLv3. We
> Doug> could then either cut off the GCC 4.2 branch entirely or le
> Doug Gregor writes:
Doug> It seems obvious to me that it would be easiest to just move today's
Doug> mainline over to GPLv3, and have every GCC release >= 4.3 be GPLv3. We
Doug> could then either cut off the GCC 4.2 branch entirely or leave it
Doug> GPLv2. Then there are no surprises for any
> Ian Lance Taylor writes:
Ian> To pile on after my earlier message, I would say that the change in
Ian> license does not matter at all, not even a tiny bit, for gcc *users*.
Ian> It only matters for gcc *distributors*. And I think the vastly
Ian> smaller population of gcc distributors can be
On 7/12/07, David Edelsohn <[EMAIL PROTECTED]> wrote:
> Doug Gregor writes:
Doug> Could we ask the SC to reconsider the change in the GCC major version
Doug> numbering for GPLv3? Or, at the very least, explain why it is
Doug> important to change the major version number for a mere license
Do
David Edelsohn <[EMAIL PROTECTED]> writes:
> > Doug Gregor writes:
>
> Doug> Could we ask the SC to reconsider the change in the GCC major version
> Doug> numbering for GPLv3? Or, at the very least, explain why it is
> Doug> important to change the major version number for a mere license
> Do
"Venkatesan Jeevanandam" <[EMAIL PROTECTED]> writes:
> DISCLAIMER:
> This message (including attachment if any) is confidential and may be
> privileged. Before opening attachments please check them for viruses and
> defects. MindTree Consulting Limited (MindTree) will not be responsible for
> a
Mark Mitchell <[EMAIL PROTECTED]> writes:
> 2. GCC 4.2.1 will be the last GPLv2 release. The FSF will permit
> backports from mainline to GCC 4.2.1, if necessary, to be downlicensed
> to GPLv2, as part of that release.
I believe that we should make a clear statement with that release that
any fu
On 12 July 2007 15:29, Doug Gregor wrote:
> On 7/12/07, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote:
>> Mark Mitchell wrote:
>>> 3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3.
>>> What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to
>>> emphasize the GP
> Doug Gregor writes:
Doug> Could we ask the SC to reconsider the change in the GCC major version
Doug> numbering for GPLv3? Or, at the very least, explain why it is
Doug> important to change the major version number for a mere license
Doug> change?
To avoid confusion among GCC users
On 7/12/07, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote:
Mark Mitchell wrote:
> 3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3.
> What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to
> emphasize the GPLv3 switch. The GCC mainline will then be GCC 4.4.
Mark Mitchell wrote:
The GCC SC is still discussing a few of the finer points of the
transition to GPLv3.[...]
Good!
Here is my initial opinion on some point you asked; but please ignore it if it
hurts somebody!
3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3.
What
Hi Thomas,
> bootstrap is broken on trunk during stage1:
Seems to be not in general. It is related to the whitespaces for the new
types used in splay-tree.h. If shrink them, it seems to work as Uros
detected. This smells, that the gengtype-lex.l has problems about too much
spaces in a typedef.
=15400== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==15400== Using valgrind-3.2.1, a dynamic binary instrumentation framework.
==15400== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==15400== For more details, rerun with: -v
==15400==
GNU C versi
Hi Mark,
Will someone (or someones) please volunteer to change the various files
that mention GPLv2 to mention GPLv3 instead, to change the COPYING file
in the gcc/ directory, and to look for other things that need to change?
I volunteer.
It has not yet been decided what to do about files th
On 12 Jul 2007 04:37:20 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
| The GCC SC is still discussing a few of the finer points of the
| transition to GPLv3.
Thanks for the update!
[...]
| 3. After GCC 4.2.1 is released, we will renumber the br
Mark Mitchell <[EMAIL PROTECTED]> writes:
| The GCC SC is still discussing a few of the finer points of the
| transition to GPLv3.
Thanks for the update!
[...]
| 3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3.
| What would have been GCC 4.2.2 will instead be GCC 4.3.3
From: Venkatesan Jeevanandam
Sent: Thursday, July 12, 2007 2:38 PM
To: [EMAIL PROTECTED]; gcc@gcc.gnu.org
Subject: GDB testsuite + dejagnu uses gcc compiler by default, how to
configure testsuite to use other 'c' compilers (like cross compilers arm-cc,
et
Hi,
I am nearly through :) The remaining macros left to be ported are
REGPARM_MAX and SSE_REGPARM_MAX. The sysv_abi uses 6 regs and 8 sses,
ms_abi uses 4 regs and 4 sse registers. The problem is for example the use
in i386.md of SSE_REGPARM_MAX without any hint, how to choose the required
abi.
From: Venkatesan Jeevanandam
Sent: Thursday, July 12, 2007 2:40 PM
To: '[EMAIL PROTECTED]'; 'gcc@gcc.gnu.org'
Subject: RE: GDB testsuite + dejagnu uses gcc compiler by default, how to
configure testsuite to use other 'c' compilers (like cross compilers ar
1 - 100 of 102 matches
Mail list logo
