Re: [isocpp-parallel] Proposal for new memory_order_consume definition
On 2016.02.27 at 15:10 -0800, Paul E. McKenney via llvm-dev wrote: > On Sat, Feb 27, 2016 at 11:16:51AM -0800, Linus Torvalds wrote: > > On Feb 27, 2016 09:06, "Paul E. McKenney" > > wrote: > > > > > > > > > But we do already have something very similar with signed integer > > > overflow. If the compiler can see a way to generate faster code that > > > does not handle the overflow case, then the semantics suddenly change > > > from twos-complement arithmetic to something very strange. The standard > > > does not specify all the ways that the implementation might deduce that > > > faster code can be generated by ignoring the overflow case, it instead > > > simply says that signed integer overflow invoked undefined behavior. > > > > > > And if that is a problem, you use unsigned integers instead of signed > > > integers. > > > > Actually, in the case of there Linux kernel we just tell the compiler to > > not be an ass. We use > > > > -fno-strict-overflow > > That is the one! > > > or something. I forget the exact compiler flag needed for "the standard is > > as broken piece of shit and made things undefined for very bad reasons". > > > > See also there idiotic standard C alias rules. Same deal. > > For which we use -fno-strict-aliasing. Do not forget -fno-delete-null-pointer-checks. So the kernel obviously is already using its own C dialect, that is pretty far from standard C. All these options also have a negative impact on the performance of the generated code. -- Markus
Re: [isocpp-parallel] Proposal for new memory_order_consume definition
On Sun, Feb 28, 2016 at 12:27 AM, Markus Trippelsdorf wrote: >> > >> > -fno-strict-overflow >> >> -fno-strict-aliasing. > > Do not forget -fno-delete-null-pointer-checks. > > So the kernel obviously is already using its own C dialect, that is > pretty far from standard C. > All these options also have a negative impact on the performance of the > generated code. They really don't. Have you ever seen code that cared about signed integer overflow? Yeah, getting it right can make the compiler generate an extra ALU instruction once in a blue moon, but trust me - you'll never notice. You *will* notice when you suddenly have a crash or a security issue due to bad code generation, though. The idiotic C alias rules aren't even worth discussing. They were a mistake. The kernel doesn't use some "C dialect pretty far from standard C". Yeah, let's just say that the original C designers were better at their job than a gaggle of standards people who were making bad crap up to make some Fortran-style programs go faster. They don't speed up normal code either, they just introduce undefined behavior in a lot of code. And deleting NULL pointer checks because somebody made a mistake, and then turning that small mistake into a real and exploitable security hole? Not so smart either. The fact is, undefined compiler behavior is never a good idea. Not for serious projects. Performance doesn't come from occasional small and odd micro-optimizations. I care about performance a lot, and I actually look at generated code and do profiling etc. None of those three options have *ever* shown up as issues. But the incorrect code they generate? It has. Linus
Re: [llvm-dev] [isocpp-parallel] Proposal for new memory_order_consume definition
Sometimes Linus says some really flippant and funny things but gosh I couldn't agree more.. with one tiny nit.. Properly written Fortran and a good compiler is potentially as fast or faster than typical C version in HPC codes. (yes you may be able to get the c version faster, but it would take some effort.) Original Message From: Linus Torvalds via llvm-dev Sent: Sunday, February 28, 2016 23:13 To: Markus Trippelsdorf Reply To: Linus Torvalds Cc: linux-a...@vger.kernel.org; gcc@gcc.gnu.org; Jade Alglave; paral...@lists.isocpp.org; llvm-...@lists.llvm.org; Will Deacon; Linux Kernel Mailing List; David Howells; Peter Zijlstra; Ramana Radhakrishnan; Luc Maranget; Andrew Morton; Paul McKenney; Ingo Molnar Subject: Re: [llvm-dev] [isocpp-parallel] Proposal for new memory_order_consume definition On Sun, Feb 28, 2016 at 12:27 AM, Markus Trippelsdorf wrote: >> > >> > -fno-strict-overflow >> >> -fno-strict-aliasing. > > Do not forget -fno-delete-null-pointer-checks. > > So the kernel obviously is already using its own C dialect, that is > pretty far from standard C. > All these options also have a negative impact on the performance of the > generated code. They really don't. Have you ever seen code that cared about signed integer overflow? Yeah, getting it right can make the compiler generate an extra ALU instruction once in a blue moon, but trust me - you'll never notice. You *will* notice when you suddenly have a crash or a security issue due to bad code generation, though. The idiotic C alias rules aren't even worth discussing. They were a mistake. The kernel doesn't use some "C dialect pretty far from standard C". Yeah, let's just say that the original C designers were better at their job than a gaggle of standards people who were making bad crap up to make some Fortran-style programs go faster. They don't speed up normal code either, they just introduce undefined behavior in a lot of code. And deleting NULL pointer checks because somebody made a mistake, and then turning that small mistake into a real and exploitable security hole? Not so smart either. The fact is, undefined compiler behavior is never a good idea. Not for serious projects. Performance doesn't come from occasional small and odd micro-optimizations. I care about performance a lot, and I actually look at generated code and do profiling etc. None of those three options have *ever* shown up as issues. But the incorrect code they generate? It has. Linus ___ LLVM Developers mailing list llvm-...@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Please remove mirror2.babylon.network
Dear, Due to reorganization of the mirror servers we will be taking the following mirror offline. Could you please remove it from the list? http://mirror2.babylon.network/gcc/ | ftp://mirror2.babylon.network/gcc/ | rsync://mirror2.babylon.network/gcc/ Once we sorted out our servers we will inform you when a new mirror will be put online. Thanks in advance! -- Tim Semeijn Babylon Network PGP: 0x2A540FA5 / 3DF3 13FA 4B60 E48A E755 9663 B187 0310 2A54 0FA5 signature.asc Description: OpenPGP digital signature
Re: [WWWDocs] Deprecate support for non-thumb ARM devices
On Wed, 24 Feb 2016, Richard Earnshaw (lists) wrote: > I propose to commit this patch later this week. + Support for revisions of the ARM architecture prior to ARMv4t has + been deprecated and will be removed in a future GCC release. + This affects ARM6, ARM7 (but not ARM7TDMI), ARM8, StrongARM, and + Faraday fa526 and fa626 devices, which do not have support for + the Thumb execution state. I am wondering whether this may be confusing for those not intricately familiar with the older history of ARM platforms. ARMv8 is pretty new, googling for it has http://www.arm.com/products/processors/armv8-architecture.php as first hit, for example, and the only difference versus ARM8 is that little lower-case "v". Gerald
Re: [WWWDocs] Deprecate support for non-thumb ARM devices
On February 28, 2016 3:20:24 PM CST, Gerald Pfeifer wrote: >On Wed, 24 Feb 2016, Richard Earnshaw (lists) wrote: >> I propose to commit this patch later this week. > >+ Support for revisions of the ARM architecture prior to ARMv4t >has >+ been deprecated and will be removed in a future GCC release. >+ This affects ARM6, ARM7 (but not ARM7TDMI), ARM8, StrongARM, >and >+ Faraday fa526 and fa626 devices, which do not have support for >+ the Thumb execution state. > >I am wondering whether this may be confusing for those not >intricately familiar with the older history of ARM platforms. > >ARMv8 is pretty new, googling for it has > http://www.arm.com/products/processors/armv8-architecture.php >as first hit, for example, and the only difference versus ARM8 >is that little lower-case "v". I assume this means a number of values for the various -mXXX arguments will be removed. Would it be more helpful to list those values? I have to agree with Gerald. I think this will obsolete a few older RTEMS BSPs but based on that wording, I don't know which. >Gerald --joel
[wwwdocs] PATCH for Re: Please remove mirror2.babylon.network
On Sun, 28 Feb 2016, NOC wrote: > Due to reorganization of the mirror servers we will be taking the > following mirror offline. Could you please remove it from the list? > > http://mirror2.babylon.network/gcc/ | ftp://mirror2.babylon.network/gcc/ > | rsync://mirror2.babylon.network/gcc/ Thank you for letting us know. I really appreciate the heads-up and updated our mirrors list as follows. Gerald Index: mirrors.html === RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v retrieving revision 1.233 diff -u -r1.233 mirrors.html --- mirrors.html24 Oct 2015 23:22:54 - 1.233 +++ mirrors.html28 Feb 2016 20:57:50 - @@ -38,11 +38,6 @@ Hungary, Budapest: http://robotlab.itk.ppke.hu/gcc/";>robotlab.itk.ppke.hu, thanks to Adam Rak (neurhlp at gmail.com) Japan: ftp://ftp.dti.ad.jp/pub/lang/gcc/";>ftp.dti.ad.jp, thanks to IWAIZAKO Takahiro (ftp-admin at dti.ad.jp) Japan: http://ftp.tsukuba.wide.ad.jp/software/gcc/";>ftp.tsukuba.wide.ad.jp, thanks to Kohei Takahashi (tsukuba-ftp-servers at tsukuba.wide.ad.jp) -The Netherlands, Amsterdam: - http://mirror2.babylon.network/gcc/";>http://mirror2.babylon.network/gcc/ | - ftp://mirror2.babylon.network/gcc/";>ftp://mirror2.babylon.network/gcc/ | - rsync://mirror2.babylon.network/gcc/, - thanks to Tim Semeijn (noc@babylon.network) at Babylon Network. The Netherlands, Nijmegen: ftp://ftp.nluug.nl/mirror/languages/gcc";>ftp.nluug.nl, thanks to Jan Cristiaan van Winkel (jc at ATComputing.nl) Slovakia, Bratislava: http://gcc.fyxm.net/";>gcc.fyxm.net, thanks to Jan Teluch (admin at 2600.sk) UK: ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/";>ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/, thanks to mirror at mirrorservice.org
gcc-6-20160228 is now available
Snapshot gcc-6-20160228 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160228/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 233797 You'll find: gcc-6-20160228.tar.bz2 Complete GCC MD5=4d56863537807982566015bba99e92b0 SHA1=42169efab8c1ca7b0d5380b3128ec25065642613 Diffs from 6-20160221 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
GNU MPFR 3.1.4 Release Candidate 2
The release of GNU MPFR 3.1.4 ("canard à l'orange", patch level 4)
is imminent. Please help to make this release as good as possible
by downloading and testing this release candidate:
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc2.tar.xz
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc2.tar.bz2
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc2.tar.gz
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc2.zip
The SHA1 digests:
cb51ad47aeed9f4261cb1d2b71dd1e5d07303a23 mpfr-3.1.4-rc2.tar.bz2
df3a6d8ce6bc8ec9166f102e267223629210e7ce mpfr-3.1.4-rc2.tar.gz
a5b77eea480675aef0b2655ea8c137361dd1a396 mpfr-3.1.4-rc2.tar.xz
b59f0ca5a05f7aba6448bbc68d00aad3249878ec mpfr-3.1.4-rc2.zip
The SHA256 digests:
b98e116590642dcf64b4d82206703569c2a1ac5e004e4a2567324fa7c7b524ce
mpfr-3.1.4-rc2.tar.bz2
cb0f85717fd32e59f02cc5745587bd2b2f6d6b5d5e591026c39002b409061d8a
mpfr-3.1.4-rc2.tar.gz
9c7415c407bb6b510916230515b818a1cf1e3fa66c2837c7ebf7f50cc9b236f1
mpfr-3.1.4-rc2.tar.xz
69345e587ba8977a434992f20095c21199aafc8fe4e04f9804222aa154fc1b08
mpfr-3.1.4-rc2.zip
The signatures:
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc2.tar.xz.asc
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc2.tar.bz2.asc
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc2.tar.gz.asc
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc2.zip.asc
Each tarball is signed by Vincent Lefèvre. This can be verified
using the DSA key ID 98C3739D; this key can be retrieved with:
gpg --recv-keys 98C3739D
or by downloading it from .
The key fingerprint is:
07F3 DBBE CC1A 3960 5078 094D 980C 1976 98C3 739D
The signatures can be verified with: gpg --verify
You should check that the key fingerprint matches.
Changes from version 3.1.3 to version 3.1.4:
- Improved MPFR manual.
- Bug fixes (see and ChangeLog file).
- MinGW (MS Windows): Added support for thread-safe DLL (shared library).
Please send success and failure reports with "./config.guess" output
to .
If no problems are found, GNU MPFR 3.1.4 should be released
around 2016-03-05.
Regards,
--
Vincent Lefèvre - Web:
