[Bug target/104440] nvptx: FAIL: gcc.c-torture/execute/pr53465.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104440
--- Comment #10 from Tom de Vries ---
A good thing to note at this point: why doesn't init-regs work here?
The pass works per insn, and when hitting the insn with the problematic use:
...
(gdb) call debug_rtx (insn)
(insn 18 17 19 4 (set (reg/v:SI 30 [ c ])
(reg/v:SI 26 [ d ])) 6 {*movsi_insn}
(expr_list:REG_DEAD (reg/v:SI 26 [ d ])
(nil)))
...
and dealing with the use of reg 26 we test:
...
/* A use is MUST uninitialized if it reaches the top of
the block from the inside of the block (the lr test)
and no def for it reaches the top of the block from
outside of the block (the ur test). */
if (bitmap_bit_p (lr, regno)
&& (!bitmap_bit_p (ur, regno)))
...
where:
...
bitmap lr = DF_LR_IN (bb);
bitmap ur = DF_LIVE_IN (bb);
...
But we have:
...
(gdb) p bitmap_bit_p (lr, regno)
$1 = true
(gdb) p bitmap_bit_p (ur, regno)
$2 = true
...
so the test fails.
In terms of the rtl-dump, the insn is here:
...
(code_label 43 42 17 4 4 (nil) [1 uses])
(note 17 43 18 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn 18 17 19 4 (set (reg/v:SI 30 [ c ])
(reg/v:SI 26 [ d ])) 6 {*movsi_insn}
(expr_list:REG_DEAD (reg/v:SI 26 [ d ])
(nil)))
...
and the corresponding df info is:
...
( 7 3 )->[4]->( 8 5 )
;; bb 4 artificial_defs: { }
;; bb 4 artificial_uses: { u-1(1){ }u-1(2){ }u-1(3){ }}
;; lr in1 [%stack] 2 [%frame] 3 [%args] 25 26 31 32 52
;; lr use 1 [%stack] 2 [%frame] 3 [%args] 25 26
;; lr def 26 30 38
;; live in 1 [%stack] 2 [%frame] 3 [%args] 25 26 31 32 52
;; live gen 26 30 38
;; live kill
;; lr out 1 [%stack] 2 [%frame] 3 [%args] 25 26 30 31 32 52
;; live out 1 [%stack] 2 [%frame] 3 [%args] 25 26 30 31 32 52
...
In short, init-regs doesn't work for this example, because reg 26 is defined on
some incoming path, and ptx (or the JIT implementation) needs it to be defined
on all incoming paths.
[Bug middle-end/104550] bogus warning from -Wuninitialized + -ftrivial-auto-var-init=pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550 --- Comment #12 from rguenther at suse dot de --- On Wed, 16 Feb 2022, qinzhao at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550 > > --- Comment #7 from qinzhao at gcc dot gnu.org --- > (In reply to rguent...@suse.de from comment #6) > > > --- Comment #4 from Andrew Pinski --- > > > Maybe __builtin_clear_padding lowering should mark the load "MEM[(struct > > > vx_audio_level *)]" as not needing a warning. > > > > Maybe padding clearing shouldn’t be exposed early but handled by > > .DEFFEREd_INIT expansion? > > > > If padding clearing is exposed too late till RTL expansion, some tree > optimization will not be able to be applied on the expanded stores? Doesn't the same argument apply to .DEFERRED_INIT itself? Dependent on the .DEFERRED_INIT expansion strathegy the padding clearing might be unneccessary (for example when using memset())? > the approach to mark the load "MEM" as not needing a warning might be better? It's probably a good thing anyway, the 'R' in the RMW cycle isn't really a use.
[Bug target/104440] nvptx: FAIL: gcc.c-torture/execute/pr53465.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104440
--- Comment #9 from Tom de Vries ---
(In reply to Tom de Vries from comment #1)
> Tentative patch that fixes example:
> ...
> diff --git a/gcc/config/nvptx/nvptx.cc b/gcc/config/nvptx/nvptx.cc
> index 5b26c0f4c7dd..4dc154434853 100644
> --- a/gcc/config/nvptx/nvptx.cc
> +++ b/gcc/config/nvptx/nvptx.cc
> @@ -1565,6 +1565,23 @@ nvptx_declare_function_name (FILE *file, const char
> *name, cons
> t_tree decl)
> fprintf (file, "\t.reg%s ", nvptx_ptx_type_from_mode (mode, true));
> output_reg (file, i, split, -2);
> fprintf (file, ";\n");
> + switch (mode)
> + {
> + case HImode:
> + fprintf (file, "\tmov.u16 %%r%d, 0;\n", i);
> + break;
> + case SImode:
> + fprintf (file, "\tmov.u32 %%r%d, 0;\n", i);
> + break;
> + case DImode:
> + fprintf (file, "\tmov.u64 %%r%d, 0;\n", i);
> + break;
> + case BImode:
> + fprintf (file, "\tsetp.ne.u32 %%r%d,0,0;\n", i);
> + break;
> + default:
> + gcc_unreachable ();
> + }
> }
> }
>
> ...
FWIW, I've tested this patch (extended a bit to handle all cases) but ran into
trouble in the libgomp testsuite, with running out of resources. So this
approach is too resource-hungry.
[Bug tree-optimization/104579] vectorizer failed to reduce max & index search together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104579
--- Comment #2 from Hongtao.liu ---
One possible way is sink maxInt = src[i] out of loop, when there's synchronised
index search in the loop, just like below.
int max (int *src, int n, int *position)
{
int maxInt;
int maxIndex;
int i;
maxInt = src[0];
maxIndex = 0;
for (i = 1; i < n; i++) {
if (maxInt < src[i]) {
maxIndex = i;
}
}
maxInt = src[maxIndex];
*position = maxIndex;
return (maxInt);
}
[Bug middle-end/102276] -ftrivial-auto-var-init fails to initialize a variable, causes a spurious warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276 --- Comment #13 from rguenther at suse dot de --- On Tue, 15 Feb 2022, qinzhao at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276 > > --- Comment #11 from qinzhao at gcc dot gnu.org --- > (In reply to rguent...@suse.de from comment #10) > > > I think it definitely makes sense to diagnose that we are not > > following -ftrivial-auto-init-var=X for a decl. Maybe we should > > do that with -Wtrivial-auto-init-var only though? > > currently we don't have -Wtrivial-auto-init-var, do you want to add a new > option -Wtrivial-auto-init-var? what's the purpose of it? It's purpose is to diagnose cases where the program might see a not auto-initialized variable despite using -ftrivial-auto-init-var=...
[Bug target/104440] nvptx: FAIL: gcc.c-torture/execute/pr53465.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104440 --- Comment #8 from Tom de Vries --- Created attachment 52456 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52456=edit Tentative patch, introducing -minit-regs=<0|1|2> This patch fixes the problem, and survived a standalone build and gcc testsuite run. Currently testing in offloading setting. Uses DF_MIR_IN, otherwise only used by pass_ree. Effect of -minit-regs=1 (insert init at function entry): ... .reg.pred %r50; .reg.pred %r51; .reg.u32 %r52; + mov.u32 %r26, 0; mov.u64 %r33, %ar0; mov.u32 %r34, %ar1; setp.le.s32 %r35, %r34, 0; ... Effect of -minit-regs=2 (insert init close to use): ... add.u64 %r32, %r33, %r37; mov.u32 %r31, 0; mov.u32 %r52, 1; + mov.u32 %r26, 0; $L4: mov.u32 %r30, %r26; ld.u32 %r26, [%r25]; ...
[Bug tree-optimization/104579] vectorizer failed to reduce max & index search together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104579 --- Comment #1 from Hongtao.liu --- cut /* Function vect_is_simple_reduction (1) Detect a cross-iteration def-use cycle that represents a simple reduction computation. We look for the following pattern: loop_header: a1 = phi < a0, a2 > a3 = ... a2 = operation (a3, a1) or a3 = ... loop_header: a1 = phi < a0, a2 > a2 = operation (a3, a1) such that: 1. operation is commutative and associative and it is safe to change the order of the computation 2. no uses for a2 in the loop (a2 is used out of the loop) 3. no uses of a1 in the loop besides the reduction operation -end-- dump vect--- [local count: 955630225]: # maxInt_19 = PHI # maxIndex_20 = PHI # i_24 = PHI _1 = (long unsigned int) i_24; _2 = _1 * 4; _3 = src_13(D) + _2; _4 = *_3; maxInt_7 = MAX_EXPR <_4, maxInt_19>; -- reduction operation maxIndex_9 = _4 <= maxInt_19 ? maxIndex_20 : i_24; --- another use here. i_18 = i_24 + 1; if (n_15(D) > i_18) dump end- For the case in the PR, there's 2 uses for a1(maxInt_19), one in reduction operation(MAX_EXPR <_4, maxInt_19>), another in 4 <= maxInt_19 ? maxIndex_20 : i_24), and it failed.
[Bug tree-optimization/104579] New: vectorizer failed to reduce max & index search together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104579
Bug ID: 104579
Summary: vectorizer failed to reduce max & index search
together
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
int max (int *src, int n, int *position)
{
int maxInt;
int maxIndex;
int i;
maxInt = src[0];
maxIndex = 0;
for (i = 1; i < n; i++) {
if (maxInt < src[i]) {
maxInt = src[i];
maxIndex = i;
}
}
*position = maxIndex;
return (maxInt);
}
GCC can reduce max and index search separately, but not together.
[Bug target/103628] ICE: Segmentation fault (in gfc_conv_tree_to_mpfr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103628 --- Comment #2 from Arseny Solokha --- Indeed. Sorry. So could you cd flang/test/f90_correct/src and than invoke gfortran the following way instead: % powerpc-e300c3-linux-gnu-gfortran-12.0.1 -w -c check_mod.f90 qp54.f08 f951: internal compiler error: Segmentation fault 0xf264e6 crash_signal /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/toplev.cc:322 <…> ?
[Bug c++/104180] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104180 --- Comment #7 from Alexandre Oliva --- I've recommended before that, without any plan to implement consumers for this debug information, keeping it in place is mostly wasteful. AFAICT other debug stmts issued by front-ends could hit the same issue, but those are only theoretical IIRC. On the one hand, disabling the feature would hide the known problem that codegen is sensitive to such debug stmts, but on the other, we can cross that bridge if we get to it again.
[Bug c++/104539] Failed to inline a very simple template function when it's explicit instantiated.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104539 --- Comment #3 from Jason Merrill --- (In reply to Richard Biener from comment #2) > the explicit instantiation lacks COMDAT (but has comdat_group) and it > has forced_by_abi. > > I'm not sure the C++ standard calls out any semantic difference for > explicit vs. implicit instantiations but maybe the Itanium ABI does. The ABI says nothing about explicit vs. implicit instantiations. mark_decl_instantiated cleared DECL_COMDAT to fix PR10968, where we failed to emit an explicit instantiation. But that was before mark_needed; now that we have that, I'd think it makes sense to have DECL_COMDAT set on explicit instantiations just like implicit ones.
[Bug c++/104578] [12 Regression] accepts invalid partial template specialization, non-type template argument depends on a template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104578 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug c++/104578] New: [12 Regression] accepts invalid partial template specialization, non-type template argument depends on a template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104578
Bug ID: 104578
Summary: [12 Regression] accepts invalid partial template
specialization, non-type template argument depends on
a template parameter
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
While looking into PR 104567, I just happened upon some code which is rejected
by before GCC 12, MSVC, clang and ICC. I suspect it is invalid code as all
other compilers besides the trunk reject it for a similar reasons.
Take:
template
struct s{};
template
struct s<_TAny, _TAny::param>
{
typedef int type;
};
struct checked_type
{
static const int param = 0;
};
s::type t;
int main()
{
return t;
}
- CUT
clang reports:
:5:17: error: type of specialized non-type template argument depends on
a template parameter of the partial specialization
struct s<_TAny, _TAny::param>
^
:14:18: error: no type named 'type' in 's'
s::type t;
~^
MSVC reports:
(8): error C2753: 's<_TAny,_TAny::param>': partial specialization
cannot match argument list for primary template
ICC reports:
(5): error: the template argument list of the partial specialization
includes a nontype argument whose type depends on a template parameter
struct s<_TAny, _TAny::param>
^
GCC 11.2.0 reports:
:5:8: error: template argument '_TAny::param' involves template
parameter(s)
5 | struct s<_TAny, _TAny::param>
|^~
GCC 12 accepts this for all levels of the C++ standard.
[Bug c++/104577] New: needs copy constructor to call method of class non-type template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104577
Bug ID: 104577
Summary: needs copy constructor to call method of class
non-type template parameter
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: f.heckenb...@fh-soft.de
Target Milestone: ---
% cat test.cpp
struct S
{
constexpr S () = default;
S (S &&) = delete;
operator int () const { return 0; }
};
template int i = s;
int main ()
{
return i ;
}
% g++ -std=c++20 test.cpp
test.cpp:8:20: error: use of deleted function 'constexpr S::S(const S&)'
test.cpp:1:8: note: 'constexpr S::S(const S&)' is implicitly declared as
deleted because 'S' declares a move constructor or move assignment operator
I don't see why a copy constructor should be needed here. (clang accepts it.)
[Bug middle-end/63311] [9/10/11/12 Regression] -O1 optimization introduces valgrind warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63311 --- Comment #21 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:5fbcbcaff7248604e04b39464f4fbd64fbf6e43b commit r12-7270-g5fbcbcaff7248604e04b39464f4fbd64fbf6e43b Author: David Malcolm Date: Wed Feb 16 18:21:58 2022 -0500 analyzer: const functions have no side effects [PR104576] PR analyzer/104576 tracks that we issue a false positive from -Wanalyzer-use-of-uninitialized-value for the reproducers of PR 63311 when optimization is disabled. The root cause is that the analyzer was considering that a call to __builtin_sinf could have side-effects. This patch fixes things by generalizing the handling for "pure" functions to also consider "const" functions. gcc/analyzer/ChangeLog: PR analyzer/104576 * region-model.cc: Include "calls.h". (region_model::on_call_pre): Use flags_from_decl_or_type to generalize check for DECL_PURE_P to also check for ECF_CONST. gcc/testsuite/ChangeLog: PR analyzer/104576 * gcc.dg/analyzer/torture/uninit-pr63311.c: New test. * gcc.dg/analyzer/uninit-pr104576.c: New test. * gfortran.dg/analyzer/uninit-pr63311.f90: New test. Signed-off-by: David Malcolm
[Bug analyzer/104576] False positive from -Wanalyzer-use-of-uninitialized-value from PR 63311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104576 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:5fbcbcaff7248604e04b39464f4fbd64fbf6e43b commit r12-7270-g5fbcbcaff7248604e04b39464f4fbd64fbf6e43b Author: David Malcolm Date: Wed Feb 16 18:21:58 2022 -0500 analyzer: const functions have no side effects [PR104576] PR analyzer/104576 tracks that we issue a false positive from -Wanalyzer-use-of-uninitialized-value for the reproducers of PR 63311 when optimization is disabled. The root cause is that the analyzer was considering that a call to __builtin_sinf could have side-effects. This patch fixes things by generalizing the handling for "pure" functions to also consider "const" functions. gcc/analyzer/ChangeLog: PR analyzer/104576 * region-model.cc: Include "calls.h". (region_model::on_call_pre): Use flags_from_decl_or_type to generalize check for DECL_PURE_P to also check for ECF_CONST. gcc/testsuite/ChangeLog: PR analyzer/104576 * gcc.dg/analyzer/torture/uninit-pr63311.c: New test. * gcc.dg/analyzer/uninit-pr104576.c: New test. * gfortran.dg/analyzer/uninit-pr63311.f90: New test. Signed-off-by: David Malcolm
[Bug target/103623] [12 Regression] error: unable to generate reloads (ICE in curr_insn_transform, at lra-constraints.c:4132), or error: insn does not satisfy its constraints (ICE in extract_constrain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623 Kewen Lin changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org Status|REOPENED|ASSIGNED --- Comment #24 from Kewen Lin --- I'll take a further look into this one.
[Bug target/103353] Indefinite recursion when compiling -mmma requiring testcase w/ -maltivec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103353 Kewen Lin changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||linkw at gcc dot gnu.org Last reconfirmed||2022-02-17 Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org --- Comment #1 from Kewen Lin --- Confirmed.
[Bug analyzer/104560] False positive from -Wanalyzer-free-of-non-heap seen with rdma-core
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104560 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from David Malcolm --- Should be fixed by the above commit
[Bug analyzer/104560] False positive from -Wanalyzer-free-of-non-heap seen with rdma-core
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104560 --- Comment #1 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:a61aaee63848d422e8443e17bbec3257ee59d5d8 commit r12-7268-ga61aaee63848d422e8443e17bbec3257ee59d5d8 Author: David Malcolm Date: Wed Feb 16 09:06:46 2022 -0500 analyzer: fixes to free of non-heap detection [PR104560] PR analyzer/104560 reports various false positives from -Wanalyzer-free-of-non-heap seen with rdma-core, on what's effectively: free (>field) where in this case "field" is the first element of its struct, and thus >field == ptr, and could be on the heap. The root cause is due to malloc_state_machine::on_stmt making "LHS = " transition LHS from start to non_heap when EXPR is not a MEM_REF; this assumption doesn't hold for the above case. This patch eliminates that state transition, instead relying on malloc_state_machine::get_default_state to detect regions known to not be on the heap. Doing so fixes the false positive, but eliminates some events relating to free-of-alloca identifying the alloca, so the patch also reworks free_of_non_heap to capture which region has been freed, adding region creation events to diagnostic paths, so that the alloca calls can be identified, and using the memory space of the region for more precise wording of the diagnostic. The improvement to malloc_state_machine::get_default_state also means we now detect attempts to free VLAs, functions and code labels. In doing so I spotted that I wasn't adding region creation events for regions for global variables, and for cases where an allocation is the last stmt within its basic block, so the patch also fixes these issues. gcc/analyzer/ChangeLog: PR analyzer/104560 * diagnostic-manager.cc (diagnostic_manager::build_emission_path): Add region creation events for globals of interest. (null_assignment_sm_context::get_old_program_state): New. (diagnostic_manager::add_events_for_eedge): Move check for changing dynamic extents from PK_BEFORE_STMT case to after the switch on the dst_point's kind so that we can emit them for the final stmt in a basic block. * engine.cc (impl_sm_context::get_old_program_state): New. * sm-malloc.cc (malloc_state_machine::get_default_state): Rewrite detection of m_non_heap to use get_memory_space. (free_of_non_heap::free_of_non_heap): Add freed_reg param. (free_of_non_heap::subclass_equal_p): Update for changes to fields. (free_of_non_heap::emit): Drop m_kind in favor of get_memory_space. (free_of_non_heap::describe_state_change): Remove logic for detecting alloca. (free_of_non_heap::mark_interesting_stuff): Add region-creation of m_freed_reg. (free_of_non_heap::get_memory_space): New. (free_of_non_heap::kind): Drop enum. (free_of_non_heap::m_freed_reg): New field. (free_of_non_heap::m_kind): Drop field. (malloc_state_machine::on_stmt): Drop transition to m_non_heap. (malloc_state_machine::handle_free_of_non_heap): New function, split out from on_deallocator_call and on_realloc_call, adding detection of the freed region. (malloc_state_machine::on_deallocator_call): Use it. (malloc_state_machine::on_realloc_call): Likewise. * sm.h (sm_context::get_old_program_state): New vfunc. gcc/testsuite/ChangeLog: PR analyzer/104560 * g++.dg/analyzer/placement-new.C: Update expected wording. * g++.dg/analyzer/pr100244.C: Likewise. * gcc.dg/analyzer/attr-malloc-1.c (test_7): Likewise. * gcc.dg/analyzer/malloc-1.c (test_24): Likewise. (test_25): Likewise. (test_26): Likewise. (test_50a, test_50b, test_50c): New. * gcc.dg/analyzer/malloc-callbacks.c (test_5): Update expected wording. * gcc.dg/analyzer/malloc-paths-8.c: Likewise. * gcc.dg/analyzer/pr104560-1.c: New test. * gcc.dg/analyzer/pr104560-2.c: New test. * gcc.dg/analyzer/realloc-1.c (test_7): Updated expected wording. * gcc.dg/analyzer/vla-1.c (test_2): New. Prune output from -Wfree-nonheap-object. Signed-off-by: David Malcolm
[Bug bootstrap/104566] Internal compiler error in fail_formatted while building gcc from source while building GCC 11.2.0 with ubuntu's 7.5.0-3ubuntu1~18.04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104566 Andrew Pinski changed: What|Removed |Added Summary|Internal compiler error in |Internal compiler error in |fail_formatted while|fail_formatted while |building gcc from source|building gcc from source ||while building GCC 11.2.0 ||with ubuntu's ||7.5.0-3ubuntu1~18.04 Version|11.2.0 |7.5.0 --- Comment #1 from Andrew Pinski --- Hmm, Makefile:4779: recipe for target 'all-stage1-gcc' failed Since this is stage 1 that is failing, the bug is related to the pre-installed compiler and not really GCC 11 issue. Also can you provide the output of "env"? Maybe there is a locale set which is causing this failure.
[Bug c++/104567] SFINAE check failure with trying to access member field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104567 Andrew Pinski changed: What|Removed |Added Known to fail|4.1.2 |4.4.7 --- Comment #3 from Andrew Pinski --- Oh I forgot default template arguments for function calls only came to be part of C++11.
[Bug c++/104567] SFINAE check failure with trying to access member field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104567
Andrew Pinski changed:
What|Removed |Added
Keywords||rejects-valid
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Known to fail||4.1.2, 4.6.4
Last reconfirmed||2022-02-16
Summary|SFINAE check failure|SFINAE check failure with
|starting gcc 4.7.1 and up |trying to access member
|with -std=c++11 |field
--- Comment #2 from Andrew Pinski ---
Actually it has always failed.
Here is a C++98 testcase which shows the issue even with GCC 4.1.2:
template
bool has_char_static_param(int)
{ return true; }
template
bool has_char_static_param(...)
{ return false; }
struct checked_type
{
int param;
};
int main()
{
int t = has_char_static_param(0);
return t;
}
[Bug c++/104567] SFINAE check failure starting gcc 4.7.1 and up with -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104567 Andrew Pinski changed: What|Removed |Added URL|https://godbolt.org/z/eGc9s | |n6GM| --- Comment #1 from Andrew Pinski --- https://godbolt.org/z/eGc9sn6GM
[Bug analyzer/104576] False positive from -Wanalyzer-use-of-uninitialized-value from PR 63311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104576 --- Comment #1 from David Malcolm --- Potentially just a dup of PR analyzer/104434, but there might be additional issues with the reproducer.
[Bug middle-end/63311] [9/10/11/12 Regression] -O1 optimization introduces valgrind warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63311 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #20 from David Malcolm --- FWIW I tried running both reproducers with -fanalyzer (Fortran and C), and found that -fanalyzer generates false positives on them, which I'm tracking separately as PR analyzer/104576.
[Bug analyzer/104576] New: False positive from -Wanalyzer-use-of-uninitialized-value from PR 63311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104576 Bug ID: 104576 Summary: False positive from -Wanalyzer-use-of-uninitialized-value from PR 63311 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- The reproducers for PR 63311, both Fortran and C (attachment 33852) currently generate false positives from -Wanalyzer-use-of-uninitialized-value when optimization is off (and they are silent when optimization is on). It seems to be an issue with -fanalyzer thinking that __builtin_sinf could clobber *flag (which presumably it can't, being pure or const), thus allowing for the "flag is false" branch to skip initialization of t and tt, and then later executing the "flag is true" branch.
[Bug target/103628] ICE: Segmentation fault (in gfc_conv_tree_to_mpfr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103628 seurer at gcc dot gnu.org changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #1 from seurer at gcc dot gnu.org --- It took me a while to figure out where this test case is located (not being familiar with flang) but when I try to compile it I get an error message: flang/test/f90_correct/src/qp54.f08:7:7: 7 | use check_mod | 1 Fatal Error: Cannot open module file 'check_mod.mod' for reading at (1): No such file or directory I assume I am missing something?
[Bug tree-optimization/89479] __restrict on a pointer ignored when disambiguating against a call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89479 --- Comment #11 from Marc Nieper-Wißkirchen --- (In reply to Richard Biener from comment #1 of bug 94416) > I think there's a duplicate somewhere. We currently cannot encode "restrict" > into the "accesses" implied by a call. > > Note there's slight complication when g (b) eventually recurses into 'f' > passing this 'b' as 'a'. Recursion makes the interpretation of the > lexically defined restrict concept a bit weird. > > So I think this bug can be closed as duplicate of the "restrict and calls" > bug. > > *** This bug has been marked as a duplicate of bug 89479 *** What do you mean by that the restrict concept is lexically defined? If I read the standard correctly, restrict makes an assumption about the dynamic extent of an executed block. This seems obvious from section 6.7.3.1 (of ISO C18) which speaks of the block of main in paragraph 2 and the lifetime of objects in paragraph 5.
[Bug libstdc++/102358] niter_base and miter_base overloaded for move_iterator missing constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102358 Artur Bać changed: What|Removed |Added CC||gcc at ebasoft dot com.pl --- Comment #2 from Artur Bać --- I have spend 20min figuring out why std::copy fails compile at constexpr with libstdc++ only ;-) and it is already reported. "* include/bits/stl_iterator.h (__niter_base): Make constexpr for C++20." c++20 ? according to cppreference make_move_iterator is constexpr since c++17 https://en.cppreference.com/w/cpp/iterator/make_move_iterator
[Bug tree-optimization/89479] __restrict on a pointer ignored when disambiguating against a call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89479 Andrew Pinski changed: What|Removed |Added CC||m...@nieper-wisskirchen.de --- Comment #10 from Andrew Pinski --- *** Bug 104574 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/104574] GCC misses basic optimization for restricted pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104574 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 89479. *** This bug has been marked as a duplicate of bug 89479 ***
[Bug fortran/104211] ICE in find_array_section, at fortran/expr.cc:1720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104211 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |11.3 --- Comment #5 from anlauf at gcc dot gnu.org --- Fixed on mainline and applied to 11-branch. Closing. Thanks for the report!
[Bug fortran/104211] ICE in find_array_section, at fortran/expr.cc:1720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104211 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:3982a308e669cc5537322c83e8c2d49b0144297e commit r11-9579-g3982a308e669cc5537322c83e8c2d49b0144297e Author: Harald Anlauf Date: Thu Feb 10 21:22:48 2022 +0100 Fortran: improve error recovery on bad array section gcc/fortran/ChangeLog: PR fortran/104211 * expr.c (find_array_section): Replace assertion by error recovery when encountering bad array constructor. gcc/testsuite/ChangeLog: PR fortran/104211 * gfortran.dg/pr104211.f90: New test. (cherry picked from commit 19b517dff37b8e25f6babf8883483be73cad8fb3)
[Bug tree-optimization/104574] GCC misses basic optimization for restricted pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104574 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug fortran/104573] ICE in resolve_structure_cons, at fortran/resolve.cc:1299
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104573 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 --- Comment #7 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-February/057554.html
[Bug c++/94944] compile error accessing member function of dependent base class template in noexcept specification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94944 Andrew Pinski changed: What|Removed |Added CC||oliver.rosten at googlemail dot co ||m --- Comment #4 from Andrew Pinski --- *** Bug 104575 has been marked as a duplicate of this bug. ***
[Bug c++/104575] noexcept operator rejects call to templated base class member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104575 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 94944. *** This bug has been marked as a duplicate of bug 94944 ***
[Bug c++/104575] New: noexcept operator rejects call to templated base class member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104575
Bug ID: 104575
Summary: noexcept operator rejects call to templated base class
member function
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: oliver.rosten at googlemail dot com
Target Milestone: ---
struct Y
{
void swap(Y& rhs) noexcept {}
};
template
struct D : B
{
void swap(D& rhs) noexcept (noexcept(B::swap(rhs))) {}
};
struct E : Y
{
void swap(E& rhs) noexcept (noexcept(Y::swap(rhs))) {}
};
void foo()
{
D x{}, y{};
x.swap(y); // Rejected
E u{}, v{};
u.swap(v); // OK
}
---
error: cannot call member function 'void Y::swap(Y&)' without object
https://godbolt.org/z/E3P9MEd6z
[Bug fortran/104573] ICE in resolve_structure_cons, at fortran/resolve.cc:1299
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104573 --- Comment #6 from anlauf at gcc dot gnu.org --- The patch in comment#2 regtests ok. I've been thinking a little to find cases where there should be a difference to the patch in comment#1, but did not succeed so far. At least not with minor variations of the original testcases.
[Bug fortran/104573] ICE in resolve_structure_cons, at fortran/resolve.cc:1299
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104573 --- Comment #5 from Steve Kargl --- On Wed, Feb 16, 2022 at 08:32:25PM +, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104573 > > --- Comment #4 from anlauf at gcc dot gnu.org --- > (In reply to Steve Kargl from comment #3) > > I'm not sure. I don't use CLASSes, so only know a bit > > about them. If I check F18:7.5.6, I find > > > > C786 (R753) A final-subroutine-name shall be the name of a moduler > >procedure with exactly one dummy argument. That argument shall > >be nonoptional and shall be a noncoarray, nonpointer, nonallocatable, > >*** nonpolymorphic *** > >variable of the derived type being defined. All length type > >parameters of the dummy argument shall be assumed. The dummy > >argument shall not have the INTENT (OUT) or VALUE attribute. > > Steve, there's no finalization referred to in this PR. > Can you please recheck? > Ah dang. I conflated PR 104572, to which I just posted a patch, with this PR. Your patch is then likely the correct approach. Sorry about any confusion.
[Bug fortran/104573] ICE in resolve_structure_cons, at fortran/resolve.cc:1299
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104573 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to Steve Kargl from comment #3) > I'm not sure. I don't use CLASSes, so only know a bit > about them. If I check F18:7.5.6, I find > > C786 (R753) A final-subroutine-name shall be the name of a moduler >procedure with exactly one dummy argument. That argument shall >be nonoptional and shall be a noncoarray, nonpointer, nonallocatable, >*** nonpolymorphic *** >variable of the derived type being defined. All length type >parameters of the dummy argument shall be assumed. The dummy >argument shall not have the INTENT (OUT) or VALUE attribute. Steve, there's no finalization referred to in this PR. Can you please recheck?
[Bug fortran/104573] ICE in resolve_structure_cons, at fortran/resolve.cc:1299
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104573
--- Comment #3 from Steve Kargl ---
On Wed, Feb 16, 2022 at 08:10:34PM +, anlauf at gcc dot gnu.org wrote:
>
> I was wondering if we also need to allow BT_CLASS.
I'm not sure. I don't use CLASSes, so only know a bit
about them. If I check F18:7.5.6, I find
C786 (R753) A final-subroutine-name shall be the name of a moduler
procedure with exactly one dummy argument. That argument shall
be nonoptional and shall be a noncoarray, nonpointer, nonallocatable,
*** nonpolymorphic ***
variable of the derived type being defined. All length type
parameters of the dummy argument shall be assumed. The dummy
argument shall not have the INTENT (OUT) or VALUE attribute.
Does the highlighted "*** nonpolymorphic ***" eliminate
CLASS?
> So something like the following might also work:
>
> diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
> index 266e41e25b1..2fa1acdbd6d 100644
> --- a/gcc/fortran/resolve.cc
> +++ b/gcc/fortran/resolve.cc
> @@ -1288,15 +1288,17 @@ resolve_structure_cons (gfc_expr *expr, int init)
> }
> }
>
> - cons = gfc_constructor_first (expr->value.constructor);
> -
>/* A constructor may have references if it is the result of substituting a
> parameter variable. In this case we just pull out the component we
> want. */
>if (expr->ref)
> comp = expr->ref->u.c.sym->components;
> - else
> + else if (expr->ts.u.derived)
> comp = expr->ts.u.derived->components;
> + else
> +return false;
> +
> + cons = gfc_constructor_first (expr->value.constructor);
>
>for (; comp && cons; comp = comp->next, cons = gfc_constructor_next (cons))
> {
Your patch looks cleaner than mine. Once we decide on whether
CLASS can occur and if yours regression tests okay, then I
think you can commit. It's fairly obvious patch.
[Bug fortran/104573] ICE in resolve_structure_cons, at fortran/resolve.cc:1299
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104573
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> Only want to access the components of a derived type if we have an actual
> derived type.
I was wondering if we also need to allow BT_CLASS.
So something like the following might also work:
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 266e41e25b1..2fa1acdbd6d 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -1288,15 +1288,17 @@ resolve_structure_cons (gfc_expr *expr, int init)
}
}
- cons = gfc_constructor_first (expr->value.constructor);
-
/* A constructor may have references if it is the result of substituting a
parameter variable. In this case we just pull out the component we
want. */
if (expr->ref)
comp = expr->ref->u.c.sym->components;
- else
+ else if (expr->ts.u.derived)
comp = expr->ts.u.derived->components;
+ else
+return false;
+
+ cons = gfc_constructor_first (expr->value.constructor);
for (; comp && cons; comp = comp->next, cons = gfc_constructor_next (cons))
{
[Bug c++/104565] [10/11/12 Regression] constexpr template goes wrong with class and call to constexpr method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104565 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED Keywords|needs-bisection | Target Milestone|--- |10.4 CC||ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- Started with r10-7096. Another issue with non-dependent expression folding it seems.
[Bug fortran/104573] ICE in resolve_structure_cons, at fortran/resolve.cc:1299
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104573
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
CC||kargl at gcc dot gnu.org
Last reconfirmed||2022-02-16
--- Comment #1 from kargl at gcc dot gnu.org ---
Only want to access the components of a derived type if we have an actual
derived type.
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 835a4783718..ef274e05d4a 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -1296,7 +1296,7 @@ resolve_structure_cons (gfc_expr *expr, int init)
if (expr->ref)
comp = expr->ref->u.c.sym->components;
else
-comp = expr->ts.u.derived->components;
+comp = expr->ts.type == BT_DERIVED ? expr->ts.u.derived->components :
NULL;
for (; comp && cons; comp = comp->next, cons = gfc_constructor_next (cons))
{
[Bug target/104353] ppc64le: Apparent reliance on undefined behavior of xvcvdpsxws
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104353 --- Comment #2 from Christian Kastner --- Thank you for resolving this. Commenting just to link to to the QEMU issue in GitLab (which I do here, as "See Also" doesn't seem to support GitLab). https://gitlab.com/qemu-project/qemu/-/issues/852
[Bug fortran/104572] ICE in gfc_resolve_finalizers, at fortran/resolve.cc:13646
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104572
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Ever confirmed|0 |1
Last reconfirmed||2022-02-16
CC||kargl at gcc dot gnu.org
Status|UNCONFIRMED |NEW
--- Comment #1 from kargl at gcc dot gnu.org ---
Self explanatory.
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 835a4783718..1e7c3a07d0e 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -13643,6 +13653,13 @@ gfc_resolve_finalizers (gfc_symbol* derived, bool
*finalizable)
}
arg = dummy_args->sym;
+ if (!arg)
+ {
+ gfc_error ("Argument of FINAL procedure at %L cannot be an "
+"alternate return", >proc_sym->declared_at);
+ goto error;
+ }
+
/* This argument must be of our type. */
if (arg->ts.type != BT_DERIVED || arg->ts.u.derived != derived)
{
[Bug fortran/104571] ICE in resolve_elemental_actual, at fortran/resolve.cc:2383
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104571
kargl at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2022-02-16
Status|UNCONFIRMED |NEW
CC||kargl at gcc dot gnu.org
Ever confirmed|0 |1
Priority|P3 |P4
--- Comment #1 from kargl at gcc dot gnu.org ---
NULL pointer dereference.
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 835a4783718..83c895b079e 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -2380,8 +2382,9 @@ resolve_elemental_actual (gfc_expr *expr, gfc_code *c)
if (rank > 0 && esym && expr == NULL)
for (eformal = esym->formal, arg = arg0; arg && eformal;
arg = arg->next, eformal = eformal->next)
- if ((eformal->sym->attr.intent == INTENT_OUT
- || eformal->sym->attr.intent == INTENT_INOUT)
+ if (eformal->sym
+ && (eformal->sym->attr.intent == INTENT_OUT
+ || eformal->sym->attr.intent == INTENT_INOUT)
&& arg->expr && arg->expr->rank == 0)
{
gfc_error ("Actual argument at %L for INTENT(%s) dummy %qs of "
[Bug c++/104568] [10/11/12 Regression] ICE [c++20] caused by option "-std=c++20 -Wall" when operand of operator new has size equal to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104568 --- Comment #4 from Jakub Jelinek --- The code tries to compute how many elements an array with such element type should have, and obviously when the element size is zero, that doesn't work. Will need to figure out if the size can be derived from something else or is completely lost at that point, 0 * anything is 0 but even with zero element size we might need to know if p[0] or p[23] etc. is valid or not.
[Bug tree-optimization/104574] New: GCC misses basic optimization for restricted pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104574
Bug ID: 104574
Summary: GCC misses basic optimization for restricted pointers
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: m...@nieper-wisskirchen.de
Target Milestone: ---
The following TU
void g (void);
int
f (int *restrict p)
{
p[0] = 7;
g ();
return p[0];
}
is compiled by GCC at -O3 to
f:
pushq %rbx
movq%rdi, %rbx
movl$7, (%rdi)
callg
movl(%rbx), %eax
popq%rbx
ret
Obviously, GCC seems to think that g may modify the data reachable through p.
However, if g did that it would cause undefined behavior anyway.
So GCC misses a simple optimization opportunity here; it doesn't have to reload
the memory contents after the call to g; in fact, the function will always
return 7.
For comparison, Clang compiles the TU to
f:
pushq %rax
movl$7, (%rdi)
callq g
movl$7, %eax
popq%rcx
retq
[Bug c++/104568] [10/11/12 Regression] ICE [c++20] caused by option "-std=c++20 -Wall" when operand of operator new has size equal to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104568
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Make it
typedef int T[0];
constexpr bool
foo ()
{
auto p = new T[0];
delete p;
return true;
}
constexpr bool a = foo ();
so that it is constant evaluated always, doesn't need -Wall then, just
-std=c++20 or -std=c++23.
[Bug c++/104568] [10/11/12 Regression] ICE [c++20] caused by option "-std=c++20 -Wall" when operand of operator new has size equal to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104568 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=91369 --- Comment #2 from Andrew Pinski --- I suspect the implementation of P0784R7 which was done as PR 91369 introduced this ICE.
[Bug c++/104568] [10/11/12 Regression] ICE [c++20] caused by option "-std=c++20 -Wall" when operand of operator new has size equal to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104568 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection, ||needs-reduction Ever confirmed|0 |1 Summary|ICE [c++20] caused by |[10/11/12 Regression] ICE |option "-std=c++20 -Wall" |[c++20] caused by option |when operand of operator|"-std=c++20 -Wall" when |new has size equal to 0 |operand of operator new has ||size equal to 0 Target Milestone|--- |10.4 Last reconfirmed||2022-02-16 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- The error-recovery issue (without -Wall) is gone in 11.2.0.
[Bug c++/104507] [10/11 Regression] internal compiler error: unexpected expression ‘(int)(__ret)’ of kind cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104507 Patrick Palka changed: What|Removed |Added Summary|[10/11/12 Regression] |[10/11 Regression] internal |internal compiler error:|compiler error: unexpected |unexpected expression |expression ‘(int)(__ret)’ |‘(int)(__ret)’ of kind |of kind cast_expr |cast_expr | --- Comment #8 from Patrick Palka --- Fixed for GCC 12 so far.
[Bug c++/104507] [10/11/12 Regression] internal compiler error: unexpected expression ‘(int)(__ret)’ of kind cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104507 --- Comment #7 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:c19f317a78c0e4c1b51d0e5a8e4c0a3b985b7a8e commit r12-7264-gc19f317a78c0e4c1b51d0e5a8e4c0a3b985b7a8e Author: Patrick Palka Date: Wed Feb 16 12:41:35 2022 -0500 c++: treat NON_DEPENDENT_EXPR as not potentially constant [PR104507] Here we're crashing from potential_constant_expression because it tries to perform trial evaluation of the first operand '(bool)__r' of the conjunction (which is overall wrapped in a NON_DEPENDENT_EXPR), but cxx_eval_constant_expression ICEs on unsupported trees (of which CAST_EXPR is one). The sequence of events is: 1. build_non_dependent_expr for the array subscript yields NON_DEPENDENT_EXPR<<<(bool)__r && __s>>> ? 1 : 2 2. cp_build_array_ref calls fold_non_dependent_expr on this subscript (after this point, processing_template_decl is cleared) 3. during which, the COND_EXPR case of tsubst_copy_and_build calls fold_non_dependent_expr on the first operand 4. during which, we crash from p_c_e_1 because it attempts trial evaluation of the CAST_EXPR '(bool)__r'. Note that even if this crash didn't happen, fold_non_dependent_expr from cp_build_array_ref would still ultimately be one big no-op here since neither constexpr evaluation nor tsubst handle NON_DEPENDENT_EXPR. In light of this and of the observation that we should never see NON_DEPENDENT_EXPR in a context where a constant expression is needed (it's used primarily in the build_x_* family of functions), it seems futile for p_c_e_1 to ever return true for NON_DEPENDENT_EXPR. And the otherwise inconsistent handling of NON_DEPENDENT_EXPR between p_c_e_1, cxx_evaluate_constexpr_expression and tsubst apparently leads to weird bugs such as this one. PR c++/104507 gcc/cp/ChangeLog: * constexpr.cc (potential_constant_expression_1) : Return false instead of recursing. Assert tf_error isn't set. gcc/testsuite/ChangeLog: * g++.dg/template/non-dependent21.C: New test.
[Bug tree-optimization/104200] [12 Regression] FAIL: gcc.target/aarch64/atomic-inst-cas.c (test for excess errors) fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104200 --- Comment #5 from Andrew Pinski --- Maybe waccess should do a similar thing to uninitialized warnings does now: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/589983.html
[Bug fortran/104573] New: ICE in resolve_structure_cons, at fortran/resolve.cc:1299
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104573 Bug ID: 104573 Summary: ICE in resolve_structure_cons, at fortran/resolve.cc:1299 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: --- Affects versions down to at least r5 : (gcc configured with --enable-checking=yes) $ cat z1.f90 program p type t end type type(*), parameter :: x = t() print *, x end $ cat z2.f90 program p type t integer :: n end type type(*), parameter :: x = t(1) print *, x end $ gfortran-12-20220213 -c z1.f90 z1.f90:4:26: 4 |type(*), parameter :: x = t() | 1 Error: Assumed type of variable x at (1) is only permitted for dummy variables z1.f90:4:28: 4 |type(*), parameter :: x = t() |1 Error: Cannot convert TYPE(t) to TYPE(*) at (1) f951: internal compiler error: Segmentation fault 0xe7073f crash_signal ../../gcc/toplev.cc:322 0x7b30e4 resolve_structure_cons ../../gcc/fortran/resolve.cc:1299 0x7a0c91 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.cc:7228 0x7a9324 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.cc:7136 0x7a9324 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.cc:11927 0x7a7cdf gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.cc:10943 0x7a8038 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.cc:11917 0x7aa977 resolve_codes ../../gcc/fortran/resolve.cc:17536 0x7aaa3e gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.cc:17571 0x792d64 resolve_all_program_units ../../gcc/fortran/parse.cc:6586 0x792d64 gfc_parse_file() ../../gcc/fortran/parse.cc:6842 0x7e102f gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:216
[Bug fortran/104572] New: ICE in gfc_resolve_finalizers, at fortran/resolve.cc:13646
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104572 Bug ID: 104572 Summary: ICE in gfc_resolve_finalizers, at fortran/resolve.cc:13646 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: --- Affects versions down to at least r5 : $ cat z1.f90 module m type t contains final :: s end type contains subroutine s(*) end end $ gfortran-12-20220213 -c z1.f90 f951: internal compiler error: Segmentation fault 0xcc8a9f crash_signal ../../gcc/toplev.cc:322 0x75abf3 gfc_resolve_finalizers ../../gcc/fortran/resolve.cc:13646 0x7726fd resolve_fl_derived ../../gcc/fortran/resolve.cc:15112 0x76c1f7 resolve_symbol ../../gcc/fortran/resolve.cc:15504 0x78b442 do_traverse_symtree ../../gcc/fortran/symbol.cc:4174 0x76f7a4 resolve_types ../../gcc/fortran/resolve.cc:17454 0x76ac3c gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.cc:17569 0x752d72 gfc_parse_file() ../../gcc/fortran/parse.cc:6792 0x7a066f gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:216
[Bug fortran/104571] New: ICE in resolve_elemental_actual, at fortran/resolve.cc:2383
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104571 Bug ID: 104571 Summary: ICE in resolve_elemental_actual, at fortran/resolve.cc:2383 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: --- Affects versions down to at least r5 : (gcc configured with --enable-checking=yes) $ cat z1.f90 program p real :: x(3) call g(x) contains elemental subroutine g(*) end end $ gfortran-12-20220213 -c z1.f90 z1.f90:5:25: 5 |elemental subroutine g(*) | 1 Error: Alternate return specifier in elemental subroutine 'g' at (1) is not allowed z1.f90:3:12: 3 |call g(x) |1 Error: Missing alternate return specifier in subroutine call at (1) f951: internal compiler error: Segmentation fault 0xe7073f crash_signal ../../gcc/toplev.cc:322 0x79bd73 resolve_elemental_actual ../../gcc/fortran/resolve.cc:2383 0x7ab0bb resolve_call ../../gcc/fortran/resolve.cc:3805 0x7a8449 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.cc:12154 0x7aa977 resolve_codes ../../gcc/fortran/resolve.cc:17536 0x7aaa3e gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.cc:17571 0x792d64 resolve_all_program_units ../../gcc/fortran/parse.cc:6586 0x792d64 gfc_parse_file() ../../gcc/fortran/parse.cc:6842 0x7e102f gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:216
[Bug fortran/104570] [12 Regression] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.cc:3681
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104570 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #1 from G. Steinmetz --- Please note, no ICE with these variants : $ cat z3.f90 program p character(:), allocatable :: x(:) x = ['abc'] call s contains subroutine s associate (y => x) associate (z => y) print *, z end associate end associate end end $ cat z4.f90 program p character(:), allocatable :: x(:) call s contains subroutine s associate (y => x) associate (z => y) print *, z end associate end associate end end $ cat z5.f90 program p character(3) :: x(2) call s contains subroutine s associate (y => x) associate (z => (y)) print *, z end associate end associate end end $ cat z6.f90 program p character, allocatable :: x(:) call s contains subroutine s associate (y => x) associate (z => (y)) print *, z end associate end associate end end $ cat z7.f90 program p character, allocatable :: x(:) x = ['a'] call s contains subroutine s associate (y => x) associate (z => (y)) print *, z end associate end associate end end
[Bug fortran/104570] New: [12 Regression] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.cc:3681
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104570 Bug ID: 104570 Summary: [12 Regression] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.cc:3681 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: --- Changed recently between 20220206 and 20220213 : $ cat z1.f90 program p character(:), allocatable :: x(:) x = ['abc'] call s contains subroutine s associate (y => x) associate (z => (y)) print *, z end associate end associate end end $ gfortran-12-20220213 -c z1.f90 z1.f90:9:22: 9 | print *, z | 1 internal compiler error: Segmentation fault 0xcc8a9f crash_signal ../../gcc/toplev.cc:322 0x7ac696 gfc_conv_scalarized_array_ref ../../gcc/fortran/trans-array.cc:3681 0x7ad18c gfc_conv_array_ref(gfc_se*, gfc_array_ref*, gfc_expr*, locus*) ../../gcc/fortran/trans-array.cc:3832 0x7dc19e gfc_conv_variable ../../gcc/fortran/trans-expr.cc:3097 0x7d857a gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.cc:9406 0x7dc779 gfc_conv_string_length(gfc_charlen*, gfc_expr*, stmtblock_t*) ../../gcc/fortran/trans-expr.cc:2551 0x7b7877 get_array_charlen ../../gcc/fortran/trans-array.cc:7353 0x7b798e get_array_charlen ../../gcc/fortran/trans-array.cc:7280 0x7b6d96 gfc_conv_expr_descriptor(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-array.cc:7680 0x81c9da trans_associate_var ../../gcc/fortran/trans-stmt.cc:1918 0x823761 gfc_trans_block_construct(gfc_code*) ../../gcc/fortran/trans-stmt.cc:2312 0x7a76e7 trans_code ../../gcc/fortran/trans.cc:2012 0x8236ef gfc_trans_block_construct(gfc_code*) ../../gcc/fortran/trans-stmt.cc:2305 0x7a76e7 trans_code ../../gcc/fortran/trans.cc:2012 0x7d093e gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:7654 0x7d076c gfc_generate_contained_functions ../../gcc/fortran/trans-decl.cc:5777 0x7d076c gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:7586 0x75367e translate_all_program_units ../../gcc/fortran/parse.cc:6651 0x75367e gfc_parse_file() ../../gcc/fortran/parse.cc:6938 0x7a066f gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:216
[Bug fortran/104569] New: ICE in generate_coarray_sym_init, at fortran/trans-decl.cc:5537
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104569 Bug ID: 104569 Summary: ICE in generate_coarray_sym_init, at fortran/trans-decl.cc:5537 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: --- Affects versions down to r7 : $ cat z1.f90 program p character :: x(2)[*] call s contains subroutine s associate (y => x) y = 'a' end associate end end $ cat z2.f90 program p character(3) :: x(2)[*] call s contains subroutine s associate (y => x) y = 'abc' end associate end end $ cat z3.f90 program p character :: x(2)[*] associate (y => x) y = 'a' end associate end $ gfortran-12-20220213 -c z1.f90 -fcoarray=single $ $ gfortran-12-20220213 -c z1.f90 -fcoarray=lib z1.f90:6:24: 6 | associate (y => x) |1 internal compiler error: in generate_coarray_sym_init, at fortran/trans-decl.cc:5537 0x7c2f32 generate_coarray_sym_init ../../gcc/fortran/trans-decl.cc:5537 0x78b442 do_traverse_symtree ../../gcc/fortran/symbol.cc:4174 0x7c2185 generate_coarray_init ../../gcc/fortran/trans-decl.cc:5685 0x7c7210 gfc_process_block_locals(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:7943 0x8236b9 gfc_trans_block_construct(gfc_code*) ../../gcc/fortran/trans-stmt.cc:2296 0x7a76e7 trans_code ../../gcc/fortran/trans.cc:2012 0x7d093e gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:7654 0x7d076c gfc_generate_contained_functions ../../gcc/fortran/trans-decl.cc:5777 0x7d076c gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:7586 0x75367e translate_all_program_units ../../gcc/fortran/parse.cc:6651 0x75367e gfc_parse_file() ../../gcc/fortran/parse.cc:6938 0x7a066f gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:216
[Bug c++/104565] [10/11/12 Regression] constexpr template goes wrong with class and call to constexpr method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104565 Andrew Pinski changed: What|Removed |Added Summary|[10/11/12 Regression] One |[10/11/12 Regression] |too many `this`es in|constexpr template goes |parsing?|wrong with class and call ||to constexpr method Keywords||needs-bisection Last reconfirmed||2022-02-16 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 102006, which changed state. Bug 102006 Summary: A false warning "Array subscript -N is outside array bounds warning" https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102006 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug tree-optimization/102006] A false warning "Array subscript -N is outside array bounds warning"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102006 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #12 from Martin Sebor --- Thanks for letting us know. Resolving as invalid then.
[Bug c++/104565] [10/11/12 Regression] One too many `this`es in parsing?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104565 Andrew Pinski changed: What|Removed |Added Blocks||55004 Keywords||rejects-valid Summary|One too many `this`es in|[10/11/12 Regression] One |parsing?|too many `this`es in ||parsing? URL|https://stackoverflow.com/q | |uestions/71135361/taking-ad | |dress-of-rvalue | --- Comment #1 from Andrew Pinski --- https://stackoverflow.com/questions/71135361/taking-address-of-rvalue Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 [Bug 55004] [meta-bug] constexpr issues
[Bug middle-end/104550] bogus warning from -Wuninitialized + -ftrivial-auto-var-init=pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550 --- Comment #11 from qinzhao at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #10) > Even in that case, filling the memory with pattern & mask instead of filling > the memory with pattern + __builtin_clear_padding afterwards seems like a > win. So, you mean It's better to do the following for pattern init: 1. add call to .DEFERRED_INIT(, pattern, ) during gimplification; 2. during RTL expansion, fill the memory with pattern & mask if the variable is in memory. how to implement "fill the memory with pattern & mask" during RTL expansion? currently, we use memset to fill the memory when the variable is in memory, pattern & mask might not fit to a BYTE-repeatable pattern that can be used for memset?
[Bug middle-end/104550] bogus warning from -Wuninitialized + -ftrivial-auto-var-init=pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550 --- Comment #10 from Jakub Jelinek --- Even in that case, filling the memory with pattern & mask instead of filling the memory with pattern + __builtin_clear_padding afterwards seems like a win. Sure, in some cases combine etc. will be able to merge those back, but in many cases it won't.
[Bug middle-end/104550] bogus warning from -Wuninitialized + -ftrivial-auto-var-init=pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550 --- Comment #9 from qinzhao at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #8) > Well, for the .DEFERRED_INIT case if the var ends up in memory, I really > don't see the point in any clear_padding, .DEFERRED_INIT expansion should > just initialize the whole DECL_RTL MEM_P slot with the pattern it wants, > trying to initialize only the non-padding bits and then only the padding > bits next to each other is a waste of CPU cycles. __builtin_clear_padding is ONLY emitted for pattern init to set the paddings to zero. for zero init, the .DEFERRED_INIT expansion should block set all the memory to zero already. no __builtin_clear_padding is added for zero init. that's the reason why this bug is only exposed with -ftrivial-auto-var-init=pattern
[Bug target/104462] ICE: in extract_constrain_insn_cached, at recog.cc:2682 with -mavx512fp16 -mno-xsave
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104462 --- Comment #5 from Jakub Jelinek --- *** Bug 104448 has been marked as a duplicate of this bug. ***
[Bug target/104448] [10/11/12 Regression] ICE: in initialize, at function-abi.cc:108 with -mavx5124vnniw / -mavx5124fmaps -mno-xsave -mabi=ms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104448 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Jakub Jelinek --- Dup then. *** This bug has been marked as a duplicate of bug 104462 ***
[Bug target/104448] [10/11/12 Regression] ICE: in initialize, at function-abi.cc:108 with -mavx5124vnniw / -mavx5124fmaps -mno-xsave -mabi=ms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104448 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f9c4917f01692a10f122f5ad56e559ba27751ace commit r12-7263-gf9c4917f01692a10f122f5ad56e559ba27751ace Author: Jakub Jelinek Date: Wed Feb 16 17:03:58 2022 +0100 testsuite: Add testcase for already fixed PR [PR104448] This PR has been fixed with r12-7147-g2f9ab267e725ddf2. 2022-02-16 Jakub Jelinek PR target/104448 * gcc.target/i386/pr104448.c: New test.
[Bug c++/104568] New: ICE [regression c++20] caused by option "-std=c++20 -Wall" when operand of operator new has size equal to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104568
Bug ID: 104568
Summary: ICE [regression c++20] caused by option "-std=c++20
-Wall" when operand of operator new has size equal to
0
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
See the following program causes ICE with flag ONLY of "-std=c++20 -Wall" which
proves it to be a regression of c++20.
The root cause is very simple that "std::default_delete" has a static_assert to
require element size pointed by pointer to be bigger than 0. A empty array of
"int[0]" violates this assertion, all other flag gives the correct root cause
without crash. However, "-std=c++20 -Wall" option issues very confusing error
message "Floating point exception" and crashes.
#include
using namespace std;
typedef int Ary0[0];
int main(){
unique_ptr ptr;
ptr.reset(new Ary0[0]);
return 0;
}
tests/unique.cpp: In function ‘int main()’:
tests/unique.cpp:7:18: internal compiler error: Floating point exception
7 | ptr.reset(new Ary0[0]);
| ~^
0x1522a90 crash_signal
/home/nick/Downloads/gcc-dev/gcc/gcc/toplev.cc:322
0xbd4829 build_new_constexpr_heap_type(tree_node*, tree_node*, tree_node*)
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/init.cc:2944
0xb2f837 cxx_eval_constant_expression
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/constexpr.cc:7262
0xb2f1cf cxx_eval_constant_expression
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/constexpr.cc:7147
0xb30dd1 cxx_eval_outermost_constant_expr
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/constexpr.cc:7700
0xb319d2 maybe_constant_value(tree_node*, tree_node*, bool)
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/constexpr.cc:7990
0xbcbd84 fold_for_warn(tree_node*)
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/expr.cc:416
0xddaed6 check_function_restrict
/home/nick/Downloads/gcc-dev/gcc/gcc/c-family/c-common.cc:5704
0xddc1d9 check_function_arguments(unsigned int, tree_node const*, tree_node
const*, int, tree_node**, vec*)
/home/nick/Downloads/gcc-dev/gcc/gcc/c-family/c-common.cc:6091
0xaf16fe build_over_call
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/call.cc:9662
0xaf5a03 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/call.cc:11146
0xc70cd6 cp_parser_postfix_expression
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/parser.cc:7844
0xc73625 cp_parser_unary_expression
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/parser.cc:9033
0xc74c64 cp_parser_cast_expression
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/parser.cc:9937
0xc74d82 cp_parser_binary_expression
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/parser.cc:10039
0xc75b61 cp_parser_assignment_expression
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/parser.cc:10343
0xc75ec3 cp_parser_expression
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/parser.cc:10513
0xc7adb5 cp_parser_expression_statement
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/parser.cc:12709
0xc7a795 cp_parser_statement
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/parser.cc:12505
0xc7b23c cp_parser_statement_seq_opt
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/parser.cc:12854
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/104448] [10/11/12 Regression] ICE: in initialize, at function-abi.cc:108 with -mavx5124vnniw / -mavx5124fmaps -mno-xsave -mabi=ms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104448 --- Comment #3 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #2) > r12-7147-g2f9ab267e725ddf2b6b44113e4fc4fb8b2a6adfb fixed this. > So, shall we just add the testcase into the testsuite and be done with it? I think so. -mno-xsave disabled AVX support and left AVX2+ enabled, which is impossible combination.
[Bug target/104448] [10/11/12 Regression] ICE: in initialize, at function-abi.cc:108 with -mavx5124vnniw / -mavx5124fmaps -mno-xsave -mabi=ms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104448 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||uros at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- r12-7147-g2f9ab267e725ddf2b6b44113e4fc4fb8b2a6adfb fixed this. So, shall we just add the testcase into the testsuite and be done with it?
[Bug target/104353] ppc64le: Apparent reliance on undefined behavior of xvcvdpsxws
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104353 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Segher Boessenkool --- This is not a bug. Please read the second programming note for xvcvdpsxws in ISA 3.1: Previous versions of the architecture allowed the contents of words 1 and 3 of the result register to be undefined. However, all processors that support this instruction write the result into words 0 and 1 and words 2 and 3 of the result register, as is required by this version of the architecture. It sounds like QEMU needs fixing to behave like all hardware does?
[Bug middle-end/104550] bogus warning from -Wuninitialized + -ftrivial-auto-var-init=pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- Well, for the .DEFERRED_INIT case if the var ends up in memory, I really don't see the point in any clear_padding, .DEFERRED_INIT expansion should just initialize the whole DECL_RTL MEM_P slot with the pattern it wants, trying to initialize only the non-padding bits and then only the padding bits next to each other is a waste of CPU cycles. Another case are C++ vars with non-trivial ctors, if we for -flifetime-dse=2 emit CLOBBERs at the start of such ctors, then IMNSHO the right thing is to emit the zero or pattern initialization in those constructors, perhaps through .DEFERRED_INIT. This is the start_preparsed_function if (!processing_template_decl && (flag_lifetime_dse > 1) && DECL_CONSTRUCTOR_P (decl1) && !DECL_CLONED_FUNCTION_P (decl1) /* Clobbering an empty base is harmful if it overlays real data. */ && !is_empty_class (current_class_type) /* We can't clobber safely for an implicitly-defined default constructor because part of the initialization might happen before we enter the constructor, via AGGR_INIT_ZERO_FIRST (c++/68006). */ && !implicit_default_ctor_p (decl1)) finish_expr_stmt (build_clobber_this ()); case. Advantage of doing it in the ctor is that if it isn't inlined, it is done just once per type, doesn't need to be duplicated in all the spots that use it. Of course, if the above conditions aren't met, then it still needs to be initialized somewhere else like where it is done currently, or for the case of vars with constructors for which we don't emit it perhaps do __builtin_clear_padding after the constructor (but can we be sure that the ctor hasn't e.g. performed placement new and built in itself some other class?). Anyway, doing __builtin_clear_padding at RTL expansion time might be non-trivial. One thing we still haven't decided on what to do with the virtual inheritance, whether we need a langhook which won't be there at expansion time, or if we can just use binfo (but doesn't free_lang_data mess up with binfo too)? And right now the code has two main possibilities, either emit gimple code to do the clearing, or set a padding bitmask in memory. For RTL, either one could use the latter and turn that into RTL code clearing, or we would need a third mode in which it would be emitting RTL directly. Emitting such code early has the advantage of store-merging and all kinds of other optimizations though...
[Bug middle-end/104550] bogus warning from -Wuninitialized + -ftrivial-auto-var-init=pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550 --- Comment #7 from qinzhao at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #6) > > --- Comment #4 from Andrew Pinski --- > > Maybe __builtin_clear_padding lowering should mark the load "MEM[(struct > > vx_audio_level *)]" as not needing a warning. > > Maybe padding clearing shouldn’t be exposed early but handled by > .DEFFEREd_INIT expansion? > If padding clearing is exposed too late till RTL expansion, some tree optimization will not be able to be applied on the expanded stores? the approach to mark the load "MEM" as not needing a warning might be better?
[Bug tree-optimization/104475] [12 Regression] Wstringop-overflow + atomics incorrect warning on dynamic object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104475 Jakub Jelinek changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I'm afraid the amount of code in the wild that assumes that >first_member == NULL for ptr == NULL is huge in real-world code, so I'm not sure if we can afford to fold such comparisons to false. But perhaps the threader shouldn't thread such paths because we should consider them extremely unlikely.
[Bug c++/104567] New: SFINAE check failure starting gcc 4.7.1 and up with -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104567
Bug ID: 104567
Summary: SFINAE check failure starting gcc 4.7.1 and up with
-std=c++11
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: armenchik at mail dot ru
Target Milestone: ---
template
constexpr bool has_char_static_param(int)
{ return true; }
template
constexpr bool has_char_static_param(...)
{ return false; }
struct checked_type
{
constexpr static char param[] = "param"; // <- everything works fine
//constexpr static int param = 0; // <- sfinae works fine, fails static
assert
//int param; // <- sfinae fails! reporting error during param substitution
//char const* param; // <- sfinae fails again as above
};
int main()
{
static_assert(has_char_static_param(0), "check failed");
return 0;
}
[Bug tree-optimization/104526] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104526 --- Comment #8 from Jakub Jelinek --- LGTM, thanks.
[Bug tree-optimization/104526] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104526 --- Comment #7 from Andrew Macleod --- On 2/16/22 07:39, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104526 > > --- Comment #6 from Jakub Jelinek --- > + tree type = TREE_TYPE (TREE_OPERAND (cond, 0)); > + if (type != TREE_TYPE (TREE_OPERAND (cond, 1))) > +return false; > looks unnecessarily restrictive. > What tree-cfg.cc verification guarantees (and no need to check it in the > ranger) > is what verify_gimple_comparison verifies, i.e. that >/* For comparisons we do not have the operations type as the > effective type the comparison is carried out in. Instead > we require that either the first operand is trivially > convertible into the second, or the other way around. */ >if (!useless_type_conversion_p (op0_type, op1_type) >&& !useless_type_conversion_p (op1_type, op0_type)) > I think the ranger has to be prepared for non-pointer-equal type mismatches as > long as they are useless_type_conversion_p compatible, that can happen > anywhere > in the IL, including even cases like different but useless_type_conversion_p > compatible types of binary operators like +, -, * etc. > So I'd just remove the >if (type != TREE_TYPE (TREE_OPERAND (cond, 1))) > return false; > lines. The rest of ranger isn't this restrictive.. it is satisfied by range_compatable_p() which boils down to "same precision, same sign". I added it here so to be super paranoid so I didn't get caught by something unexpected later in the routine and cause an ICE in intersect in the middle of building the kernel or something. In hindsight, I should have used range_compatible_p... Are you OK with the following change? I'll bootstrap and regression test... Andrew
[Bug target/103925] Missing int3 in ix86_output_indirect_function_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103925 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by H.J. Lu : https://gcc.gnu.org/g:978956485a663493130b02f787095095d163290e commit r11-9578-g978956485a663493130b02f787095095d163290e Author: H.J. Lu Date: Wed Jan 5 18:04:21 2022 -0800 x86: Generate INT3 for __builtin_eh_return Generate INT3 after indirect jmp in exception return for -fcf-protection with -mharden-sls=indirect-jmp. gcc/ PR target/103925 * config/i386/i386.c (ix86_output_indirect_function_return): Generate INT3 after indirect jmp for -mharden-sls=indirect-jmp. gcc/testsuite/ PR target/103925 * gcc.target/i386/harden-sls-6.c: New test. (cherry picked from commit c2e5c4feed32c808591b5278f680bbabe63eb225)
[Bug target/102952] New code-gen options for retpolines and straight line speculation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102952 --- Comment #43 from CVS Commits --- The releases/gcc-11 branch has been updated by H.J. Lu : https://gcc.gnu.org/g:58a4e292e8507a2968bfd2b10631ba95d5440c97 commit r11-9577-g58a4e292e8507a2968bfd2b10631ba95d5440c97 Author: H.J. Lu Date: Wed Jan 5 16:33:16 2022 -0800 x86: Rename -harden-sls=indirect-branch to -harden-sls=indirect-jmp Indirect branch also includes indirect call instructions. Rename -harden-sls=indirect-branch to -harden-sls=indirect-jmp to match its intended behavior. PR target/102952 * config/i386/i386-opts.h (harden_sls): Replace harden_sls_indirect_branch with harden_sls_indirect_jmp. * config/i386/i386.c (ix86_output_jmp_thunk_or_indirect): Likewise. (ix86_output_indirect_jmp): Likewise. (ix86_output_call_insn): Likewise. * config/i386/i386.opt: Replace indirect-branch with indirect-jmp. Replace harden_sls_indirect_branch with harden_sls_indirect_jmp. * doc/invoke.texi (-harden-sls=): Replace indirect-branch with indirect-jmp. (cherry picked from commit ed8060950c64f2e449aaf90e438aa26d0d9d0b31)
[Bug target/102952] New code-gen options for retpolines and straight line speculation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102952 --- Comment #42 from CVS Commits --- The releases/gcc-11 branch has been updated by H.J. Lu : https://gcc.gnu.org/g:5d928740a533cd9e78673fad7ea86d20b2142277 commit r11-9576-g5d928740a533cd9e78673fad7ea86d20b2142277 Author: H.J. Lu Date: Wed Oct 27 06:27:15 2021 -0700 x86: Add -mindirect-branch-cs-prefix Add -mindirect-branch-cs-prefix to add CS prefix to call and jmp to indirect thunk with branch target in r8-r15 registers so that the call and jmp instruction length is 6 bytes to allow them to be replaced with "lfence; call *%r8-r15" or "lfence; jmp *%r8-r15" at run-time. gcc/ PR target/102952 * config/i386/i386.c (ix86_output_jmp_thunk_or_indirect): Emit CS prefix for -mindirect-branch-cs-prefix. (ix86_output_indirect_branch_via_reg): Likewise. * config/i386/i386.opt: Add -mindirect-branch-cs-prefix. * doc/invoke.texi: Document -mindirect-branch-cs-prefix. gcc/testsuite/ PR target/102952 * gcc.target/i386/indirect-thunk-cs-prefix-1.c: New test. * gcc.target/i386/indirect-thunk-cs-prefix-2.c: Likewise. (cherry picked from commit 2196a681d7810ad8b227bf983f38ba716620545e)
[Bug target/102952] New code-gen options for retpolines and straight line speculation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102952 --- Comment #41 from CVS Commits --- The releases/gcc-11 branch has been updated by H.J. Lu : https://gcc.gnu.org/g:39d944c4237e5d35e28a2668d3b9a2e0f6f7bd01 commit r11-9575-g39d944c4237e5d35e28a2668d3b9a2e0f6f7bd01 Author: H.J. Lu Date: Wed Oct 27 07:48:54 2021 -0700 x86: Add -mharden-sls=[none|all|return|indirect-branch] Add -mharden-sls= to mitigate against straight line speculation (SLS) for function return and indirect branch by adding an INT3 instruction after function return and indirect branch. gcc/ PR target/102952 * config/i386/i386-opts.h (harden_sls): New enum. * config/i386/i386.c (output_indirect_thunk): Mitigate against SLS for function return. (ix86_output_function_return): Likewise. (ix86_output_jmp_thunk_or_indirect): Mitigate against indirect branch. (ix86_output_indirect_jmp): Likewise. (ix86_output_call_insn): Likewise. * config/i386/i386.opt: Add -mharden-sls=. * doc/invoke.texi: Document -mharden-sls=. gcc/testsuite/ PR target/102952 * gcc.target/i386/harden-sls-1.c: New test. * gcc.target/i386/harden-sls-2.c: Likewise. * gcc.target/i386/harden-sls-3.c: Likewise. * gcc.target/i386/harden-sls-4.c: Likewise. * gcc.target/i386/harden-sls-5.c: Likewise. (cherry picked from commit 53a643f8568067d7700a9f2facc8ba39974973d3)
[Bug target/103307] Unused "%!" before return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103307
--- Comment #3 from CVS Commits ---
The releases/gcc-11 branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:c604b03126722b419073a97e97ed844677058714
commit r11-9574-gc604b03126722b419073a97e97ed844677058714
Author: H.J. Lu
Date: Wed Nov 17 11:41:12 2021 -0800
x86: Remove "%!" before ret
Before MPX was removed, "%!" was mapped to
case '!':
if (ix86_bnd_prefixed_insn_p (current_output_insn))
fputs ("bnd ", file);
return;
After CET was added and MPX was removed, "%!" was mapped to
case '!':
if (ix86_notrack_prefixed_insn_p (current_output_insn))
fputs ("notrack ", file);
return;
ix86_notrack_prefixed_insn_p always returns false on ret since the
notrack prefix is only for indirect branches. Remove the unused "%!"
before ret.
PR target/103307
* config/i386/i386.c (ix86_code_end): Remove "%!" before ret.
(ix86_output_function_return): Likewise.
* config/i386/i386.md (simple_return_pop_internal): Likewise.
(cherry picked from commit 8e410de43ce039bbe08f1e0195e3b6ec24f68cae)
[Bug c++/99936] [modules] FAIL: g++.dg/modules/xtreme-header* on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99936 --- Comment #9 from Francois-Xavier Coudert --- Most likely this: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=db84f382ae3dc238b1c3e3a18b786bca5bd38a14
[Bug c++/99936] [modules] FAIL: g++.dg/modules/xtreme-header* on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99936 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING --- Comment #8 from Dominique d'Humieres --- The failures have disappeared between r12-7172 and r12-7200.
[Bug rtl-optimization/104544] [10/11 Regression] '-fcompare-debug' failure (length) w/ -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104544 Jakub Jelinek changed: What|Removed |Added Summary|[10/11/12 Regression] |[10/11 Regression] |'-fcompare-debug' failure |'-fcompare-debug' failure |(length) w/ -O2 |(length) w/ -O2 --- Comment #5 from Jakub Jelinek --- Fixed on the trunk.
[Bug rtl-optimization/104544] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104544
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:f997eef5654f782bedb985c9285862c4d76b3209
commit r12-7262-gf997eef5654f782bedb985c9285862c4d76b3209
Author: Jakub Jelinek
Date: Wed Feb 16 14:48:30 2022 +0100
combine: Fix up -fcompare-debug issue in the combiner [PR104544]
On the following testcase on aarch64-linux, we behave differently
with -g and -g0.
The problem is that on:
(insn 10011 10010 10012 2 (set (reg:CC 66 cc)
(compare:CC (reg:DI 105)
(const_int 0 [0]))) "pr104544.c":18:3 407 {cmpdi}
(expr_list:REG_DEAD (reg:DI 105)
(nil)))
(insn 10012 10011 10013 2 (set (reg:SI 109)
(eq:SI (reg:CC 66 cc)
(const_int 0 [0]))) "pr104544.c":18:3 444 {aarch64_cstoresi}
(expr_list:REG_DEAD (reg:CC 66 cc)
(nil)))
(insn 10013 10012 10016 2 (set (reg:DI 110)
(zero_extend:DI (reg:SI 109))) "pr104544.c":18:3 111
{*zero_extendsidi2_aarch64}
(expr_list:REG_DEAD (reg:SI 109)
(nil)))
(insn 10016 10013 10017 2 (parallel [
(set (reg:CC 66 cc)
(compare:CC (const_int 0 [0])
(reg:DI 110)))
(set (reg:DI 111)
(neg:DI (reg:DI 110)))
]) "pr104544.c":18:3 281 {negdi_carryout}
(expr_list:REG_DEAD (reg:DI 110)
(nil)))
...
(debug_insn 6 5 7 2 (var_location:SI y (debug_expr:SI D#5))
"pr104544.c":18:3 -1
(nil))
(debug_insn 7 6 10033 2 (debug_marker) "pr104544.c":11:3 -1
(nil))
(insn 10033 7 10034 2 (set (reg:DI 117 [ _14 ])
(ior:DI (reg:DI 111)
(reg:DI 112))) "pr104544.c":11:6 496 {iordi3}
(expr_list:REG_DEAD (reg:DI 112)
(expr_list:REG_DEAD (reg:DI 111)
(nil
we successfully split 3 insns into two:
Trying 10011, 10013 -> 10016:
10011: cc:CC=cmp(r105:DI,0)
REG_DEAD r105:DI
10013: r110:DI=cc:CC==0
REG_DEAD cc:CC
10016: {cc:CC=cmp(0,r110:DI);r111:DI=-r110:DI;}
REG_DEAD r110:DI
Failed to match this instruction:
(parallel [
(set (reg:CC 66 cc)
(compare:CC (reg:DI 105)
(const_int 0 [0])))
(set (reg:DI 111)
(neg:DI (eq:DI (reg:DI 105)
(const_int 0 [0]
])
Failed to match this instruction:
(parallel [
(set (reg:CC 66 cc)
(compare:CC (reg:DI 105)
(const_int 0 [0])))
(set (reg:DI 111)
(neg:DI (eq:DI (reg:DI 105)
(const_int 0 [0]
])
Successfully matched this instruction:
(set (reg:DI 111)
(neg:DI (eq:DI (reg:DI 105)
(const_int 0 [0]
Successfully matched this instruction:
(set (reg:CC 66 cc)
(compare:CC (reg:DI 105)
(const_int 0 [0])))
Successfully matched this instruction:
(set (reg:DI 112)
(neg:DI (eq:DI (reg:CC 66 cc)
(const_int 0 [0]
allowing combination of insns 10011, 10013 and 10016
original costs 4 + 4 + 4 = 16
replacement costs 4 + 4 = 12
deferring deletion of insn with uid = 10011.
but the code that searches forward for insns to update their log
links (before the change there is a link from insn 10033 to insn 10016
for pseudo 111) only finds insn 10033 and updates the log link if
-g isn't enabled, otherwise it stops earlier because there are debug insns
in between. So, with -g LOG_LINKS of 10033 isn't updated, points
eventually
to NOTE_INSN_DELETED and so we do not attempt to combine 10033 with other
insns, while with -g0 we do.
The following patch fixes that by instead ignoring debug insns during the
searching. We can still check BLOCK_FOR_INSN (insn) on those, because
if we notice DEBUG_INSN in a following basic block, necessarily there won't
be any further normal insns in the current block after it.
2022-02-16 Jakub Jelinek
PR rtl-optimization/104544
* combine.cc (try_combine): When looking for insn whose links
should be updated from i3 to i2, don't stop on debug insns, instead
skip over them.
* gcc.dg/pr104544.c: New test.
[Bug rtl-optimization/104541] [10/11/12 Regression] ICE: maximum number of LRA assignment passes is achieved (30) with -O -fno-tree-ter -fsanitize-coverage=trace-cmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104541 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2022-02-16 CC||jakub at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Jakub Jelinek --- Started with r10-3494-ga1e6ee38e708ef2bdef4dfbb99473344bd56fa2f
[Bug c/104532] ICE in lvalue_p, at c/c-typeck.cc:4987
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104532 --- Comment #2 from Jakub Jelinek --- Created attachment 52454 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52454=edit gcc12-pr104532.patch Untested patch I wrote in the meantime (passes make check-gcc for gomp.exp/goacc.exp/goacc-gomp.exp so far).
[Bug testsuite/104562] [12 regression] gfortran.dg/gomp/depend-5.f90 fails after r12-7242-g3939c1b11279dc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104562 seurer at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from seurer at gcc dot gnu.org --- OK, thanks
[Bug driver/104566] New: Internal compiler error while building from source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104566
Bug ID: 104566
Summary: Internal compiler error while building from source
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: xanderlenstra at gmail dot com
Target Milestone: ---
Created attachment 52453
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52453=edit
Full terminal output as far as I can scroll back
I was trying to get a compiler with support for c++20, but I'm working on a
university computer so I have no sudo rights. Easiest solution seemed to build
g++10 or newer from source, so I did exactly that, following the tutorial on
https://gcc.gnu.org/install/
I've downloaded it from this mirror:
http://mirror.koddos.net/gcc/releases/gcc-11.2.0/ which is marked as an
official mirror on this page: https://gcc.gnu.org/mirrors.html
Due to space concerns, I only installed the c++ component
('--enable-languages=c++') and did the lean bootstrap ('make bootstrap-lean'),
otherwise I have not deviated from the default commands recommended to be run.
I did have to restart the bootstrap once, as the variable `CPLUS_INCLUDE_PATH`
was already set to a different value, resulting in the crash described in
#61427. I `unset` the variable, and ran the same command again. This time, the
terminal showed the following error:
```
cc1: internal compiler error: in fail_formatted, at selftest.c:63
0x24d14f5 selftest::fail_formatted(selftest::location const&, char const*, ...)
../../gcc-11.2.0/gcc/selftest.c:63
0x24d15e4 selftest::assert_streq(selftest::location const&, char const*, char
const*, char const*, char const*)
../../gcc-11.2.0/gcc/selftest.c:92
0x24e86d3 test_add_location_if_nearby
../../gcc-11.2.0/gcc/diagnostic-show-locus.c:4124
0x2514db1 selftest::for_each_line_table_case(void (*)(selftest::line_table_case
const&))
../../gcc-11.2.0/gcc/input.c:3573
0x24ef897 selftest::diagnostic_show_locus_c_tests()
../../gcc-11.2.0/gcc/diagnostic-show-locus.c:5266
0x23fb40c selftest::run_tests()
../../gcc-11.2.0/gcc/selftest-run-tests.c:98
0x12e8ad5 toplev::run_self_tests()
../../gcc-11.2.0/gcc/toplev.c:2265
```
To reiterate, the exact command I ran was `make bootstrap-lean`, while inside
the objdir
The entire output as far as my terminal still shows it, is included as an
attachment. My $HOME on this pc is `/vol/s1935534`.
Running `gcc -v` gave the following output:
```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
```
I have googled for this error, but the only other bug even mentioning the
`fail_formatted` function is #81101, which appears unrelated to building gcc
from source.
If any additional information is required,
[Bug debug/104549] Missing variable at O2/O3 likely caused by -fearly-inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104549
Jakub Jelinek changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
The assembly of main is:
main:
.LFB1:
# pr104549.c:9:1
.loc 1 9 1
.cfi_startproc
# BLOCK 2, count:1073741824 (estimated locally) seq:0
# PRED: ENTRY [always] count:1073741824 (estimated locally) (FALLTHRU)
# pr104549.c:10:5
.loc 1 10 5
.LBB4:
.LBB5:
# pr104549.c:3:5
.loc 1 3 5
.LVL2:
# DEBUG i => 0
# pr104549.c:4:5
.loc 1 4 5
# pr104549.c:4:19
.loc 1 4 19
# pr104549.c:4:12
.loc 1 4 12
# pr104549.c:5:5
.loc 1 5 5
.LBE5:
.LBE4:
# pr104549.c:9:1
.loc 1 9 1 is_stmt 0
subq$8, %rsp
.cfi_def_cfa_offset 16
.LBB7:
.LBB6:
# pr104549.c:5:5
.loc 1 5 5
xorl%edi, %edi
xorl%eax, %eax
calltest
.LVL3:
.LBE6:
.LBE7:
# pr104549.c:11:1
.loc 1 11 1
xorl%eax, %eax
addq$8, %rsp
.cfi_def_cfa_offset 8
# SUCC: EXIT [always] count:1073741824 (estimated locally)
ret
with -O2 -g -dA, the inlined a is in the .LBB4...LBE4 and .LBB7...LBE7 ranges
but the first range is empty (no insns in it), the
very first insn in main doesn't belong to the inline function and .loc for it
is line 9, perhaps the debugger chooses some other one because of the is_stmt
0?
With -gno-statement-frontiers the debugger reports main's { as the first
location.
[Bug tree-optimization/104526] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104526 --- Comment #6 from Jakub Jelinek --- + tree type = TREE_TYPE (TREE_OPERAND (cond, 0)); + if (type != TREE_TYPE (TREE_OPERAND (cond, 1))) +return false; looks unnecessarily restrictive. What tree-cfg.cc verification guarantees (and no need to check it in the ranger) is what verify_gimple_comparison verifies, i.e. that /* For comparisons we do not have the operations type as the effective type the comparison is carried out in. Instead we require that either the first operand is trivially convertible into the second, or the other way around. */ if (!useless_type_conversion_p (op0_type, op1_type) && !useless_type_conversion_p (op1_type, op0_type)) I think the ranger has to be prepared for non-pointer-equal type mismatches as long as they are useless_type_conversion_p compatible, that can happen anywhere in the IL, including even cases like different but useless_type_conversion_p compatible types of binary operators like +, -, * etc. So I'd just remove the if (type != TREE_TYPE (TREE_OPERAND (cond, 1))) return false; lines.
[Bug middle-end/104558] [9/10/11/12 Regression] ICE: in expand_call, at calls.cc:3601 with -fabi-version=9 on pr83487.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104558 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 52452 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52452=edit gcc12-pr104558.patch Untested fix.
[Bug c++/104565] New: One too many `this`es in parsing?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104565
Bug ID: 104565
Summary: One too many `this`es in parsing?
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ted at lyncon dot se
Target Milestone: ---
Regression between g++ 9.4 and 10.1:
```
struct apa {
constexpr auto n() const { return 3; }
};
template
constexpr auto f() {
apa foo;
int{foo.n()}; // no matching function for call to 'apa::n(apa*)'
}
int main() {}
```
