[Bug bootstrap/56227] New: Bootstrap failure on MinGW building ggc-page.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56227 Bug #: 56227 Summary: Bootstrap failure on MinGW building ggc-page.c Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: craig.pow...@gmail.com Bootstrap is failing in stage 3 with the following error: ../../gcc-4.8-20130203/gcc/ggc-page.c: In function 'void ggc_print_statistics()' : ../../gcc-4.8-20130203/gcc/ggc-page.c:2174:31: error: unknown conversion type ch aracter 'l' in format [-Werror=format=] G.stats.total_overhead); ^ ../../gcc-4.8-20130203/gcc/ggc-page.c:2174:31: error: too many arguments for for mat [-Werror=format-extra-args] (and several more identical errors on the subsequent lines) File was attempted to compile as: /mingw/src/gcc-build/./prev-gcc/xg++ -B/mingw/src/gcc-build/./prev-gcc/ -B/usr/l ocal/i686-pc-mingw32/bin/ -nostdinc++ -B/mingw/src/gcc-build/prev-i686-pc-mingw3 2/libstdc++-v3/src/.libs -B/mingw/src/gcc-build/prev-i686-pc-mingw32/libstdc++-v 3/libsupc++/.libs -I/mingw/src/gcc-build/prev-i686-pc-mingw32/libstdc++-v3/inclu de/i686-pc-mingw32 -I/mingw/src/gcc-build/prev-i686-pc-mingw32/libstdc++-v3/incl ude -I/mingw/src/gcc-4.8-20130203/libstdc++-v3/libsupc++ -L/mingw/src/gcc-build/ prev-i686-pc-mingw32/libstdc++-v3/src/.libs -L/mingw/src/gcc-build/prev-i686-pc- mingw32/libstdc++-v3/libsupc++/.libs -c -g -O2 -D__USE_MINGW_ACCESS -Wno-pedan tic-ms-format -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwin d-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-at tribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -W error -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.8-20130203/gcc -I../../gcc-4.8-201 30203/gcc/. -I../../gcc-4.8-20130203/gcc/../include -I../../gcc-4.8-20130203/gcc /../libcpp/include -I/mingw/src/gcc-build/./gmp -I/mingw/src/gcc-4.8-20130203/gm p -I/mingw/src/gcc-build/./mpfr -I/mingw/src/gcc-4.8-20130203/mpfr -I/mingw/src/ gcc-4.8-20130203/mpc/src -I../../gcc-4.8-20130203/gcc/../libdecnumber -I../../g cc-4.8-20130203/gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc-4.8-201302 03/gcc/../libbacktrace../../gcc-4.8-20130203/gcc/ggc-page.c -o ggc-page.o Operating system is Windows 7 / x64. System compiler is gcc 4.7.2, target mingw32. prev-gcc/xg++ version is, $ ./prev-gcc/xg++ -v Using built-in specs. COLLECT_GCC=C:\MinGW\src\gcc-build\prev-gcc\xg++.exe Target: i686-pc-mingw32 Configured with: ../gcc-4.8-20130203/configure --enable-languages=c,fortran,c++ --enable-checking=release Thread model: win32 gcc version 4.8.0 20130203 (experimental) (GCC)
[Bug bootstrap/56227] Bootstrap failure on MinGW building ggc-page.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56227 --- Comment #2 from Craig Powers 2013-02-06 18:42:58 UTC --- (In reply to comment #1) > Created attachment 29374 [details] > proposed patch to use HOST_LONG_LONG_FORMAT > > Please try to bootstrap with the attached patch. That fixes the error I had, thanks! It's still going right now, I'll add another update when it's done.
[Bug bootstrap/56227] Bootstrap failure on MinGW building ggc-page.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56227 --- Comment #3 from Craig Powers 2013-02-06 18:50:34 UTC --- There's another one on line 14622 of gcc/config/i386/i386.c.
[Bug bootstrap/56227] Bootstrap failure on MinGW building ggc-page.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56227 --- Comment #4 from Craig Powers 2013-02-06 18:54:39 UTC --- (In reply to comment #3) > There's another one on line 14622 of gcc/config/i386/i386.c. Doing the same substitution as in ggc-page.c fixes it.
[Bug bootstrap/56227] Bootstrap failure on MinGW building ggc-page.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56227
--- Comment #5 from Craig Powers 2013-02-06
19:03:10 UTC ---
../../gcc-4.8-20130203/gcc/lto/lto.c: In function 'void
lto_resolution_read(spla
y_tree, FILE*, lto_file*)':
../../gcc-4.8-20130203/gcc/lto/lto.c:2229:33: error: unknown conversion type
cha
racter 'I' in format [-Werror=format=]
" not in object file", id);
^
The full line is,
internal_error ("resolution sub id " HOST_WIDE_INT_PRINT_HEX_PURE
" not in object file", id);
Given that it's an internal error, I'm going to do a workaround so it will
still build for me.
[Bug bootstrap/56227] Bootstrap failure on MinGW building ggc-page.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56227
--- Comment #7 from Craig Powers 2013-02-06
20:19:15 UTC ---
(In reply to comment #6)
> (In reply to comment #5)
> > ../../gcc-4.8-20130203/gcc/lto/lto.c: In function 'void
> > lto_resolution_read(spla
> > y_tree, FILE*, lto_file*)':
> > ../../gcc-4.8-20130203/gcc/lto/lto.c:2229:33: error: unknown conversion type
> > cha
> > racter 'I' in format [-Werror=format=]
> > " not in object file", id);
> > ^
> >
> > The full line is,
> > internal_error ("resolution sub id " HOST_WIDE_INT_PRINT_HEX_PURE
> > " not in object file", id);
> >
> > Given that it's an internal error, I'm going to do a workaround so it will
> > still build for me.
>
> I don't see anything wrong with the above HOST_WIDE_INT_PRINT_HEX_PURE
> definition. Does this hints and some MinGW specific problem in type checking?
>
> (I don't have access to MinGW platform, someone else should look a this
> problem.)
I have no idea, personally. I'm willing to try out proposed fixes for any
issues, as long as I can run it in the background and not eat up time I should
be spending getting other work done.
[Bug fortran/49111] Unnecessary warning for private interfaces having the BIND(C) attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49111 Craig Powers changed: What|Removed |Added CC||craig.powers at gmail dot ||com --- Comment #3 from Craig Powers 2012-10-12 20:53:53 UTC --- I see the accessibility denoted by PRIVATE/PUBLIC as conceptually different from the accessibility denoted by BIND(C). In addition to the fact that BIND(C) does not distinguish an import from an export, there is also the consideration that one might wish to hide the C-callable routine (marked with BIND(C)) from other Fortran code by also marking it PRIVATE. I'm in the process of producing a Fortran interface to a C library, and I find that there are some instances where I want to declare the import as PRIVATE and then provide a wrapper routine to take care of the Fortran-to-C stuff that is mechanical e.g. converting a Fortran array. Because my Fortran is a little rusty, and this is my first time making any extended use of the BIND(C) features, the warning made me concerned that I hadn't accomplished what I intended to accomplish. I see this warning as far more likely to be a spurious complaint about valid and intended usage than to be a useful hint about something unintended.
[Bug fortran/47260] New: DLLEXPORT attribute requires additional capabilities to be useful
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47260 Summary: DLLEXPORT attribute requires additional capabilities to be useful Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: craig.pow...@gmail.com With the following mingw gfortran package: Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=c:/program files/gfortran/bin/../libexec/gcc/i586-pc-mingw32 /4.6.0/lto-wrapper.exe Target: i586-pc-mingw32 Configured with: ../gcc-trunk/configure --prefix=/mingw --enable-languages=c,for tran --with-gmp=/home/brad/gfortran/dependencies --disable-werror --enable-threa ds --disable-nls --build=i586-pc-mingw32 --enable-libgomp --disable-shared --dis able-win32-registry --with-dwarf2 --disable-sjlj-exceptions --enable-lto Thread model: win32 gcc version 4.6.0 20101201 (experimental) [trunk revision 167359] (GCC) If I build a standalone function declared as: INTEGER FUNCTION test() !GCC$ ATTRIBUTES STDCALL, DLLEXPORT :: test test = 1 END FUNCTION test and build it with: gfortran -std=f2008 -march=native -c bug.f90 The result is: bug.f90:1:0: error: external linkage required for symbol 'test' because of 'dlle xport' attribute I believe that either something is not being set correctly for symbol 'test', or an additional attribute needs to be made available so that 'test' can be marked correctly. In the absence of this, the manual should clearly state that dllexport cannot be applied to procedures in Windows.
[Bug fortran/47260] DLLEXPORT attribute requires additional capabilities to be useful
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47260 --- Comment #1 from Craig Powers 2011-01-11 23:12:55 UTC --- I've also tried using dlltool and a .def file to coerce my procedure into being exported, with no luck. Does gfortran not support exporting a function?
[Bug fortran/47260] DLLEXPORT: TREE_PUBLIC for procedures lost between trans-decl.c and tree.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47260 --- Comment #6 from Craig Powers 2011-01-12 14:11:28 UTC --- I also was unable to get the procedure into a DLL with omission of DLLEXPORT, instead attempting to get it in using a .DEF file and either gfortran or dlltool. I'm not sure if that reflects another aspect of the same problem. If I do this: gfortran -shared -o test.dll test.def test.o typedata.o I get: Cannot export _compute_load_...@28: symbol not defined But if I look at the output of nm test.o, I see: T _compute_load_...@28
[Bug fortran/47260] DLLEXPORT: TREE_PUBLIC for procedures lost between trans-decl.c and tree.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47260 --- Comment #7 from Craig Powers 2011-01-13 16:59:18 UTC --- (In reply to comment #6) > I also was unable to get the procedure into a DLL with omission of DLLEXPORT, > instead attempting to get it in using a .DEF file and either gfortran or > dlltool. I'm not sure if that reflects another aspect of the same problem. If > I do this: > gfortran -shared -o test.dll test.def test.o typedata.o > > I get: > Cannot export _compute_load_cpd@28: symbol not defined > > But if I look at the output of nm test.o, I see: > T _compute_load_cpd@28 Also, -fpic/-fPIC produces the same result.
[Bug fortran/47260] DLLEXPORT: TREE_PUBLIC for procedures lost between trans-decl.c and tree.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47260 --- Comment #11 from Craig Powers 2011-01-13 19:56:11 UTC --- (In reply to comment #10) > > Please confirm that it works. (I know that it unfortunately might take a few > days until a newer MinGW build becomes available, unless you build GCC > yourself.) I'm having a go at building gcc from source. I'll let you know how it goes.
[Bug fortran/47260] DLLEXPORT: TREE_PUBLIC for procedures lost between trans-decl.c and tree.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47260 --- Comment #12 from Craig Powers 2011-01-14 00:10:29 UTC --- Rather more tricky to get gcc built in mingw than I would have liked, but... it's all fixed. I can export with DLLEXPORT or with a .def file. Thanks for the quick fix!
[Bug bootstrap/37888] make install fails attempting to build gcc/intl.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37888 --- Comment #2 from Craig Powers 2010-09-29 13:42:58 UTC --- I'll try to find time to try again. I'm no longer at school as I was when I reported the bug originally; I still have access to the systems I was using then, but I have to do it remotely and I don't have a whole lot of time. On Sun, Sep 26, 2010 at 8:29 AM, rwild at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37888 > > Ralf Wildenhues changed: > > What|Removed |Added > > > Status|UNCONFIRMED |WAITING > Last reconfirmed||2010.09.26 13:29:43 > date|| > Ever Confirmed|0 |1 > > --- Comment #1 from Ralf Wildenhues 2010-09-26 > 13:29:43 UTC --- > Can you reconfirm whether this still happens for you with current sources? > > The weird thing about this is that 'make install' should not cause any > recompilations nor relinking at all, at least not after a successful > 'make'. > Did you maybe not run 'make' or 'make all' beforehand? > > If this still happens for you, my next best bet would be timing issues, > such as > your build system and the AFS server not having synchronized clocks. > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You reported the bug. >
[Bug bootstrap/37888] make install fails attempting to build gcc/intl.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37888 --- Comment #2 from Craig Powers 2010-09-29 13:42:58 UTC --- I'll try to find time to try again. I'm no longer at school as I was when I reported the bug originally; I still have access to the systems I was using then, but I have to do it remotely and I don't have a whole lot of time. On Sun, Sep 26, 2010 at 8:29 AM, rwild at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37888 > > Ralf Wildenhues changed: > > What|Removed |Added > > > Status|UNCONFIRMED |WAITING > Last reconfirmed||2010.09.26 13:29:43 > date|| > Ever Confirmed|0 |1 > > --- Comment #1 from Ralf Wildenhues 2010-09-26 > 13:29:43 UTC --- > Can you reconfirm whether this still happens for you with current sources? > > The weird thing about this is that 'make install' should not cause any > recompilations nor relinking at all, at least not after a successful > 'make'. > Did you maybe not run 'make' or 'make all' beforehand? > > If this still happens for you, my next best bet would be timing issues, > such as > your build system and the AFS server not having synchronized clocks. > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You reported the bug. > --- Comment #3 from Craig Powers 2010-09-29 13:43:02 UTC --- I'll try to find time to try again. I'm no longer at school as I was when I reported the bug originally; I still have access to the systems I was using then, but I have to do it remotely and I don't have a whole lot of time. On Sun, Sep 26, 2010 at 8:29 AM, rwild at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37888 > > Ralf Wildenhues changed: > > What|Removed |Added > > > Status|UNCONFIRMED |WAITING > Last reconfirmed||2010.09.26 13:29:43 > date|| > Ever Confirmed|0 |1 > > --- Comment #1 from Ralf Wildenhues 2010-09-26 > 13:29:43 UTC --- > Can you reconfirm whether this still happens for you with current sources? > > The weird thing about this is that 'make install' should not cause any > recompilations nor relinking at all, at least not after a successful > 'make'. > Did you maybe not run 'make' or 'make all' beforehand? > > If this still happens for you, my next best bet would be timing issues, > such as > your build system and the AFS server not having synchronized clocks. > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You reported the bug. >
[Bug bootstrap/37888] make install fails attempting to build gcc/intl.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37888 --- Comment #3 from Craig Powers 2010-09-29 13:43:02 UTC --- I'll try to find time to try again. I'm no longer at school as I was when I reported the bug originally; I still have access to the systems I was using then, but I have to do it remotely and I don't have a whole lot of time. On Sun, Sep 26, 2010 at 8:29 AM, rwild at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37888 > > Ralf Wildenhues changed: > > What|Removed |Added > > > Status|UNCONFIRMED |WAITING > Last reconfirmed||2010.09.26 13:29:43 > date|| > Ever Confirmed|0 |1 > > --- Comment #1 from Ralf Wildenhues 2010-09-26 > 13:29:43 UTC --- > Can you reconfirm whether this still happens for you with current sources? > > The weird thing about this is that 'make install' should not cause any > recompilations nor relinking at all, at least not after a successful > 'make'. > Did you maybe not run 'make' or 'make all' beforehand? > > If this still happens for you, my next best bet would be timing issues, > such as > your build system and the AFS server not having synchronized clocks. > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You reported the bug. >
