ml/gcc-patches/2013-11/msg02046.html and approved here:
> http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00091.html
>
> 3. Then this patch itself "Strict volatile bit-fields clean-up, Take 2".
>
> 4. And finally the Clean-up patch: "Strict volatile bit-fields clean-u
ode
>>>> it wants to do the store with, so why not even have an explicit
>>>> mode argument for store_fixed_bit_field_1 instead of extracting
>>>> it from op0?
>>>>
>>>> Note I just want to help as well and I am not very familiar with
d_1 instead of extracting
>>> it from op0?
>>>
>>> Note I just want to help as well and I am not very familiar with
>>> the details of the implementation here. So I'd rather have
>>> a patch "obviously correct" to me - which expandi
On Mon, Dec 9, 2013 at 1:39 PM, Bernd Edlinger
wrote:
> On Fri, 6 Dec 2013 11:51:15, Richard Biener wrote:
>>
>> On Fri, Dec 6, 2013 at 11:15 AM, Bernd Edlinger
>> wrote:
>>> Hi,
>>>
>>> On Thu, 5 Dec 2013 15:10:51, Richard Biener wrote:
On Thu, Dec 5, 2013 at 1:27 PM, Bernd Edlinger
>>
On Fri, 6 Dec 2013 11:51:15, Richard Biener wrote:
>
> On Fri, Dec 6, 2013 at 11:15 AM, Bernd Edlinger
> wrote:
>> Hi,
>>
>> On Thu, 5 Dec 2013 15:10:51, Richard Biener wrote:
>>>
>>> On Thu, Dec 5, 2013 at 1:27 PM, Bernd Edlinger
>>> wrote:
Hi Richard,
I had just an idea how to so
Richard,
> Note I just want to help as well and I am not very familiar with
> the details of the implementation here. So I'd rather have
> a patch "obviously correct" to me - which expanding a condition
> by several more checks isn't ;)
>
Thanks a lot, I understand that very well. Any help is wel
On Fri, Dec 6, 2013 at 11:15 AM, Bernd Edlinger
wrote:
> Hi,
>
> On Thu, 5 Dec 2013 15:10:51, Richard Biener wrote:
>>
>> On Thu, Dec 5, 2013 at 1:27 PM, Bernd Edlinger
>> wrote:
>>> Hi Richard,
>>>
>>> I had just an idea how to solve that recursion problem without completely
>>> ignoring the
>>
>
> Hmm, same patch as last time attached?
>
> Richard.
>
Yes, only the change-log had one redundant line.
Bernd.
On Fri, Dec 6, 2013 at 11:15 AM, Bernd Edlinger
wrote:
> Hi,
>
> On Thu, 5 Dec 2013 15:10:51, Richard Biener wrote:
>>
>> On Thu, Dec 5, 2013 at 1:27 PM, Bernd Edlinger
>> wrote:
>>> Hi Richard,
>>>
>>> I had just an idea how to solve that recursion problem without completely
>>> ignoring the
>>
Hi,
On Thu, 5 Dec 2013 15:10:51, Richard Biener wrote:
>
> On Thu, Dec 5, 2013 at 1:27 PM, Bernd Edlinger
> wrote:
>> Hi Richard,
>>
>> I had just an idea how to solve that recursion problem without completely
>> ignoring the
>> memory mode. I hope you are gonna like it.
>>
>> This time I even a
On Thu, Dec 5, 2013 at 1:27 PM, Bernd Edlinger
wrote:
> Hi Richard,
>
> I had just an idea how to solve that recursion problem without completely
> ignoring the
> memory mode. I hope you are gonna like it.
>
> This time I even added a comment :-)
Ehm, ...
+ /* If MODE has no size i.e. BLKm
Hi Richard,
I had just an idea how to solve that recursion problem without completely
ignoring the
memory mode. I hope you are gonna like it.
This time I even added a comment :-)
Ok for trunk after boot-strap and regression-testing?
Bernd.
On Tue, 3 Dec 2013 12:23:11, Richard Biener wrote:
>
On Tue, 3 Dec 2013 12:23:11, Richard Biener wrote:
>
> On Tue, Dec 3, 2013 at 12:01 PM, Bernd Edlinger
> wrote:
>> Hi,
>>
>> This is my proposal for ulimately getting rid of the nasty
>> store_fixed_bit_field recursion.
>>
>> IMHO, the root of the recursion trouble is here:
>>
>> @@ -1007,12 +101
> From: ebotca...@adacore.com
> To: bernd.edlin...@hotmail.de
> CC: gcc-patches@gcc.gnu.org; richard.guent...@gmail.com
> Subject: Re: [PATCH] Strict volatile bit-fields clean-up
> Date: Tue, 3 Dec 2013 13:00:25 +0100
>
>> I tried
> I tried something like this, and it did boot-strap, but failed in some acats
> tests:
Am I supposed to guess which ones? Note that you can have non-byte-aligned
aggregate fields in Ada, i.e. arrays, so ARRAY_REFs can presumably reach here.
--
Eric Botcazou
>
>> Yes. I somehow did expect DECL_BIT_FIELD to be something simple,
>> without dependency on if -fstrict-volatile-bitfields is given, or what
>> Language front-end generated it, or if STRICT_ALIGNMENT is defined.
>
> Yes, it should be that way, and everything else is a bug.
>
I tried something l
On Tue, Dec 3, 2013 at 12:01 PM, Bernd Edlinger
wrote:
> Hi,
>
> This is my proposal for ulimately getting rid of the nasty
> store_fixed_bit_field recursion.
>
> IMHO, the root of the recursion trouble is here:
>
> @@ -1007,12 +1013,8 @@ store_fixed_bit_field (rtx op0, unsigned
>
>if (MEM_P
> Yes. I somehow did expect DECL_BIT_FIELD to be something simple,
> without dependency on if -fstrict-volatile-bitfields is given, or what
> Language front-end generated it, or if STRICT_ALIGNMENT is defined.
Yes, it should be that way, and everything else is a bug.
--
Eric Botcazou
Hi,
This is my proposal for ulimately getting rid of the nasty
store_fixed_bit_field recursion.
IMHO, the root of the recursion trouble is here:
@@ -1007,12 +1013,8 @@ store_fixed_bit_field (rtx op0, unsigned
if (MEM_P (op0))
{
mode = GET_MODE (op0);
if (GET_MODE_BITSIZE (m
> The trigger is a latent problem in the ada gcc_interface.
>
> That is we have a bit-field of exactly 8 bit size, which is not
> byte-aligned, but DECL_MODE=QImode, DECL_BIT_FIELD=false which looks quite
> strange, and is totally different from how C structures look like. I should
> mention that
On Tue, 3 Dec 2013 10:59:15, Richard Biener wrote:
>
> On Tue, Dec 3, 2013 at 10:47 AM, Bernd Edlinger
> wrote:
>> On Mon, 2 Dec 2013 15:42:48, Richard Biener wrote:
>>>
>>> On Wed, Nov 20, 2013 at 11:48 AM, Bernd Edlinger
>>> wrote:
Hello Richard,
as a follow-up patch to the bit-f
On Tue, Dec 3, 2013 at 10:59 AM, Richard Biener
wrote:
> On Tue, Dec 3, 2013 at 10:47 AM, Bernd Edlinger
> wrote:
>> On Mon, 2 Dec 2013 15:42:48, Richard Biener wrote:
>>>
>>> On Wed, Nov 20, 2013 at 11:48 AM, Bernd Edlinger
>>> wrote:
Hello Richard,
as a follow-up patch to the bi
On Tue, Dec 3, 2013 at 10:47 AM, Bernd Edlinger
wrote:
> On Mon, 2 Dec 2013 15:42:48, Richard Biener wrote:
>>
>> On Wed, Nov 20, 2013 at 11:48 AM, Bernd Edlinger
>> wrote:
>>> Hello Richard,
>>>
>>> as a follow-up patch to the bit-fields patch(es), I wanted to remove the
>>> dependencies on
>>>
On Mon, 2 Dec 2013 15:42:48, Richard Biener wrote:
>
> On Wed, Nov 20, 2013 at 11:48 AM, Bernd Edlinger
> wrote:
>> Hello Richard,
>>
>> as a follow-up patch to the bit-fields patch(es), I wanted to remove the
>> dependencies on
>> the variable flag_strict_volatile_bitfields from expand_assignmen
On Wed, Nov 20, 2013 at 11:48 AM, Bernd Edlinger
wrote:
> Hello Richard,
>
> as a follow-up patch to the bit-fields patch(es), I wanted to remove the
> dependencies on
> the variable flag_strict_volatile_bitfields from expand_assignment and
> expand_expr_real_1.
> Additionally I want the access
Hello Richard,
as a follow-up patch to the bit-fields patch(es), I wanted to remove the
dependencies on
the variable flag_strict_volatile_bitfields from expand_assignment and
expand_expr_real_1.
Additionally I want the access mode of the field to be selected in the memory
context,
instead of th
26 matches
Mail list logo
