GCC 4.3.0 i386-pc-mingw32 ALPHA Release

[Aaron W. LaFramboise-2]

I've uploaded a binary release of GCC 4.3.0 to the FRS.

You can get it in the usual place in the FRS as either
gcc-4.3.0-mingw-alpha-20080403.7z or gcc-4.3.0-mingw-alpha-20080403.tar.gz.

I've included a version in 7-Zip because its smaller by a huge factor.
Note there is only a single tarball, because I'd really like people to
look at the whole compiler.  The next alpha release will be split in the
usual way.

This release is intended for testing GCC, and not for general
development use.

Warning: This is an alpha release.  That means the build contains
serious problems that are likely to cause serious problems, including
silent incorrect code compilation.

Instructions:

Extract it somewhere.  Add the bin/ folder to your PATH variable.
If you extract this over your existing MinGW installation, it will
replace your current GCC version's driver executables and documentation.

This release uses about 500 megabytes of disk space when decompressed.


This is a GCC 4.3.0 tree, with the following changes

shared libgcc enabled
vtable symbol fix
main symbol fix
static object build system fix

These are mainly derived from Danny's 4.2 patchset.

All languages (Ada, C, C++, Fortran, Java, Objective-C, Objective-C++)
appear to be basically working.  The testsuite results are fairly bad,
so they may not be working very well.

Two major components are disabled : OpenMP support and mudflap pointer
checking.

This release is probably ABI incompatible with all other GCC versions
for all languages other than C.  C should be OK for portable code that
isn't compiled with exception support.

This release is compiled to support Dwarf2 exception handling only.
Dwarf2 is mutually incompatible with all other exception handling
schemes, and foreign frames.

If you want to throw exceptions between modules, you need to compile
with -shared-gcclib.


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[AaronNGray]

Hi Aaron,

A few dumb question here.

> I've uploaded a binary release of GCC 4.3.0 to the FRS.

Whats the FRS ?

> You can get it in the usual place in the FRS as either
> gcc-4.3.0-mingw-alpha-20080403.7z or
> gcc-4.3.0-mingw-alpha-20080403.tar.gz.
>
> This release is intended for testing GCC, and not for general
> development use.
>
> Warning: This is an alpha release.  That means the build contains
> serious problems that are likely to cause serious problems, including
> silent incorrect code compilation.

Okay, will test.

> Instructions:
>
> Extract it somewhere.  Add the bin/ folder to your PATH variable.
> If you extract this over your existing MinGW installation, it will
> replace your current GCC version's driver executables and documentation.
>
> This release uses about 500 megabytes of disk space when decompressed.
>
>
> This is a GCC 4.3.0 tree, with the following changes
>
> shared libgcc enabled
> vtable symbol fix
> main symbol fix
> static object build system fix
>
> These are mainly derived from Danny's 4.2 patchset.

Are these patches availiable some where, or are they from 4.2 diff's ?

> All languages (Ada, C, C++, Fortran, Java, Objective-C, Objective-C++)
> appear to be basically working.  The testsuite results are fairly bad,
> so they may not be working very well.
>
> Two major components are disabled : OpenMP support and mudflap pointer
> checking.
>
> This release is probably ABI incompatible with all other GCC versions
> for all languages other than C.  C should be OK for portable code that
> isn't compiled with exception support.
>
> This release is compiled to support Dwarf2 exception handling only.
> Dwarf2 is mutually incompatible with all other exception handling
> schemes, and foreign frames.
>
> If you want to throw exceptions between modules, you need to compile
> with -shared-gcclib.

Is this compiled on Cygwin or with MinGW ?

Aaron


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Greg Chicares-2]

On 2008-04-04 14:39Z, Aaron Gray wrote:
>
>> I've uploaded a binary release of GCC 4.3.0 to the FRS.
>
> Whats the FRS ?

"File Release System", i.e.:

http://sourceforge.net/project/showfiles.php?group_id=2435

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[John E. / TDM]

Here's your first bug report:

Remember the packaging bug in the first binutils 2.18.50 tech preview that
was pinned down in the "Necessary environment path settings" thread? This
release gets at that same issue from the other direction. Since it was
configured without a specific --build, --host or --target, it defaulted to
the autodetected "i386-pc-mingw32" platform string. However this means that
it looks for binutils in "<mingw>/i386-pc-mingw32/bin" rather than
"<mingw>/mingw32/bin". Suggested fix: add "--build=mingw32" to the configure
invocation. (As gleaned from
http://www.nabble.com/Re%3A-Standards-for-Building-MinGW-Release-Packages--(was%3A--Mingw-users--Necessary-environment-path-settings-)-p16360778.html.)

-John E.


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Aaron W. LaFramboise-2]

Aaron Gray wrote:

> Are these patches availiable some where, or are they from 4.2 diff's ?

They are not available presently.  The entire patched source is
available for download, however, so you could generate the diffs
yourself if you wanted them.  In the future, this will be packaged
separately.

> Is this compiled on Cygwin or with MinGW ?

It is a MinGW build, but I used tools from the Cygwin environment to
meet GCC's prerequisites.  I did not use MSYS; recent versions of MSYS
apparently have no trouble compiling GCC, though, and it should give
similar results.


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Aaron W. LaFramboise-2]

Thanks for the report, but see below.

John E. / TDM wrote:

> Remember the packaging bug in the first binutils 2.18.50 tech preview that
> was pinned down in the "Necessary environment path settings" thread? This
> release gets at that same issue from the other direction. Since it was
> configured without a specific --build, --host or --target, it defaulted to
> the autodetected "i386-pc-mingw32" platform string.

OK, I'll admit I didn't pay close enough addition to that discussion,
but I don't really understand this bug.

> However this means that
> it looks for binutils in "<mingw>/i386-pc-mingw32/bin" rather than
> "<mingw>/mingw32/bin".

I don't believe that it does this.

GCC finds 'as' and 'ld' on the PATH, which is the same way it finds it
on any other native GCC target, which is also the same way GCJ finds
'ecj1', for example.  I wasn't aware it was even possible to do
something different for a native build without giving GCC special options.

You can verify this by passing -Wl,-debug on the link line, which will
cause collect2 to tell you where its finding the linker, or -v on the
compile line, which will tell you how GCC is finding the assembler.

What is the actual manifestation of this problem?  What sort of problem
did it cause with the build?


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[John E. / TDM]

Aaron W. LaFramboise wrote:
> OK, I'll admit I didn't pay close enough addition to that discussion,
> but I don't really understand this bug.

Sorry, I had assumed you followed it. Basically, this bug only manifests
itself when the MinGW/GCC bin directory is *not* present in PATH -- e.g. GCC
is run with a fully-qualified command line, like
"C:\path\to\mingw\bin\gcc.exe -o myprogram mysources". It is in fact highly
useful to be able to run GCC on Windows without any additions to PATH,
particularly when working with multiple versions of it or when running it
from an IDE.

The GCC drivers (gcc.exe and friends, as well as collect2) actually search
for their subprograms ("cc1", "as" and "ld" via collect2 in a typical C
compilation) in a predefined set of locations which you can view by running
"gcc.exe -print-search-dirs". Only if the subprogram is not found in any of
those locations does it fall back on an unqualified invocation. You will see
this when you compare the verbose output of a previous GCC release with your
new one: in 3.4.5, the invocation of "as" is fully qualified; in the alpha
4.3.0, it is unqualified (and therefore fails if the directory containing it
isn't in PATH). Below is an abridged transcription of a Windows shell
session which demonstrates this:

D:\JDevel\test> D:\JDevel\MinGW\mingw-gcc-3.4.5\bin\gcc.exe -v -o test.exe
main.c

Reading specs from
D:/JDevel/MinGW/mingw-gcc-3.4.5/bin/../lib/gcc/mingw32/3.4.5/
specs
Configured with:
../gcc-3.4.5/configure --with-gcc --with-gnu-ld --with-gnu-as -
-host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls
 --
enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shar
ed --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --ena
ble-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-sync
hronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.5 (mingw-vista special r2)
<***cc1 invocation snipped***>
 D:/JDevel/MinGW/mingw-gcc-3.4.5/bin/../lib/gcc/mingw32/3.4.5/../../../../mingw32/bin/as.exe -o D:\DOCUME~1\John\LOCALS~1\Temp/ccqP4ilE.oD:\DOCUME~1\John\LOCALS~1\Temp/ccxWAvll.s<***collect2 invocation snipped***>D:\JDevel\test> D:\JDevel\MinGW\mingw-gcc-4.3.0\bin\gcc.exe -v -o test.exemain.cUsing built-in specs.Target: i386-pc-mingw32Configured with:../gcc-4.3.0/configure --prefix=/mingw --disable-nls --enable-languages=c,c++,fortran,objc,obj-c++,ada,java --disable-win32-registry --disable-sjlj-exceptions --enable-libstdcxx-debug --enable-version-specific-runtime-libs--with-gmp=/mingw/src/gcc/gmp-mpfr-root --with-mpfr=/mingw/src/gcc/gmp-mpfr-root --enable-libgcj --enable-concept-checks --enable-sharedThread model: win32gcc version 4.3.0 (GCC)<*** cc1 invocation snipped***>COLLECT_GCC_OPTIONS='-v' '-o' 'test.exe' '-mtune=i386' as -o D:\DOCUME~1\John\LOCALS~1\Temp/cc2779xd.oD:\DOCUME~1\John\LOCALS~1\Temp/ccqhufMa.sgcc.exe: CreateProcess: No such file or directoryFinally, strai
 ght from the horse's mouth:http://www.nabble.com/Re%3A-Necessary-environment-path-settings--p16243810.html.Cheers,John E.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[John E. / TDM]

I had deluded myself into thinking I could get away with using Outlook
Express with impunity. My apologies for inflicting the consequences of
that on anyone who read the message duplicated herein.

Aaron W. LaFramboise wrote:
> OK, I'll admit I didn't pay close enough addition to that discussion,
> but I don't really understand this bug.
>  
Sorry, I had assumed you followed it. Basically, this bug only manifests
itself when the MinGW/GCC bin directory is *not* present in PATH -- e.g.
GCC is run with a fully-qualified command line, like
"C:\path\to\mingw\bin\gcc.exe -o myprogram mysources". It is in fact
highly useful to be able to run GCC on Windows without any additions to
PATH, particularly when working with multiple versions of it or when
running it from and IDE.

The GCC drivers (gcc.exe and friends, as well as collect2) actually
search for their subprograms ("cc1", "as", and "ld" via collect2 in a
typical C compilation) in a predefined set of locations which you cna
view by running "gcc.exe -print-search-dirs". Only if the subprogram is
not found in any of those locations does it fall back on an unqualified
invocation. You will see this when you compare the verbose output of a
previous GCC release with your new one: in 3.4.5, the invocation of "as"
is fully qualified; in the alpha 4.3.0, it is unqualified (and therefore
fails if the directory containing it isn't in PATH). Below is an
abridged transcription of a Windows shell session which demonstrates this:

D:\JDevel\test>D:\JDevel\MinGW\mingw-gcc-3.4.5\bin\gcc.exe -v -o test.exe main.c

Reading specs from D:/JDevel/MinGW/mingw-gcc-3.4.5/bin/../lib/gcc/mingw32/3.4.5/
specs
Configured with: ../gcc-3.4.5/configure --with-gcc --with-gnu-ld --with-gnu-as -
-host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --
enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shar
ed --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --ena
ble-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-sync
hronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.5 (mingw-vista special r2)
<*** cc1 invocation snipped***>
 D:/JDevel/MinGW/mingw-gcc-3.4.5/bin/../lib/gcc/mingw32/3.4.5/../../../../mingw3
2/bin/as.exe -o D:\DOCUME~1\John\LOCALS~1\Temp/ccqP4ilE.o D:\DOCUME~1\John\LOCAL
S~1\Temp/ccxWAvll.s
<*** collect2 invocation snipped***>

D:\JDevel\test>D:\JDevel\MinGW\mingw-gcc-4.3.0\bin\gcc.exe -v -o test.exe main.c

Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../gcc-4.3.0/configure --prefix=/mingw --disable-nls --enable-l
anguages=c,c++,fortran,objc,obj-c++,ada,java --disable-win32-registry --disable-
sjlj-exceptions --enable-libstdcxx-debug --enable-version-specific-runtime-libs
--with-gmp=/mingw/src/gcc/gmp-mpfr-root --with-mpfr=/mingw/src/gcc/gmp-mpfr-root
 --enable-libgcj --enable-concept-checks --enable-shared
Thread model: win32
gcc version 4.3.0 (GCC)
<*** cc1 invocation snipped***>
COLLECT_GCC_OPTIONS='-v' '-o' 'test.exe' '-mtune=i386'
 as -o D:\DOCUME~1\John\LOCALS~1\Temp/cc2779xd.o D:\DOCUME~1\John\LOCALS~1\Temp/
ccqhufMa.s
gcc.exe: CreateProcess: No such file or directory


Finally, straight from the horse's mouth:
<http://www.nabble.com/Re%3A-Necessary-environment-path-settings--p16243810.html>.

Cheers,
John E.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Aaron W. LaFramboise-2]

John E. / TDM wrote:

> Basically, this bug only manifests
> itself when the MinGW/GCC bin directory is *not* present in PATH -- e.g.
> GCC is run with a fully-qualified command line, like
> "C:\path\to\mingw\bin\gcc.exe -o myprogram mysources". It is in fact
> highly useful to be able to run GCC on Windows without any additions to
> PATH, particularly when working with multiple versions of it or when
> running it from and IDE.

OK this makes a lot more sense to me now.  Thanks for the explanation.
Obviously I was never aware of this feature.

I will make this change in the next build.

So we're stuck with --build=mingw32 for backwards compatibility reasons.
  This is a little unfortunate, and in a way, almost a GCC bug, as
mingw32 is canonicalized to i386-pc-mingw anyway.  I would have
preferred using the latter because then autodetection works correctly,
and I feel the fewer unnecessary command line options we have, the better.

If I recall correctly, GCC and binutils treat all of 386, 486, 586, and
686 identically.  In that case, this is a bug that would be fixed in the
long run (not short run) by causing GCC to search all identical CPU
types.  The benefit is that people doing native builds on their own are
likely to get something compatible with distributed binaries as far as
this feature is concern, 'compatibility by default.'

If there are no objections, I'll put submitting a patch to FSF GCC for
that on my 'when I seriously have nothing better to do' list.  We would
avoid compatibility problems in the short-term by a local patch to check
mingw32 also.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Earnie]

Quoting "Aaron W. LaFramboise" <aaron77thyme@...>:

> John E. / TDM wrote:
>
>> Basically, this bug only manifests
>> itself when the MinGW/GCC bin directory is *not* present in PATH -- e.g.
>> GCC is run with a fully-qualified command line, like
>> "C:\path\to\mingw\bin\gcc.exe -o myprogram mysources". It is in fact
>> highly useful to be able to run GCC on Windows without any additions to
>> PATH, particularly when working with multiple versions of it or when
>> running it from and IDE.
>
> OK this makes a lot more sense to me now.  Thanks for the explanation.
> Obviously I was never aware of this feature.
>
> I will make this change in the next build.
>
> So we're stuck with --build=mingw32 for backwards compatibility reasons.
>  This is a little unfortunate, and in a way, almost a GCC bug, as
> mingw32 is canonicalized to i386-pc-mingw anyway.  I would have
> preferred using the latter because then autodetection works correctly,
> and I feel the fewer unnecessary command line options we have, the better.
>

As has already been stated in this list configure switches for GCC and
binutils and others that produce a target directory must include
--host=mingw32 --target=mingw32.  That is the reason --build=mingw32.  
The canonicalization should be i386-pc-mingw32 instead of
i386-pc-mingw.  For x86_64 it should be --host=mingw64, etc.

> If I recall correctly, GCC and binutils treat all of 386, 486, 586, and
> 686 identically.  In that case, this is a bug that would be fixed in the
> long run (not short run) by causing GCC to search all identical CPU
> types.  The benefit is that people doing native builds on their own are
> likely to get something compatible with distributed binaries as far as
> this feature is concern, 'compatibility by default.'
>

Correct, which is why the triplet is just plain stupid for mingw32; it
makes no logical sense.  We end up with i686-pc-mingw32 when it should
really be i386-pc-mingw32 just because the build is on i686 but the
target is really i386.  I remember being so confused when I first came
to Cygwin.

> If there are no objections, I'll put submitting a patch to FSF GCC for
> that on my 'when I seriously have nothing better to do' list.  We would
> avoid compatibility problems in the short-term by a local patch to check
> mingw32 also.
>

Keith and I have been in contact with Ben Elliston and one of us will
provide patches for MinGW to config.guess and config.sub.

Earnie

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[AaronNGray]

> Aaron Gray wrote:
>
>> Are these patches availiable some where, or are they from 4.2 diff's ?
>
> They are not available presently.  The entire patched source is
> available for download, however, so you could generate the diffs
> yourself if you wanted them.  In the future, this will be packaged
> separately.

Okay, thanks I have already done diff's but I was wondering if there was any
documentation at all :)

>> Is this compiled on Cygwin or with MinGW ?
>
> It is a MinGW build, but I used tools from the Cygwin environment to
> meet GCC's prerequisites.  I did not use MSYS; recent versions of MSYS
> apparently have no trouble compiling GCC, though, and it should give
> similar results.

Okay this is good.

Thanks for the reply,

Aaron


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Aaron W. LaFramboise-2]

Earnie Boyd wrote:

> Correct, which is why the triplet is just plain stupid for mingw32; it
> makes no logical sense.  We end up with i686-pc-mingw32 when it should
> really be i386-pc-mingw32 just because the build is on i686 but the
> target is really i386.  I remember being so confused when I first came
> to Cygwin.

GCC regards i386 as the same as i686; this is not true of all programs.
  See below.

> Keith and I have been in contact with Ben Elliston and one of us will
> provide patches for MinGW to config.guess and config.sub.

Are these patches to canonicalize i?86 to i386?  If so, I am opposed to
this.

We must be consistent with other targets!  If you are going to do this,
it should be for all i?86 targets, not just us.  The more
inconsistencies the -mingw targets pick up versus more popular GCC
targets, the more difficult things will be for us down the road.

If other targets do not want this sort of canonicalization, then I think
it will be a bad idea for us in the long run.  Remember that all of GNU
autoconfigury use config.sub, and if we make this change here, all sorts
of packages that use autoconf may somehow become dependent, creating
problems for us later if other targets decide that i686 means something
different from i386.

As a specific example, GMP uses the target triple to decide on the
capabilities of the host machine.  I'm not sure that this is a good
idea, but what I'm saying is that making this change here has
far-reaching consequences beyond the toolchain itself.


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Danny Smith]

> -----Original Message-----
> From: mingw-dvlpr-bounces@...
> [mailto:mingw-dvlpr-bounces@...] On Behalf
> Of Aaron W. LaFramboise
> Sent: Sunday, 6 April 2008 8:50 a.m.
> To: MinGW Devlopers Discussion List
> Subject: Re: [MinGW-dvlpr] GCC 4.3.0 i386-pc-mingw32 ALPHA Release
>
>
> Earnie Boyd wrote:
>
> > Correct, which is why the triplet is just plain stupid for
> mingw32; it
> > makes no logical sense.  We end up with i686-pc-mingw32
> when it should
> > really be i386-pc-mingw32 just because the build is on i686 but the
> > target is really i386.  I remember being so confused when I
> first came
> > to Cygwin.
>
> GCC regards i386 as the same as i686; this is not true of all
> programs.
>   See below.
>
> > Keith and I have been in contact with Ben Elliston and one
> of us will
> > provide patches for MinGW to config.guess and config.sub.
>
> Are these patches to canonicalize i?86 to i386?  If so, I am
> opposed to
> this.
>

> We must be consistent with other targets!  


FWIW I agree wholeheartedly with Aaron.


The decision to get rid of "i386"  from the target identifier was made soon after Mumit
Khan left the project, about 8 years ago. The reasons then were the same as what Earnie
states above.  I think at the same time, a decision was made to move the runtime amd
win32api headers from the target tooldir, /ming_root/mingw32-pc-i386/include/,  to
/mingw_root/include/  Likewise for libs.  This was discusssed on the newly-form mingw
mailing list which at that time was hosted by egroups.com.  I can't find an archive for
that list.

I disagreed at the time but I was a newcomer to the project then and didn't argue.  Shame
on me.  This inconsistency with other targets just creates more work for mingw.

I hope that Aaron is allowed to get rid of much of the unnecessary baggage that I had been
carrying out of habit for too long.

Aaron, gcc does use target cpu information in __builtin_sync atomic ops (see
config/i386/sync.md).  Likwise libstdc++ diffentiates between i386 and i486 in
atomicity.h.

Danny


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[John E. / TDM]

Here's another bug report on the GCC 4.3.0 alpha.

*Summary:*
Inline constructor or destructor definitions outside the class
definition of a dllimport class are not recognized.

*Testcase:*
Attached. Compiles successfully on MinGW/GCC 3.4.5 and 4.2 releases;
fails on the 4.3.0 alpha (as well as my own various 4.3.0 builds).

*Description:*
In the ISO C++ Standard, section 9.3 - Member functions [class.mfct],
point 3 says "An inline member function (whether static or nonstatic)
may also be defined outside of its class definition provided either its
declaration in the class definition or its definition outside of the
class definition declares the function as inline." This appears to be
broken in GCC 4.3.0 for the specific case of constructors and
destructors of a class defined with __declspec(dllimport), where the
definition outside the class is declared as inline but the declaration
inside the class is not. It appears that a standard import reference is
generated when the declaration is seen inside the class, but the inline
definition outside the class afterward doesn't override that reference
as it should. This leads to undefined references to import functions at
link time.

Unless someone says otherwise, I will also soon file this in GCC
bugzilla. In case anyone is interested, I discovered the bug while
attempting a build of the Code::Blocks IDE from sources. I judge its
severity to be mild, as it is easily avoided by adding "inline" to the
declaration inside the class.

-John E.


struct __declspec(dllimport) foo
{
  foo();
  ~foo();

  int bar;
};

inline foo::foo()
{
  bar = 0;
}

inline foo::~foo()
{
}

int main()
{
  foo f;
  return f.bar;
}

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Aaron W. LaFramboise-2]

John E. / TDM wrote:

> *Testcase:*
> Attached. Compiles successfully on MinGW/GCC 3.4.5 and 4.2 releases;
> fails on the 4.3.0 alpha (as well as my own various 4.3.0 builds).

This is definitely a change from previous versions, but...

This construct (and your testcase) is rejected by MSVC 8.0:

john.obj : error LNK2019: unresolved external symbol
"__declspec(dllimport) public: __thiscall foo::~foo(void)"
(__imp_??1foo@@QAE@XZ) referenced in function _main
john.obj : error LNK2019: unresolved external symbol
"__declspec(dllimport) public: __thiscall foo::foo(void)"
(__imp_??0foo@@QAE@XZ) referenced in function _main

So I am not sure if this is a bug, or if the compiler is correct in
rejecting this.  In general, when it comes to declspec, GCC's behavior
should match MSVC.

> but the inline
> definition outside the class afterward doesn't override that reference
> as it should.

I am not sure if what you describe is the intended behavior.

I can't find anything in the MSVC documentation that addresses the
intersection of 'inline' and 'dllimport,' but its my best guess that
'dllimport' should cause 'inline' to be ignored.  This seems reasonable,
occurring in the case where we're importing something that is defined as
'inline,' which could happen if we're using the API_EXPORT-style macros:

class API_EXPORT my_class {myclass() {}};

I can't find any documented or implemented exception to the rule that
dllimport will always cause an import from an external DLL.

There's some anecdotal evidence of this on the web, such as the 'Answer'
post in
<http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3039271&SiteID=1>.

Based on this, I think the previous GCC versions were incorrect in
allowing this, and GCC 4.3.0 is correct in rejecting this, and this is
not a bug.


One other issue.  If we change the constructor to be implicitly inline,
the testcase still fails on MSVC, but succeeds on 4.3.0, as well as
earlier versions of GCC.  I think this is a bug; it shouldn't matter if
we're using implicit or explicit inline, it should be rejected in either
case.


What do you think?

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[John E. / TDM]

Aaron W. LaFramboise wrote:

> John E. / TDM wrote:
>  
>> *Testcase:*
>> Attached. Compiles successfully on MinGW/GCC 3.4.5 and 4.2 releases;
>> fails on the 4.3.0 alpha (as well as my own various 4.3.0 builds).
>>    
> This is definitely a change from previous versions, but...
>
> This construct (and your testcase) is rejected by MSVC 8.0:
>
> john.obj : error LNK2019: unresolved external symbol
> "__declspec(dllimport) public: __thiscall foo::~foo(void)"
> (__imp_??1foo@@QAE@XZ) referenced in function _main
> john.obj : error LNK2019: unresolved external symbol
> "__declspec(dllimport) public: __thiscall foo::foo(void)"
> (__imp_??0foo@@QAE@XZ) referenced in function _main
>
> So I am not sure if this is a bug, or if the compiler is correct in
> rejecting this.  In general, when it comes to declspec, GCC's behavior
> should match MSVC.
> What do you think?
>  

I think it's an unfortunate loss of functionality. Why shouldn't one be
able to inline some functions in a class and have the rest be imported
from a DLL? It seems hardly different than inlining some functions in a
class and having the rest be imported from another object file.

Matching MSVC's behavior is probably a good idea for cases like this
where there is no non-Windows GNU precedent. Nevertheless I fear for
MinGW-based software already out there (such as Code::Blocks) which
currently relies on 3.4.5's behavior. So if this were a democracy, I
would vote to keep the old behavior, i.e. patch 4.3 and trunk so that
inline constructors and destructors override import references. (Unless
someone comes up with a good reason why doing so leads to broken behavior.)

-John E.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[John E. / TDM]

John E. / TDM wrote:

> Aaron W. LaFramboise wrote:
>  
>> John E. / TDM wrote:
>>  
>>    
>>> *Testcase:*
>>> Attached. Compiles successfully on MinGW/GCC 3.4.5 and 4.2 releases;
>>> fails on the 4.3.0 alpha (as well as my own various 4.3.0 builds).
>>>    
>>>      
>> This is definitely a change from previous versions, but...
>>
>> This construct (and your testcase) is rejected by MSVC 8.0:
>>
>> john.obj : error LNK2019: unresolved external symbol
>> "__declspec(dllimport) public: __thiscall foo::~foo(void)"
>> (__imp_??1foo@@QAE@XZ) referenced in function _main
>> john.obj : error LNK2019: unresolved external symbol
>> "__declspec(dllimport) public: __thiscall foo::foo(void)"
>> (__imp_??0foo@@QAE@XZ) referenced in function _main
>>
>> So I am not sure if this is a bug, or if the compiler is correct in
>> rejecting this.  In general, when it comes to declspec, GCC's behavior
>> should match MSVC.
>> What do you think?
>>    
> I think it's an unfortunate loss of functionality. Why shouldn't one be
> able to inline some functions in a class and have the rest be imported
> from a DLL? It seems hardly different than inlining some functions in a
> class and having the rest be imported from another object file.
>
> Matching MSVC's behavior is probably a good idea for cases like this
> where there is no non-Windows GNU precedent. Nevertheless I fear for
> MinGW-based software already out there (such as Code::Blocks) which
> currently relies on 3.4.5's behavior. So if this were a democracy, I
> would vote to keep the old behavior, i.e. patch 4.3 and trunk so that
> inline constructors and destructors override import references. (Unless
> someone comes up with a good reason why doing so leads to broken behavior.)
>  

In doing more research into this issue, I ran across a GCC mailing list
post by Danny Smith
(<http://gcc.gnu.org/ml/gcc-patches/2003-05/msg02419.html>) which seems
to indicate that we do indeed want to allow inline redefinitions of
dllimport member functions -- in particular, see
gcc/testsuite/g++.dg/ext/dllimport9.C. The testcase doesn't test inline
con/de-structors, but it does still fail in MSVC 8 (with __attribute__
((dllimport)) changed to __declspec(dllimport), of course).

-John E.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Aaron W. LaFramboise-2]

John E. / TDM wrote:

> I think it's an unfortunate loss of functionality. Why shouldn't one be
> able to inline some functions in a class and have the rest be imported
> from a DLL? It seems hardly different than inlining some functions in a
> class and having the rest be imported from another object file.

This is a reasonable feature to have, but I don't think dllimport inline
should be the way to accomplish it.

As best I understand, this is what MSVC's compiler does, and
consequently most Windows programmers expect:

dllimport: Always import from DLL

inline: Maybe inline, if possible, if heuristic improvement (C++)

Note according to the manual for all GCC versions, including 3.4,
"Currently, the attribute [dllimport] is ignored for inlined functions."
  So even according to GCC's manual, this was not correct behavior.

Ignoring 'inline' is only a performance problem.  Ignoring 'dllimport'
is a correctness problem, because it changes the ABI; we're not
importing something from a DLL that we should, and the program might
rely on this behavior, for eg, different DLLs may provide a different
implementation.

This is similar to the situation on some ELF models, where global
symbols are preemptable by other shared libraries, and so optimizations
(such as inlining) are inhibited to allow shared libraries to properly
override global functions.

In conclusion:
-'inline dllimport' is a valid construct on MSVC
-this construct actually comes up quite a lot in Windows code
-the old GCC behavior changes the meaning of this valid construct, which
is probably bad

> Matching MSVC's behavior is probably a good idea for cases like this
> where there is no non-Windows GNU precedent.  Nevertheless I fear for
> MinGW-based software already out there (such as Code::Blocks) which
> currently relies on 3.4.5's behavior.

I don't understand this though.  Inlining can always fail.  If the
Code::Blocks link fails without this inlining, then something is wrong
anyway.  It's only luck that this worked in the first place.

> So if this were a democracy, I
> would vote to keep the old behavior, i.e. patch 4.3 and trunk so that
> inline constructors and destructors override import references.

Democracy is a failure to reach consensus.  Let's find a solution that
will make everybody happy.

What exactly troubles you about this change?  The fact Code::Blocks no
longer compiles?  It's my feeling that either way, Code::Blocks has a
bug as inline failure shouldn't stop the link, so a change will be
needed either way.

If it's the missed optimization, what if we added a GNU-specific way to
do this, such as always_inline or something?

We could also do something like add a flag that changes the compiler to
be MS-compatible in this regard, but I think this is a very dangerous
path to go down, and if there's any way we can avoid getting ourselves
into this sort of situation, we should seek it.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[John E. / TDM]

Aaron W. LaFramboise wrote:
> Note according to the manual for all GCC versions, including 3.4,
> "Currently, the attribute [dllimport] is ignored for inlined functions."
>   So even according to GCC's manual, this was not correct behavior.
>  

I don't think one can imply a view of incorrectness from that statement
in the manual. See gcc/testsuite/g++.dg/ext/dllimport9.C,
gcc/config/i386/winnt-cxx.c:113-121 and gcc/tree.c:3990-3991 for further
proof that the old behavior is intended.

>> Matching MSVC's behavior is probably a good idea for cases like this
>> where there is no non-Windows GNU precedent.  Nevertheless I fear for
>> MinGW-based software already out there (such as Code::Blocks) which
>> currently relies on 3.4.5's behavior.
>>    
>
> I don't understand this though.  Inlining can always fail.  If the
> Code::Blocks link fails without this inlining, then something is wrong
> anyway.  It's only luck that this worked in the first place.
>  

No, Code::Blocks is just doing the exact same thing as the testcase I
provided. In the testcase, definitions for the constructor and
destructor are obviously provided, but GCC fails to recognize them as
such and therefore fails to delete the dllimport references. The exact
same thing happens when you remove the inline keyword from the
definition -- but in this case, GCC warns you that it will ignore the
previous dllimport and then proceeds to use it rather than ignore it!

>> So if this were a democracy, I
>> would vote to keep the old behavior, i.e. patch 4.3 and trunk so that
>> inline constructors and destructors override import references.
>>    
>
> Democracy is a failure to reach consensus.  Let's find a solution that
> will make everybody happy.
>
> What exactly troubles you about this change?  The fact Code::Blocks no
> longer compiles?  It's my feeling that either way, Code::Blocks has a
> bug as inline failure shouldn't stop the link, so a change will be
> needed either way.
>  

Code::Blocks doesn't care whether the functions are inlined or not; it
just wants certain member functions (in this case, the constructor) to
be directly defined in the compilation unit rather than imported from
the DLL. (I imagine it's for optimization purposes.)

The thing that troubles me about this change is A) that the old behavior
was intended, and B) the behavior has only changed for con/de-structors.
(In other words, the old behavior holds true for other member functions.)

-John E.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr

[Danny Smith]

>
> In conclusion:
> -'inline dllimport' is a valid construct on MSVC
> -this construct actually comes up quite a lot in Windows code
> -the old GCC behavior changes the meaning of this valid
> construct, which
> is probably bad
>

As I understand, "inline dllimport" under MSVC means:
"inline, if possible, else resolve as external defined in another module (specifically a
dll)."

Ignoring the (specially a dll), this is similar to what GNU pre-C99 "external inline"
does.  

G++ implentation was "inline dllimport" was to just ignore the dllimport, since dllimport
does not allow a definition in the same translation unit

 

> > Matching MSVC's behavior is probably a good idea for cases
> like this
> > where there is no non-Windows GNU precedent.  Nevertheless
> I fear for
> > MinGW-based software already out there (such as Code::Blocks) which
> > currently relies on 3.4.5's behavior.
>
> I don't understand this though.  Inlining can always fail.  If the
> Code::Blocks link fails without this inlining, then something
> is wrong
> anyway.  It's only luck that this worked in the first place.
>
> > So if this were a democracy, I
> > would vote to keep the old behavior, i.e. patch 4.3 and
> trunk so that
> > inline constructors and destructors override import references.
>

I would viote for that, since that is old G++ behaviour and the current behaviour with non
[c|d]tor methods.

I think you have a genuine GCC bug.  It will get fixed (or not) by GCC developers, not by
discussions on this list. Please report to GCC bugzilla. This affects cygwin as well
mingw.  It also affects pe-sh targets that use dllimpoprt.
Assign to me if you like, I am currently testing a patch that will restore old behaviour.

Danny


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr