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

Bug: ill-typed projection element #508

Open
msprotz opened this issue Dec 23, 2024 · 0 comments
Open

Bug: ill-typed projection element #508

msprotz opened this issue Dec 23, 2024 · 0 comments
Labels
C-bug A bug in charon

Comments

@msprotz
Copy link
Contributor

msprotz commented Dec 23, 2024

In Eurydice, I am traversing the Charon representation of the following function: https://github.com/cryspen/libcrux/blob/franziskus/mldsa-c-ci/libcrux-ml-dsa/src/simd/avx2.rs#L140-L142

To observe this, run ./boring.sh in the libcrux-ml-dsa subdirectory, on an x64 machine (this code is disabled on arm64).

This is the representation:

Visiting function: libcrux_ml_dsa::simd::avx2::{(libcrux_ml_dsa::simd::traits::Operations for libcrux_ml_dsa::simd::avx2::vector_type::AVX2SIMDUnit)}::ntt::closure
  fn libcrux_ml_dsa::simd::avx2::{libcrux_ml_dsa::simd::traits::Operations for libcrux_ml_dsa::simd::avx2::vector_type::AVX2SIMDUnit}::ntt::closure<0, 1>(state^1 : &0 mut ((&1 (@Array<core::core_arch::x86::__m256i, 32: usize>))), i^2 : usize) -> libcrux_ml_dsa::simd::avx2::v
ector_type::AVX2SIMDUnit
{
    v@0 : libcrux_ml_dsa::simd::avx2::vector_type::AVX2SIMDUnit;
    state^1 : &0 mut ((&1 (@Array<core::core_arch::x86::__m256i, 32: usize>)));
    i^2 : usize;
    v@3 : core::core_arch::x86::__m256i;
    v@4 : usize;
    v@5 : &'_ (@Array<core::core_arch::x86::__m256i, 32: usize>);
    v@6 : &'_ (core::core_arch::x86::__m256i);

    v@4 := copy i^2;
    v@5 := &*((*(state^1)).0);
    v@6 := move @ArrayIndexShared<'_, core::core_arch::x86::__m256i, 32: usize>(move v@5, copy v@4);
    v@3 := copy *(v@6);
    v@0 := libcrux_ml_dsa::simd::avx2::vector_type::AVX2SIMDUnit { coefficients = move v@3; };
    drop v@4;
    drop v@3;
    return
  }

When I translate v@5 := &*((*(state^1)).0);, I call expression_of_place which prints out both the sub-place and the path element, at this location: https://github.com/AeneasVerif/eurydice/blob/main/lib/AstOfLlbc.ml#L557 using the following debug printing (in my local copy):

      L.log "AstOfLlbc" "sub_place=%s\npe=%s\n" (C.show_place sub_place) (C.show_projection_elem pe);

My understanding is that the sub-place, e.g., has type "tuple", and the path element is valid for that type, e.g. .0 or .1.

However, this is the debug output that I get:

sub_place={ Generated_Expressions.kind =
  (Generated_Expressions.PlaceProjection (
     { Generated_Expressions.kind = (Generated_Expressions.PlaceBase 1);
       ty =
       (Generated_Types.TRef (Generated_Types.RErased,
          (Generated_Types.TArrow
             { Generated_Types.binder_regions = [];
               binder_value =
               ([(Generated_Types.TLiteral
                    (Generated_Values.TInteger Generated_Values.Usize))
                  ],
                (Generated_Types.TAdt ((Generated_Types.TAdtId 18),
                   { Generated_Types.regions = []; types = [];
                     const_generics = []; trait_refs = [] }
                   )))
               }),
          Generated_Types.RMut))
       },
     Generated_Expressions.Deref));
  ty =
  (Generated_Types.TArrow
     { Generated_Types.binder_regions = [];
       binder_value =
       ([(Generated_Types.TLiteral
            (Generated_Values.TInteger Generated_Values.Usize))
          ],
        (Generated_Types.TAdt ((Generated_Types.TAdtId 18),
           { Generated_Types.regions = []; types = []; const_generics = [];
             trait_refs = [] }
           )))
       })
  }
pe=(Generated_Expressions.Field ((Generated_Expressions.ProjTuple 1), 0))

My question is: why does it make sense to project field element 0 out of something that has an arrow type?

Note that I am only recursing on sub-places constructed by charon, so I don't think I'm rebuilding incorrect type information anywhere.

@msprotz msprotz added the C-bug A bug in charon label Dec 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug A bug in charon
Projects
None yet
Development

No branches or pull requests

1 participant