lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <d913acf949f84c6dec496a1f52c1f9f5@kernel.crashing.org>
Date:	Thu, 4 Jan 2007 19:34:46 +0100
From:	Segher Boessenkool <segher@...nel.crashing.org>
To:	Linus Torvalds <torvalds@...l.org>
Cc:	akpm@...l.org, Albert Cahalan <acahalan@...il.com>,
	linux-kernel@...r.kernel.org, s0348365@....ed.ac.uk,
	bunk@...sta.de, mikpe@...uu.se
Subject: Re: kernel + gcc 4.1 = several problems

> I'll happily turn off compiler features that are "clever optimizations
> that never actually matter in practice, but are just likely to possible
> cause problems".

The "signed wrap is undefined" thing doesn't fit in this category
though:

-- It is an important optimisation for loops with a signed
    induction variable;
-- "Random code" where it causes problems is typically buggy
    already (i.e., code that doesn't take overflow into account
    at all won't expect wraparound either);
-- Code that explicitly depends on signed overflow two's complement
    wraparound can be trivially converted to use unsigned arithmetic
    (and in almost all cases it really should have used that already).

If GCC can generate warnings for things in the second bullet point
(and it probably will, but nothing is finalised yet), I don't see
a reason for the kernel to turn off the optimisation.  Why not try
it out and only _if_ it causes troubles (after the compiler version
is stable) turn it off.

to take is not to add the compiler flag, but to fix the code.
>>
>> Nope, unless we decide that the performance advantages of
>> a language change are worth the risk and pain.

But it's not a language change -- GCC has worked like this
for a _long_ time already, since May 2003 if I read the
ChangeLog correctly -- it's just that it starts to optimise
some things more aggressively now.

> With integer overflow optimizations, the same situation may be true. 
> The
> kernel has never been "strict ANSI C". We've always used C extensions. 
> The
> extension of "signed integer arithmetic follows 
> 2's-complement-arithmetic"
> is a perfectly sane extension to the language, and quite possibly worth
> it.

Could be.  Who knows, without testing.  I'm just saying to
not add -fwrapv purely as a knee-jerk reaction.

> And the fact that it's not "strict ANSI C" has absolutely _zero_
> relevance.

I certainly never claimed so, that's all in Albert's mind it seems :-)


Segher

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ