[Bug tree-optimization/80635] [8/9/10/11 regression] std::optional and bogus -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 Miko Vich changed: What|Removed |Added CC||alexmudmiko at gmail dot com --- Comment #56 from Miko Vich --- I think Jeff is correct. While I have no experience with writing compilers, I've been wrestling with this "feature" for about 3 years now. What's odd is that it doesn't always manifest. It also seems to be restricted (at least in my cases) to using std::optional with POD or enum types. Also, the volatile thingy doesn't solve the issue if sizeof(T) is less than 16 bytes. (Again my experience.) Anyway... some findings which I think support Jeff's comment: about a year ago I went so far as to memset to zero the memory in std::optional for sizeof(T). This made the warning go away... defeats the purpose of optional of course, but no more warning. But on inspecting the assembly generated, there was no zero-ing of the memory (or any other assignment to 0). So the optimizer no longer error'd on maybe-uninitialized, but knew enough to elide away the memset. So... is this maybe a case of the warning simply being emitted too soon in the passes, i.e., before its completely finished optimizing? Because even without the memset change, the final assembly generated under -O3 never has a path where the value in the optional is accessed when uninitialized.
[Bug target/98341] [11 Regression] Ada bootstrap fails with Storage_Error stack overflow or erroneous memory access on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98341 --- Comment #4 from John Paul Adrian Glaubitz --- This regression was introduced by: commit d7e20130650fb46d71e0403652e4e07bc14f9775 (refs/bisect/bad) Author: Justin Squirek Date: Mon Aug 10 12:05:07 2020 -0400 [Ada] Reimplementation of accessibility checking
[Bug fortran/98445] Bogus error: derived type used as an actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98445 --- Comment #2 from Rich Townsend --- I know it's acceptable to overload a type name with one or more functions -- from 12.4.3.4.1 of the F2008 standard, "A generic name may be the same as a derived-type name, in which case all of the procedures in the interface block shall be functions." In reading the rules for actual and dummy arguments (12.5.2), I don't see anything prohibiting a function-overloaded type name being passed in. However, I'm going to hit up comp.lang.fortran to see if I can get advice from one of the Fortran congnescenti.
[Bug c++/96045] [11 Regression] Wrong line and column diagnostic message in a class template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96045 --- Comment #6 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:6037ebeff1cd76385e88dd9cbcaf68ada85316fb commit r11-6343-g6037ebeff1cd76385e88dd9cbcaf68ada85316fb Author: Iain Sandoe Date: Sat Dec 26 19:46:50 2020 + Objective-C++ : Fix up testcase EOF diagnostics. Some Objective-C++ testcases need modification in reponse to the solution to PR 96045. gcc/testsuite/ChangeLog: PR c++/96045 * obj-c++.dg/property/property-neg-6.mm: Adjust EOF diagnostic location. * obj-c++.dg/syntax-error-10.mm: Likewise. * obj-c++.dg/syntax-error-8.mm: Likewise. * obj-c++.dg/syntax-error-9.mm: Likewise.
[Bug c++/98450] New: Inconsistent Wunused-variable warning for std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98450
Bug ID: 98450
Summary: Inconsistent Wunused-variable warning for std::array
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: maic23 at live dot de
Target Milestone: ---
When using std::array in C++17 mode, -Wunused-variable behaves inconsistent:
$ cat /tmp/a.cpp
#include
static constexpr std::array bay{9};
static constexpr std::array bax{9};
$ gcc -std=c++17 -Wall -S /tmp/a.cpp
/tmp/a.cpp:2:37: warning: ‘bay’ defined but not used [-Wunused-variable]
2 | static constexpr std::array bay{9};
| ^~~
Now, if the two lines are switched, there is no warning:
$ cat /tmp/b.cpp
#include
static constexpr std::array bax{9};
static constexpr std::array bay{9};
$ gcc -std=c++17 -Wall -S /tmp/b.cpp
(no warning)
It makes it really hard to debug and fix this warning when it occurs only
sporadically.
The warning should probably not appear at all, because static const(expr)
variables are put in header files, but not used everywhere where the header
file is included in a cpp file.
[Bug analyzer/98447] incorrect -Wanalyzer-shift-count-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98447
--- Comment #4 from Vincent Lefèvre ---
So this can be simplified to
void f (unsigned long *p, int r, int i)
{
int b = 64, n = r % 64;
while (i >= 0 && b >= 0)
{
if (b <= n)
p[i--] = 1UL << b;
b -= n;
}
}
Here, due to the "n = r % 64", one has n <= 63, so that "1UL << b" can be
executed only when b <= 63, and the shift is necessarily valid (no overflow).
This could be part of a more general bug: I also get the
-Wanalyzer-shift-count-overflow warning if I replace "n = r % 64" by "n = r".
While with the initial code, one is certain that the shift is valid, now this
depends on the value of r. But since the compiler doesn't know the condition
under which this function will be called, it should not assume that r may have
any value.
[Bug analyzer/98447] incorrect -Wanalyzer-shift-count-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98447 --- Comment #3 from Vincent Lefèvre --- And the warning is triggered with the initial "b = 63", but not "b = 62" and smaller values.
[Bug analyzer/98447] incorrect -Wanalyzer-shift-count-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98447
--- Comment #2 from Vincent Lefèvre ---
Note: The warning occurs when the compiler knows that b < 63 in the "if" case
(it occurs up to "n = r % 64", but not with "n = r % 65") so that the condition
"b + 1 >= 64" is always false. I suppose that the p[i--] line has already been
simplified to something equivalent to
p[i--] = 1UL << (b + 1);
but the analyzer doesn't see that b has restricted values in the "if" case.
if (n > b)
{
p[i--] = 1UL << (b + 1);
b += 64;
}
triggers the warning, but not
if (63 > b)
{
p[i--] = 1UL << (b + 1);
b += 64;
}
[Bug fortran/98022] [9/10/11 Regression] ICE in gfc_assign_data_value, at fortran/data.c:468 since r9-3803-ga5fbc2f36a291cbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98022 --- Comment #10 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:c7256c8260afa313e019fd531574ad33ec49b9f6 commit r11-6342-gc7256c8260afa313e019fd531574ad33ec49b9f6 Author: Paul Thomas Date: Sat Dec 26 16:44:24 2020 + Fortran: Correction to recent patch in light of comments [PR98022]. 2020-12-26 Paul Thomas gcc/fortran PR fortran/98022 * data.c (gfc_assign_data_value): Throw an error for inquiry references. Follow with corrected code that would provide the expected result and provides clean error recovery. gcc/testsuite/ PR fortran/98022 * gfortran.dg/data_inquiry_ref.f90: Change to dg-compile and add errors for inquiry references.
[Bug tree-optimization/97424] Warn on invalid shift amount after inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97424 Vincent Lefèvre changed: What|Removed |Added CC||vincent-gcc at vinc17 dot net --- Comment #7 from Vincent Lefèvre --- I get a false positive on "b + 1 >= 64 ? 0UL : 1UL << (b + 1)" with a 64-bit unsigned long. See PR98447.
[Bug analyzer/98447] incorrect -Wanalyzer-shift-count-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98447 --- Comment #1 from Vincent Lefèvre --- This is probably due to commit 5e00ad3ffbfb4df7242c313a0d836f5b538eb2fb (where this warning was introduced, as requested by PR97424).
[Bug fortran/83118] [8/9/10/11 Regression] Bad intrinsic assignment of class(*) array component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 --- Comment #39 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:0175d45d14b1f9ebc4c15ea5bafcda655c37fc35 commit r11-6341-g0175d45d14b1f9ebc4c15ea5bafcda655c37fc35 Author: Paul Thomas Date: Sat Dec 26 15:08:11 2020 + Fix failures with -m32 and some memory leaks. 2020-12-23 Paul Thomas gcc/fortran PR fortran/83118 * trans-array.c (gfc_alloc_allocatable_for_assignment): Make sure that class expressions are captured for dummy arguments by use of gfc_get_class_from_gfc_expr otherwise the wrong vptr is used. * trans-expr.c (gfc_get_class_from_gfc_expr): New function. (gfc_get_class_from_expr): If a constant expression is encountered, return NULL_TREE; (gfc_trans_assignment_1): Deallocate rhs allocatable components after passing derived type function results to class lhs. * trans.h : Add prototype for gfc_get_class_from_gfc_expr.
[Bug libstdc++/98449] New: notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98449 Bug ID: 98449 Summary: notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: vini.ipsmaker at gmail dot com Target Milestone: --- Details of the issue can be found at: https://cplusplus.github.io/LWG/issue3343 I have a code base affected by this issue.
[Bug c++/98448] New: [11 Regression] bootstrap-O3 comparison fails due to libcody
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98448 Bug ID: 98448 Summary: [11 Regression] bootstrap-O3 comparison fails due to libcody Product: gcc Version: unknown Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org CC: nathan at gcc dot gnu.org Target Milestone: --- Doing a bootstrap-O3 on aarch64-none-linux-gnu fails comparison with: Comparing stages 2 and 3 Bootstrap comparison failure! libcody/fatal.o differs Maybe some flags need to be passed down in a Makefile somewhere?
[Bug fortran/98445] Bogus error: derived type used as an actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98445 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2020-12-26 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Can you explain when did this become valid? And which compiler accepts this? Intel v21 also rejects it with a similar error: pr98445.f90(31): error #6478: A type-name must not be used as a variable. [T] call s(t) ---^ plus some more.
