* [Bug ada/20515] "stdcall" imports are not handled correctly
2005-03-17 9:20 [Bug ada/20515] New: "stdcall" imports are not handled correctly sbellon at sbellon dot de
@ 2005-03-17 9:58 ` charlet at adacore dot com
2005-03-18 3:30 ` dannysmith at users dot sourceforge dot net
` (10 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: charlet at adacore dot com @ 2005-03-17 9:58 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug ada/20515] "stdcall" imports are not handled correctly
2005-03-17 9:20 [Bug ada/20515] New: "stdcall" imports are not handled correctly sbellon at sbellon dot de
2005-03-17 9:58 ` [Bug ada/20515] " charlet at adacore dot com
@ 2005-03-18 3:30 ` dannysmith at users dot sourceforge dot net
2005-03-18 4:23 ` dannysmith at users dot sourceforge dot net
` (9 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: dannysmith at users dot sourceforge dot net @ 2005-03-18 3:30 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |dannysmith at users dot
| |sourceforge dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20515
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug ada/20515] "stdcall" imports are not handled correctly
2005-03-17 9:20 [Bug ada/20515] New: "stdcall" imports are not handled correctly sbellon at sbellon dot de
2005-03-17 9:58 ` [Bug ada/20515] " charlet at adacore dot com
2005-03-18 3:30 ` dannysmith at users dot sourceforge dot net
@ 2005-03-18 4:23 ` dannysmith at users dot sourceforge dot net
2005-03-19 13:08 ` p dot obry at wanadoo dot fr
` (8 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: dannysmith at users dot sourceforge dot net @ 2005-03-18 4:23 UTC (permalink / raw)
To: gcc-bugs
------- 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 -0000 1.65
--- ada/decl.c 18 Mar 2005 04:15:54 -0000
*************** 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug ada/20515] "stdcall" imports are not handled correctly
2005-03-17 9:20 [Bug ada/20515] New: "stdcall" imports are not handled correctly sbellon at sbellon dot de
` (2 preceding siblings ...)
2005-03-18 4:23 ` dannysmith at users dot sourceforge dot net
@ 2005-03-19 13:08 ` p dot obry at wanadoo dot fr
2005-03-19 14:52 ` p dot obry at wanadoo dot fr
` (7 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: p dot obry at wanadoo dot fr @ 2005-03-19 13:08 UTC (permalink / raw)
To: gcc-bugs
------- 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.c 10 Feb 2005 13:53:20 -0000 1.65
> --- ada/decl.c 18 Mar 2005 04:15:54 -0000
> *************** 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug ada/20515] "stdcall" imports are not handled correctly
2005-03-17 9:20 [Bug ada/20515] New: "stdcall" imports are not handled correctly sbellon at sbellon dot de
` (3 preceding siblings ...)
2005-03-19 13:08 ` p dot obry at wanadoo dot fr
@ 2005-03-19 14:52 ` p dot obry at wanadoo dot fr
2005-03-19 20:54 ` dannysmith at users dot sourceforge dot net
` (6 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: p dot obry at wanadoo dot fr @ 2005-03-19 14:52 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug ada/20515] "stdcall" imports are not handled correctly
2005-03-17 9:20 [Bug ada/20515] New: "stdcall" imports are not handled correctly sbellon at sbellon dot de
` (4 preceding siblings ...)
2005-03-19 14:52 ` p dot obry at wanadoo dot fr
@ 2005-03-19 20:54 ` dannysmith at users dot sourceforge dot net
2005-04-06 18:14 ` p dot obry at wanadoo dot fr
` (5 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: dannysmith at users dot sourceforge dot net @ 2005-03-19 20:54 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug ada/20515] "stdcall" imports are not handled correctly
2005-03-17 9:20 [Bug ada/20515] New: "stdcall" imports are not handled correctly sbellon at sbellon dot de
` (5 preceding siblings ...)
2005-03-19 20:54 ` dannysmith at users dot sourceforge dot net
@ 2005-04-06 18:14 ` p dot obry at wanadoo dot fr
2005-04-07 8:29 ` dannysmith at users dot sourceforge dot net
` (4 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: p dot obry at wanadoo dot fr @ 2005-04-06 18:14 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug ada/20515] "stdcall" imports are not handled correctly
2005-03-17 9:20 [Bug ada/20515] New: "stdcall" imports are not handled correctly sbellon at sbellon dot de
` (6 preceding siblings ...)
2005-04-06 18:14 ` p dot obry at wanadoo dot fr
@ 2005-04-07 8:29 ` dannysmith at users dot sourceforge dot net
2005-06-16 8:57 ` cvs-commit at gcc dot gnu dot org
` (3 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: dannysmith at users dot sourceforge dot net @ 2005-04-07 8:29 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug ada/20515] "stdcall" imports are not handled correctly
2005-03-17 9:20 [Bug ada/20515] New: "stdcall" imports are not handled correctly sbellon at sbellon dot de
` (7 preceding siblings ...)
2005-04-07 8:29 ` dannysmith at users dot sourceforge dot net
@ 2005-06-16 8:57 ` cvs-commit at gcc dot gnu dot org
2005-06-16 9:11 ` charlet at gcc dot gnu dot org
` (2 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: cvs-commit at gcc dot gnu dot org @ 2005-06-16 8:57 UTC (permalink / raw)
To: gcc-bugs
------- 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: charlet@gcc.gnu.org 2005-06-16 08:56:49
Modified files:
gcc/ada : gigi.h trans.c decl.c
Log message:
2005-06-10 Eric Botcazou <ebotcazou@adacore.com>
Olivier Hainque <hainque@adacore.com>
Richard Kenner <kenner@vlsi1.ultra.nyu.edu>
Pascal Obry <obry@adacore.com>
* 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug ada/20515] "stdcall" imports are not handled correctly
2005-03-17 9:20 [Bug ada/20515] New: "stdcall" imports are not handled correctly sbellon at sbellon dot de
` (8 preceding siblings ...)
2005-06-16 8:57 ` cvs-commit at gcc dot gnu dot org
@ 2005-06-16 9:11 ` charlet at gcc dot gnu dot org
2005-06-25 12:20 ` dannysmith at users dot sourceforge dot net
2005-06-27 18:50 ` p dot obry at wanadoo dot fr
11 siblings, 0 replies; 13+ messages in thread
From: charlet at gcc dot gnu dot org @ 2005-06-16 9:11 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug ada/20515] "stdcall" imports are not handled correctly
2005-03-17 9:20 [Bug ada/20515] New: "stdcall" imports are not handled correctly sbellon at sbellon dot de
` (9 preceding siblings ...)
2005-06-16 9:11 ` charlet at gcc dot gnu dot org
@ 2005-06-25 12:20 ` dannysmith at users dot sourceforge dot net
2005-06-27 18:50 ` p dot obry at wanadoo dot fr
11 siblings, 0 replies; 13+ messages in thread
From: dannysmith at users dot sourceforge dot net @ 2005-06-25 12:20 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug ada/20515] "stdcall" imports are not handled correctly
2005-03-17 9:20 [Bug ada/20515] New: "stdcall" imports are not handled correctly sbellon at sbellon dot de
` (10 preceding siblings ...)
2005-06-25 12:20 ` dannysmith at users dot sourceforge dot net
@ 2005-06-27 18:50 ` p dot obry at wanadoo dot fr
11 siblings, 0 replies; 13+ messages in thread
From: p dot obry at wanadoo dot fr @ 2005-06-27 18:50 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 13+ messages in thread