similar to: [LLVMdev] LTO "bug" and Clang warnings

Hi Duncan, Ok, I found that even if main() does reference foo, setup() still gets chopped off and the results is the unexpected: Foo: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Bar: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Baz: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 So, while there is the issue in LTO, I still think Clang could give a warning. This is a source of buffer overflow

Hi Renato, On 08/01/13 17:16, Renato Golin wrote: > After looking at the Livermore for a while, we found the issue that was causing > LTO to produce a different result. > > Consider the code below [1]. setup() doesn't touch bar/baz, main() doesn't > reference foo. LTO finds, correctly, I don't think this is correct. At the LLVM IR level it is valid to write into bar

On Tue, Jan 8, 2013 at 8:16 AM, Renato Golin <renato.golin at linaro.org> wrote: > After looking at the Livermore for a while, we found the issue that was > causing LTO to produce a different result. > > Consider the code below [1]. setup() doesn't touch bar/baz, main() doesn't > reference foo. LTO finds, correctly, that it can remove the setup(), but the > result

On 8 January 2013 16:53, David Blaikie <dblaikie at gmail.com> wrote: > I'm not sure what you mean by "fix user's stupidity" here - could you > clarify? > Buffer overrun on foo[20] and relying on it for bar[20]. It might not even be an error to access foo[50] even though foo only has 20 elements (via pointer indirection rules), but it's user error to do so,

Andy and I briefly discussed this the other day, we have not yet got chance to list a detailed pass order for the pre- and post- IPO scalar optimizations. This is wish-list in our mind: pre-IPO: based on the ordering he propose, get rid of the inlining (or just inline tiny func), get rid of all loop xforms... post-IPO: get rid of inlining, or maybe we still need it, only

On Tue, Jan 8, 2013 at 7:29 PM, Renato Golin <renato.golin at linaro.org>wrote: > On 8 January 2013 16:53, David Blaikie <dblaikie at gmail.com> wrote: > >> I'm not sure what you mean by "fix user's stupidity" here - could you >> clarify? >> > > Buffer overrun on foo[20] and relying on it for bar[20]. > > It might not even be an

On Mon, Aug 6, 2018 at 4:30 PM Quentin Colombet <quentin.colombet at gmail.com> wrote: > Hi Bill, > > > 2018-08-06 16:13 GMT-07:00 Bill Wendling via llvm-dev < > llvm-dev at lists.llvm.org>: > > Is there a way to get object files from the LTO step before the linker > > performs the final link phase? What I'd like to do is given these bitcode > >

Dear Dressers of RedCloth, I have a question: text = "Foo\nBar\n\nBaz" RedCloth.new(text, [ :hard_breaks ]).to_html # => "<p>Foo<br />Bar<br />\nBaz</p>" Shouldn''t that really be "<p>Foo<br />Bar</p><p>Baz</p>"? So long, -- Christoffer Sawicki

Is there a way to get object files from the LTO step before the linker performs the final link phase? What I'd like to do is given these bitcode files: a.lto.o, b.lto.o, c.lto.o run LTO on them and get out the object files: a.o, b.o, c.o (These .o files hold the code that is sent directly to the final link phase.) If there doesn't currently exist a way, is such a thing possible?

On 8 January 2013 18:40, Matthieu Monrocq <matthieu.monrocq at gmail.com>wrote: > I do believe it's undefined. > > §5.2.1 Subscripting [expr.sub] > ... > §5.7 Additive operators [expr.add] > ... > Still, doesn't explicitly say it's undefined. I agree this gives the freedom of implementers to extend naturally, but it's at least arguable. I have the 2011

On Tue, Jan 8, 2013 at 10:29 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 8 January 2013 16:53, David Blaikie <dblaikie at gmail.com> wrote: >> >> I'm not sure what you mean by "fix user's stupidity" here - could you >> clarify? > > > Buffer overrun on foo[20] and relying on it for bar[20]. > > It might not even be an

On Tue, Jan 8, 2013 at 11:11 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 8 January 2013 18:40, Matthieu Monrocq <matthieu.monrocq at gmail.com> > wrote: >> >> I do believe it's undefined. >> >> §5.2.1 Subscripting [expr.sub] >> ... >> §5.7 Additive operators [expr.add] >> ... > > > Still, doesn't explicitly

Hi all, As promised, here is a brain dump on how I see CFI for vcalls working under ThinLTO. Most of this has been prototyped, so the design does appear to be sound. For context on how CFI currently works under regular LTO, please read: http://llvm.org/docs/TypeMetadata.html http://clang.llvm.org/docs/ControlFlowIntegrityDesign.html http://clang.llvm.org/docs/LTOVisibility.html ==== Summary

​Hi again, Teresa. Looks like I had forgotten to report back with success when finally building 3.9.0 in ThinLTO linker mode back in October. Sorry about that and thanks for helping me out. I know how important it is to get success reports as well, as a developer myself, so sorry again :(. While that worked back then, last weekend I tried to build 3.9.1 using 3.9.0 as installed from Arch Linux

On Fri, Jul 15, 2016 at 8:39 PM, Sean Silva <chisophugis at gmail.com> wrote: > It looks like there is really no sane fix within the current > infrastructure. I've had to essentially trigger invalidation (except in the > PreservedAnalyses::all() case) in the function pass manager and function to > loop adapters. > invalidation of *everything* I mean. -- Sean Silva

On Tue, Sep 27, 2016 at 6:33 PM, Teresa Johnson <tejohnson at google.com> wrote: > > I can't reproduce the failure. I am building with a clang built > Release from recent source as my stage-1 bootstrap compiler: > clang version 4.0.0 (trunk 282322) (llvm/trunk 282341) The clang I use was built from the 3.9 release branch: clang version 3.9.1 (branches/release_39

Hi Peter, Thanks for sending this and sorry for the slow response. Some questions below. Teresa On Tue, Oct 25, 2016 at 5:27 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > Hi all, > > As promised, here is a brain dump on how I see CFI for vcalls working > under ThinLTO. Most of this has been prototyped, so the design does appear > to be sound. For context on how CFI

Hi , I have an issue during LTO phase of llvm compiler which is as follows, File t3.c --------- #include <stdio.h> #include <stdlib.h> // A linked list node struct Node { int data; struct Node* next; struct Node* prev; }; struct Node* head; /* Given a reference (pointer to pointer) to the head of a list and an int, inserts a new node on the front of the list. */

----- Original Message ----- > From: "Sean Silva" <chisophugis at gmail.com> > To: "Chandler Carruth" <chandlerc at gmail.com> > Cc: "Xinliang David Li" <davidxl at google.com>, "llvm-dev" > <llvm-dev at lists.llvm.org>, "Davide Italiano" > <dccitaliano at gmail.com>, "Tim Amini Golling" >

Looks like this is indeed related to r360841. In C, there are distinctions between declarations, definitions and tentative definitions. Global variables declared with "extern" are declarations. Global variables that don't have "extern" and have initializers are definitions. If global variables have neither "extern" nor initializers, they are called tentative