Boost Trac, random, No-Maintainer?
I filed 3 defects into Boost Trac for Boost.Random based on work I just did on adding CI integration, and the maintainer that Trac assigned to these new items was "No-Maintainer". That seems incorrect? The backlog in trac for random also has "No-Maintainer" assigned to all the items. For folks who like (potential) compiler optimization bugs: https://svn.boost.org/trac10/ticket/13247 - Jim
James E. King, III wrote:
For folks who like (potential) compiler optimization bugs: https://svn.boost.org/trac10/ticket/13247
Looking at the source of independent_bits, this jumps out at me: S = (S << w0) + (u & y0_mask); and later S = (S << (w0 + 1)) + (u & y1_mask); Shifts with a value more than the number of bits are undefined, and debugging confirms that w0 is 32 in the failing tests. Re Trac, I just enabled Github Issues for Random. Perhaps we finally need to do that for all libraries.
Andrey Semashev wrote:
On 10/08/17 17:00, Peter Dimov via Boost wrote:
Re Trac, I just enabled Github Issues for Random. Perhaps we finally need to do that for all libraries.
I think it should be left up to the library maintainers.
The library maintainers who dislike issues can re-disable them. The problem with the current status quo is that when I look at a library and see its issues disabled, I don't know if that's because the maintainer wants them disabled, or because they are disabled because all were initially disabled. No way to gauge intent.
On 08.10.2017 11:32, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
On 10/08/17 17:00, Peter Dimov via Boost wrote:
Re Trac, I just enabled Github Issues for Random. Perhaps we finally > need to do that for all libraries.
I think it should be left up to the library maintainers.
The library maintainers who dislike issues can re-disable them.
Huh.
The problem with the current status quo is that when I look at a library and see its issues disabled, I don't know if that's because the maintainer wants them disabled, or because they are disabled because all were initially disabled. No way to gauge intent.
Yeah, the documentation structure still hasn't caught up with the move to github. Each project should *individually* contain some info to indicate how to reach the maintainer and where to submit issues. There used to be a single universal answer (trac), but quite a few libraries have moved to github, yet there is no normalized way to indicate that. (I quick and easy solution would be for each library to have its own "landing page" (accessible through "http://boostorg.github.com/<library>") which initially would be filled out with default values. Library maintainers would take ownership of that document and could change those values according to their needs.) Stefan -- ...ich hab' noch einen Koffer in Berlin...
On 10/8/17 8:41 AM, Stefan Seefeld via Boost wrote:
On 08.10.2017 11:32, Peter Dimov via Boost wrote:
Yeah, the documentation structure still hasn't caught up with the move to github. Each project should *individually* contain some info to indicate how to reach the maintainer and where to submit issues.
You mean like on the boost library incubator. it would be easy to add pages for existing boost libraries. In fact, I might just do that on my own initiative. There used to be a
single universal answer (trac), but quite a few libraries have moved to github, yet there is no normalized way to indicate that.
(I quick and easy solution would be for each library to have its own "landing page" (accessible through "http://boostorg.github.com/<library>") which initially would be filled out with default values. Library maintainers would take ownership of that document and could change those values according to their needs.)
Right, See above. Robert Ramey
Stefan
On October 8, 2017 6:33:16 PM Peter Dimov via Boost <boost@lists.boost.org> wrote:
Andrey Semashev wrote:
On 10/08/17 17:00, Peter Dimov via Boost wrote:
Re Trac, I just enabled Github Issues for Random. Perhaps we finally need to do that for all libraries.
I think it should be left up to the library maintainers.
The library maintainers who dislike issues can re-disable them.
The problem with the current status quo is that when I look at a library and see its issues disabled, I don't know if that's because the maintainer wants them disabled, or because they are disabled because all were initially disabled. No way to gauge intent.
Just let the maintainers have admin rights for their libraries, they will enable issues if they want it. Enabling it globally and asking the maintainers to complain seems like a wrong way to gauge intent.
On October 8, 2017 7:36:18 PM Peter Dimov via Boost <boost@lists.boost.org> wrote:
Andrey Semashev wrote:
Just let the maintainers have admin rights for their libraries,
They do.
No, surely not all of them do. Some admin tickets requesting admin access are hanging unanswered for quite some time and I don't think admin rights were granted to maintainers during the transition to git. Not sure if admin rights are granted for new libraries.
they will enable issues if they want it.
They do not.
Then there's your answer. If project maintainers that have admin rights don't enable issues then they don't want it.
On Sun, Oct 8, 2017 at 10:13 AM, Andrey Semashev via Boost <boost@lists.boost.org> wrote:
Then there's your answer. If project maintainers that have admin rights don't enable issues then they don't want it.
Rather than speak in generalities I think it would be more productive to talk about specific authors and specific projects. For example, I suspect that Chris does not want Issues enabled here: <https://github.com/boostorg/asio> But would rather see them here: <https://github.com/chriskohlhoff/asio> We should enumerate all of the libraries which have Issues disabled and evaluate them one by one. Thanks
On Sun, Oct 8, 2017 at 1:18 PM, Vinnie Falco via Boost < boost@lists.boost.org> wrote:
On Sun, Oct 8, 2017 at 10:13 AM, Andrey Semashev via Boost <boost@lists.boost.org> wrote:
Then there's your answer. If project maintainers that have admin rights don't enable issues then they don't want it.
Rather than speak in generalities I think it would be more productive to talk about specific authors and specific projects. For example, I suspect that Chris does not want Issues enabled here: <https://github.com/boostorg/asio>
But would rather see them here: <https://github.com/chriskohlhoff/asio>
We should enumerate all of the libraries which have Issues disabled and evaluate them one by one.
As a consumer of boost, it would make a lot more sense for me to go to one place for issues. If I go to the official repository for a boostorg library and issues are not enabled, I find that odd. Further if some have issues enabled and some do not, I find that even more odd. It makes a lot more sense to me as a consumer of boost that if I have an issue from a github repository I have pulled from, that's where I should submit issues. It also does not make sense that some repositories would prefer to have issues on personal forks. As a consumer of boost, if I cannot find the issue in github issues for that repository, I might assume the issue is not known. Taking the example of asio, which has no readme, how would I possibly know to go to chriskohlhoff's repository to submit an issue? I'm there right now and I have no idea where to submit an issue. If I poke around enough I might find my way to trac (as a ocnsumer). I'm looking at the official github page for the official boost library asio, why are issues somewhere else? My observation in the libraries I've wandered into is that issues in trac do not get a lot of attention. The backlog in many projects in trac today is littered with things that have valid patches but sit open literally for years. Let's take this to the most extreme incarnation of what people have suggested - allowing maintainers to decide: Imagine the confusion from a consumer of boost, if each boostorg repository had its own completely separate way of recording and tracking issues. I would find that quite frustrating, whereas if I can always go to one place (the issues tab in the *official* repository) to look for known issues, just like I can go to one place to look for open pull requests, that makes more sense. My personal preference would be to require github issues be enabled and used for all official boostorg repositories, and that trac be deprecated and accept no new issues. This is what end users who consume boost expect. This will make it easier for issues to be reported and dealt with. Isn't that what we want? We should not make it difficult to submit issues on boost libraries to make it easier for maintainers. We should make it easier for consumers and encourage them to want to use more libraries. Just some observations from my end. - Jim
On Sun, Oct 8, 2017 at 7:14 PM, James E. King, III via Boost <boost@lists.boost.org> wrote:
My personal preference would be to require github issues be enabled and used for all official boostorg repositories, and that trac be deprecated and accept no new issues.
That is my preference as well. I would take it one step further, issues in Trac should be imported into the corresponding GitHub repository using an automated tool, for visibility. Thanks
On 08.10.2017 22:14, James E. King, III via Boost wrote:
On Sun, Oct 8, 2017 at 1:18 PM, Vinnie Falco via Boost < boost@lists.boost.org> wrote:
On Sun, Oct 8, 2017 at 10:13 AM, Andrey Semashev via Boost <boost@lists.boost.org> wrote:
Then there's your answer. If project maintainers that have admin rights don't enable issues then they don't want it. Rather than speak in generalities I think it would be more productive to talk about specific authors and specific projects. For example, I suspect that Chris does not want Issues enabled here: <https://github.com/boostorg/asio>
But would rather see them here: <https://github.com/chriskohlhoff/asio>
We should enumerate all of the libraries which have Issues disabled and evaluate them one by one.
As a consumer of boost, it would make a lot more sense for me to go to one place for issues. Can you elaborate what you mean by "customer of boost" ? Boost contains > 100 libraries, so I think qualifying yourself as a "boost customer" isn't very helpful, and neither is it practical to have a single hub for interactions between "boost" developers and users.
If I go to the official repository for a boostorg library and issues are not enabled, I find that odd. Further if some have issues enabled and some do not, I find that even more odd.
I agree. This is why I think we need a canonical way for each library to document how to submit issues. The "Search the bug database" link on http://www.boost.org/development/bugs.html just isn't cutting it any longer (if it ever has).
It makes a lot more sense to me as a consumer of boost that if I have an issue from a github repository I have pulled from, that's where I should submit issues.
It also does not make sense that some repositories would prefer to have issues on personal forks. I think it's high time to admit that individual libraries are maintained by individual maintainers / communities. Each should provide clear instructions on how to submit issues, etc. Then you can take it up with each library individually if you don't agree with their choice of issue
I think the first step for you "as a customer" is to be aware of which library / libraries you use, and for each have a way to provide feedback (submit issues, etc.). The fact that "boost" has been trying hard to appear as a single entity doesn't help. But at least I think we can fix that. tracker, communication channel, rather than try to resolve differences on this list.
As a consumer of boost, if I cannot find the issue in github issues for that repository, I might assume the issue is not known. Taking the example of asio, which has no readme, how would I possibly know to go to chriskohlhoff's repository to submit an issue? I'm there right now and I have no idea where to submit an issue. If I poke around enough I might find my way to trac (as a ocnsumer). I agree; I can feel your pain. Boost's website needs a lot of attention to make it easier for maintainers to document how they prefer to be reachable.
I'm looking at the official github page for the official boost library asio, why are issues somewhere else?
My observation in the libraries I've wandered into is that issues in trac do not get a lot of attention. The backlog in many projects in trac today is littered with things that have valid patches but sit open literally for years.
Let's take this to the most extreme incarnation of what people have suggested - allowing maintainers to decide:
Imagine the confusion from a consumer of boost, if each boostorg repository had its own completely separate way of recording and tracking issues. I would find that quite frustrating, whereas if I can always go to one place (the issues tab in the *official* repository) to look for known issues, just like I can go to one place to look for open pull requests, that makes more sense.
It may make sense for someone who believes to be a "boost consumer". But that term is ill-defined, as "boost" isn't really a well-defined entity, as far as development is concerned. You really need to understand what boost *libraries* you are using (or "consuming", if you really have to use that term). And once you know that, you should be able to figure out where to look for and report issues.
My personal preference would be to require github issues be enabled and used for all official boostorg repositories, and that trac be deprecated and accept no new issues. This is what end users who consume boost expect. This will make it easier for issues to be reported and dealt with. Isn't that what we want? We should not make it difficult to submit issues on boost libraries to make it easier for maintainers. We should make it easier for consumers and encourage them to want to use more libraries.
While I personally agree, I don't think this is a choice anyone can impose on the people who have to maintain the individual boost libraries. We may encourage library maintainers to use a particular issue tracker, but ultimately the choice is theirs. Stefan -- ...ich hab' noch einen Koffer in Berlin...
On 09.10.2017 05:10, Stefan Seefeld via Boost wrote:
While I personally agree, I don't think this is a choice anyone can impose on the people who have to maintain the individual boost libraries. We may encourage library maintainers to use a particular issue tracker, but ultimately the choice is theirs.
How so? You require a review for accepting Boost libraries. I don't see how requiring the use of a specific issue tracker is different. As a user it's _significantly_ better to have a single issue tracker to consider, instead of having to go on a hunt to find the right one to use for each library and managing the various login credentials. Cheers - Asbjørn
Stefan Seefeld wrote:
On 08.10.2017 22:14, James E. King, III via Boost wrote:
My personal preference would be to require github issues be enabled and used for all official boostorg repositories, and that trac be deprecated and accept no new issues.
...
While I personally agree, I don't think this is a choice anyone can impose on the people who have to maintain the individual boost libraries.
We have to say something on http://www.boost.org/development/bugs.html and the something that we currently say is inadequate. Regardless of one's personal preference regarding Github issues, I think that we all ought to agree that Github pull requests are infinitely better than Trac patches (were much better even without CI, now it's not even a contest). And yet people who are willing to submit a patch are encouraged to do so on Trac. This wastes either theirs or the maintainer's time. With respect to reports not containing a patch, I also consider Github issues much superior, due to their integration with everything else on Github - you can cross-reference issues, PRs, commits, and @ people.
AMDG On 10/09/2017 05:22 AM, Peter Dimov via Boost wrote:
Regardless of one's personal preference regarding Github issues, I think that we all ought to agree that Github pull requests are infinitely better than Trac patches (were much better even without CI, now it's not even a contest).
To be honest, I prefer patches, because it means I have to deal with git less.
And yet people who are willing to submit a patch are encouraged to do so on Trac. This wastes either theirs or the maintainer's time.
With respect to reports not containing a patch, I also consider Github issues much superior, due to their integration with everything else on Github - you can cross-reference issues, PRs, commits, and @ people.
In Christ, Steven Watanabe
Steven Watanabe wrote:
On 10/09/2017 05:22 AM, Peter Dimov via Boost wrote:
Regardless of one's personal preference regarding Github issues, I think that we all ought to agree that Github pull requests are infinitely better than Trac patches (were much better even without CI, now it's not even a contest).
To be honest, I prefer patches, because it means I have to deal with git less.
A Github PR can be merged without touching git at all. :-) Apart from that, it's a toss-up; you have to git checkout develop; git pull, then apply the patch (which is a single git pull in the PR case, download the patch and 'patch' in the patch case) then test and git commit + git push. The PR wins for me as there's no separate download step.
AMDG On 10/09/2017 10:48 AM, Peter Dimov via Boost wrote:
Steven Watanabe wrote:
On 10/09/2017 05:22 AM, Peter Dimov via Boost wrote:
Regardless of one's personal preference regarding Github issues, I
think > that we all ought to agree that Github pull requests are infinitely > better than Trac patches (were much better even without CI, now it's not > even a contest).
To be honest, I prefer patches, because it means I have to deal with git less.
A Github PR can be merged without touching git at all. :-)
I consider the web interface to encourage sloppy habits. I never even consider applying a patch without testing it personally. I also rarely apply patches exactly as given. I usually want to make some edits before committing them.
Apart from that, it's a toss-up; you have to git checkout develop; git pull, then apply the patch (which is a single git pull in the PR case, download the patch and 'patch' in the patch case) then test and git commit + git push. The PR wins for me as there's no separate download step.
You left out one step: - Spend 5 minutes hunting through the man pages to figure out the correct git command. In Christ, Steven Watanabe
On 10/9/17 10:15 AM, Steven Watanabe via Boost wrote: \
You left out one step: - Spend 5 minutes hunting through the man pages to figure out the correct git command.
Ahhhh - there is a great solution for this. Its SourceTree a great GUI for git. I hardly ever have to sift through the git command line soup to do anything. Stongly, strongly recommend. https://www.sourcetreeapp.com
In Christ, Steven Watanabe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mon, Oct 9, 2017 at 12:48 PM, Peter Dimov via Boost < boost@lists.boost.org> wrote:
Steven Watanabe wrote:
On 10/09/2017 05:22 AM, Peter Dimov via Boost wrote:
Regardless of one's personal preference regarding Github issues, I
think > that we all ought to agree that Github pull requests are infinitely
better than Trac patches (were much better even without CI, now it's not even a contest).
To be honest, I prefer patches, because it means I have to deal with git less.
A Github PR can be merged without touching git at all. :-)
Apart from that, it's a toss-up; you have to git checkout develop; git pull, then apply the patch (which is a single git pull in the PR case, download the patch and 'patch' in the patch case) then test and git commit + git push. The PR wins for me as there's no separate download step.
If you set up CI jobs properly, anyone can submit a PR and it will be tested to your satisfaction automatically (to the extent that travis and appveyor support the platforms you want tested), then all you have to do is click merge. I'm not sure how you would take a patch, apply, and test it in fewer steps than that, and it doesn't require you to use git. - Jim
While I personally agree, I don't think this is a choice anyone can impose on the people who have to maintain the individual boost libraries.
At some point, I think that we have to bite the bullet and retire Trac. It's served us well but we're in the Github era now.
On 9 October 2017 at 03:14, James E. King, III via Boost <boost@lists.boost.org> wrote:
My observation in the libraries I've wandered into is that issues in trac do not get a lot of attention. The backlog in many projects in trac today is littered with things that have valid patches but sit open literally for years.
We already have github pull requests that have sat open for years. It doesn't look like moving bug reports to a different platform will fix that particular problem. http://www.boost.org/development/pull_requests.php?page_view=date
On 10/9/2017 6:12 AM, Daniel James via Boost wrote:
On 9 October 2017 at 03:14, James E. King, III via Boost <boost@lists.boost.org> wrote:
My observation in the libraries I've wandered into is that issues in trac do not get a lot of attention. The backlog in many projects in trac today is littered with things that have valid patches but sit open literally for years.
We already have github pull requests that have sat open for years. It doesn't look like moving bug reports to a different platform will fix that particular problem.
It will make it easier for developers to see all problems in a single place. I agree with James King that a large part of the problem is that PRs are on Github and bug reports are on Boost trac, so the latter gets ignored even more because of that bifurcation.
http://www.boost.org/development/pull_requests.php?page_view=date
Andrey Semashev wrote:
Just let the maintainers have admin rights for their libraries,
They do.
No, surely not all of them do. Some admin tickets requesting admin access are hanging unanswered for quite some time and I don't think admin rights were granted to maintainers during the transition to git. Not sure if admin rights are granted for new libraries.
I checked a few at random, all did. Initially they did not, but then, if I recall correctly, Github changed the way privileges worked and maintainers were made admins. I could be wrong about that though.
If project maintainers that have admin rights don't enable issues then they don't want it.
Not what my experience shows. (My sample is small, of course.) The typical case is for the maintainers to not even know they have issues disabled. (And there's no way for users to tell them short of creating a dummy pull request, as the usual mechanism of creating an issue obviously doesn't work.)
On October 8, 2017 8:25:11 PM Peter Dimov via Boost <boost@lists.boost.org> wrote:
Andrey Semashev wrote:
Just let the maintainers have admin rights for their libraries,
They do.
No, surely not all of them do. Some admin tickets requesting admin access are hanging unanswered for quite some time and I don't think admin rights were granted to maintainers during the transition to git. Not sure if admin rights are granted for new libraries.
I checked a few at random, all did. Initially they did not, but then, if I recall correctly, Github changed the way privileges worked and maintainers were made admins.
That's not my experience. AFAIR, I was made admin only after requesting via a ticket. I don't remember mass permission granting and I'm still not an admin of Boost.Atomic.
If project maintainers that have admin rights don't enable issues then they don't want it.
Not what my experience shows. (My sample is small, of course.) The typical case is for the maintainers to not even know they have issues disabled.
I find this hard to believe. It's pretty obvious there is no Issues tab on the GitHub page. And it would be strange for someone wanting to use issues to not know if they are enabled.
Andrey Semashev wrote:
I'm still not an admin of Boost.Atomic.
You are now.
Not what my experience shows. (My sample is small, of course.) The typical case is for the maintainers to not even know they have issues disabled.
I find this hard to believe. It's pretty obvious there is no Issues tab on the GitHub page.
It's obvious for users, yes.
And it would be strange for someone wanting to use issues to not know if they are enabled.
Users know, yes. But without issues enabled, they have no way of communicating this knowledge of theirs to the maintainer.
On October 8, 2017 9:01:25 PM Peter Dimov via Boost <boost@lists.boost.org> wrote:
Andrey Semashev wrote:
Not what my experience shows. (My sample is small, of course.) The typical case is for the maintainers to not even know they have issues disabled.
I find this hard to believe. It's pretty obvious there is no Issues tab on the GitHub page.
It's obvious for users, yes.
And it would be strange for someone wanting to use issues to not know if they are enabled.
Users know, yes.
Maintainers also see the same set of tabs on the project page.
James E. King, III wrote:
For folks who like (potential) compiler optimization bugs: https://svn.boost.org/trac10/ticket/13247
Looking at the source of independent_bits, this jumps out at me:
S = (S << w0) + (u & y0_mask);
and later
S = (S << (w0 + 1)) + (u & y1_mask);
Shifts with a value more than the number of bits are undefined, and debugging confirms that w0 is 32 in the failing tests.
Possible fix: C:\Projects\boost-git\boost\libs\random>git diff diff --git a/include/boost/random/independent_bits.hpp b/include/boost/random/independent_bits.hpp index dec63b3..835ec32 100644 --- a/include/boost/random/independent_bits.hpp +++ b/include/boost/random/independent_bits.hpp @@ -159,7 +159,14 @@ public: BOOST_ASSERT(n0*w0 + (n - n0)*(w0 + 1) == w); result_type S = 0; - for(std::size_t k = 0; k < n0; ++k) { + if(0 < n0) { + base_unsigned u; + do { + u = detail::subtract<base_result_type>()(_base(), (_base.min)()); + } while(u > base_unsigned(y0 - 1)); + S = (u & y0_mask); + } + for(std::size_t k = 1; k < n0; ++k) { base_unsigned u; do { u = detail::subtract<base_result_type>()(_base(), (_base.min)() ); I also see (unrelated) variant=release errors on msvc-12.0/msvc-14.0, but haven't investigated them. ...failed testing.capture-output ..\..\bin.v2\libs\random\test\test_knuth_b.test\msvc-12.0\release\threadapi-win32\threading-multi\test_knuth_b.run... ...failed testing.capture-output ..\..\bin.v2\libs\random\test\test_ecuyer1988.test\msvc-12.0\release\threadapi-win32\threading-multi\test_ecuyer1988.run... ...failed testing.capture-output ..\..\bin.v2\libs\random\test\test_independent_bits31.test\msvc-12.0\release\threadapi-win32\threading-multi\test_independent_bits31.run... ...failed testing.capture-output ..\..\bin.v2\libs\random\test\test_ecuyer1988.test\msvc-14.0\release\threadapi-win32\threading-multi\test_ecuyer1988.run... ...failed testing.capture-output ..\..\bin.v2\libs\random\test\test_knuth_b.test\msvc-14.0\release\threadapi-win32\threading-multi\test_knuth_b.run... ...failed testing.capture-output ..\..\bin.v2\libs\random\test\test_independent_bits31.test\msvc-14.0\release\threadapi-win32\threading-multi\test_independent_bits31.run...
AMDG On 10/08/2017 09:47 AM, Peter Dimov via Boost wrote:
I also see (unrelated) variant=release errors on msvc-12.0/msvc-14.0, but haven't investigated them.
...failed testing.capture-output ..\..\bin.v2\libs\random\test\test_knuth_b.test\msvc-12.0\release\threadapi-win32\threading-multi\test_knuth_b.run...
<snip>
It's probably caused by integer conversion overflow. The failing tests are checking seeding with every possible integer type. In Christ, Steven Watanabe
AMDG On 10/08/2017 09:47 AM, Peter Dimov via Boost wrote:
I also see (unrelated) variant=release errors on msvc-12.0/msvc-14.0, but haven't investigated them.
...failed testing.capture-output ..\..\bin.v2\libs\random\test\test_knuth_b.test\msvc-12.0\release\threadapi-win32\threading-multi\test_knuth_b.run...
...failed testing.capture-output ..\..\bin.v2\libs\random\test\test_ecuyer1988.test\msvc-12.0\release\threadapi-win32\threading-multi\test_ecuyer1988.run...
...failed testing.capture-output ..\..\bin.v2\libs\random\test\test_independent_bits31.test\msvc-12.0\release\threadapi-win32\threading-multi\test_independent_bits31.run...
This appears to be a compiler bug. These three generators are all random engine adaptors applied to a linear_congruential_engine. At boost/random/linear_congruential.hpp:140 if(increment == 0 && _x == 0) { _x = 1; } The compiler is generating a `cmove` but drops the corresponding `test`. I'm unable to spot any undefined behavior in the code (it still appears if there are no conversions and all the types involved are `unsigned int`), but even if there were a problem, this codegen can't possibly make sense. In Christ, Steven Watanabe
AMDG On 10/08/2017 08:00 AM, Peter Dimov via Boost wrote:
James E. King, III wrote:
For folks who like (potential) compiler optimization bugs: https://svn.boost.org/trac10/ticket/13247
Looking at the source of independent_bits, this jumps out at me:
S = (S << w0) + (u & y0_mask);
and later
S = (S << (w0 + 1)) + (u & y1_mask);
Shifts with a value more than the number of bits are undefined, and debugging confirms that w0 is 32 in the failing tests.
Fixed in develop. In Christ, Steven Watanabe
On Mon, Oct 9, 2017 at 1:17 PM, Steven Watanabe via Boost < boost@lists.boost.org> wrote:
AMDG
On 10/08/2017 08:00 AM, Peter Dimov via Boost wrote:
James E. King, III wrote:
For folks who like (potential) compiler optimization bugs: https://svn.boost.org/trac10/ticket/13247
Looking at the source of independent_bits, this jumps out at me:
S = (S << w0) + (u & y0_mask);
and later
S = (S << (w0 + 1)) + (u & y1_mask);
Shifts with a value more than the number of bits are undefined, and debugging confirms that w0 is 32 in the failing tests.
Fixed in develop.
In Christ, Steven Watanabe
Any chance you could work the same magic on this one so I can enable the "osx" builds in travis for the project? It only happens on the OSX builds; not on Linux with clang or gcc. https://svn.boost.org/trac10/ticket/13248
AMDG On 10/10/2017 10:27 AM, James E. King, III via Boost wrote:
Any chance you could work the same magic on this one so I can enable the "osx" builds in travis for the project? It only happens on the OSX builds; not on Linux with clang or gcc.
Okay, this is really a mess. The test is checking for the strong exception guarantee from something that clearly does not give such a guarantee. The reason it "works" is that there's another bug that causes an exception to be thrown early (before anything has had a chance to change). In Christ, Steven Watanabe
I filed 3 defects into Boost Trac for Boost.Random based on work I just did on adding CI integration, and the maintainer that Trac assigned to these new items was "No-Maintainer". That seems incorrect?
On 10/08/17 16:04, James E. King, III via Boost wrote: maintainers.txt says that Boost.Random maintainer is Steven Watanabe.
participants (10)
-
Andrey Semashev -
Asbjørn -
Daniel James -
Edward Diener -
James E. King, III -
Peter Dimov -
Robert Ramey -
Stefan Seefeld -
Steven Watanabe -
Vinnie Falco