[Bug analyzer/101570] [12 Regression] ICE in maybe_reconstruct_from_def_stmt, at analyzer/analyzer.cc:133
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101570 Richard Biener changed: What|Removed |Added Version|unknown |12.0 Target Milestone|--- |12.0
[Bug rtl-optimization/101562] [9/10/11/12 Regression] ICE in insert, at wide-int.cc:682
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101562 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug libstdc++/101571] New: DestroyGuard used by the ranges::uninitialized family should use addressof()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101571
Bug ID: 101571
Summary: DestroyGuard used by the ranges::uninitialized family
should use addressof()
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
The Standard Library should consistently use addressof() to defend itself
against overloaded operator&().
#include
struct I {
using value_type = std::string;
using difference_type = std::ptrdiff_t;
I& operator++();
I operator++(int);
value_type& operator*() const;
void operator&() = delete;
bool operator==(const I&) const;
};
int main() {
std::ranges::uninitialized_default_construct(I{}, I{});
}
https://godbolt.org/z/5Pb67b9jx
[Bug analyzer/101550] -Wanalyzer-file-leak false positive with an array of pointers, open and fdopen.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101550 --- Comment #2 from amatej at redhat dot com --- I have: glibc-2.33.9000-43.fc35.x86_64. Yes that is possible, I have just tried it in a container with: glibc-2.33-20.fc34.x86_64 and gcc-11.1.1-3.fc34.x86_64 and it doesn't reproduce there.
[Bug target/101504] [12 Regression] ICE: in lra_assign, at lra-assigns.c:1649 with -O2 -march=broadwell
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101504 H.J. Lu changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot com Ever confirmed|0 |1 Last reconfirmed||2021-07-22 Status|UNCONFIRMED |NEW
[Bug target/101393] PowerPC32 inline assembly broken by commit 2d94f7dea9c73ef3c116a0ddc722724578a860fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393 --- Comment #11 from Alan Modra --- Preserving certain -m gas options goes back to this patch: https://sourceware.org/pipermail/binutils/2008-January/054935.html Given the number of ppc micros around with differing functional units, it is quite reasonable that we have assembly options to say "this base cpu" plus "this extra functionality". Whether you think it was wise to allow those "extra functionality" options to be specified before the "base cpu" option is another matter, but it has been that way for a long time. I'm not inclined to change that since it would very likely break some projects, and I happen to think that it is entirely reasonable to expect that "-maltivec -mppc64" for example is the same as "-mppc64 -maltivec". In any case sticky options are a side issue here. The real issue is that emitted .machine is wrong. Note that I'm not vetoing assembler changes. It might be a good idea to reset all sticky options on processing any .machine directive for example, and I'm happy with the idea of -mno-vsx etc. options for the assembler.
[Bug analyzer/101570] New: [12 Regression] ICE in maybe_reconstruct_from_def_stmt, at analyzer/analyzer.cc:133
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101570
Bug ID: 101570
Summary: [12 Regression] ICE in
maybe_reconstruct_from_def_stmt, at
analyzer/analyzer.cc:133
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-12.0.0-alpha20210718 snapshot (g:6ae8aac19cdbdbd96d90f86e4d8505fe121bdf06)
ICEs when compiling the following testcase, reduced from
gcc/testsuite/gcc.dg/torture/pr70370.c, w/ -fanalyzer:
void
test2 (_Complex double f)
{
__asm__ ("" : "=r" (__real f));
}
% gcc-12.0.0 -fanalyzer -c erc6pp1g.c
during IPA pass: analyzer
erc6pp1g.c: In function 'test2':
erc6pp1g.c:4:3: internal compiler error: in maybe_reconstruct_from_def_stmt, at
analyzer/analyzer.cc:133
4 | __asm__ ("" : "=r" (__real f));
| ^~~
0x7ff6f0 maybe_reconstruct_from_def_stmt
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/analyzer.cc:133
0x7ff6f0 fixup_tree_for_diagnostic_1
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/analyzer.cc:180
0x1a32b3a fixup_tree_for_diagnostic_1
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/hash-table.h:687
0x1a32b3a ana::fixup_tree_for_diagnostic(tree_node*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/analyzer.cc:201
0x120761f ana::region_model::check_for_poison(ana::svalue const*, tree_node*,
ana::region_model_context*) const
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/region-model.cc:839
0x120ba80 ana::region_model::get_rvalue(tree_node*, ana::region_model_context*)
const
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/region-model.cc:1842
0x120ba80 ana::region_model::get_gassign_result(gassign const*,
ana::region_model_context*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/region-model.cc:765
0x120c62c ana::region_model::on_assignment(gassign const*,
ana::region_model_context*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/region-model.cc:869
0x11e998d ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*, ana::uncertainty_t*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/engine.cc:1223
0x11ebf22 ana::exploded_graph::process_node(ana::exploded_node*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/engine.cc:3098
0x11eca8a ana::exploded_graph::process_worklist()
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/engine.cc:2684
0x115 ana::impl_run_checkers(ana::logger*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/engine.cc:4972
0x11efd80 ana::run_checkers()
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/engine.cc:5043
0x11e0e48 execute
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210718/work/gcc-12-20210718/gcc/analyzer/analyzer-pass.cc:87
[Bug gcov-profile/101569] New: [GCOV] Wrong coverage caused by callee format.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101569
Bug ID: 101569
Summary: [GCOV] Wrong coverage caused by callee format.
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: njuwy at smail dot nju.edu.cn
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure -enable-checking=release -enable-languages=c,c++
-disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC)
$ cat test.c
#include
#include
typedef unsigned char u8;
typedef unsigned long long u64;
static inline __attribute__((always_inline)) u64 __swab64p(const u64 *p) {
return (__builtin_constant_p((u64)(*p))?
(u64)(((u64)(*p) & (u64)0x00ffULL) << 56)
:__builtin_bswap64(*p));
}
static inline u64 wwn_to_u64(void *wwn) { return __swab64p(wwn); }
static inline u64 wwn_to_u64_copy(void *wwn) {
return __swab64p(wwn);
}
void __attribute__((noinline, noclone)) broken(u64 *shost) {
u8 node_name[8] = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF};
*shost = wwn_to_u64(node_name);
*shost = wwn_to_u64_copy(node_name);
}
int main(int argc, char *argv[]) {
u64 v;
broken(&v);
if (v != (u64)-1)
__builtin_abort();
return 0;
}
$ gcc -O0 --coverage test.c;./a.out;gcov test;cat test.c.gcov
File 'test.c'
Lines executed:92.86% of 14
Creating 'test.c.gcov'
-:0:Source:test.c
-:0:Graph:test.gcno
-:0:Data:test.gcda
-:0:Runs:1
-:1:#include
-:2:#include
-:3:typedef unsigned char u8;
-:4:typedef unsigned long long u64;
-:5:
-:6:static inline __attribute__((always_inline)) u64
__swab64p(const u64 *p) {
-:7: return (__builtin_constant_p((u64)(*p))?
-:8: (u64)(((u64)(*p) &
(u64)0x00ffULL) << 56)
2:9: :__builtin_bswap64(*p));
-: 10:}
-: 11:
2: 12:static inline u64 wwn_to_u64(void *wwn) { return
__swab64p(wwn); }
-: 13:
1: 14:static inline u64 wwn_to_u64_copy(void *wwn) {
1: 15:return __swab64p(wwn);
-: 16:}
-: 17:
1: 18:void __attribute__((noinline, noclone)) broken(u64 *shost) {
1: 19: u8 node_name[8] = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
0xFF};
1: 20: *shost = wwn_to_u64(node_name);
1: 21: *shost = wwn_to_u64_copy(node_name);
1: 22:}
-: 23:
1: 24:int main(int argc, char *argv[]) {
-: 25: u64 v;
-: 26:
1: 27: broken(&v);
-: 28:
1: 29: if (v != (u64)-1)
#: 30:__builtin_abort();
-: 31:
1: 32: return 0;
-: 33:}
Line 14 and 15 were executed once. However, when they are in one line, the
coverage becomes 2.
[Bug analyzer/101547] [12 Regression] ICE: Segmentation fault (in c_tree_printer)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101547 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from David Malcolm --- Thanks for filing this; confirmed. Should be fixed by the above patch.
[Bug analyzer/101522] ICE: Segmentation fault (in ana::binding_cluster::purge_state_involving)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101522 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by the above patch.
[Bug analyzer/101547] [12 Regression] ICE: Segmentation fault (in c_tree_printer)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101547 --- Comment #1 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:893b12cc12877aca1c9df6272123b26eddf12722 commit r12-2460-g893b12cc12877aca1c9df6272123b26eddf12722 Author: David Malcolm Date: Wed Jul 21 19:19:31 2021 -0400 analyzer: bulletproof -Wanalyzer-file-leak [PR101547] gcc/analyzer/ChangeLog: PR analyzer/101547 * sm-file.cc (file_leak::emit): Handle m_arg being NULL. (file_leak::describe_final_event): Handle ev.m_expr being NULL. gcc/testsuite/ChangeLog: PR analyzer/101547 * gcc.dg/analyzer/pr101547.c: New test. Signed-off-by: David Malcolm
[Bug analyzer/101522] ICE: Segmentation fault (in ana::binding_cluster::purge_state_involving)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101522 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:87bd75cd49aac68e90bd9b6b5e14582d6e0ccafa commit r12-2459-g87bd75cd49aac68e90bd9b6b5e14582d6e0ccafa Author: David Malcolm Date: Wed Jul 21 19:16:08 2021 -0400 analyzer: fix ICE in binding_cluster::purge_state_involving [PR101522] gcc/analyzer/ChangeLog: PR analyzer/101522 * store.cc (binding_cluster::purge_state_involving): Don't change m_map whilst iterating through it. gcc/testsuite/ChangeLog: PR analyzer/101522 * g++.dg/analyzer/pr101522.C: New test. Signed-off-by: David Malcolm
[Bug fortran/78219] [F08] specifying the kind of a FORALL index in the header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78219
--- Comment #8 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #7)
> diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
> index d148de3e3b5..d7668f6a928 100644
> --- a/gcc/fortran/match.c
> +++ b/gcc/fortran/match.c
> @@ -2350,6 +2350,34 @@ match_forall_iterator (gfc_forall_iterator **result)
>gfc_forall_iterator *iter;
>locus where;
>match m;
> + gfc_typespec ts;
> + bool seen_ts;
> +
> + /* In Fortran 2018, one can do "forall (integer :: i = 1:20)".
s/2018/2008
> + Try to match an optional "type-spec ::" */
> + seen_ts = false;
> + gfc_clear_ts (&ts);
> + m = gfc_match_type_spec (&ts);
> + if (m == MATCH_YES)
> +{
> + seen_ts = (gfc_match (" ::") == MATCH_YES);
> +
> + if (seen_ts)
> + {
> + if (!gfc_notify_std (GFC_STD_F2018, "FORALL includes a "
s/2018/2008
> +"type specification at %C"))
> + return MATCH_ERROR;
> +
> + if (ts.type != BT_INTEGER)
> + {
> + gfc_error ("Type-spec at %L shall be INTEGER",
> + &gfc_current_locus);
> + return MATCH_ERROR;
> + }
> + }
> +}
> + else if (m == MATCH_ERROR)
> +return m;
>
>where = gfc_current_locus;
>iter = XCNEW (gfc_forall_iterator);
> @@ -2358,6 +2386,9 @@ match_forall_iterator (gfc_forall_iterator **result)
>if (m != MATCH_YES)
> goto cleanup;
>
> + if (seen_ts)
> +iter->var->ts = ts;
> +
>if (gfc_match_char ('=') != MATCH_YES
>|| iter->var->expr_type != EXPR_VARIABLE)
> {
[Bug fortran/83953] Internal compiler error with -fcheck=bounds option on derived type components and forall construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83953 --- Comment #4 from kargl at gcc dot gnu.org --- The original test case also appears to now work.
[Bug fortran/83953] Internal compiler error with -fcheck=bounds option on derived type components and forall construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83953 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to G. Steinmetz from comment #2) > Simplification : > > > $ cat z1.f90 > program p >type t > integer :: n = 1 > integer, allocatable :: u(:) > real :: v(3, 3) >end type >type(t) :: z >real :: x(3) = [1.0, 2.0, 3.0] >allocate (z%u(3)) >z%u = [3, 1, 2] >forall (j = 1:3) > z%v(j, z%n) = x(z%u(j)) >end forall > end > > This seems to work now.
[Bug other/101568] [12 regression] g++.dg/ipa/pr82352.C fails after r12-2338
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101568 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug other/101568] New: [12 regression] g++.dg/ipa/pr82352.C fails after r12-2338
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101568 Bug ID: 101568 Summary: [12 regression] g++.dg/ipa/pr82352.C fails after r12-2338 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:f0500db3692276f60e0562c17c87a0cb03e34398, r12-2338 make -k check-gcc RUNTESTFLAGS="dg.exp=g++.dg/ipa/pr82352.C" FAIL: g++.dg/ipa/pr82352.C -std=gnu++98 (test for excess errors) FAIL: g++.dg/ipa/pr82352.C -std=gnu++14 (test for excess errors) FAIL: g++.dg/ipa/pr82352.C -std=gnu++17 (test for excess errors) FAIL: g++.dg/ipa/pr82352.C -std=gnu++2a (test for excess errors) # of unexpected failures4 Same failure for all 4: FAIL: g++.dg/ipa/pr82352.C -std=gnu++17 (test for excess errors) Excess errors: cc1plus: warning: writing 16 bytes into a region of size 0 [-Wstringop-overflow=] Note: This still occurs with r12-2456.
[Bug target/101393] PowerPC32 inline assembly broken by commit 2d94f7dea9c73ef3c116a0ddc722724578a860fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393 --- Comment #10 from Segher Boessenkool --- (In reply to Franz Sirl from comment #9) > (In reply to Segher Boessenkool from comment #8) > > I don't think it is a good idea to add workaround upon workaround to avoid > > some of the not-so-useful behaviours of -many. Instead, we should just > > not use -many? > > As I understand it -many is just one variation of the general problem with > the sticky flags. If we remove -many from the assembler, there are still > other sticky flags like -mvsx. Turning of any sticky flag is currently not > supported by the assembler AFAICS. So for example it's impossible to switch > from a VSX supporting assembler mode to an assembler mode without VSX via > the .machine pseudo-op. Or did I misread the the assembler source? So "sticky" is some internal GAS concept? This isn't documented in the manuals. This means that its behaviour can likely be changed without too much trouble; that would be quite preferable, it's not such a hot idea to have to change what GCC does to something ever more complex, if we could just change GAS instead. Maybe the assembler can adopt -mno-vsx etc., with the same semantics as that has in GCC?
[Bug c++/101567] New: Gcc incorrectly allows co_await operator inside catch-block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101567 Bug ID: 101567 Summary: Gcc incorrectly allows co_await operator inside catch-block Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: fchelnokov at gmail dot com Target Milestone: --- According to the standard "An await-expression shall appear only in a potentially-evaluated expression within the compound-statement of a function-body outside of a handler." https://timsong-cpp.github.io/cppwp/n4861/expr.await#2 But GCC currently allows co_await operator inside catch-block, which lead to very weird results: https://gcc.godbolt.org/z/4deoG7Pnh
[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 Target Milestone|--- |11.3
[Bug analyzer/101550] -Wanalyzer-file-leak false positive with an array of pointers, open and fdopen.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101550 --- Comment #1 from David Malcolm --- Thanks for filing this bug. What version of glibc are you using? This looks similar to PR 101081 in that I think it's dependent on the exact uses of __attribute__((malloc)) within stdio.h.
[Bug fortran/101564] ICE in resolve_allocate_deallocate, at fortran/resolve.c:8169
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101564 --- Comment #5 from Steve Kargl --- On Wed, Jul 21, 2021 at 08:37:02PM +, anlauf at gcc dot gnu.org wrote: > > --- Comment #4 from anlauf at gcc dot gnu.org --- > Patch: https://gcc.gnu.org/pipermail/fortran/2021-July/056264.html > OK. Just a generic patch to avoid a null pointer dereference.
[Bug fortran/101564] ICE in resolve_allocate_deallocate, at fortran/resolve.c:8169
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101564 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org CC||anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-July/056264.html
[Bug fortran/101536] ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:7324
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101536 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED CC||anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-July/056263.html
[Bug analyzer/101522] ICE: Segmentation fault (in ana::binding_cluster::purge_state_involving)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101522 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-07-21 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from David Malcolm --- Thanks for filing this. Confirmed; I'm working on a fix.
[Bug target/95483] [i386] Missing SIMD functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95483 H.J. Lu changed: What|Removed |Added CC||jbeulich at suse dot com --- Comment #5 from H.J. Lu --- *** Bug 88035 has been marked as a duplicate of this bug. ***
[Bug target/88035] missing _mm512_reduce_round_pd() et al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88035 H.J. Lu changed: What|Removed |Added Resolution|--- |DUPLICATE Target Milestone|--- |11.0 Status|NEW |RESOLVED --- Comment #4 from H.J. Lu --- Dup. *** This bug has been marked as a duplicate of bug 95483 ***
[Bug c++/101566] gcc miscompiles lambda used as tuple-like object applied to function for call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101566
--- Comment #8 from Jonathan Wakely ---
(In reply to Dale Weiler from comment #5)
> This is curious, omitting `decltype(auto)` for get, as in just `auto` seems
> to work around the issue as well.
>
> template
> constexpr auto get(T tuple) { return *tuple(Get{}); }
>
> I'm a bit out of my element here, in that I don't understand the semantic
> differences between the two and if that behavior is correct.
auto makes it return by value, decltype(auto) returns exactly the type of the
return statement (so if it's a reference, so is the return type).
[Bug tree-optimization/101534] ICE in create_tailcall_accumulator, at tree-tailcall.c:1083
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101534 Andrew Pinski changed: What|Removed |Added URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma |il/gcc-patches/2021-July/57 |il/gcc-patches/2021-July/57 |5692.html |5771.html --- Comment #6 from Andrew Pinski --- Updated patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575771.html
[Bug c++/101566] gcc miscompiles lambda used as tuple-like object applied to function for call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101566 --- Comment #7 from Dale Weiler --- Yeah the code example is invalid, there is a reference to a temporary, decltype(auto) on *ptr produces reference type, somehow I thought it produced the value type, sorry for the confusion.
[Bug c++/101566] gcc miscompiles lambda used as tuple-like object applied to function for call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101566
Dale Weiler changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #6 from Dale Weiler ---
(In reply to Dale Weiler from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > (In reply to Dale Weiler from comment #2)
> > > Ah, passing `T&` here instead of T does appear to avoid the issue, the
> > > question now becomes why does -fsanitize=undefined find nothing, and is
> > > the
> > > return type, i.e `declval(get(t))` different in gcc compared to the
> > > other
> > > compiles. I would expect similar issues in the other compilers if this is
> > > returning a reference to the temporary given by the argument list of `get`
> >
> > So -fsanitize=undefined adds some extra code which just happens to cause GCC
> > not to optimize as much.
> >
> > Try -fsanitize=address instead which enables
> > -fsanitize-address-use-after-scope which should detect the problem but I see
> > it does not
>
> I'm unsure why this would be a temporary, given:
>
> auto lambda = [=](auto&& f) mutable -> decltype(auto) { return f(&ts...); };
>
> This should capture all `ts...` by copy, the `f(&ts...)` should reference
> the captures of `this` inside the lambda (of the compiler generated
> structure.)
>
> When `get` is called, the values from the lambda are returned by
> dereferencing since the function is called with pointers (synthesized with
> `&ts...` in the lambda). I verified this by printing
> `typeid(decltype(get(t))).name()` passed to `__cxa_demangle`. There isn't
> any reference types, just to be sure that's not some runtime quirk, the
> compile-time result of `std::is_same_v)>` is true.
>
> Where is the temporary happening?
This is curious, omitting `decltype(auto)` for get, as in just `auto` seems to
work around the issue as well.
template
constexpr auto get(T tuple) { return *tuple(Get{}); }
I'm a bit out of my element here, in that I don't understand the semantic
differences between the two and if that behavior is correct.
[Bug fortran/101564] ICE in resolve_allocate_deallocate, at fortran/resolve.c:8169
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101564
--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #2)
> The %kind was introduced probably in r9, so likely not a real regression.
>
> I am testing the following patch:
>
> diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
> index 45c3ad387ac..51d312116eb 100644
> --- a/gcc/fortran/resolve.c
> +++ b/gcc/fortran/resolve.c
> @@ -8165,6 +8165,9 @@ resolve_allocate_deallocate (gfc_code *code, const
> char *fcn)
> gfc_error ("Stat-variable at %L must be a scalar INTEGER "
>"variable", &stat->where);
>
> + if (stat->expr_type == EXPR_CONSTANT || stat->symtree == NULL)
> + goto done_stat;
> +
>for (p = code->ext.alloc.list; p; p = p->next)
> if (p->expr->symtree->n.sym->name == stat->symtree->n.sym->name)
> {
> @@ -8192,6 +8195,8 @@ resolve_allocate_deallocate (gfc_code *code, const
> char *fcn)
> }
> }
>
> +done_stat:
> +
>/* Check the errmsg variable. */
>if (errmsg)
> {
The patch I posted is simpler, but yours will also do the trick.
[Bug fortran/101564] ICE in resolve_allocate_deallocate, at fortran/resolve.c:8169
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101564
--- Comment #2 from anlauf at gcc dot gnu.org ---
The %kind was introduced probably in r9, so likely not a real regression.
I am testing the following patch:
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 45c3ad387ac..51d312116eb 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -8165,6 +8165,9 @@ resolve_allocate_deallocate (gfc_code *code, const char
*fcn)
gfc_error ("Stat-variable at %L must be a scalar INTEGER "
"variable", &stat->where);
+ if (stat->expr_type == EXPR_CONSTANT || stat->symtree == NULL)
+ goto done_stat;
+
for (p = code->ext.alloc.list; p; p = p->next)
if (p->expr->symtree->n.sym->name == stat->symtree->n.sym->name)
{
@@ -8192,6 +8195,8 @@ resolve_allocate_deallocate (gfc_code *code, const char
*fcn)
}
}
+done_stat:
+
/* Check the errmsg variable. */
if (errmsg)
{
[Bug fortran/101564] ICE in resolve_allocate_deallocate, at fortran/resolve.c:8169
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101564
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Last reconfirmed||2021-07-21
Ever confirmed|0 |1
CC||kargl at gcc dot gnu.org
Status|UNCONFIRMED |NEW
--- Comment #1 from kargl at gcc dot gnu.org ---
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 45c3ad387ac..ce22d8644ea 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -8166,7 +8167,8 @@ resolve_allocate_deallocate (gfc_code *code, const char
*fcn)
"variable", &stat->where);
for (p = code->ext.alloc.list; p; p = p->next)
- if (p->expr->symtree->n.sym->name == stat->symtree->n.sym->name)
+ if (stat->symtree
+ && stat->symtree->n.sym->name == p->expr->symtree->n.sym->name)
{
gfc_ref *ref1, *ref2;
bool found = true;
[Bug libstdc++/40380] class documentation should mention include file to use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40380 --- Comment #6 from Jonathan Wakely --- My doxygen patch was merged, so we can start to use SHOW_HEADERFILE and @headerfile to do this.
[Bug c++/101566] gcc miscompiles lambda used as tuple-like object applied to function for call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101566
--- Comment #5 from Dale Weiler ---
(In reply to Dale Weiler from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > (In reply to Dale Weiler from comment #2)
> > > Ah, passing `T&` here instead of T does appear to avoid the issue, the
> > > question now becomes why does -fsanitize=undefined find nothing, and is
> > > the
> > > return type, i.e `declval(get(t))` different in gcc compared to the
> > > other
> > > compiles. I would expect similar issues in the other compilers if this is
> > > returning a reference to the temporary given by the argument list of `get`
> >
> > So -fsanitize=undefined adds some extra code which just happens to cause GCC
> > not to optimize as much.
> >
> > Try -fsanitize=address instead which enables
> > -fsanitize-address-use-after-scope which should detect the problem but I see
> > it does not
>
> I'm unsure why this would be a temporary, given:
>
> auto lambda = [=](auto&& f) mutable -> decltype(auto) { return f(&ts...); };
>
> This should capture all `ts...` by copy, the `f(&ts...)` should reference
> the captures of `this` inside the lambda (of the compiler generated
> structure.)
>
> When `get` is called, the values from the lambda are returned by
> dereferencing since the function is called with pointers (synthesized with
> `&ts...` in the lambda). I verified this by printing
> `typeid(decltype(get(t))).name()` passed to `__cxa_demangle`. There isn't
> any reference types, just to be sure that's not some runtime quirk, the
> compile-time result of `std::is_same_v)>` is true.
>
> Where is the temporary happening?
This is curious, omitting `decltype(auto)` for get, as in just `auto` seems to
work around the issue as well.
template
constexpr auto get(T tuple) { return *tuple(Get{}); }
I'm a bit out of my element here, in that I don't understand the semantic
differences between the two and if that behavior is correct.
[Bug testsuite/101531] [11 regression] gcc.target/powerpc/pr101129.c has excess errors after r11-8780
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101531 Bill Schmidt changed: What|Removed |Added Target Milestone|11.2|11.3
[Bug testsuite/101531] [11 regression] gcc.target/powerpc/pr101129.c has excess errors after r11-8780
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101531 Bill Schmidt changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-07-21 Status|UNCONFIRMED |NEW --- Comment #3 from Bill Schmidt --- Fixed on trunk, awaiting backports. (Confirmed, BTW.)
[Bug target/88035] missing _mm512_reduce_round_pd() et al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88035 --- Comment #3 from Sunil Pandey --- I added _mm512_reduce_round_pd() and bunch of other missing intrinsic last year. commit 93103603fd66a9fcf3ea2d8b52657e4b2496f544 Author: Sunil K Pandey Date: Wed Oct 14 11:36:39 2020 -0700 x86: Add missing intrinsics [PR95483] Tested on x86-64. gcc/ChangeLog: $ git grep mm512_reduce_round_pd gcc/ChangeLog-2020: (_mm512_reduce_round_pd): Ditto. gcc/config/i386/avx512dqintrin.h:_mm512_reduce_round_pd (__m512d __A, int __B, const int __R) gcc/config/i386/avx512dqintrin.h:#define _mm512_reduce_round_pd(A, B, R) \ gcc/testsuite/gcc.target/i386/avx512dq-vreducepd-3.c: xx1 = _mm512_reduce_round_pd(xx1, IMM, _MM_FROUND_NO_EXC); $ git grep mm_*reduce_round gcc/ChangeLog-2020: * config/i386/avx512dqintrin.h (_mm_reduce_round_sd): New intrinsics. gcc/ChangeLog-2020: (_mm_reduce_round_ss): Ditto. gcc/config/i386/avx512dqintrin.h:_mm_reduce_round_sd (__m128d __A, __m128d __B, int __C, const int __R) gcc/config/i386/avx512dqintrin.h:_mm_reduce_round_ss (__m128 __A, __m128 __B, int __C, const int __R) gcc/config/i386/avx512dqintrin.h:#define _mm_reduce_round_sd(A, B, C, R) \ gcc/config/i386/avx512dqintrin.h:#define _mm_reduce_round_ss(A, B, C, R) \ gcc/testsuite/gcc.target/i386/avx512dq-vreducesd-1.c: xx1 = _mm_reduce_round_sd (xx1, xx2, IMM, _MM_FROUND_NO_EXC); gcc/testsuite/gcc.target/i386/avx512dq-vreducesd-2.c: res4.x = _mm_reduce_round_sd (s1.x, s2.x, IMM,_MM_FROUND_TO_NEAREST_INT gcc/testsuite/gcc.target/i386/avx512dq-vreducess-1.c: xx1 = _mm_reduce_round_ss (xx1, xx2, IMM, _MM_FROUND_NO_EXC); gcc/testsuite/gcc.target/i386/avx512dq-vreducess-2.c: res4.x = _mm_reduce_round_ss (s1.x, s2.x, IMM, _MM_FROUND_TO_NEAREST_INT
[Bug fortran/101565] ICE in gfc_simplify_image_index, at fortran/simplify.c:8234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101565
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Priority|P3 |P4
Last reconfirmed||2021-07-21
Ever confirmed|0 |1
--- Comment #1 from kargl at gcc dot gnu.org ---
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 27bf3a7eafe..e0162f16348 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -5970,6 +5970,13 @@ gfc_check_image_index (gfc_expr *coarray, gfc_expr *sub)
return false;
}
+ if (sub->ts.type != BT_INTEGER)
+{
+ gfc_error ("Type of %s argument of IMAGE_INDEX at %L shall be INTEGER",
+gfc_current_intrinsic_arg[1]->name, &sub->where);
+ return false;
+}
+
if (gfc_array_size (sub, &nelems))
{
int corank = gfc_get_corank (coarray);
[Bug c++/101566] gcc miscompiles lambda used as tuple-like object applied to function for call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101566
--- Comment #4 from Dale Weiler ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Dale Weiler from comment #2)
> > Ah, passing `T&` here instead of T does appear to avoid the issue, the
> > question now becomes why does -fsanitize=undefined find nothing, and is the
> > return type, i.e `declval(get(t))` different in gcc compared to the other
> > compiles. I would expect similar issues in the other compilers if this is
> > returning a reference to the temporary given by the argument list of `get`
>
> So -fsanitize=undefined adds some extra code which just happens to cause GCC
> not to optimize as much.
>
> Try -fsanitize=address instead which enables
> -fsanitize-address-use-after-scope which should detect the problem but I see
> it does not
I'm unsure why this would be a temporary, given:
auto lambda = [=](auto&& f) mutable -> decltype(auto) { return f(&ts...); };
This should capture all `ts...` by copy, the `f(&ts...)` should reference the
captures of `this` inside the lambda (of the compiler generated structure.)
When `get` is called, the values from the lambda are returned by dereferencing
since the function is called with pointers (synthesized with `&ts...` in the
lambda). I verified this by printing `typeid(decltype(get(t))).name()`
passed to `__cxa_demangle`. There isn't any reference types, just to be sure
that's not some runtime quirk, the compile-time result of `std::is_same_v)>` is true.
Where is the temporary happening?
[Bug testsuite/101531] [11 regression] gcc.target/powerpc/pr101129.c has excess errors after r11-8780
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101531 --- Comment #2 from CVS Commits --- The master branch has been updated by William Schmidt : https://gcc.gnu.org/g:133aa7e54f77fdc15c311ecb52decfb3f52e179c commit r12-2451-g133aa7e54f77fdc15c311ecb52decfb3f52e179c Author: Bill Schmidt Date: Wed Jul 21 09:23:45 2021 -0500 rs6000: Add int128 target check to pr101129.c (PR101531) 2021-07-21 Bill Schmidt gcc/testsuite/ PR target/101531 * gcc.target/powerpc/pr101129.c: Adjust.
[Bug c++/101566] gcc miscompiles lambda used as tuple-like object applied to function for call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101566 --- Comment #3 from Andrew Pinski --- (In reply to Dale Weiler from comment #2) > Ah, passing `T&` here instead of T does appear to avoid the issue, the > question now becomes why does -fsanitize=undefined find nothing, and is the > return type, i.e `declval(get(t))` different in gcc compared to the other > compiles. I would expect similar issues in the other compilers if this is > returning a reference to the temporary given by the argument list of `get` So -fsanitize=undefined adds some extra code which just happens to cause GCC not to optimize as much. Try -fsanitize=address instead which enables -fsanitize-address-use-after-scope which should detect the problen but I see it does not
[Bug c++/101566] gcc miscompiles lambda used as tuple-like object applied to function for call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101566
--- Comment #2 from Dale Weiler ---
(In reply to Andrew Pinski from comment #1)
> f.0_1 = f_8(D);
> tuple = t;
> _11 = &tuple.__ts#2;
> tuple ={v} {CLOBBER};
>
>
> template
> constexpr decltype(auto) get(T tuple) { return *tuple(Get{}); }
>
>
> I think the above function (get) is broken and is returning a reference to
> the argument and that would be invalid.
Ah, passing `T&` here instead of T does appear to avoid the issue, the question
now becomes why does -fsanitize=undefined find nothing, and is the return type,
i.e `declval(get(t))` different in gcc compared to the other compiles. I
would expect similar issues in the other compilers if this is returning a
reference to the temporary given by the argument list of `get`
[Bug c++/101566] gcc miscompiles lambda used as tuple-like object applied to function for call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101566
--- Comment #1 from Andrew Pinski ---
f.0_1 = f_8(D);
tuple = t;
_11 = &tuple.__ts#2;
tuple ={v} {CLOBBER};
template
constexpr decltype(auto) get(T tuple) { return *tuple(Get{}); }
I think the above function (get) is broken and is returning a reference to the
argument and that would be invalid.
[Bug tree-optimization/101494] [11 Regression] -Wmaybe-uninitialized false alarm with memrchr of size 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101494 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Summary|-Wmaybe-uninitialized false |[11 Regression] |alarm with memrchr of size |-Wmaybe-uninitialized false |0 |alarm with memrchr of size ||0 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Known to fail||11.1.0 --- Comment #3 from Martin Sebor --- It is a regression but only because GCC 10 doesn't check accesses to allocated storage to see if it's initialized.
[Bug rtl-optimization/101562] [9/10/11/12 Regression] ICE in insert, at wide-int.cc:682
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101562
--- Comment #2 from Andrew Pinski ---
669 /* Insert WIDTH bits from Y into X starting at START. */
670 wide_int
671 wi::insert (const wide_int &x, const wide_int &y, unsigned int start,
672 unsigned int width)
673 {
674 wide_int result;
675 wide_int mask;
676 wide_int tmp;
(gdb) p precision
$11 = 8
(gdb) p width
$12 = 16
[Bug c++/101566] New: gcc miscompiles lambda used as tuple-like object applied to function for call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101566 Bug ID: 101566 Summary: gcc miscompiles lambda used as tuple-like object applied to function for call Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: weilercdale at gmail dot com Target Milestone: --- Created attachment 51191 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51191&action=edit minimized test case The following code uses a compiler generated structure via a lambda and `[=]` capture-list to create a "tuple"-like object, `get` is implemented in terms of the gcc provided intrinsic `__integer_pack(N)` to emulate `std::index_sequence` for peeling off the value from the "tuple"-like object. `apply` calls any callable by applying `get<>` to each value in the "tuple"-like object. `PackCount` exposes the parameter pack count of the "tuple"-like object created with `make`, A `decltype` of the lambda is used to create a new struct `Lambda` that inherits both, making `PackCount::ELEMENTS` available as a compile-time constant to each created "tuple"-like object. A `Tuple` type is provided by taking the `decltype` of `make` synthesizing values for the call with `declval`. The code compiles in gcc, msvc, and clang but only works in the latter two compilers, gcc appears to miscompile the code under -O3. When compiling in gcc with -fsanitize=undefined, the code isn't miscompiled, and it runs fine. Under other optimization levels the code isn't miscompiled either. This appears to affect multiple versions of gcc including 10.1, 10.2, 10.3, 11.1.0, 11.1.1, and current trunk as can be verified on compiler explorer here https://godbolt.org/z/3sYnrj6nW
[Bug rtl-optimization/101562] [9/10/11/12 Regression] ICE in insert, at wide-int.cc:682
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101562 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-07-21 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed 2837 wide_int o = wi::insert (rtx_mode_t (outer, temp_mode), 2838 rtx_mode_t (inner, dest_mode), 2839 offset, width); 2840 2841 combine_merges++; 2842 subst_insn = i3; 2843 subst_low_luid = DF_INSN_LUID (i2); (gdb) p outer $1 = (rtx) 0x76b32490 (gdb) p debug_rtx(outer) (const_int 0 [0]) $2 = void (gdb) p debug_rtx(inner) (const_int 256 [0x100]) $3 = void (gdb) p offset $4 = 0 (gdb) p mode No symbol "mode" in current context. (gdb) p width $5 = 16 (gdb) p temp_mode $6 = QImode (gdb) p dest_mode $7 = HImode
[Bug tree-optimization/101494] -Wmaybe-uninitialized false alarm with memrchr of size 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101494
Martin Sebor changed:
What|Removed |Added
Last reconfirmed||2021-07-21
Status|UNCONFIRMED |NEW
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Martin Sebor ---
Confirmed. I think this exposes two underlying bugs: one that the
initialization isn't detected and another that the second argument to attribute
access isn't respected. A slightly enhanced test case:
$ cat b.c && gcc -O2 -S -Wall b.c
__attribute__ ((access (read_only, 1, 2))) void f (const void*, int);
void g (void)
{
char *p = __builtin_alloca (1);
*p = 0;
f (p, 0);// bogus -Wmaybe-uninitialized
}
void h (void)
{
char *p = __builtin_malloc (1);
f (p, 0);// bogus -Wmaybe-uninitialized
}
b.c: In function ‘g’:
b.c:7:3: warning: ‘p’ is used uninitialized [-Wuninitialized]
7 | f (p, 0);// bogus -Wmaybe-uninitialized
| ^~~~
b.c:1:49: note: in a call to ‘f’ declared with attribute ‘access (read_only, 1,
2)’ here
1 | __attribute__ ((access (read_only, 1, 2))) void f (const void*, int);
| ^
b.c: In function ‘h’:
b.c:13:3: warning: ‘p’ is used uninitialized [-Wuninitialized]
13 | f (p, 0);// bogus -Wmaybe-uninitialized
| ^~~~
b.c:1:49: note: in a call to ‘f’ declared with attribute ‘access (read_only, 1,
2)’ here
1 | __attribute__ ((access (read_only, 1, 2))) void f (const void*, int);
| ^
[Bug fortran/101565] New: ICE in gfc_simplify_image_index, at fortran/simplify.c:8234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101565 Bug ID: 101565 Summary: ICE in gfc_simplify_image_index, at fortran/simplify.c:8234 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Non-integer array SUB affects versions down to at least r5 : (z4 with a misleading error) $ cat z1.f90 program p integer :: x[*] print *, image_index(x, [1.0]) end $ cat z2.f90 program p integer :: x[*] print *, image_index(x, [.true.]) end $ cat z3.f90 program p type t integer :: a end type integer :: x[*] print *, image_index(x, [t(1)]) end $ cat z4.f90 program p integer :: x[*] print *, image_index(x, ['1']) end $ gfortran-12-20210718 -c z4.f90 -fcoarray=lib z4.f90:3:24: 3 |print *, image_index(x, ['1']) |1 Error: Out of bounds in IMAGE_INDEX at (1) for dimension 1, SUB has 0 and COARRAY lower bound is 1) $ gfortran-12-20210718 -c z1.f90 -fcoarray=lib f951: internal compiler error: Segmentation fault 0xe3985f crash_signal ../../gcc/toplev.c:328 0x7d59d2 gfc_simplify_image_index(gfc_expr*, gfc_expr*) ../../gcc/fortran/simplify.c:8234 0x753f73 do_simplify ../../gcc/fortran/intrinsic.c:4664 0x75e99a gfc_intrinsic_func_interface(gfc_expr*, int) ../../gcc/fortran/intrinsic.c:5050 0x7af8b9 resolve_unknown_f ../../gcc/fortran/resolve.c:2926 0x7af8b9 resolve_function ../../gcc/fortran/resolve.c:3270 0x7af8b9 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:7104 0x7b5cf4 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:7071 0x7b5cf4 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11832 0x7b463f gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:10851 0x7b4a08 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11822 0x7b7317 resolve_codes ../../gcc/fortran/resolve.c:17427 0x7b73de gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:17462 0x79f924 resolve_all_program_units ../../gcc/fortran/parse.c:6403 0x79f924 gfc_parse_file() ../../gcc/fortran/parse.c:6655 0x7ecf1f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug fortran/101564] New: ICE in resolve_allocate_deallocate, at fortran/resolve.c:8169
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101564 Bug ID: 101564 Summary: ICE in resolve_allocate_deallocate, at fortran/resolve.c:8169 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Since r9, backtrace when configured with --enable-checking=yes : $ cat z1.f90 program p integer, allocatable :: x(:) integer :: stat allocate (x(2), stat=stat) deallocate (x, stat=stat%kind) end $ cat z2.f90 program p integer, allocatable :: x[:] integer :: stat allocate (x[*], stat=stat) deallocate (x, stat=stat%kind) end $ gfortran-12-20210718 -c z1.f90 z1.f90:5:32: 5 |deallocate (x, stat=stat%kind) |1 Error: Non-variable expression in variable definition context (STAT variable) at (1) f951: internal compiler error: Segmentation fault 0xe3985f crash_signal ../../gcc/toplev.c:328 0x7b3170 resolve_allocate_deallocate ../../gcc/fortran/resolve.c:8169 0x7b67b2 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:12118 0x7b7317 resolve_codes ../../gcc/fortran/resolve.c:17427 0x7b73de gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:17462 0x79f924 resolve_all_program_units ../../gcc/fortran/parse.c:6403 0x79f924 gfc_parse_file() ../../gcc/fortran/parse.c:6655 0x7ecf1f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug c++/101563] New: ICE in lookup_template_class_1, at cp/pt.c:10184
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101563
Bug ID: 101563
Summary: ICE in lookup_template_class_1, at cp/pt.c:10184
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects versions down to at least r5 :
(in addition to g++.dg/template/mem-spec1.C)
$ cat z1.cc
namespace N {
template struct A
{
template struct B {};
A() { B b; }
};
template<> template
struct A::B
{
~B() {}
};
A x;
A::B y;
}
$ g++-12-20210718 -c z1.cc
z1.cc: In instantiation of 'N::A< >::A() [with
= int]':
z1.cc:12:10: required from here
z1.cc:5:18: internal compiler error: in lookup_template_class_1, at
cp/pt.c:10184
5 | A() { B b; }
| ^
0x98a861 lookup_template_class_1
../../gcc/cp/pt.c:10184
0x98a861 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/cp/pt.c:10230
0x98b14d tsubst_aggr_type
../../gcc/cp/pt.c:13577
0x9753d7 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:15450
0x98cb91 tsubst_decl
../../gcc/cp/pt.c:14747
0x9755bf tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:15369
0x998171 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18236
0x995852 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18479
0x993b75 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18120
0x995852 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18479
0x979d49 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18106
0x979d49 instantiate_body
../../gcc/cp/pt.c:25869
0x97b477 instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.c:26162
0x9bd42b instantiate_pending_templates(int)
../../gcc/cp/pt.c:26241
0x82cac1 c_parse_final_cleanups()
../../gcc/cp/decl2.c:4991
[Bug rtl-optimization/101562] [9/10/11/12 Regression] ICE in insert, at wide-int.cc:682
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101562 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.5 Component|c |rtl-optimization
[Bug c/101562] New: [9/10/11/12 Regression] ICE in insert, at wide-int.cc:682
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101562
Bug ID: 101562
Summary: [9/10/11/12 Regression] ICE in insert, at
wide-int.cc:682
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started with r7, at -O2+ :
(gcc here configured with --enable-checking=yes)
(helpful warning with -O2 -Wall, but not with -O1 -Wall)
(-> array subscript is above array bounds)
$ cat z1.c
struct S { char c; };
void g (struct S a, struct S b);
void f ()
{
struct S x[1];
x[0].c = 0;
x[1].c = 1;
g (x[0], x[1]);
return;
}
$ gcc-6 -c z1.c -O2
$ gcc-12-20210718 -c z1.c -O1
$
$ gcc-12-20210718 -c z1.c -O2
during RTL pass: combine
z1.c: In function 'f':
z1.c:10:1: internal compiler error: in insert, at wide-int.cc:682
10 | }
| ^
0x11ad9c1 wi::insert(generic_wide_int const&,
generic_wide_int const&, unsigned int, unsigned int)
../../gcc/wide-int.cc:682
0x17f6c2e try_combine
../../gcc/combine.c:2839
0x17f9860 combine_instructions
../../gcc/combine.c:1269
0x17f9860 rest_of_handle_combine
../../gcc/combine.c:14873
0x17f9860 execute
../../gcc/combine.c:14918
[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 #275 from dave.anglin at bell dot net --- On 2021-07-21 12:55 p.m., me at larbob dot org wrote: > Here's `disas $pc-256,$pc+256`'s output. Maybe r47 contains garbage.
[Bug target/101561] -msse4 -mno-crc32 doesn't disable CRC32 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101561 H.J. Lu changed: What|Removed |Added Known to work||12.0 Last reconfirmed||2021-07-21 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from H.J. Lu --- This is fixed in GCC 12 by r12-12 and r12-2440.
[Bug target/101549] [12 Regression] internal compiler error: in extract_insn, at recog.c:2769
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101549 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from H.J. Lu --- Fixed for GCC 12. GCC 11 failed to disable CRC32 with -mno-crc32 (PR 101561).
[Bug target/101561] New: -msse4 -mno-crc32 doesn't disable CRC32 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101561
Bug ID: 101561
Summary: -msse4 -mno-crc32 doesn't disable CRC32 intrinsics
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
[hjl@gnu-cfl-2 tmp]$ cat x.c
#include
unsigned int
test_mm_crc32_u8(unsigned int CRC, unsigned char V)
{
return _mm_crc32_u8(CRC, V);
}
[hjl@gnu-cfl-2 tmp]$ gcc -S -O2 -msse4 -mno-crc32 x.c
[hjl@gnu-cfl-2 tmp]$
[Bug target/101549] [12 Regression] internal compiler error: in extract_insn, at recog.c:2769
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101549 --- Comment #1 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:7aa28dbc371cf3c09c05c68672b00d9006391595 commit r12-2440-g7aa28dbc371cf3c09c05c68672b00d9006391595 Author: H.J. Lu Date: Wed Jul 21 05:15:55 2021 -0700 x86: Remove OPTION_MASK_ISA_SSE4_2 from CRC32 _builtin functions Since commit 39671f87b2df6a1894cc11a161e4a7949d1ddccd Author: H.J. Lu Date: Thu Apr 15 05:59:48 2021 -0700 x86: Use crc32 target option for CRC32 intrinsics enabled OPTION_MASK_ISA_CRC32 for -msse4 and removed TARGET_SSE4_2 check in sse4_2_crc32 pattens, remove OPTION_MASK_ISA_SSE4_2 from CRC32 _builtin functions. gcc/ PR target/101549 * config/i386/i386-builtin.def: Remove OPTION_MASK_ISA_SSE4_2 from CRC32 _builtin functions. gcc/testsuite/ PR target/101549 * gcc.target/i386/crc32-6.c: New test.
[Bug target/101393] PowerPC32 inline assembly broken by commit 2d94f7dea9c73ef3c116a0ddc722724578a860fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393 --- Comment #9 from Franz Sirl --- (In reply to Segher Boessenkool from comment #8) > I don't think it is a good idea to add workaround upon workaround to avoid > some of the not-so-useful behaviours of -many. Instead, we should just > not use -many? As I understand it -many is just one variation of the general problem with the sticky flags. If we remove -many from the assembler, there are still other sticky flags like -mvsx. Turning of any sticky flag is currently not supported by the assembler AFAICS. So for example it's impossible to switch from a VSX supporting assembler mode to an assembler mode without VSX via the .machine pseudo-op. Or did I misread the the assembler source?
[Bug tree-optimization/101558] Abnormal behavior with -O3 : warning: writing 8 bytes into a region of size 0 [-Wstringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101558 --- Comment #2 from Franco Corbelli --- Thank you, I spend about two days tinkering with Ubuntu's default compiler. At least I know I'm not completely crazy
[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 #274 from Larkin Nickle --- Created attachment 51190 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51190&action=edit disas of cc1 with more context Here's `disas $pc-256,$pc+256`'s output.
[Bug bootstrap/101379] libatomic arm build failure after r12-2132 due -Warray-bounds on a constant address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101379 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Martin Sebor --- Patch committed in r12-2438.
[Bug fortran/101514] ICE: out of memory allocating 18446744073709551600 bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101514 --- Comment #4 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:c2b15fe27e6a0e42b108111d51acce69628593b4 commit r12-2439-gc2b15fe27e6a0e42b108111d51acce69628593b4 Author: Harald Anlauf Date: Wed Jul 21 18:54:00 2021 +0200 Fortran: ICE, OOM while calculating sizes of derived type array components gcc/fortran/ChangeLog: PR fortran/101514 * target-memory.c (gfc_interpret_derived): Size of array component of derived type can only be computed here for explicit shape. * trans-types.c (gfc_get_nodesc_array_type): Do not dereference NULL pointers. gcc/testsuite/ChangeLog: PR fortran/101514 * gfortran.dg/pr101514.f90: New test.
[Bug target/101559] RISCV -- incorrect label address when using -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101559 --- Comment #4 from Jakub Jelinek --- You can make the compiler believe it could use computed goto to that label but actually not do that, say by void *volatile ptr = &&label; int volatile cond = 0; if (cond) goto *ptr; But even this would just have an edge from that computed goto and because of volatile it wouldn't know if the condition is never true. Or gcc supports asm goto, where the inline asm would do that csr_read_write part (before GCC 11 asm goto couldn't have output operands) and that would make the compiler take branching from the inline asm to the label as possibility.
[Bug bootstrap/101379] libatomic arm build failure after r12-2132 due -Warray-bounds on a constant address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101379 --- Comment #10 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:b937dbf2577e0fa3018c562312da7b08bbe72d70 commit r12-2438-gb937dbf2577e0fa3018c562312da7b08bbe72d70 Author: Martin Sebor Date: Wed Jul 21 10:48:55 2021 -0600 Adjust macro to avoid warning [PR101379]. Resolves: PR bootstrap/101379 - libatomic arm build failure after r12-2132 due to -Warray-bounds on a constant address libatomic/ChangeLog: PR bootstrap/101379 * config/linux/arm/host-config.h (__kernel_helper_version): New function. Adjust shadow macro.
[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 #273 from John Buddery --- If you go back a bit further, is there a speculative load of one of those registers (probably r47 / r59 ) ? A speculative load will have a .s I think. I believe ILL_REGNAT should actually be a SEGV, not SIGILL - not sure why that's the signal being generated.
[Bug target/101469] wrong code with "-O2 -fPIE" for SH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101469 --- Comment #6 from Rin Okuyama --- (In reply to Rin Okuyama from comment #3) > If that peephole is removed, GCC 10.3 generates working codes. > > NetBSD/shle built by this compiler works fine as far as I can see. > I'm carrying out full regression tests of NetBSD on this system. > (It takes about a day to finish.) It took more time due to minor troubles for my side, but it finished. Fallout from this bug is fixed, whereas no new regressions are observed! Thanks, rin
[Bug bootstrap/101553] [12 Regression] armhf builds broken on -Werror=array-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101553 --- Comment #2 from Tamar Christina --- Thanks, I didn't see the patch, I've pinged the maintainers.
[Bug libstdc++/101542] __gnu_cxx::sequence_buffer const copy constructor is badly broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101542 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |12.0 --- Comment #5 from Jonathan Wakely --- Should be fixed now.
[Bug target/101560] [12 Regression] ICE building 526.blender_r with -Ofast -flto -march=znver2 since r12-1958-gedafb35bdad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101560 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=101504 --- Comment #1 from Andrew Pinski --- Might be the same as PR 101504 even.
[Bug target/101560] [12 Regression] ICE building 526.blender_r with -Ofast -flto -march=znver2 since r12-1958-gedafb35bdad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101560 Andrew Pinski changed: What|Removed |Added Summary|ICE building 526.blender_r |[12 Regression] ICE |with -Ofast -flto |building 526.blender_r with |-march=znver2 since |-Ofast -flto -march=znver2 |r12-1958-gedafb35bdad |since r12-1958-gedafb35bdad Keywords||ice-on-valid-code Target Milestone|--- |12.0
[Bug target/101393] PowerPC32 inline assembly broken by commit 2d94f7dea9c73ef3c116a0ddc722724578a860fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393 Segher Boessenkool changed: What|Removed |Added CC||amodra at gcc dot gnu.org --- Comment #8 from Segher Boessenkool --- (In reply to Franz Sirl from comment #7) > Created attachment 51189 [details] > More complete trial patch to overhaul ASM_CPU_SPEC > > This patch should be more complete now. It does the following basic things: If it does a few things, it should be a few patches, not one. > - Only pass -many to the assembler when -massembler-any is given Interesting idea! I wonder how well that works, how many programs will need to use that new flag (for their inline assembler code). > - Unify the non-AIX (for now) asm_cpu spec settings into rs6000-cpus.def. > Currently this uses a "static inline" function because I developed on GCC10, > on GCC11 and later using a constexpr would be much nicer. > > Now, the other stuff to reliably handle -many would need some gas support, > where I likely need some help, because I've no expertise there. > > First, I suggest to introduce 2 assembler warning options: > > -wany-duplicates: Warn if the mnemonic to assemble has duplicates because > of -many, this should limit the warnings to the most difficult cases. In the > patch it's automatically enabled when -massembler-any is used. > -wany-strict: Warn if any mnemonic to assemble is only fulfilled because of > -many. You'll have to discuss this on binut...@sourceware.org . > And also some additional/changed options for .machine: > > .machine "resetsticky": Reset the sticky flags (eg. VSX, AltiVec, ANY) > .machine "pushsticky": Push CPU+sticky settings, reset the sticky flags > .machine "push": Change to push CPU+sticky, keep the sticky flags > .machine "pop": Change to pop CPU+sticky Why would you want this concept? It is mixing .machine selection with other things. > The attached patch tries to make use of such a TBD change to gas. > > Alternatively, gas could be changed to have -madditive-sticky and/or > '.machine "additive-sticky"' to make any '.machine "realcpu"' reset the > sticky flags and they have to be re-added again afterwards if needed. Maybe > this push/pop-less solution would be even easier to handle in the compiler? > > What do you think? I hope I addressed most of your concerns, suggestions > welcome. I don't think it is a good idea to add workaround upon workaround to avoid some of the not-so-useful behaviours of -many. Instead, we should just not use -many? [ Cc: Alan, for the binutils side of things ]
[Bug target/101560] New: ICE building 526.blender_r with -Ofast -flto -march=znver2 since r12-1958-gedafb35bdad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101560 Bug ID: 101560 Summary: ICE building 526.blender_r with -Ofast -flto -march=znver2 since r12-1958-gedafb35bdad Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jamborm at gcc dot gnu.org CC: hjl at gcc dot gnu.org Target Milestone: --- Host: x86_64-linux Target: x86_64-linux When building SPEC 2017 FPrate benchmark 526.blender_r with -Ofast -g -flto -march=znver2 -mtune=znver2 I see the following ICE: blender/source/blender/blenloader/intern/readfile.c: In function 'do_versions': blender/source/blender/blenloader/intern/readfile.c:7595:1: internal compiler error: in lra_assign, at lra-assigns.c:1649 7595 | } | ^ 0xb77d20 lra_assign(bool&) /home/mjambor/gcc/mine/src/gcc/lra-assigns.c:1649 0xb724c4 lra(_IO_FILE*) /home/mjambor/gcc/mine/src/gcc/lra.c:2387 0xb2d369 do_reload /home/mjambor/gcc/mine/src/gcc/ira.c:5932 0xb2d369 execute /home/mjambor/gcc/mine/src/gcc/ira.c:6118 Please submit a full bug report... Note that the assert is triggered only with checking, so release-build compilers do not see it. I have bisected it down to: commit edafb35bdadf309ebb9d1eddc5549f9e1ad49c09 Author: H.J. Lu Date: Wed Jun 2 07:15:45 2021 -0700 x86: Convert CONST_WIDE_INT/CONST_VECTOR to broadcast 1. Update move expanders to convert the CONST_WIDE_INT and CONST_VECTOR operands to vector broadcast from an integer with AVX. 2. Add ix86_gen_scratch_sse_rtx to return a scratch SSE register which won't increase stack alignment requirement and blocks transformation by the combine pass. [...rest of the commit message trimmed...] At this point I do not plan to attempt to come up with a reduced testcase.
[Bug tree-optimization/96963] [10 Regression] -Wstringop-overflow false positive on -O3 or -O2 -ftree-vectorize when assigning consecutive char struct members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96963 Andrew Pinski changed: What|Removed |Added CC||franco at francocorbelli dot com --- Comment #12 from Andrew Pinski --- *** Bug 101558 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/101558] Abnormal behavior with -O3 : warning: writing 8 bytes into a region of size 0 [-Wstringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101558 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 96963. *** This bug has been marked as a duplicate of bug 96963 ***
[Bug target/101559] RISCV -- incorrect label address when using -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101559
--- Comment #3 from Joël Porquet ---
Thanks for the quick replies and the clear explanation!
I'm a little bummed because this construct enabled me to write --what I
considered to be-- clean code for a bootloader. As shown below, I could
temporarily change the exception vector with a label's address located further
down, which corresponds to the restoration of the previous exception vector. If
any operation in between fails, we just skip ahead and ignore the rest.
```
static void setup_pmp(void)
{
uintptr_t otvec;
/* Ignore possible exception if some PMP registers are not implemented */
otvec = csr_read_write(CSR_MTVEC, &&restore_mtvec);
/* Reset configuration */
csr_write(CSR_PMPCFG0, 0);
/* Range for M-mode bootloader */
...
restore_mtvec:
csr_write(CSR_MTVEC, otvec);
}
```
This code unfortunately doesn't work because the label's address
(`restore_mtvec`) is moved to the beginning of the function and it goes into an
infinite loop if an exception is raised.
The only other way to write this code effectively seems to be to do it fully in
assembly, like they do in BBL
(https://github.com/riscv/riscv-pk/blob/66d7fcb56d6a4cd4879922f184bb2274918ac3cd/bbl/bbl.c#L53),
which I was trying to avoid since it felt pretty ugly :(
Do you see any alternative apart from the switch to assembly code?
Thanks in advance for your time.
[Bug libstdc++/101542] __gnu_cxx::sequence_buffer const copy constructor is badly broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101542 --- Comment #4 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:8edb61420502c62fa2cccdd98876a9aa039b72a6 commit r12-2437-g8edb61420502c62fa2cccdd98876a9aa039b72a6 Author: Jonathan Wakely Date: Wed Jul 21 15:29:19 2021 +0100 libstdc++: Make __gnu_cxx::sequence_buffer move-aware [PR101542] The PR explains that Clang trunk now selects a different constructor when a non-const sequence_buffer is returned in a context where it qualifies as an implicitly-movable entity. Because lookup is first performed using an rvalue, the sequence_buffer(const sequence_buffer&) constructor gets chosen, which makes a copy instead of a "pseudo-move" via the sequence_buffer(sequence_buffer&) constructor. The problem isn't seen with GCC because as noted in the r11-2412 commit log, GCC actually implements a slightly modified rule that avoids breaking exactly this type of code. This patch adds a move constructor to sequence_buffer, so that implicit or explicit moves will have the same effect, calling the sequence_buffer(sequence_buffer&) constructor. A move assignment operator is also added to make move assignment work similarly. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/101542 * include/ext/rope (sequence_buffer): Add move constructor and move assignment operator. * testsuite/ext/rope/101542.cc: New test.
[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 #272 from Larkin Nickle --- (In reply to dave.anglin from comment #271) > On 2021-07-21 2:32 a.m., me at larbob dot org wrote: > > Reading symbols from > > /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/./prev-gcc/cc1...BFD: > > /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/prev-gcc/cc1 symbol > > number > > 7215 references nonexistent SHT_SYMTAB_SHNDX section > > Can't read symbols from > > /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/prev-gcc/cc1: File in > > wrong format > This seems to be a problem with the symbol table in cc1. It's not a problem > with the dwarf info. > > Can readelf read symbols? What does file command show? If you strip cc1, > does gdb start? On system with a modern `file`: cc1: ELF 32-bit MSB executable, IA-64, version 1 (HP-UX), dynamically linked, interpreter /usr/lib/hpux32/uld.so:/usr/lib/hpux32/dld.so, with debug_info, not stripped, too many notes (256) Readelf is seemingly able to read them. > > disasm $pc-16,$pc+16 should show faulting instruction. (gdb) disas $pc-16,$pc+16 Dump of assembler code from 0x54af7e1 to 0x54af801: 0x054af7e1: st8 [r41]=r0 0x054af7e2: nop.i 0x0;; 0x054af7f0: [MMI] ld1.a r87=[r14] => 0x054af7f1: st8 [r47]=r59 0x054af7f2: nop.i 0x0 0x054af800: [MMI] st4 [r46]=r0;; End of assembler dump. This issue happens in stage3.
[Bug middle-end/28581] Illegal loading the address of a label with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28581 Andreas Schwab changed: What|Removed |Added CC||joel.porquet at gmail dot com --- Comment #13 from Andreas Schwab --- *** Bug 101559 has been marked as a duplicate of this bug. ***
[Bug target/101559] RISCV -- incorrect label address when using -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101559 Andreas Schwab changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #2 from Andreas Schwab --- *** This bug has been marked as a duplicate of bug 28581 ***
[Bug c++/101557] the value of '' is not usable in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101557 --- Comment #4 from Federico Kircheis --- Indeed. I just checked the latest versions. I wonder if there is a common cause that makes this recursive data structure harder to evaluate at compile time.
[Bug c++/101557] the value of '' is not usable in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101557 --- Comment #3 from Andrew Pinski --- (In reply to Federico Kircheis from comment #2) > clang does not reject it: > > https://godbolt.org/z/8Mq1e3o3j clang 11 does reject it but clang 12 does NOT reject it.
[Bug c++/101557] the value of '' is not usable in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101557 --- Comment #2 from Federico Kircheis --- clang does not reject it: https://godbolt.org/z/8Mq1e3o3j
[Bug bootstrap/101379] libatomic arm build failure after r12-2132 due -Warray-bounds on a constant address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101379 Martin Sebor changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #9 from Martin Sebor --- *** Bug 101553 has been marked as a duplicate of this bug. ***
[Bug bootstrap/101553] [12 Regression] armhf builds broken on -Werror=array-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101553 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Martin Sebor --- Patch was posted on 7/9 but hasn't yet been reviewed: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574880.html *** This bug has been marked as a duplicate of bug 101379 ***
[Bug target/101559] RISCV -- incorrect label address when using -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101559 Jakub Jelinek changed: What|Removed |Added Resolution|--- |INVALID CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jakub Jelinek --- That isn't a bug. If you aren't actually using the &&label value eventually to goto *ptr to it, there might be no cfg edges to a basic block that starts with that label, it can be during optimizations moved around, and while the compiler will usually try to keep it close to where it appeared originally, it is certainly not guaranteed.
[Bug target/101393] PowerPC32 inline assembly broken by commit 2d94f7dea9c73ef3c116a0ddc722724578a860fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393 Franz Sirl changed: What|Removed |Added Attachment #51164|0 |1 is obsolete|| --- Comment #7 from Franz Sirl --- Created attachment 51189 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51189&action=edit More complete trial patch to overhaul ASM_CPU_SPEC This patch should be more complete now. It does the following basic things: - Only pass -many to the assembler when -massembler-any is given - Unify the non-AIX (for now) asm_cpu spec settings into rs6000-cpus.def. Currently this uses a "static inline" function because I developed on GCC10, on GCC11 and later using a constexpr would be much nicer. Now, the other stuff to reliably handle -many would need some gas support, where I likely need some help, because I've no expertise there. First, I suggest to introduce 2 assembler warning options: -wany-duplicates: Warn if the mnemonic to assemble has duplicates because of -many, this should limit the warnings to the most difficult cases. In the patch it's automatically enabled when -massembler-any is used. -wany-strict: Warn if any mnemonic to assemble is only fulfilled because of -many. And also some additional/changed options for .machine: .machine "resetsticky": Reset the sticky flags (eg. VSX, AltiVec, ANY) .machine "pushsticky": Push CPU+sticky settings, reset the sticky flags .machine "push": Change to push CPU+sticky, keep the sticky flags .machine "pop": Change to pop CPU+sticky The attached patch tries to make use of such a TBD change to gas. Alternatively, gas could be changed to have -madditive-sticky and/or '.machine "additive-sticky"' to make any '.machine "realcpu"' reset the sticky flags and they have to be re-added again afterwards if needed. Maybe this push/pop-less solution would be even easier to handle in the compiler? What do you think? I hope I addressed most of your concerns, suggestions welcome.
[Bug target/101559] New: RISCV -- incorrect label address when using -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101559 Bug ID: 101559 Summary: RISCV -- incorrect label address when using -O2 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: joel.porquet at gmail dot com Target Milestone: --- The GNU construct `&&label` supposedly allows the programmer to get the address corresponding to a label. When compiling for RISCV, the correct address is computed when compiling with -O0 but not with -O2. Here is an example code where a label's address is properly computed: https://godbolt.org/z/qnEafeY6f. As you can see, the address corresponding to label `.L2` is properly retrieved using `lui` followed by `addi` and placed into register `a5`. Now, when the same code is compiled with `-O2`, the address is not properly computed: https://godbolt.org/z/n8zbbTnhb. As you can see, the label `.L2` is now placed at the very beginning of the function and points onto the function's first instruction. As a result, the computed address will not correspond to where the label was placed in the original code. Is that a bug, or am I missing something? Thanks!
[Bug c++/100493] Lambda default copy capture that captures "this" cannot be used in both C++17 and C++20 modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100493 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-07-21 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug c++/101557] the value of '' is not usable in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101557 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- clang++ rejects it similarly. pr101557.C:40:16: error: constexpr variable 'size3' must be initialized by a constant expression constexpr auto size3 = mysize(a); ^ ~ pr101557.C:22:45: note: read of temporary is not allowed in a constant expression outside the expression that created the temporary Wonder if this isn't related to the recently posted PR100976 patch.
[Bug libstdc++/101527] The implementation of std::common_iterator::operator== seems to be wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101527
--- Comment #3 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #2)
> I find it surprising, but the CWG consensus seems to be that a friend
> defined inline in the class body is "a member declaration of the befriended
> class".
Hey Jonathan, I just found out that std::counted_iterator also has the same
friend access issue.
#include
int main() {
std::counted_iterator it1;
std::counted_iterator it2;
return it1 == it2;
}
https://godbolt.org/z/jGT5jhbWz
[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 #271 from dave.anglin at bell dot net --- On 2021-07-21 2:32 a.m., me at larbob dot org wrote: > Reading symbols from > /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/./prev-gcc/cc1...BFD: > /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/prev-gcc/cc1 symbol > number > 7215 references nonexistent SHT_SYMTAB_SHNDX section > Can't read symbols from > /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/prev-gcc/cc1: File in > wrong format This seems to be a problem with the symbol table in cc1. It's not a problem with the dwarf info. Can readelf read symbols? What does file command show? If you strip cc1, does gdb start? disasm $pc-16,$pc+16 should show faulting instruction.
[Bug c++/101558] New: Abnormal behavior with -O3 : warning: writing 8 bytes into a region of size 0 [-Wstringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101558 Bug ID: 101558 Summary: Abnormal behavior with -O3 : warning: writing 8 bytes into a region of size 0 [-Wstringop-overflow=] Product: gcc Version: og10 (devel/omp/gcc-10) Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: franco at francocorbelli dot com Target Milestone: --- Created attachment 51188 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51188&action=edit Snippet of "strange" behavior On GCC 10.3.0 on Ubuntu 21 (...)COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 10.3.0-1ubuntu1' (...)Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.3.0 (Ubuntu 10.3.0-1ubuntu1) I get problems porting software from previous versions (8.x). In particular, there is a warning message of this kind " In member function ‘unzDT& unzDT::operator=(const unzDT&)’, inlined from ‘int main()’ at unz.cpp:27:9: unz.cpp:11:8: warning: writing 8 bytes into a region of size 0 [-Wstringop-overflow=] 11 | struct unzDT |^ unz.cpp: In function ‘int main()’: unz.cpp:13:12: note: at offset 0 to object ‘unzDT::date’ with size 8 declared here 13 | uint64_t date; | " It is reproducible with the attached snippet, by compiling with -O3 g++ -O3 unz.cpp -o unz If you want to see more "oddities" try to change the size of sha1decompressedhex from 8 to 7
[Bug c++/101557] New: the value of '' is not usable in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101557
Bug ID: 101557
Summary: the value of '' is not usable in a constant
expression
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.kircheis at gmail dot com
Target Milestone: ---
Consider following snippet
struct node {
const char* d;
const node& left;
const node& right;
};
constexpr const node Null = node{"",Null,Null};
constexpr const node a
{
"a",
node
{
"b",
node{"e",Null,Null},
node{"d",Null,Null},
},
node{"c",Null,Null},
};
constexpr int mysize(const node& n) noexcept{
return (&n == &Null) ? 0 : 1 + mysize(n.left) + mysize(n.right);
}
constexpr auto size0 = mysize(Null);
static_assert(size0 == 0, "");
constexpr auto size1 = mysize(node{"c", Null, Null});
static_assert(size1 == 1, "");
constexpr auto size2 = mysize(node
{
"b",
node{"e",Null,Null},
node{"d",Null,Null},
});
static_assert(size2 == 3, "");
// this line does not compile
constexpr auto size3 = mysize(a);
static_assert(size3 == 5, "");
The expression `constexpr auto size3 = mysize(a);` does not compile with the
error message
:41:30: in 'constexpr' expansion of 'mysize(a)'
:25:42: in 'constexpr' expansion of 'mysize((* & n.node::left))'
:41:32: error: the value of '' is not usable in a constant
expression
41 | constexpr auto size3 = mysize(a);
|^
:22:1: note: '' was not declared 'constexpr'
22 | };
| ^
Compiler returned: 1
A similar effect can be achieved with
constexpr node b = a.left;
with following error
:45:23: error: the value of '' is not usable in a constant
expression
45 | constexpr node b2 = a.left;
| ^~~~
:22:1: note: '' was not declared 'constexpr'
22 | };
| ^
Compiler returned: 1
even if
constexpr node b = a;
compiles without warnings.
Generally accessing subobjects should not be an issue, for example
struct sub{};
struct node2{
const sub& s;
};
constexpr const node2 n2{
sub{}
};
constexpr auto s = n2.s;
also compiles without issues
[Bug c++/101539] [C++20] Implement builtins for layout-compatibility and pointer-interconvertibility traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101539 --- Comment #3 from Jakub Jelinek --- I think the implementation of is_corresponding_member heavily depends on layout-compatibility ensuring the same sizes and alignments of the members, otherwise any comparison of the OFFSET_TYPE values (which just hold at runtime byte offset from the start of struct and at compile time hold also the type of the pointed non-static data member and type of the object the offset is relative to) is going to be a nighmare. So I think we first need a clarification of the standard for the various alignas cases or the [[no_unique_address]] cases that are shown e.g. in the #c1 testcase and only when we can count on the corresponding members to have the exact same offset we can move further on.
[Bug target/91602] GCC fails to build for riscv in a combined tree due to misconfigured leb128 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91602 Serge Belyshev changed: What|Removed |Added Keywords||patch --- Comment #15 from Serge Belyshev --- (In reply to Serge Belyshev from comment #12) > Testing a patch that removes in-tree gas version checks along with resulting > dead code. Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575744.html
[Bug c++/101555] Compile slowdown in tree PRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101555 --- Comment #1 from Wilson Snyder --- Created attachment 51187 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51187&action=edit Examples and runtimes
[Bug target/87743] Vectorizer doesn't support conversion of different sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87743 H.J. Lu changed: What|Removed |Added CC||skpgkp2 at gmail dot com --- Comment #8 from H.J. Lu --- This has been fixed in GCC 12. Sunil, please submit a GCC patch to add a testcase.
