Re: GNU indirect functions vs. symbol visibility

[Florian Weimer]

* Alan Modra:

> glibc people: As the main user of ifuncs, how do you feel about not
> declaring functions hidden that are implemented in glibc by ifuncs?

We have run into this before, I think:

  

> It's fine to make them hidden via a version script, or even define
> them as hidden (which requires just the rs6000_elf_encode_section_info
> part of my gcc patch to make ppc32 behave).

If it doesn't work, we'd certainly prefer an early diagnostic.

Re: GNU indirect functions vs. symbol visibility

[Alan Modra]

On Thu, Aug 25, 2016 at 01:36:53PM +0200, Florian Weimer wrote:
> * Alan Modra:
> 
> > glibc people: As the main user of ifuncs, how do you feel about not
> > declaring functions hidden that are implemented in glibc by ifuncs?
> 
> We have run into this before, I think:
> 
>   

Yes, this is exactly the same problem, a hidden visibility prototype
with an ifunc definition.  Don't add the visibility attribute to the
prototype and the problem will no longer occur.

Also note that adding hidden visibility to a prototype that has an
ifunc definition in glibc gives no benefit on targets that can handle
this situation.

The difficulty of course is that where glibc does not provide an ifunc
implementation you *do* want the hidden visibility attribute, and
whether or not ifuncs are used varies from target to target.

> > It's fine to make them hidden via a version script, or even define
> > them as hidden (which requires just the rs6000_elf_encode_section_info
> > part of my gcc patch to make ppc32 behave).
> 
> If it doesn't work, we'd certainly prefer an early diagnostic.

Right.  https://sourceware.org/bugzilla/show_bug.cgi?id=20515 opened.

-- 
Alan Modra
Australia Development Lab, IBM

Vector unaligned load/store x86 intrinsics

[Marc Glisse]

Hello,

I was considering changing the implementation of _mm_loadu_pd in x86's 
emmintrin.h to avoid a builtin. Here are 3 versions:


typedef double __m128d __attribute__ ((__vector_size__ (16), __may_alias__));
typedef double __m128d_u __attribute__ ((__vector_size__ (16), __may_alias__, 
aligned(1)));

__m128d f (double const *__P)
{
  return __builtin_ia32_loadupd (__P);
}

__m128d g (double const *__P)
{
  return *(__m128d_u*)(__P);
}

__m128d h (double const *__P)
{
  __m128d __r;
  __builtin_memcpy (&__r, __P, 16);
  return __r;
}


f is what we have currently. f and g generate the same code. h also 
generates the same code except at -O0 where it is slightly longer.


(note that I haven't regtested either version yet)

1) I don't have any strong preference between g and h, is there a reason 
to pick one over the other? I may have a slight preference for g, which 
expands to


  __m128d _3;
  _3 = MEM[(__m128d_u * {ref-all})__P_2(D)];

while h yields

  __int128 unsigned _3;
  _3 = MEM[(char * {ref-all})__P_2(D)];
  _4 = VIEW_CONVERT_EXPR(_3);


2) Reading Intel's doc for movupd, it says: "If alignment checking is 
enabled (CR0.AM = 1, RFLAGS.AC = 1, and CPL = 3), an alignment-check 
exception (#AC) may or may not be generated (depending on processor 
implementation) when the operand is not aligned on an 8-byte boundary." 
Since we generate movupd for memcpy even when the alignment is presumably 
only 1 byte, I assume that this alignment-check stuff is not supported by 
gcc?


--
Marc Glisse

gcc-6-20160825 is now available

[gccadmin]

Snapshot gcc-6-20160825 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160825/
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-branch 
revision 239763

You'll find:

 gcc-6-20160825.tar.bz2   Complete GCC

  MD5=7993b2b8080d12e9fa9b3ba5a3a1f586
  SHA1=7cac5c1f8c51ed8e175f5c8fe696a68fcd400e99

Diffs from 6-20160818 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-6
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.