On 2005-02-17 01:15:29 +0100, Marcin Dalecki wrote:
> On 2005-02-16, at 12:32, Vincent Lefevre wrote:
> >Do not use the MPFR version that comes with GMP. It is too old.
> >Remember that you can override the default by setting CFLAGS.
>
> The documentation doesn't say this. The configure scripts do
Index: MAINTAINERS
===
RCS file: /cvs/gcc/gcc/MAINTAINERS,v
retrieving revision 1.395
diff -c -3 -p -r1.395 MAINTAINERS
*** MAINTAINERS 14 Feb 2005 11:21:09 - 1.395
--- MAINTAINERS 17 Feb 2005 08:50:31 -
**
Hi, there:
I tried using the "-fprofile-arcs" and "-fbranch-probabilities" to build a
profile based optimized binary, but got some complain about the .da files.
The OS: Red Hat Enterprise Linux WS release 3 (Taroon Update 3) Kernel
2.4.21-20.ELsmp on an x86_64
The GCC: gcc (GCC) 3.2.3 20030502 (
On 2005-02-17 01:48:37 +0100, Marc Espie wrote:
> Dare I say it ?
> I don't want any locale behavior in a version control system.
> Specifically because there are client/server issues, and you never
> know which is which. I've seen enough trouble with cvs timestamps.
>
> If/when gcc switches to s
On Wed, 16 Feb 2005 10:51:58 -0500, Andrew Pinski
<[EMAIL PROTECTED]> wrote:
>
> On Feb 16, 2005, at 10:49 AM, Theodore Papadopoulo wrote:
>
> > Then, I must add that I do not know much about the compiler's
> > internals...
>
> If a[-1] os converted to a[(unsigned)-1], this is fine iff unsigned
Hello All
We are trying to fix the already ported GCC 2.95 on the ABACUS processor.
ABACUS processor is very much similar to SPARC from SUN.
We are facing 2 major problems in the fixing.
1. Variable initialization within block: If we declare and initialize a
variable within a block in the functi
> Recent versions of openssh support multiple connections through one
> single authentication token (`master' connection)
That might work, but you need version OpenSSH 3.9 I think. svn.toolchain.org
is running 3.8.1p1 and gcc.gnu.org is running 3.6.1p2.
I assume both ends need to support it but I
In article <[EMAIL PROTECTED]> you write:
>AFAIK, Subversion uses UTC time internally, but always works with the
>local time of the user for the interface (I don't know what happens for
>ambiguous dates, due to summer/winter times). Anyway, Subversion has
>global revisions, so that doing a dichotom
Hello,
I reported 2 bugs (bug19951 and bug19952) on Monday which were
apparently reproduced the same day.
However their status remains UNCONFIRMED.
As far as I understand the bugzilla system the status of a bug is set
to NEW if it is verified that this is indeed a bug.
Also if their status would
Michael Cieslinski <[EMAIL PROTECTED]> wrote:
> I reported 2 bugs (bug19951 and bug19952) on Monday which were
> apparently reproduced the same day.
> However their status remains UNCONFIRMED.
It must have been an oversight on our side.
Giovanni Bajo
On Wed, 9 Feb 2005, Mark Mitchell wrote:
> As for making all proposals public, some people have asked that they be
> kept confidential because they didn't want to put out ideas publicly
> that were going to have no chance of being included.
Personally, that sounds somewhat strange for contributi
Hi!
I'm getting an ICE in
/net/pherkad/scratch/rguenth/gcc/gcc/testsuite/gcc.dg/pr18241-2.c: In
function 'radix_tree_tag_clear':
/net/pherkad/scratch/rguenth/gcc/gcc/testsuite/gcc.dg/pr18241-2.c:24:
internal compiler error: tree check: expected integer_type or
enumeral_type or boolean_type or cha
I'm hoping someone knows what this is due to, can't see anything in bugzilla.
$ cat bug.c
long double f = __LDBL_MAX__;
$ gcc4x -c bug.c
$ gcc4x -c bug.c -pedantic -save-temps
bug.c: In function 'main':
bug.c:1: error: floating constant exceeds range of 'long double'
I only get the error with -p
> Richard Guenther wrote:
> I'm getting an ICE in
> this is because I'm feeding int_fits_type_p a (constant) pointer type:
- Wonder if because it was assumed that a pointer may most typically never
numerically "fit" an (signed) int without overflow, but as I think you're
relying on the numeric
On Thu, 17 Feb 2005, Paul Schlie wrote:
> > Richard Guenther wrote:
> > I'm getting an ICE in
> > this is because I'm feeding int_fits_type_p a (constant) pointer type:
Actually I was feeding it a constant integer trying to ask if it would
fit a pointer type. This makes TYPE_MIN_VALUE fail. All
On Thu, Feb 17, 2005 at 01:22:30PM +, Jonathan Wakely wrote:
>
> I'm hoping someone knows what this is due to, can't see anything in bugzilla.
>
> $ cat bug.c
> long double f = __LDBL_MAX__;
> $ gcc4x -c bug.c
> $ gcc4x -c bug.c -pedantic -save-temps
> bug.c: In function 'main':
> bug.c:1: e
The sort alghorithm has nothing to do with ls, but with your selection of
LC_COLLATE. But then, BSD (at least the variant used in MacOSX) is way
behind current l10n standards.
At least they do not break s/[A-Z]// which on "well-internationalized"
OSes is case-insensitive with most locales other t
On 2005-02-17 12:48:03 +0100, Marc Espie wrote:
> Bottom-line: it's very easy to shoot oneself in the foot while writing
> wrapper scripts. The default interface will give you local time listing,
> anything you generate from that will have localtime listing, so any
> `nice' meta-generated informat
On Thu, 2005-02-17 at 12:48 +0100, Marc Espie wrote:
> In article <[EMAIL PROTECTED]> you write:
> >AFAIK, Subversion uses UTC time internally, but always works with the
> >local time of the user for the interface (I don't know what happens for
> >ambiguous dates, due to summer/winter times). Anywa
Hi,
Is there a way to determine if the given RTX is
accessing an array element or not? If yes, how do I determine the
static size of that array from the given RTX?
Thanks a lot in advance.
regards,
Raj
Hi
on my i486-unknown-elf target i am unable to use #pragma pack(push[,n]) /
#pragma pop(n), which happen to be the same as Microsofts #pragma syntax.
this is because HANDLE_PRAGMA_PACK_PUSH_POP is only defined for
linux/i386/alpha/sparc freebsd and others.
Is this correct ?, comments in the a
> Please add your testcase to PR19883 and mention that this is
breaking boost.
Giovanni Bajo
OK, done!
-BenRI
On Thu, Feb 17, 2005 at 05:09:55PM +0800, [EMAIL PROTECTED] wrote:
> Hi, there:
> I tried using the "-fprofile-arcs" and "-fbranch-probabilities" to build a
> profile based optimized binary, but got some complain about the .da files.
> ...
> The fail message is:
> /usr/include/bits/sigset.h: At to
On Wed, 9 Feb 2005, Mark Mitchell wrote:
> > As for making all proposals public, some people have asked that they be
> > kept confidential because they didn't want to put out ideas publicly
> > that were going to have no chance of being included.
I wish that people didn't feel that way; off-the
Jakub Jelinek writes:
> > > While I still like using dl_iterate_phdr instead of
> > > __register_frame_info_bases for totally aesthetic reasons, there
> > > have been changes made to the dl_iterate_phdr interface since the
> > > gcc support was written that would allow the dl_iterate_phdr
Hello,
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 ??
best regards
On Thu, Feb 17, 2005 at 11:26:21AM -0500, Rajkishore Barik wrote:
> Is there a way to determine if the given RTX is
> accessing an array element or not? If yes, how do I determine the
> static size of that array from the given RTX?
In general, you don't.
r~
Joe Buck wrote:
It depends. If someone wants a confidential "sanity check" on a proposal
before making it public, I don't much care (though Mark might find himself
overburdened if he's in charge of all sanity checking, because people mail
only him). But any private communication between a propose
./config.guess
i686-pc-linux-gnu
gcc -v
Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: /Data/MyDownloads/gcc-3.4.3/configure
Thread model: posix
gcc version 3.4.3
languages enabled
all
/etc/issue
Red Hat Enterprise Linux WS release 3 (Taroon Update 4)
uname -a
>
> Substantial progress has been made towards GCC 4.0 over the past
> several weeks. There are now 103 open regressions targeted at 4.0,
> including 13 wrong-code bugs, and 31 rejects-valid or
> ice-on-valid-code bugs.
>
> That means that we are very nearly at the point where we can create
>
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 ??
best regards
http://gcc.gnu.org/
Am Donnerstag, 17. Februar 2005 03:11 schrieb James E Wilson:
> James E Wilson wrote:
> > Björn Haase wrote:
> >> #ifndef TARGET_SPECIFIC_SUBSTITUE_FOR_MODE_DF
>
> I see now that this is PR 19920. This message would have made more
> sense if you had included that important info.
>
> Anyways, I see
> 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 someth
Hi Matt,
I'm sure there are still lots of horrible bugs, which will only be
found with a more complete test suite. But the core functionality
works, and at this point I think it'll improve faster in the CVS
server than sitting on my hard disk.
OK to commit to mainline?
As far as I'm concern
On Feb 17, 2005, at 3:47 PM, Matt Austern wrote:
I'm sure there are still lots of horrible bugs
OK to commit to mainline?
Please, the copyright seems wrong. I think that should be fixed before
it goes in.
Matt Austern wrote:
OK to commit to mainline?
... before going to sleep, two very simple, slighlty less enthusiastic
comments ;)
1- Please add 2005 to the copyrights.
2- I see that the table of primes assumes that unsigned long is 32-bit:
we should do something about this, sooner or later...
Pao
> I'm sure there are still lots of horrible bugs, which will only be
> found with a more complete test suite. But the core functionality
> works, and at this point I think it'll improve faster in the CVS server
> than sitting on my hard disk.
Yep.
> OK to commit to mainline?
Sounds like
Matt Austern wrote:
OK to commit to mainline?
About your rethoric question: you made the mistake of creating the CVS
dirs before actually asking, thus making the nice surprise a little less
effective ;) ;)
Paolo.
On Thu, Feb 17, 2005 at 03:47:03PM -0800, Matt Austern wrote:
> I'm sure there are still lots of horrible bugs, which will only be
> found with a more complete test suite. But the core functionality
> works, and at this point I think it'll improve faster in the CVS server
> than sitting on m
Joe Buck wrote:
On Thu, Feb 17, 2005 at 03:47:03PM -0800, Matt Austern wrote:
I'm sure there are still lots of horrible bugs, which will only be
found with a more complete test suite. But the core functionality
works, and at this point I think it'll improve faster in the CVS server
than s
Joe Buck wrote:
> >A namespace purity nitpick:
> >
> >You define a macro named tr1_hashtable_define_trivial_hash. Shouldn't
> >that be __tr1_hashtable_define_trivial_hash or something similar?
On Fri, Feb 18, 2005 at 12:23:12AM +, Chris Jefferson wrote:
> Having just read through, everything
[EMAIL PROTECTED] (Paolo Bonzini) wrote on 17.02.05 in <[EMAIL PROTECTED]>:
> > The sort alghorithm has nothing to do with ls, but with your selection of
> > LC_COLLATE. But then, BSD (at least the variant used in MacOSX) is way
> > behind current l10n standards.
>
> At least they do not break s
On 2005-02-17 20:29:00 +0200, Kai Henningsen wrote:
> [EMAIL PROTECTED] (Paolo Bonzini) wrote on 17.02.05 in <[EMAIL PROTECTED]>:
> > I can only guess the outcry if Perl started obeying LC_COLLATE.
>
> What do you mean, "started"? It's been doing that for years now.
Not by default. From the per
This is the beta release of binutils 2.15.94.0.2.2 for Linux, which is
based on binutils 2004 1220 in CVS on sources.redhat.com plus various
changes. It is purely for Linux.
Please report any bugs related to binutils 2.15.94.0.2.2 to [EMAIL PROTECTED]
and
http://www.sourceware.org/bugzilla/
If
Joe Buck <[EMAIL PROTECTED]> writes:
| On Thu, Feb 17, 2005 at 03:47:03PM -0800, Matt Austern wrote:
| > I'm sure there are still lots of horrible bugs, which will only be
| > found with a more complete test suite. But the core functionality
| > works, and at this point I think it'll improve
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':
../../../lib
On Feb 17, 2005, at 4:18 PM, Joe Buck wrote:
On Thu, Feb 17, 2005 at 03:47:03PM -0800, Matt Austern wrote:
I'm sure there are still lots of horrible bugs, which will only be
found with a more complete test suite. But the core functionality
works, and at this point I think it'll improve faster in t
On Feb 17, 2005, at 4:03 PM, Paolo Carlini wrote:
Matt Austern wrote:
OK to commit to mainline?
... before going to sleep, two very simple, slighlty less enthusiastic
comments ;)
1- Please add 2005 to the copyrights.
Fixed.
2- I see that the table of primes assumes that unsigned long is
32-bit: w
On Feb 17, 2005, at 3:57 PM, Paolo Carlini wrote:
Hi Matt,
I'm sure there are still lots of horrible bugs, which will only be
found with a more complete test suite. But the core functionality
works, and at this point I think it'll improve faster in the CVS
server than sitting on my hard disk
I can only guess the outcry if Perl started obeying LC_COLLATE.
What do you mean, "started"? It's been doing that for years now.
By default, Perl ignores the current locale. The "use locale" pragma
tells Perl to use the current locale for some operations:
and these do not include regex chara
50 matches
Mail list logo
