[Bug c++/110295] [10/11/12/13/14 Regression] ICE in dwarf2out_finish with local class with inherited operator delete in a templated function and -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110295 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:963f87f8a65ec82f503ac4334a3da83b0a8a43b2 commit r14-1958-g963f87f8a65ec82f503ac4334a3da83b0a8a43b2 Author: Richard Biener Date: Mon Jun 19 09:23:16 2023 +0200 debug/110295 - mixed up early/late debug for member DIEs When we process a scope typedef during early debug creation and we have already created a DIE for the type when the decl is TYPE_DECL_IS_STUB and this DIE is still in limbo we end up just re-parenting that type DIE instead of properly creating a DIE for the decl, eventually picking up the now completed type and creating DIEs for the members. Instead this is currently defered to the second time we come here, when we annotate the DIEs with locations late where now the type DIE is no longer in limbo and we fall through doing the job for the decl. The following makes sure we perform the necessary early tasks for this by continuing with the decl DIE creation after setting a parent for the limbo type DIE. PR debug/110295 * dwarf2out.cc (process_scope_var): Continue processing the decl after setting a parent in case the existing DIE was in limbo. * g++.dg/debug/pr110295.C: New testcase.
[Bug c++/110295] [10/11/12/13 Regression] ICE in dwarf2out_finish with local class with inherited operator delete in a templated function and -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110295 Richard Biener changed: What|Removed |Added Known to work||14.0 Summary|[10/11/12/13/14 Regression] |[10/11/12/13 Regression] |ICE in dwarf2out_finish |ICE in dwarf2out_finish |with local class with |with local class with |inherited operator delete |inherited operator delete |in a templated function and |in a templated function and |-g |-g Known to fail|14.0| Priority|P3 |P2 --- Comment #5 from Richard Biener --- Fixed on trunk sofar.
[Bug fortran/110311] [gfortran 14.0 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 Jürgen Reuter changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #2 from Jürgen Reuter --- Actually, it could have been this commit here: 2023-06-13 Harald Anlauf Mikael Morin PR fortran/86277 * trans-array.cc (gfc_trans_allocate_array_storage): When passing a zero-sized array with fixed (= non-dynamic) size, allocate temporary by the caller, not by the callee.
[Bug target/109541] [12 regression] ICE in extract_constrain_insn on when building rhash-1.4.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109541 Eric Botcazou changed: What|Removed |Added Summary|[12/13 regression] ICE in |[12 regression] ICE in |extract_constrain_insn on |extract_constrain_insn on |when building rhash-1.4.3 |when building rhash-1.4.3 Resolution|--- |FIXED Target Milestone|12.4|13.2 Status|ASSIGNED|RESOLVED --- Comment #21 from Eric Botcazou --- Fixed on 13 branch and mainline.
[Bug fortran/110311] [14 Regression] gfortran 14.0 regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0 Summary|[gfortran 14.0 regression] |[14 Regression] gfortran ||14.0 regression
[Bug c++/110312] -Wcast-align=strict warning despite alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110312 Richard Biener changed: What|Removed |Added Last reconfirmed||2023-06-20 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- I think the warning isn't useful at least, maybe it can be improved to not diagnose in the case where we can see an appropriately aligned decl (with some effort).
[Bug fortran/92887] [F2008] Passing nullified/disassociated pointer or unalloc allocatable to OPTIONAL + VALUE dummy fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92887
--- Comment #7 from Mikael Morin ---
(In reply to anlauf from comment #6)
> (In reply to Mikael Morin from comment #5)
> > (In reply to anlauf from comment #4)
> > > @@ -6396,7 +6399,28 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol *
> > > sym,
> > > && fsym->ts.type != BT_CLASS
> > > && fsym->ts.type != BT_DERIVED)
> > > {
> > > - if (e->expr_type != EXPR_VARIABLE
> > > + /* F2018:15.5.2.12 Argument presence and
> > > +restrictions on arguments not present. */
> > > + if (e->expr_type == EXPR_VARIABLE
> > > + && (e->symtree->n.sym->attr.allocatable
> > > + || e->symtree->n.sym->attr.pointer))
> >
> > Beware of expressions like derived%alloc_comp or derived%pointer_comp which
> > don't match the above.
>
> Right. This is fixable by using
>
>
> && (gfc_expr_attr (e).allocatable
> || gfc_expr_attr (e).pointer))
>
> instead.
>
Sure. Easy. :-)
> > > @@ -7072,6 +7096,42 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol *
> > > sym,
> > > }
> > > }
> > >
> > > + /* F2023:15.5.3, 15.5.4: Actual argument expressions are evaluated
> > > + before they are associated and a procedure is executed. */
> > > + if (e && e->expr_type != EXPR_VARIABLE && !gfc_is_constant_expr
> > > (e))
> > > + {
> > > + /* Create temporary except for functions returning pointers that
> > > + can appear in a variable definition context. */
> >
> > Maybe explain *why* we have to create a temporary, that is some data
> > references may become undefined by the procedure call (intent(out) dummies)
> > so we have to evaluate values depending on them beforehand (PR 92178).
>
> That is one reason. Another one, also pointed out in PR92178 by Tobias'
> review
> of Steve's draft, is the first testcase at
>
> https://gcc.gnu.org/legacy-ml/gcc-patches/2019-10/msg01970.html
>
Not sure I understand. Looks like the same reason to me. Or maybe my words
are not clear enough.
> This is reminiscent to an issue reported for the MERGE intrinsic (pr107874,
> fixed so far, but there is a remaining issue in pr105371).
>
I don't see how pr107874 or pr105371 are related to this.
> > > + need_temp = true;
> > > + }
> > > +
> > > + if (need_temp)
> > > + {
> > > + if (cond_temp == NULL_TREE)
> > > + parmse.expr = gfc_evaluate_now (parmse.expr, &parmse.pre);
> >
> > I'm not sure about this. The condition to set need_temp looks quite general
> > (especially it matches non-scalar cases, doesn't it?), but
> > gfc_conv_expr_reference should already take care of creating a variable, so
> > that a temporary is missing only for value dummies, I think. I would rather
> > move this to the place specific to value dummies.
>
> I agree in principle. The indentation level is already awful in the specific
> place, which calls for thoughts about refactoring that mega-loop over the
> arguments than currently spans far more than 1000 source code lines.
>
Yes. The situation is severely out of hand there. We could just outline the
for loop body to a separate function, but I'm not sure it would by us much.
We could use different classes defining the argument passing convention (by
reference, by value with an extra argument, with array container, with class
container, etc) and dispatch to the methods of those classes. But it's
difficult to have a global understanding of what is needed here.
> > > + else
> >
> > I would rather move the else part to the place above where cond_temp is set,
> > so that the code is easier to follow.
> >
> > > + {
> > > + /* "Conditional temporary" to handle variables that possibly
> > > + cannot be dereferenced. Use null value as fallback. */
> > > + tree dflt_temp;
> > > + gcc_assert (e->ts.type != BT_DERIVED && e->ts.type != BT_CLASS);
> > > + gcc_assert (e->rank == 0);
> > > + dflt_temp = gfc_create_var (TREE_TYPE (parmse.expr), "temp");
> > > + TREE_STATIC (dflt_temp) = 1;
> > > + TREE_CONSTANT (dflt_temp) = 1;
> > > + TREE_READONLY (dflt_temp) = 1;
> > > + DECL_INITIAL (dflt_temp) = build_zero_cst (TREE_TYPE (dflt_temp));
> > > + parmse.expr = fold_build3_loc (input_location, COND_EXPR,
> > > + TREE_TYPE (parmse.expr),
> > > + cond_temp,
> > > + parmse.expr, dflt_temp);
> > > + parmse.expr = gfc_evaluate_now (parmse.expr, &parmse.pre);
> > > + }
> > > + }
> > > +
> > > +
> > >if (fsym && need_interface_mapping && e)
> > > gfc_add_interface_mapping (&mapping, fsym, &parmse, e);
> > >
>
> I agree that it was a bad idea to merge the patches for these two PRs just
> because temporaries are needed.
[Bug target/110313] [14 Regression] GCN Fiji reload ICE in 'process_alt_operands'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110313 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0
[Bug target/110011] -mfull-toc (-mfp-in-toc) yields incorrect _Float128 constants on power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110011 --- Comment #11 from CVS Commits --- The releases/gcc-11 branch has been updated by Kewen Lin : https://gcc.gnu.org/g:bccc9960eb728bfd890c9388593bd166efcd0591 commit r11-10865-gbccc9960eb728bfd890c9388593bd166efcd0591 Author: Kewen Lin Date: Mon Jun 12 01:07:52 2023 -0500 rs6000: Don't use TFmode for 128 bits fp constant in toc [PR110011] As PR110011 shows, when encoding 128 bits fp constant into toc, we adopts REAL_VALUE_TO_TARGET_LONG_DOUBLE which is to find the first float mode with LONG_DOUBLE_TYPE_SIZE bits of precision, it would be TFmode here. But the 128 bits fp constant can be with mode IFmode or KFmode, which doesn't necessarily have the same underlying float format as the one of TFmode, like this PR exposes, with option -mabi=ibmlongdouble TFmode has ibm_extended_format while KFmode has ieee_quad_format, mixing up the formats (the encoding/decoding ways) would cause unexpected results. This patch is to make it use constant's own mode instead of TFmode for real_to_target call. PR target/110011 gcc/ChangeLog: * config/rs6000/rs6000.c (output_toc): Use the mode of the 128-bit floating constant itself for real_to_target call. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr110011.c: New test. (cherry picked from commit 388809f2afde874180da0669c669e241037eeba0)
[Bug target/109932] ICE in in extract_insn, at recog.cc:2791 on ppc64le with -mno-vsx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109932
--- Comment #8 from CVS Commits ---
The releases/gcc-11 branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:db291447877aae67979ce3655fcc6fc877f57c6a
commit r11-10866-gdb291447877aae67979ce3655fcc6fc877f57c6a
Author: Kewen Lin
Date: Tue Jun 20 01:40:52 2023 -0500
rs6000: Guard __builtin_{un,}pack_vector_int128 with vsx [PR109932]
As PR109932 shows, builtins __builtin_{un,}pack_vector_int128
should be guarded under vsx rather than power7, as their
corresponding bif patterns have the conditions TARGET_VSX
and VECTOR_MEM_ALTIVEC_OR_VSX_P (V1TImode). This patch is to
ensure __builtin_{un,}pack_vector_int128 only available under
vsx.
PR target/109932
gcc/ChangeLog:
* config/rs6000/rs6000-builtin.def (BU_VSX_MISC_2): New macro.
({un,}pack_vector_int128): Use BU_VSX_MISC_2 instead of
BU_P7_MISC_2.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr109932-1.c: New test.
* gcc.target/powerpc/pr109932-2.c: New test.
[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized and optimizations saying that the uninitialized has a nonzero bits of 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 --- Comment #17 from Aldy Hernandez --- (In reply to Andrew Pinski from comment #4) > Phiopt does this: > ``` > v_13 == 1 ? 1 : LookupFlags_6 > Matching expression match.pd:1990, gimple-match-5.cc:23 > Matching expression match.pd:1990, gimple-match-5.cc:23 > Matching expression match.pd:2479, gimple-match-4.cc:35 > Matching expression match.pd:2482, gimple-match-3.cc:66 > Matching expression match.pd:2489, gimple-match-2.cc:58 > Matching expression match.pd:1947, gimple-match-7.cc:20 > Applying pattern match.pd:4742, gimple-match-7.cc:15326 > Folded into the sequence: > _17 = v_13 == 1; > _18 = LookupFlags_6 | _17; > Removing basic block 5 > ;; basic block 5, loop depth 1 > ;; pred: 4 > ;; succ: 6 > ``` > As zero_one_valued_p returns true for LookupFlags_6 because > tree_nonzero_bits/get_nonzero_bits returns 1 for it. > > So it is ranger in the end that returns that it has a nonzero bits of 1. > Which is completely wrong as LookupFlags_6 is defined by: > # LookupFlags_6 = PHI > > > Which has an uninitialized variable in it which is not defined at what its > value would be BTW, it doesn't seem ranger would be involved here at all, since this bug happens with -O1, and evrp nor VRP* run at this level. The only other way ranger could be involved at -O1 is through DOM threading's use of ranger, but phiopt1 from which your dump above comes from, runs before DOM. I realize further downthread y'all conclude this is an unitialized issue, but I'm just trying to understand how ranger could have been involved. FWIW, there are other passes which set global nonzero bits at -O1, most notably CCP. Theoretically any pass which calls set_range_info() or set_nonzero_bits() would alter everyone's view of a range (strlen pass, PRE, DOM, sprintf, CCP, etc). And way down on the list of likely scenarios is fold_range() being called with a global query object. This would get ranger involved in folding something with known global values (no additional lookups), but it's unlikely. You probably got a nonzero bits from some other pass.
[Bug middle-end/78405] OpenSSL v1.0.1g RSA 4096 test is 20% slower under GCC 6.2 than under Clang 3.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78405 Artem S. Tashkinov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Artem S. Tashkinov --- Hopefully this has been fixed.
[Bug middle-end/79704] [meta-bug] Phoronix Test Suite compiler performance issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79704 Bug 79704 depends on bug 78405, which changed state. Bug 78405 Summary: OpenSSL v1.0.1g RSA 4096 test is 20% slower under GCC 6.2 than under Clang 3.9 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78405 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX
[Bug rtl-optimization/110307] ICE in move_insn, at haifa-sched.cc:5473 when building Ruby on alpha with -fPIC -O2 (or -fpeephole2 -fschedule-insns2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110307 --- Comment #5 from Alexander Monakov --- It's not necessary yet for this particular bug, but might be helpful for future bugs (if disk space is not an issue).
[Bug target/91804] [10/11/12/13/14 regression] r265398 breaks gcc.target/powerpc/vec-rlmi-rlnm.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91804 Ajit Kumar Agarwal changed: What|Removed |Added CC||aagarwa at gcc dot gnu.org --- Comment #8 from Ajit Kumar Agarwal --- I don't see extra xxlor with latest gcc trunk. I think this is fixed. I think we should close this PR. Thanks & Regards Ajit
[Bug target/110313] [14 Regression] GCN Fiji reload ICE in 'process_alt_operands'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110313 --- Comment #1 from Andrew Stubbs --- This ICE also affect the following standalone test failures (raw amdgcn, no offloading): gfortran.dg/assumed_rank_21.f90 gfortran.dg/finalize_38.f90 gfortran.dg/finalize_38a.f90
[Bug target/110313] [14 Regression] GCN Fiji reload ICE in 'process_alt_operands'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110313 Thomas Schwinge changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-06-20 --- Comment #2 from Thomas Schwinge --- I had found, and wanted to report the same thing: (In reply to Andrew Stubbs from comment #1) > This ICE also affect the following standalone test failures (raw amdgcn, no > offloading): > > gfortran.dg/assumed_rank_21.f90 > gfortran.dg/finalize_38.f90 > gfortran.dg/finalize_38a.f90 ... but with the additional detail: ICE in their '-O3 -g' testing variants only.
[Bug target/109932] ICE in in extract_insn, at recog.cc:2791 on ppc64le with -mno-vsx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109932
--- Comment #9 from CVS Commits ---
The releases/gcc-10 branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:98763feef24b58573fa9e6c6eedaccc1e932bb46
commit r10-11455-g98763feef24b58573fa9e6c6eedaccc1e932bb46
Author: Kewen Lin
Date: Tue Jun 20 01:40:52 2023 -0500
rs6000: Guard __builtin_{un,}pack_vector_int128 with vsx [PR109932]
As PR109932 shows, builtins __builtin_{un,}pack_vector_int128
should be guarded under vsx rather than power7, as their
corresponding bif patterns have the conditions TARGET_VSX
and VECTOR_MEM_ALTIVEC_OR_VSX_P (V1TImode). This patch is to
ensure __builtin_{un,}pack_vector_int128 only available under
vsx.
PR target/109932
gcc/ChangeLog:
* config/rs6000/rs6000-builtin.def (BU_VSX_MISC_2): New macro.
({un,}pack_vector_int128): Use BU_VSX_MISC_2 instead of
BU_P7_MISC_2.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr109932-1.c: New test.
* gcc.target/powerpc/pr109932-2.c: New test.
(cherry picked from commit db291447877aae67979ce3655fcc6fc877f57c6a)
[Bug target/110313] [14 Regression] GCN Fiji reload ICE in 'process_alt_operands'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110313 --- Comment #3 from Andrew Stubbs --- It's curious that this affects the Fiji target only, and not the newer targets at all. There are some additional register options for multiply instructions, some differences to atomics, but mostly the difference is that Fiji's "flat" load and store instructions can't have offsets.
[Bug target/109932] ICE in in extract_insn, at recog.cc:2791 on ppc64le with -mno-vsx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109932 Kewen Lin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Kewen Lin --- Should be fixed everywhere.
[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224
--- Comment #3 from Paul Thomas ---
Hi Neil,
Thanks for posting this bug report.
> !x%var_ptr() = 2.0 ! THIS IS NOT REJECTED AS EXPECTED
Why do you think that this should be rejected? As I understood it, this was
permitted by the definition of 'variable' in F2008:6.2 and in F2018:9.2 C902
and the definition of assignment in 10.2.1.1.
ifort accepts it and does the same with it as gfortran. nagfor throws up a
syntax error for which I am going to file a bug report unless you come up with
a contrary interpretation.
I am just going to post a fix for this PR with the testcase:
! { dg-do compile }
!
! Contributed by Neil Carlson
!
module mod
type :: foo
real, pointer :: var
contains
procedure :: var_ptr
end type
contains
function var_ptr(this) result(ref)
class(foo) :: this
real, pointer :: ref
ref => this%var
end function
end module
program main
use mod
type(foo) :: x
allocate (x%var, source = 2.0)
associate (var => x%var_ptr())
var = 1.0
end associate
if (x%var .ne. 1.0) stop 1
x%var_ptr() = 2.0
if (x%var .ne. 2.0) stop 2
deallocate (x%var)
end program
Regards
Paul
[Bug rtl-optimization/110237] gcc.dg/torture/pr58955-2.c is miscompiled by RTL scheduling after reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=110309
Ever confirmed|0 |1
Last reconfirmed||2023-06-20
--- Comment #3 from Richard Biener ---
This looks like the same issue as PR110309. We have
(insn 38 35 39 3 (set (mem:V16SI (plus:DI (reg:DI 40 r12 [orig:90 _22 ] [90])
(const:DI (plus:DI (symbol_ref:DI ("b") [flags 0x2] )
(const_int -4 [0xfffc] [1 MEM
[(int *)vectp_b.12_28]+0 S64 A32])
(vec_merge:V16SI (reg:V16SI 20 xmm0 [118])
(mem:V16SI (plus:DI (reg:DI 40 r12 [orig:90 _22 ] [90])
(const:DI (plus:DI (symbol_ref:DI ("b") [flags 0x2]
)
(const_int -4 [0xfffc] [1 MEM
[(int *)vectp_b.12_28]+0 S64 A32])
so instead of a masked load we see a vec_merge with a (mem:V16SI ...)
based on the vectp_b.12_28 pointer that has full size but the load of b[1]
we try disambiguate against refers to int b[10] which is too small for
a load of 64 bytes so we disambiguate based on that.
So quite likely a duplicate.
[Bug debug/110308] [14 Regression] ICE on audiofile-0.3.6: RTL: vartrack: Segmentation fault in mode_to_precision(machine_mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110308 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||ptomsich at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- ICE started with r14-1873-g6a2e8dcbbd4bab3
[Bug rtl-optimization/110317] New: ICE at -O2 and -O3 with "-fno-tree-pre -fno-tree-dce -fno-tree-dse -fselective-scheduling2": in move_exprs_to_boundary, at sel-sched.cc:5228
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110317
Bug ID: 110317
Summary: ICE at -O2 and -O3 with "-fno-tree-pre -fno-tree-dce
-fno-tree-dse -fselective-scheduling2": in
move_exprs_to_boundary, at sel-sched.cc:5228
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
It appears to be a regression from 11.*, and affects 12.* and later.
Compiler Explorer: https://godbolt.org/z/Y893oebTc
[511] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230620 (experimental) [master r14-924-gd709841ae0f] (GCC)
[512] %
[512] % gcctk -O2 -fno-tree-pre -fno-tree-dce -fno-tree-dse
-fselective-scheduling2 small.c
during RTL pass: sched2
small.c: In function ‘main’:
small.c:19:1: internal compiler error: in move_exprs_to_boundary, at
sel-sched.cc:5228
19 | }
| ^
0x7ce44c move_exprs_to_boundary
../../gcc-trunk/gcc/sel-sched.cc:5228
0x7ce44c schedule_expr_on_boundary
../../gcc-trunk/gcc/sel-sched.cc:5436
0xf7f03f fill_insns
../../gcc-trunk/gcc/sel-sched.cc:5578
0xf7f03f schedule_on_fences
../../gcc-trunk/gcc/sel-sched.cc:7353
0xf7f03f sel_sched_region_2
../../gcc-trunk/gcc/sel-sched.cc:7491
0xf81258 sel_sched_region_1
../../gcc-trunk/gcc/sel-sched.cc:7533
0xf82876 sel_sched_region(int)
../../gcc-trunk/gcc/sel-sched.cc:7634
0xf82876 sel_sched_region(int)
../../gcc-trunk/gcc/sel-sched.cc:7619
0xf82a19 run_selective_scheduling()
../../gcc-trunk/gcc/sel-sched.cc:7720
0xf6412d rest_of_handle_sched2
../../gcc-trunk/gcc/sched-rgn.cc:3743
0xf6412d execute
../../gcc-trunk/gcc/sched-rgn.cc:3890
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[513] %
[513] % cat small.c
int a, c, d, e, f;
char b;
extern int l(int p);
int main() {
int h, i;
if (a)
while (1) {
int j = 6 / a * b, k = j || 6 ^ e;
k = h;
h = d || b;
i = (6 / a + ~f + i) >> -c;
if (!b)
l(h);
if (d)
l(i);
i = 6;
}
return 0;
}
[Bug debug/110308] [14 Regression] ICE on audiofile-0.3.6: RTL: vartrack: Segmentation fault in mode_to_precision(machine_mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110308
Jakub Jelinek changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek ---
First change with that commit already appears in the reload pass:
(insn 12 6 8 2 (set (reg:DI 5 di [84])
-(plus:DI (reg/f:DI 7 sp)
+(plus:DI (reg/f:DI 7 sp [orig:103 state+8 ] [103])
(const_int 8 [0x8]))) "pr110308.C":11:22 249 {*leadi}
(nil))
and many further changes of this kind appear later in cprop_hardreg.
The vartrack ICE is because regno_reg_rtx[103] is NULL and so PSEUDO_REGNO_MODE
(103) ICEs.
For debug info, propagation of the sp with the extra debug info related stuff
(ORIGINAL_REGNO and REG_ATTRS) is I think very harmful, but I admit I haven't
tried to understand why that change has been done.
[Bug fortran/110311] [14 Regression] gfortran 14.0 regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #3 from Jürgen Reuter ---
I redid this change here:
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index
e1c75e9fe0266d760b635f0dc7869a00ce53bf48..e7c51bae052b1e0e3a60dee35484c093d28d4653
100644 (file)
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -1117,7 +1117,7 @@ gfc_trans_allocate_array_storage (stmtblock_t * pre,
stmtblock_t * post,
desc = info->descriptor;
info->offset = gfc_index_zero_node;
- if (size == NULL_TREE || integer_zerop (size))
+ if (size == NULL_TREE || (dynamic && integer_zerop (size)))
{
/* A callee allocated array. */
gfc_conv_descriptor_data_set (pre, desc, null_pointer_node);
and it seems this is not the cause of the problem :(
[Bug tree-optimization/110251] [13/14 Regression] Hang at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110251 Jakub Jelinek changed: What|Removed |Added CC||andrew.carlotti at arm dot com, ||jakub at gcc dot gnu.org Keywords|needs-bisection | --- Comment #3 from Jakub Jelinek --- Started with r13-4208-geea52e38dd81b663254
[Bug tree-optimization/110251] [13/14 Regression] Hang at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110251 Jakub Jelinek changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||amacleod at redhat dot com --- Comment #4 from Jakub Jelinek --- Seems that change results in complete unrolling of the for (; e; a++) e &= e - 1; loop, dunno if it wouldn't be better to pattern match it as some .CTZ instead, unrolling it 16 times seems excessive. Anyway, it is then ranger that hangs.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 109858, which changed state. Bug 109858 Summary: [14 Regression] r14-172 caused some SPEC2017 bmk to degrade on Power https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/109858] [14 Regression] r14-172 caused some SPEC2017 bmk to degrade on Power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858 Kewen Lin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |crazylht at gmail dot com --- Comment #12 from Kewen Lin --- Already fixed by Hongtao's fix.
[Bug c/110318] New: Unused string literal is retained in assembler file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110318
Bug ID: 110318
Summary: Unused string literal is retained in assembler file
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
~~~c
typedef typeof(sizeof 0) size_t;
int memcmp(const void *, const void *, size_t);
int demo(const char *);
int demo(const char *p) {
const char *start = p;
while (*p == 'C')
p++;
if (p - start == 2 && memcmp(start, "if", 2) == 0)
return 2;
if (p - start == 6 && memcmp(start, "ifndef", 6) == 0)
return 6;
return 0;
}
~~~
$ uname -a
NetBSD nbcurr.roland-illig.de 10.99.3 NetBSD 10.99.3 (GENERIC) #0: Fri Apr 21
02:17:32 UTC 2023
$ gcc-12.2.0 -O2 -S code.c
$ grep string code.s
.string "ifndef"
The string "ifndef" is retained, even though it is not used in the code,
because the comparison is inlined. Curiously, the string "if" is removed.
Both strings should be removed, as they are unnecessary.
[Bug c/110318] Unused string literal is retained in assembler file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110318
--- Comment #1 from Roland Illig ---
A variant on the same theme:
~~~c
typedef typeof(sizeof 0) size_t;
int memcmp(const void *, const void *, size_t);
int demo(const char *s) {
if (memcmp(s, "12345678", 8) == 0)
return 8;
if (memcmp(s, "1234567", 7) == 0)
return 7;
if (memcmp(s, "123456", 6) == 0)
return 6;
if (memcmp(s, "12345", 5) == 0)
return 5;
if (memcmp(s, "1234", 4) == 0)
return 4;
if (memcmp(s, "123", 3) == 0)
return 3;
if (memcmp(s, "12", 2) == 0)
return 2;
if (memcmp(s, "1", 1) == 0)
return 1;
return 0;
}
~~~
It looks as if the string literals are retained if their length is not a power
of two.
[Bug middle-end/110318] Unused string literal is retained in assembler file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110318 --- Comment #2 from Andrew Pinski --- Note I suspect the linker will remove unused strings in the final executable though.
[Bug middle-end/110318] Unused string literal is retained in assembler file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110318 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #3 from Xi Ruoyao --- (In reply to Andrew Pinski from comment #2) > Note I suspect the linker will remove unused strings in the final executable > though. With --gc-sections sometimes the entire .rodata.str1.1 section can be removed, but if it contains an used string it won't happen. -fdata-sections won't separate the strings into multiple sections either.
[Bug tree-optimization/110177] [12/13/14 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r12-2305-g398572c1544
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110177 --- Comment #3 from Theodoros Theodoridis --- I think the correct bisection is: r11-3063-gfcae5121154 (or its parent r11-3062-g90e88fd376b) I can't build its parent but with its grandparent r11-3061-g1644d7f4c1c the call to foo is eliminated: gcc-1644d7f4c1c4f99231d7de5e35fa7ce2d2e2c4c6 -Os test.c -S -o /dev/stdout main: movqg(%rip), %rax movl$0, c(%rip) movq(%rax), %rdx movq%rdx, f(%rip) testq %rdx, %rdx je .L2 movq(%rax), %rax movq%rax, f(%rip) testq %rax, %rax jne .L8 movl$9, c(%rip) .L2: pushq %rax xorl%eax, %eax call__assert_fail .L8: movl$27, c(%rip) xorl%eax, %eax movl$0, e(%rip) ret r11-3063-gfcae5121154 with ranger disabled generates the same code gcc-fcae5121154d1c3382b056bcc2c563cedac28e74 -Os test.c -S -o /dev/stdout: main: movqg(%rip), %rax movl$0, c(%rip) movq(%rax), %rdx movq%rdx, f(%rip) testq %rdx, %rdx je .L2 movq(%rax), %rax movq%rax, f(%rip) testq %rax, %rax jne .L8 movl$9, c(%rip) .L2: pushq %rax xorl%eax, %eax call__assert_fail .L8: movl$27, c(%rip) xorl%eax, %eax movl$0, e(%rip) ret with ranger enabled it doesn't eliminate the call and generates mode code: gcc-fcae5121154d1c3382b056bcc2c563cedac28e74 -Os -fevrp-mode=ranger test.c -S -o /dev/stdout: main: pushq %rcx movle(%rip), %edi xorl%eax, %eax xorl%edx, %edx movl$0, c(%rip) movqg(%rip), %r8 .L2: movl%eax, %esi cmpl$27, %eax je .L20 testl %eax, %eax je .L3 movl%edi, %ecx movl%eax, %r9d movl%eax, %r10d sall%cl, %r9d movl%r9d, %ecx sarl%cl, %r10d testw %r10w, %r10w je .L3 movl%eax, c(%rip) .L3: movq(%r8), %rcx addl$9, %eax movq%rcx, f(%rip) testq %rcx, %rcx jne .L8 testb %dl, %dl je .L4 movl%esi, c(%rip) .L4: xorl%eax, %eax call__assert_fail .L8: movb$1, %dl jmp .L2 .L20: testb %dl, %dl je .L6 movl$27, c(%rip) .L6: cmpq$0, f(%rip) movl$0, e(%rip) jne .L7 callfoo .L7: xorl%eax, %eax popq%rdx ret
[Bug target/54089] [SH] Refactor shift patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 --- Comment #83 from Alexander Klepikov --- Created attachment 55367 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55367&action=edit Collapsed libcall and additional loop move invariants patch v3 I digged other targets and I found that cfun->machine can point to user-defined structure. So I implemented per-function data through it. Loop optimizer now runs when -O2 or higher is specified and only for functions where ashrsi3 libcall was expanded. I also ran all tests I did before a few times.
[Bug rtl-optimization/110237] gcc.dg/torture/pr58955-2.c is miscompiled by RTL scheduling after reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
--- Comment #4 from Hongtao.liu ---
(In reply to Richard Biener from comment #3)
> This looks like the same issue as PR110309. We have
>
> (insn 38 35 39 3 (set (mem:V16SI (plus:DI (reg:DI 40 r12 [orig:90 _22 ] [90])
> (const:DI (plus:DI (symbol_ref:DI ("b") [flags 0x2]
> )
> (const_int -4 [0xfffc] [1 MEM
> [(int *)vectp_b.12_28]+0 S64 A32])
> (vec_merge:V16SI (reg:V16SI 20 xmm0 [118])
> (mem:V16SI (plus:DI (reg:DI 40 r12 [orig:90 _22 ] [90])
> (const:DI (plus:DI (symbol_ref:DI ("b") [flags 0x2]
> )
> (const_int -4 [0xfffc] [1 MEM
> [(int *)vectp_b.12_28]+0 S64 A32])
>
> so instead of a masked load we see a vec_merge with a (mem:V16SI ...)
> based on the vectp_b.12_28 pointer that has full size but the load of b[1]
> we try disambiguate against refers to int b[10] which is too small for
> a load of 64 bytes so we disambiguate based on that.
/* If the pointer based access is bigger than the variable they cannot
alias. This is similar to the check below where we use TBAA to
increase the size of the pointer based access based on the dynamic
type of a containing object we can infer from it. */
poly_int64 dsize2;
if (known_size_p (size1) --- should be unknown??
&& poly_int_tree_p (DECL_SIZE (base2), &dsize2)
&& known_lt (dsize2, size1))
return false;
Should we set MEM_SIZE_KNOWN_P to false for maskstore/maskload?
It seems to me maxsize should be 64bytes, but real size should be unknown.
[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 --- Comment #4 from Neil Carlson --- Hi Paul, > !x%var_ptr() = 2.0 ! THIS IS NOT REJECTED AS EXPECTED I could have phrased the comment better. I expected that assignment to be okay (i.e., not rejected) and it wasn't. Sorry for the confusion.
[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 --- Comment #5 from Neil Carlson --- >> !x%var_ptr() = 2.0 ! THIS IS NOT REJECTED AS EXPECTED > > I could have phrased the comment better. I expected that assignment to be okay > (i.e., not rejected) and it wasn't. Sorry for the confusion. Argh, I'm just making things worse. That assignment was okay and WAS what I expected.
[Bug libgomp/110319] New: Performance slowdown using a pointer to perform a reduction vs. using a normal variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110319 Bug ID: 110319 Summary: Performance slowdown using a pointer to perform a reduction vs. using a normal variable Product: gcc Version: 11.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: lorien.lopez at unizar dot es CC: jakub at gcc dot gnu.org Target Milestone: --- When performing an OpenMP sum reduction into a regular variable, GCC uses a "lock cmpxchg" instruction. In contrast, when the reduction is performed into a pointer, it uses an OpenMP atomic region. The second version is several times slower in an Intel Skylake CPU. The original report can be found in Stack Overflow: https://stackoverflow.com/questions/76480632/performance-slowdown-using-a-pointer-to-perform-a-reduction-vs-using-a-normal-v
[Bug rtl-optimization/110237] gcc.dg/torture/pr58955-2.c is miscompiled by RTL scheduling after reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
--- Comment #5 from rguenther at suse dot de ---
On Tue, 20 Jun 2023, crazylht at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
>
> --- Comment #4 from Hongtao.liu ---
> (In reply to Richard Biener from comment #3)
> > This looks like the same issue as PR110309. We have
> >
> > (insn 38 35 39 3 (set (mem:V16SI (plus:DI (reg:DI 40 r12 [orig:90 _22 ]
> > [90])
> > (const:DI (plus:DI (symbol_ref:DI ("b") [flags 0x2]
> > )
> > (const_int -4 [0xfffc] [1 MEM
> > [(int *)vectp_b.12_28]+0 S64 A32])
> > (vec_merge:V16SI (reg:V16SI 20 xmm0 [118])
> > (mem:V16SI (plus:DI (reg:DI 40 r12 [orig:90 _22 ] [90])
> > (const:DI (plus:DI (symbol_ref:DI ("b") [flags 0x2]
> > )
> > (const_int -4 [0xfffc] [1 MEM
> > [(int *)vectp_b.12_28]+0 S64 A32])
> >
> > so instead of a masked load we see a vec_merge with a (mem:V16SI ...)
> > based on the vectp_b.12_28 pointer that has full size but the load of b[1]
> > we try disambiguate against refers to int b[10] which is too small for
> > a load of 64 bytes so we disambiguate based on that.
>
>
> /* If the pointer based access is bigger than the variable they cannot
> alias. This is similar to the check below where we use TBAA to
> increase the size of the pointer based access based on the dynamic
> type of a containing object we can infer from it. */
> poly_int64 dsize2;
> if (known_size_p (size1) --- should be unknown??
> && poly_int_tree_p (DECL_SIZE (base2), &dsize2)
> && known_lt (dsize2, size1))
> return false;
>
> Should we set MEM_SIZE_KNOWN_P to false for maskstore/maskload?
> It seems to me maxsize should be 64bytes, but real size should be unknown.
Yes, you shouldn't have MEM_ATTRs that indicate the size is known.
[Bug middle-end/110318] Unused string literal is retained in assembler file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110318
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-06-20
--- Comment #4 from Richard Biener ---
Confirmed. The issue is that we create a constant pool entry at RTL expansion
time and when the last use vanishes during RTL optimization the unused constant
pool entries are not pruned.
In this case we initially emit
;; _5 = __builtin_memcmp_eq (p_8(D), "ifndef", 6);
(insn 34 33 35 (set (reg/f:DI 94)
(symbol_ref/f:DI ("*.LC0") [flags 0x2] )) "t.c":13:24 -1
(nil))
(insn 35 34 36 (set (reg:CCZ 17 flags)
(compare:CCZ (mem:SI (reg/v/f:DI 91 [ p ]) [0 MEM [(void
*)p_8(D)]+0 S4 A8])
(const_int 1684956777 [0x646e6669]))) "t.c":13:24 -1
(nil))
(jump_insn 36 35 37 (set (pc)
(if_then_else (ne (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref 43)
(pc))) "t.c":13:24 -1
(nil))
(insn 37 36 38 (set (reg:CCZ 17 flags)
(compare:CCZ (mem:HI (plus:DI (reg/v/f:DI 91 [ p ])
(const_int 4 [0x4])) [0 MEM [(void *)p_8(D)]+4
S2 A8])
(const_int 26213 [0x6665]))) "t.c":13:24 -1
(nil))
(jump_insn 38 37 39 (set (pc)
(if_then_else (ne (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref 43)
(pc))) "t.c":13:24 -1
(nil))
(insn 39 38 40 (set (reg:SI 85 [ _5 ])
(const_int 0 [0])) "t.c":13:24 -1
(nil))
... so even RTL expansion doesn't end up using the string literal so
maybe this particular case can be catched early. Pruning the constant
pool would be nice of course but we emit that quite early.
I'm quite sure there's duplicate bugreports about this.
[Bug rtl-optimization/110317] [12/13/14 Regression] ICE at -O2 and -O3 with "-fno-tree-pre -fno-tree-dce -fno-tree-dse -fselective-scheduling2": in move_exprs_to_boundary, at sel-sched.cc:5228
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110317 Richard Biener changed: What|Removed |Added Version|unknown |13.1.1 Keywords||ice-on-valid-code Target Milestone|--- |12.4 Blocks||85099 Known to work||11.3.1 Summary|ICE at -O2 and -O3 with |[12/13/14 Regression] ICE |"-fno-tree-pre |at -O2 and -O3 with |-fno-tree-dce -fno-tree-dse |"-fno-tree-pre |-fselective-scheduling2": |-fno-tree-dce -fno-tree-dse |in move_exprs_to_boundary, |-fselective-scheduling2": |at sel-sched.cc:5228|in move_exprs_to_boundary, ||at sel-sched.cc:5228 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85099 [Bug 85099] [meta-bug] selective scheduling issues
[Bug fortran/108961] Segfault when associating to pointer from C_F_POINTER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108961 --- Comment #4 from Paul Thomas --- Created attachment 55368 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55368&action=edit Fix for this PR I couldn't see what the problem was initially and so I put this PR to one side. I still have it in my PR87477 (associate meta-bug) folder and so it gets tested fairly often at the moment. It now stands out as one of three failures out of 37 tests. Since I am putting off the other two since they require a "bitty" fix, I came back to it and blow me if I didn't see the problem in a few minutes. The fix took a few more minutes. If you build gfortran from source, let me know how you get on. I'll submit the patch a bit later today. Cheers Paul
[Bug target/110320] New: ELFv2 pc-rel ABI extension allows using r2 as a volatile register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110320 Bug ID: 110320 Summary: ELFv2 pc-rel ABI extension allows using r2 as a volatile register Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: bergner at gcc dot gnu.org Target Milestone: --- The PC-Relative ABI extension to the ELFv2 ABI defines register r2 (normally the TOC register in ELFv1 & ELFv2) as a volatile register available for use in the register allocator. Currently GCC doesn't make use of that fact, so this is a missed-optimization opportunity.
[Bug target/110320] ELFv2 pc-rel ABI extension allows using r2 as a volatile register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110320 Peter Bergner changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jeevitha at gcc dot gnu.org Keywords||missed-optimization Last reconfirmed||2023-06-20 Target||powerpc64le-linux CC||dje at gcc dot gnu.org, ||meissner at gcc dot gnu.org, ||segher at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Peter Bergner --- Jeevitha is working on a patch to support this.
[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 --- Comment #6 from Paul Thomas --- (In reply to Neil Carlson from comment #5) > >> !x%var_ptr() = 2.0 ! THIS IS NOT REJECTED AS EXPECTED > > > > I could have phrased the comment better. I expected that assignment to be > > okay > > (i.e., not rejected) and it wasn't. Sorry for the confusion. > > Argh, I'm just making things worse. That assignment was okay and WAS what I > expected. OK - these things happen :-) Was it as a result of the nagfor error, perhaps? If so, have you already sent them a bug report? Paul
[Bug c++/110256] passing concept to concept compiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110256 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||ppalka at gcc dot gnu.org Last reconfirmed||2023-06-20 Ever confirmed|0 |1 --- Comment #3 from Patrick Palka --- We also incorrectly accept: template concept c = true; template concept d = true; d auto x = 0;
[Bug analyzer/110198] [14 regression] g++.dg/analyzer/pr100244.C fails after r14-1632-g9589a46ddadc8b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110198 --- Comment #3 from Hans-Peter Nilsson --- (In reply to Benjamin Priour from comment #2) > Yes sorry for the regression. I confirmed it myself too on x86_64-linux-gnu. > I wrote a fix immediately yesterday, and I am currently regtesting it. > > It is promising as I quickly ran the test only for the analyzer test cases, > all of them now are back to their expected behavior. > > I'm sending the patch as soon as the regtesting finishes, so probably > tomorrow evening, as my keys on the compiler farm are not yet synced. Any news on this? I don't see anything posted to gcc-patches@ later than 2023-06-09. If you have trouble testing the patch that you mention, please send it anyway with a message mentioning your troubles.
[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 --- Comment #7 from Neil Carlson --- > Was it as a result of the nagfor error, perhaps? If so, have you already sent > them a bug report? I actually didn't originally try that commented-out assignment with nagfor, but confirm that it gets it wrong as you said. I'll give you the honor of submitting a bug report. nagfor does get the ASSOCIATE part correct, which was what I was what I was after in the first place when I encountered this bug.
[Bug analyzer/110172] Leak false positives from -fanalyzer with -fexceptions (even on C code)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110172 --- Comment #1 from David Malcolm --- Quoting: https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fexceptions """ -fexceptions Enable exception handling. Generates extra code needed to propagate exceptions. For some targets, this implies GCC generates frame unwind information for all functions, which can produce significant data size overhead, although it does not affect execution. If you do not specify this option, GCC enables it by default for languages like C++ that normally require exception handling, and disables it for languages like C that do not normally require it. However, you may need to enable this option when compiling C code that needs to interoperate properly with exception handlers written in C++. You may also wish to disable this option if you are compiling older C++ programs that don’t use exception handling. """
[Bug analyzer/110198] [14 regression] g++.dg/analyzer/pr100244.C fails after r14-1632-g9589a46ddadc8b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110198 --- Comment #4 from Benjamin Priour --- Yes, has been fixed and regtested a week ago. However I was in vacation last week. I will submit it shortly. though I would prefer to perform another regtesting on a freshly pulled trunk first. Benjamin. On Tue, Jun 20, 2023 at 4:37 PM hp at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110198 > > --- Comment #3 from Hans-Peter Nilsson --- > (In reply to Benjamin Priour from comment #2) > > Yes sorry for the regression. I confirmed it myself too on > x86_64-linux-gnu. > > I wrote a fix immediately yesterday, and I am currently regtesting it. > > > > It is promising as I quickly ran the test only for the analyzer test > cases, > > all of them now are back to their expected behavior. > > > > I'm sending the patch as soon as the regtesting finishes, so probably > > tomorrow evening, as my keys on the compiler farm are not yet synced. > > Any news on this? I don't see anything posted to gcc-patches@ later than > 2023-06-09. > > If you have trouble testing the patch that you mention, please send it > anyway > with a message mentioning your troubles. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug debug/110308] [14 Regression] ICE on audiofile-0.3.6: RTL: vartrack: Segmentation fault in mode_to_precision(machine_mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110308
--- Comment #7 from manolis.tsamis at vrull dot eu ---
Some context for the commit:
This change is originally part of an late rtl pass to optimize memory accesses.
There are a lot of cases (especially involving local arrays) that generate
reduntant stack pointer adds for address calculation which can get reduced to
`mov reg, sp`, but without actually propagating these we don't gain something.
In general it should be good to allow propagation of the stack pointer if that
is correct.
Now for the actual issue, it looks like my change for that was a bit carelees
and I didn't properly understand the context of cprop-hardreg.
> For debug info, propagation of the sp with the extra debug info related stuff
> (ORIGINAL_REGNO and REG_ATTRS) is I think very harmful, but I admit I haven't
> tried to understand why that change has been done.
Yes, the attachment of ORIGINAL_REGNO and REG_ATTRS to the stack pointer has
been accidental and is of course wrong.
I have a proposed change below that fixes the segfault by not setting
ORIGINAL_REGNO/REG_ATTRS for the stack pointer. My understanding is that this
should be fine, but I'm still testing that.
> So I think there are 2 bugs here. First the lost of debugging info because of
> ch, and the latent segfault.
I'm still looking into the difference in the debug statements.
--cut here--
--- a/gcc/regcprop.cc
+++ b/gcc/regcprop.cc
@@ -423,7 +423,7 @@ maybe_mode_change (machine_mode orig_mode, machine_mode
copy_mode,
It's unclear if we need to do the same for other special registers. */
if (regno == STACK_POINTER_REGNUM)
{
- if (orig_mode == new_mode)
+ if (orig_mode == new_mode && new_mode == GET_MODE (stack_pointer_rtx))
return stack_pointer_rtx;
else
return NULL_RTX;
@@ -487,9 +487,14 @@ find_oldest_value_reg (enum reg_class cl, rtx reg, struct
value_data *vd)
new_rtx = maybe_mode_change (oldmode, vd->e[regno].mode, mode, i,
regno);
if (new_rtx)
{
- ORIGINAL_REGNO (new_rtx) = ORIGINAL_REGNO (reg);
- REG_ATTRS (new_rtx) = REG_ATTRS (reg);
- REG_POINTER (new_rtx) = REG_POINTER (reg);
+ if (new_rtx != stack_pointer_rtx)
+ {
+ ORIGINAL_REGNO (new_rtx) = ORIGINAL_REGNO (reg);
+ REG_ATTRS (new_rtx) = REG_ATTRS (reg);
+ REG_POINTER (new_rtx) = REG_POINTER (reg);
+ }
+ else if (REG_POINTER (new_rtx) != REG_POINTER (reg))
+ return NULL_RTX;
return new_rtx;
}
}
@@ -965,15 +970,27 @@ copyprop_hardreg_forward_1 (basic_block bb, struct
value_data *vd)
if (validate_change (insn, &SET_SRC (set), new_rtx, 0))
{
- ORIGINAL_REGNO (new_rtx) = ORIGINAL_REGNO (src);
- REG_ATTRS (new_rtx) = REG_ATTRS (src);
- REG_POINTER (new_rtx) = REG_POINTER (src);
- if (dump_file)
- fprintf (dump_file,
-"insn %u: replaced reg %u with %u\n",
-INSN_UID (insn), regno, REGNO (new_rtx));
- changed = true;
- goto did_replacement;
+ bool can_change;
+ if (new_rtx != stack_pointer_rtx)
+ {
+ ORIGINAL_REGNO (new_rtx) = ORIGINAL_REGNO (src);
+ REG_ATTRS (new_rtx) = REG_ATTRS (src);
+ REG_POINTER (new_rtx) = REG_POINTER (src);
+ can_change = true;
+ }
+ else
+ can_change
+ = (REG_POINTER (new_rtx) == REG_POINTER (src));
+
+ if (can_change)
+ {
+ if (dump_file)
+ fprintf (dump_file,
+"insn %u: replaced reg %u with %u\n",
+INSN_UID (insn), regno, REGNO (new_rtx));
+ changed = true;
+ goto did_replacement;
+ }
}
/* We need to re-extract as validate_change clobbers
recog_data. */(In reply to Jakub Jelinek from comment #5)
--cut here--
[Bug debug/110308] [14 Regression] ICE on audiofile-0.3.6: RTL: vartrack: Segmentation fault in mode_to_precision(machine_mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110308 --- Comment #8 from ptomsich at gcc dot gnu.org --- @mtsamis: Could you attach the proposed patch as an attachment (to allow easy application and testing that this resolves the ICE)?
[Bug debug/110308] [14 Regression] ICE on audiofile-0.3.6: RTL: vartrack: Segmentation fault in mode_to_precision(machine_mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110308 ptomsich at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug debug/110308] [14 Regression] ICE on audiofile-0.3.6: RTL: vartrack: Segmentation fault in mode_to_precision(machine_mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110308 --- Comment #9 from Jeffrey A. Law --- Right. It's fairly common with fold-mem-offsets to end up rewriting the address arithmetic such that we'll have an sp->gpr copy of some sort in the IL. We'd really like to be able to cprop that copy away. After Manolis's fixes to that code it seemed independently commit-able so I acked it while we iterate on the fold-mem-offsets work. It's tickled a few problems, but nothing that seems unmanageable right now.
[Bug debug/110308] [14 Regression] ICE on audiofile-0.3.6: RTL: vartrack: Segmentation fault in mode_to_precision(machine_mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110308 --- Comment #10 from manolis.tsamis at vrull dot eu --- Created attachment 55369 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55369&action=edit ICE-fix-proposal-1
[Bug c++/110321] New: Double precision comaprison does not seem to work well when -std=c++17 option is selected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110321
Bug ID: 110321
Summary: Double precision comaprison does not seem to work well
when -std=c++17 option is selected
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: serge.ayoun at outlook dot com
Target Milestone: ---
The following code:
int main(int, char**)
{
double a = 2.2;
if ( a == 2.2) return 1;
return 0;
}
compiled and link with the following instruction:
g++ -O0 -m32 -std=c++17
with gcc 11.1, returns 1 as expected
with gcc 13.1, returns 0.
when -std=c++17 is removed, both return 0 as expected.
for exact reproduction See:
https://godbolt.org/#z:OYLghAFBqd5QCxAYwPYBMCmBRdBLAF1QCcAaPECAMzwBtMA7AQwFtMQByARg9KtQYEAysib0QXACx8BBAKoBnTAAUAHpwAMvAFYTStJg1DIApACYAQuYukl9ZATwDKjdAGFUtAK4sGe1wAyeAyYAHI%2BAEaYxHoADqgKhE4MHt6%2BcQlJAkEh4SxRMVy2mPaOAkIETMQEqT5%2BRXaYDskVVQQ5YZHRegqV1bXpDX3twZ353VwAlLaoXsTI7BzBBADULEzBEMukK8gIVQBUB5MmGgCCJgDsFiunZysPK%2BizEfQrTLcAzAAiK2YAdGYTJ8rOdHis8FQVhB3l9vsDfgCzJMVsRMAQ5gwVlxgTc7uC0RjiFiNLjbucrt8ONNaJwAKy8PwcLSkVCcNzWawrBSzeaYW5mT48UgETTU6YAaxAkku/zpAE4uBoAGzyz6fDRceXyy7Kun6TiSRli1mcXgKEAaEVi6ZwWAwRAoVAsWJ0aLkShoF1umLALhC0hYABueAWADU8JgAO4AeVijE4wpotAI0QtEAiJoiwSqAE9E7xs8xiLmYxFtE1RdxeF62IIYwxaPnmbwsBEvMA3GJaBbq4HMOsjOIW4G8GjmkHML2WZhVE0vKmC%2BRBCUTbQ8BFiHmPFgTQRiHgWAXplQDMAFBHo3GE33%2BIIRGJ2FIZIJFCp1CPdEUDEYUJzLPoG4WpA0yoLEZQML2AC0MYaCsUEsJ8Zjwb06AIqYljWFwly8Kgk7EAeWDARA0yNM0zgQK4Az1KQgSjHkBQZIkEHUUxWQMB0DETMUpQtMMrENCUlZ8W0nFdIUtj8Z4dQ9MMYnjIUpG8gsEg0vSxojmyHArKoAAcypQcqkgrMAyDINinz/Fw0K4IQJACkKky8FWWiTJKIB0latIcEapBHpI8r/Boum6ZcZjypqyqXPpdKXKQTIslp5qWtaLa2g6EBIF6rr0GQFAQNlPogH6XBFMGoaYJesbxkySZ0KmxDppmI5FnmS6tSWZYVg4S61owBANk2Jpth2Xa0D2S5YIOwDDiy%2BDjo4k7Trws7zoufbLKuI7rpu24YIsLL7oex58GeF6RtVN5JrID7iM%2Bd7yEoagmroZj6IYxj/jYO3EaB4HJNBsHwYhyFQah6FfdhuH4YRU7wKRQnkX4lEMO40mDLRqPyYxRTxMxyQCaQePsdj3FkRBrT9OjNHkyJ1SkxJvRtITTP0/R4mqTMcwqVMBocAy8UmlpOn6YZxmmeZpVWTZ%2BBEMQDlTM5NrTAgmBMFgMQkXzvlHp5/yKlwZiXBo8q6Uh/qSJ8guaWatgpS54qkFKdIApIwVqiqqq6RoGiCvq3mfBpiW2w7bl82YQe4SHyukPhiTOJIQA%3D
Thanks,
Serge
[Bug c++/110321] Double precision comaprison does not seem to work well when -std=c++17 option is selected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110321 --- Comment #1 from Jonathan Wakely --- As described in the manual, sincve GCC 13.1 -fexcess-precision=standard is enabled by -std=c++NN (but not by -std=gnu++NN). This means the literal 2.2 is represented with excess precision, and so is not equal to the same value converted to double. You can use (a == (double)2.2) to make the comparison work.
[Bug c++/110321] Double precision comaprison does not seem to work well when -std=c++17 option is selected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110321 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Invalid as explained. More over this is basically bug 323 in reverse.
[Bug c++/110321] Double precision comaprison does not seem to work well when -std=c++17 option is selected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110321 Jonathan Wakely changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #3 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #1) > You can use (a == (double)2.2) to make the comparison work. Or use -std=gnu++17, or use -std=c++17 -fexcess-precision=fast
[Bug analyzer/110172] Leak false positives from -fanalyzer with -fexceptions (even on C code)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110172 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #2 from Xi Ruoyao --- According to https://www.gnu.org/software/libc/manual/html_node/Registering-New-Conversions.html, people may custom vfprintf with printf_function. If the printf_function is implemented in C++ and throws, then yes there is indeed a leak. So the warning is not so false with Glibc.
[Bug target/110313] [14 Regression] GCN Fiji reload ICE in 'process_alt_operands'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110313 Thomas Schwinge changed: What|Removed |Added CC||manolis.tsamis at vrull dot eu --- Comment #4 from Thomas Schwinge --- (In reply to myself from comment #2) > I had found, and wanted to report the same thing: > > (In reply to Andrew Stubbs from comment #1) > > This ICE also affect the following standalone test failures (raw amdgcn, no > > offloading): > > > > gfortran.dg/assumed_rank_21.f90 > > gfortran.dg/finalize_38.f90 > > gfortran.dg/finalize_38a.f90 > > ... but with the additional detail: ICE in their '-O3 -g' testing variants > only. Also, there appears to be some non-determinism involved here: in another run of the exact same toolchain build I've then also seen the ICE for 'gfortran.dg/PR100906.f90' (again, '-O3 -g' testing variant only). (In reply to myself from comment #0) > I'm now bisecting. With commit r14-1873-g6a2e8dcbbd4bab374b27abea375bf7a921047800 "cprop_hardreg: Enable propagation of the stack pointer if possible" reverted, we're back to normal, both for GCN target and for GCN offloading. That, however, is completely outside my area of competence -- if such a thing exists at all... ;-)
[Bug analyzer/110172] Leak false positives from -fanalyzer with -fexceptions (even on C code)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110172 --- Comment #3 from Jonathan Wakely --- I mentioned that on IRC. I'm not sure glibc can even handle exceptions from those functions. Is that supported at all? Does printf clean up its own allocations and locks in that case? IMHO it should be UB for printf_function to exit via an exception.
[Bug c/110322] New: Be more helpful when a varargs function is called in a wrong way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110322
Bug ID: 110322
Summary: Be more helpful when a varargs function is called in a
wrong way
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
~~~c
#include
#include
static void __attribute__((__format__(__printf__, 1, 2)))
my_printf(const char *fmt, ...)
{
va_list ap;
va_start(ap, fmt);
fprintf(stderr, fmt, ap);
va_end(ap);
}
int
main(int argc, char **argv)
{
my_printf("%d", 4);
my_printf("%.*s\n", 5, "hello, world");
return 0;
}
~~~
In the above program, I am accidentally trying to call fprintf with a va_list,
instead of the correct vfprintf. GCC warns:
sl.c:10:2: error: format not a string literal, argument types not checked
[-Werror=format-nonliteral]
10 | fprintf(stderr, fmt, ap);
| ^~~
In this situation, where my only mistake was to forget the 'v' from the
function name, GCC should not complain that the format string is not a string
literal, but rather that I'm calling the wrong function.
[Bug analyzer/110172] Leak false positives from -fanalyzer with -fexceptions (even on C code)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110172 --- Comment #4 from Xi Ruoyao --- (In reply to Jonathan Wakely from comment #3) > I mentioned that on IRC. I'm not sure glibc can even handle exceptions from > those functions. Is that supported at all? Does printf clean up its own > allocations and locks in that case? IMHO it should be UB for printf_function > to exit via an exception. They compile vfprintf.c with -fexceptions, so it looks like they are at least attempting to make it work. And if they don't want to support it at all, they should've use __nothrow attribute or noexcept(true) for vfprintf then we wouldn't see the warning.
[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 --- Comment #8 from Paul Thomas --- Hi Neil, > I actually didn't originally try that commented-out assignment with nagfor, > but confirm that it gets it wrong as you said. I'll give you the honor of > submitting a bug report. Will do! > > nagfor does get the ASSOCIATE part correct, which was what I was what I was > after in the first place when I encountered this bug. In your gfortran-bugs, I think that the following are the associate bugs: gfortran-20230529.f90 Still doesn't identify co-array associate name gfortran-20220127.f90 ICE in verify_gimple gfortran-20171124a.f90 <= compiles and runs correctly from 8-branch to trunk gfortran-20160821.f90-ditto- (i) Have I got the lot? (ii) Are there existing PRs for the two most recent? Regards and thanks for your support Paul
[Bug target/110313] [14 Regression] GCN Fiji reload ICE in 'process_alt_operands'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110313 --- Comment #5 from Andrew Stubbs --- One thing that is unusual about the GCN stack pointer is that it's actually two registers. Could this be breaking some cprop assumptions? GCN can't fit an address in one (SImode) register so all (DImode) pointers require a pair of registers. We had to rework the dwarf stack representation code for this architecture, so I'm pretty sure no other port does this.
[Bug c++/110323] New: Code for explicit instantiation of template method of template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110323
Bug ID: 110323
Summary: Code for explicit instantiation of template method of
template class
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: stlim0727 at gmail dot com
Target Milestone: ---
Code for explicit instantiation of a template method of a class is not
generated with following code:
$ cat > test.cpp
#include
constexpr int VAL = 1;
struct foo {
template
void bar(typename std::conditional::type arg) {
}
};
template void foo::bar<1>(int arg);
Code is not generated for g++11 and above versions:
$ g++12 -S -o- -c test.cpp
.file "test.cpp"
.text
.section.rodata
.align 4
.type _ZL3VAL, @object
.size _ZL3VAL, 4
_ZL3VAL:
.long 1
.ident "GCC: (GNU) 12.1.1 20220628 (Red Hat 12.1.1-3)"
.section.note.GNU-stack,"",@progbits
However, the code is generated if I replace "B==VAL" with "B==1" or if I use
g++10 and below versions:
$ g++8 -S -o- -c test.cpp
.file "test.cpp"
.text
.section.rodata
.align 4
.type _ZL3VAL, @object
.size _ZL3VAL, 4
_ZL3VAL:
.long 1
.section
.text._ZN3foo3barILi1EEEvNSt11conditionalIXeqT_L_ZL3VALEEifE4typeE,"axG",@progbits,_ZN3foo3barILi1EEEvNSt11conditionalIXeqT_L_ZL3VALEEifE4typeE,comdat
.align 2
.weak _ZN3foo3barILi1EEEvNSt11conditionalIXeqT_L_ZL3VALEEifE4typeE
.type _ZN3foo3barILi1EEEvNSt11conditionalIXeqT_L_ZL3VALEEifE4typeE,
@function
_ZN3foo3barILi1EEEvNSt11conditionalIXeqT_L_ZL3VALEEifE4typeE:
.LFB9:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
movq%rdi, -8(%rbp)
movl%esi, -12(%rbp)
nop
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE9:
.size _ZN3foo3barILi1EEEvNSt11conditionalIXeqT_L_ZL3VALEEifE4typeE,
.-_ZN3foo3barILi1EEEvNSt11conditionalIXeqT_L_ZL3VALEEifE4typeE
.ident "GCC: (GNU) 8.5.0 20210514 (Red Hat 8.5.0-18)"
.section.note.GNU-stack,"",@progbits
[Bug analyzer/110172] Leak false positives from -fanalyzer with -fexceptions (even on C code)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110172 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #5 from Florian Weimer --- printf is a cancellation point, and can therefore throw. Cancellation is in POSIX, it's not a glibc extension. I don't think anyone has ever brought up the need for cancellation handlers that call va_end. I do not think it is possible to write them. POSIX should probably specify that va_end is a no-op, or that it is not required if vfprintf etc. are canceled.
[Bug rtl-optimization/110237] gcc.dg/torture/pr58955-2.c is miscompiled by RTL scheduling after reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
--- Comment #6 from Hongtao.liu ---
(In reply to rguent...@suse.de from comment #5)
> On Tue, 20 Jun 2023, crazylht at gmail dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
> >
> > --- Comment #4 from Hongtao.liu ---
> > (In reply to Richard Biener from comment #3)
> > > This looks like the same issue as PR110309. We have
> > >
> > > (insn 38 35 39 3 (set (mem:V16SI (plus:DI (reg:DI 40 r12 [orig:90 _22 ]
> > > [90])
> > > (const:DI (plus:DI (symbol_ref:DI ("b") [flags 0x2]
> > > )
> > > (const_int -4 [0xfffc] [1 MEM
> > > [(int *)vectp_b.12_28]+0 S64 A32])
> > > (vec_merge:V16SI (reg:V16SI 20 xmm0 [118])
> > > (mem:V16SI (plus:DI (reg:DI 40 r12 [orig:90 _22 ] [90])
> > > (const:DI (plus:DI (symbol_ref:DI ("b") [flags 0x2]
> > > )
> > > (const_int -4 [0xfffc] [1 MEM
> > > [(int *)vectp_b.12_28]+0 S64 A32])
> > >
> > > so instead of a masked load we see a vec_merge with a (mem:V16SI ...)
> > > based on the vectp_b.12_28 pointer that has full size but the load of b[1]
> > > we try disambiguate against refers to int b[10] which is too small for
> > > a load of 64 bytes so we disambiguate based on that.
> >
> >
> > /* If the pointer based access is bigger than the variable they cannot
> > alias. This is similar to the check below where we use TBAA to
> > increase the size of the pointer based access based on the dynamic
> > type of a containing object we can infer from it. */
> > poly_int64 dsize2;
> > if (known_size_p (size1) --- should be unknown??
> > && poly_int_tree_p (DECL_SIZE (base2), &dsize2)
> > && known_lt (dsize2, size1))
> > return false;
> >
> > Should we set MEM_SIZE_KNOWN_P to false for maskstore/maskload?
> > It seems to me maxsize should be 64bytes, but real size should be unknown.
>
> Yes, you shouldn't have MEM_ATTRs that indicate the size is known.
So it looks like a generic problem and better to be handled in
expand_partial_{load, store}_optab_fn?
[Bug c++/110323] [11/12/13/14 Regression] Code for explicit instantiation of template method of template class not generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110323 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |11.5 Summary|Code for explicit |[11/12/13/14 Regression] |instantiation of template |Code for explicit |method of template class|instantiation of template |not generated |method of template class ||not generated Ever confirmed|0 |1 Last reconfirmed||2023-06-20 Status|UNCONFIRMED |NEW URL|https://godbolt.org/z/x4ao4 | |dxdx| Known to work|10.4.0 |10.1.0, 9.1.0 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug ipa/110276] [13/14 Regression] ICE building efibootguard on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110276 --- Comment #4 from CVS Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:0be3a051c03965c5c0385b783837154902bc08fa commit r14-1998-g0be3a051c03965c5c0385b783837154902bc08fa Author: Martin Jambor Date: Tue Jun 20 18:15:22 2023 +0200 ipa-sra: Disable candidates with no known callers (PR 110276) In IPA-SRA we use can_be_local_p () predicate rather than just plain local call graph flag in order to figure out whether the node is a part of an external API that we cannot change. Although there are cases where this can allow more transformations, it also means we can analyze functions which have no callers at all, which is pointless. Moreover, it makes an assert of hint propagation trigger, which checks that we have looked at callers before processing hints that come from them. This has been reported as PR 110276. This patch simply adds a check that a node has at least one caller into the early checks and makes the node a non-candidate for any transformation if it does not. gcc/ChangeLog: 2023-06-16 Martin Jambor PR ipa/110276 * ipa-sra.cc (struct caller_issues): New field there_is_one. (check_for_caller_issues): Set it. (check_all_callers_for_issues): Check it. gcc/testsuite/ChangeLog: 2023-06-16 Martin Jambor PR ipa/110276 * gcc.dg/ipa/pr110276.c: New test.
[Bug bootstrap/110324] New: [14 Regression][bootstrap, nvptx] build/genpreds: Internal error: RTL check: expected elt 2 type 'T', have 's' due to r14-1949-g957ae904065917
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110324 Bug ID: 110324 Summary: [14 Regression][bootstrap, nvptx] build/genpreds: Internal error: RTL check: expected elt 2 type 'T', have 's' due to r14-1949-g957ae904065917 Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: tnfchris at gcc dot gnu.org Target Milestone: --- Target: nvptx-none Since r14-1949-g957ae90406591739b68e95ad49a0232faeb74217 New compact syntax for insn and insn_split in Machine Descriptions. The nvptx bootstrap fails with: build/genpreds -c src/gcc-mainline/gcc/common.md src/gcc-mainline/gcc/config/nvptx/nvptx.md > tmp-constrs.h build/genpreds: Internal error: RTL check: expected elt 2 type 'T', have 's' (rtx define_cond_exec) in convert_syntax, at gensupport.cc:883 genconditions: Internal error: RTL check: expected elt 2 type 'T', have 's' (rtx define_cond_exec) in convert_syntax, at gensupport.cc:883 build/genpreds src/gcc-mainline/gcc/common.md src/gcc-mainline/gcc/config/nvptx/nvptx.md > tmp-preds.cc build/genpreds: Internal error: Makefile:2625: recipe for target 's-preds-h' failed RTL check: expected elt 2 type 'T', have 's' (rtx define_cond_exec) in convert_syntax, at gensupport.cc:883
[Bug c++/110321] Double precision comaprison does not seem to work well when -std=c++17 option is selected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110321 --- Comment #4 from Serge Ayoun --- Thanks guys for your help
[Bug bootstrap/110325] New: [14 regression] Build failure on arm64 (libiberty/physmem.c:83:1: error: ‘+nofp’ feature modifier is incompatible with the use of floating-point types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110325 Bug ID: 110325 Summary: [14 regression] Build failure on arm64 (libiberty/physmem.c:83:1: error: ‘+nofp’ feature modifier is incompatible with the use of floating-point types) Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org Target Milestone: --- I've been slacking with my ~daily tests, so this started in the last 2 weeks or so. I suspect it's really more the last few days. ``` /var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./libiberty/physmem.c: In function ‘physmem_total’: /var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./libiberty/physmem.c:83:1: error: ‘+nofp’ feature modifier is incompatible with the use of floating-point types 83 | physmem_total (void) | ^ /var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./libiberty/physmem.c: In function ‘physmem_available’: /var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./libiberty/physmem.c:187:1: error: ‘+nofp’ feature modifier is incompatible with the use of floating-point types 187 | physmem_available (void) | ^ make[3]: *** [Makefile:1191: physmem.o] Error 1 ``` This is at commit 0be3a051c03965c5c0385b783837154902bc08fa. Let me know what more information is needed.
[Bug bootstrap/110325] [14 regression] Build failure on arm64 (libiberty/physmem.c:83:1: error: ‘+nofp’ feature modifier is incompatible with the use of floating-point types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110325 --- Comment #1 from Sam James --- Created attachment 55373 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55373&action=edit build.lo
[Bug tree-optimization/109943] [13/14 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r13-6834-g41ade3399bd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109943
--- Comment #2 from Theodoros Theodoridis ---
Not sure if it's useful but the following also started with the same commit:
https://godbolt.org/z/Tqha4K976
Given the following code:
void foo(void);
static int d, e, h;
static int *f = &e, *q;
static int **g = &f;
static long j, p;
static short k;
void __assert_fail() __attribute__((__noreturn__));
static short(a)(short b, short c) {
if (!(((b) >= -90) && ((b) <= 0))) {
__builtin_unreachable();
}
return c == 0 || b == 1 && c == 1 ?: b % c;
}
static int **i();
static int l(int *m, long n) {
j = 0 >= d;
k = j - 34834;
if (a(-n, k)) *g = m;
if (f == 0 || f == &e)
;
else
__assert_fail();
for (; h; ++h)
;
return *m;
}
static int *o() {
l(f, 90);
g = i();
if (f == 0 || f == &e)
;
else
foo();
return &d;
}
static int **i() {
a(p, h);
return &q;
}
int main() { o(); }
gcc-trunk -O2 generates:
main:
subq$8, %rsp
movqf(%rip), %rax
movqg(%rip), %rdx
movq%rax, (%rdx)
cmpq$e, %rax
je .L7
testq %rax, %rax
jne .L2
.L7:
movlh(%rip), %edx
testl %edx, %edx
je .L5
movl$0, h(%rip)
.L5:
movq$q, g(%rip)
cmpq$e, %rax
je .L6
callfoo
.L6:
xorl%eax, %eax
addq$8, %rsp
ret
.L2:
xorl%eax, %eax
call__assert_fail
gcc-12.3.0 -O2 generates:
main:
movqf(%rip), %rax
movqg(%rip), %rdx
movq%rax, (%rdx)
cmpq$e, %rax
je .L6
testq %rax, %rax
jne .L2
.L6:
movlh(%rip), %edx
testl %edx, %edx
je .L5
movl$0, h(%rip)
.L5:
movq$q, g(%rip)
xorl%eax, %eax
ret
.L2:
pushq %rax
xorl%eax, %eax
call__assert_fail
[Bug c/110322] Be more helpful when a varargs function is called in a wrong way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110322 Andrew Pinski changed: What|Removed |Added Blocks||87403 --- Comment #1 from Andrew Pinski --- Confirmed. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug c/110322] Be more helpful when a varargs function is called in a wrong way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110322 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-06-20 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- .
[Bug c/110322] Be more helpful when a varargs function is called in a wrong way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110322 --- Comment #3 from Andrew Pinski --- Note -Wformat-nonliteral is not enabled by default either (though IIRC Debian and Ubuntu turn it on by default).
[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 --- Comment #9 from Neil Carlson --- > > (i) Have I got the lot? > I believe so. > (ii) Are there existing PRs for the two most recent? > I always try to report the bugs at the same time they go into my "database". The first is here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110033 But the second one I assumed was an opencoarrays problem; or at least I decided that was the place to start. My report is here: https://github.com/sourceryinstitute/OpenCoarrays/issues/748 But I never heard back from them -- the project has been effectively abandoned as far as I'm concerned -- and I had forgotten to follow up on it. However the problem may actually be on the gfortran side. You're welcome to enter a PR for it, or I can if you would prefer that. -Neil
[Bug bootstrap/110325] [14 regression] Build failure on arm64 (libiberty/physmem.c:83:1: error: ‘+nofp’ feature modifier is incompatible with the use of floating-point types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110325 --- Comment #2 from Andrew Pinski --- What is the host compiler? It is the host compiler that is failing with -mcpu=native. Can you add -v to the failing command in /var/tmp/portage/sys-devel/gcc-14.0.0./work/build/build-aarch64-unknown-linux-gnu/libiberty , e.g. aarch64-unknown-linux-gnu-gcc -c -DHAVE_CONFIG_H -pipe -mcpu=native -fdiagnostics-color=always -ggdb3 -O2 -I. -I/var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -Wshadow=local -pedantic -D_GNU_SOURCE -fPIC /var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./libiberty/hashtab.c -o pic/hashtab.o -v
[Bug rtl-optimization/110307] ICE in move_insn, at haifa-sched.cc:5473 when building Ruby on alpha with -fPIC -O2 (or -fpeephole2 -fschedule-insns2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110307
--- Comment #6 from Alexander Monakov ---
Cross-compiler needs HAVE_AS_EXPLICIT_RELOCS=1.
With checking enabled, we get:
t.c:8:1: error: flow control insn inside a basic block
(call_insn 97 96 98 4 (parallel [
(set (reg:DI 0 $0)
(call (mem:DI (reg:DI 27 $27) [0 S8 A64])
(const_int 0 [0])))
(set (reg:DI 29 $29)
(unspec:DI [
(reg:DI 29 $29)
(const_int 6 [0x6])
] UNSPEC_LDGP1))
(use (symbol_ref:DI ("__tls_get_addr") [flags 0x41] ))
(use (unspec [
(const_int 1 [0x1])
] UNSPEC_TLSGD_CALL))
(clobber (reg:DI 26 $26))
]) "t.c":6:22 -1
(nil)
(expr_list (use (reg:DI 16 $16))
(nil)))
during RTL pass: peephole2
dump file: t.c.313r.peephole2
t.c:8:1: internal compiler error: in rtl_verify_bb_insns, at cfgrtl.cc:2797
Insn 96 appears via:
Splitting with gen_peephole2_8 (alpha.md:5972)
scanning new insn with uid = 96.
scanning new insn with uid = 97.
scanning new insn with uid = 98.
deleting insn with uid = 25.
Insn 25 was:
(call_insn/u 25 39 26 4 (parallel [
(set (reg:DI 0 $0)
(call (mem:DI (symbol_ref:DI ("__tls_get_addr") [flags 0x41]
) [0 S8 A64])
(const_int 0 [0])))
(unspec [
(const_int 1 [0x1])
] UNSPEC_TLSGD_CALL)
(use (reg:DI 29 $29))
(clobber (reg:DI 26 $26))
]) "t.c":6:22 346 {call_value_osf_tlsgd}
(expr_list:REG_DEAD (reg:DI 16 $16)
(expr_list:REG_EH_REGION (const_int -2147483648 [0x8000])
(nil)))
(expr_list (use (reg:DI 16 $16))
(nil)))
Note the REG_EH_REGION. This is relevant because can_nonlocal_goto checks it,
so for insn 25 we knew it wouldn't return to the setjmp receiver. Applying the
peephole dropped the note.
[Bug bootstrap/110325] [14 regression] Build failure on arm64 (libiberty/physmem.c:83:1: error: ‘+nofp’ feature modifier is incompatible with the use of floating-point types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110325 --- Comment #3 from Sam James --- Host compiler is: ``` gcc (Gentoo 14.0.0 p, commit f9de5c24b9a6172d48786289035eed8f947c04c1) 14.0.0 20230616 (experimental) a371a639b76f1bdcd7a957f400b5a7c0faf30a15 Copyright (C) 2023 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ``` I'll try it with w/ GCC 13 in a minute. ``` # aarch64-unknown-linux-gnu-gcc -c -DHAVE_CONFIG_H -pipe -mcpu=native -fdiagnostics-color=always -ggdb3 -O2 -I. -I/var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -Wshadow=local -pedantic -D_GNU_SOURCE -fPIC /var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./libiberty/hashtab.c -o pic/hashtab.o -v Using built-in specs. COLLECT_GCC=aarch64-unknown-linux-gnu-gcc Target: aarch64-unknown-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./configure --host=aarch64-unknown-linux-gnu --build=aarch64-unknown-linux-gnu --prefix=/usr --bindir=/usr/aarch64-unknown-linux-gnu/gcc-bin/14 --includedir=/usr/lib/gcc/aarch64-unknown-linux-gnu/14/include --datadir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/14 --mandir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/14/man --infodir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/14/info --with-gxx-include-dir=/usr/lib/gcc/aarch64-unknown-linux-gnu/14/include/g++-v14 --with-python-dir=/share/gcc-data/aarch64-unknown-linux-gnu/14/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable-checking=yes,extra,rtl --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 14.0.0 p, commit f9de5c24b9a6172d48786289035eed8f947c04c1' --with-gcc-major-version-only --enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-fixed-point --enable-libgomp --disable-libssp --disable-libada --disable-cet --disable-systemtap --disable-valgrind-annotations --disable-vtable-verify --disable-libvtv --with-zstd --without-isl --enable-default-pie --enable-host-pie --enable-default-ssp Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20230616 (experimental) a371a639b76f1bdcd7a957f400b5a7c0faf30a15 (Gentoo 14.0.0 p, commit f9de5c24b9a6172d48786289035eed8f947c04c1) COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-c' '-D' 'HAVE_CONFIG_H' '-pipe' '-ggdb3' '-O2' '-I' '.' '-I' '/var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./libiberty/../include' '-Wextra' '-Wall' '-Wwrite-strings' '-Wc++-compat' '-Wstrict-prototypes' '-Wshadow=local' '-Wpedantic' '-D' '_GNU_SOURCE' '-fPIC' '-o' 'pic/hashtab.o' '-v' '-mlittle-endian' '-mabi=lp64' '-mcpu=ares+crc+crypto+nofp+nolse+norcpc+nordma' '-dumpdir' 'pic/' /usr/libexec/gcc/aarch64-unknown-linux-gnu/14/cc1 -quiet -v -I . -I /var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./libiberty/../include -dD -D HAVE_CONFIG_H -D _GNU_SOURCE /var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./libiberty/hashtab.c -quiet -dumpdir pic/ -dumpbase hashtab.c -dumpbase-ext .c -mlittle-endian -mabi=lp64 -mcpu=ares+crc+crypto+nofp+nolse+norcpc+nordma -ggdb3 -O2 -Wextra -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -Wshadow=local -Wpedantic -version -fdiagnostics-color=always -fPIC -o - | /usr/lib/gcc/aarch64-unknown-linux-gnu/14/../../../../aarch64-unknown-linux-gnu/bin/as -v -I . -I /var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./libiberty/../include --gdwarf-5 -EL -march=armv8.2-a+crc+profile+nofp+nolse+nordma -mabi=lp64 -o pic/hashtab.o GNU assembler version 2.39.0 (aarch64-unknown-linux-gnu) using BFD version (Gentoo 2.39 p6) 2.39.0 GNU C17 (Gentoo 14.0.0 p, commit f9de5c24b9a6172d48786289035eed8f947c04c1) version 14.0.0 20230616 (experimental) a371a639b76f1bdcd7a957f400b5a7c0faf30a15 (aarch64-unknown-linux-gnu) compiled by GNU C version 14.0.0 20230616 (experimental) a371a639b76f1bdcd7a957f400b5a7c0faf30a15, GMP version 6.2.99, MPFR version 4.2.0-p9, MPC version 1.3.1, isl version none warning: GMP header version 6.2.99 differs from library version 6.2.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory "/usr/lib/gcc/aarch64-unknown-linux-gnu/14/../../../../aarch64-unknown-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: . /var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./libiberty/../include /usr/lib/gcc/aarch64-unknown-linux-gnu/14/include /usr/local/include /usr/lib/gcc/aarch64-unknown-linux-gnu/14/include-fixed /usr/include End of search list. Compiler executable
[Bug ada/110314] Gnat failed assertion and Allocators with discriminant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110314 Marc Poulhiès changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-06-20 Ever confirmed|0 |1
[Bug tree-optimization/110326] New: [gcc 14.0 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110326 Bug ID: 110326 Summary: [gcc 14.0 regression] Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Target Milestone: --- Hi, let me open up an issue already. I believe there was a regression introduced in gcc between June 11 and June 19, as our CI with a git-clone built gcc worked last week, and fails this week. Two out of our ca. 340 functional tests fail because they return zero results. I will try to boil this down to a smaller reproducer (fingers crossed), but if you want to play around already, checkout our code from here: https://gitlab.tp.nt.uni-siegen.de/whizard/public Note that you need noweb and OCaml besides gcc/gfortran. Do in the main directory ./build_master.sh and autoreconf, then in a build directory _build do ../configure, make -j4, make -C tests/functional_tests -j4 check. The failing tests are nlo_9.run and nlo_10.run in case you want to run them already now. There was a change in the Fortran directly, by this commit below, but this was not responsible for these failures. There was a lot of work on tree-optimization in the middle-end (?) last week, so I fear this might have caused this. At the moment I am struggling to boil down what is going on. Cheers, Juergen The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:c1691509e5a8875f36c068a5ea101bf13f140948 commit r14-1795-gc1691509e5a8875f36c068a5ea101bf13f140948 Author: Harald Anlauf Date: Mon Jun 12 23:08:48 2023 +0200 Fortran: fix passing of zero-sized array arguments to procedures [PR86277] gcc/fortran/ChangeLog: PR fortran/86277 * trans-array.cc (gfc_trans_allocate_array_storage): When passing a zero-sized array with fixed (= non-dynamic) size, allocate temporary by the caller, not by the callee. gcc/testsuite/ChangeLog: PR fortran/86277 * gfortran.dg/zero_sized_14.f90: New test. * gfortran.dg/zero_sized_15.f90: New test. Co-authored-by: Mikael Morin
[Bug bootstrap/110325] [14 regression] Build failure on arm64 (libiberty/physmem.c:83:1: error: ‘+nofp’ feature modifier is incompatible with the use of floating-point types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110325 Andrew Pinski changed: What|Removed |Added Keywords||build --- Comment #4 from Andrew Pinski --- driver-aarch64.cc is either being miscompiled or has the wrong logic dealing with fp or the linux kernel is no longer printing out fp feature in /proc/cpuinfo . So can you also cat /proc/cpuinfo ?
[Bug bootstrap/110325] [14 regression] Build failure on arm64 (libiberty/physmem.c:83:1: error: ‘+nofp’ feature modifier is incompatible with the use of floating-point types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110325 --- Comment #5 from Andrew Pinski --- >-march=armv8.2-a+crc+profile+nofp+nolse+nordma This seems totally wrong
[Bug ada/110314] Gnat failed assertion and Allocators with discriminant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110314 --- Comment #1 from Marc Poulhiès --- This is new in 14, was OK when forking 13. https://ada.godbolt.org/z/TvbPxYfnP Currently bisecting.
[Bug bootstrap/110324] [14 Regression][bootstrap, nvptx] build/genpreds: Internal error: RTL check: expected elt 2 type 'T', have 's' due to r14-1949-g957ae904065917
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110324
--- Comment #1 from Tobias Burnus ---
In the debugger for 'convert_syntax', it fails immediately. The caller is:
1055case DEFINE_COND_EXEC:
1056 convert_syntax (desc, loc);
(gdb) p debug_rtx(desc)
(define_cond_exec [
(match_operator 0 ("predicate_operator")
[
(match_operand:BI 1 ("nvptx_register_operand") (""))
(match_operand:BI 2 ("const0_operand") (""))
])
] ("") ("")
[])
the check output is:
build/genpreds: Internal error: RTL check: expected elt 2 type 'T', have 's'
(rtx define_cond_exec) in convert_syntax, at gensupport.cc:883
which internally is:
templ_index = GET_CODE (x) == DEFINE_INSN ? 3 : 2;
templ = XTMPL (x, templ_index);
The first one gives '2' and then:
#define XTMPL(RTX, N) (RTL_CHECK1 (RTX, N, 'T').rt_str)
and the error string is:
751 ("RTL check: expected elt %d type '%c', have '%c' (rtx %s) in %s, at
%s:%d",
752 n, c1, GET_RTX_FORMAT (GET_CODE (r))[n], GET_RTX_NAME (GET_CODE (r)),
* * *
#define RTL_CHECK1(RTX, N, C1) __extension__\
(*({ __typeof (RTX) const _rtx = (RTX); const int _n = (N); \
const enum rtx_code _code = GET_CODE (_rtx); \
if (_n < 0 || _n >= GET_RTX_LENGTH (_code))\
rtl_check_failed_bounds (_rtx, _n, __FILE__, __LINE__, \
__FUNCTION__); \
if (GET_RTX_FORMAT (_code)[_n] != C1) \
rtl_check_failed_type1 (_rtx, _n, C1, __FILE__, __LINE__,\
__FUNCTION__); \
&_rtx->u.fld[_n]; }))
[Bug bootstrap/110325] [14 regression] Build failure on arm64 (libiberty/physmem.c:83:1: error: ‘+nofp’ feature modifier is incompatible with the use of floating-point types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110325 --- Comment #6 from Sam James --- Created attachment 55374 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55374&action=edit /proc/cpuinfo
[Bug bootstrap/110325] [14 regression] Build failure on arm64 (libiberty/physmem.c:83:1: error: ‘+nofp’ feature modifier is incompatible with the use of floating-point types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110325 Sam James changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #7 from Sam James --- Ugh, I just realised I was using --personality=arm which is almost certainly it (used bash history without checking). Sorry for the noise. I'll reopen if it still happens but I doubt it will.
[Bug go/110297] [13/14 Regression] all libgo tests fail on arm-linux-gnueabi and arm-linxu-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110297 --- Comment #5 from CVS Commits --- The master branch has been updated by Ian Lance Taylor : https://gcc.gnu.org/g:efecb298d880cda20f8d7bea2d7b500a9752ce56 commit r14-1999-gefecb298d880cda20f8d7bea2d7b500a9752ce56 Author: Ian Lance Taylor Date: Mon Jun 19 14:57:54 2023 -0700 runtime: use a C function to call mmap The final argument to mmap, of type off_t, varies. In CL 445375 we changed it to always use the C off_t type, but that broke 32-bit big-endian Linux systems. On those systems, using the C off_t type requires calling the mmap64 function. In C this is automatically handled by the file. In Go, we would have to change the magic //extern comment to call mmap64 when appropriate. Rather than try to get that right, we instead go through a C function that uses C implicit type conversions to pick the right type. Fixes PR go/110297 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/504415
[Bug go/110297] [13/14 Regression] all libgo tests fail on arm-linux-gnueabi and arm-linxu-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110297 --- Comment #6 from CVS Commits --- The releases/gcc-13 branch has been updated by Ian Lance Taylor : https://gcc.gnu.org/g:4ac89ab35884906900cde8172d2db74e1d913fec commit r13-7459-g4ac89ab35884906900cde8172d2db74e1d913fec Author: Ian Lance Taylor Date: Tue Jun 20 09:56:34 2023 -0700 runtime: use a C function to call mmap The final argument to mmap, of type off_t, varies. In CL 445375 we changed it to always use the C off_t type, but that broke 32-bit big-endian Linux systems. On those systems, using the C off_t type requires calling the mmap64 function. In C this is automatically handled by the file. In Go, we would have to change the magic //extern comment to call mmap64 when appropriate. Rather than try to get that right, we instead go through a C function that uses C implicit type conversions to pick the right type. Fixes PR go/110297 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/504415
[Bug middle-end/110318] Unused string literal is retained in assembler file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110318 Andrew Pinski changed: What|Removed |Added Known to fail||7.1.0, 9.1.0 --- Comment #5 from Andrew Pinski --- Note the behavior changed between GCC 6 and GCC 7 where in GCC 6, it would just emit a call to memcmp but in GCC 7, GCC starts to inline things.
[Bug target/54089] [SH] Refactor shift patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 --- Comment #84 from Alexander Klepikov --- I've forgot to say that first I ran all tests with SH specific loop optimization enabled when condition 'optimize && flag_move_loop_invariants' is true. And only then I ran all tests with final (at the moment) version of patch once more.
[Bug bootstrap/110324] [14 Regression][bootstrap, nvptx] build/genpreds: Internal error: RTL check: expected elt 2 type 'T', have 's' due to r14-1949-g957ae904065917
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110324
--- Comment #2 from Tobias Burnus ---
BTW, regarding: type 'T', have 's'
/* Indexed by rtx code, gives a sequence of operand-types for
rtx's of that code. The sequence is a C string in which
each character describes one operand. */
const char * const rtx_format[NUM_RTX_CODE] = {
...
"s" a pointer to a string
prints the string
...
"T" like "s", but treated specially by the RTL reader;
only found in machine description patterns.
...
#define DEF_RTL_EXPR(ENUM, NAME, FORMAT, CLASS) FORMAT ,
#include "rtl.def" /* rtl expressions are defined here */
#undef DEF_RTL_EXPR
};
[Bug modula2/110284] [14 Regression] Bootstrap failures with m2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110284 Jakub Jelinek changed: What|Removed |Added Status|CLOSED |REOPENED Resolution|FIXED |--- --- Comment #9 from Jakub Jelinek --- Arsen/Iain reported on IRC is this known/fixable? (I think I have seen other folks comment on it) In file included from /src-local/arsen/gcc/m2/gm2-gcc/gcc-consolidation.h:71, from /src-local/arsen/gcc/m2/m2.flex:23: #include "insn-opinit.h" Neither m2/gm2-compiler/m2flex.o nor m2/gm2-compiler-boot/m2flex.o are included in m2_OBJS (they surely don't need to be in GM2_C_OBJS, that is m2 internal variable). Question is what other objects are suffering from that. I guess best test would be to add sleep 1h into the s-opinit rule in gcc/Makefile.in, before the $(RUN_GEN) build/genopinit$(build_exeext) $(md_file) \ line or so and then make -j128 -k (or some other very high number, such that it prints all the problems).
[Bug middle-end/110318] Unused string literal is retained in assembler file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110318 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
