On Wed, Feb 25, 2015 at 7:43 AM, Martin Jambor wrote:
> Hi Eric and Richard,
>
> On Tue, Jan 06, 2015 at 06:07:12PM +0100, Eric Botcazou wrote:
>> Martin,
>>
>> > I suppose that could be done by something like the following, which I
>> > have tested only very mildly so far, in particular I have no
> for various reasons I was not able to do it earlier, but today I have
> re-bootstrapped the following (the only change is the added testcase)
> on x86_64-linux and it passes OK. Should I commit it to trunk then?
Yes, that would be kind of you, thanks in advance.
--
Eric Botcazou
Hi Eric and Richard,
On Tue, Jan 06, 2015 at 06:07:12PM +0100, Eric Botcazou wrote:
> Martin,
>
> > I suppose that could be done by something like the following, which I
> > have tested only very mildly so far, in particular I have not double
> > checked that get_inner_reference is cfun-agnostic.
Martin,
> I suppose that could be done by something like the following, which I
> have tested only very mildly so far, in particular I have not double
> checked that get_inner_reference is cfun-agnostic.
The patch introduces no regressions on x86-64/Linux and makes the testcase
(gnat.dg/specs/pa
> Well, I call it a convenience that MEM_EXPR, unlike INDIRECT_REF, can
> be used to encapsulate an arbitrary byte-offset and view-conversion. Of
> course it's still a dereference of an address so that convenience doesn't
> work on sth non-addressable.
No discussion on the merits of MEM_EXPR vs I
On Thu, Dec 11, 2014 at 10:52 PM, Eric Botcazou wrote:
>> Note that I think the place of the check is unfortunate as you for example
>> will not remove the argument if it is unused. In fact I'm not yet sure
>> what transform exactly we are disabling. I am guessing we are
>> passing an aggregate
> Note that I think the place of the check is unfortunate as you for example
> will not remove the argument if it is unused. In fact I'm not yet sure
> what transform exactly we are disabling. I am guessing we are
> passing an aggregate by value that resides at a bit-aligned offset
> of some oute
On Wed, Dec 3, 2014 at 3:02 PM, Martin Jambor wrote:
> Hi,
>
> On Mon, Dec 01, 2014 at 12:00:14PM +0100, Richard Biener wrote:
>> On Fri, Nov 28, 2014 at 5:20 PM, Eric Botcazou wrote:
>> > Hi,
>> >
>> > the attached Ada testcase triggers an assertion in the RTL expander for the
>> > address opera
> I suppose that could be done by something like the following, which I
> have tested only very mildly so far, in particular I have not double
> checked that get_inner_reference is cfun-agnostic.
Thanks, this works fine on the testcase and I believe that get_inner_reference
is indeed cfun-agnosti
Hi,
On Mon, Dec 01, 2014 at 12:00:14PM +0100, Richard Biener wrote:
> On Fri, Nov 28, 2014 at 5:20 PM, Eric Botcazou wrote:
> > Hi,
> >
> > the attached Ada testcase triggers an assertion in the RTL expander for the
> > address operator because the operator has been applied to a non-byte-aligned
On Fri, Nov 28, 2014 at 5:20 PM, Eric Botcazou wrote:
> Hi,
>
> the attached Ada testcase triggers an assertion in the RTL expander for the
> address operator because the operator has been applied to a non-byte-aligned
> record field. The problematic ADDR_EXPR is built by ipa_modify_call_argument
Hi,
the attached Ada testcase triggers an assertion in the RTL expander for the
address operator because the operator has been applied to a non-byte-aligned
record field. The problematic ADDR_EXPR is built by ipa_modify_call_arguments
which has a hole when get_addr_base_and_unit_offset return
12 matches
Mail list logo
