similar to: [ELF] String literals don't obey -fdata-sections

On 2020-09-16 00:18, Fangrui Song wrote: > Usually it is because nobody has noticed the problem or nobody is > motivated enough to fix the problems, not that they intentionally leave > a problem open:) I took some time to look at the problem and conclude > that clang should do nothing on this. Actually, with the clang behavior, > you can discard "Unused" if you use LLD.

Hello, We would like to propose a way for improving the diagnostics for address_space by being able to pass strings as an argument to it instead of just an integer. This was initially proposed before (http://lists.llvm.org/pipermail/cfe-dev/2018-August/058702.html) but did not focus on it at the time. Reasoning: Clang's __attribute__((address_space(...))) feature uses an arbitrary integer as

+cfe-dev at lists.llvm.org On Thu, Jan 10, 2019 at 2:16 PM Jacob Lifshay <programmerjake at gmail.com> wrote: > > Stash a lookup table from integers to strings in Context and dynamically allocate integers for new strings. You can then keep integers in most of the code, writing/displaying strings for the integers with an entry in the table when writing to files or displaying. > >

On Oct 15, 2008, at 7:34 PM, Eli Friedman wrote: > This bug actually manifests itself in two places: one is > ConstantMerge, the other is the AsmPrinter. It's non-trivial to fix > because it's really a design bug: we assume that constant==mergeable, > which simply isn't true. There are a few different ways of fixing > this; however, I think the only real option is to

Hi, I'm in the process of migrating from clang5 to clang10. Unfortunately clang10 introduced a negative performance impact. The cause is an increase of PLT entries from this patch (first released in clang7): https://bugs.llvm.org/show_bug.cgi?id=36370 https://reviews.llvm.org/D43383 If I revert that clang patch locally, the additional PLT entries and the performance impact disappear. This

On Wed, Oct 15, 2008 at 8:28 AM, Chris Lattner <clattner at apple.com> wrote: >> I do think however that it's bit dangerous to combine static constants >> across compilation units. > > GCC does the same things with strings in some cases. You shouldn't > depend on this behavior if you want portable code. Combining is explicitly allowed for strings in C:

Hello All, I was trying to add Microblaze target to LLVM backend. I was able to generate object file with relocations. and debug symbols. When I try to link this object file with microblaze GCC linker I am getting below errors and debug symbols are missing in it. mb-objdump: DWARF error: found dwarf version '15877', this reader only handles version 2, 3, 4 and 5 information

On Saturday, April 18, 2020, David Blaikie <dblaikie at gmail.com> wrote: > > > On Sat, Apr 18, 2020 at 3:02 AM Nagaraju Mekala via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hello All, >> >> I was trying to add Microblaze target to LLVM backend. I was able to >> generate object file with relocations. and debug symbols. >>

Hello. I have been trying to check, how llvm works on Solaris recently. First I have tested lli, whitch seems to execute the bytecode generated on Linux without any problems. However, llc has failed to generate valid SPARC assembler code even on the helloworld example. Here is the generated code: sakharov at trillian:~$ cat ./test.s .text .align 16 .globl main

On Sat, Apr 18, 2020 at 11:11 PM David Blaikie <dblaikie at gmail.com> wrote: > > Yeah, not sure - you mention the linker produces errors, but the errors you showed looked like objdump errors? Were those errors from trying to dump the linked executable, and not errors that were produced by the linker itself? Yes, as mentioned earlier I was able to generate final executable but it

Hi, We’d like to propose an extension to both the map file and the print-gc/icf-sections output. This extension would be to report the pieces of .eh_frame and SHF_MERGE sections in these files somehow. Since all (or at least the majority) of the contents of these sections in the output come from inputs, it would be beneficial in trying to associate the output contents with where they came from,

I am running jruby (1.7.3) & rails 2.3.17 application whose apis are exposed to outside app. When I add "config.threadsafe!" in my development.rb/production.rb & hit lot many api requests in a second then I am getting following errors randomly for some of the api requests: 1. TypeError (NilClass can't be coerced into Float) 2. RuntimeError (can't add a new key

v1 was here: https://www.redhat.com/archives/libguestfs/2017-November/msg00068.html v1 -> v2: - Use a configure-time test. Rich.

Me again! Think we've found it. By diving into the LXC logs for the specific container, we found this: 2014-04-17 21:07:06.066+0000: 2861: debug : virCgroupSetValueStr:678 : Set value '/sys/fs/cgroup/devices/machine/oshi32134.libvirt-lxc/devices.allow' to 'c 189:130 rw' Looks like libvirt the permission to 'rw', not 'rmw' [1], so no surprise that when it

In compiling perlbench in SPEC2006 today, I get the following asm code: .4byte ($debug_loc2280) .4byte 1 .4byte PerlIO_fd_refcnt $set1406 = ($.bss_end)-PerlIO_fd_refcnt .4byte ($set1406) .4byte PerlIO_perlio $set1407 = ($.data_end)-PerlIO_perlio .4byte ($set1407) .4byte ($func_begin0) $set1408 = ($.text_end)-($func_begin0) .4byte

I find it surprising that given this: void f1() { const struct { int a; } b = { 0 }; } that clang does not put b on the stack. gcc does. My gut feeling says it belongs on stack. But perhaps, the thing is, it is const, and location shouldn't matter to most code, as long as lifetime is adequate. Almost no code could tell the difference. But we have code that takes the address of things, and

On Thu, Oct 16, 2008 at 3:26 PM, Mike Stump <mrs at apple.com> wrote: > On Oct 16, 2008, at 1:57 PM, Eli Friedman wrote: >> I strongly doubt we can get away with that. > > Yeah, we agree on that one. I was just thinking about the const case. > >> Here's a more concrete version of the solution I'm proposing: we add a >> new optional marking to constant

Hello, Tatu > Is that correct? I think it's just something to be aware of. Currently we're aggressively merging globals by default. Do you think it will be better to provide special flag to control this behavior? -- WBR, Anton Korobeynikov

With the MIPS compiler, when we have static constants, in the .s file we get something like: .type $.str33, at object # @.str33 .section .rodata.str1.1,"aMS", at progbits,1 $.str33: .asciz "//" .size $.str33, 3 Currently when we create direct object code we are referencing the symbol as an offset in .rodata and not directly using

Hi everyone, *1.* I had a file called server.cpp that i can run using: g++ -o server server.cpp -lrpc -ldl -lpthread *2.* Converted the file into LLVM IR, modified it and saved to file using the WriteBitcodeToFile function. The name of resulting file is "output". *3.* Used llc command for generation of "output.o" file as: llc -filetype=obj output *4.* Used gcc command to