On Mon, Nov 27, 2017 at 10:41:42AM -0500, David Malcolm wrote:
> On Sun, 2017-11-26 at 01:11 +0100, Gerald Pfeifer wrote:
> > On Mon, 20 Nov 2017, Marc Glisse wrote:
> > > new version, regtested on powerpc64le-unknown-linux-gnu. The front-
> > > end
> > > parts are up for review.
> > >
> > >
On Sun, 2017-11-26 at 01:11 +0100, Gerald Pfeifer wrote:
> On Mon, 20 Nov 2017, Marc Glisse wrote:
> > new version, regtested on powerpc64le-unknown-linux-gnu. The front-
> > end
> > parts are up for review.
> >
> > 2017-10-28 Marc Glisse
> >
> > gcc/c/
> > *
On Mon, 20 Nov 2017, Marc Glisse wrote:
new version, regtested on powerpc64le-unknown-linux-gnu. The front-end
parts are up for review.
2017-10-28 Marc Glisse
gcc/c/
* c-fold.c (c_fully_fold_internal): Handle POINTER_DIFF_EXPR.
* c-typeck.c
On 22 November 2017 at 09:29, Marc Glisse wrote:
> On Wed, 22 Nov 2017, Marc Glisse wrote:
>
>> On Wed, 22 Nov 2017, Christophe Lyon wrote:
>>
>>> Since you committed this patch (r255021), my cross-builds of GCC for
>>> aarch64-linux-gnu fail while building glibc:
>>>
>>>
On Wed, 22 Nov 2017, Marc Glisse wrote:
On Wed, 22 Nov 2017, Christophe Lyon wrote:
Since you committed this patch (r255021), my cross-builds of GCC for
aarch64-linux-gnu fail while building glibc:
/tmp/6857183_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/bin/aarch64-none-linux-gnu-gcc
On Wed, 22 Nov 2017, Christophe Lyon wrote:
Since you committed this patch (r255021), my cross-builds of GCC for
aarch64-linux-gnu fail while building glibc:
/tmp/6857183_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/bin/aarch64-none-linux-gnu-gcc
fetch-value.c -c -std=gnu99 -fgnu89-inline
Hi Marc,
On 20 November 2017 at 00:54, Marc Glisse wrote:
> Hello,
>
> new version, regtested on powerpc64le-unknown-linux-gnu. The front-end parts
> are up for review.
>
> 2017-10-28 Marc Glisse
>
> gcc/c/
> * c-fold.c
On 11/19/2017 04:54 PM, Marc Glisse wrote:
> Hello,
>
> new version, regtested on powerpc64le-unknown-linux-gnu. The front-end
> parts are up for review.
>
> 2017-10-28 Marc Glisse
>
> gcc/c/
> * c-fold.c (c_fully_fold_internal): Handle POINTER_DIFF_EXPR.
> *
On Sun, Nov 19, 2017 at 6:54 PM, Marc Glisse wrote:
> new version, regtested on powerpc64le-unknown-linux-gnu. The front-end parts
> are up for review.
The C++ changes are OK.
Jason
Hello,
new version, regtested on powerpc64le-unknown-linux-gnu. The front-end
parts are up for review.
2017-10-28 Marc Glisse
gcc/c/
* c-fold.c (c_fully_fold_internal): Handle POINTER_DIFF_EXPR.
* c-typeck.c (pointer_diff): Use POINTER_DIFF_EXPR.
On November 18, 2017 11:20:42 AM GMT+01:00, Marc Glisse
wrote:
>On Fri, 17 Nov 2017, Richard Biener wrote:
>
>> On Sat, Nov 11, 2017 at 12:44 AM, Marc Glisse
>wrote:
>>
>>> The exact undefined-behavior status should probably be clarified
>more.
>>>
On Fri, 17 Nov 2017, Joseph Myers wrote:
On Fri, 17 Nov 2017, DJ Delorie wrote:
Richard Biener writes:
The question is what ptrdiff_t is for a specific address space. Or
rather if that type may be dependent on the address space or if we can
always use that of the
On Fri, 17 Nov 2017, Richard Biener wrote:
On Sat, Nov 11, 2017 at 12:44 AM, Marc Glisse wrote:
The exact undefined-behavior status should probably be clarified more.
First, I'd like to say that POINTER_DIFF_EXPR may only take 2 pointers into
the same "object" (like in
On Fri, 17 Nov 2017, DJ Delorie wrote:
Richard Biener writes:
The question is what ptrdiff_t is for a specific address space. Or
rather if that type may be dependent on the address space or if we can
always use that of the default address space.
Some targets
On Fri, 17 Nov 2017, Jason Merrill wrote:
It's not clear to me that cp_build_binary_op needs to handle
POINTER_DIFF_EXPR, it should get MINUS_EXPR and produce
POINTER_DIFF_EXPR.
Indeed, I added POINTER_DIFF_EXPR in many places by looking for
MINUS_EXPR, but this one is useless, regtesting
On Fri, 17 Nov 2017, DJ Delorie wrote:
> Richard Biener writes:
> > The question is what ptrdiff_t is for a specific address space. Or
> > rather if that type may be dependent on the address space or if we can
> > always use that of the default address space.
>
>
On Fri, 17 Nov 2017, Richard Biener wrote:
> The question is what ptrdiff_t is for a specific address space. Or
> rather if that type may be dependent on the address space or if we can
> always use that of the default address space.
ptrdiff_t is a fixed type which does not depend on the
Richard Biener writes:
> The question is what ptrdiff_t is for a specific address space. Or
> rather if that type may be dependent on the address space or if we can
> always use that of the default address space.
Some targets have a "far" address space that's bigger
On November 17, 2017 6:20:22 PM GMT+01:00, Joseph Myers
wrote:
>On Fri, 17 Nov 2017, Richard Biener wrote:
>
>> Joseph may have an idea about the address-space issue.
>
>I'm not clear what the question is. The TR 18037 rule on subtractions
>with address spaces is "For
On Fri, 17 Nov 2017, Richard Biener wrote:
> Joseph may have an idea about the address-space issue.
I'm not clear what the question is. The TR 18037 rule on subtractions
with address spaces is "For subtraction, if the two operands are pointers
into different address spaces, the address spaces
On Fri, Nov 17, 2017 at 7:56 AM, Richard Biener
wrote:
> On Sat, Nov 11, 2017 at 12:44 AM, Marc Glisse wrote:
>> Adding some random cc: to people who might be affected. Hopefully I am not
>> breaking any of your stuff...
>>
>> Ulrich Weigand
On Sat, Nov 11, 2017 at 12:44 AM, Marc Glisse wrote:
> Adding some random cc: to people who might be affected. Hopefully I am not
> breaking any of your stuff...
>
> Ulrich Weigand (address space)
> Ilya Enkovich (pointer bound check)
> DJ Delorie (target with 24-bit partial
Adding some random cc: to people who might be affected. Hopefully I am not
breaking any of your stuff...
Ulrich Weigand (address space)
Ilya Enkovich (pointer bound check)
DJ Delorie (target with 24-bit partial mode pointer)
If you want to give it a try, or just take a quick look to check that
Hello,
first, if you are doing anything unusual with pointers (address spaces,
pointer/sizetype with weird sizes, instrumentation, etc), it would be
great if you could give this patch a try. It was bootstrapped and
regtested on powerpc64le-unknown-linux-gnu (gcc112), and a slightly older
24 matches
Mail list logo