Snapshot gcc-6-20170112 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/6-20170112/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6
On Thu, Jan 12, 2017 at 5:06 AM, Paul Smith wrote:
> TL;DR:
> I have an issue where if I have a .so linked with -static-lib* making
> all STL symbols private, and if I throw an exception out of that .so to
> be caught by the caller, then I get a SIGABRT from a gcc_assert() down
> in the guts of th
On 01/11/2017 09:16 AM, Robin Dapp wrote:
Hi,
When examining the performance of some test cases on s390 I realized
that we could do better for constructs like 2-byte memcpys or
2-byte/4-byte memsets. Due to some s390-specific architectural
properties, we could be faster by e.g. avoiding excessiv
On Thu, Jan 12, 2017 at 11:22:58AM -0600, Joel Sherrill wrote:
> I am looking at the RTEMS x86 TLS support. When -fPIC is
> specified, gcc generates calls to ___tls_get_addr(). But
> when it is not specified, there are no external calls.
> To make sure we are doing the right thing, I have a
> few q
Hi
I am looking at the RTEMS x86 TLS support. When -fPIC is
specified, gcc generates calls to ___tls_get_addr(). But
when it is not specified, there are no external calls.
To make sure we are doing the right thing, I have a
few questions:
+ What is expected for "get TLS" when __tls_get_addr()
is
On Thu, Jan 12, 2017 at 9:26 AM, Robin Dapp wrote:
>> Yes, for memset with larger element we could add an optab plus
>> internal function combination and use that when the target wants. Or
>> always use such IFN and fall back to loopy expansion.
>
> So, adding additional patterns in tree-loop-dis
On 09/01/2017 19:35, Jeff Law wrote:
> On 01/09/2017 07:02 AM, Aurelien Buhrig wrote:
>> On 06/01/2017 17:06, Jeff Law wrote:
>>> On 01/06/2017 03:20 AM, Aurelien Buhrig wrote:
>> So the insn:
>> (set (reg:QI 0 r0) (mem:QI (plus:SI (reg:SI 2 r2)(const_int 1))
>>
>> is transform
> Yes, for memset with larger element we could add an optab plus
> internal function combination and use that when the target wants. Or
> always use such IFN and fall back to loopy expansion.
So, adding additional patterns in tree-loop-distribute.c (and mapping
them to dedicated optabs) is fine?
