This overflow attitude has some resemblance to the attitude that
resulted in the Y2K issues. I don't try to troll, I have a detailed
explanation below.
Some time ago (a year?) I was told on this mailing-list that code
breakage due to undefinedness of signed overflow is not too common (I at
leas
Paolo Bonzini wrote:
foo->bar = make_a_bar();
foo->bar->none = value;
being rendered as:
call make_a_bar
foo->bar->none = value
foo->bar =
You are not describing a C compiler.
Um, I'm describing what gcc did?
I think he meant
x = make_a_bar ();
x->none = value;
foo->bar = x;
I don't
Paolo Bonzini wrote:
Some time ago (a year?) I was told on this mailing-list that code
breakage due to undefinedness of signed overflow is not too common (I
at least claimed with no evidence that it was more than one bug per
1,000 lines). My claim was counterclaimed by something like "most of
; i>= 0 ; ++i) {.}
The compiler will not be allowed to eliminate the "i>=0" check since
i<=x might return true when "i<=x && i>=0" would return false.
This wording also allows
for (i=0 ; i<=x ; ++i) {}
to be optimized to
i=x+1
since is ok to assume that i<=x returns *false* for i=MAX_INT+1.
--
Michael Veksler
http:///tx.technion.ac.il/~mveksler
s the upper limit of the loop upfront.
Anyway, the main point of the complete mail was to propose semantics
that is
strong enough for the "speed is all" camp, and predictable enough for the
"real world code assumes wrapping" camp.
--
Michael Veksler
http:///tx.technion.ac.il/~mveksler
n div_res, and mod_res=1. Then return to the following instruction.
Should I open a request for the kernel?
--
Michael Veksler
http:///tx.technion.ac.il/~mveksler
Gabriel Paubert wrote:
On Mon, Jan 15, 2007 at 10:34:23PM +0200, Michael Veksler wrote:
Once the kernel sees the FP trap (whatever its i368 name is),
it decodes the machine code and finds:
idivl (%ecx).
As far as I remember, this will put the result in two registers
one for div_res and one
Another problem is -ftrapv. You wouldn't want to kill traps on
INT_MIN/-1
with -ftrapv, would you?
GCC should be modified such that libc/kernel can distinguish
INT_MIN/-1 from INT_MIN%-1.
--
Michael Veksler
http:///tx.technion.ac.il/~mveksler
set? Probably generate a different code
sequence in the compiler.)
Simply let the kernel/libc set the overflow flag in this case, and let
the compiler
append an INTO instruction right after the idivl.
We do want to generate a trap for x / 0, of course.
Ian
--
Michael Veksler
http:///tx.technion.ac.il/~mveksler
x)
(I hope got the order right and the first prefix is redundant.)
(2)
The second option is to mark it in the executable in a different ELF
section, like debug info or like C++ exception handling.
This solution will make it workable only with the libc rather
than the kernel modi
cult to make it
scientific (e.g. how to have a reliable measure of quality of testing).
--
Michael Veksler
http:///tx.technion.ac.il/~mveksler
Marcin Dalecki wrote:
Wiadomość napisana w dniu 2007-01-24, o godz10:12, przez Michael Veksler:
Andrew, you are both correct and incorrect. Certainly, deterministic
unit testing
is not very useful. However, random unit testing is priceless. I have
been doing
pseudo-random unit tests for years
, emacs will enforce this policy for
all such files. The beauty of this is that different files may enforce
different policies. This allows consistency in old files without
re-indenting them, it allows different policies for different sub-projects.
--
Michael Veksler
http:///tx.technion.ac.il
assign copyright to FSF. I am
doing this with my student hat (need it for accurate profiling of my
research code), but my IBM researcher hat may (or may not) interfere,
and I'll need advice from our legal department.
Thanks
Michael
--
Michael Veksler
http:///tx.technion.ac.il/~mvek
tures that are more difficult to implement
if the PC is used instead of a string.
Thanks
Michael
--
Michael Veksler
http:///tx.technion.ac.il/~mveksler
Peter Barada wrote on 17/05/2005 07:12:41:
>
> >BS. Even the large disto builders do cross compilations a lot.
>
> Yeah, I know. I did consulting for a 'large disto builder'. Do you
> have a clue how long it takes to build the base packages for a PXA255
> board(including X11 that won't ev
Haren Visavadia wrote on 29/05/2005 10:51:00:
>
> You can search Bugzilla as well, so you do not fill in
> duplicate bug report.
Unfortunately, this is not 100% correct. Recently I have filed several
duplicates, *after* searching Bugzilla.
1. There are too many ways to phrase a title, and to
"Giovanni Bajo wrote on 29/05/2005 13:54:39:
> Vincent Lefevre <[EMAIL PROTECTED]> wrote:
>
> > Perhaps because GCC developers think that GCC isn't buggy when the
> > processor doesn't do the job for them? (I'm thinking of bug 323.)
>
>
> You are mistaken, we think GCC isn't buggy about 323
Giovanni Bajo wrote on 29/05/2005 13:50:59:
> Michael Veksler <[EMAIL PROTECTED]> wrote:
> > [2] GCC could implement a better error message.
>
> This is a bug, too. You can file a PR in Bugzilla explictly asking for a
more
> informative error message.
>
PR 21808
Michael
Daniel Berlin <[EMAIL PROTECTED]> wrote on 30/05/2005 06:41:54:
> On Sun, 2005-05-29 at 12:50 +0200, Giovanni Bajo wrote:
> > Michael Veksler <[EMAIL PROTECTED]> wrote:
> >
> > > 3. Nontrivial search of GCC Bugzilla are, sometimes,
> > >extre
Paul Schlie wrote on 08/06/2005 17:53:04:
>
> - I would have if someone could provide a concrete example of an
undefined
> behavior which produces a reliably useful/predictable result.
>
Well this is a simple hackery quiz, which is irrelevant to GCC.
1: int a, b;
2: int f()
Paul Schlie <[EMAIL PROTECTED]> wrote on 08/06/2005 21:16:46:
> > From: Michael Veksler <[EMAIL PROTECTED]>
> >> Paul Schlie wrote on 08/06/2005 17:53:04:
> >> - I would have if someone could provide a concrete example of an
> >> undefi
[EMAIL PROTECTED] wrote on 19/06/2005 18:33:55:
> Vincent Lefevre <[EMAIL PROTECTED]> writes:
>
> | On 2005-06-19 15:47:58 +0200, Gabriel Dos Reis wrote:
> | > If you think it is an invalid bug, then it effectively is a complete
> | > non-sense that you continue making noise on this list abo
[Gaby wants Vincent to explain:]
Vincent Lefevre <[EMAIL PROTECTED]> writes:
# This is complete non-sense. One doesn't prepare a patch for an invalid
# bug.
[Michael tries to interpret Vincent:]
| I think that what Vincent meant was:
| "One doesn't prepare a patch for a PR marked as INVALID"
Steven Bosscher <[EMAIL PROTECTED]> wrote on 20/06/2005 11:13:35:
> On Jun 20, 2005 09:51 AM, Michael Veksler <[EMAIL PROTECTED]> wrote:
>
> > Despite being descriptive and friendly, bug masters
> > frustrate me and other users by being too eager
> > to cl
Paul Schlie wrote on 20/06/2005 08:55:20:
> y = z ? z + x;// y == [INT_MIN+1, INT_MAX+2]
Invalid syntax, what did you mean?
> I guess I simply believe that optimizations should never alter the
logical
> behavior of a specified program relative to it's un-optimized form unless
> explic
Paul Schlie <[EMAIL PROTECTED]> wrote on 20/06/2005 14:03:53:
> > From: Michael Veksler <[EMAIL PROTECTED]>
...
> > Almost any optimization over line 8 will change the
> > behavior of line 4. I believe that you did not intend to
> > cover this case in your r
Paul Schlie wrote on 20/06/2005 14:13:33:
> > From: Robert Dewar <[EMAIL PROTECTED]>
...
> > Note that in the cases where something is statically optimized away
(these
> > are the easy cases), it is nice if the compiler warns that this is
happening
> > (that would certainly be the case in Ada
Paul Schlie <[EMAIL PROTECTED]> wrote on 20/06/2005 16:09:16:
> > From: Michael Veksler <[EMAIL PROTECTED]>>
> > As for overflow, you can say that you want instead of "undefined"
> > to treat is "unspecified". Where each architecture / opsys
According to the (very) long discussion on VRP, signed char/short/int/etc
do not have modulo semantic, they have an undefined behavior on overflow.
However in defines numeric_limits::is_modulo = true.
1. Is that a bug in , a bug in the standard, or is just C++
different
than C in this resp
Paul Koning <[EMAIL PROTECTED]> wrote on 27/06/2005 17:47:12:
> > "Nathan" == Nathan Sidwell <[EMAIL PROTECTED]> writes:
>
> >> And all useful programs we write rely on undefined behaviour of
> >> one sort or the other, starting with GCC. In the case of
>
> Nathan> They do? I thought
Andrew Pinski wrote on 28/06/2005 07:08:33:
> The first change in GCC which changed signed overflow/wrapping to be
> undefined
> was added back in 1992 in loop.c. The next change was in 1999 with the
> addition of simplify-rtx.c. Why are we talking about this now, instead
> of back
> when
Steven Bosscher wrote on 28/06/2005 09:55:03:
> On Tuesday 28 June 2005 07:12, Gabriel Dos Reis wrote:
> > For the concrete case at issue, if the hardware I'm writing the C/C++
> > programs for consistently displays modulo arithmetics for signed
> > integer type, Andrew can you tell me why G
Andrew Pinski wrote on 28/06/2005 08:34:25:
> On Jun 28, 2005, at 1:12 AM, Gabriel Dos Reis wrote:
>
> > So,
> > please, do refrain from reasoning like "since we did X for Y and Y was
> > undefined behaviour, we should do the same for Z." "Undefined
> > behaviour" isn't a 0 or 1 thingy, ev
Steven Bosscher <[EMAIL PROTECTED]> wrote on 28/06/2005 15:30:27:
> On Tuesday 28 June 2005 14:16, Paul Koning wrote:
> >
> > I must be missing something.
>
> Yes.
>
> > Unsigned has wraparound (modulo)
> > semantics.
>
> The whole point is that it doesn't.
>
I think that you confuse betwee
Gabriel Dos Reis wrote on 28/06/2005 17:12:43:
> Andrew Pinski <[EMAIL PROTECTED]> writes:
>
> | On Jun 28, 2005, at 9:58 AM, Gabriel Dos Reis wrote:
> |
> | > Notice that in your rendition you're assuming that you can convert
any
> | > unsigned value > INT_MAX to a int without invoking undefi
Nathan Sidwell <[EMAIL PROTECTED]> wrote on 28/06/2005 18:48:26:
>
> why are you talking about one's complement in the context of gcc. From
> implement-c.texi
>
>@cite{Whether signed integer types are represented using sign and
magnitude,
>two's complement, or one's complement, and
Morten Welinder wrote on 28/06/2005 19:59:10:
> > In particular, a very large number of C and C++ programs are written
> > with the assumptions:
>
> >- signed and unsigned types are modulo, except in loop induction
> > variables where it's bad taste
>
> Well, as demonstrated by INT_MIN/-1, g
Robert Dewar wrote on 28/06/2005 22:20:56:
> I am puzzled, why would *ANYONE* who knows C use int
> rather than unsigned if they want wrap around semantics?
>
int saturated_mul(int a, int b)
{
int ret= a*b;
if (a == 0 || ret % a == 0)
return ret;
else if ( (a<0) == (b<0) ) //
Michael Veksler wrote on 29/06/2005 00:53:33:
> Robert Dewar wrote on 28/06/2005 22:20:56:
>
> > I am puzzled, why would *ANYONE* who knows C use int
> > rather than unsigned if they want wrap around semantics?
> >
>
> int saturated_mul(int a, int b)
> {
&
After reading many messages on the subject of overflow
of signed integral values, I am inclined to think that the
standard was wrong to say that int overflow is undefined.
Of course this definition improves performance, but at
what cost? At the cost of program stability?
If the programmer wan
Robert Dewar <[EMAIL PROTECTED]> wrote on 29/06/2005 11:42:07:
> Michael Veksler wrote:
>
> > If the programmer wants a robust application,
> > then casting to unsigned must be present for almost any
> > usage of int.
>
> If you have a variable in your prog
Eric Botcazou <[EMAIL PROTECTED]> wrote on 29/06/2005 11:49:24:
> > This is unlike aliasing, when most lines of code out there,
> > did not break aliasing rules (even before they were
> > introduced).
>
> Are you sure? IIRC -fstrict-aliasing was once enabled at -O2 and then
> disabled to give
Giovanni Bajo wrote on 02/07/2005 12:18:00:
>
> Yes, but the condition is still morally true in the code. NDEBUG is meant
to
> speed up the generated code, and it's actually a pity that instead it
> *disables* some optimizations because we don't see the condition anymore.
My
> suggestion is tha
Hello,
In previous discussions on rounding of double on x86 I wanted
to find an example that points to the absurdity of current
gcc behavior.
At last I found such an example:
t.cpp start ---
#include
#include
double x=3.0;
int main()
{
std::tr1::unordered_set myset;
myset.inser
Paolo Carlini <[EMAIL PROTECTED]> wrote on 05/07/2005 16:33:12:
> Michael Veksler wrote:
>
> >The behavior of the second run does not look right. What does it mean?
> >1. Is it forbidden by tr1 to define unordered_set ?
> >2. Is it a bug in the tr1 document (wh
Joe Buck <[EMAIL PROTECTED]> wrote on 05/07/2005 21:10:25:
> On Tue, Jul 05, 2005 at 08:05:39PM +0200, Gabriel Dos Reis wrote:
> > It is definitely a good thing to use the full bits of value
> > representation if we ever want to make all "interesting" bits part of
> > the hash value. For reas
Paolo Carlini <[EMAIL PROTECTED]> wrote on 05/07/2005 19:05:40:
>
> However, sorry, as a matter of politeness, in my opinion expressions
> like "absurdity" or "very bad way" are much better accepted if
> accompanied by corresponding constructive contributions. Or,
> alternately, just avoid suc
There is one more thing to consider: the ABI.
By changing the code in the header file will break the ABI
of tr1::unordered_set. Code compiled with older gcc and
newer and fixed-gcc will not interoperate.
I don't see an easy path to avoid ABI breakage this time,
however how about preparing for
Paolo Carlini <[EMAIL PROTECTED]> wrote on 05/07/2005 23:48:03:
> Paolo Carlini wrote:
>
> >Michael Veksler wrote:
> >
> >>There is one more thing to consider: the ABI.
> >>By changing the code in the header file will break the ABI
> >>of t
Avi Kivity wrote on 06/07/2005 15:38:38:
> On Tue, 2005-07-05 at 20:05 +0200, Gabriel Dos Reis wrote:
> > Paolo Carlin
> > It is definitely a good thing to use the full bits of value
> > representation if we ever want to make all "interesting" bits part of
> > the hash value. For reasonable or
Eric Botcazou wrote on 14/07/2005 08:59:53:
> The compiler knows the answer of isinf (0) so it again optimizes away the
> call. Try something like:
>
> int a;
>
> int
> main (int argc, char *argv[])
> {
> a = isinf ((double) argc);
> return 0;
> }
This may work today, but and still br
Eric Botcazou <[EMAIL PROTECTED]> wrote on 14/07/2005 10:05:50:
[...]
> union U {
> int i;
> double d;
> };
>
> volatile int a;
>
> int
> main (int argc, char *argv[])
> {
> union U u;
> u.i = argc;
> a = isinf (u.d);
> return 0;
> }
>
Doesn't the code display undefined behavior wh
Gabriel Dos Reis wrote on 17/07/2005 06:07:29:
>
> | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20222
>
>Andrew Pinski has declared this to be a bug, but the audit trail
>isn't clear as to why.
>
Maybe because gcc treats -O1 differently from -O2, -O3,
and -Os ? Also, since abs is a (b
Gabriel Dos Reis wrote on 17/07/2005 06:07:29:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> | Anything it sees anything in a statement with volatile, it marks the
> | statement as volatile, which should stop things from touching it
> | (anything that *does* optimize something marked volatil
[EMAIL PROTECTED] wrote on 17/07/2005 08:30:26:
> Michael Veksler <[EMAIL PROTECTED]> writes:
>
> | Gabriel Dos Reis wrote on 17/07/2005 06:07:29:
> |
> | > Daniel Berlin <[EMAIL PROTECTED]> writes:
> | >
> | > | Anything it sees anything
Daniel Berlin <[EMAIL PROTECTED]> wrote on 17/07/2005 17:33:17:
> On Sun, 2005-07-17 at 08:18 +0300, Michael Veksler wrote:
[...]
> > I can't agree with that as is. I would refine it to:
> > Anything that *does* optimizes away visible reads or writes of
> >
Sebastian Pop wrote on 19/07/2005 09:49:11:
> Robert Dewar wrote:
> >
> > and that is called a false positive if in fact the loop does
> > not overrun. this sounds very dubious to me
I concur.
>
> The problem is that the compiler has no other information about the
> number of iterations in t
Sebastian Pop <[EMAIL PROTECTED]> wrote on 19/07/2005 12:58:23:
| Michael Veksler wrote:
| > This is problematic:
| > 1. I am not sure it will turn the warning off.
|
| So you don't want a warning that cannot be turned off simply by
| modifying the code.
Most of gcc warni
Kean Johnston wrote on 22/07/2005 00:41:06:
[...]
>
> I hope someone can help me. I am C++ impaired, and I am getting
> the following error when trying to bootstrap the current 4.0.2
> CVS. The error is coming from include/ext/bitmap_allocator.h
> line 111. The relevant code snippet is:
>
> cla
Richard Kenner wrote on 06/09/2005 00:27:51:
> I'm watching it deal with
>
> # small_1 = PHI <32(0), 1(1)>
>
> vrp_meet is called with [32, 32] and [1,1].
>
> It determines that the ranges don't intersect and then comes up with
> ~[0,0] since neither contain zero. But wouldn't [1,3
Yao Qi wrote on 06/09/2005 08:48:16:
> I am work on a floating points test according to IEEE754 and IEEE754
specifies
> that seven invalid arithmetic operations shall deliver a NaN unless they
are
> trapped:
> sqrt(Negative), 0*Infinity, 0.0/0.0, Infinity/Infinity,
REMAINDER(Anything,0.0),
> R
Audison Athena wrote on 24/09/2005 19:01:05:
[...]
>
> class RandomGenObj {
[...]
> int main() {
> vector v1(10, 10);
> RandomGenObj rg();
You have just declared a function named rg, that
accepts void and returns RandomGenObj by value.
C++'s ambiguity is a great thing, isn't it?
>
Wolfgang Roemer wrote on 06/10/2005 10:52:35:
>
> I don't know whether it is a bug or feature and I searched through the
mailing
> lists without success therefor I write my question this way:
>
> If you have a global variable inside a cpp file and create a library out
of
> that, the symbol name
Wolfgang Roemer wrote on 06/10/2005 12:03:39:
> Hello Michael,
>
> first of all: Thanks for the fast reply!
>
> On Thu Oct 06, 2005 10:33, you wrote:
> >> [..]
> >>
> >> It's a feature. It is undefined behavior to have conflicting
declarations
> >> in different translation units.
> >> [...]
Wolfgang Roemer wrote on 06/10/2005 16:14:03:
> On Thu Oct 06, 2005 14:50, Robert Dewar wrote:
> >> [..]
> >>
> >> I actually disagree with this, I think attempting to make the link
fail
> >> here would be a mistake.
>
> Why do you think that this would be a mistake?
>
I agree with Robert,
Per Bothner wrote on 31/10/2005 23:12:02:
> Joe Buck wrote:
> > So you want the compiler to only consider '\\$" a continuation,
>
> Not my preference, but that is my proposal, in the interest
> of compatibility.
^
Compatibility is not an absolute in this case. The two
opposite
Quoting Richard Guenther <[EMAIL PROTECTED]>:
> On 12/7/05, Morten Welinder <[EMAIL PROTECTED]> wrote:
> > He is kind of right, though. Outside struct (or perhaps union),
> > zero-sized arrays
> > make little sense and could be rejected. Or else I am missing something
> too.
>
> Well, as nearly
I am not sure if the original poster meant the same as I do. What I have
in mind is optimizations opportunities like the one of the following
linked list:
struct list_element
{
struct list_element *p_next;
int *p_value;
};
int sum_list_values(const struct list_element *p_list)
I am not sure, but it seems that this should have been sent to
[EMAIL PROTECTED] (it seems to be off-topic).
Is this scsi_buf.h a system header file?
Is it enough to have an empty c file with a single
#include
to trigger the warning?
>From an experience I had 2 weeks ago with gcc+aix, gcc can
Quoting Diego Novillo <[EMAIL PROTECTED]>:
[...]
>
> The compiler cannot statically short-circuit that predicate because it
> doesn't know whether best.score will be positive or not.
>
> The chain of inferences that the compiler would need to do to properly
> diagnose this case is beyond the sc
Paul,
In theory you could be right:
Quoting Paul Schlie <[EMAIL PROTECTED]>:
[...]
> Given that it would appear that the only time the compiler may attempt
> to optimize the allocation/use of an un-initialized variable, is when it
> knows for certain it hasn't been initialized; might it be prefer
I have been lurking on this list for many years, probably a decade.
I like the progress of GCC and its technology, esp. algorithms and data
structures,
which are exciting.
Yet, I do not contribute to GCC due to my priorities in life and not due
to any other technicality. There is family, work,
Joe Buck wrote:
On Mon, Mar 02, 2009 at 12:16:42PM -0800, Mark Mitchell wrote:
The C++ standard limits the compiler's ability to introduce copies. It
says "Here are where copies occur; some of these can be optimized away."
It doesn't say anything about inserting more copies. So, depending
Diego Novillo wrote:
On Thu, Mar 12, 2009 at 09:32, Paolo Carlini wrote:
Hi,
Notice how the third argument is 'int' instead of 'const int'. Is
this the way C++ is supposed to behave or is this a bug in the FE?
Well, I would say this is a rather well known C++ feature not a bu
There are several C++ features which not all compilers support well,
these features should be avoided if possible.
For example VC++ 2008 treats
struct foo{ static const int bar=1; };
As if the coder has also written (at the same spot)
const int foo::bar;
The consequence is multip
On 09/27/10 16:48, Paul Brook wrote:
Most of the interesting bits happen in the linker+debugger. "gcc -ffunction-
sections -fdata-sections -fPIC" is likely to be pretty good in terms of
compiler output.
What you then need is a linker that will relink an image, changing it as
little as possible
So, is union is a very useful feature in ISO C, without
gcc's extension? It seems that the only legal use of union
is to use the same type through the whole life of the object.
Here is the rationale:
Quoting Richard Guenther <[EMAIL PROTECTED]>:
> On 1/25/06, Alexandre Oliva <[EMAIL PROTECTED]> w
Hello Jack,
I has been almost a week since you mailed your question. I hope my
answer is still relevant.
Jack Howarth wrote:
Has anyone tried building python 2.4.3 using gcc trunk? The current gcc 4.2
seems to introduce a new regression in the Python testsuite...
test_builtin
test test_bu
Jack Howarth wrote:
import sys
divmod(-sys.maxint-1, -1)
(0, -2147483648)
If I add the -fwrapv flag to BASECFLAGS in the Makefile, I get...
(2147483648L, 0L)
So your analysis appears to be correct. Even more interesting is
that if I build python 2.4.3 with Apple's gcc fro
Sorry for the formatting weirdness. I should be more careful with
Thunderbird's auto-conversion to plain text. Here is the correct
version:
Jack Howarth wrote:
import sys
divmod(-sys.maxint-1, -1)
(0, -2147483648)
If I add the -fwrapv flag to BASECFLAGS in the Makefile, I get...
Paolo Bonzini wrote:
Jack Howarth wrote:
+ if (y == -1 && x < 0 && ((unsigned)x) == -(unsigned)x)
return DIVMOD_OVERFLOW;
or just a much clearer
if (y == -1 && x == INT_MIN)
return DIVMOD_OVERFLOW;
(possibly with a #include at the top).
Nit picking -
"x" i
Jordan, Laszlo (GE Healthcare) wrote:
Hi,
I had a crash in our software, which occured randomly. The valgrind logs
and the stack trace pointed to a code snippet, which uses ostringstream
for data conversion. (int -> string, float -> string, double-> string).
After changing the ostringstream co
fl wrote:
probably a library version mismatch, libstdc++.so.6.0.7 belongs to GCC
4.1.0.
regards,
lajos
Aren't libstdc++.so.6.0.n supposed to be compatible with each other
(regardless
of the value of n)?
Michael
Jack Howarth wrote:
Would any of the gcc developers care to drop by the python-dev
mailing list and give the author of python an answer?
http://mail.python.org/pipermail/python-dev/2006-August/068482.html
*Guido van Rossum wrote:
*
I'm not sure I follow why this isn't considered a regre
Guido van Rossum wrote:
It has calmed me down. But I hope that the future quality of the
arguments defending the feature is better than Michael Veksler's
attempt. Thanks for responding in person.
Sorry, next time I'll find a better example. Gosh, who would think
that a benign example, would st
On 07/30/2013 07:50 AM, David Starner wrote:
Sorry about the blank message; I accidentally hit the wrong button.
On Mon, Jul 29, 2013 at 7:19 AM, Andrew Haley wrote:
It was "This is possible, but it's tricky, and it's really important
to get it right. We don't want a half-arsed patch."
We've
On 07/30/2013 02:59 PM, hemant wrote:
I have written a std code for ARM 32-bit platform using math.h library and
float=powf(float,float) function. When I give input to my system as 100 ^
4.4 it gives me answer as 630957632. (as float) whereas calculator in
WindowsXP gives answer as 630957344
Hello All,
When I started using gcc-4.8.1 I was glad to observe a substantial
speed-up of about 10% in my code, as compared with gcc-4.7.3.
Usually, switching to newer compilers has a relatively minor effect
and definitely not a 10% speed-up. Was there anything significant
in gcc-4.8.1 which may
On 23/12/13 12:40, Michael Veksler wrote:
Hello All,
When I started using gcc-4.8.1 I was glad to observe a substantial
speed-up of about 10% in my code, as compared with gcc-4.7.3.
Usually, switching to newer compilers has a relatively minor effect
and definitely not a 10% speed-up. Was there
On 04/05/2012 02:45 PM, Eric Botcazou wrote:
I personally don't buy the "can't remember" argument. When you use
GCC, you just have to remember -g, -O, -W and that's pretty much it.
It is not that they can't remember. I am a TA at a moderately basic
programming course,
and student submit home
On 04/05/2012 03:33 PM, Robert Dewar wrote:
Wouldn't it be better in a "moderately basic programming course" to
provide standard canned scripts that set things up nicely for students
including the switches they need? Indeed for such a course wouldn't it
be better to use an appropriate IDE, so th
On 04/05/2012 03:43 PM, Andrey Belevantsev wrote:
FWIW, in our "basic programming" course students have to hand their
homework to an automated testing system which forces the compiler
options we think useful, including all the relevant warning switches
and -Werror. Of course, there is a web pag
On 02/14/2013 03:28 AM, Vladimir Makarov wrote:
On 13-02-13 6:36 PM, Michael Eager wrote:
[snip]
I thought about register pressure causing this, but I think that
should cause
spilling of one of the registers which were not used in this long
sequence,
rather than causing a large number of a
On 02/14/2013 06:31 PM, Vladimir Makarov wrote:
On 02/14/2013 03:46 AM, Michael Veksler wrote:
[snip]
I am reading this thread and getting more and more puzzled. The RA
stuff is very complicated,
having many constraints and many dependencies with other passes.
Taking this into
account, it
On 02/18/2013 02:02 PM, Alec Teal wrote:
On 18/02/13 11:40, Jeffrey Walton wrote:
Hi All,
http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#C-Dialect-Options
Is there an option to initialize variables to known values in a C/C++
program?
My use case is 'debug' builds and finding us
On 02/18/2013 03:28 PM, Jeffrey Walton wrote:
On Mon, Feb 18, 2013 at 7:42 AM, Michael Veksler
wrote:
On 02/18/2013 02:02 PM, Alec Teal wrote:
On 18/02/13 11:40, Jeffrey Walton wrote:
Hi All,
http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#C-Dialect-Options
Is there an option to
Hello,
Currently libstdc++ violates ODR:
iostream: extern ostream cout;
global_io.cc: fake_ostream cout;
It assumes that gcc will work fine with this. Apparently it does, for now.
After solving a similar problem in my code using a similar technique -
to find out that it does not work for M
98 matches
Mail list logo
