On Mon, Jul 17, 2017 at 11:10:01AM +0300, Alexander Monakov wrote:
> On Sun, 16 Jul 2017, Segher Boessenkool wrote:
> > > How? There's no stable sort in libc and switching over to std::stable_sort
> > > would be problematic.
> >
> > Why?
>
> - you'd need to decide if the build time cost of extra
On Sun, 16 Jul 2017, Segher Boessenkool wrote:
> > How? There's no stable sort in libc and switching over to std::stable_sort
> > would be problematic.
>
> Why?
- you'd need to decide if the build time cost of extra 8000+ lines
lines brought in by (per each TU) is acceptable;
- you'd need to
On Sun, 2017-07-16 at 17:32 -0500, Segher Boessenkool wrote:
> On Sun, Jul 16, 2017 at 11:54:43PM +0300, Alexander Monakov wrote:
> >
> > On Sun, 16 Jul 2017, Segher Boessenkool wrote:
> > >
> > > I am well aware, and that is not what I asked. If we would use
> > > stable sorts everywhere
> > H
On Sun, Jul 16, 2017 at 11:54:43PM +0300, Alexander Monakov wrote:
> On Sun, 16 Jul 2017, Segher Boessenkool wrote:
> > I am well aware, and that is not what I asked. If we would use stable
> > sorts everywhere
>
> How? There's no stable sort in libc and switching over to std::stable_sort
> would
On Sun, 16 Jul 2017, Segher Boessenkool wrote:
> I am well aware, and that is not what I asked. If we would use stable
> sorts everywhere
How? There's no stable sort in libc and switching over to std::stable_sort
would be problematic. The obvious approach is adding an implementation of
a stable s
On Sun, Jul 16, 2017 at 12:38:58PM +0300, Alexander Monakov wrote:
> On Sat, 15 Jul 2017, Segher Boessenkool wrote:
> > Would it hurt us to use stable sorts *everywhere*?
>
> Stability (using the usual definition: keeping the original order of
> elements that compare equal) is not required to achi
On Sat, 15 Jul 2017, Segher Boessenkool wrote:
> Would it hurt us to use stable sorts *everywhere*?
Stability (using the usual definition: keeping the original order of
elements that compare equal) is not required to achieve reproducibility [*].
GCC could import or nih any non-randomized implement
On Sat, Jul 15, 2017 at 10:01 PM, Alexander Monakov wrote:
> On Fri, 14 Jul 2017, Yuri Gribov wrote:
>> I've also detect transitiveness violation compare_assert_loc
>> (tree-vrp.c), will send fix once tests are done.
>
> There are more issues still, see the thread starting at
> https://gcc.gnu.org
On Fri, 14 Jul 2017, Yuri Gribov wrote:
> I've also detect transitiveness violation compare_assert_loc
> (tree-vrp.c), will send fix once tests are done.
There are more issues still, see the thread starting at
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00899.html
Alexander
On Sat, Jul 15, 2017 at 07:40:13PM +0100, Yuri Gribov wrote:
> Looked at generators, we have three comparison routines which return 0
> for different objects but all seem to be safe i.e. can't influence
> code generated by GCC.
>
> alt_state_cmp (genautomata.c) - intentional, duplicates are remove
On Fri, Jul 14, 2017 at 8:45 AM, Yuri Gribov wrote:
> FWIW I've done a quick analysis of recent gcc source code using
> https://github.com/yugr/sortcheck and found lots of comparison
> functions which can return 0 for different objects.
>
> All these may cause arrays to be sorted differently on di
On Thu, Jul 13, 2017 at 4:56 AM, Klaus Kruse Pedersen (Klaus)
wrote:
> On Wed, 2017-07-12 at 08:57 -0600, Sandra Loosemore wrote:
>> On 07/12/2017 05:07 AM, Klaus Kruse Pedersen (Klaus) wrote:
>> > I have seen reproducible builds being discussed here, but what is
>> > the
>> > position on inter c-
On Thu, Jul 13, 2017 at 4:56 AM, Klaus Kruse Pedersen (Klaus)
wrote:
> On Wed, 2017-07-12 at 08:57 -0600, Sandra Loosemore wrote:
>> On 07/12/2017 05:07 AM, Klaus Kruse Pedersen (Klaus) wrote:
>> > I have seen reproducible builds being discussed here, but what is
>> > the
>> > position on inter c-
On Wed, 2017-07-12 at 08:57 -0600, Sandra Loosemore wrote:
> On 07/12/2017 05:07 AM, Klaus Kruse Pedersen (Klaus) wrote:
> > I have seen reproducible builds being discussed here, but what is
> > the
> > position on inter c-lib and OS reproducible builds?
>
> I think we consider unstable sort probl
On Wed, Jul 12, 2017 at 3:57 PM, Sandra Loosemore
wrote:
> On 07/12/2017 05:07 AM, Klaus Kruse Pedersen (Klaus) wrote:
>>
>> I have seen reproducible builds being discussed here, but what is the
>> position on inter c-lib and OS reproducible builds?
>
>
> I think we consider unstable sort problems
On 07/12/2017 05:07 AM, Klaus Kruse Pedersen (Klaus) wrote:
I have seen reproducible builds being discussed here, but what is the
position on inter c-lib and OS reproducible builds?
I think we consider unstable sort problems bugs and have fixed them in
the past. Bugzilla search turned up #289
I have seen reproducible builds being discussed here, but what is the
position on inter c-lib and OS reproducible builds?
As it happens, I just hit by an interesting case were different OS'es
generate (significant) different code. The difference originate from a
relatively small memory ordering di
17 matches
Mail list logo
