[llvm-bugs] [Bug 91925] vector-transpose-lowering.mlir

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

91925




Summary

vector-transpose-lowering.mlir




  Labels
  
mlir
  



  Assignees
  
  



  Reporter
  
  banach-space
  







___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 91926] [Flang][OpenMP] Incorrect execution result when an if clause is specified for a dependent task in a sibling task that has a task dependency

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

91926




Summary

[Flang][OpenMP] Incorrect execution result when an if clause is specified for a dependent task in a sibling task that has a task dependency




  Labels
  
openmp,
flang
  



  Assignees
  
  



  Reporter
  
  ohno-fj
  




```
Version of flang-new : 19.0.0(1a498103ee5c4d101e70dc49db11938d8b87b518)/AArch64
```

In `sibling tasks` that have `task dependence`, when an `if` clause (the result is .false.) is specified for a `dependent task`, the execution result is incorrect.

The result is correct when line 27 of the program is changed as follows:
- Change `scalar-logical-_expression_` result specified in `if` clause from .false. to .true.
```
!$omp task shared(x) depend(in: x) if(x .ne. 0) ! if(.true.)
```
- Delete the `if` clause
```
!$omp task shared(x) depend(in: x)  ! no if clause
```

The following are the test program, Flang-new, Gfortran and ifort compilation/execution result.

taskdepend_054_2231.f90:
```fortran
module taskdepend_mod
  integer, parameter :: ans=1
contains
  subroutine init(x)
integer :: x
x = 2
  end subroutine init
 subroutine test(x)
integer :: x
if (x .ne. ans) then
 print *, "NG"
else
   print *, "OK"
end if
  end subroutine test
end module taskdepend_mod

program main
  use taskdepend_mod
  integer :: x
  call init(x)
!$omp parallel
!$omp single
!$omp task shared(x) depend(out: x)
  x = x - 1
!$omp end task
!$omp task shared(x) depend(in: x) if(x .eq. 0) ! if(.false.)
 call test(x)
!$omp end task
!$omp end single
!$omp end parallel
end program main
```

```
$ export OMP_NUM_THREADS=2; flang-new -fopenmp taskdepend_054_2231.f90; ./a.out
 NG
$
```

```
$ export OMP_NUM_THREADS=2; gfortran -fopenmp taskdepend_054_2231.f90; ./a.out
 OK
$
```

```
$ export OMP_NUM_THREADS=2; ifort -qopenmp -diag-disable=10448 taskdepend_054_2231.f90; ./a.out
 OK
$
```



___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 91928] [Flang][OpenMP] Compilation error when lastprivate clause specified in do construct has a derived type with an allocatable variable

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

91928




Summary

[Flang][OpenMP] Compilation error when lastprivate clause specified in do construct has a derived type with an allocatable variable




  Labels
  
openmp,
flang
  



  Assignees
  
  



  Reporter
  
  ohno-fj
  




```
Version of flang-new : 19.0.0(1a498103ee5c4d101e70dc49db11938d8b87b518)/AArch64
```

When `lastprivate` clause specified in `do` construct has a `derived type` with an allocatable variable, a compilation terminates abnormally.  
When `lastprivate` clause in `do` construct is removed, a compilation terminates normally.

The following are the test program, Flang-new, Gfortran and ifort compilation/execution result.

lp10_32.f90:
```fortran
subroutine s4
  type y3
 integer,allocatable::x
  end type y3
  type(y3)::v
 allocate(v%x)
  v%x=0
!$omp parallel
  if (.not. allocated(v%x)) print *,'101'
!$omp do lastprivate(v)
  do i=1,10
 v%x=i
 end do
!$omp end do
!$omp end parallel
end subroutine s4

program main
  call s4
  print *,'pass'
end program main
```

```
$ export OMP_NUM_THREADS=2; flang-new -fopenmp lp10_32.f90; ./a.out

fatal Fortran runtime error(/work/home/ohno/CT/test/fort/tp/reproducerJ/fomp_omp40/lp10_32.f90:12): Assign: mismatching types (to code 64 != from code 9)
fatal Fortran runtime error(/work/home/ohno/CT/test/fort/tp/reproducerJ/fomp_omp40/lp10_32.f90:12): Assign: mismatching types (to code 64 != from code 9)

Aborted (core dumped)
$
```

```
$ export OMP_NUM_THREADS=2; gfortran -fopenmp lp10_32.f90; ./a.out
 pass
$
```

```
$ export OMP_NUM_THREADS=2; ifort -qopenmp -diag-disable=10448 lp10_32.f90; ./a.out
 pass
$
```



___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 91927] [Flang][OpenMP] Incorrect execution result of an assignment statement in task construct in taskgroup construct

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

91927




Summary

[Flang][OpenMP] Incorrect execution result of an assignment statement in task construct in taskgroup construct




  Labels
  
openmp,
flang
  



  Assignees
  
  



  Reporter
  
  ohno-fj
  




```
Version of flang-new : 19.0.0(1a498103ee5c4d101e70dc49db11938d8b87b518)/AArch64
```

The attached program (An assignment statement in `task shared` construct in `taskgroup` construct) has incorrect results.  
When `task shared` construct is removed, the results are correct.

The following are the test program, Flang-new, Gfortran and ifort compilation/execution result.

taskgroup_003_22.f90:
```fortran
program main
 integer, dimension(10) :: a
  a = 0
  write(6,*) "1 : a = ", a
!$omp parallel private(i)
!$omp sections
!$omp section
!$omp taskgroup
  do i=1,10
!$omp task shared(a)
!$omp atomic write
 a(i) = 1
!$omp end task
  end do
!$omp end taskgroup
 write(6,*) "2 : a = ", a
!$omp end sections
!$omp end parallel
end program main
```

```
$ flang-new -fopenmp taskgroup_003_22.f90; ./a.out
 1 : a =  0 0 0 0 0 0 0 0 0 0
 2 : a =  0 0 0 0 0 0 0 0 0 0
$
```

```
$ gfortran -fopenmp taskgroup_003_22.f90; ./a.out
 1 : a =0   0   0   0 0   0   0   0   0   0
 2 : a = 1   1   1   1   1   1 1   1   1   1
 $
```

```
$ ifort -qopenmp -diag-disable=10448 taskgroup_003_22.f90; ./a.out
 1 : a = 0   0   0   0   0
   0 0   0   0   0
 2 : a =1   1 1   1   1
   1   1   1 1   1
$
```



___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 91929] [Flang][OpenMP] Compilation error when the variables used in an `update-statement` in `atomic` construct are declared with different types

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

91929




Summary

[Flang][OpenMP] Compilation error when the variables used in an `update-statement` in `atomic` construct are declared with different types




  Labels
  
openmp,
flang
  



  Assignees
  
  



  Reporter
  
  ohno-fj
  




```
Version of flang-new : 19.0.0(1a498103ee5c4d101e70dc49db11938d8b87b518)/AArch64
```

When the variables (`x` and `expr`) used in an `update-statement` in `atomic` construct are declared with different types, a compilation terminates abnormally.  
When both variables are declared of the same type, a compilation terminates normally.

The following are the test program, Flang-new, Gfortran and ifort compilation/execution result.

OMP_3_O_007_4_atm_expr_027_up_323.f90:
```fortran
program main
  integer(kind=4) :: s_x, i
! integer(kind=4) :: s_expr
 real(kind=4):: s_expr
  s_x= 3
  s_expr = 3.0
!$omp atomic ! update
  s_x = s_x + s_expr
!$omp end atomic
  write(6,*) 's_x = ', s_x, ', s_expr = ', s_expr
end program main
```

```
$ flang-new -fopenmp -L${LLVM_DIR}/lib OMP_3_O_007_4_atm_expr_027_up_323.f90; ./a.out
error: loc("/work/home/ohno/CT/test/fort/tp/reproducerJ/fomp_omp40/OMP_3_O_007_4_atm_expr_027_up_323.f90":6:3): no atomic update operation with region argument as operand found inside atomic.update region
error: loc("/work/home/ohno/CT/test/fort/tp/reproducerJ/fomp_omp40/OMP_3_O_007_4_atm_expr_027_up_323.f90":6:3): LLVM Translation failed for operation: omp.atomic.update
error: failed to create the LLVM module
$
```

```
$ export OMP_NUM_THREADS=2; gfortran -fopenmp OMP_3_O_007_4_atm_expr_027_up_323.f90; ./a.out
 s_x = 6 , s_expr =3.
$
```

```
$ export OMP_NUM_THREADS=2; ifort -qopenmp OMP_3_O_007_4_atm_expr_027_up_323.f90; ./a.out
 s_x =6 , s_expr =3.00
$
```



___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 91934] [libc][docs] Outdated Code Review section in 'libc/src/math/docs/add_math_function.md'

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

91934




Summary

[libc][docs] Outdated Code Review section in 'libc/src/math/docs/add_math_function.md'




  Labels
  
libc
  



  Assignees
  
  



  Reporter
  
  cyuria
  




Found this outdated section in the developer docs.
https://github.com/llvm/llvm-project/blob/ae2a18d6cbc3328410bdb7e629fdc59766b73e4b/libc/src/math/docs/add_math_function.md?plain=1#L197-L202
The section mentions and links to phabricator.
Possible Solutions:
- Remove entirely, using github should be implicit I think
- Change to mention github's PR review system
- Do nothing, it doesn't pose any problems, although the link is outdated


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 91937] [GlobalISel] CSEMIRBuilder Performance

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

91937




Summary

[GlobalISel] CSEMIRBuilder Performance




  Labels
  
llvm:globalisel
  



  Assignees
  
  



  Reporter
  
  Pierre-vh
  




Opening this issue to track performance improvement ideas for CSEMIRBuilder in GlobalISel.

I did some profiling and I found that CSEMIRBuilder takes a non-negligible amount of time, about 2%.
0.8% of that is MachineIRBuilder::buildInstr, so that means CSEMIRBuilder adds a 150% overhead to a normal MIR builder.

![image](https://github.com/llvm/llvm-project/assets/29600849/f3463047-ba7b-466c-96c3-05cd16453033)



___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 91948] MIPS: P5600 should use nan2008, fp64, msa

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

91948




Summary

MIPS: P5600 should use nan2008, fp64, msa




  Labels
  
new issue
  



  Assignees
  
  



  Reporter
  
  wzssyqa
  




```
$ ./bin/clang --target=mips -march=p5600 -mmsa -S pp.c -v
clang version 19.0.0git (g...@github.com:wzssyqa/llvm-project.git 5ca368501ae81ca364f66ee6053aa4f8104fdbdd)
Target: mips
Thread model: posix
InstalledDir: /data/syq/git-push/llvm-project.github/build-amd64/bin
Build config: +unoptimized, +assertions
 (in-process)
 "/data/syq/git-push/llvm-project.github/build-amd64/bin/clang-19" -cc1 -triple mips -S -disable-free -clear-ast-before-backend -main-file-name pp.c -mrelocation-model static -mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -target-cpu p5600 -target-feature -noabicalls -target-feature +msa -target-feature +fp64 -target-abi o32 -mfloat-abi hard -debugger-tuning=gdb -fdebug-compilation-dir=/data/syq/git-push/llvm-project.github/build-amd64 -v -fcoverage-compilation-dir=/data/syq/git-push/llvm-project.github/build-amd64 -resource-dir /data/syq/git-push/llvm-project.github/build-amd64/lib/clang/19 -ferror-limit 19 -fgnuc-version=4.2.1 -fskip-odr-check-in-gmf -fno-relaxed-template-template-args -fcolor-diagnostics -faddrsig -o pp.s -x c pp.c
error: '-mfp64' can only be used if the target supports the mfhc1 and mthc1 instructions



$ ./bin/clang --target=mips -march=p5600 -S pp.c -v
clang version 19.0.0git (g...@github.com:wzssyqa/llvm-project.git 5ca368501ae81ca364f66ee6053aa4f8104fdbdd)
Target: mips
Thread model: posix
InstalledDir: /data/syq/git-push/llvm-project.github/build-amd64/bin
Build config: +unoptimized, +assertions
 (in-process)
 "/data/syq/git-push/llvm-project.github/build-amd64/bin/clang-19" -cc1 -triple mips -S -disable-free -clear-ast-before-backend -main-file-name pp.c -mrelocation-model static -mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -target-cpu p5600 -target-feature -noabicalls -target-abi o32 -mfloat-abi hard -debugger-tuning=gdb -fdebug-compilation-dir=/data/syq/git-push/llvm-project.github/build-amd64 -v -fcoverage-compilation-dir=/data/syq/git-push/llvm-project.github/build-amd64 -resource-dir /data/syq/git-push/llvm-project.github/build-amd64/lib/clang/19 -ferror-limit 19 -fgnuc-version=4.2.1 -fskip-odr-check-in-gmf -fno-relaxed-template-template-args -fcolor-diagnostics -faddrsig -o pp.s -x c pp.c
clang -cc1 version 19.0.0git based upon LLVM 19.0.0git default target x86_64-unknown-linux-gnu
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /data/syq/git-push/llvm-project.github/build-amd64/lib/clang/19/include
 /usr/include
End of search list.

```


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] Issue 68141 in oss-fuzz: llvm: Coverage build failure

2024-05-13 Thread ClusterFuzz-External via monorail via llvm-bugs

Comment #4 on issue 68141 by ClusterFuzz-External: llvm: Coverage build failure
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=68141#c4

Friendly reminder that the build is still failing.
Please try to fix this failure to ensure that fuzzing remains productive.
Latest build log: 
https://oss-fuzz-build-logs.storage.googleapis.com/log-fa9511e1-c91e-466a-95b4-4cf17cabe584.txt

-- 
You received this message because:
  1. You were specifically CC'd on the issue

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

Reply to this email to add a comment.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 91952] ``: `ranges::ends_with`'s constraint check for bidirectional case is not quite right

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

91952




Summary

``: `ranges::ends_with`'s constraint check for bidirectional case is not quite right




  Labels
  
new issue
  



  Assignees
  
  



  Reporter
  
  hewillk
  




`ranges::ends_with` only checks whether the two sentinel types satisfy `bidirectional_iterator` then unconditionally warps all iterators and sentinels into `reverse_iterator`s.

https://github.com/llvm/llvm-project/blob/19a62fbe00930d7eaa9f948c8dd26d58f5422c00/libcxx/include/__algorithm/ranges_ends_with.h#L67-L69

There are two implicit issues here. First, theoretically, the iterator can still not satisfy `bidirectional_iterator` in such case, which makes the construction of `reverse_iterator` ill-formed. Second, the reference of sentinels and iterators may not be the same, which makes the predicate and projection functions not necessarily applicable to the `reverse_iterator`.

The following demos the issue:

```cpp
#include 
#include 

struct Proj {
  int operator()(auto&);
  int operator()(const auto&) = delete;
};

int main() {
  std::list l;
 std::ranges::subrange s{l.begin(), l.cend()};
  return std::ranges::ends_with(s, s, {}, Proj{}, Proj{}); // hard error in libc++
}
```
https://godbolt.org/z/xrMdreWEv


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 91957] Miscompile with opt -passes="loop-unroll, loop-mssa(licm, indvars)" -unroll-count=4

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

91957




Summary

Miscompile with opt -passes="loop-unroll,loop-mssa(licm,indvars)" -unroll-count=4 




  Labels
  
new issue
  



  Assignees
  
  



  Reporter
  
  mikaelholmen
  




llvm commit: e76b257483e6c
Reproduce with:
```opt -passes="loop-unroll,loop-mssa(licm,indvars)" -unroll-count=4 bbi-95405.ll -S -o -```

The input function returns 32768, but after running the passes as above we get
```
define i16 @foo() {
entry:
  br label %loop

loop: ; preds = %loop, %entry
  br i1 false, label %loop, label %end, !llvm.loop !0

end: ; preds = %loop
  ret i16 8192
}

!0 = distinct !{!0, !1}
!1 = !{!"llvm.loop.unroll.disable"}
```
So now the function returns 8192 instead.

If I extract the IR after loop-unroll or licm and run the rest of the passes instead I get the correct result.

[bbi-95405.ll.gz](https://github.com/llvm/llvm-project/files/15294896/bbi-95405.ll.gz)



___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 91959] Poor diagnostic quality for operators that cannot be used as fold-operator

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

91959




Summary

Poor diagnostic quality for operators that cannot be used as fold-operator




  Labels
  
new issue
  



  Assignees
  
  



  Reporter
  
  Eisenwave
  




```cpp
template 
void awoo(Ts... args) {
(args <=> ...);
}
```
For this code, clang outputs (https://godbolt.org/z/xozTW66rY):
```
:3:15: error: expected _expression_
3 | (args <=> ...);
  | ^
```
There are also less than ideal diagnostics for `->` (and I assume, some other operators that cannot be folded over).

Presumably, this happens because `(args <=> ...)` is not parsed as a fold-_expression_ at all, so you get some syntax error. It may be better to parse it as a fold-_expression_ but immediately reject it with an error such as
> `<=>` is not a fold operator.


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 91973] Do you still need commit access?

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

91973




Summary

Do you still need commit access?




  Labels
  
infrastructure:commit-access
  



  Assignees
  
  



  Reporter
  
  tstellar
  




### TLDR: If you want to retain your commit access, please comment on this issue.  Otherwise, you can unsubscribe from this issue and ignore it.  Commit access is not required to contribute to the project.  You can still create Pull Requests without commit access.

@AdamMagierFOSS @DylanFleming-arm @PeixinQiao @piggynl @kavitha-natarajan @ipriyanshi1708 @MarsPLR @Yunzezhu94 @hau-hsu @nirvedhmeshram @mohammed-nurulhoque @realqhc @v1nh1shungry @komalon1 @nhuhuan @tyb-arm @Sophia957 @wjschmidt @el-sc @dpenry

LLVM has a policy of downgrading write access to its repositories for accounts with long term inactivity. This is done because inactive accounts with high levels of access tend to be at increased risk of compromise and this is one tactic that the project employs to guard itself from malicious actors.  Note that write access is not required to contribute to the project.  You can still submit pull requests and have someone else merge them.

Our project policy is to ping anyone with less than five 'interactions' with the repositories over a 12 month period to see if they still need commit access.  An 'interaction' and be any one of:

* Pushing a commit.
* Merging a pull request (either their own or someone else’s).
* Commenting on a PR.

If you want to retain your commit access, please post a comment on this issue.  If you do not want to keep your commit access, you can just ignore this issue.  If you have not responded in 6 weeks, then you will move moved from the 'write' role within the project to the 'triage' role.  The 'triage' role is still a privileged role and will allow you to do the following:

* Review Pull Requests.
* Comment on issues.
* Apply/dismiss labels.
* Close, reopen, and assign all issues and pull requests.
* Apply milestones.
* Mark duplicate issues and pull requests.
* Request pull request reviews.
* Hide anyone’s comments.



___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 91975] Assertion `Elt->getBitWidth() == EltVT.getSizeInBits() && "APInt size does not match type size!"' failed.

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

91975




Summary

Assertion `Elt->getBitWidth() == EltVT.getSizeInBits() && "APInt size does not match type size!"' failed.




  Labels
  
new issue
  



  Assignees
  
  



  Reporter
  
  DigOrDog
  




# Description
The following code crashes aarch64 backend with "Assertion `Elt->getBitWidth() == EltVT.getSizeInBits() && "APInt size does not match type size!"' failed."

# Minimal Reproduction
https://godbolt.org/z/6Kvh5oeT8

## Code
```
; ModuleID = 'Fuzzer input'
source_filename = "M"

@G = global ppc_fp128 0xM7FF0

define i1 @f(i1 %0, i8 %1, i64 %2) {
BB:
  %CastFPTrunc1 = fpext float 4.20e+01 to x86_fp80
  %CastExt = sext i16 0 to i32
  %CastFPTrunc = fpext float 0x47EFE000 to ppc_fp128
  %RP = alloca i1, i32 %CastExt, align 1
  %3 = load i1, ptr %RP, align 1
  store ppc_fp128 %CastFPTrunc, ptr @G, align 16
  store x86_fp80 %CastFPTrunc1, ptr %RP, align 16
  ret i1 %3
}
```

## Stack Trace
```
llc: /root/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:1703: llvm::SDValue llvm::SelectionDAG::getConstant(const llvm::ConstantInt&, const llvm::SDLoc&, llvm::EVT, bool, bool): Assertion `Elt->getBitWidth() == EltVT.getSizeInBits() && "APInt size does not match type size!"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.	Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/llc -o /app/output.s -x86-asm-syntax=intel -mtriple aarch64 -global-isel -O0 
1.	Running pass 'Function Pass Manager' on module ''.
2.	Running pass 'AArch64 Instruction Selection' on function '@f'
 #0 0x0399e058 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x399e058)
 #1 0x0399b7ac SignalHandler(int) Signals.cpp:0:0
 #2 0x7a02eb242520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
 #3 0x7a02eb2969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
 #4 0x7a02eb242476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
 #5 0x7a02eb2287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
 #6 0x7a02eb22871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
 #7 0x7a02eb239e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
 #8 0x0372fa81 llvm::SelectionDAG::getConstant(llvm::ConstantInt const&, llvm::SDLoc const&, llvm::EVT, bool, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x372fa81)
 #9 0x0384f5aa llvm::DAGTypeLegalizer::SoftenFloatRes_ConstantFP(llvm::SDNode*) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x384f5aa)
#10 0x03862fa2 llvm::DAGTypeLegalizer::SoftenFloatResult(llvm::SDNode*, unsigned int) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x3862fa2)
#11 0x037f2ed3 llvm::DAGTypeLegalizer::run() (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x37f2ed3)
#12 0x037f3d59 llvm::SelectionDAG::LegalizeTypes() (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x37f3d59)
#13 0x037664b4 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x37664b4)
#14 0x03769f45 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x3769f45)
#15 0x0376b9b7 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (.part.0) SelectionDAGISel.cpp:0:0
#16 0x029af0d1 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.0) MachineFunctionPass.cpp:0:0
#17 0x02f70f83 llvm::FPPassManager::runOnFunction(llvm::Function&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x2f70f83)
#18 0x02f711c1 llvm::FPPassManager::runOnModule(llvm::Module&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x2f711c1)
#19 0x02f71a25 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x2f71a25)
#20 0x0082dfcc compileModule(char**, llvm::LLVMContext&) llc.cpp:0:0
#21 0x0072b486 main (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x72b486)
#22 0x7a02eb229d90 (/lib/x86_64-linux-gnu/libc.so.6+0x29d90)
#23 0x7a02eb229e40 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e40)
#24 0x00824aee _start (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x824aee)
Program terminated with signal: SIGSEGV
Compiler returned: 139
```


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 91978] [mlir][spirv] Add vulkan runner integration tests for `vector.shuffle` / `vector.interleave`

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

91978




Summary

[mlir][spirv] Add vulkan runner integration tests for `vector.shuffle` / `vector.interleave` 




  Labels
  
help wanted,
good first issue,
mlir:spirv
  



  Assignees
  
  



  Reporter
  
  kuhar
  




These go through several layers of decomposition / unrolling / emulation when targeting SPIR-V and it would be good to have e2e coverage there.

The new tests should be added under: https://github.com/llvm/llvm-project/tree/main/mlir/test/mlir-vulkan-runner


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 91979] LLVM ERROR: Unsupported library call operation!

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

91979




Summary

LLVM ERROR: Unsupported library call operation!




  Labels
  
new issue
  



  Assignees
  
  



  Reporter
  
  DigOrDog
  




# Description
The following code crashes aarch64 backend with "LLVM ERROR: Unsupported library call operation!"

# Minimal Reproduction
https://godbolt.org/z/h3zvfE69b

## Code
```
; ModuleID = 'Fuzzer input'
source_filename = "M"

@G = global float 0x36A0
@G.1 = global <32 x i2> 

define i32 @f() {
BB:
  %A2 = alloca x86_fp80, align 16
  store x86_fp80 undef, ptr %A2, align 16
  %A = alloca <32 x i2>, align 8
  %L1 = load float, ptr %A, align 4
  store <32 x i2> undef, ptr %A, align 8
  %CastIToFP = sitofp i64 -1 to float
  %RP = alloca i32, align 4
  %CastFPTrunc = fpext float %L1 to x86_fp80
  %L = load i64, ptr %RP, align 4
  %Castbitcast = bitcast i64 %L to <32 x i2>
  %0 = load i32, ptr %RP, align 4
  store float %CastIToFP, ptr @G, align 4
 %Castbitcast1 = bitcast i64 %L to <32 x i2>
  store <32 x i2> %Castbitcast, ptr %A, align 8
  store <32 x i2> %Castbitcast1, ptr @G.1, align 8
  store x86_fp80 %CastFPTrunc, ptr %A2, align 16
  ret i32 %0
}
```

## Stack Trace
```
LLVM ERROR: Unsupported library call operation!
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.	Program arguments: /opt/compiler-explorer/clang-trunk/bin/llc -o /app/output.s -x86-asm-syntax=intel -mtriple=aarch64 -O=0 
1.	Running pass 'Function Pass Manager' on module ''.
2.	Running pass 'AArch64 Instruction Selection' on function '@f'
 #0 0x0369cd38 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-trunk/bin/llc+0x369cd38)
 #1 0x0369a6ac SignalHandler(int) Signals.cpp:0:0
 #2 0x781980a42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
 #3 0x781980a969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
 #4 0x781980a42476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
 #5 0x781980a287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
 #6 0x00729d2e llvm::UniqueStringSaver::save(llvm::StringRef) (.cold) StringSaver.cpp:0:0
 #7 0x035f53f8 (/opt/compiler-explorer/clang-trunk/bin/llc+0x35f53f8)
 #8 0x034dc187 llvm::TargetLowering::makeLibCall(llvm::SelectionDAG&, llvm::RTLIB::Libcall, llvm::EVT, llvm::ArrayRef, llvm::TargetLowering::MakeLibCallOptions, llvm::SDLoc const&, llvm::SDValue) const (/opt/compiler-explorer/clang-trunk/bin/llc+0x34dc187)
 #9 0x0356e08f llvm::DAGTypeLegalizer::SoftenFloatRes_FP_EXTEND(llvm::SDNode*) (/opt/compiler-explorer/clang-trunk/bin/llc+0x356e08f)
#10 0x0356e44b llvm::DAGTypeLegalizer::SoftenFloatResult(llvm::SDNode*, unsigned int) (/opt/compiler-explorer/clang-trunk/bin/llc+0x356e44b)
#11 0x03501aa2 llvm::DAGTypeLegalizer::run() (/opt/compiler-explorer/clang-trunk/bin/llc+0x3501aa2)
#12 0x035020f1 llvm::SelectionDAG::LegalizeTypes() (/opt/compiler-explorer/clang-trunk/bin/llc+0x35020f1)
#13 0x03478a21 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/opt/compiler-explorer/clang-trunk/bin/llc+0x3478a21)
#14 0x0347b868 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/opt/compiler-explorer/clang-trunk/bin/llc+0x347b868)
#15 0x0347e049 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (.part.0) SelectionDAGISel.cpp:0:0
#16 0x027d3810 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.0) MachineFunctionPass.cpp:0:0
#17 0x02cf7af2 llvm::FPPassManager::runOnFunction(llvm::Function&) (/opt/compiler-explorer/clang-trunk/bin/llc+0x2cf7af2)
#18 0x02cf7c71 llvm::FPPassManager::runOnModule(llvm::Module&) (/opt/compiler-explorer/clang-trunk/bin/llc+0x2cf7c71)
#19 0x02cf9920 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/opt/compiler-explorer/clang-trunk/bin/llc+0x2cf9920)
#20 0x0083e4f4 compileModule(char**, llvm::LLVMContext&) llc.cpp:0:0
#21 0x0073befe main (/opt/compiler-explorer/clang-trunk/bin/llc+0x73befe)
#22 0x781980a29d90 (/lib/x86_64-linux-gnu/libc.so.6+0x29d90)
#23 0x781980a29e40 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e40)
#24 0x0083613e _start (/opt/compiler-explorer/clang-trunk/bin/llc+0x83613e)
Program terminated with signal: SIGSEGV
Compiler returned: 139
```


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 91982] [clang-tidy] modernize-min-max-use-initializer-list

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

91982




Summary

[clang-tidy] modernize-min-max-use-initializer-list




  Labels
  
clang-tidy
  



  Assignees
  
  



  Reporter
  
  VReichelt
  




Running the recently intoroduced clang-tidy check `modernize-min-max-use-initializer-list` on the following valid code snippet triggers an assertion:

```
clang-tidy: /LLVM/llvm-project/llvm/include/llvm/Support/Casting.h:706: auto llvm::cast_if_present(Y*) [with X = clang::Expr; Y = const clang::Stmt]: Assertion `isa(Val) && "cast_if_present() argument of incompatible type!"' failed.
```
```
#include 

int x() const;
int y() const;
int z() const;

int foo()
{
  return std::max(x(), std::max(y(), z()));
}
```

Stacktrace attached
[Crash.txt](https://github.com/llvm/llvm-project/files/15296684/Crash.txt)



___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 91983] Incorrect promise constructor used with lambda coroutines

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

91983




Summary

Incorrect promise constructor used with lambda coroutines




  Labels
  
new issue
  



  Assignees
  
  



  Reporter
  
  landelare
  




In the C++20 program below, the lambda has a non-static member operator(), but its object parameter is skipped when looking for a promise constructor overload. This results in the first overload being called, and an output of `Wrong`.

Tested on 18.1.5 and 19.0.0git (b5af667b01458e9083256f2614df175916c73e5a). When compiled with GCC or MSVC, the output is `Correct`, as expected.

Additionally, removing the second constructor should make the resulting program no longer compile, which is the case with MSVC and GCC, but not Clang.

```c++
#include 
#include 

struct coro {};

struct promise {
promise(int) {std::cout << "Wrong\n";}
 promise(auto, int){std::cout << "Correct\n";} // Remove me for an additional test case!

coro get_return_object() {return {};}
 std::suspend_never initial_suspend() {return {};}
std::suspend_never final_suspend() noexcept {return {};}
void return_value(int) {}
 void unhandled_exception() {}
};

template
struct std::coroutine_traits {
using promise_type = promise;
};

int main() {
int x = 0;
[x](int y) -> coro { co_return x + y; }(1);
}
```


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 91996] lldb on windows: The debugger crashes when trying to print a `shared_ptr`

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

91996




Summary

lldb on windows: The debugger crashes when trying to print a `shared_ptr`




  Labels
  
new issue
  



  Assignees
  
  



  Reporter
  
  sigasigasiga
  




```cpp
#include 
#include 

int main() {
std::shared_ptr p;
std::cout << p << std::endl;
}
```

Given the code above which was compiled with `clang++ -g3 cpp.cpp` I'm unable to print the contents of `p`:
```gdb
$ lldb a.exe
(lldb) target create "a.exe"
(lldb) Current executable set to 'C:\dev\toy\a.exe' (x86_64).
(lldb) process launch -m
(lldb) Process 24372 launched: 'C:\dev\toy\a.exe' (x86_64)
Process 24372 stopped
* thread #1, stop reason = one-shot breakpoint 1
frame #0: 0x7ff71ba4bd60 a.exe`main at cpp.cpp:4
 1#include 
   2#include 
   3
-> 4int main() {
   5std::shared_ptr p;
   6std::cout << p << std::endl;
   7}
(lldb) n
Process 24372 stopped
* thread #1, stop reason = step over
frame #0: 0x7ff71ba4bd7a a.exe`main at cpp.cpp:5
   2#include 
   3
   4int main() {
-> 5std::shared_ptr p;
   6std::cout << p << std::endl;
   7}
(lldb) p p
error: a.exe :: Class 'std::strong_ordering' has a member 'less' of type 'std::strong_ordering' which does not have a complete definition.
error: a.exe :: Class 'std::partial_ordering' has a member 'less' of type 'std::partial_ordering' which does not have a complete definition.
error: a.exe :: Class 'std::weak_ordering' has a member 'less' of type 'std::weak_ordering' which does not have a complete definition.
(lldb) LLDB diagnostics will be written to C:\Users\EGORBY~1\AppData\Local\Temp\diagnostics-dbd91a
Please include the directory content when filing a bug report
Exception Code: 0xC005
 #0 0x7ffcc890e457 (C:\Program Files\LLVM\bin\liblldb.dll+0x12de457)
 #1 0x7ffcc86a27dd (C:\Program Files\LLVM\bin\liblldb.dll+0x10727dd)
 #2 0x7ffcc86a72d8 (C:\Program Files\LLVM\bin\liblldb.dll+0x10772d8)
 #3 0x7ffcc86a6136 (C:\Program Files\LLVM\bin\liblldb.dll+0x1076136)
 #4 0x7ffcc86a4d80 (C:\Program Files\LLVM\bin\liblldb.dll+0x1074d80)
 #5 0x7ffcc7fdbc18 (C:\Program Files\LLVM\bin\liblldb.dll+0x9abc18)
 #6 0x7ffcc86de283 (C:\Program Files\LLVM\bin\liblldb.dll+0x10ae283)
 #7 0x7ffcc802756f (C:\Program Files\LLVM\bin\liblldb.dll+0x9f756f)
 #8 0x7ffcc803b824 (C:\Program Files\LLVM\bin\liblldb.dll+0xa0b824)
 #9 0x7ffcc803fc46 (C:\Program Files\LLVM\bin\liblldb.dll+0xa0fc46)
#10 0x7ffcc8681c52 (C:\Program Files\LLVM\bin\liblldb.dll+0x1051c52)
#11 0x7ffcc7fba997 (C:\Program Files\LLVM\bin\liblldb.dll+0x98a997)
#12 0x7ffcc8041600 (C:\Program Files\LLVM\bin\liblldb.dll+0xa11600)
#13 0x7ffcc7de0a32 (C:\Program Files\LLVM\bin\liblldb.dll+0x7b0a32)
#14 0x7ff723dfe925 (C:\Program Files\LLVM\bin\lldb.exe+0xe925)
#15 0x7ff723dff328 (C:\Program Files\LLVM\bin\lldb.exe+0xf328)
#16 0x7ff723e0c790 (C:\Program Files\LLVM\bin\lldb.exe+0x1c790)
#17 0x7ffdccc2257d (C:\Windows\System32\KERNEL32.DLL+0x1257d)
#18 0x7ffdce94aa48 (C:\Windows\SYSTEM32\ntdll.dll+0x5aa48)
Segmentation fault
```

The diagnostics file is not very interesting, as it duplicates the information in the error output
```
a.exe :: Class 'std::strong_ordering' has a member 'less' of type 'std::strong_ordering' which does not have a complete definition.a.exe :: Class 'std::partial_ordering' has a member 'less' of type 'std::partial_ordering' which does not have a complete definition.a.exe :: Class 'std::weak_ordering' has a member 'less' of type 'std::weak_ordering' which does not have a complete definition.
```

---

Versions
```
> cl
Microsoft (R) C/C++ Optimizing Compiler Version 19.39.33519 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

> clang++ --version
clang version 18.1.4
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin

> lldb --version
lldb version 18.1.4
```


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 91997] [SPIR-V] Inconsistent representation of SPIR-V builtins types as either simple types or pointers to types

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

91997




Summary

[SPIR-V] Inconsistent representation of SPIR-V builtins types as either simple types or pointers to types




  Labels
  
backend:SPIR-V
  



  Assignees
  
michalpaszkowski
  



  Reporter
  
  michalpaszkowski
  




SPIRVEmitIntrinsics pass inconsistently assigns types to values representing SPIR-V or OpenCL builtin using either `spv_assign_type` or `spv_assign_ptr_type`. This leads to issues in compilation e.g. when casting the types between address spaces or during runtime e.g. when passing to builtin functions.

Example of a kernel with the issue:
```
define spir_kernel void @foo() {
  %event = alloca ptr, align 8
  %call = call spir_func ptr @_Z29async_work_group_strided_copyPU3AS3hPU3AS1Khmm9ocl_event(ptr null, ptr null, i64 1, i64 1, ptr null)
  store ptr %call, ptr %event, align 8
 %event.ascast = addrspacecast ptr %event to ptr addrspace(4)
  call spir_func void @_Z17wait_group_eventsiPU3AS49ocl_event(i32 2, ptr addrspace(4) %event.ascast)
  ret void
}

declare spir_func ptr @_Z29async_work_group_strided_copyPU3AS3hPU3AS1Khmm9ocl_event(ptr, ptr, i64, i64, ptr)

declare spir_func void @_Z17wait_group_eventsiPU3AS49ocl_event(i32, ptr addrspace(4))
```


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 91998] [SPIR-V] The order of instructions leads to errors in pointer element type deduction or crashes compilation

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

91998




Summary

[SPIR-V] The order of instructions leads to errors in pointer element type deduction or crashes compilation




  Labels
  
backend:SPIR-V
  



  Assignees
  
michalpaszkowski
  



  Reporter
  
  michalpaszkowski
  




The current implementation of SPIRVEmitIntrinsics sometimes allows generating duplicate `spv_assign_ptr_type` and `spv_assign_type` intrinsics.

In these cases the order of instructions (and which intrinsic is selected first) plays a role in correct type deduction. In other words, the order of instructions or operands sometimes leads to incorrect type deduction or compilation crashes.

TODO: Add a simple test case


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 92000] Missed coalescing of adjacent writes to stack variables

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

92000




Summary

Missed coalescing of adjacent writes to stack variables




  Labels
  
new issue
  



  Assignees
  
  



  Reporter
  
  Bryce-MW
  




Here's a simple reproduction: https://godbolt.org/z/5dza4c787 (should be `mov qword ptr[rsp], 0`). I know that LLVM can coalesce known adjacent writes. The problem here is that these variables are not known to be adjacent until stack slot allocation which I know happens during target code generation so this isn't solvable at the IR level. I suspect that means that the solution would have to be per-target (currently, I can reproduce this on every arch that compiler explorer has though I am not proficient in non-x86_64 asm so I could be wrong).


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 92015] [clang] -Wmissing-include-dirs not implemented

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

92015




Summary

[clang] -Wmissing-include-dirs not implemented




  Labels
  
clang
  



  Assignees
  
  



  Reporter
  
  aeubanks
  




Clang accepts but does not implement gcc's -Wmissing-include-dirs, which warns if a non-existent path is specified to `-I` (or any of the other similar arguments).

https://gcc.gnu.org/pipermail/gcc-patches/2004-May/139462.html


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 92023] Wdocumentation false postive warning for a

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

92023




Summary

Wdocumentation false postive warning for a 




  Labels
  
new issue
  



  Assignees
  
  



  Reporter
  
  andrei-sandor
  




Here is a bug regarding a Doxygen annotation for a struct.

Given the file structDoxygenFinal.cxx:

```c++
/**
 * \struct BooleanDispatch
 * \brief A comment here
*/

template 
struct BooleanDispatch
{};

int main ()
{
  return 0;
}
```

Run this command:

```
clang++ -Wdocumentation -std=c++14 -fsyntax-only structDoxygenFinal.cxx
```

The following warning will be generated 

```
structDoxygenFinal.cxx:3:5: warning: '@struct' command should not be used in a comment attached to a non-struct declaration [-Wdocumentation]
 * \struct BooleanDispatch
 ~^~
1 warning generated.
```

To fix this warning, the comment could be placed between Template and
struct BooleanDispatch in structDoxygenFinal.cxx

Is it fine, if in general, a Doxygen comment with \struct is placed between a template
statement and a struct statement?


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 92033] [clang-cl] Using pointer to member as argument to template in the same class results in incorrect layout

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

92033




Summary

[clang-cl] Using pointer to member as argument to template in the same class results in incorrect layout




  Labels
  
new issue
  



  Assignees
  
  



  Reporter
  
  erikolofsson
  




https://godbolt.org/z/ddhddo9zP
### Reproduction
`-target x86_64-windows -std=c++23`
```
struct TestStruct {
};

template 
struct TestTemplate {
constexpr static int constexprStaticValue = 0;

 template 
struct InnerStruct {
};

using InnerType = InnerStruct;
};

struct TestRecursive {
TestStruct link;
 TestTemplate<&TestRecursive::link> tree;
};

void TestFrame() {
 TestRecursive Test; 
}
```
### Warning
```
:24:6: error: stack frame size (118115794992) exceeds limit (4294967295) in 'void __cdecl TestFrame(void)' [-Werror,-Wframe-larger-than
```

The same code works when targeting macOS or Linux. 

Cloud be related to: https://github.com/llvm/llvm-project/issues/80806

A workaround is to replace the `constexpr static` with an `enum`.



___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 92035] Clang 18.1.6 crashes in TestFind with SIMD tag with hwy::float16_t lane type on AVX512_FP16

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

92035




Summary

Clang 18.1.6 crashes in TestFind with SIMD tag with hwy::float16_t lane type on AVX512_FP16




  Labels
  
clang
  



  Assignees
  
  



  Reporter
  
  johnplatts
  




Here is the crash that occurs when compiling TestFind for vector types that have a SIMD tag with a lane type of hwy::float16_t for x86_64 with `-march=sapphirerapids` when compiled with Clang 18.1.6:
```
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.	Program arguments: /usr/bin/clang++-18 -DHWY_STATIC_DEFINE -DTOOLCHAIN_MISS_ASM_HWCAP_H -I/home/jplatts/jepprojects/hwy_avx3_dl_clang_f16_051324/jep_google_highway -isystem /home/jplatts/jepprojects/hwy_avx3_dl_clang_f16_051324/avx3_spr_build/googletest-src/googletest/include -isystem /home/jplatts/jepprojects/hwy_avx3_dl_clang_f16_051324/avx3_spr_build/googletest-src/googletest -march=sapphirerapids -DHWY_COMPILE_ONLY_STATIC=1 -ftrapv -O2 -g -DNDEBUG -fPIE -fvisibility=hidden -fvisibility-inlines-hidden -Wno-builtin-macro-redefined -D__DATE__=\"redacted\" -D__TIMESTAMP__=\"redacted\" -D__TIME__=\"redacted\" -fmerge-all-constants -Wall -Wextra -Wconversion -Wsign-conversion -Wvla -Wnon-virtual-dtor -Wcast-align -Wfloat-overflow-conversion -Wfloat-zero-conversion -Wfor-loop-analysis -Wgnu-redeclared-enum -Winfinite-recursion -Wself-assign -Wstring-conversion -Wtautological-overlap-compare -Wthread-safety-analysis -Wundefined-func-template -fno-cxx-exceptions -fno-slp-vectorize -fno-vectorize -fdiagnostics-show-option -fcolor-diagnostics -Wc++2a-extensions -fmath-errno -fno-exceptions -Wno-psabi -Werror -DHWY_IS_TEST=1 -std=c++14 -MD -MT CMakeFiles/find_test.dir/hwy/contrib/algo/find_test.cc.o -MF CMakeFiles/find_test.dir/hwy/contrib/algo/find_test.cc.o.d -o CMakeFiles/find_test.dir/hwy/contrib/algo/find_test.cc.o -c /home/jplatts/jepprojects/hwy_avx3_dl_clang_f16_051324/jep_google_highway/hwy/contrib/algo/find_test.cc
1.	 parser at end of file
2.	Code generation
3.	Running pass 'Function Pass Manager' on module '/home/jplatts/jepprojects/hwy_avx3_dl_clang_f16_051324/jep_google_highway/hwy/contrib/algo/find_test.cc'.
4.	Running pass 'Early Machine Loop Invariant Code Motion' on function '@_ZN3hwy10N_AVX3_SPR8TestFindclINS0_4SimdINS_9float16_tELm32ELi0EvT_mmRNS_11RandomStateE'
#0 0x7d32a19946d6 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/lib/llvm-18/bin/../lib/libLLVM.so.18.1+0xd946d6)
#1 0x7d32a1992690 llvm::sys::RunSignalHandlers() (/usr/lib/llvm-18/bin/../lib/libLLVM.so.18.1+0xd92690)
#2 0x7d32a18e41b0 (/usr/lib/llvm-18/bin/../lib/libLLVM.so.18.1+0xce41b0)
#3 0x7d32a0442520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x7d32a47f44f4 (/usr/lib/llvm-18/bin/../lib/libLLVM.so.18.1+0x3bf44f4)
clang++-18: error: clang frontend command failed with exit code 139 (use -v to see invocation)
Ubuntu clang version 18.1.6 (++20240513065742+09615ce869b0-1~exp1~20240513065903.119)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
clang++-18: note: diagnostic msg: 


PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang++-18: note: diagnostic msg: /tmp/find_test-aae644.cpp
clang++-18: note: diagnostic msg: /tmp/find_test-aae644.sh
clang++-18: note: diagnostic msg: 


make[3]: *** [CMakeFiles/find_test.dir/build.make:76: CMakeFiles/find_test.dir/hwy/contrib/algo/find_test.cc.o] Error 1
make[2]: *** [CMakeFiles/Makefile2:1169: CMakeFiles/find_test.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:1176: CMakeFiles/find_test.dir/rule] Error 2
make: *** [Makefile:621: find_test] Error 2
```

Attached are preprocessed soruces and run script:
[avx3_spr_f16_find_test_051324_0418pm.zip](https://github.com/llvm/llvm-project/files/15300105/avx3_spr_f16_find_test_051324_0418pm.zip)

The same code compiles successfully with GCC 12 or later.


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 92054] Factor `Error` and `Expected` boilerplate return-macros

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

92054




Summary

Factor `Error` and `Expected` boilerplate return-macros




  Labels
  
new issue
  



  Assignees
  
  



  Reporter
  
  mtrofin
  




Examples: [`RETURN_IF_ERROR` and `ASSIGN_OR_RETURN`](https://github.com/llvm/llvm-project/blob/c3028a230557405b0f10bdd7d450f7f92747bbe3/llvm/tools/llvm-rc/ResourceScriptParser.cpp#L20-L30) or [these](https://github.com/llvm/llvm-project/blob/c3028a230557405b0f10bdd7d450f7f92747bbe3/llvm/unittests/tools/llvm-profdata/OutputSizeLimitTest.cpp#L56-L70) with a slightly different name.

The idea is to place them in Error.h


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 92056] Inconsistent results when using --buffer-deallocation

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

92056




Summary

Inconsistent results when using --buffer-deallocation




  Labels
  
new issue
  



  Assignees
  
  



  Reporter
  
  wangyongj1a
  




I have the following MLIR program:
test.mlir:
```
module {
  func.func @func0(%arg0: tensor<19xi32>) -> (){
%0 = arith.constant 2 : index
%1 = tensor.extract %arg0[%0] : tensor<19xi32>
vector.print %1 : i32
 return
  }
  func.func private @func1() {
%0 = arith.constant 10 : i32
%1 = tensor.from_elements %0 : tensor<1xi32>
%2 = tensor.from_elements %0, %0, %0, %0, %0, %0, %0, %0, %0, %0, %0, %0, %0, %0, %0, %0, %0, %0, %0 : tensor<19xi32>
call @func0(%2) : (tensor<19xi32>) -> ()
return
  }
}
```
When I tried to lower the program with  ```mlir-opt --tensor-bufferize --buffer-deallocation --convert-scf-to-cf --convert-cf-to-llvm --func-bufferize --convert-func-to-llvm --convert-index-to-llvm --convert-vector-to-llvm --finalize-memref-to-llvm --convert-arith-to-llvm --reconcile-unrealized-casts test.mlir```, and executed the executable file, I got inconsistent results over multiple runs.
I noticed that after using the passes ```--tensor-bufferize --buffer-deallocation```, the program was lowered to:
```
module {
  func.func @func0(%arg0: tensor<19xi32>) {
%0 = bufferization.to_memref %arg0 : memref<19xi32>
%c2 = arith.constant 2 : index
%1 = memref.load %0[%c2] : memref<19xi32>
 vector.print %1 : i32
return
  }
  func.func private @func1() {
%c10_i32 = arith.constant 10 : i32
%alloc = memref.alloc() {alignment = 64 : i64} : memref<1xi32>
%c0 = arith.constant 0 : index
memref.store %c10_i32, %alloc[%c0] : memref<1xi32>
 memref.dealloc %alloc : memref<1xi32>
%alloc_0 = memref.alloc() {alignment = 64 : i64} : memref<19xi32>
%c0_1 = arith.constant 0 : index
%c1 = arith.constant 1 : index
%c2 = arith.constant 2 : index
%c3 = arith.constant 3 : index
%c4 = arith.constant 4 : index
%c5 = arith.constant 5 : index
%c6 = arith.constant 6 : index
%c7 = arith.constant 7 : index
%c8 = arith.constant 8 : index
%c9 = arith.constant 9 : index
%c10 = arith.constant 10 : index
%c11 = arith.constant 11 : index
%c12 = arith.constant 12 : index
%c13 = arith.constant 13 : index
%c14 = arith.constant 14 : index
%c15 = arith.constant 15 : index
%c16 = arith.constant 16 : index
%c17 = arith.constant 17 : index
%c18 = arith.constant 18 : index
memref.store %c10_i32, %alloc_0[%c0_1] : memref<19xi32>
memref.store %c10_i32, %alloc_0[%c1] : memref<19xi32>
memref.store %c10_i32, %alloc_0[%c2] : memref<19xi32>
memref.store %c10_i32, %alloc_0[%c3] : memref<19xi32>
memref.store %c10_i32, %alloc_0[%c4] : memref<19xi32>
memref.store %c10_i32, %alloc_0[%c5] : memref<19xi32>
memref.store %c10_i32, %alloc_0[%c6] : memref<19xi32>
memref.store %c10_i32, %alloc_0[%c7] : memref<19xi32>
memref.store %c10_i32, %alloc_0[%c8] : memref<19xi32>
memref.store %c10_i32, %alloc_0[%c9] : memref<19xi32>
memref.store %c10_i32, %alloc_0[%c10] : memref<19xi32>
memref.store %c10_i32, %alloc_0[%c11] : memref<19xi32>
memref.store %c10_i32, %alloc_0[%c12] : memref<19xi32>
memref.store %c10_i32, %alloc_0[%c13] : memref<19xi32>
memref.store %c10_i32, %alloc_0[%c14] : memref<19xi32>
memref.store %c10_i32, %alloc_0[%c15] : memref<19xi32>
memref.store %c10_i32, %alloc_0[%c16] : memref<19xi32>
memref.store %c10_i32, %alloc_0[%c17] : memref<19xi32>
memref.store %c10_i32, %alloc_0[%c18] : memref<19xi32>
%0 = bufferization.to_tensor %alloc_0 : memref<19xi32>
memref.dealloc %alloc_0 : memref<19xi32>
call @func0(%0) : (tensor<19xi32>) -> ()
return
  }
}
```
The memory of ```%alloc_0``` seems to be deallocated before the related tensor ```%0``` was used as an attribute in the function call. I also tried to use the pass ```--buffer-deallocation-simplification``` after ```--buffer-deallocation```, but it seems couldn't help with this case. 
I'm not sure if there is any bug in my program or the wrong usage of ```--buffer-deallocation``` and ```--buffer-deallocation-simplification``` that caused this error.
My git version is 4c79d38f82e1f6fe8575d88d8c74f2f1806b19ce.


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 92057] Crash

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

92057




Summary

Crash




  Labels
  
new issue
  



  Assignees
  
  



  Reporter
  
  wangyongj1a
  




I have the following MLIR program:
test.mlir:
```
func.func @func1() {
  %1 = arith.constant 5 : i16
  %i0 = arith.constant 0 : index
  %3 = tensor.from_elements %1, %1, %1, %1, %1, %1, %1, %1, %1, %1, %1, %1  : tensor<12xi16>
  %10 = arith.extsi %3 : tensor<12xi16> to tensor
  %7 = tensor.dim %10, %i0 : tensor
 return
}
```
The above MLIR program will cause a crash when using the following command:
```
mlir-opt --canonicalize test.mlir
```
And the crash backtrace is:
```
mlir-opt: /data/tmp/v0514/llvm-project/mlir/lib/IR/BuiltinAttributes.cpp:1342: static mlir::DenseElementsAttr mlir::DenseIntOrFPElementsAttr::getRaw(mlir::ShapedType, llvm::ArrayRef): Assertion `type.hasStaticShape() && "type must have static shape"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.  Program arguments: /data/tmp/v0514/llvm-project/build/bin/mlir-opt --canonicalize test.mlir
 #0 0x559cf13586ef llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x15946ef)
 #1 0x559cf1355744 SignalHandler(int) Signals.cpp:0:0
 #2 0x7f5be1cbb420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
 #3 0x7f5be178800b raise (/lib/x86_64-linux-gnu/libc.so.6+0x4300b)
 #4 0x7f5be1767859 abort (/lib/x86_64-linux-gnu/libc.so.6+0x22859)
 #5 0x7f5be1767729 (/lib/x86_64-linux-gnu/libc.so.6+0x22729)
 #6 0x7f5be1778fd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
 #7 0x559cf4427f58 mlir::DenseIntOrFPElementsAttr::getRaw(mlir::ShapedType, llvm::ArrayRef) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x4663f58)
 #8 0x559cf442924a mlir::DenseIntOrFPElementsAttr::getRaw(mlir::ShapedType, unsigned long, llvm::ArrayRef) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x466524a)
 #9 0x559cf4429559 mlir::DenseElementsAttr::get(mlir::ShapedType, llvm::ArrayRef) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x4665559)
#10 0x559cf15d5bd1 mlir::arith::ExtSIOp::fold(mlir::arith::ExtSIOpGenericAdaptor>) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x1811bd1)
#11 0x559cf1631e07 mlir::LogicalResult llvm::detail::UniqueFunctionBase, llvm::SmallVectorImpl&>::CallImpl::Impl, mlir::OpTrait::ZeroSuccessors, mlir::OpTrait::OneOperand, mlir::OpTrait::OpInvariants, mlir::InferIntRangeInterface::Trait, mlir::ConditionallySpeculatable::Trait, mlir::OpTrait::AlwaysSpeculatableImplTrait, mlir::MemoryEffectOpInterface::Trait, mlir::OpTrait::SameOperandsAndResultShape, mlir::CastOpInterface::Trait, mlir::VectorUnrollOpInterface::Trait, mlir::OpTrait::Elementwise, mlir::OpTrait::Scalarizable, mlir::OpTrait::Vectorizable, mlir::OpTrait::Tensorizable>::getFoldHookFn()::'lambda'(mlir::Operation*, llvm::ArrayRef, llvm::SmallVectorImpl&) const>(void*, mlir::Operation*, llvm::ArrayRef, llvm::SmallVectorImpl&) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x186de07)
#12 0x559cf1629376 mlir::RegisteredOperationName::Model::foldHook(mlir::Operation*, llvm::ArrayRef, llvm::SmallVectorImpl&) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x1865376)
#13 0x559cf44dee34 mlir::Operation::fold(llvm::ArrayRef, llvm::SmallVectorImpl&) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x471ae34)
#14 0x559cf44df1c8 mlir::Operation::fold(llvm::SmallVectorImpl&) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x471b1c8)
#15 0x559cf437a72e (anonymous namespace)::GreedyPatternRewriteDriver::processWorklist() GreedyPatternRewriteDriver.cpp:0:0
#16 0x559cf437d81b mlir::applyPatternsAndFoldGreedily(mlir::Region&, mlir::FrozenRewritePatternSet const&, mlir::GreedyRewriteConfig, bool*) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x45b981b)
#17 0x559cf42e900a (anonymous namespace)::Canonicalizer::runOnOperation() Canonicalizer.cpp:0:0
#18 0x559cf42c9881 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x4505881)
#19 0x559cf42c9d6a mlir::detail::OpToOpPassAdaptor::runPipeline(mlir::OpPassManager&, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int, mlir::PassInstrumentor*, mlir::PassInstrumentation::PipelineParentInfo const*) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x4505d6a)
#20 0x559cf42ca524 mlir::PassManager::run(mlir::Operation*) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x4506524)
#21 0x559cf42bb9ab performActions(llvm::raw_ostream&, std::shared_ptr const&, mlir::MLIRContext*, mlir::MlirOptMainConfig const&) MlirOptMain.cpp:0:0
#22 0x559cf42bc364 processBuffer(llvm::raw_ostream&, std::unique_ptr>, mlir::MlirOptMainConfig const&, mlir::Dial

[llvm-bugs] [Bug 92059] What does this "%mlir_cuda_runtime" refer to?

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

92059




Summary

What does this "%mlir_cuda_runtime"  refer to?




  Labels
  
new issue
  



  Assignees
  
  



  Reporter
  
  BruceDai003
  




https://github.com/llvm/llvm-project/blob/e20800c16f0570562fea31e9a02d65ba56e6858a/mlir/test/Integration/GPU/CUDA/all-reduce-and.mlir#L4

Hello, I'm new to these tests, don't know what these `"%mlir_cuda_runtime", "%mlir_runner_utils", cubin-format=%gpu_compilation_format"` refer to. Could anybody tell me what they are? Thanks.


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 92060] fatal error: error in backend: unknown codeview register HSI

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

92060




Summary

fatal error: error in backend: unknown codeview register HSI




  Labels
  
new issue
  



  Assignees
  
  



  Reporter
  
  oocpp
  




11:32:37:733	1>fatal error: error in backend: unknown codeview register HSI
11:32:37:733	1>PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
11:32:37:733	1>Stack dump:
11:32:37:734	1>0.	Program arguments: "C:\\Program Files\\Microsoft Visual Studio\\2022\\Preview\\VC\\Tools\\Llvm\\x64\\bin\\clang-cl.exe" @G:\\link\\Temp\\MSBuildTemp\\tmp281af428f5694b638d1d08c26d8b7191.rsp
11:32:37:734	1>1.	 parser at end of file
11:32:37:734	1>2.	Code generation
11:32:37:734	1>3.	Running pass 'Function Pass Manager' on module 'G:\code\CCCreator3\Effect\Business\Base\Framework\BEFEffect\Parser\ParserFactory.cpp'.
11:32:37:734	1>4.	Running pass 'X86 Assembly Printer' on function '@"??1?$pair@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$function@$$A6APEAVBaseParser@BEF@@XZ@2@@std@@QEAA@XZ"'
11:32:37:734	1>Exception Code: 0xE046
11:32:37:789	1> #0 0x7fff9045ab89 (C:\Windows\System32\KERNELBASE.dll+0x2ab89)
11:32:37:794	1> #1 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x501b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x502049
11:32:37:794	1> #2 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x9021 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x520a8c
11:32:37:794	1> #3 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x68595d C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x1941974
11:32:37:794	1> #4 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x1941d9f C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x1948008
11:32:37:794	1> #5 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x1f69139 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x659e77
11:32:37:794	1> #6 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x2405e4 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x6d823d
11:32:37:794	1> #7 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x3824a8 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x3885b3
11:32:37:794	1> #8 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x382b37 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x14cb704
11:32:37:794	1> #9 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x189764e C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x314cf84
11:32:37:794	1>#10 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x1801582 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x5bd4cd
11:32:37:794	1>#11 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x64fdde C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x8bd6
11:32:37:794	1>#12 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x53a9 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x168e28d
11:32:37:794	1>#13 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x501aa5 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x168da5e
11:32:37:794	1>#14 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x5a82e5 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x5a862e
11:32:37:794	1>#15 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x58e66b C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x4c2a
11:32:37:794	1>#16 0x7ff69b391b8a C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\

[llvm-bugs] Issue 65424 in oss-fuzz: llvm:llvm-special-case-list-fuzzer: Stack-overflow in p_ere

2024-05-13 Thread ClusterFuzz-External via monorail via llvm-bugs
Updates:
Status: WontFix

Comment #1 on issue 65424 by ClusterFuzz-External: 
llvm:llvm-special-case-list-fuzzer: Stack-overflow in p_ere
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=65424#c1

ClusterFuzz testcase 5593834478174208 is closed as invalid, so closing issue.

-- 
You received this message because:
  1. You were specifically CC'd on the issue

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

Reply to this email to add a comment.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 92061] [clang-tidy] create a check that looks for constructing a string from a nullptr

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

92061




Summary

[clang-tidy] create a check that looks for constructing a string from a nullptr




  Labels
  
enhancement,
good first issue,
clang-tidy
  



  Assignees
  
  



  Reporter
  
  LegalizeAdulthood
  




Consider the following code:

```
std::string foo()
{
return nullptr;
}
```
See [compiler explorer example](https://godbolt.org/z/azW348cbd)

This code compiles just fine with no warnings or errors, but crashes when you run it.  We should be able to detect cases where a `nullptr` is used to construct a string, at least in the simple case above.  I had a real-world bug that was exactly the above scenario, although I have simplified the example to remove irrelevant code. Obviously more sophisticated data flow analysis can propagate `nullptr` through usages until it hits a `std::basic_string` constructor, but even detecting the above simple case would be a useful start.


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 92062] [RegBankSelect] Assertion `N < NumContainedTys && "Element number out of range!"'

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

92062




Summary

[RegBankSelect] Assertion `N < NumContainedTys && "Element number out of range!"'




  Labels
  
backend:ARM,
llvm:codegen,
crash-on-valid
  



  Assignees
  
  



  Reporter
  
  DianQK
  




I tried the following code:

```llvm
target triple = "arm64"

@p = external global { {}, { ptr } }

define void @foo() {
bb:
  %i1 = load ptr, ptr @p, align 8
  store ptr %i1, ptr null, align 8
  ret void
}
```

When using llc in LLVM 18, the following error occurs:

```
llc: /root/llvm-project/llvm/include/llvm/IR/DerivedTypes.h:343: llvm::Type* llvm::StructType::getElementType(unsigned int) const: Assertion `N < NumContainedTys && "Element number out of range!"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.	Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/llc -o /app/output.s -x86-asm-syntax=intel -O0 
1.	Running pass 'Function Pass Manager' on module ''.
2.	Running pass 'RegBankSelect' on function '@foo'
...
 #8 0x00b27667 llvm::AArch64RegisterBankInfo::isLoadFromFPType(llvm::MachineInstr const&) const (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0xb27667)
 #9 0x00b2b155 llvm::AArch64RegisterBankInfo::getInstrMapping(llvm::MachineInstr const&) const (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0xb2b155)
#10 0x04203f47 llvm::RegBankSelect::assignInstr(llvm::MachineInstr&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x4203f47)
#11 0x042044d3 llvm::RegBankSelect::assignRegisterBanks(llvm::MachineFunction&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x42044d3)
...
Compiler returned: 139
```

https://llvm.godbolt.org/z/a4h1abfKc


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 92064] Crash when using --pass-pipeline="builtin.module(func.func(tosa-to-linalg))"

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

92064




Summary

Crash when using --pass-pipeline="builtin.module(func.func(tosa-to-linalg))"




  Labels
  
new issue
  



  Assignees
  
  



  Reporter
  
  wangyongj1a
  




I have the following MLIR program:
test.mlir:
```
module {
  func.func nested @func1() {
%33 = tensor.empty() : tensor<1x1x1xi1>
%output_real, %output_imag = "tosa.rfft2d"(%33) : (tensor<1x1x1xi1>) -> (tensor<1x1x1xi1>, tensor<1x1x1xi1>)
return
  }
}
```
The above MLIR program will cause a crash when using the following command:
```
mlir-opt --pass-pipeline="builtin.module(func.func(tosa-to-linalg))" test.mlir
```
And the crash backtrace is:
```
mlir-opt: /data/tmp/v0514/llvm-project/llvm/include/llvm/Support/Casting.h:566: decltype(auto) llvm::cast(const From&) [with To = mlir::FloatType; From = mlir::Type]: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.  Program arguments: /data/tmp/v0514/llvm-project/build/bin/mlir-opt --pass-pipeline=builtin.module(func.func(tosa-to-linalg)) test.mlir
 #0 0x556fdf39c6ef llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x15946ef)
 #1 0x556fdf399744 SignalHandler(int) Signals.cpp:0:0
 #2 0x7fa27c8c7420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
 #3 0x7fa27c39400b raise (/lib/x86_64-linux-gnu/libc.so.6+0x4300b)
 #4 0x7fa27c373859 abort (/lib/x86_64-linux-gnu/libc.so.6+0x22859)
 #5 0x7fa27c373729 (/lib/x86_64-linux-gnu/libc.so.6+0x22729)
 #6 0x7fa27c384fd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
 #7 0x556fe1bf7a2e (anonymous namespace)::RFFT2dConverter::matchAndRewrite(mlir::tosa::RFFT2dOp, mlir::PatternRewriter&) const TosaToLinalg.cpp:0:0
 #8 0x556fe1bc552f mlir::detail::OpOrInterfaceRewritePatternBase::matchAndRewrite(mlir::Operation*, mlir::PatternRewriter&) const (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x3dbd52f)
 #9 0x556fe52d41a8 mlir::PatternApplicator::matchAndRewrite(mlir::Operation*, mlir::PatternRewriter&, llvm::function_ref, llvm::function_ref, llvm::function_ref) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x74cc1a8)
#10 0x556fe23ab396 (anonymous namespace)::OperationLegalizer::legalize(mlir::Operation*, mlir::ConversionPatternRewriter&) DialectConversion.cpp:0:0
#11 0x556fe23acb9e mlir::OperationConverter::convert(mlir::ConversionPatternRewriter&, mlir::Operation*) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x45a4b9e)
#12 0x556fe23b289b mlir::OperationConverter::convertOperations(llvm::ArrayRef) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x45aa89b)
#13 0x556fe23b2eed mlir::applyFullConversion(mlir::Operation*, mlir::ConversionTarget const&, mlir::FrozenRewritePatternSet const&, mlir::ConversionConfig) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x45aaeed)
#14 0x556fe1bba34d (anonymous namespace)::TosaToLinalg::runOnOperation() TosaToLinalgPass.cpp:0:0
#15 0x556fe230d881 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x4505881)
#16 0x556fe230dd6a mlir::detail::OpToOpPassAdaptor::runPipeline(mlir::OpPassManager&, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int, mlir::PassInstrumentor*, mlir::PassInstrumentation::PipelineParentInfo const*) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x4505d6a)
#17 0x556fe230e6fc mlir::detail::OpToOpPassAdaptor::runOnOperationAsyncImpl(bool)::'lambda'(mlir::detail::OpToOpPassAdaptor::runOnOperationAsyncImpl(bool)::OpPMInfo&)::operator()(mlir::detail::OpToOpPassAdaptor::runOnOperationAsyncImpl(bool)::OpPMInfo&) const Pass.cpp:0:0
#18 0x556fe230cdd5 mlir::detail::OpToOpPassAdaptor::runOnOperationAsyncImpl(bool) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x4504dd5)
#19 0x556fe230d606 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x4505606)
#20 0x556fe230dd6a mlir::detail::OpToOpPassAdaptor::runPipeline(mlir::OpPassManager&, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int, mlir::PassInstrumentor*, mlir::PassInstrumentation::PipelineParentInfo const*) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x4505d6a)
#21 0x556fe230e524 mlir::PassManager::run(mlir::Operation*) (/data/tmp/v0514/llvm-project/build/bin/mlir-opt+0x4506524)
#22 0x556fe22ff9ab performActions(llvm::raw_ostream&, std::shared_ptr const&, mlir::MLIRContext*, mlir::MlirOptMainConfig const&) MlirOptMain.cpp:0:0
#23 0x556fe2300364 processBuffer(llvm::raw_ostream&, std::unique_ptr>, mlir::MlirOptMainC

[llvm-bugs] [Bug 92069] Inconsistent result with --sparsification-and-bufferization and tensor.empty

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

92069




Summary

Inconsistent result with --sparsification-and-bufferization and tensor.empty




  Labels
  
new issue
  



  Assignees
  
  



  Reporter
  
  Anonymous15592
  




Consider the following MLIR program:
a.mlir:
```
module {
  func.func @tensor_i32(%arg0: tensor<1xi32>) -> i32 {
%idx0 = index.constant 0
%0 = tensor.extract %arg0[%idx0] : tensor<1xi32>
return %0 : i32
  }
 func.func @func1() {
%c1_i32 = arith.constant 1 : i32
%c0_i32 = arith.constant 0 : i32
%c0 = arith.constant 0 : index
%5 = tensor.empty() : tensor<1xi32> // using empty
// %5 = tensor.from_elements %c0_i32 : tensor<1xi32>

%inserted_28 = tensor.insert %c1_i32 into %5[%c0] : tensor<1xi32>
%31 = call @tensor_i32(%inserted_28) : (tensor<1xi32>) -> i32
%308 = tensor.extract %5[%c0] : tensor<1xi32>
// vector.print %31 : i32
 vector.print %308 : i32
return
  }
}
```

It will output two different results when applying two different optimization pass sequences:
```pass sequence1```: ```--sparsification-and-bufferization --tensor-bufferize --func-bufferize --convert-func-to-llvm --convert-index-to-llvm --convert-vector-to-llvm --finalize-memref-to-llvm --convert-arith-to-llvm --reconcile-unrealized-casts```
```pass sequence2```: ```--tensor-bufferize --func-bufferize --convert-func-to-llvm --convert-index-to-llvm --convert-vector-to-llvm --finalize-memref-to-llvm --convert-arith-to-llvm --reconcile-unrealized-casts```

The ```pass sequence1``` outputs the executable that outputs 1, while the latter outputs 0.
The difference between ```pass sequence1``` and ```pass sequence2``` is that there is an additional ```--sparsification-and-bufferization``` at the begining of the ```pass sequence1```.

I futher analyze the output of these two sequences:
pass1: ```--sparsification-and-bufferization --tensor-bufferize```
pass2: ```--tensor-bufferize```
The result of ```pass1``` is:
```
module {
  func.func @tensor_i32(%arg0: memref<1xi32>) -> i32 {
%idx0 = index.constant 0
%0 = memref.load %arg0[%idx0] : memref<1xi32>
return %0 : i32
  }
 func.func @func1() {
%c1_i32 = arith.constant 1 : i32
%c0 = arith.constant 0 : index
%alloc = memref.alloc() {alignment = 64 : i64} : memref<1xi32>
memref.store %c1_i32, %alloc[%c0] : memref<1xi32>
%0 = call @tensor_i32(%alloc) : (memref<1xi32>) -> i32
%1 = memref.load %alloc[%c0] : memref<1xi32>
vector.print %1 : i32
return
  }
}
```
The result of ```pass2``` is:
```
module {
  func.func @tensor_i32(%arg0: tensor<1xi32>) -> i32 {
%0 = bufferization.to_memref %arg0 : memref<1xi32>
%idx0 = index.constant 0
%1 = memref.load %0[%idx0] : memref<1xi32>
 return %1 : i32
  }
  func.func @func1() {
%c1_i32 = arith.constant 1 : i32
%c0_i32 = arith.constant 0 : i32
%c0 = arith.constant 0 : index
%alloc = memref.alloc() {alignment = 64 : i64} : memref<1xi32>
%alloc_0 = memref.alloc() {alignment = 64 : i64} : memref<1xi32>
memref.copy %alloc, %alloc_0 : memref<1xi32> to memref<1xi32>
memref.store %c1_i32, %alloc_0[%c0] : memref<1xi32>
 %0 = bufferization.to_tensor %alloc_0 : memref<1xi32>
%1 = call @tensor_i32(%0) : (tensor<1xi32>) -> i32
%2 = memref.load %alloc[%c0] : memref<1xi32>
vector.print %2 : i32
return
 }
}
```

It seems that ```--sparsification-and-bufferization --tensor-bufferize``` treats the operand and the result of ```tensor.insert``` as same tensor(memref), 
when the operand of ```tensor.insert``` is created by ```tensor.empty```.

If I replace the ```tensor.empty``` with ```tensor.from_element```, or just wrap the ```tensor.empty``` with a function. The modified MLIR program will output the same result.
The modified program:
```
module {
  func.func @gen_tensor_i32() -> tensor<1xi32> {
%c0_i32 = arith.constant 0 : i32
%5 = tensor.empty() : tensor<1xi32>
return %5 : tensor<1xi32>
  }
  func.func @tensor_i32(%arg0: tensor<1xi32>) -> i32 {
%idx0 = index.constant 0
%0 = tensor.extract %arg0[%idx0] : tensor<1xi32>
return %0 : i32
  }
  func.func @func1() {
 %c1_i32 = arith.constant 1 : i32
%c0_i32 = arith.constant 0 : i32
 %c0 = arith.constant 0 : index
%5 = call @gen_tensor_i32() : () -> tensor<1xi32>
// %5 = tensor.empty() : tensor<1xi32> // using empty
// %5 = tensor.from_elements %c0_i32 : tensor<1xi32>

 %inserted_28 = tensor.insert %c1_i32 into %5[%c0] : tensor<1xi32>
 %31 = call @tensor_i32(%inserted_28) : (tensor<1xi32>) -> i32
%308 = tensor.extract %5[%c0] : tensor<1xi32>
// vector.print %31 : i32
 vector.print %308 : i32
return
  }
}
```

I wonder if there is some thing wrong with ```--sparsification-and-bufferization``` and ```tensor.empty```.
This result inconsistency may not be a problem because ```tensor.e

[llvm-bugs] [Bug 92071] [HLSL] Default linkage of HLSL functions should be internal

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

92071




Summary

[HLSL] Default linkage of HLSL functions should be internal




  Labels
  
  



  Assignees
  
  



  Reporter
  
  hekota
  




Currently the default linkage of HLSL function is set to external.

This issue is blocking #90095.


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 92073] Enable HLSL diagnostic on exported library functions and add tests

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

92073




Summary

Enable HLSL diagnostic on exported library functions and add tests




  Labels
  
new issue
  



  Assignees
  
  



  Reporter
  
  hekota
  







___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 92074] [ValueTracking] Missed optimization of modulo power-of-two

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

92074




Summary

[ValueTracking] Missed optimization of modulo power-of-two




  Labels
  
new issue
  



  Assignees
  
  



  Reporter
  
  YanWQ-monad
  




Recently I found a missed optimization related to modulo power-of-two. It's

https://github.com/dtcxzyw/llvm-opt-benchmark/blob/b79d63cb8adea5949cc449d4186e342d3dbdd871/bench/wasmtime-rs/optimized/1ham0fg2czw77e66.ll#L235

and it's compiled from [something](https://github.com/bytecodealliance/wasmtime/blob/a6f27eeb7e9ada3f1e10d75630f733b204e2c1ba/cranelift/codegen/meta/src/constant_hash.rs#L12-L42) like

``` rust
let modulo = if size.is_power_of_two() {  // i.e. ctpop(size) == 1
size * 2
} else {
 size.next_power_of_two()
};

let result = xxx % modulo;
```

where `urem xxx, modulo` could be optimized to `and xxx, (modulo - 1)`.

To solve it, I have created a PR #91171 that enables the recognization of `.next_power_of_two()`, and I also have a draft patch that could recognize power-of-two from dom conditions.

However, the key problem in this case is that LLVM currently only search 2 levels beyond `phi` nodes, so the resursion of `isKnownToBeAPowerOfTwo` stops at `size * 2`, and fails to know `size` is a power-of-two from the condition.
https://github.com/llvm/llvm-project/blob/37ffbbb19576a884c5bb93b9ac0ae97f89523b6b/llvm/lib/Analysis/ValueTracking.cpp#L2197-L2199

Though changing `- 1` to `- 3` could make it work in this case, it's obviously not a proper way to solve the problem.

I am not sure if there is a way to handle this complex context across multiple basic blocks, or should we instead patch `wasmtime` to use `let modulo = (size + 1).next_power_of_two()`?

cc @nikic @dtcxzyw 


___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs


[llvm-bugs] [Bug 92075] Running pass 'X86 DAG->DAG Instruction Selection' on function

2024-05-13 Thread LLVM Bugs via llvm-bugs


Issue

92075




Summary

Running pass 'X86 DAG->DAG Instruction Selection' on function




  Labels
  
new issue
  



  Assignees
  
  



  Reporter
  
  oocpp
  




14:48:08:143	1>PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
14:48:08:143	1>Stack dump:
14:48:08:205	1>0.	Program arguments: "C:\\Program Files\\Microsoft Visual Studio\\2022\\Preview\\VC\\Tools\\Llvm\\x64\\bin\\clang-cl.exe" @G:\\link\\Temp\\MSBuildTemp\\tmp4dcfa4a803b54680b871965b6596d9f6.rsp
14:48:08:205	1>1.	 parser at end of file
14:48:08:205	1>2.	Code generation
14:48:08:205	1>3.	Running pass 'Function Pass Manager' on module 'G:\code\CCCreator3\Effect\Business\Base\LuaSystem\LuaBindings.cpp'.
14:48:08:205	1>4.	Running pass 'X86 DAG->DAG Instruction Selection' on function '@"??$_Destroy_range@V?$allocator@UMeshCookingVertex@BEF@@@std@@@std@@YAXPEAUMeshCookingVertex@BEF@@QEAU12@AEAV?$allocator@UMeshCookingVertex@BEF@@@0@@Z"'
14:48:08:205	1>Exception Code: 0xC005
14:48:08:205	1> #0 0x7ff60e3ca004 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x6aa004 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x1b04617
14:48:08:205	1> #1 0x7ff60e3ca004 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x1b023e5 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x1b00092
14:48:08:205	1> #2 0x7ff60e3ca004 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x10aabfc C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x6d823d
14:48:08:205	1> #3 0x7ff60e3ca004 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x3824a8 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x3885b3
14:48:08:205	1> #4 0x7ff60e3ca004 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x382b37 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x14cb704
14:48:08:205	1> #5 0x7ff60e3ca004 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x189764e C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x314cf84
14:48:08:205	1> #6 0x7ff60e3ca004 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x1801582 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x5bd4cd
14:48:08:205	1> #7 0x7ff60e3ca004 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x64fdde C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x8bd6
14:48:08:205	1> #8 0x7ff60e3ca004 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x53a9 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x168e28d
14:48:08:205	1> #9 0x7ff60e3ca004 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x501aa5 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x168da5e
14:48:08:205	1>#10 0x7ff60e3ca004 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x5a82e5 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x5a862e
14:48:08:205	1>#11 0x7ff60e3ca004 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x58e66b C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x4c2a
14:48:08:205	1>#12 0x7ff60e3ca004 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x16f14 C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe 0x459f320
14:48:08:205	1>#13 0x7ff60e3ca004 (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x6aa004)
14:48:08:205	1>#14 0x7ff60f824617 (C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe+0x1b04617)
14:48:08:205	1>0x7FF60E3CA004, C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe(0x7FF60DD2) + 0x6AA004 byte(s)
14:48:08:205	1>0x7FF60F824617, C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\clang-cl.exe(0x7FF60DD2) + 0x1B04617 byte(s)
14:48:08:205	1>0x7FF60F8223E5, C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\Llvm\x64\bin\cl