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 i
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
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
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 se
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.
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". Th
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 mo
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
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
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 t
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,
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 require
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 therefor
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
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
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 the
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
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
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/Li
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
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
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 (XE
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, be
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 thi
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.
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 poi
26 matches
Mail list logo
