[llvm-bugs] [Bug 42215] New: [llvm-readobj] - Tool fails to dump the object if .dynsym has sh_link field set to 0.
https://bugs.llvm.org/show_bug.cgi?id=42215
Bug ID: 42215
Summary: [llvm-readobj] - Tool fails to dump the object if
.dynsym has sh_link field set to 0.
Product: tools
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: llvm-readobj
Assignee: unassignedb...@nondot.org
Reporter: gri...@accesssoftek.com
CC: jh7370.2...@my.bristol.ac.uk, llvm-bugs@lists.llvm.org
It also applies to any other invalid value of sh_link.
Tool reports:
error: invalid sh_type for string table, expected SHT_STRTAB
and exits
while GNU readelf reports a warning and continues dumping:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL
0 0 0
readelf: Warning: [ 1]: Link field (1711276134) should index a string section.
[ 1] .dynsym DYNSYM 0180
0002 0018 A 1711276134 0 0
--
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 42216] New: [yaml2obj] - Allow custom Link field for .dynsym/.symtab sections.
https://bugs.llvm.org/show_bug.cgi?id=42216 Bug ID: 42216 Summary: [yaml2obj] - Allow custom Link field for .dynsym/.symtab sections. Product: new-bugs Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: gri...@accesssoftek.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org It is not possible now to set custom-specified sh_link field for .dynsym/.symtab sections using YAML document. -- 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 42217] New: Bad exception handling with g++/MinGW
https://bugs.llvm.org/show_bug.cgi?id=42217
Bug ID: 42217
Summary: Bad exception handling with g++/MinGW
Product: lld
Version: unspecified
Hardware: PC
OS: Windows XP
Status: NEW
Severity: enhancement
Priority: P
Component: COFF
Assignee: unassignedb...@nondot.org
Reporter: org...@gmail.com
CC: llvm-bugs@lists.llvm.org
When building with g++ and lld, an exception that is thrown from a ctor is not
properly caught.
This works fine on linux with both g++ and clang, and on MinGW with clang.
$ cat ex.cpp
#include
struct exception {};
struct Foo { Foo() { throw exception(); } };
static void func() { throw exception(); }
int main()
{
try {
func();
} catch(exception &ex) { std::cout << "Caught from func" << std::endl; }
try {
Foo tmp;
} catch(exception &ex) { std::cout << "Caught from ctor" << std::endl; }
return 0;
}
$ clang++ -fuse-ld=lld -o ex.exe main.cpp
$ ./ex
Caught from func
Caught from ctor
$ g++ -fuse-ld=lld -o ex.exe main.cpp
$ ./ex
Caught from func
terminate called after throwing an instance of 'exception'
--
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 42136] Shrink wrap can leave accesses to stack objects after frame destruction
https://bugs.llvm.org/show_bug.cgi?id=42136 Francis Visoiu Mistrih changed: What|Removed |Added Status|NEW |RESOLVED CC||franci...@yahoo.com Resolution|--- |DUPLICATE --- Comment #5 from Francis Visoiu Mistrih --- *** This bug has been marked as a duplicate of bug 37472 *** -- 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 42218] New: subsystem and os version flags are not supported
https://bugs.llvm.org/show_bug.cgi?id=42218
Bug ID: 42218
Summary: subsystem and os version flags are not supported
Product: lld
Version: unspecified
Hardware: PC
OS: Windows XP
Status: NEW
Severity: enhancement
Priority: P
Component: COFF
Assignee: unassignedb...@nondot.org
Reporter: org...@gmail.com
CC: llvm-bugs@lists.llvm.org
Qbs passes --major-subsystem-version, --minor-subsystem-version,
--major-os-version and --minor-os-version. None of them is supported in lld.
$ cat test.cpp
int main() { return 0; }
$ g++.exe -fuse-ld=lld
"-Wl,-m,i386pe,-subsystem,console,--major-subsystem-version,6,--minor-subsystem-version,00,--major-os-version,6,--minor-os-version,00"
test.cpp
lld: error: unknown argument: --major-subsystem-version
collect2.exe: error: ld returned 1 exit status
--
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 42215] [llvm-readobj] - Tool fails to dump the object if .dynsym has sh_link field set to 0.
https://bugs.llvm.org/show_bug.cgi?id=42215 George Rimar changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #2 from George Rimar --- r362938 -- 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 42179] Supoptimal code for float/double abs pattern with -Ofast
https://bugs.llvm.org/show_bug.cgi?id=42179 Sanjay Patel changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)||r362909, r362937 Resolution|--- |FIXED --- Comment #3 from Sanjay Patel --- Should be fixed with an intermediate hack: https://reviews.llvm.org/rL362909 https://reviews.llvm.org/rL362937 The more general FMF problems remain, but we have related bugs tracking those. -- 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 40113] Error parsing LLVM function without entry label
https://bugs.llvm.org/show_bug.cgi?id=40113 Yannic Bonenberger changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #3 from Yannic Bonenberger --- Found the part of the docs explaining why this doesn't work. Closing -- 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 42074] Three AddressSanitizer-x86_64-windows-dynamic coverage tests fail when building with CMAKE_LINKER=lld-link.exe
https://bugs.llvm.org/show_bug.cgi?id=42074 Reid Kleckner changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #13 from Reid Kleckner --- That became r362970. There is an open question of why VC link.exe pulls in these objects when the archive is produced by link.exe instead of LLD, but I think we can leave that unanswered for now. -- 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 41832] ELF dynamic_relocation_sections treats dynamic tag values as offsets
https://bugs.llvm.org/show_bug.cgi?id=41832 Wolfgang Pieb changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Wolfgang Pieb --- Fixed by commit 54cbae1e8d/r362969. -- 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 42219] New: [X86_64] Variadic functions unconditionally spill %XMM registers
https://bugs.llvm.org/show_bug.cgi?id=42219 Bug ID: 42219 Summary: [X86_64] Variadic functions unconditionally spill %XMM registers Product: new-bugs Version: 8.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: salim.nas...@windriver.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 22082 --> https://bugs.llvm.org/attachment.cgi?id=22082&action=edit Testcase The X86_64 ABI provides a way to determine at runtime whether any "vector" registers (e.g. SSE XMM registers) have been used to pass arguments to a variadic function. Specifically the incoming value of %al is non-zero in this case. This allows variadic functions to avoid referencing XMM registers unless the caller "expects" such a use. LLVM correctly guards the va_start code to save %XMM registers with a test of %al. Unfortunately, when compiling without optimization, the va_start setup code is itself done in several parts: 1. Spill registers to temporary stack slots 2. Reload registers from stack 3. Store reloaded values to varargs area Unfortunately (1) is done unconditionally, i.e. regardless of the outcome of the %al test. Here's an extract from the attached variadic.s: # ABI defined test: %al non-zero if any vector registers used for arguments testb %al, %al # But the following %xmm spills run regardless of the result of the previous test! movaps %xmm7, -224(%rbp) # 16-byte Spill movaps %xmm6, -240(%rbp) # 16-byte Spill ... # Skip following code if no floating point arguments je .LBB0_2 # %bb.1: # The following is the "regular" varargs spill code and is only run when vector argument registers are used # Restore original value of %xmm from stack ... movaps -336(%rbp), %xmm0 # 16-byte Reload # ... and store in varargs area movaps %xmm0, -160(%rbp) movaps -320(%rbp), %xmm1 # 16-byte Reload movaps %xmm1, -144(%rbp) ... Specifically this behavior may become a problem for OS kernel code compiled with -no-implicit-float when bug 36507 is fixed (https://reviews.llvm.org/D62639). Previously, variadic functions compiled with -no-implicit-float could safely be used even with the SSE unit disabled. If we fix 36507 without fixing the present bug, such code will lead to a crash at runtime due to reading XMM registers. I understand that it is arguable whether or not that would be a bug. For example AArch64 variadic functions always unconditionally access the vector registers. But that is because the AArch64 ABI does not provide a way to avoid this. Whereas the X86_64 ABI *does*. -- 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 42135] Response file fails with MinGW/g++
https://bugs.llvm.org/show_bug.cgi?id=42135 Martin Storsjö changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #9 from Martin Storsjö --- Should be fixed in SVN r362977. -- 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 42166] to_chars can puts leading zeros on numbers
https://bugs.llvm.org/show_bug.cgi?id=42166 Marshall Clow (home) changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #6 from Marshall Clow (home) --- Fixed in revision 362967. -- 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 41221] [meta] 8.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=41221 Bug 41221 depends on bug 41222, which changed state. Bug 41222 Summary: Merge r351577 into the 8.0 branch : Fix the buildbot issue introduced by r351421 https://bugs.llvm.org/show_bug.cgi?id=41222 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |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 41222] Merge r351577 into the 8.0 branch : Fix the buildbot issue introduced by r351421
https://bugs.llvm.org/show_bug.cgi?id=41222 Tom Stellard changed: What|Removed |Added Fixed By Commit(s)|r351577 |r351577 r363006 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Tom Stellard --- Merged: r363006 -- 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 41221] [meta] 8.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=41221 Bug 41221 depends on bug 41550, which changed state. Bug 41550 Summary: Merge r358042 to the 8.0 branch https://bugs.llvm.org/show_bug.cgi?id=41550 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |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 41550] Merge r358042 to the 8.0 branch
https://bugs.llvm.org/show_bug.cgi?id=41550 Tom Stellard changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Fixed By Commit(s)|r358042 |r358042 r363010 --- Comment #4 from Tom Stellard --- Merged: r363010 -- 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 42220] New: rvalue bound to aggregate with base class fails to bind base reference member to temporary
https://bugs.llvm.org/show_bug.cgi?id=42220
Bug ID: 42220
Summary: rvalue bound to aggregate with base class fails to
bind base reference member to temporary
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++17
Assignee: unassignedclangb...@nondot.org
Reporter: davidfink...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
The following code should bind to the two temporary Obj() and extend their
lifetimes to the lifetimes of the enclosing aggregate.
While the first case (a plain aggregate) succeeds,
the second case (a child aggregate) fails to bind to the temporary Obj(), and
DD is called too early.
The line that fails to bind in the second case is:
DerivedAgg&& x = DerivedAgg{Obj()};
void AA();
void ();
void CC();
void DD();
void SEPERATOR();
struct Obj {
inline ~Obj() {
DD();
}
};
struct Agg {
Obj&& obj;
~Agg() {
CC();
}
};
struct DerivedAgg : Agg {
~DerivedAgg() {
();
}
};
int main() {
{
// works, Agg.obj ref binds to Obj(), x binds to Agg
Agg&& x = Agg{Obj()};
AA();
}
SEPERATOR();
{
// fails in clang
// DerivedAgg.Agg.obj should bind to Obj()
// x should bind to DerivedAgg
DerivedAgg&& x = DerivedAgg{Obj()};
AA();
}
}
>From godbolt, clang (trunk), identical to output for clang 8.0.0:
main: # @main
pushrbx
sub rsp, 16
callAA()
callCC()
callDD()
callSEPERATOR()
mov rax, rsp
mov qword ptr [rsp + 8], rax
callDD()
callAA()
call()
callCC()
xor eax, eax
add rsp, 16
pop rbx
ret
Compare to gcc 9.1, which gets it right (and MSVC even gets it right too)
main:
pushrbp
callAA()
callCC()
callDD()
callSEPERATOR()
callAA()
call()
callCC()
callDD()
xor eax, eax
pop rbp
ret
--
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 42221] New: Thrown exception jumps to wrong catch, resulting in incorrectly unhandled exceptions
https://bugs.llvm.org/show_bug.cgi?id=42221
Bug ID: 42221
Summary: Thrown exception jumps to wrong catch, resulting in
incorrectly unhandled exceptions
Product: lld
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: COFF
Assignee: unassignedb...@nondot.org
Reporter: akrie...@fb.com
CC: llvm-bugs@lists.llvm.org
We've recently seen a fairly reliably reproducible error cause by what seems to
be bad exception handling codegen. Unfortunately, the code in question is part
of a large complex project and a minimal repro case was not able to be
generated.
>From observations in the VS debugger, we see the following call stack / code
structure and steps when handling exceptions. The following is my best attempt
to describe the issue.
The 'entry point' to the stack is in one translation unit:
MetadataStorage.cpp:
```
std::string MetadataStorage::getString(const std::string& key) {
std::string sql = dbqueries::MetadataGetValue::getSql();
auto stmt = db_->prepareRead(sql);
#1
stmt->bind(dbqueries::MetadataGetValue::PLACEHOLDER_KEY, key);
if (!stmt->step()) {
throw MetadataStorage::KeyNotFoundError(key);
}
return stmt->getText(dbqueries::MetadataGetValue::COLUMN_VALUE);
}
```
Call #1 is where the problem occurs. #1 goes to `SqliteData::prepareRead` in
the next file,
where we call `db_.prepare(sql)` (#3):
SqliteDatabase.cpp:
```
SqliteDatabase::SqliteDatabase(const std::string& filename, int flags) try
: db_(filename, flags),
dbFilename_(filename) {
} catch (const sqlite::SQLiteException& e) {
throw clientdb::DatabaseException(e.what(), e.getExtendedErrorCode());
#2
}
SqliteDatabase::SqliteDatabase(sqlite3* db) : db_(db), dbFilename_("") {}
std::unique_ptr SqliteDatabase::prepareRead(
const std::string& sql) {
try {
return std::make_unique(db_.prepare(sql));
#3
} catch (const sqlite::SQLiteException& e) {
throw clientdb::DatabaseException(e.what(), e.getExtendedErrorCode());
#4
}
}
```
`db_.prepare(sql)` goes to a third TU:
Database.cpp:
```
Statement Database::prepare(const std::string& sql) {
sqlite3_stmt* stmt;
int ret = sqlite3_prepare_v2(db_, sql.c_str(), -1, &stmt, nullptr);
if (ret != SQLITE_OK) {
std::string strerr = sqlite3_errmsg(db_);
int errCode = sqlite3_extended_errcode(db_);
sqlite3_finalize(stmt);
throw SQLiteException(strerr, errCode);
#5
}
return Statement(*this, stmt);
}
```
What we see is the call stack goes roughly like this:
#1
#3
#5
At #5, `SQLiteException` is thrown. We would expect the catch in `prepareRead`
to fire and statement #4 to execute. Instead, the VS debugger shows control
passes to #2 (an identically formed exception handler in the same TU). From
here, the exception handling logic eventually calls terminate() and thus
abort().
Repros with: lld 7.0.0, lld 8.0.0
Does not repro with: MS link.exe, lld 9.0.0 latest snapshot (see notes below),
Notes:
- The first time this bug presented, it was masked by solving an (undetected)
multiple symbols issue in unrelated TUs linked into the final binary. The
functions were defined in a header but not marked inline. link.exe correctly
warned about this. Making them be marked inline seemed to 'resolve' the
problem, but it has since returned, in exactly the same stack and behavior.
- lld 9.0.0 most recent snapshot does _not_ reproduce the issue. However, the
fix bisects to https://reviews.llvm.org/D59797, which looks completely
unrelated to exception handling. In conjunction with the previous fix about
inlining/not inlining functions, it's possible there was a symbol ordering
change which just masks the underlying issue and doesn't solve it.
--
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 41221] [meta] 8.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=41221 Bug 41221 depends on bug 41941, which changed state. Bug 41941 Summary: Merge r360862 to the 8.0 branch https://bugs.llvm.org/show_bug.cgi?id=41941 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |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 41941] Merge r360862 to the 8.0 branch
https://bugs.llvm.org/show_bug.cgi?id=41941 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)|r360862 |r360862 r363030 Resolution|--- |FIXED --- Comment #3 from Tom Stellard --- Merged: r363030 -- 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 42222] New: ‘inner’ declared ‘static’ in ‘constexpr’ context
https://bugs.llvm.org/show_bug.cgi?id=4
Bug ID: 4
Summary: ‘inner’ declared ‘static’ in ‘constexpr’ context
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: zhong...@pku.org.cn
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
My clang is 9.0.0, and the code is:
struct test { const int *addr; };
const test* setup()
{
static constexpr test atest =
{
({ static const int inner = 123; &inner; })
};
return &atest;
}
int main(){}
clang accepts it, but icc and gcc reject it.
gcc:
source>: In function 'const test* setup()':
:7:22: error: 'inner' declared 'static' in 'constexpr' context
7 | ({ static const int inner = 123; &inner; })
| ^
Compiler returned: 1
icc:
source>(7): error: expression must have a constant value
({ static const int inner = 123; &inner; })
^
compilation aborted for (code 2)
Compiler returned: 2
--
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 42223] New: transferring the warning on designated_init on a non-struct to an error?
https://bugs.llvm.org/show_bug.cgi?id=42223
Bug ID: 42223
Summary: transferring the warning on designated_init on a
non-struct to an error?
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: zhong...@pku.org.cn
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
My clang is 9.0.0, and the code is:
struct S {
int a;
union {
int b;
int c;
};
} __attribute__((designated_init));
static struct S s = {
.a = 0,
.b = 0,
};
union U {
int a;
struct {
int b;
int c;
} __attribute__((designated_init));
};
static union U u = {
.b = 0,
.c = 0,
};
clang produces the warnings:
:7:18: warning: unknown attribute 'designated_init' ignored
[-Wunknown-attributes]
} __attribute__((designated_init));
^
:19:19: warning: unknown attribute 'designated_init' ignored
[-Wunknown-attributes]
} __attribute__((designated_init));
^
2 warnings generated.
Compiler returned: 0
Meanwhile, gcc rejects it:
:25:1: error: too many initializers for 'U'
25 | };
| ^
Compiler returned: 1
The code comes from a gcc bug reprt:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59855
Some discussions seem to be useful.
--
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
