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
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 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
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 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
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
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
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
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
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
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
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.
> 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
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
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
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
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
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:
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 ...
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
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
> 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, 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
> 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
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
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
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
> 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
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
> 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
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
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
> 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
> 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?
(
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
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
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
* 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
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 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
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
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
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
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
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
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
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
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
Good to go on AIX 5.2:
http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg01101.html
David
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
> 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
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
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
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,
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
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
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
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 :-)
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
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 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
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
|
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 =
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
> 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
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 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
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
68 matches
Mail list logo
