[Bug testsuite/106680] Test gcc.target/powerpc/bswap64-4.c fails on 32-bit BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106680 Kewen Lin changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |13.0 Status|ASSIGNED|RESOLVED --- Comment #4 from Kewen Lin --- Should be fixed on trunk.
[Bug c++/108282] Disabled template method using requires-clause still viable through requires-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108282 Martin Turski changed: What|Removed |Added CC||turningtides at outlook dot de --- Comment #1 from Martin Turski --- Created attachment 54186 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54186=edit alternative that works on latest MSVC but fails on GCC https://godbolt.org/z/57WsWr8rE
[Bug libstdc++/108260] __cpp_lib_ranges_zip feature test macro not defined while std::views::zip is supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108260 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #2 from Jiang An --- > I'm not sure if the feature is actually complete yet. It wasn't all done in a > single patch. I think the changes in P2321R2 are all done (except for the missing feature test macro). --- Changes of pair, tuple, vector::reference: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=72886fcc6269531bbf3d9a09b3d64644963bff0d zip_view: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=49e25d3e29aa1b56e6e82654de1a452a6cedc265 zip_transform_view: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1a93a84b9e01d0dd5156be8d686e8666a6fc45a8 adjacent_view: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=f956cadc292aec42ceeba1e4835ad795c9aab5c2 adjacent_transform_view: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0cb8d96157a95b7619ef1ccf28051181415fe989 LWG3692 & LWG3702: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d0fd62d0ff4d1e0648e11b650b4f449772663990 Clarifications in "Conversion and common type for integer-class types" are superseded by P2393R1 and perhaps don't require changes. Fixes for testsuites: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=f46f58e61db3b1e71beb21443c0ca9387bc836e2 PR106766: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=718a6d475b3d17759618c68331c85f55c58ec9a3 PR106798: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e469506b7fdd1bf2c958ca3140573a474fcba3b8 PR106803: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8298427f6b546cabb853edd45c009cd1967b9d38
[Bug c++/108282] New: Disabled template method using requires-clause still viable through requires-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108282
Bug ID: 108282
Summary: Disabled template method using requires-clause still
viable through requires-expression
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: turningtides at outlook dot de
Target Milestone: ---
Created attachment 54185
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54185=edit
source code for gcc 12.2
$ gcc bug.cpp -std=c++20
Log:
bug.cpp: In function ‘int main()’:
bug.cpp:13:33: error: static assertion failed
13 | static_assert( TEST > == false );
|~^~~~
bug.cpp:13:33: note: the comparison reduces to ‘(1 == 0)’
bug.cpp:15:14: error: no matching function for call to ‘B::TT()’
15 | B ::TT();// fails to compile!
| ~^~
bug.cpp:7:24: note: candidate: ‘static void B::TT() requires TEST
[with AT = C]’
7 | static inline void TT() noexcept requires ( TEST );
|^~
bug.cpp:7:24: note: constraints not satisfied
bug.cpp: In instantiation of ‘static void B::TT() requires TEST [with
AT = C]’:
bug.cpp:15:14: required from here
bug.cpp:2:9: required for the satisfaction of ‘TEST’ [with AT = C]
bug.cpp:2:16: in requirements [with T = C]
bug.cpp:2:30: note: the required expression ‘T::TT’ is invalid
2 | concept TEST = requires { T::TT; };
| ^~
cc1plus: note: set ‘-fconcepts-diagnostics-depth=’ to at least 2 for more
detail
[Bug modula2/108182] gm2 driver mishandles target and multilib options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182 --- Comment #4 from Gaius Mulley --- Created attachment 54184 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54184=edit Potential fix for target multilib_dir handling -m and -f. Work in progress.
[Bug middle-end/108278] [13 Regression] runtime error with -O1 -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278 --- Comment #2 from Andrew Pinski --- Note the original testcase does (inside _M_max_size): return std::size_t(0x7fffL) / sizeof(_Tp); Which was reduced to just: attach___trans_tmp_3 = 9223372036854775807 / 2;
[Bug middle-end/108278] [13 Regression] runtime error with -O1 -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Blocks||63426 Target Milestone|--- |13.0 Summary|runtime error with -O1 |[13 Regression] runtime |-Wall |error with -O1 -Wall Component|c++ |middle-end Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 [Bug 63426] [meta-bug] Issues found with -fsanitize=undefined
[Bug testsuite/108280] [10 regression] Many lto excess errors after r10-11132-gf543f71c54be74
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108280 Andrew Pinski changed: What|Removed |Added Component|lto |testsuite Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-01-04 Target Milestone|--- |10.5 --- Comment #1 from Andrew Pinski --- Most likely forgot to backport the following patches: r12-747-gfc186594e3ee86 r12-6144-g05edf6c470ae0a This is just a testsuite issue really. That is the everything is correct just the testsuite is not pruning these warnings and all.
[Bug tree-optimization/108281] float value range estimation missing (vs. integer)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108281 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Component|target |tree-optimization
[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 #20 from Segher Boessenkool --- (In reply to Segher Boessenkool from comment #18) > 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. It means 2.01, sorry. Nasty typo :-( So, although we get .machine "7450" in the generated assembler code, the compiler uses the default -mcpu=power4 otherwise. Some logic there is broken.
[Bug target/108281] float value range estimation missing (vs. integer)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108281 --- Comment #1 from Alexander Kleinsorge --- (same for types double and long-double)
[Bug target/108281] New: float value range estimation missing (vs. integer)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108281
Bug ID: 108281
Summary: float value range estimation missing (vs. integer)
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: aleks at physik dot tu-berlin.de
Target Milestone: ---
"gcc -O3" and optional: "-funsafe-math-optimizations" (isnan)
GCC ignores ranges of float numbers for optimization, tested via
https://godbolt.org/
For many frequent used functions (or even all in math.h) gcc could know a range
limit and concidering it for comparisons.
#include
int ranges(float x) {
if (x!=x) return -1; // optional NAN check
if (cos(x) < -1.0f) return -2;
if (sin(x) > 1.0f) return -3;
if (fabs(x) < 0.0f) return -4;
if (atan(x) < -2.0f) return -5; // +-PI/2
if (exp(x) < 0.0f) return -6;
if (sqrt(x) < 0.0f) return -7;
if (log(x) < 90.0f) return -8; // ln(FLT_MAX)=88.8
// ln(DBL_MAX) = 709.8
return 0; // the only valid return (beside -1)
}
int sqr2(float x) { // squares give non-negative results
return x*x < 0.0f; // == false
}
int ax2(float x) {
return fabs(x) > -1.0f; // == true
}
int cmp_sqrt(float x, float y) { // similar (!sadly very often seen!)
//x = fabs(x); y = fabs(y); // optional sign removal line
return sqrtf(x) < sqrtf(y); // == (x < y), hint: sqrt=slow
}
[Bug lto/108280] New: [10 regression] Many lto excess errors after r10-11132-gf543f71c54be74
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108280 Bug ID: 108280 Summary: [10 regression] Many lto excess errors after r10-11132-gf543f71c54be74 Product: gcc Version: 10.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- g:f543f71c54be74256fb4ff7ab0142ffee55e999c, r10-11132-gf543f71c54be74 FAIL: g++.dg/lto/20081022 cp_lto_20081022_0.o-cp_lto_20081022_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: g++.dg/lto/20081022 cp_lto_20081022_0.o-cp_lto_20081022_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: g++.dg/lto/20081118 cp_lto_20081118_0.o-cp_lto_20081118_1.o link, -fPIC -flto -flto-partition=1to1 -r -nostdlib FAIL: g++.dg/lto/20081118-1 cp_lto_20081118-1_0.o-cp_lto_20081118-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: g++.dg/lto/20081118-1 cp_lto_20081118-1_0.o-cp_lto_20081118-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: g++.dg/lto/20081119 cp_lto_20081119_0.o-cp_lto_20081119_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: g++.dg/lto/20081119 cp_lto_20081119_0.o-cp_lto_20081119_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: g++.dg/lto/20081119-1 cp_lto_20081119-1_0.o-cp_lto_20081119-1_1.o link, -fPIC -flto -flto-partition=1to1 -r -nostdlib FAIL: g++.dg/lto/20081123 cp_lto_20081123_0.o-cp_lto_20081123_1.o link, -flto -flto-partition=1to1 -r -nostdlib -fPIC FAIL: g++.dg/lto/20081125 cp_lto_20081125_0.o-cp_lto_20081125_1.o link, -flto -flto-partition=1to1 FAIL: g++.dg/lto/20081127 cp_lto_20081127_0.o-cp_lto_20081127_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: g++.dg/lto/20081203 cp_lto_20081203_0.o-cp_lto_20081203_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: g++.dg/lto/20081203 cp_lto_20081203_0.o-cp_lto_20081203_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: g++.dg/lto/20081204-1 cp_lto_20081204-1_0.o-cp_lto_20081204-1_1.o link, -flto -flto-partition=1to1 -fPIC -r -nostdlib FAIL: g++.dg/lto/20081209 cp_lto_20081209_0.o-cp_lto_20081209_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: g++.dg/lto/20081209 cp_lto_20081209_0.o-cp_lto_20081209_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: g++.dg/lto/20081211-1 cp_lto_20081211-1_0.o-cp_lto_20081211-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: g++.dg/lto/20081211-1 cp_lto_20081211-1_0.o-cp_lto_20081211-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: g++.dg/lto/20081219 cp_lto_20081219_0.o-cp_lto_20081219_1.o link, -fPIC -flto -flto-partition=1to1 -O2 FAIL: g++.dg/lto/20090302 cp_lto_20090302_0.o-cp_lto_20090302_1.o link, -fPIC -flto -flto-partition=1to1 -r FAIL: g++.dg/lto/20090311 cp_lto_20090311_0.o-cp_lto_20090311_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: g++.dg/lto/20090311 cp_lto_20090311_0.o-cp_lto_20090311_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: g++.dg/lto/20090311-1 cp_lto_20090311-1_0.o-cp_lto_20090311-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: g++.dg/lto/20090311-1 cp_lto_20090311-1_0.o-cp_lto_20090311-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: g++.dg/lto/20090312 cp_lto_20090312_0.o-cp_lto_20090312_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: g++.dg/lto/20090312 cp_lto_20090312_0.o-cp_lto_20090312_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: g++.dg/lto/20090313 cp_lto_20090313_0.o-cp_lto_20090313_1.o link, -flto -flto-partition=1to1 -fPIC FAIL: g++.dg/lto/20090315 cp_lto_20090315_0.o-cp_lto_20090315_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: g++.dg/lto/20090315 cp_lto_20090315_0.o-cp_lto_20090315_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: g++.dg/lto/20091026-1 cp_lto_20091026-1_0.o-cp_lto_20091026-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: g++.dg/lto/20091026-1 cp_lto_20091026-1_0.o-cp_lto_20091026-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: g++.dg/lto/20091210-1 cp_lto_20091210-1_0.o-cp_lto_20091210-1_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL: g++.dg/lto/20091210-1 cp_lto_20091210-1_0.o-cp_lto_20091210-1_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin FAIL:
gcc-11: FTBFS on hurd-i386
Source: gcc-11
Version: 11.3.0-10
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Affects: gcc-11, gcc-snapshot
X-Debbugs-CC: debian-h...@lists.debian.org
Hi,
gcc-11-11.3.0-10 in sid FTBFS on hurd-i386 due to failing linkage of
pthread_once (same error already fixed in gcc-12 and gcc-13):
/<>/build/i686-gnu/libstdc++-v3/include/i686-gnu/bits/gthr-
default.h:700: undefined reference to `pthread_once'
and more.
The patch at hand is: libstdc++-hurd.diff, attached here for convenience.
Thanks!
This is notably needed because in glibc 2.34, the move of pthread functions
into libc.so happened for Linux only, not GNU/Hurd.
The pthread_self() function can also always be used fine as it is on
GNU/Hurd.
libstdc++-v3/ChangeLog:
* config/os/gnu-linux/os_defines.h [!__linux__]
(_GLIBCXX_NATIVE_THREAD_ID, _GLIBCXX_GTHREAD_USE_WEAK): Do not define.
--- a/libstdc++-v3/config/os/gnu-linux/os_defines.h
+++ b/libstdc++-v3/config/os/gnu-linux/os_defines.h
@@ -49,22 +49,24 @@
// version dynamically in case it has changed since libstdc++ was configured.
#define _GLIBCXX_NO_OBSOLETE_ISINF_ISNAN_DYNAMIC __GLIBC_PREREQ(2,23)
-#if __GLIBC_PREREQ(2, 27)
-// Since glibc 2.27 pthread_self() is usable without linking to libpthread.
-# define _GLIBCXX_NATIVE_THREAD_ID pthread_self()
-#else
+#ifdef __linux__
+# if __GLIBC_PREREQ(2, 27)
+// Since glibc 2.27 Linux' pthread_self() is usable without linking to libpthread.
+# define _GLIBCXX_NATIVE_THREAD_ID pthread_self()
+# else
// Before then it was in libc.so.6 but not libc.a, and always returns 0,
// which breaks the invariant this_thread::get_id() != thread::id{}.
// So only use it if we know the libpthread version is available.
// Otherwise use (__gthread_t)1 as the ID of the main (and only) thread.
-# define _GLIBCXX_NATIVE_THREAD_ID \
- (__gthread_active_p() ? __gthread_self() : (__gthread_t)1)
-#endif
+# define _GLIBCXX_NATIVE_THREAD_ID \
+ (__gthread_active_p() ? __gthread_self() : (__gthread_t)1)
+# endif
-#if __GLIBC_PREREQ(2, 34)
-// Since glibc 2.34 all pthreads functions are usable without linking to
+# if __GLIBC_PREREQ(2, 34)
+// Since glibc 2.34 all Linux pthreads functions are usable without linking to
// libpthread.
-# define _GLIBCXX_GTHREAD_USE_WEAK 0
+# define _GLIBCXX_GTHREAD_USE_WEAK 0
+# endif
#endif
#endif
[Bug c++/108278] runtime error with -O1 -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278
--- Comment #1 from David Binderman ---
Reduced C++ code is
typedef int mbstate_t;
namespace std {
struct Trans_NS___cxx11_basic_string {
char *c_str();
};
template _Facet use_facet(int);
template struct __codecvt_abstract_base {
typedef _ExternT extern_type;
int length(int, extern_type *, const extern_type *, long);
};
template
struct codecvt : __codecvt_abstract_base<_ExternT> {};
} // namespace std
template struct intrusive_ptr {
intrusive_ptr(T *);
T *operator->();
};
long attach___trans_tmp_3;
struct basic_ostringstreambuf {
struct {
std::Trans_NS___cxx11_basic_string storage;
long max_size;
} m_storage_state;
void attach() {
attach___trans_tmp_3 = 9223372036854775807 / 2;
long size = attach___trans_tmp_3;
m_storage_state.max_size = size;
length_until_boundary(m_storage_state.storage.c_str(),
m_storage_state.max_size);
}
void length_until_boundary(char *s, long max_size) {
int loc;
std::codecvt fac =
std::use_facet>(loc);
mbstate_t mbs(fac.length(mbs, s, s + max_size, 0));
}
};
struct Trans_NS_v2_mt_posix_basic_formatting_ostream {
basic_ostringstreambuf m_streambuf;
void attach(std::Trans_NS___cxx11_basic_string) { m_streambuf.attach(); }
};
template
struct Trans_NS_v2_mt_posix_basic_record_ostream
: Trans_NS_v2_mt_posix_basic_formatting_ostream {
typedef std::Trans_NS___cxx11_basic_string string_type;
void init_stream();
};
struct attribute_value_impl {
attribute_value_impl(std::Trans_NS___cxx11_basic_string);
std::Trans_NS___cxx11_basic_string get();
};
template
void Trans_NS_v2_mt_posix_basic_record_ostream::init_stream() {
typedef attribute_value_impl message_impl_type;
intrusive_ptr p = new message_impl_type(string_type());
attach(p->get());
}
template class Trans_NS_v2_mt_posix_basic_record_ostream;
I will have a go at a git bisect in the morning.
[Bug libstdc++/108236] std::exclusive_scan with execution policy does not work in-place
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108236 --- Comment #2 from Jakub Klinkovský --- I copy-pasted this report in https://github.com/llvm/llvm-project/issues/59810
[Bug modula2/108182] gm2 driver mishandles target and multilib options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182 --- Comment #3 from Gaius Mulley --- I believe I have a fix for the target options. I've built gm2 as a cross compiler for the avr series of microprocessors with the fix and now get a cc1gm2 ICE (after the correct arguments are presented to cc1gm2 :-). Possibly due the separate ID space and scaffold issue? Anyway I'll attach the proposed patches to this PR shortly.
[Bug libgcc/108279] Improved speed for float128 routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279 --- Comment #1 from Thomas Koenig --- Created attachment 54183 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54183=edit Example patch with Michael S's code just pasted over the libgcc implementation, for a test A benchmarks: Just pasting over the code from the github repo yields an improvement of gfortran's matmul by almost a factor of two, so significant speedups are possible: module tick interface function rdtsc() bind(C,name="rdtsc") use iso_c_binding integer(kind=c_long) :: rdtsc end function rdtsc end interface end module tick program main use tick use iso_c_binding implicit none integer, parameter :: wp = selected_real_kind(30) ! integer, parameter :: n=5000, p=4000, m=3666 integer, parameter :: n = 1000, p = 1000, m = 1000 real (kind=wp) :: c(n,p), a(n,m), b(m, p) character(len=80) :: line integer(c_long) :: t1, t2, t3 real (kind=wp) :: fl = 2.d0*n*m*p integer :: i,j print *,wp line = '10 10' call random_number(a) call random_number(b) t1 = rdtsc() t2 = rdtsc() t3 = t2-t1 print *,t3 t1 = rdtsc() c = matmul(a,b) t2 = rdtsc() print *,1/(fl/(t2-t1-t3)),"Cycles per operation" read (unit=line,fmt=*) i,j write (unit=line,fmt=*) c(i,j) end program main showed tkoenig@gcc188:~> ./original 16 32 ^C tkoenig@gcc188:~> time ./original 16 32 90.5696151957 Cycles per operation real 1m2,148s user 1m2,123s sys 0m0,008s tkoenig@gcc188:~> time ./modified 16 32 52.81483917199957 Cycles per operation real 0m36,296s user 0m36,278s sys 0m0,008s where "original" is the current libgcc soft-float implementation, and "modified" is with the code from the repro. It does not handle exceptions, so this causes a few regressions, but certainly shows the potential
[Bug libgcc/108279] New: Improved speed for float128 routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279 Bug ID: 108279 Summary: Improved speed for float128 routines Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- Our soft-float routines, which are used for the basic float128 arithmetic (__addtf3, __subtf3, etc) are much slower than they need to be. Michael S has some routines which are considerably faster, at https://github.com/already5chosen/extfloat, which he would like to contribute to gcc. There is a rather lengthy thread in comp.arch starting with https://groups.google.com/g/comp.arch/c/Izheu-k00Nw . Current status of the discussion: The routines currently do not support rounding modes, they support round to nearest with tie even only. Adding such support would be feasible. Handling the rounding mode it is currently done in libgcc, by querying the hardware, leading to a high overhead for each call. This would not be needed if -ffast-math (or a relevant suboption) is specified. It would also be suitable as is (with a different name) for Fortran intrinsics such as matmul. Fortran is a bit special because rounding modes are default on procedure entry and are restored on procedure exit (which is why setting rounding modes in a subroutine is a no-op). This would allow to keep a local variable keeping track of the rounding mode. The current idea would be something like this: The current behavior of __addtf3 and friends could remain as is, but its speed could be improved,. but it would still query the hardware. There can be two additional routines for each arithmetic operation. One of them would implement the operation given a specified rounding mode (to be called from Fortran when the correct IEEE module is in use). The other one would just implement round-to-nearest, for use from Fortran intrinsics and from all other languages if the right flags are given. It would be good to bolt this onto some flag which is used for libgfortran, to make it accessible from C. Probably gcc14 material.
[Bug modula2/92336] cross compiling gcc fails in gm2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92336 Gaius Mulley changed: What|Removed |Added CC||gaius at gcc dot gnu.org --- Comment #4 from Gaius Mulley --- A heads up, I'm currently examining this in relation to another two bugs. PR-108182 (target multilib options) and PR-108119 (disabling plugin which involves changes to gcc/m2/configure.ac).
[Bug c++/108278] New: runtime error with -O1 -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278 Bug ID: 108278 Summary: runtime error with -O1 -Wall Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 54182 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54182=edit gzipped C++ source code The attached C++ code does this: $ ../results/bin/g++ -c -O1 -Wall bug872.cc ../../trunk.d1/gcc/poly-int.h:753:21: runtime error: signed integer overflow: 4611686018427387903 * 8 cannot be represented in type 'long int' $ The bug first seems to occur sometime between git hash d423e8dc59045d8f, from a couple of days ago and fee53a3194c0d8b7, from today, a distance of 14 commits. I have a reduction running.
[Bug c++/103760] Invalid expression inside lambda inside compound requirement causes an error instead of concept satisfaction failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103760 Patrick Palka changed: What|Removed |Added CC||avr5309 at gmail dot com --- Comment #6 from Patrick Palka --- *** Bug 108254 has been marked as a duplicate of this bug. ***
[Bug c++/108254] Usage of requires expression with an immedietely invoked lambda expression results in compile error instead of evaluating to false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108254 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Patrick Palka --- Thanks for the bug report. I believe this is a dup of PR103760, and GCC is correct to reject the program according to the current wording/intent of the standard. *** This bug has been marked as a duplicate of bug 103760 ***
[Bug c++/104995] access checking for function pointer template parameters takes place at call site inside a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104995 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Summary|access checking for |access checking for |function pointer template |function pointer template |parameters takes place at |parameters takes place at |call site |call site inside a lambda Keywords||c++-lambda Status|UNCONFIRMED |NEW Last reconfirmed||2023-01-03 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug target/108277] arm: error: generic thunk code fails with -march=armv8-m.base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108277 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-01-03 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Base is still thumb1 ... define fgroup ARMv8m_base ARMv6m armv8 cmse tdiv And this is why it is not implemented yet. That is vcall_offset is non-zero and TARGET_THUMB1 is true.
[Bug tree-optimization/107822] [13 Regression] Dead Code Elimination Regression at -Os (trunk vs. 12.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107822 --- Comment #2 from Andrew Macleod --- Sorry, I've been out for a few weeks. This isn't an on-demand issue. All versions of VRP do a full walk and resolve during the walk. This issue is a combination of lack of iteration and not optimistic evaluations on back edges. We do use on-demand to query the back edge to alleviate a number of issues with lack of iteration. The problem is that with a lack of iteration, we can't take the fully optimistic approach and assume that the value of c_10 is [1, 1] for a full iteration of the loop and then determine during the second iteration that it is always either 1 or 2. [local count: 955630225]: _1 = c_10 ^ 3; [local count: 1073741824]: # c_10 = PHI <1(2), _1(3)> b.1_3 = b; if (b.1_3 <= 8) goto ; [89.00%] else goto ; [11.00%] [local count: 118111600]: # c_13 = PHI if (c_13 != 0) When we first try to evaluate # c_10 = PHI <1(2), _1(3)> the back edge 3->4 has not been processed, so it is evaluated and _1 needs to be calculated. Unfortunately the value of c_10 has not been resolved yet, so it defaults to something pessimistically safe and assumes it is varying and we get the results you see. We have a few possible approaches. In an ideal world, we could use the path ranger to answer questions on the back edge instead of fully evaluating it. This would allow us to do a "pretend" first iteration and use the value of [1,1] for c_10, and produce _1 = result of [1,2], which in turn would then cause us to evaluate c_10 as [1,2]. It is too late in the cycle to experiment with that approach I think. I have also (still am) experimented with changing that initial value to be more optimistic. When we first evaluate a statement, We store an initial value so that if it is encountered again during evaluation, we can avoid a cycle. That initial value is what gets used by any calculations along a back edge. When we return from resolving all the inputs, we do a final evaluation of the statement and store the real global value. We have existing infrastructure which uses time stamps that should allow us to calculate one value when doing the back edge, and then recalculate it for real when we actually process that block. I have not convinced myself that this is 100% safe yet. A third option would be to recognize this is a fairly common pattern that we have a 2 input PHI node like this. and before setting the initial value we could walk the use-def chains and see if the PHI is feeding itself and make some other determinations about the range (ie, increasing, decreasing, specific values, etc) and use that for the initial estimate instead. This would give us similar results to what we did before and is likely safer than depending on timestamps to do recalculations. It is just not quite as general. Im experimenting with the latter 2 approaches this week to determine what seems safest at this point in the cycle.
[Bug target/108277] New: arm: error: generic thunk code fails with -march=armv8-m.base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108277 Bug ID: 108277 Summary: arm: error: generic thunk code fails with -march=armv8-m.base Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: acoplan at gcc dot gnu.org Target Milestone: --- The test g++.dg/torture/pr81812.C is rejected with -march=armv8-m.base (but is accepted with e.g. -march=armv8-m.main): $ gcc/xgcc -B gcc -v Reading specs from gcc/specs COLLECT_GCC=gcc/xgcc COLLECT_LTO_WRAPPER=gcc/lto-wrapper Target: arm-eabi Configured with: /home/alecop01/toolchain/src/gcc/configure --prefix=/data_sdb/toolchain/cc1s/arm --enable-languages=c,c++ --disable-bootstrap --target=arm-eabi Thread model: single Supported LTO compression algorithms: zlib gcc version 13.0.0 20230103 (experimental) (GCC) $ gcc/xgcc -B gcc -c ~/toolchain/src/gcc/gcc/testsuite/g++.dg/torture/pr81812.C -march=armv8-m.main $ gcc/xgcc -B gcc -c ~/toolchain/src/gcc/gcc/testsuite/g++.dg/torture/pr81812.C -march=armv8-m.base /home/alecop01/toolchain/src/gcc/gcc/testsuite/g++.dg/torture/pr81812.C:6:8: error: generic thunk code fails for method ‘virtual void ChildNode::_ZTv0_n12_NK9ChildNode5errorEz(...) const’ which uses ‘...’ 6 | void error(... ) const; |^
[Bug other/108276] libiberty unlink_if_ordinary does not handle Windows nul device correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108276 --- Comment #1 from Andrew Pinski --- Patches should be sent to gcc-patches@ after reading https://gcc.gnu.org/contribute.html
[Bug c++/108206] [12/13 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in merge_default_template_args, at cp/decl.cc:1563 since r12-7562-gfe548eb8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108206 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 54181 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54181=edit gcc13-pr108206.patch Untested fix.
[Bug other/108276] New: libiberty unlink_if_ordinary does not handle Windows nul device correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108276 Bug ID: 108276 Summary: libiberty unlink_if_ordinary does not handle Windows nul device correctly Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: himalr at proton dot me Target Milestone: --- Created attachment 54180 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54180=edit Handle Windows nul device correctly in unlink_if_ordinary function I reported this as a part of another bug to [Sourceware Bugzilla](https://sourceware.org/bugzilla/show_bug.cgi?id=29947) and was asked to report this here. In Windows, 'stat' function (and in turn, S_ISREG) returns true for null device as a regular file. Please note that I'm not a C programmer so let me know if there are any issues with the patch. Thanks.
[Bug c++/108275] GCC accepts invalid program using private data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108275
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Known to fail||4.1.2
Last reconfirmed||2023-01-03
--- Comment #1 from Andrew Pinski ---
here is a C++98 testcase:
```
class Base {
int i;
};
template< int Base::* V>
struct Foo {
int a;
};
int main()
{
struct Foo<::i> struct_foo;
}
```
Confirmed, not a regression.
[Bug c++/108275] New: GCC accepts invalid program using private data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108275
Bug ID: 108275
Summary: GCC accepts invalid program using private data member
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jlame646 at gmail dot com
Target Milestone: ---
The following program is accepted by gcc but rejected by clang and msvc.
https://godbolt.org/z/18fbMYTW7
```
class Base {
int i;
};
template
struct Foo {
int a;
};
int main()
{
struct Foo<::i> struct_foo;
}
```
[Bug c++/60512] would be useful if gcc implemented __has_feature similary to clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512 Alex Coplan changed: What|Removed |Added CC||acoplan at gcc dot gnu.org --- Comment #9 from Alex Coplan --- (In reply to Jonathan Wakely from comment #6) > (In reply to Manuel López-Ibáñez from comment #5) > > AFAIU, it will be welcome if someone implements it. > > I see no need to add __has_feature given that it contradicts the > recommendations of the C++ committee, and that GCC already defines the > recommended feature test macros that can be used without __has_feature. I think it's worth noting that __has_feature can be used to check for more than just C++ language features. To quote the clang documentation (https://clang.llvm.org/docs/LanguageExtensions.html): > Another use of __has_feature is to check for compiler features not related to > the language standard, such as e.g. AddressSanitizer. LLVM users can check whether ASan is enabled using __has_feature(address_sanitizer). Similarly one can query e.g. __has_feature(thread_sanitizer). I think it would be good for the alignment between GCC and LLVM if GCC were to implement this extension.
[Bug middle-end/108237] [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 at -O since r13-1085-g90467f0ad649d081
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108237 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 54179 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54179=edit gcc13-pr108237.patch Untested fix.
[Bug middle-end/108237] [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 at -O since r13-1085-g90467f0ad649d081
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108237
--- Comment #4 from Jakub Jelinek ---
Ah, I see, it is forwprop4 which does that:
+Applying pattern match.pd:6223, generic-match.cc:75158
...
- _15 = v.2_7 & { 18446744073709551360, 18446744073709551360 };
- _9 = _15 != { 0, 0 };
+ _9 = v.2_7 > { 255, 255 };
and the reason why it happens can be seen in the Applying line, it isn't GIMPLE
but GENERIC even when it happens so late.
#0 optimize_vectors_before_lowering_p () at ../../gcc/generic-match-head.cc:93
#1 0x019d3302 in generic_simplify_NE_EXPR (loc=2147483658,
code=NE_EXPR, type=, _p0=,
_p1=) at generic-match.cc:75147
#2 0x01a46486 in generic_simplify (loc=2147483658, code=NE_EXPR,
type=, _p0=,
_p1=)
at generic-match.cc:102839
#3 0x0085e140 in fold_binary_loc (loc=2147483658, code=NE_EXPR,
type=, op0=,
op1=)
at ../../gcc/fold-const.cc:10924
#4 0x00f5c7ea in combine_cond_expr_cond (stmt=, code=NE_EXPR, type=,
op0=,
op1=, invariant_only=false) at
../../gcc/tree-ssa-forwprop.cc:387
#5 0x00f5ca80 in forward_propagate_into_comparison_1
(stmt=, code=NE_EXPR, type=,
op0=, op1=) at
../../gcc/tree-ssa-forwprop.cc:446
#6 0x00f5cc71 in forward_propagate_into_comparison
(gsi=0x7fffd740) at ../../gcc/tree-ssa-forwprop.cc:493
#7 0x00f6bfff in (anonymous namespace)::pass_forwprop::execute
(this=0x37a2170, fun=0x7fffea2fd000) at ../../gcc/tree-ssa-forwprop.cc:3753
[Bug middle-end/108237] [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 at -O since r13-1085-g90467f0ad649d081
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108237
--- Comment #3 from Jakub Jelinek ---
I think the actual problem is though:
/* Transform comparisons of the form (X & Y) CMP 0 to X CMP2 Z
where ~Y + 1 == pow2 and Z = ~Y. */
(for cst (VECTOR_CST INTEGER_CST)
(for cmp (eq ne)
icmp (le gt)
(simplify
(cmp (bit_and:c@2 @0 cst@1) integer_zerop)
(with { tree csts = bitmask_inv_cst_vector_p (@1); }
(if (csts && (VECTOR_TYPE_P (TREE_TYPE (@1)) || single_use (@2)))
(with { auto optab = VECTOR_TYPE_P (TREE_TYPE (@1))
? optab_vector : optab_default;
tree utype = unsigned_type_for (TREE_TYPE (@1)); }
(if (target_supports_op_p (utype, icmp, optab)
|| (optimize_vectors_before_lowering_p ()
&& (!target_supports_op_p (type, cmp, optab)
|| !target_supports_op_p (type, BIT_AND_EXPR, optab
(if (TYPE_UNSIGNED (TREE_TYPE (@1)))
(icmp @0 { csts; })
(icmp (view_convert:utype @0) { csts; })
pattern, for V2DImode != or == works, but > does not.
I wonder how it could trigger though because target_supports_op_p (utype, icmp,
optab)
is false.
[Bug target/108274] New: [13 Regression] ICE with in df_refs_verify during arm_reorg pass with -fipa-icf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108274
Bug ID: 108274
Summary: [13 Regression] ICE with in df_refs_verify during
arm_reorg pass with -fipa-icf
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following (reduced from g++.dg/ipa/pr64146.C) fails:
$ gcc/xgcc -B gcc -v
Reading specs from gcc/specs
COLLECT_GCC=gcc/xgcc
COLLECT_LTO_WRAPPER=gcc/lto-wrapper
Target: arm-eabi
Configured with: /home/alecop01/toolchain/src/gcc/configure
--prefix=/data_sdb/toolchain/cc1s/arm --enable-languages=c,c++
--disable-bootstrap --target=arm-eabi
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20230103 (experimental) (GCC)
$ cat t.c
const char *f() { return ""; }
const char *g() { return ""; }
$ gcc/xgcc -B gcc -c t.c -fipa-icf -march=armv8-a -mthumb
during RTL pass: mach
t.c: In function ‘g’:
t.c:2:13: internal compiler error: in df_refs_verify, at df-scan.cc:4009
2 | const char *g() { return ""; }
| ^
0x8d84cf df_refs_verify
/home/alecop01/toolchain/src/gcc/gcc/df-scan.cc:4009
0x8dd84b df_insn_refs_verify
/home/alecop01/toolchain/src/gcc/gcc/df-scan.cc:4088
0x8dddce df_bb_verify
/home/alecop01/toolchain/src/gcc/gcc/df-scan.cc:4125
0x8e1687 df_scan_verify()
/home/alecop01/toolchain/src/gcc/gcc/df-scan.cc:4246
0x8cac74 df_verify()
/home/alecop01/toolchain/src/gcc/gcc/df-core.cc:1818
0x8cac74 df_analyze_1
/home/alecop01/toolchain/src/gcc/gcc/df-core.cc:1214
0x1217a40 thumb2_reorg
/home/alecop01/toolchain/src/gcc/gcc/config/arm/arm.cc:19227
0x1217a40 arm_reorg
/home/alecop01/toolchain/src/gcc/gcc/config/arm/arm.cc:19446
0xd5dc39 execute
/home/alecop01/toolchain/src/gcc/gcc/reorg.cc:3927
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
[Bug middle-end/108237] [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 at -O since r13-1085-g90467f0ad649d081
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108237
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Bet another case of post-veclower folding that turns out something we can
handle into something we can't.
In this case fre5 after veclower21 triggers:
/* Simplify comparison of something with itself. For IEEE
floating-point, we can only do some of these simplifications. */
(for cmp (eq ge le)
(simplify
(cmp @0 @0)
(if (! FLOAT_TYPE_P (TREE_TYPE (@0))
|| ! tree_expr_maybe_nan_p (@0))
{ constant_boolean_node (true, type); }
and
/* (X & Y) == X becomes (X & ~Y) == 0. */
(simplify
(cmp:c (bit_and:c @0 @1) @0)
(cmp (bit_and @0 (bit_not! @1)) { build_zero_cst (TREE_TYPE (@0)); }))
match.pd simplifications:
u.0_3 = u;
_12 = VIEW_CONVERT_EXPR(u.0_3);
_2 = {_12};
- _15 = VIEW_CONVERT_EXPR(u.0_3);
- _16 = _12 == _15;
- _17 = (_Bool) _16;
- _18 = _16 & 1;
- _19 = (signed char) _18;
- _20 = -_19;
- _5 = {_20};
- _13 = VIEW_CONVERT_EXPR(_5);
- _6 = (long long unsigned int) _13;
- _1 = {_6, _6};
v.2_7 = v;
- _8 = _1 & v.2_7;
+ _8 = v.2_7 & { 255, 255 };
_9 = v.2_7 != _8;
_10 = VEC_COND_EXPR <_9, { -1, -1 }, { 0, 0 }>;
w_14 = VIEW_CONVERT_EXPR(_10);
[Bug target/108267] [13 Regression] Bootstrap failure on aarch64-linux since r13-4953
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108267 Florian Weimer changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |fw at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Florian Weimer --- .
[Bug target/108267] [13 Regression] Bootstrap failure on aarch64-linux since r13-4953
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108267 --- Comment #2 from Florian Weimer --- Fixed with the revert in commit 455acc43518744b89d6a795bbba5045bd228060b.
[Bug tree-optimization/105043] Documentation for __builtin_object_size and other Object Size checking builtin functions should mention - D_FORTIFY_SOURCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105043 Siddhesh Poyarekar changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Siddhesh Poyarekar --- The glibc complement of this documentation is here: https://patchwork.sourceware.org/project/glibc/patch/20221222160403.4151387-1-siddh...@sourceware.org/
[Bug tree-optimization/105043] Documentation for __builtin_object_size and other Object Size checking builtin functions should mention - D_FORTIFY_SOURCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105043 --- Comment #9 from CVS Commits --- The master branch has been updated by Siddhesh Poyarekar : https://gcc.gnu.org/g:b3009222b7bb26654c1e93d34e65e8f80ae20595 commit r13-4978-gb3009222b7bb26654c1e93d34e65e8f80ae20595 Author: Siddhesh Poyarekar Date: Thu Dec 15 14:24:55 2022 -0500 tree-optimization/105043: Object Size Checking docs cleanup Break the _FORTIFY_SOURCE-specific builtins out into a separate subsection from Object Size Checking built-ins and mention _FORTIFY_SOURCE in there so that the link between the object size checking builtins, the helper builtins (e.g. __builtin___memcpy_chk) and _FORTIFY_SOURCE is clearer. gcc/ChangeLog: PR tree-optimization/105043 * doc/extend.texi (Object Size Checking): Split out into two subsections and mention _FORTIFY_SOURCE. Signed-off-by: Siddhesh Poyarekar
[Bug tree-optimization/108253] [13 Regression] ICE in set_nonzero_bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108253 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 54178 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54178=edit gcc13-pr108253.patch We actually don't need to punt on pointers but can handle them.
[Bug c++/108269] __PRETTY_FUNCTION__ for NTTP literal initialization containing a char array is assumed to ending in a null character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108269 --- Comment #4 from Camden Mannett --- > So it is just a minor issue dealing with debugging really ... __PRETTY_FUNCTION__ is (mis)used for more than that though; it's often used as an compile-time version of RTTI: https://stackoverflow.com/questions/281818/unmangling-the-result-of-stdtype-infoname/66551751#66551751 There's a whole library based around the concept: https://github.com/Manu343726/ctti
[Bug target/108229] [13 Regression] unprofitable STV transform since r13-4873-g0b2c1369d035e928
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108229 --- Comment #4 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:de59d8bd163a4b2e50ab566441ab49d7212c3356 commit r13-4976-gde59d8bd163a4b2e50ab566441ab49d7212c3356 Author: Roger Sayle Date: Tue Jan 3 13:37:31 2023 + PR target/108229: A minor STV compute_convert_gain tweak on x86. This patch addresses PR target/108229, which is a change in code generation during the STV pass, due to the recently approved patch to handle vec_select (reductions) in the vector unit. The recent change is innocent, but exposes a latent STV "gain" calculation issue that is benign (or closely balanced) on most microarchitectures. The issue is when STV considers converting PLUS with a MEM operand. On TARGET_64BIT (m=1): addq 24(%rdi), %rdx // 4 bytes or with -m32 (m=2) addl24(%esi), %eax // 3 bytes adcl28(%esi), %edx // 3 bytes is being converted by STV to vmovq 24(%rdi), %xmm5 // 5 bytes vpaddq %xmm5, %xmm4, %xmm4 // 4 bytes The current code in general_scalar_chain::compute_convert_gain considers that scalar unit addition is replaced with a vector unit addition (usually about the same cost), but doesn't consider anything special about MEM operands, assuming that a scalar load gains/costs nothing compared to a vector load. We can allow the backend slightly better fine tuning by including in the gain calculation that m scalar loads are being replaced by one vector load, and when optimizing for size including that we're increasing code size (e.g. an extra vmovq instruction for a MEM operand). This patch is a win on the CSiBE benchmark when compiled with -Os. 2023-01-03 Roger Sayle gcc/ChangeLog PR target/108229 * config/i386/i386-features.cc (general_scalar_chain::compute_convert_gain) : Consider the gain/cost of converting a MEM operand.
[Bug tree-optimization/106099] [13 Regression] ICE in execute_todo, at passes.cc:2134 since r13-1204-gd68d366425369649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106099 Jakub Jelinek changed: What|Removed |Added CC||gs...@t-online.de --- Comment #17 from Jakub Jelinek --- *** Bug 106257 has been marked as a duplicate of this bug. ***
[Bug middle-end/106257] [13 Regression] ICE in expand_builtin_unreachable, at builtins.cc:5189 since r13-1204-gd68d366425369649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106257 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- It got actually fixed with r13-2213-g530dc5aaaeb67c223fd0e3986d635408dcea4343 *** This bug has been marked as a duplicate of bug 106099 ***
[Bug middle-end/108264] [11/12 Regression] ICE compiling guacamole-server on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108264 Jakub Jelinek changed: What|Removed |Added Summary|[11/12/13 Regression] ICE |[11/12 Regression] ICE |compiling guacamole-server |compiling guacamole-server |on s390x-linux |on s390x-linux --- Comment #4 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug rtl-optimization/108263] [13 Regression] ICE building Linux kernel on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108263 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug middle-end/108264] [11/12/13 Regression] ICE compiling guacamole-server on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108264 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:226a498733e7919de72eb6f1bf3e16883ad159f6 commit r13-4975-g226a498733e7919de72eb6f1bf3e16883ad159f6 Author: Jakub Jelinek Date: Tue Jan 3 12:13:24 2023 +0100 expr: Fix up store_expr into SUBREG_PROMOTED_* target [PR108264] The following testcase ICEs on s390x-linux (e.g. with -march=z13). The problem is that target is (subreg/s/u:SI (reg/v:DI 66 [ x+-4 ]) 4) and we call convert_move from temp to the SUBREG_REG of that, expecting to extend the value properly. That works nicely if temp has some scalar integer mode (or partial one), but ICEs when temp has V4QImode on the assertion that from and to modes have the same bitsize. store_expr generally allows say store from V4QI to SI target because they have the same size and if temp is a CONST_INT, we already have code to convert the constant properly, so the following patch just adds handling of non-scalar integer modes by converting them to the mode of target first before convert_move extends them. 2023-01-03 Jakub Jelinek PR middle-end/108264 * expr.cc (store_expr): For stores into SUBREG_PROMOTED_* targets from source which doesn't have scalar integral mode first convert it to outer_mode. * gcc.dg/pr108264.c: New test.
[Bug rtl-optimization/108263] [13 Regression] ICE building Linux kernel on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108263 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4fb639a7fee5df32a2d1e7afa40fdf31d280464b commit r13-4974-g4fb639a7fee5df32a2d1e7afa40fdf31d280464b Author: Jakub Jelinek Date: Tue Jan 3 12:12:35 2023 +0100 cfgrtl: Don't try to redirect asm goto to EXIT [PR108263] The following testcase distilled from Linux kernel on ppc64le ICEs, because fixup_reorder_chain sees a bb with a single fallthru edge falling into a bb with simple return and decides to redirect that fallthru edge to EXIT. That is possible if the bb ending in the fallthru edge doesn't end with a jump or ends with a normal unconditional jump, but not when the bb ends with asm goto which can despite a single fallthru have multiple labels to the fallthrough basic block. The following patch makes sure we never try to redirect such cases to EXIT. 2023-01-03 Jakub Jelinek PR rtl-optimization/108263 * cfgrtl.cc (fixup_reorder_chain): Avoid trying to redirect asm goto to EXIT. * gcc.dg/pr108263.c: New test.
[Bug middle-end/108268] [13 Regression] Build failure on cross from powerpc64le-linux to nvptx-none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108268 --- Comment #1 from Jakub Jelinek --- Looking at GCC 12, I think no target actually stored anything into that last element unless it was a return or alternate return column. It is true that expand_builtin_init_dwarf_reg_sizes had: if (!init_state.wrote_return_column) init_return_column_size (mode, mem, DWARF_FRAME_RETURN_COLUMN); #ifdef DWARF_ALT_FRAME_RETURN_COLUMN init_return_column_size (mode, mem, DWARF_ALT_FRAME_RETURN_COLUMN); #endif which is what the new gcc tries to preserve. init_one_dwarf_reg_size had: const unsigned int dnum = DWARF_FRAME_REGNUM (regno); const unsigned int rnum = DWARF2_FRAME_REG_OUT (dnum, 1); const unsigned int dcol = DWARF_REG_TO_UNWIND_COLUMN (rnum); ... if (rnum >= DWARF_FRAME_REGISTERS) return; though, and seems DWARF_REG_TO_UNWIND_COLUMN always uses the default definition of just returning its argument, so I think init_one_dwarf_reg_size would never store to the last element. init_return_column_size can though. And TARGET_INIT_DWARF_REG_SIZES_EXTRA is only defined on msp430 and rs6000 and neither writes at offsets >= DWARF_FRAME_REGISTERS. So, I think the DWARF_FRAME_REGISTERS element should be considered into whether everything is constant/same size only if it is DWARF_FRAME_RETURN_COLUMN or DWARF_ATL_FRAME_RETURN_COLUMN.
[Bug ipa/106816] noreturn/pure attributes are not set correctly on multiversioned functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106816 --- Comment #9 from Martin Jambor --- (In reply to Martin Liška from comment #6) > > @Martin: Do we have a declaration cloning code for functions somewhere? See e.g. cgraph_node::create_virtual_clone in cgraphclones.cc. Unless you want to mess with the parameters, new_decl = copy_node (old_decl); should be enough (and it should copy over the DECL_PURE and TREE_READLONY bit soo, I believe). I am not sure at what point the duplication happens, in order to duplicate also all the various IPA summaries, cgraph machinery has to be involved and call all the summary hooks. So cgraph_node::create_clone should probably be used (or a part of it, or perhaps even one of its users?).
[Bug rtl-optimization/108273] Inconsistent dfa state between debug and non-debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108273 Kewen Lin changed: What|Removed |Added CC||bergner at gcc dot gnu.org, ||segher at gcc dot gnu.org Keywords||compare-debug-failure Target||powerpc*-linux-gnu Target Milestone|--- |13.0
[Bug rtl-optimization/108273] New: Inconsistent dfa state between debug and non-debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108273 Bug ID: 108273 Summary: Inconsistent dfa state between debug and non-debug Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: linkw at gcc dot gnu.org Target Milestone: --- Test case gcc.target/powerpc/pr105586.c fails with -fcompare-debug failure on Power10 (P10 specific) if I applied one patch to fix the current inaccurate power10 tuning setting (which would be pushed soon). By looking into it, I found the dfa state changes even if one basic block have only one debug insn, but the difference on dfa states might not necessarily cause the different choice on ready insns, it heavily depends on the context, different cpu types result in different insns, fusion can reorder some insns first, so this test case is fine on Power8 while not on Power10. On Power10, at non-debug mode, saving state for edge 2->3 // power4iu_automaton_state:8492 // power4misc_automaton_state:3 block 3 meets no_real_insns_p saving state for edge 3->4 // power4iu_automaton_state:8492 // power4misc_automaton_state:3 at debug mode: saving state for edge 2->3 // power4iu_automaton_state:8492 // power4misc_automaton_state:3 block 3 have only one insn which is one debug insn. before advance_one_cycle for block 3: // power4iu_automaton_state:8492 // power4misc_automaton_state:3 after advance_one_cycle for block 3: // power4iu_automaton_state:8501 // power4misc_automaton_state:0 So when starting to schedule for bb 4, they have different states.
[Bug sanitizer/108256] Missing integer overflow instrumentation when assignment LHS is narrow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108256 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Last reconfirmed||2023-01-03 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Jakub Jelinek --- Created attachment 54177 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54177=edit gcc13-pr108256.patch Untested fix.
[Bug target/107248] wrong scheduling of stack adjustment in leaf function at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107248 --- Comment #13 from Eric Botcazou --- > Just to make it clear, since we have had customers asking about it, it is > still possible to trigger this issue with -mtune=leon or -mtune-leon3, > though it might make it less likely to happen. Very likely not, but proving it would be quite hard.
[Bug target/107248] wrong scheduling of stack adjustment in leaf function at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107248 Daniel Cederman changed: What|Removed |Added CC||cederman at gaisler dot com --- Comment #12 from Daniel Cederman --- Just to make it clear, since we have had customers asking about it, it is still possible to trigger this issue with -mtune=leon or -mtune-leon3, though it might make it less likely to happen.
