[Bug driver/70936] Hard-coded C++ header paths and relocation problem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70936 İsmail Dönmez changed: What|Removed |Added CC||ismail at i10z dot com --- Comment #8 from İsmail Dönmez --- We can reproduce this with openSUSE mingw-w64 toolchain and we don't use --with-gxx-include-dir : Using built-in specs. COLLECT_GCC=x86_64-w64-mingw32-c++ COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-w64-mingw32/6.1.0/lto-wrapper Target: x86_64-w64-mingw32 Configured with: ../configure --prefix=/usr --bindir=/usr/bin --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/lib64 --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --build=x86_64-suse-linux-gnu --host=x86_64-suse-linux-gnu --target=x86_64-w64-mingw32 --with-gnu-as --with-gnu-ld --verbose --without-newlib --disable-multilib --disable-plugin --with-system-zlib --disable-nls --without-included-gettext --disable-win32-registry --enable-version-specific-runtime-libs --with-sysroot=/usr/x86_64-w64-mingw32/sys-root --enable-languages=c,c++,fortran,objc,obj-c++ --without-x --enable-hash-synchronization --enable-fully-dynamic-string --enable-libgomp --enable-linker-build-id Thread model: win32 gcc version 6.1.0 (GCC) Didn't try to disable "--enable-version-specific-runtime-libs" because we actually need it.
[Bug c++/56671] Gcc uses large amounts of memory and processor power with large C++11 bitsets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56671 İsmail Dönmez changed: What|Removed |Added CC||ismail at i10z dot com --- Comment #8 from İsmail Dönmez --- Confirming with gcc7 trunk as of r244889.
[Bug bootstrap/67363] [6 Regression] r227188 breaks build for mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67363 --- Comment #13 from İsmail Dönmez --- (In reply to John David Anglin from comment #12) > Created attachment 36321 [details] > Patch > > I sent this change this morning to gcc-patches but it seems to have > disappeared. The patch declares the functions but those functions do not exist on mingw-w64, seems to be this will just fail with an undefined symbol error.
[Bug bootstrap/67363] [6 Regression] r227188 breaks build for mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67363 --- Comment #15 from İsmail Dönmez --- (In reply to dave.anglin from comment #14) > On 2015-09-10 1:01 PM, ismail at i10z dot com wrote: > > The patch declares the functions but those functions do not exist on > > mingw-w64, > > seems to be this will just fail with an undefined symbol error. > The routines are in liberty and the patch assumes that that they are > built. If that's not the > case on mingw-w64, then they will have to be provided by some other means. Ah that makes sense, thanks!
[Bug bootstrap/67363] [6 Regression] r227188 breaks build for mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67363 İsmail Dönmez changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #18 from İsmail Dönmez --- (In reply to John David Anglin from comment #17) > Fixed on hppa*-*-hpux*. Also fixes mingw-w64, thank you!
[Bug bootstrap/68167] New: r229585 breaks mingw-w64 bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68167 Bug ID: 68167 Summary: r229585 breaks mingw-w64 bootstrap Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: ismail at i10z dot com Target Milestone: --- Hi, The error message is: ../../combined-6.0.0/gcc/ggc-common.c: In function 'void init_ggc_heuristics()': ../../combined-6.0.0/gcc/ggc-common.c:822:28: error: 'GGC_MIN_EXPAND' was not declared in this scope set_default_param_value (GGC_MIN_EXPAND, ggc_min_expand_heuristic ()); ^ ../../combined-6.0.0/gcc/ggc-common.c:822:71: error: 'set_default_param_value' was not declared in this scope set_default_param_value (GGC_MIN_EXPAND, ggc_min_expand_heuristic ()); ^ ../../combined-6.0.0/gcc/ggc-common.c:823:28: error: 'GGC_MIN_HEAPSIZE' was not declared in this scope set_default_param_value (GGC_MIN_HEAPSIZE, ggc_min_heapsize_heuristic ()); ^ Looks like one of the removed headers are actually needed.
[Bug c++/67081] FAIL: g++.dg/cpp0x/nsdmi-template14.C (test for errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67081 İsmail Dönmez changed: What|Removed |Added CC||ismail at i10z dot com --- Comment #1 from İsmail Dönmez --- Also see this on Linux x86-64.
[Bug go/68496] New: [libgo] reflect test fails on Linux x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68496 Bug ID: 68496 Summary: [libgo] reflect test fails on Linux x86-64 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: ismail at i10z dot com CC: cmang at google dot com Target Milestone: --- Getting: Aborted reflect.call.N13_reflect.Value /havana/sources/gcc-trunk/build/x86_64-pc-linux-gnu/libgo/gotest32408/test/value.go:450 reflect.Call.N13_reflect.Value /havana/sources/gcc-trunk/build/x86_64-pc-linux-gnu/libgo/gotest32408/test/value.go:300 reflect_test.TestCallWithStruct /havana/sources/gcc-trunk/build/x86_64-pc-linux-gnu/libgo/gotest32408/test/all_test.go:1492 testing.tRunner ../../../libgo/go/testing/testing.go:455 goroutine 16 [chan receive]: testing.RunTests ../../../libgo/go/testing/testing.go:561 testing.Run.pN9_testing.M ../../../libgo/go/testing/testing.go:493 main.main /havana/sources/gcc-trunk/build/x86_64-pc-linux-gnu/libgo/gotest32408/test/_testmain.go:146 created by main ../../../libgo/runtime/go-main.c:48 goroutine 18 [finalizer wait]: created by runtime_createfing ../../../libgo/runtime/mgc0.c:2577 goroutine 53 [sleep]: reflect_test.selectWatcher /havana/sources/gcc-trunk/build/x86_64-pc-linux-gnu/libgo/gotest32408/test/all_test.go:1383 created by reflect_test.$nested2 /havana/sources/gcc-trunk/build/x86_64-pc-linux-gnu/libgo/gotest32408/test/all_test.go:1113 FAIL: reflect λ ./gcc/gccgo -v Using built-in specs. COLLECT_GCC=./gcc/gccgo Target: x86_64-pc-linux-gnu Configured with: ../configure --prefix=/opt/gcc-trunk --enable-languages=c,c++,fortran,go --enable-checking=release --enable-ssp --disable-libssp --disable-libvtv --disable-libmpx --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --enable-linker-build-id --disable-plugin --enable-linux-futex --program-suffix=-6 --without-system-libunwind --with-tune=corei7-avx --with-build-config=bootstrap-lto --disable-multilib --disable-werror --disable-nls --with-fpmath=sse --enable-clocale=gnu Thread model: posix gcc version 6.0.0 20151123 (experimental) (GCC)
[Bug go/68496] [libgo] reflect test fails on Linux x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68496 --- Comment #2 from İsmail Dönmez --- (In reply to Ian Lance Taylor from comment #1) > I can not recreate this problem. It works fine for me. > > The stack trace is incomplete for some reason so I don't know what is going > wrong. > > If you cd into x86_64-pc-linux-gnu/libgo, you can run > make GOTESTFLAGS="--keep" reflect/check > Presumably that will fail. It will leave behind a gotest directory. In > that directory you will find an a.out executable. Running that executable > runs the test (you may have to set LD_LIBRARY_PATH so that it finds > libgo.so). Try running that executable under gdb and see if you can get a > better backtrace. Try export MALLOC_CHECK_=2 before testing. Backtrace shows an invalid free: (gdb) bt #0 0x7f8d36c51d38 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55 #1 0x7f8d36c5318a in __GI_abort () at abort.c:78 #2 0x7f8d36c960b0 in malloc_printerr (action=, str=0x7f8d36d840fa "free(): invalid pointer", ptr=, ar_ptr=) at malloc.c:5004 #3 0x00433298 in reflect.call.N13_reflect.Value (pointer=pointer@entry=0xc2080c56a0, op=..., param=...) at value.go:4 50 #4 0x004328d4 in reflect.Call.N13_reflect.Value (pointer=pointer@entry=0x7f8d33da0c40, in=...) at value.go:300 #5 0x0044ec3a in reflect_test.TestCallWithStruct (t=) at all_test.go:1492 #6 0x7f8d37e6f71c in testing.tRunner (test=0xc20807a318, param=) at ../../../libgo/go/testing/testing.go:4 55 #7 testing.$thunk15 (__go_thunk_parameter=) at ../../../libgo/go/testing/testing.go:560 #8 0x7f8d37d8fa9c in kickoff () at ../../../libgo/runtime/proc.c:235 #9 0x7f8d3812a135 in __morestack () at ../../../libgcc/config/i386/morestack.S:544 #10 0x7f8d36c62900 in ?? () from /lib64/libc.so.6 #11 0x in ?? ()
[Bug fortran/68227] ICE on using variable limit in forall header (gfc_do_allocate)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68227 İsmail Dönmez changed: What|Removed |Added CC||ismail at i10z dot com --- Comment #9 from İsmail Dönmez --- This test currently fails on Linux x86-64 machine. Is there a way to get a better debug output for the failure. For now I see: FAIL: gfortran.dg/pr68227.f90 -O (internal compiler error) FAIL: gfortran.dg/pr68227.f90 -O (test for excess errors)
[Bug fortran/68227] ICE on using variable limit in forall header (gfc_do_allocate)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68227 --- Comment #11 from İsmail Dönmez --- (In reply to Dominique d'Humieres from comment #10) > > This test currently fails on Linux x86-64 machine. Is there a way to get a > > better debug output for the failure. For now I see: > > > > FAIL: gfortran.dg/pr68227.f90 -O (internal compiler error) > > FAIL: gfortran.dg/pr68227.f90 -O (test for excess errors) > > It should be fixed after r230873. Indeed it is, thanks!
[Bug bootstrap/69310] [6 Regression] Revision r232454 breaks bootstrap on x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69310 İsmail Dönmez changed: What|Removed |Added CC||ismail at i10z dot com --- Comment #1 from İsmail Dönmez --- r232454 also breaks bootstrap for mingw-w64: libtool: compile: x86_64-w64-mingw32-c++ -L/havana/mingw-w64-6.0.0/x86_64-w64-mingw32/lib -L/havana/mingw-w64-6.0.0/mingw/lib -isystem /havana/mingw-w64-6.0.0/x86_64-w64-mingw32/include -isystem /havana/mingw-w64-6.0.0/mingw/include -I/havana/mingw-w64-build/combined-6.0.0/libstdc++-v3/../libgcc -I/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32 -I/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/include -I/havana/mingw-w64-build/combined-6.0.0/libstdc++-v3/libsupc++ -std=gnu++11 -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=cow-stdexcept.lo -g -O2 -c ../../../../../combined-6.0.0/libstdc++-v3/src/c++11/cow-stdexcept.cc -o cow-stdexcept.o ../../../../../combined-6.0.0/libstdc++-v3/src/c++11/cow-stdexcept.cc:235:70: warning: unused parameter 'exc' [-Wunused-parameter] _txnal_cow_string_C1_for_exceptions(void* that, const char* s, void *exc) ^ ../../../../../combined-6.0.0/libstdc++-v3/src/c++11/cow-stdexcept.cc: In function 'void* txnal_read_ptr(void* const*)': ../../../../../combined-6.0.0/libstdc++-v3/src/c++11/cow-stdexcept.cc:281:39: error: expected ',' before ')' token || sizeof(uint32_t) == sizeof(void*)); ^ ../../../../../combined-6.0.0/libstdc++-v3/src/c++11/cow-stdexcept.cc:281:39: error: expected string-literal before ')' token
[Bug bootstrap/69310] [6 Regression] Revision r232454 breaks bootstrap on x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69310 --- Comment #3 from İsmail Dönmez --- (In reply to torvald from comment #2) > (In reply to İsmail Dönmez from comment #1) > > r232454 also breaks bootstrap for mingw-w64: > > > > libtool: compile: x86_64-w64-mingw32-c++ > > -L/havana/mingw-w64-6.0.0/x86_64-w64-mingw32/lib > > -L/havana/mingw-w64-6.0.0/mingw/lib -isystem > > /havana/mingw-w64-6.0.0/x86_64-w64-mingw32/include -isystem > > /havana/mingw-w64-6.0.0/mingw/include > > -I/havana/mingw-w64-build/combined-6.0.0/libstdc++-v3/../libgcc > > -I/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/ > > include/x86_64-w64-mingw32 > > -I/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/ > > include -I/havana/mingw-w64-build/combined-6.0.0/libstdc++-v3/libsupc++ > > -std=gnu++11 -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra > > -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once > > -ffunction-sections -fdata-sections -frandom-seed=cow-stdexcept.lo -g -O2 -c > > ../../../../../combined-6.0.0/libstdc++-v3/src/c++11/cow-stdexcept.cc -o > > cow-stdexcept.o > > ../../../../../combined-6.0.0/libstdc++-v3/src/c++11/cow-stdexcept.cc:235:70: > > warning: unused parameter 'exc' [-Wunused-parameter] > > _txnal_cow_string_C1_for_exceptions(void* that, const char* s, void *exc) > > ^ > > ../../../../../combined-6.0.0/libstdc++-v3/src/c++11/cow-stdexcept.cc: In > > function 'void* txnal_read_ptr(void* const*)': > > ../../../../../combined-6.0.0/libstdc++-v3/src/c++11/cow-stdexcept.cc:281:39: > > error: expected ',' before ')' token > >|| sizeof(uint32_t) == sizeof(void*)); > >^ > > ../../../../../combined-6.0.0/libstdc++-v3/src/c++11/cow-stdexcept.cc:281:39: > > error: expected string-literal before ')' token > > is mingw's static_assert any different? Right now, I can't see how this > could produce this error: > > static_assert(sizeof(uint64_t) == sizeof(void*) > || sizeof(uint32_t) == sizeof(void*)); g++-5 on Linux does not compile that either, clang is more helpful to why: t.cpp:5:85: warning: static_assert with no message is a C++1z extension [-Wc++1z-extensions] So, just adding a message to static_assert fixes the issue here.
[Bug bootstrap/69386] New: [6 regression] r232586 breaks mingw-w64 bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69386
Bug ID: 69386
Summary: [6 regression] r232586 breaks mingw-w64 bootstrap
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: ismail at i10z dot com
Target Milestone: ---
With r232586 getting:
/bin/sh ../libtool --tag CXX --tag disable-shared --mode=compile
x86_64-w64-mingw32-c++ -L/havana/mingw-w64-6.0.0/x86_64-w64-mingw32/lib
-L/havana/mingw-w64-6.0.0/mingw/lib -isystem
/havana/mingw-w64-6.0.0/x86_64-w64-mingw32/include -isystem
/havana/mingw-w64-6.0.0/mingw/include
-I/havana/mingw-w64-build/combined-6.0.0/libstdc++-v3/../libgcc
-I/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32
-I/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/include
-I/havana/mingw-w64-build/combined-6.0.0/libstdc++-v3/libsupc++ -prefer-pic
-D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi -fdiagnostics-show-location=once-ffunction-sections
-fdata-sections -frandom-seed=eh_arm.lo -g -O2 -c -o eh_arm.lo
../../../../combined-6.0.0/libstdc++-v3/libsupc++/eh_arm.cc
libtool: compile: x86_64-w64-mingw32-c++
-L/havana/mingw-w64-6.0.0/x86_64-w64-mingw32/lib
-L/havana/mingw-w64-6.0.0/mingw/lib -isystem
/havana/mingw-w64-6.0.0/x86_64-w64-mingw32/include -isystem
/havana/mingw-w64-6.0.0/mingw/include
-I/havana/mingw-w64-build/combined-6.0.0/libstdc++-v3/../libgcc
-I/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32
-I/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/include
-I/havana/mingw-w64-build/combined-6.0.0/libstdc++-v3/libsupc++
-D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -frandom-seed=eh_arm.lo -g -O2 -c
../../../../combined-6.0.0/libstdc++-v3/libsupc++/eh_arm.cc -o eh_arm.o
In file included from
/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/include/stdlib.h:35:0,
from
/usr/lib64/gcc/x86_64-w64-mingw32/5.3.0/include/mm_malloc.h:27,
from
/usr/lib64/gcc/x86_64-w64-mingw32/5.3.0/include/xmmintrin.h:34,
from
/usr/lib64/gcc/x86_64-w64-mingw32/5.3.0/include/x86intrin.h:31,
from
/havana/mingw-w64-6.0.0/x86_64-w64-mingw32/include/winnt.h:1519,
from
/havana/mingw-w64-6.0.0/x86_64-w64-mingw32/include/minwindef.h:163,
from
/havana/mingw-w64-6.0.0/x86_64-w64-mingw32/include/windef.h:8,
from
/havana/mingw-w64-6.0.0/x86_64-w64-mingw32/include/windows.h:69,
from
/usr/lib64/gcc/x86_64-w64-mingw32/5.3.0/include/unwind.h:33,
from
../../../../combined-6.0.0/libstdc++-v3/libsupc++/unwind-cxx.h:36,
from
../../../../combined-6.0.0/libstdc++-v3/libsupc++/eh_arm.cc:26:
/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/include/cstdlib:
In function 'long long int std::abs(long long int)':
/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/include/cstdlib:178:20:
error: conflicting declaration of C function 'long long int std::abs(long long
int)'
abs(long long __x) { return __builtin_llabs (__x); }
^
/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/include/cstdlib:170:3:
note: previous declaration 'long int std::abs(long int)'
abs(long __i) { return __builtin_labs(__i); }
^
/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/include/cstdlib:
In function '__int128 std::abs(__int128)':
/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/include/cstdlib:183:33:
error: conflicting declaration of C function '__int128 std::abs(__int128)'
abs(__GLIBCXX_TYPE_INT_N_0 __x) { return __x >= 0 ? __x : -__x; }
^
/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/include/cstdlib:178:3:
note: previous declaration 'long long int std::abs(long long int)'
abs(long long __x) { return __builtin_llabs (__x); }
^
/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/include/cstdlib:183:33:
error: conflicting declaration of C function '__int128 std::abs(__int128)'
abs(__GLIBCXX_TYPE_INT_N_0 __x) { return __x >= 0 ? __x : -__x; }
^
/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/include/cstdlib:170:3:
note: previous declaration 'long int std::abs(long int)'
abs(long __i) { return __builtin_labs(__i); }
^
[Bug libstdc++/69386] [6 regression] r232586 breaks mingw-w64 bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69386 --- Comment #4 from İsmail Dönmez --- (In reply to Jonathan Wakely from comment #3) > Created attachment 37407 [details] > Set language linkage for C++ headers > > Does this fix it? Yes it does. Thanks!
[Bug bootstrap/67363] New: r227188 breaks build for mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67363 Bug ID: 67363 Summary: r227188 breaks build for mingw-w64 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: ismail at i10z dot com Target Milestone: --- After r227188 mingw-w64 build on Linux fails with: ../../combined-6.0.0/gcc/gcc.c: In member function 'void env_manager::xput(const char*)': ../../combined-6.0.0/gcc/gcc.c:126:50: error: 'strndup' was not declared in this scope kv.m_key = strndup (string, equals - string); ^ ../../combined-6.0.0/gcc/gcc.c: In member function 'void env_manager::restore()': ../../combined-6.0.0/gcc/gcc.c:154:2: error: '::setenv' has not been declared ::setenv (item->m_key, item->m_value, 1); ^ ../../combined-6.0.0/gcc/gcc.c:156:2: error: '::unsetenv' has not been declared ::unsetenv (item->m_key); ^
[Bug bootstrap/67363] [6 Regression] r227188 breaks build for mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67363 İsmail Dönmez changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #8 from İsmail Dönmez --- (In reply to Rainer Orth from comment #7) > Fixed for gcc 6. Your patch didnt fix the mingw part. Reopening.
[Bug bootstrap/67363] [6 Regression] r227188 breaks build for mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67363 --- Comment #9 from İsmail Dönmez --- Looks like on MinGW putenv has to be used instead of setenv/unsetenv, dmalcolm can you please have a look? I know MinGW is a Tier-NotSupported platform but it was at least compiling before this change.
[Bug c/101446] New: -Wpedantic causes an error with zero size array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101446
Bug ID: 101446
Summary: -Wpedantic causes an error with zero size array
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ismail at i10z dot com
Target Milestone: ---
The test-case minimized but originally from glibc:
; cat gbk.c
static const char __gbk_from_ucs4_tab9[][2] =
{
};
; gcc -c gbk.c
; gcc -c -Wpedantic gbk.c
gbk.c:2:1: warning: ISO C forbids empty initializer braces [-Wpedantic]
2 | {
| ^
gbk.c:1:19: error: zero or negative size array ‘__gbk_from_ucs4_tab9’
1 | static const char __gbk_from_ucs4_tab9[][2] =
| ^~~~
; gcc -v
(base)
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d,jit
--enable-offload-targets=nvptx-none,amdgcn-amdhsa, --without-cuda-driver
--enable-host-shared --enable-checking=release --disable-werror
--with-gxx-include-dir=/usr/include/c++/11 --enable-ssp --disable-libssp
--disable-libvtv --enable-cet=auto --disable-libcc1 --enable-plugin
--with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-libphobos
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-11 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic
--with-build-config=bootstrap-lto-lean --enable-link-mutex
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.1 20210625 [revision 62bbb113ae68a7e724255e17143520735bcb9ec9]
(SUSE Linux)
I believe no warning flag should result in an error.
[Bug c/101446] -Wpedantic causes an error with zero size array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101446
--- Comment #3 from İsmail Dönmez ---
(In reply to Richard Biener from comment #2)
> -Wpedantic is the same as -pedantic and that affects correctness of programs.
>
> @item -Wpedantic
> @itemx -pedantic
> @opindex pedantic
> @opindex Wpedantic
> @opindex Wno-pedantic
> Issue all the warnings demanded by strict ISO C and ISO C++;
> reject all programs that use forbidden extensions, and some other
> programs that do not follow ISO C and ISO C++. For ISO C, follows the
> version of the ISO C standard specified by any @option{-std} option used.
>
> Valid ISO C and ISO C++ programs should compile properly with or without
> this option (though a rare few require @option{-ansi} or a
> @option{-std} option specifying the required version of ISO C)@. However,
> without this option, certain GNU extensions and traditional C and C++
> features are supported as well. With this option, they are rejected.
Well, not quite so. I enabled -Wpedantic with glibc and have hundreds of
warnings and only the zero-size array one errors out. There is clearly an
inconsistency here.
[Bug c/101446] -Wpedantic causes an error with zero size array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101446 --- Comment #6 from İsmail Dönmez --- (In reply to Richard Biener from comment #4) > -Wpedantic was added as fix for PR44774 to make -Werror=pedantic work > (as opposed to -Werror=edantic) The problem is that it's inconsistent, here is a list of other -Wpedantic warnings that do not result in an error: ISO C does not support the '_Float128' type [-Wpedantic] ISO C does not support the '_Float32' type [-Wpedantic] ISO C does not support the '_Float32x' type [-Wpedantic] ISO C does not support the '_Float64' type [-Wpedantic] ISO C does not support the '_Float64x' type [-Wpedantic] ISO C does not support the ‘_Float128’ type [-Wpedantic] ISO C does not support the ‘_Float32x’ type [-Wpedantic] ISO C does not support the ‘_Float32’ type [-Wpedantic] ISO C does not support the ‘_Float64x’ type [-Wpedantic] ISO C does not support the ‘_Float64’ type [-Wpedantic] ISO C forbids 'goto *expr;' [-Wpedantic] ISO C forbids 'return' with expression, in function returning void [-Wpedantic] ISO C forbids an empty translation unit [-Wpedantic] ISO C forbids assignment between function pointer and 'void *' [-Wpedantic] ISO C forbids braced-groups within expressions [-Wpedantic] ISO C forbids conditional expr with only one void side [-Wpedantic] ISO C forbids conversion of function pointer to object pointer type [-Wpedantic] ISO C forbids conversion of object pointer to function pointer type [-Wpedantic] ISO C forbids empty initializer braces [-Wpedantic] ISO C forbids forward references to 'enum' types [-Wpedantic] ISO C forbids initialization between function pointer and 'void *' [-Wpedantic] ISO C forbids label declarations [-Wpedantic] ISO C forbids omitting the middle term of a '?:' expression [-Wpedantic] ISO C forbids passing argument 1 of '_dl_addr' between function pointer and 'void *' [-Wpedantic] ISO C forbids return between function pointer and 'void *' [-Wpedantic] ISO C forbids specifying range of elements to initialize [-Wpedantic]
[Bug c/101446] -Wpedantic causes an error with zero size array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101446 --- Comment #7 from İsmail Dönmez --- Well, it's even more confusing, grepping through glibc build log: ../include/stdlib.h:297:8: warning: ISO C forbids zero-size array 'msg' [-Wpedantic] 297 | char msg[0]; |^~~ ../inet/netinet/ip6.h:92:21: warning: ISO C forbids zero-size array 'ip6r0_addr' [-Wpedantic] 92 | struct in6_addr ip6r0_addr[0]; | ^~ So even the zero-size array warning behaves differently.
