[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647 --- Comment #22 from Khem Raj --- (In reply to Jakub Jelinek from comment #20) > How could these changes result in > ../harfbuzz-6.0.0/src/hb-map.hh:295:5: error: no match for ‘operator|’ > (operand types are ‘hb_filter_iter_t unsigned int, true>::item_t>, bool (hb_hashmap_t true>::item_t::*)() const, const&, 0>’ and > ‘hb_reduce_t::hash() > const:: true>::item_t&)>, unsigned int>’) > errors? I can see that with a cross-compiler, so VRP miscompiling the C++ > FE is not an option. argh my bad, filled in wrong tab. Sorry about this.
[Bug c++/107461] [12 Regression] ambiguity error for friend with templated constexpr argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107461 Khem Raj changed: What|Removed |Added CC||raj.khem at gmail dot com --- Comment #6 from Khem Raj --- This is now resulting in build error in harfbuzz on aarch64 which did not happen before, the testcase is here https://uclibc.org/~kraj/hb-aat-layout.cc.i Compile cmd used is /mnt/b/cross/aarch64-linux-musl/tools/bin/aarch64-linux-musl-g++ --sysroot=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/recipe-sysroot -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security -Isrc/libharfbuzz.so.0.60600.0.p -Isrc -I../harfbuzz-6.0.0/src -I. -I../harfbuzz-6.0.0 -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c++11 -fno-rtti -fno-exceptions -fno-rtti -fno-threadsafe-statics -fvisibility-inlines-hidden -DHAVE_CONFIG_H -O2 -pipe -g -feliminate-unused-debug-types -fmacro-prefix-map=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/harfbuzz-6.0.0=/usr/src/debug/harfbuzz/6.0.0-r0 -fdebug-prefix-map=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/harfbuzz-6.0.0=/usr/src/debug/harfbuzz/6.0.0-r0 -fmacro-prefix-map=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/build=/usr/src/debug/harfbuzz/6.0.0-r0 -fdebug-prefix-map=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/build=/usr/src/debug/harfbuzz/6.0.0-r0 -fdebug-prefix-map=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/recipe-sysroot= -fmacro-prefix-map=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/recipe-sysroot= -fdebug-prefix-map=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/recipe-sysroot-native= -fvisibility-inlines-hidden -fPIC -pthread -Wno-non-virtual-dtor -MD -MQ src/libharfbuzz.so.0.60600.0.p/hb-aat-layout.cc.o -MF src/libharfbuzz.so.0.60600.0.p/hb-aat-layout.cc.o.d -o src/libharfbuzz.so.0.60600.0.p/hb-aat-layout.cc.o -c ../harfbuzz-6.0.0/src/hb-aat-layout.cc
[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647 --- Comment #21 from Jakub Jelinek --- Seems it is r13-5684-g59e0376f607805ef9b67fd7b0a4a3084ab3571a5 aka PR107461 change. So, please file a separate bugreport, it has nothing to do with this PR.
[Bug tree-optimization/96963] [10 Regression] -Wstringop-overflow false positive on -O3 or -O2 -ftree-vectorize when assigning consecutive char struct members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96963
Pokechu22 changed:
What|Removed |Added
CC||pokechu022+gccbugzilla@gmai
||l.com
--- Comment #16 from Pokechu22 ---
I ran into this with Dolphin Emulator (see
https://github.com/dolphin-emu/dolphin/pull/11534), but ran into trouble trying
to simplify it. Here's what I ended up with:
```
struct Foo {
char pad[40];
char a, b;
};
struct Bar {
void Baz();
// One of these needs to be uncommented for the issue to occur
// virtual void Qux();
// int x;
Foo foo;
};
void heh(char *);
void Bar::Baz() {
heh();
foo.a = 1;
foo.b = 1;
}
```
Based on Godbolt (https://godbolt.org/z/46aTrP3vj) I can confirm that this
doesn't happen in 11.0 or 9.3/9.5, and does happen on 10.1/10.2/10.3/10.4.
[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647 --- Comment #20 from Jakub Jelinek --- How could these changes result in ../harfbuzz-6.0.0/src/hb-map.hh:295:5: error: no match for ‘operator|’ (operand types are ‘hb_filter_iter_t::item_t>, bool (hb_hashmap_t::item_t::*)() const, const&, 0>’ and ‘hb_reduce_t::hash() constitem_t&)>, unsigned int>’) errors? I can see that with a cross-compiler, so VRP miscompiling the C++ FE is not an option.
[Bug fortran/107721] Lost typespec with constant expressions using array constructors and parentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721
--- Comment #6 from Jerry DeLisle ---
I had to go back in the Standard to deepen my understanding. Yes simplifying
it would help. I think what we need to do is acknowledge that we should match
'(' and if found, recursively call the gfc_match_array_constructor and check
for the closing ')' on the other end of it.
[Bug libstdc++/94810] std::cout segmentation fault in __attribute__((constructor)) function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94810 --- Comment #12 from Murugesan Nagarajan --- Thank you for sharing comment at: >> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=4e4e3ffd10f53e Move stream initialization into compiled library I am facing my issue to have my proper environment: 01. My laptop has gone before 6 months(it was having RHEL and ubuntu) at vmplayer iso files. 02. Current acer system do not have any .iso files. 03. My working place not providing sudo access at Linux. I have verified at cygwin using g++.exe which is working fine. :) $ g++.exe --version 2>&1 | grep GCC g++ (GCC) 11.3.0 However I can verify your g++ related changes and I will update this page(in future) when I have related OS using relative admin privileges. Have a nice weekend.
[Bug libstdc++/108672] New: [13 Regression] g++.dg/modules/xtreme-header-2_a.H, _b.C, _c.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108672
Bug ID: 108672
Summary: [13 Regression] g++.dg/modules/xtreme-header-2_a.H,
_b.C, _c.C
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hp at gcc dot gnu.org
Target Milestone: ---
Target: cris-elf, pru-elf
Tl;DR: not a dup of PR98531, but a bug in libstdc++-v3. Also, a regression.
For cris-elf, these failures appeared with a commit in the range
r13-2740-gd812e8cb2a920f..r13-2748-g59f6dea963b5f7:
Build log:
Running /x/gcc/testsuite/g++.dg/modules/modules.exp ...
<...removing non-regression FAILs...>
FAIL: g++.dg/modules/xtreme-header-2_a.H -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-2_a.H module-cmi
(gcm.cache/$srcdir/g++.dg/modules/xtreme-header-2_a.H.gcm)
FAIL: g++.dg/modules/xtreme-header-2_b.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-2_c.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-2_a.H -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-2_a.H module-cmi
(gcm.cache/$srcdir/g++.dg/modules/xtreme-header-2_a.H.gcm)
FAIL: g++.dg/modules/xtreme-header-2_b.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-2_c.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-2_a.H -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-2_a.H module-cmi
(gcm.cache/$srcdir/g++.dg/modules/xtreme-header-2_a.H.gcm)
FAIL: g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-2_c.C -std=c++2b (test for excess errors)
They don't appear for {s390x, powerpc64, i686, x86_64, aarch64, arm}-linux-gnu.
They're there for pru-elf where the context looks the same as for cris-elf:
(https://gcc.gnu.org/pipermail/gcc-testresults/2023-January/775193.html).
The commit exposing the failure appears to be r13-2745-gc77f556741ded4, "c++:
xtreme-header modules tests cleanups", due to the '+#include '.
In g++.log for cris-elf, we can see that they all fail either fail
similarly as follows:
In file included from /x/gcc/libstdc++-v3/include/pstl/memory_impl.h:15,
from /x/gcc/libstdc++-v3/include/pstl/algorithm_impl.h:20,
from
/x/gccobj/cris-elf/libstdc++-v3/include/pstl/glue_execution_defs.h:50,
from /x/gccobj/cris-elf/libstdc++-v3/include/execution:34,
from /x/gcc/gcc/testsuite/g++.dg/modules/xtreme-header-2.h:4,
from
/x/gcc/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H:4:
/x/gcc/libstdc++-v3/include/pstl/unseq_backend_simd.h: In function 'bool
__pstl::__unseq_backend::__simd_or(_Index, _Di\
fferenceType, _Pred)':
/x/gcc/libstdc++-v3/include/pstl/unseq_backend_simd.h:77:9: error: 'int32_t'
was not declared in this scope
/x/gcc/libstdc++-v3/include/pstl/unseq_backend_simd.h:77:9: note: 'int32_t' is
defined in header ''; did you f\
orget to '#include '?
/x/gcc/libstdc++-v3/include/pstl/unseq_backend_simd.h:81:17: error: '__flag'
was not declared in this scope
/x/gcc/libstdc++-v3/include/pstl/unseq_backend_simd.h:82:14: error: '__flag'
was not declared in this scope
/x/gcc/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: At global scope:
/x/gcc/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: warning: not writing
module '/x/gcc/gcc/testsuite/g++.dg/modul\
es/xtreme-header-2_a.H' due to errors
compiler exited with status 1
FAIL: g++.dg/modules/xtreme-header-2_a.H -std=c++17 (test for excess errors)
Excess errors:
/x/gcc/libstdc++-v3/include/pstl/unseq_backend_simd.h:77:9: error: 'int32_t'
was not declared in this scope
/x/gcc/libstdc++-v3/include/pstl/unseq_backend_simd.h:81:17: error: '__flag'
was not declared in this scope
/x/gcc/libstdc++-v3/include/pstl/unseq_backend_simd.h:82:14: error: '__flag'
was not declared in this scope
/x/gcc/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: warning: not writing
module '/x/gcc/gcc/testsuite/g++.dg/modul\
es/xtreme-header-2_a.H' due to errors
FAIL: g++.dg/modules/xtreme-header-2_a.H module-cmi
(gcm.cache/$srcdir/g++.dg/modules/xtreme-header-2_a.H.gcm)
The error for cris-elf seems to be a "naked" use of int32_t; not having
a fitting #include: stdint.h or cstdint or inttypes.h or whatever, for
use in libstdc++-v3/include/pstl/unseq_backend_simd.h. This is not
exposed on e.g. native x86_64-pc-linux-gnu, because there, it's included
as an effect of including stdlib.h in cstdlib (follow the trace in
xtreme-header-2_a.ii with glibc-2.31-13+deb11u5). Will submit patch shortly.
[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647 Khem Raj changed: What|Removed |Added CC||raj.khem at gmail dot com --- Comment #19 from Khem Raj --- This is now resulting in build error in harfbuzz on aarch64 which did not happen before, the testcase is here https://uclibc.org/~kraj/hb-aat-layout.cc.i Compile cmd used is /mnt/b/cross/aarch64-linux-musl/tools/bin/aarch64-linux-musl-g++ --sysroot=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/recipe-sysroot -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security -Isrc/libharfbuzz.so.0.60600.0.p -Isrc -I../harfbuzz-6.0.0/src -I. -I../harfbuzz-6.0.0 -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c++11 -fno-rtti -fno-exceptions -fno-rtti -fno-threadsafe-statics -fvisibility-inlines-hidden -DHAVE_CONFIG_H -O2 -pipe -g -feliminate-unused-debug-types -fmacro-prefix-map=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/harfbuzz-6.0.0=/usr/src/debug/harfbuzz/6.0.0-r0 -fdebug-prefix-map=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/harfbuzz-6.0.0=/usr/src/debug/harfbuzz/6.0.0-r0 -fmacro-prefix-map=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/build=/usr/src/debug/harfbuzz/6.0.0-r0 -fdebug-prefix-map=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/build=/usr/src/debug/harfbuzz/6.0.0-r0 -fdebug-prefix-map=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/recipe-sysroot= -fmacro-prefix-map=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/recipe-sysroot= -fdebug-prefix-map=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/recipe-sysroot-native= -fvisibility-inlines-hidden -fPIC -pthread -Wno-non-virtual-dtor -MD -MQ src/libharfbuzz.so.0.60600.0.p/hb-aat-layout.cc.o -MF src/libharfbuzz.so.0.60600.0.p/hb-aat-layout.cc.o.d -o src/libharfbuzz.so.0.60600.0.p/hb-aat-layout.cc.o -c ../harfbuzz-6.0.0/src/hb-aat-layout.cc
[Bug c/108671] New: spurious "defined but not used" warning with static call back function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108671
Bug ID: 108671
Summary: spurious "defined but not used" warning with static
call back function
Product: gcc
Version: 9.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: galt at soe dot ucsc.edu
Target Milestone: ---
Getting an invalid "defined but not used" warning with
static call back function used in openssl. Other examples online show people
using static functions defined in the same file, so that is normal usage.
cc -O -g -std=c99 -Wall -Wformat -Wimplicit -Wreturn-type -Wuninitialized
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE -DMACHTYPE_x86_64
-DUSE_HIC -Wall -Wformat -Wimplicit -Wreturn-type -Wuninitialized -I../inc
-I../../inc -I../../../inc -I../../../../inc -I../../../../../inc -I../htslib
-I/include -I/usr/include/libpng16 -o https.o -c https.c
https.c:46:13: warning: ‘openssl_locking_callback’ defined but not used
[-Wunused-function]
46 | static void openssl_locking_callback(int mode, int n, const char *
file, int line)
| ^~~~
https.c:41:22: warning: ‘openssl_id_callback’ defined but not used
[-Wunused-function]
41 | static unsigned long openssl_id_callback(void)
| ^~~
=
#include "openssl/ssl.h"
#include "openssl/err.h"
#include
#include
#include
#include
static unsigned long openssl_id_callback(void)
{
return ((unsigned long)pthread_self());
}
static void openssl_locking_callback(int mode, int n, const char * file, int
line)
{
if (mode & CRYPTO_LOCK)
pthread_mutex_lock([n]);
else
pthread_mutex_unlock([n]);
}
void openssl_pthread_setup(void)
{
int i;
int numLocks = CRYPTO_num_locks();
AllocArray(mutexes, numLocks);
for (i = 0; i < numLocks; i++)
pthread_mutex_init([i], NULL);
CRYPTO_set_id_callback(openssl_id_callback);
CRYPTO_set_locking_callback(openssl_locking_callback);
}
void openSslInit()
/* do only once */
{
static boolean done = FALSE;
static pthread_mutex_t osiMutex = PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_lock( );
if (!done)
{
SSL_library_init();
ERR_load_crypto_strings();
ERR_load_SSL_strings();
OpenSSL_add_all_algorithms();
openssl_pthread_setup();
myDataIndex = SSL_get_ex_new_index(0, "myDataIndex", NULL, NULL, NULL);
done = TRUE;
}
pthread_mutex_unlock( );
}
So the two callback functions are not called directly,
but they are passed to openssl functions that will call
the functions later.
We have been using this same code for many years up through gcc 4.85.
Now with 4.9 we are seeing this warning for the first time.
[Bug c++/108670] New: Bogus narrowing conversion warning with designated initializers for bitfield in union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108670
Bug ID: 108670
Summary: Bogus narrowing conversion warning with designated
initializers for bitfield in union
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pokechu022+gccbugzilla at gmail dot com
Target Milestone: ---
This code (https://godbolt.org/z/4YGTfPoY9):
```
union Foo {
int x : 4;
};
union Bar {
int y : 4;
};
int foo() {
Foo foo{.x = 5};
Bar bar{.y = foo.x};
return bar.y;
}
```
Yields the following warning:
```
:9:22: warning: narrowing conversion of '(int)foo.Foo::x' from 'int' to
'signed char:4' [-Wnarrowing].
9 | Bar bar{.y = foo.x};
| ^
```
This warning does not make sense since both fields are the same size, and the
field is not a signed char. (A size of 31 will still show a warning with
int:31, while int:32 gives no warning).
Foo can be either a struct or union. Weirdly, Bar must be a union (and I
couldn't get *any* narrowing conversion warnings to occur with it as a struct,
even if the sizes don't match).
I'm pretty sure this is different from bug 106371 and bug 87292 (though the
latter seems somewhat close). Nor does it match bug 102538. Based on
godbolt.org, this bug exists in the 4.7.1, the first version to support
designated initializers (though they weren't called that then).
This was originally encountered in Dolphin Emulator (see
https://github.com/dolphin-emu/dolphin/pull/11534).
[Bug c++/108669] missing error when std::vector of incomplete type has member referenced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108669 --- Comment #3 from Luke Dalessandro --- (In reply to Jonathan Wakely from comment #2) > (In reply to Luke Dalessandro from comment #0) > > This should run afoul of the second half of > > https://eel.is/c++draft/vector#overview-4. "T shall be complete before any > > member of the resulting specialization of vector is referenced." > > > > I honestly don't know if that "shall" implies this is ill-formed or > > undefined behavior. > > The standard only defines the behaviour if T is complete, and so otherwise > it's undefined. > > In library wording we try to say explicitly when something makes the program > ill-formed. Thanks Johnathan. From that perspective this is simply a QoI diagnostic request to normalize behavior. If you want to drop the accepts-invalid tag I don’t mind.
[Bug tree-optimization/108667] Spurious "may be used uninitialized [-Wmaybe-uninitialized]" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108667 --- Comment #2 from Alvaro Begue --- Yes, this is a reduction of real code. I'm writing a signal class and I wrote a small test for it. It worked fine when compiling unoptimized, but the optimized version gave me this odd warning. Would it be interesting to see the original code? It's only around 50 lines of code.
[Bug c++/108669] missing error when std::vector of incomplete type has member referenced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108669 --- Comment #2 from Jonathan Wakely --- (In reply to Luke Dalessandro from comment #0) > This should run afoul of the second half of > https://eel.is/c++draft/vector#overview-4. "T shall be complete before any > member of the resulting specialization of vector is referenced." > > I honestly don't know if that "shall" implies this is ill-formed or > undefined behavior. The standard only defines the behaviour if T is complete, and so otherwise it's undefined. In library wording we try to say explicitly when something makes the program ill-formed.
[Bug plugins/108634] [13 regression] 'undefined symbol: tree_code_type' when building kernel GCC plugins since r13-5431-gb0241ce6e37031
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108634 --- Comment #5 from Jakub Jelinek --- https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611180.html
[Bug c++/108669] [diagnostic] missing error when std::vector of incomplete type has member referenced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108669
--- Comment #1 from Andrew Pinski ---
What I thought would be a reduced testcase is correctly rejected:
#include
struct B;
template
struct v
{
static_assert(std::is_destructible::value);
};
struct A {
v _;
};
A a{}; // <--here
struct B {};
So maybe I am missing something ...
[Bug tree-optimization/108667] Spurious "may be used uninitialized [-Wmaybe-uninitialized]" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108667 --- Comment #1 from Andrew Pinski --- This is partly caused by not inlining everything as main is marked as called once. If instead I call main, main1, the warning goes away and the following call is inlined now: std::_Function_handler >::_M_manager ([(struct function *) + 32B].D.47025._M_functor, _M_functor, 2); The warning in this case is about D.47426 which does not have any initialization before the call here. Note the call with last operand as 2 does not actually do anything and just returns. I don't know the best way to solve this specific case as it depends on inlining heurstics. Question for the reporter, was this a reduction from some real code or did you just notice the warning while testing some code?
[Bug c++/21976] Incomplete types are not detected at template definition time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21976 Andrew Pinski changed: What|Removed |Added CC||vanyacpp at gmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 59284 has been marked as a duplicate of this bug. ***
[Bug c++/59284] missing diagnostic on incomplete type at the point of template definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59284 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 21976. *** This bug has been marked as a duplicate of bug 21976 ***
[Bug c++/107079] [10/11/12/13 Regression] ICE initializing lifetime-extended constexpr variable that stores its this pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107079 --- Comment #3 from Marek Polacek --- The cxx_constant_init call actually takes decl=x so we should probably use that. value = cxx_constant_init (value, decl); However, in cxx_eval_outermost_constant_expr type is const struct X & and so we don't set up ctx.object.
[Bug c++/108669] New: [diagnostic] std::vector of incomplete type has member referenced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108669
Bug ID: 108669
Summary: [diagnostic] std::vector of incomplete type has member
referenced
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
In the following code example, I perform a value initialization of a
std::vector of incomplete type.
-
#include
struct B;
struct A {
std::vector _;
};
A a{}; // <--here
struct B {};
-
https://godbolt.org/z/ab5Erqc1n
This should run afoul of the second half of
https://eel.is/c++draft/vector#overview-4. "T shall be complete before any
member of the resulting specialization of vector is referenced."
I honestly don't know if that "shall" implies this is ill-formed or undefined
behavior. However, this test case has started to be rejected in clang-15 for
-std=C++20 code specifically, thus it would be a very helpful quality-of-life
improvement if gcc could issue a diagnostic for this problem as well.
[Bug rtl-optimization/103541] unnecessary spills around const functions calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103541 Vladimir Makarov changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #4 from Vladimir Makarov --- Honza, thank you for reporting this. Fixing just the following code will not solve the problem as LRA uses only equiv expression valid for the whole function. > ret = valid_combine; > if (!MEM_READONLY_P (memref) > && !RTL_CONST_OR_PURE_CALL_P (insn)) > return valid_none; > By the way, the old reload pass still works on the test and producing the same code as LRA currently, also reserving stack slot and using it around the call instead of reload from a. I've been working on this problem and I hope the fix will be ready on the next week.
[Bug tree-optimization/108668] [13 Regression] ICE in decompose, at wide-int.h:984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108668 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 108639. *** This bug has been marked as a duplicate of bug 108639 ***
[Bug tree-optimization/103035] [meta-bug] YARPGen bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103035 Bug 103035 depends on bug 108668, which changed state. Bug 108668 Summary: [13 Regression] ICE in decompose, at wide-int.h:984 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108668 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug tree-optimization/108639] [13 Regression] ICE on valid code at -O1 and above: in decompose, at wide-int.h:984 since r13-5578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639 Andrew Pinski changed: What|Removed |Added CC||vsevolod.livinskiy at gmail dot co ||m --- Comment #15 from Andrew Pinski --- *** Bug 108668 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/108668] New: [13 Regression] ICE in decompose, at wide-int.h:984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108668
Bug ID: 108668
Summary: [13 Regression] ICE in decompose, at wide-int.h:984
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vsevolod.livinskiy at gmail dot com
Target Milestone: ---
Link to the Compiler Explorer: https://godbolt.org/z/oY1x13Kc8
There is an open (Bug 102760) and recently closed (Bug 108547) issues with the
same assert message, but differences in reproducers, versions, and stack trace
make me suspicious that this might be a different bug.
Reproducer:
bool a;
const unsigned long long (const unsigned long long ,
const unsigned long long ) {
return c > p1 ? p1 : c;
}
char e;
unsigned long long *f;
long g;
void h() {
for (int d = 0; d < e; d = foo(8, f[0]) << foo(5, f[0]))
a = foo(1, foo(g, 7));
}
Error:
>$ g++ -O3 -c func.cpp
during GIMPLE pass: dom
func.cpp: In function 'void h()':
func.cpp:9:6: internal compiler error: in decompose, at wide-int.h:984
9 | void h() {
| ^
0x8f652a wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int > const&)
/testing/gcc/gcc_src_master/gcc/wide-int.h:984
0x8f72d6 wi::int_traits >::decompose(long*,
unsigned int, generic_wide_int const&)
/testing/gcc/gcc_src_master/gcc/value-range.h:940
0x8f72d6 wide_int_ref_storage::wide_int_ref_storage
>(generic_wide_int const&, unsigned int)
/testing/gcc/gcc_src_master/gcc/wide-int.h:1034
0x8f72d6 generic_wide_int
>::generic_wide_int
>(generic_wide_int const&, unsigned int)
/testing/gcc/gcc_src_master/gcc/wide-int.h:790
0x8f72d6 bool wi::eq_p,
generic_wide_int >(generic_wide_int const&,
generic_wide_int const&)
/testing/gcc/gcc_src_master/gcc/wide-int.h:1873
0x8f72d6 wi::binary_traits,
generic_wide_int,
wi::int_traits >::precision_type,
wi::int_traits
>::precision_type>::predicate_result
operator==,
generic_wide_int >(generic_wide_int const&,
generic_wide_int const&)
/testing/gcc/gcc_src_master/gcc/wide-int.h:3307
0x8f72d6 irange::operator==(irange const&) const
/testing/gcc/gcc_src_master/gcc/value-range.cc:1297
0x8f72d6 irange::operator==(irange const&) const
/testing/gcc/gcc_src_master/gcc/value-range.cc:1266
0x21de1d6 range_operator::fold_range(irange&, tree_node*, irange const&, irange
const&, relation_trio) const
/testing/gcc/gcc_src_master/gcc/range-op.cc:271
0x21de8cc operator_lshift::fold_range(irange&, tree_node*, irange const&,
irange const&, relation_trio) const
/testing/gcc/gcc_src_master/gcc/range-op.cc:2246
0x20c90c0 fold_using_range::range_of_range_op(vrange&,
gimple_range_op_handler&, fur_source&)
/testing/gcc/gcc_src_master/gcc/gimple-range-fold.cc:589
0x20c fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
/testing/gcc/gcc_src_master/gcc/gimple-range-fold.cc:489
0x20bbefc gimple_ranger::fold_range_internal(vrange&, gimple*, tree_node*)
/testing/gcc/gcc_src_master/gcc/gimple-range.cc:257
0x20bbefc gimple_ranger::range_of_stmt(vrange&, gimple*, tree_node*)
/testing/gcc/gcc_src_master/gcc/gimple-range.cc:318
0x20bdcd0 gimple_ranger::range_of_expr(vrange&, tree_node*, gimple*)
/testing/gcc/gcc_src_master/gcc/gimple-range.cc:126
0x13914bf cprop_operand
/testing/gcc/gcc_src_master/gcc/tree-ssa-dom.cc:1972
0x1393371 cprop_into_stmt
/testing/gcc/gcc_src_master/gcc/tree-ssa-dom.cc:2049
0x1393371 dom_opt_dom_walker::optimize_stmt(basic_block_def*,
gimple_stmt_iterator*, bool*)
/testing/gcc/gcc_src_master/gcc/tree-ssa-dom.cc:2277
0x1394723 dom_opt_dom_walker::before_dom_children(basic_block_def*)
/testing/gcc/gcc_src_master/gcc/tree-ssa-dom.cc:1682
0x2087717 dom_walker::walk(basic_block_def*)
/testing/gcc/gcc_src_master/gcc/domwalk.cc:311
gcc version 13.0.1 20230203 (093e2e1b201c0f324e0d8bfe6487aa2d470a13e7)
[Bug target/108659] Suboptimal 128 bit atomics codegen on AArch64 and x64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659 --- Comment #11 from Wilco --- (In reply to Niall Douglas from comment #10) > (In reply to Jakub Jelinek from comment #9) > > (In reply to Wilco from comment #8) > > > Yes that sounds like a reasonable approach. > > > > I don't think so. Not all variables on which __atomic_* intrinsics are used > > are actually _Atomic, the vars can be embedded in const aggregates etc. > > I'd have the attribute propagate to enclosing types, like over-alignment. Yes, a structure with a 128-bit Atomic type in a subfield/union would be forced to rwdata. And arbitrary casts (eg. from char* to an atomic type) wouldn't work due to Atomics requiring strict alignment. A 128-bit atomic type might have a higher alignment than a 128-bit integer so even casting that seems questionable.
[Bug target/108659] Suboptimal 128 bit atomics codegen on AArch64 and x64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659 --- Comment #10 from Niall Douglas --- (In reply to Jakub Jelinek from comment #9) > (In reply to Wilco from comment #8) > > Yes that sounds like a reasonable approach. > > I don't think so. Not all variables on which __atomic_* intrinsics are used > are actually _Atomic, the vars can be embedded in const aggregates etc. I'd have the attribute propagate to enclosing types, like over-alignment.
[Bug libstdc++/94810] std::cout segmentation fault in __attribute__((constructor)) function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94810 --- Comment #11 from Murugesan Nagarajan --- Hi Andrew, Thank you for your comment. I'll check this after 09:00 AM. Regards, N.Murugesan Google: murugesan openssl
[Bug c++/108667] New: Spurious "maybe used uninitialized [-Wmaybe-uninitialized]" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108667
Bug ID: 108667
Summary: Spurious "maybe used uninitialized
[-Wmaybe-uninitialized]" warning
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alvaro.begue at gmail dot com
Target Milestone: ---
I am using g++-12.1.0 on x86-64, but g++-12.2.0 in godbolt.org shows the same
problem
The options are -O3 -Wmaybe-uninitialized .
The code:
#include
struct S {
S(std::function f) : f(f) {}
std::function g;
std::function f;
};
int main() {
S s([](){});
s.f();
}
Compiler output (from godbolt.org):
In file included from
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/functional:59,
from :1:
In copy constructor 'std::function<_Res(_ArgTypes ...)>::function(const
std::function<_Res(_ArgTypes ...)>&) [with _Res = void; _ArgTypes = {}]',
inlined from 'S::S(std::function)' at :4:34,
inlined from 'int main()' at :11:15:
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/std_function.h:391:17:
warning: '' may be used uninitialized [-Wmaybe-uninitialized]
391 | __x._M_manager(_M_functor, __x._M_functor,
__clone_functor);
| ^~
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/std_function.h: In
function 'int main()':
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/std_function.h:267:7:
note: by argument 2 of type 'const std::_Any_data&' to 'static bool
std::_Function_handler<_Res(_ArgTypes ...),
_Functor>::_M_manager(std::_Any_data&, const std::_Any_data&,
std::_Manager_operation) [with _Res = void; _Functor = main()::;
_ArgTypes = {}]' declared here
267 | _M_manager(_Any_data& __dest, const _Any_data& __source,
| ^~
:11:15: note: '' declared here
11 | S s([](){});
| ^
Compiler returned: 0
[Bug analyzer/108666] New: -Wanalyzer-use-of-uninitialized-value false positives seen in coreutils's sum.c: bsd_sum_stream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108666 Bug ID: 108666 Summary: -Wanalyzer-use-of-uninitialized-value false positives seen in coreutils's sum.c: bsd_sum_stream Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- Created attachment 54408 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54408=edit Reproducer Trunk emits false positives: https://godbolt.org/z/coeesxxP4 Similar to bug 108664, but also emits: :90:3: warning: use of uninitialized value '*(unsigned int *)' [CWE-457] [-Wanalyzer-use-of-uninitialized-value] 90 | memcpy(resstream, , sizeof checksum); | ^ despite this initialization: int checksum = 0;
[Bug target/108659] Suboptimal 128 bit atomics codegen on AArch64 and x64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659 --- Comment #9 from Jakub Jelinek --- (In reply to Wilco from comment #8) > Yes that sounds like a reasonable approach. I don't think so. Not all variables on which __atomic_* intrinsics are used are actually _Atomic, the vars can be embedded in const aggregates etc.
[Bug target/108659] Suboptimal 128 bit atomics codegen on AArch64 and x64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659 --- Comment #8 from Wilco --- (In reply to Niall Douglas from comment #7) > (In reply to Andrew Pinski from comment #4) > > (In reply to Niall Douglas from comment #3) > > > You may be interested in reading https://reviews.llvm.org/D110069. It > > > wanted > > > to have LLVM generate a 128 bit AArch64 CAS for atomics. LLVM merged that > > > change, it'll be in the next release. > > > > Using CAS for atomic load is not valid thing to do ... > > Because atomic load from constant rodata needs to work. > > LLVM breaks this case as they don't care about it. GCC does though. > > I've heard that argument before, and I've always wondered why _Atomic128 > types couldn't have an attribute which applies attribute section to their > static const variable incarnations to force them into r/w memory. That would > also solve the LLVM issue. Said attribute is not unuseful in general > actually, it would help avoid having to mess with mprotect to apply copy on > write perms on regions in .rodata when you need to modify static const > variable values. > > I don't think that the standard *guarantees* that static const variables go > into read only memory, and besides, before C23 128 bit integers weren't > supported anyway so one could argue as a proprietary extension (__int128) > you get proprietary special casing. Yes that sounds like a reasonable approach. There will language lawyers that say it must also work on mmap after mprotect of course, but that seems even more unlikely in the real world... I believe that the vast majority of developers just want 128-bit atomics to work efficiently without locks when possible. Currently various packages are forced to create 128-bit atomics using inline assembler - and that seems a much worse hack than supporting lock-free atomics in the compiler.
[Bug fortran/108665] New: Depenency checking: Run-time loop reversal instead of creating a temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108665 Bug ID: 108665 Summary: Depenency checking: Run-time loop reversal instead of creating a temporary Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- In the Fortran front end, we could sometimes reverse loops at runtime if dependency analysis shows that either a forward or a backward loop would have no dependencies. Example code: module x implicit none contains subroutine foo(a,i,j,n) integer, intent(in) :: i, j, n real, dimension(:), intent(inout) :: a a(i:i+n-1) = a(j:j+n-1) + 10. end subroutine foo subroutine bar(a,i,j,n) real, dimension(:), intent(inout) :: a integer,intent(in) :: i, j, n integer :: k if (i <= j) then do k=0, n-1, 1 a(i+k) = a(j+k) + 10. end do else do k=n-1,0,-1 a(i+k) = a(j+k) + 10. end do end if end subroutine bar end module x where we create a temporary in foo.
[Bug fortran/108663] Accepts invalid bug with pdtXXX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108663 --- Comment #1 from Steve Kargl --- > $ gfortran-13-20221218 -c z1.f90 # missing error > $ > $ gfortran-13-20230115 -c z1.f90 > z1.f90:12:7: > >12 |use m, only: t, pdtt, s > | 1 > internal compiler error: in check_complete_insertion, at hash-table.h:578 For the record, the entity 'pdtt' is not specified in the module. It is constructed by gfortran in decl.cc(gfc_get_pdt_instance) when parsing a parameterized derived type. The symbol pdtt means PDT type t, and it appears to inserted into the namespace. A likely better name would have been _PDT_t, because the leading underscore means the name cannot conflict with a user's code and gfortran downcases all parsed code so PDT shows that the symbol is artificial.
[Bug analyzer/108664] New: -Wanalyzer-use-of-uninitialized-value false positive seen in coreutils's cksum.c: cksum_slice8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108664
Bug ID: 108664
Summary: -Wanalyzer-use-of-uninitialized-value false positive
seen in coreutils's cksum.c: cksum_slice8
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Created attachment 54407
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54407=edit
Reproducer
Trunk emits false postives:
https://godbolt.org/z/9Mjcr3j1W
in which the analyzer doesn't seem to grok that fread_unlocked will have
initialized part of the buffer when the return value is checked.
: In function 'cksum_slice8':
:58:16: warning: use of uninitialized value '*datap_52' [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
58 | uint32_t first = *datap++, second = *datap++;
|^
'cksum_slice8': events 1-2
|
| 33 | uint32_t buf[(1 << 16) / sizeof(uint32_t)];
| |^~~
| ||
| |(1) region created on stack here
|..
| 38 | if (!fp || !crc_out || !length_out)
| | ~
| | |
| | (2) following 'false' branch...
|
'cksum_slice8': event 3
|
|cc1:
| (3): ...to here
|
'cksum_slice8': events 4-12
|
| 41 | while ((bytes_read = fread_unlocked(buf, 1, (1 << 16), fp)) > 0)
{
| | ~^~~
| | |
| | (4)
following 'true' branch (when 'bytes_read != 0')...
|..
| 44 | if (length + bytes_read < length) {
| |
| || |
| || (5) ...to here
| |(6) following 'false' branch...
|..
| 49 | length += bytes_read;
| |
| ||
| |(7) ...to here
| 50 |
| 51 | if (bytes_read == 0) {
| |~
| ||
| |(8) following 'false' branch (when 'bytes_read != 0')...
|..
| 56 | datap = (uint32_t*)buf;
| | ~~
| | |
| | (9) ...to here
| 57 | while (bytes_read >= 8) {
| |~~~
| | |
| | (10) following 'true' branch (when
'bytes_read > 7')...
| 58 | uint32_t first = *datap++, second = *datap++;
| |~~~~
| || |
| || (11) ...to here
| |(12) use of uninitialized value '*datap_52' here
|
:58:34: warning: use of uninitialized value '*datap_77' [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
58 | uint32_t first = *datap++, second = *datap++;
| ^~
'cksum_slice8': events 1-2
|
| 33 | uint32_t buf[(1 << 16) / sizeof(uint32_t)];
| |^~~
| ||
| |(1) region created on stack here
|..
| 38 | if (!fp || !crc_out || !length_out)
| | ~
| | |
| | (2) following 'false' branch...
|
'cksum_slice8': event 3
|
|cc1:
| (3): ...to here
|
'cksum_slice8': events 4-12
|
| 41 | while ((bytes_read = fread_unlocked(buf, 1, (1 << 16), fp)) > 0)
{
| | ~^~~
| | |
| | (4)
following 'true' branch (when 'bytes_read != 0')...
|..
| 44 | if (length + bytes_read < length) {
| |
| || |
| || (5) ...to here
| |(6) following 'false' branch...
|..
| 49 | length += bytes_read;
| |
| ||
| |(7) ...to here
| 50 |
| 51 | if (bytes_read == 0) {
| |~
| ||
[Bug target/108659] Suboptimal 128 bit atomics codegen on AArch64 and x64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659 --- Comment #7 from Niall Douglas --- (In reply to Andrew Pinski from comment #4) > (In reply to Niall Douglas from comment #3) > > You may be interested in reading https://reviews.llvm.org/D110069. It wanted > > to have LLVM generate a 128 bit AArch64 CAS for atomics. LLVM merged that > > change, it'll be in the next release. > > Using CAS for atomic load is not valid thing to do ... > Because atomic load from constant rodata needs to work. > LLVM breaks this case as they don't care about it. GCC does though. I've heard that argument before, and I've always wondered why _Atomic128 types couldn't have an attribute which applies attribute section to their static const variable incarnations to force them into r/w memory. That would also solve the LLVM issue. Said attribute is not unuseful in general actually, it would help avoid having to mess with mprotect to apply copy on write perms on regions in .rodata when you need to modify static const variable values. I don't think that the standard *guarantees* that static const variables go into read only memory, and besides, before C23 128 bit integers weren't supported anyway so one could argue as a proprietary extension (__int128) you get proprietary special casing. Niall
[Bug target/108659] Suboptimal 128 bit atomics codegen on AArch64 and x64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659 --- Comment #6 from Andrew Pinski --- (In reply to Wilco from comment #5) > To me a far worse issue is that this difference for 128-bit atomics means > that LLVM and GCC are binary incompatible. AFAIK isn't an option to make > them compatible either (on AArch64 GCC13 will use a compatible sequence only > if LSE2 is available). Right and that would mean LLVM is broken for valid C code. And breaks the binary compatibility with GCC rather than the other way around. This is not the first time LLVM has chosen to break things with respect to binary compatibility with GCC (x86_64 argument passing for an example).
[Bug target/108659] Suboptimal 128 bit atomics codegen on AArch64 and x64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659 Wilco changed: What|Removed |Added CC||wilco at gcc dot gnu.org --- Comment #5 from Wilco --- (In reply to Andrew Pinski from comment #4) > (In reply to Niall Douglas from comment #3) > > You may be interested in reading https://reviews.llvm.org/D110069. It wanted > > to have LLVM generate a 128 bit AArch64 CAS for atomics. LLVM merged that > > change, it'll be in the next release. > > Using CAS for atomic load is not valid thing to do ... > Because atomic load from constant rodata needs to work. > LLVM breaks this case as they don't care about it. GCC does though. The question is how useful is this in reality? If memory is not writeable then you can use atomic loads but no other atomic accesses. We could be pragmatic and say that using 128-bit atomic loads from non-writeable memory is a user error just like unaligned atomic accesses. To me a far worse issue is that this difference for 128-bit atomics means that LLVM and GCC are binary incompatible. AFAIK isn't an option to make them compatible either (on AArch64 GCC13 will use a compatible sequence only if LSE2 is available).
[Bug c++/107079] [10/11/12/13 Regression] ICE initializing lifetime-extended constexpr variable that stores its this pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107079
--- Comment #2 from Marek Polacek ---
Very interesting. We're in store_init_value, initializing x with
_EXPR }>
but we must lifetime-extend via extend_ref_init_temps and we get
_ZGR1x_.x = (const struct X *) & >>>;, (const struct
X &) &_ZGR1x_;
Since x was declared constexpr, we do cxx_constant_init (not quiet) and we hit
the code added in r269003:
+ bool preeval = SCALAR_TYPE_P (type) || TREE_CODE (t) == MODIFY_EXPR;
+ if (preeval)
+{
+ /* Evaluate the value to be stored without knowing what object it will
be
+stored in, so that any side-effects happen first. */
+ if (!SCALAR_TYPE_P (type))
+ new_ctx.ctor = new_ctx.object = NULL_TREE;
+ init = cxx_eval_constant_expression (_ctx, init, false,
+ non_constant_p, overflow_p);
while evaluating the INIT_EXPR _ZGR1x_.x = (const struct X *)
& >>>. But we have no ctx.ctor or ctx.object here
so lookup_placeholder won't find anything and we ICE on
7861 /* A placeholder without a referent. We can get here when
7862 checking whether NSDMIs are noexcept, or in massage_init_elt;
7863 just say it's non-constant for now. */
7864 gcc_assert (ctx->quiet);
Somehow we should manage that the PLACEHOLDER_EXPR is replaced with _ZGR1x_ I
guess.
[Bug tree-optimization/108639] [13 Regression] ICE on valid code at -O1 and above: in decompose, at wide-int.h:984 since r13-5578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/103035] [meta-bug] YARPGen bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103035 Bug 103035 depends on bug 108647, which changed state. Bug 108647 Summary: [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #18 from Jakub Jelinek --- Should be fixed now.
[Bug fortran/108663] New: Accepts invalid bug with pdtXXX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108663 Bug ID: 108663 Summary: Accepts invalid bug with pdtXXX Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: accepts-invalid, ice-on-invalid-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org CC: aoliva at gcc dot gnu.org, gs...@t-online.de, jakub at gcc dot gnu.org, kargl at gcc dot gnu.org, marxin at gcc dot gnu.org, unassigned at gcc dot gnu.org Depends on: 108451 Target Milestone: --- The PR108451 testcase is accepted even when it should be rejected. +++ This bug was initially created as a clone of Bug #108451 +++ Started recently between 20221218 and 20230108, with special name pdtt : (gcc configured with --enable-checking=yes) $ cat z1.f90 module m type t(n) integer, len :: n integer :: a(n) end type contains subroutine s(x) type(t(2)) :: x end end program p use m, only: t, pdtt, s type(t(2)) :: y call s(y) end $ gfortran-13-20221218 -c z1.f90 # missing error $ $ gfortran-13-20230115 -c z1.f90 z1.f90:12:7: 12 |use m, only: t, pdtt, s | 1 internal compiler error: in check_complete_insertion, at hash-table.h:578 0x92fc0b hash_table::check_complete_insertion() const ../../gcc/hash-table.h:578 0x92fc0b hash_table::find_slot_with_hash(char const* const&, unsigned int, insert_option) ../../gcc/hash-table.h:1042 0x92c57e gfc_trans_use_stmts ../../gcc/fortran/trans-decl.cc:5329 0x92d3a6 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:7837 0x89ef8e translate_all_program_units ../../gcc/fortran/parse.cc:6721 0x89ef8e gfc_parse_file() ../../gcc/fortran/parse.cc:7027 0x8ed3af gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:229 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451 [Bug 108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
[Bug fortran/108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- The regression (ICE) is now fixed.
[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647 --- Comment #17 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e753080ab8abd4021381699bc7e857f5b4a083c4 commit r13-5698-ge753080ab8abd4021381699bc7e857f5b4a083c4 Author: Jakub Jelinek Date: Fri Feb 3 21:39:16 2023 +0100 range-op: Handle op?.undefined_p () in op[12]_range of comparisons [PR108647] As mentioned in the PR, we ICE because lhs is singleton [0, 0] or [1, 1] but op2 (or in other cases op1) is undefined and op?.*_bound () ICEs on those because there are no pairs for UNDEFINED. The following patch makes us set r to varying or return false in those cases. 2023-02-03 Jakub Jelinek PR tree-optimization/108647 * range-op.cc (operator_equal::op1_range, operator_not_equal::op1_range): Don't test op2 bound equality if op2.undefined_p (), instead set_varying. (operator_lt::op1_range, operator_le::op1_range, operator_gt::op1_range, operator_ge::op1_range): Return false if op2.undefined_p (). (operator_lt::op2_range, operator_le::op2_range, operator_gt::op2_range, operator_ge::op2_range): Return false if op1.undefined_p (). * g++.dg/torture/pr108647.C: New test.
[Bug fortran/108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:76f7f0eddcb7c418d1ec3dea3e2341ca99097301 commit r13-5697-g76f7f0eddcb7c418d1ec3dea3e2341ca99097301 Author: Jakub Jelinek Date: Fri Feb 3 21:37:27 2023 +0100 fortran: Fix up hash table usage in gfc_trans_use_stmts [PR108451] The first testcase in the PR (which I haven't included in the patch because it is unclear to me if it is supposed to be valid or not) ICEs since extra hash table checking has been added recently. The problem is that gfc_trans_use_stmts does tree *slot = entry->decls->find_slot_with_hash (rent->use_name, hash, INSERT); if (*slot == NULL) and later on doesn't store anything into *slot and continues. Another spot a few lines later correctly clears the slot if it decides not to use the slot, so the following patch does the same. 2023-02-03 Jakub Jelinek PR fortran/108451 * trans-decl.cc (gfc_trans_use_stmts): Call clear_slot before doing continue.
[Bug tree-optimization/108639] [13 Regression] ICE on valid code at -O1 and above: in decompose, at wide-int.h:984 since r13-5578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639 --- Comment #13 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:e261fcefb71e1270673f0457fcc73711f13d3079 commit r13-5696-ge261fcefb71e1270673f0457fcc73711f13d3079 Author: Aldy Hernandez Date: Thu Feb 2 18:08:44 2023 +0100 irange: Compare nonzero bits in irange with widest_int [PR108639] The problem here is we are trying to compare two ranges with different precisions and the == operator in wide_int is complaining. Interestingly, the problem is not the nonzero bits, but the fact that the entire ranges have different precisions. The reason we don't ICE when comparing the sub-ranges, is because the code in irange::operator== works on trees, and tree_int_cst_equal is promoting the comparison to a widest int: if (TREE_CODE (t1) == INTEGER_CST && TREE_CODE (t2) == INTEGER_CST && wi::to_widest (t1) == wi::to_widest (t2)) return 1; This is why we don't see the ICE until the nonzero bits comparison is done on wide ints. I think we should maintain the current equality behavior, and follow suit in the nonzero bit comparison. I have also fixed the legacy equality code, even though technically nonzero bits shouldn't appear in legacy. But better safe than sorry. PR tree-optimization/108639 gcc/ChangeLog: * value-range.cc (irange::legacy_equal_p): Compare nonzero bits as widest_int. (irange::operator==): Same.
[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647 --- Comment #16 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:10bd26d6efe88a8cf03a6a325351bc470a910cab commit r13-5695-g10bd26d6efe88a8cf03a6a325351bc470a910cab Author: Aldy Hernandez Date: Fri Feb 3 17:28:52 2023 +0100 range-ops: Handle undefined ranges in frange op[12]_range [PR108647] This patch gracefully handles undefined operand ranges for the floating point op[12]_range operators. This is very low risk, as we would have ICEd otherwise. We don't have a testcase that ICEs for floating point ranges, but it's only a matter of time. Besides, this dovetails nicely with the integer versions Jakub is testing. gcc/ChangeLog: PR tree-optimization/108647 * range-op-float.cc (foperator_lt::op1_range): Handle undefined ranges. (foperator_lt::op2_range): Same. (foperator_le::op1_range): Same. (foperator_le::op2_range): Same. (foperator_gt::op1_range): Same. (foperator_gt::op2_range): Same. (foperator_ge::op1_range): Same. (foperator_ge::op2_range): Same. (foperator_unordered_lt::op1_range): Same. (foperator_unordered_lt::op2_range): Same. (foperator_unordered_le::op1_range): Same. (foperator_unordered_le::op2_range): Same. (foperator_unordered_gt::op1_range): Same. (foperator_unordered_gt::op2_range): Same. (foperator_unordered_ge::op1_range): Same. (foperator_unordered_ge::op2_range): Same.
[Bug other/108662] New: Cast between incompatible function types in libiberty/physmem.c under MinGW-W64/MSYS2 on Windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108662
Bug ID: 108662
Summary: Cast between incompatible function types in
libiberty/physmem.c under MinGW-W64/MSYS2 on Windows
10
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: internal-improvement
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: jdx at o2 dot pl
Target Milestone: ---
Host: x86_64-w64-mingw32
Build: x86_64-w64-mingw32
The following warning appears when gcc is build under MinGW-W64/MSYS2:
gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../../gcc/libiberty/../include -W
-Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -Wshadow=local -pedantic
-D_GNU_SOURCE ../../../gcc/libiberty/physmem.c -o physmem.o
../../../gcc/libiberty/physmem.c: In function 'physmem_total':
../../../gcc/libiberty/physmem.c:161:18: warning: cast between incompatible
function types from 'FARPROC' {aka 'long long int (*)()'} to 'WINBOOL
(*)(lMEMORYSTATUSEX *)' {aka 'int (*)(lMEMORYSTATUSEX *)'}
[-Wcast-function-type]
161 | if ((pfnex = (PFN_MS_EX) GetProcAddress (h,
"GlobalMemoryStatusEx")))
| ^
../../../gcc/libiberty/physmem.c: In function 'physmem_available':
../../../gcc/libiberty/physmem.c:262:18: warning: cast between incompatible
function types from 'FARPROC' {aka 'long long int (*)()'} to 'WINBOOL
(*)(lMEMORYSTATUSEX *)' {aka 'int (*)(lMEMORYSTATUSEX *)'}
[-Wcast-function-type]
262 | if ((pfnex = (PFN_MS_EX) GetProcAddress (h,
"GlobalMemoryStatusEx")))
| ^
The offending code was added in 2003
(https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=ed935c35314a6fe3b0c699bf642c704655873d49)
and has survived virtually without changes until this day. Perhaps 20 years
later it is time to clean the code – remove definitions of lMEMORYSTATUSEX and
PFN_MS_EX at the top, remove calls to GlobalMemoryStatus (which is pretty much
useless these days) and call GlobalMemoryStatusEx directly.
[Bug fortran/89925] [10/11/12/13 Regression] Wrong array bounds from ALLOCATE with SOURCE or MOLD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89925 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #11 from kargl at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #10) > I think that could be the commit > r12-5767-g6262e3a22b3d86afc116480bc59a7bb30b0cfd40 > "fortran: Fix setting of array lower bound for named arrays" > > but I have not checked more deeply. I can confirm that your patch in r12-5767-yada-yada fixed this bug. Your patch included two testcases. Do you think that Neil's code should be converted to a new testcase or do your testcases cover this issue. Neil, sorry it took so long to get a fix.
[Bug libstdc++/39796] cin/cout/cerr constructors should run at high priority when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39796 Andrew Pinski changed: What|Removed |Added CC||vhaisman at gmail dot com --- Comment #6 from Andrew Pinski --- *** Bug 62200 has been marked as a duplicate of this bug. ***
[Bug libstdc++/62200] libstdc++ initialization priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62200 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 39796. *** This bug has been marked as a duplicate of bug 39796 ***
[Bug libstdc++/94810] std::cout segmentation fault in __attribute__((constructor)) function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94810 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=39796, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=98108, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=44952 --- Comment #10 from Andrew Pinski --- Note in GCC 13+, this should work now after r13-3707-g4e4e3ffd10f53e .
[Bug tree-optimization/107570] [13 Regression] ICE: Segmentation fault (in instantiate_scev_name/gimple_bb) since r13-3595-g7b1cdca6d6d594a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107570 Andrew Macleod changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Andrew Macleod --- Fixed.
[Bug tree-optimization/107570] [13 Regression] ICE: Segmentation fault (in instantiate_scev_name/gimple_bb) since r13-3595-g7b1cdca6d6d594a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107570 --- Comment #5 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:093e2e1b201c0f324e0d8bfe6487aa2d470a13e7 commit r13-5694-g093e2e1b201c0f324e0d8bfe6487aa2d470a13e7 Author: Andrew MacLeod Date: Wed Feb 1 11:46:18 2023 -0500 Reset SCEV before removing unreachable globals. SCEV should be reset in VRP before trying to remove unreachable globals to avoid triggering issues with it's cache. PR tree-optimization/107570 gcc/ * tree-vrp.cc (remove_and_update_globals): Reset SCEV. gcc/testsuite/ * gcc.dg/pr107570.c: New.
[Bug libstdc++/94810] std::cout segmentation fault in __attribute__((constructor)) function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94810 --- Comment #9 from Murugesan Nagarajan --- I'll update my comment today(Sat 04-Feb-2023 IST) after 09:00 AM IST. Right now I'm facing network issue due to travelling.
[Bug c++/108158] [11/12 Regression] modification of '...' is not a constant expression since r12-2304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108158 Marek Polacek changed: What|Removed |Added Summary|[11/12/13 Regression] |[11/12 Regression] |modification of '...' is|modification of '...' is |not a constant expression |not a constant expression |since r12-2304 |since r12-2304 --- Comment #7 from Marek Polacek --- Fixed on trunk so far.
[Bug c++/108158] [11/12/13 Regression] modification of '...' is not a constant expression since r12-2304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108158 --- Comment #6 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:27ac6a707e7438c3cec79c24f5d53de79493e2f8 commit r13-5693-g27ac6a707e7438c3cec79c24f5d53de79493e2f8 Author: Marek Polacek Date: Mon Jan 30 09:02:00 2023 -0500 c++: wrong error with constexpr array and value-init [PR108158] In this test case, we find ourselves evaluating 't' which is ((const struct carray *) this)->data_[VIEW_CONVERT_EXPR(index)] in cxx_eval_array_reference. ctx->object is non-null, a RESULT_DECL, so we replace it with 't': new_ctx.object = t; // result_decl replaced and then we go to cxx_eval_constant_expression to evaluate an AGGR_INIT_EXPR, where we end up evaluating an INIT_EXPR (which is in the body of the constructor for seed_or_index): ((struct seed_or_index *) this)->value_ = NON_LVALUE_EXPR <0> whereupon in cxx_eval_store_expression we go to the probe loop where the 'this' is evaluated to ze_set.tables_.first_table_.data_[0] so the 'object' is ze_set, but that isn't in ctx->global->get_value_ptr so we fail with a bogus error. ze_set is not there because it comes from a different constexpr context (it's not in cv_cache either). The problem started with r12-2304 where I added the new_ctx.object replacement. That was to prevent a type mismatch: the type of 't' and ctx.object were different. It seems clear that we shouldn't have replaced ctx.object here. The cxx_eval_array_reference I mentioned earlier is called from cxx_eval_store_expression: 6257 init = cxx_eval_constant_expression (_ctx, init, vc_prvalue, 6258non_constant_p, overflow_p); which already created a new context, whose .object we should be using unless, for instance, INIT contained a.b and we're evaluating the 'a' part, which I think was the case for r12-2304; in that case ctx.object has to be something different. It no longer seems necessary to replace new_ctx.object (likely due to changes in empty class handling). PR c++/108158 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_array_reference): Don't replace new_ctx.object. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/constexpr-108158.C: New test.
[Bug c++/101071] [10/11/12/13 Regression] ICE in gimplify_init_constructor, at gimplify.c:5228
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101071 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Marek Polacek --- Fixed. Doesn't look important to (try to) backport.
[Bug c++/101071] [10/11/12/13 Regression] ICE in gimplify_init_constructor, at gimplify.c:5228
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101071 --- Comment #6 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:60fca1802a25034f49fa1e3769b3a5656f392e89 commit r13-5692-g60fca1802a25034f49fa1e3769b3a5656f392e89 Author: Marek Polacek Date: Fri Feb 3 13:45:10 2023 -0500 c++: Add fixed test [PR101071] As a happy accident, this was fixed by the recent r13-2978. PR c++/101071 gcc/testsuite/ChangeLog: * g++.dg/cpp0x/variadic-alias8.C: New test.
[Bug middle-end/108657] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657 --- Comment #4 from Andrew Pinski --- (In reply to David Binderman from comment #3) > (In reply to Andrew Pinski from comment #2) > > If I initialize __trans_tmp_13 explictly to 0, the issue goes away > > $ fgrep trans_tmp_13 bug880.c >int64_t __trans_tmp_13; >(g_452) ^= (__trans_tmp_13); > $ > > This now looks like a bug in csmith. It might be both. I have not looked into the IR differences with respect of initializing and not initializing it and using/not using -ftrivial-auto-var-init=zero yet. This was mostly to give a hint to the next person who looks into this issue to see if they understand why there is a difference happening. -ftrivial-auto-var-init=zero should produce the similar results to initializing that variable to 0 but it is not. There has been some bugs (in GCC) recently in the area of not executed pathes with uninitialized variables changing the behavior (incorrectly) so it might be related to one of those ...
[Bug fortran/108651] Array Constructor with [type-spec:: fails to apply to all values, eg x = [integer(int64):: 1,2,3,4]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108651 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #5 from anlauf at gcc dot gnu.org --- (In reply to kargl from comment #2) > 5 | INTEGER(INT64), dimension(2), parameter:: arr1 = [integer(int64):: > -3300711175878204139, 8258803693257250632] > | > 1 > Error: Integer too big for its kind at (1). This check can be disabled with > the option '-fno-range-check' > > This is the correct behavior. -3300711175878204139 and 8258803693257250632 > are default integer kind, which is 32 bit and both numbers are outside the > range of [-huge(1)-1:huge(1)]. Indeed, and this is confirmed by other compilers, which either give an error (e.g. Nvidia) or at least a warning (Intel) in standard conformance mode. This PR should have been closed as invalid.
[Bug middle-end/108657] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657 --- Comment #3 from David Binderman --- (In reply to Andrew Pinski from comment #2) > If I initialize __trans_tmp_13 explictly to 0, the issue goes away $ fgrep trans_tmp_13 bug880.c int64_t __trans_tmp_13; (g_452) ^= (__trans_tmp_13); $ This now looks like a bug in csmith.
[Bug gcov-profile/108658] [GCOV] Function entry is not recorded in a function containing an infinite loop from another thread depending on the optimization level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108658
Sebastian Huber changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED|UNCONFIRMED
--- Comment #4 from Sebastian Huber ---
What is interesting is that -g changes the behaviour. I guess there is an error
in the mapping of the profiling counter to the associated source code lines.
gcc-12 -O2 --coverage -c main.c -g
rm -f *.gc??
gcc-12 -pthread -fprofile-update=atomic -O2 --coverage -c idle.c -g
gcc-12 -pthread --coverage main.o idle.o
./a.out
gcov-12 idle.c
File 'idle.c'
Lines executed:66.67% of 3
Creating 'idle.c.gcov'
Lines executed:66.67% of 3
cat idle.c.gcov
-:0:Source:idle.c
-:0:Graph:idle.gcno
-:0:Data:idle.gcda
-:0:Runs:1
#:1:void *idle(void *ignored)
-:2:{
213413784:3: while (1) {
-:4:/* Do nothing */
213413784:5: }
-:6:
-:7: return 0;
-:8:}
rm -f *.gc??
gcc-12 -pthread -fprofile-update=atomic -Og --coverage -c idle.c -g
gcc-12 -pthread --coverage main.o idle.o
./a.out
gcov-12 idle.c
File 'idle.c'
Lines executed:66.67% of 3
Creating 'idle.c.gcov'
Lines executed:66.67% of 3
cat idle.c.gcov
-:0:Source:idle.c
-:0:Graph:idle.gcno
-:0:Data:idle.gcda
-:0:Runs:1
#:1:void *idle(void *ignored)
-:2:{
214569562:3: while (1) {
-:4:/* Do nothing */
214569562:5: }
-:6:
-:7: return 0;
-:8:}
rm -f *.gc??
gcc-12 -pthread -fprofile-update=atomic -O0 --coverage -c idle.c -g
gcc-12 -pthread --coverage main.o idle.o
./a.out
gcov-12 idle.c
File 'idle.c'
Lines executed:100.00% of 2
Creating 'idle.c.gcov'
Lines executed:100.00% of 2
cat idle.c.gcov
-:0:Source:idle.c
-:0:Graph:idle.gcno
-:0:Data:idle.gcda
-:0:Runs:1
214896204:1:void *idle(void *ignored)
-:2:{
214896204:3: while (1) {
-:4:/* Do nothing */
-:5: }
-:6:
-:7: return 0;
-:8:}
[Bug analyzer/108661] [13 Regression] -Wanalyzer-use-of-uninitialized-value false positive seen in haproxy's sink_rotate_file_backed_ring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108661 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-02-03 Ever confirmed|0 |1 Summary|-Wanalyzer-use-of-uninitial |[13 Regression] |ized-value false positive |-Wanalyzer-use-of-uninitial |seen in haproxy's |ized-value false positive |sink_rotate_file_backed_rin |seen in haproxy's |g |sink_rotate_file_backed_rin ||g --- Comment #1 from David Malcolm --- Seems to be a regression relative to 12.2
[Bug analyzer/108661] New: -Wanalyzer-use-of-uninitialized-value false positive seen in haproxy's sink_rotate_file_backed_ring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108661
Bug ID: 108661
Summary: -Wanalyzer-use-of-uninitialized-value false positive
seen in haproxy's sink_rotate_file_backed_ring
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Consider:
#include
#include
#include
struct ring
{
char buf[1024];
};
int test (const char *name)
{
struct ring ring;
int fd;
int ret;
fd = open(name, O_RDONLY);
if (fd < 0)
return 0;
ret = read(fd, , sizeof(ring));
close(fd);
if (ret != sizeof(ring))
return 1;
if (ring.buf[0] > 1)
return 2;
return 3;
}
Currently trunk emits this false positive:
: In function 'test':
:26:21: warning: use of uninitialized value 'ring.buf[0]' [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
26 | if (ring.buf[0] > 1)
| ^~~
'test': events 1-6
|
| 12 | struct ring ring;
| | ^~~~
| | |
| | (1) region created on stack here
|..
| 17 | if (fd < 0)
| |~
| ||
| |(2) following 'false' branch (when 'fd >= 0')...
|..
| 20 | ret = read(fd, , sizeof(ring));
| | ~
| | |
| | (3) ...to here
|..
| 23 | if (ret != sizeof(ring))
| |~
| ||
| |(4) following 'false' branch (when 'ret == 1024')...
|..
| 26 | if (ring.buf[0] > 1)
| | ~~~
| | |
| | (5) ...to here
| | (6) use of uninitialized value 'ring.buf[0]'
here
|
Compiler returned: 0
https://godbolt.org/z/3sMhxej6P
Looks like the analyzer might not "know" that when "read" returns the input
size, that the buffer is fully populated.
[Bug c++/108242] [10/11/12/13 Regression] '__FUNCTION__' was not declared when used inside a generic (templated) lambda declared inside a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108242
--- Comment #7 from Jakub Jelinek ---
Sorry, above doesn't compile, but
template
void my_fun()
{
auto fun = [&](auto res) {
static constexpr char const* fun_name = __PRETTY_FUNCTION__;
struct
{
constexpr const char* operator()() const { constexpr char const*
fun_name2 = __PRETTY_FUNCTION__; return fun_name; };
} t;
t();
};
fun(12);
}
int main() {
my_fun();
}
ICEs and compiles fine with G++ 11.x.
[Bug c/108660] New: Wrong location for first statement of for loop (-Wunused-value)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108660
Bug ID: 108660
Summary: Wrong location for first statement of for loop
(-Wunused-value)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
void t1(int t)
{
for (t; t < 10; t++)
;
}
```
This should warn about a statement with no effect and GCC does but the location
marker is incorrect. The C front-end underlines the for keyword rather than the
expression `t`.
```
: In function 't1':
:3:3: warning: statement with no effect [-Wunused-value]
3 | for (t; t < 10; t++)
| ^~~
```
Note the C++ front-end gets it correct:
```
: In function 'void t1(int)':
:3:8: warning: statement has no effect [-Wunused-value]
3 | for (t; t < 10; t++)
|^
```
[Bug c++/108242] [10/11/12/13 Regression] '__FUNCTION__' was not declared when used inside a generic (templated) lambda declared inside a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108242 Marek Polacek changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=105809 CC||mpolacek at gcc dot gnu.org --- Comment #6 from Marek Polacek --- I was just looking into bug 105809 which looks like the same problem except with __PRETTY_FUNCTION__.
[Bug middle-end/108657] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657 --- Comment #2 from Andrew Pinski --- If I initialize __trans_tmp_13 explictly to 0, the issue goes away
[Bug c++/101071] [10/11/12/13 Regression] ICE in gimplify_init_constructor, at gimplify.c:5228
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101071 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #5 from Marek Polacek --- Fixed by r13-2978, which came without a test so I'll add a new one.
[Bug c++/108242] [10/11/12/13 Regression] '__FUNCTION__' was not declared when used inside a generic (templated) lambda declared inside a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108242
--- Comment #5 from Jakub Jelinek ---
Makes me wonder why finish_fname returns the IDENTIFIER_NODE rather than the
VAR_DECL when processing_template_decl, though if I comment that out it ICEs.
When DECL_INITIAL is __FUNCTION__ etc. IDENTIFIER_NODE, it is looked up using
lookup_name, which works fine if it is the template function in which
__FUNCTION__ has been referenced (ok e.g. when processing DECL_EXPR of
fun_name). But for some reason
we don't find that VAR_DECL as local specialization and trigger
/* This can happen for a variable used in a
late-specified return type of a local lambda, or for a
local static or constant. Building a new VAR_DECL
should be OK in all those cases. */
r = tsubst_decl (t, args, complain);
if (local_specializations)
/* Avoid infinite recursion (79640). */
register_local_specialization (r, t);
if (decl_maybe_constant_var_p (r))
{
/* We can't call cp_finish_decl, so handle the
initializer by hand. */
tree init = tsubst_init (DECL_INITIAL (t), r, args,
complain, in_decl);
which then doesn't work, either it finds a different __FUNCTION__ than it
should, e.g. for:
bool v;
template
void my_fun()
{
auto fun = [&](auto res) {
static constexpr char const* fun_name = __FUNCTION__;
struct
{
constexpr const char* operator()() const { return v ? __FUNCTION__
: fun_name; };
} t;
t();
};
fun(12);
}
or it doesn't find it at all.
[Bug c++/108646] nonnull attribute does not detect variables that are NULL being passed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108646 --- Comment #4 from Jonathan Wakely --- (In reply to Jonny Grant from comment #3) > Is it worth -Wnonnull emitting a warning message that it needs optimization > to get the needed data flow analysis? No, there are dozens of warnings that work poorly, or not at all, unless optimization is enabled. It's in the manual. "The effectiveness of some warnings depends on optimizations also being enabled. For example -Wsuggest-final-types is more effective with link-time optimization and some instances of other warnings may not be issued at all unless optimization is enabled. While optimization in general improves the efficacy of control and data flow sensitive warnings, in some cases it may also cause false positives."
[Bug other/108644] Format string warnings related to longs under MigW-W64/MSYS2 on Windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108644 --- Comment #7 from Jan Dubiec --- (In reply to Andrew Pinski from comment #6) [...] > as sizeof returns size_t. > > Does that make sense now? Yep, thanks.
[Bug gcov-profile/108658] [GCOV] Function entry is not recorded in a function containing an infinite loop from another thread depending on the optimization level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108658 --- Comment #3 from Sebastian Huber --- Thanks for the hint, however, adding -pthread or -fprofile-update=atomic doesn't change anything.
[Bug other/108644] Format string warnings related to longs under MigW-W64/MSYS2 on Windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108644 --- Comment #6 from Andrew Pinski --- (In reply to Jan Dubiec from comment #5) > Regarding gcc/ira-conflicts.cc, I think you are probably right, parentheses > should fix the issue. But I am not able to understand (without looking into > docs) how without the parentheses the expressions are promoted to unsigned > long long int instead of just long int. And why the warning does not appear > on Linux. (long) allocated_words_num * sizeof (IRA_INT_TYPE) For Linux, it is (long) * (unsigned long) or (long) * (unsigned int) [first is LP64 and the second is ILP32], the first gives unsigned long while the second case gives long. While under LLP64LI32, you have (long) * (unsigned long long) so you get "unsigned long long" as the type. as sizeof returns size_t. Does that make sense now?
[Bug other/108644] Format string warnings related to longs under MigW-W64/MSYS2 on Windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108644 --- Comment #5 from Jan Dubiec --- Andrew, as per your wish, preprocessed lto-plugin\lto-plugin.c is in the attachment. It was produced using the following command: gcc -DHAVE_CONFIG_H -I. -I../../../gcc/lto-plugin -I../../../gcc/lto-plugin/../include -DHAVE_CONFIG_H -Wall -DBASE_VERSION=\"13.0.1\" -E -g3 -O2 ../../../gcc/lto-plugin/lto-plugin.c -DDLL_EXPORT -DPIC -o lto-plugin-preprocessed.c Regarding gcc/ira-conflicts.cc, I think you are probably right, parentheses should fix the issue. But I am not able to understand (without looking into docs) how without the parentheses the expressions are promoted to unsigned long long int instead of just long int. And why the warning does not appear on Linux. Regarding gcc/config/h8300/h8300.cc, I will file a separate report soon.
[Bug target/108659] Suboptimal 128 bit atomics codegen on AArch64 and x64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659 --- Comment #4 from Andrew Pinski --- (In reply to Niall Douglas from comment #3) > You may be interested in reading https://reviews.llvm.org/D110069. It wanted > to have LLVM generate a 128 bit AArch64 CAS for atomics. LLVM merged that > change, it'll be in the next release. Using CAS for atomic load is not valid thing to do ... Because atomic load from constant rodata needs to work. LLVM breaks this case as they don't care about it. GCC does though.
[Bug other/108644] Format string warnings related to longs under MigW-W64/MSYS2 on Windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108644 --- Comment #4 from Jan Dubiec --- Created attachment 54406 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54406=edit Preprocessed lto-plugin\lto-plugin.c
[Bug target/108659] Suboptimal 128 bit atomics codegen on AArch64 and x64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659 --- Comment #3 from Niall Douglas --- > AMD has guaranteed it, but there is still VIA and Zhaoxin and while we have > some statement from the latter, I'm not sure it is enough and we don't have > anything from VIA. See PR104688 for details. I'm wondering if a compiler opt out flag like -no-msseatomic16 to turn off use of SSE for 128 bit atomics wouldn't be an idea? Given the small market share of those CPU vendors, seems a shame to hold up implementation. (Also, if you do turn it on by default and advertise that widely, I suspect those vendors will hurry up with their documentation) > FWIW, the GCC codegen for aarch64 is at https://godbolt.org/z/qvx9484nY (arm > and aarch64 are different targets). It emits a call to libatomic, which for > GCC 13 will use a lockless implementation when possible at runtime, see > g:d1288d850944f69a795e4ff444a427eba3fec11b Thanks for the catch, my mistake. It would seem the codegen is similarly inferior to the codegen from clang for both aarch64 and x64. You may be interested in reading https://reviews.llvm.org/D110069. It wanted to have LLVM generate a 128 bit AArch64 CAS for atomics. LLVM merged that change, it'll be in the next release.
[Bug fortran/108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #3)
> 2023-02-03 Jakub Jelinek
>
> PR fortran/108451
> * trans-decl.cc (gfc_trans_use_stmts): Call clear_slot before
> doing continue.
>
> --- gcc/fortran/trans-decl.cc.jj 2023-01-16 11:52:16.146733136 +0100
> +++ gcc/fortran/trans-decl.cc 2023-02-03 14:41:40.503322954 +0100
> @@ -5350,7 +5350,11 @@ gfc_trans_use_stmts (gfc_namespace * ns)
> /* Sometimes, generic interfaces wind up being over-ruled by a
>local symbol (see PR41062). */
> if (!st->n.sym->attr.use_assoc)
> - continue;
> + {
> + *slot = error_mark_node;
> + entry->decls->clear_slot (slot);
> + continue;
> + }
>
> if (st->n.sym->backend_decl
> && DECL_P (st->n.sym->backend_decl)
>
> fixes the regression (fairly obvious bug). Am not adding testcase because
> given #c1 I'm really not sure if the testcase is valid or not. Anyway, GCC
> 12 accept z1 and z2 and reject z3, so IMHO this bug should be split into the
> checking ICE which the above patch should fix and any possible
> accepts-invalid which doesn't look like a regression.
The code is invalid Fortran. The module m does not contain
an entity named 'pdtt'. If I had to guess the 'pdt' portion
of the name means 'parameterized derived type' and the last
't' means type 't'. This is likely an internal symbol that
has escaped. gfortran's support for PDTs is broken.
I agree with you about committing your fix for the ICE and
opening a new PR about the PDT issue. Note there are already
several open PRs, so this might end up as a dup.
[Bug fortran/108651] Array Constructor with [type-spec:: fails to apply to all values, eg x = [integer(int64):: 1,2,3,4]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108651 --- Comment #4 from kargl at gcc dot gnu.org --- (In reply to Scott Boyce from comment #3) > No its not correct because the Yes, it is the correct behavior. Please see 18-007r1.pdf, p.57. 7.4.3.1 Integer type ... Any integer value can be represented as a signed-int-literal-constant. ... The optional kind type parameter following digit-string specifies the kind type parameter of the integer constant; if it does not appear, the constant is default integer. 8258803693257250632 has default integer kind when it is parsed. 8258803693257250632_int64 has the integer type of integer(int64). Now check Sec. 7.8 "Construction of array values". R773 ac-value is expr or ac-implied-do 8258803693257250632 is an expr. C7111 (R770) If type-spec specifies an intrinsic type, each ac-value expression in the array-constructor shall be of an intrinsic type that is in type conformance with a variable of type type-spec as specified in Table 10.8. 8258803693257250632 meets the requirements of type conformance. 18-007r1.pdf, p. 89. If type-spec appears, it specifies the declared type and type parameters of the array constructor. Each ac-value expression in the array-constructor shall be compatible with intrinsic assignment to a variable of this type and type parameters. Each value is converted to the type and type parameters of the array-constructor in accordance with the rules of intrinsic assignment (10.2.1.3). Now, read that last sentence again, and then go read 10.2.1.3. 8258803693257250632 is treated as the right-hand-side of an intrinsic assignment such as integer(int64) x x = 8258803693257250632 This won't work because mathematically 8258803693257250632 exceeds huge(1). You have shown the correct way to do the array constructor, and in that case the type-spec within the constructor is redundant.
[Bug gcov-profile/108658] [GCOV] Function entry is not recorded in a function containing an infinite loop depending on the optimization level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108658 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Instrumentation-Options.html#index-fprofile-update > The GCC driver automatically selects ‘prefer-atomic’ when -pthread is present > in the command line. The default for -fprofile-update= is single.
[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647 --- Comment #15 from Aldy Hernandez --- (In reply to Jakub Jelinek from comment #14) > Created attachment 54405 [details] > gcc13-pr108647.patch > > Here is what I'm about to test momentarily, though I must say I don't > understand those operator_cast changes at all. I thought casts are unary > operators and so I don't understand what kind of range would be op2 in that > case. Oh poop, sorry. Unary operators always have the resulting type passed as VARYING in op2. It would never be undefined. Sorry for the noise; you can disregard the cast changes.
[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #14 from Jakub Jelinek --- Created attachment 54405 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54405=edit gcc13-pr108647.patch Here is what I'm about to test momentarily, though I must say I don't understand those operator_cast changes at all. I thought casts are unary operators and so I don't understand what kind of range would be op2 in that case.
[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647 --- Comment #13 from Aldy Hernandez --- Created attachment 54404 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54404=edit frange changes These are the analogous changes to range-op-float.cc. Patch in testing.
[Bug c/108657] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657 --- Comment #1 from David Binderman --- Created attachment 54403 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54403=edit C source code After 90 minutes reduction, about 12% of the original is left.
[Bug target/108642] ACLE function __arm_wsr missing for AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108642 --- Comment #6 from David Spickett --- Thanks for the link, we'll try to use those when we detect g++.
[Bug fortran/108649] allocation segmentation fault for pointer derive type and ICE for final-binding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108649 --- Comment #8 from Scott Boyce --- Sorry for sending a second message, my test cases have a workaround already added to the code for the Finalization, but the code posted has issues with ALLOCATION of derived types.
[Bug fortran/108649] allocation segmentation fault for pointer derive type and ICE for final-binding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108649 --- Comment #7 from Scott Boyce --- (In reply to Jerry DeLisle from comment #6) Thanks that is excellent news about the finalization. There also is the issue with the ALLOCATION as well. Another set of test cases are my Batteries Included Fortran Library (its part of this project under the folder bif_lib). The full repository for BiF is located at https://code.usgs.gov/fortran/bif I was not sure if I should post that code on here as a separate issue (it has lots of allocation issues as well with gfortran).
[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #12 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #7)
> So
> --- gcc/range-op.cc.jj2023-02-03 10:51:40.699003658 +0100
> +++ gcc/range-op.cc 2023-02-03 16:04:39.264159294 +0100
> @@ -642,7 +642,8 @@ operator_equal::op1_range (irange , tr
> case BRS_FALSE:
>// If the result is false, the only time we know anything is
>// if OP2 is a constant.
> - if (wi::eq_p (op2.lower_bound(), op2.upper_bound()))
> + if (!op2.undefined_p ()
> + && wi::eq_p (op2.lower_bound(), op2.upper_bound()))
> {
> r = op2;
> r.invert ();
> @@ -755,7 +756,8 @@ operator_not_equal::op1_range (irange
> case BRS_TRUE:
>// If the result is true, the only time we know anything is if
>// OP2 is a constant.
> - if (wi::eq_p (op2.lower_bound(), op2.upper_bound()))
> + if (!op2.undefined_p ()
> + && wi::eq_p (op2.lower_bound(), op2.upper_bound()))
> {
> r = op2;
> r.invert ();
> @@ -920,6 +922,9 @@ operator_lt::op1_range (irange , tree
> const irange ,
> relation_trio) const
> {
> + if (op2.undefined_p ())
> +return false;
> +
>switch (get_bool_state (r, lhs, type))
> {
> case BRS_TRUE:
> @@ -942,6 +947,9 @@ operator_lt::op2_range (irange , tree
> const irange ,
> relation_trio) const
> {
> + if (op1.undefined_p ())
> +return false;
> +
>switch (get_bool_state (r, lhs, type))
> {
> case BRS_TRUE:
> @@ -1031,6 +1039,9 @@ operator_le::op1_range (irange , tree
> const irange ,
> relation_trio) const
> {
> + if (op2.undefined_p ())
> +return false;
> +
>switch (get_bool_state (r, lhs, type))
> {
> case BRS_TRUE:
> @@ -1053,6 +1064,9 @@ operator_le::op2_range (irange , tree
> const irange ,
> relation_trio) const
> {
> + if (op1.undefined_p ())
> +return false;
> +
>switch (get_bool_state (r, lhs, type))
> {
> case BRS_TRUE:
> @@ -1141,6 +1155,9 @@ operator_gt::op1_range (irange , tree
> const irange , const irange ,
> relation_trio) const
> {
> + if (op2.undefined_p ())
> +return false;
> +
>switch (get_bool_state (r, lhs, type))
> {
> case BRS_TRUE:
> @@ -1163,6 +1180,9 @@ operator_gt::op2_range (irange , tree
> const irange ,
> relation_trio) const
> {
> + if (op1.undefined_p ())
> +return false;
> +
>switch (get_bool_state (r, lhs, type))
> {
> case BRS_TRUE:
> @@ -1252,6 +1272,9 @@ operator_ge::op1_range (irange , tree
> const irange ,
> relation_trio) const
> {
> + if (op2.undefined_p ())
> +return false;
> +
>switch (get_bool_state (r, lhs, type))
> {
> case BRS_TRUE:
> @@ -1274,6 +1297,9 @@ operator_ge::op2_range (irange , tree
> const irange ,
> relation_trio) const
> {
> + if (op1.undefined_p ())
> +return false;
> +
>switch (get_bool_state (r, lhs, type))
> {
> case BRS_TRUE:
> then plus testcase?
Looks good to me.
Do you mind adding this bit to your testing?
diff --git a/gcc/range-op.cc b/gcc/range-op.cc
index 136b709385c..fdc0a6c05fd 100644
--- a/gcc/range-op.cc
+++ b/gcc/range-op.cc
@@ -2678,7 +2678,6 @@ operator_cast::op1_range (irange , tree type,
if (lhs.undefined_p ())
return false;
tree lhs_type = lhs.type ();
- gcc_checking_assert (types_compatible_p (op2.type(), type));
// If we are calculating a pointer, shortcut to what we really care about.
if (POINTER_TYPE_P (type))
@@ -2705,6 +2704,8 @@ operator_cast::op1_range (irange , tree type,
return true;
}
+ if (op2.undefined_p ())
+return false;
if (truncating_cast_p (op2, lhs))
{
if (lhs.varying_p ())
This catches the cast operator which will ICE in truncating_cast_p when op2 is
undefined.
I've removed the checking assert since any number of operations further down
will ICE if the types don't match.
[Bug target/108659] Suboptimal 128 bit atomics codegen on AArch64 and x64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #2 from ktkachov at gcc dot gnu.org --- (In reply to Niall Douglas from comment #0) > Related: > - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 > - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94649 > - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 > > I got bitten by this again, latest GCC still does not emit single > instruction 128 bit atomics, even when the -march is easily new enough. Here > is a godbolt comparing latest MSVC, latest GCC and latest clang for the > skylake-avx512 architecture, which unquestionably supports cmpxchg16b. Only > clang emits the single instruction atomic: > > https://godbolt.org/z/EnbeeW4az > > I'm gathering from the issue comments and from the comments at > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 that you're going to > wait for AMD to guarantee atomicity of SSE instructions before changing the > codegen here, which makes sense. However I also wanted to raise potentially > suboptimal 128 bit atomic codegen by GCC for AArch64 as compared to clang: > > https://godbolt.org/z/oKv4o81nv > > GCC emits `dmb` to force a global memory fence, whereas clang does not. > > I think clang is in the right here, the seq_cst atomic semantics are not > supposed to globally memory fence. FWIW, the GCC codegen for aarch64 is at https://godbolt.org/z/qvx9484nY (arm and aarch64 are different targets). It emits a call to libatomic, which for GCC 13 will use a lockless implementation when possible at runtime, see g:d1288d850944f69a795e4ff444a427eba3fec11b
[Bug fortran/108651] Array Constructor with [type-spec:: fails to apply to all values, eg x = [integer(int64):: 1,2,3,4]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108651 --- Comment #3 from Scott Boyce --- No its not correct because the [integer(int64):: in INTEGER(INT64), dimension(2), parameter:: arr1 = [integer(int64):: -3300711175878204139, 8258803693257250632] is the initialization is indicating that all the numbers are int64 and not int32. Otherwise, what is the point of adding the type spec within the array initialization Second, otherwise you have to do something stupid like this to be compatible with gfortran: INTEGER(INT64), dimension(256), parameter:: exp_ipmf= [ & 9223372036854775806_int64, 1623796909450836942_int64, 2664290944894287536_int64, & 7387971354164062286_int64, 6515064486552725727_int64, 8840508362680705564_int64, & 6099647593382931854_int64, 7673130333659518959_int64, 6220332867583442119_int64, & 5045979640552799519_int64, 4075305837223961434_int64, 3258413672162528204_int64, & 2560664887087755460_int64, 1957224924672901793_int64, 1429800935350586317_int64, & 964606309710805398_int64, 551043923599587507_int64, 180827629096887271_int64, & -152619738120024135_int64, -454588624410297994_int64, -729385126147771550_int64, & -980551509819436091_int64, -1211029700667469343_int64, -1423284293868552853_int64, & -1619396356369054015_int64, -1801135830956208679_int64, -1970018048575620636_int64, & -2127348289059702419_int64, -2274257249303686369_int64, -2411729520096647511_int64, & -2540626634159186189_int64, -2661705860113411427_int64, -2775635634532452931_int64, & -2883008316030452685_int64, -2984350790383660344_int64, -308019198120492_int64, & -3170777096303094023_int64, -3256660348483807146_int64, -3338123885075143810_int64, & -3415475560473292784_int64, -3488994201966436213_int64, -3558932970354465681_int64, & -3625522261068040523_int64, -3688972217741992772_int64, -3749474917563780918_int64, & -3807206277531066033_int64, -3862327722496832777_int64, -3914987649156774371_int64, & -3965322714631868789_int64, -4013458973776904711_int64, -4059512885612775571_int64, & -4103592206186240140_int64, -4145796782586126309_int64, -4186219260694351160_int64, & -4224945717447272663_int64, -4262056226866286506_int64, -4297625367836515404_int64, & -4331722680528539029_int64, -4364413077437474043_int64, -4395757214229410182_int64, & -4425811824915126951_int64, -4454630025296931623_int64, -4482261588141301290_int64, & -4508753193105274668_int64, -4534148654077814519_int64, -4558489126279958535_int64, & -4581813295192218010_int64, -4604157549138257917_int64, -4625556137145252094_int64, & -4646041313519107008_int64, -4665643470413307024_int64, -4684391259530330202_int64, & -4702311703971758561_int64, -4719430301145093973_int64, -4735771117539952483_int64, & -4751356876102085678_int64, -4766209036859141945_int64, -4780347871386006289_int64, & -4793792531638886797_int64, -4806561113635134843_int64, -4818670716409303206_int64, & -4830137496634475108_int64, -4840976719260841080_int64, -4851202804490340302_int64, & -4860829371376465578_int64, -4869869278311660680_int64, -4878334660640769131_int64, & -4886236965617420889_int64, -4893586984900801361_int64, -4900394884772701206_int64, & -490667023423961_int64, -4912422031164499511_int64, -4917658726580128817_int64, & -4922388247283526639_int64, -4926618016851058129_int64, -4930354975163349944_int64, & -4933605596540647482_int64, -4936375906575298263_int64, -4938671497741363402_int64, & -4940497543854573923_int64, -4941858813449628344_int64, -4942759682136115973_int64, & -4943204143989096034_int64, -4943195822025520534_int64, -4942737977813217760_int64, & -4941833520255016417_int64, -4940485013586754412_int64, -4938694684624350782_int64, & -4936464429291796994_int64, -4933795818458819764_int64, -4930690103114058905_int64, & -4927148218896869823_int64, -4923170790008281939_int64, -4918758132519204034_int64, & -4913910257091649047_int64, -4908626871126539190_int64, -4902907380349533220_int64, & -4896750889844278395_int64, -4890156204540517421_int64, -4883121829162564021_int64, & -4875645967641788341_int64, -4867726521994914537_int64, -4859361090668117144_int64, & -4850546966345100146_int64, -4841281133215543008_int64, -4831560263698491528_int64, & -4821380714613448338_int64, -4810738522790068329_int64, -4799629400105478223_int64, & -4788048727936306618_int64, -4775991551010520594_int64, -4763452570642106428_int64, & -4750426137329493684_int64, -4736906242696391928_int64, -4722886510751374910_int64, & -4708360188440094804_int64,
[Bug target/108659] Suboptimal 128 bit atomics codegen on AArch64 and x64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- (In reply to Niall Douglas from comment #0) > I'm gathering from the issue comments and from the comments at > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 that you're going to > wait for AMD to guarantee atomicity of SSE instructions before changing the > codegen here, which makes sense. AMD has guaranteed it, but there is still VIA and Zhaoxin and while we have some statement from the latter, I'm not sure it is enough and we don't have anything from VIA. See PR104688 for details.
[Bug c++/108659] New: Suboptimal 128 bit atomics codegen on AArch64 and x64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659 Bug ID: 108659 Summary: Suboptimal 128 bit atomics codegen on AArch64 and x64 Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: s_gccbugzilla at nedprod dot com Target Milestone: --- Related: - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94649 - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 I got bitten by this again, latest GCC still does not emit single instruction 128 bit atomics, even when the -march is easily new enough. Here is a godbolt comparing latest MSVC, latest GCC and latest clang for the skylake-avx512 architecture, which unquestionably supports cmpxchg16b. Only clang emits the single instruction atomic: https://godbolt.org/z/EnbeeW4az I'm gathering from the issue comments and from the comments at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 that you're going to wait for AMD to guarantee atomicity of SSE instructions before changing the codegen here, which makes sense. However I also wanted to raise potentially suboptimal 128 bit atomic codegen by GCC for AArch64 as compared to clang: https://godbolt.org/z/oKv4o81nv GCC emits `dmb` to force a global memory fence, whereas clang does not. I think clang is in the right here, the seq_cst atomic semantics are not supposed to globally memory fence.
[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647 --- Comment #11 from Andrew Macleod --- (In reply to Jakub Jelinek from comment #10) > (In reply to Andrew Macleod from comment #9) > > (In reply to Jakub Jelinek from comment #8) > > > Unfortunately that would mean for the non-equality cases that if > > > lhs.undefined_p () we don't return undefined but false (aka VARYING). > > > Another option is to add those if (op?.undefined_p ()) return false; to > > > both > > > case BRS_TRUE: and case BRS_FALSE:. > > > > Well, if the LHS is undefined, (or even one of the operands) we are > > typically in dead code or edge anyway.. I'm not sure it really matters? > > Ok, I'll test the patch then. > > > An alternate question as well is why is the threader even looking at this > > impossible path. It should know that the branch can never be true > > I think range-op shouldn't assume nothing will call it with UNDEFINED ranges. Oh I wasn't suggesting otherwise,we should be bulletproof. Just wondering why the threader is spending any time evaluating ranges on a path it should know is impossible.
[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647 --- Comment #10 from Jakub Jelinek --- (In reply to Andrew Macleod from comment #9) > (In reply to Jakub Jelinek from comment #8) > > Unfortunately that would mean for the non-equality cases that if > > lhs.undefined_p () we don't return undefined but false (aka VARYING). > > Another option is to add those if (op?.undefined_p ()) return false; to both > > case BRS_TRUE: and case BRS_FALSE:. > > Well, if the LHS is undefined, (or even one of the operands) we are > typically in dead code or edge anyway.. I'm not sure it really matters? Ok, I'll test the patch then. > An alternate question as well is why is the threader even looking at this > impossible path. It should know that the branch can never be true I think range-op shouldn't assume nothing will call it with UNDEFINED ranges.
[Bug gcov-profile/108658] [GCOV] Function entry is not recorded in a function containing an infinite loop depending on the optimization level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108658 --- Comment #1 from Andrew Pinski --- Try compiling with -pthread too? Otherwise the instrumentation code assumes it is single threaded.
[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647 --- Comment #9 from Andrew Macleod --- (In reply to Jakub Jelinek from comment #8) > Unfortunately that would mean for the non-equality cases that if > lhs.undefined_p () we don't return undefined but false (aka VARYING). > Another option is to add those if (op?.undefined_p ()) return false; to both > case BRS_TRUE: and case BRS_FALSE:. Well, if the LHS is undefined, (or even one of the operands) we are typically in dead code or edge anyway.. I'm not sure it really matters? An alternate question as well is why is the threader even looking at this impossible path. It should know that the branch can never be true
