On 12 July 2007 05:21, [EMAIL PROTECTED] wrote:
On 7/10/07, [EMAIL PROTECTED] writes:
On 7/10/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: You haven't
explained what advantages CIL's IR has over GIMPLE. I thought it was
well explained on page:
Hi,
bootstrap is broken on trunk during stage1:
echo '/home/xtv/gcc-devel/gcc/gcc/c-common.c' tmp-gi.list
echo '/home/xtv/gcc-devel/gcc/gcc/c-common.h' tmp-gi.list
echo '/home/xtv/gcc-devel/gcc/gcc/c-pragma.h' tmp-gi.list
echo '/home/xtv/gcc-devel/gcc/gcc/c-pragma.c' tmp-gi.list
echo
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
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
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,
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
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
) 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 version 4.3.0 20070712 (experimental) (powerpc64
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.
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.
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.
I
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 who do
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 GPLv3 switch.
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 future
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
any
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
Doug change?
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
Doug
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 reached
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 anyone.
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 leave it
Doug
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 MINOR
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
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 4.2
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 then either cut off the
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: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
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
-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.2 branch
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 for
-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 should
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
them
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 all
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.
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.
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 able to
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 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 original
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
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 come
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 into
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
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.)
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
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 has not yet
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
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 file are
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
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
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 the last
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
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
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.
I
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.
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
$.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
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
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 that
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
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
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 understand
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 4.4.0,
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
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 are
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
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.
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
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.gplv3 are licensed under GPLv3.
Patches applied to previous versions are licensed under
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
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
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
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 sad
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
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
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
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
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
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 that
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
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
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 be
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
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
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
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
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
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
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
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
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_INT.
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2007-07-12 06:00
---
We have a problem of 'doubling up the directories'. This _always_ occurs for
platform i686-pc-cygwin as described here (with a FIX):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30341
Please do not pollute
--- Comment #5 from ubizjak at gmail dot com 2007-07-12 06:08 ---
(In reply to comment #4)
bootstrap to be done). The problem was reported on m68k initially but I
checked
FWIW, the problem was reported on i686-pc-linux-gnu, but it is generic RTL
missed-optimization problem.
BTW:
--- Comment #6 from dougkwan at google dot com 2007-07-12 06:17 ---
Subject: Re: [4.0/4.1/4.2/4.3 regression] Missing byte swap optimizations
I misread one of the earlier comments when I typed the reply. So I
thought it was reported on the m68k first. I agree that adding test
cases
--- Comment #7 from mark at codesourcery dot com 2007-07-12 06:20 ---
Subject: Re: [4.1 Regression] ICE in resolve_overloaded_unification
reichelt at gcc dot gnu dot org wrote:
templatetypename struct A
{
A operator(void (*)(A));
};
templatetypename T AT operator(AT, const
--- Comment #6 from pault at gcc dot gnu dot org 2007-07-12 06:22 ---
(In reply to comment #5)
Daniel,
Hmmm! Cancel that - I'll have a slot this evening where I can either fix it or
revert it myself. Just leave it to me but, I'll let you know if I am unable to
do the business.
Paul
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-07-12 06:31 ---
Subject: Bug 32634
Author: dfranke
Date: Thu Jul 12 06:31:12 2007
New Revision: 126572
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126572
Log:
2007-07-12 Daniel Franke [EMAIL PROTECTED]
PR
--- Comment #7 from dfranke at gcc dot gnu dot org 2007-07-12 06:31 ---
Subject: Bug 32727
Author: dfranke
Date: Thu Jul 12 06:31:12 2007
New Revision: 126572
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126572
Log:
2007-07-12 Daniel Franke [EMAIL PROTECTED]
PR
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-07-12 06:35 ---
Reverted patch and re-opened as requested in PR32727.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from dfranke at gcc dot gnu dot org 2007-07-12 06:36 ---
Sorry, too late :(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32727
--- Comment #9 from jv244 at cam dot ac dot uk 2007-07-12 06:57 ---
(In reply to comment #8)
Sorry, too late :(
Fine with me :-), I can give gfortran another round of testing today... thanks
BTW, if you revert a patch, you should add the testcase that is the reason it.
To avoid
--- Comment #5 from ubizjak at gmail dot com 2007-07-12 07:05 ---
(In reply to comment #3)
regmove should have changed that but it does not probably because the final
constraint does not have a duplicate operand. Actually, I think you want to
look at anddi_1_rex64, not
1 - 100 of 202 matches
Mail list logo
