[Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 --- Comment #18 from bin cheng --- Did some experiments, there are two fallouts after explicitly returning false for unsigned/wrapping types in MULT_EXPR/MINUS_EXPR/PLUS_EXPR. One is the mentioned use of multiple_of_p in number_of_iterations_ne, the other is for alignment warning in stor-layout.c. As pointed out, the latter case is known not overflow/wrap. So I am thinking to introduce an additional parameter indicating that caller knows "top" doesn't overfow/wrap, otherwise, try to get rid of the undocumented assumption. we can always improve the accuracy using ranger or other tools. Not sure if this is the right way to do. As for MULT_NO_OVERFLOW/PLUS_NO_OVERFLOW, IMHO, it's not that simple? For example, unsigned_num(multiple of 4, and larger than 0) + 0xfffc is multiple of 4, but it's overflow behavior on which we rely here.
[Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 --- Comment #19 from bin cheng --- (In reply to bin cheng from comment #18) > Did some experiments, there are two fallouts after explicitly returning > false for unsigned/wrapping types in MULT_EXPR/MINUS_EXPR/PLUS_EXPR. One is > the mentioned use of multiple_of_p in number_of_iterations_ne, the other is > for alignment warning in stor-layout.c. As pointed out, the latter case is > known not overflow/wrap. > > So I am thinking to introduce an additional parameter indicating that caller > knows "top" doesn't overfow/wrap, otherwise, try to get rid of the > undocumented assumption. we can always improve the accuracy using ranger or > other tools. Not sure if this is the right way to do. > > As for MULT_NO_OVERFLOW/PLUS_NO_OVERFLOW, IMHO, it's not that simple? For > example, unsigned_num(multiple of 4, and larger than 0) + 0xfffc is > multiple of 4, but it's overflow behavior on which we rely here. Hmm, 4 is special and not a correct example. Considering: n (unsigned, multiple of 3, and > 0) + 0xfffd It's multiple of 3, but we need to rely on wrapping to get answer.
[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99928 --- Comment #9 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:780e5d4a2bac6eb7566c966a265961c99449cb55 commit r12-902-g780e5d4a2bac6eb7566c966a265961c99449cb55 Author: Jakub Jelinek Date: Wed May 19 09:21:09 2021 +0200 openmp: Handle lastprivate on combined target correctly [PR99928] This patch deals with 2 issues: 1) the gimplifier couldn't differentiate between #pragma omp parallel master #pragma omp taskloop simd and #pragma omp parallel master taskloop simd when there is a significant difference for clause handling between the two; as master construct doesn't have any clauses, we don't currently represent it during gimplification by an gimplification omp context at all, so this patch makes sure we don't set OMP_PARALLEL_COMBINED on parallel master when not combined further. If we ever add a separate master context during gimplification, we'd use ORT_COMBINED_MASTER vs. ORT_MASTER (or MASKED probably). 2) lastprivate when combined with target should be map(tofrom:) on the target, this change handles it only when not combined with firstprivate though, that will need further work (similarly to linear or reduction). 2021-05-19 Jakub Jelinek PR middle-end/99928 gcc/ * tree.h (OMP_MASTER_COMBINED): Define. * gimplify.c (gimplify_scan_omp_clauses): Rewrite lastprivate handling for outer combined/composite constructs to a loop. Handle lastprivate on combined target. (gimplify_expr): Formatting fix. gcc/c/ * c-parser.c (c_parser_omp_master): Set OMP_MASTER_COMBINED on master when combined with taskloop. (c_parser_omp_parallel): Don't set OMP_PARALLEL_COMBINED on parallel master when not combined with taskloop. gcc/cp/ * parser.c (cp_parser_omp_master): Set OMP_MASTER_COMBINED on master when combined with taskloop. (cp_parser_omp_parallel): Don't set OMP_PARALLEL_COMBINED on parallel master when not combined with taskloop. gcc/testsuite/ * c-c++-common/gomp/pr99928-2.c: Remove all xfails. * c-c++-common/gomp/pr99928-12.c: New test.
[Bug c++/100666] New: warning: ignoring return value of 'constexpr _Tp&& std::forward(typename std::remove_reference<_Tp>::type&) [with _Tp = std::nullptr_t; typename std::remove_reference<_Tp>::type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100666
Bug ID: 100666
Summary: warning: ignoring return value of 'constexpr _Tp&&
std::forward(typename
std::remove_reference<_Tp>::type&) [with _Tp =
std::nullptr_t; typename
std::remove_reference<_Tp>::type = std::nullptr_t]',
declared with attribute 'nodiscard' [-Wunused-result]
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mh+gcc at glandium dot org
Target Milestone: ---
(Note I'm not entirely sure this is a GCC bug, but it doesn't happen with GCC <
11 and with clang)
Reduced testcase:
```
#include
extern void foo(...);
template
void bar(Ts&&... aArgs) {
foo(std::forward(aArgs)...);
}
void qux() {
bar(nullptr);
}
```
This emits the following warning:
```
: In instantiation of 'void bar(Ts&& ...) [with Ts =
{std::nullptr_t}]':
:11:8: required from here
:7:25: warning: ignoring return value of 'constexpr _Tp&&
std::forward(typename std::remove_reference<_Tp>::type&) [with _Tp =
std::nullptr_t; typename std::remove_reference<_Tp>::type = std::nullptr_t]',
declared with attribute 'nodiscard' [-Wunused-result]
7 | foo(std::forward(aArgs)...);
| ^~~
In file included from
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/bits/stl_pair.h:59,
from
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/utility:70,
from :1:
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/bits/move.h:77:5: note:
declared here
77 | forward(typename std::remove_reference<_Tp>::type& __t) noexcept
| ^~~
```
(https://godbolt.org/z/GW3xf71n3)
Incidentally, using the x86-64 gcc (static analysis) on compiler explorer fails
with:
```
during IPA pass: analyzer
: In function 'void qux()':
:11:9: internal compiler error: in make_region_for_type, at
analyzer/region-model.cc:5973
11 | bar(nullptr);
| ^~~
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug bootstrap/100654] trunk bootstrap errors with -O0 and -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100654 Richard Biener changed: What|Removed |Added Version|unknown |12.0 --- Comment #1 from Richard Biener --- When bootstrapping with non-standard flags you should consider using --disable-werror
[Bug testsuite/100655] 'g++.dg/tsan/pthread_cond_clockwait.C' FAILs due to 'pthread_cond_clockwait' missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100655 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-05-19 --- Comment #3 from Richard Biener --- Confirmed, I also see this.
[Bug c++/100659] [11/12 Regression] ICE in supplement_binding_1, at cp/name-lookup.c:2702
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100659 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.2
[Bug target/100660] [11/12 Regression] ICE in visit_assignment, at tree-ssa-ccp.c:2451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100660 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.2 Last reconfirmed||2021-05-19 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Component|c |target Priority|P3 |P2 --- Comment #1 from Richard Biener --- Confirmed: = VEC_COND_EXPR ; the LHS is missing. Target specific folding produces this from the call when the LHS is absent.
[Bug libstdc++/100667] New: std::tuple cannot be constructed from A&&, if A not defined (only forward declared)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100667
Bug ID: 100667
Summary: std::tuple cannot be constructed from A&&, if A
not defined (only forward declared)
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: piotrwn1 at gmail dot com
Target Milestone: ---
The following code stops working when switching from gcc10 to gcc11 (gcc11.1
and trunk too) (both c++17 and c++20):
#include
#include
class A;
std::tuple foo(A&& a) {
return std::tuple(std::move(a));
}
It looks that std library code start requiring this to pass:
std::is_nothrow_constructible...
Actually - I got this error when using gmock library (MOCK_METHOD), then I
extracted the problem to get SSCCE.
Error logs (https://godbolt.org/z/TqMar3Tn6):
In file included from
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/bits/move.h:57,
from
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/bits/stl_pair.h:59,
from
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/utility:70,
from :1:
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/type_traits: In
instantiation of 'struct std::is_nothrow_constructible':
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/type_traits:133:12:
required from 'struct std::__and_ >'
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/tuple:649:66: required
from 'static constexpr bool std::tuple<_Elements>::__nothrow_constructible()
[with _UElements = {A}; _Elements = {A&&}]'
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/tuple:733:49: required
from 'constexpr std::tuple<_Elements>::tuple(_UElements&& ...) [with _UElements
= {A}; bool _Valid = true; typename
std::enable_if::_TCC<_Valid>::__is_implicitly_constructible<_UElements
...>(), bool>::type = true; _Elements = {A&&}]'
:7:40: required from here
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/type_traits:971:25: error:
invalid use of incomplete type 'class A'
971 | = __bool_constant<__is_nothrow_constructible(_Tp, _Args...)>;
| ^
:4:7: note: forward declaration of 'class A'
4 | class A;
| ^
In file included from :2:
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/tuple: In instantiation of
'static constexpr bool std::tuple<_Elements>::__nothrow_constructible() [with
_UElements = {A}; _Elements = {A&&}]':
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/tuple:733:49: required
from 'constexpr std::tuple<_Elements>::tuple(_UElements&& ...) [with _UElements
= {A}; bool _Valid = true; typename
std::enable_if::_TCC<_Valid>::__is_implicitly_constructible<_UElements
...>(), bool>::type = true; _Elements = {A&&}]'
:7:40: required from here
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/tuple:649:73: error:
'value' is not a member of 'std::__and_
>'
649 | __and_...>::value;
|
^
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/tuple: In instantiation of
'constexpr std::tuple<_Elements>::tuple(_UElements&& ...) [with _UElements =
{A}; bool _Valid = true; typename
std::enable_if::_TCC<_Valid>::__is_implicitly_constructible<_UElements
...>(), bool>::type = true; _Elements = {A&&}]':
:7:40: required from here
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/tuple:733:49: in
'constexpr' expansion of 'std::tuple::__nothrow_constructible()'
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/tuple:732:9: error:
'constexpr' call flows off the end of the function
732 | tuple(_UElements&&... __elements)
| ^
ASM generation compiler returned: 1
In file included from
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/bits/move.h:57,
from
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/bits/stl_pair.h:59,
from
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/utility:70,
from :1:
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/type_traits: In
instantiation of 'struct std::is_nothrow_constructible':
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/type_traits:133:12:
required from 'struct std::__and_ >'
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/tuple:649:66: required
from 'static constexpr bool std::tuple<_Elements>::__nothrow_constructible()
[with _UElements = {A}; _Elements = {A&&}]'
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/tuple:733:49: required
from 'constexpr std::tuple<_Elements>::tuple(_UElements&& ...) [with _UElements
= {A}; bool _Valid = true; typename
std::enable_if::_TCC<_Valid>::__is_implicitly_constructible<_UElements
...>(), bool>::type = true; _Elements = {A&&}]'
:7:40: required from here
/opt/compiler-explorer
[Bug c/100661] [11/12 Regression] ICE in omp-low.c / refs_may_alias_p_2, at tree-ssa-alias.c:2460
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100661 Richard Biener changed: What|Removed |Added Keywords||openmp Target Milestone|--- |11.2 Summary|[11/12 Regression] ICE in |[11/12 Regression] ICE in |refs_may_alias_p_2, at |omp-low.c / |tree-ssa-alias.c:2460 |refs_may_alias_p_2, at ||tree-ssa-alias.c:2460 Last reconfirmed||2021-05-19 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- I get with checking: #0 fancy_abort (file=0x272ccf0 "/home/rguenther/src/gcc3/gcc/omp-low.c", line=3728, function=0x2730890 "scan_omp_1_op") at /home/rguenther/src/gcc3/gcc/diagnostic.c:1884 #1 0x01131956 in scan_omp_1_op (tp=0x766da378, walk_subtrees=0x7fffcdf4, data=0x7fffd240) at /home/rguenther/src/gcc3/gcc/omp-low.c:3728 #2 0x01762779 in walk_tree_1 (tp=0x766da378, func=0x11318a9 , data=0x7fffd240, pset=0x0, lh=0x0) at /home/rguenther/src/gcc3/gcc/tree.c:10966 #3 0x01763f16 in walk_tree_1 (tp=0x766a4bd8, func=0x11318a9 , data=0x7fffd240, pset=0x0, lh=0x0) at /home/rguenther/src/gcc3/gcc/tree.c:11314 #4 0x00f0a876 in walk_gimple_op (stmt=, callback_op=0x11318a9 , wi=0x7fffd240) at /home/rguenther/src/gcc3/gcc/gimple-walk.c:253 #5 0x00f0b7d3 in walk_gimple_stmt (gsi=0x7fffd060, callback_stmt=0x1131e42 , callback_op=0x11318a9 , wi=0x7fffd240) at /home/rguenther/src/gcc3/gcc/gimple-walk.c:596 #6 0x00f09eb5 in walk_gimple_seq_mod (pseq=0x76577418, callback_stmt=0x1131e42
[Bug c++/100668] New: Wrong warning highlight
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100668
Bug ID: 100668
Summary: Wrong warning highlight
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: brahim.pro at protonmail dot com
Target Milestone: ---
const char* const f() {
return nullptr;
}
When I compile this with -Wignored-qualifiers, the wrong const keyword is
highlighted.
Same problem her:
char const* const f() {
return nullptr;
}
and here:
char* const f() {
return nullptr;
}
[Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 --- Comment #20 from Aldy Hernandez --- On Wed, May 19, 2021 at 8:31 AM rguenth at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 > > --- Comment #17 from Richard Biener --- > (In reply to Andrew Macleod from comment #16) > > We could add an expression evaluator that can walk that expression, invoking > > range-ops on each expression, and calling a ranger instance to evaluate a > > range for any ssa_name it finds. > > > > It would bail if there are unknown tree-codes to range-ops. > > Yeah, it would be similar to the existing determine_value_range () function > which does exactly do this (but not using ranger). determine_value_range() has been calling range-ops under the covers for quite a while, so it's half-way there. It would require some minor tweaks: a) Use irange instead of value_range so as to not throw away the higher precision range-ops calculates. b) If we want context-aware ranges, pass it a gimple statement / edge / etc, and a range_query/ranger. Oh yeah, and return a proper range, not this value_range_kind + wide_int + wide_int business (determine_value_range_1 does this already).
[Bug middle-end/100669] New: [OpenACC] ICE with array-reduction variable & related issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100669
Bug ID: 100669
Summary: [OpenACC] ICE with array-reduction variable & related
issues
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, openacc
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: tschwinge at gcc dot gnu.org
Target Milestone: ---
While OpenMP supports reduction(+: sum[:10]) [→ PR99928 comment 8],
it is not quite clear to me whether OpenACC supports it.
(Admittedly, I also have not verified it in the OpenACC spec, yet).
I did not find any OpenACC testcase related to array reduction or struct
element/derived-type component reductions.
In any case, in C/C++, using an array gives the following ICE:
# gcc-trunk -fopenacc -fdump-tree-original foo.c
foo.c: In function ‘foo’:
foo.c:6:11: internal compiler error: tree check: expected tree that contains
‘decl minimal’ structure, have ‘mem_ref’ in splay_tree_compare_decl_uid, at
gimplify.c:440
6 | #pragma acc parallel loop reduction(+:sum)
| ^~~
0x788f2f tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../repos/gcc/gcc/tree.c:8857
* * *
On the Fortran side, reduction(+: array) is permitted for OpenACC during
parsing
but fails during resolution time with:
Error: Array ‘sum’ is not permitted in reduction at (1)
I also note that for a derived type, there is the odd result:
46 | !$acc parallel loop reduction(+:x%sum3)
| 1
Error: !$OMP DECLARE REDUCTION + not found for type TYPE(t) at (1)
with 'type t; integer :: sum3; end type'.
Namely: the error is a bit odd as the reduction variable is 'integer' which
does not need declare reduction – while the error talks about the derived type
itself ('x')
Question: Is it expected that 'x%...' should be parsed (accepted) with OpenACC?
With OpenMP it fails at parse time with:
38 | !$omp parallel do reduction(+:x%sum3)
| 1
Error: Syntax error in OpenMP variable list at (1)
NOTE: I have not checked what happens on the C/C++ side with struct elements.
[Bug c/100670] New: unused attribute ignored on function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100670
Bug ID: 100670
Summary: unused attribute ignored on function definition
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider the following test-case:
...
$ cat foo.c
typedef void *void_ptr;
static TYPE __attribute__((unused))
foo (void)
{
return 0;
}
...
Let's try with type int:
...
$ gcc-11 -c -Wall -O0 -g -Werror foo.c -DTYPE="int"
$
...
No warning.
Ok, now with void *:
...
$ gcc-11 -c -Wall -O0 -g -Werror foo.c -DTYPE="void *"
foo.c:4:1: error: ‘foo’ defined but not used [-Werror=unused-function]
4 | foo (void)
| ^~~
cc1: all warnings being treated as errors
...
Hmm, a warning.
Now with void_ptr:
...
$ gcc-11 -c -Wall -O0 -g -Werror foo.c -DTYPE="void_ptr"
$
...
again no warning.
My expectation was that there would be no warning for the "void *" case.
I cannot tell from the gcc attributes syntax documentation what is the correct
behaviour.
If this is not a compiler bug, then I suggest this is changed into a
documentation PR.
Note that there is at least one example that uses this style (
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
):
...
void __attribute__ ((visibility ("protected")))
f () { /* Do something. */; }
...
[Bug c/100671] New: override-init suppressed in 'two shot' compilation when initializer macro/value is defined in system header file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100671
Bug ID: 100671
Summary: override-init suppressed in 'two shot' compilation
when initializer macro/value is defined in system
header file
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.smets at nokia dot com
Target Milestone: ---
This test case reports a override-init error when doing a "one step"
compilation.
A "two shot" (preprocesing + compilation, eg, what distcc does) reports no
error when the initializer (macro) value is defined in a system header file.
I don't know if this is related, but the diagnostics point towards the value
and not the duplicate index.
#if 1
/* NULL defined in a system header file
=> warning in "one shot" compilation.
=> no warning in "two shot" compilation. */
#include
#else
/* always warns */
#define NULL (0L)
#endif
void*table[] =
{
[0] NULL,
[0] NULL,
};
echo "One shot"
gcc -c test.c -Woverride-init -o /dev/null
echo "Two shot"
gcc -c test.c -Woverride-init -o test.i -E
gcc -c test.i -o /dev/null -Woverride-init
[Bug c++/100666] [9/10/11/12 Regression] warning: ignoring return value of 'constexpr _Tp&& std::forward(typename std::remove_reference<_Tp>::type&) [with _Tp = std::nullptr_t; ...]', declared with at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100666
Jonathan Wakely changed:
What|Removed |Added
Known to work||7.5.0, 8.3.0, 9.2.0
Ever confirmed|0 |1
Last reconfirmed||2021-05-19
Known to fail||10.1.0, 11.1.0, 12.0,
||8.4.0, 9.3.0
Status|UNCONFIRMED |NEW
CC||jakub at gcc dot gnu.org
Summary|warning: ignoring return|[9/10/11/12 Regression]
|value of 'constexpr _Tp&& |warning: ignoring return
|std::forward(typename |value of 'constexpr _Tp&&
|std::remove_reference<_Tp>: |std::forward(typename
|:type&) [with _Tp = |std::remove_reference<_Tp>:
|std::nullptr_t; typename|:type&) [with _Tp =
|std::remove_reference<_Tp>: |std::nullptr_t; ...]',
|:type = std::nullptr_t]', |declared with attribute
|declared with attribute |'nodiscard'
|'nodiscard' |[-Wunused-result]
|[-Wunused-result] |
--- Comment #1 from Jonathan Wakely ---
(In reply to Mike Hommey from comment #0)
> (Note I'm not entirely sure this is a GCC bug, but it doesn't happen with
> GCC < 11 and with clang)
Yeah, this shouldn't warn.
Reduced:
[[nodiscard]] decltype(nullptr) null();
extern void foo(...);
void qux() {
foo(null());
}
GCC 10 has the same warning, it's just that std::forward didn't have the
[[nodiscard]] attribute.
It only happens when a nodiscard function returns std::nullptr_t and it's
passed to an ellipsis. GCC 7 was OK, and 8.3 and 9.2
It started with r279680:
re PR c++/92992 (Side-effects dropped when decltype(nullptr) typed
expression is passed to ellipsis)
PR c++/92992
* call.c (convert_arg_to_ellipsis): For decltype(nullptr) arguments
that have side-effects use cp_build_compound_expr.
* g++.dg/cpp0x/nullptr45.C: New test.
[Bug c++/100666] [9/10/11/12 Regression] warning: ignoring return value of 'constexpr _Tp&& std::forward(typename std::remove_reference<_Tp>::type&) [with _Tp = std::nullptr_t; ...]', declared with at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100666 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=92992 Target Milestone|--- |9.5
[Bug c++/100668] Wrong warning highlight
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100668 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jonathan Wakely --- Looks like a variation of my PR 85468 *** This bug has been marked as a duplicate of bug 85468 ***
[Bug c++/85468] Wrong location for -Wignored-qualifiers diagnostic on conversion operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85468 Jonathan Wakely changed: What|Removed |Added CC||brahim.pro at protonmail dot com --- Comment #2 from Jonathan Wakely --- *** Bug 100668 has been marked as a duplicate of this bug. ***
[Bug c++/85468] Wrong location for -Wignored-qualifiers diagnostic on conversion operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85468
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2020-11-10 00:00:00 |2021-05-19
--- Comment #3 from Jonathan Wakely ---
>From Bug 100668:
const char* const f() {
return nullptr;
}
char const* const f2() {
return nullptr;
}
char* const f3() {
return nullptr;
}
c.C:1:1: warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
1 | const char* const f() {
| ^
c.C:6:1: warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
6 | char const* const f2() {
| ^~~~
c.C:10:1: warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
10 | char* const f3() {
| ^~~~
[Bug libstdc++/100667] [11/12 Regression] std::tuple cannot be constructed from A&&, if A not defined (only forward declared)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100667 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Priority|P3 |P2 Keywords||rejects-valid Summary|std::tuple cannot be |[11/12 Regression] |constructed from A&&, if A |std::tuple cannot be |not defined (only forward |constructed from A&&, if A |declared) |not defined (only forward ||declared) Target Milestone|--- |11.2 Last reconfirmed||2021-05-19 Known to work||10.3.0
[Bug c/100671] override-init suppressed in 'two shot' compilation when initializer macro/value is defined in system header file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100671
--- Comment #1 from Jan Smets ---
Another one we've had problems with is quite similar. The example below is a
void function trying to return a value.
#if 1
/* NULL defined in a system header file
=> warning in "one shot" compilation.
=> no warning in "two shot" compilation. */
#include
#else
/* always warns */
#define NULL (0L)
#endif
void test(void)
{
return NULL;
}
[Bug c/100670] unused attribute ignored on function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100670 --- Comment #1 from Tom de Vries --- Note btw that clang does not generate a warning: ... $ clang -c -Wall -O0 -g -Werror foo.c -DTYPE="void *" $ ... which means the attribute works, because if we remove the attribute we have instead: ... $ clang -c -Wall -O0 -g -Werror foo.c -DTYPE="void *" foo.c:4:1: error: unused function 'foo' [-Werror,-Wunused-function] foo (void) ^ 1 error generated. ...
[Bug middle-end/100669] [OpenACC] ICE with array-reduction variable & related issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100669 Thomas Schwinge changed: What|Removed |Added Last reconfirmed||2021-05-19 Keywords|ice-on-valid-code |ice-on-invalid-code Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Thomas Schwinge --- We're currently implementing OpenACC 2.6, and only in OpenACC 2.7 we have: 1.12 "Changes from Version 2.6 to 2.7": "Arrays, subarrays and composite variables are now allowed in 'reduction' clauses; [...]". (Thus 'ice-on-valid-code' -> 'ice-on-invalid-code'.) That said, of course we shouldn't run into an ICE. I wonder if that's a regression, or has been like that "forever"?
[Bug target/83812] nvptx-run: error getting kernel result: operation not supported on global/shared address space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83812 Thomas Schwinge changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||tschwinge at gcc dot gnu.org Last reconfirmed||2021-05-19 --- Comment #2 from Thomas Schwinge --- See also PR97444.
[Bug c/100671] override-init suppressed in 'two shot' compilation when initializer macro/value is defined in system header file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100671 --- Comment #2 from Andrew Pinski --- I think this is a dup of bug 99791.
[Bug fortran/100662] intrinsic::ieee_arithmetic fails on aarch, powerpc architectures on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662 ripero84 at gmail dot com changed: What|Removed |Added CC||ripero84 at gmail dot com --- Comment #9 from ripero84 at gmail dot com --- Steve, is this a GCC bug or a FreeBSD bug (or if it is something else, what side does this belong to)? Other OSs seem to be able to compile gfortran with these modules for these architectures, see, e.g., https://packages.ubuntu.com/focal/arm64/gfortran-10/filelist and https://packages.ubuntu.com/focal/ppc64el/gfortran-10/filelist). And they seem to have been able to do so since the introduction of the three Fortran IEEE intrinsic modules in GCC 5 (https://packages.ubuntu.com/bionic/amd64/gfortran-5/filelist and https://packages.ubuntu.com/bionic/ppc64el/gfortran-5/filelist). Therefore, some kind of solution must exist for this - and probably has been there for over half a decade. (Apologies for not being able to provide a better insight from the Ubuntu sources.) Thank you.
[Bug c/100670] unused attribute ignored on function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100670 Richard Biener changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2021-05-19 Status|UNCONFIRMED |NEW Keywords||documentation --- Comment #2 from Richard Biener --- I think you need to use static __attribute__((unused)) TYPE thus documentation bug. Attribute parsing is somewhat odd, esp. when pointer types are involved.
[Bug c++/100659] [11/12 Regression] ICE in supplement_binding_1, at cp/name-lookup.c:2702 since r11-5003-gd50310408f54e380
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100659 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-05-19 Ever confirmed|0 |1 Summary|[11/12 Regression] ICE in |[11/12 Regression] ICE in |supplement_binding_1, at|supplement_binding_1, at |cp/name-lookup.c:2702 |cp/name-lookup.c:2702 since ||r11-5003-gd50310408f54e380 Status|UNCONFIRMED |NEW CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Confirmed, started with r11-5003-gd50310408f54e380.
[Bug target/100660] [12 Regression] ICE in visit_assignment, at tree-ssa-ccp.c:2451 since r12-110-gc54a9f7259fce1a2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100660 Martin Liška changed: What|Removed |Added Summary|[11/12 Regression] ICE in |[12 Regression] ICE in |visit_assignment, at|visit_assignment, at |tree-ssa-ccp.c:2451 |tree-ssa-ccp.c:2451 since ||r12-110-gc54a9f7259fce1a2 CC||crazylht at gmail dot com, ||marxin at gcc dot gnu.org Target Milestone|11.2|12.0 --- Comment #2 from Martin Liška --- Started with r12-110-gc54a9f7259fce1a2.
[Bug middle-end/100576] [11/12 Regression] ICE at -O1 and above: in decompose, at wide-int.h:984 since r11-2928-gd14c547abd484d35
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100576 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e6683450f4a26dae7774be735a3429f48aee9565 commit r12-906-ge6683450f4a26dae7774be735a3429f48aee9565 Author: Jakub Jelinek Date: Wed May 19 12:05:30 2021 +0200 builtins: Fix ICE with unprototyped builtin call [PR100576] For unprototyped builtins the checking we perform is only about whether the used argument is integral, pointer etc., not the exact precision. We emit a warning about the problem though: pr100576.c: In function âfooâ: pr100576.c:9:11: warning: implicit declaration of function âmemcmpâ [-Wimplicit-function-declaration] 9 | int n = memcmp (p, v, b); | ^~ pr100576.c:1:1: note: include ââ or provide a declaration of âmemcmpâ +++ |+#include 1 | /* PR middle-end/100576 */ pr100576.c:9:25: warning: âmemcmpâ argument 3 type is âintâ where âlong unsigned intâ is expected in a call to built-in function declared without prototype +[-Wbuiltin-declaration-mismatch] 9 | int n = memcmp (p, v, b); | ^ It means in the testcase below where the user incorrectly called memcmp with last argument int rather then size_t, the warning stuff in builtins.c ICEs because it compares a wide_int from such a bound with another wide_int which has precision of size_t/sizetype and wide_int asserts the compared wide_ints are compatible. Fixed by forcing the bound to have the right type. 2021-05-19 Jakub Jelinek PR middle-end/100576 * builtins.c (check_read_access): Convert bound to size_type_node if non-NULL. * gcc.c-torture/compile/pr100576.c: New test.
[Bug middle-end/100576] [11 Regression] ICE at -O1 and above: in decompose, at wide-int.h:984 since r11-2928-gd14c547abd484d35
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100576 Jakub Jelinek changed: What|Removed |Added Summary|[11/12 Regression] ICE at |[11 Regression] ICE at -O1 |-O1 and above: in |and above: in decompose, at |decompose, at |wide-int.h:984 since |wide-int.h:984 since|r11-2928-gd14c547abd484d35 |r11-2928-gd14c547abd484d35 | --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug rtl-optimization/100554] [9/10/11/12 Regression] -fcompare-debug failure w/ -Os -fmodulo-sched -fno-tree-loop-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100554 Roman Zhuykov changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=100533, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=100523 CC||abel at ispras dot ru, ||jakub at redhat dot com, ||zhroma at gcc dot gnu.org --- Comment #1 from Roman Zhuykov --- > Is it an issue at all? > Should I report more issues of this kind in the future? I think the answer is "yes" for both questions, thanks for your reports! A year ago when I bothered about regtesting with -fcompare-debug I've created a few issues unrelated to modulo scheduler and Jakub fixed most of them. Short summary is available at https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542389.html, there I've also investigated everything on modulo sched side, but small patch2.txt was never committed. Given now we are in stage1 and have three PRs (I'll check PR100533 and PR100523, they should be same), now it's time to push that.
[Bug target/83812] nvptx-run: error getting kernel result: operation not supported on global/shared address space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83812
--- Comment #3 from Thomas Schwinge ---
By the way, curious why this isn't caught at compile time ('ptxas'
verification) but only at run time (CUDA Driver/PTX JIT).
[Bug tree-optimization/100672] New: wrong code with vector shift and unary minus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100672 Bug ID: 100672 Summary: wrong code with vector shift and unary minus Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Created attachment 50843 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50843&action=edit reduced testcase Output: $ x86_64-pc-linux-gnu-gcc testcase.c -Wno-psabi $ ./a.out Aborted Seems to happen at any optimization level, and for any 32bit or 64bit target. Rewriting the expression as "(-v >> 1)" results in the expected output. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-905-20210519101846-ga73a5af281c-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r12-905-20210519101846-ga73a5af281c-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.0 20210519 (experimental) (GCC)
[Bug tree-optimization/100672] wrong code with vector shift and unary minus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100672 Zdenek Sojka changed: What|Removed |Added Known to fail||10.3.1, 11.1.1, 12.0, ||5.5.0, 6.5.0, 7.5.0, 8.4.0, ||9.3.1 --- Comment #1 from Zdenek Sojka --- Adding 8.4.0 as "Known to fail", since 8.5.0 cannot be entered: The value "8.5.0" used in the "Known to fail" field is not a valid version for the "gcc" product.
[Bug c++/100673] New: [coroutines] Non-template, UDT await_suspend return-type results in ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100673
Bug ID: 100673
Summary: [coroutines] Non-template, UDT await_suspend
return-type results in ICE.
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jehelset at gmail dot com
Target Milestone: ---
Created attachment 50844
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50844&action=edit
ICE on non-template UDT await_suspend return-type.
A non-template udt return-type from await_suspend will ICE on trunk:
https://godbolt.org/z/Gn7djfrac
#0 build_co_await (loc=674010823, a=0x7163f1c0, suspend_kind=) at ../../gcc/cp/coroutines.cc:993
993 tree tt = CLASSTYPE_TI_TEMPLATE (susp_return_type);
Relevant code:
else if (TREE_CODE (susp_return_type) == RECORD_TYPE
&& CLASS_TYPE_P (susp_return_type))
{
tree tt = CLASSTYPE_TI_TEMPLATE (susp_return_type);
if (tt == coro_handle_templ)
ok = true;
}
Seems to be checking the validity of the await_suspend call, to produce a
helpful diagnostic. Perhaps the conditional also needs to verify that
CLASSTYPE_TEMPLATE_INFO (coro_handle_templ) is non-NULL, before using
CLASSTYPE_TI_TEMPLATE.
Seemed to be the case on 10.3, 11.1 and on 12.0. 10.2 failed to compile it
without crashing.
[Bug c/100674] New: creation of alias symbols not used for optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100674
Bug ID: 100674
Summary: creation of alias symbols not used for optimization
Product: gcc
Version: 10.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: marian.buschsieweke at ovgu dot de
Target Milestone: ---
Let's consider the following source code:
int foo(int a, int b) {
return a + b;
}
__attribute__((weak))
int bar(int a, int b)
{
return foo(a, b);
}
And now the alternative implementation of the above:
int foo(int a, int b) {
return a + b;
}
int bar(int a, int b) __attribute__((weak, alias("foo")));
For the first version, GCC will emit machine code for bar which is just calling
foo, in the second GCC will emit bar as an alias for symbol foo (as explicitly
instructed to do). IMO, it would be valid (and obviously more efficient) to
also just emit an alias for the first example.
Note: Dropping the weak attribute doesn't change the output (other than no
longer marking the symbol foo as weak, as expected). I decided to include the
weak attribute in the example to point to this corner case that the alias can
indeed be a weak symbol, while the original symbol is not.
My use case is a general initialization routine, which should be possible to be
replaced by a more specific initialization routine. However, the more specific
one should still be able reuse the code from the general one by just calling
it. Hence, I need two symbols for the general routine - the regular init
function as weak symbol, and a second name for it so that the more specific one
taking preference over the weak general one can call that. IMO the first
version of the source code is much easier to read. But I would still like the
binary to be as efficient as the second one :-)
[Bug driver/86030] specs file processing does not create response files for input directories
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030 Jonathan Wakely changed: What|Removed |Added Last reconfirmed|2018-07-02 00:00:00 |2021-5-19 --- Comment #4 from Jonathan Wakely --- This is still a problem today: https://github.com/envoyproxy/envoy/issues/16196
[Bug middle-end/98109] Seemingly wrong warnings from -Wnonnull when combined with -O2 -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98109
James Legg changed:
What|Removed |Added
CC||jlegg at feralinteractive dot
com
--- Comment #2 from James Legg ---
The false positives can often be seen when converting a lambda to a function
pointer at lower optimisation levels too. For example, in g++ 11.1.1,
compiling:
int main()
{
return static_cast([](int x){ return x; })(0);
}
with -Og -Wall -fsanitize=undefined results in:
/tmp/a.cc: In static member function ‘static constexpr int
main()_FUN(int)’:
/tmp/a.cc:3:63: warning: ‘this’ pointer is null [-Wnonnull]
3 | return static_cast([](int x){ return x; })(0);
| ^
/tmp/a.cc:3:42: note: in a call to non-static member function
‘main()::’
3 | return static_cast([](int x){ return x; })(0);
| ^
[Bug c++/100675] New: std::string_view::find in constexpr function is not constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100675
Bug ID: 100675
Summary: std::string_view::find in constexpr function is not
constant expression
Product: gcc
Version: 10.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
The following code fails in 10.1, 10.2, and 10.3:
https://godbolt.org/z/soGT9o4GY
#include
template
constexpr bool g() {
std::string_view s = " ";
s.find(" ");
return true;
}
constexpr bool b = g(); // ok
template concept C = g();
static_assert(C);// error
[Bug libstdc++/100676] New: Redeclaring __failed_assertion() at every point of use of __glibcxx_assert breaks Clang CUDA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100676 Bug ID: 100676 Summary: Redeclaring __failed_assertion() at every point of use of __glibcxx_assert breaks Clang CUDA Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: joachim at joameyer dot de Target Milestone: --- As noted in https://bugs.llvm.org/show_bug.cgi?id=50383 the use of __glibcxx_assert in the complex functions breaks using the complex header with Clang CUDA. The way Clang CUDA handles that might not be ideal, but the libstdc++ issue seems to be present anyways: In every use of __glibcxx_assert the function __failed_assertion is redeclared and btw. never defined, which might break other projects as well, and then is used as an assertion in constant evaluated contexts, as it is a non constexpr function. I wasn't able to come up with an entirely better approach so far, but I guess most of the issues, that I could think of so far, would be solved by moving the void __failed_assertion(); declaration out of the macro. This would fix the issues with Clang CUDA for example: https://cuda.godbolt.org/z/GTMnxez7j
[Bug c++/100677] New: False positive unused-but-set-parameter warning when using VSX intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100677
Bug ID: 100677
Summary: False positive unused-but-set-parameter warning when
using VSX intrinsics
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alexander.gr...@tu-dresden.de
Target Milestone: ---
On some code like the below the unused-but-set-parameter warning is incorrectly
triggered:
class Vec256 {
union {
struct {
vfloat32 _vec0;
vfloat32 _vec1;
};
struct {
vbool32 _vecb0;
vbool32 _vecb1;
};
} __attribute__((__may_alias__));
Vec256(float scalar)
: _vec0{vec_splats(scalar)}, _vec1{vec_splats(scalar)} {}
};
GCC seems to think "scalar" is unused even though it is passed to "vec_splats"
which is defined as "#define vec_splats __builtin_vec_splats"
This seems to also apply to other intrinsics, see e.g.
https://qlf-gitlab.inria.fr/guenneba/eigenci-junit-test/-/blob/85330d21b58bccbf95c90e874db2a0f6775ff63b/Eigen/src/Core/arch/AltiVec/PacketMath.h#L271-275
[Bug tree-optimization/100672] wrong code with vector shift and unary minus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100672
--- Comment #2 from Richard Biener ---
Maybe sth is wrong with the testcase? clang also results in an abort. Isn't
right-shift of negative values undefined?
.original dumps
;; Function foo (null)
;; enabled by -tree-original
{
return VIEW_CONVERT_EXPR(VIEW_CONVERT_EXPR(v) >>
1);
}
where the negate is dopped somehow.
[Bug tree-optimization/100672] wrong code with vector shift and unary minus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100672
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-05-19
--- Comment #3 from Richard Biener ---
We have in negate_expr/negate_expr_p
case RSHIFT_EXPR:
/* Optimize -((int)x >> 31) into (unsigned)x >> 31 for int. */
if (TREE_CODE (TREE_OPERAND (t, 1)) == INTEGER_CST)
{
tree op1 = TREE_OPERAND (t, 1);
if (wi::to_wide (op1) == TYPE_PRECISION (type) - 1)
{
tree ntype = TYPE_UNSIGNED (type)
? signed_type_for (type)
: unsigned_type_for (type);
tree temp = fold_convert_loc (loc, ntype, TREE_OPERAND (t, 0));
temp = fold_build2_loc (loc, RSHIFT_EXPR, ntype, temp, op1);
return fold_convert_loc (loc, type, temp);
}
}
note the use of TYPE_PRECISION on a vector type...
[Bug tree-optimization/100672] wrong code with vector shift and unary minus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100672
--- Comment #4 from Richard Biener ---
diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index 419117dca3f..ef0d15a289d 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -512,7 +512,7 @@ negate_expr_p (tree t)
if (TREE_CODE (TREE_OPERAND (t, 1)) == INTEGER_CST)
{
tree op1 = TREE_OPERAND (t, 1);
- if (wi::to_wide (op1) == TYPE_PRECISION (type) - 1)
+ if (wi::to_wide (op1) == element_precision (type) - 1)
return true;
}
break;
@@ -705,7 +705,7 @@ fold_negate_expr_1 (location_t loc, tree t)
if (TREE_CODE (TREE_OPERAND (t, 1)) == INTEGER_CST)
{
tree op1 = TREE_OPERAND (t, 1);
- if (wi::to_wide (op1) == TYPE_PRECISION (type) - 1)
+ if (wi::to_wide (op1) == element_precision (type) - 1)
{
tree ntype = TYPE_UNSIGNED (type)
? signed_type_for (type)
fixes that, retaining the negate, but it's still broken somewhere.
[Bug tree-optimization/100672] wrong code with vector shift and unary minus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100672 Richard Biener changed: What|Removed |Added Status|NEW |WAITING --- Comment #5 from Richard Biener --- Hmm, don't you want a signed vector component? You're getting a logical right shift as written.
[Bug middle-end/100672] wrong code with vector shift and unary minus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100672
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Component|tree-optimization |middle-end
Status|WAITING |ASSIGNED
--- Comment #6 from Richard Biener ---
typedef long long __attribute__((__vector_size__ (32))) V;
V
foo (V v)
{
return -(v >> 1);
}
int
main (void)
{
V v = foo ((V) { -2, -4, -6, -8 });
if (v[0] != 1 || v[1] != 2 || v[2] != 3 || v[3] != 4)
__builtin_abort ();
return 0;
}
fails before my patch and succeeds afterwards.
[Bug middle-end/100672] wrong code with vector shift and unary minus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100672
--- Comment #7 from Zdenek Sojka ---
(In reply to Richard Biener from comment #2)
> Maybe sth is wrong with the testcase? clang also results in an abort. Isn't
> right-shift of negative values undefined?
>
Thank you for having a look.
I believe the behavior is fully defined. The vectors are unsigned, and the
conversion to unsigned is done by adding 2**64; this behaves the same:
$ cat testcase.c
typedef unsigned long long __attribute__((__vector_size__ (32))) V;
V
foo (V v)
{
return -(v >> 1);
}
int
main (void)
{
V v = foo ((V) { 0xfffe, 0xfffc,
0xfffa, 0xfff8 });
if (v[0] != 1 || v[1] != 2 || v[2] != 3 || v[3] != 4)
__builtin_abort ();
return 0;
}
Maybe clang behaves the same since the behavior was the same in the moment when
clang was forked.
[Bug middle-end/100672] wrong code with vector shift and unary minus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100672
--- Comment #8 from Richard Biener ---
(In reply to Zdenek Sojka from comment #7)
> (In reply to Richard Biener from comment #2)
> > Maybe sth is wrong with the testcase? clang also results in an abort.
> > Isn't
> > right-shift of negative values undefined?
> >
>
> Thank you for having a look.
>
> I believe the behavior is fully defined. The vectors are unsigned, and the
> conversion to unsigned is done by adding 2**64; this behaves the same:
>
> $ cat testcase.c
> typedef unsigned long long __attribute__((__vector_size__ (32))) V;
>
> V
> foo (V v)
> {
> return -(v >> 1);
but this is a logical right shift, thus gives 0x7ff...e, ...
and negating that doesn't yield 1.
> }
>
> int
> main (void)
> {
> V v = foo ((V) { 0xfffe, 0xfffc,
>0xfffa, 0xfff8 });
> if (v[0] != 1 || v[1] != 2 || v[2] != 3 || v[3] != 4)
> __builtin_abort ();
> return 0;
> }
>
> Maybe clang behaves the same since the behavior was the same in the moment
> when clang was forked.
[Bug middle-end/100672] wrong code with vector shift and unary minus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100672
--- Comment #9 from Zdenek Sojka ---
(In reply to Richard Biener from comment #8)
> (In reply to Zdenek Sojka from comment #7)
> > (In reply to Richard Biener from comment #2)
> > > Maybe sth is wrong with the testcase? clang also results in an abort.
> > > Isn't
> > > right-shift of negative values undefined?
> > >
> >
> > Thank you for having a look.
> >
> > I believe the behavior is fully defined. The vectors are unsigned, and the
> > conversion to unsigned is done by adding 2**64; this behaves the same:
> >
> > $ cat testcase.c
> > typedef unsigned long long __attribute__((__vector_size__ (32))) V;
> >
> > V
> > foo (V v)
> > {
> > return -(v >> 1);
>
> but this is a logical right shift, thus gives 0x7ff...e, ...
> and negating that doesn't yield 1.
>
Shame on me. You are very right.
[Bug libstdc++/100676] Redeclaring __failed_assertion() at every point of use of __glibcxx_assert breaks Clang CUDA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100676 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-05-19 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Jonathan Wakely --- (In reply to J.M. from comment #0) > In every use of __glibcxx_assert the function __failed_assertion is > redeclared and btw. never defined, By design. > which might break other projects as well, How? > and then is used as an assertion in constant evaluated contexts, as it is a > non constexpr function. Right, it's only ever used when we want compilation to fail. So it's never odr-used, so no call to it is ever emitted in the generated assembly, so no definition is needed. > I wasn't able to come up with an entirely better approach so far, Which is why this "awful" construct is used. > but I > guess most of the issues, that I could think of so far, would be solved by > moving the void __failed_assertion(); declaration out of the macro. The idea was to not pollute the namespace with a declaration of a function that will never exist.
[Bug middle-end/100672] wrong code with vector shift and unary minus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100672
--- Comment #10 from Zdenek Sojka ---
(In reply to Zdenek Sojka from comment #9)
> (In reply to Richard Biener from comment #8)
> > (In reply to Zdenek Sojka from comment #7)
> > > (In reply to Richard Biener from comment #2)
> > > > Maybe sth is wrong with the testcase? clang also results in an abort.
> > > > Isn't
> > > > right-shift of negative values undefined?
> > > >
> > >
> > > Thank you for having a look.
> > >
> > > I believe the behavior is fully defined. The vectors are unsigned, and the
> > > conversion to unsigned is done by adding 2**64; this behaves the same:
> > >
> > > $ cat testcase.c
> > > typedef unsigned long long __attribute__((__vector_size__ (32))) V;
> > >
> > > V
> > > foo (V v)
> > > {
> > > return -(v >> 1);
> >
> > but this is a logical right shift, thus gives 0x7ff...e, ...
> > and negating that doesn't yield 1.
> >
>
> Shame on me. You are very right.
I did the mistake while reducing the testcase.
The original testcase had positive arguments:
$ cat testcase.c
typedef unsigned long long __attribute__((__vector_size__ (32))) V;
V
foo (V v)
{
return -(v >> 1);
}
int
main (void)
{
V v = foo ((V) { 2, 4, 6, 8 });
if (v[0] != 0x || v[1] != 0xfffe ||
v[2] != 0xfffd || v[3] != 0xfffc)
__builtin_abort ();
return 0;
}
I wanted to prevent the long 0xf... constants, but broke the testcase in he
process. Thank you for correcting me.
[Bug bootstrap/100654] trunk bootstrap errors with -O0 and -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100654 --- Comment #2 from Manfred Schwarb --- OK, then I will not report such issues in the future and use --disable-werror per default when using non-standard flags. Thanks.
[Bug bootstrap/100654] trunk bootstrap errors with -O0 and -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100654 Martin Liška changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #3 from Martin Liška --- Closing..
[Bug c/100661] [11/12 Regression] ICE in omp-low.c / refs_may_alias_p_2, at tree-ssa-alias.c:2460
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100661 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- It seems it started with r6-6362-gb2b40051500c944e.
[Bug target/83812] nvptx-run: error getting kernel result: operation not supported on global/shared address space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83812 --- Comment #4 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:1467100fc72562a59f70cdd4e05f6c810d1fadcc commit r12-908-g1467100fc72562a59f70cdd4e05f6c810d1fadcc Author: Thomas Schwinge Date: Wed May 19 11:58:49 2021 +0200 Add 'libgomp.oacc-c-c++-common/private-atomic-1.c' [PR83812] ... to at least document/test/XFAIL nvptx offloading: PR83812 "operation not supported on global/shared address space". libgomp/ PR target/83812 * testsuite/libgomp.oacc-c-c++-common/private-atomic-1.c: New.
[Bug fortran/96983] [11/12 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #34 from Tobias Burnus --- What's actually the status of the PR – I mean on both powerpc64*-linux-gnu, sparc*-*-*. The summary states that there is an ICE – is this still the case? I am especially interested in the sparc*-*-* status. With powerpc64le-linux-gnu, I do not see an ICE anymore but two post-compilation FAILs for which I propose: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570732.html Does this also help for sparc*-*-* (and other powerpc64*-linux-gnu)? If not, what remains to be done? I assume that also some GCC 11 backporting is needed.
[Bug libstdc++/100630] Unexpected implicit conversion from volatile bool& to std::filesystem::path in gcc <= 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100630 --- Comment #5 from Romain Geissler --- Hi, Thanks for providing a fix that quickly ! I backported it in my own copy of gcc 8 and 9 and it fixed my issue on these branches as well. Cheers, Romain
[Bug target/100678] New: [OpenACC/nvptx] 'libgomp.oacc-c-c++-common/private-atomic-1.c' FAILs (differently) in certain configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100678 Bug ID: 100678 Summary: [OpenACC/nvptx] 'libgomp.oacc-c-c++-common/private-atomic-1.c' FAILs (differently) in certain configurations Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: openacc Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org CC: jules at gcc dot gnu.org, vries at gcc dot gnu.org Target Milestone: --- Target: nvptx For OpenACC/nvptx offloading, the testcase 'libgomp.oacc-c-c++-common/private-atomic-1.c' that I've just pushed as commit r12-908-g1467100fc72562a59f70cdd4e05f6c810d1fadcc "Add 'libgomp.oacc-c-c++-common/private-atomic-1.c' [PR83812]" has been expected to fail with "operation not supported on global/shared address space" (see PR83812). However, I now found that on an x86_64 GNU/Linux system, Nvidia TITAN V GPU, CUDA Driver 455.23.05, it *doesn't* fail in that way: the device kernel execution completes normally -- but it instead returns a wrong reduction result: zero. At this point, it's (a) unclear whether the PR83812 restriction indeed is supposed to be lifted for certain modern GPU hardware/SM levels/CUDA Driver releases, and (b) what is then instead going wrong so that we don't compute the expected reduction result. Assuming that (a) has been done in good faith, I can see how (b) might happen if the 'v' variable would in fact *not* be thread-private (but instead device-global, I suppose), thus all threads atomically incrementing the device-global variable concurrently, thus the '(v == -222 + 121)' expression never being true?
[Bug c++/100675] std::string_view::find in constexpr function is not constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100675
--- Comment #1 from 康桓瑋 ---
(In reply to 康桓瑋 from comment #0)
> The following code fails in 10.1, 10.2, and 10.3:
>
> https://godbolt.org/z/soGT9o4GY
>
> #include
>
> template
> constexpr bool g() {
> std::string_view s = " ";
> s.find(" ");
> return true;
> }
>
> constexpr bool b = g(); // ok
> template concept C = g();
> static_assert(C);// error
If change constexpr to consteval then compiles:
template
consteval bool g() {
std::string_view s = " ";
s.find(" ");
return true;
}
[Bug target/100678] [OpenACC/nvptx] 'libgomp.oacc-c-c++-common/private-atomic-1.c' FAILs (differently) in certain configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100678 --- Comment #1 from Tom de Vries --- (In reply to Thomas Schwinge from comment #0) > At this point, it's (a) unclear whether the PR83812 restriction indeed is > supposed to be lifted for certain modern GPU hardware/SM levels/CUDA Driver > releases, Looking at the latest ptx isa spec, 7.3, we have: ... Atomic operations may be used only with .global and .shared spaces and with generic addressing, where the address points to .global or .shared space. ... That seems pretty clear. It's also not unusual for different archs to have different failure modes. I'm not sure what you aim to achieve with the test-case. My inclination would be to skip it for nvptx, which AFAIU is opposite to your intent when adding it. So, perhaps just remove it?
[Bug testsuite/100658] Typos in dg commands and texi files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100658
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #1 from Martin Liška ---
I'm going to fix the typos, thanks,
> ./gcc/testsuite/gcc.dg/cpp/lexident.c:8:/* Escaped newlines, _ and $ in
> identifiers. */
> ./gcc/testsuite/gcc.target/i386/pr91298-1.c:4:/* { dg-xfail-if "No support
> for $ in identifiers" { *-*-solaris2.* && { ! gas } } } */
> ./gcc/testsuite/gcc.target/i386/pr91298-2.c:4:/* { dg-xfail-if "No support
> for $ in identifiers" { *-*-solaris2.* && { ! gas } } } */
> ./libcpp/charset.c:1131: cpp_error (pfile, CPP_DL_PEDWARN, "'$' in
> identifier or number");
> ./libcpp/lex.c:1335: cpp_error (pfile, CPP_DL_PEDWARN, "'$' in
> identifier or number");
What's wrong about the $ sign?
[Bug testsuite/100658] Typos in dg commands and texi files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100658 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:32bd0353db37af2cb023e575ed4ce8c944fd9dba commit r12-912-g32bd0353db37af2cb023e575ed4ce8c944fd9dba Author: Martin Liska Date: Wed May 19 15:25:36 2021 +0200 Fix typos. PR testsuite/100658 gcc/cp/ChangeLog: * mangle.c (write_encoding): Fix typos. gcc/jit/ChangeLog: * libgccjit.c (gcc_jit_context_new_function): Fix typos. gcc/testsuite/ChangeLog: * gcc.dg/local1.c: Fix typos. * gcc.dg/ucnid-5-utf8.c: Likewise. * gcc.dg/ucnid-5.c: Likewise.
[Bug testsuite/100655] 'g++.dg/tsan/pthread_cond_clockwait.C' FAILs due to 'pthread_cond_clockwait' missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100655 --- Comment #4 from Martin Liška --- (In reply to Jonathan Wakely from comment #2) > It's not glibc-specific though, it's going to be in the next POSIX standard > and other C libraries. > > It's a bit of a hack, but you could include any libstdc++ header and then > check _GLIBCXX_USE_PTHREAD_COND_CLOCKWAIT (because libstdc++ already has > autoconf checks for it). Can you please prepare such a patch?
[Bug c/100680] New: false positive warning for certain __builtin_memcmp() argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100680
Bug ID: 100680
Summary: false positive warning for certain __builtin_memcmp()
argument
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jbeulich at suse dot com
Target Milestone: ---
In this example
struct s {
char a[8];
int i;
long l;
};
extern char ea[8];
static char sa[8] = { 1, 2, 3, 4 };
int test(void) {
const struct s*ps = (const struct s *)0x12345678L;
if(__builtin_memcmp(ps->a, ps->a, 8))
return 0;
if(__builtin_memcmp(ps->a, ea, 8))
return 0;
if(__builtin_memcmp(ps->a, sa, 8))
return 0;
if(__builtin_memcmp(ps->a, "abcdABCD", 8))
return 0;
return 1;
}
all except, oddly enough, the first invocation cause "'__builtin_memcmp'
specified bound of 8 exceeds source size of 0 [-Wstringop-overread]". Obviously
the above example is heavily simplified from actual uses in the Xen hypervisor
sources, but clearly in (at least) OS and alike low-level development it is not
uncommon for pointers to get derived from known integer constants.
[Bug c/100680] false positive warning for certain __builtin_memcmp() argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100680 Richard Biener changed: What|Removed |Added Keywords||diagnostic CC||msebor at gcc dot gnu.org --- Comment #1 from Richard Biener --- I believe this is wrong "fallback" for failing to extract a size from the pointer constant argument. It should be unknown, not zero. Martin?
[Bug middle-end/100672] wrong code with vector shift and unary minus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100672 --- Comment #11 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:8d51039cb7c807ed84ff7df5416a1e3ba07a5e63 commit r12-913-g8d51039cb7c807ed84ff7df5416a1e3ba07a5e63 Author: Richard Biener Date: Wed May 19 13:35:07 2021 +0200 middle-end/100672 - fix bogus right shift folding This fixes the bogus use of TYPE_PRECISION on vector types from optimizing -((int)x >> 31) into (unsigned)x >> 31. 2021-05-19 Richard Biener PR middle-end/100672 * fold-const.c (fold_negate_expr_1): Use element_precision. (negate_expr_p): Likewise. * gcc.dg/torture/pr100672.c: New testcase.
[Bug middle-end/100672] wrong code with vector shift and unary minus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100672 Richard Biener changed: What|Removed |Added Known to fail|12.0| Known to work||12.0 --- Comment #12 from Richard Biener --- Fixed on trunk sofar.
[Bug target/100678] [OpenACC/nvptx] 'libgomp.oacc-c-c++-common/private-atomic-1.c' FAILs (differently) in certain configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100678
--- Comment #2 from Thomas Schwinge ---
I ran into this in a different OpenACC context (OpenACC privatization levels),
where in testcases we're trying to use 'atomic' on 'private' variables. ...
which for nvptx offloading only works for gang-private (PTX '.shared'), but
fails for everything else, per PR83812 ("old" failure mode).
(In reply to Tom de Vries from comment #1)
> I'm not sure what you aim to achieve with the test-case.
To document the current failure mode -- a deficiency in the OpenACC/nvptx
implementation. So that there is precedence for this, and it doesn't appear
just in the upcoming OpenACC privatization levels testcases.
And then, as reported in this issue here, I found the "wrong reduction result"
problem ("new" failure mode), which seems to be another deficiency in the
OpenACC/nvptx implementation.
> My inclination would be to skip it for nvptx, which AFAIU is opposite to
> your intent when adding it. So, perhaps just remove it?
I'd rather conditionalize the nvptx offloading XFAIL appropriately for both the
"old" and "new" failure modes, and then eventually un-XFAIL, once these issues
have been addressed.
[Bug libstdc++/100630] Unexpected implicit conversion from volatile bool& to std::filesystem::path in gcc <= 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100630 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |9.5 --- Comment #6 from Jonathan Wakely --- It's too late for 9.4 but I plan to backport it for 9.5
[Bug testsuite/100655] 'g++.dg/tsan/pthread_cond_clockwait.C' FAILs due to 'pthread_cond_clockwait' missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100655
--- Comment #5 from Jonathan Wakely ---
--- a/gcc/testsuite/g++.dg/tsan/pthread_cond_clockwait.C
+++ b/gcc/testsuite/g++.dg/tsan/pthread_cond_clockwait.C
@@ -4,6 +4,10 @@
#include
+// Include this to get the libstdc++ _GLIBCXX_USE_PTHREAD_COND_CLOCKWAIT
+// macro that indicates pthread_cond_clockwait is available.
+#include
+
pthread_cond_t cv;
pthread_mutex_t mtx;
@@ -23,7 +27,9 @@ int main() {
struct timespec ts;
clock_gettime(CLOCK_MONOTONIC, &ts);
ts.tv_sec += 10;
+#ifdef _GLIBCXX_USE_PTHREAD_COND_CLOCKWAIT
pthread_cond_clockwait(&cv, &mtx, CLOCK_MONOTONIC, &ts);
+#endif
pthread_mutex_unlock(&mtx);
pthread_join(tid, NULL);
[Bug c++/100681] New: [[noreturn]] attribute can be applied to parameters of function type with strange results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100681 Bug ID: 100681 Summary: [[noreturn]] attribute can be applied to parameters of function type with strange results Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: felix.von.s at posteo dot de Target Milestone: --- Created attachment 50845 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50845&action=edit Sample program Attached is a code sample which G++ accepts and all other compilers I tested reject. When the `never::invoke` line is uncommented, compilation fails with a message naming the type of func as `R(Args ...) volatile`, which is an abominable function type. There doesn’t seem to be a real way to use the method. Expected behaviour: the code is rejected in both versions, just like in other compilers. Desired behaviour: the code is accepted in both versions, with the [[noreturn]] attribute applied to func as if it were a function invoked directly.
[Bug target/99977] arm: ICE with __sync_bool_compare_and_swap and -mcpu=cortex-m23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99977 --- Comment #7 from CVS Commits --- The master branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:beeb01541ae845b445837b873126a7f968b8f654 commit r12-922-gbeeb01541ae845b445837b873126a7f968b8f654 Author: Christophe Lyon Date: Wed May 19 14:45:54 2021 + arm/testsuite: Fix testcase for PR99977 Some targets (eg arm-none-uclinuxfdpiceabi) do not support Thumb-1, and since the testcase forces -march=armv8-m.base, we need to check whether this option is actually supported. Using dg-add-options arm_arch_v8m_base ensure that we pass -mthumb as needed too. 2021-05-19 Christophe Lyon PR target/99977 gcc/testsuite/ * gcc.target/arm/pr99977.c: Require arm_arch_v8m_base.
[Bug target/99977] arm: ICE with __sync_bool_compare_and_swap and -mcpu=cortex-m23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99977 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:c412100235ba34ae9c133fb7a77cc52c2e93fc87 commit r11-8435-gc412100235ba34ae9c133fb7a77cc52c2e93fc87 Author: Christophe Lyon Date: Wed May 19 14:45:54 2021 + arm/testsuite: Fix testcase for PR99977 Some targets (eg arm-none-uclinuxfdpiceabi) do not support Thumb-1, and since the testcase forces -march=armv8-m.base, we need to check whether this option is actually supported. Using dg-add-options arm_arch_v8m_base ensure that we pass -mthumb as needed too. 2021-05-19 Christophe Lyon PR target/99977 gcc/testsuite/ * gcc.target/arm/pr99977.c: Require arm_arch_v8m_base.
[Bug target/100333] arm: ICE (unrecognizable insn) with CMSE nonsecure call and -march=armv8.1-m.main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100333 --- Comment #2 from CVS Commits --- The master branch has been updated by Alex Coplan : https://gcc.gnu.org/g:5b953740da1976d90d974055c6d825c509c6e654 commit r12-923-g5b953740da1976d90d974055c6d825c509c6e654 Author: Alex Coplan Date: Wed May 19 15:52:45 2021 +0100 arm: Fix ICE with CMSE nonsecure calls on Armv8.1-M [PR100333] As the PR shows, we ICE shortly after expanding nonsecure calls for Armv8.1-M. For Armv8.1-M, we have TARGET_HAVE_FPCXT_CMSE. As it stands, the expander (arm.md:nonsecure_call_internal) moves the callee's address to a register (with copy_to_suggested_reg) only if !TARGET_HAVE_FPCXT_CMSE. However, looking at the pattern which the insn appears to be intended to match (thumb2.md:*nonsecure_call_reg_thumb2_fpcxt), it requires the callee's address to be in a register. This patch therefore just forces the callee's address into a register in the expander. gcc/ChangeLog: PR target/100333 * config/arm/arm.md (nonsecure_call_internal): Always ensure callee's address is in a register. gcc/testsuite/ChangeLog: PR target/100333 * gcc.target/arm/cmse/pr100333.c: New test.
[Bug target/100333] arm: ICE (unrecognizable insn) with CMSE nonsecure call and -march=armv8.1-m.main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100333 --- Comment #3 from Alex Coplan --- Fixed on trunk for now.
[Bug target/97205] arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205
--- Comment #20 from SRINATH PARVATHANENI ---
(In reply to rguent...@suse.de from comment #17)
> On Mon, 23 Nov 2020, bernd.edlinger at hotmail dot de wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205
> >
> > --- Comment #16 from Bernd Edlinger ---
> > (In reply to SRINATH PARVATHANENI from comment #15)
> > > (In reply to Bernd Edlinger from comment #14)
> > > > fixed on trunk.
> > >
> > > Thanks Bernd for fixing this on trunk, would you mind backporting this to
> > > GCC-10 as well?
> > >
> > > Thanks you.
> > >
> > > Regards,
> > > Srinath.
> >
> > Since it is a gcc_checking_assert that triggers the ICE,
> > I assumed that does not affect a release build,
> > is that correct?
>
> That is correct.
I did not understand what you meant above, please correct me if I'm wrong.
My observation:
$ arm-none-eabi-gcc bugx.c -O0 -c
during RTL pass: expand
bugx.c: In function 'fn1':
bugx.c:4:5: internal compiler error: in gen_movsi, at config/arm/arm.md:6364
4 | x b = ({
| ^
0x14ede14 gen_movsi(rtx_def*, rtx_def*)
/data/dgboter/bbs/build22--cen7x86_64/buildbot/cen7x86_64--arm-none-eabi--all-profiles/build/src/gcc/gcc/config/arm/arm.md:6364
0x92153f insn_gen_fn::operator()(rtx_def*, rtx_def*) const
/data/dgboter/bbs/build22--cen7x86_64/buildbot/cen7x86_64--arm-none-eabi--all-profiles/build/src/gcc/gcc/recog.h:317
0x92153f emit_move_insn_1(rtx_def*, rtx_def*)
/data/dgboter/bbs/build22--cen7x86_64/buildbot/cen7x86_64--arm-none-eabi--all-profiles/build/src/gcc/gcc/expr.c:3759
0x921cf4 emit_move_insn(rtx_def*, rtx_def*)
/data/dgboter/bbs/build22--cen7x86_64/buildbot/cen7x86_64--arm-none-eabi--all-profiles/build/src/gcc/gcc/expr.c:3855
0x92a6f0 store_expr(tree_node*, rtx_def*, int, bool, bool)
/data/dgboter/bbs/build22--cen7x86_64/buildbot/cen7x86_64--arm-none-eabi--all-profiles/build/src/gcc/gcc/expr.c:5931
0x92c973 expand_assignment(tree_node*, tree_node*, bool)
/data/dgboter/bbs/build22--cen7x86_64/buildbot/cen7x86_64--arm-none-eabi--all-profiles/build/src/gcc/gcc/expr.c:5516
0x7d965c expand_gimple_stmt_1
/data/dgboter/bbs/build22--cen7x86_64/buildbot/cen7x86_64--arm-none-eabi--all-profiles/build/src/gcc/gcc/cfgexpand.c:3755
0x7d965c expand_gimple_stmt
/data/dgboter/bbs/build22--cen7x86_64/buildbot/cen7x86_64--arm-none-eabi--all-profiles/build/src/gcc/gcc/cfgexpand.c:3851
0x7dbf65 expand_gimple_basic_block
/data/dgboter/bbs/build22--cen7x86_64/buildbot/cen7x86_64--arm-none-eabi--all-profiles/build/src/gcc/gcc/cfgexpand.c:5895
0x7dce7b execute
/data/dgboter/bbs/build22--cen7x86_64/buildbot/cen7x86_64--arm-none-eabi--all-profiles/build/src/gcc/gcc/cfgexpand.c:6550
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug middle-end/99578] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 Martin Sebor changed: What|Removed |Added CC||jbeulich at suse dot com --- Comment #13 from Martin Sebor --- *** Bug 100680 has been marked as a duplicate of this bug. ***
[Bug middle-end/100680] false positive warning for certain __builtin_memcmp() argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100680 Martin Sebor changed: What|Removed |Added Component|c |middle-end Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Martin Sebor --- The warning is by design: it considers a constant non-null pointer value a likely result of (invalid) arithmetic on a null pointer, as in the example in pr99578 comment #1. *** This bug has been marked as a duplicate of bug 99578 ***
[Bug libstdc++/100361] gcc-11 for msp430-elf fails to build: src/c++17/floating_to_chars.cc:107: d2fixed_full_table.h:1283:23: error: size of array ‘POW10_SPLIT_2’ exceeds maximum object size ‘32767’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100361 --- Comment #8 from Jorn Wolfgang Rennecke --- Bootstrapped and regression tested on x86_64-pc-linux-gnu.
[Bug libstdc++/100682] New: Outdated manual about the debug mode using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100682 Bug ID: 100682 Summary: Outdated manual about the debug mode using Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: frankhb1989 at gmail dot com Target Milestone: --- As I see has been removed in GCC 11, but the doc disagree: https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode_using.html https://gcc.gnu.org/onlinedocs/gcc-11.1.0/libstdc++/manual/manual/debug_mode_using.html In table 17.2, is still at the first row. BTW, what is the compatibility policy here? Is it true that any headers could be removed in a future release of GCC without deprecation?
[Bug fortran/100662] intrinsic::ieee_arithmetic fails on aarch, powerpc architectures on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662
--- Comment #10 from Steve Kargl ---
On Wed, May 19, 2021 at 09:45:12AM +, ripero84 at gmail dot com wrote:
> --- Comment #9 from ripero84 at gmail dot com ---
> Steve, is this a GCC bug or a FreeBSD bug (or if it is something else, what
> side does this belong to)?
I suppose it is both. AFAIK, there is no longer an active FreeBSD
maintainer for GCC (if there were, the few non-gfortran PR/patches
I submitted would have been committed). I no longer send patches
to GCC for gfortran as I know virtually nothing about git.
> Other OSs seem to be able to compile gfortran with these modules for these
> architectures, see, e.g.,
> https://packages.ubuntu.com/focal/arm64/gfortran-10/filelist and
> https://packages.ubuntu.com/focal/ppc64el/gfortran-10/filelist). And they
> seem
> to have been able to do so since the introduction of the three Fortran IEEE
> intrinsic modules in GCC 5
> (https://packages.ubuntu.com/bionic/amd64/gfortran-5/filelist and
> https://packages.ubuntu.com/bionic/ppc64el/gfortran-5/filelist). Therefore,
> some kind of solution must exist for this - and probably has been there for
> over half a decade. (Apologies for not being able to provide a better insight
> from the Ubuntu sources.)
ubuntu is glibc. You (or something) needs to read libgfortran/configure.host,
and add the needed logic for FreeBSD to pick up an appropriate fpu-*.h
file on aarch64. The first 3 non-comment lines of that file are
# DEFAULTS
fpu_host='fpu-generic'
ieee_support='no'
which is what non-i386/amd64 FreeBSD systems likely use. It seems
fpu-generic.h provides stubs for a few functions required to build
gfortran. After gfortran is built, installation does not install
useless ieee*.mod files. Note, a standard conforming Fortran
compiler is not required to support the ieee modules.
Furhter down in the file, there is a check for fenv compatibilities,
if test "x${have_feenableexcept}" = "xyes"; then
fpu_host='fpu-glibc'
ieee_support='yes'
fi
but the name of the file seems too specific to glibc. If fenv
facilities are available, I would have thought the file would
be named fpu-fenv.h. My guess is that configure does not find
fenv on aarch64 FreeBSD and/or aarch64 FreeBSD does not support
fenv.
[Bug fortran/100683] New: Array initialization refuses valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100683 Bug ID: 100683 Summary: Array initialization refuses valid Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gcc dot gnu.org Target Milestone: --- Created attachment 50846 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50846&action=edit Fortran code showing problem Hi All! Refuses valid array initialization with bogus error. Seen on: GNU Fortran (GCC) 9.3.1 20210514 GNU Fortran (GCC) 10.3.1 20210514 GNU Fortran (GCC) 11.1.1 20210514 GNU Fortran (GCC) 12.0.0 20210514 (experimental) Thank you very much. Best regards, José Rui
[Bug target/97205] arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205 --- Comment #21 from Bernd Edlinger --- Hi Srinath, when we add new assertions to gcc we use always a gcc_checking_assert nowadays, that is also the case here. The assertion is only firing in your compiler because it is a development snapshot 10.3.1. So that is an experimemtal version. That means the release version 10.3.0 will not have an ICE with this test case, except the long-standing potential wrong code due to unaligned memory access, however most contemporary ARM chips do no longer trap on an unaligned load/store. But on the other hand, this change might affects all targets whether or not they have any issue at all. So it might trigger a completely unrelated bug in a completely different area of the compiler. That said I do not object this back-port, I just wanted to say that it fixes a non-issue in a released compiler version. And even a small risk of a regression seems to be not worth it. Regards Bernd.
[Bug libstdc++/100361] gcc-11 for msp430-elf fails to build: src/c++17/floating_to_chars.cc:107: d2fixed_full_table.h:1283:23: error: size of array ‘POW10_SPLIT_2’ exceeds maximum object size ‘32767’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100361 --- Comment #9 from Jonathan Wakely --- Nice, thanks, Joern. That patch is OK for trunk and gcc-11 (please remember to CC the libstdc++ list when you post it to gcc-patches).
[Bug middle-end/100684] New: spurious -Wnonnull with -O1 on a C++ lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100684
Bug ID: 100684
Summary: spurious -Wnonnull with -O1 on a C++ lambda
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: ---
>From James Legg in comment pr98109 comment 2:
> The false positives can often be seen when converting a lambda to a function
> pointer at lower optimisation levels too. For example, in g++ 11.1.1,
> compiling:
> int main()
> {
> return static_cast([](int x){ return x; })(0);
> }
>
> with -Og -Wall -fsanitize=undefined results in:
> /tmp/a.cc: In static member function ‘static constexpr int
> main()_FUN(int)’:
> /tmp/a.cc:3:63: warning: ‘this’ pointer is null [-Wnonnull]
> 3 | return static_cast([](int x){ return x; })(0);
> | ^
> /tmp/a.cc:3:42: note: in a call to non-static member function
> ‘main()::’
> 3 | return static_cast([](int x){ return x; })(0);
> | ^
[Bug libstdc++/100682] Outdated manual about the debug mode using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100682
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2021-05-19
Status|UNCONFIRMED |NEW
--- Comment #1 from Jonathan Wakely ---
(In reply to frankhb1989 from comment #0)
> BTW, what is the compatibility policy here? Is it true that any
> headers could be removed in a future release of GCC without deprecation?
We probably shouldn't do that.
I suppose we could restore but with this content:
#include
namespace __gnu_debug { using std::array; using std::get; using std::swap; }
And then deprecate it.
[Bug middle-end/100684] spurious -Wnonnull with -O1 on a C++ lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100684 Martin Sebor changed: What|Removed |Added Known to fail||11.1.0, 12.0 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Blocks||95507 Keywords||diagnostic Last reconfirmed||2021-05-19 --- Comment #1 from Martin Sebor --- Confirmed. The front end -Wnonull has suppression logic dealing with lambdas but the middle-end -Wnonnull in tree-ssa-ccp.c doesn't have anything like that. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95507 [Bug 95507] [meta-bug] bogus/missing -Wnonnull
[Bug middle-end/98109] Seemingly wrong warnings from -Wnonnull when combined with -O2 -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98109 --- Comment #3 from Martin Sebor --- (In reply to James Legg from comment #2) This is a different problem from the one reported in comment 0 so I opened a new bug for it: pr100684.
[Bug middle-end/100680] false positive warning for certain __builtin_memcmp() argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100680 --- Comment #3 from jbeulich at suse dot com --- (In reply to Martin Sebor from comment #2) > The warning is by design: it considers a constant non-null pointer value a > likely result of (invalid) arithmetic on a null pointer, as in the example > in pr99578 comment #1. If the warning is by design, there ought to be a way to avoid these specific instances without disabling the warning altogether. I'm also observing such bogus warnings in cases other than pointer derivation from literal numbers, possibly along the lines of what Andi has said in that other bug in comment 12. For Xen I've submitted a patch to work around the issue without disabling the warning, but it's not really pretty: https://lists.xen.org/archives/html/xen-devel/2021-05/msg01058.html I also consider Richard's comment 7 in that other bug as quite relevant. The compiler _guessing_ that offsetting from a NULL pointer is an actual issue conflicts with people intentionally doing so. Warnings based on heuristics should imo always be separately controllable, such that they can - if the heuristics prove to be wrong - be turned off, without affecting other, non-heuristic warnings. This is even more relevant for all those projects (like the Xen hypervisor) building with -Werror, resulting in false positive warnings breaking the build.
[Bug c++/89700] Warn if move constructor is not generated and not deleted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89700 Jonathan Wakely changed: What|Removed |Added CC||nunoplopes at sapo dot pt --- Comment #8 from Jonathan Wakely --- *** Bug 96501 has been marked as a duplicate of this bug. ***
[Bug c++/87403] [Meta-bug] Issues that suggest a new warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 Bug 87403 depends on bug 96501, which changed state. Bug 96501 Summary: [C++11] Should warn when classes only have copy constructor defined https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96501 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/96501] [C++11] Should warn when classes only have copy constructor defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96501 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jonathan Wakely --- This is a dup, and there's additional discussion in the dup. *** This bug has been marked as a duplicate of bug 89700 ***
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #216 from dave.anglin at bell dot net --- On 2021-05-17 5:56 a.m., jvb at cyberscience dot com wrote: > With the working as, I changed gcc to use brl instructions for calls, > including > tail calls: > > --- gcc-11.1.0/gcc/config/ia64/ia64.md 2021-04-27 11:00:13.0 +0100 > +++ gcc-11.1.0-snake/gcc/config/ia64/ia64.md2021-05-13 14:49:21.0 > +0100 > @@ -4410,7 +4410,9 @@ > (const_int 0)) > (clobber (match_operand:DI 1 "register_operand" "=b,b"))] >"" > - "br.call%+.many %1 = %0" > + "@ > + br.call%+.many %1 = %0 > + brl.call%+.many %1 = %0" >[(set_attr "itanium_class" "br,scall")]) > > (define_insn "call_value_nogp" > @@ -4419,14 +4421,18 @@ > (const_int 0))) > (clobber (match_operand:DI 2 "register_operand" "=b,b"))] >"" > - "br.call%+.many %2 = %1" > + "@ > + br.call%+.many %2 = %1 > + brl.call%+.many %2 = %1" >[(set_attr "itanium_class" "br,scall")]) > > (define_insn "sibcall_nogp" >[(call (mem:DI (match_operand:DI 0 "call_operand" "?b,s")) > (const_int 0))] >"" > - "br%+.many %0" > + "@ > + br%+.many %0 > + brl%+.many %0" >[(set_attr "itanium_class" "br,scall")]) > > (define_insn "call_gp" We only should use brl when TARGET_HPUX and ia64_tune == PROCESSOR_ITANIUM2. I wouldn't worry too much about it being slightly less efficient. You can use the pattern constraint to implement this.
[Bug fortran/96983] [11/12 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #35 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #34 from Tobias Burnus --- > What's actually the status of the PR – I mean on both powerpc64*-linux-gnu, > sparc*-*-*. > > The summary states that there is an ICE – is this still the case? > I am especially interested in the sparc*-*-* status. Checking my test result logs, I find that the sparc failures are gone after 20210309. > If not, what remains to be done? > I assume that also some GCC 11 backporting is needed. AFAICS, this failure never existed on the gcc-11 branch on sparc.
[Bug middle-end/100685] New: #pragma GCC push_options ineffective for optimize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100685
Bug ID: 100685
Summary: #pragma GCC push_options ineffective for optimize
options
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: ---
The #pragma GCC push_options in the program below should prevent the folding of
the strlen() call in g() but doesn't. This has changed in GCC 11 (GCC 10
behaves as expected). The dump shows that the optimize attribute has both
optimization options, -O1 as well as -O2. That also seems unexpected but it
has not changed between 10 and 11.
$ cat a.c && gcc -O0 -S -Wall -fdump-tree-optimized=/dev/stdout a.c
#pragma GCC optimize ("2")
int f (void)
{
const char s[] = "12";
return __builtin_strlen (s); // folded to 1 (good)
}
#pragma GCC push_options
#pragma GCC optimize ("1")
int g (void)
{
const char s[] = "1";
return __builtin_strlen (s); // also folded but shouldn't be
}
;; Function f (f, funcdef_no=0, decl_uid=1943, cgraph_uid=1, symbol_order=0)
__attribute__((optimize ("2")))
int f ()
{
[local count: 1073741824]:
return 2;
}
;; Function g (g, funcdef_no=1, decl_uid=1947, cgraph_uid=2, symbol_order=1)
__attribute__((optimize ("2", "1")))
int g ()
{
[local count: 1073741824]:
return 1;
}
[Bug c++/100596] [12 Regression] error: attribute appertains to a friend declaration that is not a definition since r12-786-g149061188c7c6ddf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100596 --- Comment #5 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:adcb497bdba499d161d2e5e8de782bdd6f75d62c commit r12-925-gadcb497bdba499d161d2e5e8de782bdd6f75d62c Author: Marek Polacek Date: Tue May 18 16:11:16 2021 -0400 c++: Relax attribute on friend declaration checking [PR100596] It turned out that there are codebases that profusely use GNU attributes on friend declarations, so we have to dial back our checking and allow them. And for C++11 attributes let's just warn instead of giving errors. PR c++/100596 gcc/cp/ChangeLog: * cp-tree.h (any_non_type_attribute_p): Remove. * decl.c (grokdeclarator): Turn an error into a warning and only warn for standard attributes. * decl2.c (any_non_type_attribute_p): Remove. * parser.c (cp_parser_elaborated_type_specifier): Turn an error into a warning and only warn for standard attributes. (cp_parser_member_declaration): Likewise. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/friend7.C: Turn a few dg-warnings into dg-errors. Remove dg-errors for GNU attributes. * g++.dg/ext/attrib63.C: Remove dg-error. * g++.dg/cpp0x/friend8.C: New test.
[Bug c++/100596] [12 Regression] error: attribute appertains to a friend declaration that is not a definition since r12-786-g149061188c7c6ddf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100596 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Marek Polacek --- Should be fixed, sorry.
[Bug fortran/100683] Array initialization refuses valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100683 --- Comment #1 from José Rui Faustino de Sousa --- Patch posted: https://gcc.gnu.org/pipermail/fortran/2021-May/056053.html
