[llvm-branch-commits] [clang] [serialization] No transitive type change (PR #92511)
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/92511
>From 57cfb2b7791666022ee46201b5126ac610c19bdd Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Fri, 17 May 2024 14:25:53 +0800
Subject: [PATCH] [serialization] No transitive type change
---
.../include/clang/Serialization/ASTBitCodes.h | 32 --
clang/include/clang/Serialization/ASTReader.h | 23 ++--
.../clang/Serialization/ASTRecordReader.h | 2 +-
.../include/clang/Serialization/ModuleFile.h | 3 -
clang/lib/Serialization/ASTReader.cpp | 104 +-
clang/lib/Serialization/ASTWriter.cpp | 31 +++---
clang/lib/Serialization/ModuleFile.cpp| 1 -
.../Modules/no-transitive-decls-change.cppm | 12 +-
.../no-transitive-identifier-change.cppm | 3 -
.../Modules/no-transitive-type-change.cppm| 68
clang/test/Modules/pr5.cppm | 36 +++---
11 files changed, 196 insertions(+), 119 deletions(-)
create mode 100644 clang/test/Modules/no-transitive-type-change.cppm
diff --git a/clang/include/clang/Serialization/ASTBitCodes.h
b/clang/include/clang/Serialization/ASTBitCodes.h
index 03bac9be2bf3d..13ee1e4724f1e 100644
--- a/clang/include/clang/Serialization/ASTBitCodes.h
+++ b/clang/include/clang/Serialization/ASTBitCodes.h
@@ -26,6 +26,7 @@
#include "clang/Serialization/SourceLocationEncoding.h"
#include "llvm/ADT/DenseMapInfo.h"
#include "llvm/Bitstream/BitCodes.h"
+#include "llvm/Support/MathExtras.h"
#include
#include
@@ -70,38 +71,53 @@ using DeclID = DeclIDBase::DeclID;
/// An ID number that refers to a type in an AST file.
///
-/// The ID of a type is partitioned into two parts: the lower
+/// The ID of a type is partitioned into three parts:
+/// - the lower
/// three bits are used to store the const/volatile/restrict
-/// qualifiers (as with QualType) and the upper bits provide a
-/// type index. The type index values are partitioned into two
+/// qualifiers (as with QualType).
+/// - the upper 29 bits provide a type index in the corresponding
+/// module file.
+/// - the upper 32 bits provide a module file index.
+///
+/// The type index values are partitioned into two
/// sets. The values below NUM_PREDEF_TYPE_IDs are predefined type
/// IDs (based on the PREDEF_TYPE_*_ID constants), with 0 as a
/// placeholder for "no type". Values from NUM_PREDEF_TYPE_IDs are
/// other types that have serialized representations.
-using TypeID = uint32_t;
+using TypeID = uint64_t;
/// A type index; the type ID with the qualifier bits removed.
+/// Keep structure alignment 32-bit since the blob is assumed as 32-bit
+/// aligned.
class TypeIdx {
+ uint32_t ModuleFileIndex = 0;
uint32_t Idx = 0;
public:
TypeIdx() = default;
- explicit TypeIdx(uint32_t index) : Idx(index) {}
+ explicit TypeIdx(uint32_t Idx) : ModuleFileIndex(0), Idx(Idx) {}
+
+ explicit TypeIdx(uint32_t ModuleFileIdx, uint32_t Idx)
+ : ModuleFileIndex(ModuleFileIdx), Idx(Idx) {}
+
+ uint32_t getModuleFileIndex() const { return ModuleFileIndex; }
- uint32_t getIndex() const { return Idx; }
+ uint64_t getValue() const { return ((uint64_t)ModuleFileIndex << 32) | Idx; }
TypeID asTypeID(unsigned FastQuals) const {
if (Idx == uint32_t(-1))
return TypeID(-1);
-return (Idx << Qualifiers::FastWidth) | FastQuals;
+unsigned Index = (Idx << Qualifiers::FastWidth) | FastQuals;
+return ((uint64_t)ModuleFileIndex << 32) | Index;
}
static TypeIdx fromTypeID(TypeID ID) {
if (ID == TypeID(-1))
return TypeIdx(-1);
-return TypeIdx(ID >> Qualifiers::FastWidth);
+return TypeIdx(ID >> 32, (ID & llvm::maskTrailingOnes(32)) >>
+ Qualifiers::FastWidth);
}
};
diff --git a/clang/include/clang/Serialization/ASTReader.h
b/clang/include/clang/Serialization/ASTReader.h
index 3f38a08f0da3a..f4180984eaad3 100644
--- a/clang/include/clang/Serialization/ASTReader.h
+++ b/clang/include/clang/Serialization/ASTReader.h
@@ -490,14 +490,6 @@ class ASTReader
/// ID = (I + 1) << FastQual::Width has already been loaded
llvm::PagedVector TypesLoaded;
- using GlobalTypeMapType =
- ContinuousRangeMap;
-
- /// Mapping from global type IDs to the module in which the
- /// type resides along with the offset that should be added to the
- /// global type ID to produce a local ID.
- GlobalTypeMapType GlobalTypeMap;
-
/// Declarations that have already been loaded from the chain.
///
/// When the pointer at index I is non-NULL, the declaration with ID
@@ -1423,8 +1415,8 @@ class ASTReader
RecordLocation(ModuleFile *M, uint64_t O) : F(M), Offset(O) {}
};
- QualType readTypeRecord(unsigned Index);
- RecordLocation TypeCursorForIndex(unsigned Index);
+ QualType readTypeRecord(serialization::TypeID ID);
+ RecordLocation TypeCursorForIndex(serialization::TypeID ID);
void LoadedDecl(unsigned Index, Decl *D);
Decl *ReadDeclRecord(GlobalDeclID
[llvm-branch-commits] [RISCV][MC] Warn if SEW/LMUL may not be compatible (PR #94313)
@@ -71,18 +73,21 @@ vsetvli a2, a0, e32, m8, ta, ma
vsetvli a2, a0, e32, mf2, ta, ma
# CHECK-INST: vsetvli a2, a0, e32, mf2, ta, ma
+# CHECK-WARNING: :[[#@LINE-2]]:17: warning: SEW > 16 may not be compatible
with all RVV implementations{{$}}
# CHECK-ENCODING: [0x57,0x76,0x75,0x0d]
# CHECK-ERROR: instruction requires the following: 'V' (Vector Extension for
Application Processors), 'Zve32x' (Vector Extensions for Embedded
Processors){{$}}
# CHECK-UNKNOWN: 0d757657
vsetvli a2, a0, e32, mf4, ta, ma
# CHECK-INST: vsetvli a2, a0, e32, mf4, ta, ma
+# CHECK-WARNING: :[[#@LINE-2]]:17: warning: SEW > 8 may not be compatible with
all RVV implementations{{$}}
lukel97 wrote:
I see that the spec recommends that we warn when LMUL < SEWMIN/ELEN, but do we
need to warn for SEW > LMUL * ELEN? IIUC this cause a warning on zve64x too
since 32 > 1/4 * 64
https://github.com/llvm/llvm-project/pull/94313
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [RISCV][MC] Warn if SEW/LMUL may not be compatible (PR #94313)
@@ -1,5 +1,7 @@ # RUN: llvm-mc -triple=riscv64 -show-encoding --mattr=+v %s \ # RUN:| FileCheck %s --check-prefixes=CHECK-ENCODING,CHECK-INST +# RUN: llvm-mc -triple=riscv64 -show-encoding --mattr=+zve32x %s 2>&1 \ +# RUN:| FileCheck %s --check-prefix=CHECK-WARNING lukel97 wrote: Nit, can we name the prefix something like CHECK-ZVE32X https://github.com/llvm/llvm-project/pull/94313 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] [clang] Define ptrauth_string_discriminator builtin. (PR #93903)
https://github.com/kovdan01 commented: LGTM, but I want someone else with deeper understanding of the context to take a look before this gets merged. https://github.com/llvm/llvm-project/pull/93903 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] [clang] Define ptrauth_string_discriminator builtin. (PR #93903)
https://github.com/kovdan01 dismissed https://github.com/llvm/llvm-project/pull/93903 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)
https://github.com/5chmidti edited https://github.com/llvm/llvm-project/pull/94248 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [RISCV][MC] Warn if SEW/LMUL may not be compatible (PR #94313)
@@ -71,18 +73,21 @@ vsetvli a2, a0, e32, m8, ta, ma
vsetvli a2, a0, e32, mf2, ta, ma
# CHECK-INST: vsetvli a2, a0, e32, mf2, ta, ma
+# CHECK-WARNING: :[[#@LINE-2]]:17: warning: SEW > 16 may not be compatible
with all RVV implementations{{$}}
# CHECK-ENCODING: [0x57,0x76,0x75,0x0d]
# CHECK-ERROR: instruction requires the following: 'V' (Vector Extension for
Application Processors), 'Zve32x' (Vector Extensions for Embedded
Processors){{$}}
# CHECK-UNKNOWN: 0d757657
vsetvli a2, a0, e32, mf4, ta, ma
# CHECK-INST: vsetvli a2, a0, e32, mf4, ta, ma
+# CHECK-WARNING: :[[#@LINE-2]]:17: warning: SEW > 8 may not be compatible with
all RVV implementations{{$}}
wangpc-pp wrote:
I suppose we should.
One example I just met days ago:
```c
int main() {
asm("vsetivli zero, 1, e32, mf4, ta, ma\n"
"csrr a0, vtype\n"
"csrr a1, vlenb\n"
"vmv.s.x v24, a6");
return 0;
}
```
For MF4, the must supported SEWs are [8, 16], while the SEW is 32 here.
For C908 core on K230 board, this code will crash with an `Illegal Instruction`
error, but not on `qemu`.
The `vlen` of C908 is 128 bits, theoretically, for MF4, we can store one
element in a vector register. But the implementation sets `vill` for this
configuration (this is not against the RVV spec, though).
So I think we should warn as it can be incompatible.
https://github.com/llvm/llvm-project/pull/94313
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [RISCV][MC] Warn if SEW/LMUL may not be compatible (PR #94313)
@@ -71,18 +73,21 @@ vsetvli a2, a0, e32, m8, ta, ma
vsetvli a2, a0, e32, mf2, ta, ma
# CHECK-INST: vsetvli a2, a0, e32, mf2, ta, ma
+# CHECK-WARNING: :[[#@LINE-2]]:17: warning: SEW > 16 may not be compatible
with all RVV implementations{{$}}
# CHECK-ENCODING: [0x57,0x76,0x75,0x0d]
# CHECK-ERROR: instruction requires the following: 'V' (Vector Extension for
Application Processors), 'Zve32x' (Vector Extensions for Embedded
Processors){{$}}
# CHECK-UNKNOWN: 0d757657
vsetvli a2, a0, e32, mf4, ta, ma
# CHECK-INST: vsetvli a2, a0, e32, mf4, ta, ma
+# CHECK-WARNING: :[[#@LINE-2]]:17: warning: SEW > 8 may not be compatible with
all RVV implementations{{$}}
lukel97 wrote:
Ok, that seems reasonable. Should we maybe then reword the LMUL < SEWMIN/ELEN
case to mention that the encoding is actually reserved, whereas for SEW > LMUL
* ELEN it may just not be compatible
https://github.com/llvm/llvm-project/pull/94313
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)
https://github.com/AaronBallman edited https://github.com/llvm/llvm-project/pull/94248 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)
https://github.com/AaronBallman commented:
It looks like precommit CI found relevant failures:
```
_bk;t=1717501095887FAILED:
tools/clang/unittests/ASTMatchers/ASTMatchersDocTests.cpp
_bk;t=1717501095887cmd.exe /C "cd /D
C:\ws\src\build\tools\clang\unittests\ASTMatchers &&
C:\ws\src\clang\utils\generate_ast_matcher_doc_tests.py --input-file
C:/ws/src/clang/include/clang/ASTMatchers/ASTMatchers.h --output-file
C:/ws/src/build/tools/clang/unittests/ASTMatchers/ASTMatchersDocTests.cpp"
_bk;t=1717501095887 File
"C:\ws\src\clang\utils\generate_ast_matcher_doc_tests.py", line 613
_bk;t=1717501099131const StringRef Code = R"cpp(\n{"\t#include
\"cuda.h\"\n" if has_cuda else ""}{self.code})cpp";\n"""
_bk;t=1717501099131
^
_bk;t=1717501099131SyntaxError: f-string expression part cannot include a
backslash
```
https://github.com/llvm/llvm-project/pull/94248
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [SPARC][IAS] Add named prefetch tag constants (PR #94249)
@@ -537,16 +537,26 @@ ! V9: stxa %g0, [%g2+%i5] #ASI_SNF ! encoding: [0xc0,0xf0,0x90,0x7d] stxa %g0, [%g2 + %i5] #ASI_SNF -! V8: error: instruction requires a CPU feature not currently enabled +! V8: error: invalid operand for instruction koachan wrote: This is probably the same issue that causes the error message in [PR 92450](https://github.com/llvm/llvm-project/pull/94250/files#r1624938216) to be wrong. I can at least change the tag parser to return a NoMatch here, but I suppose the full fix is probably better done separately, like you said there? https://github.com/llvm/llvm-project/pull/94249 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [SPARC][IAS] Add named prefetch tag constants (PR #94249)
https://github.com/koachan updated
https://github.com/llvm/llvm-project/pull/94249
>From 2debba6d10e3025ae5b312ef8ef8e1f68bc2b794 Mon Sep 17 00:00:00 2001
From: Koakuma
Date: Tue, 4 Jun 2024 22:30:09 +0700
Subject: [PATCH] Update tests and apply suggestions
Created using spr 1.3.4
---
.../Target/Sparc/AsmParser/SparcAsmParser.cpp | 28 --
llvm/test/MC/Disassembler/Sparc/sparc-v9.txt | 58 +++-
llvm/test/MC/Sparc/sparcv9-instructions.s | 90 +++
3 files changed, 165 insertions(+), 11 deletions(-)
diff --git a/llvm/lib/Target/Sparc/AsmParser/SparcAsmParser.cpp
b/llvm/lib/Target/Sparc/AsmParser/SparcAsmParser.cpp
index a0dec24e3200a..f0a3a4e88b30c 100644
--- a/llvm/lib/Target/Sparc/AsmParser/SparcAsmParser.cpp
+++ b/llvm/lib/Target/Sparc/AsmParser/SparcAsmParser.cpp
@@ -1120,23 +1120,33 @@ ParseStatus
SparcAsmParser::parsePrefetchTag(OperandVector &Operands) {
SMLoc E = Parser.getTok().getEndLoc();
int64_t PrefetchVal = 0;
- if (getLexer().getKind() == AsmToken::Hash) {
+ switch (getLexer().getKind()) {
+ case AsmToken::LParen:
+ case AsmToken::Integer:
+ case AsmToken::Identifier:
+ case AsmToken::Plus:
+ case AsmToken::Minus:
+ case AsmToken::Tilde:
+if (getParser().parseAbsoluteExpression(PrefetchVal) ||
+!isUInt<5>(PrefetchVal))
+ return Error(S, "invalid prefetch number, must be between 0 and 31");
+break;
+ case AsmToken::Hash: {
SMLoc TagStart = getLexer().peekTok(false).getLoc();
Parser.Lex(); // Eat the '#'.
-auto PrefetchName = Parser.getTok().getString();
-auto PrefetchTag = SparcPrefetchTag::lookupPrefetchTagByName(PrefetchName);
+const StringRef PrefetchName = Parser.getTok().getString();
+const SparcPrefetchTag::PrefetchTag *PrefetchTag =
+SparcPrefetchTag::lookupPrefetchTagByName(PrefetchName);
Parser.Lex(); // Eat the identifier token.
if (!PrefetchTag)
return Error(TagStart, "unknown prefetch tag");
PrefetchVal = PrefetchTag->Encoding;
- } else if (!getParser().parseAbsoluteExpression(PrefetchVal)) {
-if (!isUInt<5>(PrefetchVal))
- return Error(S, "invalid prefetch number, must be between 0 and 31");
- } else {
-return Error(S, "malformed prefetch tag, must be a constant integer "
-"expression, or a named tag");
+break;
+ }
+ default:
+return ParseStatus::NoMatch;
}
Operands.push_back(SparcOperand::CreatePrefetchTag(PrefetchVal, S, E));
diff --git a/llvm/test/MC/Disassembler/Sparc/sparc-v9.txt
b/llvm/test/MC/Disassembler/Sparc/sparc-v9.txt
index 49b6e339435f1..d561216fec6f2 100644
--- a/llvm/test/MC/Disassembler/Sparc/sparc-v9.txt
+++ b/llvm/test/MC/Disassembler/Sparc/sparc-v9.txt
@@ -132,11 +132,65 @@
# CHECK: membar #LoadLoad | #StoreLoad | #LoadStore | #StoreStore | #Lookaside
| #MemIssue | #Sync
0x81 0x43 0xe0 0x7f
+# CHECK: prefetch [%i1+3968], #n_reads
+0xc1 0x6e 0x6f 0x80
+
# CHECK: prefetch [%i1+3968], #one_read
-0xc3,0x6e,0x6f,0x80
+0xc3 0x6e 0x6f 0x80
+
+# CHECK: prefetch [%i1+3968], #n_writes
+0xc5 0x6e 0x6f 0x80
+
+# CHECK: prefetch [%i1+3968], #one_write
+0xc7 0x6e 0x6f 0x80
+
+# CHECK: prefetch [%i1+3968], #page
+0xc9 0x6e 0x6f 0x80
+
+# CHECK: prefetch [%i1+3968], #unified
+0xe3 0x6e 0x6f 0x80
+
+# CHECK: prefetch [%i1+3968], #n_reads_strong
+0xe9 0x6e 0x6f 0x80
+
+# CHECK: prefetch [%i1+3968], #one_read_strong
+0xeb 0x6e 0x6f 0x80
+
+# CHECK: prefetch [%i1+3968], #n_writes_strong
+0xed 0x6e 0x6f 0x80
+
+# CHECK: prefetch [%i1+3968], #one_write_strong
+0xef 0x6e 0x6f 0x80
+
+# CHECK: prefetch [%i1+%i2], #n_reads
+0xc1 0x6e 0x40 0x1a
# CHECK: prefetch [%i1+%i2], #one_read
-0xc3,0x6e,0x40,0x1a
+0xc3 0x6e 0x40 0x1a
+
+# CHECK: prefetch [%i1+%i2], #n_writes
+0xc5 0x6e 0x40 0x1a
+
+# CHECK: prefetch [%i1+%i2], #one_write
+0xc7 0x6e 0x40 0x1a
+
+# CHECK: prefetch [%i1+%i2], #page
+0xc9 0x6e 0x40 0x1a
+
+# CHECK: prefetch [%i1+%i2], #unified
+0xe3 0x6e 0x40 0x1a
+
+# CHECK: prefetch [%i1+%i2], #n_reads_strong
+0xe9 0x6e 0x40 0x1a
+
+# CHECK: prefetch [%i1+%i2], #one_read_strong
+0xeb 0x6e 0x40 0x1a
+
+# CHECK: prefetch [%i1+%i2], #n_writes_strong
+0xed 0x6e 0x40 0x1a
+
+# CHECK: prefetch [%i1+%i2], #one_write_strong
+0xef 0x6e 0x40 0x1a
# CHECK: done
0x81,0xf0,0x00,0x00
diff --git a/llvm/test/MC/Sparc/sparcv9-instructions.s
b/llvm/test/MC/Sparc/sparcv9-instructions.s
index f0348eb70f1c5..80f67ac30bc82 100644
--- a/llvm/test/MC/Sparc/sparcv9-instructions.s
+++ b/llvm/test/MC/Sparc/sparcv9-instructions.s
@@ -542,21 +542,111 @@
! V9: prefetch [%i1+3968], #one_read ! encoding:
[0xc3,0x6e,0x6f,0x80]
prefetch [ %i1 + 0xf80 ], 1
+! V8: error: unexpected token
+! V8-NEXT: prefetch [ %i1 + 0xf80 ], #n_reads
+! V9: prefetch [%i1+3968], #n_reads ! encoding: [0xc1,0x6e,0x6f,0x80]
+prefetch [ %i1 + 0xf80 ], #n_reads
+
! V8: error: unexpected token
! V8-NEXT: prefetch [ %i1 + 0xf80 ], #o
[llvm-branch-commits] [SPARC][IAS] Add support for `prefetcha` instruction (PR #94250)
@@ -557,6 +557,36 @@ ! V9: prefetch [%i1+%i2], #one_read ! encoding: [0xc3,0x6e,0x40,0x1a] prefetch [ %i1 + %i2 ], #one_read +! V8: error: malformed ASI tag, must be a constant integer expression koachan wrote: Okay, so parsePrefetchTag has changed to return NoMatch like you suggested, but what to do with the ASI errors displayed here? Should I do that in another patch? https://github.com/llvm/llvm-project/pull/94250 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [libcxx] [libc++][TZDB] Implements time_zone::to_sys. (PR #90394)
https://github.com/ldionne approved this pull request. LGTM w/ comments applied (in particular the missing tests). https://github.com/llvm/llvm-project/pull/90394 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [libcxx] [libc++][TZDB] Implements time_zone::to_sys. (PR #90394)
@@ -0,0 +1,20 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include
+
+_LIBCPP_BEGIN_NAMESPACE_STD
+
+namespace chrono {
+
+_LIBCPP_AVAILABILITY_TZDB _LIBCPP_EXPORTED_FROM_ABI
nonexistent_local_time::~nonexistent_local_time() = default;
+_LIBCPP_AVAILABILITY_TZDB _LIBCPP_EXPORTED_FROM_ABI
ambiguous_local_time::~ambiguous_local_time() = default;
ldionne wrote:
```suggestion
_LIBCPP_AVAILABILITY_TZDB _LIBCPP_EXPORTED_FROM_ABI
nonexistent_local_time::~nonexistent_local_time() = default; // key function
_LIBCPP_AVAILABILITY_TZDB _LIBCPP_EXPORTED_FROM_ABI
ambiguous_local_time::~ambiguous_local_time() = default; // key function
```
https://github.com/llvm/llvm-project/pull/90394
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [libcxx] [libc++][TZDB] Implements time_zone::to_sys. (PR #90394)
@@ -0,0 +1,33 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+// UNSUPPORTED: c++03, c++11, c++14, c++17
+
+// XFAIL: libcpp-has-no-experimental-tzdb
+// XFAIL: availability-tzdb-missing
+
+//
+
+// class nonexistent_local_time : public runtime_error {
+// public:
+// template
+// nonexistent_local_time(const local_time& tp, const
local_info& i);
+// };
+
+#include
+#include
+#include
+
+// Basic properties
+static_assert(std::is_base_of_v);
+static_assert(!std::is_default_constructible_v);
+static_assert(std::is_destructible_v);
+static_assert(std::is_copy_constructible_v);
+static_assert(std::is_move_constructible_v);
+static_assert(std::is_copy_assignable_v);
+static_assert(std::is_move_assignable_v);
ldionne wrote:
Instead of just asserting those traits, you should have actual runtime tests
that exercise these functions.
For example if we declared the copy constructor as non-inline in the headers
and never defined it in the dylib, this test would pass but we'd want it to
fail.
https://github.com/llvm/llvm-project/pull/90394
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [libcxx] [libc++][TZDB] Implements time_zone::to_sys. (PR #90394)
@@ -70,6 +72,30 @@ class _LIBCPP_AVAILABILITY_TZDB time_zone {
return __get_info(chrono::time_point_cast(__time));
}
+ // Since the interface promisses throwing, don't add nodiscard.
ldionne wrote:
I don't think this comment is necessary -- we assume no `nodiscard` by default
anyway, and I think anyone pausing to think whether this should be made
`nodiscard` will easily come to the same conclusion.
Or if you want to keep the comment, I would reword to `We don't apply nodiscard
here since this function throws on many inputs, so it could be used as a
validation`.
https://github.com/llvm/llvm-project/pull/90394
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [libcxx] [libc++][TZDB] Implements time_zone::to_sys. (PR #90394)
https://github.com/ldionne edited https://github.com/llvm/llvm-project/pull/90394 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [libcxx] [libc++][TZDB] Implements time_zone::to_sys. (PR #90394)
@@ -339,6 +339,9 @@ if (LIBCXX_ENABLE_LOCALIZATION AND LIBCXX_ENABLE_FILESYSTEM AND LIBCXX_ENABLE_TI include/tzdb/types_private.h include/tzdb/tzdb_list_private.h include/tzdb/tzdb_private.h +# TODO TZDB The exception could be moved in chrono once the TZDB library +# is no longer experimental. +chrono_exception.cpp time_zone.cpp tzdb.cpp tzdb_list.cpp ldionne wrote: Those should all move to `libcxx/src/experimental/`. Can be done in a separate patch. https://github.com/llvm/llvm-project/pull/90394 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [libcxx] [libc++][TZDB] Implements time_zone::to_sys. (PR #90901)
@@ -0,0 +1,37 @@ +//===--===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception +// +//===--===// + +// UNSUPPORTED: c++03, c++11, c++14, c++17 +// UNSUPPORTED: no-filesystem, no-localization, no-tzdb + +// XFAIL: libcpp-has-no-experimental-tzdb +// XFAIL: availability-tzdb-missing + +// + +// enaum class choose; ldionne wrote: ```suggestion // enum class choose; ``` https://github.com/llvm/llvm-project/pull/90901 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [libcxx] [libc++][TZDB] Implements time_zone::to_sys. (PR #90901)
https://github.com/ldionne edited https://github.com/llvm/llvm-project/pull/90901 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [libcxx] [libc++][TZDB] Implements time_zone::to_sys. (PR #90901)
https://github.com/ldionne approved this pull request. https://github.com/llvm/llvm-project/pull/90901 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [libcxx] [libc++][TZDB] Implements time_zone::to_local. (PR #91003)
https://github.com/ldionne edited https://github.com/llvm/llvm-project/pull/91003 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [libcxx] [libc++][TZDB] Implements time_zone::to_local. (PR #91003)
https://github.com/ldionne approved this pull request. https://github.com/llvm/llvm-project/pull/91003 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [libcxx] [libc++][TZDB] Implements time_zone::to_local. (PR #91003)
@@ -0,0 +1,66 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+// UNSUPPORTED: c++03, c++11, c++14, c++17
+// UNSUPPORTED: no-filesystem, no-localization, no-tzdb
+
+// XFAIL: libcpp-has-no-experimental-tzdb
+// XFAIL: availability-tzdb-missing
+
+//
+
+// class time_zone;
+
+// template
+// local_time>
+// to_local(const sys_time& tp) const;
+
+#include
+#include
+#include
+#include
+
+#include "test_macros.h"
+#include "assert_macros.h"
+#include "concat_macros.h"
+
+int main(int, char**) {
+ // To make sure the test does not depend on changes in the database it uses a
+ // time zone with a fixed offset.
+ using namespace std::literals::chrono_literals;
+
+ const std::chrono::time_zone* tz = std::chrono::locate_zone("Etc/GMT+1");
+
+ assert(tz->to_local(std::chrono::sys_time{-1ns}) ==
+ std::chrono::local_time{-1ns - 1h});
+
+ assert(tz->to_local(std::chrono::sys_time{0us}) ==
+ std::chrono::local_time{0us - 1h});
+
+ assert(tz->to_local(
+
std::chrono::sys_time{std::chrono::sys_days{std::chrono::January
/ 1 / -21970}}) ==
+ std::chrono::local_time{
+ (std::chrono::sys_days{std::chrono::January / 1 /
-21970}).time_since_epoch() - 1h});
+
+ assert(
+
tz->to_local(std::chrono::sys_time{std::chrono::sys_days{std::chrono::January
/ 1 / 21970}}) ==
+ std::chrono::local_time{
+ (std::chrono::sys_days{std::chrono::January / 1 /
21970}).time_since_epoch() - 1h});
+
+ assert(tz->to_local(std::chrono::sys_time{}) ==
+ std::chrono::local_time{
+ (std::chrono::sys_days{std::chrono::January / 1 /
1970}).time_since_epoch() - 1h});
+
+ assert(tz->to_local(std::chrono::sys_time{}) ==
+ std::chrono::local_time{
+ (std::chrono::sys_days{std::chrono::January / 1 /
1970}).time_since_epoch() - 1h});
+
+ assert(tz->to_local(std::chrono::sys_time{}) ==
+ std::chrono::local_time{
+ (std::chrono::sys_days{std::chrono::January / 1 /
1970}).time_since_epoch() - 1h});
+}
ldionne wrote:
`return 0;`
https://github.com/llvm/llvm-project/pull/91003
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [libcxx] [libc++][TZDB] Implements zoned_traits. (PR #91059)
@@ -0,0 +1,32 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+// UNSUPPORTED: c++03, c++11, c++14, c++17
+// UNSUPPORTED: no-filesystem, no-localization, no-tzdb
+
+// XFAIL: libcpp-has-no-experimental-tzdb
+// XFAIL: availability-tzdb-missing
+
+//
+
+// template struct zoned_traits {};
+//
+// A specialization for const time_zone* is provided by the implementation:
+// template<> struct zoned_traits { ... }
+
+#include
+#include
+
+// This test test whether non-specialized versions exhibit the expected
+// behavior. (Note these specializations are not really useful.)
+static_assert(std::is_trivial_v>);
ldionne wrote:
I think we actually need to check `is_empty_v && is_trivial_v` here. Otherwise
a type like this would pass the `is_trivial` test:
```
struct foo {
foo();
};
```
https://github.com/llvm/llvm-project/pull/91059
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [libcxx] [libc++][TZDB] Implements zoned_traits. (PR #91059)
https://github.com/ldionne edited https://github.com/llvm/llvm-project/pull/91059 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [libcxx] [libc++][TZDB] Implements zoned_traits. (PR #91059)
https://github.com/ldionne approved this pull request. LGTM w/ minor comment. https://github.com/llvm/llvm-project/pull/91059 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [libcxx] [libc++][chrono] Fixes leap seconds. (PR #90070)
https://github.com/ldionne edited https://github.com/llvm/llvm-project/pull/90070 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [libcxx] [libc++][chrono] Fixes leap seconds. (PR #90070)
@@ -626,29 +626,49 @@ static void __parse_leap_seconds(vector&
__leap_seconds, istream&&
// seconds since 1 January 1970.
constexpr auto __offset = sys_days{1970y / January / 1} - sys_days{1900y /
January / 1};
- while (true) {
-switch (__input.peek()) {
-case istream::traits_type::eof():
- return;
-
-case ' ':
-case '\t':
-case '\n':
- __input.get();
- continue;
+ struct __entry {
+sys_seconds __timestamp;
+seconds __value;
+ };
+ vector<__entry> __entries;
+ [&] {
+while (true) {
+ switch (__input.peek()) {
+ case istream::traits_type::eof():
+return;
+
+ case ' ':
+ case '\t':
+ case '\n':
+__input.get();
+continue;
+
+ case '#':
+chrono::__skip_line(__input);
+continue;
+ }
-case '#':
+ sys_seconds __date =
sys_seconds{seconds{chrono::__parse_integral(__input, false)}} - __offset;
+ chrono::__skip_mandatory_whitespace(__input);
+ seconds __value{chrono::__parse_integral(__input, false)};
chrono::__skip_line(__input);
- continue;
-}
-sys_seconds __date = sys_seconds{seconds{chrono::__parse_integral(__input,
false)}} - __offset;
-chrono::__skip_mandatory_whitespace(__input);
-seconds __value{chrono::__parse_integral(__input, false)};
-chrono::__skip_line(__input);
-
-__leap_seconds.emplace_back(std::__private_constructor_tag{}, __date,
__value);
- }
+ __entries.emplace_back(__date, __value);
+}
+ }();
+ // The Standard requires the leap seconds to be sorted. The file
+ // leap-seconds.list usually provides them in sorted order, but that is not
+ // guaranteed so we ensure it here.
+ std::ranges::sort(__entries, {}, &__entry::__timestamp);
ldionne wrote:
```suggestion
ranges::sort(__entries, {}, &__entry::__timestamp);
```
https://github.com/llvm/llvm-project/pull/90070
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [libcxx] [libc++][chrono] Fixes leap seconds. (PR #90070)
@@ -626,29 +626,49 @@ static void __parse_leap_seconds(vector&
__leap_seconds, istream&&
// seconds since 1 January 1970.
constexpr auto __offset = sys_days{1970y / January / 1} - sys_days{1900y /
January / 1};
- while (true) {
-switch (__input.peek()) {
-case istream::traits_type::eof():
- return;
-
-case ' ':
-case '\t':
-case '\n':
- __input.get();
- continue;
+ struct __entry {
+sys_seconds __timestamp;
+seconds __value;
+ };
+ vector<__entry> __entries;
+ [&] {
+while (true) {
+ switch (__input.peek()) {
+ case istream::traits_type::eof():
+return;
+
+ case ' ':
+ case '\t':
+ case '\n':
+__input.get();
+continue;
+
+ case '#':
+chrono::__skip_line(__input);
+continue;
+ }
-case '#':
+ sys_seconds __date =
sys_seconds{seconds{chrono::__parse_integral(__input, false)}} - __offset;
+ chrono::__skip_mandatory_whitespace(__input);
+ seconds __value{chrono::__parse_integral(__input, false)};
chrono::__skip_line(__input);
- continue;
-}
-sys_seconds __date = sys_seconds{seconds{chrono::__parse_integral(__input,
false)}} - __offset;
-chrono::__skip_mandatory_whitespace(__input);
-seconds __value{chrono::__parse_integral(__input, false)};
-chrono::__skip_line(__input);
-
-__leap_seconds.emplace_back(std::__private_constructor_tag{}, __date,
__value);
- }
+ __entries.emplace_back(__date, __value);
+}
+ }();
+ // The Standard requires the leap seconds to be sorted. The file
+ // leap-seconds.list usually provides them in sorted order, but that is not
+ // guaranteed so we ensure it here.
+ std::ranges::sort(__entries, {}, &__entry::__timestamp);
+
+ // The database should contain the number of seconds inserted by a leap
+ // second (1 or -1). So the difference between the two elements are stored.
ldionne wrote:
```suggestion
// second (1 or -1). So the difference between the two elements is stored.
```
https://github.com/llvm/llvm-project/pull/90070
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [libcxx] [libc++][chrono] Fixes leap seconds. (PR #90070)
https://github.com/ldionne approved this pull request. https://github.com/llvm/llvm-project/pull/90070 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [SPARC][IAS] Add support for `prefetcha` instruction (PR #94250)
@@ -557,6 +557,36 @@ ! V9: prefetch [%i1+%i2], #one_read ! encoding: [0xc3,0x6e,0x40,0x1a] prefetch [ %i1 + %i2 ], #one_read +! V8: error: malformed ASI tag, must be a constant integer expression s-barannikov wrote: I hoped a fix would be trivial. Let's do it in separate patch then. https://github.com/llvm/llvm-project/pull/94250 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [SPARC][IAS] Add named prefetch tag constants (PR #94249)
@@ -537,16 +537,26 @@ ! V9: stxa %g0, [%g2+%i5] #ASI_SNF ! encoding: [0xc0,0xf0,0x90,0x7d] stxa %g0, [%g2 + %i5] #ASI_SNF -! V8: error: instruction requires a CPU feature not currently enabled +! V8: error: invalid operand for instruction s-barannikov wrote: Let's do it in another patch. https://github.com/llvm/llvm-project/pull/94249 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [SPARC][IAS] Add named prefetch tag constants (PR #94249)
https://github.com/s-barannikov approved this pull request. https://github.com/llvm/llvm-project/pull/94249 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [SPARC][IAS] Add support for `prefetcha` instruction (PR #94250)
https://github.com/s-barannikov approved this pull request. https://github.com/llvm/llvm-project/pull/94250 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [SPARC][IAS] Add movr(n)e alias for movr(n)z (PR #94252)
https://github.com/s-barannikov approved this pull request. LGTM https://github.com/llvm/llvm-project/pull/94252 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] gn build: Embed libc++abi.a objects into libc++.a. (PR #88463)
aeubanks wrote: could you point to where this is done in CMake? https://github.com/llvm/llvm-project/pull/88463 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [Support] Integrate SipHash.cpp into libSupport. (PR #94394)
https://github.com/ahmedbougacha created https://github.com/llvm/llvm-project/pull/94394 Start building it as part of the library, with some minor tweaks compared to the reference implementation: - clang-format to match libSupport - remove tracing support - add file header - templatize cROUNDS/dROUNDS, as well as 8B/16B result type - replace assert with static_assert - return the result directly, as uint64_t/uint128_t - remove big-endian support - use LLVM_FALLTHROUGH - remove tracing support The siphash function itself isn't used yet, and will be in a follow-up commit. >From 12bb6238aa0e7f90342aa194e54a8286e3e35dbd Mon Sep 17 00:00:00 2001 From: Ahmed Bougacha Date: Tue, 4 Jun 2024 12:41:47 -0700 Subject: [PATCH 1/3] [Support] Reformat SipHash.cpp to match libSupport. While there, give it our usual file header and an acknowledgement, and remove the imported README.md.SipHash. --- llvm/lib/Support/README.md.SipHash | 126 -- llvm/lib/Support/SipHash.cpp | 264 ++--- 2 files changed, 129 insertions(+), 261 deletions(-) delete mode 100644 llvm/lib/Support/README.md.SipHash diff --git a/llvm/lib/Support/README.md.SipHash b/llvm/lib/Support/README.md.SipHash deleted file mode 100644 index 4de3cd1854681..0 --- a/llvm/lib/Support/README.md.SipHash +++ /dev/null @@ -1,126 +0,0 @@ -# SipHash - -[](http://creativecommons.org/publicdomain/zero/1.0/) - -[](https://opensource.org/licenses/MIT) - - -SipHash is a family of pseudorandom functions (PRFs) optimized for speed on short messages. -This is the reference C code of SipHash: portable, simple, optimized for clarity and debugging. - -SipHash was designed in 2012 by [Jean-Philippe Aumasson](https://aumasson.jp) -and [Daniel J. Bernstein](https://cr.yp.to) as a defense against [hash-flooding -DoS attacks](https://aumasson.jp/siphash/siphashdos_29c3_slides.pdf). - -SipHash is: - -* *Simpler and faster* on short messages than previous cryptographic -algorithms, such as MACs based on universal hashing. - -* *Competitive in performance* with insecure non-cryptographic algorithms, such as [fhhash](https://github.com/cbreeden/fxhash). - -* *Cryptographically secure*, with no sign of weakness despite multiple [cryptanalysis](https://eprint.iacr.org/2019/865) [projects](https://eprint.iacr.org/2019/865) by leading cryptographers. - -* *Battle-tested*, with successful integration in OSs (Linux kernel, OpenBSD, -FreeBSD, FreeRTOS), languages (Perl, Python, Ruby, etc.), libraries (OpenSSL libcrypto, -Sodium, etc.) and applications (Wireguard, Redis, etc.). - -As a secure pseudorandom function (a.k.a. keyed hash function), SipHash can also be used as a secure message authentication code (MAC). -But SipHash is *not a hash* in the sense of general-purpose key-less hash function such as BLAKE3 or SHA-3. -SipHash should therefore always be used with a secret key in order to be secure. - - -## Variants - -The default SipHash is *SipHash-2-4*: it takes a 128-bit key, does 2 compression -rounds, 4 finalization rounds, and returns a 64-bit tag. - -Variants can use a different number of rounds. For example, we proposed *SipHash-4-8* as a conservative version. - -The following versions are not described in the paper but were designed and analyzed to fulfill applications' needs: - -* *SipHash-128* returns a 128-bit tag instead of 64-bit. Versions with specified number of rounds are SipHash-2-4-128, SipHash4-8-128, and so on. - -* *HalfSipHash* works with 32-bit words instead of 64-bit, takes a 64-bit key, -and returns 32-bit or 64-bit tags. For example, HalfSipHash-2-4-32 has 2 -compression rounds, 4 finalization rounds, and returns a 32-bit tag. - - -## Security - -(Half)SipHash-*c*-*d* with *c* ≥ 2 and *d* ≥ 4 is expected to provide the maximum PRF -security for any function with the same key and output size. - -The standard PRF security goal allow the attacker access to the output of SipHash on messages chosen adaptively by the attacker. - -Security is limited by the key size (128 bits for SipHash), such that -attackers searching 2*s* keys have chance 2*s*−128 of finding -the SipHash key. -Security is also limited by the output size. In particular, when -SipHash is used as a MAC, an attacker who blindly tries 2*s* tags will -succeed with probability 2*s*-*t*, if *t* is that tag's bit size. - - -## Research - -* [Research paper](https://www.aumasson.jp/siphash/siphash.pdf) "SipHash: a fast short-input PRF" (accepted at INDOCRYPT 2012) -* [Slides](https://cr.yp.to/talks/2012.12.12/slides.pdf) of the presentation of SipHash at INDOCRYPT 2012 (Bernstein) -* [Slides](https://www.aumasson.jp/siphash/siphash_slides.pdf) of the presentation of SipHash at the DIAC workshop (Aumasson) - - -## Usage - -Running - -```sh - make -``` - -will build tests for - -* SipHash-2-4-64 -
[llvm-branch-commits] [compiler-rt] backport to release/17.x (PR #94397)
https://github.com/wrotki created
https://github.com/llvm/llvm-project/pull/94397
The greendragon was recently moved and now it runs on somewhat newer macOS
version - which breaks some sanitizers tests
rdar://125052915
(cherry picked from commit 2347384476d680f5c7e5ba37d5834b2a1c8282f2)
>From 7cb964cf203d1253510c343254788ee16978c51b Mon Sep 17 00:00:00 2001
From: Mariusz Borsa
Date: Wed, 20 Mar 2024 16:15:47 -0700
Subject: [PATCH] [Sanitizers][Darwin] Bump up
DEFAULT_SANITIZER_MIN_OSX_VERSION
The greendragon was recently moved and now it runs on somewhat newer macOS
version - which breaks some sanitizers tests
rdar://125052915
(cherry picked from commit 2347384476d680f5c7e5ba37d5834b2a1c8282f2)
---
compiler-rt/cmake/config-ix.cmake | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/compiler-rt/cmake/config-ix.cmake
b/compiler-rt/cmake/config-ix.cmake
index 8d3dc8d208b25..9243dcd5e93e0 100644
--- a/compiler-rt/cmake/config-ix.cmake
+++ b/compiler-rt/cmake/config-ix.cmake
@@ -446,7 +446,7 @@ if(APPLE)
# Note: In order to target x86_64h on OS X the minimum deployment target must
# be 10.8 or higher.
- set(DEFAULT_SANITIZER_MIN_OSX_VERSION 10.10)
+ set(DEFAULT_SANITIZER_MIN_OSX_VERSION 10.13)
set(DARWIN_osx_MIN_VER_FLAG "-mmacosx-version-min")
if(NOT SANITIZER_MIN_OSX_VERSION)
string(REGEX MATCH "${DARWIN_osx_MIN_VER_FLAG}=([.0-9]+)"
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [compiler-rt] backport to release/17.x (PR #94397)
https://github.com/github-actions[bot] closed https://github.com/llvm/llvm-project/pull/94397 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [compiler-rt] backport to release/17.x (PR #94397)
github-actions[bot] wrote: This repository does not accept pull requests. Please follow http://llvm.org/docs/Contributing.html#how-to-submit-a-patch for contribution to LLVM. https://github.com/llvm/llvm-project/pull/94397 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [compiler-rt] backport to release/17.x (PR #94397)
https://github.com/github-actions[bot] locked https://github.com/llvm/llvm-project/pull/94397 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)
https://github.com/AaronBallman edited https://github.com/llvm/llvm-project/pull/94248 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)
https://github.com/AaronBallman commented: I wonder if we should add some documentation to ASTMatchers.h about the new special syntax for comments so that users who hit test failures with the new automatic tests have some more help getting to a solution. https://github.com/llvm/llvm-project/pull/94248 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)
@@ -330,35 +377,46 @@ AST_POLYMORPHIC_MATCHER_P(isExpandedFromMacro,
/// Matches declarations.
///
-/// Examples matches \c X, \c C, and the friend declaration inside \c C;
+/// Given
/// \code
/// void X();
/// class C {
-/// friend X;
+/// friend void X();
/// };
/// \endcode
+/// \compile_args{-std=c++}
+/// The matcher \matcher{decl()}
+/// matches \match{void X()}, \match{type=name;count=2$C}
+/// and \match{count=2$friend void X()}.
AaronBallman wrote:
Can you explain `\match{type=name;count=2$C}`? I can see it matching `class C`,
but I'm wondering what the second match is (and should we add a comment
explaining that other match?).
https://github.com/llvm/llvm-project/pull/94248
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)
@@ -176,11 +176,13 @@ inline internal::TrueMatcher anything() { return
internal::TrueMatcher(); }
/// \code
/// int X;
/// namespace NS {
-/// int Y;
+/// int Y;
/// } // namespace NS
/// \endcode
-/// decl(hasDeclContext(translationUnitDecl()))
-/// matches "int X", but not "int Y".
+/// \compile_args{-std=c++}
+/// The matcher \matcher{namedDecl(hasDeclContext(translationUnitDecl()))}
+/// matches \match{type=name$X} and \match{type=name$NS},
AaronBallman wrote:
Under what circumstances do you need to use this special `type=name$foo` syntax?
https://github.com/llvm/llvm-project/pull/94248
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] release/18.x: [PPCMergeStringPool] Only replace constant once (#92996) (PR #93442)
https://github.com/llvmbot updated
https://github.com/llvm/llvm-project/pull/93442
>From 7e6ece9b4f2d37caf8ff7b87603f15ed9ad2d6ec Mon Sep 17 00:00:00 2001
From: Nikita Popov
Date: Mon, 27 May 2024 08:54:11 +0200
Subject: [PATCH] [PPCMergeStringPool] Only replace constant once (#92996)
In #88846 I changed this code to use RAUW to perform the replacement
instead of manual updates -- but kept the outer loop, which means we try
to perform RAUW once per user. However, some of the users might be freed
by the RAUW operation, resulting in use-after-free.
The case where this happens is constant users where the replacement
might result in the destruction of the original constant.
Fixes https://github.com/llvm/llvm-project/issues/92991.
(cherry picked from commit 9f85bc834b07ebfec9e5e02deb9255a0f6ec5cc7)
---
.../lib/Target/PowerPC/PPCMergeStringPool.cpp | 37 ---
.../PowerPC/mergeable-string-pool-pr92991.ll | 20 ++
2 files changed, 27 insertions(+), 30 deletions(-)
create mode 100644 llvm/test/CodeGen/PowerPC/mergeable-string-pool-pr92991.ll
diff --git a/llvm/lib/Target/PowerPC/PPCMergeStringPool.cpp
b/llvm/lib/Target/PowerPC/PPCMergeStringPool.cpp
index ebd876d50c44e..0830b02370cd0 100644
--- a/llvm/lib/Target/PowerPC/PPCMergeStringPool.cpp
+++ b/llvm/lib/Target/PowerPC/PPCMergeStringPool.cpp
@@ -290,13 +290,6 @@ bool PPCMergeStringPool::mergeModuleStringPool(Module &M) {
return true;
}
-static bool userHasOperand(User *TheUser, GlobalVariable *GVOperand) {
- for (Value *Op : TheUser->operands())
-if (Op == GVOperand)
- return true;
- return false;
-}
-
// For pooled strings we need to add the offset into the pool for each string.
// This is done by adding a Get Element Pointer (GEP) before each user. This
// function adds the GEP.
@@ -307,29 +300,13 @@ void
PPCMergeStringPool::replaceUsesWithGEP(GlobalVariable *GlobalToReplace,
Indices.push_back(ConstantInt::get(Type::getInt32Ty(*Context), 0));
Indices.push_back(ConstantInt::get(Type::getInt32Ty(*Context),
ElementIndex));
- // Need to save a temporary copy of each user list because we remove uses
- // as we replace them.
- SmallVector Users;
- for (User *CurrentUser : GlobalToReplace->users())
-Users.push_back(CurrentUser);
-
- for (User *CurrentUser : Users) {
-// The user was not found so it must have been replaced earlier.
-if (!userHasOperand(CurrentUser, GlobalToReplace))
- continue;
-
-// We cannot replace operands in globals so we ignore those.
-if (isa(CurrentUser))
- continue;
-
-Constant *ConstGEP = ConstantExpr::getInBoundsGetElementPtr(
-PooledStructType, GPool, Indices);
-LLVM_DEBUG(dbgs() << "Replacing this global:\n");
-LLVM_DEBUG(GlobalToReplace->dump());
-LLVM_DEBUG(dbgs() << "with this:\n");
-LLVM_DEBUG(ConstGEP->dump());
-GlobalToReplace->replaceAllUsesWith(ConstGEP);
- }
+ Constant *ConstGEP =
+ ConstantExpr::getInBoundsGetElementPtr(PooledStructType, GPool, Indices);
+ LLVM_DEBUG(dbgs() << "Replacing this global:\n");
+ LLVM_DEBUG(GlobalToReplace->dump());
+ LLVM_DEBUG(dbgs() << "with this:\n");
+ LLVM_DEBUG(ConstGEP->dump());
+ GlobalToReplace->replaceAllUsesWith(ConstGEP);
}
} // namespace
diff --git a/llvm/test/CodeGen/PowerPC/mergeable-string-pool-pr92991.ll
b/llvm/test/CodeGen/PowerPC/mergeable-string-pool-pr92991.ll
new file mode 100644
index 0..4e9c69e5fe4cf
--- /dev/null
+++ b/llvm/test/CodeGen/PowerPC/mergeable-string-pool-pr92991.ll
@@ -0,0 +1,20 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
UTC_ARGS: --version 5
+; RUN: llc -mtriple=powerpc64le-unknown-linux-gnu < %s | FileCheck %s
+
+@g = private constant [4 x i32] [i32 122, i32 67, i32 35, i32 56]
+@g2 = private constant [1 x i64] [i64 1], align 8
+
+define void @test(ptr %p, ptr %p2) {
+; CHECK-LABEL: test:
+; CHECK: # %bb.0:
+; CHECK-NEXT:addis 5, 2, .L__ModuleStringPool@toc@ha
+; CHECK-NEXT:addi 5, 5, .L__ModuleStringPool@toc@l
+; CHECK-NEXT:addi 6, 5, 12
+; CHECK-NEXT:std 6, 0(3)
+; CHECK-NEXT:addi 3, 5, 16
+; CHECK-NEXT:std 3, 0(4)
+; CHECK-NEXT:blr
+ store ptr getelementptr inbounds ([4 x i32], ptr @g, i64 0, i64 1), ptr %p
+ store ptr getelementptr inbounds ([4 x i32], ptr @g, i64 0, i64 2), ptr %p2
+ ret void
+}
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] release/18.x: [PPCMergeStringPool] Only replace constant once (#92996) (PR #93442)
tstellar wrote: What release note should we use for this change? https://github.com/llvm/llvm-project/pull/93442 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] 7e6ece9 - [PPCMergeStringPool] Only replace constant once (#92996)
Author: Nikita Popov
Date: 2024-06-04T13:50:32-07:00
New Revision: 7e6ece9b4f2d37caf8ff7b87603f15ed9ad2d6ec
URL:
https://github.com/llvm/llvm-project/commit/7e6ece9b4f2d37caf8ff7b87603f15ed9ad2d6ec
DIFF:
https://github.com/llvm/llvm-project/commit/7e6ece9b4f2d37caf8ff7b87603f15ed9ad2d6ec.diff
LOG: [PPCMergeStringPool] Only replace constant once (#92996)
In #88846 I changed this code to use RAUW to perform the replacement
instead of manual updates -- but kept the outer loop, which means we try
to perform RAUW once per user. However, some of the users might be freed
by the RAUW operation, resulting in use-after-free.
The case where this happens is constant users where the replacement
might result in the destruction of the original constant.
Fixes https://github.com/llvm/llvm-project/issues/92991.
(cherry picked from commit 9f85bc834b07ebfec9e5e02deb9255a0f6ec5cc7)
Added:
llvm/test/CodeGen/PowerPC/mergeable-string-pool-pr92991.ll
Modified:
llvm/lib/Target/PowerPC/PPCMergeStringPool.cpp
Removed:
diff --git a/llvm/lib/Target/PowerPC/PPCMergeStringPool.cpp
b/llvm/lib/Target/PowerPC/PPCMergeStringPool.cpp
index ebd876d50c44e..0830b02370cd0 100644
--- a/llvm/lib/Target/PowerPC/PPCMergeStringPool.cpp
+++ b/llvm/lib/Target/PowerPC/PPCMergeStringPool.cpp
@@ -290,13 +290,6 @@ bool PPCMergeStringPool::mergeModuleStringPool(Module &M) {
return true;
}
-static bool userHasOperand(User *TheUser, GlobalVariable *GVOperand) {
- for (Value *Op : TheUser->operands())
-if (Op == GVOperand)
- return true;
- return false;
-}
-
// For pooled strings we need to add the offset into the pool for each string.
// This is done by adding a Get Element Pointer (GEP) before each user. This
// function adds the GEP.
@@ -307,29 +300,13 @@ void
PPCMergeStringPool::replaceUsesWithGEP(GlobalVariable *GlobalToReplace,
Indices.push_back(ConstantInt::get(Type::getInt32Ty(*Context), 0));
Indices.push_back(ConstantInt::get(Type::getInt32Ty(*Context),
ElementIndex));
- // Need to save a temporary copy of each user list because we remove uses
- // as we replace them.
- SmallVector Users;
- for (User *CurrentUser : GlobalToReplace->users())
-Users.push_back(CurrentUser);
-
- for (User *CurrentUser : Users) {
-// The user was not found so it must have been replaced earlier.
-if (!userHasOperand(CurrentUser, GlobalToReplace))
- continue;
-
-// We cannot replace operands in globals so we ignore those.
-if (isa(CurrentUser))
- continue;
-
-Constant *ConstGEP = ConstantExpr::getInBoundsGetElementPtr(
-PooledStructType, GPool, Indices);
-LLVM_DEBUG(dbgs() << "Replacing this global:\n");
-LLVM_DEBUG(GlobalToReplace->dump());
-LLVM_DEBUG(dbgs() << "with this:\n");
-LLVM_DEBUG(ConstGEP->dump());
-GlobalToReplace->replaceAllUsesWith(ConstGEP);
- }
+ Constant *ConstGEP =
+ ConstantExpr::getInBoundsGetElementPtr(PooledStructType, GPool, Indices);
+ LLVM_DEBUG(dbgs() << "Replacing this global:\n");
+ LLVM_DEBUG(GlobalToReplace->dump());
+ LLVM_DEBUG(dbgs() << "with this:\n");
+ LLVM_DEBUG(ConstGEP->dump());
+ GlobalToReplace->replaceAllUsesWith(ConstGEP);
}
} // namespace
diff --git a/llvm/test/CodeGen/PowerPC/mergeable-string-pool-pr92991.ll
b/llvm/test/CodeGen/PowerPC/mergeable-string-pool-pr92991.ll
new file mode 100644
index 0..4e9c69e5fe4cf
--- /dev/null
+++ b/llvm/test/CodeGen/PowerPC/mergeable-string-pool-pr92991.ll
@@ -0,0 +1,20 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
UTC_ARGS: --version 5
+; RUN: llc -mtriple=powerpc64le-unknown-linux-gnu < %s | FileCheck %s
+
+@g = private constant [4 x i32] [i32 122, i32 67, i32 35, i32 56]
+@g2 = private constant [1 x i64] [i64 1], align 8
+
+define void @test(ptr %p, ptr %p2) {
+; CHECK-LABEL: test:
+; CHECK: # %bb.0:
+; CHECK-NEXT:addis 5, 2, .L__ModuleStringPool@toc@ha
+; CHECK-NEXT:addi 5, 5, .L__ModuleStringPool@toc@l
+; CHECK-NEXT:addi 6, 5, 12
+; CHECK-NEXT:std 6, 0(3)
+; CHECK-NEXT:addi 3, 5, 16
+; CHECK-NEXT:std 3, 0(4)
+; CHECK-NEXT:blr
+ store ptr getelementptr inbounds ([4 x i32], ptr @g, i64 0, i64 1), ptr %p
+ store ptr getelementptr inbounds ([4 x i32], ptr @g, i64 0, i64 2), ptr %p2
+ ret void
+}
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] release/18.x: [PPCMergeStringPool] Only replace constant once (#92996) (PR #93442)
https://github.com/tstellar closed https://github.com/llvm/llvm-project/pull/93442 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] gn build: Embed libc++abi.a objects into libc++.a. (PR #88463)
pcc wrote: Hmm, after actually doing a CMake build it doesn't seem to be the CMake default in fact. It's what you get if you set `LIBCXX_ENABLE_STATIC_ABI_LIBRARY` to true. I think I got the idea that it was the default after inspecting the NDK compiler, which was built with `LIBCXX_ENABLE_STATIC_ABI_LIBRARY` set to true, combined with the fact that `-static-libstdc++ -stdlib=libc++` does not work out of the box unless you set this (several CMake caches set `LIBCXX_ENABLE_STATIC_ABI_LIBRARY` to true, presumably in order to get this working). Conceptually we want `libc++.a` to be like `libc++.so`, which is a linker script that causes `libc++.so.1` and `libc++abi.so` to be linked. One way to do that would be to make it a linker script as well. But the other way would be to combine `libc++.a` and `libc++abi.a` by default. On the CMake side that's controlled by `LIBCXX_STATICALLY_LINK_ABI_IN_STATIC_LIBRARY` which defaults to `LIBCXX_ENABLE_STATIC_ABI_LIBRARY`. So maybe the right fix here would be to change `LIBCXX_STATICALLY_LINK_ABI_IN_STATIC_LIBRARY` to default to true, and land this patch to make the gn build consistent? https://github.com/llvm/llvm-project/pull/88463 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] release/18.x: [PPCMergeStringPool] Only replace constant once (#92996) (PR #93442)
nikic wrote: > What release note should we use for this change? Something like this maybe? > Fix a regression from the 18.1.6 release, which could result in compiler > crashes in the PPCMergeStringPool pass when compiling for PowerPC targets. https://github.com/llvm/llvm-project/pull/93442 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [Support] Integrate SipHash.cpp into libSupport. (PR #94394)
https://github.com/ahmedbougacha updated https://github.com/llvm/llvm-project/pull/94394 >From 1e9a3fde97d907c3cd6be33db91d1c18c7236ffb Mon Sep 17 00:00:00 2001 From: Ahmed Bougacha Date: Tue, 4 Jun 2024 12:41:47 -0700 Subject: [PATCH 1/3] [Support] Reformat SipHash.cpp to match libSupport. While there, give it our usual file header and an acknowledgement, and remove the imported README.md.SipHash. --- llvm/lib/Support/README.md.SipHash | 126 -- llvm/lib/Support/SipHash.cpp | 264 ++--- 2 files changed, 129 insertions(+), 261 deletions(-) delete mode 100644 llvm/lib/Support/README.md.SipHash diff --git a/llvm/lib/Support/README.md.SipHash b/llvm/lib/Support/README.md.SipHash deleted file mode 100644 index 4de3cd1854681..0 --- a/llvm/lib/Support/README.md.SipHash +++ /dev/null @@ -1,126 +0,0 @@ -# SipHash - -[](http://creativecommons.org/publicdomain/zero/1.0/) - -[](https://opensource.org/licenses/MIT) - - -SipHash is a family of pseudorandom functions (PRFs) optimized for speed on short messages. -This is the reference C code of SipHash: portable, simple, optimized for clarity and debugging. - -SipHash was designed in 2012 by [Jean-Philippe Aumasson](https://aumasson.jp) -and [Daniel J. Bernstein](https://cr.yp.to) as a defense against [hash-flooding -DoS attacks](https://aumasson.jp/siphash/siphashdos_29c3_slides.pdf). - -SipHash is: - -* *Simpler and faster* on short messages than previous cryptographic -algorithms, such as MACs based on universal hashing. - -* *Competitive in performance* with insecure non-cryptographic algorithms, such as [fhhash](https://github.com/cbreeden/fxhash). - -* *Cryptographically secure*, with no sign of weakness despite multiple [cryptanalysis](https://eprint.iacr.org/2019/865) [projects](https://eprint.iacr.org/2019/865) by leading cryptographers. - -* *Battle-tested*, with successful integration in OSs (Linux kernel, OpenBSD, -FreeBSD, FreeRTOS), languages (Perl, Python, Ruby, etc.), libraries (OpenSSL libcrypto, -Sodium, etc.) and applications (Wireguard, Redis, etc.). - -As a secure pseudorandom function (a.k.a. keyed hash function), SipHash can also be used as a secure message authentication code (MAC). -But SipHash is *not a hash* in the sense of general-purpose key-less hash function such as BLAKE3 or SHA-3. -SipHash should therefore always be used with a secret key in order to be secure. - - -## Variants - -The default SipHash is *SipHash-2-4*: it takes a 128-bit key, does 2 compression -rounds, 4 finalization rounds, and returns a 64-bit tag. - -Variants can use a different number of rounds. For example, we proposed *SipHash-4-8* as a conservative version. - -The following versions are not described in the paper but were designed and analyzed to fulfill applications' needs: - -* *SipHash-128* returns a 128-bit tag instead of 64-bit. Versions with specified number of rounds are SipHash-2-4-128, SipHash4-8-128, and so on. - -* *HalfSipHash* works with 32-bit words instead of 64-bit, takes a 64-bit key, -and returns 32-bit or 64-bit tags. For example, HalfSipHash-2-4-32 has 2 -compression rounds, 4 finalization rounds, and returns a 32-bit tag. - - -## Security - -(Half)SipHash-*c*-*d* with *c* ≥ 2 and *d* ≥ 4 is expected to provide the maximum PRF -security for any function with the same key and output size. - -The standard PRF security goal allow the attacker access to the output of SipHash on messages chosen adaptively by the attacker. - -Security is limited by the key size (128 bits for SipHash), such that -attackers searching 2*s* keys have chance 2*s*−128 of finding -the SipHash key. -Security is also limited by the output size. In particular, when -SipHash is used as a MAC, an attacker who blindly tries 2*s* tags will -succeed with probability 2*s*-*t*, if *t* is that tag's bit size. - - -## Research - -* [Research paper](https://www.aumasson.jp/siphash/siphash.pdf) "SipHash: a fast short-input PRF" (accepted at INDOCRYPT 2012) -* [Slides](https://cr.yp.to/talks/2012.12.12/slides.pdf) of the presentation of SipHash at INDOCRYPT 2012 (Bernstein) -* [Slides](https://www.aumasson.jp/siphash/siphash_slides.pdf) of the presentation of SipHash at the DIAC workshop (Aumasson) - - -## Usage - -Running - -```sh - make -``` - -will build tests for - -* SipHash-2-4-64 -* SipHash-2-4-128 -* HalfSipHash-2-4-32 -* HalfSipHash-2-4-64 - - -```C - ./test -``` - -verifies 64 test vectors, and - -```C - ./debug -``` - -does the same and prints intermediate values. - -The code can be adapted to implement SipHash-*c*-*d*, the version of SipHash -with *c* compression rounds and *d* finalization rounds, by defining `cROUNDS` -or `dROUNDS` when compiling. This can be done with `-D` command line arguments -to many compilers such as below. - -```sh -gcc -Wall --
[llvm-branch-commits] [llvm] [Support] Integrate SipHash.cpp into libSupport. (PR #94394)
https://github.com/ahmedbougacha ready_for_review https://github.com/llvm/llvm-project/pull/94394 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [Support] Integrate SipHash.cpp into libSupport. (PR #94394)
llvmbot wrote: @llvm/pr-subscribers-llvm-support Author: Ahmed Bougacha (ahmedbougacha) Changes Start building it as part of the library, with some minor tweaks compared to the reference implementation: - clang-format to match libSupport - remove tracing support - add file header - templatize cROUNDS/dROUNDS, as well as 8B/16B result type - replace assert with static_assert - return the result directly, as uint64_t/uint128_t - remove big-endian support - use LLVM_FALLTHROUGH - remove tracing support The siphash function itself isn't used yet, and will be in a follow-up commit. --- Full diff: https://github.com/llvm/llvm-project/pull/94394.diff 3 Files Affected: - (modified) llvm/lib/Support/CMakeLists.txt (+1-3) - (removed) llvm/lib/Support/README.md.SipHash (-126) - (modified) llvm/lib/Support/SipHash.cpp (+126-176) ``diff diff --git a/llvm/lib/Support/CMakeLists.txt b/llvm/lib/Support/CMakeLists.txt index 7cc01a5399911..f5f8447d48d01 100644 --- a/llvm/lib/Support/CMakeLists.txt +++ b/llvm/lib/Support/CMakeLists.txt @@ -127,9 +127,6 @@ endif() add_subdirectory(BLAKE3) -# Temporarily ignore SipHash.cpp before we fully integrate it into LLVMSupport. -set(LLVM_OPTIONAL_SOURCES SipHash.cpp) - add_llvm_component_library(LLVMSupport ABIBreak.cpp AMDGPUMetadata.cpp @@ -226,6 +223,7 @@ add_llvm_component_library(LLVMSupport SHA1.cpp SHA256.cpp Signposts.cpp + SipHash.cpp SmallPtrSet.cpp SmallVector.cpp SourceMgr.cpp diff --git a/llvm/lib/Support/README.md.SipHash b/llvm/lib/Support/README.md.SipHash deleted file mode 100644 index 4de3cd1854681..0 --- a/llvm/lib/Support/README.md.SipHash +++ /dev/null @@ -1,126 +0,0 @@ -# SipHash - -[](http://creativecommons.org/publicdomain/zero/1.0/) - -[](https://opensource.org/licenses/MIT) - - -SipHash is a family of pseudorandom functions (PRFs) optimized for speed on short messages. -This is the reference C code of SipHash: portable, simple, optimized for clarity and debugging. - -SipHash was designed in 2012 by [Jean-Philippe Aumasson](https://aumasson.jp) -and [Daniel J. Bernstein](https://cr.yp.to) as a defense against [hash-flooding -DoS attacks](https://aumasson.jp/siphash/siphashdos_29c3_slides.pdf). - -SipHash is: - -* *Simpler and faster* on short messages than previous cryptographic -algorithms, such as MACs based on universal hashing. - -* *Competitive in performance* with insecure non-cryptographic algorithms, such as [fhhash](https://github.com/cbreeden/fxhash). - -* *Cryptographically secure*, with no sign of weakness despite multiple [cryptanalysis](https://eprint.iacr.org/2019/865) [projects](https://eprint.iacr.org/2019/865) by leading cryptographers. - -* *Battle-tested*, with successful integration in OSs (Linux kernel, OpenBSD, -FreeBSD, FreeRTOS), languages (Perl, Python, Ruby, etc.), libraries (OpenSSL libcrypto, -Sodium, etc.) and applications (Wireguard, Redis, etc.). - -As a secure pseudorandom function (a.k.a. keyed hash function), SipHash can also be used as a secure message authentication code (MAC). -But SipHash is *not a hash* in the sense of general-purpose key-less hash function such as BLAKE3 or SHA-3. -SipHash should therefore always be used with a secret key in order to be secure. - - -## Variants - -The default SipHash is *SipHash-2-4*: it takes a 128-bit key, does 2 compression -rounds, 4 finalization rounds, and returns a 64-bit tag. - -Variants can use a different number of rounds. For example, we proposed *SipHash-4-8* as a conservative version. - -The following versions are not described in the paper but were designed and analyzed to fulfill applications' needs: - -* *SipHash-128* returns a 128-bit tag instead of 64-bit. Versions with specified number of rounds are SipHash-2-4-128, SipHash4-8-128, and so on. - -* *HalfSipHash* works with 32-bit words instead of 64-bit, takes a 64-bit key, -and returns 32-bit or 64-bit tags. For example, HalfSipHash-2-4-32 has 2 -compression rounds, 4 finalization rounds, and returns a 32-bit tag. - - -## Security - -(Half)SipHash-*c*-*d* with *c* ≥ 2 and *d* ≥ 4 is expected to provide the maximum PRF -security for any function with the same key and output size. - -The standard PRF security goal allow the attacker access to the output of SipHash on messages chosen adaptively by the attacker. - -Security is limited by the key size (128 bits for SipHash), such that -attackers searching 2*s* keys have chance 2*s*−128 of finding -the SipHash key. -Security is also limited by the output size. In particular, when -SipHash is used as a MAC, an attacker who blindly tries 2*s* tags will -succeed with probability 2*s*-*t*, if *t* is that tag's bit size. - - -## Research - -* [Research paper](https://www.aumasson.jp/siphash/siphash.pdf) "SipHash: a fast short-input PRF" (accepted at INDOCR
[llvm-branch-commits] [llvm] [Support] Add SipHash-based 16/64-bit ptrauth stable hash. (PR #93902)
https://github.com/ahmedbougacha edited https://github.com/llvm/llvm-project/pull/93902 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [Support] Add SipHash-based 16/64-bit ptrauth stable hash. (PR #93902)
@@ -0,0 +1,47 @@
+//===--- SipHash.h - An ABI-stable string SipHash ---*- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// A family of ABI-stable string hash algorithms based on SipHash, currently
+// used to compute ptrauth discriminators.
+//
+//===--===//
+
+#ifndef LLVM_SUPPORT_SIPHASH_H
+#define LLVM_SUPPORT_SIPHASH_H
+
+#include
+
+namespace llvm {
+class StringRef;
+
+/// Compute a stable 64-bit hash of the given string.
+///
+/// The exact algorithm is the little-endian interpretation of the
+/// non-doubled (i.e. 64-bit) result of applying a SipHash-2-4 using
+/// a specific key value which can be found in the source.
+///
+/// By "stable" we mean that the result of this hash algorithm will
+/// the same across different compiler versions and target platforms.
+uint64_t getPointerAuthStableSipHash64(StringRef S);
+
+/// Compute a stable non-zero 16-bit hash of the given string.
+///
+/// This computes the full getPointerAuthStableSipHash64, but additionally
+/// truncates it down to a non-zero 16-bit value.
+///
+/// We use a 16-bit discriminator because ARM64 can efficiently load
+/// a 16-bit immediate into the high bits of a register without disturbing
+/// the remainder of the value, which serves as a nice blend operation.
+/// 16 bits is also sufficiently compact to not inflate a loader relocation.
+/// We disallow zero to guarantee a different discriminator from the places
+/// in the ABI that use a constant zero.
+uint64_t getPointerAuthStableSipHash16(StringRef S);
ahmedbougacha wrote:
It's always used as a 64-bit value and in i64 contexts, but I can see how
that's too subtle of a distinction, one that doesn't make a practical
difference anyway. Replaced with `uint16_t`.
https://github.com/llvm/llvm-project/pull/93902
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [Support] Add SipHash-based 16/64-bit ptrauth stable hash. (PR #93902)
ahmedbougacha wrote: I split out: - https://github.com/llvm/llvm-project/pull/94393 - https://github.com/llvm/llvm-project/pull/94394 and rebased this on top: we're now left with only the thin wrapper (the 16-bit one only here) and the simple unittests. https://github.com/llvm/llvm-project/pull/93902 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [Support] Add SipHash-based 16/64-bit ptrauth stable hash. (PR #93902)
@@ -0,0 +1,174 @@
+//===--- StableHash.cpp - An ABI-stable string hash
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file implements an ABI-stable string hash based on SipHash, used to
+// compute ptrauth discriminators.
+//
+//===--===//
+
+#include "llvm/Support/SipHash.h"
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/Debug.h"
+#include
+#include
+
+using namespace llvm;
+
+#define DEBUG_TYPE "llvm-siphash"
+
+// Lightly adapted from the SipHash reference C implementation by
+// Jean-Philippe Aumasson and Daniel J. Bernstein.
+
+#define SIPHASH_ROTL(x, b) (uint64_t)(((x) << (b)) | ((x) >> (64 - (b
+
+#define SIPHASH_U8TO64_LE(p)
\
+ (((uint64_t)((p)[0])) | ((uint64_t)((p)[1]) << 8) |
\
+ ((uint64_t)((p)[2]) << 16) | ((uint64_t)((p)[3]) << 24) |
\
+ ((uint64_t)((p)[4]) << 32) | ((uint64_t)((p)[5]) << 40) |
\
+ ((uint64_t)((p)[6]) << 48) | ((uint64_t)((p)[7]) << 56))
+
+#define SIPHASH_SIPROUND
\
+ do {
\
+v0 += v1;
\
+v1 = SIPHASH_ROTL(v1, 13);
\
+v1 ^= v0;
\
+v0 = SIPHASH_ROTL(v0, 32);
\
+v2 += v3;
\
+v3 = SIPHASH_ROTL(v3, 16);
\
+v3 ^= v2;
\
+v0 += v3;
\
+v3 = SIPHASH_ROTL(v3, 21);
\
+v3 ^= v0;
\
+v2 += v1;
\
+v1 = SIPHASH_ROTL(v1, 17);
\
+v1 ^= v2;
\
+v2 = SIPHASH_ROTL(v2, 32);
\
+ } while (0)
+
+template
+static inline ResultTy siphash(const uint8_t *in, uint64_t inlen,
+ const uint8_t (&k)[16]) {
+ static_assert(sizeof(ResultTy) == 8 || sizeof(ResultTy) == 16,
+"result type should be uint64_t or uint128_t");
+ uint64_t v0 = 0x736f6d6570736575ULL;
+ uint64_t v1 = 0x646f72616e646f6dULL;
+ uint64_t v2 = 0x6c7967656e657261ULL;
+ uint64_t v3 = 0x7465646279746573ULL;
+ uint64_t b;
+ uint64_t k0 = SIPHASH_U8TO64_LE(k);
+ uint64_t k1 = SIPHASH_U8TO64_LE(k + 8);
+ uint64_t m;
+ int i;
+ const uint8_t *end = in + inlen - (inlen % sizeof(uint64_t));
+ const int left = inlen & 7;
+ b = ((uint64_t)inlen) << 56;
+ v3 ^= k1;
+ v2 ^= k0;
+ v1 ^= k1;
+ v0 ^= k0;
+
+ if (sizeof(ResultTy) == 16) {
+v1 ^= 0xee;
+ }
+
+ for (; in != end; in += 8) {
+m = SIPHASH_U8TO64_LE(in);
+v3 ^= m;
+
+for (i = 0; i < cROUNDS; ++i)
+ SIPHASH_SIPROUND;
+
+v0 ^= m;
+ }
+
+ switch (left) {
+ case 7:
+b |= ((uint64_t)in[6]) << 48;
+LLVM_FALLTHROUGH;
+ case 6:
+b |= ((uint64_t)in[5]) << 40;
+LLVM_FALLTHROUGH;
+ case 5:
+b |= ((uint64_t)in[4]) << 32;
+LLVM_FALLTHROUGH;
+ case 4:
+b |= ((uint64_t)in[3]) << 24;
+LLVM_FALLTHROUGH;
+ case 3:
+b |= ((uint64_t)in[2]) << 16;
+LLVM_FALLTHROUGH;
+ case 2:
+b |= ((uint64_t)in[1]) << 8;
+LLVM_FALLTHROUGH;
+ case 1:
+b |= ((uint64_t)in[0]);
+break;
+ case 0:
+break;
+ }
+
+ v3 ^= b;
+
+ for (i = 0; i < cROUNDS; ++i)
+SIPHASH_SIPROUND;
+
+ v0 ^= b;
+
+ if (sizeof(ResultTy) == 8) {
+v2 ^= 0xff;
+ } else {
+v2 ^= 0xee;
+ }
+
+ for (i = 0; i < dROUNDS; ++i)
+SIPHASH_SIPROUND;
+
+ b = v0 ^ v1 ^ v2 ^ v3;
+
+ // This mess with the result type would be easier with 'if constexpr'.
+
+ uint64_t firstHalf = b;
+ if (sizeof(ResultTy) == 8)
+return firstHalf;
+
+ v1 ^= 0xdd;
+
+ for (i = 0; i < dROUNDS; ++i)
+SIPHASH_SIPROUND;
+
+ b = v0 ^ v1 ^ v2 ^ v3;
+ uint64_t secondHalf = b;
+
+ return firstHalf | (ResultTy(secondHalf) << (sizeof(ResultTy) == 8 ? 0 :
64));
+}
+
+//===--- LLVM-specific wrappers around siphash.
+
+/// Compute an ABI-stable 64-bit hash of the given string.
+uint
[llvm-branch-commits] [llvm] [Support] Add SipHash-based 16/64-bit ptrauth stable hash. (PR #93902)
https://github.com/ahmedbougacha edited https://github.com/llvm/llvm-project/pull/93902 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [Support] Add SipHash-based 16/64-bit ptrauth stable hash. (PR #93902)
https://github.com/ahmedbougacha edited https://github.com/llvm/llvm-project/pull/93902 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [Support] Add SipHash-based 16/64-bit ptrauth stable hash. (PR #93902)
https://github.com/ahmedbougacha edited https://github.com/llvm/llvm-project/pull/93902 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] [Support] Add SipHash-based 16-bit ptrauth stable hash. (PR #93902)
https://github.com/ahmedbougacha edited https://github.com/llvm/llvm-project/pull/93902 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm][IR] Extend BranchWeightMetadata to track provenance of weights (PR #86609)
ilovepi wrote: @MatzeB @david-xl are there any lingering issues I've missed? I think all the comments have been addressed now. https://github.com/llvm/llvm-project/pull/86609 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)
https://github.com/5chmidti edited https://github.com/llvm/llvm-project/pull/94248 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [BOLT][BAT] Add support for three-way split functions (PR #93760)
https://github.com/dcci requested changes to this pull request. https://github.com/llvm/llvm-project/pull/93760 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [BOLT][BAT] Add support for three-way split functions (PR #93760)
https://github.com/dcci edited https://github.com/llvm/llvm-project/pull/93760 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [BOLT][BAT] Add support for three-way split functions (PR #93760)
@@ -129,6 +129,8 @@ void BoltAddressTranslation::write(const BinaryContext &BC,
raw_ostream &OS) {
LLVM_DEBUG(dbgs() << " Cold part\n");
for (const FunctionFragment &FF :
Function.getLayout().getSplitFragments()) {
+ if (FF.empty())
dcci wrote:
can you add a comment explaining why we're skipping empty fragments?
https://github.com/llvm/llvm-project/pull/93760
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)
https://github.com/5chmidti edited https://github.com/llvm/llvm-project/pull/94248 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)
@@ -176,11 +176,13 @@ inline internal::TrueMatcher anything() { return
internal::TrueMatcher(); }
/// \code
/// int X;
/// namespace NS {
-/// int Y;
+/// int Y;
/// } // namespace NS
/// \endcode
-/// decl(hasDeclContext(translationUnitDecl()))
-/// matches "int X", but not "int Y".
+/// \compile_args{-std=c++}
+/// The matcher \matcher{namedDecl(hasDeclContext(translationUnitDecl()))}
+/// matches \match{type=name$X} and \match{type=name$NS},
5chmidti wrote:
Using `type=name` can be generally considered to be a
style/readability/expressiveness choice if the AST node supports it. The `X`
example would probably be better spelling the declaration out, the same goes
for `Y` (probably remnants of the early days). There may be other trivial
examples that could be spelled out.
There are for sure some more trivial cases which could be spelled out. I'll
check on the documentation again tomorrow and provide some updates (also w.r.t
to your other comment).
If we wanted to spell out the namespace, we could, but that would require
writing the `NS` in a single line. It's an artificial limitation in the script
that can probably be implemented if we want to have the option.
https://github.com/llvm/llvm-project/pull/94248
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)
https://github.com/5chmidti commented: > I wonder if we should add some documentation to ASTMatchers.h I'll add one in a day or so. I updated the description with some more information, and I'll probably take parts of that as a basis for the comment in the header (and update the script comment as well). > so that users who hit test failures with the new automatic tests have some > more help getting to a solution. There is now a `What if ...?` section to the pr description, which I will put into the header comment as well. https://github.com/llvm/llvm-project/pull/94248 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [clang] [clang][test] add testing for the AST matcher reference (PR #94248)
@@ -330,35 +377,46 @@ AST_POLYMORPHIC_MATCHER_P(isExpandedFromMacro,
/// Matches declarations.
///
-/// Examples matches \c X, \c C, and the friend declaration inside \c C;
+/// Given
/// \code
/// void X();
/// class C {
-/// friend X;
+/// friend void X();
/// };
/// \endcode
+/// \compile_args{-std=c++}
+/// The matcher \matcher{decl()}
+/// matches \match{void X()}, \match{type=name;count=2$C}
+/// and \match{count=2$friend void X()}.
5chmidti wrote:
```
|-FunctionDecl col:6 X 'void ()'
`-CXXRecordDecl line:2:7 class C definition
|-DefinitionData pass_in_registers empty aggregate standard_layout
trivially_copyable pod trivial literal has_constexpr_non_copy_move_ctor
can_const_default_init
| |-DefaultConstructor exists trivial constexpr needs_implicit
defaulted_is_constexpr
| |-CopyConstructor simple trivial has_const_param needs_implicit
implicit_has_const_param
| |-MoveConstructor exists simple trivial needs_implicit
| |-CopyAssignment simple trivial has_const_param needs_implicit
implicit_has_const_param
| |-MoveAssignment exists simple trivial needs_implicit
| `-Destructor simple irrelevant trivial needs_implicit
|-CXXRecordDecl col:7 implicit class C
`-FriendDecl col:17
`-FunctionDecl parent 0xf23a388 prev 0xf284370 col:17
friend X 'void ()'
```
> Can you explain `\match{type=name;count=2$C}`?
That is the `implicit class C` in the AST above. I couldn't access it from the
top-level `C` and I couldn't find a way from the `implicit class C` back to the
top-level one, so I don't know how to call it. I thought it would be a decl but
not a definition, however, `getDefinition` returns a `nullptr` for the
`implicit class C`.
> should we add a comment explaining that other match?
Certainly. I'll read the documentation again to see if there are more cases
like this that could be improved as well.
https://github.com/llvm/llvm-project/pull/94248
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [BOLT][BAT] Add support for three-way split functions (PR #93760)
https://github.com/aaupov updated https://github.com/llvm/llvm-project/pull/93760 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [BOLT][BAT] Add support for three-way split functions (PR #93760)
https://github.com/aaupov updated https://github.com/llvm/llvm-project/pull/93760 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [llvm] 2e96a19 - Revert "[symbolizer] Empty string is not an error (#92660)"
Author: Serge Pavlov
Date: 2024-06-05T10:58:52+07:00
New Revision: 2e96a199a72cdc88e140d0b4dc2a73d32bad762d
URL:
https://github.com/llvm/llvm-project/commit/2e96a199a72cdc88e140d0b4dc2a73d32bad762d
DIFF:
https://github.com/llvm/llvm-project/commit/2e96a199a72cdc88e140d0b4dc2a73d32bad762d.diff
LOG: Revert "[symbolizer] Empty string is not an error (#92660)"
This reverts commit 22a7f7c3314328dd1ac20042158f4b68a4ac5c1f.
Added:
Modified:
llvm/test/tools/llvm-symbolizer/get-input-file.test
llvm/tools/llvm-symbolizer/llvm-symbolizer.cpp
Removed:
diff --git a/llvm/test/tools/llvm-symbolizer/get-input-file.test
b/llvm/test/tools/llvm-symbolizer/get-input-file.test
index 50eb051968718..8c21816591c81 100644
--- a/llvm/test/tools/llvm-symbolizer/get-input-file.test
+++ b/llvm/test/tools/llvm-symbolizer/get-input-file.test
@@ -1,9 +1,9 @@
# If binary input file is not specified, llvm-symbolizer assumes it is the
first
# item in the command.
-# No input items at all. Report an unknown line, but do not produce any output
on stderr.
+# No input items at all, complain about missing input file.
RUN: echo | llvm-symbolizer 2>%t.1.err | FileCheck %s --check-prefix=NOSOURCE
-RUN: FileCheck --input-file=%t.1.err --implicit-check-not={{.}} --allow-empty
%s
+RUN: FileCheck --input-file=%t.1.err --check-prefix=NOFILE %s
# Only one input item, complain about missing addresses.
RUN: llvm-symbolizer "foo" 2>%t.2.err | FileCheck %s --check-prefix=NOSOURCE
@@ -32,6 +32,8 @@ RUN: FileCheck --input-file=%t.7.err --check-prefix=BAD-QUOTE
%s
NOSOURCE: ??
NOSOURCE-NEXT: ??:0:0
+NOFILE: error: no input filename has been specified
+
NOADDR: error: 'foo': no module offset has been specified
NOTFOUND: error: 'foo': [[MSG]]
diff --git a/llvm/tools/llvm-symbolizer/llvm-symbolizer.cpp
b/llvm/tools/llvm-symbolizer/llvm-symbolizer.cpp
index 6d7953f3109a5..b98bdbc388faf 100644
--- a/llvm/tools/llvm-symbolizer/llvm-symbolizer.cpp
+++ b/llvm/tools/llvm-symbolizer/llvm-symbolizer.cpp
@@ -337,14 +337,6 @@ static void symbolizeInput(const opt::InputArgList &Args,
object::BuildID BuildID(IncomingBuildID.begin(), IncomingBuildID.end());
uint64_t Offset = 0;
StringRef Symbol;
-
- // An empty input string may be used to check if the process is alive and
- // responding to input. Do not emit a message on stderr in this case but
- // respond on stdout.
- if (InputString.empty()) {
-printUnknownLineInfo(ModuleName, Printer);
-return;
- }
if (Error E = parseCommand(Args.getLastArgValue(OPT_obj_EQ), IsAddr2Line,
StringRef(InputString), Cmd, ModuleName, BuildID,
Symbol, Offset)) {
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
