On 17 Feb 2005, Marc Espie said:
> No need for fsh or anything. Didn't this feature make it into portable
> openssh ?
Yes, it did, but as usual with OpenSSH entirely without documentation
other than a changelog entry and silent change to the manpage describing
the extra options but not how to use
Regression went from 16 to 143:
http://gcc.gnu.org/ml/gcc-testresults/2005-02/msg00758.html
Any idea of what may have caused this?
Laurent
Matt Austern wrote:
By the way, it's up to you what to do exactly with libstdc++/19554...
I think I agree with you: no point in fixing enhancement requests in
obsolete components
Fine, I closed it as WONTFIX (the audit trail explains sufficiently
clearly, in my opinion, what WONTFIX means in this
Don Lindsay wrote:
On Feb 17, 2005, at 9:52 AM, Davide Rossetti wrote:
I remember I read on this mlist about a testing tool. a script or
something which took a source file in input and tried to swap lines
and compile it, then reported results... can't google it exacly.. any
help ??
H
Syed Shabir Zakiullah <[EMAIL PROTECTED]> writes:
> While building gcc-3.4.3 I am getting following error during make stage.
>
> ../../../libiberty/cplus-dem.c:55: error: conflicting types for 'malloc'
> ../../../libiberty/cplus-dem.c:55: error: conflicting types for 'malloc'
> ../../../libibert
> Regression went from 16 to 143:
>
> http://gcc.gnu.org/ml/gcc-testresults/2005-02/msg00758.html
Yup.
> Any idea of what may have caused this?
2005-02-17 Jason Merrill <[EMAIL PROTECTED]>
PR mudflap/19319, c++/19317
* gimplify.c (gimplify_modify_expr_rhs) [CALL_EXPR]: Make re
Jason,
Your patch has caused a lot of breakage for many platforms
and languages. It seems clear that it is far too intrusive
to apply in this stage.
Please revert your patch.
Thanks in advance,
-Geert
On Feb 18, 2005, at 12:14, Eric Botcazou wrote:
Regression went from 16 to 143:
http://gcc.gnu.o
Subject:
PATCH: TR1 unordered associative containers
From:
Matt Austern <[EMAIL PROTECTED]>
Date:
Thu, 17 Feb 2005 15:47:03 -0800
To:
libstdc++ <[EMAIL PROTECTED]>, gcc mailing list
To:
libstdc++ <[EMAIL PROTECTED]>, gcc mailing list
+ template
+ const unsigned long X::primes[n_primes + 1] =
+
On Feb 18, 2005, at 9:58 AM, R. D. Flowers wrote:
If this is supposed to be a list of SOME primes, no problem.
If it is supposed to be a list of ALL primes up to that size, YES a
problem.
It is supposed to be a list of some primes less than 2^32. A list of
all primes up to that size would be too
Is there a reason REG_POINTER isn't propagated to the target register for
rtl insns of the form "reg_x = regP_y + reg_z", where regP_y is a reg
marked as REG_POINTER? It seems the attribute is only propagated when we
have "reg_x = regP_y + CONST", at least in the couple instances I saw
(regcla
On Wed, Feb 16, 2005 at 10:59:00PM -0500, Jason Merrill wrote:
> I suspect that the problem is that the transformations fold_indirect_ref_1
> is doing on arrays don't mix well with how fortran handles arrays.
I have been trying to look at the problem in the BLAS sources,
and I find it hard to deb
Thomas Koenig wrote:
> On Wed, Feb 16, 2005 at 10:59:00PM -0500, Jason Merrill wrote:
>>I suspect that the problem is that the transformations fold_indirect_ref_1
>>is doing on arrays don't mix well with how fortran handles arrays.
>
>
> I have been trying to look at the problem in the BLAS sourc
On Feb 18, 2005, at 5:12 PM, Thomas Koenig wrote:
On Wed, Feb 16, 2005 at 10:59:00PM -0500, Jason Merrill wrote:
I suspect that the problem is that the transformations
fold_indirect_ref_1
is doing on arrays don't mix well with how fortran handles arrays.
I have been trying to look at the problem i
> Your analysis is correct, see http://gcc.gnu.org/PR20030 :-) A fix has already
> been committed.
Thanks, I should have searched the PRs more carefully before starting
work on this :-)
On Fri, Feb 18, 2005 at 05:16:29PM -0500, Andrew Pinski wrote:
>
> On Feb 18, 2005, at 5:12 PM, Thomas Koenig wrote:
>
> >On Wed, Feb 16, 2005 at 10:59:00PM -0500, Jason Merrill wrote:
> >
> >>I suspect that the problem is that the transformations
> >>fold_indirect_ref_1
> >>is doing on arrays d
* Paolo Bonzini:
> and these do not include regex character ranges. LC_COLLATE would only
> be used for sorting and for string comparisons.
You end up with similar behavior if you read the POSIX spec carefully,
IIRC. LC_COLLATE should not affect character ranges.
Florian Weimer <[EMAIL PROTECTED]> writes:
> * Paolo Bonzini:
>
>> and these do not include regex character ranges. LC_COLLATE would only
>> be used for sorting and for string comparisons.
>
> You end up with similar behavior if you read the POSIX spec carefully,
> IIRC. LC_COLLATE should not a
Snapshot gcc-3.4-20050218 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050218/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 CVS branch
with the following options: -rgcc-ss-3_4-20050218
You'll
Christopher Faylor wrote:
> I don't think fsh is a good idea. That could mean potentially hundreds
> of persistent ssh connections sitting around on the server.
There would at most be one per user making commits to the depot. Do
you really have hundreds of people making commits? You probably ha
19 matches
Mail list logo
