Re: Regular darwin builds
Due to pr64625 I have looked more carefully to your logs and I did not see any entry for libgomp. Is it expected? TIA Dominique > Le 15 déc. 2014 à 22:11, FX a écrit : > > Hi all, > > I’ve set up daily builds and regtests on a darwin box. The results should > appear directly on gcc-testresults > (https://gcc.gnu.org/ml/gcc-testresults/current/). > This should, in the future, help track down regressions affecting darwin > (PIC-related, in particular!). > > The hardware is new, the OS is the latest and greatest > (x86_64-apple-darwin14), and will be updated to keep it that way. However, > it’s not very powerful (it’s a Mac Mini). Bootstrap (C, C++, Obj-C, Obj-C++, > Fortran, Java, LTO) takes about 2 hours, regtesting both 32 and 64-bit takes > a bit over 3 hours. > > I plan to schedule it for: > > - daily bootstrap + regtest of trunk > - weekly bootstrap of latest release branch (currently 4.9) > > If you have other ideas, I’m open to suggestions. > > FX
[patch libstdc++] Add POSIX variant of shared_timed_mutex.
This adds a POSIX-based implementation of shared_timed_mutex, using
pthread_rwlock_* operations directly instead of implementing with
mutexes and two condvars. This enables using an optimized
pthread_rwlock_t on POSIX.
Tested on x86_64-linux.
OK?
2015-01-16 Torvald Riegel
* include/std/shared_mutex (shared_timed_mutex): Add POSIX-based
implementation.
commit e0a32ddb058d8b4dd563f89130d03bce220ace8c
Author: Torvald Riegel
Date: Thu Jan 15 22:29:23 2015 +0100
libstdc++: Add POSIX variant of shared_timed_mutex.
* include/std/shared_mutex (shared_timed_mutex): Add POSIX-based
implementation.
diff --git a/libstdc++-v3/include/std/shared_mutex b/libstdc++-v3/include/std/shared_mutex
index 8bfede3..643768c 100644
--- a/libstdc++-v3/include/std/shared_mutex
+++ b/libstdc++-v3/include/std/shared_mutex
@@ -57,6 +57,188 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
/// shared_timed_mutex
class shared_timed_mutex
{
+#if defined(__GTHREADS_CXX0X)
+typedef chrono::system_clock __clock_t;
+
+pthread_rwlock_t _M_rwlock;
+
+ public:
+shared_timed_mutex()
+{
+ int __ret = pthread_rwlock_init(&_M_rwlock, NULL);
+ if (__ret == ENOMEM)
+ throw bad_alloc();
+ else if (__ret == EAGAIN)
+ __throw_system_error(int(errc::resource_unavailable_try_again));
+ else if (__ret == EPERM)
+ __throw_system_error(int(errc::operation_not_permitted));
+ // Errors not handled: EBUSY, EINVAL
+ _GLIBCXX_DEBUG_ASSERT(__ret == 0);
+}
+
+~shared_timed_mutex()
+{
+ int __ret __attribute((unused)) = pthread_rwlock_destroy(&_M_rwlock);
+ // Errors not handled: EBUSY, EINVAL
+ _GLIBCXX_DEBUG_ASSERT(__ret == 0);
+}
+
+shared_timed_mutex(const shared_timed_mutex&) = delete;
+shared_timed_mutex& operator=(const shared_timed_mutex&) = delete;
+
+// Exclusive ownership
+
+void
+lock()
+{
+ int __ret = pthread_rwlock_wrlock(&_M_rwlock);
+ if (__ret == EDEADLK)
+ __throw_system_error(int(errc::resource_deadlock_would_occur));
+ // Errors not handled: EINVAL
+ _GLIBCXX_DEBUG_ASSERT(__ret == 0);
+}
+
+bool
+try_lock()
+{
+ int __ret = pthread_rwlock_trywrlock(&_M_rwlock);
+ if (__ret == EBUSY) return false;
+ // Errors not handled: EINVAL
+ _GLIBCXX_DEBUG_ASSERT(__ret == 0);
+ return true;
+}
+
+template
+ bool
+ try_lock_for(const chrono::duration<_Rep, _Period>& __rel_time)
+ {
+ return try_lock_until(__clock_t::now() + __rel_time);
+ }
+
+template
+ bool
+ try_lock_until(const chrono::time_point<__clock_t, _Duration>& __atime)
+ {
+ auto __s = chrono::time_point_cast(__atime);
+ auto __ns = chrono::duration_cast(__atime - __s);
+
+ __gthread_time_t __ts =
+ {
+ static_cast(__s.time_since_epoch().count()),
+ static_cast(__ns.count())
+ };
+
+ int __ret = pthread_rwlock_timedwrlock(&_M_rwlock, &__ts);
+ // On self-deadlock, we just fail to acquire the lock. Technically,
+ // the program violated the precondition.
+ if (__ret == ETIMEDOUT || __ret == EDEADLK)
+ return false;
+ // Errors not handled: EINVAL
+ _GLIBCXX_DEBUG_ASSERT(__ret == 0);
+ return true;
+ }
+
+template
+ bool
+ try_lock_until(const chrono::time_point<_Clock, _Duration>& __abs_time)
+ {
+ // DR 887 - Sync unknown clock to known clock.
+ const typename _Clock::time_point __c_entry = _Clock::now();
+ const __clock_t::time_point __s_entry = __clock_t::now();
+ const auto __delta = __abs_time - __c_entry;
+ const auto __s_atime = __s_entry + __delta;
+ return try_lock_until(__s_atime);
+ }
+
+void
+unlock()
+{
+ int __ret __attribute((unused)) = pthread_rwlock_unlock(&_M_rwlock);
+ // Errors not handled: EPERM, EBUSY, EINVAL
+ _GLIBCXX_DEBUG_ASSERT(__ret == 0);
+}
+
+// Shared ownership
+
+void
+lock_shared()
+{
+ int __ret = pthread_rwlock_rdlock(&_M_rwlock);
+ if (__ret == EDEADLK)
+ __throw_system_error(int(errc::resource_deadlock_would_occur));
+ if (__ret == EAGAIN)
+ // Maximum number of read locks has been exceeded.
+ __throw_system_error(int(errc::device_or_resource_busy));
+ // Errors not handled: EINVAL
+ _GLIBCXX_DEBUG_ASSERT(__ret == 0);
+}
+
+bool
+try_lock_shared()
+{
+ int __ret = pthread_rwlock_tryrdlock(&_M_rwlock);
+ // If the maximum number of read locks has been exceeded, we just fail
+ // to acquire the lock. Unlike for lock(), we are not allowed to throw
+ // an exception.
+ if (__ret == EBUSY || __ret == EAGAIN) return false;
+ // Errors not handled: EINVAL
+ _GLIBCXX_DEBUG_ASSERT(__ret == 0);
+ return true;
+}
+
+template
+ bool
+ try_lock_shared_for(const chrono::duration<_Rep, _Period>& __rel_time)
+ {
+ return try_lock_shared_until(__clock_t::now() + __rel_time);
+ }
+
+template
+ bool
+ try_lock_shared_
Re: Android native build of GCC
On Fri, Jan 9, 2015 at 6:37 AM, Andrew Haley wrote: > On 01/09/2015 12:30 PM, Richard Biener wrote: >> Does --disable-lto-plugin work? > > Over to you, Cyd. > > Andrew. > An additional important note about --disable-lto, --disable-libsanitizer appears to be required with that option and bootstrapping doesn't appear to work. For the record, the complete configure I used for the build: ../gcc-4.9.2/configure --prefix=/usr/gcc-4.9.2 --build=arm-linux-androideabi --host=arm-linux-androideabi --target=arm-linux-androideabi --disable-ld --with-mpfr=/usr/gcc-4.9.2 --with-mpc=/usr/gcc-4.9.2 --with-gmp=/usr/gcc-4.9.2 --with-as=/usr/gcc-4.9.2/bin/as --with-ld=/usr/gcc-4.9.2/bin/ld --enable-shared --enable-languages=c,c++ --disable-bootstrap --disable-sjlj-exceptions --disable-nls --disable-gold --disable-fortran --disable-libssp --disable-lto --disable-libquadmath --disable-libquadmath-support --disable-libada --disable-werror --disable-multilib --disable-libgomp --disable-cloog --with-build-time-tools=/usr/gcc-4.8.3/bin CFLAGS=-Wall -O2 -mandroid -mbionic CXXFLAGS=-Wall -mandroid -mbionic -frtti LDFLAGS=-Wl,--dynamic-linker=/system/bin/linker -lc -ldl -lgcc -lm LIBCFLAGS=-O2 -mandroid -mbionic LIBCPPFLAGS=-O2 -mandroid -mbionic LIBCXXFLAGS=-O2 -mandroid -mbionic -fno-implicit-templates -frtti LIBS=-lc -ldl -lgcc -lm -lsupc++ -lgnustl_shared --with-build-sysroot=/usr/gcc-4.8.3/sysroot --disable-libsanitizer
Re: LRA handling of subreg (on AARCH64 with ILP32)
On Thu, Jan 15, 2015 at 4:11 AM, Andrew Pinski wrote: > Hi, > I have some code where we generate some weird code that has stores > followed by a load from the same location. > For an example we get: > add x14, sp, 240 > add x15, sp, 232 > str x14, [sp, 136] > mov w2, w27 > ldr w1, [sp, 136] > str x15, [sp, 136] > ldr w0, [sp, 136] > > The RTL originally using an offset of the frame pointer and in DImode > and then we use it in SImode because pointers are 32bit in ILP32. > Can you explain how LRA decides to create this code and ways of improving it? > > This is in perlbench in SPEC CPU 2006. I can provide the preprocessed > sources (since I am using LTO) if needed. I wonder if this is similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55769 on ARM. I thought I'd seen this before - this is a case where A, B and C appear to store a 64 bit value on the stack and then reobtain into a different register set , ie. r6, r3 -> r6, r7 Ramana > > Thanks, > Andrew Pinski
LRA and CANNOT_CHANGE_MODE_CLASS
Hi,
on S/390 I see invalid subregs being generated by LRA although
CANNOT_CHANGE_MODE_CLASS is supposed
to prevent these. The reason appears to be the code you've added with:
commit c6a6cdaaea571860c94f9a9fe0f98c597fef7c81
Author: vmakarov
Date: Tue Oct 23 15:51:41 2012 +
...
int
simplify_subreg_regno (unsigned int xregno, machine_mode xmode,
unsigned int offset, machine_mode ymode)
{
struct subreg_info info;
unsigned int yregno;
#ifdef CANNOT_CHANGE_MODE_CLASS
/* Give the backend a chance to disallow the mode change. */
if (GET_MODE_CLASS (xmode) != MODE_COMPLEX_INT
&& GET_MODE_CLASS (xmode) != MODE_COMPLEX_FLOAT
&& REG_CANNOT_CHANGE_MODE_P (xregno, xmode, ymode)
/* We can use mode change in LRA for some transformations. */<---
&& ! lra_in_progress)<---
return -1;
...
In my testcase it is a subreg which is wrapped into a strict_low_part:
ira:
(insn 295 294 296 39 (set (strict_low_part (subreg:SI (reg/v:TI 252 [ g ]) 4))
(reg:SI 108 [ D.99773 ])) /home3/andreas/patched/../gcc/gcc/ipa-icf.h:391 882
{movstrictsi}
(nil))
reload:
(insn 295 930 931 39 (set (strict_low_part (reg:SI 16 %f0 [ g+4 ]))
(reg:SI 0 %r0 [orig:108 D.99773 ] [108]))
/home3/andreas/patched/../gcc/gcc/ipa-icf.h:391 882
{movstrictsi}
(nil))
Assigning an FPR here is wrong due to the differing endianess of GPRs vs FRPs.
>From what I've seen there does not seem to be code after that in LRA which
>would repair this. Do you
have a hint how I can get this working again?
Unfortunately I was not able to reproduce it with current head. It is only
triggered with the
patchset I'm working on.
-Andreas-
Re: LRA and CANNOT_CHANGE_MODE_CLASS
On 2015-01-16 12:30 PM, Andreas Krebbel wrote:
Hi,
on S/390 I see invalid subregs being generated by LRA although
CANNOT_CHANGE_MODE_CLASS is supposed
to prevent these. The reason appears to be the code you've added with:
commit c6a6cdaaea571860c94f9a9fe0f98c597fef7c81
Author: vmakarov
Date: Tue Oct 23 15:51:41 2012 +
...
int
simplify_subreg_regno (unsigned int xregno, machine_mode xmode,
unsigned int offset, machine_mode ymode)
{
struct subreg_info info;
unsigned int yregno;
#ifdef CANNOT_CHANGE_MODE_CLASS
/* Give the backend a chance to disallow the mode change. */
if (GET_MODE_CLASS (xmode) != MODE_COMPLEX_INT
&& GET_MODE_CLASS (xmode) != MODE_COMPLEX_FLOAT
&& REG_CANNOT_CHANGE_MODE_P (xregno, xmode, ymode)
/* We can use mode change in LRA for some transformations. */<---
&& ! lra_in_progress)<---
return -1;
...
In my testcase it is a subreg which is wrapped into a strict_low_part:
ira:
(insn 295 294 296 39 (set (strict_low_part (subreg:SI (reg/v:TI 252 [ g ]) 4))
(reg:SI 108 [ D.99773 ])) /home3/andreas/patched/../gcc/gcc/ipa-icf.h:391 882
{movstrictsi}
(nil))
reload:
(insn 295 930 931 39 (set (strict_low_part (reg:SI 16 %f0 [ g+4 ]))
(reg:SI 0 %r0 [orig:108 D.99773 ] [108]))
/home3/andreas/patched/../gcc/gcc/ipa-icf.h:391 882
{movstrictsi}
(nil))
Assigning an FPR here is wrong due to the differing endianess of GPRs vs FRPs.
From what I've seen there does not seem to be code after that in LRA which
would repair this. Do you
have a hint how I can get this working again?
Originally the condition ! lra_in_progress was added to deal with
situation of matching reloads of operands with different modes for x86.
LRA temporarily generates illegal subregs of pseudos to deal with such
situation. Later such subregs started to be marked by LRA_SUBREG_P.
You could try to change condition !lra_in_progress to (!lra_in_progress
|| ! LRA_SUBREG_P (original_pseudo)). You need to pass original_pseudo
somehow too. Let me know if it does not work.
