I've noticed that my test program is getting run once for each test
-j. So
make -kj8 RUNTESTFLAGS="ms-sysv.exp" check
will result in 8 jobs each running the same tests. (Incidentally, I've
moved my tests from gcc.target/i386/msabi to
gcc.target/x86_64/abi/ms-sysv for taxonomic correctness.)
Snapshot gcc-7-20170420 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/7-20170420/
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/branches/gcc-7
On 20/04/17 12:20 +0100, Jonathan Wakely wrote:
On 20/04/17 11:12 +0100, Jonathan Wakely wrote:
On 20/04/17 12:07 +0200, Jakub Jelinek wrote:
On Thu, Apr 20, 2017 at 11:03:38AM +0100, Jonathan Wakely wrote:
Yet another case where warning suppression in system headers hurts the
library's abilit
On 04/20/2017 10:39 AM, Jonathan Wakely wrote:
>
> Or simply deprecate support for it in std::atomic. **If** the
> extension for built-in types is useful then I can imagine it might be
> useful to have it for std::atomic too, for a subset of the programs
> relying on the original extension. But I'
On 20/04/17 11:12 +0100, Jonathan Wakely wrote:
On 20/04/17 12:07 +0200, Jakub Jelinek wrote:
On Thu, Apr 20, 2017 at 11:03:38AM +0100, Jonathan Wakely wrote:
Yet another case where warning suppression in system headers hurts the
library's ability to give diagnostics. We can't warn about using
Status
==
The trunk has branched for the GCC 7 release and is now open
again for general development, stage 1. Please consider not
disrupting it too much during the RC phase of GCC 7 so it
is possible to test important fixes for 7.1 on it.
Quality Data
Priority # Cha
On 20/04/17 12:07 +0200, Jakub Jelinek wrote:
On Thu, Apr 20, 2017 at 11:03:38AM +0100, Jonathan Wakely wrote:
Yet another case where warning suppression in system headers hurts the
library's ability to give diagnostics. We can't warn about using
incomplete types in std::unique_ptr because the -
On Thu, Apr 20, 2017 at 11:03:38AM +0100, Jonathan Wakely wrote:
> Yet another case where warning suppression in system headers hurts the
> library's ability to give diagnostics. We can't warn about using
> incomplete types in std::unique_ptr because the -Wdelete-incomplete
> warning gets suppresse
On 20/04/17 11:57 +0200, Florian Weimer wrote:
On 04/20/2017 11:52 AM, Jonathan Wakely wrote:
On 20/04/17 11:43 +0200, Florian Weimer wrote:
On 04/20/2017 11:25 AM, Jonathan Wakely wrote:
I mean, with -pedantic-errors we already error on void * arighmetics
or function pointer arithmetics. If
Status
==
We have reached zero P1 regressions today (and < 100 important
regressions) and the branches/gcc-7-branch has been created;
GCC 7.1-rc1 will be built and announced likely tomorrow.
The branch is now frozen for blocking regressions and documentation
fixes only, all changes to the bran
On 04/20/2017 11:52 AM, Jonathan Wakely wrote:
On 20/04/17 11:43 +0200, Florian Weimer wrote:
On 04/20/2017 11:25 AM, Jonathan Wakely wrote:
I mean, with -pedantic-errors we already error on void * arighmetics
or function pointer arithmetics. If std::atomic would use
the void * arithmetics, i
On 20/04/17 11:48 +0200, Florian Weimer wrote:
On 04/20/2017 11:39 AM, Jonathan Wakely wrote:
Or simply deprecate support for it in std::atomic. **If** the
extension for built-in types is useful then I can imagine it might be
useful to have it for std::atomic too, for a subset of the programs
re
On 20/04/17 11:43 +0200, Florian Weimer wrote:
On 04/20/2017 11:25 AM, Jonathan Wakely wrote:
I mean, with -pedantic-errors we already error on void * arighmetics
or function pointer arithmetics. If std::atomic would use
the void * arithmetics, it would also reject it. Or does it use integer
On 04/20/2017 11:39 AM, Jonathan Wakely wrote:
Or simply deprecate support for it in std::atomic. **If** the
extension for built-in types is useful then I can imagine it might be
useful to have it for std::atomic too, for a subset of the programs
relying on the original extension. But I'm unconvi
On 04/20/2017 11:25 AM, Jonathan Wakely wrote:
I mean, with -pedantic-errors we already error on void * arighmetics
or function pointer arithmetics. If std::atomic would use
the void * arithmetics, it would also reject it. Or does it use integer
arithmetics instead?
No, it does it on void*,
On 20/04/17 10:31 +0100, Jonathan Wakely wrote:
On 20/04/17 11:24 +0200, Florian Weimer wrote:
On 04/20/2017 11:22 AM, Jonathan Wakely wrote:
On 20/04/17 10:18 +0100, Jonathan Wakely wrote:
On 20/04/17 08:19 +0200, Florian Weimer wrote:
On 04/19/2017 07:07 PM, Jonathan Wakely wrote:
I know i
On Thu, 20 Apr 2017, Florian Weimer wrote:
On 04/19/2017 07:07 PM, Jonathan Wakely wrote:
I know it's a bit late, but I'd like to propose deprecating the
libstdc++ extension that allows arithmetic on std::atomic.
Currently we make it behave like arithmetic on void*, which is also a
GNU extensio
On 20/04/17 11:24 +0200, Florian Weimer wrote:
On 04/20/2017 11:22 AM, Jonathan Wakely wrote:
On 20/04/17 10:18 +0100, Jonathan Wakely wrote:
On 20/04/17 08:19 +0200, Florian Weimer wrote:
On 04/19/2017 07:07 PM, Jonathan Wakely wrote:
I know it's a bit late, but I'd like to propose deprecati
On Thu, Apr 20, 2017 at 10:25:40AM +0100, Jonathan Wakely wrote:
> In theory maybe.
>
> > I mean, with -pedantic-errors we already error on void * arighmetics
> > or function pointer arithmetics. If std::atomic would use
> > the void * arithmetics, it would also reject it. Or does it use integer
On 20/04/17 10:25 +0100, Jonathan Wakely wrote:
On 20/04/17 11:21 +0200, Jakub Jelinek wrote:
On Thu, Apr 20, 2017 at 10:18:09AM +0100, Jonathan Wakely wrote:
On 20/04/17 08:19 +0200, Florian Weimer wrote:
On 04/19/2017 07:07 PM, Jonathan Wakely wrote:
> I know it's a bit late, but I'd like to
On 20/04/17 11:21 +0200, Jakub Jelinek wrote:
On Thu, Apr 20, 2017 at 10:18:09AM +0100, Jonathan Wakely wrote:
On 20/04/17 08:19 +0200, Florian Weimer wrote:
> On 04/19/2017 07:07 PM, Jonathan Wakely wrote:
> > I know it's a bit late, but I'd like to propose deprecating the
> > libstdc++ extensi
On 04/20/2017 11:22 AM, Jonathan Wakely wrote:
On 20/04/17 10:18 +0100, Jonathan Wakely wrote:
On 20/04/17 08:19 +0200, Florian Weimer wrote:
On 04/19/2017 07:07 PM, Jonathan Wakely wrote:
I know it's a bit late, but I'd like to propose deprecating the
libstdc++ extension that allows arithmeti
On 20/04/17 10:18 +0100, Jonathan Wakely wrote:
On 20/04/17 08:19 +0200, Florian Weimer wrote:
On 04/19/2017 07:07 PM, Jonathan Wakely wrote:
I know it's a bit late, but I'd like to propose deprecating the
libstdc++ extension that allows arithmetic on std::atomic.
Currently we make it behave li
On Thu, Apr 20, 2017 at 10:18:09AM +0100, Jonathan Wakely wrote:
> On 20/04/17 08:19 +0200, Florian Weimer wrote:
> > On 04/19/2017 07:07 PM, Jonathan Wakely wrote:
> > > I know it's a bit late, but I'd like to propose deprecating the
> > > libstdc++ extension that allows arithmetic on std::atomic.
On 20/04/17 08:19 +0200, Florian Weimer wrote:
On 04/19/2017 07:07 PM, Jonathan Wakely wrote:
I know it's a bit late, but I'd like to propose deprecating the
libstdc++ extension that allows arithmetic on std::atomic.
Currently we make it behave like arithmetic on void*, which is also a
GNU exten
25 matches
Mail list logo
