similar to: [LLVMdev] [DragonEgg] Why Fortran's "call flush()" is converted to "call void bitcast (void (...)* @_gfortran_flush_i4 to void (i8*)*)(i8* null) nounwind" ?

Hi Dmitry, > Do you think this is a system problem of gcc applicable to other functions too, or just a flush-specific bug? it has nothing to do with flush - for all I know flush is fine. Dragonegg does this for all Fortran functions because the Fortran front-end is so buggy, i.e. often produces wrong function types. I have another way of handling this in mind, which would avoid this trick,

Duncan, Oh, right, now I remember: it's a very old problem I knew 1.5 years ago. There were even some bugs on it, here is a common case: > cat test1.f90 program test call test1() end program test > kernelgen-dragonegg test1.f90 -o- | opt -O3 -S -o - ; ModuleID = '<stdin>' target datalayout =

On 17/07/12 08:22, Anton Korobeynikov wrote: > Dmitry, > >> This is probably a question for Fortran/DragonEGG experts: >> >> Why Fortran's "call flush()" is converted to "call void bitcast (void (...)* >> @_gfortran_flush_i4 to void (i8*)*)(i8* null) nounwind" ? Why it needs >> bitcast? > Just a wild guess (basing from my llvm-gcc

Dmitry, > This is probably a question for Fortran/DragonEGG experts: > > Why Fortran's "call flush()" is converted to "call void bitcast (void (...)* > @_gfortran_flush_i4 to void (i8*)*)(i8* null) nounwind" ? Why it needs > bitcast? Just a wild guess (basing from my llvm-gcc knwoledge though): there is a bug with in gcc fortran frontend where it fails to

Dear Anton and Duncan, Thank you for your insight, Do you think this is a system problem of gcc applicable to other functions too, or just a flush-specific bug? Best, - Dima. ----- Original message ----- > On 17/07/12 08:22, Anton Korobeynikov wrote: > > Dmitry, > > > > > This is probably a question for Fortran/DragonEGG experts: > > > > > > Why

Hi Anton, >> How do you think what would be the best way to workaround this problem, if >> it seems to be not in focus for anybody for now? > Keep in mind, this not LLVM problem, it's gfortran problem. Also, it's > of pretty low priority for gcc devs since they do almost no type > checking on TREEs, so the varargs decl seems to be only viable > llvm-side fix.

> Oh, right, now I remember: it's a very old problem I knew 1.5 years ago. > There were even some bugs on it, here is a common case: Yes, this is right, fortran frontend produces bogus trees for every external call. The problem seems to have roots from the fact that there is no external function decl here, so frontend has no way even to infer the type from. > How do you think what

Hi Anton, On 17/07/12 15:35, Anton Korobeynikov wrote: >> actually there is a different fix, which is to not pay any attention to GCC >> function types when generating calls (and function prototypes), and instead >> do everything by querying GCC's CUMULATIVE_ARGS. > I tried to do this during llvm-gcc times and it turned out that there > might be different calls with

Thanks, Duncan, makes sense! I suppose you meant something like this: Function* callee = dyn_cast<Function>( call->getCalledValue()->stripPointerCasts()); if (!callee) continue; - D. 2012/7/17 Duncan Sands <baldrick at free.fr> > Hi Dmitry, it would be neater to use stripPointerCasts. > > Ciao, Duncan.

> actually there is a different fix, which is to not pay any attention to GCC > function types when generating calls (and function prototypes), and instead > do everything by querying GCC's CUMULATIVE_ARGS. I tried to do this during llvm-gcc times and it turned out that there might be different calls with different signatures in single module e.g. function with N arguments is called

Hi Dmitry, it would be neater to use stripPointerCasts. Ciao, Duncan. > OK, at our end the following workaround seems to be sufficient: > > // Check if function is called (needs -instcombine pass). > Function* callee = call->getCalledFunction(); > if (!callee) > { >

OK, at our end the following workaround seems to be sufficient: // Check if function is called (needs -instcombine pass). Function* callee = call->getCalledFunction(); if (!callee) { // Could be also a function called inside a bitcast. // So try to extract function

On Wed, Oct 06, 2010 at 09:21:51PM +0400, Anton Korobeynikov wrote: > Jack, > > >   Have you considered looking up that bug in FSF gcc bugzilla and pinging it? > > The gfortran developers may  have forgotten about it and perhaps it could be > > addressed by them for gcc 4.6 (as they are still in stage 1 for a few more weeks). > Well, that bug is in bugzilla since gcc

After almost 40 hours of work and testing over 6 computers I have finally figured out the answer to my problem of Roaming profiles not updating. This has occurred with SAMBA versions 2.2.* and later up through and including 3.0.2a (completely clean install in each case, including rebuilding domain, users and groups and smb.conf from scratch). It does not appear to be a SAMBA issue but one

According to comment in tree-nested.c, these frames should be only introduced in case of debug or OpenMP lowering: /* A subroutine of convert_nonlocal_reference_op. Create a local variable in the nested function with DECL_VALUE_EXPR set to reference the true variable in the parent function. This is used both for debug info and in OpenMP lowering. */ However, in this code example we

Hi Duncan, A DragonEgg/GCC-related question: do you know where these strange FRAME tokens originate from (e.g. %struct.FRAME.matmul)? Compiling simple Fortran code with DragonEgg: > cat matmul.f90 subroutine matmul(nx, ny, nz) implicit none integer :: nx, ny, nz real, dimension(nx, ny) :: A real, dimension(ny, nz) :: B real, dimension(nx, nz) :: C integer :: i, j, k real,

Hi Nick, > Since I'm busy muddying the waters by changing how exception handling > works, I thought I should ask for clarification on the exact behaviour > of the current 'nounwind' attribute found on functions, calls and invokes. > > I was thinking these would be similar to the AA analysis notes like > "doesNotAccessMemory" which is a provable property

On Sun, Jul 21, 2013 at 5:56 PM, Andrew Trick <atrick at apple.com> wrote: > Does 'nounwind' have semantics that inform optimization passes? It seems to in some cases, but not consistently. For example... > > int32_t foo(int32_t* ptr) { > int i = 0; > int result; > do { > bar(ptr); > result = *ptr; > bar(ptr); > } while (i++ <

Hi Eli, On 22/07/13 03:37, Eli Friedman wrote: > On Sun, Jul 21, 2013 at 5:56 PM, Andrew Trick <atrick at apple.com> wrote: >> Does 'nounwind' have semantics that inform optimization passes? It seems to in some cases, but not consistently. For example... >> >> int32_t foo(int32_t* ptr) { >> int i = 0; >> int result; >> do { >>

On Thu, Feb 9, 2017 at 8:41 AM, Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Wed, Feb 8, 2017 at 5:45 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: >> >> What isn’t clear to me still is : why shouldn't this be transitive? >> In the example you’re showing, for a caller of f() in bar, what is the >> advantage of knowing that f()