[Bug middle-end/66269] New: Issues with mixing strict aliasing (verify_type ICE with Ada)

[Bug middle-end/66269] New: Issues with mixing strict aliasing (verify_type ICE with Ada)

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66269

            Bug ID: 66269
           Summary: Issues with mixing strict aliasing (verify_type ICE
                    with Ada)
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

Hi,
after fixing few issues I get to the following ICE with Ada.  This is due to
LTO preloading - the "int" type is produced by LTO FE, while "integer" type is
a variant of integer_type_node produced by Ada.
They disagree by alias set (variant has alias set 0). This comes from streaming
that notes alias set 0 on variants. Alias sets 0 on variants won't however work
because get_alias_set goes to main variant first.  I wonder what is the proper
fix? Also I wonder how mixing -fstrict-aliasing and -fno-strict-aliasing is
supposed to work? I guess we need variants of types with alias set 0 and make
alias.c/tree-ssa-alias.c to honor (i.e. not go to main variant if it disagree
on alias-set-0-ness) that? 

This has chance to work IMO at LTO (it is still iffy), but at compile time I am
not sure how we can deal with -fno-strict-aliasing in optimize attribute. 
Someone would need to produce type variants all the time and be sure that the
main variant never gets alias set 0...

Honza

../../gcc/ada/a-except.adb:852:0: error: type variant differs by
TYPE_ALIAS_SET.
    end Exception_Name_Simple;
^
 <integer_type 0x3fff79ae07e0 int asm_written public SI
    size <integer_cst 0x3fff79ab1380 type <integer_type 0x3fff79ae02a0
bitsizetype> constant 32>
    unit size <integer_cst 0x3fff79ab1398 type <integer_type 0x3fff79ae01f8
sizetype> constant 4>
    align 32 symtab 16383 alias set 4 canonical type 0x3fff79ae07e0 precision
32 min <integer_cst 0x3fff79ab1338 -2147483648> max <integer_cst 0x3fff79ab1350
2147483647>
    pointer_to_this <pointer_type 0x3fff79ae18f0>>
 <integer_type 0x3fff7a95f0d8 integer readonly public SI
    size <integer_cst 0x3fff79ab1380 type <integer_type 0x3fff79ae02a0
bitsizetype> constant 32>
    unit size <integer_cst 0x3fff79ab1398 type <integer_type 0x3fff79ae01f8
sizetype> constant 4>
    align 32 symtab 0 alias set 0 canonical type 0x3fff79ae07e0 precision 32
min <integer_cst 0x3fff79ab1338 -2147483648> max <integer_cst 0x3fff79ab1350
2147483647> context <translation_unit_decl 0x3fff7ba80f00 D.2718>>
../../gcc/ada/a-except.adb:852:0: internal compiler error: verify_type failed

[Bug middle-end/66269] Issues with mixing strict aliasing (verify_type ICE with Ada)

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66269

--- Comment #1 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Actually this reproduce very easily with mixing two units with
-fstrict-aliasing and -fno-strict-aliasing.

[Bug middle-end/66269] Issues with mixing strict aliasing (verify_type ICE with Ada)

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66269

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-05-26
                 CC|                            |ebotcazou at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #2 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
I agree that it's a bug, but how can I reproduce the issue exactly?