zouqiong wrote:
i am surprised about it.
You seem surprised, and I am terrified you are using a compiler that
old. Please go look at:
http://kegel.com/crosstool/
which automatically builds cross toolchains and even still has
scripts to build your ancient (IMHO) combination.
-Steve
Tommy Vercetti wrote:
> Hi folks
>
> I would like to ask you about source validation software. Software that runs
> trough source code, and attempts to find any possible memory leaks, and other
> problems. Is there anything opensource for C or/and C++ out there ?
My summer research project that
Mathieu Malaterre <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > Tommy Vercetti <[EMAIL PROTECTED]> writes:
| > | On Sunday 19 June 2005 03:03, you wrote:
| > | > Tommy Vercetti <[EMAIL PROTECTED]> writes:
| > | > | On Sunday 19 June 2005 00:32, you wrote:
| > | > | > Something like:
|
> Tommy Vercetti <[EMAIL PROTECTED]> writes:
>
> | Yeah, but for more than just STL, and opensource. C++ checker that
> | is going to work for instance for KDE.
> | Wonder why they use proprietary parser,
>
Gabriel Dos Reis wrote:
> Most of the tools I know of are either "research projects" (w
i download the release version of gcc-2.95.3, and binutils 2.15, then i
did the following things:
1.
mkdir binutils-build;
../../binutils-2.15/configure --prefix=/opt/gcc --target=mipsel-linux
-v;
make;make install;
2.i copy the o32 lib, o32 include to the /opt/gcc/mipsel-linux/lib,
/opt/gcc/mip
1.
in the gt-c-decl.h,
three functions about lang_decl,
gt_pch_nx_lang_decl(),gt_ggc_mx_lang_decl, gt_pch_g_9lang_decl(),
what are the differences between the three functions?
2.
i can find the prefixes in the gengtype.c,
what are they setting for?
static const struct write_types_data ggc_wtd =
Gabriel Dos Reis wrote:
Tommy Vercetti <[EMAIL PROTECTED]> writes:
| On Sunday 19 June 2005 03:03, you wrote:
| > Tommy Vercetti <[EMAIL PROTECTED]> writes:
| > | On Sunday 19 June 2005 00:32, you wrote:
| > | > Something like:
| > | >
| > | > http://www.cs.rpi.edu/~gregod/STLlint/STLlint.html
|
Tommy Vercetti <[EMAIL PROTECTED]> writes:
| On Sunday 19 June 2005 03:03, you wrote:
| > Tommy Vercetti <[EMAIL PROTECTED]> writes:
| > | On Sunday 19 June 2005 00:32, you wrote:
| > | > Something like:
| > | >
| > | > http://www.cs.rpi.edu/~gregod/STLlint/STLlint.html
| > |
| > | Yeah, but for m
On Sunday 19 June 2005 03:03, you wrote:
> Tommy Vercetti <[EMAIL PROTECTED]> writes:
> | On Sunday 19 June 2005 00:32, you wrote:
> | > Something like:
> | >
> | > http://www.cs.rpi.edu/~gregod/STLlint/STLlint.html
> |
> | Yeah, but for more than just STL, and opensource. C++ checker that
> | is g
Tommy Vercetti <[EMAIL PROTECTED]> writes:
| On Sunday 19 June 2005 00:32, you wrote:
| > Something like:
| >
| > http://www.cs.rpi.edu/~gregod/STLlint/STLlint.html
|
| Yeah, but for more than just STL, and opensource. C++ checker that
| is going to work for instance for KDE.
| Wonder why they u
Gabriel Dos Reis wrote:
I suspect the real question is which kind of codes and how they are
representative.
Absolutely, and my general rule is that optimizations are disappointing,
which has a corrolary that removing an optimization is not necessarily
disappointing in terms of performance :-)
Robert Dewar <[EMAIL PROTECTED]> writes:
| Laurent GUERBY wrote:
| > On Sat, 2005-06-18 at 16:45 -0400, Robert Dewar wrote:
| >
| >>Mattias Karlsson wrote:
| >>
| >>
| >>>Since the "gcc-is-buggy" solution of changing x87 rounding modes will:
| >>>1) Be a lot of work.
| >>>2) Cause a lot of regress
Paul Schlie wrote:
[Justification snipped]
> Therefore regardless of the result of an "undefined" result/operation at
> it's enclosing sequence point, the remaining program must continue to abide
> by the specified semantics of the language.
Tell that to Mister my_array[sizeof(my_array) / sizeof
Eric Botcazou wrote:
>1 new failure for libstdc++-v3 in 64-bit mode:
>
>FAIL: ext/array_allocator/2.cc execution test
>
>but *not* a regression.
>
>
Indeed, I can confirm that: it's a very long standing issue ultimately
due to basic_string not rebinding the allocator template argument to one
suf
On Sunday 19 June 2005 00:32, you wrote:
> Something like:
>
> http://www.cs.rpi.edu/~gregod/STLlint/STLlint.html
Yeah, but for more than just STL, and opensource. C++ checker that is going to
work for instance for KDE.
Wonder why they use proprietary parser, there are opensource parsers around,
On Sat, Jun 18, 2005 at 11:27:15PM +0200, "Martin v. L?wis" wrote:
> > This worked before. Why shouldn't it? Please tell me how to work
Before the string was marked as c-format and therefore gettext
did not complain. But GCC whenever it tried to issue that diagnostics
worked in english, but crash
Something like:
http://www.cs.rpi.edu/~gregod/STLlint/STLlint.html
HTH
Mathieu
Tommy Vercetti wrote:
Hi folks
I would like to ask you about source validation software. Software that runs
trough source code, and attempts to find any possible memory leaks, and other
problems. Is there anythin
> GCC 4.0.1 RC2 is now available here:
>
>ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050616
OK on SPARC/Solaris:
http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg01107.html
http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg01110.html
http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg01108.html
Hi folks
I would like to ask you about source validation software. Software that runs
trough source code, and attempts to find any possible memory leaks, and other
problems. Is there anything opensource for C or/and C++ out there ?
I know it's the wrong list to ask for it, but that's quite clos
Good to go on AIX 5.2:
http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg01101.html
David
Mark Michell wrote:
> GCC 4.0.1 RC2 is now available here:
>
>ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050616
Still fine on s390(x):
http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg01103.html
http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg01104.html
Bye,
Ulrich
--
Dr. Ulrich Weiga
Laurent GUERBY wrote:
On Sat, 2005-06-18 at 17:37 -0400, Robert Dewar wrote:
Changing the default rounding of the processor will make code less
efficient?
Yes, if you have to change it backwards and forwards for float and
double
Quite rare. Only usage I've seen is for tabulation when yo
On Sat, 2005-06-18 at 17:37 -0400, Robert Dewar wrote:
> > Changing the default rounding of the processor will make code less
> > efficient?
> Yes, if you have to change it backwards and forwards for float and
> double
Quite rare. Only usage I've seen is for tabulation when you want
to save stor
I'm preparing the third part of the reduction support for mainline,
introducing vector shifts (see
http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01317.html). The vectorizer
generates the following epilog code:
vect_var_.53_60 = vect_var_.50_59 v>> 64;
vect_var_.53_61 = vect_var_.50_59 + vect_va
Laurent GUERBY wrote:
On Sat, 2005-06-18 at 16:45 -0400, Robert Dewar wrote:
Mattias Karlsson wrote:
Since the "gcc-is-buggy" solution of changing x87 rounding modes will:
1) Be a lot of work.
2) Cause a lot of regressions.
To this you can add
3) generate less efficient code
Changing
On Sat, 2005-06-18 at 16:45 -0400, Robert Dewar wrote:
> Mattias Karlsson wrote:
>
> > Since the "gcc-is-buggy" solution of changing x87 rounding modes will:
> > 1) Be a lot of work.
> > 2) Cause a lot of regressions.
>
> To this you can add
>
>3) generate less efficient code
Changing the d
On Jun 18, 2005, at 5:27 PM, Martin v. Löwis wrote:
So the questions are:
- Does GCC support $ reordering of arguments?
- If yes, why does gettext complain?
- If no, shouldn't it?
GCC does not support (yet) $ reordering of arguments
but there is a recent patch to support it:
http://gcc.gnu.org
Original Message
Subject: Re: gcc-4.0.1-b20050607.de.po [REJECTED]MIME-Version: 1.0
Date: Sat, 18 Jun 2005 23:03:45 +0200
From: Roland Stigge <[EMAIL PROTECTED]>
Organization: Antcom
To: Translation Project Robot <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTE
Paul Schlie wrote:
From: "Joseph S. Myers" <[EMAIL PROTECTED]>
"no requirements" means that *any* translation conforms in the case of
undefined behavior. Only those executions not involving undefined
behavior have any requirements.
What delineates the bounds between undefined and non-undefine
Joseph S. Myers wrote:
The traditional form of undefined behavior is for demons to fly out of
your nose. We just haven't yet got -fnasal-demons working reliably but it
would be conforming for it to be on by default. If you are lucky, it will
happen anyway without that option.
A nice piece
* Paul Schlie:
> So in effect the standard committee have chosen to allow any program which
> invokes any undefined behavior to behave arbitrarily without diagnosis?
>
> This is a good thing?
It's the way things are. There isn't a real market for
bounds-checking C compilers, for example, which o
Paul Schlie wrote:
- an optimization which presumes the execution state of a program does not
proceed past a sequence point. but in fact does, may result in erroneous
behavior; which would be the case if NULL pointer comparisons were optimized
away presuming an earlier pointer dereference would
Mattias Karlsson wrote:
Since the "gcc-is-buggy" solution of changing x87 rounding modes will:
1) Be a lot of work.
2) Cause a lot of regressions.
To this you can add
3) generate less efficient code
4) cause some algorithms that work now to fail
On Sat, 18 Jun 2005, Paul Schlie wrote:
> So in effect the standard committee have chosen to allow any program which
> invokes any undefined behavior to behave arbitrarily without diagnosis?
That is the *whole point* of undefined behavior. Unless the program also
violates a compile-time syntax
> From: "Joseph S. Myers" <[EMAIL PROTECTED]>
> "no requirements" means that *any* translation conforms in the case of
> undefined behavior. Only those executions not involving undefined
> behavior have any requirements.
What delineates the bounds between undefined and non-undefined behaviors?
(
> Honza,
>
> Your patch here: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00976.html
> has left a number of fortran test cases broken (e.g. gfortran.dg/select_2).
>
> The problem seems to be that you used the aux field as a replacement for
> rbi->copy_number, but tree_verify_flow_info assumes au
So in effect the standard committee have chosen to allow any program which
invokes any undefined behavior to behave arbitrarily without diagnosis?
This is a good thing?
[ curiously can't find any actual reference stating that integer overflow
is specifically results in undefined behavior, altho
Benjamin Kosnik wrote:
Please test this version and report problems in Bugzilla, with a Cc:
to me. I'd also appreciate explicit confirmation from a representative
of the libstdc++ team that this version as packaged still has the
desired behavior, just to catch any packaging snafus.
This versio
> On Friday 17 June 2005 08:30, Steve Kargl wrote:
> > On Fri, Jun 17, 2005 at 08:01:47AM +0200, FX Coudert wrote:
> > > Jerry DeLisle wrote:
> > > >There appears to be numerous regression failures this evening. I
> > > >suppose these are back end related.
> > >
> > > On i686-freebsd, i386-linux a
On Sat, 18 Jun 2005, Paul Schlie wrote:
>[#1] Behavior, upon use of a nonportable or erroneous
>program construct, of erroneous data, or of indeterminately
>valued objects, for which this International Standard
>imposes no requirements. Permissibl
> Please test this version and report problems in Bugzilla, with a Cc:
> to me. I'd also appreciate explicit confirmation from a representative
> of the libstdc++ team that this version as packaged still has the
> desired behavior, just to catch any packaging snafus.
This version looks correct to
Snapshot gcc-4.1-20050618 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20050618/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 CVS branch
with the following options: -D2005-06-18 17:43 UTC
You'll
On Sat, 18 Jun 2005, Paul Schlie wrote:
> > You appear to have confused unspecified behavior (where the possibilities
> > are bounded) and undefined behavior (where the possibilities are
> > unbounded). On *undefined* behavior (such as signed integer overflow),
> > *this International Standard im
Sorry, yes the quote below defines unspecified, not undefined behavior.
Now more correctly:
[#1] Behavior, upon use of a nonportable or erroneous
program construct, of erroneous data, or of indeterminately
valued objects, for which this International Standard
> From: "Joseph S. Myers" <[EMAIL PROTECTED]>
> On Sat, 18 Jun 2005, Paul Schlie wrote:
>
>> Maybe I didn't phrase my statement well; I fully agree with the cited
>> paragraph above which specifically says a program containing unspecified
>> behavior "shall be a correct program and act in ac
On Sat, 18 Jun 2005, Paul Schlie wrote:
> Maybe I didn't phrase my statement well; I fully agree with the cited
> paragraph above which specifically says a program containing unspecified
> behavior "shall be a correct program and act in accordance with
> 5.1.2.3". Which specifies program ex
> Mike Stump wrote:
>> Paul Schlie wrote:
>> - If the semantics of an operation are "undefined", I'd agree; but if
>> control is returned to the program, the program's remaining specified
>> semantics must be correspondingly obeyed, including the those which
>> may utilize the resulting value
On Sat, 18 Jun 2005, Robert Dewar wrote:
Mattias Karlsson wrote:
On Sat, 18 Jun 2005, Robert Dewar wrote:
Mattias Karlsson wrote:
Don't know about you, but I consider any processor that is unable to
store a register to memory and then read back the same value to be buggy.
THe x86/x87 doe
Giovanni Bajo wrote:
Nathan,
I see some failures in the testsuite which appear to be related by your recent
changes to rtti.c (VECification). For instance:
FAIL: obj-c++.dg/basic.mm (test for excess errors)
Excess errors:/home/rasky/gcc/mainline/gcc/libstdc++-v3/libsupc++/exception:55:
internal
Toon Moene wrote:
The new thing I learned from your mail is the above. If GCC can support
this, than we can properly solve PR/323. This is independent of whether
I recall the thing I read in the past correctly.
Interesting, let me restudy PR/323 ...
Robert Dewar wrote:
Well, I haven't studied this to such a great detail because I (according
to Kahan) belong to the group of people who "don't care about floating
point accuracy because their code is so robust they can even run on
Cray's", but doesn't this mean that we can solve it in the com
Toon Moene wrote:
Well, I haven't studied this to such a great detail because I (according
to Kahan) belong to the group of people who "don't care about floating
point accuracy because their code is so robust they can even run on
Cray's", but doesn't this mean that we can solve it in the compi
Mattias Karlsson wrote:
On Sat, 18 Jun 2005, Robert Dewar wrote:
Mattias Karlsson wrote:
Don't know about you, but I consider any processor that is unable to
store a register to memory and then read back the same value to be
buggy.
THe x86/x87 does not violate this requirement
In my Ob
Giovanni Bajo wrote:
Nathan,
I see some failures in the testsuite which appear to be related by your recent
changes to rtti.c (VECification). For instance:
FAIL: obj-c++.dg/basic.mm (test for excess errors)
Excess errors:/home/rasky/gcc/mainline/gcc/libstdc++-v3/libsupc++/exception:55:
internal
By the way, we had one customer recently report an experiment of
using -march=pentium4 -fpmath=sse on a big application and seeing
a 5% improvement in performance. This customer incidentally had
reported a bug under the title "intel x86 numeric nightmare",
which was another version of PR/323 in th
> Well, I haven't studied this to such a great detail because I (according
> to Kahan) belong to the group of people who "don't care about floating
> point accuracy because their code is so robust they can even run on
> Cray's", but doesn't this mean that we can solve it in the compiler by
> ha
On Sat, 18 Jun 2005, Robert Dewar wrote:
Mattias Karlsson wrote:
Don't know about you, but I consider any processor that is unable to store
a register to memory and then read back the same value to be buggy.
THe x86/x87 does not violate this requirement
In my Obi-Wan-Point-Of-View it does.
Robert Dewar wrote:
I wrote:
Unfortunately, somewhere in the design process of the 8087 things went
wrong and the chip only handles 8 80-bit registers, not providing an
interrupt (or any other support) to an OS to fake the "virtual" 80-bit
registers.
This is nonsense. It is perfectly pos
Toon Moene wrote:
Vincent Lefevre wrote:
Unfortunately, somewhere in the design process of the 8087 things went
wrong and the chip only handles 8 80-bit registers, not providing an
interrupt (or any other support) to an OS to fake the "virtual" 80-bit
registers.
This is nonsense. It is per
Sylvain Pion wrote:
That would indeed be a funny kind of processor, but x86 can store its
registers in memory exactly : simply store/reread them as long doubles.
There was indeed a processor (I think by Honeywell) where the fpt accumulator
had extra precision bits that could not be stored in m
Mattias Karlsson wrote:
Don't know about you, but I consider any processor that is unable to
store a register to memory and then read back the same value to be buggy.
THe x86/x87 does not violate this requirement
Vincent Lefevre wrote:
Saying that the x86 processor is buggy is just completely silly.
Only some gcc developers think so.
No, Kahan thinks so too (sorry, can't come up with a link just right
now). The original plan for x87 extended precision floating point was
to have a small stack of 80-b
Dale Johannesen wrote:
2 NOTE Possible undefined behavior ranges from ignoring the situation
completely with
unpredictable results, to behaving during translation or program
execution in a documented
manner characteristic of the environment (with or without the issuance
of a diagnostic messag
On Friday 17 June 2005 08:30, Steve Kargl wrote:
> On Fri, Jun 17, 2005 at 08:01:47AM +0200, FX Coudert wrote:
> > Jerry DeLisle wrote:
> > >There appears to be numerous regression failures this evening. I
> > >suppose these are back end related.
> >
> > On i686-freebsd, i386-linux and x86_64-linu
Honza,
Your patch here: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00976.html
has left a number of fortran test cases broken (e.g. gfortran.dg/select_2).
The problem seems to be that you used the aux field as a replacement for
rbi->copy_number, but tree_verify_flow_info assumes aux is cleared b
On Sat, Jun 18, 2005 at 12:54:40PM +0200, Mattias Karlsson wrote:
> On Sat, 18 Jun 2005, Vincent Lefevre wrote:
>
> >On 2005-06-16 17:54:03 -0400, Robert Dewar wrote:
> >>As you well know, not everyone agrees this is a bug, and this does
> >>not have to do with performance. Saying over and over ag
On Sat, 18 Jun 2005, Vincent Lefevre wrote:
On 2005-06-16 17:54:03 -0400, Robert Dewar wrote:
As you well know, not everyone agrees this is a bug, and this does
not have to do with performance. Saying over and over again that you
think it is a bug does not make it so.
I haven't seen any corre
On Saturday 18 June 2005 02:52 am, Vincent Lefevre wrote:
> Saying that the x86 processor is buggy is just completely silly.
> Only some gcc developers think so.
Yeah, the smart ones.
--
Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED]
"Computer games don't affect kids; I mean if Pac-Man affec
68 matches
Mail list logo
