Hi Eric,
On Wed, 14 May 2014 09:28:55, Eric Botcazou wrote:
>
>>> So does this remove the last concern around Bernd's patch?
>>
>> And can we remove TYPE_ALIGN_OK as followup? (ISTR it's used
>> by obj-c/c++ as well, but I can't find such use)
>
> Probably but, as previously indicated, I need to d
> > So does this remove the last concern around Bernd's patch?
>
> And can we remove TYPE_ALIGN_OK as followup? (ISTR it's used
> by obj-c/c++ as well, but I can't find such use)
Probably but, as previously indicated, I need to do some testing first.
--
Eric Botcazou
On May 5, 2014, at 1:00 AM, Richard Biener wrote:
> And can we remove TYPE_ALIGN_OK as followup? (ISTR it's used
> by obj-c/c++ as well, but I can't find such use)
I didn’t find any current hint… the only landmine I found was:
./gcc/config/pa/pa.c:1878:/* Using TYPE_ALIGN_O
On Fri, May 2, 2014 at 8:18 AM, Jeff Law wrote:
> On 04/22/14 03:25, Eric Botcazou wrote:
>>>
>>> Sure, and thanks again for your help.
>>
>>
>> Thanks!
>>
>>> I was not able to find any difference on the generated code with
>>> or without that patch.
>>
>>
>> Yes, my gut feeling is that TYPE_ALIG
On 04/22/14 03:25, Eric Botcazou wrote:
Sure, and thanks again for your help.
Thanks!
I was not able to find any difference on the generated code with
or without that patch.
Yes, my gut feeling is that TYPE_ALIGN_OK is really obsolete now. It is set
in a single place in the compiler (gcc-i
> Sure, and thanks again for your help.
Thanks!
> I was not able to find any difference on the generated code with
> or without that patch.
Yes, my gut feeling is that TYPE_ALIGN_OK is really obsolete now. It is set
in a single place in the compiler (gcc-interface/decl.c:gnat_to_gnu_entity):
Hi Eric,
On Tue, 22 Apr 2014 10:09:28, Eric Botcazou wrote:
>
>> I still have that already-approved patch, updated to current trunk.
>> I've successfully boot-strapped it on armv7-linux-gnueabihf with
>> all languages enabled, including Ada.
>> The test suite runs cleanly without any drop-outs.
>
> I still have that already-approved patch, updated to current trunk.
> I've successfully boot-strapped it on armv7-linux-gnueabihf with
> all languages enabled, including Ada.
> The test suite runs cleanly without any drop-outs.
Thanks for the testing.
> Is it OK to commit now, or are there obje
Hi,
On Wed, 27 Nov 2013 12:47:19, Richard Biener wrote:
>
> On Wed, Nov 27, 2013 at 10:43 AM, Eric Botcazou wrote:
>>> I think you are right, this flag is no longer necessary, and removing
>>> this code path would simplify everything. Therefore I'd like to propose
>>> to remove the "keep_alignin
> Ah, get_object_alignment used keep_aligning ...
Yes, the patch contains the rather explicit hunks:
Index: gcc/builtins.c
===
--- gcc/builtins.c (revision 204101)
+++ gcc/builtins.c (working copy)
@@ -315,7 +315,7 @@ get_o
On Wed, Nov 27, 2013 at 1:29 PM, Eric Botcazou wrote:
>> I'm fine with reverting it for now (you were in CC of the patch submission
>> but silent on it, I asked for the patch to start simplifying the way
>> mems are expanded - ultimately to avoid the recursion and mem-attribute
>> compute by the r
> I'm fine with reverting it for now (you were in CC of the patch submission
> but silent on it, I asked for the patch to start simplifying the way
> mems are expanded - ultimately to avoid the recursion and mem-attribute
> compute by the recursion).
Because I'm totally lost in this thread and its
On Wed, 27 Nov 2013 12:47:19, Richard Biener wrote:
>
> On Wed, Nov 27, 2013 at 10:43 AM, Eric Botcazou wrote:
>>> I think you are right, this flag is no longer necessary, and removing
>>> this code path would simplify everything. Therefore I'd like to propose
>>> to remove the "keep_aligning" par
On Wed, Nov 27, 2013 at 10:43 AM, Eric Botcazou wrote:
>> I think you are right, this flag is no longer necessary, and removing
>> this code path would simplify everything. Therefore I'd like to propose
>> to remove the "keep_aligning" parameter of get_inner_reference as
>> a split-out patch.
>>
>
> Well, I did that. Apologies for not mentioning that.
OK, on which strict-alignment platform did you test it with Ada enabled?
> The change on the ada interface is actually not critical, because all
> invocations of get_inner_reference there used keep_aligning == false, as
> did the majority of
Hi,
On 27 Nov 2013 10:43:59, Eric Botcazou wrote:
>
>> I think you are right, this flag is no longer necessary, and removing
>> this code path would simplify everything. Therefore I'd like to propose
>> to remove the "keep_aligning" parameter of get_inner_reference as
>> a split-out patch.
>>
>> B
> I think you are right, this flag is no longer necessary, and removing
> this code path would simplify everything. Therefore I'd like to propose
> to remove the "keep_aligning" parameter of get_inner_reference as
> a split-out patch.
>
> Boot-strapped (with languages=all,ada,go) and
> regression-
On Sun, Oct 27, 2013 at 5:01 PM, Bernd Edlinger
wrote:
> Hi,
>
> On Fri, 25 Oct 2013 12:51:13, Richard Biener wrote:
>> Finally I think the recursion into the VIEW_CONVERT_EXPR case
>> is only there because of the keep_aligning flag of get_inner_reference
>> which should be obsolete now that we pr
Hi,
On Fri, 25 Oct 2013 12:51:13, Richard Biener wrote:
> Finally I think the recursion into the VIEW_CONVERT_EXPR case
> is only there because of the keep_aligning flag of get_inner_reference
> which should be obsolete now that we properly handle its effects
> in get_object_alignment. So you woul
19 matches
Mail list logo
