[llvm-bugs] [Bug 28408] clang rejects valid (?) C++ code invoking base class destructor
https://llvm.org/bugs/show_bug.cgi?id=28408 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Richard Smith --- Looks like this is a GCC bug. EDG and MSVC, like Clang, accept b->A::~A() and reject b->~A(), as the standard appears to require. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 24517] Running -jump-threading twice crashes opt in ValueHandleBase::ValueIsDeleted
https://llvm.org/bugs/show_bug.cgi?id=24517 Jesper Antonsson changed: What|Removed |Added Status|NEW |RESOLVED CC||jesper.antonsson@ericsson.c ||om Resolution|--- |WORKSFORME --- Comment #4 from Jesper Antonsson --- This bug is no longer reproducible. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 28224] [Regression] GVN optimization pass since llvm 3.8 produces wrong IR in one case
https://llvm.org/bugs/show_bug.cgi?id=28224 l...@joakim.fea.st changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #9 from l...@joakim.fea.st --- > I guess what I am trying to say is that this bug has nothing to > do with inlining: imagine that the code in imagine_shift was in > main because it was written that way. I don't have to imagine it: I noted in my comment that when I replaced the function with the exact same code, manual inlining essentially, clang warned about that expression, while it did nothing if the code was in a separate function. Since I noted this behavior on the ldc forum, one of the ldc contributors pointed me at this old llvm blog post, explaining why llvm doesn't try to warn about such behavior: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html While there are a lot of arguments there, I don't find the reasoning that "we simply don't have the internal tracking infrastructure to produce" usable error messages that follow optimizations from the original code to be convincing. I think that needs to be done. Anyway, I suppose the usual argument is that the function is wrong given certain input and it's not up to the optimizer to flag such bugs, but the code should have been tested unoptimized to shake out such bugs first. I'll look into why our debug-mode tests weren't catching this either, that's likely the real reason this got through. Of course, many people don't exhaustively test their code and it's going to make matters worse for them when the llvm optimizer just removes it without a warning. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 28410] New: Optimized code contains illegal movaps instruction when using aligned attribute in typedef
https://llvm.org/bugs/show_bug.cgi?id=28410
Bug ID: 28410
Summary: Optimized code contains illegal movaps instruction
when using aligned attribute in typedef
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: lukasz.c...@intel.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
clang generates MOVAPS instruction with wrongly aligned operand (resulting in
SEGFAULT) when compiling following code with optimizations enabled (-O2):
#include
struct Foo
{
uint32_t data[ 13 ];
};
typedef __attribute__((aligned(16))) Foo FooDef;
int counter;
struct Bar
{
FooDef array[4];
};
__attribute__ ((noinline)) void do_sth(FooDef* foo)
{
counter += ((char*)foo)[0];
}
int main()
{
Bar* bar = new Bar();
FooDef tmp = {{0}};
for (int i = 0; i < 4; i++)
{
FooDef *foo = &bar->array[i];
*foo = tmp;
do_sth(foo);
}
return 0;
}
Explanation: aligned(16) attribute is ignored when determining sizeof(FooDef)
(so sizeof(FooDef) == 52, not 64). At the other hand optimizer assumes that the
given alignment holds for all elements of bar->array which is not true due to
sizeof(FooDef) not aligned to 16 bytes.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 28411] New: isl_sioimath_add not always inlined
https://llvm.org/bugs/show_bug.cgi?id=28411
Bug ID: 28411
Summary: isl_sioimath_add not always inlined
Product: Polly
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: isl
Assignee: polly-...@googlegroups.com
Reporter: tob...@grosser.es
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Certain compilers do not always inline the functions isl_sioimath_add,
isl_sioimath_mul, and isl_sioimath_addmul. Also, a specialized shortcut for
isl_sioimath_addmul might improve the execution time of this function.
This has been observed with
https://llvm.org/svn/llvm-project/polly/trunk@274430.
We should investigate how beneficial these optimization opportunities are.
The following patch can serve as starting point:
--- a/lib/External/isl/isl_int_sioimath.h
+++ b/lib/External/isl/isl_int_sioimath.h
@@ -628,7 +628,7 @@ inline void isl_sioimath_sub_ui(isl_sioimath_ptr dst,
isl_sioimath lhs,
/* Sum of two isl_ints.
*/
-inline void isl_sioimath_add(isl_sioimath_ptr dst, isl_sioimath_src lhs,
+inline __attribute__((always_inline)) void isl_sioimath_add(isl_sioimath_ptr
dst, isl_sioimath_src lhs,
isl_sioimath_src rhs)
{
isl_sioimath_scratchspace_t scratchlhs, scratchrhs;
@@ -670,7 +670,7 @@ inline void isl_sioimath_sub(isl_sioimath_ptr dst,
isl_sioimath_src lhs,
/* Multiply two isl_ints.
*/
-inline void isl_sioimath_mul(isl_sioimath_ptr dst, isl_sioimath_src lhs,
+inline __attribute__((always_inline)) void isl_sioimath_mul(isl_sioimath_ptr
dst, isl_sioimath_src lhs,
isl_sioimath_src rhs)
{
isl_sioimath_scratchspace_t scratchlhs, scratchrhs;
@@ -799,9 +799,19 @@ inline void isl_sioimath_pow_ui(isl_sioimath_ptr dst,
isl_sioimath_src lhs,
/* Fused multiply-add.
*/
-inline void isl_sioimath_addmul(isl_sioimath_ptr dst, isl_sioimath_src lhs,
+inline __attribute__((always_inline)) void
isl_sioimath_addmul(isl_sioimath_ptr dst, isl_sioimath_src lhs,
isl_sioimath_src rhs)
{
+ int32_t smalllhs, smallrhs, smalldst;
+
+if (isl_sioimath_decode_small(lhs, &smalllhs) &&
+isl_sioimath_decode_small(rhs, &smallrhs) &&
+isl_sioimath_decode_small(*dst, &smalldst)) {
+isl_sioimath_set_int64(
+ dst, (int64_t) smalldst +
+ (int64_t) smalllhs * (int64_t) smallrhs);
+return;
+}
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 28412] New: std::vector incorrectly requires CopyConstructible, Destructible and other concepts
https://llvm.org/bugs/show_bug.cgi?id=28412
Bug ID: 28412
Summary: std::vector incorrectly requires CopyConstructible,
Destructible and other concepts
Product: libc++
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: zi...@kayari.org
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Classification: Unclassified
Container requirements are all stated in terms of CopyInsertable into X, and
Erasable from X, which involves indirection through the container's allocator.
The following test shows a class which can only be constructed/destroyed by its
allocator, revealing that std::vector tries to construct temporaries directly
without going through the allocator.
/usr/local/libcxx-head/include/c++/v1/vector:1815:24: error: call to deleted
constructor of 'value_type' (aka 'X')
#include
struct Tag { };
template
class TaggingAllocator
{
public:
using value_type = T;
TaggingAllocator() = default;
template
TaggingAllocator(const TaggingAllocator&) { }
T*
allocate(std::size_t n) { return std::allocator{}.allocate(n); }
void
deallocate(T* p, std::size_t n) { std::allocator{}.deallocate(p, n); }
template
void
construct(U* p, Args&&... args)
{ ::new((void*)p) U(Tag{}, std::forward(args)...); }
template
void
destroy(U* p)
{ p->~U(); }
};
template
bool
operator==(const TaggingAllocator&, const TaggingAllocator&)
{ return true; }
template
bool
operator!=(const TaggingAllocator&, const TaggingAllocator&)
{ return false; }
struct X
{
// All constructors must be passed the Tag type.
// DefaultInsertable into vector>,
X(Tag) { }
// CopyInsertable into vector>,
X(Tag, const X&) { }
// MoveInsertable into vector>, and
X(Tag, X&&) { }
// EmplaceConstructible into vector> from args.
template
X(Tag, Args&&...) { }
// not DefaultConstructible, CopyConstructible or MoveConstructible.
X() = delete;
X(const X&) = delete;
X(X&&) = delete;
// CopyAssignable.
X& operator=(const X&) { return *this; }
// MoveAssignable.
X& operator=(X&&) { return *this; }
private:
// Not Destructible.
~X() { }
// Erasable from vector>.
friend class TaggingAllocator;
};
int main()
{
std::vector> v;
v.reserve(3);
v.emplace_back();
v.emplace(v.begin());
v.emplace(v.begin(), 1, 2, 3);
}
// template class std::vector>;
Uncommenting the last line to explicitly instantiate the vector fails
differently, presumably there are some SFINAE conditions which make invalid
assumptions about the type.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 28413] New: [mc][gfx8] V_CMP_I/U32 -- fail to accept floating inline constants.
https://llvm.org/bugs/show_bug.cgi?id=28413 Bug ID: 28413 Summary: [mc][gfx8] V_CMP_I/U32 -- fail to accept floating inline constants. Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Backend: AMDGPU Assignee: sam.kol...@amd.com Reporter: artem.tama...@amd.com CC: llvm-bugs@lists.llvm.org, nikolay.haus...@amd.com, valery.pykh...@gmail.com Classification: Unclassified Created attachment 16684 --> https://llvm.org/bugs/attachment.cgi?id=16684&action=edit 20160704-weekly-regressions.zip 192 regressions found during weekly testing. Example of failing instruction: > v_cmp_le_i32_e64 s[0:1], 0.5, s0 Most likely, this issue is very similar to https://github.com/RadeonOpenCompute/LLVM-AMDGPU-Assembler-Extra/issues/13 The regression point is > r274340 | ad58f8c | [AMDGPU] Assembler: support SDWA for VOPC instructions Lit tests attached. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 28348] Regression(r272251): error in backend: Cannot select: t45: i32 = ARMISD::BFI t4, Constant:i32<1>, t34
https://llvm.org/bugs/show_bug.cgi?id=28348 James Molloy changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from James Molloy --- Hi Nico, Thanks for bringing this to my attention, and sorry that I didn't act on it quickly as I was on vacation. The underlying problem is actually my use of DAG->getConstant. I should be using DAG->getTargetConstant. The use of getConstant() in this testcase actually increments the use count of Constant<4095> from one to two. In this case, the lowering of ARMISD::BFI is contingent on its constant argument only having one use - if it's shared, ISel falls over. I've committed a fixed version in r274510. Cheers, James -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 28414] New: lld can't be used with GCC 7
https://llvm.org/bugs/show_bug.cgi?id=28414 Bug ID: 28414 Summary: lld can't be used with GCC 7 Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: hjl.to...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified On Linux/x86-64, when GCC 7 configured with /export/gnu/import/git/sources/gcc/configure --enable-languages=c,c++,fortran --disable-bootstrap --enable-libmpx --with-ld=/export/build/gnu/llvm-clang/release/opt/llvm/master/bin/lld --with-plugin-ld=/export/build/gnu/llvm-clang/release/opt/llvm/master/bin/lld --prefix=/usr/gcc-7.0.0 --with-local-prefix=/usr/local --enable-gnu-indirect-function --with-fpmath=sse I got mkdir -p -- 32 /export/build/gnu/gcc-test/build-x86_64-linux/./gcc/xgcc -B/export/build/gnu/gcc-test/build-x86_64-linux/./gcc/ -B/usr/gcc-7.0.0/x86_64-pc-linux-gnu/bin/ -B/usr/gcc-7.0.0/x86_64-pc-linux-gnu/lib/ -isystem /usr/gcc-7.0.0/x86_64-pc-linux-gnu/include -isystem /usr/gcc-7.0.0/x86_64-pc-linux-gnu/sys-include-O2 -O2 -g -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -DUSE_ELF_SYMVER -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map -o 32/libgcc_s.so.1.tmp -O2 -g -m32 -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o cpuinfo_s.o tf-signs_s.o sfp-exceptions_s.o addtf3_s.o divtf3_s.o eqtf2_s.o getf2_s.o letf2_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o floatditf_s.o floatunditf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfsf2_s.o trunctfdf2_s.o trunctfxf2_s.o enable-execute-stack_s.o unwind-dw2_s.o unwind-dw2-fde-dip_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lc && rm -f 32/libgcc_s.so && if [ -f 32/libgcc_s.so.1 ]; then mv -f 32/libgcc_s.so.1 32/libgcc_s.so.1.backup; else true; fi && mv 32/libgcc_s.so.1.tmp 32/libgcc_s.so.1 && (echo "/* GNU ld script"; echo " Use the shared library, but some functions are only in"; echo " the static library. */"; echo "GROUP ( libgcc_s.so.1 -lgcc )" ) > 32/libgcc_s.so -flavor option is missing. Available flavors are gnu, darwin or link. collect2: error: ld returned 1 exit status Makefile:945: recipe for target 'libgcc_s.so' failed make[5]: *** [libgcc_s.so] Error 1 make[5]: Leaving directory '/export/build/gnu/gcc-test/build-x86_64-linux/x86_64-pc-linux-gnu/32/libgcc' -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 28415] New: optimizer loop removal should issue diagnostics in presence of "#pragma clang loop vectorize"
https://llvm.org/bugs/show_bug.cgi?id=28415 Bug ID: 28415 Summary: optimizer loop removal should issue diagnostics in presence of "#pragma clang loop vectorize" Product: new-bugs Version: trunk Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: s...@rogue-research.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified If the optimizer decides to remove a loop that's tagged with "#pragma clang loop vectorize(enable)", then some kind of diagnostic should be issued, instead of silence as the case currently. If/since the pragma is explicitly there, the programmer is obviously expecting/requiring vectorization, so if that's not performed, she should be warned. This is related to PR28374. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 28416] New: malloc is optimized out for release build
https://llvm.org/bugs/show_bug.cgi?id=28416
Bug ID: 28416
Summary: malloc is optimized out for release build
Product: clang
Version: 3.8
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: dmark...@mac.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
the following code behaves incorrectly
int main(int argc, const char * argv[]) {
size_t need_size = 0x1;
void *data = malloc(need_size);
if(data == NULL) {
printf("data == NULL\n");
return 1;
} else {
printf("data != NULL\n");
}
free(data);
return 0;
}
it returns
data != NULL
Program ended with exit code: 0
but it should return
data == NULL
Program ended with exit code: 1
gcc handles that situation correctly
clang shouldn't optimize it out, because result of the malloc is used and
caller of my program relies on the exit code
Note, clang flag -fno-builtin prevents clang from malloc optimize out
and solve the problem.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 28416] malloc is optimized out for release build
https://llvm.org/bugs/show_bug.cgi?id=28416 David Majnemer changed: What|Removed |Added Status|NEW |RESOLVED CC||david.majne...@gmail.com Resolution|--- |INVALID --- Comment #1 from David Majnemer --- LLVM has not optimized your program into an inconsistent state because calling malloc is not an observable side effect in and of itself. If the compiler can satisfy your use of malloc in a way which doesn't end up calling malloc, that's ok. If you did something else with the malloc'd pointer like called malloc_usable_size (or escaped it through any other mechanism) then that would be a different story. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 28417] New: missing tailcall optimization
https://llvm.org/bugs/show_bug.cgi?id=28417
Bug ID: 28417
Summary: missing tailcall optimization
Product: libraries
Version: 3.8
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: vanya...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
For this code LLVM generates code that doesn't use tailcall optimization.
struct token
{
char const* tok_start;
char const* tok_end;
int tok_type;
unsigned identifier_hash;
};
token f();
token g()
{
return f();
}
Generated code:
g(): # @g()
pushq %rbx
movq%rdi, %rbx
callq f()
movq%rbx, %rax
popq%rbx
retq
Expected code:
g(): # @g()
jmpqf()
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 28416] malloc is optimized out for release build
https://llvm.org/bugs/show_bug.cgi?id=28416 dmark...@mac.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #2 from dmark...@mac.com --- we have a use case which is far more complicated than example I used in the bug report, but even in my example result of the malloc was used in the exit code of the program, clang shouldn't alter logic of the program it MUST return NULL if memory wasn't allocated and was used in the next line of the code from malloc man page: RETURN VALUES If successful, calloc(), malloc(), realloc(), reallocf(), and valloc() functions return a pointer to allocated memory. If there is an error, they return a NULL pointer and set errno to ENOMEM. so clang behavior isn't compliant to the malloc documentation you're saying: "If the compiler can satisfy your use of malloc in a way which doesn't end up calling malloc, that's ok." problem is that in my example compiler didn't satisfy my use of malloc and alter code flow which isn't acceptable -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 28407] Invalid C accepted: flexible array member in struct with only unnamed member
https://llvm.org/bugs/show_bug.cgi?id=28407 Alexander Cherepanov changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #2 from Alexander Cherepanov --- Now, this testcase is diagnosed as "test.c:5:9: error: flexible array member 'a' not allowed in otherwise empty struct". The message is wrong as the struct is not otherwise empty -- it contains an unnamed field. Not sure if a separate message for this case is worth the trouble, maybe something like "flexible array member 'a' not allowed in struct without other named member" could do? Should I file a separate PR for this? -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 28418] New: opt never finishes compiling with -gvn option
https://llvm.org/bugs/show_bug.cgi?id=28418 Bug ID: 28418 Summary: opt never finishes compiling with -gvn option Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: katya_roman...@playstation.sony.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16685 --> https://llvm.org/bugs/attachment.cgi?id=16685&action=edit reduced reproducer for this bug opt never finishes compiling test case t.ll with –gvn option opt -gvn t.ll -o foo Kudos to Rafael for helping me to reduce this. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 11723] Clang doesn't substitute into template parameter list of type template parameter pack if the pack is unused
https://llvm.org/bugs/show_bug.cgi?id=11723 Nathan Ridge changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #9 from Nathan Ridge --- I just discovered that this has been fixed on trunk for 5 months, in bug 23840! \o/ (It missed the clang 3.8 release, however.) Closing as dupe. *** This bug has been marked as a duplicate of bug 23840 *** -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 15700] Assertion failure '!isImplicitAccess()' involving decltype and default function template arguments
https://llvm.org/bugs/show_bug.cgi?id=15700 Nathan Ridge changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #4 from Nathan Ridge --- Seems to be fixed since clang 3.7. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
