Re: SafeStack proposal in GCC
* Rich Felker: > On Wed, Apr 20, 2016 at 06:09:54PM +0200, Volodymyr Kuznetsov wrote: >> We have prototype that supports swapcontext that we're happy to >> release, but it clearly requires more work before being ready to merge >> upstream. > > The *context APIs are deprecated and I'm not sure they're worth > supporting with this. It would be a good excuse to get people to stop > using them. QEMU is a high-value target which would benefit from stack hardening, and it is a heavy user of these interfaces.
Re: Bug maintenance
On 4/28/2016 2:01 AM, Richard Biener wrote: On Thu, Apr 28, 2016 at 9:35 AM, David Wohlferd wrote: As part of the work I've done on inline asm, I've been looking thru the bugs for it. There appear to be a number that have been fixed or overtaken by events over the years, but the bug is still open. Is closing some of these old bugs of any value? Yes, definitely. If so, how do I pursue this? I suppose adding a final comment to them will work, people (like me) watching gcc-bugs can then do the actual closing. Perfect. That gives the OP a chance to respond as well. Look for my updates to 30527, 39440 & 43319. dw
Re: Bug maintenance
On 4/28/2016 9:41 AM, Martin Sebor wrote: On 04/28/2016 01:35 AM, David Wohlferd wrote: As part of the work I've done on inline asm, I've been looking thru the bugs for it. There appear to be a number that have been fixed or overtaken by events over the years, but the bug is still open. Is closing some of these old bugs of any value? If so, how do I pursue this? There are nearly 10,000 still unresolved bugs in Bugzilla, almost half of which are New, and a third Unconfirmed, so I'm sure any effort to help reduce the number is of value and appreciated. That's exactly what prompted me to ask. There's such a vast number of them, it's hard to believe that 9 year old bugs are still of interest. I can share with you my own approach to dealing with them (others might have better suggestions). In cases where the commit that fixed a bug is known, I mention it in the comment closing the bug. I also try to indicate the version in which the bug was fixed (if I can determine it using the limited number of versions I have built). Otherwise, when a test doesn't already exist (finding out whether or not one does can be tedious), I add one before closing the bug will help avoid a regression. I'll see what I can do. dw
Re: Bug maintenance
On 4/28/2016 12:23 PM, Andrew Pinski wrote: On Thu, Apr 28, 2016 at 12:35 AM, David Wohlferd wrote: As part of the work I've done on inline asm, I've been looking thru the bugs for it. There appear to be a number that have been fixed or overtaken by events over the years, but the bug is still open. Is closing some of these old bugs of any value? Yes it is. In fact this is how I got my start into GCC. If so, how do I pursue this? If you go through the bug reports and have a low rate of false positives, I (and others) can get you permission to change the bug reports (I started out with a bug report only account too). I'll do my best. But it's not always clear what might trigger a debate. I swear to you, I never expected 24414 to blow up the way it did. dw
Re: Bug maintenance
On Sun, 2016-05-08 at 15:03 -0700, David Wohlferd wrote: > On 4/28/2016 9:41 AM, Martin Sebor wrote: > > On 04/28/2016 01:35 AM, David Wohlferd wrote: > > > As part of the work I've done on inline asm, I've been looking > > > thru the > > > bugs for it. There appear to be a number that have been fixed or > > > overtaken by events over the years, but the bug is still open. > > > > > > Is closing some of these old bugs of any value? > > > > > > If so, how do I pursue this? > > > > There are nearly 10,000 still unresolved bugs in Bugzilla, almost > > half of which are New, and a third Unconfirmed, so I'm sure any > > effort to help reduce the number is of value and appreciated. > > That's exactly what prompted me to ask. There's such a vast number > of them, it's hard to believe that 9 year old bugs are still of > interest. Sometimes there is. Before randomly closing any bugs because they are too old, one should at least have a look at them and see if they're still an issue etc. Often things would've been fixed along the way, but not all of them. Cheers, Oleg
Machine constraints list
Looking at the v6 release criteria (https://gcc.gnu.org/gcc-6/criteria.html) there are about a dozen supported platforms. Looking at the Machine Constraints docs (https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html), there are 34 architectures listed. That's a lot of entries to scroll thru. If these architectures aren't supported anymore, is it time to drop some of these from this page? As a first pass, maybe something like this: Keep AArch64 family—config/aarch64/constraints.md ARM family—config/arm/constraints.md MIPS—config/mips/constraints.md PowerPC and IBM RS6000—config/rs6000/constraints.md S/390 and zSeries—config/s390/s390.h SPARC—config/sparc/sparc.h x86 family—config/i386/constraints.md Drop ARC —config/arc/constraints.md AVR family—config/avr/constraints.md Blackfin family—config/bfin/constraints.md CR16 Architecture—config/cr16/cr16.h Epiphany—config/epiphany/constraints.md FRV—config/frv/frv.h FT32—config/ft32/constraints.md Hewlett-Packard PA-RISC—config/pa/pa.h Intel IA-64—config/ia64/ia64.h M32C—config/m32c/m32c.c MeP—config/mep/constraints.md MicroBlaze—config/microblaze/constraints.md Motorola 680x0—config/m68k/constraints.md Moxie—config/moxie/constraints.md MSP430–config/msp430/constraints.md NDS32—config/nds32/constraints.md Nios II family—config/nios2/constraints.md PDP-11—config/pdp11/constraints.md RL78—config/rl78/constraints.md RX—config/rx/constraints.md SPU—config/spu/spu.h TI C6X family—config/c6x/constraints.md TILE-Gx—config/tilegx/constraints.md TILEPro—config/tilepro/constraints.md Visium—config/visium/constraints.md Xstormy16—config/stormy16/stormy16.h Xtensa—config/xtensa/constraints.md dw
gcc-7-20160508 is now available
Snapshot gcc-7-20160508 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20160508/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 236012 You'll find: gcc-7-20160508.tar.bz2 Complete GCC MD5=e29d9be7b73d0463eea7d463b2a5f106 SHA1=b53ba1ca5814a864cec8b082567eb0291fd6b16c Diffs from 7-20160501 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 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.
[wwwdocs] PATCH for Re: Change in mirror setup
On Fri, 6 May 2016, NOC wrote: > We have changed our mirror server setup. > > Could you please update the mirror list and replace: > > France, Gravelines: http://mirror0.babylon.network/gcc/ | > ftp://mirror0.babylon.network/gcc/ | > rsync://mirror0.babylon.network/gcc/, thanks to Tim Semeijn > (noc@babylon.network) at Babylon Network. > France, Roubaix: http://mirror1.babylon.network/gcc/ | > ftp://mirror1.babylon.network/gcc/ | > rsync://mirror1.babylon.network/gcc/, thanks to Tim Semeijn > (noc@babylon.network) at Babylon Network. > > -with- > > The Netherlands, Amsterdam: http://nl.mirror.babylon.network/gcc/ | > ftp://nl.mirror.babylon.network/gcc/ | > rsync://nl.mirror.babylon.network/gcc/, thanks to Tim Semeijn > (noc@babylon.network) at Babylon Network. > France, Roubaix: http://fr.mirror.babylon.network/gcc/ | > ftp://fr.mirror.babylon.network/gcc/ | > rsync://fr.mirror.babylon.network/gcc/, thanks to Tim Semeijn > (noc@babylon.network) at Babylon Network. Thanks for the heads up! I believe my patch below, which I applied, implements these changes. Please let me know if I missed (or misunderstood) anything. Gerald Index: mirrors.html === RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v retrieving revision 1.234 diff -u -r1.234 mirrors.html --- mirrors.html28 Feb 2016 20:59:34 - 1.234 +++ mirrors.html8 May 2016 22:51:23 - @@ -20,14 +20,9 @@ France (no snapshots): ftp://ftp.lip6.fr/pub/gcc/";>ftp.lip6.fr, thanks to ftpmaint at lip6.fr France, Brittany: ftp://ftp.irisa.fr/pub/mirrors/gcc.gnu.org/gcc/";>ftp.irisa.fr, thanks to ftpmaint at irisa.fr France, Gravelines: - http://mirror0.babylon.network/gcc/";>http://mirror0.babylon.network/gcc/ | - ftp://mirror0.babylon.network/gcc/";>ftp://mirror0.babylon.network/gcc/ | - rsync://mirror0.babylon.network/gcc/, - thanks to Tim Semeijn (noc@babylon.network) at Babylon Network. -France, Roubaix: - http://mirror1.babylon.network/gcc/";>http://mirror1.babylon.network/gcc/ | - ftp://mirror1.babylon.network/gcc/";>ftp://mirror1.babylon.network/gcc/ | - rsync://mirror1.babylon.network/gcc/, + http://fr.mirror.babylon.network/gcc/";>http://fr.mirror.babylon.network/gcc/ | + ftp://fr.mirror.babylon.network/gcc/";>ftp://fr.mirror.babylon.network/gcc/ | + rsync://fr.mirror.babylon.network/gcc/, thanks to Tim Semeijn (noc@babylon.network) at Babylon Network. France, Versailles: ftp://ftp.uvsq.fr/pub/gcc/";>ftp.uvsq.fr, thanks to ftpmaint at uvsq.fr Germany, Berlin: ftp://ftp.fu-berlin.de/unix/languages/gcc/";>ftp.fu-berlin.de, thanks to ftp at fu-berlin.de @@ -38,6 +33,11 @@ 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://nl.mirror.babylon.network/gcc/";>http://nl.mirror.babylon.network/gcc/ | + ftp://nl.mirror.babylon.network/gcc/";>ftp://nl.mirror.babylon.network/gcc/ | + rsync://nl.mirror.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
Re: Machine constraints list
On Sun, 2016-05-08 at 15:27 -0700, David Wohlferd wrote: > Looking at the v6 release criteria > (https://gcc.gnu.org/gcc-6/criteria.html) there are about a dozen > supported platforms. > > Looking at the Machine Constraints docs > (https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html), there > are > 34 architectures listed. That's a lot of entries to scroll thru. If > these architectures aren't supported anymore, is it time to drop some > of these from this page? It's not that these architectures are not supported anymore. They're just neither primary nor secondary but tertiary platforms instead. On the release criteria page it says: "There are no release criteria for tertiary platforms." BTW, the list of supported architectures is not the "machine constrants" page, but rather this one: https://gcc.gnu.org/backends.html Cheers, Oleg
