[llvm-bugs] [Bug 38862] New: Optimize pass struct by value to tail call
https://bugs.llvm.org/show_bug.cgi?id=38862
Bug ID: 38862
Summary: Optimize pass struct by value to tail call
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: david.bolvan...@gmail.com
CC: llvm-bugs@lists.llvm.org
struct A {
int x[64];
};
void structByValue(A s);
void callStructByValue(A s) {
structByValue(s);
}
Clang:
callStructByValue(A): # @callStructByValue(A)
sub rsp, 264
lea rsi, [rsp + 272]
mov ecx, 32
mov rdi, rsp
rep movsq
call structByValue(A)
add rsp, 264
ret
GCC:
callStructByValue(A):
jmp structByValue(A)
If I change code to:
struct A {
int *x;
};
Clang tail calls it too.
--
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 38863] New: IndVars doesn't seem to update "Changed" properly
https://bugs.llvm.org/show_bug.cgi?id=38863 Bug ID: 38863 Summary: IndVars doesn't seem to update "Changed" properly Product: new-bugs Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: max.kazant...@azul.com CC: llvm-bugs@lists.llvm.org One example of this has caused the bug https://bugs.llvm.org/show_bug.cgi?id=38855, the fix for it is https://reviews.llvm.org/D51770. Other places around it need to be revisited carefully: we might not update it properly in other places as well. -- 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 38855] Assertion `NumReferences == 0 && "Node deleted while references remain"' with -inline -functionattrs -indvars
https://bugs.llvm.org/show_bug.cgi?id=38855 Max Kazantsev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Max Kazantsev --- Should be fixed by https://reviews.llvm.org/rL341633. I am going to follow-up and fix potential issues of this kind in frames of bug 38863. -- 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 38864] New: clang fails building ppc64le Linux kernel
https://bugs.llvm.org/show_bug.cgi?id=38864 Bug ID: 38864 Summary: clang fails building ppc64le Linux kernel Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: j...@jms.id.au CC: llvm-bugs@lists.llvm.org Created attachment 20852 --> https://bugs.llvm.org/attachment.cgi?id=20852&action=edit preprocesed source for kernel/irq/manage.c I am attempting to build the powerpc Linux kernel (v4.19-rc2) with clang. At link time, it will fail with a number of failed relocations: ld: kernel/irq/manage.o: in function `local_bh_enable': manage.c:(.text+0x3ccc): relocation truncated to fit: R_PPC64_ADDR16_HA against `.text'+3cb8 3cb0 : 3cb0: 00 00 4c 3c addis r2,r12,0 3cb4: 00 00 42 38 addir2,r2,0 3cb8: a6 02 08 7c mflrr0 3cbc: 10 00 01 f8 std r0,16(r1) 3cc0: e1 ff 21 f8 stdur1,-32(r1) 3cc4: 00 00 60 38 li r3,0 3cc8: 00 02 80 38 li r4,512 3ccc: 00 00 63 3c addis r3,r3,0 3cd0: 01 00 00 48 bl 3cd0 3cd4: 00 00 00 60 nop 3cd8: 20 00 21 38 addir1,r1,32 3cdc: 10 00 01 e8 ld r0,16(r1) 3ce0: a6 03 08 7c mtlrr0 3ce4: 20 00 80 4e blr It is suspected that the use of _THIS_IP_ is the cause of the error. On GCC this is placed in the TOC, but that is not the case for clang. I was able to reproduce with clang trunk. I've attached the preprocessed source file. Here's the line used to compile it: clang-7 -nostdinc -Qunused-arguments -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -no-integrated-as -fno-PIE -mlittle-endian -m64 -msoft-float -pipe -Iarch/powerpc -mabi=elfv2 -mcmodel=medium -mcpu=power8 -mtune=power9 -mno-altivec -mno-vsx -funit-at-a-time -fno-dwarf2-cfi-asm -Wa,-maltivec -Wa,-mpower8 -mlittle-endian -fno-delete-null-pointer-checks -Wno-duplicate-decl-specifier -O2 -Wframe-larger-than=2048 -fno-stack-protector -Wno-format-invalid-specifier -Wno-gnu -Wno-address-of-packed-member -Wno-tautological-compare -mno-global-merge -Wno-unused-const-variable -fomit-frame-pointer -g -fno-var-tracking -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fno-merge-all-constants -fno-stack-check -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -Werror=incompatible-pointer-types -Wno-initializer-overrides -Wno-unused-value -Wno-format -Wno-sign-compare -Wno-format-zero-length -Wno-uninitialized -c -o manage.o manage.i To reproduce from kernel sources: Apply this patch: https://patchwork.ozlabs.org/patch/966825/ make ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- powernv_defconfig ./scripts/config -e PPC_DISABLE_WERROR ./scripts/config -d FTRACE ./scripts/config -d BTRFS_FS ./scripts/config -d MD_RAID456 make CC=clang-7 CLANG_TRIPLE=powerpc64le-linux-gnu \ ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- ld: kernel/irq/manage.o: in function `local_bh_enable': /scratch/joel/linus/./include/linux/bottom_half.h:32:(.text+0x3ccc): relocation truncated to fit: R_PPC64_ADDR16_HA against `.text'+3cb8 ld: kernel/rcu/srcutree.o: in function `local_bh_enable': /scratch/joel/linus/./include/linux/bottom_half.h:32:(.text+0x258c): relocation truncated to fit: R_PPC64_ADDR16_HA against `.text'+2578 ld: kernel/time/hrtimer.o: in function `local_bh_enable': /scratch/joel/linus/./include/linux/bottom_half.h:32:(.text+0x242c): relocation truncated to fit: R_PPC64_ADDR16_HA against `.text'+2418 ld: kernel/bpf/cpumap.o: in function `local_bh_enable': /scratch/joel/linus/./include/linux/bottom_half.h:32:(.text+0x134c): relocation truncated to fit: R_PPC64_ADDR16_HA against `.text'+1338 ld: drivers/net/ethernet/broadcom/tg3.o: in function `local_bh_enable': /scratch/joel/linus/./include/linux/bottom_half.h:32:(.text+0x87dc): relocation truncated to fit: R_PPC64_ADDR16_HA against `.text'+87c8 ld: drivers/net/ethernet/intel/e1000/e1000_main.o: in function `local_bh_enable': /scratch/joel/linus/./include/linux/bottom_half.h:32:(.text+0xc13c): relocation truncated to fit: R_PPC64_ADDR16_HA against `.text'+c128 ld: net/core/sock.o: in function `local_bh_enable': /scratch/joel/linus/./include/linux/bottom_half.h:32:(.text+0x5a6c): relocation truncated to fit: R_PPC64_ADDR16_HA against `.text'+5a58 ld: net/core/gen_estimator.o: in function `local_bh_enable': /scratch/joel/linus/./include/linux/bottom_half.h:32:(.text+0x2ec): relocation truncated to fit: R_PPC64_ADDR16_HA against `.text'+2d8 ld: net/core/dev.o: in function `local_bh_enable': /scratch/joel/linus/./include/linux/bottom_
[llvm-bugs] [Bug 38865] New: x32: error in backend: Unable to copy EFLAGS physical register!
https://bugs.llvm.org/show_bug.cgi?id=38865
Bug ID: 38865
Summary: x32: error in backend: Unable to copy EFLAGS physical
register!
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: theonetruecam...@gmx.de
CC: llvm-bugs@lists.llvm.org
reduced test case:
==> /tmp/test-c03594.cpp <==
# 1 ""
# 1 "test.cpp"
struct a { a(const a&); };
a b() { return b(); }
==> /tmp/test-c03594.sh <==
# Crash reproducer for clang version 6.0.1 (tags/RELEASE_601/final)
# Driver args: "--driver-mode=g++" "-c" "test.cpp" "-O0" "-v"
# Original command: "/usr/lib/llvm/6/bin/clang-6.0" "-cc1" "-triple"
"x86_64-pc-linux-gnux32" "-emit-obj" "-mrelax-all" "-disable-free"
"-disable-llvm-verifier" "-discard-value-names" "-main-file-name" "test.cpp"
"-mrelocation-model" "static" "-mthread-model" "posix" "-mdisable-fp-elim"
"-fmath-errno" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables"
"-fuse-init-array" "-target-cpu" "x86-64" "-dwarf-column-info"
"-debugger-tuning=gdb" "-v" "-coverage-notes-file" "/home/sphinx/test.gcno"
"-resource-dir" "/usr/lib/llvm/6/bin/../../../../lib/clang/6.0.1"
"-internal-isystem" "/usr/lib/gcc/x86_64-pc-linux-gnux32/7.3.0/include/g++-v7"
"-internal-isystem"
"/usr/lib/gcc/x86_64-pc-linux-gnux32/7.3.0/include/g++-v7/x86_64-pc-linux-gnux32"
"-internal-isystem"
"/usr/lib/gcc/x86_64-pc-linux-gnux32/7.3.0/include/g++-v7/backward"
"-internal-isystem" "/usr/local/include" "-internal-isystem"
"/usr/lib/llvm/6/bin/../../../../lib/clang/6.0.1/include"
"-internal-externc-isystem" "/include" "-internal-externc-isystem"
"/usr/include" "-O0" "-fdeprecated-macro" "-fdebug-compilation-dir"
"/home/sphinx" "-ferror-limit" "19" "-fmessage-length" "173"
"-fobjc-runtime=gcc" "-fcxx-exceptions" "-fexceptions"
"-fdiagnostics-show-option" "-fcolor-diagnostics" "-o" "test.o" "-x" "c++"
"test.cpp"
"/usr/lib/llvm/6/bin/clang-6.0" "-cc1" "-triple" "x86_64-pc-linux-gnux32"
"-emit-obj" "-mrelax-all" "-disable-free" "-disable-llvm-verifier"
"-discard-value-names" "-main-file-name" "test.cpp" "-mrelocation-model"
"static" "-mthread-model" "posix" "-mdisable-fp-elim" "-fmath-errno"
"-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-fuse-init-array"
"-target-cpu" "x86-64" "-dwarf-column-info" "-debugger-tuning=gdb" "-v"
"-coverage-notes-file" "/home/sphinx/test.gcno" "-O0" "-fdeprecated-macro"
"-ferror-limit" "19" "-fmessage-length" "173" "-fobjc-runtime=gcc"
"-fcxx-exceptions" "-fexceptions" "-fdiagnostics-show-option"
"-fcolor-diagnostics" "-x" "c++" "test-c03594.cpp"
Attempting to compile with -O0 but not any other optimization level results in
this output, the problem also exists in trunk:
$ /usr/lib/llvm/6/bin/clang++ -c test.cpp -O0 -v -mx32
clang version 6.0.1 (tags/RELEASE_601/final)
Target: x86_64-pc-linux-gnux32
Thread model: posix
InstalledDir: /usr/lib/llvm/6/bin
Selected GCC installation: /usr/lib/gcc/x86_64-pc-linux-gnux32/7.3.0
Candidate multilib: .;@mx32
Candidate multilib: 64;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@mx32
"/usr/lib/llvm/6/bin/clang-6.0" -cc1 -triple x86_64-pc-linux-gnux32 -emit-obj
-mrelax-all -disable-free -disable-llvm-verifier -discard-value-names
-main-file-name test.cpp -mrelocation-model static -mthread-model posix
-mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases
-munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info
-debugger-tuning=gdb -v -coverage-notes-file /home/sphinx/test.gcno
-resource-dir /usr/lib/llvm/6/bin/../../../../lib/clang/6.0.1 -internal-isystem
/usr/lib/gcc/x86_64-pc-linux-gnux32/7.3.0/include/g++-v7 -internal-isystem
/usr/lib/gcc/x86_64-pc-linux-gnux32/7.3.0/include/g++-v7/x86_64-pc-linux-gnux32
-internal-isystem
/usr/lib/gcc/x86_64-pc-linux-gnux32/7.3.0/include/g++-v7/backward
-internal-isystem /usr/local/include -internal-isystem
/usr/lib/llvm/6/bin/../../../../lib/clang/6.0.1/include
-internal-externc-isystem /include -internal-externc-isystem /usr/include -O0
-fdeprecated-macro -fdebug-compilation-dir /home/sphinx -ferror-limit 19
-fmessage-length 173 -fobjc-runtime=gcc -fcxx-exceptions -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -o test.o -x c++ test.cpp
clang -cc1 version 6.0.1 based upon LLVM 6.0.1 default target
x86_64-pc-linux-gnux32
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnux32/7.3.0/include/g++-v7
/usr/lib/gcc/x86_64-pc-linux-gnux32/7.3.0/include/g++-v7/x86_64-pc-linux-gnux32
/usr/lib/gcc/x86_64-pc-linux-gnux32/7.3.0/include/g++-v7/backward
/usr/lib/llvm/6/bin/../../../../lib/clang/6.0.1/include
/usr/include
End of search list.
fatal error: error in backend
[llvm-bugs] Issue 10250 in oss-fuzz: llvm: Build failure
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: Proj-llvm Type: Build-Failure New issue 10250 by ClusterFuzz-External: llvm: Build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10250 The last 2 builds for llvm have been failing. Build log: https://oss-fuzz-build-logs.storage.googleapis.com/log-9c0bc01b-590f-47ea-8260-680d71e3a044.txt Build type: coverage To reproduce locally, please see: https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md#reproducing-build-failures If you have any questions, please file a bug on https://github.com/google/oss-fuzz/issues/new. **This bug will be automatically closed within a day once it is fixed.** -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38866] New: WebAssembly- assertion failure with alias for function
https://bugs.llvm.org/show_bug.cgi?id=38866
Bug ID: 38866
Summary: WebAssembly- assertion failure with alias for function
Product: tools
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: llc
Assignee: unassignedb...@nondot.org
Reporter: dfordi...@gmail.com
CC: llvm-bugs@lists.llvm.org
The alias in following code causes the below mentioned assertion with
webassembly target. It works fine with x86.
I guess this is because the alias Symbol is marked as 'isData' instead of
'isFunction'
llc: /home/divam/repos/llvm/lib/MC/WasmObjectWriter.cpp:1323: virtual uint64_t
{anonymous}::WasmObjectWriter::writeObject(llvm::MCAssembler&, const
llvm::MCAsmLayout&): Assertion `DataLocations.count(ResolvedSym) > 0' failed.
target datalayout = "e-m:e-p:32:32-i64:64-n32:64-S128"
target triple = "wasm32-unknown-unknown-wasm"
; target datalayout = "e-m:e-p:32:32-f64:32:64-f80:32-n8:16:32-S128"
; target triple = "i386-unknown-linux-gnu"
@ghczmprim_GHCziTypes_heqzusel_entry = alias i8, bitcast (void ()*
@ghczmprim_GHCziTypes_heqzusel_entry$def to i8*)
define ccc void @ghczmprim_GHCziTypes_heqzusel_entry$def() align 4 nounwind
{
c9YQ:
%ln9YZ = ptrtoint i8* @MainCapability to i32
%ln9Z0 = add i32 %ln9YZ, 808
ret void
}
@MainCapability = external global i8
--
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 38867] New: Merge r341642 into the 7.0 branch: ARM: fix ldrex on local variables
https://bugs.llvm.org/show_bug.cgi?id=38867 Bug ID: 38867 Summary: Merge r341642 into the 7.0 branch: ARM: fix ldrex on local variables Product: libraries Version: 7.0 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Backend: ARM Assignee: unassignedb...@nondot.org Reporter: t.p.northo...@gmail.com CC: llvm-bugs@lists.llvm.org The Rust folks seemed pretty keen on getting this into a release. -- 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 38868] New: for Microsoft compatibility, md5 hash on long mangled names
https://bugs.llvm.org/show_bug.cgi?id=38868
Bug ID: 38868
Summary: for Microsoft compatibility, md5 hash on long mangled
names
Product: clang
Version: 6.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: mib.bugzi...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
For long mangled names, VS2017 (and earlier) create an md5 hash for some
external names. Since clang doesn't do this, there is an undefined symbol at
link time. Here is a test case.
In my experiment, clang created a External PROC named xxxfoo, but Microsoft
mangled it to
test.asm: call??@f37d033b2f7c2800ae7be4d047d48121@
File test.h
#include
#include
#define FUN4096 xxfoo
#define FUN4095 xfoo
#define FUN4097 xxxfoo
class yField {};
typedef std::map
yxxxScreen
;
typedef std::map yxxxWebApp;
typedef std::map yxxxw2;
typedef std::map mymap;
//typedef std::map WebAppTest;
//typedef std::map mymap;
extern void FUN4096(mymap);
extern void FUN4095(mymap);
extern void FUN4097(mymap);
File test.cpp
#include "test.h"
#include
mymap obj;
int main() {
FUN4096(obj);
FUN4095(obj);
FUN4097(obj);
printf("PASSED\n");
return 0;
}
File testa.cpp
#include "test.h"
void FUN4096( mymap obj)
{
obj.clear();
}
void FUN4095( mymap obj)
{
obj.clear();
}
void FUN4097( mymap obj)
{
obj.clear();
}
--
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 37517] Assertion `NumReferences == 0 && "Node deleted while references remain"' with -inline -newgvn
https://bugs.llvm.org/show_bug.cgi?id=37517 bjorn.a.petters...@ericsson.com changed: What|Removed |Added Resolution|--- |FIXED CC||bjorn.a.pettersson@ericsson ||.com Fixed By Commit(s)||rL341651 Status|NEW |RESOLVED --- Comment #3 from bjorn.a.petters...@ericsson.com --- Fixed by Florian Hahn in rL341651 (see https://reviews.llvm.org/D51169 for more info) -- 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 38870] New: Add warnings for unusual unicode identifiers
https://bugs.llvm.org/show_bug.cgi?id=38870 Bug ID: 38870 Summary: Add warnings for unusual unicode identifiers Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: jykni...@google.com CC: llvm-bugs@lists.llvm.org The use of unicode in source code can cause great confusion to readers. This is true no matter what, but it is rather exacerbated by the fact that the C++11/C11 standards have a syntax for identifiers which does not follow the unicode consortium's recommendation for identifiers (http://www.unicode.org/reports/tr31/) Notably, the C/C++ syntax allows a bunch of codepoints which are invisible format characters (in the unicode character class "Cf"). One instance which I just ran into in actual source code (causing great consternation!) is U+200b ZERO WIDTH SPACE. In multiple cases in our codebase, developers have managed to type (or copy/paste) that character into an identifier declaration, and then used editor completion to copy that mistake into the uses of the name, too. I believe clang should have warnings for this -- both an default-on warning for the characters that really shouldn't be present at all, and some optional warnings for further restricting the character-set used. I propose 3 new warnings. None of these should warn on the use of \u escapes in an identifier, *only* for unicode characters literally in the source code. -Wunicode-identifier-unusual: Warn on the use of a non-escaped character in an identifier which is not a usual identifier character (per Unicode Consortium UAX#31's ID_Continue). This will warn on the usage of invisible format characters, amongst others. Enabled by default. -Wunicode-identifier-unusual=2: Warn on the use of a non-escaped character in an identifier which are not valid in UAX#31's ID_continue table, and on those which are listed in the additional candidates for exclusion table. -Wunicode-identifier: Warn on the use of any unescaped non-ascii character in an identifier. An ID_Continue table has 707 ranges, and a table of excluded ranges for the additional candidates to exclude for the 2nd level warning is somewhere around 230 ranges. Thus, this would probably add about 7K of extra static data to clang, which doesn't seem an unreasonable amount. While checking the codebase for this sort of issue, some instances in string constants were also found -- and although one such instance was a bug, I don't believe strange characters in string constants is as obviously wrong, so I don't propose to do anything about that. -- 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 38871] New: std::atomic not always atomic when compiling with GCC
https://bugs.llvm.org/show_bug.cgi?id=38871
Bug ID: 38871
Summary: std::atomic not always atomic when compiling with GCC
Product: libc++
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: richard-l...@metafoo.co.uk
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Compiling this with GCC:
#include
struct X { char c[4]; };
std::atomic x;
... results in a call to __atomic_load to load the X object. However, due to
gcc.gnu.org/PR87237, that builtin is not actually atomic in this case.
libstdc++ works around this by increasing the alignment of atomic to
sizeof(X) if sizeof(X) is a power of 2 not greater than 16, so that's
presumably the set of cases where the GCC bug occurs. libc++ should probably do
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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38872] New: Unexpected break before lessless if it is between two strings
https://bugs.llvm.org/show_bug.cgi?id=38872
Bug ID: 38872
Summary: Unexpected break before lessless if it is between two
strings
Product: clang
Version: 6.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: jzpigtc4...@0box.eu
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
$ echo -e 'void fu(void) {\ncout << "A" << "B" << "C" << D << "E" << "F" <<
"G"\n}' | clang-format -style="{BasedOnStyle: LLVM, AlignAfterOpenBracket:
DontAlign, AlignOperands: false}"
void fu(void) {
cout << "A"
<< "B"
<< "C" << D << "E"
<< "F"
<< "G"
}
clang-format inserts an (unwanted) break before a lessless (stream insertion)
operator if (and only if) it is between two string literals. Why? Is there any
intention or rationale? (ColumnLimit cannot be a cause.)
Moreover the lessless-es get aligned, despite that no alignment is allowed.
--
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 38873] New: Unexpected breaks after 'endl'
https://bugs.llvm.org/show_bug.cgi?id=38873
Bug ID: 38873
Summary: Unexpected breaks after 'endl'
Product: clang
Version: 6.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: jzpigtc4...@0box.eu
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
If ColumnLimit high enough (but not zero) then the statement fits in a single
line:
$ echo -e 'void fu(void) {\ncerr << endl << endl << "A" << endl << endl << endl
<< "B" << endl;\n}' |clang-format -style="{BasedOnStyle: LLVM, ColumnLimit:
200, AlignAfterOpenBracket: DontAlign, AlignOperands: false}"
void fu(void) { cerr << endl << endl << "A" << endl << endl << endl << "B" <<
endl; }
If ColumnLimit does not allow single line, then the line is breaked (wrapped)
-- but into too many pieces:
$ echo -e 'void fu(void) {\ncerr << endl << endl << "A" << endl << endl << endl
<< "B" << endl;\n}' |clang-format -style="{BasedOnStyle: LLVM, ColumnLimit: 60,
AlignAfterOpenBracket: DontAlign, AlignOperands: false}"
void fu(void) {
cerr << endl
<< endl
<< "A" << endl
<< endl
<< endl
<< "B" << endl;
}
After each and every 'endl' a break is introduced. Why? Any rationale or
intention?
Moreover, "ColumnLimit: 0" ("infinite limit") is NOT respected! I expected the
same behaviour as with "ColumnLimit: 220" (or 2 or any very high value).
$ echo -e 'void fu(void) {\ncerr << endl << endl << "A" << endl << endl << endl
<< "B" << endl;\n}' |clang-format -style="{BasedOnStyle: LLVM, ColumnLimit: 0,
AlignAfterOpenBracket: DontAlign, AlignOperands: false}"
void fu(void) {
cerr << endl
<< endl
<< "A" << endl
<< endl
<< endl
<< "B" << endl;
}
Moreover, alignment occurs, despite that alignments are prohibited (each 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 38787] MCCodeView assertion and compilation failure with benchmark library
https://bugs.llvm.org/show_bug.cgi?id=38787 Reid Kleckner changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Reid Kleckner --- I built with clang r340925 and this assertion doesn't occur. I re-enabled the benchmark library in r341716, so I will say this is 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38730] segfault in llvm::DAGTypeLegalizer::DisintegrateMERGE_VALUES
https://bugs.llvm.org/show_bug.cgi?id=38730 Nick Desaulniers changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #16 from Nick Desaulniers --- *** This bug has been marked as a duplicate of bug 36378 *** -- 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 38874] New: Benchmarks library introduces new cmake warnings
https://bugs.llvm.org/show_bug.cgi?id=38874 Bug ID: 38874 Summary: Benchmarks library introduces new cmake warnings Product: new-bugs Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: r...@google.com CC: kbobyrev.opensou...@gmail.com, llvm-bugs@lists.llvm.org I see two new cmake warnings in my build on Windows since the benchmarks library was enabled: CMake Warning (dev) at utils/benchmark/CMakeLists.txt:3 (project): Policy CMP0048 is not set: project() command manages VERSION variables. Run "cmake --help-policy CMP0048" for policy details. Use the cmake_policy command to set the policy and suppress this warning. The following variable(s) would be set to empty: PROJECT_VERSION PROJECT_VERSION_MAJOR PROJECT_VERSION_MINOR PROJECT_VERSION_PATCH This warning is for project developers. Use -Wno-dev to suppress it. -- git Version: v0.0.0 -- Version: 0.0.0 -- Performing Test HAVE_GNU_POSIX_REGEX -- failed to compile -- Performing Test HAVE_POSIX_REGEX -- failed to compile CMake Warning at utils/benchmark/CMakeLists.txt:234 (message): Using std::regex with exceptions disabled is not fully supported It would be great to fix the CMP0048 one at least since it's very noisy. The second one seems difficult. -- 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 38875] New: lld always emits .relr.dyn section even when that section is empty
https://bugs.llvm.org/show_bug.cgi?id=38875 Bug ID: 38875 Summary: lld always emits .relr.dyn section even when that section is empty Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: pho...@chromium.org CC: llvm-bugs@lists.llvm.org We're seeing this in our kernel, there should be no need for lld to emit that section. ./prebuilt/downloads/clang/bin/llvm-readelf -S build-x64-clang/zircon.elf ~/fuchsia/zircon There are 40 section headers, starting at offset 0xc83088: Section Headers: [Nr] Name TypeAddress OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .text.boot0 PROGBITS8010 001000 70 00 A 0 0 1 [ 2] .buildsig PROGBITS80100070 001070 28 00 A 0 0 1 [ 3] .text.bootPROGBITS80100098 001098 0002d8 00 AX 0 0 8 [ 4] .text.bootstrap16 PROGBITS80101000 002000 000166 00 AX 0 0 4096 [ 5] .text PROGBITS80101170 002170 0f6325 00 AX 0 0 16 [ 6] .rodata.rodso_image PROGBITS 801f8000 0f9000 00e000 00 A 0 0 4096 [ 7] code_patch_table PROGBITS80206000 107000 60 00 A 0 0 8 [ 8] .relr.dyn RELR80206060 107060 00 08 A 0 0 8 [ 9] .note.gnu.build-id NOTE 80206060 107060 18 00 A 0 0 4 [10] .kcounter.descPROGBITS80206078 107078 0001a0 00 WA 0 0 8 [11] .rodata PROGBITS80206220 107220 024bd0 00 AMS 0 0 32 [12] .data.rel.ro PROGBITS8022adf0 12bdf0 0062d8 00 WA 0 0 16 [13] .init_array INIT_ARRAY 802310c8 1320c8 c0 00 WA 0 0 8 [14] .data PROGBITS80232000 133000 00f0e8 00 WA 0 0 4096 [15] .bss NOBITS 80242000 1420e8 083970 00 WA 0 0 4096 [16] .comment PROGBITS 1420e8 000107 01 MS 0 0 1 [17] .rela.textRELA 1421f0 0e7048 18 I 37 5 8 [18] .rela.data.rel.ro RELA 229238 00e178 18 I 37 12 8 [19] .debug_strPROGBITS 2373b0 0fb516 01 MS 0 0 1 [20] .debug_locPROGBITS 3328c6 220c96 00 0 0 1 [21] .debug_abbrev PROGBITS 55355c 044085 00 0 0 1 [22] .debug_info PROGBITS 5975e1 3faedc 00 0 0 1 [23] .debug_ranges PROGBITS 9924bd 06a9c0 00 0 0 1 [24] .debug_macinfoPROGBITS 9fce7d 00013b 00 0 0 1 [25] .debug_pubnames PROGBITS 9fcfb8 0be92b 00 0 0 1 [26] .debug_pubtypes PROGBITS abb8e3 070e6b 00 0 0 1 [27] .debug_frame PROGBITS b2c750 033b88 00 0 0 8 [28] .debug_line PROGBITS b602d8 0cdaf2 00 0 0 1 [29] .rela.rodata RELA c2ddd0 0113d0 18 I 37 11 8 [30] .rela.dataRELA c3f1a0 000588 18 I 37 14 8 [31] .rela.init_array RELA c3f728 000240 18 I 37 13 8 [32] .rela.kcounter.desc RELA c3f968 0004e0 18 I 37 10 8 [33] .debug_arangesPROGBITS c3fe48 000290 00 0 0 1 [34] .rela.text.boot RELA c400d8 000540 18 I 37 3 8 [35] .relacode_patch_table RELA c40618 c0 18 I 37 7 8 [36] .rela.text.bootstrap16 RELA c406d8 c0 18 I 37 4 8 [37] .symtab SYMTAB c40798 01a9d0 18 39 4534 8 [38] .shstrtab STRTAB c5b168 000206 00 0 0 1 [39] .strtab STRTAB c5b36e 027d17 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), l (large) I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) -- You are receiving t
[llvm-bugs] [Bug 38876] New: Suppressing -Wduplicate-enum via pragma is less intuitive than it should be
https://bugs.llvm.org/show_bug.cgi?id=38876 Bug ID: 38876 Summary: Suppressing -Wduplicate-enum via pragma is less intuitive than it should be Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: arthur.j.odw...@gmail.com CC: llvm-bugs@lists.llvm.org Inspired by discussion of duplicated enum values in https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/mpGmQBP4AqI , I decided to play around with -Wduplicate-enum. cat >test.cc
