Re: Array of pointers to global data
On Fri, Feb 1, 2013 at 5:03 AM, Matt Davis wrote:
> Hello,
> I have a routine that creates a local array containing pointers to
> global data. At runtime, when this array is passed to a function, I
> do not see the pointers to the global objects. The GIMPLE does show
> that the array is declared with the addresses of the globals as the
> elements to the array, and that looks fine to me. But at runtime,
> when this array is passed to a callee function, the callee receives
> the array, but its contents are not the addresses of the globals.
>
> After looking at the corresponding assembly, this makes sense, as I do
> not see the assembly building the array before it passes the array to
> the callee. I do not see the asm code assigning the elements of the
> array to be that of the global pointers. I suppose there is a flag I
> need to set? If not, I suppose I can always build the array as a
> series of assignments.
>
> Here is how I build the local array. Note, if I build this array as a
> global with static-linkage, then everything works fine:
>
> tree create_array(const region_t reg, gimple stmt)
> {
> unsigned i, n_elts;
> const type_info_t *ti;
> tree type, unique, decl;
> VEC(constructor_elt,gc) *entries = NULL;
>
> n_elts = VEC_length(tree, reg->unique_types);
> type = build_array_type_nelts(ptr_type_node, n_elts);
>
> FOR_EACH_VEC_ELT(tree, reg->unique_types, i, unique)
> {
> ti = get_type_info(reg, unique);
> CONSTRUCTOR_APPEND_ELT(
> entries, NULL, build1(ADDR_EXPR, ptr_type_node, ti->decl));
> }
>
> decl = create_tmp_var(type, "testarray");
> DECL_INITIAL(decl) = build_constructor(type, entries);
>
> return decl;
> }
>
> Do I have to explicitly create assignment statements for each element,
> since my array is local? As I mention above, if I make my array
> global, everything is fine.
Locals with DECL_INITIAL need to be lowered in GIMPLE to make the
initialization explicit. What you can do is output the constructor as
constant (supposed all elements are constant) using tree_output_constant_def.
See how gimplification handles initializers of locals.
Richard.
> -Matt
ADA runtime System.Address type
Hi, I'm working on a gcc/gnat port for a private target (gcc 4.5.2, gnat 6.4.2). On this target, scalar values shall be stored in $R registers whereas pointer values shall be stored in $C registers. My current ABI for procedure/function calls uses $R and $C registers depending on arguments and return values type (scalar or pointer). I need an ABI of this kind for performance reasons (the instruction set does not allow $R and $C everywhere and copying $R in $C for each procedure calls is too expensive). I tested this ABI through GCC C and C++ torture suite and everything is ok (after solving special cases for implicit calls) During my tests I tried to mix ADA and C sources code using the 'pragma import/export'. For example I tried to implement the "__gnat_malloc" expected by the ZFP runtime by an ADA function and 'pragma export' : function Gnat_Malloc (Size : in Integer) return System.Address is begin -- implementation end Gnat_Malloc; pragma Export (C, Gnat_Malloc, "__gnat_malloc"); Here is my problem : * the caller of __gnat_malloc expects that return value of type pointer to be in a $C register (as defined in the ABI) * the called function Gnat_Malloc return a value of type system.address in $R register because system.address is considered as a scalar value (system.ads: type Address is mod Memory_Size;) ==> caller and callee return values doesn't match, the ABI is broken I tried to modified system.ads so that system.address arguments become pointers (using access keyword) but I can't figure out how to do this because the System package is 'pragma Pure' ... Is there a way to modify something somewhere (runtime, backend, frontend ...) so that arguments of type system.address are seen as pointers and not scalar values ? Regards, Selim Belbachir
Re: ADA runtime System.Address type
BELBACHIR Selim writes: > Hi, > > I'm working on a gcc/gnat port for a private target (gcc 4.5.2, gnat 6.4.2). > On this target, scalar values shall be stored in $R registers whereas > pointer values shall be stored in $C registers. My current ABI for > procedure/function calls uses $R and $C registers depending on arguments and > return values type (scalar or pointer). I need an ABI of this kind for > performance reasons (the instruction set does not allow $R and $C everywhere > and copying $R in $C for each procedure calls is too expensive). > > I tested this ABI through GCC C and C++ torture suite and everything is ok > (after solving special cases for implicit calls) > > During my tests I tried to mix ADA and C sources code using the 'pragma > import/export'. For example I tried to implement the "__gnat_malloc" > expected by the ZFP runtime by an ADA function and 'pragma export' : > > function Gnat_Malloc (Size : in Integer) return System.Address is > begin > -- implementation > end Gnat_Malloc; > pragma Export (C, Gnat_Malloc, "__gnat_malloc"); > > Here is my problem : > * the caller of __gnat_malloc expects that return value of type pointer to > be in a $C register (as defined in the ABI) > * the called function Gnat_Malloc return a value of type system.address in > $R register because system.address is considered as a scalar value > (system.ads: type Address is mod Memory_Size;) > ==> caller and callee return values doesn't match, the ABI is broken > > I tried to modified system.ads so that system.address arguments become > pointers (using access keyword) but I can't figure out how to do this > because the System package is 'pragma Pure' ... > > Is there a way to modify something somewhere (runtime, backend, frontend > ...) so that arguments of type system.address are seen as pointers and not > scalar values ? This is a known issue, m68k-linux has the exact same problem with its A(ddress) and D(ata) registers. See PR48835 for discussion and patches. With those patches people are successfully building and using GCC's Ada on m68k-linux.
Re: System V Application Binary Interface 0.99.5
On 02/01/2013 12:38 AM, Jan Hubicka wrote: > Doing the extensions at caller side always is however IMO a preformance bug in > GCC. We can definitly drop them at -Os, for non-PRS targets and for calls > within compilation unit where we know that GCC is not really producing > code like in Michael's testcase. Well we can, yeah, at the cost of breaking interworking with LLVM. Do we care? ;-) Andrew.
Re: Use-new-strlen-implementation-in-rtld
Crossposting to gcc. On Fri, Feb 01, 2013 at 08:52:48AM -0800, Richard Henderson wrote: > On 01/31/2013 04:37 AM, Ondřej Bílka wrote: > >To also use my implementation of strlen in runtime linker > >use following patch. > > > >It uses fact that xmm are call clobbered and only xmm0-xmm7 can be > >used to pass arguments so xmm8-xmm15 are available. > > FYI, on the gcc list, in the context of Cilk+, Intel have been talking > about a new calling convention for "vector" functions that would in > fact use all 16 sse registers for argument passing. > > So, please no. > And did they provide any example where it would lead to simpler code and improve performance? It would benefit only when function pass 9 and more floats/vectors functions that need this are not performance critical. A calling convention that would help it would keep arguments passed at xmm0-7 but make xmm2-7 caller save. This could be specified by fastcall attribute. This would help quite often, there is a optimization rule not to call any function when using vectors float callculations because pushing/poping them on stack easily increases cost of call by 20 cycles. > > r~
Bootstrapping process
Heya, yes I'm still here (Hope that's good) I'd like to know more about the bootstrapping phases in terms of why, how, why split it into the phases that exist, so forth but something detailed rather than a "how to" with some side-notes. Alec.
Re: Bootstrapping process
Alec Teal ha scritto: >I'd like to know more about the bootstrapping phases in terms of why, >how, why split it into the phases that exist, so forth but something >detailed rather than a "how to" with some side-notes. Just in case your are also curious about living Italian, often in such cases we jokingly reply something like: what about a slice of my ass too? Paolo
Re: Bootstrapping process
On 01/02/13 20:52, Paolo Carlini wrote: Alec Teal ha scritto: I'd like to know more about the bootstrapping phases in terms of why, how, why split it into the phases that exist, so forth but something detailed rather than a "how to" with some side-notes. Just in case your are also curious about living Italian, often in such cases we jokingly reply something like: what about a slice of my ass too? Paolo I don't follow, I would imagine there are plenty of large pdfs and reams of web-pages on moving to Italy and coping with the life-style and whatever else living like an Italian entails, and the Internet has a strong body of ass and things involving it. If you could link such documentation but about the way GCC is built, then you'd be answering my question
Re: Bootstrapping process
On Fri, Feb 01, 2013 at 08:56:43PM +, Alec Teal wrote:
>
> If you could link such documentation but about the way GCC is built,
> then you'd be answering my question
http://www.cse.iitb.ac.in/grc/ has a lot of resources & slides.
http://gcc-melt.org/docum.html has some slides notably
http://gcc-melt.org/GCC-MELT-HiPEAC2012.pdf
which might also help.
And you can find many other resources on the web too...
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Bootstrapping process
What would you search for to find more on the web? I found a lot of stack-overflow questions and guides to building GCC in my quest? Thanks for the links! Alec On 01/02/13 21:16, Basile Starynkevitch wrote: On Fri, Feb 01, 2013 at 08:56:43PM +, Alec Teal wrote: If you could link such documentation but about the way GCC is built, then you'd be answering my question http://www.cse.iitb.ac.in/grc/ has a lot of resources & slides. http://gcc-melt.org/docum.html has some slides notably http://gcc-melt.org/GCC-MELT-HiPEAC2012.pdf which might also help. And you can find many other resources on the web too... Cheers
Re: Bootstrapping process
Nevermind, http://gcc.gnu.org/onlinedocs/ this is amazing and linked to from the gcc-melt link. Thanks so much Basile! I really appreciate the reply, If you feel like replying again any more? I'm a heavy reader :) Alec On 01/02/13 21:17, Alec Teal wrote: What would you search for to find more on the web? I found a lot of stack-overflow questions and guides to building GCC in my quest? Thanks for the links! Alec On 01/02/13 21:16, Basile Starynkevitch wrote: On Fri, Feb 01, 2013 at 08:56:43PM +, Alec Teal wrote: If you could link such documentation but about the way GCC is built, then you'd be answering my question http://www.cse.iitb.ac.in/grc/ has a lot of resources & slides. http://gcc-melt.org/docum.html has some slides notably http://gcc-melt.org/GCC-MELT-HiPEAC2012.pdf which might also help. And you can find many other resources on the web too... Cheers
gcc-4.6-20130201 is now available
Snapshot gcc-4.6-20130201 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20130201/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 195679 You'll find: gcc-4.6-20130201.tar.bz2 Complete GCC MD5=2d1d88286517b5cb2c4dfd148a97 SHA1=c79fef04388f286fdccf444f609d0240037fb5aa Diffs from 4.6-20130125 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
The Linux binutils 2.23.51.0.9 is released
This is the beta release of binutils 2.23.51.0.9 for Linux, which is
based on binutils 2013 0118 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been applied and
in what order they have been applied.
Starting from the 2.21.51.0.3 release, you must remove .ctors/.dtors
section sentinels when building glibc or other C run-time libraries.
Otherwise, you will run into:
http://sourceware.org/bugzilla/show_bug.cgi?id=12343
Starting from the 2.21.51.0.2 release, BFD linker has the working LTO
plugin support. It can be used with GCC 4.5 and above. For GCC 4.5, you
need to configure GCC with --enable-gold to enable LTO plugin support.
Starting from the 2.21.51.0.2 release, binutils fully supports compressed
debug sections. However, compressed debug section isn't turned on by
default in assembler. I am planning to turn it on for x86 assembler in
the future release, which may lead to the Linux kernel bug messages like
WARNING: lib/ts_kmp.o (.zdebug_aranges): unexpected non-allocatable section.
But the resulting kernel works fine.
Starting from the 2.20.51.0.4 release, no diffs against the previous
release will be provided.
You can enable both gold and bfd ld with --enable-gold=both. Gold will
be installed as ld.gold and bfd ld will be installed as ld.bfd. By
default, ld.bfd will be installed as ld. You can use the configure
option, --enable-gold=both/gold to choose gold as the default linker,
ld. IA-32 binary and X64_64 binary tar balls are configured with
--enable-gold=both/ld --enable-plugins --enable-threads.
Starting from the 2.18.50.0.4 release, the x86 assembler no longer
accepts
fnstsw %eax
fnstsw stores 16bit into %ax and the upper 16bit of %eax is unchanged.
Please use
fnstsw %ax
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections from being
equal to VMA (virtual memory address), to keeping the difference between
LMA and VMA the same as the previous output section in the same region.
For
.data.init_task : { *(.data.init_task) }
LMA of .data.init_task section is equal to its VMA with the old linker.
With the new linker, it depends on the previous output section. You
can use
.data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) }
to ensure that LMA of .data.init_task section is always equal to its
VMA. The linker script in the older 2.6 x86-64 kernel depends on the
old behavior. You can add AT (ADDR(section)) to force LMA of
.data.init_task section equal to its VMA. It will work with both old
and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and
above is OK.
The new x86_64 assembler no longer accepts
monitor %eax,%ecx,%edx
You should use
monitor %rax,%ecx,%edx
or
monitor
which works with both old and new x86_64 assemblers. They should
generate the same opcode.
The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,
movl (%eax),%ds
movl %ds,(%eax)
To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,
mov (%eax),%ds
mov %ds,(%eax)
should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.1 will also support
movw (%eax),%ds
movw %ds,(%eax)
without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are
available at
http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch
http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch
The ia64 assembler is now defaulted to tune for Itanium 2 processors.
To build a kernel for Itanium 1 processors, you will need to add
ifeq ($(CONFIG_ITANIUM),y)
CFLAGS += -Wa,-mtune=itanium1
AFLAGS += -Wa,-mtune=itanium1
endif
to arch/ia64/Makefile in your kernel source tree.
Please report any bugs related to binutils 2.23.51.0.9 to
hjl.to...@gmail.com
and
http://www.sourceware.org/bugzilla/
Changes from binutils 2.23.51.0.8:
1. Update from binutils 2013 0118.
2. Support R_386_SIZE32, R_X86_64_SIZE32 and R_X86_64_SIZE64
relocations.
3. Fix x86 assembler for "xtrn@got -1". PR 15019.
4. Don't generate old dtags with --enable-new-dtags.
5. Add Meta support.
6. Improve gold.
7. Improve aarch64 support.
8. Improve arm support.
9. Improve cr16 support.
10. Improve mips support.
11. Improve ppc support.
12. Improve v850 support.
13. Improve xgate support.
Changes from binutils 2.23.51.0.7:
1. Properly adjust h->plt.refcount. PR 14980.
Changes from binutils 2.23.51.0.6:
1. Update from binutils 2012 1218.
2. Add missing R_*_IRELATIVE relocations. PR 14968.
3. Remove unnecessary R_*_NONE relocations. PR 14956.
4. Fix ar/ranlib on 32-bit filesystems. PR 14933.
5. Fix a
Re: Bootstrapping process
On 1 February 2013 21:27, Alec Teal wrote: > Nevermind, http://gcc.gnu.org/onlinedocs/ this is amazing and linked to from > the gcc-melt link. And linked to from the GCC home page ... I kinda assumed when asking for something to read you'd looked at the GCC web pages already. If you say what you've read and what you're looking for it might help, otherwise we can't know if the existing docs on the home page are relevant or if telling you to read them first then come back is patronising.
Re: Bootstrapping process
I prefer books or large bodies of text, not notes and how Tom's I. Wiki pages Jonathan Wakely wrote: >On 1 February 2013 21:27, Alec Teal wrote: >> Nevermind, http://gcc.gnu.org/onlinedocs/ this is amazing and linked to from >> the gcc-melt link. > >And linked to from the GCC home page ... I kinda assumed when asking >for something to read you'd looked at the GCC web pages already. > >If you say what you've read and what you're looking for it might help, >otherwise we can't know if the existing docs on the home page are >relevant or if telling you to read them first then come back is >patronising. >
Re: Array of pointers to global data
Thanks Ian, Richard.
I have some modified code which seems to be along the same lines as
what you all suggested. However, I am still having troubles. Mainly,
I see the array in the callee but the contents are still empty, and I
verified by looking at the asm dump of the resulting code.
On Fri, Feb 1, 2013 at 8:09 PM, Richard Biener
wrote:
> On Fri, Feb 1, 2013 at 5:03 AM, Matt Davis wrote:
>> Hello,
>> I have a routine that creates a local array containing pointers to
>> global data. At runtime, when this array is passed to a function, I
>> do not see the pointers to the global objects. The GIMPLE does show
>> that the array is declared with the addresses of the globals as the
>> elements to the array, and that looks fine to me. But at runtime,
>> when this array is passed to a callee function, the callee receives
>> the array, but its contents are not the addresses of the globals.
>>
>> After looking at the corresponding assembly, this makes sense, as I do
>> not see the assembly building the array before it passes the array to
>> the callee. I do not see the asm code assigning the elements of the
>> array to be that of the global pointers. I suppose there is a flag I
>> need to set? If not, I suppose I can always build the array as a
>> series of assignments.
>>
>> Here is how I build the local array. Note, if I build this array as a
>> global with static-linkage, then everything works fine:
>>
>> tree create_array(const region_t reg, gimple stmt)
>> {
>> unsigned i, n_elts;
>> const type_info_t *ti;
>> tree type, unique, decl;
>> VEC(constructor_elt,gc) *entries = NULL;
>>
>> n_elts = VEC_length(tree, reg->unique_types);
>> type = build_array_type_nelts(ptr_type_node, n_elts);
>>
>> FOR_EACH_VEC_ELT(tree, reg->unique_types, i, unique)
>> {
>> ti = get_type_info(reg, unique);
>> CONSTRUCTOR_APPEND_ELT(
>> entries, NULL, build1(ADDR_EXPR, ptr_type_node, ti->decl));
>> }
>>
>> decl = create_tmp_var(type, "testarray");
>> DECL_INITIAL(decl) = build_constructor(type, entries);
>>
>> return decl;
>> }
>>
>> Do I have to explicitly create assignment statements for each element,
>> since my array is local? As I mention above, if I make my array
>> global, everything is fine.
>
> Locals with DECL_INITIAL need to be lowered in GIMPLE to make the
> initialization explicit. What you can do is output the constructor as
> constant (supposed all elements are constant) using tree_output_constant_def.
> See how gimplification handles initializers of locals.
I did look through the gimplification stuff. And I added a
"tree_output_constant_def" on my DECL_INITIAL as suggested by Richard.
As Ian suggested, I created a DECL_EXPR for this array that I am generating.
The new code is the following:
/* Build the constructor for the array */
FOR_EACH_VEC_ELT(tree, reg->unique_types, i, unique)
{
ti = get_type_info(reg, unique);
CONSTRUCTOR_APPEND_ELT(
entries, NULL, build1(ADDR_EXPR, ptr_type_node, ti->decl));
}
/* Create the VAR_DECL for the array, set the constructor and force it to
* be generated at local scope.
*/
decl = create_tmp_var(type, "testarray");
DECL_INITIAL(decl) =
tree_output_constant_def(build_constructor(type, entries));
return build1_loc(gimple_location(stmt), DECL_EXPR, type, decl);
I use the DECL_EXPR_DECL() of the returned value as I would have
normally used 'decl' in my previous listing. Looking at the gimple
dump and assembly, I see the gimple code now containing a pointer to
a label for the declaration (thanks to tree_output_constant_def). In
the resulting asm, I do not see this label anywhere.
-Matt
Las Nuevas Reformas Laborales 2012
Las Nuevas Reformas Laborales 2012 y su Impacto en las Empresas ¿Dónde se llevará a cabo? Lugar: Su computadora. Fecha: 26 de Febrero de 2013. Duración: 6 Horas. Horario: De 10:00 a.m a 1:00 p.m. y de 3:00 p.m a 6:00 p.m. (Hora del Centro de México). Como profesional de Recursos Humanos, la cantidad de asuntos legales que usted debe tener en cuenta puede ser abrumadora, especialmente si se toma en consideración la naturaleza litigante de nuestra sociedad y las numerosas variaciones a la Ley Federal del Trabajo con las Nuevas Reformas. Asista y aprenda cómo implementar las mejores prácticas para proteger los intereses de la compañía y los trabajadores de manera justa y legal. Este evento, le ayudará a ganar la confianza y experiencia en el manejo de situaciones concernientes a las NUEVAS REFORMAS A LA LEY FEDERAL DEL TRABAJO y a las relaciones con los empleados. Adquiera el folleto completo y sin compromiso, sólo responda este correo con los siguientes datos: Nombre(imprescindible) : Empresa : Teléfonos (imprescindible): E-mail: g...@gnu.org o Comuníquese a nuestro Centro Nacional de Atencion Telefonica: 01 - 800 - 212 - 9393 Reciba un muy cordial saludo! Lic. Areliz Massanges. Líder de Proyectos Para darte de baja y no recibir ningún tema de nuestra empresa, envíe un correo con asunto Nomasinfo
