On 7 January 2016 at 13:36, Jonathan Wakely wrote:
> On 7 January 2016 at 13:14, Jonathan Wakely wrote:
>> On 6 January 2016 at 21:05, Jonathan Wakely wrote:
>>> I have been meaning to try solving it in libstdc++ with a new
>>> that includes the libc one and extends it, to see how well that works.
On Fri, 2016-01-08 at 12:56 +0100, Richard Biener wrote:
> On Fri, Jan 8, 2016 at 12:40 PM, Eric Botcazou
> wrote:
> >> I think we only assume it if the pointer is actually dereferenced,
> >> otherwise
> >> it just breaks too much code in the wild. And while memcpy dereferences,
> >> it derefer
On Fri, Jan 08, 2016 at 03:28:53PM +, paul_kon...@dell.com wrote:
> If it really is necessary to say that memcpy is defined to behave as if it
> had a cast to char* in its implementation, it would still be useful -- and
> obviously valid -- to rely on the greater alignment when there is other
> On Jan 8, 2016, at 6:32 AM, Jakub Jelinek wrote:
>
> On Fri, Jan 08, 2016 at 12:24:49PM +0100, Eric Botcazou wrote:
>>> See some existing PR. The GCC middle-end cannot assume that pointers
>>> are aligned according to their type (while at least the C language would
>>> support that notion).
>
On Tues, Oct 27, 2015 at 2:39 PM, Richard Biener
wrote:
On Mon, Oct 26, 2015 at 6:59 AM, sameera wrote:
Richard, we have defined the input language for convenience in prototype
implementation. However, we will be using GIMPLE as our IR. As per grammar
of our tree, p-tree denote the permute o
On Fri, Jan 08, 2016 at 02:36:32PM +0900, AKASHI Takahiro wrote:
> On 01/07/2016 11:56 PM, Richard Earnshaw (lists) wrote:
> >On 07/01/16 14:22, Will Deacon wrote:
> >>On Thu, Dec 24, 2015 at 04:57:54PM +0900, AKASHI Takahiro wrote:
> >>>So I'd like to introduce a function prologue analyzer to dete
On Fri, Jan 8, 2016 at 12:40 PM, Eric Botcazou wrote:
>> I think we only assume it if the pointer is actually dereferenced, otherwise
>> it just breaks too much code in the wild. And while memcpy dereferences,
>> it dereferences it through a char * cast, and thus only the minimum
>> alignment is
> I think we only assume it if the pointer is actually dereferenced, otherwise
> it just breaks too much code in the wild. And while memcpy dereferences,
> it dereferences it through a char * cast, and thus only the minimum
> alignment is assumed.
Yet the compiler was generating the expected code
On Fri, Jan 8, 2016 at 12:24 PM, Eric Botcazou wrote:
>> See some existing PR. The GCC middle-end cannot assume that pointers
>> are aligned according to their type (while at least the C language would
>> support that notion).
>
> Only on x86. It could (and used to) do it on strict-alignment arc
On Fri, Jan 08, 2016 at 12:24:49PM +0100, Eric Botcazou wrote:
> > See some existing PR. The GCC middle-end cannot assume that pointers
> > are aligned according to their type (while at least the C language would
> > support that notion).
>
> Only on x86. It could (and used to) do it on strict-a
> See some existing PR. The GCC middle-end cannot assume that pointers
> are aligned according to their type (while at least the C language would
> support that notion).
Only on x86. It could (and used to) do it on strict-alignment architectures.
--
Eric Botcazou
On Thu, Jan 7, 2016 at 9:05 PM, Steve Ellcey wrote:
> I have a question about __builtin_memcpy and alignment. While working on
> MIPS I noticed that this program:
>
> void foo(int *a, int *b)
> {
> __builtin_memcpy (a, b, 8);
> }
>
> Is generating the following MIPS code (allowing for any
On Thu, Jan 7, 2016 at 7:41 PM, Toon Moene wrote:
> On 01/06/2016 07:46 PM, Toon Moene wrote:
>
>> Would it be possible to add an option -mveclibabi=glibc to cater for
>> this *for all languages*; or is this too low level (after all, the glibc
>> libmvec has code for multiple architectures). If so
On Wed, Jan 6, 2016 at 4:26 PM, Jeff Law wrote:
> On 01/06/2016 08:17 AM, Ian Lance Taylor wrote:
>>
>> The bug report https://golang.org/issue/13662 describes a case in
>> which ivopts appears to be breaking garbage collection for the Go
>> compiler. There is an array allocated in memory, and th
On Thu, Dec 24, 2015 at 3:40 PM, Gary Funck wrote:
>
> Currently, the default optimization level when building,
> bootstrapping GCC is -O2.
>
> We routinely build with --with-build-config='bootstrap-debug bootstrap-O3'
> because we want to verify that our UPC changes don't affect the
> compiler wh
15 matches
Mail list logo
