similar to: [LLVMdev] [PATCH] Prevent clang from throwing the diagnostics twice.

Test cases? Also, this seems a bit heavy-handed for a solution. Why is getLastArgIntValue being called twice in the first place? ~Aaron On Fri, Nov 15, 2013 at 6:35 AM, Umesh Kalappa <umesh.kalappa0 at gmail.com> wrote: > Hi All, > > Clang pop up with the "error: invalid integral value" diagnostics twice > ,when you enable the optimization through -O with a

On Fri, Nov 15, 2013 at 11:19 AM, Umesh Kalappa <umesh.kalappa0 at gmail.com> wrote: > Hi Aaron, > >>>Why is getLastArgIntValue being called twice in the first place? > > It has been called from the getOptimizationLevel() ,which in turn called by > methods like ParseCodeGenArgs() and ParseLangArgs(), > > where method getOptimizationLevel() register the

> As Chad pointed, it's likely that this requires a non-trivial > refactoring. I don't have particularly bright ideas on solving it, but > I'm uncomfortable adding the flag at the arg level because it kind of > encourages lazy design when handling args. Perhaps looking into ways > the code could be refactored so that getOptimizationLevel() is only > called once (and

Hi Justin , Thank you for the confirmation and we would like to know that ,going forward the clang has the support the gcc gcov format or use the -fprofile-instr-generate -fcoverage-mapping and get ride of gcov format . We are planing to customize the clang code coverage for embedded world ,before we start tweaking the gcov / -fprofile-instr-generate code-base ,we would like to take feedback

Umesh Kalappa <umesh.kalappa0 at gmail.com> writes: > Hi Justin , > > Thank you for the confirmation and we would like to know that ,going > forward the clang has the support the gcc gcov format or use the > -fprofile-instr-generate -fcoverage-mapping and get ride of gcov > format . Going forward, the -fprofile-instr-generate -fcoverage-mapping (which I'll refer to as

Hi All, We have populated info in the Clang Sema i.e class Sema (include/clang/Sema/Sema.h) and like to propagate the same to Clang Codegen . Currently we are propagating through ASTContext ,where we have duplicating fields info and operation in the Sema and ASTContext . Any better way of doing the same ? Thank you ~Umesh

Try using $PWD/test.cpp on the clang command line. I am seeing the duplicate DIFile entries, but not yet able to reproduce a .debug_line section with multiple directory entries. --paulr From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Tomar, Sourabh Singh via llvm-dev Sent: Tuesday, September 1, 2020 1:07 PM To: Umesh Kalappa <umesh.kalappa0 at gmail.com>; cfe-dev at

Hi All, We trying to use clang+llvm to generate the gcc coverage format as clang version 3.6.0 $clang --coverage -Xclang -coverage-cfg-checksum -Xclang -coverage-no-function-names-in-data -Xclang -coverage-version='407*' test.c $a.out $llvm-cov gcov test.gcda Unexpected version: *704. Invalid .gcno File! Debugging the above cause ,But any hints from experts here ,will help a lot

> On May 29, 2016, at 5:44 PM, Shi, Steven <steven.shi at intel.com> wrote: > > (And I doubt the GNU linker supports LTO with LLVM). > [Steven]: I’ve pushed GNU Binutils ld to support LLVM gold plugin, see detail in this bug https://sourceware.org/bugzilla/show_bug.cgi?id=20070 <https://sourceware.org/bugzilla/show_bug.cgi?id=20070>. The new GNU ld linker works well with

> On May 29, 2016, at 5:10 PM, Shi, Steven <steven.shi at intel.com> wrote: > > Hi Mehdi, > GCC LTO seems support large code model in my side as below, if the code model is linker specific, does the GCC LTO use a special linker which is different from the one in GNU Binutils? I don't know anything about GCC. (And I doubt the GNU linker supports LTO with LLVM). > I’m a

Hi Mehdi, Should I apply your attached patch on my llvm3.8 source firstly? Or should I use the latest llvm SVN trunk instead? Steven Shi Intel\SSG\STO\UEFI Firmware Tel: +86 021-61166522 iNet: 821-6522 From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] Sent: Monday, May 30, 2016 2:13 PM To: Shi, Steven <steven.shi at intel.com> Cc: Umesh Kalappa <umesh.kalappa0 at

Hi, > On May 29, 2016, at 7:36 AM, Shi, Steven <steven.shi at intel.com> wrote: > > Hi Mehdi, > After deeper debug, I found my firmware LTO wrong code issue is related to X64 code model (-mcmodel=large) is always overridden as small (-mcmodel=small) if LTO build. And I don't know how to correctly specific the large code model for my X64 firmware LTO build. Appreciate if

Hi Steven, > On May 29, 2016, at 11:28 PM, Shi, Steven <steven.shi at intel.com> wrote: > > Hi Mehdi, > Should I apply your attached patch on my llvm3.8 source firstly? Or should I use the latest llvm SVN trunk instead? I wrote it on trunk, but I expect it to be fairly easy to port on 3.8. This is really just quickly plumbing an option on the TargetMachine creation. --

> On May 17, 2016, at 11:21 AM, Umesh Kalappa <umesh.kalappa0 at gmail.com> wrote: > > Steven, > > As mehdi stated , the optimisation level is specific to linker and it > enables Inter-Pro opts passes ,please refer function To be very clear: the -O option may trigger *linker* optimizations as well, independently of LTO. -- Mehdi > >

Dear Andrew and the Group, I’m trying come up with a SchedMachineModel for the AMD bulldozer http://en.wikipedia.org/wiki/Bulldozer_(microarchitecture). The model is not exist for the same .Please correct me if am i wrong here. I was going through your reference @ https://llvm.org/svn/llvm-project/llvm/trunk/include/llvm/Target/TargetSchedule.td . But I couldn’t model some of the

Hi andrea, R11 treated as frame pointer at arm backend , which is fixed again . Thanks Umesh On Tuesday, October 15, 2013, Andrea Mucignat <andrea at nestlabs.com> wrote: > Umesh, > Makes some sort of sense to me, OTOH: > If instead of choosing r11 as a "dummy" to align the stack we had chosen some other register in the range r0-r7 then we could have emitted the PUSH

(And I doubt the GNU linker supports LTO with LLVM). [Steven]: I’ve pushed GNU Binutils ld to support LLVM gold plugin, see detail in this bug https://sourceware.org/bugzilla/show_bug.cgi?id=20070. The new GNU ld linker works well with LLVM/Clang LTO when build IA32 code in my side. And from the ld owner input in the bug comments, the current X64 LLVM LTO issue is in llvm LTO plugin. The fact

On 7 June 2016 at 10:54, Shi, Steven <steven.shi at intel.com> wrote: > Hi Rafael, > I finally enable the clang LTO build with small code model and PIE, and my clang LTO Uefi firmware works now. Thank you! But I have one more issue on the clang normal build (without LTO) now. I find the small code model + "-fpie" build option will let clang generate some R_X86_64_GOTPCREL

Edited the Subject. On Fri, Jul 20, 2018 at 5:50 PM, Umesh Kalappa <umesh.kalappa0 at gmail.com> wrote: > Hi All , > > We are looking at the C sample i.e > > extern int i,j; > > int test() > { > while(1) > { i++; > j=20; > } > return 0; > } > > command used :(clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final) > ) > clang

Hi Mehdi, After deeper debug, I found my firmware LTO wrong code issue is related to X64 code model (-mcmodel=large) is always overridden as small (-mcmodel=small) if LTO build. And I don't know how to correctly specific the large code model for my X64 firmware LTO build. Appreciate if you could let me know it. You know, parts of my Uefi firmware (BIOS) have to been loaded to run in high