[Bug ada/20515] "stdcall" imports are not handled correctly
--- Additional Comments From p dot obry at wanadoo dot fr 2005-06-27 18:50 --- Danny, (In reply to comment #10) > The patch that was committed to fix this is wrong. > > #ifdef TARGET_DLLIMPORT_DECL_ATTRIBUTES is always true. It is defined to 0 > for > non-dll targets in defaults.h. I see! Would #if instead of #ifdef fix the problem. I'm not a cross expert, so this is why I got this wrong. > Why not make this a runtime switch as suggested earlier, rather than a > preprocessor switch? Maybe it is better to have this checked statically if possible. What do you think ? Pascal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20515
[Bug ada/20515] "stdcall" imports are not handled correctly
--- Additional Comments From dannysmith at users dot sourceforge dot net 2005-06-25 12:20 --- The patch that was committed to fix this is wrong. #ifdef TARGET_DLLIMPORT_DECL_ATTRIBUTES is always true. It is defined to 0 for non-dll targets in defaults.h. Why not make this a runtime switch as suggested earlier, rather than a preprocessor switch? Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20515
[Bug ada/20515] "stdcall" imports are not handled correctly
--- Additional Comments From charlet at gcc dot gnu dot org 2005-06-16 09:11 --- Fixed on mainline. Arno -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20515
[Bug ada/20515] "stdcall" imports are not handled correctly
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-16 08:57 --- Subject: Bug 20515 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-16 08:56:49 Modified files: gcc/ada: gigi.h trans.c decl.c Log message: 2005-06-10 Eric Botcazou <[EMAIL PROTECTED]> Olivier Hainque <[EMAIL PROTECTED]> Richard Kenner <[EMAIL PROTECTED]> Pascal Obry <[EMAIL PROTECTED]> * gigi.h: (build_allocator): Add arg IGNORE_INIT_TYPE. * trans.c (call_to_gnu): Issue a warning for users of Starlet when making a temporary around a procedure call because of non-addressable actual parameter. (process_freeze_entity): If entity is a private type, capture size information that may have been computed for the full view. (tree_transform, case N_Allocator): If have initializing expression, check type for Has_Constrained_Partial_View and pass that to build_allocator. (tree_transform, case N_Return_Statement): Pass extra arg to build_allocator. * decl.c (annotate_value): Remove early return if -gnatR is not specified. (gnat_to_gnu_field): Don't make a packable type for a component clause if the position is byte aligned, the field is aliased, and the clause size isn't a multiple of the packable alignment. It serves no useful purpose packing-wise and would be rejected later on. (gnat_to_gnu_entity, case object): Pass extra arg to build_allocator. PR ada/20515 (gnat_to_gnu_entity): Remove use of macro _WIN32 which is wrong in the context of cross compilers. We use TARGET_DLLIMPORT_DECL_ATTRIBUTES instead. (create_concat_name): Idem. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/gigi.h.diff?cvsroot=gcc&r1=1.35&r2=1.36 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/trans.c.diff?cvsroot=gcc&r1=1.97&r2=1.98 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/decl.c.diff?cvsroot=gcc&r1=1.71&r2=1.72 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20515
[Bug ada/20515] "stdcall" imports are not handled correctly
--- Additional Comments From dannysmith at users dot sourceforge dot net 2005-04-07 08:29 --- "So, what about the proposal on #4 ?" OK with me. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20515
[Bug ada/20515] "stdcall" imports are not handled correctly
--- Additional Comments From p dot obry at wanadoo dot fr 2005-04-06 18:14 --- (In reply to comment #5) Ok, the documentation is missing the part where Stdcall is equivalent to C on UNIX. This is a feature implemented some time ago. Will fix the doc. So, what about the proposal on #4 ? Pascal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20515
[Bug ada/20515] "stdcall" imports are not handled correctly
--- Additional Comments From dannysmith at users dot sourceforge dot net 2005-03-19 20:54 --- In reply to comment #3 >From gnat_ugn.texi: @findex Stdcall @cindex Convention Stdcall @item Stdcall This is relevant only to NT/Win95 implementations of GNAT, and specifies that the Stdcall calling sequence will be used, as defined by the NT API. In all other languages "stdcall" also applies to all i386 targets, although the symbol decoration part is specific to windows Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20515
[Bug ada/20515] "stdcall" imports are not handled correctly
--- Additional Comments From p dot obry at wanadoo dot fr 2005-03-19 14:52 --- I had a closer look. In GCC 3.4.x we have TARGET_IS_PE_COFF. So changing _WIN32 by TARGET_IS_PE_COFF is ok. In GCC 4.x we have: #define TARGET_DLLIMPORT_DECL_ATTRIBUTES 1 So instead of using TARGET_IS_PE_COFF we can use TARGET_DLLIMPORT_DECL_ATTRIBUTES. So I propose to keep the #ifdef as it is today and use TARGET_IS_PE_COFF on 3.4 and TARGET_DLLIMPORT_DECL_ATTRIBUTES on 4.0. Does this looks fine to you Danny ? Pascal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20515
[Bug ada/20515] "stdcall" imports are not handled correctly
--- Additional Comments From p dot obry at wanadoo dot fr 2005-03-19 13:08
---
(In reply to comment #2)
> The IS_TARGET_PE_COFF hack works on 3.4.x bit won't on trunk.
>
> Here is a cleaner patch against trunk that replaces the preprocessor tests
> with runtime tests. I have tested with nativr mingw bootstrap but not with
> cross-compile build.
The first part of the patch is not correct. On UNIX machines, we want the
Stdcall calling convention applied to a function or procedure be equivalent
to a C calling convention. The first part of the pacth break that.
> Index: ada/decl.c
> ===
> RCS file: /cvs/gcc/gcc/gcc/ada/decl.c,v
> retrieving revision 1.65
> diff -c -3 -p -r1.65 decl.c
> *** ada/decl.c10 Feb 2005 13:53:20 - 1.65
> --- ada/decl.c18 Mar 2005 04:15:54 -
> *** gnat_to_gnu_entity (Entity_Id gnat_entit
> *** 3642,3648
> if (list_length (gnu_return_list) == 1)
> gnu_return_type = TREE_TYPE (TREE_PURPOSE (gnu_return_list));
>
> - #ifdef _WIN32
> if (Convention (gnat_entity) == Convention_Stdcall)
> {
> struct attrib *attr
> --- 3642,3647
The other part looks fine to me.
Pascal.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20515
[Bug ada/20515] "stdcall" imports are not handled correctly
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-03-18 04:23 ---
The IS_TARGET_PE_COFF hack works on 3.4.x bit won't on trunk.
Here is a cleaner patch against trunk that replaces the preprocessor tests
with runtime tests. I have tested with nativr mingw bootstrap but not with
cross-compile build.
* decl. c (gnat_to_gnu_entity): Remove unnecessary _WIN32
preprocessor guard.
(create_concat_name): Replace _WIN32 preprocessor guard
with runtime chcek on TARGET_DLLIMPORT_DECL_ATTRIBUTES.
Index: ada/decl.c
===
RCS file: /cvs/gcc/gcc/gcc/ada/decl.c,v
retrieving revision 1.65
diff -c -3 -p -r1.65 decl.c
*** ada/decl.c 10 Feb 2005 13:53:20 - 1.65
--- ada/decl.c 18 Mar 2005 04:15:54 -
*** gnat_to_gnu_entity (Entity_Id gnat_entit
*** 3642,3648
if (list_length (gnu_return_list) == 1)
gnu_return_type = TREE_TYPE (TREE_PURPOSE (gnu_return_list));
- #ifdef _WIN32
if (Convention (gnat_entity) == Convention_Stdcall)
{
struct attrib *attr
--- 3642,3647
*** gnat_to_gnu_entity (Entity_Id gnat_entit
*** 3655,3661
attr->error_point = gnat_entity;
attr_list = attr;
}
- #endif
/* Both lists ware built in reverse. */
gnu_param_list = nreverse (gnu_param_list);
--- 3654,3659
*** create_concat_name (Entity_Id gnat_entit
*** 6576,6602
Get_External_Name_With_Suffix (gnat_entity, fp);
- #ifdef _WIN32
/* A variable using the Stdcall convention (meaning we are running
on a Windows box) live in a DLL. Here we adjust its name to use
the jump-table, the _imp__NAME contains the address for the NAME
variable. */
! {
! Entity_Kind kind = Ekind (gnat_entity);
! const char *prefix = "_imp__";
! int plen = strlen (prefix);
!
! if ((kind == E_Variable || kind == E_Constant)
! && Convention (gnat_entity) == Convention_Stdcall)
! {
! int k;
! for (k = 0; k <= Name_Len; k++)
! Name_Buffer [Name_Len - k + plen] = Name_Buffer [Name_Len - k];
! strncpy (Name_Buffer, prefix, plen);
! }
! }
! #endif
!
return get_identifier (Name_Buffer);
}
--- 6574,6596
Get_External_Name_With_Suffix (gnat_entity, fp);
/* A variable using the Stdcall convention (meaning we are running
on a Windows box) live in a DLL. Here we adjust its name to use
the jump-table, the _imp__NAME contains the address for the NAME
variable. */
! if (TARGET_DLLIMPORT_DECL_ATTRIBUTES
! && (Ekind (gnat_entity) == E_Variable
! || Ekind (gnat_entity) == E_Constant)
! && Convention (gnat_entity) == Convention_Stdcall)
! {
! const char *prefix = "_imp__";
! int plen = strlen (prefix);
! int k;
! for (k = 0; k <= Name_Len; k++)
! Name_Buffer [Name_Len - k + plen] = Name_Buffer [Name_Len - k];
! strncpy (Name_Buffer, prefix, plen);
! }
!
return get_identifier (Name_Buffer);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20515
[Bug ada/20515] "stdcall" imports are not handled correctly
-- What|Removed |Added CC||dannysmith at users dot ||sourceforge dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20515
[Bug ada/20515] "stdcall" imports are not handled correctly
--- Additional Comments From charlet at adacore dot com 2005-03-17 09:58 --- Subject: Re: New: "stdcall" imports are not handled correctly Patch looks correct (certainly better) to me, investigating. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20515
