This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Interesting issue in gimplify_init_constructor


The test case is the following Ada files:

with Pkg1;
procedure Main is

   C : Pkg1.Instance := ((Time => (2.345, 4)), 126);

begin
   null;
end Main;

package Msg is

   type Float_64 is digits 15;

   type Uint_16 is mod 65_536;

    type Time_Stamp is
        record
            Sec : Float_64 := 0.0;
            Year : Uint_16 := 0;
        end record;

    for Time_Stamp use
        record
            Sec at 0 range 0 .. 63;
            Year at 8 range 0 .. 15;
        end record;

    for Time_Stamp'Size use 10 * 8;

    type  Msg_Header is
        record
            Time : Time_Stamp;
        end record;

    for Msg_Header use
        record
            Time at 0 range 0 .. 79;
        end record;

    for Msg_Header'Size use 80;

    --  Header : constant Msg_Header := (Time => (2.345, 4));

end Msg;

with Msg;
package Pkg1 is

   type Byte is range 0 .. 127;
   for Byte'Size use 8;

   type Instance is
   record
      Header : Msg.Msg_Header;
      Value  : Byte;
   end record;

   for Instance use
   record
      Header at 0 range 0 .. 79;
      Value at 10 range 0 .. 7;
   end record;

   for Instance'Size use 11 * 8;

end Pkg1;

What happens here is that we end up in the code that's trying to promote
a variable to be static.  We aren't allowed to set DECL_INITIAL of such
a decl to an expression for which initializer_constant_valid_p is not
true and that's supposed to mean that output_constant can handle it.

However:

(1) We don't even call initializer_constant_valid_p here.
(2) Even if we did, it doesn't notice that it can't handle it because
it doesn't check for a bitfield whose value isn't an INTEGER_CST.

Here we have a bitfield that's a RECORD_TYPE.

A few issues:

(1) The Ada front end is careful to not set TREE_CONSTANT and TREE_STATIC
in that case, but the code in question doesn't even check them, relying
instead on categorize_ctor_elements.

(2) We already have the mismatch between initializer_constant_valid_p
and output_constant, which shouldn't be the case, but what about the
possible mismatch between initializer_valid_p and categorize_ctor_elements?

My feeling here is to do the following:

(1) Leave categorize_ctor_elements alone.
(2) Add the bitfield check to initializer_valid_p.
(3) Call initializer_valid_p in gimplify_init_constructor.
(4) Remove the bitfield check from the Ada code, leaving just the call
to initializer_valid_p.

What do you think?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]