Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error operating bit<X> var casted from enum #3178

Closed
lzhzero opened this issue Apr 6, 2022 · 3 comments · Fixed by #3181
Closed

Error operating bit<X> var casted from enum #3178

lzhzero opened this issue Apr 6, 2022 · 3 comments · Fixed by #3181
Assignees
Labels
bug This behavior is unintended and should be fixed. fixed This topic is considered to be fixed.

Comments

@lzhzero
Copy link
Contributor

lzhzero commented Apr 6, 2022

Hi,
We hit error when operating bit<X> variable casted from enum type.

enum bit<1> TableType {TT_ACL = 0, TT_FWD = 1};

const bit<10> b10 = (bit<10>)(bit<1>)TableType.TT_ACL;
const bit<10> mask = 1 << 9;

const bit<10> test1 = b10 << 3;
const bit<10> test2 = mask | b10;

Here is the detailed p4c compiler output.

bug/test_enum.p4(5): [--Werror=expected] error: cast: expected an integer value
const bit<10> b10 = (bit<10>)(bit<1>)TableType.TT_ACL;
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
bug/test_enum.p4(8): [--Werror=invalid] error: <<: Cannot evaluate initializer for constant
const bit<10> test1 = b10 << 3;
                      ^^^^^^^^
bug/test_enum.p4(9): [--Werror=invalid] error: |: Cannot evaluate initializer for constant
const bit<10> test2 = mask | b10;
                      ^^^^^^^^^^
@mihaibudiu mihaibudiu self-assigned this Apr 6, 2022
@mihaibudiu mihaibudiu added bug This behavior is unintended and should be fixed. fixed This topic is considered to be fixed. labels Apr 6, 2022
@apinski-cavium
Copy link

I think I ran into this too:

enum bit<2> e
{
  e0 = 0,
  e1 = 1,
  e2 = 2,
  e3 = 3
}

const bit<2> c = e.e0;
typedef bit<(c)> t;

@mihaibudiu
Copy link
Contributor

Unfortunately this fix won't address this problem. The reason is that we do two (at least) two rounds of constant folding: one before type checking and one after. The one before cannot use type information. And the error in this example is given before the type checking, since the information is needed by the type checker. So it's a phase ordering problem.

We can probably work around this by tracking enough information in the constant folding pass. I will think about it.

@mihaibudiu
Copy link
Contributor

It's not that easy, tried for a while, but I will probably give up for now.
Without type knowledge it's not easy to do constant folding safely.
Feel free to file a separate issue about this last example; it won't work for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This behavior is unintended and should be fixed. fixed This topic is considered to be fixed.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants