search for: architectures

Hallo, Matt, Du meintest am 25.06.13: [compiling syslinux-6.00] >> Thanks - now it crashes later ... > What crash are you seeing? ------------- cite on ------------- [...] gcc -Wp,-MT,abort.o,-MD,./.abort.o.d -Os -march=x86-64 -falign- functions=0 -falign-jumps=0 -falign-labels=0 -ffast-math -fomit-frame- pointer -std=gnu99 -fno-stack-protector -fwrapv -freg-struct-return -

On Tue, 25 Jun, at 01:52:00PM, Helmut Hullen wrote: > Thanks - now it crashes later ... What crash are you seeing? > I don't have the ia64 files which are needed for a complete binary. But > maybe that's only my special problem. You shouldn't need ia64 files to build ia32 and x86-64 versions of gnu-efi or Syslinux. -- Matt Fleming, Intel Open Source Technology Center

What are the current limitations of using -O4 in llvm-gcc-4.2? As a first test, I compiled the molscript program first as -O3 and it works fine. However if i try to compile the same code as -O4, the build fails with... ar -cru clib.a args.o str_utils.o dynstring.o err.o indent.o vector3.o matrix3.o quaternion.o body3d.o extent3d.o io_utils.o colour.o key_value.o named_data.o double_hash.o

We recently fixed the hardwaremodel and architecture facts on Windows as they were always returning i386[1]. The change will be in the upcoming 1.6.10 release of Facter[2]. The new behavior is that hardwaremodel will return something like i686, ia64, x64, etc, while the architecture fact will return either x86 or x64. Since the new behavior will likely affect puppet users that are trying to write

hello list!! I have developed a custom apache module for my company that setups up our own particular config of httpd and php in order to run our sites.. However, there is one wrinkle. It take two puppet runs to start the httpd service with this module and we''d like to get that down to one run! The reason seems to be that we have our own custom ssl vhost conf that we use called

...-r mode. So, where the check is done to see that the arch is correct, may actually cause the architecture in the LinkingContext to be set. For lld, I think the flavor also would need to be inferred from the first object, isnt it ? > > * mach-o also has “fat” files which can contain multiple architectures. So, the reader needs to know the arch to even try to parse. In other words, if the Reader is told the intended arch, the Reader could error out if the file is not of that arch (and for mach-o the Reader would select the right slice in a fat file). Since all of the code ends up within the parseFi...

...t, may actually cause the >>> architecture in the LinkingContext to be set. >>> >> For lld, I think the flavor also would need to be inferred from the first >> object, isnt it ? >> >>> >>> * mach-o also has “fat” files which can contain multiple architectures. >>> So, the reader needs to know the arch to even try to parse. In other >>> words, if the Reader is told the intended arch, the Reader could error out >>> if the file is not of that arch (and for mach-o the Reader would select the >>> right slice in a fat fil...

I've looked through the code for sys_mmap2 on several architectures, and it looks like some architectures plays by the "shift is always 12" rule, e.g. SPARC, and some expect userspace to actually obtain the page size, e.g. PowerPC and MIPS. On some architectures, e.g. x86 and ARM, the point is moot since PAGE_SIZE is always 2^12. a. Is this correc...

...the components required for JIT (core, mcjit, native, etc.) can be cross-compiled and linked with an Intel or IBM compiler for such an architecture, and somehow one manages to execute the application. (I didn't try all that yet.) Also, let's assume there is some codegen support for these architectures (which I understand there is). It might not be complete, but it might also be enough for my application (only floating-point and integer arithmetic, loads/stores). What JIT-related features are definitely not there (yet) and would be needed to make MCJIT actually work such these architectures?...

...ack to "default": /mybootdir/pxelinux.cfg/b8945908-d6a6-41a9-611d-74a6ab80b83d /mybootdir/pxelinux.cfg/01-88-99-aa-bb-cc-dd /mybootdir/pxelinux.cfg/C000025B [...] /mybootdir/pxelinux.cfg/C /mybootdir/pxelinux.cfg/default When serving PXE config files to machines of different architectures (requiring separate boot images and config files), this means we cannot use the autodisovery mechanism without having prior knowledge of a MAC/IP/uuid-to-architecture mapping. This change introduces an additional step to the autodiscovery process, using a name based on the client machine architect...

Using -O4 requires support from the system linker, because the files written out are LLVM bitcode files rather than object files. --Owen On Dec 29, 2007, at 11:43 AM, Jack Howarth wrote: > What are the current limitations of using -O4 in > llvm-gcc-4.2? As a first test, I compiled the molscript > program first as -O3 and it works fine. However if i > try to compile the same code

...stead the linker infers the architecture by looking at the first object file. This is mostly used in -r mode. So, where the check is done to see that the arch is correct, may actually cause the architecture in the LinkingContext to be set. * mach-o also has “fat” files which can contain multiple architectures. So, the reader needs to know the arch to even try to parse. In other words, if the Reader is told the intended arch, the Reader could error out if the file is not of that arch (and for mach-o the Reader would select the right slice in a fat file). -Nick

Are there any RPM wizards out there that know how to specify a different architecture for a subpackage in a spec file? I have a package that has a binary component and a non-binary component that I would like split into 2 packages one, the binary which is architecture dependant and the other 'noarch'. I haven't found a spec file that does this yet :-( Ross S. W. Walker

Hi Ben, At XDC you asked about the architecture field in NV_PMC_BOOT_0, and how to correctly determine the GPU architecture. It looks like Nouveau is getting the architecture from bits 20-27 in NV_PMC_BOOT_0 (though masking off bits 20-23). For >= NV10, the architecture field in NV_PMC_BOOT_0 is bits 24-28. E.g., the GK2xx architecture has architecture value 0x10, while GK11x has value 0xF

I've been working on getting the LLVM OpenMP library to build smoothly alongside llvm/clang using CMake, but one problem I'm having is determining exactly which CMake option designates the architecture the compiler will compile. I see LLVM_TARGET_ARCH, LLVM_TARGETS_TO_BUILD, LLVM_DEFAULT_TARGET_TRIPLE, etc. I thought I should just ask which one designates the architecture the compiler

Hi Gene, >> What I'm looking to do here is establish a bit of a convention for >> allowing machines of multiple architectures to be perform PXE >> configuration in a uniform way (in this case, without requiring the DHCP >> server to send out different lease parameters in response to the >> client's DHCP architecture ID). > > How do you have multiple architectures booting from the same director...

...architecture as part of 2009's Google Summer of Code program. TPA processor is a new architecture that offers the possibility of high instruction-level parallelism with energy efficiency. TPA architecture partitions the work between the compiler and the hardware differently from RISC and CISC architectures. TPA architecture has three different features that require new complier support. First, the compiler is responsible for partitioning the program into a sequence of structured blocks, which logically execute atomically. Secondly, the compiler should encode instruction dependences explicitly, elimin...

...+224,9 @@ let parse_cmdline () = let ditto = " -\"-" in let argspec = Arg.align [ + "--allow-foreign-arch-ops", Arg.Set allow_foreign_arch_ops, + " " ^ s_"Allow executing commands even on non-native output architectures"; + "--arch", Arg.Set_string arch, "arch" ^ " " ^ s_"Set the output architecture"; "--attach", Arg.String attach_disk, "iso" ^ " " ^ s_"Attach data disk/ISO during install"; "--attach...

Our architecture(TCE) can have LOTS of registers. It seems r152019 changed some register bookkeeping data structures to 8-bit. This broke support for architectures with >255 registers. Please revert this change or make those register-related values at least 16 bits wide.

...re of files that are being > read. We could very well be passed in a hexagon input file while the target > specified was x86_64. we got to reject the input file as the user has chosen > the architecture to be x86_64. Moreover, inside MIPS architecture there are some incompatible "sub-architectures". It would be nice if we can check input files and reject incorrect combinations. -- Simon Atanasyan