[Bug c++/107532] New: [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532
Bug ID: 107532
Summary: [13 Regression] -Werror=dangling-reference false
positives in libcamera-0.0.1
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org
Target Milestone: ---
libcamera-0.0.1 and a few other projects (like cvise) fail to compile due to
-Werror on -Werror=dangling-reference.
I think those are false positives related to value-like types that pass
references through.
Extracted example from libcamera:
// $ cat a.cpp.cpp
struct Plane { unsigned int bytesused; };
// Passes a reference through. Does not change lifetime.
template
struct Ref {
const Inner & i_;
Ref(const Inner & i) : i_(i) {}
const Inner & inner() { return i_; }
};
struct FrameMetadata {
Ref planes() const { return p_; }
Plane p_;
};
void bar(const Plane & meta);
void foo(const FrameMetadata & fm)
{
const Plane & meta = fm.planes().inner();
bar(meta);
}
$ g++-13.0.0 -c -Wall -Werror=dangling-reference a.cpp
a.cpp: In function 'void foo(const FrameMetadata&)':
a.cpp:20:19: error: possibly dangling reference to a temporary
[-Werror=dangling-reference]
20 | const Plane & meta = fm.planes().inner();
| ^~~~
a.cpp:20:43: note: the temporary was destroyed at the end of the full
expression '(& fm)->FrameMetadata::planes().Ref::inner()'
20 | const Plane & meta = fm.planes().inner();
| ~^~
cc1plus: some warnings being treated as errors
This gcc version is this week's gcc-13 snapshot with
https://gcc.gnu.org/PR107488 applied on top.
[Bug c++/107531] List of references calls destructors, add warning?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107531 --- Comment #2 from nightstrike --- It looks like you're right. The root cause of the problem is that in my non-reduced case, I didn't have a copy constructor, but I had a non-default destructor that was releasing resources twice. So it's clearly my fault, I just kind of hoped the compiler could be a little more omniscient :) If a warning is not really possible here, then I guess this could be "closed invalid". Or maybe there are already PR's open to request a warning to remind you that you did something requiring a non-default copy constructor?
[Bug c++/107531] List of references calls destructors, add warning?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107531 --- Comment #1 from Andrew Pinski --- My bet is on a copy constructor being invoked.
[Bug c++/107531] New: List of references calls destructors, add warning?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107531
Bug ID: 107531
Summary: List of references calls destructors, add warning?
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
The following code results in a destructor being calling twice:
#include
struct S {
S() { __builtin_printf("ctor\n"); }
~S() { __builtin_printf("dtor\n"); }
};
template
void f(Args const & ... args) {
for (auto const & s: { args... })
;
}
int main() {
S s;
f(s);
}
$ ./a.out
ctor
dtor
dtor
Changing line 9 to use pointers fixes it:
for (auto const * s: { })
$ ./a.out
ctor
dtor
I think that if my code is exploiting some kind of bad behavior (and it likely
is), a warning at -Wall would be a nice addition (currently, there is none).
If what I'm doing is allowed, I don't think calling a destructor twice is the
best idea :) :). I'd be betting money on the first thing, though. Maybe
adding something from -fsanitize=undefined would be an option?
[Bug c++/107528] constexpr evaluator doesn't check for deallocate of mismatched size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107528 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #1 from Jiang An --- Currently it's unspecified whether this UB results in constant evaluation failure, because this is only caused by the specification in the standard library part (see [expr.const]).
[Bug objc++/61759] [ICE] [objc++] reaching gcc_unreachable in objc_eh_runtime_type at objc/objc-next-runtime-abi-01.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61759 --- Comment #12 from Sergey Fedorov --- (In reply to Andrew Pinski from comment #11) > *** Bug 107530 has been marked as a duplicate of this bug. *** I.e. gcc12 has the same bug too.
[Bug objc++/107530] ICE: in objc_eh_runtime_type, at objc/objc-next-runtime-abi-01.cc:2795
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107530 --- Comment #2 from Sergey Fedorov --- (In reply to Andrew Pinski from comment #1) > Dup of bug 61759 > > *** This bug has been marked as a duplicate of bug 61759 *** I guess then it is worth adding gcc12 to confirmed to fail list there.
[Bug objc++/107530] ICE: in objc_eh_runtime_type, at objc/objc-next-runtime-abi-01.cc:2795
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107530 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 61759 *** This bug has been marked as a duplicate of bug 61759 ***
[Bug objc++/61759] [ICE] [objc++] reaching gcc_unreachable in objc_eh_runtime_type at objc/objc-next-runtime-abi-01.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61759 Andrew Pinski changed: What|Removed |Added CC||vital.had at gmail dot com --- Comment #11 from Andrew Pinski --- *** Bug 107530 has been marked as a duplicate of this bug. ***
[Bug target/107530] New: ICE: in objc_eh_runtime_type, at objc/objc-next-runtime-abi-01.cc:2795
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107530 Bug ID: 107530 Summary: ICE: in objc_eh_runtime_type, at objc/objc-next-runtime-abi-01.cc:2795 Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vital.had at gmail dot com CC: iains at gcc dot gnu.org Target Milestone: --- Target: powerpc-apple-darwin Created attachment 53830 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53830=edit Output on 10.6.8 While building jack for ppc32 with gcc12, I got this error: during GIMPLE pass: eh In file included from ../macosx/coreaudio/JackCoreAudioDriver.mm:29: ../common/JackLockedEngine.h: In member function 'int Jack::JackLockedEngine::PortRegister(int, const char*, const char*, unsigned int, unsigned int, jack_port_id_t*)': ../common/JackLockedEngine.h:196:13: internal compiler error: in objc_eh_runtime_type, at objc/objc-next-runtime-abi-01.cc:2795 196 | int PortRegister(int refnum, const char* name, const char *type, unsigned int flags, unsigned int buffer_size, jack_port_id_t* port) | ^~~~ Identical error on 10.6.8 Rosetta (for which I attach .mii file) and 10.6 PPC (10A190). Output file produced with: /opt/local/bin/g++-mp-12 -save-temps -v -pipe -Os -arch ppc -Wall -Wno-invalid-offsetof -std=gnu++11 -Wno-deprecated-register -fPIC -I. -I.. -Icommon -I../common -Icommon/jack -I../common/jack -Imacosx -I../macosx -Iposix -I../posix -DAFTEN=1 -DHAVE_DOXYGEN=0 -DHAVE_ALSA=0 -DHAVE_FIREWIRE=0 -DHAVE_IIO=0 -DHAVE_PORTAUDIO=0 -DHAVE_WINMME=0 -DHAVE_CELT=0 -DHAVE_EXAMPLE_TOOLS=0 -DHAVE_OPUS=0 -DHAVE_SAMPLERATE=1 -DHAVE_SNDFILE=1 -DHAVE_READLINE=0 -DHAVE_SYSTEMD=0 -DHAVE_DB=0 -DHAVE_ZALSA=0 -DHAVE_ALLOCA_H=1 -DHAVE_EXECINFO_H=1 -DUSE_CLASSIC_AUTOLAUNCH=1 -DCLIENT_NUM=256 -DPORT_NUM_FOR_CLIENT=2048 -DADDON_DIR="/opt/local/lib/jack" -DJACK_LOCATION="/opt/local/bin" -DUSE_POSIX_SHM=1 -DJACKMP=1 -DHAVE_CONFIG_H -DSERVER_SIDE ../macosx/coreaudio/JackCoreAudioDriver.mm -c -o/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_jack/jack/work/jack2-1.9.21/build/macosx/coreaudio/JackCoreAudioDriver.mm.7.o -I/opt/local/include gcc info: COLLECT_GCC=/opt/local/bin/g++-mp-12 COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/powerpc-apple-darwin10/12.2.0/lto-wrapper Target: powerpc-apple-darwin10 Configured with: /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_lang_gcc12/gcc12/work/gcc-12.2.0/configure --prefix=/opt/local --build=powerpc-apple-darwin10 --enable-languages=c,c++,objc,obj-c++,lto,fortran,jit --libdir=/opt/local/lib/gcc12 --includedir=/opt/local/include/gcc12 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-12 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-12 --with-gxx-include-dir=/opt/local/include/gcc12/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local --with-zstd=/opt/local --enable-checking=release --disable-multilib --enable-lto --enable-libstdcxx-time --without-build-config --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket --enable-host-shared --with-darwin-extra-rpath=/opt/local/lib/libgcc --with-libiconv-prefix=/opt/local --disable-tls --with-pkgversion='MacPorts gcc12 12.2.0_0' Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.2.0 (MacPorts gcc12 12.2.0_0)
[Bug debug/53135] Duplicates cause size explosion (vta/dwarf)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53135 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #19 from Jeffrey A. Law --- I think it's just workaround that got installed in 2012, not a real fix. Of course, 10 years later one could ask if the workaround has become the "real fix".
[Bug c++/107529] New: constexpr evaluator doesn't check for destroyed objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107529
Bug ID: 107529
Summary: constexpr evaluator doesn't check for destroyed
objects
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vanyacpp at gmail dot com
Target Milestone: ---
I believe this function contains undefined behavior and should not be allowed
to evaluate at compile-time.
The call to `std::destroy_at(p)` should end the lifetime of `*p` and accesses
to `*p` after that should be invalid.
#include
struct mytype
{
constexpr mytype() : x(42) {}
constexpr ~mytype() {}
int x;
};
constexpr int foo()
{
std::allocator alloc;
mytype* p = alloc.allocate(1);
std::construct_at(p);
std::destroy_at(p); // destroy *p
int result = p->x;// access
alloc.deallocate(p, 1);
return result;
}
static_assert(foo() == 42);
[Bug c++/107528] New: constexpr evaluator doesn't check for deallocate of mismatched size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107528
Bug ID: 107528
Summary: constexpr evaluator doesn't check for deallocate of
mismatched size
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vanyacpp at gmail dot com
Target Milestone: ---
This functions causes undefined behavior and should not be evaluated at
compile-time.
The problem is the second argument of `deallocate` function (number of objects
to deallocate). It must be equal to the number of objects that were allocated.
#include
constexpr int foo()
{
std::allocator alloc;
int* p = alloc.allocate(1);
alloc.deallocate(p, 3);
return 42;
}
static_assert(foo() == 42);
[Bug c++/107327] internal compiler error: in tsubst_pack_expansion, at cp/pt.c:12930
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107327 --- Comment #11 from Carlos E --- Created attachment 53829 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53829=edit preprocessed file on 10.2 preprocessed with echo '#include ' | gcc -x c - -E
[Bug jit/101491] /usr/local/include/libgccjit++.h conflicts between different GCC installations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101491 John Hein changed: What|Removed |Added Attachment #53828|install libgccjit*.h under |install libgccjit*.h under description|$(libdir)/gcc/$(target_alia |$(libdir)/gcc/$(target_alia |s)/$(gcc_version) instead |s)/$(gcc_version) instead |of $(libdir)/include|of $(includedir) --- Comment #11 from John Hein --- Comment on attachment 53828 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53828 install libgccjit*.h under $(libdir)/gcc/$(target_alias)/$(gcc_version) instead of $(includedir) minor correction on patch description
[Bug c++/107527] warning: declaration of ‘void operator delete(void*, std::size_t)’ has a different exception specifier [-Wsystem-headers]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107527 --- Comment #1 from Andrew Pinski --- I thought I had saw this one before. Specifically something related to Darwin.
[Bug c++/107527] New: warning: declaration of ‘void operator delete(void*, std::size_t)’ has a different exception specifier [-Wsystem-headers]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107527
Bug ID: 107527
Summary: warning: declaration of ‘void operator delete(void*,
std::size_t)’ has a different exception specifier
[-Wsystem-headers]
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
This code compiles cleanly unless you use -Wsystem-headers:
#include
#include
void* operator new(std::size_t n)
{
return std::malloc(n);
}
void operator delete(void* p)
{
std::free(p);
}
void operator delete(void* p, std::size_t)
{
std::free(p);
}
$ g++ del.C -c
$ g++ del.C -c -Wsystem-headers
del.C:9:6: warning: declaration of ‘void operator delete(void*)’ has a
different exception specifier [-Wsystem-headers]
9 | void operator delete(void* p)
| ^~~~
In file included from del.C:1:
/usr/include/c++/12/new:130:6: note: from previous declaration ‘void operator
delete(void*) noexcept’
130 | void operator delete(void*) _GLIBCXX_USE_NOEXCEPT
| ^~~~
del.C:14:6: warning: declaration of ‘void operator delete(void*, std::size_t)’
has a different exception specifier [-Wsystem-headers]
14 | void operator delete(void* p, std::size_t)
| ^~~~
/usr/include/c++/12/new:135:6: note: from previous declaration ‘void operator
delete(void*, std::size_t) noexcept’
135 | void operator delete(void*, std::size_t) _GLIBCXX_USE_NOEXCEPT
| ^~~~
But the warning is correct, and indicates a problem in the user code. It should
not be suppressed by the system header.
[Bug debug/100523] [11/12/13 Regression] armv8.1-m.main -fcompare-debug failure with -O -fmodulo-sched -mtune=cortex-a53
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100523 Ramana Radhakrishnan changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #3 from Ramana Radhakrishnan --- It does fall over but isn't this is a bit of an undefined testcase given that crc is an uninitialised local variable used before initialisation ? What am I missing ? Ramana
[Bug c++/107500] Useless atexit entry for ~constant_init in eh_globals.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500 --- Comment #24 from R. Diez --- In case somebody else wants to patch their GCC 12.2, here is the slightly-modified patch for convenience: https://github.com/rdiez/DebugDue/blob/master/Toolchain/Patches/Gcc12EhGlobalsAtexit.patch
[Bug libstdc++/107466] [12/13 Regression] invalid -Wnarrowing error with std::subtract_with_carry_engine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107466 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2022-11-04 Status|UNCONFIRMED |NEW Component|c++ |libstdc++ Ever confirmed|0 |1 --- Comment #4 from Jonathan Wakely --- That's not the standard. That text comes from a general requirement in [rand.req.gen] that applies to all engines and adaptors. The more specific requirements for subtract_with_carry_engine say it uses a specialization of linear_congruential_engine that is ill-formed. More specific requirements overrule more general ones. I've created a new LWG issue so this will get fixed in the standard. The best suggestion so far is that it should use linear_congruential_engine instead of using its own result_type. Reassigning to component:libstdc++.
[Bug target/94604] support for the ETSI basic operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94604 Ramana Radhakrishnan changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2022-11-04 CC||ramana at gcc dot gnu.org --- Comment #3 from Ramana Radhakrishnan --- I'd suggest moving this to Waiting given the time without a response and the correct links to documentation and that this should be covered really by arm_acle.h . Ramana
[Bug jit/101491] /usr/local/include/libgccjit++.h conflicts between different GCC installations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101491 --- Comment #10 from John Hein --- (In reply to John Hein from comment #9) Oops. s/libgccgit/libgccjit/ in the previous comment.
[Bug jit/101491] /usr/local/include/libgccjit++.h conflicts between different GCC installations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101491 John Hein changed: What|Removed |Added CC||rv4chsst7e at liamekaens dot com --- Comment #9 from John Hein --- Created attachment 53828 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53828=edit install libgccjit*.h under $(libdir)/gcc/$(target_alias)/$(gcc_version) instead of $(libdir)/include I've been using the attached patch on FreeBSD for a few months to install libgccjit*.h in the location of other header files under $(libdir)/gcc/$(target_alias)/$(gcc_version)/ as suggested in comment 5. emacs uses libgccgit.h (if configured --with-native-compilation), and the emacs port builds fine with this new location.
[Bug target/61593] Support '#pragma mark - foo' on non-Darwin targets (by simply ignoring it without warning)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61593 --- Comment #13 from Jonathan Wakely --- (In reply to Eric Gallager from comment #5) > It should be pretty easy; in config/darwin.h #pragma mark is registered as > part of the DARWIN_REGISTER_TARGET_PRAGMAS() macro like this: > > if (!flag_preprocess_only)\ > cpp_register_pragma (parse_in, NULL, "mark",\ > darwin_pragma_ignore, false); > > ...and then darwin_pragma_ignore() is a simple no-op declared in > config/darwin-protos.h and defined in config/darwin-c.c. So I guess it'd > just have to be re-titled and moved somewhere generic? I looked into doing this as a follow-up to my PR 85487 patch. However, the definition of c_register_pragma in gcc/c-family/c-pragma.cc says: /* Front-end wrappers for pragma registration to avoid dragging cpplib.h in almost everywhere. */ So I don't think we want to include cpplib.h in that file, which means that it can't make the same call to cpp_register_pragma. I don't know the reason for treating that pragma differently from the others (this appears to be the only use of cpp_register_pragma in the whole of GCC!), so I don't want to change it. That means I won't be tackling this one myself. Maybe it could just use c_register_pragmas, or maybe including cpplib.h in c-pragma.cc is OK. If somebody else wants to, my patch for PR 85487 (which I'm going to re-propose soon) adds a target-independent handle_pragma_ignore that could be used for this, once the issue above is cleared up.
[Bug debug/53135] Duplicates cause size explosion (vta/dwarf)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53135 --- Comment #18 from Ramana Radhakrishnan --- Since the fix got installed in 2012 this really should have been fixed from 4.8.0 onwards. Should we really keep this still open or can we close this out ? Ramana
[Bug tree-optimization/55157] Missed VRP with != 0 and multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157 Aldy Hernandez changed: What|Removed |Added Attachment #53826|0 |1 is obsolete|| --- Comment #11 from Aldy Hernandez --- Created attachment 53827 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53827=edit revised patch in testing
[Bug tree-optimization/55157] Missed VRP with != 0 and multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157 --- Comment #10 from Aldy Hernandez --- Original TYPE_UNSIGNED patch with leading / trailing suggestions: -2.52% As attached: -3.62% Moving the code out of set_range_from_nonzero_bits back into set_nonzero_bits: -3.7%
[Bug tree-optimization/55157] Missed VRP with != 0 and multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157 --- Comment #9 from Aldy Hernandez --- (In reply to Aldy Hernandez from comment #7) > (In reply to Andrew Macleod from comment #6) > > (In reply to Aldy Hernandez from comment #4) > > 3) It also seems to me that you then only need to add the zero/union iff the > > trailing bit has zeros. ie, if the are no trailing zeros, then just set the > > lb to 0, and calculate the UB based on the clz. > > That actually made it slightly worse. I did some more testing. Your suggestions actually improved the original code from 3.3% to 2.5%, but I added: + if (!wi::neg_p (mask, TYPE_SIGN (type ())) && prec > 1) instead of: + if (TYPE_UNSIGNED (type ()) && prec > 1) because we can still perform the optimization for signed positive numbers. And that brought the slowdown back to 3.6%. But ISTM that we're gonna do it, might as well do it for signed numbers as well. H... I think we really should do our best to represent masks as ranges as it makes other optimizations possible across the ranger ecosystem. But I'm not ecstatic about the 3.6% drop (even though overall compilation is unaffected).
[Bug tree-optimization/107523] [13 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107523 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection Summary|wrong code at -O2 and -O3 |[13 Regression] wrong code |on x86_64-linux-gnu |at -O2 and -O3 on ||x86_64-linux-gnu Target Milestone|--- |13.0
[Bug c++/106644] [C++23] P2468R2 - The Equality Operator You Are Looking For
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106644 Jason Merrill changed: What|Removed |Added Last reconfirmed||2022-11-04 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug libstdc++/24537] Non-uglified names inside namespace __gnu_cxx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24537 Jonathan Wakely changed: What|Removed |Added Status|NEW |WAITING --- Comment #8 from Jonathan Wakely --- I would like to suggest closing this bug. I don't think we should rename __gnu_cxx::char_traits, it uses a reserved name. I don't think there is anything wrong with e.g. __debug::vector or __gnu_cxx::char_traits and we shouldn't pick ugly names to avoid problems for users who abuse using-directives. Changing status to WAITING to start the timer, but if I don't hear otherwise then I'll close it.
[Bug c++/98940] Implement C++23 language features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940 Bug 98940 depends on bug 102614, which changed state. Bug 102614 Summary: [C++23] P2314R4 - Character sets and encodings https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102614 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/102614] [C++23] P2314R4 - Character sets and encodings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102614 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jakub Jelinek --- I believe we implement this already (probably starting with GCC 10 or so when UTF-8 chars in identifiers etc. were introduced).
[Bug tree-optimization/107413] Perf loss ~14% on 519.lbm_r SPEC cpu2017 benchmark with r8-7132-gb5b33e113434be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107413 Wilco changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-11-04 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org --- Comment #10 from Wilco --- (In reply to Rama Malladi from comment #9) > (In reply to Rama Malladi from comment #8) > > (In reply to Wilco from comment #7) > > > The revert results in about 0.5% loss on Neoverse N1, so it looks like the > > > reassociation pass is still splitting FMAs into separate MUL and ADD > > > (which > > > is bad for narrow cores). > > > > Thank you for checking on N1. Did you happen to check on V1 too to reproduce > > the perf results I had? Any other experiments/ tests I can do to help on > > this filing? Thanks again for the debug/ fix. > > I ran SPEC cpu2017 fprate 1-copy benchmark built with the patch reverted and > using option 'neoverse-n1' on the Graviton 3 processor (which has support > for SVE). The performance was up by 0.4%, primary contributor being > 519.lbm_r which was up 13%. I'm seeing about 1.5% gain on Neoverse V1 and 0.5% loss on Neoverse N1. I'll post a patch that allows per-CPU settings for FMA reassociation, so you'll get good performance with -mcpu=native. However reassociation really needs to be taught about the existence of FMAs.
[Bug c++/56958] Spurious set but not used variable warning in empty pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56958 serpent7776 at gmail dot com changed: What|Removed |Added CC||serpent7776 at gmail dot com --- Comment #7 from serpent7776 at gmail dot com --- I was just hit by this warning in a very similar scenario. To me this warning in this context is not only unhelpful, but confusing. clang doesn't issue this warning in this context.
[Bug libstdc++/107525] propagate_const should not be using SFINAE on its conversion operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107525 --- Comment #9 from Giuseppe D'Angelo --- (In reply to Jonathan Wakely from comment #5) > Please don't! At least not in the next 9 days. We intend to vote out LFTSv3 > at next week's meeting, there will be no more proposals for LFTS considered. > And I don't want to derail the vote next week by having open proposals > arriving at the last minute. No problem, I wouldn't have done this before a few weeks anyhow. > Feel free to file a library issue though. If propagate_const ever gets > proposed for inclusion in the standard then this should be taken into > account. OK. Thank you very much for the prompt fix. (Ville: guess what, this bug stem from trying to make uic and friends use propagate_const. Small world!)
[Bug tree-optimization/55157] Missed VRP with != 0 and multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157 --- Comment #8 from Aldy Hernandez --- Created attachment 53826 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53826=edit untested Here's what I tested and we're still around a 3% degradation for VRP.
[Bug tree-optimization/55157] Missed VRP with != 0 and multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157 --- Comment #7 from Aldy Hernandez --- (In reply to Andrew Macleod from comment #6) > (In reply to Aldy Hernandez from comment #4) > > > > > The patch below does this, but it does have a 3% penalty for VRP (though no > > penalty to overall compilation). I'm inclined to pursue this route, since > > it makes nonzero mask optimization more pervasive across the board. > > > > What do you think Andrew? > > > > 1) Why wouldn't this be done in set_range_from_nonzero_bits()? That call is You're right. > 2) That seems expensive.. we must be doing unnecessary work. Maybe it would > speed up if we checked if either the ctz or clz would cause it to do > anything first. Thus avoiding creating a couple of ranges and performing a > union and intersection in cases where neither the leading nor trailing bit > is a zero? I had already played with that. It made a marginal difference. > > 3) It also seems to me that you then only need to add the zero/union iff the > trailing bit has zeros. ie, if the are no trailing zeros, then just set the > lb to 0, and calculate the UB based on the clz. That actually made it slightly worse. I'll attach what I just tested.
[Bug analyzer/107526] - -Wanayzer-null-dereference false positive with different behaviors when delete unrelated statement “int *e = 0;”
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107526 --- Comment #1 from Geoffrey --- And if i compile this case with gcc 11.3, it does not report NPD warning. https://godbolt.org/z/v88PWvs3s seems like a regression problem.
[Bug libstdc++/107525] propagate_const should not be using SFINAE on its conversion operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107525 Ville Voutilainen changed: What|Removed |Added CC||ville.voutilainen at gmail dot com --- Comment #8 from Ville Voutilainen --- (In reply to Jonathan Wakely from comment #7) > Ping Ville: please take a look Looks fine to me.
[Bug analyzer/107526] New: - -Wanayzer-null-dereference false positive with different behaviors when delete unrelated statement “int *e = 0;”
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107526
Bug ID: 107526
Summary: - -Wanayzer-null-dereference false positive with
different behaviors when delete unrelated statement
“int *e = 0;”
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: geoffreydgr at icloud dot com
Target Milestone: ---
I encountered a false positive when compiling the following MCVE program with
gcc (trunk) with -fanalyzer -O0 in https://godbolt.org/z/ojqa7PjPf
```
#include
void f(short *g) {
int a =0;
int b = (0 != g);
am:
if (b) {
int *c =
*c = printf("NPD_FLAG\n");
}
int *e = 0; // (3) 'g' is NULL
(*g)++;
if (a)
goto am;
}
int main() {
short d=0;
f();
return 0;
}
```
Gcc static analyzer reports dereference of NULL 'g' at line 4, which is a
false positive. while it gives wrong path note (3) 'g' is NULL at line 12.
If I delete line 12 as the following code, gcc analyzer does not report NPD
warning anymore.The statement `int *e = 0; ` is unrelated to `g` , but gcc
analyzer has different behaviors before and after deleting the statement.
```
#include
void f(short *g) {
int a =0;
int b = (0 != g);
am:
if (b) {
int *c =
*c = printf("NPD_FLAG\n");
}
int *e = 0; // (3) 'g' is NULL
(*g)++;
if (a)
goto am;
}
int main() {
short d=0;
f();
return 0;
}
```
Do you have any thoughts about this false positive?
[Bug libstdc++/107525] propagate_const should not be using SFINAE on its conversion operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107525 Jonathan Wakely changed: What|Removed |Added CC||ville at gcc dot gnu.org --- Comment #7 from Jonathan Wakely --- Ping Ville: please take a look
[Bug libstdc++/107525] propagate_const should not be using SFINAE on its conversion operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107525 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #6 from Jonathan Wakely --- Created attachment 53825 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53825=edit Do not use SFINAE for propagate_const conversions I got nerd sniped by the incorrect constraint, so replaced them with base classes as you suggested. I'll probably push this next week.
[Bug libstdc++/107525] propagate_const should not be using SFINAE on its conversion operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107525 --- Comment #5 from Jonathan Wakely --- (In reply to Giuseppe D'Angelo from comment #4) > Sorry, what I meant is, of course there is interest at keeping this code to > compile in pre-C++20 mode, and possibly have the same semantics no matter > what's the language version used? Or is it acceptable to have such an "API > break"? (E.g. stuff like `is_convertible_v, Base > *>` changes value.) I think that's fine for TS material. > More in general, I think these operators are strangely defined. I'm not sure > why they're not simply defined to be > > template operator U *() requires (std::is_convertible_v *>); > > mut.mut. for the `const` version. That seems better to me. > The current definition also allows for pointer arithmetic (only if one uses > a C++20 constraint, otherwise it doesn't work), which is something the > original paper says it does NOT want to support. And the current definition > allows for `delete`ing a propagate_const, which maybe is wanted, but in > contradiction with the lack of support for pointer arithmetic. > > I guess I'll need to submit a paper. Please don't! At least not in the next 9 days. We intend to vote out LFTSv3 at next week's meeting, there will be no more proposals for LFTS considered. And I don't want to derail the vote next week by having open proposals arriving at the last minute. Feel free to file a library issue though. If propagate_const ever gets proposed for inclusion in the standard then this should be taken into account.
[Bug c++/107500] Useless atexit entry for ~constant_init in eh_globals.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500 --- Comment #23 from R. Diez --- Many thanks for the fix. If you backport it to GCC 12.x, I won't be able to complain so much. ;-)
[Bug libstdc++/107525] propagate_const should not be using SFINAE on its conversion operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107525 --- Comment #4 from Giuseppe D'Angelo --- (In reply to Jonathan Wakely from comment #1) > (In reply to Giuseppe D'Angelo from comment #0) > > So. ideally, the conversion operators should be using C++20 constraints, but > > of course that's not possible. > > It's totally possible for C++20 mode. > > I don't know how much motivation anybody has to do anything about this > though. Sorry, what I meant is, of course there is interest at keeping this code to compile in pre-C++20 mode, and possibly have the same semantics no matter what's the language version used? Or is it acceptable to have such an "API break"? (E.g. stuff like `is_convertible_v, Base *>` changes value.) > And the spec seems wrong as well. The const overload should be constrained > for const T being convertible to const element_type*. Yes, that sounds like a defect to me. -- More in general, I think these operators are strangely defined. I'm not sure why they're not simply defined to be template operator U *() requires (std::is_convertible_v); mut.mut. for the `const` version. The current definition also allows for pointer arithmetic (only if one uses a C++20 constraint, otherwise it doesn't work), which is something the original paper says it does NOT want to support. And the current definition allows for `delete`ing a propagate_const, which maybe is wanted, but in contradiction with the lack of support for pointer arithmetic. I guess I'll need to submit a paper.
[Bug libstdc++/107525] propagate_const should not be using SFINAE on its conversion operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107525
--- Comment #3 from Jonathan Wakely ---
And the spec seems wrong as well. The const overload should be constrained for
const T being convertible to const element_type*.
This should probably not compile:
#include
struct X
{
int& operator*() { return *i; }
const int& operator*() const { return *i; }
int* get() { return i; }
const int* get() const { return i; }
int* i = nullptr;
operator int*() { return i; }
operator const int*() const = delete;
};
int main()
{
using std::experimental::propagate_const;
X x;
const propagate_const px(x);
static_assert(!std::is_convertible_v);
static_assert(std::is_convertible_v, const int*>);
const int* pi = px;
}
[Bug tree-optimization/107342] Optimization opportunity where integer '/' corresponds to '>>'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107342 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Aldy Hernandez --- fixed
[Bug tree-optimization/107342] Optimization opportunity where integer '/' corresponds to '>>'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107342 --- Comment #4 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:679be32e66428f0ba81d1c1b55f7bd47f01cb295 commit r13-3688-g679be32e66428f0ba81d1c1b55f7bd47f01cb295 Author: Aldy Hernandez Date: Fri Nov 4 10:20:46 2022 +0100 Set nonzero bits for multiplication and divisions by a power of 2. We're missing a lot of TLC in keeping track of nonzero bits across range-ops. It isn't an oversight, but just limited amount of hours to implement stuff. This patch keeps better track of the nonzero mask (really maybe_nonzero bits as discussed) across multiplication and division when the RHS is a power of 2. It fixes PR107342 and also touches on PR55157. In the latter, the nonzero mask is being set quite late (CCP2) but could be set by evrp time if we enhanced range-ops. I have added tests from both PRs. Tested PR tree-optimization/107342 gcc/ChangeLog: * range-op.cc (operator_mult::fold_range): New. (operator_div::fold_range): New. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/vrp122.c: New test. * gcc.dg/tree-ssa/vrp123.c: New test.
[Bug c++/107500] Useless atexit entry for ~constant_init in eh_globals.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |12.3 --- Comment #22 from Jonathan Wakely --- Fixed for GCC 13 then. Backport to GCC 12 to be decided later.
[Bug libstdc++/107525] propagate_const should not be using SFINAE on its conversion operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107525 --- Comment #2 from Jonathan Wakely --- Also, the constraint is wrong for the non-const conversion. It checks for convertibility to const element_type* but should be element_type*.
[Bug libstdc++/107511] [13 Regression] gcc-13-20221030 failure to build on Cygwin due to lack of secure_getenv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107511 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jonathan Wakely --- Should be fixed now.
[Bug c++/107500] Useless atexit entry for ~constant_init in eh_globals.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500 --- Comment #21 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:418999fe382c608facf57f96b53a9cb12d2fdd20 commit r13-3685-g418999fe382c608facf57f96b53a9cb12d2fdd20 Author: Jonathan Wakely Date: Thu Nov 3 11:48:57 2022 + libstdc++: Simplify lifetime of eh_globals variable [PR107500] Since this is a trivial type, we probably don't need to do anything to ensure it's still accessible after other static dtors. libstdc++-v3/ChangeLog: PR libstdc++/107500 * libsupc++/eh_globals.cc (eh_globals): Remove immortalizing wrapper. (__cxxabiv1::__cxa_get_globals_fast): Adjust. (__cxxabiv1::__cxa_get_globals): Adjust.
[Bug libstdc++/107511] [13 Regression] gcc-13-20221030 failure to build on Cygwin due to lack of secure_getenv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107511 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:f505f37a8e5a7646af4038b5c46f72d8a05dc7f0 commit r13-3684-gf505f37a8e5a7646af4038b5c46f72d8a05dc7f0 Author: Jonathan Wakely Date: Thu Nov 3 11:44:47 2022 + libstdc++: Define _GNU_SOURCE for secure_getenv on Cygwin [PR107511] As in r12-6867-ge20486d508afdf we need to define _GNU_SOURCE explicitly for Cygwin, because configure finds it in libc but it isn't declared unless we request it. libstdc++-v3/ChangeLog: PR libstdc++/107511 * libsupc++/eh_alloc.cc (_GNU_SOURCE): Define.
[Bug libstdc++/107525] propagate_const should not be using SFINAE on its conversion operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107525 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Keywords||rejects-valid Last reconfirmed||2022-11-04 Status|UNCONFIRMED |NEW --- Comment #1 from Jonathan Wakely --- (In reply to Giuseppe D'Angelo from comment #0) > So. ideally, the conversion operators should be using C++20 constraints, but > of course that's not possible. It's totally possible for C++20 mode. I don't know how much motivation anybody has to do anything about this though.
[Bug c++/86369] constexpr const char* comparison fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86369 --- Comment #11 from Aaron Ballman --- (In reply to Jakub Jelinek from comment #10) > (In reply to Aaron Ballman from comment #9) > > Doesn't [expr.eq] make it unspecified though? > > Will defer that answer to Jason. > But please have a look at the comment 6 testcase. I strongly hope that > constexpr const char *p = "abc"; > constexpr const char *q = p; > static_assert (p == q, ""); > doesn't actually mean the string literal is evaluated multiple times, because > if it would be, then one pretty much can't use string literals for anything > reliably. Oh yeah, I agree with you in that case. I was talking about the summary example with function calls returning a string literal. Sorry for not being more clear! > I bet the wording in there is for the > constexpr const char *r = "abc"; > constexpr const char *s = "abc"; > case, where the standard doesn't force implementations to unify same string > literals within the same TU but allows it (and also allows say tail merging > of them). From what I can see in the LLVM constant expression evaluation > behavior, it doesn't track what comes from which evaluation of a string > literal (GCC doesn't track that either) and just assumes that it could be > different evaluation, while GCC assumes it is not. Yeah, that sounds plausible.
[Bug tree-optimization/55157] Missed VRP with != 0 and multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157 --- Comment #6 from Andrew Macleod --- (In reply to Aldy Hernandez from comment #4) > > The patch below does this, but it does have a 3% penalty for VRP (though no > penalty to overall compilation). I'm inclined to pursue this route, since > it makes nonzero mask optimization more pervasive across the board. > > What do you think Andrew? > 1) Why wouldn't this be done in set_range_from_nonzero_bits()? That call is just above that spot in the code. Or is the name misleading and it does something else? 2) That seems expensive.. we must be doing unnecessary work. Maybe it would speed up if we checked if either the ctz or clz would cause it to do anything first. Thus avoiding creating a couple of ranges and performing a union and intersection in cases where neither the leading nor trailing bit is a zero? 3) It also seems to me that you then only need to add the zero/union iff the trailing bit has zeros. ie, if the are no trailing zeros, then just set the lb to 0, and calculate the UB based on the clz. I should think that would speed things up a bit.
[Bug modula2/107524] building html docs from gm2.texi fails due to missing top node
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107524 Gaius Mulley changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Gaius Mulley --- Thanks, applied patch.
[Bug c++/86369] constexpr const char* comparison fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86369 --- Comment #10 from Jakub Jelinek --- (In reply to Aaron Ballman from comment #9) > Doesn't [expr.eq] make it unspecified though? Will defer that answer to Jason. But please have a look at the comment 6 testcase. I strongly hope that constexpr const char *p = "abc"; constexpr const char *q = p; static_assert (p == q, ""); doesn't actually mean the string literal is evaluated multiple times, because if it would be, then one pretty much can't use string literals for anything reliably. I bet the wording in there is for the constexpr const char *r = "abc"; constexpr const char *s = "abc"; case, where the standard doesn't force implementations to unify same string literals within the same TU but allows it (and also allows say tail merging of them). From what I can see in the LLVM constant expression evaluation behavior, it doesn't track what comes from which evaluation of a string literal (GCC doesn't track that either) and just assumes that it could be different evaluation, while GCC assumes it is not.
[Bug c++/86369] constexpr const char* comparison fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86369 Aaron Ballman changed: What|Removed |Added CC||aaron at aaronballman dot com --- Comment #9 from Aaron Ballman --- (In reply to Jason Merrill from comment #8) > (In reply to Nicolas Lesser from comment #1) > > For clarity, b1 shouldn't compile. > > > > [lex.string]p16 says: "whether successive evaluations of a string-literal > > yield the same or a different object is unspecified." > > > > [expr.const]p2 says: "An expression e is a core constant expression unless > > the evaluation of e, [...], would evaluate one of the following expressions: > > [...]; a relational or equality operator where the result is unspecified;" > > I think the second quote refers to places in [expr.eq] that say "the result > is unspecified", not to all instances of unspecified behavior in the > standard. Doesn't [expr.eq] make it unspecified though? [expr.eq]p6 says: "If two operands compare equal, the result is true for the == operator and false for the != operator. If two operands compare unequal, the result is false for the == operator and true for the != operator. Otherwise, the result of each of the operators is unspecified." If it is unspecified whether a subsequent string literal evaluation produces the same object or a different object then it's unspecified whether the two operands will or won't compare equal, so the result of the operators is also unspecified.
[Bug c++/107500] Useless atexit entry for ~constant_init in eh_globals.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500 --- Comment #20 from R. Diez --- I had to modify the patch slightly. I guess that union member "unsigned char unused;" was removed after GCC 12.2 was released. But otherwise, the patch does work, at least in my bare-metal scenario. The atexit entry is no longer being generated, and I haven't seen any other side-effects yet.
[Bug fortran/69090] Allocatable arrays mishandled in 'omp declare target'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69090 --- Comment #9 from Tobias Burnus --- (In reply to Thomas Schwinge from comment #8) > Has this been fixed via PR96668 "[OpenMP] Re-mapping allocated but > previously unallocated allocatable does not work", by chance? (Tobias?) I think both examples should work since that commit went into GCC 11 (untested, however). (It is clear why the example in comment 0 did not work back then (2015), but the one in comment 7 is unclear as no GCC version was mentioned; if it was mainline it should work (GCC 11), if it was a release branch, the fail is understandable.) NOTE: While the fix for PR96668 handles previously unallocated arrays, the OpenMP specification since 5.1 (or rather already TR 9) clarified that the 'always' modifier is required. This requirement might go away in OpenMP 6.0, but even TR11 still has it. NOTE 2: PR96668 is not yet closed as scalar allocatables are not handled, yet. (But both examples in this PR use arrays.)
[Bug tree-optimization/55157] Missed VRP with != 0 and multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157 --- Comment #5 from Aldy Hernandez --- (In reply to Aldy Hernandez from comment #4) > + // Reflect the mask as a simple range. For example, a mask of > + // 0xff00 could be represented as [0,0][0x100, 0x]. > + if (TYPE_UNSIGNED (type ()) && prec > 1) Bonus points for making it work with signed. I'm not smart enough to do that :).
[Bug libstdc++/107525] New: propagate_const should not be using SFINAE on its conversion operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107525 Bug ID: 107525 Summary: propagate_const should not be using SFINAE on its conversion operators Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: dangelog at gmail dot com Target Milestone: --- propagate_const in the LFTSv3 has implicit conversion operators which have constraints on them: https://cplusplus.github.io/fundamentals-ts/v3.html#propagate_const.const_observers > constexpr operator const element_type*() const; > > Constraints: >T is an object pointer type or has an implicit conversion to const > element_type*. > Returns: >get(). libstdc++ implements these constraints by means of SFINAE on the operators. This is user-hostile: using SFINAE means that the conversion operator is now a function template, and that means that https://eel.is/c++draft/over.ics.user#3 kicks in: > If the user-defined conversion is specified by a specialization of a > conversion function template, the second standard conversion sequence shall > have exact match rank. Concretely, this means that for instance we lose implicit conversions towards base classes of the pointed-to type: std::experimental::propagate_const ptr; Derived *d1 = ptr; // Convert precisely to Derived *: OK Base *b1= ptr; // Convert to a pointer to a base: ERROR Base *b2= static_cast(ptr); // OK Base *b3= static_cast(ptr);// ERROR Base *b4= ptr.get(); // OK But these should all work. The design of propagate_const is for it to be "drop-in replacement", maximizing compatibility with existing code. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4388.html says explictly "When T is an object pointer type operator value* exists and allows implicit conversion to a pointer. This avoids using get to access the pointer in contexts where it was unnecesary before addition of the propagate_const wrapper." -- So. ideally, the conversion operators should be using C++20 constraints, but of course that's not possible. I guess that a reasonable alternative would be to isolate them in a base class, and apply SFINAE on that base class instead?
[Bug modula2/107524] New: building html docs from gm2.texi fails due to missing top node
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107524 Bug ID: 107524 Summary: building html docs from gm2.texi fails due to missing top node Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- Building html docs fails from gm2.texi fails due to missing top node, which is only included in info mode, unlike all other nodes. --- a/gcc/doc/gm2.texi +++ b/gcc/doc/gm2.texi @@ -64,10 +83,8 @@ Boston, MA 02110-1301, USA@* @c `Top' Node and Master Menu -@ifinfo @node Top, Overview, (dir), (dir) @top Introduction -@end ifinfo @menu * Overview:: What is GNU Modula-2.
[Bug tree-optimization/55157] Missed VRP with != 0 and multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55157
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
||amacleod at redhat dot com
--- Comment #4 from Aldy Hernandez ---
We have a variety of ways of fixing this:
1. Improve the range-op entry for MULT_EXPR.
2. Handle nonzero bits in the relational operators.
3. Reflect the nonzero bits in the actual range for trivial masks.
At evrp time we have:
=== BB 2
Imports: t_3(D)
Exports: t_3(D) g_4
g_4 : t_3(D)(I)
t_3(D) [irange] unsigned int VARYING
:
g_4 = t_3(D) * 16;
if (g_4 == 0)
goto ; [INV]
else
goto ; [INV]
2->3 (T) g_4 : [irange] unsigned int [0, 0] NONZERO 0x0
2->4 (F) g_4 : [irange] unsigned int [1, +INF]
Since this is unsigned, improving the multiply range-op entry could give a
range for g_4 of [0,0][16,+INF]. This would be enough to fold the other
conditional: if (g_4 <= 4).
The code for mult and div is legacy code inherited from legacy VRP. I'm
assuming we didn't handle the above originally because legacy ranges couldn't
represent [0,0][16,+INF]. We can now, so we could improve here.
However, even without a multiplication improvement, the nonzero mask could help
here. Though this mask is missing by evrp time (because mult doesn't handle it
(yet)), CCP2 does provide it and we can see it by vrp1 time:
g_4: [irange] unsigned int [1, +INF] NONZERO 0xfff0
This should be enough to fold the second conditional: if (g_4 <= 4). But alas,
the LE_EXPR range-op entry does not take into account nonzero bits.
The above mask of 0xfff0 is fancy talk for [0, 0][16, +INF] which we could
intersect with [1, +INF]. We could teach the LE_EXPR range-op entry about
nonzero bits.
However, perhaps instead of teaching all the relation operators about nonzero
bits, we could augment the range in irange::set_nonzero_bits(). Basically,
intersecting [0,0][16,+INF] with the [1, +INF] when setting the nonzero mask.
The patch below does this, but it does have a 3% penalty for VRP (though no
penalty to overall compilation). I'm inclined to pursue this route, since it
makes nonzero mask optimization more pervasive across the board.
What do you think Andrew?
diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index a855aaf626c..db6a3b7bcb6 100644
--- a/gcc/value-range.cc
+++ b/gcc/value-range.cc
@@ -2962,6 +2962,20 @@ irange::set_nonzero_bits (const wide_int_ref )
normalize_kind ();
if (flag_checking)
verify_range ();
+
+ // Reflect the mask as a simple range. For example, a mask of
+ // 0xff00 could be represented as [0,0][0x100, 0x].
+ if (TYPE_UNSIGNED (type ()) && prec > 1)
+{
+ gcc_checking_assert (nz != 0);
+ wide_int lb = wi::lshift (wi::one (prec), wi::ctz (nz));
+ wide_int ub = wi::lrshift (wi::minus_one (prec), wi::clz (nz));
+ int_range<2> r (type (), lb, ub);
+ int_range<2> zero;
+ zero.set_zero (type ());
+ r.union_ (zero);
+ intersect (r);
+}
}
// Return the nonzero bitmask. This will return the nonzero bits plus
[Bug modula2/103574] race condition in bootstrap build, trunk 20211203
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103574 Matthias Klose changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME CC||doko at gcc dot gnu.org --- Comment #1 from Matthias Klose --- had at least one successful build on sparc64-linux-gnu in October 2022
[Bug modula2/106917] modula-2 fails to bootstrap with the modula-2 branch ,20220912
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106917 Matthias Klose changed: What|Removed |Added Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED --- Comment #3 from Matthias Klose --- late October builds succeeded for me
[Bug modula2/92146] gm2: the brig, fortran, go and D frontends are missing lang_register_spec_functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92146 Matthias Klose changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED CC||doko at gcc dot gnu.org --- Comment #2 from Matthias Klose --- applied some months ago
[Bug modula2/92147] gm2: modula-2 fails to build on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92147 Matthias Klose changed: What|Removed |Added CC||doko at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Matthias Klose --- recent trunk builds succeed on powerpc-linux-gnu
[Bug c++/107358] [13 Regression] i686-linux: Since r13-3290-g98e341130f8798 code fails to build libjxl-0/7.0 (vector float code)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107358 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed for 11.4+/12.3+ in C too.
[Bug c/106981] [10 Regression][OpenACC][OpenMP] ICE in decompose, at wide-int.h:984 with '#pragma omp/acc atomic capture'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106981 Jakub Jelinek changed: What|Removed |Added Summary|[10/11/12 |[10 |Regression][OpenACC][OpenMP |Regression][OpenACC][OpenMP |] ICE in decompose, at |] ICE in decompose, at |wide-int.h:984 with |wide-int.h:984 with |'#pragma omp/acc atomic |'#pragma omp/acc atomic |capture'|capture' --- Comment #13 from Jakub Jelinek --- Fixed for 11.4+ and 12.3+ too.
[Bug debug/106261] [10 Regression] ICE in output_call_frame_info, at dwarf2out.cc:943
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106261 Jakub Jelinek changed: What|Removed |Added Summary|[10/11 Regression] ICE in |[10 Regression] ICE in |output_call_frame_info, at |output_call_frame_info, at |dwarf2out.cc:943|dwarf2out.cc:943 --- Comment #9 from Jakub Jelinek --- Fixed for 11.4+ too.
[Bug rtl-optimization/106032] [10 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106032 Jakub Jelinek changed: What|Removed |Added Summary|[10/11 Regression] wrong|[10 Regression] wrong code |code at -Os and above on|at -Os and above on |x86_64-linux-gnu|x86_64-linux-gnu --- Comment #15 from Jakub Jelinek --- Fixed for 11.4+ too.
[Bug other/89863] [meta-bug] Issues in gcc that other static analyzers (cppcheck, clang-static-analyzer, PVS-studio) find that gcc misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863 Bug 89863 depends on bug 71324, which changed state. Bug 71324 Summary: liboffloadmic/runtime/offload_env.cpp:316]: (style) Redundant condition https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71324 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX
[Bug other/71324] liboffloadmic/runtime/offload_env.cpp:316]: (style) Redundant condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71324 Thomas Schwinge changed: What|Removed |Added Resolution|--- |WONTFIX Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED CC||tschwinge at gcc dot gnu.org --- Comment #2 from Thomas Schwinge --- Code removed in commit r13-3652-ge4cba49413ca429dc82f6aa2e88129ecb3fdd943 "Remove support for Intel MIC offloading".
[Bug target/89788] trunk/liboffloadmic/runtime/emulator/coi_host.cpp:175]: (error) Null pointer dereference (missed -Wnull-dereference)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89788 Thomas Schwinge changed: What|Removed |Added Target|i?86-intelmic | CC||tschwinge at gcc dot gnu.org --- Comment #6 from Thomas Schwinge --- This liboffloadmic code is gone after commit r13-3652-ge4cba49413ca429dc82f6aa2e88129ecb3fdd943 "Remove support for Intel MIC offloading", but I'm leaving this PR open, as it's not specifically about liboffloadmic code, but rather about a missing GCC compile-time diagnostic, as I understand this.
[Bug c/41041] Documentation: -fwide-exec-charset defaults to UCS-4/UCS-2, not UTF-32/UTF-16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41041
--- Comment #11 from Jonathan Wakely ---
SOmething like this:
--- a/gcc/doc/cppopts.texi
+++ b/gcc/doc/cppopts.texi
@@ -318,9 +318,10 @@ supported by the system's @code{iconv} library routine.
@opindex fwide-exec-charset
@cindex character set, wide execution
Set the wide execution character set, used for wide string and
-character constants. The default is UTF-32 or UTF-16, whichever
-corresponds to the width of @code{wchar_t}. As with
-@option{-fexec-charset}, @var{charset} can be any encoding supported
+character constants. The default is one of UTF-32BE, UTF-32LE, UTF-16BE,
+or UTF-16LE, whichever corresponds to the width of @code{wchar_t} and the
+big-endian or little-endian byte order being used for code generation. As
+with @option{-fexec-charset}, @var{charset} can be any encoding supported
by the system's @code{iconv} library routine; however, you will have
problems with encodings that do not fit exactly in @code{wchar_t}.
[Bug fortran/69090] Allocatable arrays mishandled in 'omp declare target'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69090 Thomas Schwinge changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=96668 CC||burnus at gcc dot gnu.org, ||tschwinge at gcc dot gnu.org --- Comment #8 from Thomas Schwinge --- Has this been fixed via PR96668 "[OpenMP] Re-mapping allocated but previously unallocated allocatable does not work", by chance? (Tobias?)
[Bug c/41041] Documentation: -fwide-exec-charset defaults to UCS-4/UCS-2, not UTF-32/UTF-16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41041 Jonathan Wakely changed: What|Removed |Added Resolution|WONTFIX |--- Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|RESOLVED|ASSIGNED --- Comment #10 from Jonathan Wakely --- Now that we have macros exposing the execution character set, we can check it easily: $ gcc -E -dM -x c /dev/null | grep EXEC #define __GNUC_WIDE_EXECUTION_CHARSET_NAME "UTF-32LE" #define __GNUC_EXECUTION_CHARSET_NAME "UTF-8" So the docs are misleading. I think I'll take this bug myself and try to document it without too much verbosity.
[Bug c++/107500] Useless atexit entry for ~constant_init in eh_globals.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500 Sebastian Huber changed: What|Removed |Added CC||sebastian.huber@embedded-br ||ains.de --- Comment #19 from Sebastian Huber --- I just have a side note. Enabling the thread-local storage may be an option for targets with limited memory resources. Newlib has the configuration option --enable-newlib-reent-thread-local to use thread-local objects instead of one big struct _reent.
[Bug c++/107358] [13 Regression] i686-linux: Since r13-3290-g98e341130f8798 code fails to build libjxl-0/7.0 (vector float code)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107358 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:57da0797a73f32c879bca77e121a4f55fcc57ce1 commit r11-10363-g57da0797a73f32c879bca77e121a4f55fcc57ce1 Author: Jakub Jelinek Date: Mon Oct 24 17:53:16 2022 +0200 c, c++: Fix up excess precision handling of scalar_to_vector conversion [PR107358] As mentioned earlier in the C++ excess precision support mail, the following testcase is broken with excess precision both in C and C++ (though just in C++ it was triggered in real-world code). scalar_to_vector is called in both FEs after the excess precision promotions (or stripping of EXCESS_PRECISION_EXPR), so we can then get invalid diagnostics that say float vector + float involves truncation (on ia32 from long double to float). The following patch fixes that by calling scalar_to_vector on the operands before the excess precision promotions, let scalar_to_vector just do the diagnostics (it does e.g. fold_for_warn so it will fold EXCESS_PRECISION_EXPR around REAL_CST to constants etc.) but will then do the actual conversions using the excess precision promoted operands (so say if we have vector double + (float + float) we don't actually do vector double + (float) ((long double) float + (long double) float) but vector double + (double) ((long double) float + (long double) float) 2022-10-24 Jakub Jelinek PR c++/107358 gcc/c/ * c-typeck.c (build_binary_op): Pass operands before excess precision promotions to scalar_to_vector call. gcc/testsuite/ * c-c++-common/pr107358.c: New test. (cherry picked from commit 65e3274e363cb2c6bfe6b5e648916eb7696f7e2f)
[Bug c/106981] [10/11/12 Regression][OpenACC][OpenMP] ICE in decompose, at wide-int.h:984 with '#pragma omp/acc atomic capture'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106981 --- Comment #12 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:01b894bc8a59691cc1d8dc29936635c8cfb8aed7 commit r11-10359-g01b894bc8a59691cc1d8dc29936635c8cfb8aed7 Author: Jakub Jelinek Date: Sat Sep 24 09:19:26 2022 +0200 openmp, c: Tighten up c_tree_equal [PR106981] This patch changes c_tree_equal to work more like cp_tree_equal, be more strict in what it accepts. The ICE on the first testcase was due to INTEGER_CST wi::wide (t1) == wi::wide (t2) comparison which ICEs if the two constants have different precision, but as the second testcase shows, being too lenient in it can also lead to miscompilation of valid OpenMP programs where we think certain expression is the same even when it isn't and can be guaranteed at runtime to represent different memory location. So, the patch looks through only NON_LVALUE_EXPRs and for constants as well as casts requires that the types match before actually comparing the constant values or recursing on the cast operands. 2022-09-24 Jakub Jelinek PR c/106981 gcc/c/ * c-typeck.c (c_tree_equal): Only strip NON_LVALUE_EXPRs at the start. For CONSTANT_CLASS_P or CASE_CONVERT: return false if t1 and t2 have different types. gcc/testsuite/ * c-c++-common/gomp/pr106981.c: New test. libgomp/ * testsuite/libgomp.c-c++-common/pr106981.c: New test. (cherry picked from commit 3c5bccb608c665ac3f62adb1817c42c845812428)
[Bug c++/105774] Bogus overflow in constant expression with signed char++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105774
--- Comment #9 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:11a37955860f8573570aaf8d9fb0b6e02a3d4d5a
commit r11-10362-g11a37955860f8573570aaf8d9fb0b6e02a3d4d5a
Author: Jakub Jelinek
Date: Mon Oct 24 16:25:29 2022 +0200
c++: Fix up constexpr handling of char/signed char/short pre/post
inc/decrement [PR105774]
signed char, char or short int pre/post inc/decrement are represented by
normal {PRE,POST}_{INC,DEC}REMENT_EXPRs in the FE and only gimplification
ensures that the {PLUS,MINUS}_EXPR is done in unsigned version of those
types:
case PREINCREMENT_EXPR:
case PREDECREMENT_EXPR:
case POSTINCREMENT_EXPR:
case POSTDECREMENT_EXPR:
{
tree type = TREE_TYPE (TREE_OPERAND (*expr_p, 0));
if (INTEGRAL_TYPE_P (type) && c_promoting_integer_type_p (type))
{
if (!TYPE_OVERFLOW_WRAPS (type))
type = unsigned_type_for (type);
return gimplify_self_mod_expr (expr_p, pre_p, post_p, 1, type);
}
break;
}
This means during constant evaluation we need to do it similarly (either
using unsigned_type_for or using widening to integer_type_node).
The following patch does the latter.
2022-10-24 Jakub Jelinek
PR c++/105774
* constexpr.c (cxx_eval_increment_expression): For signed types
that promote to int, evaluate PLUS_EXPR or MINUS_EXPR in int type.
* g++.dg/cpp1y/constexpr-105774.C: New test.
(cherry picked from commit da8c362c4c18cff2f2dfd5c4706bdda7576899a4)
[Bug target/106721] Error: invalid character '<' in mnemonic since r13-2122-g86c0d98620ee3a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106721 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:edf40e86344c407cadca769a6496905a0ec31e48 commit r11-10358-gedf40e86344c407cadca769a6496905a0ec31e48 Author: Jakub Jelinek Date: Wed Aug 24 09:57:09 2022 +0200 i386: Fix up mode iterators that weren't expanded [PR106721] Currently, when md file reader sees and something is valid mode (or code) attribute but which doesn't include case for the current mode (or code), it just keeps the untouched. I went through all cases matching <[a-zA-Z] in tmp-mddump.md after make mddump. One of the cases was related to the V*HF mode additions and there was one typo. 2022-08-24 Jakub Jelinek PR target/106721 * config/i386/sse.md (avx512er_vmrcp28): Fix typo, mask_opernad3 -> mask_operand3. (cherry picked from commit 846e5c009e360f0c4fe58ff0d3aee03ebe3ca1a9)
[Bug c/107001] ICE in expand_gimple_stmt_1, at cfgexpand.cc:4017 since r9-3941-g28567c40e2c7c88e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107001
--- Comment #5 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:8693cafd8975364ef9b409c18ddfc233e66345d8
commit r11-10360-g8693cafd8975364ef9b409c18ddfc233e66345d8
Author: Jakub Jelinek
Date: Sat Sep 24 09:24:26 2022 +0200
openmp: Fix ICE with taskgroup at -O0 -fexceptions [PR107001]
The following testcase ICEs because with -O0 -fexceptions
GOMP_taskgroup_end
call isn't directly followed by GOMP_RETURN statement, but there are some
conditionals to handle exceptions and we fail to find the correct
GOMP_RETURN.
The fix is to treat taskgroup similarly to target data, both of these
constructs
emit a try { body } finally { end_call } around the construct's body during
gimplification and we need to see proper construct nesting during
gimplification
and omp lowering (including nesting of regions checks), but during omp
expansion
we don't really need their nesting anymore, all we need is emit something
at
the start of the region and the end of the region is the end API call we've
already emitted during gimplification. For target data, we weren't adding
GOMP_RETURN statement during omp lowering, so after that pass it is treated
merely like stand-alone omp directives. This patch does the same for
taskgroup too.
2022-09-24 Jakub Jelinek
PR c/107001
* omp-low.c (lower_omp_taskgroup): Don't add GOMP_RETURN statement
at the end.
* omp-expand.c (build_omp_regions_1): Clarify
GF_OMP_TARGET_KIND_DATA
is not stand-alone directive. For GIMPLE_OMP_TASKGROUP, also don't
update parent.
(omp_make_gimple_edges) : Reset
cur_region back after new_omp_region.
* c-c++-common/gomp/pr107001.c: New test.
(cherry picked from commit ad2aab5c816a6fd56b46210c0a4a4c6243da1de9)
[Bug rtl-optimization/106032] [10/11 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106032 --- Comment #14 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:fe6e8a09a5338c0acda23ab2d3ef4433fb83637f commit r11-10354-gfe6e8a09a5338c0acda23ab2d3ef4433fb83637f Author: Jakub Jelinek Date: Tue Jun 21 11:40:16 2022 +0200 ifcvt: Don't introduce trapping or faulting reads in noce_try_sign_mask [PR106032] noce_try_sign_mask as documented will optimize if (c < 0) x = t; else x = 0; into x = (c >> bitsm1) & t; The optimization is done if either t is unconditional (e.g. for x = t; if (c >= 0) x = 0; ) or if it is cheap. We already check that t doesn't have side-effects, but if t is conditional, we need to punt also if it may trap or fault, as we make it unconditional. I've briefly skimmed other noce_try* optimizations and didn't find one that would suffer from the same problem. 2022-06-21 Jakub Jelinek PR rtl-optimization/106032 * ifcvt.c (noce_try_sign_mask): Punt if !t_unconditional, and t may_trap_or_fault_p, even if it is cheap. * gcc.c-torture/execute/pr106032.c: New test. (cherry picked from commit a0c30fe3b888f20215f3e040d21b62b603804ca9)
[Bug debug/106261] [10/11 Regression] ICE in output_call_frame_info, at dwarf2out.cc:943
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106261 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:904b0d0418077c1fe2c3ab328002bba40c6b0271 commit r11-10356-g904b0d0418077c1fe2c3ab328002bba40c6b0271 Author: Jakub Jelinek Date: Wed Jul 27 12:06:22 2022 +0200 cgraphunit: Don't emit asm thunks for -dx [PR106261] When -dx option is used (didn't know we have it and no idea what is it useful for), we just expand functions to RTL and then omit all further RTL passes, so the normal functions aren't actually emitted into assembly, just variables. The following testcase ICEs, because we don't emit the methods, but do emit thunks pointing to that and those thunks have unwind info and rely on at least some real functions to be emitted (which is normally the case, thunks are only emitted for locally defined functions) because otherwise there are no CIEs, only FDEs and dwarf2out is upset about it. The following patch fixes that by not emitting assembly thunks for -dx either. 2022-07-27 Jakub Jelinek PR debug/106261 * cgraphunit.c (cgraph_node::assemble_thunks_and_aliases): Don't output asm thunks for -dx. * g++.dg/debug/pr106261.C: New test. (cherry picked from commit f9671b60f9395cb1dca128b92f5dd215f5aeaae1)
[Bug middle-end/106144] wide_int shifted_mask() and mask() do not agree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106144
--- Comment #6 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:4d853d49202a3b9fdaade64a6d5f920304c2b38d
commit r11-10355-g4d853d49202a3b9fdaade64a6d5f920304c2b38d
Author: Jakub Jelinek
Date: Fri Jul 1 11:17:41 2022 +0200
wide-int: Fix up wi::shifted_mask [PR106144]
As the following self-test testcase shows, wi::shifted_mask sometimes
doesn't create canonicalized wide_ints, which then fail to compare equal
to canonicalized wide_ints with the same value.
In particular, wi::mask (128, false, 128) gives { -1 } with len 1 and prec
128,
while wi::shifted_mask (0, 128, false, 128) gives { -1, -1 } with len 2
and prec 128.
The problem is that the code is written with the assumption that there are
3 bit blocks (or 2 if start is 0), but doesn't consider the possibility
where there are 2 bit blocks (or 1 if start is 0) where the highest block
isn't present. In that case, there is the optional block of negate ? 0 :
-1
elts, followed by just one elt (either one from the if (shift) or just
negate ? -1 : 0) and the rest is implicit sign-extension.
Only if end < prec there is 1 or more bits above it that have different bit
value and so we need to emit all the elts till end and then one more elt.
if (end == prec) would work too, because we have:
if (width > prec - start)
width = prec - start;
unsigned int end = start + width;
so end is guaranteed to be end <= prec, dunno what is preferred.
2022-07-01 Jakub Jelinek
PR middle-end/106144
* wide-int.cc (wi::shifted_mask): If end >= prec, return right
after
emitting element for shift or if shift is 0 first element after
start.
(wide_int_cc_tests): Add tests for equivalency of wi::mask and
wi::shifted_mask with 0 start.
(cherry picked from commit e52592073f6df3d7a3acd9f0436dcc32a8b7493d)
[Bug middle-end/106030] [13 Regression] ice in emit_move_insn, at expr.cc:4026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106030 --- Comment #10 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d9b72d8d03134813d5fa84cffb190027fd29f6d6 commit r11-10353-gd9b72d8d03134813d5fa84cffb190027fd29f6d6 Author: Jakub Jelinek Date: Tue Jun 21 11:38:59 2022 +0200 expand: Fix up expand_cond_expr_using_cmove [PR106030] If expand_cond_expr_using_cmove can't find a cmove optab for a particular mode, it tries to promote the mode and perform the cmove in the promoted mode. The testcase in the patch ICEs on arm because in that case we pass temp which has the promoted mode (SImode) as target to expand_operands where the operands have the non-promoted mode (QImode). Later on the function uses paradoxical subregs: if (GET_MODE (op1) != mode) op1 = gen_lowpart (mode, op1); if (GET_MODE (op2) != mode) op2 = gen_lowpart (mode, op2); to change the operand modes. The following patch fixes it by passing NULL_RTX as target if it has promoted mode. 2022-06-21 Jakub Jelinek PR middle-end/106030 * expr.c (expand_cond_expr_using_cmove): Pass NULL_RTX instead of temp to expand_operands if mode has been promoted. * gcc.c-torture/compile/pr106030.c: New test. (cherry picked from commit 2df1df945fac85d7b3d084001414a66a2709d8fe)
[Bug libgomp/106045] Incorrect testcase in libgomp.c/target-31.c at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106045
--- Comment #4 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:732e2315e6782bfc93241027f01cd3dfbdb5269c
commit r11-10352-g732e2315e6782bfc93241027f01cd3dfbdb5269c
Author: Jakub Jelinek
Date: Tue Jun 21 17:51:08 2022 +0200
libgomp: Fix up target-31.c test [PR106045]
The i variable is used inside of the parallel in:
#pragma omp simd safelen(32) private (v)
for (i = 0; i < 64; i++)
{
v = 3 * i;
ll[i] = u1 + v * u2[0] + u2[1] + x + y[0] + y[1] + v + h[0] +
u3[i];
}
where i is predetermined linear (so while inside of the body
it is safe, private per SIMD lane var) the final value is written to
the shared variable, and in:
for (i = 0; i < 64; i++)
if (ll[i] != u1 + 3 * i * u2[0] + u2[1] + x + y[0] + y[1] + 3 * i +
13 + 14 + i)
#pragma omp atomic write
err = 1;
which is a normal loop and so it isn't in any way privatized there.
So we have a data race, fixed by adding private (i) clause to the
parallel.
2022-06-21 Jakub Jelinek
Paul Iannetta
PR libgomp/106045
* testsuite/libgomp.c/target-31.c: Add private (i) clause.
(cherry picked from commit 85d613da341b76308edea48359a5dbc7061937c4)
[Bug c++/107521] clang rejects invalid code in libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107521 --- Comment #4 from Jakub Jelinek --- And e.g. https://godbolt.org/z/qfzTT5jna from that PR is I think clearly a clang bug, not a grey area, neither string literal is evaluated there multiple times.
[Bug c++/107521] clang rejects invalid code in libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107521
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
http://eel.is/c++draft/expr.eq#3
only talks about unspecified behavior if one is a pointer to a start of an
object and another to one past the end of another.
I believe we implement that in GCC, try e.g.
constexpr const char *f (const char* a, const char *b) {
if (a == b)
return a;
return b;
}
char a, b;
constexpr const char *k = f(, );
constexpr const char *l = f(, + 1);
When string literals are involved, I think this is PR86369 instead, and Jason
said he thinks GCC is correct there, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86369#c8
[Bug c++/107488] [13 Regression] -Werror=dangling-reference false positives in cppunit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107488 --- Comment #4 from Sergei Trofimovich --- Thank you! cppunit-1.15.1 now builds fine with your fix.
[Bug tree-optimization/107523] New: wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107523
Bug ID: 107523
Summary: wrong code at -O2 and -O3 on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
This appears to be a recent regression as 12.2 compiles the test correctly.
Compiler Explorer: https://godbolt.org/z/1erPMzzjK
[522] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
--with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221104 (experimental) [master r13-3645-gfabe470b244] (GCC)
[523] %
[523] % gcctk -Os small.c; ./a.out
[524] %
[524] % gcctk -O2 small.c
[525] % ./a.out
Floating point exception
[526] %
[526] % cat small.c
int a, b = 1;
unsigned int c = 1;
int main() {
int d = 1, f;
if (b)
d = 0;
a = -1;
b = ~d ^ 465984011;
L1:;
if (b < 2)
f = b;
b = f;
if (f <= a) {
int g = -(a && 1), h = g - f && a, i = ~(c / f) && 1 % (a | h);
if (c) {
g = f;
if (i || (g && (g > -465984012)))
goto L2;
}
c = g | f / c;
}
if (0)
L2:
a = 0;
if (a <= c)
goto L1;
return 0;
}
