Re: Some baseline thoughts

[Stephan Bergmann]

On 06/15/2017 03:45 PM, Stephan Bergmann wrote:

On 06/15/2017 03:34 PM, Stephan Bergmann wrote:
If there's no objections, I'd bump current master towards LO 6.0 to 
GCC 4.8.


(4.8.1 even, so we'll have ref-qualifiers known-working everywhere and 
can drop HAVE_CXX11_REF_QUALIFIER.)


done now with 
 
"Bump GCC baseline to 4.8.1" and follow-up 
 
"Work around GCC derivates with two-section 'gcc -dumpversion' output" 
(and note



Jun 16 13:20:56sberg: is it an overkill to compile a small 
test program that reads __GNUC_PATCHLEVEL__ to avoid the need to assume things?
Jun 16 13:47:43  vmiklos, given 
 and the changed version scheme since 
GCC 5, I'd just leave it at that; ref-qualifiers only available in 4.8.1 seems to be a rare 
exception where a feature only became available in a x.y.1 release, and we're still 
explicitly checking for existence of that feature independent of the GCC version we 
determine


about the latter)

consequently, also did 
 
"Remove HAVE_CXX11_REF_QUALIFIER, always true now"

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Some baseline thoughts

[Stephan Bergmann]

On 06/15/2017 03:34 PM, Stephan Bergmann wrote:

On 03/29/2017 07:09 PM, Christian Lohmaier wrote:
On Thu, Mar 16, 2017 at 12:20 PM, Stephan Bergmann 
 wrote:

Some of our baselines on current master (towards LO 5.4) are as follows:
** GCC 4.8.1:
*** inheriting constructors
*** ref-qualifiers


FYI: baseline CentOS with devtoolset has 4.8.2


Is anybody actually still using GCC 4.7 on master (towards LO 6.0, by now)?

Just tried to build recent master against some GCC 4.7.4 (on F25, using 
system's libstdc++ 6.3 at runtime), and that doesn't work well, causing 
spurious -Wsign-compare warnings, spurious errors about allegedly 
implicitly noexcept(false) dtors of std::exception derivations, and 
failure to compile usage of thread_local in 
comphelper/source/misc/threadpool.cxx (where support for thread-local 
storage was only "partial" in GCC < 4.8, according to 
).  So I wonder if 
anybody still manages to build with anything less than GCC 4.8?


(LHM's tb56 appears to be using GCC 4.8 by now, and that used to be one 
with a notoriously old compiler.)


If there's no objections, I'd bump current master towards LO 6.0 to GCC 
4.8.


(4.8.1 even, so we'll have ref-qualifiers known-working everywhere and 
can drop HAVE_CXX11_REF_QUALIFIER.)

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Some baseline thoughts

[Stephan Bergmann]

On 03/29/2017 07:09 PM, Christian Lohmaier wrote:

On Thu, Mar 16, 2017 at 12:20 PM, Stephan Bergmann  wrote:

Some of our baselines on current master (towards LO 5.4) are as follows:
** GCC 4.8.1:
*** inheriting constructors
*** ref-qualifiers


FYI: baseline CentOS with devtoolset has 4.8.2


Is anybody actually still using GCC 4.7 on master (towards LO 6.0, by now)?

Just tried to build recent master against some GCC 4.7.4 (on F25, using 
system's libstdc++ 6.3 at runtime), and that doesn't work well, causing 
spurious -Wsign-compare warnings, spurious errors about allegedly 
implicitly noexcept(false) dtors of std::exception derivations, and 
failure to compile usage of thread_local in 
comphelper/source/misc/threadpool.cxx (where support for thread-local 
storage was only "partial" in GCC < 4.8, according to 
).  So I wonder if 
anybody still manages to build with anything less than GCC 4.8?


(LHM's tb56 appears to be using GCC 4.8 by now, and that used to be one 
with a notoriously old compiler.)


If there's no objections, I'd bump current master towards LO 6.0 to GCC 4.8.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Some baseline thoughts

[Stephan Bergmann]

On 03/16/2017 12:20 PM, Stephan Bergmann wrote:
*  macOS 10.8 
() 



Bumping this to macOS 10.9 would get rid of the last known case of 
!HAVE_THREADSAFE_STATICS (cf. 
 
"Found out that Mac OS X 10.9 has working threadsafe statics").  What is 
unknown however is the status on Android and iOS.  Having 
HAVE_THREADSAFE_STATICS everywhere would allow to clean up code, see 
e.g.  "replace 
double-checked-locking with C++11 static initializer".


So

* macOS baseline is bumped 
( 
"bumb MacOS baseline to 10.9")


* and all toolchains are now considered to have thread-safe statics 
( 
"HAVE_THREADSAFE_STATICS sould always be true")


(and writing typo-free commit messages is hard).
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Some baseline thoughts

[Miklos Vajna]

Hi Stephan,

On Thu, Jun 01, 2017 at 09:49:31AM +0200, Stephan Bergmann 
 wrote:
> I don't think your experiment is telling much.  There are three cases to
> consider:
> 
> 1  A toolchain that doesn't support thread-safe statics.
> 
> 2  A toolchain that correctly supports thread-safe statics.
> 
> 3  A (dated GCC) toolchain that supports thread-safe statics, but in a
> broken way (using a single lock for all static variables) that can lead to
> deadlock.
> 
> To guard against kind 3, solenv/gbuild/platform/com_GCC_defs.mk adds
> -fno-threadsafe-statics (to effectively turn the toolchain into kind 1) when
> HAVE_THREADSAFE_STATICS is not true.
> 
> So your experiment (which would try to detect whether Android toolchains are
> of kind 3) would probably also need to remove -fno-threadsafe-statics from
> com_GCC_defs.mk (unless com_GCC_defs.mk somehow isn't relevant for building
> on Android, anyway).
> 
> However, your experiment doesn't try to detect whether Android toolchains
> are of kind 1.  (But it's probably safe to assume that they are not if they
> use a GCC that supports -fthreadsafe-statics.)

I repeated the experiment with
 applied (so
HAVE_THREADSAFE_STATICS is TRUE in config_host.mk, also verified that
the generated commandline when compiling a C++ file contains no
-fno-threadsafe-statics), and also did a clean build, so all code is
built with the new compiler flags. I still see no deadlock up to the
point where a Writer document is rendered.

In addition, we build for Android using (currently) gcc-4.9, so 3) seems
to be out of question.

Does that help?

Regards,

Miklos


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Some baseline thoughts

[Stephan Bergmann]

On 05/31/2017 10:06 PM, Miklos Vajna wrote:

As far as I can see it's the "because those setting up Android support
didn't bother" case. The attached patch does not break opening Writer
documents for me, so I guess it's safe to turn that "always false" to
"always true", as it happens on macOS.


I don't think your experiment is telling much.  There are three cases to 
consider:


1  A toolchain that doesn't support thread-safe statics.

2  A toolchain that correctly supports thread-safe statics.

3  A (dated GCC) toolchain that supports thread-safe statics, but in a 
broken way (using a single lock for all static variables) that can lead 
to deadlock.


To guard against kind 3, solenv/gbuild/platform/com_GCC_defs.mk adds 
-fno-threadsafe-statics (to effectively turn the toolchain into kind 1) 
when HAVE_THREADSAFE_STATICS is not true.


So your experiment (which would try to detect whether Android toolchains 
are of kind 3) would probably also need to remove 
-fno-threadsafe-statics from com_GCC_defs.mk (unless com_GCC_defs.mk 
somehow isn't relevant for building on Android, anyway).


However, your experiment doesn't try to detect whether Android 
toolchains are of kind 1.  (But it's probably safe to assume that they 
are not if they use a GCC that supports -fthreadsafe-statics.)

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Some baseline thoughts

[Miklos Vajna]

Hi,

On Wed, May 31, 2017 at 11:27:16AM +0200, Stephan Bergmann 
 wrote:
> So after the recent bump to macOS 10.9, HAVE_THREADSAFE_STATICS should
> effectively be true everywhere expect on Android (where configure.ac doesn't
> bother at all to decide whether or not it would be true, always leaving it
> false; either because it is known to be false for the current Android
> baseline, or because those setting up Android support didn't bother).
> 
> Can somebody clarify the actual situation on Android?

As far as I can see it's the "because those setting up Android support
didn't bother" case. The attached patch does not break opening Writer
documents for me, so I guess it's safe to turn that "always false" to
"always true", as it happens on macOS.

Regards,

Miklos
diff --git a/sw/source/core/view/vnew.cxx b/sw/source/core/view/vnew.cxx
index c8755a246d39..d35acdebe197 100644
--- a/sw/source/core/view/vnew.cxx
+++ b/sw/source/core/view/vnew.cxx
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 
 void SwViewShell::Init( const SwViewOption *pNewOpt )
 {
@@ -138,6 +139,18 @@ void SwViewShell::Init( const SwViewOption *pNewOpt )
 }
 }
 
+int h() { return 0; }
+void * g(void * /*unused*/) {
+  static int n = h();
+  return 
+}
+int f() {
+  pthread_t t;
+  pthread_create(, 0, g, 0);
+  pthread_join(t, 0);
+  return 0;
+}
+
 /// CTor for the first Shell.
 SwViewShell::SwViewShell( SwDoc& rDocument, vcl::Window *pWindow,
 const SwViewOption *pNewOpt, OutputDevice *pOutput,
@@ -166,6 +179,10 @@ SwViewShell::SwViewShell( SwDoc& rDocument, vcl::Window 
*pWindow,
 mpPrePostOutDev(nullptr),
 maPrePostMapMode()
 {
+SAL_DEBUG("SwViewShell ctor, before test");
+static int n = f();
+(void)n;
+SAL_DEBUG("SwViewShell ctor, after test");
 // in order to suppress event handling in
 //  during construction of  instance
 mbInConstructor = true;


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Some baseline thoughts

[Stephan Bergmann]

On 03/16/2017 12:48 PM, Miklos Vajna wrote:

On Thu, Mar 16, 2017 at 12:20:54PM +0100, Stephan Bergmann 
 wrote:

Bumping this to macOS 10.9 would get rid of the last known case of
!HAVE_THREADSAFE_STATICS (cf. 

"Found out that Mac OS X 10.9 has working threadsafe statics").  What is
unknown however is the status on Android and iOS.  Having
HAVE_THREADSAFE_STATICS everywhere would allow to clean up code, see e.g.
 "replace double-checked-locking
with C++11 static initializer".


master-android$ grep -R THREADSAFE config_*/*.h
config_build/config_global.h:#define HAVE_THREADSAFE_STATICS 1
config_host/config_global.h:#define HAVE_THREADSAFE_STATICS 0

But this is not set in stone, quite possibly the Android toolchain (NDK,
which provides the C++ cross-compiler) can be updated to a newer
version, and then the problem will go away. (See
"with_android_ndk_toolchain_version=4.9" in configure.ac.)


So after the recent bump to macOS 10.9, HAVE_THREADSAFE_STATICS should 
effectively be true everywhere expect on Android (where configure.ac 
doesn't bother at all to decide whether or not it would be true, always 
leaving it false; either because it is known to be false for the current 
Android baseline, or because those setting up Android support didn't 
bother).


Can somebody clarify the actual situation on Android?
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Some baseline thoughts

[Stephan Bergmann]

On 05/19/2017 01:51 PM, Norbert Thiebaud wrote:

I don't mind bumping to 10.9. the box that do the realease is already
at 10.9 anyway


Note 
 
"Minutes of ESC call ..."



* Mac OS X 10.8 support (Michael S)
+ the only platform that does not have thread safe statics
  cf. https://bugs.documentfoundation.org/show_bug.cgi?id=93119
+ de-facto unsupported by Apple since August 2015
  https://support.apple.com/en-gb/HT201222
+ Mozilla dropped support September 2016
  
https://support.mozilla.org/t5/Install-and-Update/Firefox-support-has-ended-for-Mac-OS-X-10-6-10-7-and-10-8/ta-p/32725
+ Chrome dropped support April 2016
  
https://chrome.googleblog.com/2015/11/updates-to-chrome-platform-support.html
+ deprecation warning in 5.4, and drop for 5.5? (Thorsten)
+ around 2nd half of May
+ OK to wait the month (Michael S.)
+ shouldn’t block OS update (Cloph)
+ support to wait 1 month (Kendy)
+ needs some work on Android too (Miklos)
+ toolchain update etc.
+ but shouldn’t affect the runtime (Miklos)
+ release note that etc. (Thorsten)


and resulting release notes update at 
.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Some baseline thoughts

[Norbert Thiebaud]

On Fri, May 19, 2017 at 5:58 AM, Tor Lillqvist  wrote:
>
>> that box use 10.8sdk which come with libxml:
>> #define LIBXML_DOTTED_VERSION "2.7.8"
>>
>
> In a current SDK it is 2.9.4. I don't know how it has been updated in SDK
> versions. But seriously, couldn't we bump the baseline to 10.9 by now? That
> would also help the thread-safe statics thing, if I understand correctly.
> Macs that can't be upgraded to 10.9 or beyond are about ten years old now, I
> think.

I don't mind bumping to 10.9. the box that do the realease is already
at 10.9 anyway

according to google there are about 2 to 3% of mac users still on 10.8.
but hey.. if they are content with sticking to 10.8 they can be
content with sticking with lo 5.3

Norbert
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Some baseline thoughts

[Tor Lillqvist]

> that box use 10.8sdk which come with libxml:
> #define LIBXML_DOTTED_VERSION "2.7.8"
>
>
In a current SDK it is 2.9.4. I don't know how it has been updated in SDK
versions. But seriously, couldn't we bump the baseline to 10.9 by now? That
would also help the thread-safe statics thing, if I understand correctly.
Macs that can't be upgraded to 10.9 or beyond are about ten years old now,
I think.

--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Some baseline thoughts

[Miklos Vajna]

Hi Norbert,

On Thu, May 18, 2017 at 01:11:38PM -0500, Norbert Thiebaud 
 wrote:
> the code use input_id of parserCtxt which was introduced in 2.8
> 
> that box use 10.8sdk which come with libxml:
> #define LIBXML_DOTTED_VERSION "2.7.8"

 is my attempt to address that.
We'll have to move to internal libxml in the long term though, xmlsec
upstream refused the patch, arguing libxml-2.8 was released 5 years ago,
so it's OK to depend on it.

Feedback on the above patch is appreciated, since Jenkins will mark the
patch as verified even if the 10.8 baseline is still broken.

Thanks,

Miklos


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Some baseline thoughts

[Norbert Thiebaud]

On Wed, May 17, 2017 at 2:50 AM, Miklos Vajna  wrote:
> Hi,
>
> On Thu, Mar 16, 2017 at 12:20:54PM +0100, Stephan Bergmann 
>  wrote:
>> *  macOS 10.8 
>> ()
>>
>> Bumping this to macOS 10.9 would get rid of the last known case of
>> !HAVE_THREADSAFE_STATICS (cf. 
>> 
>> "Found out that Mac OS X 10.9 has working threadsafe statics").  What is
>> unknown however is the status on Android and iOS.  Having
>> HAVE_THREADSAFE_STATICS everywhere would allow to clean up code, see e.g.
>>  "replace double-checked-locking
>> with C++11 static initializer".
>
> Do we have any tinderbox building against the 10.8 SDK? I just realized
> that the xmlsec we bundle on master now requires libxml 2.8, and as far
> as I see Jenkins builds against the 10.9 SDK. So there is a risk that
> the 10.8 SDK provides an older libxml and this went unnoticed.

it got noticed today. the beta1 build faird for that very reason

the code use input_id of parserCtxt which was introduced in 2.8

that box use 10.8sdk which come with libxml:
#define LIBXML_DOTTED_VERSION "2.7.8"

Norbert
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Some baseline thoughts

[Miklos Vajna]

Hi,

On Thu, Mar 16, 2017 at 12:20:54PM +0100, Stephan Bergmann 
 wrote:
> *  macOS 10.8 
> ()
> 
> Bumping this to macOS 10.9 would get rid of the last known case of
> !HAVE_THREADSAFE_STATICS (cf. 
> 
> "Found out that Mac OS X 10.9 has working threadsafe statics").  What is
> unknown however is the status on Android and iOS.  Having
> HAVE_THREADSAFE_STATICS everywhere would allow to clean up code, see e.g.
>  "replace double-checked-locking
> with C++11 static initializer".

Do we have any tinderbox building against the 10.8 SDK? I just realized
that the xmlsec we bundle on master now requires libxml 2.8, and as far
as I see Jenkins builds against the 10.9 SDK. So there is a risk that
the 10.8 SDK provides an older libxml and this went unnoticed.

Regards,

Miklos


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Some baseline thoughts

[Christian Lohmaier]

Hi *,

On Thu, Mar 16, 2017 at 12:20 PM, Stephan Bergmann  wrote:
> Some of our baselines on current master (towards LO 5.4) are as follows:
> […]
> ** GCC 4.8.1:
> *** inheriting constructors
> *** ref-qualifiers

FYI: baseline CentOS with devtoolset has 4.8.2

> […]
> The question is what old versions of GCC are required exactly by the various
> builds.
> […]
> *  For --enable-compiler-plugins, Clang 3.4
> (
> "Remove support for Clang < 3.4")

FYI: clang for CentOS baseline from epel repo would be at 3.4.2

> […] unknown however is the status on Android and iOS.

switching to clang for android would use the llvm version, so I guess
should also be fine then. (right now it still users gcc, but support
for that is being faded out by google)

ciao
Christian
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Some baseline thoughts

[Jan-Marek Glogowski]

Am 16.03.2017 um 12:20 schrieb Stephan Bergmann:
> Some of our baselines on current master (towards LO 5.4) are as follows:
> 
> 
> *  GCC 4.7
> (
> "configure: GCC 4.6 is no longer supported on master")
> 
> The latest version is GCC 6.  Noteworthy C++ conformance we would gain
> with a bump (according to
> ) would be:
> 
> ** GCC 4.8.1:
> *** inheriting constructors
> *** ref-qualifiers

> ** GCC 4.9:
> *** decltype(auto), return type deduction for normal functions
> *** generic lambdas
> *** deprecated attribute
> *** single quote as digit separator
> 
> ** GCC 5:
> *** variable templates
> *** user-defined literals for  and 
> 
> The question is what old versions of GCC are required exactly by the
> various builds.

Ubuntu LTS 14.04 has 4.8 as the default compiler. An update for 4.9 is
the maximum available compiler.

> *  MSVC 2015 Update 3
> (
> "Drop support for MSVC 2013")
> 
> Bumping this to MSVC 2017 is unlikely to happen anytime soon, given we
> bumped to MSVC 2015 Update 3 only recently.

Someone / the wiki claimed 2017 is already working, which is a
difference to the previous 2015 bump, which apparently took some time to
fix the fallout of the update.

> *  For --enable-compiler-plugins, Clang 3.4
> (
> "Remove support for Clang < 3.4")
> 
> The latest version is Clang 4 (just released the other day).  Bumping
> this would allow to clean up some #ifdefs across compilerplugins/clang/.
>  The question is what old versions of Clang are required exactly by
> people building with --enable-compiler-plugins.
> 
> (For our C++ conformance, the oldest supported Clang version is rarely
> the limiting factor.)

Ubuntu doesn't have any official clang compiler, but provides a
clang-3.8 in the 14.04 repo, which I use for cross-checking.

I would just like to keep the 14.04 baseline because it makes backports
easier. We'll hopefully stay with 5.2 for a while, but I also thought so
about a 5.0 release, which was dropped.

JMG

P.S. 16.04 has gcc 5.3 as default and 5.4 as an update, clang still 3.8.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Some baseline thoughts

[Miklos Vajna]

Hi,

On Thu, Mar 16, 2017 at 12:20:54PM +0100, Stephan Bergmann 
 wrote:
> *  GCC 4.7 
> (
> "configure: GCC 4.6 is no longer supported on master")

openSUSE stable/SLE still defaults to gcc-4.8 (4.8.5), so depending on
4.9 or newer is a bit uncomfortable for those users (including me).

> Bumping this to macOS 10.9 would get rid of the last known case of
> !HAVE_THREADSAFE_STATICS (cf. 
> 
> "Found out that Mac OS X 10.9 has working threadsafe statics").  What is
> unknown however is the status on Android and iOS.  Having
> HAVE_THREADSAFE_STATICS everywhere would allow to clean up code, see e.g.
>  "replace double-checked-locking
> with C++11 static initializer".

master-android$ grep -R THREADSAFE config_*/*.h
config_build/config_global.h:#define HAVE_THREADSAFE_STATICS 1
config_host/config_global.h:#define HAVE_THREADSAFE_STATICS 0

But this is not set in stone, quite possibly the Android toolchain (NDK,
which provides the C++ cross-compiler) can be updated to a newer
version, and then the problem will go away. (See
"with_android_ndk_toolchain_version=4.9" in configure.ac.)

Regards,

Miklos


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice