On 03/10/2010 12:24, Ralf Wildenhues wrote:
> [ adding bug-gnulib ]
>
> Hi Dave,
>
> * Dave Korn wrote on Sun, Oct 03, 2010 at 01:42:15PM CEST:
>> I can't find any mention of it at the usual place for external sources
>> (http://gcc.gnu.org/codingconventions.h
On 31 December 2006 18:47, Paul Eggert wrote:
> "Daniel Berlin" <[EMAIL PROTECTED]> writes:
> The question is not whether GCC should support wrapv
> semantics; it already does, if you specify -fwrapv.
> The question is merely whether wrapv should be the default
> with optimization levels -O0 thro
On 30 December 2006 11:49, Robert Dewar wrote:
> Paul Eggert wrote:
Nor would I relish the prospect of keeping wrapv assumptions out of
GCC as other developers make further contributions, as the wrapv
assumption is so natural and pervasive.
>>> It's neither natural not pervasive to
On 22 December 2006 00:59, Denis Vlasenko wrote:
> Or this, absolutely typical C code. i386 arch can compare
> 16 bits at a time here (luckily, no alighment worries on this arch):
Whaddaya mean, no alignment worries? Misaligned accesses *kill* your
performance!
I know this doesn't affect c
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-
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
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
On 20 December 2006 02:40, Mike Stump wrote:
> On Dec 19, 2006, at 6:33 PM, Dave Korn wrote:
>> On 20 December 2006 02:28, Andrew Pinski wrote:
>>
>>>> Paul Brook wrote:
>>>>>> Compiler can optimize it any way it wants,
>>>>>> as
On 20 December 2006 02:28, Andrew Pinski wrote:
>> 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 p
10 matches
Mail list logo
