[Bug fortran/109076] New: class extending abstract type with deferred procedures, with another unrelated procedure interface, crashes on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109076 Bug ID: 109076 Summary: class extending abstract type with deferred procedures, with another unrelated procedure interface, crashes on valid code Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: federico.perini at gmail dot com Target Milestone: --- Hello gfortran/gcc team, I've reduced my issue to the following minimum viable example. Please note I haven't shortened the names because changing them sometimes solves this issue. - The abstract class has deferred procedures, with their abstract interface - The extended type implements them, AND it has another unrelated subroutine that contains a procedure interface - A casual solution is found by either shortening the unrelated subroutine name, or removing some imports from the abstract interface ==> With all gfortran versions from 12.2.0 down to 4.9, I get an "interface mismatch" issue: /app/example.f90:13:15: 13 | procedure :: expand => i_expand | 1 Error: Argument mismatch for the overriding procedure 'expand' at (1): Shape mismatch in argument 'array' The code can be found to play with here: https://godbolt.org/z/GfKGE1cYa And is also here: module my_mod use iso_fortran_env, only: real64 implicit none private type, abstract, public :: parallel_class contains procedure(par_expand_r64), pass(this), deferred :: expand end type parallel_class type, public, extends(parallel_class) :: interpolator contains procedure :: expand => i_expand end type interpolator abstract interface pure subroutine par_expand_r64(this,array) import parallel_class,real64 class(parallel_class), intent(inout) :: this real(real64), intent(in) :: array(:) end subroutine par_expand_r64 pure function interp_fun(ndim,x) result(fun_values) ! ** SOLUTION #1 *** !import real64 ! works with this import real64,interpolator ! this crashes gfortran-12 integer , intent(in) :: ndim real(real64), intent(in) :: x real(real64), dimension(ndim) :: fun_values end function interp_fun end interface contains !** SOLUTION #2 ** !subroutine create_object(this,fun) ! works with this name subroutine interpolator_create_fromfun_fixedstep(this,fun) ! crashes with this name class(interpolator) , intent(inout) :: this procedure(interp_fun) :: fun print *, 'hello world' end subroutine ! Get comm size pure subroutine i_expand(this,array) class(interpolator), intent(inout) :: this real(real64), intent(in) :: array(:) end subroutine i_expand end module my_mod Thank you, Federico
[Bug target/108809] gcc.target/powerpc/builtins-5-p9-runnable.c fails on power 9 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108809 Kewen Lin changed: What|Removed |Added CC||linkw at gcc dot gnu.org Last reconfirmed||2023-03-09 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Kewen Lin --- It's very likely a test issue, may need to adjust some built-in function for endianness issue (as they have different element ordering on BE and LE).
[Bug tree-optimization/109075] [13 Regression] rnflow hangs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075 Thomas Koenig changed: What|Removed |Added Keywords||needs-bisection Target Milestone|--- |13.0 --- Comment #4 from Thomas Koenig --- As also confirmed by Paul Thomas, the program works fine at -O2.
[Bug tree-optimization/109075] [13 Regression] rnflow hangs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075 --- Comment #3 from Thomas Koenig --- Created attachment 54619 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54619&action=edit Compressed input file
[Bug tree-optimization/109075] [13 Regression] rnflow hangs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075 --- Comment #2 from Thomas Koenig --- Created attachment 54618 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54618&action=edit Header file needed for compilation
[Bug tree-optimization/109075] [13 Regression] rnflow hangs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075 --- Comment #1 from Thomas Koenig --- Created attachment 54617 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54617&action=edit rnflow.f90
[Bug tree-optimization/109075] New: [13 Regression] rnflow hangs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075 Bug ID: 109075 Summary: [13 Regression] rnflow hangs at -O3 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- rnflow from the pb11 Polyhedron benchmark hangs at -O3 with recent trunk, gcc-Version 13.0.1 20230308 (experimental) [master revision e87559d202d:f4e6da6e8ac:36ec54aac7da134441c83248e14825381b8d6f17] (GCC) Compiling with -O3 -g, running under gdb and interrupting the program sometime after (gdb) r rnflow.in Starting program: /tmp/a.out rnflow.in 0: 0: 0.000 -> Read sequence 0: 0: 0.213 -> extract extrema 0: 0: 0.215 -> Generate raw transitions counts 0: 0: 0.221 -> Compute Markov matrix 0: 0: 0.221 -> Calculate theoretical rainflow 0: 0: 7.487 -> Simulate random markov sequences ^C Program received signal SIGINT, Interrupt. 0x00402149 in minlst (ipos2=, ipos1=) at rnflow.f90:3698 3698 if (xxtrt (ipos) < xxtrt (minlst)) then (gdb) l 3693! 3694! .. dernier minimum de xxtrt entre ipos1 et ipos2 3695! 3696 minlst = ipos2 3697 do ipos = ipos2 - 1, ipos1, -1 3698 if (xxtrt (ipos) < xxtrt (minlst)) then 3699minlst = ipos 3700 endif 3701 enddo 3702 end function minlst where it goes into an endless loop. This happens both on x86_64 and on POWER.
[Bug c++/109074] New: SIGABRT signal without using -lpthread at Linux RHEL 7.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109074
Bug ID: 109074
Summary: SIGABRT signal without using -lpthread at Linux RHEL
7.3
Product: gcc
Version: 4.8.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: murugesandins at gmail dot com
Target Milestone: ---
Hi G++ bugzilla,
$ /usr/bin/g++ --version
g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ /usr/bin/cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.3 (Maipo)
I don't have root access and sudo access.
I tried following sample thread.cpp program:
[code]
/*
* Creating thread using "class thread" at C++
* Sample C++ program using the "class thread".
* Once an object is created, it used to create a thread.
* When creating object, we need to pass the name of the function as parameter
to that object.
* Once creating the object, that function used to be called by the thread.
* I will write mutex comments later.
* Example:
* thread t1(ThreadMethod);
* Here t1 is creating the new thread.
* I have not tested following code at other operating
systems(UNIX/AIX/SunOS/HP-UX/...) excluding Linux, CYGWIN_NT and MINGW
*/
#include
#if defined(LINUX)
#include // syscall(SYS_gettid)
#ifdef SYS_gettid
#define gettid() ((pid_t)syscall(SYS_gettid))
#endif
#elif defined(CYGWIN_NT) || defined (MINGW)
#define gettid() (unsigned long)pthread_self()
#endif
#include
#include
#include
using namespace std;
int TotalThreadCount = 0;
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
void ThreadMethod()
{
while(true)
{
if( 2 <= TotalThreadCount )
{
break;
}
pthread_mutex_lock(&mutex);
string DispTID = "";
DispTID = string("TotalThreadCount :") +
to_string(TotalThreadCount) + " TID: " + to_string(gettid()) + "\n";
cout << DispTID;
cout.flush();
sleep(1);
++TotalThreadCount;
pthread_mutex_unlock(&mutex);
}
}
int main()
{
// class thread available from C++11
// initialize the object using related thread function.
thread t1(ThreadMethod);
thread t2(ThreadMethod);
t1.join();
t2.join();
// cout << "mutex.__data: " << (unsigned long long)&mutex.__data <<
"\n";
return 0;
}
/*
pthread_mutex_t is a union having one struct one char array[40] and one long.
union pthread_mutex_t
{
pthread_mutex_t::__pthread_mutex_s == double linked list
{
int __lock; == 04 bytes
unsigned int __count; == 04 bytes
int __owner;== 04 bytes
unsigned int __nusers; == 04 bytes
int __kind; == 04 bytes
int __spins;== 04 bytes
__pthread_list_t __list;== 16 bytes
{
*prev;
*next;
}
} __data; == 40 bytes
char __size[40];== 40 bytes
long __align; == 08 bytes
} == 40 bytes since this is union
taking maximum bytes.
Hence size of this union is 40 bytes.
*/
[/code]
$ /usr/bin/g++ -DLINUX -g -Wall thread.cpp -o ./a.out -std=c++11
$ ./a.out
terminate called after throwing an instance of 'std::system_error'
what(): Enable multithreading to use std::thread: Operation not permitted
Aborted (core dumped)
$ gdb a.out core.27255
Reading symbols from ./a.out...done.
[New LWP 27255]
Core was generated by `./a.out'.
Program terminated with signal 6, Aborted.
#0 0x7f1125cdd1d7 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.17-157.el7.x86_64
libgcc-4.8.5-11.el7.x86_64 libstdc++-4.8.5-11.el7.x86_64
(gdb) #0 0x7f1125cdd1d7 in raise () from /lib64/libc.so.6
#1 0x7f1125cde8c8 in abort () from /lib64/libc.so.6
#2 0x7f11265e1ab5 in __gnu_cxx::__verbose_terminate_handler() () from
/lib64/libstdc++.so.6
#3 0x7f11265dfa26 in ?? () from /lib64/libstdc++.so.6
#4 0x7f11265dfa53 in std::terminate() () from /lib64/libstdc++.so.6
#5 0x7f11265dfc73 in __cxa_throw () from /lib64/libstdc++.so.6
#6 0x7f11266364b9 in
std::thread::_M_start_thread(std::shared_ptr) ()
from /lib64/libstdc++.so.6
#7 0x004020d2 in std::thread::
[Bug rtl-optimization/108707] suboptimal allocation with same memory op for many different instructions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108707 --- Comment #6 from Hongtao.liu --- 3 patches pending for GCC14.
[Bug rtl-optimization/108707] suboptimal allocation with same memory op for many different instructions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108707 --- Comment #5 from Hongtao.liu --- Created attachment 54616 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54616&action=edit 0003.patch
[Bug rtl-optimization/108707] suboptimal allocation with same memory op for many different instructions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108707 --- Comment #4 from Hongtao.liu --- Created attachment 54615 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54615&action=edit 0002.patch
[Bug rtl-optimization/108707] suboptimal allocation with same memory op for many different instructions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108707 --- Comment #3 from Hongtao.liu --- Created attachment 54614 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54614&action=edit 0001.patch
[Bug target/108804] missed vectorization in presence of conversion from uint64_t to float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108804 --- Comment #4 from Hongtao.liu --- Created attachment 54613 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54613&action=edit Patch pending for GCC14
[Bug target/108938] Missing bswap detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108938 --- Comment #15 from Hongtao.liu --- Created attachment 54612 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54612&action=edit Patch pending for GCC14
[Bug target/94908] Failure to optimally optimize certain shuffle patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94908 --- Comment #8 from Hongtao.liu --- (In reply to Uroš Bizjak from comment #7) > Created attachment 54607 [details] > Proposed patch > > Patch in testing. > > Attached patch produces (-O2 -msse4.1): > > f: > subq$24, %rsp > xorl%eax, %eax > vmovaps %xmm0, (%rsp) > callg > vmovaps (%rsp), %xmm1 > addq$24, %rsp > vinsertps $64, %xmm0, %xmm1, %xmm0 > ret I'm thinking of something like below so it can be matched both by expand_vselect_vconcat in ix86_expand_vec_perm_const_1 and patterns created by pass_combine(theoretically). +(define_insn_and_split "*sse4_1_insertps_1" + [(set (match_operand:VI4F_128 0 "register_operand") + (vec_select:VI4F_128 + (vec_concat: + (match_operand:VI4F_128 1 "register_operand") + (match_operand:VI4F_128 2 "register_operand")) + (match_parallel 3 "insertps_parallel" + [(match_operand 4 "const_int_operand")])))] + "TARGET_SSE4_1 && ix86_pre_reload_split ()" + "#" + "&& 1"
[Bug target/108938] Missing bswap detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108938
--- Comment #14 from Hongtao.liu ---
Got 1 performance opportunity in GCC itself with bswap + bit_and + rotate, the
Intermediate value are all single-use which can be DCEd.
Got 4 performance opportunity in SPEC2017.
bswap + bit_and + rotate + single_use: 1
bswap + rotate + single_use: 1
bswap + rotate + not single_use: 2.
For 2 not single use, the tectase is like
foo1 (char* a, unsigned int* __restrict b)
{
a[0] = b[0] >> 24;
a[1] = b[0] >> 16;
a[2] = b[0] >> 8;
a[3] = b[0];
a[4] = b[1] >> 24;
a[5] = b[1] >> 16;
a[6] = b[1] >> 8;
a[7] = b[1];
}
b[0] is used by multi stmt for shift, but no other places, so it actually can
be DECd. So for GCC itself and SPEC2017 with -O2, bswap + bit_and + rotate
optimization won't cause extra stmts.
[Bug libgomp/109062] [13 regression] Default value of GOMP_SPINCOUNT changes since r13-2545
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109062 Hongyu Wang changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Hongyu Wang --- Fixed on trunk so far.
[Bug libgomp/109062] [13 regression] Default value of GOMP_SPINCOUNT changes since r13-2545
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109062 --- Comment #1 from CVS Commits --- The master branch has been updated by Hongyu Wang : https://gcc.gnu.org/g:288bc7b5d17511d1791899e4b2e3bf3489eb06dd commit r13-6548-g288bc7b5d17511d1791899e4b2e3bf3489eb06dd Author: Hongyu Wang Date: Wed Mar 8 11:29:46 2023 +0800 libgomp: Fix default value of GOMP_SPINCOUNT [PR 109062] When OMP_WAIT_POLICY is not specified, current implementation will cause icv flag GOMP_ICV_WAIT_POLICY unset, so global variable wait_policy will remain its uninitialized value. Initialize it to -1 to make GOMP_SPINCOUNT behavior consistent with its description. libgomp/ChangeLog: PR libgomp/109062 * env.c (wait_policy): Initialize to -1. (initialize_icvs): Initialize icvs->wait_policy to -1. * testsuite/libgomp.c-c++-common/pr109062.c: New test.
[Bug c++/107280] [10/11/12/13 Regression] ICE: tree check: expected constructor, have view_convert_expr in cxx_eval_store_expression, at cp/constexpr.cc:5928
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107280 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug c++/107280] [10/11/12/13 Regression] ICE: tree check: expected constructor, have view_convert_expr in cxx_eval_store_expression, at cp/constexpr.cc:5928
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107280
--- Comment #4 from Marek Polacek ---
We crash in cxx_eval_store_expression. *valp for 'str', the VAR_DECL, used to
be {.str=""} so in the !refs->is_empty () loop we'd go to the if (TREE_CODE
(*valp) == STRING_CST) branch when processing the .str initializer. But now
*valp is {.str=VCE("")} so we crash on
no_zero_init = CONSTRUCTOR_NO_CLEARING (*valp);
So far it seems to me that we just need to strip the location wrapper.
[Bug target/109073] __builtin_vsx_lxvp() doesn't allow a const __vector_pair * operand in GCC 11 & 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109073 Peter Bergner changed: What|Removed |Added CC||chip.kerchner at ibm dot com, ||segher at gcc dot gnu.org Last reconfirmed||2023-03-08 Status|UNCONFIRMED |ASSIGNED Keywords||rejects-valid Target Milestone|--- |11.4 Known to fail||10.0, 11.0 Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org Target||powerpc*-*-* Known to work||12.0, 13.0 Ever confirmed|0 |1
[Bug target/109073] New: __builtin_vsx_lxvp() doesn't allow a const __vector_pair * operand in GCC 11 & 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109073
Bug ID: 109073
Summary: __builtin_vsx_lxvp() doesn't allow a const
__vector_pair * operand in GCC 11 & 10
Product: gcc
Version: 11.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
On GCC 11 and GCC 10, we error on the following test case which GCC 12 and
trunk accept with no errors:
bergner@ltcden2$ cat t.cc
void
foo (void *dst, const __vector_pair *src)
{
__vector_pair pair = __builtin_vsx_lxvp(0L, src);
__builtin_vsx_disassemble_pair(dst, &pair);
}
bergner@ltcden2$ g++ -S -O2 -mcpu=power10 t.cc
t.cc: In function ‘void foo(void*, const __vector_pair*)’:
t.cc:4:47: error: invalid conversion from ‘const __vector_pair*’ to
‘__vector_pair*’ [-fpermissive]
4 | __vector_pair pair = __builtin_vsx_lxvp(0L, src);
| ^~~
| |
| const __vector_pair*
: note: initializing argument 2 of ‘__vector_pair
__builtin_vsx_lxvp(sizetype, __vector_pair*)’
This was "fixed" in GCC 12 with Bill's rs6000 built-in rewrite, which we don't
want to backport. I have a smaller fix which can be backported that I am
testing. The same problem affects the __builtin_vsx_stxvp() and
__builtin_vsx_disassemble_pair() and __builtin_mma_disassemble_acc() builtins.
[Bug target/109072] New: [12/13 Regression] SLP costs for vec duplicate too high since g:4963079769c99c4073adfd799885410ad484cbbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109072
Bug ID: 109072
Summary: [12/13 Regression] SLP costs for vec duplicate too
high since g:4963079769c99c4073adfd799885410ad484cbbe
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
CC: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*
The following example
---
#include
float32x4_t f (float32x4_t v, float res)
{
float data[4];
data[0] = res;
data[1] = res;
data[2] = res;
data[3] = res;
return vld1q_f32 (&data[0]);
}
---
compiled with -Ofast fails to SLP starting with GCC 12.
This used to generate:
f:
dup v0.4s, v1.s[0]
ret
and now generates:
f:
fmovw5, s1
fmovw1, s1
fmovw4, s1
fmovw0, s1
mov x2, 0
mov x3, 0
bfi x2, x5, 0, 32
bfi x3, x1, 0, 32
bfi x2, x4, 32, 32
bfi x3, x0, 32, 32
fmovd0, x2
ins v0.d[1], x3
ret
The SLP costs went from:
Vector cost: 2
Scalar cost: 4
to:
Vector cost: 12
Scalar cost: 4
it looks like it's no longer costing it as a duplicate but instead 4 vec
inserts.
bisected to:
commit g:4963079769c99c4073adfd799885410ad484cbbe
Author: Richard Sandiford
Date: Tue Feb 15 18:09:33 2022 +
vect+aarch64: Fix ldp_stp_* regressions
ldp_stp_1.c, ldp_stp_4.c and ldp_stp_5.c have been failing since
vectorisation was enabled at -O2. In all three cases SLP is
generating vector code when scalar code would be better.
[Bug target/108927] error: too few arguments to function 'long unsigned int __riscv_vsetvlmax_e8mf8(void)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108927 --- Comment #3 from JuzheZhong --- This issue should be fixed since patch is merged.
[Bug analyzer/109058] RFE: analyzer should elide repeated calls to strcmp in execution paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109058 --- Comment #2 from David Malcolm --- (In reply to David Malcolm from comment #0) > Seen on a diagnostic in haproxy's cfgparse-global.c: cfg_parse_global For reference, see cfg_parse_global in: http://git.haproxy.org/?p=haproxy.git;a=blob;f=src/cfgparse-global.c which has a long sequence of strcmp against each of various string literals.
[Bug c++/107280] [10/11/12/13 Regression] ICE: tree check: expected constructor, have view_convert_expr in cxx_eval_store_expression, at cp/constexpr.cc:5928
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107280
Marek Polacek changed:
What|Removed |Added
Summary|ICE: tree check: expected |[10/11/12/13 Regression]
|constructor, have |ICE: tree check: expected
|view_convert_expr in|constructor, have
|cxx_eval_store_expression, |view_convert_expr in
|at cp/constexpr.cc:5928 |cxx_eval_store_expression,
||at cp/constexpr.cc:5928
Target Milestone|13.0|10.5
Priority|P3 |P2
--- Comment #3 from Marek Polacek ---
This isn't about consteval. Adjusted C++17 test:
// PR c++/107280
struct string {
char str[8] = "";
};
template constexpr void
test ()
{
string str{};
auto append = [&](const char *s) { *str.str = *s; };
append("");
}
static_assert ((test(), true), "");
Started with r10-3661-g8e007055dd1374, making this a regression.
commit 8e007055dd1374ca4c44406a4ead172be0dfa3a8
Author: Jakub Jelinek
Date: Sat Oct 5 09:38:21 2019 +0200
PR c++/91369 - Implement P0784R7: constexpr new
[Bug fortran/104332] [10/11/12/13 Regression] ICE in resolve_symbol, at fortran/resolve.cc:15815
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104332
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #7 from anlauf at gcc dot gnu.org ---
This adjustment of the logic also fixes the ICE and the accepts-invalid:
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 2780c82c798..c7f42dd2a4d 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -15933,8 +15942,8 @@ resolve_symbol (gfc_symbol *sym)
/* First, make sure the variable is declared at the
module-level scope (J3/04-007, Section 15.3). */
- if (sym->ns->proc_name->attr.flavor != FL_MODULE &&
- sym->attr.in_common == 0)
+ if (!(sym->ns->proc_name && sym->ns->proc_name->attr.flavor ==
FL_MODULE)
+ && sym->attr.in_common == 0)
{
gfc_error ("Variable %qs at %L cannot be BIND(C) because it "
"is neither a COMMON block nor declared at the "
[Bug target/109069] Vector truncation test program produces incorrect result on big-endian powerpc64-linux-gnu with -mcpu=power10 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109069 --- Comment #1 from John Platts --- The C++ test program below does generate the correct results when compiled with the -mcpu=power10 -O0 options.
[Bug tree-optimization/109071] -Warray-bounds warning when array index checked via inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109071 --- Comment #1 from Andrew Pinski --- Jump threading is happening which is causing some code to be duplicated. I am 100% sure there is a dup of this bug already filed too.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 68092, which changed state. Bug 68092 Summary: [C++1z] error: Two symbols with same comdat_group are not linked by the same_comdat_group list. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68092 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/68608] [concepts] ICE with explicit class instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68608 Andrew Pinski changed: What|Removed |Added CC||chrisb2244 at gmail dot com --- Comment #5 from Andrew Pinski --- *** Bug 68092 has been marked as a duplicate of this bug. ***
[Bug c++/68092] [C++1z] error: Two symbols with same comdat_group are not linked by the same_comdat_group list.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68092 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #8 from Andrew Pinski --- Even though 68608 is slightly newer, there is more analysis of what is going wrong, marking this as a dup of bug 68608. *** This bug has been marked as a duplicate of bug 68608 ***
[Bug c++/68608] [concepts] ICE with explicit class instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68608 Andrew Pinski changed: What|Removed |Added CC||ed at catmur dot uk --- Comment #4 from Andrew Pinski --- *** Bug 109070 has been marked as a duplicate of this bug. ***
[Bug c++/109070] ICE in class template member function overloads distinguished by non-functionally-equivalent constraints and return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109070 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 68608. *** This bug has been marked as a duplicate of bug 68608 ***
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 104615, which changed state. Bug 104615 Summary: [Concepts] ICE in explicit instantiation when multiple candidates are valid (CWG2421) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104615 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/68608] [concepts] ICE with explicit class instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68608 Andrew Pinski changed: What|Removed |Added CC||roi.jacobson1 at gmail dot com --- Comment #3 from Andrew Pinski --- *** Bug 104615 has been marked as a duplicate of this bug. ***
[Bug c++/104615] [Concepts] ICE in explicit instantiation when multiple candidates are valid (CWG2421)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104615 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 68608. *** This bug has been marked as a duplicate of bug 68608 ***
[Bug c/109071] New: -Warray-bounds warning when array index checked via inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109071
Bug ID: 109071
Summary: -Warray-bounds warning when array index checked via
inline
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
Created attachment 54611
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54611&action=edit
PoC for -Warray-bounds false positive
The Linux kernel is seeing -Warray-bounds warnings when array indexes are being
checked via inlines. This appears to be in the overly noisy/false positive
territory, but I don't actually know what's going on.
The upstream report is here:
https://lore.kernel.org/lkml/20230306220947.1982272-1-t...@redhat.com/
Originally I thought this was another -fsanitizer=shift issue, but after
reducing the test-case, it seems to be related to inlining or some other aspect
of optimization passes.
If the "assign" function is open-coded in the caller, the warning goes away.
If the index checks are moved before the "assign" calls, the warning goes away.
If there is only 1 call to "assign", the warning goes away.
Fundamentally there should be no warning at all since the value of "index" is
entirely unknown _except_ when it makes the call to "warn".
$ cat test.c
extern void warn(void);
#define MAX_ENTRIES 4
static inline void assign(int val, int *regs, int index)
{
if (index >= MAX_ENTRIES)
warn();
*regs = val;
}
struct nums {
int vals[MAX_ENTRIES];
};
void sparx5_psfp_sg_set(int *ptr, struct nums *sg, int index)
{
int *val;
val = &sg->vals[index];
assign(0,ptr, index);
assign(*val, ptr, index);
}
$ gcc -Wall -O2 -c -o test.o test.c
test.c: In function 'sparx5_psfp_sg_set':
test.c:20:24: warning: array subscript 4 is above array bounds of 'int[4]'
[-Warray-bounds=]
20 | val = &sg->vals[index];
|^~~
test.c:13:13: note: while referencing 'vals'
13 | int vals[MAX_ENTRIES];
| ^~~~
[Bug target/109069] New: Vector truncation test program produces incorrect result on big-endian powerpc64-linux-gnu with -mcpu=power10 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109069
Bug ID: 109069
Summary: Vector truncation test program produces incorrect
result on big-endian powerpc64-linux-gnu with
-mcpu=power10 -O2
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: john_platts at hotmail dot com
Target Milestone: ---
The following C++ test program generates a test failure when compiled for
big-endian powerpc64-linux-gnu with GCC 12.2.1 with the -mcpu=power10 -O2
options:
#pragma push_macro("vector")
#pragma push_macro("pixel")
#pragma push_macro("bool")
#undef vector
#undef pixel
#undef bool
#include
#pragma pop_macro("vector")
#pragma pop_macro("pixel")
#pragma pop_macro("bool")
#include
#include
#include
#include
#include
#include
template
struct AltivecTypes {
};
template<>
struct AltivecTypes<1> {
using UnsignedLaneT = unsigned char;
using SignedLaneT = signed char;
using UnsignedVectT = __vector unsigned char;
using SignedVectT = __vector signed char;
using BoolVectT = __vector __bool char;
};
template<>
struct AltivecTypes<2> {
using UnsignedLaneT = unsigned short;
using SignedLaneT = signed short;
using UnsignedVectT = __vector unsigned short;
using SignedVectT = __vector signed short;
using BoolVectT = __vector __bool short;
};
template<>
struct AltivecTypes<4> {
using UnsignedLaneT = unsigned int;
using SignedLaneT = signed int;
using FloatLaneT = float;
using UnsignedVectT = __vector unsigned int;
using SignedVectT = __vector signed int;
using BoolVectT = __vector __bool int;
using FloatVectT = __vector float;
};
template<>
struct AltivecTypes<8> {
using UnsignedLaneT = unsigned long long;
using SignedLaneT = signed long long;
using FloatLaneT = double;
using UnsignedVectT = __vector unsigned long long;
using SignedVectT = __vector signed long long;
using BoolVectT = __vector __bool long long;
using FloatVectT = __vector double;
};
template, bool = std::is_integral_v,
bool = std::is_floating_point_v, class = void>
struct MakeAltivecVectorType {
};
template
struct MakeAltivecVectorType::SignedVectT>> {
using type = typename AltivecTypes::SignedVectT;
};
template
struct MakeAltivecVectorType::UnsignedVectT>> {
using type = typename AltivecTypes::UnsignedVectT;
};
template
struct MakeAltivecVectorType::FloatVectT>> {
using type = typename AltivecTypes::FloatVectT;
};
template
using AltivecVectorType = typename MakeAltivecVectorType::type;
template* = nullptr>
AltivecVectorType LoadVector(const T* __restrict__ src) {
using Bits = typename AltivecTypes<(sizeof(T) * N)>::UnsignedLaneT;
Bits bits;
__builtin_memcpy(&bits, src, sizeof(T) * N);
return reinterpret_cast>(vec_splats(bits));
}
template* = nullptr>
AltivecVectorType LoadVector(const T* __restrict__ src) {
using LaneT =
std::decay_t>()[0])>;
typedef LaneT LoadRawT
__attribute__((__vector_size__(16), __aligned__(16), __may_alias__));
const LoadRawT* __restrict__ p = reinterpret_cast(src);
return reinterpret_cast>(*p);
}
template* = nullptr>
void StoreVector(T* __restrict__ dest, AltivecVectorType vect) {
using Bits = typename AltivecTypes<(sizeof(T) * N)>::UnsignedLaneT;
typedef Bits BitsVectT __attribute__((__vector_size__(16)));
const Bits bits = reinterpret_cast(vect)[0];
__builtin_memcpy(dest, &bits, sizeof(T) * N);
}
template* = nullptr>
void StoreVector(T* __restrict__ dest, AltivecVectorType vect) {
using LaneT =
std::decay_t>()[0])>;
typedef LaneT StoreRawT
__attribute__((__vector_size__(16), __aligned__(16), __may_alias__));
StoreRawT* __restrict__ p = reinterpret_cast(dest);
*p = reinterpret_cast(vect);
}
template
AltivecVectorType AltivecTruncateToU8(FromV vect) {
static_assert(N >= 1, "N >= 1 must be true");
using FromLaneT = std::decay_t()[0])>;
constexpr size_t sizeOfFromLane = sizeof(FromLaneT);
static_assert(sizeOfFromLane >= 2, "sizeOfFromLane >= 2 must be true");
if constexpr(N == 1) {
#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
return reinterpret_cast<__vector unsigned char>(vect);
#else
return reinterpret_cast<__vector unsigned char>(
vec_sld(vect, vect, sizeof(FromLaneT) - sizeof(unsigned char)));
#endif
} else {
if constexpr(sizeOfFromLane >= 4) {
return AltivecTruncateToU8(vec_pack(vect, vect));
} else {
const __vector unsigned short u16Vect =
reinterpret_cast<__vector unsigned short>(vect);
return vec_pack(u16Vect, u16Vect);
}
}
}
static int TestsFailedCount = 0;
template
static constexpr decltype(auto) CharToNumber(T&& val) {
using DecayT = std::decay_t;
if constexpr(std::is_same_v) {
if constexpr(std::is_signed_v)
return static_cast(val);
else
return
[Bug c++/109070] New: ICE in class template member function overloads distinguished by non-functionally-equivalent constraints and return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109070
Bug ID: 109070
Summary: ICE in class template member function overloads
distinguished by non-functionally-equivalent
constraints and return type
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ed at catmur dot uk
Target Milestone: ---
template concept C = true;
template struct A {
int f() requires C<42> { return 1; } // #1
unsigned f() requires true { return 2u; } // #2
};
int main() {
int (A::*p)() = &A::f;
unsigned (A::*q)() = &A::f;
return (A().*p)() + (A().*q)();
}
:10:1: error: Two symbols with same comdat_group are not linked by the
same_comdat_group list.
10 | }
| ^
_ZN1AIiE1fEv/2 (unsigned int A::f() requires true [with T = int])
Type: function definition analyzed
Visibility: semantic_interposition public weak comdat
comdat_group:_ZN1AIiE1fEv one_only
previous sharing asm name: 1
Address is taken.
References:
Referring: main/0 (addr)
Function flags: body
Called by:
Calls:
_ZN1AIiE1fEv/1 (int A::f() requires C<42> [with T = int])
Type: function definition analyzed
Visibility: semantic_interposition public weak comdat
comdat_group:_ZN1AIiE1fEv one_only
next sharing asm name: 2
Address is taken.
References:
Referring: main/0 (addr)
Function flags: body
Called by:
Calls:
:10:1: internal compiler error: symtab_node::verify failed
0x247b73e internal_error(char const*, ...)
???:0
0xed5c22 symtab_node::verify_symtab_nodes()
???:0
0xef042b symbol_table::finalize_compilation_unit()
???:0
This is valid per [temp.over.link]/5, but that seems impossible to implement -
I've filed https://github.com/cplusplus/CWG/issues/256.
[Bug c++/79682] [concepts] ambiguous overload with functionally equivalent predicate constraints compiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79682 Ed Catmur changed: What|Removed |Added CC||ed at catmur dot uk --- Comment #2 from Ed Catmur --- I think this was made IFNDR by CWG2603?
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #33 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #32)
> > > > struct foo {
> > > > int len;
> > > > char (*buf)[.len];
> > > > };
> Here the last element is not a flexible array member but
> a pointer to an array of size len. The size of the pointer is
> fixed.
Oh, that's right.
then, just curious on how did you embed the '.len' information into IR?
[Bug fortran/108957] Fortran FE memleak with interfaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108957 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||memory-hog --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to Mikael Morin from comment #1) > This seems to do the trick for this testcase: [...] > I can't fully test it right now. Regtests cleanly on x86_64-pc-linux-gnu here, and passes further tests. And yes, the memleak is gone for the example.
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #32 from Martin Uecker ---
Am Mittwoch, dem 08.03.2023 um 19:20 + schrieb qinzhao at gcc dot gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
>
> --- Comment #30 from qinzhao at gcc dot gnu.org ---
> (In reply to Martin Uecker from comment #28)
>
> > The problems with VLA are in my opinion caused by poor
> > implementation (e.g. no stack probing etc) and bad
> > code generation (Linus was not happy about this) and
> > not because anything is fundamentally bad about them
> > from the point of language semantics.
>
> you mean gcc's implementation? how about other compilers?
I mostly mean compilers without stack probing (which GCC
has but is not activated by default). Code quality is
probably still bad for most compilers.
>
> > VM = variably modified. In C it is a type which is derived from
> > a VLA which is not necessarily itself a VLA, e.g. a pointer to
> > a VLA. But a VLA is also a VM type.
>
> Okay.
> >
> > > struct foo {
> > > int len;
> > > char (*buf)[.len];
> > > };
> > >
> > >
> > > This has less issues because the size of the struct then does not depend
> > > on the length.
>
> but I am still not clear on why "the size of the above struct 'foo' does not
> depend on the .len?" in my opinion, it should depend on .len. do I miss
> anything here?
Here the last element is not a flexible array member but
a pointer to an array of size len. The size of the pointer is
fixed.
Martin
>
[Bug tree-optimization/109008] [13 Regression] Wrong code in scipy package since r13-3926-gd4c2f1d376da6f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008 --- Comment #38 from Jakub Jelinek --- I've also repeated the testing with the above generator generated testcase with " - " replaced with " / " and " + " with " * ", with #c32 + #c33 patches this resulted in 1 15 50 1 17 50 1 18 50 1 23 50 1 29 50 1 32 50 1 50 14 1 50 18 1 50 33 1 50 35 2 11 50 2 13 50 2 50 12 2 50 8 2 7 50 3 50 10 3 9 50 4 50 6 4 50 9 4 6 50 5 10 50 5 8 50 6 50 7 9 5 50 10 4 50 10 50 4 12 50 5 28 3 50 45 50 3 171 50 2 194 2 50 366 1 50 411 50 1 8744 50 50 33627 2 2 45607 1 2 52776 1 1 70436 2 1 85436 -1 -1 so again, seems at least for the 297936 tests with finite ranges it is conservatively correct and while it still has various 50+ulps cases, in most cases it is within an ulp or two from the minimal range. If we find some important issue where it is too conservative, we can deal with it incrementally.
[Bug fortran/108925] memory leak of gfc_get_namespace result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108925 --- Comment #7 from anlauf at gcc dot gnu.org --- (In reply to Mikael Morin from comment #6) > Created attachment 54598 [details] > Tentative patch > This seems to work on the reduced testcases, can't fully test right now. I tried it and killed regtesting really rather early ... So it might be better to wait for stage1 before pursuing this further.
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #31 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #29)
> > however, I think that both the new attribute and the new C syntax extension
> > should support the similar user interface. We might need to decide on this
> > first.
>
> I think there are some fundamental differences: In one
> case the size is encoded into the type and in the other
> it is just an annotation that can be ignored.
Yes, understood.
I might not make myself clear in the previous message. what I mean by the "the
similar user interfaces" is:
both might support the following:
1. a declared variable as the size:
**C syntax extension:
unsigned int length;
struct object {
int others;
char flex[length];
}
**corresponding attribute:
unsigned int length;
struct object {
int others;
char flex[] __attribute__((__element_count__(length)));
}
2. a declared field of the same structure as the size:
**C syntax extension:
struct object {
unsigned int length;
char flex[.length];
}
**corresponding attribute:
struct object {
unsigned int length;
char flex[] __attribute__((__element_count__(.length)));
}
3. expressions including declared variables and declared fields of the same
structure as the size:
**C syntax extension:
unsigned int item;
struct object {
unsigned int ratio;
char flex[item * .ratio];
}
**corresponding attribute:
unsigned int item;
struct object {
unsigned int ratio;
char flex[] __attribute__((__element_count__(item * .ratio)));
}
Not sure on the following case:
4. a declared field of the containing structure as the size:
**C syntax extension:
struct object {
unsigned int length;
struct inner {
...
int flex[..length];
};
}
**corresponding attribute:
struct object {
unsigned int length;
struct inner {
...
char flex[] __attribute__((__element_count__(..length)));
}
}
what else from the user's point of view?
>
> >
> > right now, the user interface we cannot agreed on is:
> >
> > whether we should support the following nested annotation (either with
> > attribute or with the C syntax extension):
> >
> > struct object {
> > ...
> > unsigned int items;
> > ...
> > struct inner {
> > ...
> > int flex[];
> > };
> > } *ptr;
> >
> I am fine with supporting it, but one needs to decide
> on the semantics in the case where inner is not accessed
> via the outer struct.
Yes, that's right.
[Bug target/109067] Powerpc GCC does not support __ibm128 complex multiply/divide if long double is IEEE 128-bit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109067 --- Comment #1 from Segher Boessenkool --- Do you have a testcase please?
[Bug target/109068] New: bpf: "error: too many function arguments for eBPF" for always_inline function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109068
Bug ID: 109068
Summary: bpf: "error: too many function arguments for eBPF" for
always_inline function
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: david.faust at oracle dot com
CC: cupertino.miranda at oracle dot com, jemarch at gcc dot
gnu.org
Target Milestone: ---
Target: bpf
BPF calling convention does not support function calls with more than
5 arguments. But if the function is inlined this restriction should be
relaxed.
Many convenience macros for BPF in the kernel make use of always_inline
functions, and the expansion of the macro uses can result in an
always_inline function with >5 args. There are several examples of this
in the BPF selftests, so GCC fails to compile those tests.
e.g. on bpf-next:
linux/tools/testing/selftests/bpf/progs/bpf_syscall_macro.c
and corresponding BPF_KSYSCALL macro def in
linux/tools/testing/selftests/bpf/tools/include/bpf/bpf_tracing.h
duplicated from
linux/tools/lib/bpf/bpf_tracing.h
clang compiles these tests without issue.
We should fix the BPF backend check for function arguments to allow
calls to inline functions with >5 args.
$ cat args.c
inline __attribute__((always_inline))
int foo (int a, int b, int c, int d, int e, int f)
{
return a + b + c + d + e + f;
}
int bar (int x)
{
return foo (x, x*2, x*3, x*4, x*5, x*6);
}
$ bpf-unknown-none-gcc -c args.c -o args.o
args.c: In function ‘foo’:
args.c:2:5: error: too many function arguments for eBPF
2 | int foo (int a, int b, int c, int d, int e, int f)
| ^~~
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #30 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #28)
> The problems with VLA are in my opinion caused by poor
> implementation (e.g. no stack probing etc) and bad
> code generation (Linus was not happy about this) and
> not because anything is fundamentally bad about them
> from the point of language semantics.
you mean gcc's implementation? how about other compilers?
> VM = variably modified. In C it is a type which is derived from
> a VLA which is not necessarily itself a VLA, e.g. a pointer to
> a VLA. But a VLA is also a VM type.
Okay.
>
> > struct foo {
> > int len;
> > char (*buf)[.len];
> > };
> >
> >
> > This has less issues because the size of the struct then does not depend
> > on the length.
but I am still not clear on why "the size of the above struct 'foo' does not
depend on the .len?" in my opinion, it should depend on .len. do I miss
anything here?
[Bug target/109067] New: Powerpc GCC does not support __ibm128 complex multiply/divide if long double is IEEE 128-bit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109067 Bug ID: 109067 Summary: Powerpc GCC does not support __ibm128 complex multiply/divide if long double is IEEE 128-bit. Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: meissner at gcc dot gnu.org Target Milestone: ---
[Bug tree-optimization/109008] [13 Regression] Wrong code in scipy package since r13-3926-gd4c2f1d376da6f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #37 from Jakub Jelinek ---
I've additionally ran
#include
#include "pr109008-4.c"
struct S { float (*fn) (float); float lb, ub; };
struct S arr[] = {
#include "pr109008-4.h"
};
int
main ()
{
float plus_inf = __builtin_inf ();
float minus_inf = -plus_inf;
for (int i = 0; i < sizeof (arr) / sizeof (arr[0]); ++i)
{
int n1, n2;
float lb = nextafterf (arr[i].lb, minus_inf);
float ub = nextafterf (arr[i].ub, plus_inf);
if (!__builtin_isnan (arr[i].fn (lb)) || !__builtin_isnan (arr[i].fn
(ub)))
__builtin_printf ("%p err\n", arr[i].fn);
lb = arr[i].lb;
ub = arr[i].ub;
for (n1 = 0; n1 < 50; n1++)
if (!__builtin_isnan (arr[i].fn (lb)))
break;
else if (lb > ub)
{
n1 = -1;
n2 = -1;
break;
}
else
lb = nextafterf (lb, plus_inf);
if (n1 != -1)
for (n2 = 0; n2 < 50; n2++)
if (!__builtin_isnan (arr[i].fn (ub)))
break;
else
ub = nextafterf (ub, minus_inf);
__builtin_printf ("%d %d\n", n1, n2);
}
}
on the header from the #c32+#c33 patches, and
./pr109008-4-main 2>&1 | sort | uniq -c | sort -n
1 1 11
1 11 1
1 1 17
1 1 25
1 1 28
1 1 3
1 1 4
1 19 1
1 2 13
1 2 16
1 2 17
1 2 36
1 2 40
1 3 2
1 39 1
1 5 1
1 5 2
2 1 32
2 1 7
2 3 1
2 3 50
3 4 1
12 50 2
16 2 50
27 50 1
39 1 50
48 32 32
53 33 33
57 17 17
73 16 16
77 8 8
78 9 9
114 4 4
124 5 5
170 3 3
8533 2 2
15203 1 1
24287 50 50
59288 2 1
59613 1 2
130096 -1 -1
The -1 -1 case means that in reality the range is empty (UNDEFINED), there are
no values of eps for which the function returns it, as the difference in
exponents is too large for such a number to exist. 50 means actually 50 or
more ulps.
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #29 from Martin Uecker ---
Am Mittwoch, dem 08.03.2023 um 17:13 + schrieb qinzhao at gcc dot gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
>
> --- Comment #24 from qinzhao at gcc dot gnu.org ---
> (In reply to Martin Uecker from comment #15)
> >
...
>
> however, I think that both the new attribute and the new C syntax extension
> should support the similar user interface. We might need to decide on this
> first.
I think there are some fundamental differences: In one
case the size is encoded into the type and in the other
it is just an annotation that can be ignored.
>
> right now, the user interface we cannot agreed on is:
>
> whether we should support the following nested annotation (either with
> attribute or with the C syntax extension):
>
> struct object {
> ...
> unsigned int items;
> ...
> struct inner {
> ...
> int flex[];
> };
> } *ptr;
>
>
> My opinion is: No, we should not support this, it will make the implementation
> much more complicated both for attribute and for C syntax extension.
>
> But I am not very sure on this yet.
I am fine with supporting it, but one needs to decide
on the semantics in the case where inner is not accessed
via the outer struct.
>
> Is the PLACEHOLDER_EXPR able to resolve this?
I don't know yet.
Martin
>
[Bug fortran/109066] New: Segfault when using defined assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109066 Bug ID: 109066 Summary: Segfault when using defined assignment Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: abensonca at gcc dot gnu.org Target Milestone: --- The following code (compiled using current trunk), when run, causes a segfault, and valgrind complains about an invalid read. The code appears correct to me, and runs correctly (no segfault, no warnings from valgrind) when compiled with ifort. module Input_Parameters_Bug public type :: resourceManager integer :: counter=0 ! Remove this to resolve segfault contains procedure :: resourceManagerAssign generic :: assignment(=) => resourceManagerAssign end type resourceManager type hdf5Object private type (resourceManager) :: objectManager contains procedure :: openGroup =>IO_HDF5_Open_Group ! procedure :: h5Assign ! Add this defined assignment to avoid segfault. ! generic :: assignment(=) => h5Assign end type hdf5Object interface hdf5Object module procedure hdf5Constructor end interface hdf5Object type :: inputParameters private type(hdf5Object), pointer :: outputParameters => null() ! Make this allocatable instead of pointer to resolve segfault end type inputParameters interface inputParameters module procedure inputParametersConstructorNode end interface inputParameters contains subroutine resourceManagerAssign(to,from) implicit none class(resourceManager), intent( out) :: to class(resourceManager), intent(in ) :: from to%counter=from%counter+1 write (0,*) "ASSIGN",to%counter return end subroutine resourceManagerAssign function hdf5Constructor() result(self) implicit none type(hdf5Object) :: self return end function hdf5Constructor function IO_HDF5_Open_Group(inObject) result (self) implicit none type(hdf5Object) :: self class(hdf5Object), intent(in ) :: inObject write (0,*) "OPEN" return end function IO_HDF5_Open_Group subroutine h5Assign(to,from) implicit none class(hdf5Object), intent( out) :: to class(hdf5Object), intent(in ) :: from write (0,*) "ASSIGN H5" to%objectManager=from%objectManager return end subroutine h5Assign function inputParametersConstructorNode(outputParametersGroup) result(self) implicit none type(inputParameters) :: self type(hdf5Object ), intent(in ) :: outputParametersGroup allocate(self%outputParameters) write (0,*) "START" self%outputParameters=outputParametersGroup%openGroup() write (0,*) "STOP" return end function inputParametersConstructorNode end module Input_Parameters_Bug program Test_Parameters_Bug use :: Input_Parameters_Bug implicit none type(hdf5Object) :: outputFile type(inputParameters) :: testParameters outputFile=hdf5Object() write (0,*) "CALL" testParameters=inputParameters(outputFile) end program Test_Parameters_Bug $ gfortran bug.F90 -g $ valgrind --track-origins=yes ./a.out ==19625== Memcheck, a memory error detector ==19625== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==19625== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info ==19625== Command: ./a.out ==19625== ASSIGN 1 CALL START OPEN ==19625== Use of uninitialised value of size 8 ==19625==at 0x4012DF: __input_parameters_bug_MOD_inputparametersconstructornode (bug.F90:73) ==19625==by 0x4017D4: MAIN__ (bug.F90:87) ==19625==by 0x401812: main (bug.F90:81) ==19625== Uninitialised value was created by a stack allocation ==19625==at 0x401206: __input_parameters_bug_MOD_inputparametersconstructornode (bug.F90:67) ==19625== Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x4e161ef in ??? #1 0x4012df in __input_parameters_bug_MOD_inputparametersconstructornode at /data001/abenson/Galacticus/galacticus_gfortranFinalization/bug.F90:73 #2 0x4017d4 in test_parameters_bug at /data001/abenson/Galacticus/galacticus_gfortranFinalization/bug.F90:87 #3 0x401812 in main at /data001/abenson/Galacticus/galacticus_gfortranFinalization/bug.F90:81 ==19625== ==19625== Process terminating with default action of signal 11 (SIGSEGV) ==19625==at 0x4E1613E: raise (in /home/abenson/Galacticus/Tools/lib/libc-2.12.1.so) ==19625==by 0x4E161EF: ??? (in /home/abenson/Galacticus/Tools/lib/libc-2.12.1.so) ==19625==by 0x4012DE: __input_parameters_bug_MOD_inputparametersconstructornode (bug.F90:73) ==19625==by 0x4017D4: MAIN__ (bug.F90:87) ==19625==by 0x401812: main (bug.F90:81) ==19625== ==19625== HEAP SUMMARY: ==19625== in use at exit: 5,448 bytes in 18 blocks ==1962
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #28 from Martin Uecker ---
Am Mittwoch, dem 08.03.2023 um 16:56 + schrieb qinzhao at gcc dot gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
>
> --- Comment #23 from qinzhao at gcc dot gnu.org ---
> (In reply to Martin Uecker from comment #13)
> >
> > VLAs and VM types exist since C99 and were made optional in C11.
> > The minimal change we adopted to make support for VM types
> > (but not VLAs) mandatory again was:
> >
> > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2778.pdf
>
> So, this will be official in C23? i.e, VM types will be mandatory, but VLA
> will
> be optional (and later might be deprecated?)
Yes, this is in C23. But no, the plan is *not* to deprecate VLAs.
I really hope we can make VLAs mandatory at some point as well
and I will push very much in this direction.
This reason is that VLAs are very good properties:
- automatic memory management
- run-time bounds (which can be used for checking)
The problems with VLA are in my opinion caused by poor
implementation (e.g. no stack probing etc) and bad
code generation (Linus was not happy about this) and
not because anything is fundamentally bad about them
from the point of language semantics.
They are now often replaced by fixed size buffers on
the stack, which I think is a step backwards form the
point of security because the information about the
precise run-time bound is lost.
> >
> > I think using PLACEHOLDER_EXPR that are insert into the size
> > expression and then replaced later by the struct being accessed,
> > e.g.
> >
> > struct foo {
> > int len;
> > char buf[PLACEHOLDER_EXPR.len]
> > };
> >
> > and then later when we have
> >
> > struct foo x;
> >
> > x->buf
> >
> > we would replace in the size of the type for x->buf the placeholder
> > with x itself.
>
> I see. Yes, this will resolve the implementation difficulty for filling the
> size of the FAM field when the size is the previous declared field in the same
> structure.
>
>
> > Yes, this was what I wanted to do... My main use case is not flexible
> > array members but VM types in struct:
> >
> > struct foo {
> > int len;
> > char (*buf)[.len];
> > };
> >
> >
> > This has less issues because the size of the struct then does not depend
> > on the length.
>
> a little confused here:
> what's the definition of VM type? it's size will not depend on the ".len" ?
VM = variably modified. In C it is a type which is derived from
a VLA which is not necessarily itself a VLA, e.g. a pointer to
a VLA. But a VLA is also a VM type.
Martin
>
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896 --- Comment #27 from qinzhao at gcc dot gnu.org --- (In reply to Siddhesh Poyarekar from comment #22) > This really should have been the way __access__ was implemented, but we tied > that attribute to only functions. Would it be a terrible idea to make > __element_count__ more general purpose so that it ends up deprecating > __access__? I feel that __access__ and __element_count_ have some overlapping, but serve different purposes, might not be good to merge them?
[Bug c++/109065] [11/12/13 Regression] Type alias combination erroneously fails with "incomplete type"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109065
--- Comment #2 from Andrew Pinski ---
>* Don't use the second alias level for d, i.e. https://godbolt.org/z/KaWq9Pfq8
Using a typedef instead of alias still fails.
That is:
```
template using DataAlias = int;
template struct MyUniquePtr {};
template struct Test {
typedef DataAlias Data;
MyUniquePtr d;
};
Test test;
```
Still fails.
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896 --- Comment #26 from qinzhao at gcc dot gnu.org --- (In reply to Martin Uecker from comment #20) > > I agree. An attribute is simple and extending C will take > more care (and work). > > The reason I think we should also extend C (together with > WG14) is because this would allow writing code where the > bound is never lost because it is encoded in the type, > while the __builtin_dynamic_object_size is extremely > useful to enhance existing code bases, but is best > effort only. > > So I think we should do both. > Agreed.
[Bug c++/109065] [11/12/13 Regression] Type alias combination erroneously fails with "incomplete type"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109065 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection, ||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2023-03-08 Target Milestone|--- |11.4 Ever confirmed|0 |1 Known to fail||11.1.0 Known to work||10.4.0 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #25 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #17)
> The syntax with the dot would make it not conflict. But I need
> this for this use case
>
> struct foo {
> int count;
> int (*buf)[.count];
> };
>
> so that ARRAY_SIZE(*foo->buf) works correctly and also accesses
> to foo->buf are bounds checkked. So it would make sense to
> solve to treat flexible array members in the same way.
Yes, I agree.
then the size of the array type (even though it's not a constant) will be
embedded in the TYPE consistently. therefore simplify compiler's implementation
and make it consistently.
>
> But I agree that we should simply add the attribute now also
> because it makes it possible to use it for existing code bases.
Yes.
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #24 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #15)
>
> Yes, but that syntax would be intuitive which I would see
> as an advantage.
Yes, I agree.
>
> But I am not saying we shouldn't have the attribute first.
both the new attribute and the C's syntax extension might be needed at the same
time, I think.
1. Attribute might be better for changing the existing source code to make them
bound-checking friendly;
2. new code can use the C's syntax change, and hopefully this new syntax
extension can be made into next C language standard.
however, I think that both the new attribute and the new C syntax extension
should support the similar user interface. We might need to decide on this
first.
right now, the user interface we cannot agreed on is:
whether we should support the following nested annotation (either with
attribute or with the C syntax extension):
struct object {
...
unsigned int items;
...
struct inner {
...
int flex[];
};
} *ptr;
My opinion is: No, we should not support this, it will make the implementation
much more complicated both for attribute and for C syntax extension.
But I am not very sure on this yet.
Is the PLACEHOLDER_EXPR able to resolve this?
[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109031
--- Comment #18 from David Binderman ---
Part way through reduction, the C code seems to be
int crc32_tab_0;
int crc32_context = 0xUL;
void main(int , char []) {
{
int crc;
int i;
i = 0;
for (; i < 256; i++)
crc32_tab_0 = crc;
{
{ crc32_context = 0 ^ crc32_tab_0; }
}
printf("...checksum after hashing %s : %lX\n", "g_50",
crc32_context ^ 0xUL);
}
}
This looks to me like reading rubbish off the local variable stack in main
and then hashing it.
AFAIK not a bug in gcc, but may be a bug in csmith.
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #23 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #13)
>
> VLAs and VM types exist since C99 and were made optional in C11.
> The minimal change we adopted to make support for VM types
> (but not VLAs) mandatory again was:
>
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2778.pdf
So, this will be official in C23? i.e, VM types will be mandatory, but VLA will
be optional (and later might be deprecated?)
>
> I think using PLACEHOLDER_EXPR that are insert into the size
> expression and then replaced later by the struct being accessed,
> e.g.
>
> struct foo {
> int len;
> char buf[PLACEHOLDER_EXPR.len]
> };
>
> and then later when we have
>
> struct foo x;
>
> x->buf
>
> we would replace in the size of the type for x->buf the placeholder
> with x itself.
I see. Yes, this will resolve the implementation difficulty for filling the
size of the FAM field when the size is the previous declared field in the same
structure.
> Yes, this was what I wanted to do... My main use case is not flexible
> array members but VM types in struct:
>
> struct foo {
> int len;
> char (*buf)[.len];
> };
>
>
> This has less issues because the size of the struct then does not depend
> on the length.
a little confused here:
what's the definition of VM type? it's size will not depend on the ".len" ?
[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109031 --- Comment #17 from David Binderman --- (In reply to Martin Liška from comment #16) > bash -x qwe.sh bug892.c That's a really useful tip. Thanks. I've debugged the script some more and now have: rm -f 1 2 one.exe two.exe /usr/bin/gcc -w -Werror=implicit bug892.c -o one.exe \ && (./one.exe 1 | fgrep "checksum after hashing g_50 :" > 1) if test $? != 0; then exit 1 fi # So we have a checksum in file 1. /home/dcb36/gcc/results/bin/gcc -w -O2 -fno-strict-aliasing bug892.c -o two.exe \ && (./two.exe 1 | fgrep "checksum after hashing g_50 :" > 2) if test $? != 0; then exit 1 fi # And we have a checksum in file 2. diff 1 2 if test $? = 0; then exit 1 fi exit 0 This script appears to be running nicely now. I will report back when it has finished or made significant progress.
[Bug tree-optimization/109008] [13 Regression] Wrong code in scipy package since r13-3926-gd4c2f1d376da6f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #36 from Jakub Jelinek ---
Ok, checked the #c30 patch with printouts from #c33 added by hand before return
true;
at the end of each of +/- op?_range, that passed 30 tests too.
Out of the 297936 lines in the pr109008.h headers (rest are probably lines with
nans),
#include
#include "pr109008-4.c"
struct S { float (*fn) (float); float lb, ub; };
struct S arr[] = {
#include "pr109008-4-new.h"
};
struct S arr2[] = {
#include "pr109008-4-iter.h"
};
int
main ()
{
int stats[10] = {};
float plus_inf = __builtin_inf ();
float minus_inf = -plus_inf;
for (int i = 0; i < sizeof (arr) / sizeof (arr[0]); ++i)
{
if (arr[i].lb == arr2[i].lb && arr[i].ub == arr2[i].ub)
{
stats[0]++;
continue;
}
if (arr[i].lb > arr2[i].lb || arr[i].ub < arr2[i].ub)
{
stats[1]++;
continue;
}
float lb = nextafterf (arr2[i].lb, minus_inf);
float ub = nextafterf (arr2[i].ub, plus_inf);
if (arr[i].lb == lb && arr[i].ub == ub)
{
stats[2]++;
continue;
}
__builtin_printf ("%p %a %a %a %a\n", arr[i].fn, arr[i].lb, arr2[i].lb,
arr2[i].ub, arr[i].ub);
}
__builtin_printf ("%d %d %d\n", stats[0], stats[1], stats[2]);
}
hack shows 128572 cases where both approaches yield the same ranges, 0 cases
where the #c32 would result
in narrower ranges than #c30, 167497 where both bounds are exactly one ulp
worse with #c32 and 1868
other cases, some are 2ulps, others a little bit more. But I'd say this is
still all acceptable.
Richi, what do you think?
I'll bootstrap/regtest the #c32 patch overnight just in case.
[Bug libstdc++/109064] Maximum recursion depth exceeded in std::shared_ptr xmethod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109064 --- Comment #1 from ks1322 at gmail dot com --- Looks like infinite recursion is here, SharedPtrUseCountWorker.__init__ calls itself ``` class SharedPtrUseCountWorker(gdb.xmethod.XMethodWorker): "Implements std::shared_ptr::use_count()" def __init__(self, elem_type): SharedPtrUseCountWorker.__init__(self, elem_type) ```
[Bug libstdc++/109024] [C++23][ranges][repeat_view] The default ctor unuseable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109024 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org CC||ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug tree-optimization/109041] Bogus compile time check by __builtin_memset? error: ‘__builtin_memset’ writing 4 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109041 --- Comment #7 from ishikawa,chiaki --- If I change gcc-11 into gcc-12 in the attached script, I get the different warning. My version of gcc-12 is: ishikawa@ip030:/NREF-COMM-CENTRAL/mozilla$ gcc-12 --version gcc-12 (Debian 12.2.0-14) 12.2.0 Copyright (C) 2022 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug tree-optimization/109008] [13 Regression] Wrong code in scipy package since r13-3926-gd4c2f1d376da6f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #35 from Jakub Jelinek ---
gcc -g -o pr109008-main{,.c}; ./pr109008-main
should have been
gcc -g -o pr109008-main{,.c} -lm; ./pr109008-main
sorry.
Anyway, 30 functions now finished, 25471 errors for #c33 patch, 0 errors
for #c32 + #c33 patches, now #c30 with adjustments.
[Bug tree-optimization/109041] Bogus compile time check by __builtin_memset? error: ‘__builtin_memset’ writing 4 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109041 --- Comment #6 from ishikawa,chiaki --- Created attachment 54610 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54610&action=edit The script to produce the warning in the original report with gcc-11. The source file needs to be in /tmp/sqlite3-preprocessed-2.c Run this script with bash this-script and it will print something like this on my linux PC. Here I put the script into t83.sh: bash ~/Dropbox/TB-DIR/WALL-PATCH-DIR/t83.sh /tmp/sqlite3-preprocessed-2.c: In function ‘posixUnlock’: /tmp/sqlite3-preprocessed-2.c:22632:42: error: self-comparison always evaluates to true [-Werror=tautological-compare] 22632 | sqlite3PendingByte+1==(sqlite3PendingByte+1) | ^~ In function ‘memset’, inlined from ‘pager_playback’ at /tmp/sqlite3-preprocessed-2.c:32113:4: /tmp/sqlite3-preprocessed-2.c:4273:10: error: ‘__builtin_memset’ writing 4 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=] 4273 | return __builtin___memset_chk (__dest, __ch, __len, __builtin_object_size (__dest, 0)); | ^~~ /tmp/sqlite3-preprocessed-2.c: In function ‘pager_playback’: /tmp/sqlite3-preprocessed-2.c:32089:30: note: destination object ‘*pPager.pTmpSpace’ of size [0, 9223372036854775807] 32089 | zSuper = (void *) &pPager->pTmpSpace[4]; |~~^~~ /tmp/sqlite3-preprocessed-2.c:32089:30: note: destination object ‘*pPager.pTmpSpace’ of size [0, 9223372036854775807] cc1: all warnings being treated as errors ishikawa@ip030:/NREF-COMM-CENTRAL/mozilla$
[Bug modula2/109032] message 'compiler checks to force' is too complicated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109032 Gaius Mulley changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2023-03-08 --- Comment #6 from Gaius Mulley --- Many thanks for reporting these areas of poor error messages - I'll change all of these.
[Bug tree-optimization/109008] [13 Regression] Wrong code in scipy package since r13-3926-gd4c2f1d376da6f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #34 from Jakub Jelinek ---
Testing I've performed so far (though on 1 iterations rather than 30,
that is ongoing), once with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008#c33 patch alone, once with
that patch and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008#c32.
First step, generate a random testcase:
pr109008-gen.c:
#include
#include
#include
#include
static long rand_n;
static int rand_c;
static uint32_t
get_rand32 (void)
{
uint32_t ret = 0;
if (rand_c == 0)
{
ret = random () & 0x7fff;
rand_c = 31;
}
else
ret = rand_n & (((uint32_t) 1 << rand_c) - 1);
ret <<= (32 - rand_c);
rand_n = random ();
ret |= rand_n & (((uint32_t) 1 << (32 - rand_c)) - 1);
rand_n >>= (32 - rand_c);
rand_c = 31 - (32 - rand_c);
return ret;
}
static uint64_t
get_rand64 (void)
{
return (((uint64_t) get_rand32 ()) << 32) | get_rand32 ();
}
static float
get_randf (void)
{
uint32_t i = get_rand32 ();
float f;
memcpy (&f, &i, sizeof (f));
return f;
}
int
main ()
{
printf ("#define nanf __builtin_nanf (\"\")\n");
printf ("#define inf __builtin_inff ()\n");
for (int n = 0; n < 30; ++n)
{
float n1 = get_randf ();
float n2 = get_randf ();
uint32_t x = get_rand32 ();
if ((x & 7) == 0)
n2 = n1;
x >>= 3;
printf ("float f%d (float eps) { float f = ", n);
switch (x % 3)
{
case 0: printf ("%af + eps", n1); break;
case 1: printf ("%af - eps", n1); break;
case 2: printf ("eps - %af", n1); break;
}
printf ("; if (f == %af) return eps; return __builtin_nanf (\"42\");
}\n", n2);
}
return 0;
}
pr109008-main.c:
#include
#include "pr109008.c"
struct S { float (*fn) (float); float lb, ub; };
struct S arr[] = {
#include "pr109008.h"
};
int
main ()
{
float plus_inf = __builtin_inf ();
float minus_inf = -plus_inf;
for (int i = 0; i < sizeof (arr) / sizeof (arr[0]); ++i)
{
float lb = nextafterf (arr[i].lb, minus_inf);
float ub = nextafterf (arr[i].ub, plus_inf);
if (!__builtin_isnan (arr[i].fn (lb)) || !__builtin_isnan (arr[i].fn
(ub)))
__builtin_printf ("%p err\n", arr[i].fn);
}
}
gcc -g -O2 -o pr109008-gen{,.c}; ./pr109008-gen > pr109008.c
Next, with cc1 built with just #c33 patch:
rm -f /tmp/ranges; ./cc1 -quiet -O2 pr109008.c; sort -u /tmp/ranges >
pr109008.h
gcc -g -o pr109008-main{,.c}; ./pr109008-main
For 1 iterations this showed 872 errors.
Next, with cc1 built with both #c32 and #c33 patches:
rm -f /tmp/ranges; ./cc1 -quiet -O2 pr109008.c; sort -u /tmp/ranges >
pr109008.h
gcc -g -o pr109008-main{,.c}; ./pr109008-main
This didn't print any errors, so at least for foperator_plus and
foperator_minus seems
to be from this limited testing conservatively correct.
Want to finish now this testing also for 30 iterations and then perhaps try
the #c30 patch with variant of #c33 to check also that implementation.
And finally compare the #c32+#c33 vs. #c30+#c33variant ranges.
Another thing which would be nice to think about is whether
float_widen_lhs_range
needs to extend even real_{min,max}_representable () bounds towards -+inf, or
whether
that case can't happen (and check that separately for + or - and * or /),
because e.g. for mult/div whether lhs is finite is quite important.
[Bug tree-optimization/109008] [13 Regression] Wrong code in scipy package since r13-3926-gd4c2f1d376da6f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008 --- Comment #33 from Jakub Jelinek --- Created attachment 54609 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54609&action=edit gcc13-pr109008-debug.patch And debugging code.
[Bug tree-optimization/109008] [13 Regression] Wrong code in scipy package since r13-3926-gd4c2f1d376da6f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008 --- Comment #32 from Jakub Jelinek --- Created attachment 54608 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54608&action=edit gcc13-pr109008.patch So far almost untested patch which does the lhs widening.
[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109031 --- Comment #16 from Martin Liška --- (In reply to David Binderman from comment #15) > (In reply to Martin Liška from comment #14) > > > cvise is written in perl, isn't it ? You've got my cvise script. > > > > No, it's written in Python. > > Of course. How stupid of me. > > > So show me how you run cvise then? > > $ cvise --n 8 qwe.sh bug892.c > > where qwe.sh is the script shown above and bug892.c is the csmith > produced C source code I am trying to reduce. and what error do you see? Then please run: bash -x qwe.sh bug892.c
[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109031 --- Comment #15 from David Binderman --- (In reply to Martin Liška from comment #14) > > cvise is written in perl, isn't it ? You've got my cvise script. > > No, it's written in Python. Of course. How stupid of me. > So show me how you run cvise then? $ cvise --n 8 qwe.sh bug892.c where qwe.sh is the script shown above and bug892.c is the csmith produced C source code I am trying to reduce.
[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109031 --- Comment #14 from Martin Liška --- (In reply to David Binderman from comment #13) > (In reply to Martin Liška from comment #12) > > > perl program converted to 0 is proving to be a challenge. > > > > perl? Please provide a complete script reproducer. > > cvise is written in perl, isn't it ? You've got my cvise script. No, it's written in Python. So show me how you run cvise then?
[Bug libstdc++/108976] codecvt for Unicode allows surrogate code points
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108976 --- Comment #6 from Dimitrij Mijoski --- I sent a single patch to the mailing list with a good detailed commit message. I think that is better than multiple patches.
[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109031 --- Comment #13 from David Binderman --- (In reply to Martin Liška from comment #12) > > perl program converted to 0 is proving to be a challenge. > > perl? Please provide a complete script reproducer. cvise is written in perl, isn't it ? You've got my cvise script.
[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109031 --- Comment #12 from Martin Liška --- > perl program converted to 0 is proving to be a challenge. perl? Please provide a complete script reproducer.
[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109031 --- Comment #11 from David Binderman --- (In reply to Martin Liška from comment #10) > What about: > > /usr/bin/gcc -w -Werror=implicit bug892.c -o one.exe > && (./one.exe 1 | fgrep "checksum after hashing g_50 :" > 1) > && /home/dcb36/gcc/results/bin/gcc -w -O2 -fno-strict-aliasing bug892.c > -o two.exe > && (./two.exe 1 | fgrep "checksum after hashing g_50 :" > 2) > > if test $? != 0; then > exit 1 > > diff 1 2; > if test $? = 0; then > exit 1 > fi > exit 0 > > ? Thanks for the idea, but no further forward ;-|. Getting to the diff is easy. Getting the return code of 1 from the diff out to the calling perl program converted to 0 is proving to be a challenge. $ diff 1 2 1c1 < ...checksum after hashing g_50 : 646CF84D --- > ...checksum after hashing g_50 : C21BF3F9 $ echo $? 1 $
[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109031 --- Comment #10 from Martin Liška --- (In reply to David Binderman from comment #9) > (In reply to Martin Liška from comment #8) > > > but then if diff returns 1, the script should return 0 and > > > if diff returns 0, then the script should return 1. > > > > You can take an inspiration here: > > https://github.com/marxin/gcc-util/blob/master/bisect/reduce.sh > > Thanks for that. I am a bit further forward and I have this cvise > script: > > /usr/bin/gcc -w -Werror=implicit bug892.c -o one.exe > && (./one.exe 1 | fgrep "checksum after hashing g_50 :" > 1) > && /home/dcb36/gcc/results/bin/gcc -w -O2 -fno-strict-aliasing bug892.c > -o two.exe If the compilation fails for any reason, then the compound && expression is false (non-zero) and thus you end up with 'exit 0'. That's not what you want I guess. What about: /usr/bin/gcc -w -Werror=implicit bug892.c -o one.exe && (./one.exe 1 | fgrep "checksum after hashing g_50 :" > 1) && /home/dcb36/gcc/results/bin/gcc -w -O2 -fno-strict-aliasing bug892.c -o two.exe && (./two.exe 1 | fgrep "checksum after hashing g_50 :" > 2) if test $? != 0; then exit 1 diff 1 2; if test $? = 0; then exit 1 fi exit 0 ? > && (./two.exe 1 | fgrep "checksum after hashing g_50 :" > 2) > && diff 1 2; > if test $? = 0; then > exit 1 > fi > exit 0 > > It still doesn't work right and I can't fathom what's wrong. > It all works nicely when I do it line by line.
[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109031 --- Comment #9 from David Binderman --- (In reply to Martin Liška from comment #8) > > but then if diff returns 1, the script should return 0 and > > if diff returns 0, then the script should return 1. > > You can take an inspiration here: > https://github.com/marxin/gcc-util/blob/master/bisect/reduce.sh Thanks for that. I am a bit further forward and I have this cvise script: /usr/bin/gcc -w -Werror=implicit bug892.c -o one.exe && (./one.exe 1 | fgrep "checksum after hashing g_50 :" > 1) && /home/dcb36/gcc/results/bin/gcc -w -O2 -fno-strict-aliasing bug892.c -o two.exe && (./two.exe 1 | fgrep "checksum after hashing g_50 :" > 2) && diff 1 2; if test $? = 0; then exit 1 fi exit 0 It still doesn't work right and I can't fathom what's wrong. It all works nicely when I do it line by line.
[Bug target/94908] Failure to optimally optimize certain shuffle patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94908 --- Comment #7 from Uroš Bizjak --- Created attachment 54607 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54607&action=edit Proposed patch Patch in testing. Attached patch produces (-O2 -msse4.1): f: subq$24, %rsp xorl%eax, %eax vmovaps %xmm0, (%rsp) callg vmovaps (%rsp), %xmm1 addq$24, %rsp vinsertps $64, %xmm0, %xmm1, %xmm0 ret
[Bug c++/109065] New: [11/12/13 Regression] Type alias combination erroneously fails with "incomplete type"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109065
Bug ID: 109065
Summary: [11/12/13 Regression] Type alias combination
erroneously fails with "incomplete type"
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marcel.jacobse at ewetel dot net
Target Milestone: ---
Starting with gcc 11.1, the code
template using DataAlias = int;
template struct MyUniquePtr {};
template struct Test {
using Data = DataAlias;
MyUniquePtr d;
};
Test test;
fails to compile with
: In instantiation of 'struct Test':
:8:11: required from here
:6:25: error: 'Test::d' has incomplete type
6 | MyUniquePtr d;
| ^
:2:27: note: declaration of 'struct MyUniquePtr'
2 | template struct MyUniquePtr {};
| ^~~
See for example: https://godbolt.org/z/oq9TjqKrW
I believe this to be valid C++11 through C++20 and it seems to compile just
fine with clang, MSVC and any gcc <= 10.4 that supports C++11.
A range of minor changes make it compile again, for example:
* Make DataAlias actually use T in any way, e.g.
https://godbolt.org/z/cb9dW1E6s
* Don't use an array type for d, i.e. https://godbolt.org/z/MGKPcjEz3
* Don't use the second alias level for d, i.e. https://godbolt.org/z/KaWq9Pfq8
[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109031 --- Comment #8 from Martin Liška --- (In reply to David Binderman from comment #7) > (In reply to David Binderman from comment #4) > > Created attachment 54596 [details] > > C source code > > > > After 3 hours further reduction. > > I am struggling with further reduction. My bash knowledge is short. > > My cvise script is: > > /usr/bin/gcc -w -Werror=implicit bug892.c \ > && (./a.out 1 > 1) \ > && /home/dcb36/gcc/results/bin/gcc -w -O2 -fno-strict-aliasing bug892.c > \ > && (./a.out 1 > 2) \ > && diff 1 2; \ > > but then if diff returns 1, the script should return 0 and > if diff returns 0, then the script should return 1. You can take an inspiration here: https://github.com/marxin/gcc-util/blob/master/bisect/reduce.sh and you can use multiple `if` statements.
[Bug libstdc++/109064] New: Maximum recursion depth exceeded in std::shared_ptr xmethod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109064
Bug ID: 109064
Summary: Maximum recursion depth exceeded in std::shared_ptr
xmethod
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ks1322 at gmail dot com
Target Milestone: ---
Based on
https://stackoverflow.com/questions/75652764/gdb-fails-with-python-exception-class-recursionerror-maximum-recursion-dep
Seems that trying to print unique() and use_count() in GDB for std::shared_ptr
causes infinite recursion in Python xmethods.
For this code:
```
#include
#include
int main() {
auto ptr = std::make_shared(0);
std::cout << ptr.use_count() << "\n";
return 0;
}
```
Buid with:
```
g++ -g main.cc
```
Results in "maximum recursion depth exceeded" error
```
$ gdb -batch -ex "b 7" -ex r -ex "p ptr.use_count()" -ex "p ptr.unique()" a.out
Breakpoint 1 at 0x40122f: file /tmp/main.cc, line 7.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
1
Breakpoint 1, main () at /tmp/main.cc:7
7 return 0;
Python Exception : maximum recursion depth exceeded
Error while looking for matching xmethod workers defined in Python.
Python Exception : maximum recursion depth exceeded
Error while looking for matching xmethod workers defined in Python.
```
As a workaround xmethods can be disabled with
```
(gdb) disable xmethod
```
[Bug tree-optimization/109008] [13 Regression] Wrong code in scipy package since r13-3926-gd4c2f1d376da6f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008 --- Comment #31 from Jakub Jelinek --- Created attachment 54606 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54606&action=edit gcc13-pr109008-wip-debug.patch And the incremental debugging patch for that.
[Bug tree-optimization/109008] [13 Regression] Wrong code in scipy package since r13-3926-gd4c2f1d376da6f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008 Jakub Jelinek changed: What|Removed |Added Attachment #54602|0 |1 is obsolete|| --- Comment #30 from Jakub Jelinek --- Created attachment 54605 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54605&action=edit gcc13-pr109008-wip.patch Fixed iterative patch (just for archival purposes only). Note, even this one isn't exact, because of the way the tests conservatively try to round inexact operations (normally in a way to make the range slightly larger, in this case the tests for e.g. low bound the normal operation towards +inf), for f1 above with this patch one gets [frange] double [-1.11022302462515641716411522730772571691741167456465161356e-16 (-0x0.f8p-53), 2.22044604925031283432823045461545143383482334912930322712e-16 (0x0.f8p-52)] instead of [-0x0.8p-53, 0x0.8p-52] which is the minimal range.
[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109031 --- Comment #7 from David Binderman --- (In reply to David Binderman from comment #4) > Created attachment 54596 [details] > C source code > > After 3 hours further reduction. I am struggling with further reduction. My bash knowledge is short. My cvise script is: /usr/bin/gcc -w -Werror=implicit bug892.c \ && (./a.out 1 > 1) \ && /home/dcb36/gcc/results/bin/gcc -w -O2 -fno-strict-aliasing bug892.c \ && (./a.out 1 > 2) \ && diff 1 2; \ but then if diff returns 1, the script should return 0 and if diff returns 0, then the script should return 1.
[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532 --- Comment #13 from Martin Liška --- I can confirm the reduced test-case is fixed, however the original file is still not. I've created: https://bugs.libcamera.org/show_bug.cgi?id=185
[Bug middle-end/108546] [11/12/13 Regression] ICE in expand_expr_real_1, at expr.cc:10910 since r10-4531-ga2c26c50310a3363
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108546 --- Comment #4 from CVS Commits --- The releases/gcc-12 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:fa1e458d05a94d064e8daef88c2be300317d7e8b commit r12-9235-gfa1e458d05a94d064e8daef88c2be300317d7e8b Author: Tobias Burnus Date: Wed Mar 1 13:53:09 2023 +0100 OpenMP/Fortran: Fix handling of optional is_device_ptr + bind(C) [PR108546] For is_device_ptr, optional checks should only be done before calling libgomp, afterwards they are NULL either because of absent or, by chance, because it is unallocated or unassociated (for pointers/allocatables). Additionally, it fixes an issue with explicit mapping for 'type(c_ptr)'. PR middle-end/108546 gcc/fortran/ChangeLog: * trans-openmp.cc (gfc_trans_omp_clauses): Fix mapping of type(C_ptr) variables. gcc/ChangeLog: * omp-low.cc (lower_omp_target): Remove optional handling on the receiver side, i.e. inside target (data), for use_device_ptr. libgomp/ChangeLog: * testsuite/libgomp.fortran/is_device_ptr-3.f90: New test. * testsuite/libgomp.fortran/use_device_ptr-optional-4.f90: New test. (cherry picked from commit 96ff97ff6574666a5509ae9fa596e7f2b6ad4f88)
[Bug tree-optimization/109008] [13 Regression] Wrong code in scipy package since r13-3926-gd4c2f1d376da6f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008 --- Comment #29 from Aldy Hernandez --- Created attachment 54604 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54604&action=edit untested patch for NAN state copying This is what I had in mind. Notice I haven't touched the fields in frange itself, to keep disruption to a minimum in this release. In the next release we could replace m_pos_nan and m_neg_nan with nan_state. If this helps, I could test and document it.
[Bug tree-optimization/109041] Bogus compile time check by __builtin_memset? error: ‘__builtin_memset’ writing 4 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109041 --- Comment #5 from Martin Liška --- I can't reproduce the warning with the provided test-case :/ What options do you use?
[Bug tree-optimization/109008] [13 Regression] Wrong code in scipy package since r13-3926-gd4c2f1d376da6f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #28 from Jakub Jelinek ---
On IRC we've discussed this and I believe a possible fix could be before we do:
return float_binary_op_range_finish (minus.fold_range (r, type, lhs, op2),
r, type, lhs);
etc. artificially extend the lhs range by 1ulp or .5ulp or whatever works in
each direction (on a copy) and then just let it do its job.
But I want to fixup above patch first, so that we have something to compare to.
From
--- gcc/range-op-float.cc.jj2023-03-07 21:20:49.885225381 +0100
+++ gcc/range-op-float.cc 2023-03-08 09:13:10.063608296 +0100
@@ -2319,9 +2319,15 @@ float_range_extend (tree type, frange &r
u = m;
}
gcc_checking_assert (l + 1 == u);
+fprintf (stderr, "--\n");
+SET_REAL_EXP (&t, l);
+real_arithmetic (&w, PLUS_EXPR, &v, &t);
+real_convert (&w, mode, &w);
+test (w, type, lhs, op2);
SET_REAL_EXP (&t, u);
real_arithmetic (&w, PLUS_EXPR, &v, &t);
real_convert (&w, mode, &w);
+test (w, type, lhs, op2);
REAL_VALUE_TYPE lastw = w;
for (int i = SIGNIFICAND_BITS - 2; i >= SIGNIFICAND_BITS - 2 - p; i--)
{
@@ -2338,7 +2344,10 @@ float_range_extend (tree type, frange &r
lastw = w;
}
w = lastw;
+fprintf (stderr, "---\n");
+test (w, type, lhs, op2);
frange_nextafter (mode, w, upper ? dconstninf : dconstinf);
+test (w, type, lhs, op2);
goto update;
}
@@ -2367,7 +2376,15 @@ public:
REAL_VALUE_TYPE res;
frange_arithmetic (PLUS_EXPR, type, res, r,
op2.lower_bound (), dconstinf);
- return !real_less (&res, &lhs.lower_bound ());
+bool ret = !real_less (&res, &lhs.lower_bound ());
+char br[60], bop2[60], bres[60], blhs[60];
+real_to_hexadecimal (br, &r, sizeof (br), 0, 1);
+real_to_hexadecimal (bop2, &op2.lower_bound (), sizeof (bop2), 0, 1);
+real_to_hexadecimal (bres, &res, sizeof (bres), 0, 1);
+real_to_hexadecimal (blhs, &lhs.lower_bound (), sizeof (blhs), 0, 1);
+fprintf (stderr, "float_range_extend1 %s + %s = %s %s %s\n", br, bop2, bres,
ret ? ">=" : "<", blhs);
+return ret;
+// return !real_less (&res, &lhs.lower_bound ());
});
float_range_extend (type, r, lhs, op2, true,
[] (REAL_VALUE_TYPE &r, tree type,
@@ -2376,7 +2393,15 @@ public:
REAL_VALUE_TYPE res;
frange_arithmetic (PLUS_EXPR, type, res, r,
op2.upper_bound (), dconstninf);
- return !real_less (&lhs.upper_bound (), &res);
+bool ret = !real_less (&lhs.upper_bound (), &res);
+char br[60], bop2[60], bres[60], blhs[60];
+real_to_hexadecimal (br, &r, sizeof (br), 0, 1);
+real_to_hexadecimal (bop2, &op2.lower_bound (), sizeof (bop2), 0, 1);
+real_to_hexadecimal (bres, &res, sizeof (bres), 0, 1);
+real_to_hexadecimal (blhs, &lhs.lower_bound (), sizeof (blhs), 0, 1);
+fprintf (stderr, "float_range_extend2 %s + %s = %s %s %s\n", br, bop2, bres,
ret ? "<=" : ">", blhs);
+return ret;
+// return !real_less (&lhs.upper_bound (), &res);
});
return true;
}
debugging hacks seems it is the loop that tries to narrow the mantissa bits
that is wrong, as immediately before it the l and u values seem correct:
float_range_extend1 -0x0.8p-53 + 0x0.8p+1 = 0x0.8p+1 >= 0x0.8p+1
float_range_extend1 -0x0.8p-52 + 0x0.8p+1 = 0x0.f8p+0 < 0x0.8p+1
where the first is for l where test passes and u doesn't (and the right answer
here is -0x0.8p-53).
[Bug tree-optimization/109008] [13 Regression] Wrong code in scipy package since r13-3926-gd4c2f1d376da6f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #27 from Aldy Hernandez ---
(In reply to Richard Biener from comment #21)
> So without messing with real.cc to try exposing 0.5ulp adjustments for GCC
> 13 I'd simply do something like the following:
>
> diff --git a/gcc/range-op-float.cc b/gcc/range-op-float.cc
> index ff42b95de4f..1ae68503664 100644
> --- a/gcc/range-op-float.cc
> +++ b/gcc/range-op-float.cc
> @@ -2214,7 +2214,26 @@ public:
> range_op_handler minus (MINUS_EXPR, type);
> if (!minus)
>return false;
> -return float_binary_op_range_finish (minus.fold_range (r, type, lhs,
> op2),
> +/* The forward operation is
> +lhs = r + op2
> + where the result is +-0.5ulp of lhs before rounding. For the
> + reverse operation we need the lhs range before rounding, so
> + conservatively use nextafter on it.
> + ??? REAL_VALUE_TYPE could handle this more precisely if we
> + make sure to not round the inputs for the format before the
> + real_operation is carried out and when we can properly round
> + towards +-Inf for the lower/upper bounds. */
> +frange wlhs (lhs);
> +if (!lhs.known_isnan ())
> + {
> + REAL_VALUE_TYPE lhsl = lhs.lower_bound ();
> + frange_nextafter (TYPE_MODE (type), lhsl, dconstninf);
> + REAL_VALUE_TYPE lhsu = lhs.upper_bound ();
> + frange_nextafter (TYPE_MODE (type), lhsu, dconstinf);
> + wlhs.set (type, lhsl, lhsu);
> + wlhs.union_ (lhs); /* Copy NaN state. */
> + }
> +return float_binary_op_range_finish (minus.fold_range (r, type, wlhs,
> op2),
> r, type, lhs);
>}
>virtual bool op2_range (frange &r, tree type,
Could we abstract this into an inline function until this could be properly
implemented in real.cc?
[Bug libstdc++/108969] [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 --- Comment #13 from Jakub Jelinek --- (In reply to Richard Biener from comment #12) > then shouldn't the > solution be that programs using streams and compiled with GCC 13 require > a symbol with a version newer than 6.0.30 (or even not present in the > oder DSOs) so the dynamic link will fail? I believe that is what we're discussing here, how to arrange that such symbols would be those mentioned in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969#c7 That solution doesn't work everywhere, because only GNU symbol versioning allows the same symbol to be exported at multiple symbol versions. So, for Solaris we can just not do anything, or come up with some other solution (like the artificial use of a symbol through asm in the header file).
[Bug tree-optimization/109008] [13 Regression] Wrong code in scipy package since r13-3926-gd4c2f1d376da6f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008 Aldy Hernandez changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #26 from Aldy Hernandez --- (In reply to Richard Biener from comment #16) > (In reply to Jakub Jelinek from comment #14) > > Created attachment 54599 [details] > > gcc13-pr109008-wip.patch > > > > I have now this WIP but it doesn't work correctly yet, need to debug it now, > > just finished writing it and making it compile. > > Note, after the binary search it is still unfinished, I'd like to then > > adjust it one bit at a time to narrow it further. But before working on > > that it needs to work correctly. > > Looks nicer and more precise (even though the iterating function is ugly > and you also suffer from the lack of copying of alternate range state, > but using .union () is a way out here I guess ;)). While working on LTO streaming of ranges, I also noticed that we don't have a way of accessing the individual NAN sign bits or a way of copying NAN state. Why don't we get this right instead of hacking around it? Would it help if we provided the following? nan_state_t irange::get_nan_state (); irange::set (tree type, const REAL_VALUE_TYPE &, const REAL_VALUE_TYPE &, const nan_state_t &, value_range_kind = VR_RANGE); We could implement nan_state_t to include the m_pos_nan and m_neg_nan for minimal disruption now, and later use it for extending the NAN information (signalling, etc).
[Bug libstdc++/108969] [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 --- Comment #12 from Richard Biener --- I wonder why this bug is relevant at all, but even if, then shouldn't the solution be that programs using streams and compiled with GCC 13 require a symbol with a version newer than 6.0.30 (or even not present in the oder DSOs) so the dynamic link will fail?
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109063
Bug ID: 109063
Summary: GCC Static Analyzer evaluates `e == &d + 1` to be
UNKNOWN with the fact that `e == &d`
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: geoffreydgr at icloud dot com
Target Milestone: ---
Hi, David. I found a problem that GCC Static Analyzer evaluates `e == &d + 1`
to be UNKNOWN with the fact that `e == &d`.
Maybe GCC Static Analyzer should have the ability to evaluates `e == &d + 1` to
be FALSE ?
See it live: https://godbolt.org/z/Wcd4T1jGa.
Input:
```c
void __analyzer_eval();
void __analyzer_describe();
void c()
{
int d = 42;
int *e = &d;
if (e == &d)
{
__analyzer_describe(0, e);
__analyzer_describe(0, &d + 1);
__analyzer_eval(e == &d + 1);
__analyzer_eval(e + 1 == &d + 1);
}
}
```
Output:
```bash
: In function 'c':
:11:9: warning: svalue: '&d'
11 | __analyzer_describe(0, e);
| ^
:12:9: warning: svalue: '(&d+(sizetype)4)'
12 | __analyzer_describe(0, &d + 1);
| ^~
:14:9: warning: UNKNOWN
14 | __analyzer_eval(e == &d + 1);
| ^~~~
:15:9: warning: TRUE
15 | __analyzer_eval(e + 1 == &d + 1);
| ^~~~
Compiler returned: 0
```
