similar to: Alpha compile warning

An ext3 patch against linux 2.4.10 is at http://www.uow.edu.au/~andrewm/linux/ext3/ This patch is *lightly tested* - ie, it boots and does stuff. The changes to ext3 are small, but the kernel which it patches has recently changed a lot. If you're cautious, please wait a couple of days. The patch retains the buffer-tracing code. This will soon be broken out into a separate patch to make

Well I decided that 2am on a thursday night would be a good time to try this and I've hit a wall... most of the other errors were pretty easy to fix. I just don't understand this one: --snip--snip--snip-- gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -D__linux__ -pipe -fno-strength-reduce

Right now I'm building a 2.4.17 kernel on an HPPA Linux system. The kernel it ships with supports ext2 only. Has anybody tried ext3 on HPPA? -- Ralf Hildebrandt (Im Auftrag des Referat V A) Ralf.Hildebrandt@charite.de Charite Campus Virchow-Klinikum Tel. +49 (0)30-450 570-155 Referat V A - Kommunikationsnetze - Fax. +49 (0)30-450 570-916 "A man who

I'm adding support for -ffixed-<reg> <http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Code-Gen-Options.html#index-ffixed-1435> for Hexagon and was wondering if I should do it in such a way that other targets get the support as well by default or if a given target back-end should have to explicitly opt-in for support. Any opinions? Matthew Curtis. -- Qualcomm Innovation Center,

Thank you for your reply Eli, I too was working with Carey on this feature, so please let me reply. On 12/21/18 8:05 PM, Friedman, Eli via llvm-dev wrote: > As a side-note, you might want to check that prologue/epilogue emission won't emit a PUSH/POP that refers to a register reserved this way; we sometimes add an "extra" register to align the stack. Yes, you are right.

On 10/2/2012 9:36 AM, 陳韋任 (Wei-Ren Chen) wrote: > On Tue, Oct 02, 2012 at 09:23:27AM -0500, Matthew Curtis wrote: >> I'm adding support for -ffixed-<reg> for Hexagon and was wondering if I should >> do it in such a way that other targets get the support as well by default or if >> a given target back-end should have to explicitly opt-in for support. > What

On Tue, Oct 02, 2012 at 09:23:27AM -0500, Matthew Curtis wrote: > I'm adding support for -ffixed-<reg> for Hexagon and was wondering if I should > do it in such a way that other targets get the support as well by default or if > a given target back-end should have to explicitly opt-in for support. What "-ffixed-<reg>" does? Regards, chenwj -- Wei-Ren Chen

On Oct 2, 2012, at 7:23 AM, Matthew Curtis <mcurtis at codeaurora.org> wrote: > I'm adding support for -ffixed-<reg> for Hexagon and was wondering if I should do it in such a way that other targets get the support as well by default or if a given target back-end should have to explicitly opt-in for support. It would be great to have this as a target-indepentent (well, obviously

Hi Chris, > From the design perspective, I think it would make sense to represent this in > LLVM IR with named metadata (http://llvm.org/docs/LangRef.html# > namedmetadatastructure) like "!llvm.fixedregs". This could then be picked up > by the code generator, installed as preallocated registers (Jakob would be the > one to ask how best to do this). -ffixed-<reg>

Hi all, This is a RFC on support for Global Register Variables in the Arm backend. Whilst there has been some prior discussion about whether or not LLVM should (or even needs to) support global register variables, today there seems to be a good measure of support for this in both Clang+LLVM (although it is currently limited to SP). When most of this support landed there was some concern

On Oct 30, 2008, at 11:02 PM, Chris Lattner wrote: > On Oct 30, 2008, at 5:23 PM, Jack Howarth wrote: >> ps We do have one oddity left in llvm-gfortran from current llvm >> svn. I find everytime I compile something with llvm-gfortran that >> I get a series of warning messages... >> >> f951: warning: command line option "-Wformat" is valid for C/C++/

I am trying to compile 2.4.10-ac11 w/ the ext3-2.4-0.9.12-2410ac11 patch. I'm getting unresolved symbols w/ ext3 module: cd /lib/modules/2.4.10-ac11; \ mkdir -p pcmcia; \ find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i -r ln -sf ../{} pcmcia if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.4.10-ac11; fi depmod: *** Unresolved symbols in

On Oct 30, 2008, at 5:23 PM, Jack Howarth wrote: > ps We do have one oddity left in llvm-gfortran from current llvm > svn. I find everytime I compile something with llvm-gfortran that > I get a series of warning messages... > > f951: warning: command line option "-Wformat" is valid for C/C++/ > ObjC/ObjC++ but not for Fortran > f951: warning: command line option

This patch contains the following possible cleanups: - make needlessly global functions static - journal.c: remove the unused global function __journal_internal_check and move the check to journal_init - remove the following write-only global variable: - journal.c: current_journal - remove the following unneeded EXPORT_SYMBOL's: - journal.c: journal_check_used_features -

> From the GCC manual (http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/ > Code-Gen-Options.html#index-ffixed-2267) > > -ffixed-reg > > Treat the register named reg as a fixed register; generated code should > never refer to it (except perhaps as a stack pointer, frame pointer or in > some other fixed role). > > reg must be the name of a register. The

i have error in install module of tor2. but it compile good. what happen ? ivr2:/usr/src/zaptel # make clean; make install rm -f torisatool makefw tor2fw.h rm -f zttool rm -f *.o ztcfg tzdriver sethdlc rm -f zonedata.lo tonezone.lo libtonezone.so.1.0 *.lo rm -f gendigits tones.h rm -f libtonezone* rm -f tor2ee rm -f core cc -I. -O4 -g -Wall -DBUILDING_TONEZONE -DSTANDALONE_ZAPATA -c -o

Hi, When using Wine to run Windows ARM64 executables on Linux, there's one major ABI incompatibility between the two; Windows treats the x18 register as the reserved platform register, while it is free to be clobbered anywhere in code on Linux. The Wine code sets up this register before passing control over to the Windows executable code, but whenever the Windows code calls a function

Hi I am trying to register shadow a global variable using -ffixed option in llvm-gcc. I am able to accomplish this using gcc however llvm-gcc seems to ignore this option and generate code using the register. command line: >gcc -Wall -m64 -O3 -pthread -ftls-model=initial-exec -ffixed-r12 test.c -o test >objdump -d ./test | grep r12 >llvm-gcc -Wall -m64 -O3 -pthread

On Oct 3, 2012, at 12:13 AM, 陳韋任 (Wei-Ren Chen) <chenwj at iis.sinica.edu.tw> wrote: > Hi Chris, > >> From the design perspective, I think it would make sense to represent this in >> LLVM IR with named metadata (http://llvm.org/docs/LangRef.html# >> namedmetadatastructure) like "!llvm.fixedregs". This could then be picked up >> by the code

Chris and Bill, I have tested the proposed patch from... http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-August/016490.html under i686-apple-darwin9 and it solves the problems building gfortran from llvm svn. The resulting compiler works fine so can we get that patch in before 2.4 is release? Jack ps We do have one oddity left in llvm-gfortran from current llvm svn. I find