GCC 4.1.0 RC1 is here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.0-20060219
Please download, build, and test. Please use these tarballs, rather
than the current SVN branch, so that we test packaging, and other
similar issues.
If you find problems, please do not send me email directly; instead
Hello,
> 1) single_set is built on top of single_set2.
> 2) single_set_2 uses REG_UNUSED notes.
> 3) tree-ssa-loop-ivops.c:seq_cost uses single_set.
>
> I can find no indication that rtl dfa is run here to provide the
> information for single_set to produce the correct answer.
it is not. Nevert
On Sun, 19 Feb 2006, Mark Mitchell wrote:
| In the past, we've had a confusing situation for users, in which
| "upgrading" from one branch to another could result in known
| regressions. In particular, consider our current situation:
|
| * GCC 4.0.2 is the latest release on the 4.0 branch.
|
| *
On Sun, 19 Feb 2006, Mark Mitchell wrote:
| Matthias Klose wrote:
| > Mark Mitchell writes:
| >> and the 3.4.x branch is official dead at this point.
| >
| > No, see http://gcc.gnu.org/ml/gcc/2005-12/msg00189.html
|
| My mistake; thanks for the pointer.
|
| However, that doesn't change the general
Some projects have a time-based release strategy
(e.g. "we release once every six months").
Would it make sense for gcc to do that
for all maintenance releases? e.g.
leave the current process the same for .0
versions, which users are scared of anyway,
but coordinate all other releases
to occur on
Mark Mitchell <[EMAIL PROTECTED]> writes:
> In the past, we've had a confusing situation for users, in which
> "upgrading" from one branch to another could result in known
> regressions. In particular, consider our current situation:
>
> * GCC 4.0.2 is the latest release on the 4.0 branch.
>
> *
Matthias Klose wrote:
> Mark Mitchell writes:
>> and the 3.4.x branch is official dead at this point.
>
> No, see http://gcc.gnu.org/ml/gcc/2005-12/msg00189.html
My mistake; thanks for the pointer.
However, that doesn't change the general thrust of my mail; the only
issue is how soon we must be
Daniel Berlin wrote:
> On Sun, 2006-02-19 at 09:56 -0500, Kenneth Zadeck wrote:
>
>> Steven, Zdenek
>>
>> 1) single_set is built on top of single_set2.
>>
> Yes
>
>> 2) single_set_2 uses REG_UNUSED notes.
>>
> Only if there are multiple sets.
>
>
>> 3) tree-ssa-loop-ivops.c:seq_c
Mark Mitchell writes:
> and the 3.4.x branch is official dead at this point.
No, see http://gcc.gnu.org/ml/gcc/2005-12/msg00189.html
Matthias
In the past, we've had a confusing situation for users, in which
"upgrading" from one branch to another could result in known
regressions. In particular, consider our current situation:
* GCC 4.0.2 is the latest release on the 4.0 branch.
* GCC 4.1 will be released soon.
* GCC 4.0.3 will be rel
On Feb 19, 2006, at 2:39 PM, Andrew Pinski wrote:
Now I run into another problem:
/var/tmp//ccBWaqmT.s:130:Fixup of 1073745640 too large for field width
of 26 bits
We have a 1GB decl here. So the section that this decl goes into
is between the TEXT section and the stub section which causes t
Laurent GUERBY wrote:
On Sun, 2006-02-19 at 14:23 -0500, Richard Kenner wrote:
"Second, for a given integer type (such as
natural___XDLU_0_2147483647), the type for the nodes in TYPE_MIN_VALUE
and TYPE_MAX_VALUE really should be a natural___XDLU_0_2147483647.
ie, the type of an i
> No, the type of the bounds of a subtype should be the *base type*.
> That's how the tree has always looked, as far back as I can remember.
This is because intermediate computations can produce results
outside the subtype range but within the base type range (RM 3.5(6)),
rig
On Sun, 2006-02-19 at 14:23 -0500, Richard Kenner wrote:
> "Second, for a given integer type (such as
> natural___XDLU_0_2147483647), the type for the nodes in TYPE_MIN_VALUE
> and TYPE_MAX_VALUE really should be a natural___XDLU_0_2147483647.
> ie, the type of an integer constant s
On Feb 19, 2006, at 4:26 AM, Richard Sandiford wrote:
Have you thought about overriding the output_anchor hook for Darwin?
It sounds simpler than what you did in the patch, and the hook was
there specifically for cases where the ASM_OUTPUT_DEF thing wouldn't
work.
That is a good idea, thanks.
"Second, for a given integer type (such as
natural___XDLU_0_2147483647), the type for the nodes in TYPE_MIN_VALUE
and TYPE_MAX_VALUE really should be a natural___XDLU_0_2147483647.
ie, the type of an integer constant should be the same as the type of
its min/max values."
No, th
> Anyway, hopefully Eric and Jeff can work together in identifying the
> proper fix.
Jeff already did a thorough analysis of the problem (thanks!) and came to the
following double conclusion. Quoting him:
"First, the inconsistency between the type's precision in its min/max
values needs to be f
I will be spinning RC1 this morning, as previously announced.
I know that there are some outstanding patches in my email, which people
have requested for 4.1. I'll review those before producing RC1, and
apply them to the 4.1 branch myself if appropriate; I'll still ask the
original submitters to
Laurent GUERBY writes:
> On Fri, 2006-02-17 at 22:43 +, Joern RENNECKE wrote:
> > Has anybody done timings for gcc bootstrap / cross builds and regtests
> > with modern multi-core processors? I wonder what a sensible modern
> > configuration would be for gcc development, but the the mult
Andrew Pinski writes:
>
> On Feb 19, 2006, at 12:09 PM, Andrew Haley wrote:
>
> > When building a-textio in libada, today's gcc build fails when memory
> > is exhausted.
>
> This has already been reported as PR 26348 and it looks like a bug
> in the Ada front-end.
Oh right, thanks. Was
Andrew Haley <[EMAIL PROTECTED]> writes:
> When building a-textio in libada, today's gcc build fails when memory
> is exhausted.
This is PR26348.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58
> This has already been reported as PR 26348 and it looks like a bug
> in the Ada front-end.
Note that technically, its still a regression caused by a non Ada patch.
Anyway, hopefully Eric and Jeff can work together in identifying the
proper fix.
Arno
On Feb 19, 2006, at 12:09 PM, Andrew Haley wrote:
When building a-textio in libada, today's gcc build fails when memory
is exhausted.
This has already been reported as PR 26348 and it looks like a bug
in the Ada front-end.
Thanks,
Andrew Pinski
When building a-textio in libada, today's gcc build fails when memory
is exhausted.
Seems like VRP is looping, consuming more and more memory.
Andrew.
make[7]: `a-teioed.o' is up to date.
/home/aph/gcc/build-x86_64-unknown-linux-gnu/./gcc/xgcc
-B/home/aph/gcc/build-x86_64-unknown-linux-gnu/./
On Sun, 2006-02-19 at 09:56 -0500, Kenneth Zadeck wrote:
> Steven, Zdenek
>
> 1) single_set is built on top of single_set2.
Yes
> 2) single_set_2 uses REG_UNUSED notes.
Only if there are multiple sets.
> 3) tree-ssa-loop-ivops.c:seq_cost uses single_set.
This is because Zdenek builds RTL to dete
Steven, Zdenek
1) single_set is built on top of single_set2.
2) single_set_2 uses REG_UNUSED notes.
3) tree-ssa-loop-ivops.c:seq_cost uses single_set.
I can find no indication that rtl dfa is run here to provide the
information for single_set to produce the correct answer.
Inquiring minds want t
Andrew Pinski <[EMAIL PROTECTED]> writes:
> Since -fsection-anchors is very useful for PPC-Darwin, I decided to
> see what I needed to do to support them.
> I started by just doing a bootstrap with them enabled by default
> and ran into the first issue of SET_ASM_OP not being set. Next
> I ran int
27 matches
Mail list logo
