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

BitMask error #1560

Closed
llvmbot opened this issue Feb 8, 2007 · 1 comment
Closed

BitMask error #1560

llvmbot opened this issue Feb 8, 2007 · 1 comment
Labels
bugzilla Issues migrated from bugzilla compile-fail Use [accepts-invalid] and [rejects-valid] instead

Comments

@llvmbot
Copy link
Collaborator

llvmbot commented Feb 8, 2007

Bugzilla Link 1188
Resolution FIXED
Resolved on Feb 22, 2010 12:55
Version 1.8
OS All
Reporter LLVM Bugzilla Contributor

Extended Description

I find there is a potential bitmask error with long long type.
In the INTEGER_ASSIGN macro, the program uses (1ull << BitWidth) -1 to get the
bitmask. If BitWidth = 64, the value is 0. The correct way is to use
~(uint64_t)(0ull) >> (BitWidth-1).

Please review the following patch.
Index: lib/ExecutionEngine/Interpreter/Execution.cpp

RCS file: /var/cvs/llvm/llvm/lib/ExecutionEngine/Interpreter/Execution.cpp,v
retrieving revision 1.167
diff -t -d -u -p -5 -r1.167 Execution.cpp
--- lib/ExecutionEngine/Interpreter/Execution.cpp 2 Feb 2007 02:16:22 -0000 1.167
+++ lib/ExecutionEngine/Interpreter/Execution.cpp 7 Feb 2007 23:58:56 -0000
@@ -1305,11 +1305,11 @@ void Interpreter::visitAShr(BinaryOperat
SetValue(&I, Dest, SF);
}

#define INTEGER_ASSIGN(DEST, BITWIDTH, VAL)
{ \

  • uint64_t Mask = (1ull << BITWIDTH) - 1; \
  • uint64_t Mask = ~(uint64_t)(0ull) >> (64-BITWIDTH);
    if (BITWIDTH == 1) {
    Dest.Int1Val = (bool) (VAL & Mask);
    } else if (BITWIDTH <= 8) {
    Dest.Int8Val = (uint8_t) (VAL & Mask);
    } else if (BITWIDTH <= 16) {
    Index: lib/ExecutionEngine/Interpreter/Interpreter.h
    ===================================================================
    RCS file: /var/cvs/llvm/llvm/lib/ExecutionEngine/Interpreter/Interpreter.h,v
    retrieving revision 1.82
    diff -t -d -u -p -5 -r1.82 Interpreter.h
    --- lib/ExecutionEngine/Interpreter/Interpreter.h 2 Feb 2007 02:16:22 -0000 1.82
    +++ lib/ExecutionEngine/Interpreter/Interpreter.h 7 Feb 2007 23:58:56 -0000
    @@ -234,11 +234,11 @@ private: // Helper functions
    void popStackAndReturnValueToCaller(const Type *RetTy, GenericValue Result);

};

inline void maskToBitWidth(GenericValue& GV, unsigned BitWidth) {

  • uint64_t BitMask = (1ull << BitWidth) - 1;
  • uint64_t BitMask = ~(uint64_t)(0ull) >> (64-BitWidth);
    if (BitWidth <= 8)
    GV.Int8Val &= BitMask;
    else if (BitWidth <= 16)
    GV.Int16Val &= BitMask;
    else if (BitWidth <= 32)
@llvmbot
Copy link
Collaborator Author

llvmbot commented Feb 8, 2007

Looks right to me. Patches applied. Thanks, Leo.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
clementval pushed a commit that referenced this issue Jun 13, 2022
…1560)

The pass was raising TODOs when a function both had a fir.boxproc<> argument
and a fir.type<> argument (even if the fir.type<> did not contain a
fir.boxproc itself).

Prevent the TODO from firing when a fir.type<> does not actually contain
a fir.boxproc. Add the location for the remaining TODO (it will be
needed when procedure pointer components are supported in lowering).

FYI, I actually tried to just implement the TODO, but I there is  a funny
issue. When creating the new fir::RecordType, since the name and context
are the same as the type being translated, fir::RecordType:get just
returns the existing type, and there is no way to change it (finalize()
does nothing since it is already finalized). So this will require to add
the ability to mutate the existing type, and I am not sure what are the
MLIR constraints here, so I escaped and left the TODO for that case.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: jeanPerier, PeteSteinfeld

Differential Revision: https://reviews.llvm.org/D127633

Co-authored-by: Jean Perier <jperier@nvidia.com>
troelsbjerre pushed a commit to troelsbjerre/llvm-project that referenced this issue Jan 10, 2024
…n_objcinterfacedecl_always_importdeclcontext_start_def

[ASTImporter] Modify ImportDefiniton for ObjCInterfaceDecl so that we always the ImportDeclContext one we start the definition
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla compile-fail Use [accepts-invalid] and [rejects-valid] instead
Projects
None yet
Development

No branches or pull requests

1 participant