On 11/28/12 10:25, Richard Biener wrote:
On Tue, Nov 27, 2012 at 11:45 PM, Ramana Radhakrishnan
<ramana....@googlemail.com> wrote:
On Tue, Nov 27, 2012 at 8:22 PM, Richard Sandiford
<rdsandif...@googlemail.com> wrote:
Ramana Radhakrishnan <ramra...@arm.com> writes:
Tested on x86_64-linux-gnu, powerpc64-linux-gnu and mipsisa64-elf.
Also tested by making sure that there were no changes in assembly
output for a set of gcc .ii files. On the other hand, the -march=octeon
output for a set of mips64-linux-gnu gcc .ii files showed the optimisation
kicking in as hoped.
This sequence of patches caused a regression in
gcc.target/arm/volatile-bitfields-1.c . I haven't reviewed the patch
stack in great detail yet, but it looks like this sequence of patches
doesn't take the ARM volatile bitfields into account. (193600 is fine,
193606 is not).
Looks like I was wrong to drop the conditions from patch 5.
Please could you try the attached?
Fixes volatile-bitfields-1.c but appears to break volatile-bitfields-4.c :( .
Can arm folks please re-implement strict volatile bitfields in terms of
DECL_BIT_FIELD_REPRESENTATIVE as I suggested elsewhere?
Thus, adjust stor-layout.c to compute a proper representative honoring
strict volatile bitfield semantics?
This is a regression in a feature that used to work before this patch
went in.
I've now opened PR55516 to track this and in my book this is a P1
regression in a primary port and will break the USB stack in the Linux
kernel from previous experience (PR51442)
If this has to be rewritten, are you suggesting that this be done in
time for 4.8 ? I've found the reference to your previous posts on the
subject but on a quick perusal I don't see it as an easy fix. None of us
understand the code as well as you do :)
OTOH I would have naively expected such a rewrite to be painful in
stage3 even if we worked our way around this area.
Thanks,
Ramana
