[Bug rtl-optimization/104154] [12 Regression] Another ICE due to recent ifcvt changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104154 --- Comment #2 from rdapp at linux dot ibm.com --- Yes, your guess was right again. We ICE here: gcc_assert (cmode == SImode || cmode == SFmode || cmode == DFmode); but cmode == E_CCmode with the patch. This already helps and the resulting sequences are less expensive: diff --git a/gcc/config/arc/arc.cc b/gcc/config/arc/arc.cc index 8cc173519ab..d802c45f9af 100644 --- a/gcc/config/arc/arc.cc +++ b/gcc/config/arc/arc.cc @@ -2254,6 +2254,8 @@ gen_compare_reg (rtx comparison, machine_mode omode) cmode = GET_MODE (x); + if (cmode == CCmode) +return comparison; if (cmode == VOIDmode) cmode = GET_MODE (y); gcc_assert (cmode == SImode || cmode == SFmode || cmode == DFmode); As we are trying to ifcvt very long sequences (5+ insns) the overall outcome does not change, though.
[Bug target/104363] hppa: __asm__ directive .global and multiple .symver not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104363 --- Comment #8 from Mathieu Malaterre --- Dear John, (In reply to John David Anglin from comment #6) > For context, see: > https://github.com/smuellerDD/libkcapi/issues/133#issuecomment-1024349323 > > Note that the following commit fixes the symbol issue on hppa with gcc-11: > https://github.com/smuellerDD/libkcapi/commit/ > 71d80bcffca26373149121e026d612146b4695d5 As mentionned in the commit message, this is an alternate solution (use of gcc-10 new attribute for `symver`). > The patch predates the hppa issue and it doesn't have anything to do > with hppa. It does mention -flto but this doesn't seem to apply here. Use of -flto seems to confict with the use of asm .symver directive, which is solved by using gcc attribute. > As far as I remember, support for symbol versioning is done in generic code. > > If I was to guess, I suspect the problem is with asm. Maybe a '\t' > is needed before .symver on hppa. The hppa assembler wants white space > before directives. That would not explain the regression gcc-10 -> gcc-11 AFAIK.
[Bug target/104363] hppa: __asm__ directive .global and multiple .symver not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104363 --- Comment #9 from Mathieu Malaterre --- (In reply to Andrew Pinski from comment #5) > (In reply to Mathieu Malaterre from comment #2) > > I've downgraded binutils to version from bullseye, and I am getting the > > exact same symptoms: > > Did you build from scratch or reuse the object files? Everything was done using a fresh tarball export.
[Bug middle-end/104402] [9/10/11/12 Regression] ICE on valid code caused by not lowering complex int compare inside a COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104402
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #4 from Richard Biener ---
I think the best would be to to keep the condition split out since that's
desirable anyway from an IL perspective (we've only covered VEC_COND_EXPR
there).
> grep '\?' t.c.*
t.c.039t.evrp: _7 = _4 ? 3 : 2;
so EVRP introduces this.
t.c.108t.forwprop2: _5 = a.1_3 != __complex__ (0, 0) ? 3 : 2;
and forwprop moves the condition in.
A quick workaround would thus be to disable propagating complex compares
into COND_EXPRs from forwprop but then treating _Complex like vector and
forcing is_gimple_condexpr to return false for composite types would be
a good step with likely not much fallout.
Btw, since vector type equality compares can return a bool as well we can
in theory see
vec1 != vec2 ? scalar1 : scalar2;
which we might not handle in vector lowering either. is_gimple_condexpr
is the predicate to adjust here. For example like the following (but
the factoring with is_gimple_condexpr_for_cond makes it a bit awkwardly
inefficient):
diff --git a/gcc/gimple-expr.cc b/gcc/gimple-expr.cc
index 05b12747499..b71f7afb686 100644
--- a/gcc/gimple-expr.cc
+++ b/gcc/gimple-expr.cc
@@ -615,6 +615,9 @@ is_gimple_condexpr_1 (tree t, bool allow_traps)
bool
is_gimple_condexpr (tree t)
{
+ if (COMPARISON_CLASS_P (t)
+ && TREE_CODE (TREE_TYPE (TREE_OPERAND (t, 0))) == COMPLEX_TYPE)
+return false;
return is_gimple_condexpr_1 (t, true);
}
[Bug target/97005] [nvptx] FAIL: c-c++-common/torture/builtin-arith-overflow-15.c -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97005 --- Comment #4 from Tom de Vries --- (In reply to Jakub Jelinek from comment #3) > Is some workaround possible, like instead of emitting cvt.u32.u16 do > cvt.u32.s16 and add explicit and? This already works: ... diff --git a/builtin-arith-overflow-15/src.cu b/builtin-arith-overflow-15/src.cu index 7a2535f..96f5f1e 100644 --- a/builtin-arith-overflow-15/src.cu +++ b/builtin-arith-overflow-15/src.cu @@ -46,6 +46,7 @@ hello (unsigned int *output) //"mov.u16 r33,0xff80;" "cvt.u32.u16 r35,r33;" +"and.b32 r35,r35,0x;" //"mov.u32 r35, 0xff80;" "st.u32 [rp], r35;" ... > Do other zero extends work correctly? I've rewritten the example to cvt.u64.u32, but that one passes fine. But cvt.u64.u16 runs into the same problem.
[Bug rtl-optimization/104405] Inefficient register allocation on complex arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104405 --- Comment #7 from Richard Biener --- (In reply to Eric Botcazou from comment #6) > > But seems to me a simple enough thing that we should be able to handle. > > Register allocation is a global problem though, so what happens on toy > examples is not always representative of what happens in real world code > because there is a lot of heuristics involved and you want to tune it for > the latter case, not for the former case. There is of course the option to switch to alternate heuristics if, by heuristic, the argument/return part of the function is a big part of it (aka for toy examples or small functions which do happen in real-life). Also toy examples can highlight issues that also exist in the real world.
[Bug tree-optimization/104406] SLP discovery doesn't use TWO_OPERAND nodes as seeds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104406 Richard Biener changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Richard Biener --- It is indeed. The "trick" will be to start at _3 = COMPLEX_EXPR <..> like we start at vector CONSTRUCTOR. For the vectorization of the root stmt you'd then simply do V_C_E (vector-result). Now, for bigger vectors you'd have to start with multiple COMPLEX_EXPRs which will unfortunately not be related in the SSA graph (so that's going to be more difficult if desired). *** This bug has been marked as a duplicate of bug 31485 ***
[Bug tree-optimization/31485] C complex numbers, amd64 SSE, missed optimization opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485 Richard Biener changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #28 from Richard Biener --- *** Bug 104406 has been marked as a duplicate of this bug. ***
[Bug target/97005] [nvptx] FAIL: c-c++-common/torture/builtin-arith-overflow-15.c -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97005
--- Comment #5 from Jakub Jelinek ---
What about u16.u8, u32.u8 and u64.u8 zero extensions?
If it is just hi -> {si,di} zext, then we could take HImode out of the
(define_insn "zero_extendsi2"
[(set (match_operand:SI 0 "nvptx_register_operand" "=R,R")
(zero_extend:SI (match_operand:QHIM 1 "nvptx_nonimmediate_operand"
"R,m")))]
""
"@
%.\\tcvt.u32.u%T1\\t%0, %1;
%.\\tld%A1.u%T1\\t%0, %1;"
[(set_attr "subregs_ok" "true")])
(define_insn "zero_extenddi2"
[(set (match_operand:DI 0 "nvptx_register_operand" "=R,R")
(zero_extend:DI (match_operand:QHSIM 1 "nvptx_nonimmediate_operand"
"R,m")))]
""
"@
%.\\tcvt.u64.u%T1\\t%0, %1;
%.\\tld%A1%u1\\t%0, %1;"
[(set_attr "subregs_ok" "true")])
iterators and add patterns for the hisi and hidi that would do the and
afterwards for the cvt case.
[Bug target/104413] _mm_set1_epi8 isn't optimized for SSE2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104413 --- Comment #3 from Hongtao.liu --- (In reply to Hongtao.liu from comment #2) > (In reply to Hongtao.liu from comment #1) > > Just note pshufb needs SSE3, and it seems reasonable to define a SSE3 > > broadcast pattern which generates pxor + pshufb. > It's SSSE3 not SSE3. :( So it looks optimal with -mssse3 movd%edi, %xmm0 pxor %xmm1, %xmm1; pshufb %xmm1, %xmm0
[Bug target/97005] [nvptx] FAIL: c-c++-common/torture/builtin-arith-overflow-15.c -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97005 --- Comment #6 from Tom de Vries --- (In reply to Jakub Jelinek from comment #5) > What about u16.u8, u32.u8 and u64.u8 zero extensions? ptx has no .u8 registers, so there's no straightforward translation of the example.
[Bug tree-optimization/104408] SLP discovery fails due to -Ofast rewriting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104408
Richard Biener changed:
What|Removed |Added
Blocks||53947
CC||rguenth at gcc dot gnu.org
--- Comment #3 from Richard Biener ---
match.pd just does canonicalization here. SLP discovery could handle this
in the existing swap operands or reassoc support but I guess the desire here
is to pull out a Complex SLP pattern.
So what should really be done in the end is get rid of the restriction during
SLP build that a node has to be from a single interleaving chain. We can
handle {d[i].i, c[i].r} as permute of {d[i].r, d[i].i} and {c[i].r, c[i].i}
during discovery. Of course doing that interferes with the swap-operands
logic which when successful will produce a more optimal initial SLP graph
but that relies on the recursive SLP discovery to first fail.
Forming an optimal SLP graph is likely NP complete so we have to employ
heuristics to some extent.
So - no perfect idea yet how to reliably match a Complex pattern here but
trying to attack this from the match.pd side sounds wrong.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug tree-optimization/104408] SLP discovery fails due to -Ofast rewriting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104408 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-02-07 Ever confirmed|0 |1
[Bug c++/104410] [11/12 Regression] Internal error using default-initialized constexpr bool in requires clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104410 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/97005] [nvptx] FAIL: c-c++-common/torture/builtin-arith-overflow-15.c -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97005 --- Comment #7 from Tom de Vries --- (In reply to Tom de Vries from comment #6) > (In reply to Jakub Jelinek from comment #5) > > What about u16.u8, u32.u8 and u64.u8 zero extensions? > > ptx has no .u8 registers, so there's no straightforward translation of the > example. Um, sorry, I misremembered, that's not true, it does exist, but it's very restricted: mostly ld, st, and cvt. So the sub insn doesn't exist in a u8 mode.
[Bug target/104414] New: [AArch64] About the condition of calls_alloca in aarch64_layout_frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104414
Bug ID: 104414
Summary: [AArch64] About the condition of calls_alloca in
aarch64_layout_frame
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ashimida at linux dot alibaba.com
Target Milestone: ---
There is the following code in aarch64_layout_frame:
else if (crtl->outgoing_args_size.is_constant (&const_outgoing_args_size)
&& frame.saved_regs_size.is_constant (&const_saved_regs_size)
&& const_outgoing_args_size + const_saved_regs_size < 512
&& (!saves_below_hard_fp_p || const_outgoing_args_size == 0)
// 1)
&& !(cfun->calls_alloca
&& frame.hard_fp_offset.is_constant (&const_fp_offset)
&& const_fp_offset < max_push_offset))
{
/* Frame with small outgoing arguments:
sub sp, sp, frame_size
stp reg1, reg2, [sp, outgoing_args_size]
stp reg3, reg4, [sp, outgoing_args_size + 16] */
frame.initial_adjust = frame.frame_size;
frame.callee_offset = const_outgoing_args_size;
}
..
else if (frame.hard_fp_offset.is_constant (&const_fp_offset)
&& const_fp_offset < max_push_offset)
{
// 2)
/* Frame with large outgoing arguments or SVE saves, but with
a small local area:
stp reg1, reg2, [sp, -hard_fp_offset]!
stp reg3, reg4, [sp, 16]
[sub sp, sp, below_hard_fp_saved_regs_size]
[save SVE registers relative to SP]
sub sp, sp, outgoing_args_size */
As described in 2), "Frame with large outgoing arguments or SVE saves,
but with a small local area".
But due to the condition at 1), the following code (small outgoing with
a small local area) also uses the insns in 2), which is slightly different
from the description:
#include
#include
#define REP9(X) X,X,X,X,X,X,X,X,X
int alloc_size;
void outgoing_1 (int x, ...)
{
return 0;
}
int main(void)
{
outgoing1 (REP9(1));
char * y = alloca(alloc_size);
return 0;
}
Could the condition in 1) be removed, or am I missing something?
Thanks,
Dan.
[Bug target/104412] union initialization of a vector is not optimized due to vector cost model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104412 --- Comment #2 from Richard Biener --- On x86_64 we get movq%rsi, %xmm0 movq%rdi, %xmm1 punpcklqdq %xmm1, %xmm0 ret > ./cc1 -quiet t.c -I include -O2 -fopt-info-vec t.c:10:7: optimized: basic block part vectorized using 16 byte vectors and at -O1 movq%rsi, -24(%rsp) movq%rdi, -16(%rsp) movdqa -24(%rsp), %xmm0 ret costing is a bit difficult since we get t.c:10:7: note: Cost model analysis: i2_4(D) 1 times scalar_store costs 12 in body i1_6(D) 1 times scalar_store costs 12 in body i2_4(D) 1 times vector_store costs 12 in body 1 times vec_construct costs 8 in prologue t.c:10:7: note: Cost model analysis for part in loop 0: Vector cost: 20 Scalar cost: 24 as we do not have an idea how costly the construction is (depends on calling conventions) or how the return d.v allows us to elide the store and the load.
[Bug rtl-optimization/104405] Inefficient register allocation on complex arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104405 --- Comment #8 from Eric Botcazou --- > There is of course the option to switch to alternate heuristics if, by > heuristic, the argument/return part of the function is a big part of it (aka > for toy examples or small functions which do happen in real-life). Indeed a solution to be considered, but then... > Also toy examples can highlight issues that also exist in the real world. ...you break the connection between toy examples and real world even more. In any case, I'm not a RA specialist so I'll stop there, but my understanding is that you don't build a good RA for real world code by examining a list of reduced cases and trying to make it optimal for each of them.
[Bug target/104413] _mm_set1_epi8 isn't optimized for SSE2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104413 Richard Biener changed: What|Removed |Added Target|x86-64 |x86_64-*-* Keywords||missed-optimization --- Comment #4 from Richard Biener --- So it sounds like this bug is INVALID?
[Bug target/104414] [AArch64] About the condition of calls_alloca in aarch64_layout_frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104414 --- Comment #1 from Richard Biener --- Please ask such questions on the mailing list instead, there you will more likely get an answer.
[Bug target/104407] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -std=c++17 -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104407 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Keywords|needs-bisection | --- Comment #3 from Jakub Jelinek --- Started with r11-2834-g7fe2cec41bb2ccb499b6b6c513e00da1a270370f
[Bug target/104414] [AArch64] About the condition of calls_alloca in aarch64_layout_frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104414 --- Comment #2 from ashimida --- (In reply to Richard Biener from comment #1) > Please ask such questions on the mailing list instead, there you will more > likely get an answer. Oh, thanks, sorry to bother.
[Bug target/104407] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -std=c++17 -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104407 --- Comment #4 from Jakub Jelinek --- DECL_RTL is set in the -g case prematurely during: #0 set_decl_rtl (t=, x=0x7fffea3b9bb8) at ../../gcc/emit-rtl.cc:1440 #1 0x01bdc0a5 in make_decl_rtl (decl=) at ../../gcc/varasm.cc:1633 #2 0x0120cb23 in expand_expr_real_1 (exp=, target=0x0, tmode=E_DImode, modifier=EXPAND_INITIALIZER, alt_rtl=0x0, inner_reference_p=false) at ../../gcc/expr.cc:10551 #3 0x01204aaf in expand_expr_real (exp=, target=0x0, tmode=E_DImode, modifier=EXPAND_INITIALIZER, alt_rtl=0x0, inner_reference_p=false) at ../../gcc/expr.cc:8736 #4 0x011e20e8 in expand_expr (exp=, target=0x0, mode=E_DImode, modifier=EXPAND_INITIALIZER) at ../../gcc/expr.h:301 #5 0x01203a46 in expand_expr_addr_expr_1 (exp=, target=0x0, tmode=DImode, modifier=EXPAND_INITIALIZER, as=0 '\000') at ../../gcc/expr.cc:8427 #6 0x01204402 in expand_expr_addr_expr (exp=, target=0x0, tmode=E_DImode, modifier=EXPAND_INITIALIZER) at ../../gcc/expr.cc:8548 #7 0x01212ed7 in expand_expr_real_1 (exp=, target=0x0, tmode=E_VOIDmode, modifier=EXPAND_INITIALIZER, alt_rtl=0x0, inner_reference_p=false) at ../../gcc/expr.cc:11767 #8 0x01204aaf in expand_expr_real (exp=, target=0x0, tmode=E_VOIDmode, modifier=EXPAND_INITIALIZER, alt_rtl=0x0, inner_reference_p=false) at ../../gcc/expr.cc:8736 #9 0x0112950c in expand_expr (exp=, target=0x0, mode=E_VOIDmode, modifier=EXPAND_INITIALIZER) at ../../gcc/expr.h:301 #10 0x011595e0 in rtl_for_decl_init (init=, type=) at ../../gcc/dwarf2out.cc:20488 #11 0x0115ab99 in tree_add_const_value_attribute (die=>, t=) at ../../gcc/dwarf2out.cc:20915 Unfortunately it is deep in the expansion code, so we can't easily make it if (!early_dwarf) don't SET_DECL_RTL, because we don't really know that this is from early dwarf.
[Bug target/104407] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -std=c++17 -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104407 --- Comment #5 from Jakub Jelinek --- Perhaps we could introduce EXPAND_EARLY_DEBUG and use that instead of EXPAND_NORMAL, but it would be quite large change.
[Bug target/104407] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -std=c++17 -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104407 --- Comment #6 from Jakub Jelinek --- I mean EXPAND_INITIALIZER. Anyway, we'd have to adjust most of those ~ 35 spots referencing EXPAND_INITIALIZER in expr.cc.
[Bug target/104407] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -std=c++17 -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104407 Richard Biener changed: What|Removed |Added Priority|P3 |P2 --- Comment #7 from Richard Biener --- Hmm, we are trying very hard to _not_ do any RTL expansion during early_dwarf exactly because of this. I suppose there might be a path that slipped through ...
[Bug target/104407] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -std=c++17 -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104407 --- Comment #8 from Jakub Jelinek --- One way would be either not to call rtl = expand_expr (init, NULL_RTX, VOIDmode, EXPAND_INITIALIZER); during early_dwarf or do some extra checks whether it is safe. I see for the early_dwarf case it does native_encode_initializer through which obviously nothing that needs relocation like addresses of vars will make it through, so e.g. punting for early_dwarf before expand_expr if it refers to any decls would do the job.
[Bug rtl-optimization/104154] [12 Regression] Another ICE due to recent ifcvt changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104154 --- Comment #3 from rdapp at linux dot ibm.com --- Power(10) also saw a similar problem where the backend was not prepared to handle what we are passing now. I'm starting to become a bit concerned now that more backends might (latently) not be able to deal with this.
[Bug target/104407] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -std=c++17 -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104407 --- Comment #9 from Jakub Jelinek --- Like either for early_dwarf in reference_to_unused return *tp; for any DECL_P or STRING_CST found, or for early_dwarf use a different callback that does that.
[Bug target/104407] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -std=c++17 -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104407 --- Comment #10 from Richard Biener --- So at least /* Generate the RTL even if early_dwarf to force mangling of all refered to symbols. */ rtl = rtl_for_decl_init (init, type); if (rtl && !early_dwarf) doesn't apply anymore since we mangle all globals in free-lang-data. But of course we do not actually run free-lang-data without -flto ... assign_assembler_name_if_needed is the part that's needed. I suppose we could, in dwarf2out, do a walk_tree on the initializer and call that function on each decl.
[Bug target/104407] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -std=c++17 -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104407 --- Comment #11 from Richard Biener --- (In reply to Jakub Jelinek from comment #8) > One way would be either not to call rtl = expand_expr (init, NULL_RTX, > VOIDmode, EXPAND_INITIALIZER); during early_dwarf or do some extra checks > whether it is safe. I see for the early_dwarf case it does > native_encode_initializer through which obviously nothing that needs > relocation like addresses of vars will make it through, so e.g. punting for > early_dwarf before expand_expr if it refers to any decls would do the job. Yes, early dwarf may not encode references to other decls - those may go away when optimizing. It may only refer to those via dwarf, but not via locations and symbol-refs.
[Bug debug/104407] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -std=c++17 -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104407 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek --- Created attachment 52362 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52362&action=edit gcc12-pr104407.patch This works for me.
[Bug middle-end/104402] [9/10/11/12 Regression] ICE on valid code caused by not lowering complex int compare inside a COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104402 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:70430001b74d0f67386a6b3642c857b3389cd5d0 commit r12-7080-g70430001b74d0f67386a6b3642c857b3389cd5d0 Author: Richard Biener Date: Mon Feb 7 09:31:07 2022 +0100 middle-end/104402 - split out _Complex compares from COND_EXPRs This makes sure we always have a _Complex compare split to a different stmt for the compare operand in a COND_EXPR on GIMPLE. Complex lowering doesn't handle this and the change is something we want for all kind of compares at some point. 2022-02-07 Richard Biener PR middle-end/104402 * gimple-expr.cc (is_gimple_condexpr): _Complex typed compares are not valid. * tree-cfg.cc (verify_gimple_assign_ternary): For COND_EXPR check is_gimple_condexpr. * gcc.dg/torture/pr104402.c: New testcase.
[Bug middle-end/104402] [9/10/11 Regression] ICE on valid code caused by not lowering complex int compare inside a COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104402 Richard Biener changed: What|Removed |Added Known to work||12.0 Summary|[9/10/11/12 Regression] ICE |[9/10/11 Regression] ICE on |on valid code caused by not |valid code caused by not |lowering complex int|lowering complex int |compare inside a COND_EXPR |compare inside a COND_EXPR --- Comment #6 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/104408] SLP discovery fails due to -Ofast rewriting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104408 --- Comment #4 from Tamar Christina --- (In reply to Richard Biener from comment #3) > match.pd just does canonicalization here. SLP discovery could handle this > in the existing swap operands or reassoc support but I guess the desire here > is to pull out a Complex SLP pattern. Yes, though also to optimize the case where you don't have the optab, currently the generated code is much worse at -Ofast. > > So - no perfect idea yet how to reliably match a Complex pattern here but > trying to attack this from the match.pd side sounds wrong. Well the problem is that the scalar code is suboptimal too. even without matching a complex pattern, so the epilogue here does an extra sub on each unrolled step. So I initially figured we'd want to not perform the canonization if it's coming at the expense of sharing. However that looks harder than I though at first as there are multiple points in const-fold.c that will try and force this form. I can probably fix the epilogue post vectorization but that seemed like a worse solution.
[Bug tree-optimization/104415] New: uninit diagnostic improvement at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104415
Bug ID: 104415
Summary: uninit diagnostic improvement at -O0
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
For
int foo ()
{
int cond = 1;
int tem;
return cond ? tem : 0;
}
we emit
t.c: In function 'foo':
t.c:5:21: warning: 'tem' may be used uninitialized [-Wmaybe-uninitialized]
5 | return cond ? tem : 0;
| ~~~^~~
t.c:4:7: note: 'tem' was declared here
4 | int tem;
| ^~~
when not optimizing but
t.c: In function 'foo':
t.c:5:21: warning: 'tem' is used uninitialized [-Wuninitialized]
5 | return cond ? tem : 0;
| ~~~^~~
t.c:4:7: note: 'tem' was declared here
4 | int tem;
| ^~~
when optimizing. Even when not optimizing we could figure out the condition
is constant and emit the "is used uninitialized" variant.
[Bug tree-optimization/104415] uninit diagnostic improvement at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104415 Richard Biener changed: What|Removed |Added Depends on||104373 --- Comment #1 from Richard Biener --- PR104373 mentions how this can be improved. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104373 [Bug 104373] [12 regression] bogus -Wmaybe-uninitialized warning with array new
[Bug target/104327] [12 Regression] Inlining error on s390x since r12-1039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104327 --- Comment #9 from CVS Commits --- The master branch has been updated by Andreas Krebbel : https://gcc.gnu.org/g:db95441cf5399aabc46ca83df19f7290c3e23cb1 commit r12-7081-gdb95441cf5399aabc46ca83df19f7290c3e23cb1 Author: Andreas Krebbel Date: Sun Feb 6 09:07:41 2022 +0100 Check always_inline flag in s390_can_inline_p [PR104327] MASK_MVCLE is set for -Os but not for other optimization levels. In general it should not make much sense to inline across calls where the flag is different but we have to allow it for always_inline. The patch also rearranges the hook implementation a bit based on the recommendations from Jakub und Martin in the PR. Bootstrapped and regression tested on s390x with various arch flags. Will commit after giving a few days for comments. gcc/ChangeLog: PR target/104327 * config/s390/s390.cc (s390_can_inline_p): Accept a few more flags if always_inline is set. Don't inline when tune differs without always_inline. gcc/testsuite/ChangeLog: PR target/104327 * gcc.c-torture/compile/pr104327.c: New test.
[Bug other/104416] New: 'lto-wrapper' invoking 'mkoffload's with duplicated command-line options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104416 Bug ID: 104416 Summary: 'lto-wrapper' invoking 'mkoffload's with duplicated command-line options Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- If you compile offloading code for example with '-foffload=nvptx-none=-Wl,foo.o\ -Wl,bar.o' where these '*.o' files intend to override things from GCC target libraries, you'll get duplicate symbols errors (at run time in case of nvptx offloading). The reason is these options end up twice on the nvptx offloading compilation command line. Per '-v -save-temps', we see the 'lto-wrapper' invoke '[...]/mkoffload @./a.offload_args', and 'a.offload_args' ends with: [...] -dumpbase ./a.xnvptx-none -Wl,foo.o -Wl,bar.o -Wl,foo.o -Wl,bar.o That's (I suppose) not a problem for flags (because even if a later one overrides an earlier, the same then happens again for the duplicated set of flags), but it may be problematic for other options, as per above. These command-line options are built in 'gcc/lto-wrapper.cc:compile_offload_image': [...] obstack_ptr_grow (&argv_obstack, "-dumpbase"); obstack_ptr_grow (&argv_obstack, dumpbase); /* Append options specified by -foffload last. In case of conflicting options we expect offload compiler to choose the latest. */ append_offload_options (&argv_obstack, target, compiler_opts); append_offload_options (&argv_obstack, target, linker_opts); obstack_ptr_grow (&argv_obstack, NULL); argv = XOBFINISH (&argv_obstack, char **); fork_execute (argv[0], argv, true, "offload_args"); [...] I have not yet looked into 'compiler_opts', 'linker_opts'. Per a quick check, this problem also exists for GCC 11, 10, 9, 8.
[Bug c++/104403] [12 Regression] ICE while optimizing lambda that returns address of a static variable hidden in a switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104403 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 52363 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52363&action=edit gcc12-pr104403.patch Untested fix.
[Bug debug/104407] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -std=c++17 -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104407 --- Comment #13 from Richard Biener --- (In reply to Jakub Jelinek from comment #12) > Created attachment 52362 [details] > gcc12-pr104407.patch > > This works for me. Yes. Note we're throwing away the result anyway but the comment at the caller hints at the expansion being necessary because that triggers mangling. Now, with your change we won't ever do any mangling and thus we can instead avoid calling the function at all?
[Bug analyzer/104417] New: [12 Regression] ICE in check_dynamic_size_for_taint, at analyzer/sm-taint.cc:1058
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104417
Bug ID: 104417
Summary: [12 Regression] ICE in check_dynamic_size_for_taint,
at analyzer/sm-taint.cc:1058
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc 12.0.1 20220206 snapshot (g:8eb329e963593342855b6072e5692659107337b7) ICEs
when compiling the following testcase, reduced from
gcc/testsuite/gcc.dg/Wfree-nonheap-object-2.c, w/ -fanalyzer:
char eparr[1];
void *
warn_realloc_extern_ptrarr_offset (int i, int n)
{
return __builtin_realloc (eparr + i, n);
}
% gcc-12.0.1 -fanalyzer -c e9xvubm5.c
during IPA pass: analyzer
e9xvubm5.c: In function 'warn_realloc_extern_ptrarr_offset':
e9xvubm5.c:6:10: internal compiler error: in check_dynamic_size_for_taint, at
analyzer/sm-taint.cc:1058
6 | return __builtin_realloc (eparr + i, n);
| ^~~~
0x7b4ac7 ana::region_model::check_dynamic_size_for_taint(ana::memory_space,
ana::svalue const*, ana::region_model_context*) const
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220206/work/gcc-12-20220206/gcc/analyzer/sm-taint.cc:1058
0x1299852 ana::region_model::set_dynamic_extents(ana::region const*,
ana::svalue const*, ana::region_model_context*)
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220206/work/gcc-12-20220206/gcc/analyzer/region-model.cc:3895
0x12a3510 update_model
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220206/work/gcc-12-20220206/gcc/analyzer/region-model-impl-calls.cc:667
0x1270a0b ana::exploded_graph::process_node(ana::exploded_node*)
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220206/work/gcc-12-20220206/gcc/analyzer/engine.cc:3808
0x127157a ana::exploded_graph::process_worklist()
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220206/work/gcc-12-20220206/gcc/analyzer/engine.cc:3137
0x1273c00 ana::impl_run_checkers(ana::logger*)
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220206/work/gcc-12-20220206/gcc/analyzer/engine.cc:5716
0x1274afe ana::run_checkers()
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220206/work/gcc-12-20220206/gcc/analyzer/engine.cc:5787
0x1263808 execute
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220206/work/gcc-12-20220206/gcc/analyzer/analyzer-pass.cc:87
[Bug tree-optimization/104408] SLP discovery fails due to -Ofast rewriting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104408 --- Comment #5 from Richard Biener --- (In reply to Tamar Christina from comment #4) > (In reply to Richard Biener from comment #3) > > match.pd just does canonicalization here. SLP discovery could handle this > > in the existing swap operands or reassoc support but I guess the desire here > > is to pull out a Complex SLP pattern. > > Yes, though also to optimize the case where you don't have the optab, > currently the generated code is much worse at -Ofast. > > > > > So - no perfect idea yet how to reliably match a Complex pattern here but > > trying to attack this from the match.pd side sounds wrong. > > Well the problem is that the scalar code is suboptimal too. even without > matching a complex pattern, so the epilogue here does an extra sub on each > unrolled step. Well, the issue is then why the scalar code is not optimized (yes, it's not so easy). > So I initially figured we'd want to not perform the canonization if it's > coming at the expense of sharing. However that looks harder than I though at > first as there are multiple points in const-fold.c that will try and force > this form. Yep. The canonicalization likely happens early before we do CSE. > I can probably fix the epilogue post vectorization but that seemed like a > worse solution. Well, the CSE opportunity needs to be realized despite the canonialization.
[Bug debug/104407] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -std=c++17 -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104407 --- Comment #14 from Jakub Jelinek --- Ah, you're right, I thought the rtl is used in the native_encode_initializer case but it is not. So, if the point of r11-2834 was to mangle the referenced symbols, then we shouldn't call rtl_for_decl_init but instead do STRIP_NOPS + if (initializer_constant_valid_p) walk_tree with a callback that will DECL_ASSEMBLER_NAME on the decls.
[Bug debug/104407] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -std=c++17 -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104407 --- Comment #15 from rguenther at suse dot de --- On Mon, 7 Feb 2022, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104407 > > --- Comment #14 from Jakub Jelinek --- > Ah, you're right, I thought the rtl is used in the native_encode_initializer > case but it is not. > So, if the point of r11-2834 was to mangle the referenced symbols, then we > shouldn't call rtl_for_decl_init but instead do STRIP_NOPS + if > (initializer_constant_valid_p) walk_tree with a callback that will > DECL_ASSEMBLER_NAME on the decls. Yeah, I guess so, using assign_assembler_name_if_needed ()
[Bug debug/104407] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -std=c++17 -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104407 Jakub Jelinek changed: What|Removed |Added Attachment #52362|0 |1 is obsolete|| --- Comment #16 from Jakub Jelinek --- Created attachment 52364 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52364&action=edit gcc12-pr104407.patch Updated patch. Hope it doesn't do more harm for -fcompare-debug, I'm not really sure if e.g. mangling something doesn't force some instantiations that wouldn't otherwise happen. And this patch can mangle even things that weren't mangled before with the PR96690 change, though I guess reference_to_unused calls during early_dwarf are just random lottery.
[Bug target/97005] [nvptx] FAIL: c-c++-common/torture/builtin-arith-overflow-15.c -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97005
--- Comment #8 from Tom de Vries ---
I've tried the workaround (posting here only the patch for trunchiqi2, the
pattern that was actually triggered):
...
@@ -424,9 +436,21 @@
[(set (match_operand:QI 0 "nvptx_nonimmediate_operand" "=R,m")
(truncate:QI (match_operand:HI 1 "nvptx_register_operand" "R,R")))]
""
- "@
- %.\\tcvt%t0.u16\\t%0, %1;
- %.\\tst%A0.u8\\t%0, %1;"
+ {
+if (which_alternative == 1)
+ return "%.\\tst%A0.u8\\t%0, %1;";
+
+const char *cvt = "%.\\tcvt%t0.u16\\t%0, %1;";
+if (1)
+ {
+/* Workaround https://developer.nvidia.com/nvidia_bug/3527713. */
+output_asm_insn ("%.\\tcvt.s32.s16\\t%0, %1;", operands);
+output_asm_insn ("%.\\tand.b32\\t%0, %0,0x;", operands);
+return "";
+ }
+
+return cvt;
+ }
[(set_attr "subregs_ok" "true")])
(define_insn "truncsi2"
...
but it didn't work for the test-case from comment 0.
Something that does seem to work for both cases, and the unreduced
builtin-arith-overflow-15.c:
...
diff --git a/gcc/config/nvptx/nvptx.md b/gcc/config/nvptx/nvptx.md
index 6c399dea1908..c33903688a5d 100644
--- a/gcc/config/nvptx/nvptx.md
+++ b/gcc/config/nvptx/nvptx.md
@@ -507,7 +507,13 @@
(minus:HSDIM (match_operand:HSDIM 1 "nvptx_register_operand" "R")
(match_operand:HSDIM 2 "nvptx_register_operand" "R")))]
""
- "%.\\tsub%t0\\t%0, %1, %2;")
+ {
+if (GET_MODE (operands[0]) == HImode)
+ /* Workaround https://developer.nvidia.com/nvidia_bug/3527713. */
+ return "%.\\tsub.s16\\t%0, %1, %2;";
+
+return "%.\\tsub%t0\\t%0, %1, %2;";
+ })
(define_insn "mul3"
[(set (match_operand:HSDIM 0 "nvptx_register_operand" "=R")
...
[Bug fortran/104382] Finalization of parent components not compliant with standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104382 --- Comment #1 from Paul Thomas --- (In reply to Paul Thomas from comment #0) > Created attachment 52349 [details] > Testcase for the problems > > With all branches that feature finalization, the attached testcase outputs: > final_count after assignment =0 > destructor4(complicated) 4. 5. > destructor5 (simple2) -1 > destructor5 (simple2) -2 > destructor2(simple) 3 4 > final_count after deallocation =4 > > Ifort, on the other hand, outputs: > destructor4(complicated) 2.00 2.00 > destructor5 (simple2) 5 > destructor5 (simple2) 6 > destructor1(simple) 1 > destructor1(simple) 1 > final_count after assignment =5 > destructor4(complicated) 4.00 5.00 > destructor5 (simple2) -1 > destructor5 (simple2) -2 > destructor1(simple) 3 > destructor1(simple) 4 > final_count after deallocation = 10 > > There are two problems: > (i) The finalization of 'var' prior to reallocation is not ocurring. This is > fixed by the patch that I posted to the list yesterday. > > (ii) The parent component is not being treated as a component, as mandated > by F2018 7.5.6.2/1(3). Ifort is behaving correctly. > > Paul I now discover that NAG 7.1 behaves the same way as gfortran. Paul
[Bug c++/104418] New: Error inheriting base class constructors by using-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104418
Bug ID: 104418
Summary: Error inheriting base class constructors by
using-declaration
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
This code
```
struct B {
B(int) {}
B(int&&) {}
};
int i = 1;
B b(i); //ok everywhere
struct C : B {
using B::B;
};
C c(i); //ok in Clang only
```
is accepted in Clang, but GCC complains:
```
:13:6: error: use of deleted function 'C::C(int) [inherited from B]'
13 | C c(i);
| ^
:10:14: note: 'C::C(int) [inherited from B]' is implicitly deleted
because the default definition would be ill-formed:
10 | using B::B;
| ^
:10:14: error: call of overloaded 'B(int)' is ambiguous
```
Demo: https://gcc.godbolt.org/z/79EoYM94d
Related question: https://stackoverflow.com/q/71005539/7325599
[Bug middle-end/103641] [11/12 regression] Severe compile time regression in SLP vectorize step
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103641 --- Comment #30 from Tamar Christina --- No problem during nightlies. No real changes in other workloads in compile time nor runtime. can confirm no perf change for xxhash and compile time decreased from 8 to 1 sec. tree vectorization : 0.28 ( 3%) 0.00 ( 0%) 0.28 ( 3%) 135k ( 0%) tree slp vectorization : 7.43 ( 89%) 0.00 ( 0%) 7.41 ( 87%) 3450k ( 8%) into tree vectorization : 0.02 ( 2%) 0.00 ( 0%) 0.02 ( 2%) 135k ( 0%) tree slp vectorization : 0.37 ( 35%) 0.00 ( 0%) 0.39 ( 31%) 3400k ( 8%)
[Bug target/97006] [nvptx] FAIL: gcc.dg/tree-ssa/builtin-sprintf.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97006
--- Comment #2 from Tom de Vries ---
With -fno-builtin, mimimized further to:
...
char buffer[100];
int
main (void)
{
unsigned int i = 0xdeadbeef;
__builtin_sprintf (buffer, "%hhx", i);
__builtin_printf ("%s\n", buffer);
__builtin_printf ("%hhx\n", i);
return 0;
}
...
On x86_64 with glibc:
...
$ gcc gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c
$ ./a.out
ef
ef
...
On nvptx with newlib:
...
spawn nvptx-none-run ./builtin-sprintf.exe^M
beef^M
%hhx^M
...
This could be related to newlib support for hh, I'll try to rebuild with
--enable-newlib-io-c99-formats.
[Bug target/104327] [12 Regression] Inlining error on s390x since r12-1039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104327 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Jakub Jelinek --- Fixed.
[Bug c++/104300] [12 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c:2977 since r12-6326-ge948436eab818c52
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104300 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug target/104396] [11/12 Regression] Invalid SIMD intriniscs accepted at -O1 and above after r11-6794-g04b472ad0e1dc93aba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104396 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||ktkachov at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- So shouldn't diagnostics of the builtins errors that now can be and previously couldn't be DCEd done in the gimple fold target hook?
[Bug target/104413] _mm_set1_epi8 isn't optimized for SSE2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104413 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from H.J. Lu --- pshufb is SSSE3.
[Bug target/97006] [nvptx] FAIL: gcc.dg/tree-ssa/builtin-sprintf.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97006 --- Comment #3 from Tom de Vries --- (In reply to Tom de Vries from comment #2) > I'll try to rebuild with > --enable-newlib-io-c99-formats. And we run into: ... In file included from /home/vries/nvptx/trunk/source-gcc/newlib/libc/include/stdlib.h:22, from /home/vries/nvptx/trunk/source-gcc/newlib/libc/stdio/vfscanf.c:83: /home/vries/nvptx/trunk/source-gcc/newlib/libc/stdio/vfscanf.c: In function ‘__ssvfiscanf_r’: /home/vries/nvptx/trunk/source-gcc/newlib/libc/stdio/vfscanf.c:451:39: sorry, unimplemented: \ target cannot support alloca ...
[Bug c++/104419] New: [[no_unique_address]] interaction with is_standard_layout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104419
Bug ID: 104419
Summary: [[no_unique_address]] interaction with
is_standard_layout
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Keywords: ABI
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
GCC disagrees with Clang and MSVC in this example (reduced from our std::tuple,
and affecting std::unique_ptr):
template struct node;
#ifdef USE_EBO
template struct node : T
{ };
#else
template struct node
{
[[no_unique_address]] T t;
};
#endif
template struct node
{
T t;
};
template struct tuple;
template
struct tuple : node { };
template
struct tuple : tuple, node
{ };
struct empty {};
static_assert( sizeof(tuple) == sizeof(int), "" );
static_assert( __is_standard_layout(tuple), "");
static_assert( __is_standard_layout(tuple), "");
static_assert( __is_standard_layout(tuple), ""); // Clang fails
template struct tuple2;
template
struct tuple2 : node, node
{ };
static_assert( sizeof(tuple2) == sizeof(int), "" );
// GCC and Clang agree for this type (with no recursive inheritance)
static_assert( ! __is_standard_layout(tuple2), "");
If USE_EBO is defined, everybody agrees tuple is standard layout.
But when replacing EBO with [[no_unique_address]] other compilers say it's no
longer standard layout. If they're right, that's a problem for our std::tuple
(as it means the change to use [[no_unique_address]] in std::tuple affected its
ABI).
It seems to me that we should be able to replace EBO with [[no_unique_address]]
(that was the whole point of it), which would support GCC's interpretation. But
if that's the case, I'm not sure why tuple2 isn't standard layout,
even for GCC.
[Bug tree-optimization/104420] New: [12 Regression] Inconsistent checks for X * 0.0 optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104420
Bug ID: 104420
Summary: [12 Regression] Inconsistent checks for X * 0.0
optimization
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
(from a comment in PR 104389)
/* Maybe fold x * 0 to 0. The expressions aren't the same
when x is NaN, since x * 0 is also NaN. Nor are they the
same in modes with signed zeros, since multiplying a
negative value by 0 gives -0, not +0. Nor when x is +-Inf,
since x * 0 is NaN. */
(simplify
(mult @0 real_zerop@1)
(if (!tree_expr_maybe_nan_p (@0)
&& (!HONOR_NANS (type) || !tree_expr_maybe_infinite_p (@0))
&& !tree_expr_maybe_real_minus_zero_p (@0)
&& !tree_expr_maybe_real_minus_zero_p (@1))
@1))
Notice how the comment talks about @0 being a "negative value" while the code
says "!tree_expr_maybe_real_minus_zero_p (@0)", which is not at all the same
thing.
Because tree_expr_maybe_real_minus_zero_p is rather weak, it does not trigger
so often, but still:
double f(int a){
return a*0.;
}
is optimized to "return 0.;" whereas f(-42) should return -0.
[Bug target/97006] [nvptx] FAIL: gcc.dg/tree-ssa/builtin-sprintf.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97006
--- Comment #4 from Tom de Vries ---
This fixes it:
...
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c
b/gcc/testsuite/gcc.dg/tree-ss
a/builtin-sprintf.c
index f90558e9b7ee..9368a2e0e50a 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf.c
@@ -3,7 +3,8 @@
constant folding. With optimization enabled the test will fail to
link if any of the assertions fails. Without optimization the test
aborts at runtime if any of the assertions fails. */
-/* { dg-do run } */
+/* { dg-do run { target c99_runtime } } */
+/* { dg-do link { target { ! c99_runtime } } } */
/* { dg-skip-if "not IEEE float layout" { "pdp11-*-*" } } */
/* { dg-additional-options "-O2 -Wall -Wno-pedantic -fprintf-return-value" }
*/
...
[Bug ada/104421] New: The Ada.Directories.Modification_Time procedure does not work for non-ASCII filenames in the Windows environment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104421
Bug ID: 104421
Summary: The Ada.Directories.Modification_Time procedure does
not work for non-ASCII filenames in the Windows
environment.
Product: gcc
Version: 10.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: yeongtaek.ham at gmail dot com
Target Milestone: ---
The Ada.Directories.Modification_Time procedure does not work for non-ASCII
filenames in the Windows environment.
Example code (file is UTF-8 encoded):
with Ada.Calendar;
with Ada.Directories;
with Ada.Text_IO;
with GNAT.Calendar.Time_IO;
procedure Main is
package TEXT_IO renames Ada.Text_IO;
package TIME_IO renames GNAT.Calendar.Time_IO;
Mod_Time : Ada.Calendar.Time;
begin
TEXT_IO.Put_Line ("한글 출력");
-- Good
Mod_Time := Ada.Directories.Modification_Time("modtime.gpr");
TIME_IO.Put_Time (Mod_Time, TIME_IO.ISO_Time);
TEXT_IO.NEW_LINE;
-- Error
Mod_Time := Ada.Directories.Modification_Time("한글.txt");
TIME_IO.Put_Time (Mod_Time, TIME_IO.ISO_Time);
TEXT_IO.NEW_LINE;
end Main;
Execution result:
PS C:\Users\Regentag\desktop\AdaDev\FileModTime> chcp 65001
Active code page: 65001
PS C:\Users\Regentag\desktop\AdaDev\FileModTime> dir
디렉터리: C:\Users\Regentag\desktop\AdaDev\FileModTime
Mode LastWriteTime Length Name
- --
d- 22-02-07 22:46obj
d- 22-02-07 21:02src
-a 22-02-07 19:30126 modtime.gpr
-a 22-02-07 19:30126 한글.txt
PS C:\Users\Regentag\desktop\AdaDev\FileModTime> C:\GNAT\2021\bin\gprbuild.exe
.\modtime.gpr
Compile
[Ada] main.adb
Bind
[gprbind] main.bexch
[Ada] main.ali
Link
[link] main.adb
PS C:\Users\Regentag\desktop\AdaDev\FileModTime> .\obj\main.exe
한글 출력
2022-02-07T19:30:02+09
raised ADA.IO_EXCEPTIONS.USE_ERROR : Unable to get modification time of the
file "한글.txt"
PS C:\Users\Regentag\desktop\AdaDev\FileModTime>
My GCC version info:
PS C:\GNAT\2021\bin> ./gcc -v
Using built-in specs.
COLLECT_GCC=C:\GNAT\2021\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/gnat/2021/bin/../libexec/gcc/x86_64-w64-mingw32/10.3.1/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../src/configure --enable-languages=ada,c,c++
--enable-checking=release --enable-threads=win32 --enable-libstdcxx-threads
--enable-lto --enable-large-address-aware
--with-bugurl=URL:mailto:rep...@adacore.com --disable-nls
--without-libiconv-prefix --disable-libstdcxx-pch --disable-libada
--disable-multilib --enable-libstdcxx
--with-mpfr=/it/sbx/a2c2/x86_64-windows64/mpfr-3.1.5/install
--with-gmp=/it/sbx/a2c2/x86_64-windows64/gmp-6.1.2/install
--with-mpc=/it/sbx/a2c2/x86_64-windows64/mpc-1.0.3/install
--with-build-time-tools=/it/sbx/a2c2/x86_64-windows64/gcc-c/build/buildtools/bin
--prefix=/it/sbx/a2c2/x86_64-windows64/gcc-c/pkg --build=x86_64-w64-mingw32
Thread model: win32
Supported LTO compression algorithms: zlib
gcc version 10.3.1 20210520 (for GNAT Community 2021 20210519) (GCC)
PS C:\GNAT\2021\bin>
In my opinion, the cause is the use of the GetFileAttributesExA() function
without proper handling of the file name in the __gnat_file_time() function
implemented in adaint.c.
*
https://github.com/gcc-mirror/gcc/blob/db95441cf5399aabc46ca83df19f7290c3e23cb1/gcc/ada/adaint.c#L1515
[Bug c++/104379] [9/10/11/12 Regression] -Wshadow warning given three times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104379 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Created attachment 52365 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52365&action=edit gcc12-pr104379.patch Untested fix (just for -Wshadow).
[Bug c++/104410] [11/12 Regression] Internal error using default-initialized constexpr bool in requires clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104410 Patrick Palka changed: What|Removed |Added Keywords|needs-bisection | CC||ppalka at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- Started with r11-6321. I suppose the underlying problem is that the assert in satisfaction_value should is too strict, it should be relaxed to accept cv-qualified bool.
[Bug rtl-optimization/104154] [12 Regression] Another ICE due to recent ifcvt changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104154 --- Comment #4 from Jeffrey A. Law --- Given we've run this code on a pretty wide variety of targets, I'm not too concerned. The arc issue was the last one I'm aware of related to your ifcvt changes.
[Bug fortran/102596] [11/12 Regression] ICE in gfc_omp_clause_default_ctor, at fortran/trans-openmp.c:713 since r11-4883-ge929ef532ad52cde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102596
Tobias Burnus changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Keywords||ice-on-valid-code
--- Comment #2 from Tobias Burnus ---
The problem is that gfc_omp_clause_default_ctor requires outer != NULL_TREE
(gcc_assert).
(C++ does ignore the last argument and C uses the hook_tree_tree_tree_tree_null
fallback.)
That is used in Fortran for:
/* Allocatable arrays and scalars in PRIVATE clauses need to be set to
"not currently allocated" allocation status if outer
array is "not currently allocated", otherwise should be allocated. */
But omp-low.cc has:
x = lang_hooks.decls.omp_clause_default_ctor
(c, unshare_expr (new_var),
cond ? NULL_TREE
: build_outer_var_ref (var, ctx));
Note the NULL_TREE.
My impression is that NULL_TREE is fine for reduction - and there is also code
like:
/* Reduction clause requires allocated ALLOCATABLE. */
if (OMP_CLAUSE_CODE (clause) != OMP_CLAUSE_REDUCTION
&& OMP_CLAUSE_CODE (clause) != OMP_CLAUSE_IN_REDUCTION
&& OMP_CLAUSE_CODE (clause) != OMP_CLAUSE_TASK_REDUCTION)
{
gfc_init_block (&cond_block);
...
tree tem = fold_convert (pvoid_type_node,
GFC_DESCRIPTOR_TYPE_P (type)
? gfc_conv_descriptor_data_get (outer) :
outer);/*...*/
cond = fold_build2_loc (input_location, NE_EXPR, logical_type_node,
tem, null_pointer_node);
However - there is other code which uses 'outer' like:
tree tem = gfc_walk_alloc_comps (outer, decl,
or
gfc_add_modify (&cond_block, decl, outer);
and those make use of 'outer'.
I don't quickly see whether outer is always required or it can be deduced in
this case.
(Does using OMP_CLAUSE_REDUCTION_PLACEHOLDER() make sense here?) — Or whether
some is-always-used case (→ 'cond' case) is needed as additional flag or
encoded in outer.
PS: I don't think it is a real regression as 'reduction(task:' wasn't supported
before.
[Bug middle-end/103641] [11 regression] Severe compile time regression in SLP vectorize step
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103641 Richard Biener changed: What|Removed |Added Known to work||12.0 Summary|[11/12 regression] Severe |[11 regression] Severe |compile time regression in |compile time regression in |SLP vectorize step |SLP vectorize step Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #31 from Richard Biener --- Marking fixed for GCC 12 then (still 35% with SLP vectorization is on the high end). I'm not sure about backporting this particular change, I'll definitely wait more for that. I suppose the slowness is still entirely within synth_mult?
[Bug target/104422] New: nvptx: for-3.exe fail with driver 390.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104422
Bug ID: 104422
Summary: nvptx: for-3.exe fail with driver 390.x
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
While testing libgomp using legacy driver 390.x on a maxwell card, Quadro K620
I ran into a for-3.exe execution failure.
I've minimized it to this:
...
$ cat for-3.c
/* { dg-additional-options "-std=gnu99" { target c } } */
extern void abort ();
#pragma omp declare target
int a[1500];
void
test_ds_normal (void)
{
#pragma omp target update to(a)
;
#pragma omp target teams
#pragma distribute simd
for (int i = 0; i < 1500; i++)
a[i] += 2;
#pragma omp target update from(a)
;
}
#pragma omp end declare target
int
main (void)
{
int err = 0;
for (int i = 0; i < 1500; i++)
a[i] = i - 25;
test_ds_normal ();
for (int i = 0; i < 1500; i++)
if (a[i] != i - 23)
err = 1;
if (err)
abort ();
return 0;
}
...
This might be a driver problem, we know of problems that we reported to nvidia
that they're not going to fix in this driver.
Then again, it might not be a driver problem...
[Bug testsuite/104423] New: [libgomp, testsuite] Add means to do accelerator-only testing in libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104423 Bug ID: 104423 Summary: [libgomp, testsuite] Add means to do accelerator-only testing in libgomp Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- For nvptx offload testing, I switched to an eGPU setup, and cycle through 4 boards (kepler, maxwell, pascal, turing) to do pre-commit testing. Sometime in the future that'll be 5, once I get an ampere board as well. I run a script test-board.sh that iterates over various dimensions, which takes about 5 hours per board. In practice, this means testing a patch get spread over 2 days. Furthermore, I'm looking to extend the dimensions on which I test, possibly doubling the test-board time. I noticed that a lot of time is spent running libgomp tests that do not use the accelerator, and which are not needed for my purposes. It would be nice if libgomp provided a mode to run only tests that use the accelerator, to drive down the test-board.sh execution time.
[Bug fortran/104382] Finalization of parent components not compliant with standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104382 --- Comment #2 from anlauf at gcc dot gnu.org --- crayftn 11 & 12 output: destructor4(complicated) 2*2. destructor5 (simple2) 5 destructor5 (simple2) 6 destructor2(simple) 2*1 destructor4(complicated) 4., 5. destructor5 (simple2) -1 destructor5 (simple2) -2 destructor2(simple) 3, 4 final_count after assignment = 8 destructor4(complicated) 4., 5. destructor5 (simple2) -1 destructor5 (simple2) -2 destructor2(simple) 3, 4 final_count after deallocation = 12
[Bug fortran/104382] Finalization of parent components not compliant with standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104382 --- Comment #3 from Paul Thomas --- (In reply to anlauf from comment #2) > crayftn 11 & 12 output: > > destructor4(complicated) 2*2. > destructor5 (simple2) 5 > destructor5 (simple2) 6 > destructor2(simple) 2*1 > destructor4(complicated) 4., 5. > destructor5 (simple2) -1 > destructor5 (simple2) -2 > destructor2(simple) 3, 4 > final_count after assignment = 8 > destructor4(complicated) 4., 5. > destructor5 (simple2) -1 > destructor5 (simple2) -2 > destructor2(simple) 3, 4 > final_count after deallocation = 12 That seems to make a majority vote for the present gfortran behaviour then. Thanks Paul
[Bug tree-optimization/24021] VRP does not work with floating points
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021 Aldy Hernandez changed: What|Removed |Added CC||aldyh at gcc dot gnu.org --- Comment #5 from Aldy Hernandez --- (In reply to Andrew Macleod from comment #4) > FWIW, we hope to enable floating point range support in ranger for GCC 13. > > One of the post stage 1 tasks is to generalize ranger to use a vrange class, > from which we can derive integral (irange), pointer (prange), and float > (frange) types. possibly complex integral (cirange) and/or string (srange) > have been thrown around if appropriate. > > Before we go to develop the frange class, we'll have a working session of > some sort to flesh out what it can track, then implement some range-ops for > some float tree-codes. FWIW, I'm on this. I've begun work on vrange, and simultaneously have started work on a proof-of-concept for floating points that I hope some more savvy floating experts can extend.
[Bug c/104424] New: -fvolatile, not documented in gcc-4.3.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104424 Bug ID: 104424 Summary: -fvolatile, not documented in gcc-4.3.3 Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: swaroop.tekale at se dot com Target Milestone: --- "-fvolatile" flag is not listed in the below gcc-4.3.6: https://gcc.gnu.org/onlinedocs/gcc-4.3.6/gcc/Option-Summary.html#Option-Summary Can you please confirm if this is explicitly removed, as it should not be configured ? Or if it is a gcc document miss in above link? We are still able to use the -fvolatile flag as part of compiler options, So need confirmation if this is still a valid flag ? This will help us to understand if we still have to keep "-fvolatile" flag in our environment or consider removing it. Compiler version: gnu 4.3.3
[Bug target/104380] -D_FORTIFY_SOURCE -mabi=ieeelongdouble -std=c* wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104380 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5d2a330dee37ed10daa424d33ab1bcd5727c187b commit r12-7084-g5d2a330dee37ed10daa424d33ab1bcd5727c187b Author: Jakub Jelinek Date: Mon Feb 7 17:39:11 2022 +0100 testsuite: Fix up testsuite/gcc.c-torture/execute/builtins/lib/chk.c for powerpc [PR104380] > > The following testcase FAILs when configured with > > --with-long-double-format=ieee . Only happens in the -std=c* modes, not the > > GNU modes; while the glibc headers have __asm redirects of > > vsnprintf and __vsnprinf_chk to __vsnprintfieee128 and > > __vsnprintf_chkieee128, the vsnprintf fortification extern inline gnu_inline > > always_inline wrapper calls __builtin_vsnprintf_chk and we actually emit > > a call to __vsnprinf_chk (i.e. with IBM extended long double) instead of > > __vsnprintf_chkieee128. > > > > rs6000_mangle_decl_assembler_name already had cases for *printf and *scanf, > > so this just adds another case for *printf_chk. *scanf_chk doesn't exist. > > __ prefixing isn't done because *printf_chk already starts with __. Unfortunately, while I've tested the testcase also with -mabi=ieeelongdouble by hand, the full bootstrap/regtest was on GCCFarm where glibc is too old to test with --with-long-double-format=ieee. I've done full bootstrap/regtest with that option during the weekend and the patch regressed: FAIL: gcc.c-torture/execute/builtins/snprintf-chk.c execution, -O1 FAIL: gcc.c-torture/execute/builtins/snprintf-chk.c execution, -O2 FAIL: gcc.c-torture/execute/builtins/snprintf-chk.c execution, -O2 -flto -fno-use-linker-plugin -flto-partition=none FAIL: gcc.c-torture/execute/builtins/snprintf-chk.c execution, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: gcc.c-torture/execute/builtins/snprintf-chk.c execution, -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions FAIL: gcc.c-torture/execute/builtins/snprintf-chk.c execution, -O3 -g FAIL: gcc.c-torture/execute/builtins/snprintf-chk.c execution, -Og -g FAIL: gcc.c-torture/execute/builtins/snprintf-chk.c execution, -Os FAIL: gcc.c-torture/execute/builtins/sprintf-chk.c execution, -O1 FAIL: gcc.c-torture/execute/builtins/sprintf-chk.c execution, -O2 FAIL: gcc.c-torture/execute/builtins/sprintf-chk.c execution, -O2 -flto -fno-use-linker-plugin -flto-partition=none FAIL: gcc.c-torture/execute/builtins/sprintf-chk.c execution, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: gcc.c-torture/execute/builtins/sprintf-chk.c execution, -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions FAIL: gcc.c-torture/execute/builtins/sprintf-chk.c execution, -O3 -g FAIL: gcc.c-torture/execute/builtins/sprintf-chk.c execution, -Og -g FAIL: gcc.c-torture/execute/builtins/sprintf-chk.c execution, -Os FAIL: gcc.c-torture/execute/builtins/vsnprintf-chk.c execution, -O1 FAIL: gcc.c-torture/execute/builtins/vsnprintf-chk.c execution, -O2 FAIL: gcc.c-torture/execute/builtins/vsnprintf-chk.c execution, -O2 -flto -fno-use-linker-plugin -flto-partition=none FAIL: gcc.c-torture/execute/builtins/vsnprintf-chk.c execution, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: gcc.c-torture/execute/builtins/vsnprintf-chk.c execution, -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions FAIL: gcc.c-torture/execute/builtins/vsnprintf-chk.c execution, -O3 -g FAIL: gcc.c-torture/execute/builtins/vsnprintf-chk.c execution, -Og -g FAIL: gcc.c-torture/execute/builtins/vsnprintf-chk.c execution, -Os FAIL: gcc.c-torture/execute/builtins/vsprintf-chk.c execution, -O1 FAIL: gcc.c-torture/execute/builtins/vsprintf-chk.c execution, -O2 FAIL: gcc.c-torture/execute/builtins/vsprintf-chk.c execution, -O2 -flto -fno-use-linker-plugin -flto-partition=none FAIL: gcc.c-torture/execute/builtins/vsprintf-chk.c execution, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: gcc.c-torture/execute/builtins/vsprintf-chk.c execution, -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions FAIL: gcc.c-torture/execute/builtins/vsprintf-chk.c execution, -O3 -g FAIL: gcc.c-torture/execute/builtins/vsprintf-chk.c execution, -Og -g FAIL: gcc.c-torture/execute/builtins/vsprintf-chk.c execution, -Os The problem is that the execute/builtins/ testsuite wants to override some of the library functions and with the change we (correctly) call __*printf_chkieee128 and so lib/chk.c is no longer called but the glibc APIs are. 2022-02-07 Jakub Jelinek PR target/104380 * gcc.c-torture/execute/builtins/lib/chk.c (__sprintf_chkieee128, __vsprintf_chkieee128, __snprintf_chkieee12
[Bug c/104424] -fvolatile, not documented in gcc-4.3.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104424 --- Comment #1 from Andreas Schwab --- Such a flag never existed, there is only -Wvolatile.
[Bug c/104424] -fvolatile, not documented in gcc-4.3.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104424 --- Comment #2 from Swaroop Tekale --- It seems to be there on or before gcc-3.3.6: https://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/Option-Summary.html#Option-Summary Code Generation Options See Options for Code Generation Conventions. -fcall-saved-reg -fcall-used-reg -ffixed-reg -fexceptions -fnon-call-exceptions -funwind-tables -fasynchronous-unwind-tables -finhibit-size-directive -finstrument-functions -fno-common -fno-ident -fno-gnu-linker -fpcc-struct-return -fpic -fPIC -freg-struct-return -fshared-data -fshort-enums -fshort-double -fshort-wchar -fvolatile -fvolatile-global -fvolatile-static -fverbose-asm -fpack-struct -fstack-check -fstack-limit-register=reg -fstack-limit-symbol=sym -fargument-alias -fargument-noalias -fargument-noalias-global -fleading-underscore -ftls-model=model -ftrapv -fbounds-check
[Bug c/104424] -fvolatile, not documented in gcc-4.3.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104424 --- Comment #3 from Jonathan Wakely --- It's not there because it was removed in GCC 3.4: https://gcc.gnu.org/gcc-3.4/changes.html You will get an error if you try to use it with 4.3.3 There is no bug report here, so I think it would have been more appropriate on the gcc-help mailing list, https://gcc.gnu.org/lists.html
[Bug c/104424] -fvolatile, not documented in gcc-4.3.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104424 Jonathan Wakely changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Jonathan Wakely --- .
[Bug c/104424] -fvolatile, not documented in gcc-4.3.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104424 Swaroop Tekale changed: What|Removed |Added Resolution|INVALID |WORKSFORME Status|RESOLVED|VERIFIED --- Comment #5 from Swaroop Tekale --- As mentioned in the description: We are able to use the -fvolatile flag. We are not getting any errors. And hence need to understand if this is a a document miss or really an invalid flag for gcc 4.3.3 ?
[Bug c++/104425] New: SFINAE hard error on failed resolution of << for defined class in namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104425
Bug ID: 104425
Summary: SFINAE hard error on failed resolution of << for
defined class in namespace
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: saalvage at gmail dot com
Target Milestone: ---
namespace A { class foo {}; }
namespace B { class bar {}; }
A::foo& operator<<(A::foo& f, const B::bar&) { return f; }
namespace C {
template
T val();
class asd {};
A::foo& operator<<(A::foo& f, const asd& in) { return f; }
template
struct has_insertion_operator {
static constexpr bool value = false;
};
template
struct has_insertion_operator() << val(),
void())> {
static constexpr bool value = true;
};
}
int main() { C::has_insertion_operator::value; }
Produces:
: In instantiation of 'struct C::has_insertion_operator':
:24:47: required from here
:19:62: error: no match for 'operator<<' (operand types are 'A::foo'
and 'B::bar')
19 | struct has_insertion_operator() <<
val(), void())> {
|
~~~^~~
:11:13: note: candidate: 'A::foo& C::operator<<(A::foo&, const
C::asd&)'
11 | A::foo& operator<<(A::foo& f, const asd& in) { return f; }
| ^~~~
:11:46: note: no known conversion for argument 2 from 'B::bar' to
'const C::asd&'
11 | A::foo& operator<<(A::foo& f, const asd& in) { return f; }
| ~~~^~
:19:62: error: no match for 'operator<<' (operand types are 'A::foo'
and 'B::bar')
19 | struct has_insertion_operator() <<
val(), void())> {
|
~~~^~~
:11:13: note: candidate: 'A::foo& C::operator<<(A::foo&, const
C::asd&)'
11 | A::foo& operator<<(A::foo& f, const asd& in) { return f; }
| ^~~~
:11:46: note: no known conversion for argument 2 from 'B::bar' to
'const C::asd&'
11 | A::foo& operator<<(A::foo& f, const asd& in) { return f; }
| ~~~^~
:19:62: error: no match for 'operator<<' (operand types are 'A::foo'
and 'B::bar')
19 | struct has_insertion_operator() <<
val(), void())> {
|
~~~^~~
:11:13: note: candidate: 'A::foo& C::operator<<(A::foo&, const
C::asd&)'
11 | A::foo& operator<<(A::foo& f, const asd& in) { return f; }
| ^~~~
:11:46: note: no known conversion for argument 2 from 'B::bar' to
'const C::asd&'
11 | A::foo& operator<<(A::foo& f, const asd& in) { return f; }
| ~~~^~
:20: confused by earlier errors, bailing out
Notably, the same candidate appears to be reinspected thrice?
Bizzarely enough, both of the following fix the issue:
- Calling operator<< explicitely
- Only declaring, not defining B::bar
[Bug target/88798] AVX512BW code does not use bit-operations that work on mask registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88798 --- Comment #8 from Wojciech Mula --- Thank you for the answer. Thus my question is: is it possible to delay conversion from kmasks into ints? I'm not a language lawyer, but I guess a `x binop y` has to be treated as `(int)x binop (int)y`. If it's true, we will have to prove that `(int)(x avx512-binop y)` is equivalent to the latter expr.
[Bug c/104424] -fvolatile, not documented in gcc-4.3.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104424 Andreas Schwab changed: What|Removed |Added Resolution|WORKSFORME |INVALID
[Bug c++/104426] New: -fsanitize=undefined causes constexpr failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104426
Bug ID: 104426
Summary: -fsanitize=undefined causes constexpr failures
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pdimov at gmail dot com
Target Milestone: ---
The following program
```
struct category
{
constexpr bool failed() const noexcept
{
return true;
}
};
inline constexpr category s_cat;
struct condition
{
category const* cat_;
constexpr bool failed() const noexcept
{
if( cat_ )
{
return cat_->failed();
}
else
{
return false;
}
}
};
int main()
{
constexpr condition cond{ &s_cat };
static_assert( cond.failed() );
}
```
compiles without -fsanitize=undefined (https://godbolt.org/z/Pn9M5ocfz), but
fails with it (https://godbolt.org/z/KKc8Tb9qe) with
```
: In function 'int main()':
:31:31: error: non-constant condition for static assertion
31 | static_assert( cond.failed() );
|~~~^~
:31:31: in 'constexpr' expansion of 'cond.condition::failed()'
:17:13: error: '((& s_cat) != 0)' is not a constant expression
17 | if( cat_ )
| ^~~~
```
This happens under all GCC versions starting from 7.
(The above is an extract from the test suite for
boost::system::error_condition.)
[Bug c++/104419] [[no_unique_address]] interaction with is_standard_layout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104419 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=104386 --- Comment #1 from Andrew Pinski --- Pr 104386 is very much related.
[Bug target/104271] [12 Regression] 538.imagick_r run-time at -Ofast -march=native regressed by 26% on Intel Cascade Lake server CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104271 --- Comment #2 from Martin Jambor --- (In reply to Hongtao.liu from comment #1) > I think this patch has already been reverted by > r12-3011-g1db70e61a92978377a648bbd90e383859fc0126b. Unfortunately that revision does not help.
[Bug libgomp/104385] Segmentation fault when using nested dependent tasks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104385 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #7 from Jakub Jelinek --- Created attachment 52366 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52366&action=edit gcc12-pr104385.patch So far lightly tested fix.
[Bug c/104427] New: [12 Regression] ICE in gimplify_expr, at gimplify.cc:15759
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104427
Bug ID: 104427
Summary: [12 Regression] ICE in gimplify_expr, at
gimplify.cc:15759
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 2024 and 20211121 :
$ cat z1.c
_Float16 x, y;
int foo()
{
return __builtin_assoc_barrier(x + y) - y;
}
$ gcc-12-20220206 -c z1.c
z1.c:4:36: internal compiler error: in gimplify_expr, at gimplify.cc:15759
4 | return __builtin_assoc_barrier(x + y) - y;
| ~~^~~
0xac934a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:15759
0xac70cb gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:15720
0xac43ca gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:15066
0xac3f9d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:15729
0xac9c78 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7035
0xac57ee gimplify_and_add(tree_node*, gimple**)
../../gcc/gimplify.cc:495
0xac57ee gimplify_return_expr
../../gcc/gimplify.cc:1677
0xac57ee gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:15225
0xac9c78 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7035
0xaca603 gimplify_bind_expr
../../gcc/gimplify.cc:1427
0xac5f8a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:15164
0xac9c78 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7035
0xacb85e gimplify_body(tree_node*, bool)
../../gcc/gimplify.cc:16209
0xacbe47 gimplify_function_tree(tree_node*)
../../gcc/gimplify.cc:16363
0x8dd527 cgraph_node::analyze()
../../gcc/cgraphunit.cc:675
0x8e07d6 analyze_functions
../../gcc/cgraphunit.cc:1240
0x8e19ad symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.cc:2500
[Bug fortran/104428] New: [12 Regression] ICE in gfc_trans_omp_declare_variant, at fortran/trans-openmp.cc:7648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104428
Bug ID: 104428
Summary: [12 Regression] ICE in gfc_trans_omp_declare_variant,
at fortran/trans-openmp.cc:7648
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: ---
Started between 20211010 and 20211017 :
$ cat z1.f90
program p
contains
subroutine s
!$omp declare variant(x) match(construct={do})
end
end
$ cat z2.f90 # accepted
subroutine s
!$omp declare variant(x) match(construct={do})
end
$ gfortran-12-20220206 -c z2.f90 -fopenmp
$
$ gfortran-12-20220206 -c z1.f90 -fopenmp
z1.f90:3:15:
3 |subroutine s
| 1
interner Compiler-Fehler: Speicherzugriffsfehler
0xcc806f crash_signal
../../gcc/toplev.cc:322
0x816506 gfc_trans_omp_declare_variant(gfc_namespace*)
../../gcc/fortran/trans-openmp.cc:7648
0x7cb007 gfc_create_function_decl(gfc_namespace*, bool)
../../gcc/fortran/trans-decl.cc:3118
0x7d016e gfc_generate_contained_functions
../../gcc/fortran/trans-decl.cc:5768
0x7d016e gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.cc:7586
0x7530ae translate_all_program_units
../../gcc/fortran/parse.cc:6651
0x7530ae gfc_parse_file()
../../gcc/fortran/parse.cc:6938
0x7a00af gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:216
[Bug fortran/104429] New: [9/10/11/12 Regression] ICE in gfc_conv_variable, at fortran/trans-expr.cc:3056
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104429 Bug ID: 104429 Summary: [9/10/11/12 Regression] ICE in gfc_conv_variable, at fortran/trans-expr.cc:3056 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: --- Started between 20180826 and 20180902 : $ cat z1.f90 module m type t contains procedure :: op procedure :: assign generic :: operator(*) => op generic :: assignment(=) => assign end type contains function op (x, y) class(t), allocatable :: op class(t), intent(in) :: x real, intent(in) :: y end subroutine assign (z, x) type(t), intent(in) :: x class(t), intent(out) :: z end end program p use m class(t), allocatable :: x x = x * y end $ gfortran-8 -c z1.f90 $ $ gfortran-12-20220206 -c z1.f90 z1.f90:23:12: 23 |x = x * y |1 interner Compiler-Fehler: in gfc_conv_variable, at fortran/trans-expr.cc:3056 0x7dc07f gfc_conv_variable ../../gcc/fortran/trans-expr.cc:3056 0x7d7fba gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.cc:9406 0x7e5102 get_proc_ptr_comp ../../gcc/fortran/trans-expr.cc:4176 0x7e5102 conv_function_val ../../gcc/fortran/trans-expr.cc:4215 0x7e5102 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) ../../gcc/fortran/trans-expr.cc:7650 0x81f040 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool) ../../gcc/fortran/trans-stmt.cc:422 0x7a7043 trans_code ../../gcc/fortran/trans.cc:1995 0x7d037e gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:7654 0x7530ae translate_all_program_units ../../gcc/fortran/parse.cc:6651 0x7530ae gfc_parse_file() ../../gcc/fortran/parse.cc:6938 0x7a00af gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:216
[Bug c/104427] ICE with __builtin_assoc_barrier and float16 types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104427 --- Comment #1 from Andrew Pinski --- >Started between 2024 and 20211121 : Started when __builtin_assoc_barrier support was added (r12-5368-gefb7c51024ccad9df2) so this is not a regression.
[Bug fortran/104430] New: [9/10/11/12 Regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.cc:2742
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104430 Bug ID: 104430 Summary: [9/10/11/12 Regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.cc:2742 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: --- Starts with r8, basically r9 changed between 20181014 and 20181021 : $ cat z1.f90 module m type t integer :: a end type contains function f(x) result(z) class(t) :: x(:) type(t) :: z(size(x%a)) end end program p use m class(t), allocatable :: y(:), z(:) z = f(y) end $ gfortran-7 -c z1.f90 $ $ gfortran-12-20220206 -c z1.f90 z1.f90:14:11: 14 |z = f(y) | 1 internal compiler error: Segmentation fault 0xe6fc6f crash_signal ../../gcc/toplev.cc:322 0x8265df tree_check3(tree_node*, char const*, int, char const*, tree_code, tree_code, tree_code) ../../gcc/tree.h:3483 0x8265df gfc_conv_component_ref(gfc_se*, gfc_ref*) ../../gcc/fortran/trans-expr.cc:2742 0x837897 gfc_conv_variable ../../gcc/fortran/trans-expr.cc:3118 0x83264a gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.cc:9406 0x835760 gfc_conv_expr_lhs(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.cc:9436 0x7f0858 gfc_conv_ss_descriptor ../../gcc/fortran/trans-array.cc:3219 0x7fd2e5 gfc_conv_expr_descriptor(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-array.cc:7494 0x8462cf gfc_conv_intrinsic_size ../../gcc/fortran/trans-intrinsic.cc:7975 0x86295b gfc_conv_intrinsic_function(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-intrinsic.cc:10644 0x83262a gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.cc:9398 0x834b5a gfc_apply_interface_mapping(gfc_interface_mapping*, gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.cc:4865 0x7ee747 gfc_set_loop_bounds_from_array_spec(gfc_interface_mapping*, gfc_se*, gfc_array_spec*) ../../gcc/fortran/trans-array.cc:1080 0x83066f gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) ../../gcc/fortran/trans-expr.cc:7472 0x8426ac gfc_trans_arrayfunc_assign ../../gcc/fortran/trans-expr.cc:10873 0x8428d4 gfc_trans_assignment(gfc_expr*, gfc_expr*, bool, bool, bool, bool) ../../gcc/fortran/trans-expr.cc:12038 0x7e9887 trans_code ../../gcc/fortran/trans.cc:1916 0x8207a9 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:7654 0x7931fe translate_all_program_units ../../gcc/fortran/parse.cc:6651 0x7931fe gfc_parse_file() ../../gcc/fortran/parse.cc:6938
[Bug c/104427] ICE with __builtin_assoc_barrier and float types which introduce excess precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104427
Andrew Pinski changed:
What|Removed |Added
Summary|ICE with|ICE with
|__builtin_assoc_barrier and |__builtin_assoc_barrier and
|float16 types |float types which introduce
||excess precision
Target||aarch64*-* x86_64-*-*
--- Comment #2 from Andrew Pinski ---
It is an interaction between excess_precision_expr and the barrier.
Here is another testcase which shows the same issue but on i?86 (-m32 -mno-sse
-std=c99):
float x, y;
int foo()
{
return __builtin_assoc_barrier(x + y) - y;
}
[Bug c/104427] ICE with __builtin_assoc_barrier and float types which introduce excess precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104427 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-02-07
[Bug other/104431] New: Provide better error message when GCC "multilib" is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104431 Bug ID: 104431 Summary: Provide better error message when GCC "multilib" is missing Product: gcc Version: 8.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: eyalroz1 at gmx dot com Target Milestone: --- I was recently trying to build GCC 8.5.0 on my Devuan Chimaera machine, which has GCC 9 and 10 installed. When configuring, I was told: /usr/bin/ld: cannot find Scrt1.o: No such file or directory /usr/bin/ld: cannot find crti.o: No such file or directory /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/10/libgcc.a when searching for -lgcc /usr/bin/ld: cannot find -lgcc /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/10/libgcc.a when searching for -lgcc /usr/bin/ld: cannot find -lgcc it is _quite_ difficult for the lay person to understand what the actual problem here. I have GCC 10, I have ligcc for GCC 10 - what's wrong with it? And what are Scrt1 and crti ? And why is configure checking for `.o` files anyway? Now, as explained in this StackOverflow answer: https://stackoverflow.com/a/16016792/1593077 this is easily resolved by installing the "gcc-multilib" Debian package, which meant in practice installing: gcc-10-multilib lib32asan6 lib32atomic1 lib32gcc-10-dev lib32gomp1 lib32itm1 lib32quadmath0 lib32ubsan1 libc6-dev-i386 libc6-dev-x32 libc6-x32 libx32asan6 libx32atomic1 libx32gcc-10-dev libx32gcc-s1 libx32gomp1 libx32itm1 libx32quadmath0 libx32stdc++6 libx32ubsan1 I don't need to be told about all of these, but some kind of message saying "cross-platform build libraries missing" or "GCC multilib 32-bit libraries missing" or whatever. It doesn't have to be distribution-specific, but it _should_ tell me what I need to go look for.
[Bug other/104431] Provide better error message when GCC "multilib" is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104431 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2022-02-07 --- Comment #1 from Andrew Pinski --- >I was recently trying to build GCC 8.5.0 How did configure GCC? GCC has a nice error message about not having a 32bit mutlilib installed since r0-127201 (which is pre GCC 5.0). So I have no idea why you are getting the error message you are getting without exact instructions on how to reproduce this.
[Bug target/104422] nvptx: for-3.exe fail with driver 390.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104422 Roger Sayle changed: What|Removed |Added CC||roger at nextmovesoftware dot com --- Comment #1 from Roger Sayle --- Is the problem reproduceable (with the legacy driver) when the omp #pragma are removed, and the program compiled with -mainkernel and executed with nvptx-none-run-single? This eliminates the GOMP (interaction) as source of the problem.
[Bug other/104431] Provide better error message when GCC "multilib" is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104431 --- Comment #2 from Eyal Rozenberg --- (In reply to Andrew Pinski from comment #1) > How did configure GCC? I used: ./configure --disable-gnat --disable-fortran (although I'm not sure --disable-fortran does anything).
[Bug c++/104418] Error inheriting base class constructors by using-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104418 --- Comment #1 from Andrew Pinski --- MSVC and ICC reject this for the same reason as GCC. Are you sure this is not a bug in clang?
[Bug c++/104432] New: [12 Regression] ICE in operator() from filter_memfn_lookup since r12-6080
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104432
Bug ID: 104432
Summary: [12 Regression] ICE in operator() from
filter_memfn_lookup since r12-6080
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Since r12-6080-gab85331c58223e483c55ff0316a92265d7910e9b the following testcase
ICEs:
rh2051651.C: In instantiation of ‘void E< >::bar()
[with = int]’:
rh2051651.C:22:8: required from here
rh2051651.C:22:38: internal compiler error: in operator(), at cp/pt.c:16271
22 | void bar () { for (auto i : b) foo (i); }
| ^~~
0xddb7b4 operator()
../../gcc/cp/pt.c:16271
0xddbac4 filter_memfn_lookup
../../gcc/cp/pt.c:16276
0xddc1cf tsubst_baselink
../../gcc/cp/pt.c:16363
0xdf6444 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:20864
0xdf42e3 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:20494
0xdeed6a tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:19313
0xde6c18 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18326
0xde8c90 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18557
0xde9a37 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18655
0xe0d76a instantiate_body
../../gcc/cp/pt.c:26236
0xe0f136 instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.c:26529
0xe0f4d2 instantiate_pending_templates(int)
../../gcc/cp/pt.c:26608
0xc10624 c_parse_final_cleanups()
../../gcc/cp/decl2.c:5097
0xf5edcd c_common_parse_file()
../../gcc/c-family/c-opts.c:1260
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/104432] [12 Regression] ICE in operator() from filter_memfn_lookup since r12-6080
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104432 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |12.0 Status|UNCONFIRMED |NEW CC||ppalka at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2022-02-07
[Bug c++/104432] [12 Regression] ICE in operator() from filter_memfn_lookup since r12-6080
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104432 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug c++/104433] New: [modules] Importing and using std::make_shared causes linker errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104433
Bug ID: 104433
Summary: [modules] Importing and using
std::make_shared causes linker errors
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lhlaurini at hotmail dot com
Target Milestone: ---
Greetings.
I found that by importing and trying to use std::make_shared, some
symbols seem to not be defined. Example:
$ cat main.cpp
import ;
int main()
{
std::make_shared();
}
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.0 (GCC)
$ g++ -fmodules-ts -x c++-system-header memory
$ g++ -fmodules-ts main.cpp
/usr/bin/ld: /tmp/ccezjsm1.o: in function `std::_Sp_make_shared_tag::_S_ti()':
main.cpp:(.text._ZNSt19_Sp_make_shared_tag5_S_tiEv[_ZNSt19_Sp_make_shared_tag5_S_tiEv]+0x7):
undefined reference to `std::_Sp_make_shared_tag::_S_ti()::__tag'
collect2: error: ld returned 1 exit status
$ g++-12 -v
Using built-in specs.
COLLECT_GCC=g++-12
COLLECT_LTO_WRAPPER=/home/username/.local/stow/gcc/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/username/.local
--enable-languages=c,c++ --disable-bootstrap --disable-multilib
--with-system-zlib --program-suffix=-12
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220207 (experimental) (GCC)
$ g++-12 -fmodules-ts -x c++-system-header memory
$ g++-12 -fmodules-ts main.cpp
/usr/bin/ld: /tmp/cca9Gc2j.o: in function `std::_Sp_make_shared_tag::_S_ti()':
main.cpp:(.text._ZNSt19_Sp_make_shared_tag5_S_tiEv[_ZNSt19_Sp_make_shared_tag5_S_tiEv]+0x5):
undefined reference to `std::_Sp_make_shared_tag::_S_ti()::__tag'
/usr/bin/ld: /tmp/cca9Gc2j.o: in function
`std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count()':
main.cpp:(.text._ZNSt14__shared_countILN9__gnu_cxx12_Lock_policyE2EED2Ev[_ZNSt14__shared_countILN9__gnu_cxx12_Lock_policyE2EED5Ev]+0x23):
undefined reference to
`std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release()'
collect2: error: ld returned 1 exit status
As you can see the code fails on both gcc 11.1 (as packaged by Arch Linux) and
the latest gcc. There are more errors with the newer version, but these are
caused by a change in libstdc++.
>From some quick investigation, I found that the errors seem to be occur when
importing a header which either:
1. has a function that returns a static constexpr variable;
2. defines a member function of a class specialization outside the class
template declaration (using inline or not).
Additionally, I also found that defining a member function outside the
(non-template) class declaration also causes the error, unless it's marked
inline, but this problem doesn't seem to be directly triggered by .
This is my attempt to create some simpler test cases for showing the bug(s):
$ cat header.hpp
struct A
{
static const int& f()
{
static constexpr int x = 0;
return x;
}
};
struct B
{
static void f1();
static void f2();
};
void B::f1()
{
}
// This is ok
inline void B::f2()
{
}
template
struct C
{
static void f1();
static void f2();
};
template <>
void C::f1()
{
}
template <>
inline void C::f2()
{
}
$ cat main.cpp
import "header.hpp";
int main()
{
A::f();
B::f1();
B::f2();
C::f1();
C::f2();
}
$ g++ -fmodules-ts -x c++-header header.hpp
$ g++ -fmodules-ts main.cpp
/usr/bin/ld: /tmp/ccMu0ee3.o: in function `main':
main.cpp:(.text+0xa): undefined reference to `B::f1()'
/usr/bin/ld: main.cpp:(.text+0x14): undefined reference to `C::f1()'
/usr/bin/ld: main.cpp:(.text+0x19): undefined reference to `C::f2()'
/usr/bin/ld: /tmp/ccMu0ee3.o: in function `A::f()':
main.cpp:(.tex
