[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #12 from ofv at wanadoo dot es --- I don't see other failure messages on the previous dozens of lines but, if they exist, they are not deemed serious enough to stop the build by the build system. BTW, we successfully built gcc-11-dwarf with gcc-10-sjlj. Now we will see if the resulting binaries work for bootstrapping gcc-11. That would suggest that there is a problem with 10 and it is fixed/masked/whatever on 11.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #10 from ofv at wanadoo dot es --- Setting CFLAGS/CXXFLAGS/BOOT_CFLAGS to -dwarf-4 has no effect: the build fails the same.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #9 from ofv at wanadoo dot es --- With those variables unset the build fails the same. Other users reported that only DWARF crashes. If the build is configured for SJLJ or SEH exception models, it completes. A user speculated that the problem might be related to Gcc 11 using DWARF 5 now. If you think that that is plausible and instruct me on how to revert that change I'll test the hypothesis.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #7 from ofv at wanadoo dot es --- make BOOT_CFLAGS='-O1' V=1 all make BOOT_CFLAGS='-O0' V=1 both fails the same way as the initial report. export CFLAGS="-march=i686 -mtune=generic -O0 -pipe" export CXXFLAGS="-march=i686 -mtune=generic -O0 -pipe" make BOOT_CFLAGS='-O0' V=1 fails on configure: error: unsupported system, cannot find sizeof (omp_lock_t) make[2]: *** [Makefile:24035: configure-stage1-target-libgomp] Error 1 (this is before the build reaches the failure point discussed on this bug report). Finally, trying to reduce as much as possible the optimization passes: export CFLAGS="-march=i686 -mtune=generic -Og -pipe" export CXXFLAGS="-march=i686 -mtune=generic -Og -pipe" make BOOT_CFLAGS='-Og' V=1 fails the same way as the initial report.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #5 from ofv at wanadoo dot es --- Taken from config.log: ac_cs_config=" '--prefix=/mingw32' '--with-local-prefix=/mingw32/local' '--build=i686-w64-mingw32' '--host=i686-w64-mingw32' '--target=i686-w64-mingw32' '--with-native-system-header-dir=/mingw32/i686-w64-mingw32/include' '--libexecdir=/mingw32/lib' '--enable-bootstrap' '--enable-checking=release' '--with-arch=i686' '--with-tune=generic' '--enable-shared' '--enable-static' '--enable-libatomic' '--enable-threads=posix' '--enable-graphite' '--enable-fully-dynamic-string' '--enable-libstdcxx-filesystem-ts' '--enable-libstdcxx-time' '--disable-libstdcxx-pch' '--disable-libstdcxx-debug' '--enable-lto' '--enable-libgomp' '--disable-multilib' '--disable-rpath' '--disable-win32-registry' '--disable-nls' '--disable-werror' '--disable-symvers' '--with-libiconv' '--with-system-zlib' '--with-gmp=/mingw32' '--with-mpfr=/mingw32' '--with-mpc=/mingw32' '--with-isl=/mingw32' '--with-pkgversion=Rev1, Built by MSYS2 project' '--with-bugurl=https://github.com/msys2/MINGW-packages/issues' '--with-gnu-as' '--with-gnu-ld' '--with-boot-ldflags=-pipe -Wl,--dynamicbase,--nxcompat,--no-seh -Wl,--large-address-aware -Wl,--disable-dynamicbase -static-libstdc++ -static-libgcc' 'LDFLAGS_FOR_TARGET=-pipe -Wl,--dynamicbase,--nxcompat,--no-seh -Wl,--large-address-aware' '--enable-linker-plugin-flags=LDFLAGS=-static-libstdc++\\ -static-libgcc\\ -pipe\\ -Wl,--dynamicbase,--nxcompat,--no-seh\\ -Wl,--large-address-aware\\ -Wl,--stack,12582912' '--disable-sjlj-exceptions' '--with-dwarf2' 'build_alias=i686-w64-mingw32' 'host_alias=i686-w64-mingw32' 'target_alias=i686-w64-mingw32' 'CC=gcc' 'CFLAGS=-march=i686 -mtune=generic -O2 -pipe' 'LDFLAGS=-pipe -Wl,--dynamicbase,--nxcompat,--no-seh -Wl,--large-address-aware -Wl,--disable-dynamicbase' 'CPPFLAGS=-D__USE_MINGW_ANSI_STDIO=1' 'CXX=g++' 'CXXFLAGS=-march=i686 -mtune=generic -O2 -pipe' '--enable-languages=c,ada,c++,fortran,jit,lto,objc,obj-c++'"
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #4 from ofv at wanadoo dot es --- (In reply to Eric Botcazou from comment #3) > We definitely cannot investigate this without more information, in > particular the configure line. Barring that, you might want to try with the > current gcc-11 branch where a very recent change could help. Which change? 014e6aa467b1648d09eab9897ca367bfec5e6b76 ? Applying that on top of gcc 11.1 makes no difference. Sorry for not providing the configure line yet. I'll try to setup a local build environment ASAP.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 ofv at wanadoo dot es changed: What|Removed |Added CC||ofv at wanadoo dot es --- Comment #2 from ofv at wanadoo dot es --- IIUC the problem consists on the compiler crashing, so no "error message from the compiler". You can see the full build output here: https://github.com/msys2/MINGW-packages/pull/8320/checks?check_run_id=2534098704 As for the configure line, it is not shown on the build output, I'll try to get it from elsewhere. Meanwhile, you can look at the relevant point of the build script here: https://github.com/msys2/MINGW-packages/blob/134b37fb4bc9b395615cfdf701aeb0635c54fa1a/mingw-w64-gcc/PKGBUILD#L197
[Bug c++/90664] [7/8 regression] noexcept confuses template argument deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90664 ofv at wanadoo dot es changed: What|Removed |Added Summary|noexcept confuses template |[7/8 regression] noexcept |argument deduction |confuses template argument ||deduction --- Comment #2 from ofv at wanadoo dot es --- The upcoming gcc 11 still shows this problem. I edited the bug title to indicate that it is a regression.
[Bug c++/90664] New: noexcept confuses template argument deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90664
Bug ID: 90664
Summary: noexcept confuses template argument deduction
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ofv at wanadoo dot es
Target Milestone: ---
consider this code:
<<<<<<<<<<<<<<<<<<
template struct OpM;
template
struct OpM
{};
class Class {
public:
int address() noexcept { return 0; }
void address(int) noexcept {}
};
struct Sk {
template Sk(R (C::*p)()) {
typedef OpM OP;
}
};
Sk sk(static_cast(&Class::address));
>>>>>>>>>>>>>>>>>>>>>>>>
$ g++.exe -std=c++17 -fsyntax-only -c kk.cpp
kk.cpp: In instantiation of 'Sk::Sk(R (C::*)()) [with C = Class; R = int]':
kk.cpp:19:53: required from here
kk.cpp:15:64: error: 'int (Class::*)(){((int (Class::*)())Class::address), 0}'
is not a valid template argument for type 'int (Class::*)()'
15 | typedef OpM OP;
|^~
kk.cpp:15:64: note: it must be a pointer-to-member of the form '&X::Y'
The error message is obviously wrong.
Also, I suppose that noexcept is leaking. The static_cast has no problem
deducing the correct overload without mentioning noexcept but then the
instantiation of Sk in the typedef fails because noexcept is missing
(unconmment the noexcept and the compilation succeeds).
The problem was first noticed with gcc 8.x and boost 1.70.
[Bug libstdc++/63227] regex_replace fails on BOOST example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63227 ofv at wanadoo dot es changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from ofv at wanadoo dot es --- Thanks for the correction and sorry for the noise.
[Bug libstdc++/63227] New: regex_replace fails on BOOST example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63227
Bug ID: 63227
Summary: regex_replace fails on BOOST example
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ofv at wanadoo dot es
Created attachment 33473
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33473&action=edit
Adapted example from boost::regex
The attached code is adapted from the credit_card.cpp example of boost::regex.
When compiled using boost::regex
g++ -std=c+11 -DBOOST credit_card.cpp -lboost_regex
the output is as expected:
machine_readable_card_number("") returned
machine_readable_card_number(" ") returned
machine_readable_card_number("---") returned
machine_readable_card_number("000---") returned 000
human_readable_card_number("") returned ---
human_readable_card_number(" ") returned ---
human_readable_card_number("---") returned ---
human_readable_card_number("000---") returned 000---
but when compiled with std::regex then std::regex_replace simply returns the
same string it is given:
g++ -std=c++11 credit_card.cpp
machine_readable_card_number("") returned
machine_readable_card_number(" ") returned
machine_readable_card_number("---") returned
---
machine_readable_card_number("000---") returned 000---
human_readable_card_number("") returned
human_readable_card_number(" ") returned
human_readable_card_number("---") returned ---
human_readable_card_number("000---") returned 000---
[Bug libstdc++/63219] New: Superfluous template parameter in match_result::format overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63219
Bug ID: 63219
Summary: Superfluous template parameter in match_result::format
overload
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ofv at wanadoo dot es
This method:
template
basic_string
format(const basic_string& __fmt,
match_flag_type __flags = regex_constants::format_default) const
{
basic_string __result;
format(std::back_inserter(__result), __fmt, __flags);
return __result;
}
in std::match_results contains "typename _Out_iter", which seems a copy&pasto.
Trying to use this method results on a compile error.
[Bug c++/56746] [4.8 regression] increased memory usage when compiling C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56746 ofv at wanadoo dot es changed: What|Removed |Added CC||ofv at wanadoo dot es --- Comment #13 from ofv at wanadoo dot es --- My case is similar to the one described by Mathias Gaunard, but with a difference of 3x memory usage when -ftrack-macro-expansion=0 is not added to the command line. I use Boost Preprocessor plus a number of macros to define and instantiate lots of templates. That's the case that requires 3x more memory (low estimate) with some TUs requiring way more than 1GB to compile (on a 32 bit machine, which means that parallel builds usually ends with massive swapping and the compile jobs killed due to memory starvation.) I have a version of the same code base that uses variadic templates instead of Boost Preprocessor, although the macros for instantiating the templates are still there. That requires about 1.5x more memory.
[Bug c++/21675] New: -fvisibility : misleading documentation and low QoI
The -fvisibility documentation talks about declarations when explaining where
to
put __attribute__ ((visibility("default"))). However, compiling this code:
class __attribute__ ((visibility("default"))) Foo;
class Foo {};
produces a warning:
warning: type attributes are honored only at type definition
The mentions to Windows DLLs on the documentation and the web pages it refers
to
are misleading: Windows compilers allows dll-exporting by putting
__declspec(dllexport) on the declarations. Lots of dll-aware Windows and
cross-platform code (ex. wxWindows) puts the __declspect(dllexport|dllimport)
on
declarations. By disallowing attributes on declarations, you difficult the use
of the visibility feature for those libraries and break the builds on Windows
with MinGW.
I suggest to allow (at least certain) attributes on declarations as it was the
case for MinGW until recently or change the -fvisibility documentation for
explicitly saying that __attribute__ ((visibility("default"))) should be used
on
definitions only.
--
Summary: -fvisibility : misleading documentation and low QoI
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ofv at wanadoo dot es
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21675
