similar to: [PATCH/RFC] gcc warnings of void * arithmetic

Use devm_platform_ioremap_resource() to simplify code. Signed-off-by: Yangtao Li <tiny.windzz at gmail.com> --- drivers/iommu/omap-iommu.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c index be551cc34be4..297c1be7ecb0 100644 --- a/drivers/iommu/omap-iommu.c +++ b/drivers/iommu/omap-iommu.c @@ -1175,7 +1175,6

Use devm_platform_ioremap_resource() to simplify code. Signed-off-by: Yangtao Li <tiny.windzz at gmail.com> --- drivers/iommu/omap-iommu.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c index be551cc34be4..297c1be7ecb0 100644 --- a/drivers/iommu/omap-iommu.c +++ b/drivers/iommu/omap-iommu.c @@ -1175,7 +1175,6

Hi, We have a number of HP PC's which were refusing to netboot both floppy and hard disk images with memdisk. Testing the problem under DOS for simplicity, the cause was because the INT 13 AH=0 Disk Reset function call is passed on to the BIOS by memdisk, and it appears that AMI's BIOS (V2.00) returns with the carry set flag if there are no (physical) disks present. This causes a failure

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

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

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

Dear LLVM, 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? I'm expecting something like "call void @_gfortran_flush_i4(i8* null)". Otherwise, we will need to teach our call parsers to digg

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) > { >

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

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 =

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

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,

There is an design problem with the qdisc interface that causes qlen related bugs in netem, tbf, and other qdisc''s that peek at the top of the queue. The problem is that requeue needs to be called from the dequeue function but requeue can fail. If requeue fails, then the calling qdisc can not properly handle the error. If it returns NULL, then the parent''s expectation about qlen

An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.linux-foundation.org/pipermail/virtualization/attachments/20080423/f5baa8b7/attachment.txt

Hey all, I have the MTGO3 game loader running till 34% and then it shows this error. not implemented at System.Drawing:void AddFontFile(System.String) any workarounds yet to get passed this? cheers Pete

An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.linux-foundation.org/pipermail/virtualization/attachments/20080423/f5baa8b7/attachment.txt