[Bug c++/92442] New: Compiling Boost.Spirit.X3 code uses exuberant amount of RAM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92442 Bug ID: 92442 Summary: Compiling Boost.Spirit.X3 code uses exuberant amount of RAM Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vanboxem.ruben at gmail dot com Target Milestone: --- Created attachment 47207 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47207&action=edit preprocessed source for reproduction Compiling the attached preprocessed code like this: g++ -pedantic-errors -Wextra -Wconversion -Winit-self -Wmissing-include-dirs -Wstrict-aliasing -Werror -ffunction-sections -fdata-sections -gsplit-dwarf -g -fPIE -std=c++17 -MD -MT test.o test.ii consumes a peak amount of 7227,6 MB of RAM. Subsequent assembler call uses 2283 MB of RAM. Clang 9 uses 4941 MB of RAM, which is also quite a lot, but almost 2 GB less.
[Bug debug/92442] Compiling Boost.Spirit.X3 code uses exuberant amount of RAM with -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92442 --- Comment #2 from Ruben Van Boxem --- I hit the submit button too early, I was still removing commandline options. Indeed the -gsplit-dwarf option seems the culprit here. I added it to decrease library link times (seems like it did at least something in that directionà, guess I should remove it again to prevent OOM when compiling until this is fixed.
[Bug c++/56926] New: Crash (without ICE) while compiling Boost.Math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926 Bug #: 56926 Summary: Crash (without ICE) while compiling Boost.Math Classification: Unclassified Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: vanboxem.ru...@gmail.com When compiling the file libs\math\build\..\src\tr1\assoc_laguerre.cpp from Boost 1.52.0 or 1.53.0 (perhaps any other version is affected too), GCC causes a dirty crash providing me no way of getting a sensible backtrace or providing a preprocessed source for reproduction. The compile command is: "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -mthreads -fvisibility=hidden -Winvalid-pch -DBOOST_ALL_NO_LIB=1 -DBOOST_BUILD_PCH_ENABLED -I"bin.v2\libs\math\build\gcc-mingw-4.8.1\debug\link-static\threading-multi\..\src\tr1" -I"." -I"libs\math\src\tr1" -c -o "bin.v2\libs\math\build\gcc-mingw-4.8.1\debug\link-static\threading-multi\assoc_laguerre.o" "libs\math\build\..\src\tr1\assoc_laguerre.cpp" This does not happen with GCC 4.7. If there is anything I can try to give more output, please let me know. The crash happens before -save-temps outputs anything. The binaries are for Windows 64-bit and available here (but require Win64, I haven't tested the Linux binaries built with the exact same build process): http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/gcc-4.8-release/x86_64-w64-mingw32-gcc-4.8.0-win64_rubenvb.7z/download
[Bug c++/56859] alignas() fails in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56859
Ruben Van Boxem changed:
What|Removed |Added
CC||vanboxem.ruben at gmail dot
||com
--- Comment #3 from Ruben Van Boxem
2013-04-24 19:09:57 UTC ---
Another simple case that fails (even without instantiation) is:
template
struct aligned_storage
{
using type = struct { alignas(alignment) unsigned char data[size]; };
};
from http://en.cppreference.com/w/cpp/types/aligned_storage
The error is:
error: requested alignment is not an integer constant
using type = struct { alignas(alignment) unsigned char data[size]; };
^
[Bug target/57225] New: x64 Windows seh GCC should define __USING_SEH_EXCEPTIONS like sjlj and dw2 builds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57225 Bug #: 57225 Summary: x64 Windows seh GCC should define __USING_SEH_EXCEPTIONS like sjlj and dw2 builds Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: vanboxem.ru...@gmail.com This is required because two functions: __register_frame __deregister_frame are not present in libgcc-seh.
[Bug c++/56926] Crash (without ICE) while compiling Boost.Math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926 --- Comment #2 from Ruben Van Boxem --- As bugzilla has a file size limit of 1000kB, here's a link to my dropbox containing a zipped gch file that I believe is responsible for the crash. https://dl.dropboxusercontent.com/u/58715553/pch.hpp.gch.zip This file was created with GCC 4.8.1 20130425. Alternatively (if you have a 64-bit Windows (virtual)box) just download http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/gcc-4.8-release/x86_64-w64-mingw32-gcc-4.8.0-win64_rubenvb.7z and Boost http://sourceforge.net/projects/boost/files/boost/1.53.0/ and add the mingw64/bin extracted directory to PATH, and run bootstrap toolset=gcc b2 toolset=gcc which will slowly compile Boost up to Boost.Math, which will result in several crashes.
[Bug regression/54314] New: undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstream, std::allocator >'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314 Bug #: 54314 Summary: undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstream, std::allocator >' Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: regression AssignedTo: unassig...@gcc.gnu.org ReportedBy: vanboxem.ru...@gmail.com I'm trying to build GCC 4.8 for x86_64-w64-mingw32. I have a cross-compiler but I cannot build my C++ code with it. The error is exactly the same as the one detailed here: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01142.html I seem to be unable to detect when exactly this problem shows up, but I run into it when building PPL-0.12.1 with the Linux->Windows cross-compiler: /bin/bash ../../libtool --tag=CXX --mode=link x86_64-w64-mingw32-g++ -g -O2 -frounding-math -W -Wall -o ppl_pips.exe ppl_pips.o ../../src/libppl.la ../../utils/libppl_utils.a -L/home/ruben/mingw-w64/prereq/x86_64-w64-mingw32/install/lib -lgmpxx -lgmp libtool: link: x86_64-w64-mingw32-g++ -g -O2 -frounding-math -W -Wall -o ppl_pips.exe ppl_pips.o ../../src/.libs/libppl.a -L/home/ruben/mingw-w64/prereq/x86_64-w64-mingw32/install/lib ../../utils/libppl_utils.a /home/ruben/mingw-w64/prereq/x86_64-w64-mingw32/install/lib/libgmpxx.a /home/ruben/mingw-w64/prereq/x86_64-w64-mingw32/install/lib/libgmp.a ppl_pips.o: In function `basic_istream': /home/ruben/mingw-w64/linux64mingw64/mingw64/x86_64-w64-mingw32/include/c++/4.8.0/istream:609: undefined reference to `construction vtable for std::istream-in-std::basic_istringstream, std::allocator >' /home/ruben/mingw-w64/linux64mingw64/mingw64/x86_64-w64-mingw32/include/c++/4.8.0/istream:609: undefined reference to `construction vtable for std::istream-in-std::basic_istringstream, std::allocator >' ppl_pips.o: In function `~basic_istream': /home/ruben/mingw-w64/linux64mingw64/mingw64/x86_64-w64-mingw32/include/c++/4.8.0/istream:106: undefined reference to `construction vtable for std::istream-in-std::basic_istringstream, std::allocator >' ppl_pips.o: In function `basic_istream': /home/ruben/mingw-w64/linux64mingw64/mingw64/x86_64-w64-mingw32/include/c++/4.8.0/istream:609: undefined reference to `construction vtable for std::istream-in-std::basic_istringstream, std::allocator >' /home/ruben/mingw-w64/linux64mingw64/mingw64/x86_64-w64-mingw32/include/c++/4.8.0/istream:609: undefined reference to `construction vtable for std::istream-in-std::basic_istringstream, std::allocator >' ppl_pips.o:/home/ruben/mingw-w64/linux64mingw64/mingw64/x86_64-w64-mingw32/include/c++/4.8.0/istream:106: more undefined references to `construction vtable for std::istream-in-std::basic_istringstream, std::allocator >' follow collect2: error: ld returned 1 exit status This effectively makes g++ useless. I seem to remember only non-debug builds are affected.
[Bug bootstrap/53912] [4.7/4.8 Regression] bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53912 Ruben Van Boxem changed: What|Removed |Added CC||ktietz at gcc dot gnu.org, ||vanboxem.ruben at gmail dot ||com --- Comment #18 from Ruben Van Boxem 2012-08-18 13:12:54 UTC --- This is still an issue on current GCC trunk.
[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstream, std::allocator >'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314 --- Comment #10 from Ruben Van Boxem 2012-09-25 08:11:23 UTC --- I can confirm adding the exports gets rid of the undefined references.
[Bug other/55165] New: Build failure for x86_64-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55165 Bug #: 55165 Summary: Build failure for x86_64-w64-mingw32 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: vanboxem.ru...@gmail.com Building GCC master on 1 November 2012 for build=x86_64-gnu-linux host=x86_64-w64-mingw32 results in this error during the make all-target-libgcc step: /home/ruben/mingw-w64/src/gcc/gcc/stmt.c: In function 'void compute_cases_per_edge(gimple)': /home/ruben/mingw-w64/src/gcc/gcc/stmt.c:2064:54: error: cast from 'void*' to 'long int' loses precision [-fpermissive] case_edge->aux = (void *)((long)(case_edge->aux) + 1); ^ /home/ruben/mingw-w64/src/gcc/gcc/stmt.c:2064:59: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] case_edge->aux = (void *)((long)(case_edge->aux) + 1); ^ /home/ruben/mingw-w64/src/gcc/gcc/stmt.c: In function 'void expand_case(gimple)': /home/ruben/mingw-w64/src/gcc/gcc/stmt.c:2179:57: error: cast from 'void*' to 'long int' loses precision [-fpermissive] case_edge->probability / (long)(case_edge->aux), ^ This is due to the fact that a pointer is not an int.
[Bug bootstrap/47055] New: "make profiledbootstrap" fails on MSYS/mingw-w64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47055 Summary: "make profiledbootstrap" fails on MSYS/mingw-w64 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: vanboxem.ru...@gmail.com When doing a "make profiledbootstrap", there are two things that go wrong: 1. All "mkdir" commands contain "/:\" and fail. Example >profiling:/M:\Development\msys\home\Ruben\mingw64\build64\gcc\libiberty/pex-common.gcda:Skip >profiling:/M::Cannot create directory 2. Random errors (which are caused by #1?) make the stage profile fail. Doing a normal "make" (which does the stage 1, 2, and 3 + compare 2=?3) works as expected. MSYS can handle "m:/path/to/file" and "/m/path/to/file" and any mix of capitals and non-capitals. It can't however, handle "/m:/path/to/file", which is a mix of the two.
[Bug target/47178] New: QtWebKit miscompiled for x86_64-*-mingw*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47178 Summary: QtWebKit miscompiled for x86_64-*-mingw* Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: vanboxem.ru...@gmail.com The 64-bit runtime provided by the mingw-w64 project together with the GCC toolchain can compile Qt completely (with no known issues as far as I know) with GCC 4.4 (earlier versions don't have the necessary support for x64 Windows). Only with GCC 4.5 and 4.6, issues arise in the form of runtime errors when QtWebKit is compiled for x86_64-w64-mingw32. I have created a WebKit bug report here: https://bugs.webkit.org/show_bug.cgi?id=44052 The report has a stack backtrace of a Qt application (Assistant) showing the crash. All binaries are compiled with "-g3" (highest debug level). Optimization level (none or -O2) does not change the fact that the app crashes. Looking at the backtrace, the problem is in WebKit somewhere, but as no other platforms show this problem, the issue must be toolchain-side somewhere. A correct binary is produced using patched (for Win64) 4.4 GCC toolchains.
[Bug target/47178] QtWebKit miscompiled for x86_64-*-mingw*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47178 --- Comment #2 from Ruben Van Boxem 2011-01-11 12:35:37 UTC --- I'm sorry, I cannot make a testcase for this because I don't know the exact cause of the problem. Webkit is huge, and highly optimised and above my understanding... I have provided all the information that I can, and tested several different (Webkit) build configurations. Sorry.
[Bug c++/56038] declarations in xmmintrin.h conflict with mingw-w64 intrin.h in c++ mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56038 Ruben Van Boxem changed: What|Removed |Added CC||vanboxem.ruben at gmail dot com --- Comment #7 from Ruben Van Boxem --- Can this patch please be either applied or rejected for a valid reason? As far as I understand, something might be "broken" in the compiler wrt inlining: http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00059.html which affects this issue indirectly. Nearly three years have passed since the original discussion.
[Bug bootstrap/50139] New: in-tree GMP/PPL/CLooG is misconfigured
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50139 Bug #: 50139 Summary: in-tree GMP/PPL/CLooG is misconfigured Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: vanboxem.ru...@gmail.com Created attachment 25062 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25062 Patch When building the Graphite prereqs in-tree mkdir $GCC_SRC/ppl mkdir $GCC_SRC/cloog ln -s $SRC/ppl-0.11.2/* $GCC_SRC/ppl ln -s $SRC/cloog)0.16.3/* $GCC_SRC/cloog All subdirectories are detected well, but as some may or may not know, GMP in tree does not play well with PPL/CLooG in tree, and CLooG(-isl) does not work well in-tree. Attached is a patch to add the necessary paths in the various places, using existing infrastructure. Some notes before you ask yourself what I did: - PPL-0.11.2 has a configure option --with-gmp-build, but it does not seem to work as MPFR/MPC's options do (ie only the linker uses it, the include path still needed to be set by CPPFLAGS). My way is a bit more secure for older versions of PPL as well. - CLooG has an half-documented feature (not in the online docs, but you get it from "configure --help"): --with-gmp-builddir, which is equally broken, as the C compiler test tries to link with gmp. - PPL also needs both the gmp source as gmp build path, because it checks for gmpxx.h, which is not in the build directory, but gmpxx.h includes gmp.h, which is only present in the build directory. The 4.5 and 4.6 branches also work with the CLooG/PPL versions I used here (if built out-of-tree) so a fix for those branches would be very helpful as well.
[Bug bootstrap/50139] in-tree GMP/PPL/CLooG is misconfigured
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50139 --- Comment #1 from Ruben Van Boxem 2011-08-21 10:47:56 UTC --- Created attachment 25064 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25064 patch for 4.5 branch Attached congruent patch for 4.5 branch
[Bug bootstrap/50139] in-tree GMP/PPL/CLooG is misconfigured
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50139 --- Comment #2 from Ruben Van Boxem 2011-08-21 10:48:32 UTC --- Created attachment 25065 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25065 Patch for 4.6 branch Attached congruent patch for 4.6 branch.
[Bug bootstrap/50156] New: in-tree CLooG is not picked up by toplevel configure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50156
Bug #: 50156
Summary: in-tree CLooG is not picked up by toplevel configure
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vanboxem.ru...@gmail.com
Created attachment 25078
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25078
gcc/config.log
With the patches attached to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50139
I can successfully build GCC with in-tree GMP/MPFR/MPC/PPL/CLOOG for
--host=x86_64-linux-gnu --target=*-w64-mingw32 --build=x86_64-linux-gnu
--host=*-w64-mingw32 --target=*-w64-mingw32 --build=x86_64-linux-gnu
I can see in the build logs all libs are built in tree, but when linking the
cc1 executable, the cloog libs are missing. Searching for the "no-graphite"
error message ("sorry, unimplemented...") I found that HAVE_cloog is not
properly defined, which is a symptom of clooglibs not being properly filled in
in gcc/configure
Attached is gcc/config.log
[Bug bootstrap/50156] in-tree CLooG is not picked up by toplevel configure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50156 --- Comment #1 from Ruben Van Boxem 2011-08-22 19:07:38 UTC --- Created attachment 25079 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25079 "make all-gcc" log where -lcloog and friends are missing for cc1 Attached build log
[Bug bootstrap/50156] in-tree CLooG is not picked up by toplevel configure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50156 --- Comment #2 from Ruben Van Boxem 2011-08-24 19:26:55 UTC --- Created attachment 25090 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25090 Patch to allow a non-bootstrap compiler to build with in tree prereqs for graphite Attached is a full patch (including manual changes to generated files) that allow for in-tree CLooG (isl) to be used to build a GCC with Graphite. This patch was made against GCC 4.6 (SVN) and should apply cleanly for testing purposes. I have not "ported" the configure bit for CLooG to configure.ac, the rest (in configure and makefile.in) should be matched by makefile.def and configure.ac changes.
[Bug bootstrap/50156] in-tree CLooG is not picked up by toplevel configure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50156 Ruben Van Boxem changed: What|Removed |Added Attachment #25090|0 |1 is obsolete|| --- Comment #3 from Ruben Van Boxem 2011-08-24 20:15:20 UTC --- Created attachment 25093 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25093 Patch to allow a non-bootstrap compiler to build with in tree prereqs for graphite Corrected small issues with ppl-watchdog (enabled it regardless for an intree build; this would break an out-of tree ppl without libpwl though: it's hacky) The problem is that in-tree ppl should be configured with --disable-watchdog if $enable_watchdog is not requested.
[Bug bootstrap/50229] New: [4.7 Regression] Can't cross compile for i686-apple-darwin10 from x86_64-redhat_linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50229 Bug #: 50229 Summary: [4.7 Regression] Can't cross compile for i686-apple-darwin10 from x86_64-redhat_linux Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: vanboxem.ru...@gmail.com Created attachment 25130 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25130 toplevel config.log I am cross-compiling a HOST=i686-apple-darwin10 BUILD=x86_64-redhat-linux TARGET=i686-w64_mingw32 cross-compiler. GCC 4.6 (and most probably 4.5) work fine, GCC 4.7 misconfigures and results in a build failure. Attached is top-level toplevel config.log, more to follow.
[Bug bootstrap/50229] [4.7 Regression] Can't cross compile for i686-apple-darwin10 from x86_64-redhat_linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50229 Ruben Van Boxem changed: What|Removed |Added Attachment #25130|0 |1 is obsolete|| --- Comment #1 from Ruben Van Boxem 2011-08-29 18:22:32 UTC --- Created attachment 25131 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25131 toplevel config.log Add proper toplevel config.log
[Bug bootstrap/50229] [4.7 Regression] Can't cross compile for i686-apple-darwin10 from x86_64-redhat_linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50229 --- Comment #2 from Ruben Van Boxem 2011-08-29 18:23:12 UTC --- Created attachment 25132 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25132 gcc/config.log Attached gcc/config.log
[Bug bootstrap/50229] [4.7 Regression] Can't cross compile for i686-apple-darwin10 from x86_64-redhat_linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50229
--- Comment #3 from Ruben Van Boxem
2011-08-29 18:26:10 UTC ---
Created attachment 25133
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25133
Compressed build log detailing failure
Attached build log. ("make all-gcc" output)
[Bug bootstrap/50229] [4.7 Regression] Can't cross compile for i686-apple-darwin10 from x86_64-redhat_linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50229 --- Comment #4 from Ruben Van Boxem 2011-08-29 18:30:29 UTC --- For those wondering how on Earth I am cross-compiling for Mac, see http://build1.openftd.org/fedora-cross-darwinx/ This is a cross toolchain for Fedora, which works quite well. The version used in the build is: Using built-in specs. Target: i686-apple-darwin10 Configured with: ../configure --prefix=/usr --bindir=/usr/bin --includedir=/usr/include --libdir=/usr/lib64 --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=i686-apple-darwin10 --enable-languages=c,objc,c++,obj-c++ --with-sysroot=/usr/darwinx/SDKs/MacOSX10.5.sdk --with-as=/usr/bin/darwinx-as --with-ld=/usr/bin/darwinx-ld --enable-static --enable-shared --disable-nls --enable-multilib --enable-libssp Thread model: posix gcc version 4.2.1 (Apple Inc. build 5664)
[Bug bootstrap/50229] [4.7 Regression] Can't cross compile for i686-apple-darwin10 from x86_64-redhat_linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50229 --- Comment #7 from Ruben Van Boxem 2011-09-19 19:28:48 UTC --- I'm still experiencing the same behavior. I don't think the darwinx toolchain has the problems you say? Why do you think it uses a Darwin9 system framework and headers? It has GCC 4.2.1 and the Mac OS X 10.5 SDK, which are all pretty Darwin10 as far as I can see. Something changed in 4.6 vs 4.7. I have sys/malloc.h , objc/malloc.h, and malloc/malloc.h. Somehow, HAVE_MALLOC_H is being wrongfully defined to 1 when it should be 0. auto-host.h has the define commented out. auto-build.h has it defined. These are the same for GCC 4.6. So the problem must lie elsewhere... I noticed the gengtype-lex.o object file is build with i686-apple-darwin10-gcc for GCC 4.7, and (Linux) gcc for GCC 4.6. This cannot be intended behavior.
[Bug tree-optimization/10980] vararg functions are not inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10980 Ruben Van Boxem changed: What|Removed |Added CC||vanboxem.ruben at gmail dot ||com --- Comment #7 from Ruben Van Boxem 2011-09-23 13:34:52 UTC --- This problem popped up when compiling LLVM's libc++: M:\Development\Source\libc++\src\locale.cpp:1:0: warning: -fPIC ignored for target (all code is position independent) [enabled by default] M:\Development\Source\libc++\include/locale: In function 'int std::__1::__asprintf_l(char**, _locale_t, const char*, ...)': M:\Development\Source\libc++\include/locale:372:5: sorry, unimplemented: function 'int std::__1::__asprintf_l(char**, _locale_t, const char*, ...)' can never be inlined because it uses variable argument lists M:\Development\Source\libc++\include/locale: In function 'int std::__1::__sprintf_l(char*, _locale_t, const char*, ...)': M:\Development\Source\libc++\include/locale:344:5: sorry, unimplemented: function 'int std::__1::__sprintf_l(char*, _locale_t, const char*, ...)' can never be inlined because it uses variable argument lists M:\Development\Source\libc++\include/locale: In function 'int std::__1::__snprintf_l(char*, size_t, _locale_t, const char*, ...)': M:\Development\Source\libc++\include/locale:358:5: sorry, unimplemented: function 'int std::__1::__snprintf_l(char*, size_t, _locale_t, const char*, ...)' can never be inlined because it uses variable argument lists M:\Development\Source\libc++\include/locale: In function 'int std::__1::__sscanf_l(const char*, _locale_t, const char*, ...)': M:\Development\Source\libc++\include/locale:386:5: sorry, unimplemented: function 'int std::__1::__sscanf_l(const char*, _locale_t, const char*, ...)' can never be inlined because it uses variable argument lists The code can be found here: http://llvm.org/svn/llvm-project/libcxx/trunk/include/locale
[Bug tree-optimization/10980] vararg functions are not inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10980 --- Comment #9 from Ruben Van Boxem 2011-09-23 13:46:27 UTC --- Current Clang compiled everything without a hitch. It might ignore the attribute, I haven't checked. Perhaps this error should be made a warning?
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773 Ruben Van Boxem changed: What|Removed |Added CC||vanboxem.ruben at gmail dot ||com --- Comment #117 from Ruben Van Boxem 2011-09-28 12:14:38 UTC --- Thanks for the effort! Any chance of this being backported to older branches? Seems quite useful for the future.
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773 --- Comment #120 from Ruben Van Boxem 2011-09-28 13:58:03 UTC --- OK, somewhat understandable to keep evil legacy code compiling. Last plea for Standards conformance: What about only setting the correct define if -std=c++89/03/0x/11 is passed and keeping the old behavior for -std=gnu++*?
[Bug tree-optimization/10980] vararg functions are not inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10980 --- Comment #11 from Ruben Van Boxem 2011-10-17 18:44:39 UTC --- (In reply to comment #10) > I bet it just ignores the attribute that is not how the attribute is > supposed to work. > > We output error in this case intentionally (and warning in at the same > spot if function is declared inline and -Winline is given). > Functions marked always_inlined really ought to be always inlined and > attribute is supposed to be useable in the cases where compilation would > fail otherwise (such as SSE buitins). > > Our documentation is however not particularly clear here, perhaps it should > be updated... > > Honza Seeing that documentation is unclear (no mention of when errors or warnings are produced), and Qt Creator devs want to know what version of GCC started errorring on this, could you please let me know what GCC version started producing errors? Thanks!
[Bug target/50779] New: always_inline function fails to inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50779 Bug #: 50779 Summary: always_inline function fails to inline Classification: Unclassified Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: vanboxem.ru...@gmail.com Attached is a preprocessed source that fails to compile on GCC 4.5+, but works fine on GCC 4.4.7. This happens on all MinGW targets (*-pc-* and *-w64-*). I tested with GCC 4.4.7, 4.5, 4.6 and 4.7.
[Bug target/50779] always_inline function fails to inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50779 --- Comment #1 from Ruben Van Boxem 2011-10-18 18:43:39 UTC --- Created attachment 25547 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25547 Compile with "g++ -O[012] -c profileparser.ii" to trigger the error (preprocessed with x86_64-w64-mingw32) Added zipped preprocessed source.
[Bug target/50779] always_inline function fails to inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50779 --- Comment #3 from Ruben Van Boxem 2011-10-19 10:17:54 UTC --- Sorry about that: m:\Development\source\qtcreator\src\shared\proparser\profileparser.cpp: In member function 'void ProFileParser::leaveScope(ushort*&)': m:\Development\source\qtcreator\src\shared\proparser\profileparser.cpp:203:6: sorry, unimplemented: inlining failed in call to 'void ProFileParser::putBlockLen(ushort*&, uint)': function not inlinable m:\Development\source\qtcreator\src\shared\proparser\profileparser.cpp:813:31: sorry, unimplemented: called from here m:\Development\source\qtcreator\src\shared\proparser\profileparser.cpp:198:6: sorry, unimplemented: inlining failed in call to 'void ProFileParser::putTok(ushort*&, ushort)': function not inlinable m:\Development\source\qtcreator\src\shared\proparser\profileparser.cpp:816:38: sorry, unimplemented: called from here And yes, the error does go away if I comment out ProfileParser's "PROPARSER_EXPORT" qualifier.
[Bug target/50779] always_inline function fails to inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50779 --- Comment #5 from Ruben Van Boxem 2011-10-19 10:37:37 UTC --- There's this on msdn about inline and dllexport: http://msdn.microsoft.com/en-us/library/xa0d9ste.aspx On top of this, MSVC allows its __forceinline to be used in a dllexport context, so I would assume GCC could do the same thing in this case.
[Bug bootstrap/50229] [4.7 Regression] Can't cross compile for i686-apple-darwin10 from x86_64-redhat_linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50229 --- Comment #9 from Ruben Van Boxem 2011-10-26 12:49:43 UTC --- I received a build of a darwinx-ld binary from the darwinx toolchain maintainer that accepts the -no_compact_unwind option, and the problem has not gone away. Configure is either using the wrong headers for the build or configure is messing up.
[Bug libgcj/50895] New: Build failure in jni.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50895 Bug #: 50895 Summary: Build failure in jni.cc Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: libgcj AssignedTo: unassig...@gcc.gnu.org ReportedBy: vanboxem.ru...@gmail.com Building a x86_64-linux-gnu to i686-w64-mingw32 cross-compiler with --enable-libgcj, I get this build error: /bin/sh ./libtool --tag=CXX --mode=compile /home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/./gcc/xgcc -shared-libgcc -B/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/./gcc -nostdinc++ -L/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/i686-w64-mingw32/libstdc++-v3/src -L/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/i686-w64-mingw32/libstdc++-v3/src/.libs -L/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/lib -L/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/mingw/lib -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/include -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/mingw/include -B/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/bin/ -B/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/lib/ -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/include -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/sys-include -DHAVE_CONFIG_H -I. -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava -I./include -I./gcj -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava -Iinclude -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/include -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/classpath/include -Iclasspath/include -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/classpath/native/fdlibm -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/../boehm-gc/include -I../boehm-gc/include -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/libltdl -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/libltdl -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/.././libjava/../gcc -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/../zlib -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -ffloat-store -fomit-frame-pointer -Usun -fno-omit-frame-pointer -Wextra -Wall -D_GNU_SOURCE -DPREFIX="\"/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32\"" -DTOOLEXECLIBDIR="\"/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/lib/../lib\"" -DJAVA_HOME="\"/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32\"" -DBOOT_CLASS_PATH="\"/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/share/java/libgcj-4.6.3.jar\"" -DJAVA_EXT_DIRS="\"/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/share/java/ext\"" -DGCJ_ENDORSED_DIRS="\"/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/share/java/gcj-endorsed\"" -DGCJ_VERSIONED_LIBDIR="\"/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/lib/../lib/gcj-4.6.3-12\"" -DPATH_SEPARATOR="\":\"" -DECJ_JAR_FILE="\"\"" -DLIBGCJ_DEFAULT_DATABASE="\"/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/lib/../lib/gcj-4.6.3-12/classmap.db\"" -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL="\"gcj-4.6.3-12/classmap.db\"" -g -O2 -MT jni.lo -MD -MP -MF $depbase.Tpo -c -o jni.lo /home/ruben/mingw-w64/toolchain/src/gcc/libjava/jni.cc &&\ mv -f $depbase.Tpo $depbase.Plo libtool: compile: /home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/./gcc/xgcc -shared-libgcc -B/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/./gcc -nostdinc++ -L/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/i686-w64-mingw32/libstdc++-v3/src -L/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/i686-w64-mingw32/libstdc++-v3/src/.libs -L/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/lib -L/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/mingw/lib -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/include -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/mingw/include -B/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/bin/ -B/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/lib/ -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/include -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/sys-include -DHAVE_CONFIG_H -I. -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava -I./include -I./gcj -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava -Iinclude -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/include -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/classpath/include -Iclasspath/include -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/classpath/native/fdlibm -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/../boehm-g
[Bug c/50913] New: ICE: compiling libgfortran for i686-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50913 Bug #: 50913 Summary: ICE: compiling libgfortran for i686-w64-mingw32 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: vanboxem.ru...@gmail.com Created attachment 25662 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25662 Preprocessed source for file causing ICE I get an ICE compiling this: /home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/./gcc/xgcc -B/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/./gcc/ -L/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/lib -L/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/mingw/lib -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/include -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/mingw/include -B/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/bin/ -B/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/lib/ -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/include -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/sys-include -DHAVE_CONFIG_H -I. -I/home/ruben/mingw-w64/toolchain/src/gcc/libgfortran -iquote/home/ruben/mingw-w64/toolchain/src/gcc/libgfortran/io -I/home/ruben/mingw-w64/toolchain/src/gcc/libgfortran/../gcc -I/home/ruben/mingw-w64/toolchain/src/gcc/libgfortran/../gcc/config -I/home/ruben/mingw-w64/toolchain/src/gcc/libgfortran/../libquadmath -I../.././gcc -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections -g -O2 -mtune=core2 -fomit-frame-pointer -momit-leaf-frame-pointer -fgraphite-identity -floop-interchange -floop-block -floop-parallelize-all -MT spread_i2.lo -MD -MP -MF .deps/spread_i2.Tpo -c /home/ruben/mingw-w64/toolchain/src/gcc/libgfortran/generated/spread_i2.c -DDLL_EXPORT -DPIC -o ./libs/spread_i2.o xgcc -v output: Using built-in specs. COLLECT_GCC=/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/./gcc/xgcc Target: i686-w64-mingw32 Configured with: /home/ruben/mingw-w64/toolchain/src/gcc/configure --host=x86_64-linux-gnu --build=x86_64-linux-gnu --target=i686-w64-mingw32 --with-sysroot=/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32 --prefix=/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32 --with-libiconv-prefix=/home/ruben/mingw-w64/toolchain/linux64mingw32/prereq_install --with-gmp=/home/ruben/mingw-w64/toolchain/linux64mingw32/prereq_install --with-mpfr=/home/ruben/mingw-w64/toolchain/linux64mingw32/prereq_install --with-mpc=/home/ruben/mingw-w64/toolchain/linux64mingw32/prereq_install --with-ppl=/home/ruben/mingw-w64/toolchain/linux64mingw32/prereq_install --with-cloog=/home/ruben/mingw-w64/toolchain/linux64mingw32/prereq_install --enable-cloog-backend=isl --with-host-libstdcxx='-lstdc++ -lsupc++ -lm -lgcc_eh' --enable-shared --enable-static --enable-threads=posix --disable-multilib --enable-languages=c,lto,c++,fortran,objc,obj-c++,java --enable-libgomp --enable-sjlj-exceptions --enable-fully-dynamic-string --disable-nls --disable-werror --enable-checking=release CFLAGS='-O2 -mtune=core2 -fomit-frame-pointer -momit-leaf-frame-pointer -fgraphite-identity -floop-interchange -floop-block -floop-parallelize-all' LDFLAGS= Thread model: posix gcc version 4.7.0 20111029 (experimental) (GCC) Preprocessed source attached. Same thing happens for spread_i1.c.
[Bug c++/50920] New: add a -std=c++11 option to the driver
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50920 Bug #: 50920 Summary: add a -std=c++11 option to the driver Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: vanboxem.ru...@gmail.com Since the new Standard has been ratified and published, I think it's more than time this gets added. In the next release, there could be a warning about the deprecation of -std=c++0x in favor of the new one.
[Bug middle-end/50913] ICE: compiling libgfortran for i686-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50913 --- Comment #2 from Ruben Van Boxem 2011-10-30 15:20:43 UTC --- (In reply to comment #1) > What was the ICE? Sorry about that: /home/ruben/mingw-w64/toolchain/src/gcc/libgfortran/generated/spread_i1.c: In function 'spread_i1': /home/ruben/mingw-w64/toolchain/src/gcc/libgfortran/generated/spread_i1.c:36:1: internal compiler error: in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:633
[Bug libstdc++/53578] include/ext/concurrence.h relies on ill-formed narrowing conversions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53578 Ruben Van Boxem changed: What|Removed |Added CC||vanboxem.ruben at gmail dot ||com --- Comment #5 from Ruben Van Boxem 2012-06-06 10:25:26 UTC --- This is not only a problem, but also turns up with `std::unique_ptr` (so the header ) on Windows. This error is caught by Clang in c++11 mode: http://llvm.org/bugs/show_bug.cgi?id=12707
[Bug libstdc++/53578] include/ext/concurrence.h relies on ill-formed narrowing conversions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53578 --- Comment #7 from Ruben Van Boxem 2012-06-06 11:10:34 UTC --- Changing this line: static typename __enable_if::__type to read: static typename __enable_if(sizeof(&_Rm::sema)), void>::__type makes the unique_ptr problem go away (see http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-June/021863.html).
[Bug c/51437] GCC should warn on the use of reserved identifier/macro names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51437 --- Comment #10 from Ruben Van Boxem 2012-02-19 09:33:05 UTC --- (In reply to comment #9) > (In reply to comment #8) > > You really do want to flag both definition and usage. For instance, there's > > plenty of buggy software (especially GNU software like binutils) using > > __pid_t > > and similar when it should be using pid_t, etc. > > In the case of identifiers containing __ or starting with _[A-Z], that does > hold true; I hadn't considered programs using internal identifiers when > corresponding public identifiers exist. (Ideally the headers could have > avoided exposing those internal identifiers to user programs in the first > place, but I don't know any sensible way to implement that.) > > However, note that the standards also reserve various other classes of names, > such as types ending in _t, for which GCC should only flag definitions, not > uses. Only system headers should define new _t types, but user code can *use* > types like time_t or pid_t without warning. These are only reserved for POSIX, and should not always be warned about! > > (Some of the other reserved identifier categories, such as E[A-Z0-9].*, > is[a-z].*, to[a-z].*, and mem[a-z].* should go under some separate, more > pedantic warning option.) I don't see why this should happen at all. There's nothing special about these general names? > > > From an undefined behavior standpoint, defining a name in the reserved > > namespace is no worse than using a name in the referred namespace assuming > > the > > implementation has defined it. Both are incorrect C usage and both should be > > flagged. > > True. I had mostly wanted to avoid generating hundreds of warnings for the > same identifier. However, that seems better than missing cases like the > __pid_t you mentioned above. > > > My heuristic about -isystem would prevent flagging usage of reserved names > > resulting from implementations of system headers - for instance, if a macro > > in > > a system header used __uint32_t because it needs to avoid making uint32_t > > visible. > > Right. That seems like the same heuristic documented at > http://gcc.gnu.org/onlinedocs/cpp/System-Headers.html that I referenced in > comment 7: "Macros defined in a system header are immune to a few warnings > wherever they are expanded."
[Bug c/51437] GCC should warn on the use of reserved identifier/macro names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51437 --- Comment #14 from Ruben Van Boxem 2012-02-19 21:51:37 UTC --- I don't think adding future reserved identifiers serves any purpose. In general, code is written against a certain version of a language's Standard, with the current constraints, not would-be might-be constraints. Perhaps split that into a very pedantic extra warning or something.
[Bug c++/52465] New: g++ rejects valid code with in-class using declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52465
Bug #: 52465
Summary: g++ rejects valid code with in-class using declaration
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vanboxem.ru...@gmail.com
This code is rejected by GCC 4.7 (built 2/25), but accepted by everything else:
class A
{
protected:
struct B {};
};
class C : A
{
protected:
using A::B;
struct D : public B {};
};
This prevents WebKit compilation where a similar construct is used.
[Bug java/52468] New: Build failure for *-*-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52468 Bug #: 52468 Summary: Build failure for *-*-mingw32 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassig...@gcc.gnu.org ReportedBy: vanboxem.ru...@gmail.com GCC configured with: /home/ruben/mingw-w64/toolchain/src/gcc/configure --host=x86_64-linux-gnu --build=x86_64-linux-gnu --target=i686-w64-mingw32 --with-sysroot=/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32 --prefix=/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32 --with-libiconv-prefix=/home/ruben/mingw-w64/toolchain/linux64mingw32/prereq_install --with-gmp=/home/ruben/mingw-w64/toolchain/linux64mingw32/prereq_install --with-mpfr=/home/ruben/mingw-w64/toolchain/linux64mingw32/prereq_install --with-mpc=/home/ruben/mingw-w64/toolchain/linux64mingw32/prereq_install --with-ppl=/home/ruben/mingw-w64/toolchain/linux64mingw32/prereq_install --with-cloog=/home/ruben/mingw-w64/toolchain/linux64mingw32/prereq_install --enable-cloog-backend=isl --with-host-libstdcxx=-static -lstdc++ -lm -lgcc_eh --enable-shared --enable-static --enable-threads=posix --disable-multilib --enable-languages=c,lto,c++,objc,obj-c++,java --enable-libgomp --enable-libgcj --enable-sjlj-exceptions --enable-fully-dynamic-string --disable-nls -- disable-werror --enable-checking=release CFLAGS=-O2 -mtune=core2 -fomit-frame-pointer -momit-leaf-frame-pointer -fgraphite-identity -floop-interchange -floop-block -floop-parallelize-all LDFLAGS= Fails to build gcj: libtool: compile: /home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/./gcc/xgcc -shared-libgcc -B/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/./gcc -nostdinc++ -L/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/i686-w64-mingw32/libstdc++-v3/src -L/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/i686-w64-mingw32/libstdc++-v3/src/.libs -L/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/lib -L/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/mingw/lib -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/include -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/mingw/include -B/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/bin/ -B/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/lib/ -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/include -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/sys-include -DHAVE_CONFIG_H -I. -I/ home/ruben/mingw-w64/toolchain/src/gcc/libjava -I./include -I./gcj -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava -Iinclude -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/include -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/classpath/include -Iclasspath/include -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/classpath/native/fdlibm -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/../boehm-gc/include -I../boehm-gc/include -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/libltdl -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/libltdl -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/.././libjava/../libgcc -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/../zlib -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -ffloat-store -fomit-frame-pointer -Usun -fno-omit-frame-pointer -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\"/home/ruben/mingw-w64/toolchain/linux64mingw32/ mingw32\" -DTOOLEXECLIBDIR=\"/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/lib/../lib\" -DJAVA_HOME=\"/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32\" -DBOOT_CLASS_PATH=\"/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/share/java/libgcj-4.7.0.jar\" -DJAVA_EXT_DIRS=\"/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/share/java/ext\" -DGCJ_ENDORSED_DIRS=\"/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/share/java/gcj-endorsed\" -DGCJ_VERSIONED_LIBDIR=\"/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/lib/../lib/gcj-4.7.0-13\" -DPATH_SEPARATOR=\":\" -DECJ_JAR_FILE=\"\" -DLIBGCJ_DEFAULT_DATABASE=\"/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/lib/../lib/gcj-4.7.0-13/classmap.db\" -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-4.7.0-13/classmap.db\" -g -O2 -MT gnu/java/nio/natVMSelector.lo -MD -MP -MF gnu/java/nio/.deps/natVMSelector.Tpo -c gnu/java/nio/natVMSelector.cc -DDLL_EXPORT -DPIC -o gnu/java/nio/.libs/natVMSelector.o gnu/java/nio/natVMSelector.cc: In static member function 'static jint gnu::java::nio::VMSelector::select(jintArray, jintArray, jintArray, jlong)': gnu/java/nio/natVMSelector.cc:49:48: error: '_Jv_Win32GetInterruptEvent' was not declared in this scope
[Bug c/51437] New: GCC should warn on the use of reserved identifier/macro names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51437 Bug #: 51437 Summary: GCC should warn on the use of reserved identifier/macro names Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: vanboxem.ru...@gmail.com For C and C++, Clang should warn when user code uses identifiers or macros that are implementation-reserved. For C(99), this would mean names starting with an underscore followed by another unerscore or capitalized letter. For C++ a single underscore is also reserved for the global namespace. I could have messed the above rules up, but these are the cause of a lot of unexpected bugs, and a warning would be super-easy to implement.
[Bug c/51437] GCC should warn on the use of reserved identifier/macro names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51437 --- Comment #2 from Ruben Van Boxem 2011-12-06 11:50:18 UTC --- (In reply to comment #1) > (In reply to comment #0) > > For C and C++, Clang > > Ahem! > > > For C++ a single underscore is also reserved for the global namespace. > > That comes from C, not C++: > "All identifiers that begin with an underscore are always reserved for use as > identifiers with file scope in both the ordinary and tag name spaces." Fair enough. I warned you, I only quickly glanced at both standard documens :)
[Bug other/51688] New: libgcc dll is installed in /lib instead of /bin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51688 Bug #: 51688 Summary: libgcc dll is installed in /lib instead of /bin Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: vanboxem.ru...@gmail.com GCC configured like this: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=m:/development/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.7.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: /home/ruben/mingw-w64/toolchain/src/gcc/configure --host=x86_64-w64-mingw32 --build=x86_64-linux-gnu --target=x86_64-w64-mingw32 --with-sysroot=/home/ruben/mingw-w64/toolchain/mingw64mingw64/mingw64 --prefix=/home/ruben/mingw-w64/toolchain/mingw64mingw64/mingw64 --with-libiconv-prefix=/home/ruben/mingw-w64/toolchain/mingw64mingw64/prereq_install --with-gmp=/home/ruben/mingw-w64/toolchain/mingw64mingw64/prereq_install --with-mpfr=/home/ruben/mingw-w64/toolchain/mingw64mingw64/prereq_install --with-mpc=/home/ruben/mingw-w64/toolchain/mingw64mingw64/prereq_install --with-ppl=/home/ruben/mingw-w64/toolchain/mingw64mingw64/prereq_install --with-cloog=/home/ruben/mingw-w64/toolchain/mingw64mingw64/prereq_install --enable-cloog-backend=isl --with-host-libstdcxx='-static -lstdc++ -lm -lgcc_eh' --enable-shared --enable-static --enable-threads=posix --disable-multilib --enable-languages=c,lto,c++,objc,obj-c++,java --enable-libgomp --enable-sjlj-exceptions --enable-fully-dynamic-string --disable-nls --disable-werror --enable-checking=release --disable-win32-registry --disable-rpath --disable-werror CFLAGS='-O2 -mtune=core2 -fomit-frame-pointer -momit-leaf-frame-pointer -fgraphite-identity -floop-interchange -floop-block -floop-parallelize-all' LDFLAGS= Thread model: posix gcc version 4.7.0 20111226 (experimental) (GCC) puts libgcc_s_sjlj-1.dll in /home/ruben/mingw-w64/toolchain/mingw64mingw64/mingw64/lib, instead of the previous (GCC 4.5/4.6) /home/ruben/mingw-w64/toolchain/mingw64mingw64/mingw64/bin, where it belongs. This is with a native 64-bit windows compiler, built from Linux.
[Bug libgcj/50895] Build failure in jni.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50895 --- Comment #2 from Ruben Van Boxem 2012-01-24 15:29:24 UTC --- With GCC 4.7, I get a different failure (and jni.cc hasn't been reached yet I think), which is pthread-related (I configured with --enable-threads=posix): libtool: compile: /home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/./gcc/xgcc -shared-libgcc -B/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/./gcc -nostdinc++ -L/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/i686-w64-mingw32/libstdc++-v3/src -L/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/i686-w64-mingw32/libstdc++-v3/src/.libs -L/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/lib -L/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/mingw/lib -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/include -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/mingw/include -B/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/bin/ -B/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/lib/ -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/include -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/sys-include -DHAVE_CONFIG_H -I. -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava -I./include -I./gcj -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava -Iinclude -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/include -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/classpath/include -Iclasspath/include -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/classpath/native/fdlibm -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/../boehm-gc/include -I../boehm-gc/include -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/libltdl -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/libltdl -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/.././libjava/../libgcc -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/../zlib -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -ffloat-store -fomit-frame-pointer -Usun -fno-omit-frame-pointer -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\"/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32\" -DTOOLEXECLIBDIR=\"/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/lib/../lib\" -DJAVA_HOME=\"/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32\" -DBOOT_CLASS_PATH=\"/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/share/java/libgcj-4.7.0.jar\" -DJAVA_EXT_DIRS=\"/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/share/java/ext\" -DGCJ_ENDORSED_DIRS=\"/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/share/java/gcj-endorsed\" -DGCJ_VERSIONED_LIBDIR=\"/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/lib/../lib/gcj-4.7.0-13\" -DPATH_SEPARATOR=\":\" -DECJ_JAR_FILE=\"\" -DLIBGCJ_DEFAULT_DATABASE=\"/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/lib/../lib/gcj-4.7.0-13/classmap.db\" -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-4.7.0-13/classmap.db\" -g -O2 -MT win32.lo -MD -MP -MF .deps/win32.Tpo -c /home/ruben/mingw-w64/toolchain/src/gcc/libjava/win32.cc -DDLL_EXPORT -DPIC -o .libs/win32.o /home/ruben/mingw-w64/toolchain/src/gcc/libjava/boehm.cc:60:8: warning: 'void GC_enable()' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes] /home/ruben/mingw-w64/toolchain/src/gcc/libjava/boehm.cc:61:8: warning: 'void GC_disable()' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes] /home/ruben/mingw-w64/toolchain/src/gcc/libjava/boehm.cc:716:1: warning: unused parameter 'thread' [-Wunused-parameter] /home/ruben/mingw-w64/toolchain/src/gcc/libjava/boehm.cc:725:1: warning: unused parameter 'thread' [-Wunused-parameter] /home/ruben/mingw-w64/toolchain/src/gcc/libjava/boehm.cc:734:1: warning: unused parameter 'thread' [-Wunused-parameter] /home/ruben/mingw-w64/toolchain/src/gcc/libjava/boehm.cc:73:12: warning: 'int _Jv_GC_has_static_roots(const char*, void*, size_t)' declared 'static' but never defined [-Wunused-function] depbase=`echo posix-threads.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\ /bin/sh ./libtool --tag=CXX --mode=compile /home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/./gcc/xgcc -shared-libgcc -B/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/./gcc -nostdinc++ -L/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/i686-w64-mingw32/libstdc++-v3/src -L/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/i686-w64-mingw32/libstdc++-v3/src/.libs -L/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/lib -L/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/mingw/lib -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/include -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/mingw/include -B/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32
[Bug c++/88183] New: [GCC7 Regression] Fold expression with operator .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88183 Bug ID: 88183 Summary: [GCC7 Regression] Fold expression with operator . Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vanboxem.ruben at gmail dot com Target Milestone: ---
[Bug c++/88183] [GCC7 Regression] Fold expression with operator .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88183
--- Comment #1 from Ruben Van Boxem ---
Created attachment 45084
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45084&action=edit
compressed preprocessed source causing ICE
Attached preprocessed source file ICEs GCC 8.2.1 20180831 on Arch Linux.
It compiles and works just fine on Clang 7.0.0, MSVC 19.16.27023.1, and GCC
7.3.1 20180814.
It uses Boost.Spirit.X3 from Boost 1.68.
Compile with 'g++ -std=c++17 -c ice.ii' produces:
In file included from
/home/ruben/Development/skui/css/grammar/background.h++:33,
from /home/ruben/Development/skui/css/grammar.h++:40,
from
/home/ruben/Development/skui/tests/css/grammar.test.c++:30:
/home/ruben/Development/skui/css/grammar/make_property.h++: In instantiation of
'auto skui::css::grammar::make_property(const PropertyType&, const ValueType&,
PointerToMemberType ...) [with PropertyType = char [14]; ValueType =
skui::css::grammar::align_content_table; PointerToMemberType =
{skui::css::align_content skui::css::declaration_block::*}]':
/home/ruben/Development/skui/css/grammar.h++:56:112: required from here
/home/ruben/Development/skui/css/grammar/make_property.h++:43:39: internal
compiler error: Segmentation fault
(_val(context).* ... .* member) = _attr(context);
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug c++/88183] [GCC7 Regression] Fold expression with operator .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88183 --- Comment #2 from Ruben Van Boxem --- Additionally I tested compiling the GCC7 preprocessed source with GCC 8.2.1, which expectedly leads to an ICE as well. Simple attempts to trigger the same issue (e.g. http://coliru.stacked-crooked.com/a/6982545ffce8c57d) fail. I'm not familiar enough with Boost.Spirit.X3 and/or fusion to further reduce this.
[Bug libgcj/50895] Build failure in jni.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50895 --- Comment #5 from Ruben Van Boxem 2012-12-10 12:32:36 UTC --- (In reply to comment #4) > A question about this build-failure. Were you using posix-threading model for > 4.6 ? It's been a while, but I believe the 4.6 was normal win32 threading.
[Bug rtl-optimization/55106] ice: Maximum number of LRA constraint passes is achieved (15)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55106 Ruben Van Boxem changed: What|Removed |Added CC||vanboxem.ruben at gmail dot ||com --- Comment #5 from Ruben Van Boxem 2012-12-20 19:36:08 UTC --- I'm still hitting this failure when building GMP 5.1.0 for i686-w64-mingw32: libtool: compile: i686-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../../../src/gmp/mpn -I.. -D__GMP_WITHIN_GMP -I../../../../src/gmp -DOPERATION_sbpi1_div_qr -O2 -march=nocona -mtune=core2 -fomit-frame-pointer -momit-leaf-frame-pointer -c sbpi1_div_qr.c -o sbpi1_div_qr.o div_qr_2u_pi1.c: In function '__gmpn_div_qr_2u_pi1': div_qr_2u_pi1.c:67:1: internal compiler error: Maximum number of LRA constraint passes is achieved (30) } ^ Please submit a full bug report, with preprocessed source if appropriate. The build for x86_64-w64-mingw32 did not encounter this problem. I'm building on 64-bit Debian using a self-built linux to Windows cross-compilers.
[Bug rtl-optimization/55106] ice: Maximum number of LRA constraint passes is achieved (15)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55106 --- Comment #6 from Ruben Van Boxem 2012-12-20 19:42:02 UTC --- I can also add that GMP 5.0.5 does not trigger this ICE.
[Bug c++/55898] Can't obtain stack trace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55898 Ruben Van Boxem changed: What|Removed |Added CC||vanboxem.ruben at gmail dot ||com --- Comment #3 from Ruben Van Boxem 2013-01-07 18:57:20 UTC --- I can confirm this happens on GCC 4.7.2 x86_64 sjlj GCC 4.6.3 x86_64 sjlj And does not happen on (a good stack trace is obtained): GCC 4.*.* i686 sjlj/dw2 GCC 4.8 x86_64 seh
[Bug lto/55493] [4.8 Regression] LTO always ICEs on i686-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55493 Ruben Van Boxem changed: What|Removed |Added CC||vanboxem.ruben at gmail dot ||com --- Comment #8 from Ruben Van Boxem 2013-01-20 18:34:11 UTC --- I can confirm that this bug is present for GCC 4.8 dated 20121221, which is available here: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/gcc-4.8-unstable/i686-w64-mingw32-gcc-4.8-unstable-win32_rubenvb.7z/download I get: lto1.exe: internal compiler error: cannot read LTO decls from R:\temp\ccgzHybZ.o Please submit a full bug report, with preprocessed source if appropriate. See for instructions. lto-wrapper: g++ returned 1 exit status m:/development/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld.exe: lto-wrapper failed collect2.exe: error: ld returned 1 exit status
[Bug bootstrap/50229] [5/6/7/8 Regression] Can't cross compile for i686-apple-darwin10 from x86_64-redhat_linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50229 --- Comment #28 from Ruben Van Boxem --- (In reply to Eric Gallager from comment #27) > (In reply to Iain Sandoe from comment #21) > > (In reply to Francois-Xavier Coudert from comment #20) > > > This PR appears to report two different issues: > > > 1. cross-compiler targeting Darwin > > > 2. cross-compiler hosted on Darwin > > in short (2) is very definitely "works for me" > So does this bug need to stay open then? I reported the original issue using Fedora's Mac OS X cross compiler toolchains that were available at the time. They are still described here, but the repo has become unavailable: https://fedoraproject.org/wiki/MinGW/CrossCompilerFramework I cannot seem to locate an active repository providing these now. So it is really your number one. If the problem lies outside of GCC sources, perhaps it's best to close this issue, but as it used to work in GCC 4.6, it seems something changed that made this setup nonfunctional.
[Bug go/47726] language go can not build for mingw target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47726 Ruben Van Boxem changed: What|Removed |Added CC||vanboxem.ruben at gmail dot ||com --- Comment #1 from Ruben Van Boxem 2011-05-01 22:38:55 UTC --- I can confirm this problem. I concur with Dongsheng's proposal.
[Bug c++/45799] New: ICE + segfault when compiling Qt's WebKit JavaScriptCore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45799 Summary: ICE + segfault when compiling Qt's WebKit JavaScriptCore Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: vanboxem.ru...@gmail.com Host: x86_64-w64-mingw32 Target: x86_64-w64-mingw32 Build: x86_64-w64-mingw32 Output from "gcc -v": Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=m:/development/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../../src/gcc/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64 --with-sysroot=/mingw64 --enable-lto --disable-multilib --enable-shared --enable-stage1-languages=c,lto --enable-languages=c,c++,lto --with-libiconv-prefix=/home/Ruben/mingw64/build64/gcc-libs --with-libexpat-prefix=/home/Ruben/mingw64/build64/gcc-libs --with-gmp=/home/Ruben/mingw64/build64/gcc-libs --with-mpfr=/home/Ruben/mingw64/build64/gcc-libs --with-mpc=/home/Ruben/mingw64/build64/gcc-libs --with-ppl=/home/Ruben/mingw64/build64/gcc-libs --with-cloog-ppl=/home/Ruben/mingw64/build64/gcc-libs --disable-win32-registry --enable-fully-dynamic-string --enable-checking=release --disable-werror --disable-nls CFLAGS='-mtune=core2 -fomit-frame-pointer -momit-leaf-frame-pointer' LFLAGS= Thread model: win32 gcc version 4.6.0 20100918 (experimental) (GCC) Command used to compile the source file: g++ -c -Wall -Wreturn-type -fno-strict-aliasing -Wcast-align -Wchar-subscripts -Wformat-security -Wreturn-type -Wno-unused-parameter -Wno-sign-compare -Wno-switch -Wno-switch-enum -Wundef -Wmissing-noreturn -Winit-self -O2 -frtti -fexceptions -mthreads -DQT_SHARED -DQT_THREAD_SUPPORT -DUNICODE -DQT_LARGEFILE_SUPPORT -DJSC=QTJSC -Djscyyparse=qtjscyyparse -Djscyylex=qtjscyylex -Djscyyerror=qtjscyyerror -DWTF=QTWTF -DQT_BUILD_SCRIPT_LIB -DQT_NO_USING_NAMESPACE -DQLALR_NO_QSCRIPTGRAMMAR_DEBUG_INFO -DQT_MAKEDLL -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_FAST_OPERATOR_PLUS -DQT_USE_FAST_CONCATENATION -D_USE_MATH_DEFINES -DBUILDING_QT__=1 -DWTF_USE_ACCELERATED_COMPOSITING -DUSE_SYSTEM_MALLOC -DNDEBUG -DBUILDING_QT__ -DBUILDING_JavaScriptCore -DBUILDING_WTF -DWTF_USE_JAVASCRIPTCORE_BINDINGS=1 -DWTF_CHANGES=1 -DNDEBUG -DJS_NO_EXPORT -DQT_DLL -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_HAVE_MMX -DQT_HAVE_3DNOW -DQT_HAVE_SSE -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 -I"..\..\include\QtCore" -I"..\..\include" -I"m:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore" -I"m:\Development\Source\Qt\src\3rdparty\javascriptcore" -I"m:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\assembler" -I"m:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\bytecode" -I"m:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\bytecompiler" -I"m:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\debugger" -I"m:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\interpreter" -I"m:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\jit" -I"m:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\parser" -I"m:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\pcre" -I"m:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\profiler" -I"m:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\runtime" -I"m:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\wrec" -I"m:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\wtf" -I"m:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\wtf\unicode" -I"m:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\yarr" -I"m:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\API" -I"m:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\ForwardingHeaders" -I"m:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\generated" -I"..\..\include\QtScript" -I"tmp\rcc\release_shared" -I"tmp" -I"m:\Development\Source\Qt\src\3rdparty\javascriptcore\WebKit\qt\Api" -I"m:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\pcre" -I"m:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\tmp" -I"m:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore" -I"m:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\parser" -I"m:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\bytecompiler" -I"m:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\debugger" -I"m:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\runtime" -I"m:\Development\Source\Qt\src\3rdparty\javascriptcore\JavaScriptCore\wtf" -I"m:\Development\Source\Qt\src\script\..\3rdparty\javascriptcore\Ja
[Bug c++/45822] New: [4.6-regression] Qt 4.7.0 declarative build fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45822 Summary: [4.6-regression] Qt 4.7.0 declarative build fails Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: vanboxem.ru...@gmail.com gcc -v: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=m:/development/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../../src/gcc/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64 --with-sysroot=/mingw64 --enable-lto --disable-multilib --enable-shared --enable-stage1-languages=c,lto --enable-languages=c,c++,lto --with-libiconv-prefix=/home/Ruben/mingw64/build64/gcc-libs --with-libexpat-prefix=/home/Ruben/mingw64/build64/gcc-libs --with-gmp=/home/Ruben/mingw64/build64/gcc-libs --with-mpfr=/home/Ruben/mingw64/build64/gcc-libs --with-mpc=/home/Ruben/mingw64/build64/gcc-libs --disable-win32-registry --enable-fully-dynamic-string --enable-checking=release --disable-werror --disable-nls CFLAGS='-O2 -mtune=core2 -fomit-frame-pointer -momit-leaf-frame-pointer' LFLAGS=-no-undefined BOOT_CFLAGS= 'BOOT_LFLAGS=-flto -fwhopr=2' TARGET_CFLAGS= 'TARGET_LFLAGS=-flto -fwhopr=2' Thread model: win32 gcc version 4.6.0 20100918 (experimental) (GCC) This is built from a snapshot and patched for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45580 Command used to compile the file and its output: g++ -c -O2 -Wall -frtti -fexceptions -mthreads -DQT_SHARED -DQT_THREAD_SUPPORT -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_BUILD_DECLARATIVE_LIB -DQT_NO_URL_CAST_FROM_STRING -DQT_MAKEDLL -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_FAST_OPERATOR_PLUS -DQT_USE_FAST_CONCATENATION -D_USE_MATH_DEFINES -DQT_DLL -DQT_NO_DEBUG -DQT_SCRIPT_LIB -DQT_SVG_LIB -DQT_SQL_LIB -DQT_XMLPATTERNS_LIB -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -I"..\..\include\QtCore" -I"..\..\include\QtNetwork" -I"..\..\include\QtGui" -I"..\..\include\QtOpenGL" -I"..\..\include\QtXmlPatterns" -I"..\..\include\QtSql" -I"..\..\include\QtSvg" -I"..\..\include\QtScript" -I"..\..\include" -I"..\..\include\QtDeclarative" -I"tmp\rcc\release_shared" -I"tmp" -I"m:\Development\Source\qt\src\declarative\util" -I"m:\Development\Source\qt\src\declarative\graphicsitems" -I"m:\Development\Source\qt\src\declarative\qml" -I"m:\Development\Source\qt\src\declarative\qml\parser" -I"m:\Development\Source\qt\src\declarative\qml\rewriter" -I"m:\Development\Source\qt\src\declarative\debugger" -I"..\..\include\ActiveQt" -I"tmp\moc\release_shared" -I"m:\Development\Source\qt\src\declarative" -I"." -I"..\..\mkspecs\win32-g++" -o tmp\obj\release_shared\qdeclarativeitemsmodule.o m:\Development\Source\qt\src\declarative\graphicsitems\qdeclarativeitemsmodule.cpp In file included from ..\..\include/QtDeclarative/qdeclarativeprivate.h:1:0, from ..\..\include\QtDeclarative/../../../../Source/qt/src/declarative/qml/qdeclarative.h:45, from ..\..\include\QtDeclarative/qdeclarative.h:1, from ..\..\include\QtDeclarative/private/../../../../../Source/qt/src/declarative/graphicsitems/qdeclarativeitemsmodule_p.h:45, from ..\..\include\QtDeclarative/private/qdeclarativeitemsmodule_p.h:1, from m:\Development\Source\qt\src\declarative\graphicsitems\qdeclarativeitemsmodule.cpp:42: ..\..\include/QtDeclarative/../../../../Source/qt/src/declarative/qml/qdeclarativeprivate.h: In constructor 'QDeclarativePrivate::QDeclarativeElement::QDeclarativeElement()': ..\..\include/QtDeclarative/../../../../Source/qt/src/declarative/qml/qdeclarativeprivate.h:85:11: instantiated from 'void QDeclarativePrivate::createInto(void*) [with T = QGraphicsWidget]' ..\..\include\QtDeclarative/../../../../Source/qt/src/declarative/qml/qdeclarative.h:185:5: instantiated from 'int qmlRegisterType(const char*, int, int, const char*) [with T = QGraphicsWidget]' m:\Development\Source\qt\src\declarative\graphicsitems\qdeclarativeitemsmodule.cpp:154:64: instantiated from here ..\..\include/QtDeclarative/../../../../Source/qt/src/declarative/qml/qdeclarativeprivate.h:85:11: error: no matching function for call to 'QFlags::QFlags(int)' ..\..\include/QtCore/../../../../Source/qt/src/corelib/global/qglobal.h:2181:12: note: candidates are: QFlags::QFlags(QFlag) [with Enum = Qt::WindowType] ..\..\include/QtCore/../../../../Source/qt/src/corelib/global/qglobal.h:2180:12: note: QFlags::QFlags(QFlags::Zero) [with Enum = Qt::WindowType, QFlags::Zero = void**] ..\..\include/QtCore/../../../../Source/qt/src/corelib/global/qglobal.h:2179:12: note: QFlags::QFlags(Enum) [with Enum = Qt::WindowType] ..\..\include/QtCore/../../../../Source/qt/src/corelib/global/qglobal.h:2178:12: note: QFl
[Bug c++/45822] [4.6-regression] Qt 4.7.0 build fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45822 --- Comment #3 from Ruben Van Boxem 2010-09-28 20:34:48 UTC --- This also happens later in the build process, with this command and output: g++ -c -O2 -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_THREAD_SUPPORT -DQT_NEEDS_QMAIN -I"..\..\..\include\QtCore" -I"..\..\..\include\QtGui" -I"..\..\..\include" -I"..\..\..\include\ActiveQt" -I"tmp\moc\release_shared" -I"m:\Development\Source\qt\examples\animation\moveblocks" -I"." -I"..\..\..\mkspecs\win32-g++" -o tmp\obj\release_shared\main.o m:\Development\Source\qt\examples\animation\moveblocks\main.cpp m:\Development\Source\qt\examples\animation\moveblocks\main.cpp: In constructor 'QGraphicsRectWidget::QGraphicsRectWidget()': m:\Development\Source\qt\examples\animation\moveblocks\main.cpp:69:7: error: no matching function for call to 'QFlags::QFlags(int)' ..\..\..\include/QtCore/../../../../Source/qt/src/corelib/global/qglobal.h:2181:12: note: candidates are: QFlags::QFlags(QFlag) [with Enum = Qt::WindowType] ..\..\..\include/QtCore/../../../../Source/qt/src/corelib/global/qglobal.h:2180:12: note: QFlags::QFlags(QFlags::Zero) [with Enum = Qt::WindowType, QFlags::Zero = void**] ..\..\..\include/QtCore/../../../../Source/qt/src/corelib/global/qglobal.h:2179:12: note: QFlags::QFlags(Enum) [with Enum = Qt::WindowType] ..\..\..\include/QtCore/../../../../Source/qt/src/corelib/global/qglobal.h:2178:12: note: QFlags::QFlags(const QFlags&) [with Enum = Qt::WindowType, QFlags = QFlags] m:\Development\Source\qt\examples\animation\moveblocks\main.cpp: In function 'int qMain(int, char**)': m:\Development\Source\qt\examples\animation\moveblocks\main.cpp:177:40: note: synthesized method 'QGraphicsRectWidget::QGraphicsRectWidget()' first required here I can provide preprocessed source for this if needed.
[Bug c++/49326] New: Lambda arguments should not have a default value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49326
Summary: Lambda arguments should not have a default value
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vanboxem.ru...@gmail.com
Currently, GCC 4.6.1 warns in pedantic mode when a lambda is written that
provides default value for an argument:
[](bool a, bool=true){ return !a;} }
Which, according to the FDIS n3290 section 5.1.2/5, should be illegal and thus
give an error.
As the detection code is already present/functional (in -pedantic mode),
changing that into an error shouldn't be hard.
[Bug c++/49326] Lambda arguments should not have a default value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49326 --- Comment #2 from Ruben Van Boxem 2011-06-08 16:54:34 UTC --- I compiled with -std=c++0x, so GCC extensions should be turned off.
[Bug c++/49326] Lambda arguments should not have a default value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49326 Ruben Van Boxem changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Ruben Van Boxem 2011-06-08 17:48:53 UTC --- Ok, my mistake, I compiled with -std=c++0x -pedantic, which (as I'm reading in the manual now) turns off GCC extensions and makes program adhere to strict standards... But emits warnings only. I should use -pedantic-errors then. OK. That works as it should in this case. Thanks.
[Bug tree-optimization/71824] New: ICE when compiling libiberty with Graphite loop optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71824 Bug ID: 71824 Summary: ICE when compiling libiberty with Graphite loop optimizations Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vanboxem.ruben at gmail dot com Target Milestone: --- Created attachment 38866 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38866&action=edit preprocessed source file that causes ICE Compiling attached file for x86_64-w64-mingw32 ICEs: x86_64-w64-mingw32-gcc -c -O2 -march=nocona -mtune=core2 -fomit-frame-pointer -momit-leaf-frame-pointer -fgraphite-identity -floop-interchange -floop-block -floop-parallelize-all -x c getopt.ii/home/ruben/MinGW-w64-build-scripts/src/binutils/libiberty/getopt.c: In function 'exchange': /home/ruben/MinGW-w64-build-scripts/src/binutils/libiberty/getopt.c:317:1: internal compiler error: in add_loop_constraints, at graphite-sese-to-poly.c:933 exchange (char **argv) ^~~~ Please submit a full bug report, with preprocessed source if appropriate. See for instructions. The cross-compiler in question is GCC 6.1.0 built with ISL 0.16.1.
