Gabriel Dos Reis wrote:
I don't believe this particular issue of optimization based on
"undefined behaviour" can be resolved by just telling people "hey
look, the C standard says it is undefined, therefore we can optimize.
And if you're not happy, just tell the compiler not to optimize".
For not
Matthew Woehlke <[EMAIL PROTECTED]> writes:
> That said, I've seen even stranger things, too. For example:
>
> foo->bar = make_a_bar();
> foo->bar->none = value;
>
> being rendered as:
>
> call make_a_bar
> foo->bar->none = value
> foo->bar =
That would obviously be a bug in the compiler.
>
Andrew Haley <[EMAIL PROTECTED]> writes:
[...]
| C is no longer a kind of high-level assembly laguage:
| it's defined by a standard, in terms of an abstract machine, and some
| operations are not well-defined.
that does not mean C is not a kind of high-level assembly language.
:-/
-- Gaby
"Dave Korn" <[EMAIL PROTECTED]> writes:
[...]
| > We (in a major, commercial application) ran into exactly this issue.
| > 'asm volatile("lock orl $0,(%%esp)"::)' is your friend when this happens
| > (it is a barrier across which neither the compiler nor CPU will reorder
| > things). Failing that
Paul Brook <[EMAIL PROTECTED]> writes:
| > Compiler can optimize it any way it wants,
| > as long as result is the same as unoptimized one.
|
| We have an option for that. It's called -O0.
|
| Pretty much all optimization will change the behavior of your program. The
| important distinction is
Marcin Dalecki wrote:
On 2006-12-20, at 22:48, Richard B. Kreckel wrote:
2) Signed types are not an algebra, they are not even a ring, at
least when their elements are interpreted in the canonical way as
integer numbers. (Heck, what are they?)
You are apparently using a different definiti
Marcin Dalecki wrote:
Numerical stability of incomplete floating point representations are
an entirely different
problem category then some simple integer tricks. In the first case
the difficulties are inherent
to the incomplete representation of the calculation domain. In the
second case it's
On 12/20/06, Dave Korn <[EMAIL PROTECTED]> wrote:
...
> We (in a major, commercial application) ran into exactly this issue.
> 'asm volatile("lock orl $0,(%%esp)"::)' is your friend when this happens
> (it is a barrier across which neither the compiler nor CPU will reorder
> things). Failing that
On 21 December 2006 02:50, Gabriel Dos Reis wrote:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> [...]
>
>> C is no longer a kind of high-level assembly laguage:
>> it's defined by a standard, in terms of an abstract machine, and some
>> operations are not well-defined.
>
> that does not mean
On 20 December 2006 21:42, Matthew Woehlke wrote:
> Dave Korn wrote:
>>> Particularly lock-free queues whose correct
>>> operation is critically dependent on the order in which the loads and
>>> stores are performed.
>>
>> No, absolutely not. Lock-free queues work by (for example) having a
>>
On 20 December 2006 20:16, Seongbae Park wrote:
> On 12/20/06, Dave Korn <[EMAIL PROTECTED]> wrote:
> ...
>>> We (in a major, commercial application) ran into exactly this issue.
>>> 'asm volatile("lock orl $0,(%%esp)"::)' is your friend when this happens
>>> (it is a barrier across which neither
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Lorenzo Bettini on 12/20/2006 12:44 PM:
>> Thanks for the feedback. Last time we discussed whether gnulib-cache.m4
>> should be added to EXTRA_DIST by gnulib-tool, so that anyone getting a
>> tarball can do "gnulib-tool --update", there wa
But the same applies to floating point numbers. There, the
situation is even better, because nowadays I can rely on a float or
double being the representation defined in IEEE 754 because there
is such overwhelming hardware support.
You better don't. Really! Please just realize for example t
Andreas Schwab wrote:
Matthew Woehlke <[EMAIL PROTECTED]> writes:
That said, I've seen even stranger things, too. For example:
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
On 2006-12-20, at 22:48, Richard B. Kreckel wrote:
2) Signed types are not an algebra, they are not even a ring, at
least when their elements are interpreted in the canonical way as
integer numbers. (Heck, what are they?)
You are apparently using a different definition of an algebra or rin
Matthew Woehlke <[EMAIL PROTECTED]> writes:
> That said, I've seen even stranger things, too. For example:
>
> 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.
Andreas.
--
A
On 12/20/06, Lorenzo Bettini <[EMAIL PROTECTED]> wrote:
> You see, there's no clear borderline between <> and "".
I see, but are <> ensuring that the version of gnulib is used (even if
getopt.h is available in the system)?
Hi Lorenzo,
Not possible. The only difference between them from the c
On 20 December 2006 16:25, Matthew Woehlke wrote:
> Dave Korn wrote:
>> On 20 December 2006 02:28, Andrew Pinski wrote:
Paul Brook wrote:
> Pretty much all optimization will change the behavior of your program.
Now that's a bit TOO strong a statement, critical optimizations lik
Bruno Haible wrote:
Lorenzo Bettini wrote:
gnulib-tool says:
You may need to add #include directives for the following .h files.
#include
shouldn't it be
#include "getopt.h"
?
Given that the source and build directories are searched by the compiler
(due to the many "-I." flags), it
Bruno Haible wrote:
Lorenzo Bettini wrote:
Maybe: "gnulib-tool --update" relies on the presence of gnulib-comp.m4 and
gnulib-cache.m4.
OK, those files were not there (this is because gnulib-cache.m4 is not
included in the .tar.gz produced by make dist, is this correct?)
now --update works
Lorenzo Bettini wrote:
> gnulib-tool says:
>
> You may need to add #include directives for the following .h files.
>#include
>
> shouldn't it be
>
>#include "getopt.h"
>
> ?
Given that the source and build directories are searched by the compiler
(due to the many "-I." flags), it boil
Lorenzo Bettini wrote:
> > Maybe: "gnulib-tool --update" relies on the presence of gnulib-comp.m4 and
> > gnulib-cache.m4.
> >
>
> OK, those files were not there (this is because gnulib-cache.m4 is not
> included in the .tar.gz produced by make dist, is this correct?)
>
> now --update works as
Yoann Vandoorselaere wrote:
Le mardi 19 décembre 2006 à 09:52 -0800, Paul Eggert a écrit :
Paolo Bonzini <[EMAIL PROTECTED]> writes:
I don't remember if it was Paul or Bruno who suggested that POLLHUP
does not increase the return value. What do you think?
It wasn't me, so I guess it was Brun
Dave Korn wrote:
On 20 December 2006 02:28, Andrew Pinski wrote:
Paul Brook wrote:
Pretty much all optimization will change the behavior of your program.
Now that's a bit TOO strong a statement, critical optimizations like
register allocation and instruction scheduling will generally not chan
Bruno Haible wrote:
Lorenzo Bettini wrote:
~/work/gnulib/gnulib-tool --update --dry-run
Module list with included dependencies:
File list:
lib/dummy.c
m4/onceonly_2_57.m4
Create directory ./lib
Create directory ./m4
Create directory ./lib
Create directory ./m4
Copy file lib/dummy.c
Copy f
by the way, upon importing getopt, gnulib-tool says:
You may need to add #include directives for the following .h files.
#include
shouldn't it be
#include "getopt.h"
?
--
+-+
| Lorenzo Bettini ICQ# lbetto, 16080134 |
| PhD
Ralf Wildenhues wrote:
> > "gnulib-tool --update" relies on the presence of gnulib-comp.m4 and
> > gnulib-cache.m4.
>
> Which may be found only after knowing the value of $m4base, as that's
> where those files are.
There's a trick. Look at gnulib-tool lines 2780..2818.
Bruno
* Bruno Haible wrote on Wed, Dec 20, 2006 at 03:01:47PM CET:
> Lorenzo Bettini wrote:
> > ~/work/gnulib/gnulib-tool --update --dry-run
[...]
> > probably I forgot to include in the CVS some vital file?
>
> Maybe: "gnulib-tool --update" relies on the presence of gnulib-comp.m4 and
> gnulib-cache.m4
Lorenzo Bettini wrote:
> ~/work/gnulib/gnulib-tool --update --dry-run
> Module list with included dependencies:
>
> File list:
>lib/dummy.c
>m4/onceonly_2_57.m4
> Create directory ./lib
> Create directory ./m4
> Create directory ./lib
> Create directory ./m4
> Copy file lib/dummy.c
> Copy
On 2006-12-20, at 00:10, Richard B. Kreckel wrote:
C89 did not refer to IEEE 754 / IEC 60559. Yet, as far as I am aware,
-ffast-math or the implied optimizations have never been turned on
by GCC
unless explicitly requested. That was a wise decision.
By the same token it would be wise to re
Zdenek Dvorak wrote:
actually, you do not even need (invalid) multithreaded programs to
realize that register allocation may change behavior of a program.
If the size of the stack is bounded, register allocation may
cause or prevent program from running out of stack, thus turning a
crashing prog
Denis Vlasenko writes:
> On Tuesday 19 December 2006 20:05, Andrew Haley wrote:
> > Denis Vlasenko writes:
> > >
> > > I wrote this just a few days ago:
> > >
> > > do {
> > > int32_t v1 = v << 1;
> > > if (v < 0) v1 ^= mask;
> > >
Hello,
> > Paul Brook wrote:
> > >> Compiler can optimize it any way it wants,
> > >> as long as result is the same as unoptimized one.
> > >
> > > We have an option for that. It's called -O0.
> > >
> > > Pretty much all optimization will change the behavior of your program.
> >
> > Now that's
Bruno Haible wrote:
Lorenzo Bettini wrote:
as reported in the documentation, I have the source base and m4 base,
resp., in gl and gl/m4
now I'm trying to run gnulib-tool --update as follows, but I get an error:
gnulib-tool --update --m4-base=gl/m4/ --source-base=gl/ --dry-run
gnulib-tool: inv
Yes, for the moment this is the only one.
In case I need some more I'll send you an email.
thanks a lot
cheers
Lorenzo
Bruno Haible wrote:
Lorenzo Bettini wrote:
I thus included a possible patch.
strdup.h is all you need? Ok, I commit this:
--
+---
35 matches
Mail list logo
