TomAokigcc14 is reported to be problematic on building math/openblas by another user.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284425#c35
Sean Murthy@strudlzrout That is an impressive list of changes. Thanks for the summary and for your contribution. ππ½
Just a minor correction for the code snippet for "CTAD from inherited constructors". I believe the end-of-line comment on the last line should say C<int*> instead of C<int>:
`//OK, deduces C<int*> `
For my own benefit, I made an example with two separate derived classes: one for T, another for T*. It helps me fully appreciate the feature's power.
Compiler Explorer - C++
//C++23: CTAD from inherited ctors, now works in GCC 14.1 //implements P2582R1: https://wg21.link/P2582R1 template<typename T> struct B { B(T); }; template<typename T> struct C : B<T> { using B<T>::B; }; template<typename T> struct P : B<T*> { using B<T*>::B; }; int main() { int i{}; C ci(i); //OK, deduces C<int> float f{}; C cf(f); //OK, deduces C<float> P pi(&i); //OK, deduces P<int*> }
Harry Sintonen#GCC14 promoted some warnings to errors. This can break #autoconf, #CMake, #Meson or other build environments autoprobing for features, resulting in code built with missing or altered functionality. This could even lead to security impact, if some security related feature is unexpectedly not enabled.
Passing CC as "gcc -fpermissive" should fix this. If this is not an option there's even the nuclear option of adding a gcc wrapper script that does:
#!/bin/sh
exec /usr/bin/gcc -fpermissive "$@"
EDIT: I do not mean to say that these new options should blanket-disabled globally. There however are currently some packages that have problems with GCC 14 (missing features or existing functions not being used, or just failing to build). Naturally these packages should be fixed themselves. Meanwhile -fpermissive will allow building most of these troublesome packages.
Ported #gcc14 for #MorphOS. The #rust frontend #gccrs works and produces working code, too. The usability of this thing is currently somewhat limited of course as gccrs is still experimental.
GCC 14.1 fixes most of the issues with constrained type parameters in template template parameters (at least) in an aliased template. βπ½
So, for me, upgrading to GCC 14.1 is absolutely worth it.
Here is the revised code and link if you wish to compare and experiment:
Compiler Explorer - C++
//template template parameter with type parameter template<template <std::integral T> class V> class C {}; //template template parameter with non-type parameter template<template <int I> class V> class D {}; //aliases of interest follow: all tested with C++20 //compiler versions mentioned are how far back I tested, //or the first compiler version I have access with C++20 support //results: //A1, A2: OK with GCC (back to 10.5) and Clang (back to 11.0.0) //A3: OK with GCC 10.5 and Clang (back to 11.0.0); fails since GCC 11.1 //A4: OK with GCC 10.5 and Clang (back to 11.0.0); fails since GCC 11.1 //A5: fails since GCC 10.5; fails up to Clang 15.0; OK since Clang 16.0 //A6: included to demonstrate no issues with constraint on non-type parameter template<template<typename> class V> using A1 = C<V>; //OK template<template<class> class V> using A2 = C<V>; //OK template<template<std::integral> class V> using A3 = C<V>; //Error: since GCC 11.1 up to 13.2; OK in GCC 14.1; OK in GCC 10.5 and since Clang 11.0 template<template<typename T> requires std::integral<T> class V> using A4 = C<V>; //Error: since GCC 11.1 up to 13.2; OK in GCC 14.1; OK in GCC 10.5 and since Clang 11.0 template<template<typename T> requires std::is_integral_v<T> class V> using A5 = C<V>; //Error: since GCC 10.5 and up to Clang 15.0; OK since Clang 16.0 //no error for constrained non-type parameter in template template parameter template<template<int I> requires (I != 10) class V> using A6 = D<V>; //Error: up to Clang 15.0; OK since Clang 16.0; OK since GCC 10.5 int main(){} /* GCC 13.2 error messaages <source>:31:15: error: constraint mismatch at argument 1 in template parameter list for 'template<template<class T> class requires integral<T> V> class C' 31 | using A3 = C<V>; //Error: since GCC 11.1; OK in GCC 10.5 and since Clang 11.0 | ^ <source>:31:15: note: expected 'template<class T> class requires integral<T> V' but got 'template<class> class requires integral< <template-parameter-2-1> > V' <source>:34:15: error: constraint mismatch at argument 1 in template parameter list for 'template<template<class T> class requires integral<T> V> class C' 34 | using A4 = C<V>; //Error: since GCC 11.1; OK in GCC 10.5 and since Clang 11.0 | ^ <source>:34:15: note: expected 'template<class T> class requires integral<T> V' but got 'template<class T> class requires integral<T> V' <source>:37:15: error: constraint mismatch at argument 1 in template parameter list for 'template<template<class T> class requires integral<T> V> class C' 37 | using A5 = C<V>; //Error: since GCC 10.5 and up to Clang 15.0; OK since Clang 16.0 | ^ <source>:37:15: note: expected 'template<class T> class requires integral<T> V' but got 'template<class T> class requires is_integral_v<T> V' */
Deadly Headshot@mxk
"For one, GCC 14 gains a new "-Wanalyzer-infinite-loop" option to try to detect simple cases of infinite loops occurring" - isn't this the halting problem? Have they solved it somehow? Does #GCC14 run on #QuantumComputers?
"For one, GCC 14 gains a new "-Wanalyzer-infinite-loop" option to try to detect simple cases of infinite loops occurring" - isn't this the halting problem? Have they solved it somehow? Does #GCC14 run on #QuantumComputers?
DJ-BauerDavid Malcolm has massively increased the scope for which the #GCC14 static code analyzer can find bugs.
My personal highlight include:
- possible infinite loop detection (yet still not solving the halting problem smh)
- visual appealing buffer overflows including proper display of UTF-8 unicode characters in strings.
- __attribute for Functions, which require a null terminated string to communicate that
- Checks for input sanitation, that could lead to exploits.
https://developers.redhat.com/articles/2024/04/03/improvements-static-analysis-gcc-14-compiler
My personal highlight include:
- possible infinite loop detection (yet still not solving the halting problem smh)
- visual appealing buffer overflows including proper display of UTF-8 unicode characters in strings.
- __attribute for Functions, which require a null terminated string to communicate that
- Checks for input sanitation, that could lead to exploits.
https://developers.redhat.com/articles/2024/04/03/improvements-static-analysis-gcc-14-compiler
