[llvm-bugs] [Bug 50501] New: JavaScript / TypeScript BreakBeforeBraces Problem
https://bugs.llvm.org/show_bug.cgi?id=50501
Bug ID: 50501
Summary: JavaScript / TypeScript BreakBeforeBraces Problem
Product: clang
Version: 12.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: jkope...@sievers-group.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
In JavaScript and TypeScript I fail to set the BreakBeforeBraces to always.
Moreover by function returns, the format differs according to the last comma
and semicolon. Some of that can be intentional, but I don't see any logic
there.
1) Is there a way to set BreakBeforeBraces to really always in JS and TS?
2) Is the function return behaviour intentional? (it should be actually solved
when 1) is solved
```
enum SampleEnum {
ENUM1,
ENUM2
}
const sampleObject = {
sampleBoolean: true,
sampleInt: 5
};
function noEndComma()
{
return {first: true, last: false};
}
function noColon()
{
return
{
first: true, last: false
}
}
function endCommaAndColon()
{
return {
first: true,
last: false,
};
}
```
my setting:
```
---
Language:JavaScript
BasedOnStyle:Chromium
ColumnLimit: 100
BreakBeforeBraces: Allman
AlignConsecutiveAssignments: 'true'
AlignConsecutiveMacros: 'true'
AlignConsecutiveDeclarations: 'true'
AlignOperands: 'true'
AlignTrailingComments: 'true'
AllowShortBlocksOnASingleLine: 'false'
AllowShortCaseLabelsOnASingleLine: 'false'
AllowShortFunctionsOnASingleLine: None
AllowShortIfStatementsOnASingleLine: 'false'
AllowShortLambdasOnASingleLine: 'false'
AllowShortLoopsOnASingleLine: 'false'
BinPackArguments: 'false'
BinPackParameters: 'false'
BreakBeforeBinaryOperators: None
BreakBeforeTernaryOperators: 'true'
BreakConstructorInitializers: BeforeColon
AlwaysBreakTemplateDeclarations: Yes
ConstructorInitializerAllOnOneLineOrOnePerLine: 'true'
DerivePointerAlignment: 'false'
IncludeBlocks: Preserve
IndentCaseLabels: 'false'
IndentWidth: '4'
KeepEmptyLinesAtTheStartOfBlocks: 'true'
MaxEmptyLinesToKeep: '1'
NamespaceIndentation: 'None'
PenaltyBreakBeforeFirstCallParameter: 19
PenaltyBreakComment: 300
PenaltyBreakFirstLessLess: 120
PenaltyBreakString: 1000
PenaltyExcessCharacter: 100
PenaltyReturnTypeOnItsOwnLine: 60
PointerAlignment: Left
SortIncludes: 'true'
SpaceBeforeAssignmentOperators: 'true'
SpaceBeforeParens: ControlStatements
SpacesInAngles: false
SpacesInContainerLiterals: false
SpaceInEmptyParentheses: 'false'
SpacesInAngles: 'false'
SpacesInCStyleCastParentheses: 'false'
SpacesInParentheses: 'false'
TabWidth: '4'
UseTab: Never
```
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50502] New: LLVM - VSCode AlignConsecutiveDeclarations not working
https://bugs.llvm.org/show_bug.cgi?id=50502 Bug ID: 50502 Summary: LLVM - VSCode AlignConsecutiveDeclarations not working Product: clang Version: 12.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: jkope...@sievers-group.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org I use the xaver.clang-format extension in VS Code. AlignConsecutiveDeclarations: 'true' doesn't do anything, I cannot set it to the values like 'AcrossEmptyLinesAndComments' though. I get 'invalid argument' error ```JavaScript let letVariable = 5; const constVariable = 10; ``` my setting: ``` --- Language:JavaScript BasedOnStyle:Chromium ColumnLimit: 100 BreakBeforeBraces: Allman AlignConsecutiveAssignments: 'true' AlignConsecutiveMacros: 'true' AlignConsecutiveDeclarations: 'true' AlignOperands: 'true' AlignTrailingComments: 'true' AllowShortBlocksOnASingleLine: 'false' AllowShortCaseLabelsOnASingleLine: 'false' AllowShortFunctionsOnASingleLine: None AllowShortIfStatementsOnASingleLine: 'false' AllowShortLambdasOnASingleLine: 'false' AllowShortLoopsOnASingleLine: 'false' BinPackArguments: 'false' BinPackParameters: 'false' BreakBeforeBinaryOperators: None BreakBeforeTernaryOperators: 'true' BreakConstructorInitializers: BeforeColon AlwaysBreakTemplateDeclarations: Yes ConstructorInitializerAllOnOneLineOrOnePerLine: 'true' DerivePointerAlignment: 'false' IncludeBlocks: Preserve IndentCaseLabels: 'false' IndentWidth: '4' KeepEmptyLinesAtTheStartOfBlocks: 'true' MaxEmptyLinesToKeep: '1' NamespaceIndentation: 'None' PenaltyBreakBeforeFirstCallParameter: 19 PenaltyBreakComment: 300 PenaltyBreakFirstLessLess: 120 PenaltyBreakString: 1000 PenaltyExcessCharacter: 100 PenaltyReturnTypeOnItsOwnLine: 60 PointerAlignment: Left SortIncludes: 'true' SpaceBeforeAssignmentOperators: 'true' SpaceBeforeParens: ControlStatements SpacesInAngles: false SpacesInContainerLiterals: false SpaceInEmptyParentheses: 'false' SpacesInAngles: 'false' SpacesInCStyleCastParentheses: 'false' SpacesInParentheses: 'false' TabWidth: '4' UseTab: Never ``` -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50503] New: JavaScript / TypeScript AllowShortLambdasOnASingleLine doesn't work
https://bugs.llvm.org/show_bug.cgi?id=50503
Bug ID: 50503
Summary: JavaScript / TypeScript AllowShortLambdasOnASingleLine
doesn't work
Product: clang
Version: 12.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: jkope...@sievers-group.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
AllowShortLambdasOnASingleLine: 'false'
doesn't work when the function is surrounded by () braces:
```JavaScript
const sampleBraces = (() => {return 25})
const sampleNoBraces = () => {
return 25
}
```
(I already opened ID 50501, because the curl braces are not on the new line)
my setting:
```
---
Language:JavaScript
BasedOnStyle:Chromium
ColumnLimit: 100
BreakBeforeBraces: Allman
AlignConsecutiveAssignments: 'true'
AlignConsecutiveMacros: 'true'
AlignConsecutiveDeclarations: 'true'
AlignOperands: 'true'
AlignTrailingComments: 'true'
AllowShortBlocksOnASingleLine: 'false'
AllowShortCaseLabelsOnASingleLine: 'false'
AllowShortFunctionsOnASingleLine: None
AllowShortIfStatementsOnASingleLine: 'false'
AllowShortLambdasOnASingleLine: 'false'
AllowShortLoopsOnASingleLine: 'false'
BinPackArguments: 'false'
BinPackParameters: 'false'
BreakBeforeBinaryOperators: None
BreakBeforeTernaryOperators: 'true'
BreakConstructorInitializers: BeforeColon
AlwaysBreakTemplateDeclarations: Yes
ConstructorInitializerAllOnOneLineOrOnePerLine: 'true'
DerivePointerAlignment: 'false'
IncludeBlocks: Preserve
IndentCaseLabels: 'false'
IndentWidth: '4'
KeepEmptyLinesAtTheStartOfBlocks: 'true'
MaxEmptyLinesToKeep: '1'
NamespaceIndentation: 'None'
PenaltyBreakBeforeFirstCallParameter: 19
PenaltyBreakComment: 300
PenaltyBreakFirstLessLess: 120
PenaltyBreakString: 1000
PenaltyExcessCharacter: 100
PenaltyReturnTypeOnItsOwnLine: 60
PointerAlignment: Left
SortIncludes: 'true'
SpaceBeforeAssignmentOperators: 'true'
SpaceBeforeParens: ControlStatements
SpacesInAngles: false
SpacesInContainerLiterals: false
SpaceInEmptyParentheses: 'false'
SpacesInAngles: 'false'
SpacesInCStyleCastParentheses: 'false'
SpacesInParentheses: 'false'
TabWidth: '4'
UseTab: Never
```
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50504] New: immediately invoked functions indent
https://bugs.llvm.org/show_bug.cgi?id=50504 Bug ID: 50504 Summary: immediately invoked functions indent Product: clang Version: 12.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: jkope...@sievers-group.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org I don't like the solution here: https://reviews.llvm.org/D32989 It would be better to have an option to decide. The standard style is to indent the iifes, so it is in books and so it is made by esbenp.prettier-vscode, which is by far the most popular formatter in VS Code. Would it be possible to add a boolean to control the setting? -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45899] LLParser fails due to the "non-global-value-max-name-size" limit in Value.cpp
https://bugs.llvm.org/show_bug.cgi?id=45899 Mikael Holmén changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Mikael Holmén --- Fixed with https://reviews.llvm.org/rG8d25762720660aba3344752e577ae7017e6125c2 Thanks! -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37951] error: use of undefined value '%.split.split.split.[...].split.spl171 with "-bounds-checking -aggressive-instcombine -loop-unswitch -loop-rotate -licm -sroa -simple-loop-unswit
https://bugs.llvm.org/show_bug.cgi?id=37951 Mikael Holmén changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Mikael Holmén --- Fixed with https://reviews.llvm.org/rG8d25762720660aba3344752e577ae7017e6125c2 Thanks! -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50505] New: -fno-cuda-host-device-constexpr not supported?
https://bugs.llvm.org/show_bug.cgi?id=50505 Bug ID: 50505 Summary: -fno-cuda-host-device-constexpr not supported? Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: CUDA Assignee: unassignedclangb...@nondot.org Reporter: carlosgalv...@gmail.com CC: llvm-bugs@lists.llvm.org Hi, We are compiling CUDA code with clang 12 (12.0.0~%2b%2b20210319082650%2b4990141a4366-1~exp1~20210319193429.62), and get the following error: error: constexpr function 'foo' without __host__ or __device__ attributes cannot overload __device__ function with same signature. Add a __host__ attribute, or build with -fno-cuda-host-device-constexpr. [clang-diagnostic-error] So we try to add "-fno-cuda-host-device-constexpr" when building, but it seems to be unsupported: clang: error: unknown argument: '-fno-cuda-host-device-constexpr' What should we use instead? -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50506] New: [obj2yaml][yaml2obj] Cannot round-trip clang-produced object file
https://bugs.llvm.org/show_bug.cgi?id=50506 Bug ID: 50506 Summary: [obj2yaml][yaml2obj] Cannot round-trip clang-produced object file Product: new-bugs Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org If you take a trivial clang object file, run it through obj2yaml and then the output through yaml2obj, the latter tool reports an error: C:\Work\TempWork> touch test.cpp C:\Work\TempWork> C:\llvm\build\Debug\bin\clang.exe -c test.cpp C:\Work\TempWork> C:\llvm\build\Debug\bin\obj2yaml.exe test.o -o test.yaml C:\Work\TempWork> C:\llvm\build\Debug\bin\yaml2obj test.yaml -o test2.o yaml2obj: error: section '.shstrtab' should be present in the 'Sections' or 'Excluded' lists The intermediate YAML file looks like this: --- !ELF FileHeader: Class: ELFCLASS64 Data:ELFDATA2LSB Type:ET_REL Machine: EM_X86_64 Sections: - Name:.text Type:SHT_PROGBITS Flags: [ SHF_ALLOC, SHF_EXECINSTR ] AddressAlign:0x4 - Name:.comment Type:SHT_PROGBITS Flags: [ SHF_MERGE, SHF_STRINGS ] AddressAlign:0x1 EntSize: 0x1 Content: 00636C616E672076657273696F6E2031332E302E3000 - Name:.note.GNU-stack Type:SHT_PROGBITS AddressAlign:0x1 - Name:.llvm_addrsig Type:SHT_LLVM_ADDRSIG Flags: [ SHF_EXCLUDE ] Link:.symtab AddressAlign:0x1 Offset: 0x88 Symbols: [ ] - Type:SectionHeaderTable Sections: - Name:.strtab - Name:.text - Name:.comment - Name:.note.GNU-stack - Name:.llvm_addrsig - Name:.symtab Symbols: - Name:test.cpp Type:STT_FILE Index: SHN_ABS ... The problem is the presence of the SectionHeaderTable key. Deleting it causes the error to go away. The SectionHeaderTable key however is necessary to faithfully represent the input object file: the section data in that object file is not in the same order as the section header table. Additionally, clang quite reasonably produces a single combined string table for the symbol and section names (the .strtab) section. This single section is represented in the SectionHeaderTable. yaml2obj implicitly generates separate sections for these strings however(i.e .strtab and .shstrtab), and when a SectionHeaderTable element is present, it expects all sections to be listed (either in the Sections list, or the Exclude list). Since .shstrtab wasn't present in the object file, it doesn't appear in the YAML, which causes yaml2obj to reject it. I can think of a couple of different possible fixes: 1) Add yaml2obj implicitly created sections to the end of the output object file, if not mentioned in the SectionHeaderTable. 2) Add a key to obj2yaml/yaml2obj which indicates which section to use for the section header table and/or symbol string table, or which indicates the two tables should be merged. yaml2obj would then generate one or two string tables as requesteed. 3) Change the LLVM code to emit sections in the section header table in the order they appear in the output. That would mean obj2yaml doesn't need to generate a SectionHeaderKey in this instance. I think 2) most faithfully represents the input object, and should therefore be our preferred approach. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50507] New: wasm32: i8x16.bitmask return value assumes upper 16 bits may not be zero
https://bugs.llvm.org/show_bug.cgi?id=50507
Bug ID: 50507
Summary: wasm32: i8x16.bitmask return value assumes upper 16
bits may not be zero
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: WebAssembly
Assignee: unassignedb...@nondot.org
Reporter: a...@crichton.co
CC: llvm-bugs@lists.llvm.org
In the course of binding the i8x16.bitmask instruction for Rust some discussion
-- https://github.com/rust-lang/rust/issues/74372#issuecomment-848543931 --
brought up that an appropriate return value for this intrinsic would be u16
since it can only return 16 bits of data (and u8 for the other bitmask
intrinsics). When changing the intrinsics to do this, though, it generates an
unnecessary i32.and instruction to mask out the upper bits.
I believe the reason for this is that the intrinsics are declared in LLVM as
returning an i32 so when we cast that to an i16 in LLVM IR it causes the
general codegen mechanism for such a cast to kick in which masks away the upper
bits.
Basically this IR:
target triple = "wasm32"
declare i32 @llvm.wasm.bitmask.v16i8(<16 x i8>)
define zeroext i16 @foo(<4 x i32> %a) unnamed_addr #0 {
start:
%0 = bitcast <4 x i32> %a to <16 x i8>
%1 = tail call i32 @llvm.wasm.bitmask.v16i8(<16 x i8> %0)
%2 = trunc i32 %1 to i16
ret i16 %2
}
attributes #0 = { "target-features"="+simd128" }
produces (expectedly) the sequence:
i8x16.bitmask
i32.const 65535
i32.and
Could the intrisnic, however, be modified to return `i16`? Simlarly could the
other intrinsics be updated to return `i8`? I'm not sure if `i4` is well
supported but presumably if it works it could be used for `i32x4.bitmask`,
although for language binding purposes it'd be nice to also accept `i8` as a
return value for the intrinsic.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 34677 in oss-fuzz: llvm:clang-objc-fuzzer: Stack-overflow in clang::Lexer::FormTokenWithChars
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 34677 by ClusterFuzz-External: llvm:clang-objc-fuzzer: Stack-overflow in clang::Lexer::FormTokenWithChars https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=34677#c1 ClusterFuzz testcase 4932329484189696 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202105260614:202105270636 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- 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 50508] New: 'Incomplete type' error when mapping a global extern std::array
https://bugs.llvm.org/show_bug.cgi?id=50508
Bug ID: 50508
Summary: 'Incomplete type' error when mapping a global extern
std::array
Product: OpenMP
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Runtime Library
Assignee: unassignedb...@nondot.org
Reporter: jtr...@anl.gov
CC: llvm-bugs@lists.llvm.org
An error occurs when compiling the following file (transfer.cpp) that attempts
to map a global scope std::array object declared as extern:
#include
#pragma omp declare target
extern std::array arr;
#pragma omp end declare target
void copy_host_to_device()
{
#pragma omp target update to(arr)
}
void copy_device_to_host()
{
#pragma omp target update from(arr)
}
Compiled with clang++ (version 13.0.0 (https://github.com/llvm/llvm-project.git
59d938e649e62db0cef4903d495e838fbc6a6eb8) for a V100 target as:
clang++ -Wall -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda -Xopenmp-target
-march=sm_70 -c transfer.cpp -o transfer.o
The error given is:
transfer.cpp:9:32: error: incomplete type 'std::array' where a
complete type is required
#pragma omp target update to(arr)
^~~
transfer.cpp:9:3: error: expected at least one 'to' clause or 'from' clause
specified to '#pragma omp target update'
#pragma omp target update to(arr)
^
transfer.cpp:14:34: error: incomplete type 'std::array' where a
complete type is required
#pragma omp target update from(arr)
^~~
transfer.cpp:14:3: error: expected at least one 'to' clause or 'from' clause
specified to '#pragma omp target update'
#pragma omp target update from(arr)
^
4 errors generated.
As a workaround (found by Johannes Doerfert), it works if the array is
instantiated in the first function as:
void copy_host_to_device()
{
arr[0];
#pragma omp target update to(arr)
}
The code for this reproducer is available at:
https://github.com/jtramm/omp_target_issues/blob/master/array_simple/transfer.cpp
and a larger version with a main can be found at:
https://github.com/jtramm/omp_target_issues/tree/master/array
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46812] WebAssembly: non-simd128 functions aren't inlined into simd128 functions
https://bugs.llvm.org/show_bug.cgi?id=46812 Alex Crichton changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Alex Crichton --- I believe this has since been fixed -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50509] New: CUDA fails to build on Windows with included due to missing __device__ signbit(long double)
https://bugs.llvm.org/show_bug.cgi?id=50509
Bug ID: 50509
Summary: CUDA fails to build on Windows with included
due to missing __device__ signbit(long double)
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: CUDA
Assignee: unassignedclangb...@nondot.org
Reporter: joac...@joameyer.de
CC: llvm-bugs@lists.llvm.org
Following the libstdc++ 11 issue with , we added a test for that case
in hipSYCL and discovered another issue with Clang CUDA's complex on Windows.
You can see the failing build here:
https://github.com/illuhad/hipSYCL/runs/2666453501?check_suite_focus=true
The error is:
```
C:\Program Files (x86)\Microsoft Visual
Studio\2019\Enterprise\VC\Tools\MSVC\14.28.29910\include\complex:565:16: error:
call to 'signbit' is ambiguous
return (_STD signbit)(_Left);
^~
D:\a\hipSYCL\hipSYCL\install\lib\clang\11.1.0\include\__clang_cuda_cmath.h:137:17:
note: candidate function
__DEVICE__ bool signbit(float __x) { return ::__signbitf(__x); }
^
D:\a\hipSYCL\hipSYCL\install\lib\clang\11.1.0\include\__clang_cuda_cmath.h:138:17:
note: candidate function
__DEVICE__ bool signbit(double __x) { return ::__signbitd(__x); }
```
This was worked around on the hipSYCL side by providing a __device__ bool
std::signbit(long double) overload which just maps to its double counterpart,
as long double on GPUs is pretty non-sensical anyways...
namespace std {
__device__
inline bool signbit(long double v) {return signbit(static_cast(v));}
}
As I don't see a way to toggle using long double or not in the MS STL, I'd be
open to contributing a similar workaround for the Clang side but would like
some guidance on the correct approach.
Should we just add this overload blindly, add it for Windows only or even
exclusively when using the MS STL? (if so, do you have any idea how to detect
the MS STL is used?)
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50510] New: repeatable crash during msvc build
https://bugs.llvm.org/show_bug.cgi?id=50510 Bug ID: 50510 Summary: repeatable crash during msvc build Product: clang Version: 11.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: C++2a Assignee: unassignedclangb...@nondot.org Reporter: jack.heeley.on.git...@gmail.com CC: blitzrak...@gmail.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 24897 --> https://bugs.llvm.org/attachment.cgi?id=24897&action=edit crashdump Code that was fine with msvc 16.9.4 now causes a problem for code analysis after the recent 16.10 upgrade. Repeatable. Code is available in public domain (if that helps with diagnosis). Not sure if I picked the correct component (C++2a) but I am compiling with /std:c++latest -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50511] New: [LoopDeletion] Infinite loop removed without mustprogress
https://bugs.llvm.org/show_bug.cgi?id=50511
Bug ID: 50511
Summary: [LoopDeletion] Infinite loop removed without
mustprogress
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: nikita@gmail.com
CC: jdoerf...@anl.gov, llvm-bugs@lists.llvm.org
define void @test(i1 %c1, i1 %c2) {
br label %loop1
loop1:
br i1 %c1, label %loop1.latch, label %loop2
loop2:
br i1 %c2, label %loop1.latch, label %loop2
loop1.latch:
br i1 false, label %loop1, label %exit
exit:
ret void
}
opt -S -loop-deletion
define void @test(i1 %c1, i1 %c2) {
br label %exit
exit: ; preds = %0
ret void
}
Note that the original code goes into an infinite loop for %c1=false, %c2=false
and the function is not mustprogress.
While LoopDeletion makes sure that the loop has a finite trip count, it does
not account for an inner infinite loop.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50512] New: AArch64 backend ignores failure ordering for cmpxchg
https://bugs.llvm.org/show_bug.cgi?id=50512
Bug ID: 50512
Summary: AArch64 backend ignores failure ordering for cmpxchg
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: AArch64
Assignee: unassignedb...@nondot.org
Reporter: efrie...@quicinc.com
CC: arnaud.degrandmai...@arm.com,
llvm-bugs@lists.llvm.org, smithp...@googlemail.com,
ties.st...@arm.com
https://godbolt.org/z/jvnYzrPce
For the following testcase:
#include
void test(_Atomic(int) *a, int b) {
atomic_compare_exchange_weak_explicit(a, &b, 1, memory_order_relaxed,
memory_order_seq_cst); // undefined!
}
We generate (with --target=aarch64 -O2 -march=armv8.2-a):
test:
mov w8, #1
cas w1, w8, [x0]
ret
This is pretty clearly wrong, especially with the most recent updates to the
C++ standard.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35072] [AArch64] cmpxchg not using Armv8.1-a instructions at -O0
https://bugs.llvm.org/show_bug.cgi?id=35072 Eli Friedman changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||efrie...@quicinc.com --- Comment #1 from Eli Friedman --- We correctly produce cas on trunk. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50513] New: [WebAssembly] DW_TAG_call_site is not supported for indirect calls
https://bugs.llvm.org/show_bug.cgi?id=50513 Bug ID: 50513 Summary: [WebAssembly] DW_TAG_call_site is not supported for indirect calls Product: libraries Version: trunk Hardware: All OS: All Status: CONFIRMED Severity: enhancement Priority: P Component: Backend: WebAssembly Assignee: unassignedb...@nondot.org Reporter: ahee...@gmail.com CC: aardap...@gmail.com, dsch...@google.com, llvm-bugs@lists.llvm.org, ydelen...@mozilla.com DWARF Call site information (DW_TAG_call_site) is generated in DwarfDebug:: constructCallSiteEntryDIEs (https://github.com/llvm/llvm-project/blob/0d5219feb9b26f299823b43c3c478e98cb3a0915/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp#L879-L1018) method, which supports two kinds of callee locations: global values for direct calls and machine registers for indirect calls. (https://github.com/llvm/llvm-project/blob/0d5219feb9b26f299823b43c3c478e98cb3a0915/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp#L938-L944) It looks Chrome devtools do not use DW_TAG_call_site at the moment, so the lack of support does not cause missing debug info there, but this bug is to make a record that this is missing for the full DWARF support. Direct calls are fine, but because wasm does not use machine registers, it cannot record DW_TAG_call_site info for indirect calls. Wasm uses virtual registers and they are stackified, and the info for stackified registers are generated in WebAssemblyDebugFixup pass. I think we can add support for DW_TAG_call_site in the DebugFixup pass too, if it becomes necessary. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 50514] New: TypeScript Union | not surrounded by spaces in tp
https://bugs.llvm.org/show_bug.cgi?id=50514 Bug ID: 50514 Summary: TypeScript Union | not surrounded by spaces in tp Product: clang Version: 12.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: jkope...@sievers-group.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 34744 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Decl::castFromDeclContext
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-05-28 Type: Bug New issue 34744 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Decl::castFromDeclContext https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=34744 Detailed Report: https://oss-fuzz.com/testcase?key=5070760698839040 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffdc50a0ff8 Crash State: clang::Decl::castFromDeclContext clang::DeclContext::getLookupParent clang::Sema::DiagnoseEmptyLookup Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202105260614:202105270636 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5070760698839040 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- 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
