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.

Sign up for GitHub

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

Jump to bottom

ICE when performing binary operation on consteval result and consteval member result #47579

Closed
Snektron mannequin opened this issue Nov 19, 2020 · 2 comments
Closed

ICE when performing binary operation on consteval result and consteval member result #47579

Snektron mannequin opened this issue Nov 19, 2020 · 2 comments
Labels
bugzilla Issues migrated from bugzilla clang:frontend Language frontend issues, e.g. anything involving "Sema"

Comments

@Snektron
Copy link
Mannequin

Snektron mannequin commented Nov 19, 2020

Bugzilla Link 48235
Resolution FIXED
Resolved on Oct 27, 2021 08:26
Version 11.0
OS Linux
Attachments Script which clang produced
CC @AaronBallman,@zygoloid

Extended Description

The following code causes an ICE:

consteval int c() {
return 1;
}

struct A {
consteval int a() const {
return 1;
}

void b() {
    this->a() + c();
}

};

This does not seem to be a problem on clang 10. When c is not consteval, there is no problem. When the call to c is replaced with another call to a(), the same crash happens. (I only later realized that a consteval member is not valid.)

test.cpp:11:19: warning: expression result unused [-Wunused-value]
this->a() + c();
~~~~~~~~~ ^ ~~~
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /usr/bin/clang-11 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name test.cpp -mrelocation-model static -mframe-pointer=all -fmath-errno -fno-rounding-math -mconstructor-aliases -munwind-tables -target-cpu x86-64 -fno-split-dwarf-inlining -debugger-tuning=gdb -resource-dir /usr/lib/clang/11.0.0 -internal-isystem /bin/../lib64/gcc/x86_64-unknown-linux-gnu/10.2/../../../../include/c++/10.2 -internal-isystem /bin/../lib64/gcc/x86_64-unknown-linux-gnu/10.2/../../../../include/c++/10.2/x86_64-unknown-linux-gnu -internal-isystem /bin/../lib64/gcc/x86_64-unknown-linux-gnu/10.2/../../../../include/c++/10.2/backward -internal-isystem /usr/local/include -internal-isystem /usr/lib/clang/11.0.0/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++2a -fdeprecated-macro -fdebug-compilation-dir /home/robin/programming/zooi -ferror-limit 19 -fgnuc-version=4.2.1 -fno-implicit-modules -fcxx-exceptions -fexceptions -fcolor-diagnostics -faddrsig -o /tmp/test-3cc570.o -x c++ test.cpp

  1. parser at end of file
  2. test.cpp:5:1: parsing struct/union/class body 'A'
  3. test.cpp:10:14: parsing function body 'A::b'
    #​0 0x00007feceece191a llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/bin/../lib/libLLVM-11.so+0xb1891a)
    #​1 0x00007feceecdf7e4 llvm::sys::RunSignalHandlers() (/usr/bin/../lib/libLLVM-11.so+0xb167e4)
    #​2 0x00007feceecdf928 (/usr/bin/../lib/libLLVM-11.so+0xb16928)
    #​3 0x00007feceddd89b0 __restore_rt (/usr/bin/../lib/libc.so.6+0x3b9b0)
    #​4 0x00007fecf4832708 clang::computeDependence(clang::CXXThisExpr*) (/usr/bin/../lib/libclang-cpp.so.11+0xc29708)
    #​5 0x00007fecf50f2222 clang::Sema::BuildCXXThisExpr(clang::SourceLocation, clang::QualType, bool) (/usr/bin/../lib/libclang-cpp.so.11+0x14e9222)
    #​6 0x00007fecf4ff5f43 (/usr/bin/../lib/libclang-cpp.so.11+0x13ecf43)
    #​7 0x00007fecf50a8423 (/usr/bin/../lib/libclang-cpp.so.11+0x149f423)
    #​8 0x00007fecf50a5c31 (/usr/bin/../lib/libclang-cpp.so.11+0x149cc31)
    #​9 0x00007fecf5046cf7 clang::Sema::PopExpressionEvaluationContext() (/usr/bin/../lib/libclang-cpp.so.11+0x143dcf7)
    #​10 0x00007fecf4e9d263 clang::Sema::ActOnFinishFunctionBody(clang::Decl*, clang::Stmt*, bool) (/usr/bin/../lib/libclang-cpp.so.11+0x1294263)
    #​11 0x00007fecf46ae9dd clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) (/usr/bin/../lib/libclang-cpp.so.11+0xaa59dd)
    #​12 0x00007fecf45ffc96 clang::Parser::ParseLexedMethodDef(clang::Parser::LexedMethod&) (/usr/bin/../lib/libclang-cpp.so.11+0x9f6c96)
    #​13 0x00007fecf45ff95d clang::Parser::ParseLexedMethodDefs(clang::Parser::ParsingClass&) (/usr/bin/../lib/libclang-cpp.so.11+0x9f695d)
    #​14 0x00007fecf463e4e4 clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, clang::SourceLocation, clang::Parser::ParsedAttributesWithRange&, unsigned int, clang::Decl*) (/usr/bin/../lib/libclang-cpp.so.11+0xa354e4)
    #​15 0x00007fecf4640b7b clang::Parser::ParseClassSpecifier(clang::tok::TokenKind, clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, bool, clang::Parser::DeclSpecContext, clang::Parser::ParsedAttributesWithRange&) (/usr/bin/../lib/libclang-cpp.so.11+0xa37b7b)
    #​16 0x00007fecf461b3c5 clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, clang::Parser::DeclSpecContext, clang::Parser::LateParsedAttrList*) (/usr/bin/../lib/libclang-cpp.so.11+0xa123c5)
    #​17 0x00007fecf46c7bff clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec&, clang::AccessSpecifier) (/usr/bin/../lib/libclang-cpp.so.11+0xabebff)
    #​18 0x00007fecf46c83c5 (/usr/bin/../lib/libclang-cpp.so.11+0xabf3c5)
    #​19 0x00007fecf46d0310 clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) (/usr/bin/../lib/libclang-cpp.so.11+0xac7310)
    #​20 0x00007fecf46d107d clang::Parser::ParseTopLevelDecl(clang::OpaquePtrclang::DeclGroupRef&, bool) (/usr/bin/../lib/libclang-cpp.so.11+0xac807d)
    #​21 0x00007fecf45ff009 clang::ParseAST(clang::Sema&, bool, bool) (/usr/bin/../lib/libclang-cpp.so.11+0x9f6009)
    #​22 0x00007fecf618b1a9 clang::FrontendAction::Execute() (/usr/bin/../lib/libclang-cpp.so.11+0x25821a9)
    #​23 0x00007fecf613cbbb clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/bin/../lib/libclang-cpp.so.11+0x2533bbb)
    #​24 0x00007fecf62176e0 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/usr/bin/../lib/libclang-cpp.so.11+0x260e6e0)
    #​25 0x000055fe4792d98d cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/usr/bin/clang-11+0x1498d)
    #​26 0x000055fe4792b33b (/usr/bin/clang-11+0x1233b)
    #​27 0x000055fe4792808e main (/usr/bin/clang-11+0xf08e)
    #​28 0x00007feceddc3deb __libc_start_main /builddir/glibc-2.30/csu/../csu/libc-start.c:342:3
    #​29 0x000055fe4792aeca _start (/usr/bin/clang-11+0x11eca)
    clang-11: error: unable to execute command: Segmentation fault
    clang-11: error: clang frontend command failed due to signal (use -v to see invocation)
    clang version 11.0.0
    Target: x86_64-unknown-linux-gnu
    Thread model: posix
    InstalledDir: /bin
@AaronBallman
Copy link
Collaborator

This should now be fixed in 9fcca8b.

@AaronBallman
Copy link
Collaborator

mentioned in issue llvm/llvm-bugzilla-archive#48730

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 10, 2021
statham-arm added a commit that referenced this issue May 3, 2022
@statham-arm
[Windows] Fix cmd line tokenization of unclosed quotes.
1be024e 
When cl::TokenizeWindowsCommandLine received a command line with an
unterminated double-quoted string at the end, it would discard the
text within that string. That doesn't match the behavior of the
standard Windows C library, which will return the text in the unclosed
quoted string as an argv word.

Fixed, and added extra unit tests in that area.

In some cases (specifically the one in Bugzilla #47579) this could
cause TokenizeWindowsCommandLine to return a zero-length list of
arguments, leading to an array overrun at the call site in
windows::GetCommandLineArguments. Added a check there, for extra
safety: now windows::GetCommandLineArguments will return an error code
instead of failing an assertion.

(This change was written as part of https://reviews.llvm.org/D122914,
but split into a separate commit at the last minute at the code
reviewer's suggestion, because it's fixing an unrelated bug in the
same area. The rest of D122914 will follow in the next commit.)
statham-arm added a commit that referenced this issue May 3, 2022
@statham-arm
[Windows] Fix handling of \" in program name on cmd line.
32814df 
Bugzilla #47579: if you invoke clang on Windows via a pathname in
which a quoted section closes just after a backslash, e.g.

  "C:\Program Files\Whatever\"clang.exe

then cmd.exe and CreateProcess will correctly find the binary, because
when they parse the program name at the start of the command line,
they don't regard the \ before the " as having any kind of escaping
effect. This is different from the behaviour of the Windows standard C
library when it parses the rest of the command line, which would
consider that \" not to close the quoted string.

But this confuses windows::GetCommandLineArguments, because the
Windows API function GetCommandLineW() will return a command line
containing that \" sequence, and cl::TokenizeWindowsCommandLine will
tokenize the whole string according to the C library's rules. So it
will misidentify where the program name stops and the arguments start.

To fix this, I've introduced a new variant function
cl::TokenizeWindowsCommandLineFull(), intended to be applied to the
string returned from GetCommandLineW(). It parses the first word of
the command line according to CreateProcess's rules, considering \ to
never be an escaping character; thereafter, it switches over to the C
library rules for the rest of the command line.

Reviewed By: hans

Differential Revision: https://reviews.llvm.org/D122914
@usx95 usx95 mentioned this issue Aug 19, 2022
Closed
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bugzilla Issues migrated from bugzilla clang:frontend Language frontend issues, e.g. anything involving "Sema"
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@AaronBallman