Hi!
On Wed, Oct 10, 2018 at 08:55:12PM -0400, Paul Koning wrote:
[ snip ]
> Note that this isn't permitted by the .md file -- the mode is wrong (QI not
> HI).
Other targets use an expander and check the mode explicitly in there. See
rs6000 or sh for example.
> It's not obvious to me how that
On 11/10/18 04:53, Alexandre Oliva wrote:
> On Oct 10, 2018, Rich Felker wrote:
>> For aarch64 at least, according to discussions I had with Szabolcs
>> Nagy, there is an intent that any new extensions to the aarch64
>> register file be treated as clobbered by tlsdesc functions, rather
>> than pre
> On Oct 11, 2018, at 3:11 AM, Segher Boessenkool
> wrote:
>
> Hi!
>
> On Wed, Oct 10, 2018 at 08:55:12PM -0400, Paul Koning wrote:
>
> [ snip ]
>
>> ...
>> Why is this happening, and how can I fix it (short of removing the
>> doloop_end pattern)? I see a comment in loop-doloop.c about h
Hello,
Hope you are doing good. I am not sure whether you got a chance to read my
previous mail (mentioned below).
Please let me know if you are interested in acquiring the complete list of
attendee contacts.
Hope to hear from you soon.
Best Wishes,
Peter
From: Peter Chase [
On Thu, Oct 11, 2018 at 12:53:04AM -0300, Alexandre Oliva wrote:
> On Oct 10, 2018, Rich Felker wrote:
>
> > It's recently come up in musl libc development that the tlsdesc asm
> > functions, at least for some archs, are potentially not future-proof,
> > in that, for a given fixed version of the
Hey GCConauts,
I've noticed some strange behavior in gcc > 5.
unsigned int hmmm5(unsigned int a, unsigned int b, unsigned int c)
{
return a + (b << c << c << c << c << c);
}
This function compiles how you'd expect:
mov ecx, edx
sal esi, cl
sal esi, cl
sal esi, cl
sal esi, cl
sal esi, cl
lea
On Thu, 11 Oct 2018, Jason A. Donenfeld wrote:
>
> I realize this is probably a fairly trivial matter, but I am very
> curious if somebody knows which heuristic gcc is applying here, and
> why exactly. It's not something done by any other compiler I could
> find, and it only started happening with
Snapshot gcc-7-20181011 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/7-20181011/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7
On Oct 11, 2018, Rich Felker wrote:
> This is indeed the big risk for glibc right now (with lazy,
> non-fail-safe allocation of dynamic TLS)
Yeah, dynamic TLS was a can of works in that regard even before lazy TLS
relocations.
> that it's unlikely for vector-heavy code to be using TLS where the
On Thu, Oct 11, 2018 at 08:18:37PM -0300, Alexandre Oliva wrote:
> On Oct 11, 2018, Rich Felker wrote:
>
> > This is indeed the big risk for glibc right now (with lazy,
> > non-fail-safe allocation of dynamic TLS)
>
> Yeah, dynamic TLS was a can of works in that regard even before lazy TLS
> rel
10 matches
Mail list logo
