On 30/11/16 09:50 +0100, Christophe Lyon wrote:
I'll try to think about it, but I can live with that single "known" failure.
It's better than the ~3500 failures I used to have, and hopefully
won't report false regressions anymore.
OK, cool. One rather than 3500 is a nice improvement :-)
On 29 November 2016 at 21:18, Jonathan Wakely wrote:
> On 16/11/16 22:18 +0100, Christophe Lyon wrote:
>>
>> On 15 November 2016 at 12:50, Jonathan Wakely wrote:
>>>
>>> On 14/11/16 14:32 +0100, Christophe Lyon wrote:
On 20 October 2016 at 19:40, Jonathan Wakely wrote:
>
>
On 16/11/16 22:18 +0100, Christophe Lyon wrote:
On 15 November 2016 at 12:50, Jonathan Wakely wrote:
On 14/11/16 14:32 +0100, Christophe Lyon wrote:
On 20 October 2016 at 19:40, Jonathan Wakely wrote:
On 20/10/16 10:33 -0700, Mike Stump wrote:
On Oct 20, 2016, at 9:34 AM, Jonathan Wakel
Ping?
On 16 November 2016 at 22:18, Christophe Lyon
wrote:
> On 15 November 2016 at 12:50, Jonathan Wakely wrote:
>> On 14/11/16 14:32 +0100, Christophe Lyon wrote:
>>>
>>> On 20 October 2016 at 19:40, Jonathan Wakely wrote:
On 20/10/16 10:33 -0700, Mike Stump wrote:
>
>
>
On 15 November 2016 at 12:50, Jonathan Wakely wrote:
> On 14/11/16 14:32 +0100, Christophe Lyon wrote:
>>
>> On 20 October 2016 at 19:40, Jonathan Wakely wrote:
>>>
>>> On 20/10/16 10:33 -0700, Mike Stump wrote:
On Oct 20, 2016, at 9:34 AM, Jonathan Wakely wrote:
>
>
>
On 14/11/16 14:32 +0100, Christophe Lyon wrote:
On 20 October 2016 at 19:40, Jonathan Wakely wrote:
On 20/10/16 10:33 -0700, Mike Stump wrote:
On Oct 20, 2016, at 9:34 AM, Jonathan Wakely wrote:
On 20/10/16 09:26 -0700, Mike Stump wrote:
On Oct 20, 2016, at 5:20 AM, Jonathan Wakely wro
On 14 November 2016 at 21:31, Ramana Radhakrishnan
wrote:
>
> On Mon, 14 Nov 2016 at 19:59, Christophe Lyon
> wrote:
>>
>> On 14 November 2016 at 18:54, Mike Stump wrote:
>> > On Oct 21, 2016, at 1:00 AM, Christophe Lyon
>> > wrote:
>> >>
>> >> So if we say that the current behaviour has to kee
On Nov 14, 2016, at 12:31 PM, Ramana Radhakrishnan
wrote:
>
> https://sourceware.org/ml/newlib/2015/msg00653.html
I think that patch is wrong. It is wrong to warn on a system where an empty
body is correct. It is wrong to warn when something more than nothing needs to
be done. In short, it
On 14 November 2016 at 18:54, Mike Stump wrote:
> On Oct 21, 2016, at 1:00 AM, Christophe Lyon
> wrote:
>>
>> So if we say that the current behaviour has to keep being the default,
>> so that users think about what they are really doing,
>
> Having a toolchain not work by default to force users
On Oct 21, 2016, at 1:00 AM, Christophe Lyon wrote:
>
> So if we say that the current behaviour has to keep being the default,
> so that users think about what they are really doing,
Having a toolchain not work by default to force users to think, isn't a winning
strategy.
Everything should al
On 20 October 2016 at 19:40, Jonathan Wakely wrote:
> On 20/10/16 10:33 -0700, Mike Stump wrote:
>>
>> On Oct 20, 2016, at 9:34 AM, Jonathan Wakely wrote:
>>>
>>>
>>> On 20/10/16 09:26 -0700, Mike Stump wrote:
On Oct 20, 2016, at 5:20 AM, Jonathan Wakely wrote:
>
>
> I am c
Hi all,
On 21/10/16 09:00, Christophe Lyon wrote:
[ccying Ramana]
Ramana is currently OoO all of this week.
Kyrill
On 20 October 2016 at 18:34, Jonathan Wakely wrote:
On 20/10/16 09:26 -0700, Mike Stump wrote:
On Oct 20, 2016, at 5:20 AM, Jonathan Wakely wrote:
I am considering leavin
[ccying Ramana]
On 20 October 2016 at 18:34, Jonathan Wakely wrote:
> On 20/10/16 09:26 -0700, Mike Stump wrote:
>>
>> On Oct 20, 2016, at 5:20 AM, Jonathan Wakely wrote:
>>>
>>>
>>> I am considering leaving this in the ARM backend to force people to
>>> think what they want to do about thread s
On 20 October 2016 at 18:51, Jonathan Wakely wrote:
> On 20/10/16 10:40 +0100, Jonathan Wakely wrote:
>>
>> Please CC the libstdc++ list for libstdc++ patches, this is a
>> requirement for patch submission, see https://gcc.gnu.org/lists.html
>>
>>
>> On 20/10/16 09:55 +0200, Christophe Lyon wrote:
On 20/10/16 10:33 -0700, Mike Stump wrote:
On Oct 20, 2016, at 9:34 AM, Jonathan Wakely wrote:
On 20/10/16 09:26 -0700, Mike Stump wrote:
On Oct 20, 2016, at 5:20 AM, Jonathan Wakely wrote:
I am considering leaving this in the ARM backend to force people to
think what they want to do about
On Oct 20, 2016, at 9:34 AM, Jonathan Wakely wrote:
>
> On 20/10/16 09:26 -0700, Mike Stump wrote:
>> On Oct 20, 2016, at 5:20 AM, Jonathan Wakely wrote:
>>>
>>> I am considering leaving this in the ARM backend to force people to
>>> think what they want to do about thread safety with statics a
On 20 October 2016 at 20:08, Mike Stump wrote:
> So, from a test suite perspective, the correct fix it to make the port just
> work. I have a bare metal port, I test libstdc++.
> I'd be curious to hear from the arm folks about it.
I daresay that would be the correct fix from many other perspec
On Oct 20, 2016, at 9:51 AM, Jonathan Wakely wrote:
> If Every. Single. Test. that uses the libstdc++ library has this
> failure, and the library can't be made to be usable, the answer is
> surely to change the meaning of "dg-do run" to not link+run tests, not
> add a new directive to Every. Singl
On 20 October 2016 at 19:51, Jonathan Wakely wrote:
> add a new directive to Every. Single. Test. (and every single test we
> add in future too!)
Uh, that would be a rather unfortunate burden for every library patch
submitter, and to the maintainer
as well, because we _will_ forget it and then
On 20 October 2016 at 19:34, Jonathan Wakely wrote:
> Either way, I don't think disabling 50% of the testsuite is the
> answer. If you don't like the failures, configure the library to build
> without threadsafe statics, or configure it to depend on libatomic, or
> something else. (We might want n
On 20/10/16 10:40 +0100, Jonathan Wakely wrote:
Please CC the libstdc++ list for libstdc++ patches, this is a
requirement for patch submission, see https://gcc.gnu.org/lists.html
On 20/10/16 09:55 +0200, Christophe Lyon wrote:
Hi,
Several times I have noticed/reported test failures because so
On 20/10/16 09:26 -0700, Mike Stump wrote:
On Oct 20, 2016, at 5:20 AM, Jonathan Wakely wrote:
I am considering leaving this in the ARM backend to force people to
think what they want to do about thread safety with statics and C++
on bare-metal systems.
The quoting makes it look like those a
On Oct 20, 2016, at 5:20 AM, Jonathan Wakely wrote:
>
> I am considering leaving this in the ARM backend to force people to
> think what they want to do about thread safety with statics and C++
> on bare-metal systems.
Not quite in the GNU spirit? The port people should decide the best way to g
On 20/10/16 14:01 +0200, Christophe Lyon wrote:
On 20 October 2016 at 11:40, Jonathan Wakely wrote:
Please CC the libstdc++ list for libstdc++ patches, this is a
requirement for patch submission, see https://gcc.gnu.org/lists.html
OK, I thought I wasn't really modifying the lib itself :-)
On 20 October 2016 at 11:40, Jonathan Wakely wrote:
> Please CC the libstdc++ list for libstdc++ patches, this is a
> requirement for patch submission, see https://gcc.gnu.org/lists.html
>
OK, I thought I wasn't really modifying the lib itself :-)
>
> On 20/10/16 09:55 +0200, Christophe Lyon wrot
On 20/10/16 10:40 +0100, Jonathan Wakely wrote:
Please CC the libstdc++ list for libstdc++ patches, this is a
requirement for patch submission, see https://gcc.gnu.org/lists.html
CCing ...
On 20/10/16 09:55 +0200, Christophe Lyon wrote:
Hi,
Several times I have noticed/reported test failure
Please CC the libstdc++ list for libstdc++ patches, this is a
requirement for patch submission, see https://gcc.gnu.org/lists.html
On 20/10/16 09:55 +0200, Christophe Lyon wrote:
Hi,
Several times I have noticed/reported test failures because some test
cases wouldn't link on arm-none-eabi usin
On 20 October 2016 at 09:55, Christophe Lyon wrote:
> Hi,
>
> Several times I have noticed/reported test failures because some test
> cases wouldn't link on arm-none-eabi using the default 'old' cpu
> target: __sync_synchronize cannot be resolved by the linker.
>
> The attached long patch adds
> +
Hi,
Several times I have noticed/reported test failures because some test
cases wouldn't link on arm-none-eabi using the default 'old' cpu
target: __sync_synchronize cannot be resolved by the linker.
The attached long patch adds
+// { dg-require-thread-fence "" }
to all the tests that require it
29 matches
Mail list logo
