gamedevlists-general

[GD-General] Two issues: __attribute__((cdecl)) and MSVC++ Toolkit 2003

[<ho...@bo...>]

Forgive me for doing this as a single question, I'm writing this from a
Web client...

Going back to the __attribute((cdecl)) issue, I've found that this does
NOT work when using GCC 3.3.4 for Athlon64.  I get a warning that the
attribute will be ignored.  It compiles fine using GCC 3.3.1 for Cygwin
however.

So, back to the drawing board I guess. *sigh*

Unrelated to this I just found out that Microsoft has the command line
compiler from VC++ 7.2 available for download. I'd like to test it out,
but I don't want it to screw up my VC++ 6.0 installation -- has anyone
downloaded it and used it with VC++ 6 and not had the latter die?

Thanks,

Brian

RE: [GD-General] Two issues: __attribute__((cdecl)) and MSVC++ Toolkit 2003

[tweety <mi...@sy...>]

About the 2nd:
Works perfectly as long as you don't install them in the same folder and
keep separate PATH env vars to switch around (this is kinda done for you
with vdvars32.bat and similar).

As a side note, vc++ 8, vc# 8 and vb.net 8 beta 1 are also available for
free download with ide included. I heard they're pretty stable.

----------------------------------
Peace and love,
Tweety
mi...@sy... - twe...@us...
YahooID: tweety_04_01

> -----Original Message-----
> From: gam...@li... 
> [mailto:gam...@li...] On 
> Behalf Of ho...@bo...
> Sent: July 7, 2004 3:34 PM
> To: gam...@li...
> Subject: [GD-General] Two issues: __attribute__((cdecl)) and 
> MSVC++ Toolkit 2003
> 
> Forgive me for doing this as a single question, I'm writing 
> this from a
> Web client...
> 
> Going back to the __attribute((cdecl)) issue, I've found that 
> this does
> NOT work when using GCC 3.3.4 for Athlon64.  I get a warning that the
> attribute will be ignored.  It compiles fine using GCC 3.3.1 
> for Cygwin
> however.
> 
> So, back to the drawing board I guess. *sigh*
> 
> Unrelated to this I just found out that Microsoft has the command line
> compiler from VC++ 7.2 available for download. I'd like to 
> test it out,
> but I don't want it to screw up my VC++ 6.0 installation -- has anyone
> downloaded it and used it with VC++ 6 and not had the latter die?
> 
> Thanks,
> 
> Brian
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
> 

Re: [GD-General] Two issues: __attribute__((cdecl)) and MSVC++ Toolkit 2003

[<cas...@ya...>]

--- ho...@bo... wrote: 
> Forgive me for doing this as a single question, I'm writing this from a
> Web client...
> 
> Going back to the __attribute((cdecl)) issue, I've found that this does
> NOT work when using GCC 3.3.4 for Athlon64.  I get a warning that the
> attribute will be ignored.  It compiles fine using GCC 3.3.1 for Cygwin
> however.
> 
> So, back to the drawing board I guess. *sigh*

Oh, that's sad, I've been using that on Cygwin and Linux with gcc3.3 and
maybe with other versions. I will do a more throughfull test as soon as I
come home. Maybe we could contact the gcc team and ask them to maintain that
feature, it's free software afterall.


> Unrelated to this I just found out that Microsoft has the command line
> compiler from VC++ 7.2 available for download. I'd like to test it out,
> but I don't want it to screw up my VC++ 6.0 installation -- has anyone
> downloaded it and used it with VC++ 6 and not had the latter die?

I've been using them together without any problem. However, you will also
have to download the platform sdk to do something useful with the compiler.
You can also use it with the old VC6 IDE by changing the path of the
executables in the settings.

The VC++ 8 beta1 is also available for download with the full IDE. However, I
haven't read the license in detail so I'm not aware of it's restrictions.

--
Ignacio Castaño
cas...@ya...





		
______________________________________________
Renovamos el Correo Yahoo!: ¡100 MB GRATIS!
Nuevos servicios, más seguridad
http://correo.yahoo.es

Re: [GD-General] Two issues: __attribute__((cdecl)) and MSVC++ Toolkit 2003

[Brian H. <ho...@bo...>]

Here it is enumerated.  The prefix form of __attribute__((cdecl)):

gcc 2.95, Linux/x86 -- YES
gcc 3.3.4, Linux/A64 -- NO
gcc 3.3, OS X/PowerPC -- NO
gcc 3.3.1, Cygwin/x86 -- YES

No rhyme nor reason, other than possibly needing to be a pure x86 code 
generator, but this is a front-end thing, not a back-end thing, so I 
dunno what's going on.

Brian

Re: [GD-General] Two issues: __attribute__((cdecl)) and MSVC++ Toolkit 2003

[Brian H. <ho...@bo...>]

On Wed, 7 Jul 2004 22:14:09 -0400, Brian Hook wrote:
> Here it is enumerated.  The prefix form of __attribute__((cdecl)):
>
> gcc 2.95, Linux/x86 -- YES
> gcc 3.3.4, Linux/A64 -- NO
> gcc 3.3, OS X/PowerPC -- NO
> gcc 3.3.1, Cygwin/x86 -- YES
>
> No rhyme nor reason, other than possibly needing to be a pure x86


ACtually, there is a rhyme -- it's supported on x86, and not supported 
on non-x86, where A64 is considered non-x86 for some reason.  This 
makes sense given that calling conventions are by and large an x86 
kind of thing (at least, these specific ones).

So it's not a positioning thing, it's an availability thing.  Duh, 
shoulda thought of that a while ago.

Brian

Re: [GD-General] Two issues: __attribute__((cdecl)) and MSVC++ Toolkit 2003

[Ignacio <cas...@ya...>]

On Wednesday 07 July 2004 20:05, Brian Hook wrote:
> On Wed, 7 Jul 2004 22:14:09 -0400, Brian Hook wrote:
> > Here it is enumerated.  The prefix form of __attribute__((cdecl)):
> >
> > gcc 2.95, Linux/x86 -- YES
> > gcc 3.3.4, Linux/A64 -- NO
> > gcc 3.3, OS X/PowerPC -- NO
> > gcc 3.3.1, Cygwin/x86 -- YES
> >
> > No rhyme nor reason, other than possibly needing to be a pure x86
>
> ACtually, there is a rhyme -- it's supported on x86, and not supported
> on non-x86, where A64 is considered non-x86 for some reason.  This
> makes sense given that calling conventions are by and large an x86
> kind of thing (at least, these specific ones).
>
> So it's not a positioning thing, it's an availability thing.  Duh,
> shoulda thought of that a while ago.

Additionally I can also confirm that the followings also work:

gcc 3.2.3, Linux/x86
gcc 3.3.1, Linux/x86
gcc 3.4.0, Linux/x86

I don't have access to a non-x86 machine, but your conclusions make a lot o=
f=20
sense. To discard any othe possibility, you could also try with any other=20
attribute on a non-x86, like noreturn for instance.

=2D-=20
Ignacio Casta=F1o
cas...@ya...