clever routine. Certainly
you have to be a floating-point expert to even touch it!
Robert Dewar
On 5/11/2013 10:46 AM, Robert Dewar wrote:
As 1) only way is measure that. Compile following an we will see who is
rigth.
Right, probably you should have done that before posting
anything! (I leave the experiment up to you!)
And of course this experiment says nothing about accuracy!
As 1) only way is measure that. Compile following an we will see who is
rigth.
Right, probably you should have done that before posting
anything! (I leave the experiment up to you!)
cat "
#include
int main(){ int i;
double x=0;
double ret=0;
double f;
for(i=0;i<1000;i++){
On 5/11/2013 5:42 AM, jacob navia wrote:
1) The fsin instruction is ONE instruction! The sin routine is (at
least) thousand instructions!
Even if the fsin instruction itself is "slow" it should be thousand
times faster than the
complicated routine gcc calls.
2) The FPU is at 64 bits ma
Wrong. It specifies that objects with static storage duration that
aren't explicitely initialized are initialized with null pointers, or
zeros depending on type. 6.7.8.10.
OK, that means that the comments of my last mesage don't apply to
variables of this type. So they should at least option
Forgive me, but I don't see where anything is guaranteed to be zero'd
before use. I'm likely wrong somewhere since you disagree.
http://en.wikipedia.org/wiki/.bss
This is about what happens to work, and specifically notes that it is
not part of the C standard. There is a big difference betwe
On 1/28/2013 6:48 AM, Alec Teal wrote:
On 28/01/13 10:41, Jonathan Wakely wrote:
On 28 January 2013 06:18, Alec Teal wrote:
the very
nature of just putting the word "hard" before a typedef is something I find
appealing
I've already explained why that's not likely to be acceptable, because
iden
On 1/24/2013 10:33 AM, Jeffrey Walton wrote:
In this case, I claim we must perform the operation. Its the result
that we can't use under some circumstances (namely, overflow or wrap).
You do not have to do the operation if the program has an
overflow. The compiler can reason about this, so for
On 1/24/2013 10:02 AM, Jeffrey Walton wrote:
What I am not clear about is when an operation is deemed "undefined"
or "implementation defined".
The compiler is free to assume that no arithmetic operation
on signed integers results in overflow. It is allowed to
take advantage of such assumptions
On 1/24/2013 9:10 AM, Alec Teal wrote:
Alec I am eager to see what you guys think, this is a 'feature' I've
wanted for a long time and you all seem approachable rather than the
distant compiler gods I expected.
I certainly see the point of this proposal, indeed introducing
this kind of strong
About the time Clang does because GCC now has to compete."
How about that? Clang is currently slightly ahead and GCC really needs
to change if it is to continue to be the best.
Best is measured by many metrics, and it is unrealistic to expect
any product to be best in all respects.
Anyway, it
On 1/16/2013 7:10 AM, Mischa Baars wrote:
And as I have said before: if you are satisfied with the answer '2',
then so be it and you keep the compiler the way it is, personally I'm am
not able to accept changes to the sources anyway. I don't think it is
the right answer though.
The fact that y
On 1/16/2013 6:54 AM, Mischa Baars wrote:
]
And indeed apparently the answer then is '2'. However, I don't think
this is correct. If that means that there is an error in the C
specification, then there probably is an error in the specification.
The C specification seems perfectly reasonable to
On 1/2/2013 12:26 PM, Jeff Law wrote:
Any thoughts on doing something similar?
I've always found lazily updating the copyright years to be error prone.
If we could just update all of them now, which is OK according to the
FSF guidelines we could avoid one class of problems.
For GNAT at Ada
On 12/15/2012 12:32 PM, Cynthia Rempel wrote:
Hi,
Thanks for the fast response!
So to keep an architecture supported by GCC, we would need to:
Three or more times a year preferably either during OR after
"stage3"
1. use the SVN version of gcc, 2. patch with an RTEMS patch, 3. use
./contrib/te
On 12/15/2012 12:42 AM, Ralf Corsepius wrote:
If you want a port to be live show that it is live by posting regular
testresults to gcc-testresults.
Not all of this world is Linux nor backed by large teams at
companies :) We simply do not have the resources do to this.
But that's the poi
Having read this whole thread, Ivote for deprecating the 386.
People using this ancient architecture can perfectly well use
older versions of gcc that have this support.
On 12/14/2012 3:13 PM, Cynthia Rempel wrote:
Hi,
RTEMS still supports the i386, and there are many i386 machines still
in use. Deprecating the i386 will negatively impact RTEMS ability to
support the i386. As Steven Bosscher said, the "benefits" are small,
and the impact would be serious for R
On 12/13/2012 7:26 AM, Steven Bosscher wrote:
Ralf has found one such a vendor, it seems.
But to me, that doesn't automatically imply that GCC must continue to
support such a target. Other criteria should also be considered. For
instance, quality of implementation and maintenance burden.
Yes,
Intel stopped producing embedded 386 chips in 2007.
Right, but this architecture is not protected, so the
question is whether there are other vendors producing
compatible chips. I don't know the answer.
On 12/12/2012 2:52 PM, Steven Bosscher wrote:
And as usual: If you use an almost 30 years old architecture, why
would you need the latest-and-greatest compiler technology?
Seriously...
Well the embedded folk often end up with precisely this dichotomy :-)
But if no sign of 386 embedded chips, t
On 12/12/2012 1:01 PM, Steven Bosscher wrote:
Hello,
Linux support for i386 has been removed. Should we do the same for GCC?
The "oldest" ix86 variant that'd be supported would be i486.
Are there any embedded chips that still use the 386 instruction set?
On 11/24/2012 1:13 PM, Jonathan Wakely wrote:
The official gmail app, which obviously integrates well with gmail and
is good in most other ways, won't send non-html mails.
There seem to be a variety of alternatives
http://www.tested.com/tech/android/3110-the-best-alternative-android-apps-to-
On 11/24/2012 12:59 PM, Daniel Berlin wrote:
On Sat, Nov 24, 2012 at 12:47 PM, Robert Dewar wrote:
2) The fact that Android refuses to provide a non-HTML e-mail capability
is ridiculous but does not seem to me to be a reason for us to change
our policy.
Surely there are altenrative email
2) The fact that Android refuses to provide a non-HTML e-mail capability
is ridiculous but does not seem to me to be a reason for us to change
our policy.
Surely there are altenrative email client for Android that have plain
text capability???
For me the most annoying thing about HTML burdened emails
is idiots who choose totally inappropriate fonts, that make
their stuff really hard to read. I choose a font for plain
text emails that is just right on my screen etc. I do NOT
want it overridden. And as for people who use color etc,
well o
On 11/7/2012 11:08 AM, Richard Kenner wrote:
Correct. A court of competent jurisdiction can decide whether your scheme
conforms to the relevant licenses; neither licens...@fsf.org nor the
people on this list can.
A minor correction: licens...@fsf.org *could* determine that since they are
the c
On 11/7/2012 9:44 AM, nk...@physics.auth.gr wrote:
Quoting Richard Kenner :
There are not many lawyers in Greece that deal with open-source licenses.
The legal issue here has nothing whatsoever to do with open-source
licenses: the exact same issue comes up with proprietary licenses and
that,
On 11/7/2012 8:17 AM, nk...@physics.auth.gr wrote:
I disagree.
I think you are wrong, however it is not really productive to express it.
I would not casually ignore Richard's opinion, he has FAR more
experience here than you do, and far more familiarity with
the issues involved.
I'm pretty certain I have correctly interpreted GPL,v3. I have good
reasons to believe that. However, I'm willing to read your
interpretation of the GPL,v3, if you have any.
If you are certain enough, then you can of course proceed
on that assumption. I have no interest in giving my opinion
on t
olks who are not attorneys may help confirm your
intepretation, but it's risky to rely on such opinions.
BTW, it is no surprise that you got no response from
licens...@fsf.org.
Robert Dewar
On 10/10/2012 4:16 PM, Joseph S. Myers wrote:
I'm not talking about the relation between the headings textually located
in a source file and the license of that source file. I'm talking about
the relation between the license of a .o file and the license of .h files
#included at several levels o
On 10/10/2012 10:48 AM, Joseph S. Myers wrote:
On Wed, 10 Oct 2012, Gabor Loki wrote:
2) repeat all the compilation commands related to the previous list in
the proper environment. The only thing which I have added to the
compilation command is an extra "-E" option to preprocess every sources.
On 9/24/2012 6:53 AM, Jerome Huck wrote:
from Mr Jerome Huck
Good morning.
I have been using the GCC suite on Windows, mainly in the various
Fortran. 77, 2003,... Thanks for those tools ! The Little Google Nexus 7
seems a wonderfull tool. I would like to know if we can expect a version
of GCC t
On 7/2/2012 8:35 AM, Alexandre Oliva wrote:
On Jun 30, 2012, David Edelsohn wrote:
IBM's policy specifies a comma:
,
and not a dash range.
But this notation already means something else in our source tree.
I think using the dash is preferable, and is a VERY widely used
notation, us
On 6/24/2012 12:09 PM, Ángel González wrote:
"Peter A. Felvegi" writes:
My question is: wouldn't it be possible to print a warning when a jmp
to itself or trivial infinite recursion is generated? The code
compiled fine w/ -Wall -Wextra -Werror w/ 4.6 and 4.7.
Note that if the target architectur
On 6/24/2012 11:22 AM, Richard Guenther wrote:
I suppose I think it would be reasonable to issue a -Wall warning for
code like that. The trick is detecting it. Obviously there is nothing
wrong with a recursive call. What is different here is that the
recursive call is unconditional. I don't
On 5/14/2012 6:26 PM, Andy Lutomirski wrote:
This seems to defeat the purpose, and adding
#pragma GCC diagnostic ignored "-Wpragmas"
is a little gross. How am I supposed to do this?
The gcc mailing list is for gcc development, not
quetions about the use of gcc, please address such
questions t
On 4/30/2012 4:16 AM, Paulo J. Matos wrote:
Peter,
We have a working backend for an Harvard Architecture chip where
function pointer and data pointers have necessarily different sizes. We
couldn't do this without changing GCC itself in strategic places and
adding some extra support in our backen
On 4/29/2012 1:19 PM, Basile Starynkevitch wrote:
For instance, I don't think that porting the Linux kernel (or the FreeBSD one)
to such an
architecture (having data pointers of different size that function pointers) is
easy.
Well it doesnt' surprise me too much that GNU/Linux has non-standa
On 4/29/2012 12:47 PM, Basile Starynkevitch wrote:
My biased point of view is that designing a processor instruction set (for
POSIX-like
systems or standard C software in mind) with function pointers of different
size than
data pointers is today a mistake: most software make the implicit assum
On 4/29/2012 9:25 AM, Andreas Schwab wrote:
Robert Dewar writes:
Just to be clear, there is nothing in the standard that forbids the
sizes being different AFAIK? I understand that both gcc and apps
may make unwarranted assumptions.
POSIX makes that assumption, via the dlsym interface
On 4/29/2012 8:51 AM, Georg-Johann Lay wrote:
Peter Bigot a écrit:
The MSP430's split address space and ISA make it expensive to place
data above the 64 kB boundary, but cheap to place code there. So I'm
looking for a way to use HImode for data pointers, but PSImode for
function pointers. If
On 4/16/2012 5:36 AM, Chiheng Xu wrote:
On Sat, Apr 14, 2012 at 7:07 PM, Robert Dewar wrote:
hand, but to suggest banning all templates is not a supportable
notion.
Why ?
Because some simple uses of templates are very useful, and
not problematic from any point of view.
On 4/14/2012 6:02 AM, Chiheng Xu wrote:
If debugger fully support namespace, that will be nice. I just say,
in case debugger have trouble with namespace, you can avoid it.
But personally, when I write C++ code, I never use namespace. I
always prefix my class name(and corresponding source file
On 4/14/2012 6:39 AM, Gabriel Dos Reis wrote:
Indeed, the notion that 'namspace' is "advance" is troublesome.
Similarly I would find any notion that simple uses and definitions
of templates (functions, datatypes) "advanced" a bit specious.
Indeed! In the case of templates there is a real issu
On 4/14/2012 6:38 AM, Chiheng Xu wrote:
Actually, I only partially agree with you on this. And I didn't say
smaller is necessarily better.
But normally, high cohesion and low coupling code tend not be large.
Normally large files tend to export only few highly related entry
points. Most of the fu
On 4/13/2012 9:34 PM, Chiheng Xu wrote:
On Wed, Apr 4, 2012 at 7:38 PM, Richard Guenther
wrote:
Oh, and did we address all the annoyances of debugging gcc when it's
compiled by a C++ compiler? ...
Probably, if you can refrain from using some "advance" C++
features(namespace, template, etc.
On 4/13/2012 9:15 PM, Chiheng Xu wrote:
So, I can say, most of the GCC source code is in large files.
And this also hold for language front-ends.
I see nothing inherently desirable about having all small files.
For example, in GNAT, yes, some files are large, sem_ch3 (semantic
analysis for ch
On 4/13/2012 2:03 AM, Gabriel Dos Reis wrote:
On Thu, Apr 12, 2012 at 4:50 PM, Robert Dewar wrote:
End of thread for me, remove me from the reply lists, thanks
discussion is going nowhere, at this stage my vote is for
no change whatever in the way warnings are handled.
I was asked "w
End of thread for me, remove me from the reply lists, thanks
discussion is going nowhere, at this stage my vote is for
no change whatever in the way warnings are handled.
On 4/12/2012 5:40 PM, Gabriel Dos Reis wrote:
It isn't non-sense just because you decide so or you don't like the observation.
and
nonsense now, this has nothing to do with incompleteness!
I think you don't know what incompleteness is about, yes, it is
nonsense, because no one can make any
On 4/12/2012 5:35 PM, Gabriel Dos Reis wrote:
There's nothing more ambiguous than saying that something is final in a
world where perfection is never achieved. That's why software has
monotonically increasing version numbers, instead of just one that means "this
is done now".
As I observed
On 4/12/2012 10:48 AM, Andrew Haley wrote:
Ultimately, it's a matter of taste and experience. I'm going to find
it hard to write for people who don't know the relative precedence of
& and | .
There are probably some programmers who completely know ALL the operator
precedence rules in C. Ther
On 4/12/2012 11:23 AM, Gabriel Dos Reis wrote:
less warnings to more warnings, what could be more
ordered than that!
What exactly do you put in -Wn to make it give *more* warning?
I can think of a reduced number of switch that would give you
more warning on a specific program without them bein
On 4/12/2012 10:48 AM, Andrew Haley wrote:
Certainly, everything that adds to clarity (and has no runtime costs!)
is desirable. But adding parentheses may not add to clarity if doing
so also obfuscates the code. There is a cost to the reader due to a
blizzard of syntactically redundant parenth
On 4/12/2012 11:06 AM, Gabriel Dos Reis wrote:
What is nonsensical there?
But they *are* ordinal.
Now? What is the order?
less warnings to more warnings, what could be more
ordered than that!
It works just fine for -O,
Exactly what happens with -O? -On does not necessarily
generate
On 4/12/2012 10:26 AM, Gabriel Dos Reis wrote:
-W0: no warnings (equivalent to -w)
-W1: default
-W2: equivalent to the current -Wall
-W3: equivalent to the current -Wall -Wextra
I like this suggestion a lot.
Me too!
I also like short switches, but gcc mostly favors long
hard-to-type not-n
On 4/12/2012 9:30 AM, Andrew Haley wrote:
Sorry for the confusion: I intended to write
I would also suggest that your competent programmer would know what
they don't know; when reading code they'd look it up, when writing
code they'd insert parentheses for clarity.
Using two different defin
On 4/12/2012 6:44 AM, Andrew Haley wrote:
I would also suggest that a competent programmer would know what they
don't know; when reading code they'd look it up, when writing code
they'd insert parentheses for clarity.
Yes, of course I 100% agree with that. But then by your definition
code that
On 4/12/2012 5:55 AM, Miles Bader wrote:
... and it's quite possible that such bugs resulting from adding
parentheses means that the programmer "fixing" the code didn't
actually know the right precedence!
or that the layout (which is what in practice we should rely on
to make things clear with
On 4/12/2012 4:55 AM, Fabien Chêne wrote:
I've got a radically different experience here, real bugs were
introduced while trying to remove this warning, and as far as I can
tell, I've never found any bugs involving precedence of&& and || --
in the code I'm working on --, whose precedence is rea
O
This one is an interesting case, since there are strong arguments on
both sides.
I enabled the C++ warning about the precedence of&& and || (it's been
in C for many years). It found real bugs in real code, bugs that had
existed for years.
I think for ordinary programmers, the fact that AND
On 4/9/2012 1:36 PM, Jonathan Wakely wrote:
Maybe -Wstandard isn't the best name though, as "standard" usually
means something quite specific for compilers, and the warning switch
wouldn't have anything to do with standards conformance.
-Wdefault
might be better
On 4/9/2012 1:29 PM, Eric Botcazou wrote:
That would be my preferred solution -- by far. But, my understanding
is that that would provoke a riot so I am willing to compromise by
introducing a new warning switch (even if I dislike that thought.)
Hopefully, it is it is going to be the default, mos
On 4/9/2012 1:29 PM, Gabriel Dos Reis wrote:
We are in agreement. I was just explaining to Gerald that his proposal
would have been my first choice, but I am compromising by moving to
your suggestion. My complaint is the introduction of a new switch
just to accomodate warnings that should not
On 4/9/2012 1:08 PM, Gabriel Dos Reis wrote:
On Mon, Apr 9, 2012 at 11:29 AM, Gerald Pfeifer wrote:
On Sun, 8 Apr 2012, Robert Dewar wrote:
Do you really want me to file hundreds of bug reports that are for
cases of uninitialized variables well known to everyone, and well
understood by
On 4/8/2012 4:59 PM, Gabriel Dos Reis wrote:
no, -Wstandard wasn't in my original proposal. It is the name suggested
by Miles for the list I gave Arnaud upon request.
I know that, I can read -:)
I am just saying I think this issue still needs discussion (and you
were complaining about contin
On 4/8/2012 4:26 PM, Gabriel Dos Reis wrote:
On Sun, Apr 8, 2012 at 3:13 PM, Robert Dewar wrote:
On 4/8/2012 4:02 PM, Jonathan Wakely wrote:
But I'd be just as happy with a -Wstandard (by any name) enabled by
default as I would be with -Wall on by default. Only enabling warnings
with
On 4/8/2012 4:25 PM, Gabriel Dos Reis wrote:
On Sun, Apr 8, 2012 at 2:54 PM, Robert Dewar wrote:
On 4/8/2012 3:37 PM, Jonathan Wakely wrote:
Again, that also applies when people use -Wall today: a false positive
is unwanted even if you use -Wall, and those false positives are bugs
and so
On 4/8/2012 4:23 PM, Gabriel Dos Reis wrote:
I think I agree with this. I suspect the only difference might be that
I do not believe the fix is necessarily to turn them off.
Well there are three possibilities
a) fix the false positives, at the possible expense of introducing
new false negati
On 4/8/2012 4:02 PM, Jonathan Wakely wrote:
No, because those are already in bugzilla, and there's a whole wiki
page about improving that particular warning.
Yes, I know, and that page is to me good justification for NOT including
this warning in the set that is on by default.
But I'd be just
On 4/8/2012 3:37 PM, Jonathan Wakely wrote:
Again, that also applies when people use -Wall today: a false positive
is unwanted even if you use -Wall, and those false positives are bugs
and so having them in bugzilla is good.
Do you really want me to file hundreds of bug reports that are for
ca
On 4/8/2012 3:33 PM, Gabriel Dos Reis wrote:
On Sun, Apr 8, 2012 at 1:51 PM, Robert Dewar wrote:
On 4/8/2012 1:56 PM, Jonathan Wakely wrote:
The people who don't want -Wall (or
-Wstandard) enabled are likely to be the ones who know how to use
-Wno-all or whatever to get what they
On 4/8/2012 1:56 PM, Jonathan Wakely wrote:
The people who don't want -Wall (or
-Wstandard) enabled are likely to be the ones who know how to use
-Wno-all or whatever to get what they want.
I see no evidence that supports that guess. On the contrary, I
would guess that if -Wall is set by defau
Hello Diego,
I am all set with my plans for Prague, but I have to
leave on a flight at 2pm on Wednesday. I hope my
presentation can be scheduled consistently with these
travel plans?
Robert Dewar
On 4/8/2012 11:59 AM, Rick Hodgin wrote:
What are the possibilities of adding a GCC extension to allow:
switch (foo) {
case 1:
case 2:
case 3 to 8:
case 9:
default:
}
in C/C++ case statements?
Best regards,
Rick C. Hodgin
I think there is very little enthusiasm these days for adding
non-stan
On 4/7/2012 6:57 PM, Miles Bader wrote:
Dave Korn writes:
IMHO we should move the -Wunused ones into -Wextra if we're going to turn on
-Wall by default. The rest seem pretty reasonable defaults to me.
How about instead adding new "-Wstandard", which will be on by default,
and keeping -Wal
On 4/5/2012 4:24 PM, Russ Allbery wrote:
Gabriel Dos Reis writes:
If it is the non-expert that would be caught in code so non-obvious that
-Wuninitialized would trip into false positives, then it is highly
likely that the code might in fact contain an error.
I wish this were the case, but al
On 4/5/2012 8:59 AM, Michael Veksler wrote:
They use an IDE, which is either Code-Blocks or Dev-C++, which run on
Windows, but these IDEs don't turn -Wall on by default. As for the advice
to use -Wall, there is so much to advise and so little time, and the
sheer
mass of information confuses
It's on my large TODO list, somewhere at the bottom, to propose
to make -O1 stop after early optimizations and drop right to
expansion from there. That would turn optimization expectations
upside-down of course, but early optimizations should be mostly
reducing code size (and thus increase comp
On 4/5/2012 8:28 AM, Michael Veksler wrote:
It is not that they can't remember. I am a TA at a moderately basic
programming course,
and student submit home assignments with horrible errors. These errors,
such as
free(*str) or *str=malloc(n) are easily be caught by -Wall. I have to
remember to
a
On 4/5/2012 8:06 AM, Vincent Lefevre wrote:
On 2012-04-05 06:26:43 -0400, Robert Dewar wrote:
Well a lot of users have been burned by using optimization
options, either becausae of compiler bugs, or because of bugs
in their own code triggered by optimization. So the requirement
of not using any
On 4/5/2012 2:39 AM, Arnaud Charlet wrote:
Can someone summarize what the most useful warnings people are expecting
that -Wall would bring?
I suspect not all of -Wall would actually be welcome/a good idea by default,
and we might be looking for a better compromise where most warnings are
enabled
On 4/5/2012 12:23 AM, Gabriel Dos Reis wrote:
-Wall is roughtly equivalent to -gnatwa in the GNAT front end,
and this is definitely NOT on by default. If you run GNAT in
default mode, there are virtually no false positives, since
the only warnings on by default are the kind of warnings that
say
On 4/5/2012 12:17 AM, Miles Bader wrote:
Robert Dewar writes:
We have run into people running benchmarks where they were
specifically prohibited from using other than the default
options, and gcc fared badly in such comparisons.
Yeah, there was the silly "benchmark" at phoronix
On 4/4/2012 6:42 PM, Gabriel Dos Reis wrote:
On Wed, Apr 4, 2012 at 4:21 PM, Robert Dewar wrote:
On 4/4/2012 2:34 PM, Dominique Dhumieres wrote:
IMO only the warnings in C that are likely errors should be the default as
it is in gfortran (don't ask for examples of such warnings for C,
On 4/4/2012 7:03 PM, Gabriel Dos Reis wrote:
Again, this proposal does not come out of a whim.
But it does seem to come out of a few anecdotal requests
for a change, and you always have to be careful in considering
such input, because of course people who agree with the status
quo do not write
On 4/4/2012 2:34 PM, Dominique Dhumieres wrote:
IMO only the warnings in C that are likely errors should be the default as
it is in gfortran (don't ask for examples of such warnings for C, I am
quasi-illiterate).
That's also the default philosophy in GNAT, there never should be false
positives
On 4/4/2012 2:02 PM, Gabriel Dos Reis wrote:
The interesting thing about -Wall is that it is pretty safe, for the most part,
in terms of false positives.
And, for the record, I find lots of false positives, the front end of
GNAT has a lot of junk initialiations marked "keep back end quiet".
Sometimes, we have to be brave to challenge tradition. The world around
us is moving and we definitely want GCC to remain competitive. It is
hard to define what "it's told" means without tripping over.
The interesting thing about -Wall is that it is pretty safe, for the most part,
in terms of
On 3/21/2012 11:35 AM, Basile Starynkevitch wrote:
I would be happy to help, but please understand that my understanding of GCC
is restricted to gengtype, ggc, and some parts of the middle-end. I know
nothing about the vast rest of the GCC compiler.
Perhaps suggestions about improvements in th
Very well said. Discussing about modules also makes no sense. Figure out
the present state.
these kind of meta discussions are very rarely of value, this
one is no exception IMO
Richard.
--
P.
On 3/18/2012 12:56 PM, Basile Starynkevitch wrote:
* you can name and count the modules of a software
Well in a hierarchical system this is not so clear, since modules may
exist at different levels of abstraction. For instance in a compiler,
at one level of abstraction, the front end is a
On 2/4/2012 9:57 AM, Andreas Schwab wrote:
\
How can the sine function know which of the millions of numbers
represented by 0x1.0f0cf064dd591p+73 are meant? Applying the sine to
this interval covers the whole result domain of the function.
The idea that an IEEE number necessarily represents an
On 2/4/2012 9:09 AM, Andreas Schwab wrote:
Robert Dewar writes:
But if you write a literal that can be represented exactly, then it is
perfectly reasonable to expect trig functions to give the proper
result, which is unambiguous in this case.
How do you know that the number is exact
On 2/4/2012 7:00 AM, Andreas Schwab wrote:
Vincent Lefevre writes:
Wrong. 53 bits of precision. And 10^22 is the last power of 10
exactly representable in double precision (FYI, this example has
been chosen because of this property).
But it is indistinguishable from 10^22+pi. So both -0.852
On 2/3/2012 4:32 PM, Vincent Lefevre wrote:
Yes, I do! The floating-point representation of this number
This fact is not even necessarily correct because you don't know the
intent of the programmer. In the program,
double a = 4.47460300787e+182;
could mean two things:
1. A number whic
g to "x is separable with x+pi/4" rule. It seems,
everything works inside this range.
Yes, it is a good idea to only generate useful tests when you
are autogenerating, otherwise you will get garbage in garbage out :-)
---
With best regards, Konstantin
On Fri, Feb 3, 2012 at 7:13 PM, Robe
On 2/3/2012 10:55 AM, Vincent Lefevre wrote:
On 2012-02-03 10:33:58 -0500, Robert Dewar wrote:
On 2/3/2012 10:28 AM, Vincent Lefevre wrote:
If the user requested such a computation, there should at least be
some intent. Unless an option like -ffast-math is given, the result
should be accurate
1 - 100 of 1015 matches
Mail list logo
