Re:Re : inquiry
Dear Sir /Madam , Good day ! This is Mrs .chen from a trading company specializing in import. we have been in this area for over 10 years , we are very interested in your products .please send us your catalog , we will choose we need . waiting for your reply . Chen At 2021-11-24 21:54:48, "Mrs. Chen" wrote: Dear Sir /Madam , This is Mrs .chen from a trading company specializing in import. we have been in this area for over 10 years , we are very interested in your products .please send us your catalog , we will choose we need . waiting for your reply . Mrs.chen
[Bug c++/104046] New: C++ compiler should forbid throw move-only type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104046
Bug ID: 104046
Summary: C++ compiler should forbid throw move-only type
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fsb4000 at yandex dot ru
Target Milestone: ---
Hello.
We were reported a bug: https://github.com/microsoft/STL/issues/2466
But we think that the report is wrong.
Code:
#include
#include
using namespace std;
class C {
public:
C() = default;
C(const C&) = delete;
C& operator=(const C&) = delete;
C(C&&) = default;
C& operator=(C&&) = default;
private:
string m;
};
int main() {
exception_ptr eptr;
try {
throw C();
} catch (const C&) {
eptr = std::current_exception();
}
try {
rethrow_exception(eptr);
} catch (const C&) {
}
}
godbolt: https://godbolt.org/z/GKTGbjbvK
We think that C++ compiler should reject the program because the program
violates [except.throw]/5: https://eel.is/c++draft/except.throw#5
Quote: "When the thrown object is a class object, the constructor selected for
the copy-initialization as well as the constructor selected for a
copy-initialization considering the thrown object as an lvalue shall be
non-deleted and accessible, even if the copy/move operation is elided"
We decided to notify developers of other C++ compilers too.
[Bug libstdc++/101037] C++20 std::atomic_flag deadlock on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101037
Pekka S changed:
What|Removed |Added
CC||p...@gcc-bugzilla.mail.kaps
||i.fi
--- Comment #3 from Pekka S ---
Created attachment 52203
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52203=edit
Ensure _M_ver and _M_cv/_M_mtx are synchronized
Hi.
I suspect this is not a w64-mingw32 specific error but present on all platforms
that do not define _GLIBCXX_HAVE_PLATFORM_WAIT.
If I have not mistaken the problem lies within __waiter_pool::_M_do_wait and
that _M_ver and _M_cv/_M_mtx are not properly synchronized:
stdlibc++v3/include/bits/atomic_wait.h:
254 void
255 _M_do_wait(const __platform_wait_t* __addr, __platform_wait_t __old)
noexcept
256 {
257 #ifdef _GLIBCXX_HAVE_PLATFORM_WAIT
258 __platform_wait(__addr, __old);
259 #else
260 __platform_wait_t __val;
261 __atomic_load(__addr, &__val, __ATOMIC_RELAXED);
262 if (__val == __old)
263 {
264 lock_guard __l(_M_mtx);
265 _M_cv.wait(_M_mtx);
266 }
267 #endif // __GLIBCXX_HAVE_PLATFORM_WAIT
268 }
In this case _GLIBCXX_HAVE_PLATFORM_WAIT is not defined and __addr will point
to __waiter_pool_base::_M_ver (I do not know why it is called ver). _M_ver is
used to indicate if a thread has been notified. __old is the value of _M_ver
when the conditional wait was entered at __waiter::_M_do_wait_v or
__waiter::_M_do_wait.
(__waiter and __waiter_pool are different classes, __waiter::_M_do_wait calls
__waiter__pool::_M_do_wait unless a predicate on which to wait passes.)
310 if (_M_laundered())
311 {
312 __atomic_fetch_add(_M_addr, 1, __ATOMIC_ACQ_REL);
313 __all = true;
314 }
Each time a thread is notified _M_ver is incremented by one. _M_laundered
simply checks if _M_addr is equal to _M_ver (of __waiter_base::_M_w).
This is where the problem is: A waiting thread might observe a (soon-to-be)
stale value which is equal to __old. This is because between __atomic_load and
_M_cv.wait the value of _M_ver might change. So, in other words,
_M_cv.notify_all (note that notify_one never actually happens since __all is
forced as true) might occur before _M_cv.wait is properly registered and/or
actually waiting.
As __waiter_bool::_M_do_wait can only observe _M_ver (e.g. not a value of
atomic_flag on which the user expects the wait to happen) it must not wait
based on a stale information -- so, it absolutely must not miss any notifies,
or it will not be able to return to __waiter::_M_do_wait which does the
predicate level checking.
My suggestion is that __l(_M_mtx) shall be moved outside the `if (__val ==
__old)' block and _M_ver shall be only modified if the _M_mtx mutex is held.
Since _M_cv.wait(_M_mtx) releases the mutex when the thread is actually waiting
this should "just work".
Attached patch does that and bit more: _M_laundered is moved from
__waiter_base to __waiter_pool_base since it must be able to access _M_mtx.
_M_enter_notify is added along with _M_enter, _M_leave and
__detail::__atomic_load_value helpers. _M_mtx and _M_cv are marked mutable so
that __waiter_pool::_M_do_wait / _M_do_spin can be made const. Instead of
__addr it uses _M_ver (and adds _M_laundered(__addr) assertation) to clearly
communicate that non-_GLIBCXX_HAVE_PLATFORM_WAIT code is specialized. Also,
added const and/or noexcept where due.
[Bug target/104045] [AArch64] combine related to insn fmaxnm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104045 --- Comment #4 from Andrew Pinski --- Note I don't even think llvm implements-ftrapping-math . Still not a gcc bug. There is a bug request on changing the default already opened for gcc.
[Bug target/104045] [AArch64] combine related to insn fmaxnm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104045 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- Yes I just checked and we get the constant folding as expected with -fno-trappimg-math. So the defaults are different between the two.
[Bug target/104045] [AArch64] combine related to insn fmaxnm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104045 --- Comment #2 from Andrew Pinski --- I read that wrong. We have Max. I suspect the issue is gcc has -ftrapping-math turned on by default while clang does not. Does -fno-trapping-math fix the issue?
[Bug target/104045] [AArch64] combine related to insn fmaxnm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104045 --- Comment #1 from Andrew Pinski --- I think gcc is correct and clang is wrong. Fmax treats Nan as missing data so fmax is really just a.
[Bug c/104045] New: [AArch64] combine related to insn fmaxnm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104045
Bug ID: 104045
Summary: [AArch64] combine related to insn fmaxnm
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhongyunde at huawei dot com
Target Milestone: ---
test case, see detail https://gcc.godbolt.org/z/95osxxjx5
float foo(float a)
{
float x = 1.0f;
float y = 0.0f;
float z = x / y;
return fmax (a, z);
}
as the z is Inf, so above fmax need be combined as clang ?
[Bug other/89863] [meta-bug] Issues in gcc that other static analyzers (cppcheck, clang-static-analyzer, PVS-studio) find that gcc misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863 Bug 89863 depends on bug 102074, which changed state. Bug 102074 Summary: include/bits/atomic_timed_wait.h:215: possible missing return ? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102074 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug libstdc++/102074] include/bits/atomic_timed_wait.h:215: possible missing return ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102074 Thomas Rodgers changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Thomas Rodgers --- Fixed on master, see - https://gcc.gnu.org/g:763eb1f19239ebb19c0f87590a4f02300c02c52b
[Bug c++/84544] Missing warning when returning a reference to internal variable inside a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84544
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #3 from Martin Sebor ---
This should be easily detectable even without optimization by the new
-Wdangling-pointer. I think it's essentially equivalent to the following test
case:
$ cat t.C && gcc -S -Wall -fdump-tree-waccess1=/dev/stdout t.C
struct A
{
int
};
A f ()
{
int x = 0;
return A{ x };
}
;; Function f (_Z1fv, funcdef_no=0, decl_uid=2373, cgraph_uid=1,
symbol_order=0)
...
struct A f ()
{
int x;
struct A D.2386;
:
x = 0;
D.2386.r = <<< not handled by -Wdangling-pointer
x ={v} {CLOBBER};
:
:
return D.2386; <<<
}
[Bug c++/49974] missing -Wreturn-local-addr for indirectly returning reference to local/temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49974
--- Comment #18 from Martin Sebor ---
This detection is partially implemented in GCC 12 by the -Wdnagling-pointer:
$ cat pr49974.C && gcc -O -S -Wall pr49974.C
struct X { };
inline const X& f(const X& r) { return r; }
const X& g()
{
X x;
return f(x); // !!!
}
const X& h()
{
return f(X()); // !!!
}
struct Y {
Y(int& i) : r(i) { }
int& r;
};
Y f()
{
int i=0;
return Y(i);
}
pr49974.C: In function ‘const X& g()’:
pr49974.C:9:15: warning: using a dangling pointer to ‘x’ [-Wdangling-pointer=]
9 | return f(x); // !!!
| ^
pr49974.C:8:7: note: ‘x’ declared here
8 | X x;
| ^
pr49974.C: In function ‘const X& h()’:
pr49974.C:14:17: warning: using a dangling pointer to an unnamed temporary
[-Wdangling-pointer=]
14 | return f(X()); // !!!
| ^
pr49974.C:14:16: note: unnamed temporary defined here
14 | return f(X()); // !!!
|^
For the test case in comment #17 GCC with -O1 issues:
pr49974-c17.C: In function ‘int main()’:
pr49974-c17.C:11:12: warning: using a dangling pointer to an unnamed temporary
[-Wdangling-pointer=]
11 | return x.i;
|^
pr49974-c17.C:10:15: note: unnamed temporary defined here
10 | X&& x = f(X{});
| ^
pr49974-c17.C:11:12: warning: ‘.X::i’ is used uninitialized
[-Wuninitialized]
11 | return x.i;
|^
pr49974-c17.C:10:15: note: ‘’ declared here
10 | X&& x = f(X{});
| ^
[Bug tree-optimization/90905] missing -Wreturn-local-addr returning a local std::string::c_str()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90905 --- Comment #9 from Martin Sebor --- This still isn't diagnosed by GCC 12 even with its -Wuse-after-free and -Wdangling-pointer.
[Bug tree-optimization/90906] diagnose returning pointers to freed memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90906 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Target Milestone|--- |12.0 --- Comment #4 from Martin Sebor --- Implemented in GCC 12 (r12-6605) as -Wuse-after-free.
[Bug tree-optimization/80532] warning on pointer access after free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80532 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |12.0 Resolution|--- |FIXED --- Comment #10 from Martin Sebor --- Implemented in GCC 12 as -Wuse-after-free.
[Bug middle-end/63272] GCC should warn when using pointer to dead scoped variable within the same function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63272 Martin Sebor changed: What|Removed |Added Target Milestone|--- |12.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Martin Sebor --- Implemented in GCC 12 as -Wdangling-pointer.
[Bug tree-optimization/104038] ranger infinite loop on a PHI statement while building Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104038 Martin Sebor changed: What|Removed |Added Summary|ranger infinite loop on a |ranger infinite loop on a |PHI statement |PHI statement while ||building Clang CC||amacleod at redhat dot com --- Comment #7 from Martin Sebor --- With r12-6606 the infinite loop should be reproducible with an unmodified GCC trunk.
[Bug middle-end/63272] GCC should warn when using pointer to dead scoped variable within the same function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63272 --- Comment #8 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:9d6a0f388eb048f8d87f47af78f07b5ce513bfe6 commit r12-6606-g9d6a0f388eb048f8d87f47af78f07b5ce513bfe6 Author: Martin Sebor Date: Sat Jan 15 16:41:40 2022 -0700 Add -Wdangling-pointer [PR63272]. Resolves: PR c/63272 - GCC should warn when using pointer to dead scoped variable with in the same function gcc/c-family/ChangeLog: PR c/63272 * c.opt (-Wdangling-pointer): New option. gcc/ChangeLog: PR c/63272 * diagnostic-spec.c (nowarn_spec_t::nowarn_spec_t): Handle -Wdangling-pointer. * doc/invoke.texi (-Wdangling-pointer): Document new option. * gimple-ssa-warn-access.cc (pass_waccess::clone): Set new member. (pass_waccess::check_pointer_uses): New function. (pass_waccess::gimple_call_return_arg): New function. (pass_waccess::gimple_call_return_arg_ref): New function. (pass_waccess::check_call_dangling): New function. (pass_waccess::check_dangling_uses): New function overloads. (pass_waccess::check_dangling_stores): New function. (pass_waccess::check_dangling_stores): New function. (pass_waccess::m_clobbers): New data member. (pass_waccess::m_func): New data member. (pass_waccess::m_run_number): New data member. (pass_waccess::m_check_dangling_p): New data member. (pass_waccess::check_alloca): Check m_early_checks_p. (pass_waccess::check_alloc_size_call): Same. (pass_waccess::check_strcat): Same. (pass_waccess::check_strncat): Same. (pass_waccess::check_stxcpy): Same. (pass_waccess::check_stxncpy): Same. (pass_waccess::check_strncmp): Same. (pass_waccess::check_memop_access): Same. (pass_waccess::check_read_access): Same. (pass_waccess::check_builtin): Call check_pointer_uses. (pass_waccess::warn_invalid_pointer): Add arguments. (is_auto_decl): New function. (pass_waccess::check_stmt): New function. (pass_waccess::check_block): Call check_stmt. (pass_waccess::execute): Call check_dangling_uses, check_dangling_stores. Empty m_clobbers. * passes.def (pass_warn_access): Invoke pass two more times. gcc/testsuite/ChangeLog: PR c/63272 * g++.dg/warn/Wfree-nonheap-object-6.C: Disable valid warnings. * g++.dg/warn/ref-temp1.C: Prune expected warning. * gcc.dg/uninit-pr50476.c: Expect a new warning. * c-c++-common/Wdangling-pointer-2.c: New test. * c-c++-common/Wdangling-pointer-3.c: New test. * c-c++-common/Wdangling-pointer-4.c: New test. * c-c++-common/Wdangling-pointer-5.c: New test. * c-c++-common/Wdangling-pointer-6.c: New test. * c-c++-common/Wdangling-pointer.c: New test. * g++.dg/warn/Wdangling-pointer-2.C: New test. * g++.dg/warn/Wdangling-pointer.C: New test. * gcc.dg/Wdangling-pointer-2.c: New test. * gcc.dg/Wdangling-pointer.c: New test.
[Bug tree-optimization/80532] warning on pointer access after free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80532 --- Comment #9 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:671a283636de75f7ed638ee6b01ed2d44361b8b6 commit r12-6605-g671a283636de75f7ed638ee6b01ed2d44361b8b6 Author: Martin Sebor Date: Sat Jan 15 16:37:54 2022 -0700 Add -Wuse-after-free [PR80532]. gcc/c-family/ChangeLog PR tree-optimization/80532 * c.opt (-Wuse-after-free): New options. gcc/ChangeLog: PR tree-optimization/80532 * common.opt (-Wuse-after-free): New options. * diagnostic-spec.c (nowarn_spec_t::nowarn_spec_t): Handle OPT_Wreturn_local_addr and OPT_Wuse_after_free_. * diagnostic-spec.h (NW_DANGLING): New enumerator. * doc/invoke.texi (-Wuse-after-free): Document new option. * gimple-ssa-warn-access.cc (pass_waccess::check_call): Rename... (pass_waccess::check_call_access): ...to this. (pass_waccess::check): Rename... (pass_waccess::check_block): ...to this. (pass_waccess::check_pointer_uses): New function. (pass_waccess::gimple_call_return_arg): New function. (pass_waccess::warn_invalid_pointer): New function. (pass_waccess::check_builtin): Handle free and realloc. (gimple_use_after_inval_p): New function. (get_realloc_lhs): New function. (maybe_warn_mismatched_realloc): New function. (pointers_related_p): New function. (pass_waccess::check_call): Call check_pointer_uses. (pass_waccess::execute): Compute and free dominance info. libcpp/ChangeLog: * files.c (_cpp_find_file): Substitute a valid pointer for an invalid one to avoid -Wuse-after-free. libiberty/ChangeLog: * regex.c: Suppress -Wuse-after-free. gcc/testsuite/ChangeLog: PR tree-optimization/80532 * gcc.dg/Wmismatched-dealloc-2.c: Avoid -Wuse-after-free. * gcc.dg/Wmismatched-dealloc-3.c: Same. * gcc.dg/analyzer/file-1.c: Prune expected warning. * gcc.dg/analyzer/file-2.c: Same. * gcc.dg/attr-alloc_size-6.c: Disable -Wuse-after-free. * gcc.dg/attr-alloc_size-7.c: Same. * c-c++-common/Wuse-after-free-2.c: New test. * c-c++-common/Wuse-after-free-3.c: New test. * c-c++-common/Wuse-after-free-4.c: New test. * c-c++-common/Wuse-after-free-5.c: New test. * c-c++-common/Wuse-after-free-6.c: New test. * c-c++-common/Wuse-after-free-7.c: New test. * c-c++-common/Wuse-after-free.c: New test. * g++.dg/warn/Wmismatched-dealloc-3.C: New test. * g++.dg/warn/Wuse-after-free.C: New test.
[Bug c/104044] New: Useless empty statements (across projects)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104044 Bug ID: 104044 Summary: Useless empty statements (across projects) Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- mn10300.c says: > break;; nvptx.c says: > tree r = NULL_TREE;; jit-playback.c says: > tree x = as_tree ();; These extra semicolons (and all the others in the whole tree) should be removed, as they don't add any value. Quite the opposite, they create an impression that the code were carelessly written. I'm only concerned about obviously useless semicolons. In particular, I have no problem with the empty statement in "while (i-- > 0) ;". Is there a GCC warning for useless empty statements like these? I saw that this was already reported as Bug 49053, but maybe your attitude towards this topic changed in the past 5 years. I stumbled upon these empty statements as I made the same mistake in my own code.
[Bug fortran/85150] internal compiler error for module with illegal non-constant pointer initialization designator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85150 --- Comment #7 from Nathan Weeks --- Great, thanks! -- Nathan On Sat, Jan 15, 2022 at 4:11 PM anlauf at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85150 > > anlauf at gcc dot gnu.org changed: > >What|Removed |Added > > > Status|NEW |RESOLVED > Resolution|--- |DUPLICATE > > --- Comment #6 from anlauf at gcc dot gnu.org --- > This is indeed fixed by commit r12-6387. Closing. > > Thanks for the report! > > *** This bug has been marked as a duplicate of bug 101762 *** > > -- > You are receiving this mail because: > You reported the bug.
[Bug fortran/103695] [12 Regression][OpenMP] affinity clause - ICE: verify_ssa failed since r12-1108-g9a5de4d5af1c10a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103695 --- Comment #4 from sandra at gcc dot gnu.org --- Ooops, I meant AFFINITY clause in the message above, not ASSOCIATED.
[Bug fortran/103695] [12 Regression][OpenMP] affinity clause - ICE: verify_ssa failed since r12-1108-g9a5de4d5af1c10a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103695
--- Comment #3 from sandra at gcc dot gnu.org ---
It appears that the wrong-scope problem is introduced in gfc_finish_var_decl,
in this block of code:
/* Chain this decl to the pending declarations. Don't do pushdecl()
because this would add them to the current scope rather than the
function scope. */
if (current_function_decl != NULL_TREE)
{
if (sym->ns->proc_name
&& (sym->ns->proc_name->backend_decl == current_function_decl
|| sym->result == sym))
gfc_add_decl_to_function (decl);
else if (sym->ns->proc_name
&& sym->ns->proc_name->attr.flavor == FL_LABEL)
/* This is a BLOCK construct. */
add_decl_as_local (decl);
else
gfc_add_decl_to_parent_function (decl);
}
ns->proc_name contains something completely unexpected here so it's falling
through to gfc_add_decl_to_parent_function. I think it's an accident that it
works at all when it's not inside a nested function. Do we really want these
iterator variables to have local scope instead?
gfortran.h documents the proc_name field as
/* If this is a namespace of a procedure, this points to the procedure. */
struct gfc_symbol *proc_name;
but the ASSOCIATED clause seems to be using it for an entirely different
purpose, to chain the list of iterator variables (see handle_iterator in
trans-openmp.c). I think that's the real bug, rather than the code snippet
quoted above. It ought to be adding a new field to struct gfc_namespace if
there isn't a better place to store this information, instead of overloading
one that means something else.
I'm still trying to find my way around the code that manipulates these
namespaces and iterator variables. There's an annoying lack of comments here
to explain the data structures it is using or what parts are handled during
gimplification. :-(
[Bug analyzer/104042] Four memcpy/memset analyzer failures on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104042 --- Comment #4 from Andrew Pinski --- So I suspect they will fail if you default the linux compiler to _FORTIFY_SOURCE=2 then too. (I thought there was a configure option to do that or maybe Debian/Ubuntu has patches for it I forget).
[Bug fortran/83079] ICE in gfc_widechar_to_char, at fortran/scanner.c:198
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83079 --- Comment #7 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:29401b7b4581e9131e7057e263dcea8b40a6b5ab commit r12-6604-g29401b7b4581e9131e7057e263dcea8b40a6b5ab Author: Harald Anlauf Date: Tue Jan 11 22:06:10 2022 +0100 Fortran: fix ICE and wrong code with TRANSFER and CHARACTER(kind=4) gcc/fortran/ChangeLog: PR fortran/83079 * target-memory.c (gfc_interpret_character): Result length is in bytes and thus depends on the character kind. * trans-intrinsic.c (gfc_conv_intrinsic_transfer): Compute correct string length for the result of the TRANSFER intrinsic and for temporaries for the different character kinds. gcc/testsuite/ChangeLog: PR fortran/83079 * gfortran.dg/transfer_char_kind4.f90: New test.
[Bug c++/101715] [11/12 Regression] ICE with noexcept and canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101715 --- Comment #18 from Sergei Trofimovich --- (In reply to Marek Polacek from comment #17) > Patch posted > https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588520.html Applying patch locally fixes build of compiler-rt from llvm-13 for me. Thank you!
[Bug fortran/101762] ICE with "Every subscript of the target specification must be a constant expression"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101762 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||weeks at iastate dot edu --- Comment #8 from anlauf at gcc dot gnu.org --- *** Bug 85150 has been marked as a duplicate of this bug. ***
[Bug fortran/85150] internal compiler error for module with illegal non-constant pointer initialization designator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85150 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from anlauf at gcc dot gnu.org --- This is indeed fixed by commit r12-6387. Closing. Thanks for the report! *** This bug has been marked as a duplicate of bug 101762 ***
[Bug fortran/101762] ICE with "Every subscript of the target specification must be a constant expression"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101762 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:27424f10d4ad28fbcceb1c9fc767605b4d46494c commit r11-9463-g27424f10d4ad28fbcceb1c9fc767605b4d46494c Author: Harald Anlauf Date: Sun Jan 9 22:08:14 2022 +0100 Fortran: reject invalid non-constant pointer initialization targets gcc/fortran/ChangeLog: PR fortran/101762 * expr.c (gfc_check_pointer_assign): For pointer initialization targets, check that subscripts and substring indices in specifications are constant expressions. gcc/testsuite/ChangeLog: PR fortran/101762 * gfortran.dg/pr101762.f90: New test. (cherry picked from commit 2e63128306ff93d8f53119137dd6c28b2defac94)
[Bug fortran/103777] ICE in gfc_simplify_maskl, at fortran/simplify.c:4918
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103777 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:3bd2fd2840789909f6088d1c00d2efe9567293b4 commit r11-9462-g3bd2fd2840789909f6088d1c00d2efe9567293b4 Author: Harald Anlauf Date: Mon Dec 20 22:59:53 2021 +0100 Fortran: check arguments of MASKL/MASKR intrinsics before simplification gcc/fortran/ChangeLog: PR fortran/103777 * simplify.c (gfc_simplify_maskr): Check validity of argument 'I' before simplifying. (gfc_simplify_maskl): Likewise. gcc/testsuite/ChangeLog: PR fortran/103777 * gfortran.dg/masklr_3.f90: New test. (cherry picked from commit 49d73c9fb644673323845efebfe6b3106e70af8a)
[Bug c++/60679] [DR1647] class specialization not instantiated even though it is a better match than the primary template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60679 Patrick Palka changed: What|Removed |Added CC||fchelnokov at gmail dot com --- Comment #6 from Patrick Palka --- *** Bug 104043 has been marked as a duplicate of this bug. ***
[Bug c++/104043] Non-type template specialization with another type is accepted but ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104043 Patrick Palka changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- dup *** This bug has been marked as a duplicate of bug 60679 ***
[Bug c++/104031] [12 regression] Global nested constructors generate invalid code since r12-6329-g4f6bc28fc7dd86bd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104031
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek ---
My guess is that the problem is that when the TARGET_EXPR_SLOT is created using
build_local_temp, current_function_decl is NULL, it is in s_op global namespace
var initializer.
Eventually we add it to ssdf and call in the new r12-6329 spot
split_nonconstant_init, which has:
743 if (VAR_P (dest) && !is_local_temp (dest))
744 {
745 DECL_INITIAL (dest) = init;
746 TREE_READONLY (dest) = 0;
747 }
but due to the still unchanged DECL_CONTEXT being NULL is_local_temp returns
false and we set DECL_INITIAL instead of what the code expects.
The temporary gets DECL_CONTEXT set only during gimplification.
So, I think either we should fill in TARGET_EXPR_SLOT's DECL_CONTEXT when we
are adding those exprs into ssdf, or the r12-6329 code should ensure the slot
has non-NULL DECL_CONTEXT if current_function_decl or something similar.
[Bug c++/104043] New: Non-type template specialization with another type is accepted but ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104043
Bug ID: 104043
Summary: Non-type template specialization with another type is
accepted but ignored
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
This code
```
template
struct A;
template
struct A {};
A<1> a;
```
is accepted by other compiler but GCC complains:
```
error: aggregate 'A<1> a' has incomplete type and cannot be defined
```
Demo: https://gcc.godbolt.org/z/MbrndEj6q
[Bug analyzer/104042] Four memcpy/memset analyzer failures on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104042 --- Comment #3 from Iain Sandoe --- erm, that is probably _FORTIFY_SOURCE from the command line.
[Bug analyzer/104042] Four memcpy/memset analyzer failures on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104042 --- Comment #2 from Iain Sandoe --- FX, You might be able to force Darwin to use the non-checked versions (perhaps by adding -D_USE_FORTIFY_LEVEL=0)
[Bug tree-optimization/103603] [11 Regression] stack overflow on ranger for huge program, but OK for legacy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103603 Andrew Macleod changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Andrew Macleod --- fixed
[Bug analyzer/104042] Four memcpy/memset analyzer failures on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104042 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-01-15 CC||dmalcolm at gcc dot gnu.org, ||iains at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Francois-Xavier Coudert --- The reason for the failure is that the darwin headers, in (included from ), defines memcpy like this: #if __has_builtin(__builtin___memcpy_chk) || defined(__GNUC__) #undef memcpy /* void *memcpy(void *dst, const void *src, size_t n) */ #define memcpy(dest, ...) \ __builtin___memcpy_chk (dest, __VA_ARGS__, __darwin_obsz0 (dest)) #endif where __darwin_obsz0 is defined thusly: #define __darwin_obsz0(object) __builtin_object_size (object, 0) So either the testcase should be modified to use __builtin_memcpy, or the analyzer should handle __builtin___memcpy_chk and emit the right warning.
[Bug analyzer/104042] New: Four memcpy/memset analyzer failures on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104042
Bug ID: 104042
Summary: Four memcpy/memset analyzer failures on darwin
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
Created attachment 52202
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52202=edit
Preprocessed source
Some analyzer testcases fail on darwin
(https://gcc.gnu.org/pipermail/gcc-testresults/2022-January/747918.html) due to
what I believe are false positive.
Those four cases fail for the same reason:
gcc.dg/analyzer/data-model-1.c
gcc.dg/analyzer/pr103526.c
gcc.dg/analyzer/taint-size-1.c
gcc.dg/analyzer/write-to-string-literal-1.c
The failures are related to memcpy and memset, and can be reduced to this:
$ cat write-to-string-literal-1.c
#include
void test_2 (void) {
memcpy ("abc", "def", 3); /* { dg-warning "write to string literal" } */
}
$ ./bin/gcc -fdiagnostics-plain-output -fanalyzer -Wanalyzer-too-complex
-fanalyzer-call-summaries write-to-string-literal-1.c -c
No warning is emitted, and the test expects a warning. The preprocessed source
for this reduced testcase is attached.
The testcase passes if the memcpy() call is replaced by __builtin_memcpy().
[Bug libgcc/62109] __gthr_i486_lock_cmp_xchg missing clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109 jyong at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||jyong at gcc dot gnu.org --- Comment #15 from jyong at gcc dot gnu.org --- Pushed the patch as dcf8fe1eeab668a4d24bcc4baa3ad185dbf1b5e0, thanks David.
[Bug c++/104041] static_assert failure triggered by non-selected template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104041 --- Comment #3 from Jonathan Wakely --- Please don't change the resolution to FIXED. There was no GCC bug, and so nothing was fixed. The correct resolution is INVALID.
[Bug libstdc++/104019] Testsuite 17_intro/headers/c++2020/stdc++_multiple_inclusion.cc failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104019 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |12.0
[Bug libstdc++/104019] Testsuite 17_intro/headers/c++2020/stdc++_multiple_inclusion.cc failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104019 --- Comment #2 from Jonathan Wakely --- I have a script that's supposed to pick up those macro inconsistencies, I wonder why it's not working. The aliasing violation is real, we should use memset instead.
[Bug libfortran/104006] [12 regression] power-ieee128 merge breaks Solaris build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104006 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #28 from Jakub Jelinek --- Hopefully everything is fixed now. Sorry for the breakages.
[Bug ada/104027] [12 Regression] libgnat-12.so requires executable stack on x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104027 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug libstdc++/104032] Cannot move-assign a spanstream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104032 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2022-01-15 Status|UNCONFIRMED |ASSIGNED Target Milestone|--- |12.0 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug libstdc++/104019] Testsuite 17_intro/headers/c++2020/stdc++_multiple_inclusion.cc failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104019 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug target/104001] [12 Regression] ICE in extract_insn, at recog.c:2769 since r12-6538-g5f19303ada7db92c155332e7ba317233ca05946b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104001 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Andrew Pinski --- .
[Bug c++/104041] static_assert failure triggered by non-selected template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104041 Andrew Pinski changed: What|Removed |Added Resolution|FIXED |INVALID
[Bug c++/104041] static_assert failure triggered by non-selected template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104041 bugzilla at cems dot de changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #2 from bugzilla at cems dot de --- (In reply to Andrew Pinski from comment #1) > Since the value that is done in the static_assert is not value dependent, it > is rejected at the definition time of C::C. > > This is correct. So if I replace the condition in the static_assert by something which is value dependent,it will not be triggered in an unselected specialization even if the condition is always false, e.g.: static_assert(sizeof(T) < 0, "C selected"); OK, thanks.
[Bug rtl-optimization/93748] too much quotation in diagnostic (%qs instead of %s)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93748 --- Comment #4 from Andrew Pinski --- (In reply to Roland Illig from comment #3) > Are you sure about the "will not be used"? Bug 80055 is still open. Right that bug should track putting those strings in the .pot which we really should not be doing.
[Bug c++/104041] static_assert failure triggered by non-selected template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104041
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Andrew Pinski ---
Since the value that is done in the static_assert is not value dependent, it is
rejected at the definition time of C::C.
This is correct.
Can you use either do the following instead:
template struct C
{
C(T) = delete;
};
Which requires a specialization for C::C so it will not be a deleted
constructor.
[Bug libstdc++/104019] Testsuite 17_intro/headers/c++2020/stdc++_multiple_inclusion.cc failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104019
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-01-15
Target||*-*-freebsd* *-*-dragonfly*
--- Comment #1 from Andrew Pinski ---
Oh there is a difference:
include/bits/utility.h:#define __cpp_lib_integer_sequence 201304L
include/std/version:# define __cpp_lib_integer_sequence 201304
include/std/utility:#define __cpp_lib_exchange_function 201304L
include/std/version:# define __cpp_lib_exchange_function 201304
// FreeBSD wants warning clean system headers:
// { dg-options "-Wall -Wsystem-headers" { target *-*-freebsd* *-*-dragonfly* }
}
Confirmed.
I suspect there are more regressions lately because we have not had a testsuite
results from dragonfly recently likewise from freebsd too.
[Bug rtl-optimization/93748] too much quotation in diagnostic (%qs instead of %s)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93748 --- Comment #3 from Roland Illig --- (In reply to Andrew Pinski from comment #2) > Since all 4 are internal compiler error, they will not be used for > translation and the rules for diagnostic does not need to apply here. Are you sure about the "will not be used"? Bug 80055 is still open.
[Bug c++/104041] New: static_assert failure triggered by non-selected template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104041
Bug ID: 104041
Summary: static_assert failure triggered by non-selected
template specialization
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzilla at cems dot de
Target Milestone: ---
A static_assert failure can be triggered even by a template specialization that
is not selected.
The following code selects the specialization C if allowed to compile, but
compilation fails if there is a failing static_assert in the generic template
C, despite it not being selected.
#include
template struct C
{ C(T) {
#ifdef DEBUG
static_assert(false, "C selected");
#endif
std::cout << "C selected"; }
};
template <> struct C
{ C(int) { std::cout << "C selected"; }
};
int main()
{ C c(1);
}
/*
with macro DEBUG defined, compilation error with diagnostic:
error: static assertion failed: C selected
without macro DEBUG defined, compiles and runs with output:
C selected
*/
[Bug rtl-optimization/93748] too much quotation in diagnostic (%qs instead of %s)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93748 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Andrew Pinski --- Since all 4 are internal compiler error, they will not be used for translation and the rules for diagnostic does not need to apply here. So closing as won't fix.
