Re: x86_64: Should the -mavx* options affected __alignof__ (max_align_t)?

[Florian Weimer]

On 03/23/2015 07:41 PM, Florian Weimer wrote:

> Ah, I should have looked at what max_align_t actually meant.  With these
> semantics, the name is a bit confusing.  I agree that requiring 64 byte
> alignment from malloc does not make much sense.  Thanks.

Follow-up question: Can malloc return a pointer which is not aligned to
_Alignof (max_align_t)?

This happens with most mallocs on x86_64 for sizes of 8 or less, for
which these mallocs only provide an alignment of 8.

DR445 does not seem to have reached consensus on that point.

-- 
Florian Weimer / Red Hat Product Security

Re: x86_64: Should the -mavx* options affected __alignof__ (max_align_t)?

[Andrew Haley]

On 04/02/2015 09:26 AM, Florian Weimer wrote:
> On 03/23/2015 07:41 PM, Florian Weimer wrote:
> 
>> Ah, I should have looked at what max_align_t actually meant.  With these
>> semantics, the name is a bit confusing.  I agree that requiring 64 byte
>> alignment from malloc does not make much sense.  Thanks.
> 
> Follow-up question: Can malloc return a pointer which is not aligned to
> _Alignof (max_align_t)?

No.

max_align_t is specified in 7.19#2 as "an object type...

As for malloc:

"The pointer returned if the allocation succeeds is suitably aligned
so that it may be assigned to a pointer to any type of object with a
fundamental alignment requirement and then used..."

"A fundamental alignment is represented by an alignment less than or
equal to the greatest alignment supported by the implementation in all
contexts, which is equal to _Alignof (max_align_t)."

So, max_align_t is an object type, and therefore malloc returns a
pointer suitable for max_align_t.

Andrew.

Re: x86_64: Should the -mavx* options affected __alignof__ (max_align_t)?

[Florian Weimer]

On 04/02/2015 10:40 AM, Andrew Haley wrote:

> So, max_align_t is an object type, and therefore malloc returns a
> pointer suitable for max_align_t.

Then the GCC definition of max_align_t is incorrect, it should be 8 on
x86_64 GNU/Linux, because traditionally, that's what mallocs implement
for this architecture.  (dlmalloc in glibc is an exception.)

-- 
Florian Weimer / Red Hat Product Security

Re: x86_64: Should the -mavx* options affected __alignof__ (max_align_t)?

[Andrew Haley]

On 04/02/2015 09:46 AM, Florian Weimer wrote:
> On 04/02/2015 10:40 AM, Andrew Haley wrote:
> 
>> So, max_align_t is an object type, and therefore malloc returns a
>> pointer suitable for max_align_t.
> 
> Then the GCC definition of max_align_t is incorrect, it should be 8 on
> x86_64 GNU/Linux, because traditionally, that's what mallocs implement
> for this architecture.  (dlmalloc in glibc is an exception.)

Or the libcs are wrong; one or the other.

Andrew.

Combine changes ASHIFT into mult for non-MEM rtx

[Bin.Cheng]

Hi,
In function make_compound_operation, the code/comment says:

case ASHIFT:
  /* Convert shifts by constants into multiplications if inside
 an address.  */
  if (in_code == MEM && CONST_INT_P (XEXP (x, 1))
  && INTVAL (XEXP (x, 1)) < HOST_BITS_PER_WIDE_INT
  && INTVAL (XEXP (x, 1)) >= 0
  && SCALAR_INT_MODE_P (mode))
{


Right now, it changes ASHIFT in any SET into mult because of below code:

  /* Select the code to be used in recursive calls.  Once we are inside an
 address, we stay there.  If we have a comparison, set to COMPARE,
 but once inside, go back to our default of SET.  */

  next_code = (code == MEM ? MEM
   : ((code == PLUS || code == MINUS)
  && SCALAR_INT_MODE_P (mode)) ? MEM // 

Re: Combine changes ASHIFT into mult for non-MEM rtx

[Kugan]

On 02/04/15 20:39, Bin.Cheng wrote:
> Hi,
> In function make_compound_operation, the code/comment says:
> 
> case ASHIFT:
>   /* Convert shifts by constants into multiplications if inside
>  an address.  */
>   if (in_code == MEM && CONST_INT_P (XEXP (x, 1))
>   && INTVAL (XEXP (x, 1)) < HOST_BITS_PER_WIDE_INT
>   && INTVAL (XEXP (x, 1)) >= 0
>   && SCALAR_INT_MODE_P (mode))
> {
> 
> 
> Right now, it changes ASHIFT in any SET into mult because of below code:
> 
>   /* Select the code to be used in recursive calls.  Once we are inside an
>  address, we stay there.  If we have a comparison, set to COMPARE,
>  but once inside, go back to our default of SET.  */
> 
>   next_code = (code == MEM ? MEM
>: ((code == PLUS || code == MINUS)
>   && SCALAR_INT_MODE_P (mode)) ? MEM // : ((code == COMPARE || COMPARISON_P (x))
>   && XEXP (x, 1) == const0_rtx) ? COMPARE
>: in_code == COMPARE ? SET : in_code);
> 
> This seems an overlook to me.  The effect is all targets have to
> support the generated expression in the corresponding pattern.  Some
> times the generated expression is just too stupid and missed.  For
> example below insn is tried by combine:
> (set (reg:SI 79 [ D.2709 ])
> (plus:SI (subreg:SI (sign_extract:DI (mult:DI (reg:DI 1 x1 [ i ])
> (const_int 2 [0x2]))
> (const_int 17 [0x11])
> (const_int 0 [0])) 0)
> (reg:SI 0 x0 [ a ])))
> 
> 
> It actually equals to
> (set (reg/i:SI 0 x0)
> (plus:SI (ashift:SI (sign_extend:SI (reg:HI 1 x1 [ i ]))
> (const_int 1 [0x1]))
> (reg:SI 0 x0 [ a ])))
> 
> equals to below instruction on AARCH64:
> addw0, w0, w1, sxth 1
> 
> 
> Because of the existing comment, also because it will make backend
> easier (I suppose), is it reasonable to fix this behavior in
> combine.c?  Another question is, if we are going to make the change,
> how many targets might be affected?
> 

I think https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01020.html is
related to this.


Thanks,
kugan

Re: Combine changes ASHIFT into mult for non-MEM rtx

[Bin.Cheng]

On Thu, Apr 2, 2015 at 5:49 PM, Kugan  wrote:
> On 02/04/15 20:39, Bin.Cheng wrote:
>> Hi,
>> In function make_compound_operation, the code/comment says:
>>
>> case ASHIFT:
>>   /* Convert shifts by constants into multiplications if inside
>>  an address.  */
>>   if (in_code == MEM && CONST_INT_P (XEXP (x, 1))
>>   && INTVAL (XEXP (x, 1)) < HOST_BITS_PER_WIDE_INT
>>   && INTVAL (XEXP (x, 1)) >= 0
>>   && SCALAR_INT_MODE_P (mode))
>> {
>>
>>
>> Right now, it changes ASHIFT in any SET into mult because of below code:
>>
>>   /* Select the code to be used in recursive calls.  Once we are inside an
>>  address, we stay there.  If we have a comparison, set to COMPARE,
>>  but once inside, go back to our default of SET.  */
>>
>>   next_code = (code == MEM ? MEM
>>: ((code == PLUS || code == MINUS)
>>   && SCALAR_INT_MODE_P (mode)) ? MEM // >: ((code == COMPARE || COMPARISON_P (x))
>>   && XEXP (x, 1) == const0_rtx) ? COMPARE
>>: in_code == COMPARE ? SET : in_code);
>>
>> This seems an overlook to me.  The effect is all targets have to
>> support the generated expression in the corresponding pattern.  Some
>> times the generated expression is just too stupid and missed.  For
>> example below insn is tried by combine:
>> (set (reg:SI 79 [ D.2709 ])
>> (plus:SI (subreg:SI (sign_extract:DI (mult:DI (reg:DI 1 x1 [ i ])
>> (const_int 2 [0x2]))
>> (const_int 17 [0x11])
>> (const_int 0 [0])) 0)
>> (reg:SI 0 x0 [ a ])))
>>
>>
>> It actually equals to
>> (set (reg/i:SI 0 x0)
>> (plus:SI (ashift:SI (sign_extend:SI (reg:HI 1 x1 [ i ]))
>> (const_int 1 [0x1]))
>> (reg:SI 0 x0 [ a ])))
>>
>> equals to below instruction on AARCH64:
>> addw0, w0, w1, sxth 1
>>
>>
>> Because of the existing comment, also because it will make backend
>> easier (I suppose), is it reasonable to fix this behavior in
>> combine.c?  Another question is, if we are going to make the change,
>> how many targets might be affected?
>>
>
> I think https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01020.html is
> related to this.

Hi Kugan,
Thanks for pointing me to this.  Actually it's exactly the same case I
am looking.
Glad to know that somebody else is looking after it, only that message
isn't followed up recently :(

Thanks,
bin

>
>
> Thanks,
> kugan

Re: x86_64: Should the -mavx* options affected __alignof__ (max_align_t)?

[H.J. Lu]

On Thu, Apr 2, 2015 at 1:46 AM, Florian Weimer  wrote:
> On 04/02/2015 10:40 AM, Andrew Haley wrote:
>
>> So, max_align_t is an object type, and therefore malloc returns a
>> pointer suitable for max_align_t.
>
> Then the GCC definition of max_align_t is incorrect, it should be 8 on
> x86_64 GNU/Linux, because traditionally, that's what mallocs implement
> for this architecture.  (dlmalloc in glibc is an exception.)
>

x86-64 psABI specifies that a memory >= 16 bytes is 16-byte aligned.
If malloc doesn't do it, it is a broken.


-- 
H.J.

Re: x86_64: Should the -mavx* options affected __alignof__ (max_align_t)?

[Florian Weimer]

On 04/02/2015 01:06 PM, H.J. Lu wrote:
> On Thu, Apr 2, 2015 at 1:46 AM, Florian Weimer  wrote:
>> On 04/02/2015 10:40 AM, Andrew Haley wrote:
>>
>>> So, max_align_t is an object type, and therefore malloc returns a
>>> pointer suitable for max_align_t.
>>
>> Then the GCC definition of max_align_t is incorrect, it should be 8 on
>> x86_64 GNU/Linux, because traditionally, that's what mallocs implement
>> for this architecture.  (dlmalloc in glibc is an exception.)
>>
> 
> x86-64 psABI specifies that a memory >= 16 bytes is 16-byte aligned.
> If malloc doesn't do it, it is a broken.

My concern is different.  I think _Alignof (max_align_t) == 16 (as it is
in GCC now) implies that malloc return values for sizes less than 16
bytes are 16-byte-aligned, too, which is not required by the x86-64 psABI.

-- 
Florian Weimer / Red Hat Product Security

Re: x86_64: Should the -mavx* options affected __alignof__ (max_align_t)?

[H.J. Lu]

On Thu, Apr 2, 2015 at 4:08 AM, Florian Weimer  wrote:
> On 04/02/2015 01:06 PM, H.J. Lu wrote:
>> On Thu, Apr 2, 2015 at 1:46 AM, Florian Weimer  wrote:
>>> On 04/02/2015 10:40 AM, Andrew Haley wrote:
>>>
 So, max_align_t is an object type, and therefore malloc returns a
 pointer suitable for max_align_t.
>>>
>>> Then the GCC definition of max_align_t is incorrect, it should be 8 on
>>> x86_64 GNU/Linux, because traditionally, that's what mallocs implement
>>> for this architecture.  (dlmalloc in glibc is an exception.)
>>>
>>
>> x86-64 psABI specifies that a memory >= 16 bytes is 16-byte aligned.
>> If malloc doesn't do it, it is a broken.
>
> My concern is different.  I think _Alignof (max_align_t) == 16 (as it is
> in GCC now) implies that malloc return values for sizes less than 16
> bytes are 16-byte-aligned, too, which is not required by the x86-64 psABI.
>

If you take this way, malloc of 1 byte can return 1-byte aligned memory.

-- 
H.J.

Re: x86_64: Should the -mavx* options affected __alignof__ (max_align_t)?

[Florian Weimer]

On 04/02/2015 01:13 PM, H.J. Lu wrote:
> On Thu, Apr 2, 2015 at 4:08 AM, Florian Weimer  wrote:
>> On 04/02/2015 01:06 PM, H.J. Lu wrote:
>>> On Thu, Apr 2, 2015 at 1:46 AM, Florian Weimer  wrote:
 On 04/02/2015 10:40 AM, Andrew Haley wrote:

> So, max_align_t is an object type, and therefore malloc returns a
> pointer suitable for max_align_t.

 Then the GCC definition of max_align_t is incorrect, it should be 8 on
 x86_64 GNU/Linux, because traditionally, that's what mallocs implement
 for this architecture.  (dlmalloc in glibc is an exception.)

>>>
>>> x86-64 psABI specifies that a memory >= 16 bytes is 16-byte aligned.
>>> If malloc doesn't do it, it is a broken.
>>
>> My concern is different.  I think _Alignof (max_align_t) == 16 (as it is
>> in GCC now) implies that malloc return values for sizes less than 16
>> bytes are 16-byte-aligned, too, which is not required by the x86-64 psABI.
>>
> 
> If you take this way, malloc of 1 byte can return 1-byte aligned memory.

If this is the case, is this code valid?

  struct S {
char a __attribute__ ((aligned (__alignof__ (max_align_t;
  };

  struct S *p = malloc (sizeof (struct S));

-- 
Florian Weimer / Red Hat Product Security

Re: x86_64: Should the -mavx* options affected __alignof__ (max_align_t)?

[H.J. Lu]

On Thu, Apr 2, 2015 at 4:17 AM, Florian Weimer  wrote:
> On 04/02/2015 01:13 PM, H.J. Lu wrote:
>> On Thu, Apr 2, 2015 at 4:08 AM, Florian Weimer  wrote:
>>> On 04/02/2015 01:06 PM, H.J. Lu wrote:
 On Thu, Apr 2, 2015 at 1:46 AM, Florian Weimer  wrote:
> On 04/02/2015 10:40 AM, Andrew Haley wrote:
>
>> So, max_align_t is an object type, and therefore malloc returns a
>> pointer suitable for max_align_t.
>
> Then the GCC definition of max_align_t is incorrect, it should be 8 on
> x86_64 GNU/Linux, because traditionally, that's what mallocs implement
> for this architecture.  (dlmalloc in glibc is an exception.)
>

 x86-64 psABI specifies that a memory >= 16 bytes is 16-byte aligned.
 If malloc doesn't do it, it is a broken.
>>>
>>> My concern is different.  I think _Alignof (max_align_t) == 16 (as it is
>>> in GCC now) implies that malloc return values for sizes less than 16
>>> bytes are 16-byte-aligned, too, which is not required by the x86-64 psABI.
>>>
>>
>> If you take this way, malloc of 1 byte can return 1-byte aligned memory.
>
> If this is the case, is this code valid?
>
>   struct S {
> char a __attribute__ ((aligned (__alignof__ (max_align_t;
>   };
>
>   struct S *p = malloc (sizeof (struct S));
>

2 bugs related to MALLOC_ABI_ALIGNMENT:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56726
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36159

-- 
H.J.

Re: x86_64: Should the -mavx* options affected __alignof__ (max_align_t)?

[Joseph Myers]

On Thu, 2 Apr 2015, Florian Weimer wrote:

> On 04/02/2015 01:06 PM, H.J. Lu wrote:
> > On Thu, Apr 2, 2015 at 1:46 AM, Florian Weimer  wrote:
> >> On 04/02/2015 10:40 AM, Andrew Haley wrote:
> >>
> >>> So, max_align_t is an object type, and therefore malloc returns a
> >>> pointer suitable for max_align_t.
> >>
> >> Then the GCC definition of max_align_t is incorrect, it should be 8 on
> >> x86_64 GNU/Linux, because traditionally, that's what mallocs implement
> >> for this architecture.  (dlmalloc in glibc is an exception.)
> >>
> > 
> > x86-64 psABI specifies that a memory >= 16 bytes is 16-byte aligned.
> > If malloc doesn't do it, it is a broken.
> 
> My concern is different.  I think _Alignof (max_align_t) == 16 (as it is
> in GCC now) implies that malloc return values for sizes less than 16
> bytes are 16-byte-aligned, too, which is not required by the x86-64 psABI.

Right back to C90 (DR#075), malloc of any size has been required to return 
a pointer suitably aligned for all types that can be defined in C90 (such 
as long double).  ABIs can only be understood in conjunction with the 
language standard requirements.  If malloc fails to return memory suitably 
aligned for long double, that's a malloc bug.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: x86_64: Should the -mavx* options affected __alignof__ (max_align_t)?

[Florian Weimer]

On 04/02/2015 01:34 PM, Joseph Myers wrote:
> On Thu, 2 Apr 2015, Florian Weimer wrote:
> 
>> On 04/02/2015 01:06 PM, H.J. Lu wrote:
>>> On Thu, Apr 2, 2015 at 1:46 AM, Florian Weimer  wrote:
 On 04/02/2015 10:40 AM, Andrew Haley wrote:

> So, max_align_t is an object type, and therefore malloc returns a
> pointer suitable for max_align_t.

 Then the GCC definition of max_align_t is incorrect, it should be 8 on
 x86_64 GNU/Linux, because traditionally, that's what mallocs implement
 for this architecture.  (dlmalloc in glibc is an exception.)

>>>
>>> x86-64 psABI specifies that a memory >= 16 bytes is 16-byte aligned.
>>> If malloc doesn't do it, it is a broken.
>>
>> My concern is different.  I think _Alignof (max_align_t) == 16 (as it is
>> in GCC now) implies that malloc return values for sizes less than 16
>> bytes are 16-byte-aligned, too, which is not required by the x86-64 psABI.
> 
> Right back to C90 (DR#075), malloc of any size has been required to return 
> a pointer suitably aligned for all types that can be defined in C90 (such 
> as long double).  ABIs can only be understood in conjunction with the 
> language standard requirements.  If malloc fails to return memory suitably 
> aligned for long double, that's a malloc bug.

sizeof (long double) is 16 on x86_64, and malloc (16) is 16-byte-aligned
with jemalloc and tcmalloc.  This means that there is no problem in
practice.

But it is dubious to require that, say, strdup ("example") returns a
pointer which is 16-byte-aligned, too.

What is missing, it seems to me, is the qualification that for the
pointer returned by malloc, the alignment requirements only of those
types whose size does not exceed the malloc argument argument need to be
considered.

-- 
Florian Weimer / Red Hat Product Security

Re: x86_64: Should the -mavx* options affected __alignof__ (max_align_t)?

[Jakub Jelinek]

On Thu, Apr 02, 2015 at 01:43:28PM +0200, Florian Weimer wrote:
> But it is dubious to require that, say, strdup ("example") returns a
> pointer which is 16-byte-aligned, too.
> 
> What is missing, it seems to me, is the qualification that for the
> pointer returned by malloc, the alignment requirements only of those
> types whose size does not exceed the malloc argument argument need to be
> considered.

Why?  The standard requires that it is aligned even for the smaller sizes, and
glibc malloc honors that.  Why do you want to change it all of sudden?

Jakub

Re: Combine changes ASHIFT into mult for non-MEM rtx

[Jeff Law]

On 04/02/2015 03:39 AM, Bin.Cheng wrote:

Hi,
In function make_compound_operation, the code/comment says:

 case ASHIFT:
   /* Convert shifts by constants into multiplications if inside
  an address.  */
   if (in_code == MEM && CONST_INT_P (XEXP (x, 1))
   && INTVAL (XEXP (x, 1)) < HOST_BITS_PER_WIDE_INT
   && INTVAL (XEXP (x, 1)) >= 0
   && SCALAR_INT_MODE_P (mode))
 {


Right now, it changes ASHIFT in any SET into mult because of below code:

   /* Select the code to be used in recursive calls.  Once we are inside an
  address, we stay there.  If we have a comparison, set to COMPARE,
  but once inside, go back to our default of SET.  */

   next_code = (code == MEM ? MEM
: ((code == PLUS || code == MINUS)
   && SCALAR_INT_MODE_P (mode)) ? MEM // 

Re: x86_64: Should the -mavx* options affected __alignof__ (max_align_t)?

[Andrew Haley]

On 04/02/2015 12:43 PM, Florian Weimer wrote:
> 
> But it is dubious to require that, say, strdup ("example") returns a
> pointer which is 16-byte-aligned, too.
> 
> What is missing, it seems to me, is the qualification that for the
> pointer returned by malloc, the alignment requirements only of those
> types whose size does not exceed the malloc argument argument need to be
> considered.

I'm trying to guess how you'd write a strictly-conforming program that
could tell the difference.  (Casting to an integer and looking at the
low-order bits doesn't count because the mapping from a pointer to an
integer is not well-defined.)

Andrew.

Re: x86_64: Should the -mavx* options affected __alignof__ (max_align_t)?

[Michael Matz]

Hi,

On Thu, 2 Apr 2015, Jakub Jelinek wrote:

> > But it is dubious to require that, say, strdup ("example") returns a 
> > pointer which is 16-byte-aligned, too.
> > 
> > What is missing, it seems to me, is the qualification that for the 
> > pointer returned by malloc, the alignment requirements only of those 
> > types whose size does not exceed the malloc argument argument need to 
> > be considered.
> 
> Why?  The standard requires that it is aligned even for the smaller 
> sizes, and glibc malloc honors that.  Why do you want to change it all 
> of sudden?

Because it would increase waste even more when going from align-8 
to align-16 even for allocations for less than 8 byte.


Ciao,
Michael.

Re: String literals in __init functions

[Joseph Myers]

On Thu, 26 Mar 2015, Joe Perches wrote:

> > I'd have thought that a function-wide
> > __attribute__((__string_section__(foo))
> > wouldn't be a ton of work to implement.
> 
> Maybe not.
> 
> Could some future version of gcc move string constants
> in a function to a specific section marked in a manner
> similar to what Andrew described above?

Putting string constants in a special section is an old project idea at 
.
  
I still think support for that would make sense.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: String literals in __init functions

[Joe Perches]

On Thu, 2015-04-02 at 16:00 +, Joseph Myers wrote:
> On Thu, 26 Mar 2015, Joe Perches wrote:
> > > I'd have thought that a function-wide
> > >   __attribute__((__string_section__(foo))
> > > wouldn't be a ton of work to implement.
> > 
> > Maybe not.
> > 
> > Could some future version of gcc move string constants
> > in a function to a specific section marked in a manner
> > similar to what Andrew described above?
> 
> Putting string constants in a special section is an old project idea at 
> .
>   

That's news to me.  Thanks for the link.

> I still think support for that would make sense.

That's good to know.

Do you know of a mechanism in place to prioritize
development for these optimization projects or is
this a placeholder for unscheduled or unresourced
TODOs?

Re: Selecting an architecture tuple for the Rumprun toolchain

[Joseph Myers]

On Mon, 30 Mar 2015, Martin Lucina wrote:

> Regarding future possibilities, the Rump Kernel/anykernel concept is
> applicable to other operating system kernels, not just NetBSD. So, say
> someone does the work to use the Linux kernel as an anykernel, we could
> then provide a Linux "userspace". This would give us the following example
> future combinations:
> 
> x86_64-rumprun-xen-linux (Rumprun, on x86_64 ISA, running a Linux Rump
> Kernel on Xen)
> aarch64-rumprun-baremetal-linux (Rumprun, on AARCH64 ISA, running a Linux
> Rump Kernel on bare metal)
> 
> Is this the right way to go, now and in the future?

The concept of a Linux userspace does not make sense; Linux is a kernel.

By Linux userspace, do you mean that the C library used provides 
interfaces to Linux-specific syscalls such as inotify and signalfd, and 
the headers provide Linux-specific ioctls, and those syscalls and ioctls 
work at runtime, and that the headers include the uapi headers exported by 
the Linux kernel?

If existing binaries built for the existing Linux kernel with glibc 
userspace (existing glibc ports) would run in your environment, then the 
existing *-linux-gnu triplets should be used; tuples do not distinguish 
the possible use of an emulation environment in which to run code.

If you would use a different glibc port, but providing access to 
Linux-specific interfaces, then the tuple would be 
---gnu, much like *-*-kfreebsd-gnu describes a glibc 
port running on the FreeBSD kernel.

If you would use a different glibc port, would it be meaningful to do so 
both for Linux (however Linux is involved in your system) and for NetBSD?  
If so, it seems you have something like (but different from) 
*-*-linux-gnu, and something like (but different from) *-*-knetbsd-gnu - 
if both kernels affect the glibc port in some way, the kernel component of 
the triplet might need to include both kernel names, or else the OS 
component might need to contain one of them.  (I don't recommend treating 
the vendor component as semantically significant.)  Thus, you might have 
arm-*-linux-gnueabirumprun, or (if multiple rumprun variants each need 
their own tools / libc) arm-*-linux-gnueabirumprunxen.

If you would use a different glibc port, but that port does not provide 
any Linux-specific interfaces and is independent of the underlying kernel 
(if rumprun binaries are portable to all kernels that might be used), then 
--rumprun-gnu would be appropriate.

If you would use some other libc, then the -gnu component would not appear 
in the tuple at all (much like *-*-linux-uclibc for tools configured to 
use the Linux kernel with uClibc-based userspace).  Similar reasoning to 
the above can be applied to use of a non-GNU userspace providing access to 
Linux-specific kernel/userspace interfaces (syscalls, ioctls etc.).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: x86_64: Should the -mavx* options affected __alignof__ (max_align_t)?

[Joseph Myers]

On Thu, 2 Apr 2015, Florian Weimer wrote:

> On 03/23/2015 07:41 PM, Florian Weimer wrote:
> 
> > Ah, I should have looked at what max_align_t actually meant.  With these
> > semantics, the name is a bit confusing.  I agree that requiring 64 byte
> > alignment from malloc does not make much sense.  Thanks.
> 
> Follow-up question: Can malloc return a pointer which is not aligned to
> _Alignof (max_align_t)?
> 
> This happens with most mallocs on x86_64 for sizes of 8 or less, for
> which these mallocs only provide an alignment of 8.
> 
> DR445 does not seem to have reached consensus on that point.

I see no lack of consensus.  
 says 
"The proposed changes have raised no concerns and so the committee has 
agreed to use them as the following Proposed Technical Corrigendum.", and 
nothing regarding alignment for small allocations has changed since 
DR#075.  "suitably aligned so that it may be assigned to a pointer to any 
type of object with a fundamental alignment requirement" (unchanged 
wording in 7.22.3) implies being suitably aligned for all types with 
fundamental alignment requirements; otherwise such assignment would result 
in undefined behavior at runtime.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Question about Gimple FE

[Jeff Law]

On 03/31/2015 09:34 AM, Trevor Saunders wrote:

On Thu, Mar 26, 2015 at 03:15:22PM +0100, Richard Biener wrote:

On Thu, Mar 26, 2015 at 2:31 PM, xue yinsong  wrote:

I think the gimple front end project would be quite useful to gcc so I’d like 
to do work on it this summer.

The problem is, it seems the GIMPLE front end project hasn’t been active for 
some time
and Diego Novillo told me it may not even make sense to use the same codebase, 
but start from scratch.

I’m not sure if I should pick it up where it left off or write another one from 
scratch

Could you give me some advice?


I don't know the current codebase at all (unfortunately).  I think it
is useful to get yourself familiarized
with it even if you start from scratch as it will get you to learn
something about GIMPLE and about
writing a frontend.

Note that LTO support already is able to output everything needed to
re-create GIMPLE thus from
there you can also learn what is required to populate a GIMPLE
representation.  And LTO support
might be used to create output that can be read by the GIMPLE frontend
- the whole project
feels like finding a textual form of the LTO bytecode (in some way).


I think its part being able to convert LTO byte code to text, and part
refactoring byte code reading / writing such that we can do things like
read in byte code run a single pass and then dump the resulting byte
code.  I suppose in a sense you can probably already do that with lto1
and -r, but that's not exactly straight forward.
David has some code that allows creation of gimple on the fly and 
feeding it to a pass which is obviously designed with unit testing in mind.


Jeff

gcc-4.8-20150402 is now available

[gccadmin]

Snapshot gcc-4.8-20150402 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20150402/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch 
revision 221845

You'll find:

 gcc-4.8-20150402.tar.bz2 Complete GCC

  MD5=d41b37230d932e219a81e25d7a086ad1
  SHA1=5b0f70d6224f2ecf43fb84b1dfdd45095702a5d9

Diffs from 4.8-20150326 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.8
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.

Re: Combine changes ASHIFT into mult for non-MEM rtx

[Bin.Cheng]

On Thu, Apr 2, 2015 at 8:32 PM, Jeff Law  wrote:
> On 04/02/2015 03:39 AM, Bin.Cheng wrote:
>>
>> Hi,
>> In function make_compound_operation, the code/comment says:
>>
>>  case ASHIFT:
>>/* Convert shifts by constants into multiplications if inside
>>   an address.  */
>>if (in_code == MEM && CONST_INT_P (XEXP (x, 1))
>>&& INTVAL (XEXP (x, 1)) < HOST_BITS_PER_WIDE_INT
>>&& INTVAL (XEXP (x, 1)) >= 0
>>&& SCALAR_INT_MODE_P (mode))
>>  {
>>
>>
>> Right now, it changes ASHIFT in any SET into mult because of below code:
>>
>>/* Select the code to be used in recursive calls.  Once we are inside
>> an
>>   address, we stay there.  If we have a comparison, set to COMPARE,
>>   but once inside, go back to our default of SET.  */
>>
>>next_code = (code == MEM ? MEM
>> : ((code == PLUS || code == MINUS)
>>&& SCALAR_INT_MODE_P (mode)) ? MEM // > : ((code == COMPARE || COMPARISON_P (x))
>>&& XEXP (x, 1) == const0_rtx) ? COMPARE
>> : in_code == COMPARE ? SET : in_code);
>>
>> This seems an overlook to me.  The effect is all targets have to
>> support the generated expression in the corresponding pattern.  Some
>> times the generated expression is just too stupid and missed.  For
>> example below insn is tried by combine:
>> (set (reg:SI 79 [ D.2709 ])
>>  (plus:SI (subreg:SI (sign_extract:DI (mult:DI (reg:DI 1 x1 [ i ])
>>  (const_int 2 [0x2]))
>>  (const_int 17 [0x11])
>>  (const_int 0 [0])) 0)
>>  (reg:SI 0 x0 [ a ])))
>>
>>
>> It actually equals to
>> (set (reg/i:SI 0 x0)
>>  (plus:SI (ashift:SI (sign_extend:SI (reg:HI 1 x1 [ i ]))
>>  (const_int 1 [0x1]))
>>  (reg:SI 0 x0 [ a ])))
>>
>> equals to below instruction on AARCH64:
>> addw0, w0, w1, sxth 1
>>
>>
>> Because of the existing comment, also because it will make backend
>> easier (I suppose), is it reasonable to fix this behavior in
>> combine.c?  Another question is, if we are going to make the change,
>> how many targets might be affected?
>
> There's already a thread on this issue -- it's not a regression so I haven't
> pushed it forward and probably won't until stage1 reopens.
Indeed, Kugan pointed me to that thread.  Glad somebody else is
looking after the problem.

Thanks,
bin
>
> jeff

Re: Question about Gimple FE

[xue yinsong]

On 15/3/30 下午5:40, "Richard Biener"  wrote:

>On Mon, Mar 30, 2015 at 11:36 AM, Richard Biener
> wrote:
>> On Fri, Mar 27, 2015 at 4:00 PM, xue yinsong  wrote:
>>> Thanks for your reply to my proposal.
>>> AFAIS, most of the files generated by -fdump-tree-all are presented in 
>>> C-like form instead
>>> of in lisp-like tuple form.
>>> So it’s better to implement a front end for the C-like gimple 
>>> representations.
>>>
>>> I want to make sure if I get the idea right.
>>>
>>> Besides, I’m uncertain about the following questions:
>>> 1.I suppose the syntax of the original gimple file generated by 
>>> -fdump-tree-gimple would cover
>>> the syntax of those generated in later stages. Could some one tell me if 
>>> that’s correct?
>>
>> Well - in 004t.gimple there is still no CFG and we are not in SSA
>> form, so syntax of 'gimple'
>> would change slightly dependent on properties of the IL.  GCC goes to
>> various lowering stages
>> (also for things like OpenMP, nested function and exception handling 
>> support).
>
>Btw, I wouldn't necessarily try to parse exactly those dump format -
>streamlining it for
>easier parsing would be ok, especially for the basic-block markers.
>There was a request
>multiple times to make it easier to adjust a function cut&pasted from
>a dump produced
>by -fdump-tree to valid C (thus accepted by gcc).  One annoying
>road-block is how we
>dump labels and goto destinations.

I tried to compile some simple programs with -fdump-treep-all and 
read some of the dumped files. I have the following comments. 
If I said something wrong please correct me. 


I suppose our goal is to translate the dumped program back to 
the C source code (otherwise we can simply retain the gotos and 
labels since they are already `valid’ in C). In this case we have to 
convert the gotos back to if-elses and whiles. As long as 
CFG informations are given, it’s possible to get rid of these gotos.
 
 Apart from this, Gimple and C also have some differences 
in PHI nodes and exception handling code. They also need to be 
converted back to corresponding C syntax.

—
Yinsong


>
>>> 2.On my computer, it seems both -fdump-tree-gimple and 
>>> -fdump-tree-gimple-raw dump the code to .004t.gimple.
>>> tf -fdump-tree-all is used, only the result of -fdump-tree-gimple will be 
>>> presented.
>>> Does gcc behave this way on purpose?
>>
>> I think so.  -raw is a dump modifier while -all selects '-gimple' and
>> all others.
>>
>> Richard.
>>
>>>
>>>
>>>
>>> ——
>>> Best regards,
>>> Yinsong Xue
>>>