Re: Accessing the subversion repository
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 them. As a result, I wasn't sure how to use it for anything. Your example there is the first I've seen, and is decidedly helpful: thanks! -- > ...Hires Root Beer... What we need these days is a stable, fast, anti-aliased root beer with dynamic shading. Not that you can let just anybody have root. --- John M. Ford
Ada totally borken on x86-linux
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
Re: PATCH: TR1 unordered associative containers
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 specific case) Paolo.
Re: OT: combinatorial source line swapper test
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 ?? Here's something vaguely related: a quick hack for shrinking testcases, when you're looking for a cutdown that still exhibits some still-mysterious failure. nice snippet :) thanks a lot to both Mike and Don...
Re: Error while building gcc-3.4.3 !
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' > ../../../libiberty/cplus-dem.c: In function `code_for_qualifier': > ../../../libiberty/cplus-dem.c:630: warning: implicit declaration of function > `abort' > ../../../libiberty/cplus-dem.c: In function `squangle_mop_up': > ../../../libiberty/cplus-dem.c:1154: warning: implicit declaration of > function > `free' > ../../../libiberty/cplus-dem.c: In function `demangle_qualified': > ../../../libiberty/cplus-dem.c:3310: warning: implicit declaration of > function > `atoi' > make: *** [cplus-dem.o] Error 1 > > > Can any one help me to fix this error, I searched net but didnot find any > information on this. BTW: I am using Glibc-2.3.4 with NPTL+LinuxThreads. For some reason the libiberty configure script thinks that you don't have on your system. There should be a file named something like libiberty/config.log; look at that to see if you see any errors related to . Ian
Re: Ada totally borken on x86-linux
> 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 return slot explicit. -- Eric Botcazou
Re: Ada totally borken on x86-linux
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.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 return slot explicit.
Re: PATCH: TR1 unordered associative containers
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] =
+ {
+ 2ul, 3ul, 5ul, 7ul, 11ul, 13ul, 17ul, 19ul, 23ul, 29ul, 31ul,
+ 37ul, 41ul, 43ul, 47ul, 53ul, 59ul, 61ul, 67ul, 71ul, 73ul, 79ul,
+ 83ul, 89ul, 97ul, 103ul, 109ul, 113ul, 127ul, 137ul, 139ul, 149ul,
+ 157ul, 167ul, 179ul, 193ul, 199ul, 211ul, 227ul, 241ul, 257ul,
+ 277ul, 293ul, 313ul, 337ul, 359ul, 383ul, 409ul, 439ul, 467ul,
+ 503ul, 541ul, 577ul, 619ul, 661ul, 709ul, 761ul, 823ul, 887ul,
+ 953ul, 1031ul, 1109ul, 1193ul, 1289ul, 1381ul, 1493ul, 1613ul,
+ 1741ul, 1879ul, 2029ul, 2179ul, 2357ul, 2549ul, 2753ul, 2971ul,
+ 3209ul, 3469ul, 3739ul, 4027ul, 4349ul, 4703ul, 5087ul, 5503ul,
+ 5953ul, 6427ul, 6949ul, 7517ul, 8123ul, 8783ul, 9497ul, 10273ul,
+ 3ul, 12011ul, 12983ul, 14033ul, 15173ul, 16411ul, 17749ul,
+ 19183ul, 20753ul, 22447ul, 24281ul, 26267ul, 28411ul, 30727ul,
+ 33223ul, 35933ul, 38873ul, 42043ul, 45481ul, 49201ul, 53201ul,
+ 57557ul, 62233ul, 67307ul, 72817ul, 78779ul, 85229ul, 92203ul,
+ 99733ul, 107897ul, 116731ul, 126271ul, 136607ul, 147793ul,
+ 159871ul, 172933ul, 187091ul, 202409ul, 218971ul, 236897ul,
+ 256279ul, 277261ul, 299951ul, 324503ul, 351061ul, 379787ul,
+ 410857ul, 87ul, 480881ul, 520241ul, 562841ul, 608903ul,
+ 658753ul, 712697ul, 771049ul, 834181ul, 902483ul, 976369ul,
+ 1056323ul, 1142821ul, 1236397ul, 1337629ul, 1447153ul, 1565659ul,
+ 1693859ul, 1832561ul, 1982627ul, 2144977ul, 2320627ul, 2510653ul,
+ 2716249ul, 2938679ul, 3179303ul, 3439651ul, 3721303ul, 4026031ul,
+ 4355707ul, 4712381ul, 5098259ul, 5515729ul, 5967347ul, 6456007ul,
+ 6984629ul, 7556579ul, 8175383ul, 8844859ul, 9569143ul, 10352717ul,
+ 11200489ul, 12117689ul, 13109983ul, 14183539ul, 15345007ul,
+ 16601593ul, 17961079ul, 19431899ul, 21023161ul, 22744717ul,
+ 24607243ul, 26622317ul, 28802401ul, 31160981ul, 33712729ul,
+ 36473443ul, 39460231ul, 42691603ul, 46187573ul, 49969847ul,
+ 54061849ul, 58488943ul, 63278561ul, 68460391ul, 74066549ul,
+ 80131819ul, 86693767ul, 93793069ul, 101473717ul, 109783337ul,
+ 118773397ul, 128499677ul, 139022417ul, 150406843ul, 162723577ul,
+ 176048909ul, 190465427ul, 206062531ul, 222936881ul, 241193053ul,
+ 260944219ul, 282312799ul, 305431229ul, 330442829ul, 357502601ul,
+ 386778277ul, 418451333ul, 452718089ul, 489790921ul, 529899637ul,
+ 573292817ul, 620239453ul, 671030513ul, 725980837ul, 785430967ul,
+ 849749479ul, 919334987ul, 994618837ul, 1076067617ul, 1164186217ul,
+ 1259520799ul, 1362662261ul, 1474249943ul, 1594975441ul,
+ 1725587117ul, 1866894511ul, 2019773507ul, 2185171673ul,
+ 2364114217ul, 2557710269ul, 2767159799ul, 2993761039ul,
+ 3238918481ul, 3504151727ul, 3791104843ul, 4101556399ul,
+ 4294967291ul,
+ 4294967291ul // sentinel so we don't have to test result of
lower_bound
+ };
+
Just checking.
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.
The first missing primes are 101 and 107. More and more are missing as
we get higher.
--
R. D. Flowers
19a5.02.01
Things have long and short names. The long name for the secret of life
(I say) is -- insistent truthful choice; the short name (I say) is --
heresy.
You cannot conform and be truthful.
allies ever sought.
http://chalice.us/poe
http://gccnews.chatta.us
http://chattablogs.com/rd0
Re: PATCH: TR1 unordered associative containers
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 large to be useful; the prime number theorem says that the list would have something like 190 million entries. --Matt
Propagation of "pointer" attribute on registers
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 (regclass.c:reg_scan_mark_refs() and explow.c:memory_address()). I've run across a case where lack of the REG_POINTER attribute is causing global PRE to miss a hoisting opportunity since a memory reference no longer looks available (memory disambiguation fails in alias.c:base_alias_check() since we can't determine the base address of the memory reference). -Pat
Re: Major regression on mainline
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 debug because it goes away when print statements are added to the source (I hate that...) Anyway, this looks like a character-related failure. The first error in the single precision level 2 BLAS routines is the following: * ILLEGAL VALUE OF PARAMETER NUMBER 1 NOT DETECTED BY SGEMV * *** SGEMV FAILED THE TESTS OF ERROR-EXITS *** The call to SGEMV happens in line 2325 in sblat2.f and looks like this: CALL SGEMV( '/', 0, 0, ALPHA, A, 1, X, 1, BETA, Y, 1 ) The argument list to SGEMV looks like this: SUBROUTINE SGEMV ( TRANS, M, N, ALPHA, A, LDA, X, INCX, $ BETA, Y, INCY ) * .. Scalar Arguments .. REAL ALPHA, BETA INTEGERINCX, INCY, LDA, M, N CHARACTER*1TRANS * .. Array Arguments .. REAL A( LDA, * ), X( * ), Y( * ) * .. and the first executable statements are IF ( .NOT.LSAME( TRANS, 'N' ).AND. $ .NOT.LSAME( TRANS, 'T' ).AND. $ .NOT.LSAME( TRANS, 'C' ) )THEN INFO = 1 ... where LSAME is a logical function that compares single-character strings for equality. For some reason that I can't fathom, the INFO=1 statement isn't reached. If the statement print *,trans is insterted before the if statement, the failure in question does not occur. That's as far as I could get. You can get BLAS from netlib if you download LAPACK. Thomas
Re: Major regression on mainline
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 sources, > and I find it hard to debug because it goes away when print > statements are added to the source (I hate that...) > > Anyway, this looks like a character-related failure. The first error > in the single precision level 2 BLAS routines is the following: Your analysis is correct, see http://gcc.gnu.org/PR20030 :-) A fix has already been committed. Regards, - Tobi
Re: Major regression on mainline
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 in the BLAS sources, and I find it hard to debug because it goes away when print statements are added to the source (I hate that...) Wasn't this fixed by my patch which I applied this morning: 2005-02-18 Andrew Pinski <[EMAIL PROTECTED]> PR middle-end/20030 * fold-const.c (fold_indirect_ref_1): Use the correct index for zero access, the lower bound of the array type if it exists. -- Pinski
Re: Major regression on mainline
> 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 :-)
Re: Major regression on mainline
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 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 debug because it goes away when print > >statements are added to the source (I hate that...) > > > > Wasn't this fixed by my patch which I applied this morning: > > 2005-02-18 Andrew Pinski <[EMAIL PROTECTED]> > > PR middle-end/20030 > * fold-const.c (fold_indirect_ref_1): Use the correct index for > zero access, > the lower bound of the array type if it exists. > Yes, your patch fixed the problem. -- Steve
Re: LC_COLLATE
* 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.
Re: LC_COLLATE
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 affect character ranges. POSIX defines the behaviour of ranges only in the POSIX locale. In any other locale the behaviour is unspecified. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
gcc-3.4-20050218 is now available
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 find: gcc-3.4-20050218.tar.bz2 Complete GCC (includes all of below) gcc-core-3.4-20050218.tar.bz2 C front end and core compiler gcc-ada-3.4-20050218.tar.bz2 Ada front end and runtime gcc-g++-3.4-20050218.tar.bz2 C++ front end and runtime gcc-g77-3.4-20050218.tar.bz2 Fortran 77 front end and runtime gcc-java-3.4-20050218.tar.bz2 Java front end and runtime gcc-objc-3.4-20050218.tar.bz2 Objective-C front end and runtime gcc-testsuite-3.4-20050218.tar.bz2The GCC testsuite Diffs from 3.4-20050211 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-3.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Accessing the subversion repository
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 have hundreds of people pulling sources by anonymous read-only access but that is a different path. I will agree that the default timeout value for fsh is too long. The default is apparently ten hours unless changed. For me personally 15 minutes is a good value and I would set the default on the server to something short. Bob
