SRA and inconsistencies in bit-field types

[Alexandre Oliva]

On Feb 19, 2007, Alexandre Oliva <aoliva@redhat.com> wrote:

> On Feb 18, 2007, Eric Botcazou <ebotcazou@adacore.com> wrote:
>>> Or, even better, could you perhaps provide me with a testcase and
>>> instructions to trigger the problem on a uninstalled toolchain?

>> Attached.  In the build directory: gcc/xgcc -Bgcc -O -S p.adb -Igcc/ada/rts 

>> +===========================GNAT BUG DETECTED==============================+
>> | 4.3.0 20070216 (experimental) (i586-suse-linux-gnu) GCC error:           |
>> | in sra_build_assignment, at tree-sra.c:1733                              |
>> | Error detected at p.adb:11:4              

> Thanks.  I'm looking into it, but I haven't been able to figure out
> how to fix this yet, so I'm temporarily disabling the assertion, such
> that this testcase compiles again.

After further investigation, I've concluded this test is just too
strict, and the intent behind it just can't be met.

The problem scenario is when the front end emits accesses to fields of
a RECORD_TYPE using types that are different from the fields' nominal
types.  We'll end up using these alternate types for scalarization.

Then, if there are also copies between entire records, some of which
have fields accessed with different types and are scalarized, some of
which don't or aren't scalarizable, we'll emit per-element assignments
using different types.  The types are supposed to be compatible to
some extent, but their main variant types don't necessarily have the
same canonical type, and not even language-specific type compatibility
tests define as compatible (in this particular case, it's pointers to
the gimplified array data and array bound type for one operand and
pointer-to-void in the other.

Adding fold_convert to sra_build_assignment would thus fix the crash,
introducing a NOP_EXPR or CONVERT_EXPR when needed, even though
everything appears to work just fine without it, and CONVERT_EXPRs
would be quite unexpected.  In fact they'd have hidden the failure
mode that got me to investigate the bug that started this thread.

I've actually written code that took note of situations in which a
field was accessed under a type other than its nominal type, or under
multiple types, and only allowed type conversions in these cases, but
I decided that was too much wasted effort.  The patch I've discarded
is attached, for the record, after the patch I'm checking in, that
permanently removes the assertion checks, replacing them with comments
explaining briefly why we'd like to but can't perform the sanity
checks.

I'm going ahead and checking this in.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc-bz223576-dont-check-types.patch
Type: text/x-patch
Size: 1376 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20070219/a171bd80/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc-bz223576-check-types.patch
Type: text/x-patch
Size: 5555 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20070219/a171bd80/attachment-0001.bin>
-------------- next part --------------

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}