On Fri, 2017-01-20 at 09:55 -0800, Richard Henderson wrote:
> On 01/19/2017 10:23 AM, Torvald Riegel wrote:
> > I think I prefer Option 3b as the short-term solution. It does not
> > break programs (except the __atomic_always_lock_free assertion scenario,
> > but that's likely to not work anyway g
Hello,
I noticed some implicit-fallthrough warnings in a powerpc64le-linux GCC
build:
/home/sh/b-gcc-git/./gcc/xgcc -B/home/sh/b-gcc-git/./gcc/
-B/home/sh/install-gcc-git/powerpc64le-unknown-linux-gnu/bin/
-B/home/sh/install-gcc-git/powerpc64le-unknown-linux-gnu/lib/ -isystem
/home/sh/insta
Hello,
some time ago IEEE 128-bit floating point support for PowerPC was added
to GCC:
https://gcc.gnu.org/wiki/Ieee128PowerPC
I noticed some issues for RTEMS in this area. Firstly, RTEMS had no
__powerpc__ builtin define, so some source files were effectively
disabled, e.g. ibm-ldouble.c.
On Tue, 24 Jan 2017, Sebastian Huber wrote:
> I noticed some issues for RTEMS in this area. Firstly, RTEMS had no
> __powerpc__ builtin define, so some source files were effectively disabled,
> e.g. ibm-ldouble.c. With __powerpc__ defined, the ibm-ldouble.c didn't compile
> due to:
When you're us
Hello,
I'm a newbie working on a GCC port [1] for PRU [2]. In order to achieve ABI
compatibility with the proprietary TI toolchain, I need my Machine Description
to support HW register subfields as indipendent first-class registers. I could
not find a relevant example in the GCC source. Looks l
On 01/24/2017 03:24 PM, Dimitar Dimitrov wrote:
Currently I'm attempting to describe the 8-bit PRU subregisters as the "real"
target register set, and then work on defining 16-bit and 32-bit ALU operations. But I'm
not sure if that would be efficient for a 32-bit PRU target, or feasible at al
On 01/24/2017 01:08 AM, Torvald Riegel wrote:
> Unless HW transactions are guaranteed to succeed for scenarios that are
> sufficient for the atomics, HTM won't help because we'd have to consider
> the worst-case, which would mean some non-HTM fallback.
We're talking about a 16 byte aligned load he
On 1/24/17 3:06 PM, Richard Henderson wrote:
The only possible concern I see might be with simulators that force HTM
failure, for the purpose of forcibly testing fallback paths. I guess we'd have
to continue to fall back to the lock path for that case.
IIRC, this was the path that valgrind was
Snapshot gcc-5-20170124 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/5-20170124/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5
