[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183 --- Comment #16 from Iain Sandoe --- Created attachment 54170 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54170&action=edit Patch registration constructors This modifies the registration CTORs that are currently defined in C++ to be defined as 'extern "C"' and registered to be run at program load time. This is as described in comments #14 and 15.
[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183 --- Comment #17 from Iain Sandoe --- (In reply to Iain Sandoe from comment #16) > Created attachment 54170 [details] > Patch registration constructors > > This modifies the registration CTORs that are currently defined in C++ to be > defined as 'extern "C"' and registered to be run at program load time. > > This is as described in comments #14 and 15. I did not post this yet - because I was wondering if there is more needed (i.e. that the code-gen should also do something similar when .mods are compiled). For example, if I take a random test case, and examine the symbols - I see these CTORs - but I do not see any CTORs for non-library modules. Of course, that could also be a separate patch - don't think I know the m2 sources well enough to attempt it at present, tho.
[Bug middle-end/108256] New: Missing integer overflow instrumentation when assignment LHS is narrow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108256
Bug ID: 108256
Summary: Missing integer overflow instrumentation when
assignment LHS is narrow
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
For
unsigned short f(unsigned short x, unsigned short y)
{
return x * y;
}
unsigned short g(unsigned short x, unsigned short y)
{
int r = x * y;
return r;
}
gcc -O2 -fsanitize=undefined emits instrumentation only for 'g', although both
are equivalent. When 'int r' is changed to 'unsigned short r', 'g' is also not
instrumented.
PR 107912 shows a slightly more complicated variant of this. Affects both C and
C++.
[Bug c++/108257] New: Incorrect (non-unique) mangling of structured binding's backing variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108257
Bug ID: 108257
Summary: Incorrect (non-unique) mangling of structured
binding's backing variable
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
C++20 permits structured bindings (decomposition declarations) to be `static`.
This means we can use them in inline functions, where they need to be mangled
in the context of that inline function. Clang seems to get this right; GCC
forgets to include the context.
// https://godbolt.org/z/aKanscav3
struct A { int x,y; };
inline int f() {
static auto [a,b] = A{1,2};
return a;
}
inline int g() {
static auto [a,b] = A{3,4};
return a;
}
int (*pf)() = f;
int (*pg)() = g;
int main() {
printf("%d %d\n", f(), g());
printf("%d %d\n", pf(), pg());
}
This program should print "1 3" twice. On GCC, it fails to assemble, because
the symbol name `_ZNDC1a1bEE` is used for both backing variables.
On Clang, the symbol names are `_ZZ1fvEDC1a1bE` and `_ZZ1gvEDC1a1bE` instead.
(Totally off-topic, it is awful that the name of the backing variable includes
all of the names of the individual bindings, concatenated. That can easily
produce humongous symbol names, and interacts unusually poorly with (UB)
macro-expansion. If anyone wants to go talk to the Itanium ABI folks and get
everyone to switch to a simple "mangling number" scheme like we have already
built for lambda closure types, that would be awesome. Notice that you already
need a "mangling number" scheme *on top* of the current design, because of
https://godbolt.org/z/cYqxzxfxe — so I'm just proposing to make the scheme
simpler, if the Itanium ABI folks are willing to change it.)
[Bug modula2/107612] plugin/m2rte doesn't build on Mac OS X 10.7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612 --- Comment #11 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:ebc41f9a817dbae01c7450cd33c1968318ce8df0 commit r13-4939-gebc41f9a817dbae01c7450cd33c1968318ce8df0 Author: Rainer Orth Date: Thu Dec 15 10:43:37 2022 + modula-2: Fix building the plugin for Darwin [PR107612]. * Makes the configured value for INCINTL available as a variable so that it can be used in language makefile fragements. It is then used in the m2 fragment to make the include path available to the plugin compile. * Updates the DSO suffix to use .dylib for Darwin. * Adds '-Wl,-undefined,dynamic_lookup' to the link flags so that symbols can be resolved at runtime. * Removes the extraneous $(exeext) from the DSO names. Since the linking is driven by CXX, we also need to supress the addition of default libraries otherwise: (1) we will get a reference to an uninstalled libstdc++ (2) the process opening the plugin would have two instances 0f libstdc++ - one statically linked into gm2 and one dynamically linked into the plugin. PR modula2/107612 gcc/ChangeLog: * Makefile.in: Make the configured libintl includes avaiable in INCINTL. (BUILD_CPPFLAGS): Use INCINTL. gcc/m2/ChangeLog: * Make-lang.in (soext): Use .dylib for Darwin. (PLUGINLDFLAGS): Use dynmic lookup, set the plugin name, and append -nodefaultlibs to suppress the linking of libstdc++. Use INCINTL in compile lines for the plugin. Co-Authored-By: Iain Sandoe
[Bug target/105010] [12/13 regression] GCC 12 after 20220227 fails to build on powerpc64-freebsd with Error: invalid mfcr mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010 --- Comment #18 from Segher Boessenkool --- We have (since ten years or sp already) /* ISA 2.01 allowed FCFID to be done in 32-bit, previously it was 64-bit only. Enable 32-bit fcfid's on any of the switches for newer ISA machines. */ #define TARGET_FCFID(TARGET_POWERPC64 \ || TARGET_PPC_GPOPT/* 970/power4 */\ || TARGET_POPCNTB /* ISA 2.02 */ \ || TARGET_CMPB /* ISA 2.05 */ \ || TARGET_POPCNTD) /* ISA 2.06 */ I don't see how this can ever be enabled for 7450. But! We do not support 2.00 at all since quite a while (-mcpu=power4 does not mean 2.00, it means 2.02, i.e. POWER4+ actually), so this macro could be a lot simpler. Could you please show the generated .s file? (Compile with -S instead of -c).
[Bug libstdc++/108225] cross build gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 --- Comment #1 from cqwrteur --- a.cc include mutex #include x86_64-w64-mingw32-g++ -o a a.cc -Ofast -std=c++23 -s -flto -march=native -D_WIN32_WINNT=0x0500 (Any value which is below 0x0500 since GDB defines it with a lower value)
[Bug libstdc++/108225] cross build gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 --- Comment #2 from cqwrteur --- Created attachment 54171 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54171&action=edit Error message This is an example of how incorrectly discarding the support of old systems would randomly cause build issues. Please stop! Windows 95 support is extremely important
[Bug libstdc++/108225] cross build gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 --- Comment #3 from cqwrteur --- (In reply to cqwrteur from comment #2) > Created attachment 54171 [details] > Error message > > This is an example of how incorrectly discarding the support of old systems > would randomly cause build issues. > > Please stop! Windows 95 support is extremely important libstdc++ completely ignores __GTHREAD_HAS_COND macro which cause build failure for gdb
[Bug libstdc++/108225] cross build gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 --- Comment #4 from cqwrteur --- (In reply to cqwrteur from comment #3) > (In reply to cqwrteur from comment #2) > > Created attachment 54171 [details] > > Error message > > > > This is an example of how incorrectly discarding the support of old systems > > would randomly cause build issues. > > > > Please stop! Windows 95 support is extremely important > > > libstdc++ completely ignores __GTHREAD_HAS_COND macro which cause build > failure for gdb The entire win32 thread model is a mess. It does not support the thread model well enough while causing enormous pain. If users need threading, they can use posix and mcf. Why win32??
[Bug libstdc++/108225] cross build gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225
--- Comment #5 from cqwrteur ---
(In reply to cqwrteur from comment #4)
> (In reply to cqwrteur from comment #3)
> > (In reply to cqwrteur from comment #2)
> > > Created attachment 54171 [details]
> > > Error message
> > >
> > > This is an example of how incorrectly discarding the support of old
> > > systems
> > > would randomly cause build issues.
> > >
> > > Please stop! Windows 95 support is extremely important
> >
> >
> > libstdc++ completely ignores __GTHREAD_HAS_COND macro which cause build
> > failure for gdb
>
> The entire win32 thread model is a mess. It does not support the thread
> model well enough while causing enormous pain. If users need threading, they
> can use posix and mcf. Why win32??
BTW who gives you the luxury to include in public header? windows.h
causes enormous pain.
if you need them, you should use __asm__ macro to deal with apis in windows.h
instead of including them.
#if defined(_MSC_VER) && !defined(__clang__)
__declspec(dllimport)
#elif (__has_cpp_attribute(__gnu__::__dllimport__)&&!defined(__WINE__))
[[__gnu__::__dllimport__]]
#endif
#if (__has_cpp_attribute(__gnu__::__stdcall__)&&!defined(__WINE__))
[[__gnu__::__stdcall__]]
#endif
extern void*
#if (!__has_cpp_attribute(__gnu__::__stdcall__)&&!defined(__WINE__)) &&
defined(_MSC_VER)
__stdcall
#endif
MapViewOfFile(void*,std::uint_least32_t,std::uint_least32_t,std::uint_least32_t,std::size_t)
noexcept
#if defined(__clang__) || defined(__GNUC__)
#if SIZE_MAX<=UINT_LEAST32_MAX &&(defined(__x86__) || defined(_M_IX86) ||
defined(__i386__))
#if !defined(__clang__)
__asm__("MapViewOfFile@20")
#else
__asm__("_MapViewOfFile@20")
#endif
#else
__asm__("MapViewOfFile")
#endif
#endif
;
This is how you use them.
windows.h causes massive compilation speed to slow down.
[Bug libstdc++/108225] cross build gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 --- Comment #6 from cqwrteur --- x86_64-w64-mingw32/artifacts/hostbuild/x86_64-w64-mingw32/gcc/./isl/include -I/home/cqwrteur/toolchains_build/gcc/isl/include -o cp/cvt.o -MT cp/cvt.o -MMD -MP -MF cp/.deps/cvt.TPo /home/cqwrteur/toolchains_build/gcc/gcc/cp/cvt.cc make[2]: *** [Makefile:1148: diagnostic-color.o] Error 1 make[2]: *** Waiting for unfinished jobs /home/cqwrteur/toolchains_build/gcc/gcc/system.h:791:30: error: expected identifier before string constant 791 | #define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__) | ^~~~ /home/cqwrteur/toolchains_build/gcc/gcc/system.h:791:30: error: expected ',' or '...' before string constant /home/cqwrteur/toolchains_build/gcc/gcc/system.h:791:30: error: expected identifier before string constant 791 | #define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__) | ^~~~ /home/cqwrteur/toolchains_build/gcc/gcc/system.h:791:30: error: expected ',' or '...' before string constant It looks like macro pollution also causes the Canadian compilation for GCC to fail. __FILE__ macro fails.
[Bug libstdc++/108258] New: std::ranges::begin() fails on zero sized std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108258 Bug ID: 108258 Summary: std::ranges::begin() fails on zero sized std::array Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: mwd at md5i dot com Target Milestone: --- The following snippet fails to compile (with -std=c++20) in snapshot gcc-13-20221225. #include #include static constexpr std::array a; static constexpr auto b = std::ranges::begin(a); This appears to be because __array_traits::Type's members aren't constexpr. This compiled in gcc-12. Preprocessed sources attached.
[Bug libstdc++/108258] std::ranges::begin() fails on zero sized std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108258 --- Comment #1 from Michael Duggan --- Preprocessed source will be added once I've reduced it. In the meantime, the non-preprocessed source in the comment should be enough to trigger the problem with the specified version of gcc.
[Bug libstdc++/108258] std::ranges::begin() fails on zero sized std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108258 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0 Ever confirmed|0 |1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=104719 Status|UNCONFIRMED |NEW Last reconfirmed||2022-12-31 --- Comment #2 from Andrew Pinski --- (In reply to Michael Duggan from comment #1) > Preprocessed source will be added once I've reduced it. In the meantime, > the non-preprocessed source in the comment should be enough to trigger the > problem with the specified version of gcc. No reason for the preprocessed source as the problem is in the headers of libstdc++. Looks like it was introduced by r13-113-gef8d5ac08b5e .
[Bug c++/108257] Incorrect (non-unique) mangling of structured binding's backing variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108257 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-12-31 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug sanitizer/71962] error: ‘((& x) != 0u)’ is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71962 Andrew Pinski changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #10 from Andrew Pinski --- *** Bug 67762 has been marked as a duplicate of this bug. ***
[Bug c++/67762] [C++1z] 'not a constant expression" errors only with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67762 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #9 from Andrew Pinski --- Even though PR 71962 is reported after this bug, the comments has more analysis of what is going on so closing as a dup. *** This bug has been marked as a duplicate of bug 71962 ***
