Re: Optimization breaks inline asm code w/ptrs

[Liu Hao]

On 2017/8/14 20:41, Alan Modra wrote:

On Sun, Aug 13, 2017 at 10:25:14PM +0930, Alan Modra wrote:

On Sun, Aug 13, 2017 at 03:35:15AM -0700, David Wohlferd wrote:

Using "m"(*pStr) as an (unused) input parameter has no effect.


Use "m" (*(const void *)pStr) and ignore the warning, or use
"m" (*(const struct {char a; char x[];} *) pStr).


or even better "m" (*(const char (*)[]) pStr).



This should work in the sense that GCC now thinks bytes adjacent to 
`pStr` are subject to modification by the asm statement.


But I just tried GCC 7.2 and it seems that even if such a "+m" 
constraint is the only output parameter of an asm statement and there is 
no `volatile` or the "memory" clobber, GCC optimizer will not optimize 
the asm statement away, which is the case if a plain `"+m"(*pStr)` is used.



The issue is one of letting gcc know what memory is accessed by the
asm, if you don't want to use a "memory" clobber.  And there are very
good reasons to avoid clobbering all memory.

"m"(*pStr) ought to work IMO, but apparently just tells gcc you are
only interested in the first character.  Of course that is exactly
what *pStr is, but in this context it would be nicer if it meant the
entire array.


I take that back.  The relatively simple cast to differentiate a
pointer to a char from a pointer to an indeterminate length char array
makes it quite unnecessary for "m"(*pStr) to be treated as as array
reference.

I've opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81845 to
track the lack of documentation.



Yes. I hope there will be a memory-range constraint in the future.



--
Best regards,
LH_Mouse

Re: Behaviour of __forced_unwind with noexcept

[Richard Biener]

On Tue, Aug 15, 2017 at 6:44 AM, Ron  wrote:
> On Mon, Aug 14, 2017 at 06:22:39PM +0100, Jonathan Wakely wrote:
>> On 13 August 2017 at 19:20, Ron wrote:
>> >
>> > Hi,
>> >
>> > I'm looking for some clarification of how the __forced_unwind thread
>> > cancellation exceptions intersect with noexcept.  I've long been a
>> > big fan of the __forced_unwind idiom, but now that C++14 is the default
>> > since GCC 6.1, and many methods including destructors are implicitly
>> > noexcept, using it safely appears to have become a lot more tricky.
>> >
>> > The closest I've found so far to an "authoritative" statement of the
>> > expected behaviour is the comments from Jonathan Wakely here:
>> >
>> > https://stackoverflow.com/questions/14268080/cancelling-a-thread-that-has-a-mutex-locked-does-not-unlock-the-mutex
>> >
>> > In particular: "It interacts with noexcept as you'd expect:
>> > std::terminate() is called if a __forced_unwind escapes a noexcept
>> > function, so noexcept functions are really noexcept, they won't
>> > unexpectedly throw some 'special' type"
>> >
>> > Which does seem logical, but unless I'm missing something this makes
>> > it unsafe to perform any operation in a destructor which might cross
>> > a cancellation point, unless that destructor is noexcept(false).
>>
>> Unfortunately I still think that's true.
>>
>> This was also raised in https://gcc.gnu.org/ml/gcc-help/2015-08/msg00040.html
>
> Ouch.  Had you considered the option of having any scope that is
> noexcept(true) also be treated as if it was implicitly in a scoped
> pthread_setcancelstate(PTHREAD_CANCEL_DISABLE), restoring the
> old state when it leaves that scope?
>
> Would it be feasible for the compiler to automatically generate that?
>
> For any toolchain which does use the unwinding exceptions extension,
> that also seems like a logical extension to the noexcept behaviour,
> since allowing cancellation will otherwise result in an exception and
> process termination.  If people really need cancellation in such
> scopes, then they can more manageably mark just those noexcept(false).
>
>
> It would need to be done by the compiler, since in user code I can't
> do that in a destructor in a way that will also protect unwinding
> members of a class (which may have destructors in code I don't
> control).
>
> I can't even completely mitigate this by just always using -std=c++03
> because presumably I'm also exposed to (at least) libstdc++.so being
> built with the new compiler default of C++14 or later.
>
>
> I'd be really sad to lose the stack unwinding we currently have when
> a thread is cancelled.  I've always known it was an extension (and I'm
> still a bit surprised it hasn't become part of the official standard),
> but it is fairly portable in practice.
>
> On Linux (or on Debian at least) clang also supports it.  It's also
> supported by gcc on FreeBSD and MacOS (though not by clang there).
> It's supported by mingw for Windows builds.  OpenBSD is currently
> the only platform I know of where even its gcc toolchain doesn't
> support this (but they're also missing support for standard locale
> functionality so it's a special snowflake anyway).
>
>
> It seems that we need to find some way past the status-quo though,
> because "don't ever use pthread_cancel" is the same as saying that
> there's no longer any use for the forced_unwind extension.  Or that
> "you can have a pthread_cancel which leaks resources, or none at all".
>
> Having a pthread_cancel that only works on cancellation points that
> aren't noexcept seems like a reasonable compromise and extension to
> the shortcomings of the standard to me.  Am I missing something there
> which makes that solution not a viable option either?

Have glibc override the abort () from the forced_unwind if in pthread_cancel
context?

I guess sprinkling pthread_setcancelstate () around would be doable
(in some __cxxabi helper) but it might be quite expensive to do so...

Richard.

>
>> > And since that could be something as simple as logging to stdio and
>> > almost impossible to definitely rule out in a future proof way if the
>> > destructor does anything non-trivial (like calling functions in a
>> > system or other 3rd party library) ...  and since the race of catching
>> > a cancellation request in such a destructor could be a relatively rare
>> > one to lose in a lot of code ...  there could be a lot of extant code
>> > with new latent 'crasher' bugs when built with GCC 6.1 or later.
>> >
>> > And/or a lot of people are going to have to go through a lot of code
>> > and mark up a lot of methods with noexcept(false).
>> >
>> >
>> > So I'm half-hoping that I am actually missing something here which
>> > mitigates that - but if not, is this something we need to give a
>> > bit more thought to?
>> >
>> > (Please keep me cc'd, I'm not currently on this list)
>> >
>> >   Cheers,
>> >   Ron

Re: Should --enable-checking=yes,rtl work on 32-bit hosts?

[Richard Biener]

On Mon, Aug 14, 2017 at 5:23 PM, H.J. Lu  wrote:
> For GCC 8, when --enable-checking=yes,rtl is used with x32 GCC,
> I got
>
> cc1plus: out of memory allocating 56137200 bytes after a total of
> 3139436544 bytes
> make[5]: *** [Makefile:1104: insn-extract.o] Error 1
> make[5]: *** Waiting for unfinished jobs
>
> gcc-7-branch is OK.  Is this expected?

I suppose not.  Who allocates all the memory?

Richard.

> --
> H.J.

Re: Behaviour of __forced_unwind with noexcept

[Jonathan Wakely]

On 15 August 2017 at 11:24, Richard Biener  wrote:
> On Tue, Aug 15, 2017 at 6:44 AM, Ron  wrote:
>> On Mon, Aug 14, 2017 at 06:22:39PM +0100, Jonathan Wakely wrote:
>>> On 13 August 2017 at 19:20, Ron wrote:
>>> >
>>> > Hi,
>>> >
>>> > I'm looking for some clarification of how the __forced_unwind thread
>>> > cancellation exceptions intersect with noexcept.  I've long been a
>>> > big fan of the __forced_unwind idiom, but now that C++14 is the default
>>> > since GCC 6.1, and many methods including destructors are implicitly
>>> > noexcept, using it safely appears to have become a lot more tricky.
>>> >
>>> > The closest I've found so far to an "authoritative" statement of the
>>> > expected behaviour is the comments from Jonathan Wakely here:
>>> >
>>> > https://stackoverflow.com/questions/14268080/cancelling-a-thread-that-has-a-mutex-locked-does-not-unlock-the-mutex
>>> >
>>> > In particular: "It interacts with noexcept as you'd expect:
>>> > std::terminate() is called if a __forced_unwind escapes a noexcept
>>> > function, so noexcept functions are really noexcept, they won't
>>> > unexpectedly throw some 'special' type"
>>> >
>>> > Which does seem logical, but unless I'm missing something this makes
>>> > it unsafe to perform any operation in a destructor which might cross
>>> > a cancellation point, unless that destructor is noexcept(false).
>>>
>>> Unfortunately I still think that's true.
>>>
>>> This was also raised in 
>>> https://gcc.gnu.org/ml/gcc-help/2015-08/msg00040.html
>>
>> Ouch.  Had you considered the option of having any scope that is
>> noexcept(true) also be treated as if it was implicitly in a scoped
>> pthread_setcancelstate(PTHREAD_CANCEL_DISABLE), restoring the
>> old state when it leaves that scope?
>>
>> Would it be feasible for the compiler to automatically generate that?
>>
>> For any toolchain which does use the unwinding exceptions extension,
>> that also seems like a logical extension to the noexcept behaviour,
>> since allowing cancellation will otherwise result in an exception and
>> process termination.  If people really need cancellation in such
>> scopes, then they can more manageably mark just those noexcept(false).
>>
>>
>> It would need to be done by the compiler, since in user code I can't
>> do that in a destructor in a way that will also protect unwinding
>> members of a class (which may have destructors in code I don't
>> control).
>>
>> I can't even completely mitigate this by just always using -std=c++03
>> because presumably I'm also exposed to (at least) libstdc++.so being
>> built with the new compiler default of C++14 or later.
>>
>>
>> I'd be really sad to lose the stack unwinding we currently have when
>> a thread is cancelled.  I've always known it was an extension (and I'm
>> still a bit surprised it hasn't become part of the official standard),
>> but it is fairly portable in practice.
>>
>> On Linux (or on Debian at least) clang also supports it.  It's also
>> supported by gcc on FreeBSD and MacOS (though not by clang there).
>> It's supported by mingw for Windows builds.  OpenBSD is currently
>> the only platform I know of where even its gcc toolchain doesn't
>> support this (but they're also missing support for standard locale
>> functionality so it's a special snowflake anyway).
>>
>>
>> It seems that we need to find some way past the status-quo though,
>> because "don't ever use pthread_cancel" is the same as saying that
>> there's no longer any use for the forced_unwind extension.  Or that
>> "you can have a pthread_cancel which leaks resources, or none at all".
>>
>> Having a pthread_cancel that only works on cancellation points that
>> aren't noexcept seems like a reasonable compromise and extension to
>> the shortcomings of the standard to me.  Am I missing something there
>> which makes that solution not a viable option either?
>
> Have glibc override the abort () from the forced_unwind if in pthread_cancel
> context?

If the forced_unwind exception escapes a noexcept function then the
compiler calls std::terminate(). That can be replaced by the user so
that it doesn't call abort(). It must not return, but a user-supplied
terminate handler could trap or raise SIGKILL or something else.

Required behavior: A terminate_handler shall terminate execution of
the program without returning
to the caller.
Default behavior: The implementation’s default terminate_handler calls abort().

I don't think glibc can help, I think the compiler would need to
change to not call std::terminate().

Re: Behaviour of __forced_unwind with noexcept

[Richard Biener]

On Tue, Aug 15, 2017 at 1:28 PM, Jonathan Wakely  wrote:
> On 15 August 2017 at 11:24, Richard Biener  wrote:
>> On Tue, Aug 15, 2017 at 6:44 AM, Ron  wrote:
>>> On Mon, Aug 14, 2017 at 06:22:39PM +0100, Jonathan Wakely wrote:
 On 13 August 2017 at 19:20, Ron wrote:
 >
 > Hi,
 >
 > I'm looking for some clarification of how the __forced_unwind thread
 > cancellation exceptions intersect with noexcept.  I've long been a
 > big fan of the __forced_unwind idiom, but now that C++14 is the default
 > since GCC 6.1, and many methods including destructors are implicitly
 > noexcept, using it safely appears to have become a lot more tricky.
 >
 > The closest I've found so far to an "authoritative" statement of the
 > expected behaviour is the comments from Jonathan Wakely here:
 >
 > https://stackoverflow.com/questions/14268080/cancelling-a-thread-that-has-a-mutex-locked-does-not-unlock-the-mutex
 >
 > In particular: "It interacts with noexcept as you'd expect:
 > std::terminate() is called if a __forced_unwind escapes a noexcept
 > function, so noexcept functions are really noexcept, they won't
 > unexpectedly throw some 'special' type"
 >
 > Which does seem logical, but unless I'm missing something this makes
 > it unsafe to perform any operation in a destructor which might cross
 > a cancellation point, unless that destructor is noexcept(false).

 Unfortunately I still think that's true.

 This was also raised in 
 https://gcc.gnu.org/ml/gcc-help/2015-08/msg00040.html
>>>
>>> Ouch.  Had you considered the option of having any scope that is
>>> noexcept(true) also be treated as if it was implicitly in a scoped
>>> pthread_setcancelstate(PTHREAD_CANCEL_DISABLE), restoring the
>>> old state when it leaves that scope?
>>>
>>> Would it be feasible for the compiler to automatically generate that?
>>>
>>> For any toolchain which does use the unwinding exceptions extension,
>>> that also seems like a logical extension to the noexcept behaviour,
>>> since allowing cancellation will otherwise result in an exception and
>>> process termination.  If people really need cancellation in such
>>> scopes, then they can more manageably mark just those noexcept(false).
>>>
>>>
>>> It would need to be done by the compiler, since in user code I can't
>>> do that in a destructor in a way that will also protect unwinding
>>> members of a class (which may have destructors in code I don't
>>> control).
>>>
>>> I can't even completely mitigate this by just always using -std=c++03
>>> because presumably I'm also exposed to (at least) libstdc++.so being
>>> built with the new compiler default of C++14 or later.
>>>
>>>
>>> I'd be really sad to lose the stack unwinding we currently have when
>>> a thread is cancelled.  I've always known it was an extension (and I'm
>>> still a bit surprised it hasn't become part of the official standard),
>>> but it is fairly portable in practice.
>>>
>>> On Linux (or on Debian at least) clang also supports it.  It's also
>>> supported by gcc on FreeBSD and MacOS (though not by clang there).
>>> It's supported by mingw for Windows builds.  OpenBSD is currently
>>> the only platform I know of where even its gcc toolchain doesn't
>>> support this (but they're also missing support for standard locale
>>> functionality so it's a special snowflake anyway).
>>>
>>>
>>> It seems that we need to find some way past the status-quo though,
>>> because "don't ever use pthread_cancel" is the same as saying that
>>> there's no longer any use for the forced_unwind extension.  Or that
>>> "you can have a pthread_cancel which leaks resources, or none at all".
>>>
>>> Having a pthread_cancel that only works on cancellation points that
>>> aren't noexcept seems like a reasonable compromise and extension to
>>> the shortcomings of the standard to me.  Am I missing something there
>>> which makes that solution not a viable option either?
>>
>> Have glibc override the abort () from the forced_unwind if in pthread_cancel
>> context?
>
> If the forced_unwind exception escapes a noexcept function then the
> compiler calls std::terminate(). That can be replaced by the user so
> that it doesn't call abort(). It must not return, but a user-supplied
> terminate handler could trap or raise SIGKILL or something else.
>
> Required behavior: A terminate_handler shall terminate execution of
> the program without returning
> to the caller.
> Default behavior: The implementation’s default terminate_handler calls 
> abort().
>
> I don't think glibc can help, I think the compiler would need to
> change to not call std::terminate().

Maybe it could call an unwinder provided hook so that forced_unwind can
set it to sth stopping the unwinding and signalling an error rather than
abort()ing.

Richard.

Please support Coroutines TS in C++

[Ramón García]

Hello,

Please consider supporting the Coroutines TS in GNU C++.

It is really important to make asynchronous programming usable.

Modern programs should be scalable to use the performance of multicore
processors. Stackless coroutines allow the programmer to scale to
millions of asynchronous requests. But without the primitives in the
Concurrency TS, chaining the result of an asynchronous computation to
the next step, one must program a chain of callbacks. It becomes
quickly unusable.

The promise/future, as specified in the concurrency TS, (that is, with
the function future::then for chaining a callback to the completion of
the future) make asynchronous programming somewhat more usable.
Unfortunately, almost no C++ library shipped supports future with
then.

This is an excellent explanation of the Coroutines TS:

https://www.slideshare.net/SergeyPlatonov/gor-nishanov-c-coroutines-a-negative-overhead-abstraction

Both Visual C++ 2017 and CLANG (SVN version) support the Coroutines
TS. Please consider it.

I saw that someone started an attempt at implementing it:
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00435.html but there
were no replies.

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

[Jonathan Wakely]

On 15 August 2017 at 04:10, Martin Sebor wrote:
> On 08/14/2017 04:22 PM, Eric Gallager wrote:
>>
>> I'm emailing this manually to the list because Bugzilla is down and I
>> can't file a bug on Bugzilla about Bugzilla being down. The error
>> message looks like this:


Even if it were possible, there wouldn't be any point in filing a bug
that bugzilla's down, and so not much point emailing gcc-bugs either
(since that's for bugzilla mail).  Using gcc@ seems like the right
list to me.

N.B. since the server is being restored from a backup all of
yesterday's changes to bugzilla have been lost, including all Richi's
7.2 release changes, and Eric's housekeeping.

I don't suggest redoing all that work until all services are fully
restored, in case it's lost again.

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

[Szabolcs Nagy]

On 15/08/17 04:10, Martin Sebor wrote:
> On 08/14/2017 04:22 PM, Eric Gallager wrote:
>> I'm emailing this manually to the list because Bugzilla is down and I
>> can't file a bug on Bugzilla about Bugzilla being down. The error
>> message looks like this:
> 
> Bugzilla and the rest of gcc.gnu.org have been down much of
> the afternoon/evening due to a hard drive upgrade (the old disk
> apparently failed).  You're not the only one who found out about
> it the hard way.  I (and I suspect most others) also discovered
> it when things like Git and SVN (and Bugzilla) stopped working.
> 
> I've CC'd the gcc list to let others know (not sure what list
> to subscribe to in order to get a heads up on these kinds of
> maintenance issues).
> 

i seems the database got corrupted.

at least one of my bugs was overwritten by another:

original 81846:
https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01574.html
current 81846:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81846

similarly there are two bugs on the bug mailing list
for 81845 and later bugs are missing.

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

[Martin Sebor]

On 08/15/2017 07:27 AM, Jonathan Wakely wrote:

On 15 August 2017 at 04:10, Martin Sebor wrote:

On 08/14/2017 04:22 PM, Eric Gallager wrote:


I'm emailing this manually to the list because Bugzilla is down and I
can't file a bug on Bugzilla about Bugzilla being down. The error
message looks like this:



Even if it were possible, there wouldn't be any point in filing a bug
that bugzilla's down, and so not much point emailing gcc-bugs either
(since that's for bugzilla mail).  Using gcc@ seems like the right
list to me.

N.B. since the server is being restored from a backup all of
yesterday's changes to bugzilla have been lost, including all Richi's
7.2 release changes, and Eric's housekeeping.

I don't suggest redoing all that work until all services are fully
restored, in case it's lost again.


It looks like the data loss extends beyond 8/14.  Bug 81840
was created Sunday afternoon but is not in the database:

  https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01303.html

(Strangely, 81841 is there, as is 81839.)

Is there a plan to restore the lost data somehow or should
we try to do that ourselves for the bugs we know about?

Martin

Re: Behaviour of __forced_unwind with noexcept

[Ron]

On Tue, Aug 15, 2017 at 01:31:10PM +0200, Richard Biener wrote:
> On Tue, Aug 15, 2017 at 1:28 PM, Jonathan Wakely  
> wrote:
> > On 15 August 2017 at 11:24, Richard Biener  
> > wrote:
> >> On Tue, Aug 15, 2017 at 6:44 AM, Ron  wrote:
> >>> On Mon, Aug 14, 2017 at 06:22:39PM +0100, Jonathan Wakely wrote:
>  On 13 August 2017 at 19:20, Ron wrote:
>  >
>  > Hi,
>  >
>  > I'm looking for some clarification of how the __forced_unwind thread
>  > cancellation exceptions intersect with noexcept.  I've long been a
>  > big fan of the __forced_unwind idiom, but now that C++14 is the default
>  > since GCC 6.1, and many methods including destructors are implicitly
>  > noexcept, using it safely appears to have become a lot more tricky.
>  >
>  > The closest I've found so far to an "authoritative" statement of the
>  > expected behaviour is the comments from Jonathan Wakely here:
>  >
>  > https://stackoverflow.com/questions/14268080/cancelling-a-thread-that-has-a-mutex-locked-does-not-unlock-the-mutex
>  >
>  > In particular: "It interacts with noexcept as you'd expect:
>  > std::terminate() is called if a __forced_unwind escapes a noexcept
>  > function, so noexcept functions are really noexcept, they won't
>  > unexpectedly throw some 'special' type"
>  >
>  > Which does seem logical, but unless I'm missing something this makes
>  > it unsafe to perform any operation in a destructor which might cross
>  > a cancellation point, unless that destructor is noexcept(false).
> 
>  Unfortunately I still think that's true.
> 
>  This was also raised in 
>  https://gcc.gnu.org/ml/gcc-help/2015-08/msg00040.html
> >>>
> >>> Ouch.  Had you considered the option of having any scope that is
> >>> noexcept(true) also be treated as if it was implicitly in a scoped
> >>> pthread_setcancelstate(PTHREAD_CANCEL_DISABLE), restoring the
> >>> old state when it leaves that scope?
> >>>
> >>> Would it be feasible for the compiler to automatically generate that?
> >>>
> >>> For any toolchain which does use the unwinding exceptions extension,
> >>> that also seems like a logical extension to the noexcept behaviour,
> >>> since allowing cancellation will otherwise result in an exception and
> >>> process termination.  If people really need cancellation in such
> >>> scopes, then they can more manageably mark just those noexcept(false).
> >>>
> >>>
> >>> It would need to be done by the compiler, since in user code I can't
> >>> do that in a destructor in a way that will also protect unwinding
> >>> members of a class (which may have destructors in code I don't
> >>> control).
> >>>
> >>> I can't even completely mitigate this by just always using -std=c++03
> >>> because presumably I'm also exposed to (at least) libstdc++.so being
> >>> built with the new compiler default of C++14 or later.
> >>>
> >>>
> >>> I'd be really sad to lose the stack unwinding we currently have when
> >>> a thread is cancelled.  I've always known it was an extension (and I'm
> >>> still a bit surprised it hasn't become part of the official standard),
> >>> but it is fairly portable in practice.
> >>>
> >>> On Linux (or on Debian at least) clang also supports it.  It's also
> >>> supported by gcc on FreeBSD and MacOS (though not by clang there).
> >>> It's supported by mingw for Windows builds.  OpenBSD is currently
> >>> the only platform I know of where even its gcc toolchain doesn't
> >>> support this (but they're also missing support for standard locale
> >>> functionality so it's a special snowflake anyway).
> >>>
> >>>
> >>> It seems that we need to find some way past the status-quo though,
> >>> because "don't ever use pthread_cancel" is the same as saying that
> >>> there's no longer any use for the forced_unwind extension.  Or that
> >>> "you can have a pthread_cancel which leaks resources, or none at all".
> >>>
> >>> Having a pthread_cancel that only works on cancellation points that
> >>> aren't noexcept seems like a reasonable compromise and extension to
> >>> the shortcomings of the standard to me.  Am I missing something there
> >>> which makes that solution not a viable option either?
> >>
> >> Have glibc override the abort () from the forced_unwind if in 
> >> pthread_cancel
> >> context?
> >
> > If the forced_unwind exception escapes a noexcept function then the
> > compiler calls std::terminate(). That can be replaced by the user so
> > that it doesn't call abort(). It must not return, but a user-supplied
> > terminate handler could trap or raise SIGKILL or something else.
> >
> > Required behavior: A terminate_handler shall terminate execution of
> > the program without returning
> > to the caller.
> > Default behavior: The implementation’s default terminate_handler calls 
> > abort().
> >
> > I don't think glibc can help, I think the compiler would need to
> > change to not call std::terminate().
> 
> Maybe it could call an unwinder p

Re: Behaviour of __forced_unwind with noexcept

[Richard Biener]

On Tue, Aug 15, 2017 at 5:21 PM, Ron  wrote:
> On Tue, Aug 15, 2017 at 01:31:10PM +0200, Richard Biener wrote:
>> On Tue, Aug 15, 2017 at 1:28 PM, Jonathan Wakely  
>> wrote:
>> > On 15 August 2017 at 11:24, Richard Biener  
>> > wrote:
>> >> On Tue, Aug 15, 2017 at 6:44 AM, Ron  wrote:
>> >>> On Mon, Aug 14, 2017 at 06:22:39PM +0100, Jonathan Wakely wrote:
>>  On 13 August 2017 at 19:20, Ron wrote:
>>  >
>>  > Hi,
>>  >
>>  > I'm looking for some clarification of how the __forced_unwind thread
>>  > cancellation exceptions intersect with noexcept.  I've long been a
>>  > big fan of the __forced_unwind idiom, but now that C++14 is the 
>>  > default
>>  > since GCC 6.1, and many methods including destructors are implicitly
>>  > noexcept, using it safely appears to have become a lot more tricky.
>>  >
>>  > The closest I've found so far to an "authoritative" statement of the
>>  > expected behaviour is the comments from Jonathan Wakely here:
>>  >
>>  > https://stackoverflow.com/questions/14268080/cancelling-a-thread-that-has-a-mutex-locked-does-not-unlock-the-mutex
>>  >
>>  > In particular: "It interacts with noexcept as you'd expect:
>>  > std::terminate() is called if a __forced_unwind escapes a noexcept
>>  > function, so noexcept functions are really noexcept, they won't
>>  > unexpectedly throw some 'special' type"
>>  >
>>  > Which does seem logical, but unless I'm missing something this makes
>>  > it unsafe to perform any operation in a destructor which might cross
>>  > a cancellation point, unless that destructor is noexcept(false).
>> 
>>  Unfortunately I still think that's true.
>> 
>>  This was also raised in 
>>  https://gcc.gnu.org/ml/gcc-help/2015-08/msg00040.html
>> >>>
>> >>> Ouch.  Had you considered the option of having any scope that is
>> >>> noexcept(true) also be treated as if it was implicitly in a scoped
>> >>> pthread_setcancelstate(PTHREAD_CANCEL_DISABLE), restoring the
>> >>> old state when it leaves that scope?
>> >>>
>> >>> Would it be feasible for the compiler to automatically generate that?
>> >>>
>> >>> For any toolchain which does use the unwinding exceptions extension,
>> >>> that also seems like a logical extension to the noexcept behaviour,
>> >>> since allowing cancellation will otherwise result in an exception and
>> >>> process termination.  If people really need cancellation in such
>> >>> scopes, then they can more manageably mark just those noexcept(false).
>> >>>
>> >>>
>> >>> It would need to be done by the compiler, since in user code I can't
>> >>> do that in a destructor in a way that will also protect unwinding
>> >>> members of a class (which may have destructors in code I don't
>> >>> control).
>> >>>
>> >>> I can't even completely mitigate this by just always using -std=c++03
>> >>> because presumably I'm also exposed to (at least) libstdc++.so being
>> >>> built with the new compiler default of C++14 or later.
>> >>>
>> >>>
>> >>> I'd be really sad to lose the stack unwinding we currently have when
>> >>> a thread is cancelled.  I've always known it was an extension (and I'm
>> >>> still a bit surprised it hasn't become part of the official standard),
>> >>> but it is fairly portable in practice.
>> >>>
>> >>> On Linux (or on Debian at least) clang also supports it.  It's also
>> >>> supported by gcc on FreeBSD and MacOS (though not by clang there).
>> >>> It's supported by mingw for Windows builds.  OpenBSD is currently
>> >>> the only platform I know of where even its gcc toolchain doesn't
>> >>> support this (but they're also missing support for standard locale
>> >>> functionality so it's a special snowflake anyway).
>> >>>
>> >>>
>> >>> It seems that we need to find some way past the status-quo though,
>> >>> because "don't ever use pthread_cancel" is the same as saying that
>> >>> there's no longer any use for the forced_unwind extension.  Or that
>> >>> "you can have a pthread_cancel which leaks resources, or none at all".
>> >>>
>> >>> Having a pthread_cancel that only works on cancellation points that
>> >>> aren't noexcept seems like a reasonable compromise and extension to
>> >>> the shortcomings of the standard to me.  Am I missing something there
>> >>> which makes that solution not a viable option either?
>> >>
>> >> Have glibc override the abort () from the forced_unwind if in 
>> >> pthread_cancel
>> >> context?
>> >
>> > If the forced_unwind exception escapes a noexcept function then the
>> > compiler calls std::terminate(). That can be replaced by the user so
>> > that it doesn't call abort(). It must not return, but a user-supplied
>> > terminate handler could trap or raise SIGKILL or something else.
>> >
>> > Required behavior: A terminate_handler shall terminate execution of
>> > the program without returning
>> > to the caller.
>> > Default behavior: The implementation’s default terminate_handler calls 
>> > abort()

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

[Joseph Myers]

On Tue, 15 Aug 2017, Martin Sebor wrote:

> It looks like the data loss extends beyond 8/14.  Bug 81840
> was created Sunday afternoon but is not in the database:
> 
>   https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01303.html
> 
> (Strangely, 81841 is there, as is 81839.)

That's another 81839 replacing the original 81839.  As I noted on 
overseers, the cut-off for GCC Bugzilla appears to be between 
 and 
, early Sunday 
morning UTC (and for sourceware Bugzilla it may well be similar).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Behaviour of __forced_unwind with noexcept

[Szabolcs Nagy]

On 15/08/17 16:21, Ron wrote:
> On Tue, Aug 15, 2017 at 01:31:10PM +0200, Richard Biener wrote:
>> On Tue, Aug 15, 2017 at 1:28 PM, Jonathan Wakely  
>> wrote:
>>> On 15 August 2017 at 11:24, Richard Biener  
>>> wrote:
 On Tue, Aug 15, 2017 at 6:44 AM, Ron  wrote:
> On Mon, Aug 14, 2017 at 06:22:39PM +0100, Jonathan Wakely wrote:
>> On 13 August 2017 at 19:20, Ron wrote:
>>>
>>> Hi,
>>>
>>> I'm looking for some clarification of how the __forced_unwind thread
>>> cancellation exceptions intersect with noexcept.  I've long been a
>>> big fan of the __forced_unwind idiom, but now that C++14 is the default
>>> since GCC 6.1, and many methods including destructors are implicitly
>>> noexcept, using it safely appears to have become a lot more tricky.
>>>
>>> The closest I've found so far to an "authoritative" statement of the
>>> expected behaviour is the comments from Jonathan Wakely here:
>>>
>>> https://stackoverflow.com/questions/14268080/cancelling-a-thread-that-has-a-mutex-locked-does-not-unlock-the-mutex
>>>
>>> In particular: "It interacts with noexcept as you'd expect:
>>> std::terminate() is called if a __forced_unwind escapes a noexcept
>>> function, so noexcept functions are really noexcept, they won't
>>> unexpectedly throw some 'special' type"
>>>
>>> Which does seem logical, but unless I'm missing something this makes
>>> it unsafe to perform any operation in a destructor which might cross
>>> a cancellation point, unless that destructor is noexcept(false).
>>
>> Unfortunately I still think that's true.
>>
>> This was also raised in 
>> https://gcc.gnu.org/ml/gcc-help/2015-08/msg00040.html
>
> Ouch.  Had you considered the option of having any scope that is
> noexcept(true) also be treated as if it was implicitly in a scoped
> pthread_setcancelstate(PTHREAD_CANCEL_DISABLE), restoring the
> old state when it leaves that scope?
>
> Would it be feasible for the compiler to automatically generate that?
>
> For any toolchain which does use the unwinding exceptions extension,
> that also seems like a logical extension to the noexcept behaviour,
> since allowing cancellation will otherwise result in an exception and
> process termination.  If people really need cancellation in such
> scopes, then they can more manageably mark just those noexcept(false).
>
>
> It would need to be done by the compiler, since in user code I can't
> do that in a destructor in a way that will also protect unwinding
> members of a class (which may have destructors in code I don't
> control).
>
> I can't even completely mitigate this by just always using -std=c++03
> because presumably I'm also exposed to (at least) libstdc++.so being
> built with the new compiler default of C++14 or later.
>
>
> I'd be really sad to lose the stack unwinding we currently have when
> a thread is cancelled.  I've always known it was an extension (and I'm
> still a bit surprised it hasn't become part of the official standard),
> but it is fairly portable in practice.
>
> On Linux (or on Debian at least) clang also supports it.  It's also
> supported by gcc on FreeBSD and MacOS (though not by clang there).
> It's supported by mingw for Windows builds.  OpenBSD is currently
> the only platform I know of where even its gcc toolchain doesn't
> support this (but they're also missing support for standard locale
> functionality so it's a special snowflake anyway).
>
>
> It seems that we need to find some way past the status-quo though,
> because "don't ever use pthread_cancel" is the same as saying that
> there's no longer any use for the forced_unwind extension.  Or that
> "you can have a pthread_cancel which leaks resources, or none at all".
>
> Having a pthread_cancel that only works on cancellation points that
> aren't noexcept seems like a reasonable compromise and extension to
> the shortcomings of the standard to me.  Am I missing something there
> which makes that solution not a viable option either?

 Have glibc override the abort () from the forced_unwind if in 
 pthread_cancel
 context?
>>>
>>> If the forced_unwind exception escapes a noexcept function then the
>>> compiler calls std::terminate(). That can be replaced by the user so
>>> that it doesn't call abort(). It must not return, but a user-supplied
>>> terminate handler could trap or raise SIGKILL or something else.
>>>
>>> Required behavior: A terminate_handler shall terminate execution of
>>> the program without returning
>>> to the caller.
>>> Default behavior: The implementation’s default terminate_handler calls 
>>> abort().
>>>
>>> I don't think glibc can help, I think the compiler would need to
>>> change to not call std::terminate().
>>
>> Maybe it could call 

Re: Behaviour of __forced_unwind with noexcept

[Szabolcs Nagy]

On 15/08/17 16:47, Richard Biener wrote:
> On Tue, Aug 15, 2017 at 5:21 PM, Ron  wrote:
>> Is changing the cancellation state really an expensive operation?
>> Moreso than the checking which I assume already needs to be done for
>> noexcept to trap errant exceptions?
> 
> The noexcept checking only needs to happen if an exception is thrown
> while the pthread cancel state needs to be adjusted whenever we are
> about to enter/exit such function.
> 
>> If it really is, I guess we could also have an attribute which declares
>> a stronger guarantee than noexcept, to claim there are no cancellation
>> points in that scope, if people have something in a hot path where a few
>> cycles really matter to them and this protection is not actually needed.
>> Which could also be an automatic optimisation if the compiler is able to
>> prove there are no cancellation points?
> 
> I guess that's possible.
> 
> I suppose prototyping this would be wrapping all noexcept calls in
> 
>   try { pthread_setcancelstate (PTHREAD_CANCEL_DISABLE, &old); call
> (); } finally { pthread_setcancelstate (old, &old); }
> 

i think changing the state this way is only valid if call
itself does not change the state, which we don't know.

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

[Martin Sebor]

On 08/15/2017 10:27 AM, Joseph Myers wrote:

On Tue, 15 Aug 2017, Martin Sebor wrote:


It looks like the data loss extends beyond 8/14.  Bug 81840
was created Sunday afternoon but is not in the database:

  https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01303.html

(Strangely, 81841 is there, as is 81839.)


That's another 81839 replacing the original 81839.  As I noted on
overseers, the cut-off for GCC Bugzilla appears to be between
 and
, early Sunday
morning UTC (and for sourceware Bugzilla it may well be similar).


Thanks for the update.  Can I subscribe to this list?

(It might be helpful to post an announcement of what's going on
here for those of us who aren't subscribed to the overseers list
or even are aware of its archives.)

Martin

Re: Behaviour of __forced_unwind with noexcept

[Jonathan Wakely]

On 15 August 2017 at 16:21, Ron  wrote:
> On Tue, Aug 15, 2017 at 01:31:10PM +0200, Richard Biener wrote:
>> On Tue, Aug 15, 2017 at 1:28 PM, Jonathan Wakely  
>> wrote:
>> > On 15 August 2017 at 11:24, Richard Biener  
>> > wrote:
>> >> On Tue, Aug 15, 2017 at 6:44 AM, Ron  wrote:
>> >>> On Mon, Aug 14, 2017 at 06:22:39PM +0100, Jonathan Wakely wrote:
>>  On 13 August 2017 at 19:20, Ron wrote:
>>  >
>>  > Hi,
>>  >
>>  > I'm looking for some clarification of how the __forced_unwind thread
>>  > cancellation exceptions intersect with noexcept.  I've long been a
>>  > big fan of the __forced_unwind idiom, but now that C++14 is the 
>>  > default
>>  > since GCC 6.1, and many methods including destructors are implicitly
>>  > noexcept, using it safely appears to have become a lot more tricky.
>>  >
>>  > The closest I've found so far to an "authoritative" statement of the
>>  > expected behaviour is the comments from Jonathan Wakely here:
>>  >
>>  > https://stackoverflow.com/questions/14268080/cancelling-a-thread-that-has-a-mutex-locked-does-not-unlock-the-mutex
>>  >
>>  > In particular: "It interacts with noexcept as you'd expect:
>>  > std::terminate() is called if a __forced_unwind escapes a noexcept
>>  > function, so noexcept functions are really noexcept, they won't
>>  > unexpectedly throw some 'special' type"
>>  >
>>  > Which does seem logical, but unless I'm missing something this makes
>>  > it unsafe to perform any operation in a destructor which might cross
>>  > a cancellation point, unless that destructor is noexcept(false).
>> 
>>  Unfortunately I still think that's true.
>> 
>>  This was also raised in 
>>  https://gcc.gnu.org/ml/gcc-help/2015-08/msg00040.html
>> >>>
>> >>> Ouch.  Had you considered the option of having any scope that is
>> >>> noexcept(true) also be treated as if it was implicitly in a scoped
>> >>> pthread_setcancelstate(PTHREAD_CANCEL_DISABLE), restoring the
>> >>> old state when it leaves that scope?
>> >>>
>> >>> Would it be feasible for the compiler to automatically generate that?
>> >>>
>> >>> For any toolchain which does use the unwinding exceptions extension,
>> >>> that also seems like a logical extension to the noexcept behaviour,
>> >>> since allowing cancellation will otherwise result in an exception and
>> >>> process termination.  If people really need cancellation in such
>> >>> scopes, then they can more manageably mark just those noexcept(false).
>> >>>
>> >>>
>> >>> It would need to be done by the compiler, since in user code I can't
>> >>> do that in a destructor in a way that will also protect unwinding
>> >>> members of a class (which may have destructors in code I don't
>> >>> control).
>> >>>
>> >>> I can't even completely mitigate this by just always using -std=c++03
>> >>> because presumably I'm also exposed to (at least) libstdc++.so being
>> >>> built with the new compiler default of C++14 or later.
>> >>>
>> >>>
>> >>> I'd be really sad to lose the stack unwinding we currently have when
>> >>> a thread is cancelled.  I've always known it was an extension (and I'm
>> >>> still a bit surprised it hasn't become part of the official standard),
>> >>> but it is fairly portable in practice.
>> >>>
>> >>> On Linux (or on Debian at least) clang also supports it.  It's also
>> >>> supported by gcc on FreeBSD and MacOS (though not by clang there).
>> >>> It's supported by mingw for Windows builds.  OpenBSD is currently
>> >>> the only platform I know of where even its gcc toolchain doesn't
>> >>> support this (but they're also missing support for standard locale
>> >>> functionality so it's a special snowflake anyway).
>> >>>
>> >>>
>> >>> It seems that we need to find some way past the status-quo though,
>> >>> because "don't ever use pthread_cancel" is the same as saying that
>> >>> there's no longer any use for the forced_unwind extension.  Or that
>> >>> "you can have a pthread_cancel which leaks resources, or none at all".
>> >>>
>> >>> Having a pthread_cancel that only works on cancellation points that
>> >>> aren't noexcept seems like a reasonable compromise and extension to
>> >>> the shortcomings of the standard to me.  Am I missing something there
>> >>> which makes that solution not a viable option either?
>> >>
>> >> Have glibc override the abort () from the forced_unwind if in 
>> >> pthread_cancel
>> >> context?
>> >
>> > If the forced_unwind exception escapes a noexcept function then the
>> > compiler calls std::terminate(). That can be replaced by the user so
>> > that it doesn't call abort(). It must not return, but a user-supplied
>> > terminate handler could trap or raise SIGKILL or something else.
>> >
>> > Required behavior: A terminate_handler shall terminate execution of
>> > the program without returning
>> > to the caller.
>> > Default behavior: The implementation’s default terminate_handler calls 
>> > abort().
>> 

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

[Joseph Myers]

On Tue, 15 Aug 2017, Martin Sebor wrote:

> On 08/15/2017 10:27 AM, Joseph Myers wrote:
> > On Tue, 15 Aug 2017, Martin Sebor wrote:
> > 
> > > It looks like the data loss extends beyond 8/14.  Bug 81840
> > > was created Sunday afternoon but is not in the database:
> > > 
> > >   https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01303.html
> > > 
> > > (Strangely, 81841 is there, as is 81839.)
> > 
> > That's another 81839 replacing the original 81839.  As I noted on
> > overseers, the cut-off for GCC Bugzilla appears to be between
> >  and
> > , early Sunday
> > morning UTC (and for sourceware Bugzilla it may well be similar).
> 
> Thanks for the update.  Can I subscribe to this list?

I believe it's open subscription.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Behaviour of __forced_unwind with noexcept

[Jonathan Wakely]

On 15 August 2017 at 17:39, Jonathan Wakely wrote:
> Also currently std::thread runs the supplied function object inside a
> noexcept function. With your proposal cancellation would be blocked in
> any thread created by a std::thread, i.e. you could only cancel in the
> main() thread, or threads created by pthread_create.

Sorry, that was incorrect. I misremembered what the std::thread code does.

Re: Behaviour of __forced_unwind with noexcept

[Ron]

On Tue, Aug 15, 2017 at 05:39:10PM +0100, Jonathan Wakely wrote:
> On 15 August 2017 at 16:21, Ron  wrote:
> > On Tue, Aug 15, 2017 at 01:31:10PM +0200, Richard Biener wrote:
> >> On Tue, Aug 15, 2017 at 1:28 PM, Jonathan Wakely  
> >> wrote:
> >> > On 15 August 2017 at 11:24, Richard Biener  
> >> > wrote:
> >> >> On Tue, Aug 15, 2017 at 6:44 AM, Ron  wrote:
> >> >>> On Mon, Aug 14, 2017 at 06:22:39PM +0100, Jonathan Wakely wrote:
> >>  On 13 August 2017 at 19:20, Ron wrote:
> >>  >
> >>  > Hi,
> >>  >
> >>  > I'm looking for some clarification of how the __forced_unwind thread
> >>  > cancellation exceptions intersect with noexcept.  I've long been a
> >>  > big fan of the __forced_unwind idiom, but now that C++14 is the 
> >>  > default
> >>  > since GCC 6.1, and many methods including destructors are implicitly
> >>  > noexcept, using it safely appears to have become a lot more tricky.
> >>  >
> >>  > The closest I've found so far to an "authoritative" statement of the
> >>  > expected behaviour is the comments from Jonathan Wakely here:
> >>  >
> >>  > https://stackoverflow.com/questions/14268080/cancelling-a-thread-that-has-a-mutex-locked-does-not-unlock-the-mutex
> >>  >
> >>  > In particular: "It interacts with noexcept as you'd expect:
> >>  > std::terminate() is called if a __forced_unwind escapes a noexcept
> >>  > function, so noexcept functions are really noexcept, they won't
> >>  > unexpectedly throw some 'special' type"
> >>  >
> >>  > Which does seem logical, but unless I'm missing something this makes
> >>  > it unsafe to perform any operation in a destructor which might cross
> >>  > a cancellation point, unless that destructor is noexcept(false).
> >> 
> >>  Unfortunately I still think that's true.
> >> 
> >>  This was also raised in 
> >>  https://gcc.gnu.org/ml/gcc-help/2015-08/msg00040.html
> >> >>>
> >> >>> Ouch.  Had you considered the option of having any scope that is
> >> >>> noexcept(true) also be treated as if it was implicitly in a scoped
> >> >>> pthread_setcancelstate(PTHREAD_CANCEL_DISABLE), restoring the
> >> >>> old state when it leaves that scope?
> >> >>>
> >> >>> Would it be feasible for the compiler to automatically generate that?
> >> >>>
> >> >>> For any toolchain which does use the unwinding exceptions extension,
> >> >>> that also seems like a logical extension to the noexcept behaviour,
> >> >>> since allowing cancellation will otherwise result in an exception and
> >> >>> process termination.  If people really need cancellation in such
> >> >>> scopes, then they can more manageably mark just those noexcept(false).
> >> >>>
> >> >>>
> >> >>> It would need to be done by the compiler, since in user code I can't
> >> >>> do that in a destructor in a way that will also protect unwinding
> >> >>> members of a class (which may have destructors in code I don't
> >> >>> control).
> >> >>>
> >> >>> I can't even completely mitigate this by just always using -std=c++03
> >> >>> because presumably I'm also exposed to (at least) libstdc++.so being
> >> >>> built with the new compiler default of C++14 or later.
> >> >>>
> >> >>>
> >> >>> I'd be really sad to lose the stack unwinding we currently have when
> >> >>> a thread is cancelled.  I've always known it was an extension (and I'm
> >> >>> still a bit surprised it hasn't become part of the official standard),
> >> >>> but it is fairly portable in practice.
> >> >>>
> >> >>> On Linux (or on Debian at least) clang also supports it.  It's also
> >> >>> supported by gcc on FreeBSD and MacOS (though not by clang there).
> >> >>> It's supported by mingw for Windows builds.  OpenBSD is currently
> >> >>> the only platform I know of where even its gcc toolchain doesn't
> >> >>> support this (but they're also missing support for standard locale
> >> >>> functionality so it's a special snowflake anyway).
> >> >>>
> >> >>>
> >> >>> It seems that we need to find some way past the status-quo though,
> >> >>> because "don't ever use pthread_cancel" is the same as saying that
> >> >>> there's no longer any use for the forced_unwind extension.  Or that
> >> >>> "you can have a pthread_cancel which leaks resources, or none at all".
> >> >>>
> >> >>> Having a pthread_cancel that only works on cancellation points that
> >> >>> aren't noexcept seems like a reasonable compromise and extension to
> >> >>> the shortcomings of the standard to me.  Am I missing something there
> >> >>> which makes that solution not a viable option either?
> >> >>
> >> >> Have glibc override the abort () from the forced_unwind if in 
> >> >> pthread_cancel
> >> >> context?
> >> >
> >> > If the forced_unwind exception escapes a noexcept function then the
> >> > compiler calls std::terminate(). That can be replaced by the user so
> >> > that it doesn't call abort(). It must not return, but a user-supplied
> >> > terminate handler could trap or raise SIG

Re: Behaviour of __forced_unwind with noexcept

[Ron]

On Tue, Aug 15, 2017 at 05:37:21PM +0100, Szabolcs Nagy wrote:
> On 15/08/17 16:47, Richard Biener wrote:
> > On Tue, Aug 15, 2017 at 5:21 PM, Ron  wrote:
> >> Is changing the cancellation state really an expensive operation?
> >> Moreso than the checking which I assume already needs to be done for
> >> noexcept to trap errant exceptions?
> > 
> > The noexcept checking only needs to happen if an exception is thrown
> > while the pthread cancel state needs to be adjusted whenever we are
> > about to enter/exit such function.
> > 
> >> If it really is, I guess we could also have an attribute which declares
> >> a stronger guarantee than noexcept, to claim there are no cancellation
> >> points in that scope, if people have something in a hot path where a few
> >> cycles really matter to them and this protection is not actually needed.
> >> Which could also be an automatic optimisation if the compiler is able to
> >> prove there are no cancellation points?
> > 
> > I guess that's possible.
> > 
> > I suppose prototyping this would be wrapping all noexcept calls in
> > 
> >   try { pthread_setcancelstate (PTHREAD_CANCEL_DISABLE, &old); call
> > (); } finally { pthread_setcancelstate (old, &old); }
> > 
> 
> i think changing the state this way is only valid if call
> itself does not change the state, which we don't know.

That's a fair statement, but we're only talking about doing this in
functions which are declared noexcept.

It already requires the person writing that code to ensure that
no exceptions are thrown (else the process will terminate), and
this extension would additionally require them to ensure that no
cancellation points become active (which is already required now
anyway since that's already directly equivalent to throwing an
exception as things are now).

The only difference is the compiler can do it safely, where trying
to write that explicitly in user code will still leave gaps where
an unwind exception could leak out.

[sparc64] kernel OOPS with gcc 7.1 / 7.2

[Anatoly Pugachev]

Hello.

Together with Dmitry (ldv) , we've discovered that running test suite
from strace produces kernel OOPS, when kernel is compiled with gcc 7.1
or with gcc 7.2 , but not with gcc 6 :

$ git clone https://github.com/strace/strace.git
ttip:~/strace$ ./bootstrap
ttip:~/strace$ ./configure && make -j
ttip:~/strace$ cd tests-m32 && make mq
ttip:~/strace/tests-m32$ ./mq
Killed

kernel log:

[   61.839563] Unable to handle kernel NULL pointer dereference
[   61.839649] tsk->{mm,active_mm}->context = 040e
[   61.839686] tsk->{mm,active_mm}->pgd = fff8004099e06000
[   61.839721]   \|/  \|/
[   61.839721]   "@'/ .. \`@"
[   61.839721]   /_| \__/ |_\
[   61.839721]  \__U_/
[   61.839879] mq(937): Oops [#1]
[   61.839909] CPU: 10 PID: 937 Comm: mq Not tainted
4.13.0-rc5-9-gfcd07350007b #412
[   61.839958] task: fff80040968ed940 task.stack: fff800409c26c000
[   61.839997] TSTATE: 004411001600 TPC: 0069fb2c TNPC:
0069fb30 Y: 02f7Not tainted
[   61.840062] TPC: 
[   61.840091] g0: fff8004096588400 g1: 000143c0 g2:
000a g3: 
[   61.840143] g4:  g5:  g6:
fff800409c26c000 g7: 000a
[   61.840196] o0:  o1: 00014000 o2:
 o3: 000a
[   61.840247] o4: 0001 o5:  sp:
fff800409c26f3e1 ret_pc: 007072d0
[   61.840308] RPC: 
[   61.840341] l0: 00da l1: f7c87bf0 l2:
f7c34000 l3: 
[   61.840395] l4: f7c86100 l5:  l6:
00017c96f087 l7: f7c86000
[   61.840450] i0:  i1: 00c4e924 i2:
fff800409c26fd58 i3: fff800409c26fd60
[   61.840504] i4: 00014000 i5: 0014 i6:
fff800409c26f491 i7: 007074fc
[   61.840560] I7: 
[   61.840590] Call Trace:
[   61.840614]  [007074fc] do_mq_open+0x1bc/0x320
[   61.840652]  [0070839c] compat_SyS_mq_open+0x5c/0xa0
[   61.840694]  [004061d4] linux_sparc_syscall32+0x34/0x60
[   61.840734] Disabling lock debugging due to kernel taint
[   61.840756] Caller[007074fc]: do_mq_open+0x1bc/0x320
[   61.840778] Caller[0070839c]: compat_SyS_mq_open+0x5c/0xa0
[   61.840800] Caller[004061d4]: linux_sparc_syscall32+0x34/0x60
[   61.840824] Caller[f7c3c7fc]: 0xf7c3c7fc
[   61.840842] Instruction DUMP:
[   61.840846]  9de3bf50
[   61.840860]  0100
[   61.840872]  0100
[   61.840885] 
[   61.840897]  81cfe008
[   61.840910]  d0406068
[   61.840922]  0100
[   61.840935]  0100
[   61.840947]  9de3bf30
[   61.840960]

And if kernel is compiled with gcc 6 , test ends in other way:

ttip:~$ cd strace/tests-m32/ && ./mq
mq_open("strace-mq-910.sample", O_RDONLY|O_CREAT, 0700, NULL) = 0
mq_getsetattr(0, NULL, {mq_flags=0, mq_maxmsg=10, mq_msgsize=8192,
mq_curmsgs=0}) = 0
mq_getsetattr(0, {mq_flags=0, mq_maxmsg=10, mq_msgsize=8192,
mq_curmsgs=0}, NULL) = 0
mq_unlink("strace-mq-910.sample") = 0
+++ exited with 0 +++

and nothing is printed in kernel logs.

versions of used gcc and kernels:

gcc 6 compiled kernel is git 4.13.0-rc5
gcc 7.2 compiled kernel is git 4.13.0-rc5-9-gfcd07350007b

$ gcc-6 -v
Using built-in specs.
COLLECT_GCC=gcc-6
COLLECT_LTO_WRAPPER=/usr/lib/gcc/sparc64-linux-gnu/6/lto-wrapper
Target: sparc64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
6.4.0-3' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++
--prefix=/usr --program-suffix=-6 --program-prefix=sparc64-linux-gnu-
--enable-shared --enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --libdir=/usr/lib
--enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-libquadmath --enable-plugin --enable-default-pie
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-sparc64/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-sparc64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-sparc64
--with-arch-directory=sparc64
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc=auto
--enable-multiarch --enable-targets=all --with-cpu-32=ultrasparc
--with-long-double-128 --enable-multilib --enable-checking=release
--build=sparc64-linux-gnu --host=sparc64-linux-gnu
--target=sparc64-linux-gnu
Thread model: posix
gcc version 6.4.0 20170805 (Debian 6.4.0-3)

$ gcc-7 -v
Using built-in specs.
COLLECT_GCC=gcc-7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/sparc64-linux-gnu/7/lto-wrapper
Target: sparc64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
7.1.0-13' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,d,fo

Re: [sparc64] kernel OOPS with gcc 7.1 / 7.2

[Sam Ravnborg]

Hi Anatoly.

On Tue, Aug 15, 2017 at 09:50:45PM +0300, Anatoly Pugachev wrote:
> Hello.
> 
> Together with Dmitry (ldv) , we've discovered that running test suite
> from strace produces kernel OOPS, when kernel is compiled with gcc 7.1
> or with gcc 7.2 , but not with gcc 6 :

First, could you please verify if you have following fix in your kernel.
This fixed a similar oops when runnign strace test suite.
And was only seen on ultrasparc-III

Sam



commit 0ede1c401332173ab0693121dc6cde04a4dbf131
Author: David S. Miller 
Date:   Fri Aug 4 09:47:52 2017 -0700

sparc64: Fix exception handling in UltraSPARC-III memcpy.

Mikael Pettersson reported that some test programs in the strace-4.18
testsuite cause an OOPS.

After some debugging it turns out that garbage values are returned
when an exception occurs, causing the fixup memset() to be run with
bogus arguments.

The problem is that two of the exception handler stubs write the
successfully copied length into the wrong register.

Fixes: ee841d0aff64 ("sparc64: Convert U3copy_{from,to}_user to accurate 
exception reporting.")
Reported-by: Mikael Pettersson 
Tested-by: Mikael Pettersson 
Reviewed-by: Sam Ravnborg 
Signed-off-by: David S. Miller 

Re: [sparc64] kernel OOPS with gcc 7.1 / 7.2

[Anatoly Pugachev]

On Tue, Aug 15, 2017 at 11:08 PM, Sam Ravnborg  wrote:
> Hi Anatoly.
>
> On Tue, Aug 15, 2017 at 09:50:45PM +0300, Anatoly Pugachev wrote:
>> Hello.
>>
>> Together with Dmitry (ldv) , we've discovered that running test suite
>> from strace produces kernel OOPS, when kernel is compiled with gcc 7.1
>> or with gcc 7.2 , but not with gcc 6 :
>
> First, could you please verify if you have following fix in your kernel.
> This fixed a similar oops when runnign strace test suite.
> And was only seen on ultrasparc-III
>
> Sam
>
>
>
> commit 0ede1c401332173ab0693121dc6cde04a4dbf131
> Author: David S. Miller 
> Date:   Fri Aug 4 09:47:52 2017 -0700
>
> sparc64: Fix exception handling in UltraSPARC-III memcpy.

Sam,

it is in the git tree I'm using to compile kernel :
$ git show -s --oneline 0ede1c401332173ab0693121dc6cde04a4dbf131
0ede1c401332 sparc64: Fix exception handling in UltraSPARC-III memcpy.

gcc-5-20170815 is now available

[gccadmin]

Snapshot gcc-5-20170815 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/5-20170815/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch 
revision 251107

You'll find:

 gcc-5-20170815.tar.xzComplete GCC

  SHA256=3a0a2cf3837b346723c537af186a12fe236ca425f9249d1c198a4f7b45b13bdf
  SHA1=cfaa16f91723c56e049f42939ed14c52865d449e

Diffs from 5-20170808 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-5
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.

Re: Should --enable-checking=yes,rtl work on 32-bit hosts?

[Daniel Santos]

On 08/15/2017 06:18 AM, Richard Biener wrote:
> On Mon, Aug 14, 2017 at 5:23 PM, H.J. Lu  wrote:
>> For GCC 8, when --enable-checking=yes,rtl is used with x32 GCC,
>> I got
>>
>> cc1plus: out of memory allocating 56137200 bytes after a total of
>> 3139436544 bytes
>> make[5]: *** [Makefile:1104: insn-extract.o] Error 1
>> make[5]: *** Waiting for unfinished jobs
>>
>> gcc-7-branch is OK.  Is this expected?
> I suppose not.  Who allocates all the memory?
>
> Richard.

Well I didn't dig into it too deeply, but below is a backtrace just
prior to the error.  I'm not at all intimate with gcc's memory
management, if gcc keeps track of how much each component has allocated.

(gdb) bt
#0  __GI___libc_malloc (bytes=56137200) at malloc.c:2905
#1  0x025bc8dc in xmalloc (size=56137200) at 
/home/daniel/proj/sys/gcc/head/libiberty/xmalloc.c:147
#2  0x0124ffa7 in (anonymous namespace)::pass_cprop_hardreg::execute 
(this=0x32b8e50, fun=0xd359d270) at 
/home/daniel/proj/sys/gcc/head/gcc/regcprop.c:1272
#3  0x011c9f23 in execute_one_pass (pass=) at /home/daniel/proj/sys/gcc/head/gcc/passes.c:2495
#4  0x011ca2ac in execute_pass_list_1 (pass=) at /home/daniel/proj/sys/gcc/head/gcc/passes.c:2584
#5  0x011ca2de in execute_pass_list_1 (pass=) at /home/daniel/proj/sys/gcc/head/gcc/passes.c:2585
#6  0x011ca2de in execute_pass_list_1 (pass=) at /home/daniel/proj/sys/gcc/head/gcc/passes.c:2585
#7  0x011ca340 in execute_pass_list (fn=0xd359d270, pass=) at /home/daniel/proj/sys/gcc/head/gcc/passes.c:2595
#8  0x00cb317b in cgraph_node::expand (this=) at /home/daniel/proj/sys/gcc/head/gcc/cgraphunit.c:2054 #9  
0x00cb384b in expand_all_functions () at 
/home/daniel/proj/sys/gcc/head/gcc/cgraphunit.c:2190
#10 0x00cb4469 in symbol_table::compile (this=0xf64f60d8) at 
/home/daniel/proj/sys/gcc/head/gcc/cgraphunit.c:2542
#11 0x00cb46d4 in symbol_table::finalize_compilation_unit (this=0xf64f60d8) at 
/home/daniel/proj/sys/gcc/head/gcc/cgraphunit.c:2631
#12 0x013c7412 in compile_file () at 
/home/daniel/proj/sys/gcc/head/gcc/toplev.c:496
#13 0x013c9c51 in do_compile () at 
/home/daniel/proj/sys/gcc/head/gcc/toplev.c:2037
#14 0x013c9f76 in toplev::main (this=0xcb20, argc=77, argv=0xcc14) at 
/home/daniel/proj/sys/gcc/head/gcc/toplev.c:2171
#15 0x024fd468 in main (argc=77, argv=0xcc14) at 
/home/daniel/proj/sys/gcc/head/gcc/main.c:39


Thanks,
Daniel

Re: [sparc64] kernel OOPS with gcc 7.1 / 7.2

[Anthony Yznaga]

> On Aug 15, 2017, at 11:50 AM, Anatoly Pugachev  wrote:
> 
> Hello.
> 
> Together with Dmitry (ldv) , we've discovered that running test suite
> from strace produces kernel OOPS, when kernel is compiled with gcc 7.1
> or with gcc 7.2 , but not with gcc 6 :
> 
> $ git clone https://github.com/strace/strace.git
> ttip:~/strace$ ./bootstrap
> ttip:~/strace$ ./configure && make -j
> ttip:~/strace$ cd tests-m32 && make mq
> ttip:~/strace/tests-m32$ ./mq
> Killed
> 
> kernel log:
> 
> [   61.839563] Unable to handle kernel NULL pointer dereference
> [   61.839649] tsk->{mm,active_mm}->context = 040e
> [   61.839686] tsk->{mm,active_mm}->pgd = fff8004099e06000
> [   61.839721]   \|/  \|/
> [   61.839721]   "@'/ .. \`@"
> [   61.839721]   /_| \__/ |_\
> [   61.839721]  \__U_/
> [   61.839879] mq(937): Oops [#1]
> [   61.839909] CPU: 10 PID: 937 Comm: mq Not tainted
> 4.13.0-rc5-9-gfcd07350007b #412
> [   61.839958] task: fff80040968ed940 task.stack: fff800409c26c000
> [   61.839997] TSTATE: 004411001600 TPC: 0069fb2c TNPC:
> 0069fb30 Y: 02f7Not tainted
> [   61.840062] TPC: 
> [   61.840091] g0: fff8004096588400 g1: 000143c0 g2:
> 000a g3: 
> [   61.840143] g4:  g5:  g6:
> fff800409c26c000 g7: 000a
> [   61.840196] o0:  o1: 00014000 o2:
>  o3: 000a
> [   61.840247] o4: 0001 o5:  sp:
> fff800409c26f3e1 ret_pc: 007072d0
> [   61.840308] RPC: 
> [   61.840341] l0: 00da l1: f7c87bf0 l2:
> f7c34000 l3: 
> [   61.840395] l4: f7c86100 l5:  l6:
> 00017c96f087 l7: f7c86000
> [   61.840450] i0:  i1: 00c4e924 i2:
> fff800409c26fd58 i3: fff800409c26fd60
> [   61.840504] i4: 00014000 i5: 0014 i6:
> fff800409c26f491 i7: 007074fc
> [   61.840560] I7: 
> [   61.840590] Call Trace:
> [   61.840614]  [007074fc] do_mq_open+0x1bc/0x320
> [   61.840652]  [0070839c] compat_SyS_mq_open+0x5c/0xa0
> [   61.840694]  [004061d4] linux_sparc_syscall32+0x34/0x60
> [   61.840734] Disabling lock debugging due to kernel taint
> [   61.840756] Caller[007074fc]: do_mq_open+0x1bc/0x320
> [   61.840778] Caller[0070839c]: compat_SyS_mq_open+0x5c/0xa0
> [   61.840800] Caller[004061d4]: linux_sparc_syscall32+0x34/0x60
> [   61.840824] Caller[f7c3c7fc]: 0xf7c3c7fc
> [   61.840842] Instruction DUMP:
> [   61.840846]  9de3bf50
> [   61.840860]  0100
> [   61.840872]  0100
> [   61.840885] 
> [   61.840897]  81cfe008
> [   61.840910]  d0406068
> [   61.840922]  0100
> [   61.840935]  0100
> [   61.840947]  9de3bf30
> [   61.840960]

The panic happens in current_umask() on this instruction which
fetches current->fs:

ldx   [%g4 + 0x720], %g1

%g4 is expected to be the current task pointer, but from the log
messages above, %g4 and %g5 are 0.  %g4 and %g5 are set to the current
task pointer and the current CPU base pointer respectively in etrap and
expected to be preserved while executing in the kernel.

I compiled a kernel with gcc 7 and found that the compiler inserted a
call to __multi3() in mq_attr_ok().  The sparc64 implementation of
__multi3() was added by 1b4af13ff2cc specifically for gcc 7 and later,
but it clobbers %g4 and %g5.  Not sure if that was intended but it
looks like __multi3() is not safe to call from kernel code.

Anthony

> 
> And if kernel is compiled with gcc 6 , test ends in other way:
> 
> ttip:~$ cd strace/tests-m32/ && ./mq
> mq_open("strace-mq-910.sample", O_RDONLY|O_CREAT, 0700, NULL) = 0
> mq_getsetattr(0, NULL, {mq_flags=0, mq_maxmsg=10, mq_msgsize=8192,
> mq_curmsgs=0}) = 0
> mq_getsetattr(0, {mq_flags=0, mq_maxmsg=10, mq_msgsize=8192,
> mq_curmsgs=0}, NULL) = 0
> mq_unlink("strace-mq-910.sample") = 0
> +++ exited with 0 +++
> 
> and nothing is printed in kernel logs.
> 
> versions of used gcc and kernels:
> 
> gcc 6 compiled kernel is git 4.13.0-rc5
> gcc 7.2 compiled kernel is git 4.13.0-rc5-9-gfcd07350007b
> 
> $ gcc-6 -v
> Using built-in specs.
> COLLECT_GCC=gcc-6
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/sparc64-linux-gnu/6/lto-wrapper
> Target: sparc64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Debian
> 6.4.0-3' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
> --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++
> --prefix=/usr --program-suffix=-6 --program-prefix=sparc64-linux-gnu-
> --enable-shared --enable-linker-build-id --libexecdir=/usr/lib
> --without-included-gettext --enable-threads=posix --libdir=/usr/lib
> --enable-nls --with-sysroot=/ --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object
> --disable-libquadmath --ena

Re: [sparc64] kernel OOPS with gcc 7.1 / 7.2

[David Miller]

From: Anthony Yznaga 
Date: Tue, 15 Aug 2017 17:45:12 -0700

> I compiled a kernel with gcc 7 and found that the compiler inserted a
> call to __multi3() in mq_attr_ok().  The sparc64 implementation of
> __multi3() was added by 1b4af13ff2cc specifically for gcc 7 and later,
> but it clobbers %g4 and %g5.  Not sure if that was intended but it
> looks like __multi3() is not safe to call from kernel code.

Good catch, we have to redo the register allocation in that routine
to fix this.

Re: [sparc64] kernel OOPS with gcc 7.1 / 7.2

[David Miller]

From: Anatoly Pugachev 
Date: Tue, 15 Aug 2017 21:50:45 +0300

> Together with Dmitry (ldv) , we've discovered that running test suite
> from strace produces kernel OOPS, when kernel is compiled with gcc 7.1
> or with gcc 7.2 , but not with gcc 6 :

Please try this patch:

diff --git a/arch/sparc/lib/multi3.S b/arch/sparc/lib/multi3.S
index d6b6c97..703127a 100644
--- a/arch/sparc/lib/multi3.S
+++ b/arch/sparc/lib/multi3.S
@@ -5,26 +5,26 @@
.align  4
 ENTRY(__multi3) /* %o0 = u, %o1 = v */
mov %o1, %g1
-   srl %o3, 0, %g4
-   mulx%g4, %g1, %o1
+   srl %o3, 0, %o4
+   mulx%o4, %g1, %o1
srlx%g1, 0x20, %g3
-   mulx%g3, %g4, %g5
-   sllx%g5, 0x20, %o5
-   srl %g1, 0, %g4
+   mulx%g3, %o4, %g7
+   sllx%g7, 0x20, %o5
+   srl %g1, 0, %o4
sub %o1, %o5, %o5
srlx%o5, 0x20, %o5
-   addcc   %g5, %o5, %g5
+   addcc   %g7, %o5, %g7
srlx%o3, 0x20, %o5
-   mulx%g4, %o5, %g4
+   mulx%o4, %o5, %o4
mulx%g3, %o5, %o5
sethi   %hi(0x8000), %g3
-   addcc   %g5, %g4, %g5
-   srlx%g5, 0x20, %g5
+   addcc   %g7, %o4, %g7
+   srlx%g7, 0x20, %g7
add %g3, %g3, %g3
movcc   %xcc, %g0, %g3
-   addcc   %o5, %g5, %o5
-   sllx%g4, 0x20, %g4
-   add %o1, %g4, %o1
+   addcc   %o5, %g7, %o5
+   sllx%o4, 0x20, %o4
+   add %o1, %o4, %o1
add %o5, %g3, %g2
mulx%g1, %o2, %g1
add %g1, %g2, %g1