Good First Issues in Llvm

https://godbolt.org/z/YdMdsWqP6 Similar to #230886, frexp can be inlined via expandFrexp, but since code size is larger and it may not always be faster than libcall, expandFrexp should only be used for vector frexp when veclib is not available to avoid poor scalarization codegen.

see #173021 #179434 #179434 added an inline expand for modf in SDAG, given this function's inline expansion is very short, x86 should use this to allow vectorization without veclib. https://godbolt.org/z/dGPav1rqE

If a precision is specified for a %s conversion, a null terminator does not need to be present in the array pointed to by the const char * argument. In src/__support/printf_core/string_converter.h, the printf_core::char_writer() function first calls internal::string_length() and afterward clamps using the precision. The printf_core::wchar_writer() function for %ls does not have the same problem, as it counts the length using an internal::StringConverter capped to converting at most precision characters.

The following code: module m type :: x end type integer, bind(c) :: x end Resulted in this output: fatal internal error: CDEFINED not allowed on this kind of symbol at flang/lib/Semantics/symbol.cpp(506) Fortran::common::die Fortran::semantics::Symbol::SetIsCDefined(bool) Fortran::semantics::AttrsVisitor::SetBindNameOn(Fortran::semantics::Symbol&) Fortran::semantics::DeclarationVisitor::DeclareUnknownEntity(Fortran::parser::Name const&, Fortran::semantics::Attrs) Fortran::semantics::DeclarationVisitor::Post(Fortran::parser::EntityDecl const&) Fortran::semantics::ResolveNamesVisitor::Pre(Fortran::parser::SpecificationPart const&) Fortran::semantics::ResolveNamesVisitor::ResolveSpecificationParts(Fortran::semantics::ProgramTree&) Fortran::semantics::ResolveNames(...) Trunk: https://godbolt.org/z/7qEhnv57j This bug was found by fusion-fuzz

sinh is a sign-preserving function. We currently handle the case where sinh(non-negative) = non-negative, but we do not currently handle the mirror case. If the input to sinh is known to never be non-zero positive (fcPosSubnormal | fcPosNormal | fcPosInf), then the result will also never be non-zero positive (fcPosSubnormal | fcPosNormal | fcPosInf). Ruling out zero can be risky, so we will limit the optimization to just ruling out all non-zero positive classes. The result may still be +0.0 or -0.0. non-positive means any value that is negative (including -0.0) or NaN. non-negative means any value that is positive (including +0.0) or NaN. Tests should be similar to how atan2(y, x) is structured. Be careful around FTPZ/DAPZ (flush to positive zero/denormals are positive zero) since a negative-subnormal input or a negative-subnormal output may become positive zero. You can use the applyInputDenormalMode and applyOutputDenormalMode helpers to assist with handling of denormal modes. Note:

tanh is a sign-preserving function. We currently handle the case where tanh(non-negative) = non-negative, but we do not currently handle the mirror case. If the input to tanh is known to never be non-zero positive (fcPosSubnormal | fcPosNormal | fcPosInf), then the result will also never be non-zero positive finite (fcPosSubnormal | fcPosNormal). Ruling out zero can be risky, so we will limit the optimization to just ruling out all non-zero positive classes. The result may still be +0.0 or -0.0. non-positive means any value that is negative (including -0.0) or NaN. non-negative means any value that is positive (including +0.0) or NaN. Tests should be similar to how atan2(y, x) is structured. Be careful around FTPZ/DAPZ (flush to positive zero/denormals are positive zero) since a negative-subnormal input or a negative-subnormal output may become positive zero. You can use the applyInputDenormalMode and applyOutputDenormalMode helpers to assist with handling of denormal modes. Note: Thi

asin is a sign-preserving function. We currently handle the case where asin(non-negative) = non-negative, but we do not currently handle the mirror case. If the input to asin is known to never be non-zero positive finite (fcPosSubnormal | fcPosNormal), then the result will also never be non-zero positive finite (fcPosSubnormal | fcPosNormal). Ruling out zero can be risky, so we will limit the optimization to just ruling out all non-zero positive classes. The result may still be +0.0 or -0.0. non-positive means any value that is negative (including -0.0) or NaN. non-negative means any value that is positive (including +0.0) or NaN. Tests should be similar to how atan2(y, x) is structured. Be careful around FTPZ/DAPZ (flush to positive zero/denormals are positive zero) since a negative-subnormal input or a negative-subnormal output may become positive zero. You can use the applyInputDenormalMode and applyOutputDenormalMode helpers to assist with handling of denormal modes. Note: This is

atan is a sign-preserving function. We currently handle the case where atan(non-negative) = non-negative, but we do not currently handle the mirror case. If the input to atan is known to never be non-zero positive (fcPosSubnormal | fcPosNormal | fcPosInf), then the result will also never be non-zero positive finite (fcPosSubnormal | fcPosNormal). Ruling out zero can be risky, so we will limit the optimization to just ruling out all non-zero positive classes. The result may still be +0.0 or -0.0. non-positive means any value that is negative (including -0.0) or NaN. non-negative means any value that is positive (including +0.0) or NaN. Tests should be similar to how atan2(y, x) is structured. Be careful around FTPZ/DAPZ (flush to positive zero/denormals are positive zero) since a negative-subnormal input or a negative-subnormal output may become positive zero. You can use the applyInputDenormalMode and applyOutputDenormalMode helpers to assist with handling of denormal modes. Note: Thi

A DBG_VALUE at the beginning of a successor block can prevent the AArch64 load/store optimizer from forming a post-index addressing mode. As a result, compiling the same source with -g emits an additional add instruction. This reproduces with LLVM 24.0.0git at revision 2fd31faf6ec53ad7fc0c92355856367b9c5f3ad8 and remains present on main at a32be176a59c306f98677cf6e44a7289b5ae7508. Reproducer void h(int *); static inline void put_next(int *q) { h(q + 1); } void f(int *p, int v, int c) { *p = v; if (c) put_next(p); } Compile with and without debug information: clang --target=aarch64-linux-gnu -O2 -S input.c -o no-debug.s clang --target=aarch64-linux-gnu -O2 -g -S input.c -o debug.s The difference is also present at -O1, -O3, and -Os. Actual behavior Without -g, the store and pointer update are combined: f: str w1, [x0], #4 cbz w2, .LBB0_2 b h .LBB0_2: ret With -g, the pointer update remains separate: f: str w1, [x0]

Related PR: #228863 Original Issue: #225037 While working on #225037, where using an enum as the element type of ext_vector_type triggers an assertion failure, we added regression tests covering template instantiation in PR #228863 and discovered an additional diagnostic location issue. This issue also reproduces without the changes from PR #228863, using a struct as the element type. For the test case below, instantiating Vector<S> correctly produces an error about the invalid element type. However, the primary error diagnostic does not include a filename, line number, or column number, nor does it display the corresponding source line. In contrast, the note pointing to the template instantiation has a valid source location. Reproducer (https://godbolt.org/z/rToTWfrxj): struct S {}; template <typename T> struct Vector { typedef T type __attribute__((ext_vector_type(4))); }; Vector<S> struct_vector; Actual output: error: invalid vector element type 'S' <source>:7:11: note: in insta

#228027 (review) #228027 added handling for SMULH/UMULH, but any isTriviallyVectorizable() intrinsic (min/max etc.) would benefit - will probably need poison handling via the intrinsicPropagatesPoison() check as well. As usual, decent test coverage is where the time will be spent......

Adding one DBG_VALUE between two otherwise adjacent GlobalISel carry operations changes AArch64 instruction selection. The input without the record reuses the carry flags produced by ADDSXrr; the input with it emits an extra CSINCWr and SUBSWri before ADCSXr. This reproduces with an assertions-enabled LLVM 24.0.0git build at revision aa797754ed4f on x86-64 Linux. Both inputs pass -verify-machineinstrs before and after instruction selection. Reproducer Attach with-debug.mir.txt, without-debug.mir.txt, and issue-reproducer.sh individually. The .txt suffix is only used because GitHub does not accept .mir uploads. Run: $ LLC=/path/to/llc bash issue-reproducer.sh Actual behavior After instruction-select, the relevant ordinary Machine IR difference is: %4:gpr64 = ADDSXrr %0, %2, implicit-def $nzcv + %5:gpr32common = CSINCWr $wzr, $wzr, 3, implicit $nzcv + %8:gpr32 = SUBSWri %5, 1, 0, implicit-def $nzcv %6:gpr64 = ADCSXr %1, %3, implicit-def $nzcv, implicit $nzcv Replacing the DBG_VAL

On AArch64 at -O1, adding debug information changes how GlobalISel lowers a multiplication by six followed by an addition. The -g build selects two shifted adds, while the -g0 build selects an immediate move and madd. SelectionDAG produces identical code with and without debug information. This reproduces with an assertions-enabled LLVM 24.0.0git build at revision aa797754ed4f on x86-64 Linux, targeting AArch64. All four compilations also pass -verify-machineinstrs. Reproducer Attach reduced-source.c and issue-reproducer.sh, then run: issue-reproducer.sh reduced-source.c $ bash issue-reproducer.sh c03da3f7254f2a95d22bda37243d0a57a785ed2d7b8dbb551bb57e202e1a6197 .../gisel.g.text 46092834bc51797e841663ec2fe62860b5fcb9dc8fbe7fd66a30fe17548cdae7 .../gisel.g0.text 46092834bc51797e841663ec2fe62860b5fcb9dc8fbe7fd66a30fe17548cdae7 .../sdag.g.text 46092834bc51797e841663ec2fe62860b5fcb9dc8fbe7fd66a30fe17548cdae7 .../sdag.g0.text GlobalISel: -g and -g0 .text DIFFER SelectionDAG: -g and -g0

-ffixed-line-length=<n> parses <n> as a 64-bit integer and then stores it into an int without a range check. It rejects negative values and values below 7, but values above 2147483647 are silently truncated to int: 2147483648 and 4294967296 become a negative or zero column limit. Every column is then "past the limit", the whole source file is ignored, and nothing is diagnosed. 4294967368 quietly behaves like -ffixed-line-length=72. program p print *, 42 end $ flang -ffixed-line-length=2147483648 fixed.f /usr/bin/ld: /lib/x86_64-linux-gnu/Scrt1.o: in function `_start': (.text+0x1b): undefined reference to `main' flang-24: error: linker command failed with exit code 1 (use -v to see invocation) $ flang -ffixed-line-length=2147483647 fixed.f && ./a.out 42 With -c there is no error at all: the command exits 0 and nm fixed.o prints no symbols (without the option, it defines _QQmain and main). A line with text past column 72 (wide.f: x = 1 padded with blanks so th

It appears that double atan2(double) is incorrectly recognized as double atan2(double, double) in this test: llvm-project/llvm/test/CodeGen/PowerPC/lower-scalar-mass-fast.ll Lines 372 to 379 in 841433d define double @atan2_f64(double %a) { ; CHECK-LABEL: atan2_f64 ; CHECK: __xl_atan2_finite ; CHECK: blr entry: %call = tail call nnan ninf afn nsz double @atan2(double %a) ret double %call } Other two argument functions appear to be written correctly in that file. TODO: Fix the broken test to use the correct prototype for atan2 Add tests (in a separate file) to make sure that tail cal

flang silently accepts a module that USEs itself directly in its own specification part, even with -pedantic: module m1 use m1 end module m1 $ flang -fsyntax-only repro.f90 $ echo $? 0 F2023 14.2.2 p1: "A module shall not reference itself, either directly or indirectly." flang already enforces this one scope deeper — the same USE inside a module procedure of m1 gets error: Module 'm1' cannot USE itself — and NAG, gfortran and ifx all reject the direct form too. A variant shows the same gap as a misleading message: module m1 use m1, only: y integer :: y = 1 end module m1 $ flang -fsyntax-only repro.f90 error: Semantic errors in repro.f90 repro.f90:2:17: error: 'y' not found in module 'm1' use m1, only: y ^ (y is declared in m1; the real problem is the self-reference.) Cause: ModuleVisitor::FindModule in flang/lib/Semantics/resolve-names.cpp guards the self-USE check with DoesScopeContain(scope, currScope()), which per tools.h is a proper-ancestor test and

With -fopenmp, flang segfaults in semantics on a program whose modules form a USE cycle. Without -fopenmp the same input gets the proper diagnostic. Reproducer cycle.f90 module m1 use m2 end module m2 use m1 end $ flang -fopenmp -c cycle.f90 PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace and instructions to reproduce the bug. Stack dump: ... #4 Fortran::semantics::OmpStructureChecker::Enter(Fortran::parser::Module const&) #5 ... Fortran::parser::detail::ParseTreeVisitorLookupScope::Walk<Fortran::parser::Module, Fortran::semantics::SemanticsVisitor<Fortran::semantics::OmpStructureChecker>>(...) #6 Fortran::semantics::Semantics::Perform() #7 Fortran::frontend::FrontendAction::runSemanticChecks() #8 Fortran::frontend::CodeGenAction::beginSourceFileAction() flang-24: error: unable to execute command: Segmentation fault flang-24: error: flang frontend command failed with exit code -2 (use -v to see invocation) Same with fl

llvm-project/llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp Lines 2826 to 2846 in 6c75b01 // log(exp{,2,10}(y)) -> y*log({e,2,10}) // TODO: There is no exp10() intrinsic yet. if (ArgLb == ExpLb || ArgLb == Exp2Lb || ArgLb == Exp10Lb || ArgID == Intrinsic::exp || ArgID == Intrinsic::exp2) { Constant *Eul; if (ArgLb == ExpLb || ArgID == Intrinsic::exp) // FIXME: Add more precise value of e for long double. Eul = ConstantFP::get(Log->getType(), numbers::e); else if (ArgLb == Exp2Lb || ArgID == Intrinsic::exp2) Eul

For the division functions, we can assume that the denominator is non-zero even if we are unable to rule out a zero denominator (i.e. 0b000?, 0b0???, 0b?000, etc). This occurs when the denominator has no known set bits. udiv chooses the minimum non-zero denominator by setting the lowest unknown bit. llvm-project/llvm/lib/Support/KnownBits.cpp Lines 1295 to 1307 in 8267555 // A zero denominator is UB, so the minimum attainable denominator is the // smallest non-zero value consistent with the known bits. APInt MinDenom = RHS.getMinValue(); if (MinDenom.isZero()) MinDenom.setBit(RHS.countMinTrailingZeros()); // The quotient grows when the numerato

llvm-project/llvm/lib/Support/KnownBits.cpp Lines 1301 to 1307 in 8267555 // The quotient grows when the numerator grows and shrinks when the // denominator grows, and all four operand bounds are attainable, so the // result is in [MinNum / MaxDenom, MaxNum / MinDenom]. Keep the common // leading bits of the two bounds (as ConstantRange::toKnownBits does), // which can include leading ones, not just leading zeros. APInt MaxRes = LHS.getMaxValue().udiv(MinDenom); APInt MinRes = LHS.getMinValue().udiv(RHS.getMaxValue()); If the division is exact, then we can tighten the bounds on minimum result (or equivalently the minimum numerator). The theor

Part of #221801 1. Public Headers & Support Libraries Check utils/bazel/llvm-project-overlay/libc/BUILD.bazel for long double functions. The end result should be that every implemented long double function has both its internal support library (libc_support_library) and public entrypoint target (libc_math_function / libc_function) in the Bazel file. 2. Tests For every long double function implemented so far: Check whether a regular MPFR-based test exists under libc/test/src/math/. If it exists, check whether it is added to utils/bazel/llvm-project-overlay/libc/test/src/math/BUILD.bazel. If not, add it. Check whether a smoke test exists under libc/test/src/math/smoke/. If it exists, check whether it is added to utils/bazel/llvm-project-overlay/libc/test/src/math/smoke/BUILD.bazel. If not, add it. This should be done for all long double math functions implemented so far. Additional Guidelines: Please split into 3 separate PRs (one for each file to be edited: libc/BUILD.bazel, libc/tes

Part of #221801 1. Public Headers & Support Libraries Check utils/bazel/llvm-project-overlay/libc/BUILD.bazel for double functions. The end result should be that every implemented double function has both its internal support library (libc_support_library) and public entrypoint target (libc_math_function / libc_function) in the Bazel file. 2. Tests For every double function implemented so far: Check whether a regular MPFR-based test exists under libc/test/src/math/. If it exists, check whether it is added to utils/bazel/llvm-project-overlay/libc/test/src/math/BUILD.bazel. If not, add it. Check whether a smoke test exists under libc/test/src/math/smoke/. If it exists, check whether it is added to utils/bazel/llvm-project-overlay/libc/test/src/math/smoke/BUILD.bazel. If not, add it. This should be done for all double math functions implemented so far. Additional Guidelines: Please split into 3 separate PRs (one for each file to be edited: libc/BUILD.bazel, libc/test/src/math/BUILD.baz

Part of #221801 1. Public Headers & Support Libraries Check utils/bazel/llvm-project-overlay/libc/BUILD.bazel for float functions. The end result should be that every implemented float function has both its internal support library (libc_support_library) and public entrypoint target (libc_math_function / libc_function) in the Bazel file. 2. Tests For every float function implemented so far: Check whether a regular MPFR-based test exists under libc/test/src/math/. If it exists, check whether it is added to utils/bazel/llvm-project-overlay/libc/test/src/math/BUILD.bazel. If not, add it. Check whether a smoke test exists under libc/test/src/math/smoke/. If it exists, check whether it is added to utils/bazel/llvm-project-overlay/libc/test/src/math/smoke/BUILD.bazel. If not, add it. This should be done for all float math functions implemented so far. Additional Guidelines: Please split into 3 separate PRs (one for each file to be edited: libc/BUILD.bazel, libc/test/src/math/BUILD.bazel,

Testcase: struct A { int n; }; struct B : A {} b[2]; constexpr int *f() { // Loses MostDerived array information. A *p = b; return &static_cast<B*>(p)[1].n; } static_assert(f() == &b[1].n); Clang incorrectly rejects: <source>:10:15: error: static assertion expression is not an integral constant expression 10 | static_assert(f() == &b[1].n); | ^~~~~~~~~~~~~~ <source>:7:11: note: cannot access base class of pointer past the end of object 7 | return &static_cast<B*>(p)[1].n; | ^ <source>:10:15: note: in call to 'f()' 10 | static_assert(f() == &b[1].n); | ^~~ This is happening because reconstruction of an LValue from an APValue (specifically, SubobjectDesignator construction) is miscomputing the values for the MostDerivedIsArrayElement and MostDerivedArraySize fields in the case where the most-derived object that the lvalue refers to is an array element, but the lvalue itself is not (that is, when the lvalue refers

The fold (A + vscale(C1)) + vscale(C2) -> A + vscale(C1 + C2) does not seem to beneficial for riscv when inner add has multiple uses, as it would introduce extra add. unnecesary add can be optimized from here: https://godbolt.org/z/9xfWc5voc

The main aim of this is to add all the targets for math functions which were missed to be added to bazel files. The issues below can be collaboratively worked on too if needed BFloat16: #221026 Float16: #221799 Float: #223664 Double: #223714 Long double: #223717 (Note: This one's a metaissue/tracking issue only. The linked sub-issues are open to work on. )

The following functions have been identified so far: BFloat16: ceilbf16 floorbf16 truncbf16 roundbf16 roundevenbf16 fabsbf16 frexpbf16 remquobf16 Float16: fabsf16 frexpf16 remquof16 These functions already have implementations and smoke tests, but are missing MPFR-based coverage. Their float and double counterparts already have corresponding MPFR tests. Additionally, I'd also like the Bazel files to be updated accordingly. NoteAI policy https://llvm.org/docs/AIToolPolicy.html Mostly not allowed for good first issues

This issue just started for me. I recently updated VS 2026 to the latest release, but I’ve also been adding settings to my .clang-tidy file. Clang-tidy.exe is version “LLVM version 22.1.3” . I don’t know if the version got updated with the latest VS install. The crash is related to the 'bugprone-unique-ptr-array-mismatch' check. If I disable it with “-bugprone-unique-ptr-array-mismatch” , the crash does not happen. The recent changes to my .clang-tidy file were not related to any “bugprone*” settings. I don’t have a simple repro case at this time. The referenced line (242 in socket.h) interestingly contains a coding error that was flagged recently, but hadn't yet been addressed. Fixing the bug in our code stops clang-tidy.exe from crashing. const std::unique_ptr <char> b( new char[l] ); should be: const std::unique_ptr<char[]> b( new char[l] ); Below is the stack dump from when the error existed in our code. Build started at 11:22 AM... 1>------ Build st

clang-repl asserts when -fdelayed-template-parsing is enabled (the default in MSVC-compatibility mode) and a late-parsed template is instantiated from a later incremental fragment: $ cat repro.cpp namespace ns { template <typename T> int f(T) { return 0; } } ns::f(1); $ clang-repl -Xcc -fdelayed-template-parsing < repro.cpp clang-repl: clang/lib/Sema/SemaDecl.cpp:1385: void clang::Sema::PushDeclContext(Scope*, DeclContext*): Assertion `DC->getLexicalParent() == CurContext && "The next DeclContext should be lexically contained in the current one."' failed. The declaration shape asserts too (int y = ns::f(1);), so this is not specific to TopLevelStmtDecl statements — any cross-fragment instantiation of a late-parsed template hits it. Stack: IncrementalParser::Parse → ActOnEndOfTranslationUnitFragment → PerformPendingInstantiations → InstantiateFunctionDefinition → Parser::ParseLateTemplatedFuncDef → Sema::PushDeclContext (assert). The pending instantiation runs at the end of

So long as no overflow happens, llvm.[su]cmp are scale- and translation-invariant, but those folds seem to be missing. For example, these two currently don't fold: https://llvm.godbolt.org/z/cb8q16536 define noundef i8 @demo_addu(i12 noundef %a, i12 noundef %b, i12 noundef %n) unnamed_addr #0 { start: %an = add nuw i12 %a, %n %bn = add nuw i12 %b, %n %_0 = call i8 @llvm.ucmp.i8.i12(i12 %an, i12 %bn) ret i8 %_0 } define noundef i8 @demo_mulu(i12 noundef %a, i12 noundef %b, i12 noundef range(i12 1, 0) %n) unnamed_addr #0 { start: %an = mul nuw i12 %a, %n %bn = mul nuw i12 %b, %n %_0 = call i8 @llvm.ucmp.i8.i12(i12 %an, i12 %bn) ret i8 %_0 } But Alive2 confirms that they should collapse, like https://alive2.llvm.org/ce/z/wdGE-_ define i8 @src(i12 noundef %a, i12 noundef %b, i12 noundef %n) noundef { start: %an = add nuw i12 noundef %a, noundef %n %bn = add nuw i12 noundef %b, noundef %n %_0 = ucmp i8 i12 %an, %bn %#range_0_%_0 = !range i8 %_0, i8 255, i8 2 ret i