[Bug tree-optimization/94092] Code size and performance degradations after -ftree-loop-distribute-patterns was enabled at -O[2s]+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94092
--- Comment #15 from rguenther at suse dot de ---
On Fri, 30 Apr 2021, law at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94092
>
> Jeffrey A. Law changed:
>
>What|Removed |Added
>
> CC||law at gcc dot gnu.org
>
> --- Comment #14 from Jeffrey A. Law ---
> WRT Jim's comment about alignments in c#6.
>
> Right now a pointer's alignment is really only used to eliminate unnecessary
> masking -- we don't propagate a pointer's known alignment to improve the known
> alignment of memory operations involving that pointer.
Hmm, but we do - in set_mem_attributes_minus_bitpos. But maybe below
is for way later RTL generation,
> This is something I'd cobbled together for a closely related issue which will
> try to increase the known alignment of a MEM by using the alignment of a
> pointer to that MEM.
>
> We've gone a slightly different (and more effective) route for that internal
> issue, but this may still be worth polishing a bit and submitting.
>
> diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
> index 972512e81..be9ff76b5 100644
> --- a/gcc/emit-rtl.c
> +++ b/gcc/emit-rtl.c
> @@ -859,6 +859,28 @@ gen_rtx_MEM (machine_mode mode, rtx addr)
> we clear it here. */
>MEM_ATTRS (rt) = 0;
>
> + /* If we can deduce a higher alignment for the memory access
> + based on the pointer, then it's advantageous to do so. */
> + unsigned int align = 0;
> + if (REG_P (addr)
> + && REG_POINTER (addr))
> +align = REGNO_POINTER_ALIGN (REGNO (addr));
> + else if (GET_CODE (addr) == PLUS
> + && REG_P (XEXP (addr, 0))
> + && REG_POINTER (XEXP (addr, 0))
> + && REGNO_POINTER_ALIGN (REGNO (XEXP (addr, 0)))
> + && GET_CODE (XEXP (addr, 1)) == CONST_INT)
> +{
> + unsigned int tmp = 1 << (ffs_hwi (INTVAL (XEXP (addr, 1))) - 1);
> + /* ALIGN is in bits. */
> + tmp <<= 3;
> + align = REGNO_POINTER_ALIGN (REGNO (XEXP (addr, 0)));
> + align = (align > tmp) ? tmp : align;
> +}
> +
> + if (align > mode_mem_attrs[(int) mode]->align)
> +set_mem_align (rt, align);
> +
>return rt;
> }
>
>
[Bug c++/100335] Using statement of a ref-qualified method from base class: method not callable on derived object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100335 --- Comment #7 from Daniel --- To me it seems that [over.load] is the right section of the standard as the start of the section explicitly mentions that the rules there (either all or none of the overloads must have ref-qualifiers) applies when a using declaration is involved: "Not all function declarations can be overloaded. Those that cannot be overloaded are specified here. A program is ill-formed if it contains two such non-overloadable declarations in the same scope. [Note:This restriction applies to explicit declarations in a scope, and between such declarations and declarations made through a using-declaration(7.3.3). It does not apply to sets of functions fabricated as a result of name lookup (e.g., because of using-directives) or overload resolution (e.g., for operator functions).— end note]" Could it be that - gcc is on the right track by rejecting the example, but it should also reject the code in the case where the offending method is not called (see Comment 6)? - clang, MSVC are not taking the above note into consideration and thus are missing an error in this case?
[Bug libgomp/100390] New: FAIL: libgomp.fortran/depobj-1.f90 -O execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100390 Bug ID: 100390 Summary: FAIL: libgomp.fortran/depobj-1.f90 -O execution test Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- I ran into: ... Execution timeout is: 300 spawn [open ...]^M STOP 3 FAIL: libgomp.fortran/depobj-1.f90 -O execution test ... Build from commit a13a50047ef "Fortran: Async I/O - avoid unlocked unlocking [PR100352]". Configured like so: ... $ ./build/gcc/xgcc -v Using built-in specs. COLLECT_GCC=./build/gcc/xgcc Target: x86_64-pc-linux-gnu Configured with: /home/vries/gcc_versions/devel/src/configure --disable-bootstrap --enable-languages=c,c++,fortran --disable-multilib --prefix=/home/vries/gcc_versions/devel/install CFLAGS='-O0 -g -Wall' CXXFLAGS='-O0 -g -Wall' Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.0 20210502 (experimental) (GCC) ...
[Bug libgomp/100390] FAIL: libgomp.fortran/depobj-1.f90 -O execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100390 --- Comment #1 from Tom de Vries --- Fails not very often (twice in a run of 100): ... $ for n in $(seq 1 100); do make check "RUNTESTFLAGS=fortran.exp=depobj-1.f90" 2>&1 | grep "expected passes"; done # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes1 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes1 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 ...
[Bug tree-optimization/100382] [12 Regression] go.test/test/fixedbugs/issue16095.go hang since r12-248
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100382
--- Comment #2 from Richard Biener ---
Hum. OK, so DSE would also miss is_ctrl_altering_stmt (DCE checks this which
covers stmt_can_throw_internal). So with non-call-EH we even want to preserve
externally throwing EH? Given there's can_delete_dead_exceptions I wonder
if this applies to call EH as well. Note for this to make a practical
difference the throwing function would need to be pure at least (thus subject
to DCE in the first place).
So - wouldn't a more consistent check be
(!stmt_could_throw_p ()
|| cfun->can_delete_dead_exceptions)
?
int x, y;
int __attribute__((pure,noinline)) foo () { if (x) throw; return y; }
int main()
{
int a[2];
x = 1;
try {
int res = foo ();
a[0] = res;
} catch (...) {
return 0;
}
return 1;
}
should show this but the post-dom domwalk is plagued by the same ordering
issue as the dom domwalk was (we visit dom children in non-"RPO" order,
in this case inverted postorder).
[Bug libgomp/100390] FAIL: libgomp.fortran/depobj-1.f90 -O execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100390 --- Comment #2 from Tom de Vries --- In combination with stress -c 5, I get more FAILs: ... $ for n in $(seq 1 100); do make check "RUNTESTFLAGS=fortran.exp=depobj-1.f90" 2>&1 | grep "expected passes"; done # of expected passes1 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes1 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes1 # of expected passes1 # of expected passes2 # of expected passes1 # of expected passes2 # of expected passes2 # of expected passes1 # of expected passes1 # of expected passes2 # of expected passes1 # of expected passes2 # of expected passes1 # of expected passes1 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes1 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes1 # of expected passes2 # of expected passes1 # of expected passes2 # of expected passes1 # of expected passes2 # of expected passes1 # of expected passes2 # of expected passes2 # of expected passes1 # of expected passes2 # of expected passes2 # of expected passes1 # of expected passes2 # of expected passes2 # of expected passes1 # of expected passes2 # of expected passes1 # of expected passes1 # of expected passes1 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes1 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes1 # of expected passes1 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes1 # of expected passes1 # of expected passes1 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 # of expected passes2 ...
[Bug tree-optimization/100382] [12 Regression] go.test/test/fixedbugs/issue16095.go hang since r12-248
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100382 --- Comment #3 from Richard Biener --- With the following patch this "issue" would show. Not sure why we think a postdom walk is appropriate for DSE rather than a reverse program order one. diff --git a/gcc/tree-ssa-dse.c b/gcc/tree-ssa-dse.c index aecf6ab8c46..5bb5adf43c6 100644 --- a/gcc/tree-ssa-dse.c +++ b/gcc/tree-ssa-dse.c @@ -39,6 +39,7 @@ along with GCC; see the file COPYING3. If not see #include "builtins.h" #include "gimple-fold.h" #include "gimplify.h" +#include "cfganal.h" /* This file implements dead store elimination. @@ -1280,7 +1281,16 @@ pass_dse::execute (function *fun) /* Dead store elimination is fundamentally a walk of the post-dominator tree and a backwards walk of statements within each block. */ dse_dom_walker walker (CDI_POST_DOMINATORS); - walker.walk (fun->cfg->x_exit_block_ptr); + //walker.walk (fun->cfg->x_exit_block_ptr); + int *rpo = XNEWVEC (int, n_basic_blocks_for_fn (fun) - NUM_FIXED_BLOCKS); + auto_bitmap exits; + edge entry = single_succ_edge (ENTRY_BLOCK_PTR_FOR_FN (fun)); + bitmap_set_bit (exits, EXIT_BLOCK); + int n = rev_post_order_and_mark_dfs_back_seme +(fun, entry, exits, true, rpo, NULL); + for (int i = n; i != 0; --i) +walker.before_dom_children (BASIC_BLOCK_FOR_FN (fun, rpo[i-1])); + free (rpo); free_dominance_info (CDI_POST_DOMINATORS); unsigned todo = walker.todo ();
[Bug target/100354] [9/10/11/12 regression] aarch64: non-deligitimized UNSPEC UNSPEC_TLS (76) found in variable location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100354 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.4
[Bug testsuite/100355] gcc.c-torture/execute/ieee/cdivchkld.c needs fmaxl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100355 --- Comment #1 from Richard Biener --- guard the testcase with c99_runtime?
[Bug c++/100362] [11/12 Regression] ICE with Boost.Asio async_initiate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100362 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c/100360] scalar operation fails the compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100360 --- Comment #3 from Richard Biener --- It's more likely that mpfr and/or GMP were configured with a wrong CPU and thus run into the illegal instruction. In the end this is unlikely a GCC problem. Please verify with a debugger.
[Bug c++/100396] New: [11.1 regression] The template function overload is not selected correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100396
Bug ID: 100396
Summary: [11.1 regression] The template function overload is
not selected correctly
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vopl at bk dot ru
Target Milestone: ---
Regression in 11.1.0
$ cat src.cpp && echo EOFFF
/0/1/2/3/4/5/6/7
template
constexpr bool valid = (0 < sizeof(F{}(Args{}...)));
/0/1/2/3/4/5/6/7
template
void ovr(F f, Args... args)
requires valid // external checker - fail, wrong Args formed
//requires (0 < sizeof(F{}(Args{}...))) // inline checker - ok (are wrong Args
compensated by SFINAE?)
{
return ovr(int{}, f, args...); // a second ovr is expected to
be called, but the compiler tries to call this ovr again. Collision between
'int' and 'F' is ignored, extra Args appended from 'f'
}
template void ovr(int, F, Args...){}
/0/1/2/3/4/5/6/7
void use()
{
ovr([]{return 'c';});
}
EOFFF
$ g++-11.1.0 -std=c++20 -c src.cpp
src.cpp: In instantiation of 'constexpr const bool valid,
use():: >':
src.cpp:8:10: required by substitution of 'template
void ovr(F, Args ...) requires valid [with F = use()::;
Args = {use()::}]'
src.cpp:11:27: required from 'void ovr(F, Args ...) requires valid [with F = use()::; Args = {}]'
src.cpp:19:8: required from here
src.cpp:3:39: error: no match for call to '(use()::)
(use()::)'
3 | constexpr bool valid = (0 < sizeof(F{}(Args{}...)));
| ^~~~
src.cpp:3:39: note: candidate: 'char (*)()' (conversion)
src.cpp:3:39: note: candidate expects 1 argument, 2 provided
src.cpp:19:9: note: candidate: 'use()::'
19 | ovr([]{return 'c';});
| ^
src.cpp:19:9: note: candidate expects 0 arguments, 1 provided
$ g++-11.1.0 -v
Using built-in specs.
COLLECT_GCC=g++-11.1.0
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/11.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-11.1.0/work/gcc-11.1.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/11.1.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.1.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.1.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.1.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/g++-v11
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/11.1.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --disable-nls --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 11.1.0 p1'
--disable-esp --enable-libstdcxx-time --with-build-config=bootstrap-lto
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64
--disable-fixed-point --enable-targets=all --enable-libgomp --disable-libssp
--disable-libada --enable-systemtap --disable-valgrind-annotations
--enable-vtable-verify --with-zstd --enable-lto --with-isl
--disable-isl-version-check --enable-default-pie --disable-default-ssp
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.0 (Gentoo 11.1.0 p1)
[Bug c++/100368] Missing guaranteed elision in constexpr evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100368 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||ppalka at gcc dot gnu.org Last reconfirmed||2021-05-03 --- Comment #1 from Patrick Palka --- Confirmed, looks like this never worked.
[Bug c++/100396] [11.1 regression] The template function overload is not selected correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100396
--- Comment #2 from vopl at bk dot ru ---
Please, try this, also failed
/0/1/2/3/4/5/6/7
template struct Checker
{
using Some = decltype(F{}(Args{}...));
};
template concept valid =
requires { typename Checker::Some; };
/0/1/2/3/4/5/6/7
template auto ovr(F f, Args... args)
requires valid
{
return ovr(int{}, f, args...); // a second ovr is expected to
be called, but the compiler tries to call this ovr again. Collision between
'int' and 'F' is ignored, extra Args provided to call
}
template auto ovr(int, F f, Args... args)
{
return f(args...);
}
/0/1/2/3/4/5/6/7
void use()
{
ovr([]{});
}
$ g++-11.1.0 -std=c++20 -c src.cpp
src.cpp: In instantiation of 'struct Checker,
use():: >':
src.cpp:8:25: required by substitution of 'template
auto ovr(F, Args ...) requires valid [with F = use()::;
Args = {use()::}]'
src.cpp:14:27: required from 'auto ovr(F, Args ...) requires valid [with F = use()::; Args = {}]'
src.cpp:25:8: required from here
src.cpp:4:30: error: no match for call to '(use()::)
(use()::)'
4 | using Some = decltype(F{}(Args{}...));
| ~~~^~~
src.cpp:4:30: note: candidate: 'void (*)()' (conversion)
src.cpp:4:30: note: candidate expects 1 argument, 2 provided
src.cpp:25:9: note: candidate: 'use()::'
25 | ovr([]{});
| ^
src.cpp:25:9: note: candidate expects 0 arguments, 1 provided
--
IMHO, the problem is not caused by concepts, but caused by corrupted
overloading selection mechanic. Please, take a look at the collision between
argument 'int{}' and first template parameter specified as 'F'. Next, no SFINAE
expected in this case due to correct overloading, but overloading failed and
SFINAE happens. Thanks.
[Bug libstdc++/100334] atomic::notify_one() sometimes wakes wrong thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334 Thomas Rodgers changed: What|Removed |Added Attachment #50728|0 |1 is obsolete|| --- Comment #7 from Thomas Rodgers --- Created attachment 50740 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50740=edit Fix wrong thread getting notification, take 2 This should fix the issue, submitting patch to mailing list.
[Bug c++/100362] [11/12 Regression] ICE with Boost.Asio async_initiate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100362
--- Comment #4 from Patrick Palka ---
If we remove the unneeded 'this' capture, then it's a rejects-valid bug:
template
struct Qux {
struct A { } a_;
void AsyncOp() {
[](auto) {
struct Grault : decltype(a_) {};
Grault ptr;
}(0);
}
};
void corge() {
Qux qux;
qux.AsyncOp();
}
: In instantiation of ‘struct
Qux::AsyncOp()Grault’:
:11:14: required from ‘Qux::AsyncOp():: [with
auto:1 = int]’
:12:6: required from ‘void Qux< >::AsyncOp()
[with = int]’
:18:14: required from here
:10:32: error: invalid use of non-static data member ‘Qux::a_’
:10:32: error: ‘Qux::A Qux::a_’ is inaccessible within this
context
:6:16: note: declared here
[Bug tree-optimization/100363] gcc generating wider load/store than warranted at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363 --- Comment #16 from Andrew Pinski --- (In reply to Vineet Gupta from comment #15) > The problem is is indeed gone. I need to analyze the assembly fully how it > prevents the bad case. e.g. I'm still not comfortable seeing the loop > entered with following and it doing 8 byte ldd/std when we know it should > only do 2 at a time. Why? It is called a "vectorization" optimization. Where we are vectorizing the 2 byte load/stores into a 4x2 vector load/stores.
[Bug libstdc++/100290] join_view::_Iterator::operator++ copies _M_parent->_M_inner when _S_ref_is_glvalue is false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100290 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Patrick Palka --- Fixed.
[Bug libstdc++/100290] join_view::_Iterator::operator++ copies _M_parent->_M_inner when _S_ref_is_glvalue is false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100290 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:b81834eaf85d5c4e0df8e4fc2307cbdd083dea6c commit r10-9789-gb81834eaf85d5c4e0df8e4fc2307cbdd083dea6c Author: Patrick Palka Date: Tue Apr 27 14:07:46 2021 -0400 libstdc++: Fix up lambda in join_view::_Iterator::operator++ [PR100290] Currently, the return type of this lambda is decltype(auto), so the lambda ends up returning a copy of _M_parent->_M_inner rather than a reference to it when _S_ref_glvalue is false. This means _M_inner and ranges::end(__inner_range) are respectively an iterator and sentinel for different ranges, so comparing them is undefined. libstdc++-v3/ChangeLog: PR libstdc++/100290 * include/std/ranges (join_view::_Iterator::operator++): Correct the return type of the lambda to avoid returning a copy of _M_parent->_M_inner. * testsuite/std/ranges/adaptors/join.cc (test10): New test. (cherry picked from commit 85ef4b8d4eb3313a48b79c7e752891f9646bb246)
[Bug c++/100405] Add implicit 'return *this;' in assignment operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100405
Jonathan Wakely changed:
What|Removed |Added
Summary|missing return assignment |Add implicit 'return
||*this;' in assignment
||operators
Resolution|INVALID |---
Severity|normal |enhancement
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=85523
Last reconfirmed||2021-05-03
Ever confirmed|0 |1
Status|RESOLVED|NEW
--- Comment #2 from Jonathan Wakely ---
It would be nice if G++ would Do The Right Thing here:
struct T
{
T& operator=(const T& t)
{
i = t.i;
/* forgot to write return *this; */
}
int i = 0;
};
If the user forgets to write 'return *this;' in an assignment operator the
results can be quite unpleasant (after optimization).
Similar to the implicit 'return 0;' in main it would be nice to add an implicit
return *this to assignment operators. It could be done in cases where
-Wreturn-type warns (e.g. there isn't a throw or a call to a noreturn function
before the end of the function) and if the return type is decltype(*this).
G++ does give a -Wreturn-type warning for the example above (and since gcc 9 it
adds a fix-it hint, thanks to PR 85523) but for a template it doesn't warn
until it's instantiated:
template
struct T
{
T& operator=(const T& t)
{
i = t.i;
/* forgot to write return *this; */
}
int i = 0;
};
This compiles without a warning (which is PR 48586).
[Bug target/100321] [OpenMP][nvptx, SIMT] (Con't) Reduction fails with optimization and 'loop'/'for simd' but not with 'for'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100321 --- Comment #6 from CVS Commits --- The master branch has been updated by Tom de Vries : https://gcc.gnu.org/g:f87990a2a8fc9e20d30462a0a4c9047582af0cd9 commit r12-395-gf87990a2a8fc9e20d30462a0a4c9047582af0cd9 Author: Tom de Vries Date: Mon May 3 11:36:14 2021 +0200 [openmp, simt] Disable SIMT for user-defined reduction The test-case included in this patch contains this target region: ... for (int i0 = 0 ; i0 < N0 ; i0++ ) counter_N0.i += 1; ... When running with nvptx accelerator, the counter variable is expected to be N0 after the region, but instead is N0 / 32. The problem is that rather than getting the result for all warp lanes, we get it for just one lane. This is caused by the implementation of SIMT being incomplete. It handles regular reductions, but appearantly not user-defined reductions. For now, handle this by disabling SIMT in this case, specifically by setting sctx->max_vf to 1. Tested libgomp on x86_64-linux with nvptx accelerator. gcc/ChangeLog: 2021-05-03 Tom de Vries PR target/100321 * omp-low.c (lower_rec_input_clauses): Disable SIMT for user-defined reduction. libgomp/ChangeLog: 2021-05-03 Tom de Vries PR target/100321 * testsuite/libgomp.c/target-44.c: New test.
[Bug target/100321] [OpenMP][nvptx, SIMT] (Con't) Reduction fails with optimization and 'loop'/'for simd' but not with 'for'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100321 Tom de Vries changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |12.0 Resolution|--- |FIXED --- Comment #7 from Tom de Vries --- Patch committed, marking resolved-fixed.
[Bug libstdc++/100180] experimental/net/internet/address/v6/members.cc fails on arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100180 Christophe Lyon changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from Christophe Lyon --- Fixed.
[Bug c++/46224] Enhancement: Issue warning when matching placement delete operator is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46224 Martin Sebor changed: What|Removed |Added Last reconfirmed|2018-10-01 00:00:00 |2021-5-3 Blocks|87403 |100406 --- Comment #5 from Martin Sebor --- Reconfirming with GCC 11. The release has added -Wmismatched-new-delete. It doesn't detect the problems in any of the test cases but doing so sounds like a useful enhancement to the warning. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100406 [Bug 100406] bogus/missing -Wmismatched-new-delete
[Bug testsuite/100355] gcc.c-torture/execute/ieee/cdivchkld.c needs fmaxl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100355 --- Comment #2 from Christophe Lyon --- Tried that, but it's not taken into account. ieee.exp uses c-torture-execute, maybe that function does not honor dg directives? (none of the tests under ieee/ has a dg- directive)
[Bug c/100404] New: Unable to disable removal of null pointer checks for nonnull function arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100404
Bug ID: 100404
Summary: Unable to disable removal of null pointer checks for
nonnull function arguments
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gccgc at bithub dot de
Target Milestone: ---
Based on the documentation of the "nonnull" function attribute
"-fno-delete-null-pointer-checks" may be used to disable compiler optimizations
based on the knowledge that a function argument cannot be null ([1]).
However, on GCC 10.2 with optimization level 1 (and also on earlier versions
with optimization level 2) the NULL check is eliminated from the following
sample program:
int __attribute__ ((nonnull)) isnull(char *ptr) {
if (ptr == 0)
return 0;
return 1;
}
int main(void) {
return isnull(0);
}
Compiling this sample without optimizations and "-fdelete-null-pointer-checks"
does not eliminate the check so the optimization seems to be triggered by
another optimization.
[1]
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-nonnull-function-attribute
[Bug middle-end/100406] New: bogus/missing -Wmismatched-new-delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100406 Bug ID: 100406 Summary: bogus/missing -Wmismatched-new-delete Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- This is a meta bug for false positives and negatives in and enhancements for -Wmismatched-new-delete.
[Bug middle-end/100406] bogus/missing -Wmismatched-new-delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100406 Martin Sebor changed: What|Removed |Added Last reconfirmed||2021-05-03 Keywords||diagnostic Alias||Wmismatched-new-delete Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Sebor --- -Wmismatched-new-delete was first introduced in GCC 11.1.0.
[Bug c++/86355] [8/9/10/11/12 Regression] Internal compiler error with pack expansion and fold expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86355
Patrick Palka changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
||ppalka at gcc dot gnu.org
Known to fail||5.2.0, 6.4.0
Target Milestone|--- |8.5
Known to work||5.1.0
Summary|Internal compiler error |[8/9/10/11/12 Regression]
|with pack expansion and |Internal compiler error
|fold expression |with pack expansion and
||fold expression
--- Comment #5 from Patrick Palka ---
A reduced valid C++11 testcase:
template struct integral_constant {
static const int value = 1;
};
template using mp_all = integral_constant;
template using check2 = mp_all>>;
check2<> x;
We started ICEing on this one after r6-1487.
[Bug c++/100362] [11/12 Regression] ICE with Boost.Asio async_initiate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100362 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:a32b7d03210f1763a5ccd017181ad88bd95b07d1 commit r11-8344-ga32b7d03210f1763a5ccd017181ad88bd95b07d1 Author: Patrick Palka Date: Mon May 3 13:35:37 2021 -0400 c++: base-clause parsing and implicit 'this' [PR100362] My r11-6815 change to defer access checking when processing a base-clause removed a pair of pushclass / popclass calls that seemed to be unnecessary now that we'd also defer access checking while parsing the base-clause. But it turns out these calls make a difference in the below testcase, where we have a local class whose base-clause implicitly uses the 'this' of the enclosing class. Before r11-6815, while parsing the base-clause of the local class, maybe_resolve_dummy would fail to resolve the dummy 'this' object because the current scope would be the local class. Now, since the current scope is the lambda, maybe_resolve_dummy succeeds and returns the 'this' for the enclosing class Qux. Later, during deferred instantiation of the local class, we get confused trying to resolve the access of 'a_' through this non-dummy 'this'. So this patch just reinstates the calls to pushclass / popclass that were removed in r11-6815. gcc/cp/ChangeLog: PR c++/100362 * parser.c (cp_parser_class_head): Reinstate calls to pushclass and popclass when parsing the base-clause that were removed in r11-6815. gcc/testsuite/ChangeLog: PR c++/100362 * g++.dg/cpp1y/lambda-generic-100362.C: New test. (cherry picked from commit 2a6fc19e655e696bf0df9b7aaedf9848b23f07f3)
[Bug tree-optimization/100404] Unable to disable removal of null pointer checks for nonnull function arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100404
--- Comment #1 from Jonathan Wakely ---
I'm pretty sure what the docs mean is that the compiler will not optimise the
caller to assume that anything passed to the function is non-null. Inside the
function it will still assume the parameter is never null.
So by default the null check here can be removed:
void f(char* p) {
isnull(p);
if (p)
puts(p);
}
The puts call will be done unconditionally, because using p as the argument to
isnull implies it is not null, so the check is redundant.
The option prevents the if (p) check being removed.
[Bug c++/100405] New: missing return assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100405 Bug ID: 100405 Summary: missing return assignment Product: gcc Version: 10.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: ---
[Bug c++/100405] missing return assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100405 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- Oops, I hit enter in the Summary field and submitted this too soon. Please ignore (for now).
[Bug c++/85523] Add fix-it hint for missing return statement in assignment operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85523 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |9.0
[Bug middle-end/100403] Bogus "function may return address of local variable" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100403
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Component|c |middle-end
CC||msebor at gcc dot gnu.org
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #3 from Martin Sebor ---
The warning behaves as designed. There's no way for it tell from the IL that
the function cannot return the address of x:
[local count: 375809640]:
# msg_21 = PHI <"Error w/code"(6), msg_19(10)>
if ( [(void *) + 128B] > msg_21)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 187904820]:
[local count: 1073741824]:
# err_3 = PHI
x ={v} {CLOBBER};
return err_3; <<< -Wreturn-local-addr
[local count: 375809641]:
# msg_19 = PHI <(5), (3)> <<< x is on stack
__builtin_puts (msg_19);
goto ; [100.00%]
}
As Andrew explained, the pointer relational expression is undefined if msg
points to the string literal (changing it to equality avoids the warning). In
addition, and arguably more important, GCC's ability to extract useful
information from pointer relationships is quite limited so it doesn't "see
through" the expression. The underlying problem (and the limitation) can be
reduced to the failure to fold and the false positive for the much simpler test
case below. For a + n to be valid n must be zero or one, and so the function
must return null. If GCC used that to fold the function the warning wouldn't
trigger.
With that, I think the report can be resolved as invalid (I'm sure the pointer
range optimization has its own bug.)
$ cat z.c && gcc -O2 -S -Wall -fdump-tree-isolate-paths=/dev/stdout z.c
void* f (int n)
{
char a[1], *p = a + n;
if (p <= a + 1)
p = 0;
return p;
}
;; Function f (f, funcdef_no=0, decl_uid=1943, cgraph_uid=1, symbol_order=0)
z.c: In function ‘f’:
z.c:6:10: warning: function may return address of local variable
[-Wreturn-local-addr]
6 | return p;
| ^
z.c:3:8: note: declared here
3 | char a[1], *p = a + n;
|^
SSA replacement table
N_i -> { O_1 ... O_j } means that N_i replaces O_1, ..., O_j
p_7 -> { p_2 }
.MEM_8 -> { .MEM_6 }
Incremental SSA update started at block: 2
Number of blocks in CFG: 6
Number of blocks to update: 2 ( 33%)
Removing basic block 3
void * f (int n)
{
char * p;
char a[1];
sizetype _1;
[local count: 1073741824]:
_1 = (sizetype) n_3(D);
p_4 = + _1;
if ( [(void *) + 1B] >= p_4)
goto ; [100.00%]
else
goto ; [0.00%]
[local count: 311385128]:
# p_2 = PHI <0B(2)>
a ={v} {CLOBBER};
return p_2;
[count: 0]:
# p_7 = PHI
a ={v} {CLOBBER};
return 0B;
}
[Bug c++/70834] Incorrect warning for placement new when conditionally used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70834 Martin Sebor changed: What|Removed |Added Last reconfirmed|2017-01-03 00:00:00 |2021-5-3 Blocks||100399 Known to fail|8.0 |11.1.0, 12.0, 8.4.0 --- Comment #7 from Martin Sebor --- No change in GCC 11. This false positive too will be avoided by running -Wplacement-new later, when the program is in SSA form, rather than in the front end. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100399 [Bug 100399] bogus/missing -Wplacement-new
[Bug c/100403] Bogus "function may return address of local variable" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100403 --- Comment #1 from Andrew Pinski --- Note, the following condition in the if statement if (x.rec <= msg && msg < x.rec + sizeof(x)) Is undefined if msg is not in the range of x.rec[0]...x.rec[RECLEN] .
[Bug libstdc++/100384] Compiling in c++17 mode breaks compilation of functions named visit()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100384 --- Comment #5 from Jonathan Wakely --- Possibly, but it needs to be constrained for p2162 anyway, which I'm doing via the return type.
[Bug middle-end/100401] Bogus -Wformat-overflow for a trailing zero-length array of a union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100401 --- Comment #2 from lavr at ncbi dot nlm.nih.gov --- > GCC warnings are designed to "report constructions that are not inherently > erroneous but that are risky or suggest there may have been an error." Certainly, but the [0] size trailing member arrays were specifically devised to be such constructions, TBH. So the warning in this case is like shooting yourself in the foot... Especially when the boundaries are well observed.
[Bug tree-optimization/100366] spurious warning - std::vector::clear followed by std::vector::insert(vec.end(), ...) with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100366 --- Comment #3 from Sam Varshavchik --- If the warning is justified then something else isn't adding up. I double-checked (with cppreference.com) something that I was pretty sure of: and an insert() at the end() iterator is valid. The insert()ed range is valid. If the C++ code is UB, or even potentially UB, I don't see it.
[Bug libstdc++/100351] experimental/net/internet/tcp.cc fails on arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100351 Christophe Lyon changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Christophe Lyon --- Fixed
[Bug c++/100362] [11/12 Regression] ICE with Boost.Asio async_initiate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100362 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Patrick Palka --- Fixed for GCC 11.2 and 12.
[Bug middle-end/100401] Bogus -Wformat-overflow for a trailing zero-length array of a union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100401 Martin Sebor changed: What|Removed |Added Known to fail||10.2.0, 11.1.0 Summary|Bogus -Wformat-overflow |Bogus -Wformat-overflow for |warning |a trailing zero-length ||array of a union CC||msebor at gcc dot gnu.org Status|UNCONFIRMED |NEW Component|c |middle-end Last reconfirmed||2021-05-03 Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Confirmed with GCC 10. The warning is avoided in GCC 11 (since r11-5622). The change is too intrusive to backport and it's seems that the warning doesn't trigger anymore might be incidental to it. It can still be reproduced on trunk but only in C++. I would suggest to expect warnings for tricks like in the test case (writing past subobject boundaries). GCC warnings are designed to "report constructions that are not inherently erroneous but that are risky or suggest there may have been an error." Access warnings like -Warray-bounds, -Wformat-overflow, and -Wstringop-overflow try to accommodate code they have been taught is likely safe but the logic is secondary to helping find bugs, and not foolproof.
[Bug libstdc++/100384] Compiling in c++17 mode breaks compilation of functions named visit()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100384
Jonathan Wakely changed:
What|Removed |Added
Resolution|INVALID |---
Ever confirmed|0 |1
Last reconfirmed||2021-05-03
Status|RESOLVED|NEW
--- Comment #6 from Jonathan Wakely ---
Yes, we can fix this easily without the rest of P2162 (and can backport it):
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -1248,7 +1248,8 @@ namespace __variant
#endif
template
-constexpr decltype(auto) visit(_Visitor&&, _Variants&&...);
+constexpr invoke_result_t<_Visitor, variant_alternative_t<0,
_Variants>...>
+visit(_Visitor&&, _Variants&&...);
template
inline enable_if_t<(is_move_constructible_v<_Types> && ...)
@@ -1736,7 +1737,7 @@ namespace __variant
template
-constexpr decltype(auto)
+constexpr invoke_result_t<_Visitor, variant_alternative_t<0,
_Variants>...>
visit(_Visitor&& __visitor, _Variants&&... __variants)
{
if ((__variants.valueless_by_exception() || ...))
[Bug c/100403] Bogus "function may return address of local variable" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100403 --- Comment #2 from lavr at ncbi dot nlm.nih.gov --- > undefined if msg is not in the range of x.rec[0]...x.rec[RECLEN] Indeed for the segmented data address space. But in most systems it's linear, and the warning is then architecture dependent, and is only expected on those, where the comparison cannot be safely made. Besides, the warning then should be about that fact, not the return address being of a local variable -- that's misleading, at best.
[Bug middle-end/100403] Bogus "function may return address of local variable" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100403 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=91227 --- Comment #4 from Martin Sebor --- The pointer limitation is discussed in more detail in pr91227.
[Bug libstdc++/100286] experimental/net/internet/socket/opt.cc fails on arm-eabi (r12-137)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100286 Christophe Lyon changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Christophe Lyon --- Fixed.
[Bug c++/100405] Add implicit 'return *this;' in assignment operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100405 --- Comment #3 from Jonathan Wakely --- Another option would be to add an implicit __builtin_trap() there. Failing hard is probably preferable to the kind of surprising behaviour you get from the optimizers today.
[Bug c++/100399] New: bogus/missing -Wplacement-new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100399 Bug ID: 100399 Summary: bogus/missing -Wplacement-new Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- This is a meta-bug to track -Wplacement-new false positives, negatives, and enhancements to the warning.
[Bug c/100401] New: Bogus -Wformat-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100401
Bug ID: 100401
Summary: Bogus -Wformat-overflow warning
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lavr at ncbi dot nlm.nih.gov
Target Milestone: ---
$ gcc --version
gcc (GCC) 10.2.0
$ cat bogus.c
#include
#define RECLEN 128
struct S {
int code;
char text[0];
};
const void fun(int n)
{
union {
struct S s;
char rec[RECLEN];
} x;
const char* err;
if (!n) {
err = "No error";
} else {
sprintf(x.s.text, "Error %d", n);
err = x.s.text;
}
printf("%s\n", err);
}
int main(int argc, const char* argv[])
{
fun(argc);
return 0;
}
$ gcc -Wall -O2 bogus.c
bogus.c: In function ‘fun’:
bogus.c:22:28: warning: ‘Error ’ directive writing 6 bytes into a region of
size 0 [-Wformat-overflow=]
22 | sprintf(x.s.text, "Error %d", n);
|^~
bogus.c:22:9: note: ‘sprintf’ output between 8 and 18 bytes into a destination
of size 0
22 | sprintf(x.s.text, "Error %d", n);
| ^~~~
[Bug c/93031] Wish: When the underlying ISA does not force pointer alignment, option to make GCC not assume it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93031 --- Comment #7 from Alexander Monakov --- In comment #2 I touched upon a potentially more practical way to offer -fno-strict-alignment: Run early work with ABI alignments: compute __alignof correctly, lay out composite types as required by ABI, and assign alignments to variables (including stack variables and function parameters). Then make a pass over types and reduce their alignment. This way, optimizations see a universe where types have alignment 1, and variables are defined as if they had an explicit attribute-align with increased alignment (and likewise for structure fields).
[Bug testsuite/100397] New: New test case libgomp.fortran/depobj-1.f90 fails erratically since its introduction in r12-20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100397 Bug ID: 100397 Summary: New test case libgomp.fortran/depobj-1.f90 fails erratically since its introduction in r12-20 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:a61c4964cd71446232d62ec9b10a7d45b440dd9f, r12-20 This test case fails erratically (ever few runs) on powerpc64 since its introduction. I have seen it fail on power 7 BE and power 9 LE machines. make -k check-target-libgomp RUNTESTFLAGS="fortran.exp=libgomp.fortran/depobj-1.f90" FAIL: libgomp.fortran/depobj-1.f90 -O execution test # of expected passes1 # of unexpected failures1 spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/./gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/./gcc/ -B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/bin/ -B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/lib/ -isystem /home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/include -isystem /home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/sys-include exceptions_enabled48342.cc -B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/ -B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/.libs -I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp -I/home/seurer/gcc/git/gcc-test/libgomp/testsuite/../../include -I/home/seurer/gcc/git/gcc-test/libgomp/testsuite/.. -fmessage-length=0 -fno-diagnostics-show-caret -fdiagnostics-color=never -fopenmp -B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/../libquadmath/.libs/ -B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/../libgfortran/.libs -S -o exceptions_enabled48342.s PASS: libgomp.fortran/depobj-1.f90 -O (test for excess errors) Setting LD_LIBRARY_PATH to .:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/.libs:/home/seurer/gcc/git/build/gcc-test/gcc:/home/seurer/gcc/git/build/gcc-test/gcc/32:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/../libgfortran/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/../libquadmath/.libs:/home/seurer/gcc/git/build/gcc-test/./gcc:/home/seurer/gcc/git/build/gcc-test/./gcc/32:.:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/.libs:/home/seurer/gcc/git/build/gcc-test/gcc:/home/seurer/gcc/git/build/gcc-test/gcc/32:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/../libgfortran/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/../libquadmath/.libs:/home/seurer/gcc/git/build/gcc-test/./gcc:/home/seurer/gcc/git/build/gcc-test/./gcc/32:/home/seurer/gcc/git/build/gcc-test/./gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./isl/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-isl/.libs:/home/seurer/gcc/install/gcc-8.3.0/lib64 Execution timeout is: 300 spawn [open ...] STOP 2 FAIL: libgomp.fortran/depobj-1.f90 -O execution test Author: Tobias Burnus Date: Wed Apr 21 10:58:29 2021 +0200 Fortran/OpenMP: Add 'omp depobj' and 'depend(mutexinoutset:'
[Bug tree-optimization/100398] New: [12 Regression] ICE in gimple_redirect_edge_and_branch, at tree-cfg.c:6082
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100398
Bug ID: 100398
Summary: [12 Regression] ICE in
gimple_redirect_edge_and_branch, at tree-cfg.c:6082
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: x86_64-unknown-linux-gnu
gcc-12.0.0-alpha20210502 snapshot (g:92f59e47f5a468b96b12b15233a6729904b1a1ee)
ICEs when compiling the following testcase, reduced from
test/CodeGen/asm-goto.c from the clang 11.1.0 test suite, w/ -O1:
int
test5_limit (void)
{
int addr;
asm goto ("" : "+r" (addr) : : : t_err);
return 0;
t_err:
return 1;
}
% x86_64-unknown-linux-gnu-gcc-12.0.0 -O1 -c xttz2qcb.c
during GIMPLE pass: veclower2
xttz2qcb.c: In function 'test5_limit':
xttz2qcb.c:2:1: internal compiler error: in gimple_redirect_edge_and_branch, at
tree-cfg.c:6082
2 | test5_limit (void)
| ^~~
0x6cfa49 gimple_redirect_edge_and_branch
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/tree-cfg.c:6082
0x9701e9 redirect_edge_and_branch(edge_def*, basic_block_def*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/cfghooks.c:373
0xe610a6 remove_forwarder_block
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/tree-cfgcleanup.c:585
0xe610a6 cleanup_tree_cfg_bb
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/tree-cfgcleanup.c:754
0xe61808 cleanup_tree_cfg_noloop
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/tree-cfgcleanup.c:1103
0xe61808 cleanup_tree_cfg(unsigned int)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/tree-cfgcleanup.c:1187
0xd2bf64 execute_function_todo
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/passes.c:2008
0xd2c89b execute_todo
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/passes.c:2096
[Bug c++/100055] [10/11/12 Regression] ICE on invalid requires expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100055 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Marek Polacek --- Fixed for GCC 12.
[Bug c++/68942] overly strict use of deleted function before argument-dependent lookup (ADL)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68942 --- Comment #4 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:eef4fa6968ae0682679c27dae06409db3d113d5d commit r12-391-geef4fa6968ae0682679c27dae06409db3d113d5d Author: Patrick Palka Date: Mon May 3 13:35:26 2021 -0400 c++: mark_used and ADL with template-id [PR100344] My r11-295 patch for PR68942 didn't consider that the callee of an ADL-eligible function call can be a TEMPLATE_ID_EXPR, and we don't want to disable mark_used when substituting into the template arguments of this TEMPLATE_ID_EXPR because the arguments are clearly used regardless of the outcome of ADL. In the first testcase below, this oversight causes us to trip over the assert in build_call_a for the call to find_index because the function no longer had its TREE_USED bit set from mark_used. So this patch restricts the original fix to disable mark_used only when the callee is a FUNCTION_DECL, which seems to be the only case that matters for PR68942. For instance, in the second testcase below we already don't mark_used the deleted function specialization even before r11-295. gcc/cp/ChangeLog: PR c++/68942 PR c++/100344 * pt.c (tsubst_copy_and_build) : Set tf_conv only when the callee is a FUNCTION_DECL. gcc/testsuite/ChangeLog: PR c++/68942 PR c++/100344 * g++.dg/template/call8.C: New test. * g++.dg/template/koenig12a.C: New test.
[Bug c++/100344] [12 Regression] compiler ICE internal compiler error: in build_call_a, at cp/call.c:38
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100344 --- Comment #11 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:eef4fa6968ae0682679c27dae06409db3d113d5d commit r12-391-geef4fa6968ae0682679c27dae06409db3d113d5d Author: Patrick Palka Date: Mon May 3 13:35:26 2021 -0400 c++: mark_used and ADL with template-id [PR100344] My r11-295 patch for PR68942 didn't consider that the callee of an ADL-eligible function call can be a TEMPLATE_ID_EXPR, and we don't want to disable mark_used when substituting into the template arguments of this TEMPLATE_ID_EXPR because the arguments are clearly used regardless of the outcome of ADL. In the first testcase below, this oversight causes us to trip over the assert in build_call_a for the call to find_index because the function no longer had its TREE_USED bit set from mark_used. So this patch restricts the original fix to disable mark_used only when the callee is a FUNCTION_DECL, which seems to be the only case that matters for PR68942. For instance, in the second testcase below we already don't mark_used the deleted function specialization even before r11-295. gcc/cp/ChangeLog: PR c++/68942 PR c++/100344 * pt.c (tsubst_copy_and_build) : Set tf_conv only when the callee is a FUNCTION_DECL. gcc/testsuite/ChangeLog: PR c++/68942 PR c++/100344 * g++.dg/template/call8.C: New test. * g++.dg/template/koenig12a.C: New test.
[Bug c++/100362] [11/12 Regression] ICE with Boost.Asio async_initiate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100362 --- Comment #5 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:2a6fc19e655e696bf0df9b7aaedf9848b23f07f3 commit r12-392-g2a6fc19e655e696bf0df9b7aaedf9848b23f07f3 Author: Patrick Palka Date: Mon May 3 13:35:37 2021 -0400 c++: base-clause parsing and implicit 'this' [PR100362] My r11-6815 change to defer access checking when processing a base-clause removed a pair of pushclass / popclass calls that seemed to be unnecessary now that we'd also defer access checking while parsing the base-clause. But it turns out these calls make a difference in the below testcase, where we have a local class whose base-clause implicitly uses the 'this' of the enclosing class. Before r11-6815, while parsing the base-clause of the local class, maybe_resolve_dummy would fail to resolve the dummy 'this' object because the current scope would be the local class. Now, since the current scope is the lambda, maybe_resolve_dummy succeeds and returns the 'this' for the enclosing class Qux. Later, during deferred instantiation of the local class, we get confused trying to resolve the access of 'a_' through this non-dummy 'this'. So this patch just reinstates the calls to pushclass / popclass that were removed in r11-6815. gcc/cp/ChangeLog: PR c++/100362 * parser.c (cp_parser_class_head): Reinstate calls to pushclass and popclass when parsing the base-clause that were removed in r11-6815. gcc/testsuite/ChangeLog: PR c++/100362 * g++.dg/cpp1y/lambda-generic-100362.C: New test.
[Bug c++/100344] [12 Regression] compiler ICE internal compiler error: in build_call_a, at cp/call.c:38
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100344 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Patrick Palka --- Fixed.
[Bug tree-optimization/100363] gcc generating wider load/store than warranted at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363 --- Comment #14 from Linus Torvalds --- (In reply to Vineet Gupta from comment #13) > Sorry the workaround proposed by Alexander doesn't seem to cure it (patch > attached), outcome is the same Vineet - it's not the ldd/std that is necessarily buggy, it's the earlier tests of the address that guard that vectorized path. So your quoted parts of the code generation aren't necessarily the problematic ones. Did you actually test the code and check whether it has the same issue? Maybe it changed the address limit guards before that ldd/std? I also sent you a separate patch to test if just upgrading to a newer version of the zlib code helps. Although that may be buggy for other reasons, it's not like I actually tested the end result.. But it would be interesting to hear if that one works for you (again, ldd/std might be a valid end result of trying to vectorize that code assuming the aliasing tests are done correctly in the vectorized loop headers).
[Bug tree-optimization/100363] gcc generating wider load/store than warranted at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363 --- Comment #15 from Vineet Gupta --- (In reply to Linus Torvalds from comment #14) > (In reply to Vineet Gupta from comment #13) > > Sorry the workaround proposed by Alexander doesn't seem to cure it (patch > > attached), outcome is the same > > Vineet - it's not the ldd/std that is necessarily buggy, it's the earlier > tests of the address that guard that vectorized path. > > So your quoted parts of the code generation aren't necessarily the > problematic ones. /me slaps myself. How can I be so stupid. > Did you actually test the code and check whether it has the same issue? > Maybe it changed the address limit guards before that ldd/std? The problem is is indeed gone. I need to analyze the assembly fully how it prevents the bad case. e.g. I'm still not comfortable seeing the loop entered with following and it doing 8 byte ldd/std when we know it should only do 2 at a time. r21 = 0xbf178036 (pre-increment so 0x3e will be first src) r22 = 0xbf1780b2 LPC = 4 80d9a360: lp 12 ;80d9a36c 80d9a364: ldd.a r18r19,[r21,8] 80d9a368: std.ab r18r19,[r22,8] > I also sent you a separate patch to test if just upgrading to a newer > version of the zlib code helps. Although that may be buggy for other > reasons, it's not like I actually tested the end result.. But it would be > interesting to hear if that one works for you (again, ldd/std might be a > valid end result of trying to vectorize that code assuming the aliasing > tests are done correctly in the vectorized loop headers). Thx for that. And this seems to boot as well.
[Bug middle-end/100394] wrong-code with EH and pure/const functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100394 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Last reconfirmed||2021-05-03 Status|UNCONFIRMED |ASSIGNED --- Comment #5 from Richard Biener --- OK, with standard C++ GCC 3.4 doesn't work at -O0 while GCC 4.3+ do but with -O1+ it breaks even with trunk. And the posted patches fix it.
[Bug tree-optimization/100363] gcc generating wider load/store than warranted at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363 --- Comment #13 from Vineet Gupta --- Sorry the workaround proposed by Alexander doesn't seem to cure it (patch attached), outcome is the same mov lp_count,r13;5 #, bnd.65 lp @.L201 ; lp_count:@.L50->@.L201#, .align 2 .L50: # ../lib/zlib_inflate/inffast.c:288: PUP(sout) = PUP(sfrom); ldd.a r18,[r21,8] # MEM[base: _496, offset: 0B], MEM[base: _496, offset: 0B] # ../lib/zlib_inflate/inffast.c:288: PUP(sout) = PUP(sfrom); std.ab r18,[r22,8] # MEM[base: vectp_prephitmp.73_741, offset: 0B], MEM[base: _496, offset: 0B] .align 2 .L201: ; ZOL_END, begins @.L50 #
[Bug target/100402] New: Crash in longjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100402
Bug ID: 100402
Summary: Crash in longjmp
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ssbssa at yahoo dot de
Target Milestone: ---
The following example:
-- >8 --
// gcc -O1 test.c
#include
static jmp_buf buf;
static bool stop = false;
void call_func(void(*func)(void))
{
func();
}
void func()
{
stop = true;
longjmp(buf, 1);
}
int main()
{
setjmp(buf);
while (!stop)
call_func(func);
return 0;
}
-- >8 --
Crashes deep in longjmp():
Starting program: C:\src\tests\a.exe
gdb: unknown target exception 0xc028 at 0x779dd7e8
Program received signal ?, Unknown signal.
0x779dd7e8 in ntdll!RtlRaiseStatus () from
C:\Windows\SYSTEM32\ntdll.dll
(gdb) bt
#0 0x779dd7e8 in ntdll!RtlRaiseStatus () from
C:\Windows\SYSTEM32\ntdll.dll
#1 0x7797f4ec in ntdll!RtlIsDosDeviceName_U () from
C:\Windows\SYSTEM32\ntdll.dll
#2 0x07fefe11e5a3 in msvcrt!longjmp () from C:\Windows\system32\msvcrt.dll
#3 0x00013fe61620 in func ()
#4 0x00013fe61627 in call_func ()
#5 0x00013fe61664 in main ()
#6 0x00013fe61431 in __tmainCRTStartup () at
C:/gcc/src/mingw-w64-v8.0.0/mingw-w64-crt/crt/crtexe.c:345
#7 0x00013fe615b6 in mainCRTStartup () at
C:/gcc/src/mingw-w64-v8.0.0/mingw-w64-crt/crt/crtexe.c:220
Note: Doesn't crash with -O0, or if I change `while (!stop)` to `if (!stop)`.
And it also works fine with gcc-10.2, or if I revert both fixes [1] [2] of
PR99234.
[1]
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=49a714e59194a7c549aa6657676a1b4be4520650
[2]
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=2939b358936bb824330888def98ad848dea41483
[Bug target/100402] Crash in longjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100402 --- Comment #1 from Hannes Domani --- Created attachment 50743 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50743=edit preprocessed code (-E)
[Bug c++/100372] [11/12 Regression] ICE with variadic template template, internal compiler error: in strip_typedefs, at cp/tree.c:1544
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100372 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-05-03 Status|UNCONFIRMED |NEW CC||jason at gcc dot gnu.org, ||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- Thanks for the bug report, confirmed. Started with r11-7931. Reduced reproducer: template using enable_if_t = int; template bool has_P_match_v; template class... List> enable_if_t> a;
[Bug tree-optimization/100391] 128 bit arithmetic --- many unnecessary instructions when extracting smaller parts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100391 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Component|target |tree-optimization Last reconfirmed||2021-05-03 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. There is a missed optimization at the tree level in the first place. The cast to uint32_t is not prograded back through the PHI node. _1 = kt_4 >> 60; if (_1 != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 536870913]: kt_5 = kt_4 & 1152921504606846975; [local count: 1073741824]: # kt_2 = PHI _6 = (uint32_t) kt_2; If it was then the above would have became just: _6 = (uint32_t) kt_4;
[Bug c/100403] New: Bogus "function may return address of local variable" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100403
Bug ID: 100403
Summary: Bogus "function may return address of local variable"
warning
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lavr at ncbi dot nlm.nih.gov
Target Milestone: ---
$ gcc --version
gcc (GCC) 10.2.0
$ cat test.c
#include
#include
#define RECLEN 128
struct R {
int head;
int code;
char text[1];
};
const char* fun(int n, const struct R* p)
{
union {
struct R r;
char rec[RECLEN];
} x;
const char* err = 0;
memset(, 0, sizeof(x));
if (p)
memcpy(, p, sizeof(*p));
else
err = "Invalid argument";
if (!err) {
static const char magic[] = "MAGIC";
const char* msg;
if (memcmp(x.rec, magic, sizeof(magic)-1) == 0)
msg = x.rec;
else if (x.r.text[0])
msg = x.r.text;
else
msg = "Error w/code";
if (msg)
printf("%s\n", msg);
if (x.rec <= msg && msg < x.rec + sizeof(x))
err = "Error detected";
else
err = msg;
} else
printf("%s\n", err);
return err;
}
$ gcc -Wall -O2 -c test.c
test.c: In function ‘fun’:
test.c:45:12: warning: function may return address of local variable
[-Wreturn-local-addr]
45 | return err;
|^~~
test.c:19:7: note: declared here
19 | } x;
| ^
test.c:19:7: note: declared here
Noted that does not matter whether "sizeof(x)" or "sizeof(x.rec)" is used at
the end of the "if()" statement on line 39.
[Bug c++/100374] Type-constraints of member function templates should not be substituted into during implicit instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100374 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2021-05-03 --- Comment #1 from Patrick Palka --- Confirmed.
[Bug c++/100399] bogus/missing -Wplacement-new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100399 Martin Sebor changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-05-03 Status|UNCONFIRMED |NEW Alias||Wplacement-new Keywords||diagnostic, meta-bug Version|11.1.0 |6.1.0 --- Comment #1 from Martin Sebor --- -Wplacement-new was added in GCC 6.1.
[Bug c++/100370] [11/12 Regression] Incorrect warning for placement new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100370
Martin Sebor changed:
What|Removed |Added
Blocks||100399
Last reconfirmed||2021-05-03
Known to fail||11.1.0
Status|UNCONFIRMED |NEW
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Martin Sebor ---
Confirmed. The false positive here is the result of trying to avoid other
false positives for unions and not considering that the pointer might point to
space that's larger than that. Like the false negative in pr100307 comment 2
(AKA pr100325), this would also be prevented by running -Wplacement-new later,
when the program is in SSA form, rather than from the front end.
if (code == COMPONENT_REF)
{
tree ref = TREE_OPERAND (ptr, 0);
if (TREE_CODE (TREE_TYPE (ref)) == UNION_TYPE)
/* In accesses through union types consider the entire unions
rather than just their members. */
ostype = 0;
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100399
[Bug 100399] bogus/missing -Wplacement-new
[Bug c++/100055] [10/11/12 Regression] ICE on invalid requires expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100055 --- Comment #5 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:c9b6890d0b6aa030b307fdb620f8c53ed59ca3b5 commit r12-389-gc9b6890d0b6aa030b307fdb620f8c53ed59ca3b5 Author: Marek Polacek Date: Thu Apr 22 17:32:01 2021 -0400 c++: Fix ICE with invalid requires-expression [PR100055] This fixes a crash on invalid requires-expression: in this test, current_template_parms is null so accessing TEMPLATE_PARMS_CONSTRAINTS is going to fail. So don't crash, but make sure we've complained already. gcc/cp/ChangeLog: PR c++/100055 * decl.c (grokfndecl): Check current_template_parms. gcc/testsuite/ChangeLog: PR c++/100055 * g++.dg/concepts/diagnostic18.C: New test.
[Bug c++/100396] [11.1 regression] The template function overload is not selected correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100396 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- Thanks for the bug report. It looks like we started rejecting this after r11-2774. The testcase is invalid, I think. You need to declare 'valid' as a concept instead of a constexpr variable so that substitution failure during constraint checking of the first overload of 'ovr' is a SFINAE error.
[Bug tree-optimization/100363] gcc generating wider load/store than warranted at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363 --- Comment #10 from Linus Torvalds --- (In reply to Richard Biener from comment #9) > > Note alignment has nothing to do with strict-aliasing (-fno-strict-aliasing > you mean btw). I obviously meant -fno-strict-aliasing, yes. But I think it's actually essentially the same issue, just in a different guise: > One thing we do is (I'm not 50% sure this explains the observed issue) assume > that if you have two accesses with type 'short' and they are aligned > according to this type then they will not partly overlap. Note this has > nothing to do with C strict aliasing rules but is basic pointer math when > you know lower zero bits. Well, the thing is, you have two situations: (a) you can statically see that the two do not alias, because the offset arithmetic is either constant or you have some range logic that can tell that they are sufficiently far apart. (b) you can't. Now, everybody is ok with the static aliasing situation in (a). If you can tell that two addresses don't alias, your'e done, they are independent, there's no question about it. But that's not the situation here. So we're in (b). And what I find personally so annoying is that gcc has actually *done* that distance check, but apparently intentionally done it badly based on type information. And the reason I think this is similar to -fno-strict-aliasing is that it's that same (b) case, and it looks like a very similar "do a bad job of doing actual run-time alias analysis based on type information". It seems to be literally an off-by-one error, not because it generates better code, but because the compiler has decided to pointlessly make a bad range comparison based on type. But I've never worked with the gcc IR dumps, so Andrew Pinski's debug output in #c5 doesn't actually make me go "ahh, there". Maybe it's that 8 vs 6 that he pointed out. Did somebody notice that "offset > 8" was off-by-one, and should have been "offset >= 8"? And then changed it to "offset > 6" which is off-by-one in the other direction instead? > I suggest to try the fix suggested in comment#7 and report back if that > fixes the observed issue. Vineet? I still think gcc is doing the wrong thing, exactly because of that "pointlessly using the wrong range check" issue. This particular code comes from some old version of zlib, and I can't test because I don't have the ARC background to make any sense of the generated code.
[Bug middle-end/100395] Bogus -Wstringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100395 Martin Sebor changed: What|Removed |Added Blocks||88443 Component|c |middle-end Resolution|--- |FIXED Known to fail||10.3.0 Keywords||diagnostic CC||msebor at gcc dot gnu.org Last reconfirmed||2021-5-3 Known to work||11.1.0, 9.3.0 Status|UNCONFIRMED |RESOLVED --- Comment #1 from Martin Sebor --- Fixed in r11-1183. The fix is not suitable for backporting to GCC 10. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 [Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 100395, which changed state. Bug 100395 Summary: Bogus -Wstringop-overflow warning https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100395 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/100363] gcc generating wider load/store than warranted at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363 --- Comment #11 from Linus Torvalds --- (In reply to Linus Torvalds from comment #10) > > This particular code comes > from some old version of zlib, and I can't test because I don't have the ARC > background to make any sense of the generated code. Heh. We upgraded to a "recent version" of zlib back in 2006: "Upgrade the zlib_inflate implementation in the kernel from a patched version 1.1.3/4 to a patched 1.2.3" but it turns out that the "do things a 16-bit word at a time" was a kernel-local optimization for some very slow old PowerPC microcontroller. The code in upstream zlib actually looks rather better (which is not saying much, admittedly), doesn't have any 16-bit accesses, and we probably should just try to synchronize with that instead.
[Bug tree-optimization/94589] Optimize (i<=>0)>0 to i>0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94589 Jakub Jelinek changed: What|Removed |Added Attachment #50719|0 |1 is obsolete|| Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #19 from Jakub Jelinek --- Created attachment 50741 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50741=edit gcc12-pr94589.patch Full untested patch.
[Bug tree-optimization/100363] gcc generating wider load/store than warranted at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363 --- Comment #12 from Vineet Gupta --- Created attachment 50742 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50742=edit kernel patch as proposed on comment #7
[Bug tree-optimization/100366] spurious warning - std::vector::clear followed by std::vector::insert(vec.end(), ...) with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100366
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #2 from Martin Sebor ---
The warning is issued during expansion of the memcpy call. It seems fishy that
although it mentions __builtin_memcpy it points to __builtin_memmove:
error: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’ writing
1 or more bytes into a region of size 0 overflows the destination
[-Werror=stringop-overflow=]
431 | __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
| ~^~~
The IL looks like the warning is justified:
void func (struct vector & vec)
{
const ptrdiff_t _Num;
char * _6;
char * _7;
char * prephitmp_16;
char * _21;
long int _23;
long unsigned int _24;
sizetype prephitmp_31;
char * _36;
char * _38;
char * prephitmp_42;
char * _50;
long unsigned int _Num.10_52;
char * _54;
char * _61;
char * pretmp_67;
long int _69;
char * pretmp_70;
long int _71;
unsigned int pretmp_72;
unsigned int _89;
char * _90;
char * _98;
char * _101;
long unsigned int _112;
char * _116;
long unsigned int _144;
long int _146;
char * _147;
char * _155;
sizetype _157;
char * _158;
[local count: 1073741824]:
_6 = vec_2(D)->D.33449._M_impl.D.32762._M_start;
_7 = vec_2(D)->D.33449._M_impl.D.32762._M_finish;
if (_6 != _7)
goto ; [70.00%]
else
goto ; [30.00%]
[local count: 322122544]:
_21 = vec_2(D)->D.33449._M_impl.D.32762._M_end_of_storage;
_23 = _21 - _7;
_24 = (long unsigned int) _23;
if (_24 > 3)
goto ; [67.00%]
else
goto ; [33.00%]
[local count: 751619281]:
vec_2(D)->D.33449._M_impl.D.32762._M_finish = _6;
_147 = vec_2(D)->D.33449._M_impl.D.32762._M_end_of_storage;
_146 = _147 - _6;
_144 = (long unsigned int) _146;
if (_144 > 3)
goto ; [67.00%]
else
goto ; [33.00%]
[local count: 237404317]:
# prephitmp_16 = PHI <_7(3), _6(4)>
_89 = MEM [(char * {ref-all})];
MEM [(char * {ref-all})prephitmp_16] = _89;
_36 = vec_2(D)->D.33449._M_impl.D.32762._M_finish;
_38 = _36 + 4;
vec_2(D)->D.33449._M_impl.D.32762._M_finish = _38;
goto ; [100.00%]
[local count: 108584968]:
__builtin_memmove (_90, pretmp_67, _157);
MEM [(char * {ref-all})_155] = pretmp_72;
_116 = vec_2(D)->D.33449._M_impl.D.32762._M_finish;
_Num_117 = _116 - prephitmp_42;
if (_Num_117 != 0)
goto ; [33.00%] >>> _Num_117 != 0
else
goto ; [67.00%]
[local count: 220460391]:
MEM [(char * {ref-all})_155] = pretmp_72;
_50 = vec_2(D)->D.33449._M_impl.D.32762._M_finish;
_Num_51 = _50 - prephitmp_42;
if (_Num_51 != 0)
goto ; [33.00%] >>> _Num_51 != 0
else
goto ; [67.00%]
[local count: 108584968]:
# _Num_119 = PHI <_Num_51(7), _Num_117(6)> <<< _Num_119 != 0
_Num.10_52 = (long unsigned int) _Num_119;
__builtin_memcpy (_61, prephitmp_42, _Num.10_52); <<< -Wstringop-overflow
[local count: 256293430]:
# prephitmp_31 = PHI <0(7), _Num.10_52(8)>
_54 = _61 + prephitmp_31;
if (pretmp_67 != 0B)
goto ; [40.26%]
else
goto ; [59.74%]
[local count: 175940553]:
# _98 = PHI <_54(9), _61(6)>
_71 = pretmp_70 - pretmp_67;
_112 = (long unsigned int) _71;
operator delete (pretmp_67, _112);
[local count: 329045359]:
# _101 = PHI <_54(9), _98(10)>
vec_2(D)->D.33449._M_impl.D.32762._M_start = _90;
vec_2(D)->D.33449._M_impl.D.32762._M_finish = _101;
vec_2(D)->D.33449._M_impl.D.32762._M_end_of_storage = _158;
[local count: 1048452384]:
return;
[local count: 230225493]:
# prephitmp_42 = PHI <_6(4), _7(3)>
_90 = operator new (4); <<< _90 is 4 bytes
pretmp_67 = vec_2(D)->D.33449._M_impl.D.32762._M_start;
_69 = prephitmp_42 - pretmp_67;
_157 = (sizetype) _69;
_158 = _90 + 4;
pretmp_70 = vec_2(D)->D.33449._M_impl.D.32762._M_end_of_storage;
_155 = _90 + _157; <<< _155 is in [_90, _90
+ 4]
_61 = _155 + 4; <<< _61 = _90 + 4
pretmp_72 = MEM [(char * {ref-all})];
if (_69 != 0)
goto ; [58.89%]
else
goto ; [41.11%]
}
In the translation unit the warning is triggered by a call to the __copy_m()
function below:
template
struct __copy_move<_IsMove, true, random_access_iterator_tag>
{
template
static _Tp*
__copy_m(const _Tp* __first, const _Tp* __last, _Tp* __result)
{
using __assignable = conditional<_IsMove,
is_move_assignable<_Tp>,
is_copy_assignable<_Tp>>;
static_assert( __assignable::type::value, "type is not assignable" );
const ptrdiff_t _Num = __last - __first;
if (_Num)
[Bug c++/100396] [11.1 regression] The template function overload is not selected correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100396
--- Comment #3 from Patrick Palka ---
(In reply to vopl from comment #2)
> Please, try this, also failed
>
> /0/1/2/3/4/5/6///
> //7
> template struct Checker
> {
> using Some = decltype(F{}(Args{}...));
> };
>
> template concept valid =
> requires { typename Checker::Some; };
>
> /0/1/2/3/4/5/6///
> //7
> template auto ovr(F f, Args... args)
> requires valid
> {
> return ovr(int{}, f, args...); // a second ovr is expected
> to be called, but the compiler tries to call this ovr again. Collision
> between 'int' and 'F' is ignored, extra Args provided to call
> }
>
> template auto ovr(int, F f, Args... args)
> {
> return f(args...);
> }
>
> /0/1/2/3/4/5/6///
> //7
> void use()
> {
> ovr([]{});
> }
>
>
> $ g++-11.1.0 -std=c++20 -c src.cpp
> src.cpp: In instantiation of 'struct Checker,
> use():: >':
> src.cpp:8:25: required by substitution of 'template Args> auto ovr(F, Args ...) requires valid [with F =
> use()::; Args = {use()::}]'
> src.cpp:14:27: required from 'auto ovr(F, Args ...) requires valid Args ...> [with F = use()::; Args = {}]'
> src.cpp:25:8: required from here
> src.cpp:4:30: error: no match for call to '(use()::)
> (use()::)'
> 4 | using Some = decltype(F{}(Args{}...));
> | ~~~^~~
> src.cpp:4:30: note: candidate: 'void (*)()' (conversion)
> src.cpp:4:30: note: candidate expects 1 argument, 2 provided
> src.cpp:25:9: note: candidate: 'use()::'
>25 | ovr([]{});
> | ^
> src.cpp:25:9: note: candidate expects 0 arguments, 1 provided
>
> --
> IMHO, the problem is not caused by concepts, but caused by corrupted
> overloading selection mechanic. Please, take a look at the collision between
> argument 'int{}' and first template parameter specified as 'F'. Next, no
> SFINAE expected in this case due to correct overloading, but overloading
> failed and SFINAE happens. Thanks.
Although the collision between 'int{}' and the template argument for 'F' does
mean that the first overload ultimately isn't viable, the compiler as per
CWG2369 first needs to check the overload's constraints (using the
provided/deduced template arguments) _before_ checking whether 'int' is
convertible to 'F', and it's during this constraint checking we hit the hard
error. So as far as I can tell, the compiler is behaving as specified. See
also PR99599 and its related PRs.
[Bug libstdc++/100384] Compiling in c++17 mode breaks compilation of functions named visit()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100384 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #4 from Patrick Palka --- Hmm, isn't problem here ultimately that std::visit is specified to have a concrete SFINAE-friendly return type, but our implementation uses a deduced return type?
[Bug tree-optimization/100400] New: ICE in visit_loops_in_gang_single_region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100400
Bug ID: 100400
Summary: ICE in visit_loops_in_gang_single_region
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: openacc
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
g++-12.0.0-alpha20210502 snapshot (g:92f59e47f5a468b96b12b15233a6729904b1a1ee)
ICEs when compiling the following testcase, reduced from
libgomp/testsuite/libgomp.oacc-c-c++-common/kernels-decompose-1.c, w/ -O1
-fopenacc -g --param openacc-kernels=decompose:
int *p;
void
foo (void)
{
#pragma acc kernels
{
int c;
p =
#pragma acc loop independent
for (c = 0; c < 1; ++c)
;
}
}
% g++-12.0.0 -O1 -fopenacc -g --param openacc-kernels=decompose -c uupipzvt.c
during GIMPLE pass: omp_oacc_kernels_decompose
uupipzvt.c: In function 'void foo()':
uupipzvt.c:14:7: internal compiler error: in visit_loops_in_gang_single_region,
at omp-oacc-kernels-decompose.cc:242
14 | ;
| ^
0x8b682a visit_loops_in_gang_single_region
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/omp-oacc-kernels-decompose.cc:242
0x8b682a visit_loops_in_gang_single_region
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/omp-oacc-kernels-decompose.cc:230
0xe16a2a walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/gimple-walk.c:578
0xe16c70 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/gimple-walk.c:51
0xe16b39 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/gimple-walk.c:641
0xe16c70 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/gimple-walk.c:51
0xe16d03 walk_gimple_seq(gimple*, tree_node* (*)(gimple_stmt_iterator*, bool*,
walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/gimple-walk.c:81
0x1bf9048 make_loops_gang_single
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/omp-oacc-kernels-decompose.cc:290
0x1bf9048 make_region_seq
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/omp-oacc-kernels-decompose.cc:331
0x1bfb60c decompose_kernels_region_body
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/omp-oacc-kernels-decompose.cc:1336
0x1bfb60c omp_oacc_kernels_decompose_1
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/omp-oacc-kernels-decompose.cc:1453
0x1bfb60c omp_oacc_kernels_decompose_callback_stmt
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/omp-oacc-kernels-decompose.cc:1478
0xe16a2a walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/gimple-walk.c:578
0xe16c70 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/gimple-walk.c:51
0xe16b15 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/gimple-walk.c:685
0xe16c70 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/gimple-walk.c:51
0x1bf89d6 omp_oacc_kernels_decompose
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/omp-oacc-kernels-decompose.cc:1495
0x1bf89d6 execute
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/omp-oacc-kernels-decompose.cc:1534
[Bug target/100402] Crash in longjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100402 --- Comment #3 from Hannes Domani --- Created attachment 50745 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50745=edit output of -fdump-tree-optimized
[Bug target/100402] Crash in longjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100402 --- Comment #2 from Hannes Domani --- Created attachment 50744 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50744=edit assembly (-S)
[Bug tree-optimization/91914] [9 Regression] Invalid strlen optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91914 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Martin Sebor --- (In reply to Richard Biener from comment #7) > It's not clear to me which rev. fixed this for GCC 10, but we should > backport the fix to GCC 9 please. It was fixed in r274837. The change isn't completely isolated and affects warnings which is why I suggested the much more targeted fix in comment #2. I committed it in r9-9501.
[Bug tree-optimization/83819] [meta-bug] missing strlen optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819 Bug 83819 depends on bug 91914, which changed state. Bug 91914 Summary: [9 Regression] Invalid strlen optimization https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91914 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug libfortran/99210] X editing for reading file with encoding='utf-8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99210 --- Comment #4 from Jerry DeLisle --- I think the patch works fine as is as far as I can tell. There will be a similar fix for writing files with encoding='utf8'
[Bug c++/100405] Add implicit 'return *this;' in assignment operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100405 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- That is already supported with -fsanitize-undefined-trap-on-error -fsanitize=unreachable or -fsanitize=unreachable. It isn't always the best choice though, e.g. for functions with switches or ifs where the compiler can't prove it doesn't fallthru into end of function but the user is certain, having __builtin_trap or __ubsan_handle_builtin_unreachable is certainly more expensive than __builtin_unreachable.
[Bug libstdc++/100334] atomic::notify_one() sometimes wakes wrong thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334 Thomas Rodgers changed: What|Removed |Added Status|WAITING |ASSIGNED
[Bug libstdc++/100334] atomic::notify_one() sometimes wakes wrong thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334 Thomas Rodgers changed: What|Removed |Added Keywords||patch --- Comment #8 from Thomas Rodgers --- Candidate patch submitted to mailing list - https://gcc.gnu.org/pipermail/libstdc++/2021-May/052464.html
[Bug testsuite/100407] New: New test cases attr-retain-*.c fail after their introduction in r11-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100407 Bug ID: 100407 Summary: New test cases attr-retain-*.c fail after their introduction in r11-7284 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:6347f4a0904fce17eedf5c071be6f3c118680290, r11-7284 These attr-retain-*.c test cases fail on powerpc64 BE. FAIL: gcc.c-torture/compile/attr-retain-1.c -O0 scan-assembler .rodata.*,"aR" FAIL: gcc.c-torture/compile/attr-retain-1.c -O1 scan-assembler .rodata.*,"aR" FAIL: gcc.c-torture/compile/attr-retain-1.c -O2 scan-assembler .rodata.*,"aR" FAIL: gcc.c-torture/compile/attr-retain-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none scan-assembler .rodata.*,"aR" FAIL: gcc.c-torture/compile/attr-retain-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects scan-assembler .rodata.*,"aR" FAIL: gcc.c-torture/compile/attr-retain-1.c -O3 -g scan-assembler .rodata.*,"aR" FAIL: gcc.c-torture/compile/attr-retain-1.c -Os scan-assembler .rodata.*,"aR" FAIL: gcc.c-torture/compile/attr-retain-2.c -O0 scan-assembler .rodata.used_rodata,"aR" FAIL: gcc.c-torture/compile/attr-retain-2.c -O0 scan-assembler .rodata.used_rodata2,"aR" FAIL: gcc.c-torture/compile/attr-retain-2.c -O1 scan-assembler .rodata.used_rodata,"aR" FAIL: gcc.c-torture/compile/attr-retain-2.c -O1 scan-assembler .rodata.used_rodata2,"aR" FAIL: gcc.c-torture/compile/attr-retain-2.c -O2 scan-assembler .rodata.used_rodata,"aR" FAIL: gcc.c-torture/compile/attr-retain-2.c -O2 scan-assembler .rodata.used_rodata2,"aR" FAIL: gcc.c-torture/compile/attr-retain-2.c -O2 -flto -fno-use-linker-plugin -flto-partition=none scan-assembler .rodata.used_rodata,"aR" FAIL: gcc.c-torture/compile/attr-retain-2.c -O2 -flto -fno-use-linker-plugin -flto-partition=none scan-assembler .rodata.used_rodata2,"aR" FAIL: gcc.c-torture/compile/attr-retain-2.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects scan-assembler .rodata.used_rodata,"aR" FAIL: gcc.c-torture/compile/attr-retain-2.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects scan-assembler .rodata.used_rodata2,"aR" FAIL: gcc.c-torture/compile/attr-retain-2.c -O3 -g scan-assembler .rodata.used_rodata,"aR" FAIL: gcc.c-torture/compile/attr-retain-2.c -O3 -g scan-assembler .rodata.used_rodata2,"aR" FAIL: gcc.c-torture/compile/attr-retain-2.c -Os scan-assembler .rodata.used_rodata,"aR" FAIL: gcc.c-torture/compile/attr-retain-2.c -Os scan-assembler .rodata.used_rodata2,"aR" I thought I saw some other ones earlier but these are the ones failing now in trunk and gcc 11. Author: H.J. Lu Date: Mon Feb 15 11:31:12 2021 -0800 Add retain attribute to place symbols in SHF_GNU_RETAIN section
[Bug libstdc++/100334] atomic::notify_one() sometimes wakes wrong thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334 Thomas Rodgers changed: What|Removed |Added Status|ASSIGNED|WAITING
[Bug tree-optimization/91914] [9 Regression] Invalid strlen optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91914 --- Comment #8 from CVS Commits --- The releases/gcc-9 branch has been updated by Martin Sebor : https://gcc.gnu.org/g:176e7fa198dd50aca4c882c74fc8f4386a3f9131 commit r9-9501-g176e7fa198dd50aca4c882c74fc8f4386a3f9131 Author: Martin Sebor Date: Mon May 3 18:10:03 2021 -0600 Minimal change to avoid incorrect strlen constant folding (PR 91914). gcc/ChangeLog: PR tree-optimization/91914 * expr.c (string_constant): Pass argument type to fold_ctor_reference to guide it. gcc/testsuite/ChangeLog: PR tree-optimization/91914 * gcc.dg/strlenopt-79.c: New test.
[Bug tree-optimization/100363] gcc generating wider load/store than warranted at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #9 from Richard Biener --- (In reply to Linus Torvalds from comment #8) > (In reply to Alexander Monakov from comment #7) > > > > Most likely the issue is that sout/sfrom are misaligned at runtime, while > > the vectorized code somewhere relies on them being sufficiently aligned for > > a 'short'. > > They absolutely are. > > And we build the kernel with -Wno-strict-aliasing exactly to make sure the > compiler doesn't think that "oh, I can make aliasing decisions based on type > information". > > Because we have those kinds of issues all over, and we know which > architectures support unaligned loads etc, and all the tricks with > "memcpy()" and unions make for entirely unreadable code. > > So please fix the aliasing logic to not be type-based when people explicitly > tell you not to do that. > > Linus Note alignment has nothing to do with strict-aliasing (-fno-strict-aliasing you mean btw). One thing we do is (I'm not 50% sure this explains the observed issue) assume that if you have two accesses with type 'short' and they are aligned according to this type then they will not partly overlap. Note this has nothing to do with C strict aliasing rules but is basic pointer math when you know lower zero bits. I suggest to try the fix suggested in comment#7 and report back if that fixes the observed issue.
[Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #46 from Iain Sandoe --- Created attachment 50737 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50737=edit trial patch for testing looking at the way other ports handle things like use of registers in veneers etc. it seems that adding to clobbers in the call lowering is a usable mechanism. This patch does seem the DTRT on gcc-10.3 when tested against the original code (although the patch is against master). Otherwise, this is as yet untested ..
[Bug c/93031] Wish: When the underlying ISA does not force pointer alignment, option to make GCC not assume it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93031 --- Comment #6 from Richard Biener --- It's still UB. Note that GCC has for a _long_ time made this assumption - just the places we take advantage of it have grown. Note it would be _very_ difficult to provide a -fno-strict-alignment option because we can't really make all data types unaligned since that would break the ABI. So instead we'd have to sprinkle flag_strict_alignment checks all over the place so I'm very sure you won't get a "fixed" compiler and you might get one that doesn't adhere to the platform ABI any more (in case we put one flag_strict_alignment too many).
[Bug c++/100370] [11/12 Regression] Incorrect warning for placement new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100370 Richard Biener changed: What|Removed |Added Summary|[11.1.0 regression] |[11/12 Regression] |Incorrect warning for |Incorrect warning for |placement new |placement new Target Milestone|--- |11.2 Version|unknown |11.1.0
[Bug c++/100372] [11/12 Regression] ICE with variadic template template, internal compiler error: in strip_typedefs, at cp/tree.c:1544
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100372 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.2 Keywords||ice-on-valid-code Summary|ICE with variadic template |[11/12 Regression] ICE with |template, internal compiler |variadic template template, |error: in strip_typedefs, |internal compiler error: in |at cp/tree.c:1544 |strip_typedefs, at ||cp/tree.c:1544
[Bug bootstrap/100373] [12 Regression] Darwin, Compare-debug fail after r12-248-gb58dc0b803057
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100373 Richard Biener changed: What|Removed |Added Status|NEW |UNCONFIRMED Ever confirmed|1 |0 CC||rguenth at gcc dot gnu.org Target Milestone|--- |12.0 Version|unknown |12.0
[Bug target/100375] [12 Regression] trunk 20210501 ftbfs for nvptx-none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100375 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0 Version|11.0|12.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #6 from Richard Biener --- Fixed.
