[llvm-bugs] [Bug 45707] New: unaligned Memory Access Identify
https://bugs.llvm.org/show_bug.cgi?id=45707
Bug ID: 45707
Summary: unaligned Memory Access Identify
Product: clang
Version: 8.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: 2077213...@qq.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
When I write code to access a specified address that is not 4-byte aligned,The
compiler still thinks he's 4-byte aligned.
code:
void test() {
int *p = (int *)0x101;
*p = 2;
}
cmd: clang -O2 --target=arm-none-eabi -mcpu=cortex-r52 -emit-llvm -S test.c
test.ll
llvm IR: -- the store is align 4！
define dso_local void @test() local_unnamed_addr #0 {
store i32 2, i32* inttoptr (i32 257 to i32*), align 4, !tbaa !3
ret void
}
Even if I don't allow unaligned access, the compiler won't split into ldrb.
CMD: llc -mattr=+strict-align test.ll
ASM:
test:
.fnstart
@ %bb.0:
mov r0, #1
mov r1, #2
orr r0, r0, #256
str r1, [r0]
bx lr
GCC can identify the misaligned access.
CMD: arm-none-eabi-gcc -mcpu=cortex-r52 -munaligned-access -O2 -S test.c
test:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mov r3, #0
mov r2, #2
str r2, [r3, #257] @ unaligned
bx lr
CMD: arm-none-eabi-gcc -mcpu=cortex-r52 -mno-unaligned-access -O2 -S test.c
test:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mov r3, #0
mov r2, #2
strb r3, [r3, #258]
strb r3, [r3, #259]
strb r3, [r3, #260]
strb r2, [r3, #257]
bx lr
--
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 45708] New: RISC-V DataLayout is wrong which causes many optimizations to not work on RISC-V
https://bugs.llvm.org/show_bug.cgi?id=45708 Bug ID: 45708 Summary: RISC-V DataLayout is wrong which causes many optimizations to not work on RISC-V Product: new-bugs Version: trunk Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: heikki.kult...@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org The RV32I and RV64I Base ISAs supports 8-bit and 16-bit memory operations, AND they support unaligned memory operations. However, on LLVM RISCV32 data layout is just "e-m:e-p:32:32-i64:64-n32-S128", and RISCV64 data layout is just "e-m:e-p:64:64-i64:64-i128:128-n64-S128". These lacks information about 8- and 16-bit data types, and also the alignment for 32 and 64 bit memory accesses is wrong. Because the data layout forces aligned memory accesses, the backend generates very slow code consisting of multiple narrower accesses when it cannot prove that a memory access is aligned. And the total lack of information about 8-bit and 16-bit accesses in the data layout makes clang think 8-bit and 16-bit types or memory accesses are not legal, which prevents some optimizations from working, for example -ffine-grained-bitfield-accesses fails to generate 8-bit or 16-bit accesses because there is a check that it only generates legal loads. -- 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 45709] New: misoptimization with defaulting to POWER7 and newer
https://bugs.llvm.org/show_bug.cgi?id=45709
Bug ID: 45709
Summary: misoptimization with defaulting to POWER7 and newer
Product: libraries
Version: 10.0
Hardware: Other
OS: FreeBSD
Status: NEW
Severity: normal
Priority: P
Component: Backend: PowerPC
Assignee: unassignedb...@nondot.org
Reporter: pku...@anongoth.pl
CC: llvm-bugs@lists.llvm.org, nemanja.i@gmail.com
Reduced test case:
class a {
void b();
void m_fn2();
int c;
float d[];
};
void a ::b() {
float e;
for (int f; f <= c; f++)
if (e < d[f])
e = d[f];
if (e)
m_fn2();
}
Compile with:
c++ -ffast-math -O2 -c sms.cpp
It builds fine without -ffast-math, or when lowering optimizations to -O1, or
after adding -mcpu=power7 (power8 or power9 are also ok for clang).
Result:
Illegal instruction
--
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 45710] New: Alignment for array pointer access
https://bugs.llvm.org/show_bug.cgi?id=45710
Bug ID: 45710
Summary: Alignment for array pointer access
Product: clang
Version: 8.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: 2077213...@qq.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
When accessing an array pointer, the compiler considers it to be aligned 1,
even if the element it points to is aligned 4.
The code is as follows:
int alignaddress[10];
void test() {
int (*p)[] = &alignaddress;
(*p)[2] = 0x12;
}
clang -O0 --target=arm-none-eabi -emit-llvm -S test.c
IR: the store 0x12 is align 1
define dso_local void @test() #0 {
%1 = alloca [0 x i32]*, align 4
store [0 x i32]* bitcast ([10 x i32]* @alignaddress to [0 x i32]*), [0 x
i32]** %1, align 4
%2 = load [0 x i32]*, [0 x i32]** %1, align 4
%3 = getelementptr inbounds [0 x i32], [0 x i32]* %2, i32 0, i32 2
store i32 18, i32* %3, align 1
ret void
}
when we dont allow unaligned-access, it will use 4 strb instruction to access
CMD: llc -mattr=+strict-align test.ll
test:
.fnstart
@ %bb.0:
.pad #4
sub sp, sp, #4
ldr r0, .LCPI0_0
str r0, [sp]
ldr r0, [sp]
mov r1, #18
strb r1, [r0, #8]!
mov r1, #0
strb r1, [r0, #3]
strb r1, [r0, #2]
strb r1, [r0, #1]
add sp, sp, #4
bx lr
gcc think it is an aligned access.
CMD: arm-none-eabi-gcc -mno-unaligned-access -S test.c
test:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 1, uses_anonymous_args = 0
@ link register save eliminated.
str fp, [sp, #-4]!
add fp, sp, #0
sub sp, sp, #12
ldr r3, .L2
str r3, [fp, #-8]
ldr r3, [fp, #-8]
mov r2, #18
str r2, [r3, #8]
nop
add sp, fp, #0
@ sp needed
ldr fp, [sp], #4
bx lr
Is this a bug or is the llvm processing more conservative because the address
which the pointer points is unknown?
But in the following case, llvm thinks it's aligned 4.
int a;
void test() {
int *p = &a;
*p = 2;
}
However, in the current scenario, I think that the llvm processing is
incorrect.
--
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 45707] unaligned Memory Access Identify
https://bugs.llvm.org/show_bug.cgi?id=45707
Roman Lebedev changed:
What|Removed |Added
Resolution|--- |INVALID
CC||lebedev...@gmail.com
Status|NEW |RESOLVED
--- Comment #1 from Roman Lebedev ---
> void test() {
> int *p = (int *)0x101;
> *p = 2;
> }
That is UB.
int is 4-byte aligned.
If you've got a misaligned pointer, you need to use memcpy to access 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 45711] New: AUTOSAR rules for range loops
https://bugs.llvm.org/show_bug.cgi?id=45711
Bug ID: 45711
Summary: AUTOSAR rules for range loops
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: michael.kras...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Hello,
i am working on a project that uses clang and an AUTOSAR compliance tool.
I would like to file not a bug but an issue that two AUTOSAR rules are
counter-exclusive for code generated by llvm.
Namely,
Rule A6-5-1 (required, implementation, automated)
A for-loop that loops through all elements of the container and does not use
its loop-counter shall not be used.
The rules implies that following code has to be used
#include
void f(std::vector values)
{
for (auto value : values)
{
}
}
The clang generates the following code
#include
void f(std::vector > values)
{
{
std::vector > & __range1 = values;
__gnu_cxx::__normal_iterator >
> __begin1 = __range1.begin();
__gnu_cxx::__normal_iterator >
> __end1 = __range1.end();
for(; __gnu_cxx::operator!=(__begin1, __end1); __begin1.operator++())
{
int value = __begin1.operator*();
}
}
}
and the AUTOSAR compliance tool shows violations of another rule
Rule A8-5-2 (required, implementation, automated)
Braced-initialization {}, without equals sign, shall be used for variable
initialization
as AUTOSAR C++14 Declarators (AUTOSAR C++14 A8-5-2)1.
autosar_cpp14_a8_5_2_violation: Initializing variable __range1 without using
braced-initialization {}.
Would it be beneficial for llvm to change implementation of initialization of
__range, __begin, __end in range-based loops in Sema::ActOnCXXForRangeStmt from
T & ref = object ;
to
T & ref { object } ;
so the code above will be
std::vector > & __range1{values};
__gnu_cxx::__normal_iterator
> > __begin1{__range1.begin()};
__gnu_cxx::__normal_iterator
> > __end1{__range1.end()};
Regards,
Michael Krasnyk
--
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 45712] New: [LTO] -fwhole-program-vtables causes bad generated code in hybrid lto/non-lto build
https://bugs.llvm.org/show_bug.cgi?id=45712
Bug ID: 45712
Summary: [LTO] -fwhole-program-vtables causes bad generated
code in hybrid lto/non-lto build
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Interprocedural Optimizations
Assignee: unassignedb...@nondot.org
Reporter: sylvain.a...@ubisoft.com
CC: llvm-bugs@lists.llvm.org, pe...@pcc.me.uk,
r...@google.com, tejohn...@google.com
When trying to enable Thin-LTO on one of our games, we found invalid generated
code which caused an infinite loop when we enabled -the
`-fwhole-program-vtables`.
The bug also appeared when we tried LTO.
I mentionned this bug in comments of D55153
Note that we build the game against some libraries that were not built with
LTO/ThinLTO.
Here it is, reduced as a relatively small repro:
$cat main.cpp
#include "inc.h"
extern void UseExternal();
int main() {
UseExternal();
return 0;
}
$cat inc.h
class A {
public:
virtual void f() {
pNext->f();
}
A* pNext = nullptr;
};
class B : public A {
public:
virtual void f() {}
};
$cat external.cpp
#include "inc.h"
static A s_A;
static B s_B;
void UseExternal() {
s_A.pNext = &s_B;
(&s_A)->f();
}
$cat def.cpp
#include "inc.h"
A g_A;
$clang-cl main.cpp def.cpp -c /Z7 /O2 /GR- -flto -fwhole-program-vtables
$clang-cl extern.cpp -c /Z7 /O2 /GR-
$lld-link /NODEFAULTLIB /ENTRY:main /OUT:main.exe def.obj main.obj external.obj
In the generated code, we can see that A::f() is generated as an endless loop.
14000103f: cc int3
140001040: eb fejmp0x140001040 ; endless loop
140001042: cc int3
It looks like it was wrongly devirtualized:
virtual void f() {
pNext->f();
}
where pNext->f() becomes an endless recursion.
IMPORTANT: The bug appears only if def.obj is the first object in the lld-link
command.
This bug is pretty fragile to reproduce.
The repro above is with clang-cl / lld-link; I didn't manage to repro it under
clang/ld.lld.
--
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 45713] New: use RtlRestoreContext which is forbidden in winstore builds
https://bugs.llvm.org/show_bug.cgi?id=45713 Bug ID: 45713 Summary: use RtlRestoreContext which is forbidden in winstore builds Product: Runtime Libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: libunwind Assignee: unassignedb...@nondot.org Reporter: rob...@ycbcr.xyz CC: llvm-bugs@lists.llvm.org The current template AbstractUnwindCursor on Windows seems to create a context along the way and when jumpto() is called, RtlRestoreContext is called. This call is not allowed in some UCRT/UWP context. Here are the list of allowed API entries: https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-apis In particular the RTL support: https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-rtlsupport-l1-2-0dll Maybe RtlUnwind or RtlUnwindEx could be used instead. But it seems like the code would need a big rework. In the meantime, builds with _LIBUNWIND_SUPPORT_SEH_UNWIND (the default when __SEH__ is enable, which is also the default on win64) cannot be published on the Windows Store for some devices because this API is not allowed (mostly for C++ based code). -- 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 45714] New: [llvm][utils] update_llc_test_checks doesn't take action with runtime preemption specifiers
https://bugs.llvm.org/show_bug.cgi?id=45714 Bug ID: 45714 Summary: [llvm][utils] update_llc_test_checks doesn't take action with runtime preemption specifiers Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: zb...@google.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Steps 1. Write an LLVM IR test case function with a runtime preemption specifier and a RUN line that uses LLC. 2. Run llvm/utils/update_llc_test_checks.py Expected: The test file gets updated with 1) the autogenerated advertisement and 2) the llc output in CHECK lines Actual: The test file gets updated with 1) the autogenerated advertisements with no other changes. I suspect the regex that matches to functions doesn't handle runtime preemption specfiers. -- 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 45715] New: Failure to recognize bswap.i64 pattern
https://bugs.llvm.org/show_bug.cgi?id=45715
Bug ID: 45715
Summary: Failure to recognize bswap.i64 pattern
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: llvm-bugs@lists.llvm.org
uint64_t swap64(uint64_t x)
{
return __builtin_bswap32(x >> 32) | ((uint64_t)__builtin_bswap32(x) << 32);
}
This is equivalent to `__builtin_bswap64(x)`. GCC does this transformation, but
only if `__builtin_bswap32` is replaced by a function equivalent to it (i.e.
that is recognized by GCC as equivalent to `__builtin_bswap32`). It would be
nice if LLVM could recognize this as equivalent to `__builtin_bswap64`
Comparison here : https://godbolt.org/z/gtJQdM
--
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 45716] New: Missing a recursion guard for sizeof
https://bugs.llvm.org/show_bug.cgi?id=45716
Bug ID: 45716
Summary: Missing a recursion guard for sizeof
Product: clang
Version: 9.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: jynel...@email.sc.edu
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Created attachment 23412
--> https://bugs.llvm.org/attachment.cgi?id=23412&action=edit
The output of the shell command mentioned in the bug report
The following command crashes clang:
```
$ { echo 'int i = '; yes 'sizeof ' | head -n 2000; echo 'int;'; } | tr -d '\n'
| clang -x c -
```
I expect this to instead give an error about the expression being too nested,
like clang does for parentheses:
```
$ { echo 'int i = '; yes '( ' | head -n 2000; } | tr -d '\n' | clang -x c -
:1:521: fatal error: bracket nesting level exceeded maximum of 256
```
Extract of the stack trace (it goes on for another 300 stack frames):
#330 0x7f7dcd91080f ParseCastExpression
/build/llvm-toolchain-9-uSl4bC/llvm-toolchain-9-9/tools/clang/lib/Parse/ParseExpr.cpp:535:20
#331 0x7f7dcd91080f
clang::Parser::ParseExprAfterUnaryExprOrTypeTrait(clang::Token const&, bool&,
clang::OpaquePtr&, clang::SourceRange&)
/build/llvm-toolchain-9-uSl4bC/llvm-toolchain-9-9/tools/clang/lib/Parse/ParseExpr.cpp:1924:15
#332 0x7f7dcd90f3c8 clang::Parser::ParseUnaryExprOrTypeTraitExpression()
/build/llvm-toolchain-9-uSl4bC/llvm-toolchain-9-9/tools/clang/lib/Parse/ParseExpr.cpp:2037:24
#333 0x7f7dcd905999 clang::Parser::ParseCastExpression(bool, bool, bool&,
clang::Parser::TypeCastState, bool)
/build/llvm-toolchain-9-uSl4bC/llvm-toolchain-9-9/tools/clang/lib/Parse/ParseExpr.cpp:1204:12
#334 0x7f7dcd91080f ParseCastExpression
/build/llvm-toolchain-9-uSl4bC/llvm-toolchain-9-9/tools/clang/lib/Parse/ParseExpr.cpp:535:20
#335 0x7f7dcd91080f
clang::Parser::ParseExprAfterUnaryExprOrTypeTrait(clang::Token const&, bool&,
clang::OpaquePtr&, clang::SourceRange&)
/build/llvm-toolchain-9-uSl4bC/llvm-toolchain-9-9/tools/clang/lib/Parse/ParseExpr.cpp:1924:15
#336 0x7f7dcd90f3c8 clang::Parser::ParseUnaryExprOrTypeTraitExpression()
/build/llvm-toolchain-9-uSl4bC/llvm-toolchain-9-9/tools/clang/lib/Parse/ParseExpr.cpp:2037:24
#337 0x7f7dcd905999 clang::Parser::ParseCastExpression(bool, bool, bool&,
clang::Parser::TypeCastState, bool)
/build/llvm-toolchain-9-uSl4bC/llvm-toolchain-9-9/tools/clang/lib/Parse/ParseExpr.cpp:1204:12
#338 0x7f7dcd91080f ParseCastExpression
/build/llvm-toolchain-9-uSl4bC/llvm-toolchain-9-9/tools/clang/lib/Parse/ParseExpr.cpp:535:20
#339 0x7f7dcd91080f
clang::Parser::ParseExprAfterUnaryExprOrTypeTrait(clang::Token const&, bool&,
clang::OpaquePtr&, clang::SourceRange&)
/build/llvm-toolchain-9-uSl4bC/llvm-toolchain-9-9/tools/clang/lib/Parse/ParseExpr.cpp:1924:15
#340 0x7f7dcd90f3c8 clang::Parser::ParseUnaryExprOrTypeTraitExpression()
/build/llvm-toolchain-9-uSl4bC/llvm-toolchain-9-9/tools/clang/lib/Parse/ParseExpr.cpp:2037:24
clang: error: unable to execute command: Segmentation fault (core dumped)
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 9.0.0-2~ubuntu18.04.2 (tags/RELEASE_900/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /home/joshua/.local/bin
clang: note: diagnostic msg: PLEASE submit a bug report to
https://bugs.llvm.org/ and include the crash backtrace, preprocessed source,
and associated run script.
clang: note: diagnostic msg: Error generating preprocessed source(s) - ignoring
input from stdin.
clang: note: diagnostic msg: Error generating preprocessed source(s) - no
preprocessable inputs.
--
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 34165] Wrong code generation on arm/thumb2
https://bugs.llvm.org/show_bug.cgi?id=34165
Manoj Gupta changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC||manojgu...@google.com
Resolution|FIXED |---
--- Comment #10 from Manoj Gupta ---
Breaks GCC compatibility:
Test:
void fn(int fd, int arg)
{
register int r7 __asm__("r7") = 54;
__asm__ __volatile__ ( "svc 0" : : "r"(r7), "r"(fd), "r"(arg) : "memory");
}
Compiler args:
-march=armv7-a -mthumb -mfloat-abi=soft -O2
https://godbolt.org/z/wP8_ic
--
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 45717] New: OpenMP: array element not allowed in reduction clause
https://bugs.llvm.org/show_bug.cgi?id=45717
Bug ID: 45717
Summary: OpenMP: array element not allowed in reduction clause
Product: OpenMP
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Clang Compiler Support
Assignee: unassignedclangb...@nondot.org
Reporter: david.pa...@intel.com
CC: llvm-bugs@lists.llvm.org
Compiler generates an error when array element is referred to in a reduction
clause. Spec seems to say this is valid, and other compilers accept it.
Test case:
static short x[100];
static short y[100];
static const int N = 100;
void test() {
short (*yptr)[N] = &y;
#pragma omp parallel for simd reduction(+:yptr[0])
for(int i = 0; i < N; i++) {
yptr[0][25 + i/4] += x[i];
}
}
Compile: clang -fopenmp test.cpp
Error:
test.cpp:8:43: error: list item of type 'int [100]' is not valid for specified
reduction operation: unable to provide default initialization value
#pragma omp parallel for simd reduction(+:yptr[0])
~ ^
test.cpp:7:11: note: 'yptr' defined here
int (*yptr)[N] = &y;
^
1 error generated.
--
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 45718] New: Failure to merge loops with identi
https://bugs.llvm.org/show_bug.cgi?id=45718
Bug ID: 45718
Summary: Failure to merge loops with identi
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: llvm-bugs@lists.llvm.org
void f(int *__restrict a, int *__restrict b, size_t sz)
{
for (int i = 0; i < sz; ++i)
a[i] += b[i];
for (int i = 0; i < sz; ++i)
a[i] += b[i];
}
These two loops could be merged into a single one doing two additions per
iteration. ICC does this transformation, LLVM does not.
See also https://godbolt.org/z/YnCPNA
--
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 44842] lld fails to link GNU indirect functions
https://bugs.llvm.org/show_bug.cgi?id=44842 Jean-Michaël Celerier changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #8 from Jean-Michaël Celerier --- This still fails with clang-10 / lld-10. @Fangrui Song does the FFTW issue I reported initially works for you ? -- 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 45719] New: clang appends ".1"/... to asm()-specified symbol names
https://bugs.llvm.org/show_bug.cgi?id=45719
Bug ID: 45719
Summary: clang appends ".1"/... to asm()-specified symbol names
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: equinox-l...@diac24.net
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
int testfn(void)
{
do {
extern int name_c1 asm("name_asm_a");
static __attribute__((used)) int *ptr = &name_c1;
static __attribute__((used)) int def_c asm("name_asm_a") =
0x1234;
} while (0);
do {
extern int name_c2 asm("name_asm_b");
static __attribute__((used)) int *ptr = &name_c2;
static __attribute__((used)) int def_c asm("name_asm_b") =
0x2345;
} while (0);
return 0;
}
compiles to (shortened):
testfn.ptr:
.quad name_asm_a
name_asm_a.1:
.long 4660 # 0x1234
testfn.ptr.2:
.quad name_asm_b
name_asm_b.3:
.long 9029 # 0x2345
- the "def_c" statements use assembler labels "name_asm_a.1" and "name_asm_b.3"
instead of expected "name_asm_a" and "name_asm_b".
- the initializer for "ptr" uses the asm name without the ".1" or ".3" suffix
This ultimately leads to the linker erroring out due to the symbols not
resolving correctly.
(The example above is extracted from a macro that is trying to create static
variables with cyclical pointers between two of them, hence the odd "extern"
declaration.)
--
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 34165] Wrong code generation on arm/thumb2
https://bugs.llvm.org/show_bug.cgi?id=34165 Eli Friedman changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED CC||efrie...@quicinc.com --- Comment #11 from Eli Friedman --- clang defaults to -fno-omit-frame-pointer, and gcc defaults to -fomit-frame-pointer. Arguably a bug, but not this bug. Otherwise, the behavior is the same. -- 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 45700] Failure to optimize condition into sbb
https://bugs.llvm.org/show_bug.cgi?id=45700 Craig Topper changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Fixed By Commit(s)||0de7ddbfb033671d6ba75aa8c88 ||c63e2919a6ad6 --- Comment #4 from Craig Topper --- Fixed in 0de7ddbfb033671d6ba75aa8c88c63e2919a6ad6 -- 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 45711] AUTOSAR rules for range loops
https://bugs.llvm.org/show_bug.cgi?id=45711 Richard Smith changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #1 from Richard Smith --- Clang does not lower range-based for loops to regular for loops. I don't know what tool you're using for that, but: 1) it's not clang, and 2) it's likely not reasonable to run your conformance checker on its output -- 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 45720] New: Attribute "cold" not permitted on Blocks language extension
https://bugs.llvm.org/show_bug.cgi?id=45720 Bug ID: 45720 Summary: Attribute "cold" not permitted on Blocks language extension Product: clang Version: 10.0 Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: c...@freebsd.org CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk It seems like block code is function-like enough that it makes sense to be able to annotate the objects with __attribute__((cold)) (or hot). Currently this is rejected by Basic/Attr.td due to Cold/Hot SubjectLists containing only "Function." And I'm sure some support would be needed internally to actually map hot/cold attributes to meaningful behavior internally. My observation is that: 1. Blocks are useful for generating known-cold code via macros, such as in assert or (conditional) debug-level log constructs. 2. Clang attempts to inline all blocks. 3. Even when blocks are not inlined, they are laid out adjacent to their parent function in .text. The desired behavior of cold-attribute Blocks is basically that the cold attribute is passed down to the generated LLVM function corresponding to Block invocation. This affects NeverInline (2) and perhaps code placement (3). As a giant kludge for (3), it seems to work to use -ffunction-sections to put non-inlined blocks in their own sections and carefully use a linker script to place them far away from other code. I don't have any good workarounds for (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 45645] Using --relocatable with mismatching function signatures crashes
https://bugs.llvm.org/show_bug.cgi?id=45645 Heejin Ahn changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #9 from Heejin Ahn --- @Sam The context was, this bug was reported in https://bugs.llvm.org/show_bug.cgi?id=45461#c15. And the test case here was reduced by me, and my reduced test case here now compiles with your fix, so I assumed it also fixed Olgierd's bug, but apparently not. Sorry for that. I reproduced his problem. His test case here was a bit cumbersome to try out, so I made it a single compressed file, but this exceeds 1MB so I had to upload in my Dropbox. The link is below. https://www.dropbox.com/s/c9dc5w3kp3iamk6/sources.tar.gz?dl=0 After downloading this file, to reproduce the problem, tar xf sources.tar.gz cd sources CPPFLAGS=-IFMI2 emconfigure ./configure emmake make -- 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 45035] Enabling UseAA in the arm backend generates wrong instruction order for pattern initialization
https://bugs.llvm.org/show_bug.cgi?id=45035 Yabin Cui changed: 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 45721] New: [GlobalISel][AArch64] Assertion "invalid narrowing extend" with soft-float fp128
https://bugs.llvm.org/show_bug.cgi?id=45721
Bug ID: 45721
Summary: [GlobalISel][AArch64] Assertion "invalid narrowing
extend" with soft-float fp128
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: AArch64
Assignee: unassignedb...@nondot.org
Reporter: efrie...@quicinc.com
CC: aemer...@apple.com, arnaud.degrandmai...@arm.com,
jpaque...@apple.com, llvm-bugs@lists.llvm.org,
smithp...@googlemail.com, ties.st...@arm.com
Testcase:
define double @x(fp128 %a) "target-features"="-fp-armv8" { ret double undef }
Compile with "llc -O0 -mtriple=aarch64":
llc: upstream/llvm-top/llvm/lib/CodeGen/GlobalISel/MachineIRBuilder.cpp:912:
void llvm::MachineIRBuilder::validateTruncExt(const llvm::LLT, const llvm::LLT,
bool): Assertion `DstTy.getSizeInBits() > SrcTy.getSizeInBits() && "invalid
narrowing extend"' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace.
Stack dump:
0. Program arguments: upstream-build-release/bin/llc -O0 -mtriple=aarch64
1. Running pass 'Function Pass Manager' on module ''.
2. Running pass 'IRTranslator' on function '@x'
#0 0x024214d4 PrintStackTraceSignalHandler(void*)
(upstream-build-release/bin/llc+0x24214d4)
#1 0x0241f080 llvm::sys::RunSignalHandlers()
(upstream-build-release/bin/llc+0x241f080)
#2 0x024217dc SignalHandler(int)
(upstream-build-release/bin/llc+0x24217dc)
#3 0x7f21efc45330 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x10330)
#4 0x7f21ee629c37 raise
/build/eglibc-xkFqqE/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0
#5 0x7f21ee62d028 abort
/build/eglibc-xkFqqE/eglibc-2.19/stdlib/abort.c:91:0
#6 0x7f21ee622bf6 __assert_fail_base
/build/eglibc-xkFqqE/eglibc-2.19/assert/assert.c:92:0
#7 0x7f21ee622ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2)
#8 0x0280a07c llvm::MachineIRBuilder::validateTruncExt(llvm::LLT,
llvm::LLT, bool) (upstream-build-release/bin/llc+0x280a07c)
#9 0x0280ac6d llvm::MachineIRBuilder::buildInstr(unsigned int,
llvm::ArrayRef, llvm::ArrayRef,
llvm::Optional) (upstream-build-release/bin/llc+0x280ac6d)
#10 0x0281c177 llvm::CSEMIRBuilder::buildInstr(unsigned int,
llvm::ArrayRef, llvm::ArrayRef,
llvm::Optional) (upstream-build-release/bin/llc+0x281c177)
#11 0x008fc1c0
llvm::AArch64CallLowering::lowerReturn(llvm::MachineIRBuilder&, llvm::Value
const*, llvm::ArrayRef, llvm::Register) const
(upstream-build-release/bin/llc+0x8fc1c0)
#12 0x027c2624 llvm::IRTranslator::translate(llvm::Instruction const&)
(upstream-build-release/bin/llc+0x27c2624)
#13 0x027c3df4
llvm::IRTranslator::runOnMachineFunction(llvm::MachineFunction&)
(upstream-build-release/bin/llc+0x27c3df4)
#14 0x01992739
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
(upstream-build-release/bin/llc+0x1992739)
#15 0x01d54daf llvm::FPPassManager::runOnFunction(llvm::Function&)
(upstream-build-release/bin/llc+0x1d54daf)
#16 0x01d55093 llvm::FPPassManager::runOnModule(llvm::Module&)
(upstream-build-release/bin/llc+0x1d55093)
#17 0x01dc llvm::legacy::PassManagerImpl::run(llvm::Module&)
(upstream-build-release/bin/llc+0x1dc)
#18 0x006cd5d3 compileModule(char**, llvm::LLVMContext&)
(upstream-build-release/bin/llc+0x6cd5d3)
#19 0x006cb32d main (upstream-build-release/bin/llc+0x6cb32d)
#20 0x7f21ee614f45 __libc_start_main
/build/eglibc-xkFqqE/eglibc-2.19/csu/libc-start.c:321:0
#21 0x006ca889 _start (upstream-build-release/bin/llc+0x6ca889)
--
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 45722] New: [X86] Using SSE4 instructions for roundl() cause test failure in Android.
https://bugs.llvm.org/show_bug.cgi?id=45722 Bug ID: 45722 Summary: [X86] Using SSE4 instructions for roundl() cause test failure in Android. Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: yab...@google.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org With patch https://reviews.llvm.org/D73607 ([X86] Custom lower ISD::FROUND with SSE4.1 to avoid a libcall), we have a problem to pass a test in Android. The test is TEST(MATH_TEST, roundl) in https://android.googlesource.com/platform/bionic/+/refs/heads/master/tests/math_test.cpp#1224. The problem is: with the LLVM patch, roundl(0.5L) is replace by SSE instructions when building for 32-bit tests on x86_64. And SSE instructions are affected by round mode set by fesetround(FE_TOWARDZERO), and makes roundl(0.5L) => 0. I am not sure where we should fix this (Android bionic libc or llvm). So create this bug to ask for help. -- 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 45723] New: Failure to optimize out useless zero-ing after register was already zero-ed
https://bugs.llvm.org/show_bug.cgi?id=45723
Bug ID: 45723
Summary: Failure to optimize out useless zero-ing after
register was already zero-ed
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
int f(bool b, int *p)
{
return b && *p;
}
LLVM generates this with -O3 :
f(bool, int*): # @f(bool, int*)
xor eax, eax ; Note that eax is zero-ed here
test dil, dil
je .LBB0_2
xor eax, eax ; Zero-ing eax here is thus useless
cmp dword ptr [rsi], 0
setne al
.LBB0_2:
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 45724] New: clang crash while compiling boost
https://bugs.llvm.org/show_bug.cgi?id=45724 Bug ID: 45724 Summary: clang crash while compiling boost Product: clang Version: 10.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: j...@zorins.us CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk clang-10: error: clang frontend command failed due to signal (use -v to see invocation) Abyss OS clang version 10.0.0 (https://github.com/abyss-os/phase1.git 8c6d30f400c0e33f4cdf53f79aacf08e095895e8) Target: mips64-abyss-linux-musl Thread model: posix InstalledDir: /usr/bin clang-10: note: diagnostic msg: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script. clang-10: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang-10: note: diagnostic msg: /tmp/riemann_zetal-03044d.cpp clang-10: note: diagnostic msg: /tmp/riemann_zetal-03044d.sh clang-10: note: diagnostic msg: "clang++" -c -x c++ -fvisibility-inlines-hidden -pthread -O3 -Wall -fvisibility=hidden -Wno-inline -O2 -Winvalid-pch -DBOOST_ALL_NO_LIB=1 -DBOOST_BUILD_PCH_ENABLED -DNDEBUG -I"." -I"libs/math/src/tr1" -Xclang -include-pch -Xclang "bin.v2/libs/math/build/clang-linux-10.0.0/release/link-static/threading-multi/visibility-hidden/../src/tr1/pch.hpp.pth" -o "bin.v2/libs/math/build/clang-linux-10.0.0/release/link-static/threading-multi/visibility-hidden/riemann_zetal.o" "libs/math/build/../src/tr1/riemann_zetal.cpp" ...failed clang-linux.compile.c++.with-pch bin.v2/libs/math/build/clang-linux-10.0.0/release/link-static/threading-multi/visibility-hidden/riemann_zetal.o... clang-linux.compile.c++.with-pch bin.v2/libs/math/build/clang-linux-10.0.0/release/link-static/threading-multi/visibility-hidden/sph_legendrel.o Stack dump: 0. Program arguments: clang++ -c -x c++ -fvisibility-inlines-hidden -pthread -O3 -Wall -fvisibility=hidden -Wno-inline -O2 -Winvalid-pch -DBOOST_ALL_NO_LIB=1 -DBOOST_BUILD_PCH_ENABLED -DNDEBUG -I. -Ilibs/math/src/tr1 -Xclang -include-pch -Xclang bin.v2/libs/math/build/clang-linux-10.0.0/release/link-static/threading-multi/visibility-hidden/../src/tr1/pch.hpp.pth -o bin.v2/libs/math/build/clang-linux-10.0.0/release/link-static/threading-multi/visibility-hidden/sph_legendrel.o libs/math/build/../src/tr1/sph_legendrel.cpp -- 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 45725] New: Prebuilt Windows x64 binary allows conversion from false to pointer
https://bugs.llvm.org/show_bug.cgi?id=45725
Bug ID: 45725
Summary: Prebuilt Windows x64 binary allows conversion from
false to pointer
Product: clang
Version: 10.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: C++17
Assignee: unassignedclangb...@nondot.org
Reporter: ph...@seiryu.org
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
Created attachment 23416
--> https://bugs.llvm.org/attachment.cgi?id=23416&action=edit
test code
Prebuilt clang for Windows x64 which can be downloaded from
https://llvm.org/builds/ compiles the test code with the following output. I
tried both 11.0.0(2663a25f) and 10.0.0.
>"\Program Files\LLVM\bin\clang.exe" -Wall -Wextra -std=c++17 -c test1.cpp
test.cpp:6:28: warning: initialization of pointer of type 'const char *' to
null
from a constant boolean expression [-Wbool-conversion]
[[maybe_unused]] s t = false;
^
1 warning generated.
Expected result is error like below.
test.cpp:6:24: error: no viable conversion from 'bool' to 's'
[[maybe_unused]] s t = false;
^ ~
test.cpp:1:8: note: candidate constructor (the implicit copy constructor) not
viable: no known conversion from 'bool' to 'const s &' for 1st argument
struct s {
^
test.cpp:1:8: note: candidate constructor (the implicit move constructor) not
viable: no known conversion from 'bool' to 's &&' for 1st argument
struct s {
^
test.cpp:2:5: note: candidate constructor not viable: no known conversion from
'bool' to 'const char *' for 1st argument
s(const char *) {}
^
1 error generated.
--
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 45726] New: _Generic selection failed to compile with enum
https://bugs.llvm.org/show_bug.cgi?id=45726
Bug ID: 45726
Summary: _Generic selection failed to compile with enum
Product: clang
Version: 10.0
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: rajendra...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Created attachment 23419
--> https://bugs.llvm.org/attachment.cgi?id=23419&action=edit
C program with _Generic selection failed to compile with enum
$ clang --version
clang version 10.0.0
Target: x86_64-unknown-linux-gnu
Thread model: posix
$ clang -o /tmp/test /tmp/test.c
/tmp/test.c:41:35: error: unknown type name 'CheckBegin'
printf("Check %d: %s\n", start, checkEnum(start)? "Yes" : "No");
^
/tmp/test.c:29:34: note: expanded from macro 'checkEnum'
enum Begin : CheckBegin, \
^
/tmp/test.c:41:35: error: expected ':'
/tmp/test.c:29:44: note: expanded from macro 'checkEnum'
enum Begin : CheckBegin, \
^
/tmp/test.c:42:34: error: unknown type name 'CheckBegin'
printf("Check %d: %s\n", stop, checkEnum(stop)? "Yes" : "No");
^
/tmp/test.c:29:34: note: expanded from macro 'checkEnum'
enum Begin : CheckBegin, \
^
/tmp/test.c:42:34: error: expected ':'
/tmp/test.c:29:44: note: expanded from macro 'checkEnum'
enum Begin : CheckBegin, \
^
/tmp/test.c:43:32: error: unknown type name 'CheckBegin'
printf("Check %d: %s\n", na, checkEnum(na)? "Yes" : "No");
^
/tmp/test.c:29:34: note: expanded from macro 'checkEnum'
enum Begin : CheckBegin, \
^
/tmp/test.c:43:32: error: expected ':'
/tmp/test.c:29:44: note: expanded from macro 'checkEnum'
enum Begin : CheckBegin, \
^
6 errors generated.
No errors with clang-7
$ clang --version
Juniper clang version 7.0.1
Target: x86_64-unknown-linux-gnu
Thread model: posix
$ clang -o /tmp/test /tmp/test.c
--
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
