linux-kernel - Re: kernel + gcc 4.1 = several problems

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: <8069085182dff3b0e63a661d81804dbb@kernel.crashing.org>
Date:	Thu, 4 Jan 2007 18:24:08 +0100
From:	Segher Boessenkool <segher@...nel.crashing.org>
To:	"Albert Cahalan" <acahalan@...il.com>
Cc:	akpm@...l.org, linux-kernel@...r.kernel.org, s0348365@....ed.ac.uk,
	bunk@...sta.de, mikpe@...uu.se, torvalds@...l.org
Subject: Re: kernel + gcc 4.1 = several problems

>> Lack of the flag does not break any valid C code, only code
>> making unwarranted assumptions (i.e., buggy code).
>
> Right, if "C" means "strictly conforming ISO C" to you.

Without any further qualification, it of course does, yes.

> (in which case, nearly all real-world code is broken)

Not "nearly all" -- but lots of code, yes.

> FYI, the kernel also assumes that a "char" is 8 bits.
> Maybe you should run away screaming.

No, that's fine with me.  It's fine with GCC as well
of course.

>> Anyway, with 4.1 you shouldn't see frequent problems due to
>
> Right, it gets much worse with the current gcc snapshots.

Yes.  And that problem will be fixed some way pretty soon --
simply because it _has_ to be fixed.

> IMHO you should play such games with "g++ -O9", but that's
> a discussion for a different mailing list.

For a different mailing list indeed; let me just point out
that for certain important quite common cases it's an ~50%
overall speedup.

>> "not using -fwrapv while my code is broken WRT signed overflow"
>> yet; and if/when problems start to happen, to "correct" action
>> 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.

If the kernel breaks all over the place, of course you should add
the flag.  But it won't, it would break *all* programs all over
the place then, and that wouldn't be acceptable to GCC.  If instead
only a few kernel code bugs pop up, it's easy to fix.

Aaaaanyway -- my only real point was to point out that there's
no doomsday scenario here, yes current GCC TOT seems to regress
here (for some definition of that word), but GCC development
is in stage 1, that sort of thing happens.  It'll stabilise
again.

In the meantime, building git HEAD kernels with GCC 4.1 and
4.2 will probably rattle out quite a few bugs still, both
in the kernel and in GCC -- neither is used all that often
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/