On Mon, Jun 28, 2021 at 02:51:22PM +0100, Philip Herron wrote:
> On 28/06/2021 14:49, Philip Herron wrote:
> > In Rust the language has the notion of the unit type '()', so for example:
> >
> > fn foo ->i32 { ... }
> > fn bar() { ... }
> >
> > Foo has the return type i32, and bar has no return type, which means it
> > is unit-type so that it can be a value assignable just like any other
> > function call. You can also declare unit-structs or unit as a type on
> > variables:
> >
> > struct foobar; // empty unit struct
> > let a:() = (); // unit type
So you probably should have the unit type only in the language code, and
use an actual type for anything later? Or can the actual type stay
unknown as well? That is new territory for GCC.
> > I thought I could use GCC's void_type_node to represent the unit type
> > and void_node for the value when assigning or using it, but this causes
> > the ICE:
"void" already has a meaning, and it is not this.
> > Then Tom Tromey suggested I try a zero precision integer so I called:
> > make_unsigned_type (0) for the type and then use integer_zero_node for
> > the value, and this solves the problem; however, if I use this zero
> > precision integer type for the return type on functions and turn
> > optimizations on I get the ICE:
> >
> > ```
> > test.rs: In function ‘main’:
> > test.rs:16:1: internal compiler error: in min_value, at wide-int.cc:346
So you'll need to update the max/min code to know about this. Or, don't
expose unit type in generic code at all? Can the language code not
always lower it to an actual type instead of the placeholder it is?
There will be many more places things will break after vrp1. Including
many RTL passes.
Segher
