[Bug c++/104139] [12 Regression] g++.dg/abi/no_unique_address2.C at r12-6028 (a37e8ce3b663)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104139 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0 Target||cris-elf, pru-elf
[Bug middle-end/104140] [12 Regression] ICE verify_gimple failed: type mismatch in binary expression since r12-6434-g0752c75536e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104140 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0 Priority|P3 |P1
[Bug tree-optimization/104114] vect.exp fails when run with -Wvector-operation-performance due to bogus diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104114 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Richard Biener --- Fixed for GCC 12.
[Bug tree-optimization/104114] vect.exp fails when run with -Wvector-operation-performance due to bogus diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104114 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:ad4188f8385f86cc04806fb0e26c7da1f5f655b8 commit r12-6755-gad4188f8385f86cc04806fb0e26c7da1f5f655b8 Author: Richard Biener Date: Wed Jan 19 13:59:21 2022 +0100 tree-optimization/104114 - avoid diagnosing V1mode lowering Currently we diagnose vector lowering of V1mode operations that are not natively supported into V_C_E, scalar op plus CTOR with -Wvector-operation-performance but that's hardly useful behavior even though the way we lower things can be improved. The following disables the diagnostics for the cases the vect.exp testsuite runs into, on x86 that are vect-cond-11.c and vect-singleton_1.c. 2022-01-19 Richard Biener PR tree-optimization/104114 * tree-vect-generic.cc (expand_vector_piecewise): Do not diagnose single element vector decomposition.
[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #5 from Martin Liška --- (In reply to Eric Gallager from comment #3) > Along these lines, there's also some non-portable usage of `expr` in the > file, too (which I brought up on IRC), but I forget what exactly it was... Do you know what exactly is problematic regarding the portability?
[Bug bootstrap/104135] [12 Regression] -Werror=format-diag breaks rtl checking bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104135 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2022-01-20 --- Comment #4 from Martin Liška --- Let me handle this, sorry for the breakage.
[Bug c++/104134] Bootstrap with --disable-nls compiling gcc/cp/error.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104134 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-01-20 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #15 from Martin Liška --- I have a patch candidate.
[Bug target/104117] gcc10 fails to build icu for ppc64 on 10.5.8 (direct access to a floating-point constant)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104117 --- Comment #6 from Iain Sandoe --- .. not (In reply to Iain Sandoe from comment #5) > (In reply to Richard Biener from comment #4) not enough coffee before posting ... [this problem comes into play when we use force_const_mem() on an operand, and then process_address() on that - but disentangling what exactly is happening will take some more time]. ( I am not familiar with using the RTL FE so that is something that will also take some time ) > I had a quick look yesterday and it seems that there might be a bug in the > target address legaliser in this case [it is being called]. > > (there is another extremely similar problem, where the legaliser is never > called, but I was jumping to conclusions that it was the same one too soon) It seems that both of these are actually in play (it is not sufficient just to fix the legaliser)
[Bug c++/104142] New: [9/10/11/12] Spurios warning unused-variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104142
Bug ID: 104142
Summary: [9/10/11/12] Spurios warning unused-variable
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: phdiv at fastmail dot fm
Target Milestone: ---
Created attachment 52238
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52238&action=edit
Reproducer.
> cat c.cpp
struct A { };
static const A a;
struct B { B()=default; };
static const B b;
> g++ -Wunused-variable -Wunused-const-variable -c c.cpp
c.cpp:5:16: warning: 'b' defined but not used [-Wunused-variable]
5 | static const B b;
|^
c.cpp:2:16: warning: 'a' defined but not used [-Wunused-const-variable=]
2 | static const A a;
|^
I would expect the warning unused-const-variable to be issued for both a and b.
[Bug fortran/104143] New: [F2018] Accept scalar actual arguments to assumed-type assumed-size array dummies [type(*), dimension(*)]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104143 Bug ID: 104143 Summary: [F2018] Accept scalar actual arguments to assumed-type assumed-size array dummies [type(*), dimension(*)] Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- Passing a (non-character) scalar to an assumed-type assumed-size array dummy is now permitted - new in Fortran 2018 (see last bullet in the quote below). Fortran 2008 (12.5.2.4 Ordinary dummy variables): "... If the actual argument is a noncoindexed scalar, the corresponding dummy argument shall be scalar unless the actual argument is default character, of type character with the C character kind (15.2.2), or is an element or substring of an element of an array that is not an assumed-shape, pointer, or polymorphic array." Fortran 2018: "If the actual argument is a noncoindexed scalar, the corresponding dummy argument shall be scalar unless • the actual argument is default character, of type character with the C character kind (18.2.2), or is an element or substring of an element of an array that is not an assumed-shape, pointer, or polymorphic array, • the dummy argument has assumed-rank, or • the dummy argument is an assumed-type assumed-size array." Example: interface subroutine foo(x) type(*) :: x(*) end end interface integer :: a call foo(a) end (When a generic interface is used, passing a scalar or array element to an assumed-size array is not permitted - at least that's how GCC+ifort have implemented it.) (The new feature avoids the need to use the '!GCC$ ATTRIBUTES NO_ARG_CHECK' attribute as workaround.)
[Bug c++/104142] Spurios warning unused-variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104142 Richard Biener changed: What|Removed |Added Summary|[9/10/11/12] Spurios|Spurios warning |warning unused-variable |unused-variable Keywords||diagnostic Last reconfirmed||2022-01-20 Status|UNCONFIRMED |NEW Known to fail||10.3.0, 11.2.0, 12.0, 9.4.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- 'b' is likely not marked readonly as it is initialized.
[Bug tree-optimization/104058] [12 Regression] 6-7% x264_r regression with -march=native -Ofast -funroll-loops -flto on x86 since r12-6420-gd3ff7420e941931d32ce2e332e7968fe67ba20af
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104058 Levy Hsu changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #4 from Levy Hsu --- SkyLake +6.79% CascadeLake +7.56% Zen2 +5.77% Look likes it's resolved. We'll track it further in weekly report. Thanks
[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 104058, which changed state. Bug 104058 Summary: [12 Regression] 6-7% x264_r regression with -march=native -Ofast -funroll-loops -flto on x86 since r12-6420-gd3ff7420e941931d32ce2e332e7968fe67ba20af https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104058 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 104058, which changed state. Bug 104058 Summary: [12 Regression] 6-7% x264_r regression with -march=native -Ofast -funroll-loops -flto on x86 since r12-6420-gd3ff7420e941931d32ce2e332e7968fe67ba20af https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104058 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug target/103771] [12 Regression] Missed vectorization under -mavx512f -mavx512vl after r12-5489
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103771 --- Comment #31 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:8bc700f4c3fbe405413db02281ef2918bfa831fc commit r12-6756-g8bc700f4c3fbe405413db02281ef2918bfa831fc Author: liuhongt Date: Mon Jan 17 10:47:46 2022 +0800 Enhance vec_pack_trunc for integral mode mask. For testcase in PR, the patch supports QI:4 -> HI:16 pack with multi steps(first pack QI:4 -> QI:8 through vec_pack_sbool_trunc_qi, then pack QI:8 -> HI:16 through vec_pack_trunc_hi). Similar for QI:2 -> HI:16 which is test4 in mask-pack-prefer-128.c. gcc/ChangeLog: PR target/103771 * tree-vect-stmts.cc (supportable_narrowing_operation): Enhance integral mode mask pack by multi steps which takes vec_pack_sbool_trunc_optab as start when elements number is less than BITS_PER_UNITS. gcc/testsuite/ChangeLog: * gcc.target/i386/mask-pack-prefer128.c: New test. * gcc.target/i386/mask-pack-prefer256.c: New test. * gcc.target/i386/pr103771.c: New test.
[Bug tree-optimization/102650] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102650 --- Comment #7 from Richard Biener --- Actually e will not be used uninitialized for (; d < 1; d++) e = f + a; will initialize it since d is zero and its value will be 4. But jump threading isolates the case where we would access e uninitialized. So yes, it does seem worth doing that but maybe only on isolated paths (to not defeat uninit diagnostics and also to remove spurious uninit diagnostics). The situation isn't easily visible from the threader itself and the question is how much GCC itself will expose unconditional uninit uses (there are some bugs around ifcombine doing that) so it's prone to producing wrong-code as well. That said, we probably have to live with this regression for GCC 12 and could look into sanitizing our undef behavior for GCC 13 somehow.
[Bug fortran/102621] ICE in convert_nonlocal_reference_op, at tree-nested.c:1166 since r12-1108-g9a5de4d5af1c10a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102621 Richard Biener changed: What|Removed |Added Target Milestone|12.0|--- Summary|[12 Regression] ICE in |ICE in |convert_nonlocal_reference_ |convert_nonlocal_reference_ |op, at tree-nested.c:1166 |op, at tree-nested.c:1166 |since |since |r12-1108-g9a5de4d5af1c10a8 |r12-1108-g9a5de4d5af1c10a8 --- Comment #2 from Richard Biener --- It's not clear that only Fortran is affected but GCC 11 rejected the code with t.f90:3:15: 3 |!$omp task affinity (iterator(j=1:8) : a(j)) | 1 Error: Failed to match clause at (1) t.f90:4:17: 4 |!$omp end task | 1 Error: Unexpected !$OMP END TASK statement at (1) so it's not a regression.
[Bug fortran/102596] [11/12 Regression] ICE in gfc_omp_clause_default_ctor, at fortran/trans-openmp.c:713 since r11-4883-ge929ef532ad52cde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102596 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug target/104122] On Zen3, 510.parest_r (built with -Ofast) is faster with generic than with native ISA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104122 --- Comment #3 from Martin Jambor --- (In reply to Richard Biener from comment #2) > It's ISA, not tuning. You are of course correct, unfortunately I am too accustomed to using the wrong term. > I suppose -march=native -mtune=generic is still bad? I don't know, I'd have to manually check. > I wonder if you tried the obvious -mprefer-avx128? I hope that is equivalent to -mprefer-vector-width=128 If it is, -march=native -mtune=native -mprefer-vector-width=128 is even quite a bit slower than -march=native -mtune=native.
[Bug tree-optimization/102540] [12 Regression] Dead Code Elimination Regression at -O3 since r12-476-gd846f225c25c5885
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102540
--- Comment #9 from Richard Biener ---
I think the GCC 12 IL would require tracking equivalences on parts of
registers,
in this case that _2 is equal to the low part of a.0_1. That is, one would
need to extend what CCP does with bit propagation to include equivalences.
There's also the if ((long)unsigned-var != 0) -> if (unsigned-var != 0)
transform that could save us here but we have that guarded with
single_use () and the converted value is used after the branching
but not the source so we'd have increased register pressure.
I do not see a good way to fix this issue, slightly altering the testcase to
do the undesired transform on the source level
static long a;
static unsigned b;
void foo(void);
int main() {
long c, e;
b = a;
c = (unsigned)a;
e = c ? 2 / (c + 1) : 0;
if (e && !b)
foo();
a = 0;
}
causes the issue to appear also with GCC 11.
[Bug middle-end/102519] [12 Regression] VRP Jump threader memory explosion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519 Richard Biener changed: What|Removed |Added Status|NEW |WAITING --- Comment #24 from Richard Biener --- David, I believe the issue is fixed meanwhile. Can you please confirm that?
[Bug middle-end/102517] [12 regression] regressions on aarch64 since r12-3899
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102517 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Keywords||testsuite-fail --- Comment #5 from Richard Biener --- The testcase still fails, Richard, please have a look on how to adjust it.
[Bug c++/102489] [12 Regression] coroutines: ICE in is_this_parameter, at cp/semantics.c:11273 since r12-3529-g70ee703c479081ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102489 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/102473] [12 Regression] 521.wrf_r 5% slower at -Ofast and generic x86_64 tuning after r12-3426-g8f323c712ea76c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102473 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Status|NEW |WAITING --- Comment #16 from Richard Biener --- The change causing the regression was reverted, correct? So we can close this bug?
[Bug fortran/102459] [12 Regression] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.c:3549 since r12-1108-g9a5de4d5af1c10a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102459 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug c++/102434] [11/12 Regression] ICE in output_constructor_regular_field, at varasm.c:5514 since r11-4547-g6fb7e3c29188ab7c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102434 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/102433] [11/12 Regression] ICE in ~saved_token_sentinel, at cp/parser.c:1293 since r11-8118-g82198676c80764ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102433 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug c++/102414] [12 Regression] ICE in unify_array_domain, at cp/pt.c:23442 since r12-1933-ge66d0b7b87d105d2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102414 Richard Biener changed: What|Removed |Added Priority|P3 |P1 --- Comment #2 from Richard Biener --- GCC 11 rejects the code, so does clang t.ii: In function 'void f()': t.ii:4:14: warning: division by zero [-Wdiv-by-zero] 4 | auto (*b)[0/0] = &a; | ~^~ t.ii:4:10: error: 'b' declared as array of 'auto' 4 | auto (*b)[0/0] = &a; | ^
[Bug sanitizer/101476] AddressSanitizer check failed, points out a (potentially) non-existing stack error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101476 --- Comment #11 from Stas Sergeev --- The third bug here seems to be that __asan_handle_no_return: https://github.com/gcc-mirror/gcc/blob/master/libsanitizer/asan/asan_rtl.cpp#L602 also calls sigaltstack() before unpoisoning stacks. I believe this makes the problem much more reproducible, for example the test-case with longjmp() is likely possible too. I've found about that instance by trying to call __asan_handle_no_return() manually as a pthread cleanup handler, in a hope to work around the destructor bug. But it appears __asan_handle_no_return() does the same thing. So the fix should be to move this line: https://github.com/gcc-mirror/gcc/blob/master/libsanitizer/asan/asan_rtl.cpp#L607 above PlatformUnpoisonStacks() call.
[Bug tree-optimization/102329] [11/12 Regression] pointer "maybe uninitialized" right after assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102329 Richard Biener changed: What|Removed |Added Priority|P3 |P2 --- Comment #9 from Richard Biener --- The wording should be fixed ASAP, not sure what's blocking that. It might be nice to provide a way to separately disable this diagnostic like by introducing a separate option (no good idea on the naming).
[Bug fortran/102314] [12 Regression] ICE in verify_ssa, at tree-ssa.c:1076 since r12-1319-gd4d38135b3137f1d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102314 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c/102291] [9/10/11/12 Regression] wrong overflow warning for compound expression conversion and bit_and expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102291 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/102264] [9/10/11/12 Regression] extra spilling when using inline-asm and all registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102264 --- Comment #6 from Richard Biener --- Created attachment 52239 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52239&action=edit testcase with the constraints fixed I don't see how 4.9.4 "works", even that spills some regs. It does seem to spill a little less but not sure if AVX512 support which was new in GCC 4.9 is up to speed there. I've attached the testcase with fixed asm constraints, GCC 11 produces 18 spills of zmm and 12 reloads.
[Bug fortran/104126] [12 Regression] ICE in gfc_conv_gfc_desc_to_cfi_desc, at fortran/trans-expr.c:5649 since r12-4467-g64f9623765da3306
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104126 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-01-20 Summary|ICE in |[12 Regression] ICE in |gfc_conv_gfc_desc_to_cfi_de |gfc_conv_gfc_desc_to_cfi_de |sc, at |sc, at |fortran/trans-expr.c:5649 |fortran/trans-expr.c:5649 ||since ||r12-4467-g64f9623765da3306 Ever confirmed|0 |1 CC||burnus at gcc dot gnu.org, ||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #2 from Martin Liška --- Started with r12-4467-g64f9623765da3306.
[Bug c++/102261] [12 Regression] ICE: Segmentation fault (in build_this_conversion) since r12-3346-g47543e5f9d1fc502
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102261 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug fortran/104127] [9/10/11/12 Regression] ICE in get_array_charlen, at fortran/trans-array.c:7244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104127 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org --- Comment #4 from Martin Liška --- Started with r9-6726-gd5f48c7c62d3d8cf.
[Bug fortran/104130] [12 Regression] ICE in gfc_add_class_array_ref, at fortran/class.c:274 since r12-4467-g64f9623765da3306
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104130 Martin Liška changed: What|Removed |Added CC||burnus at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 Summary|[12 Regression] ICE in |[12 Regression] ICE in |gfc_add_class_array_ref, at |gfc_add_class_array_ref, at |fortran/class.c:274 |fortran/class.c:274 since ||r12-4467-g64f9623765da3306 Status|UNCONFIRMED |NEW Last reconfirmed||2022-01-20 --- Comment #1 from Martin Liška --- Started with r12-4467-g64f9623765da3306.
[Bug fortran/104131] ICE in gfc_conv_array_ref, at fortran/trans-array.c:3810
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104131 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 CC||kcy at codesourcery dot com, ||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2022-01-20 --- Comment #1 from Martin Liška --- Started with r11-6752-ga6d22fb21c6f1ad7.
[Bug tree-optimization/102178] [12 Regression] SPECFP 2006 470.lbm regressions on AMD Zen CPUs after r12-897-gde56f95afaaa22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102178 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Priority|P3 |P1 Keywords||missed-optimization Host|x86_64-linix| --- Comment #5 from Richard Biener --- Analysis is missing but the regression persists. On Haswell I do not see any effect. I do suspect it's about cmov vs. non-cmov but w/o a profile and looking affected assembly that's a wild guess.
[Bug middle-end/104067] [12 Regression] wrong code compiling QEMU since r12-4790-g4b3a325f07acebf4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104067 --- Comment #6 from Aldy Hernandez --- (In reply to Jeffrey A. Law from comment #5) > I briefly looked at the other BZ last week, but didn't make much headway. > The first thing that stood out was why are we threading around the loop. I > thought that was disabled. Anyway, Aldy and/or I will take both of these in > the coming days. This is the threadfull2 pass which is the most aggressive of the threaders. Loop optimizations have completed, so anything goes wrt loops (as per jt_path_registry::cancel_invalid_paths). Note that the issue here is not exactly a backedge problem as in PR103721, but a domination problem. I will comment in the other PR as they are related.
[Bug middle-end/104140] [12 Regression] ICE verify_gimple failed: type mismatch in binary expression since r12-6434-g0752c75536e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104140
Roger Sayle changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2022-01-20
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
--- Comment #1 from Roger Sayle ---
Mine (perhaps?). To quote the review from my HIGHPART_MULT_EXPR patch:
>+ if (optype != TREE_TYPE (mop2)
>
> I think mop1 and mop2 have to be compatible types (the tree-cfg.c
> GIMPLE verification only tests for same precision it seems but tree.def
> says they are of type T1). That said, I think optype != TREE_TYPE (mop2)
> is superfluous and too conservative at it.
It turns out that restoring this clause from the original patch submission
resolves this ICE on a cross-compiler to riscv-unknown-linux-gnu.
diff --git a/gcc/tree-ssa-math-opts.c b/gcc/tree-ssa-math-opts.c
index 1b6a57b..89a26dd 100644
--- a/gcc/tree-ssa-math-opts.c
+++ b/gcc/tree-ssa-math-opts.c
@@ -4600,7 +4600,8 @@ convert_mult_to_highpart (gassign *stmt,
gimple_stmt_itera
bool unsignedp = TYPE_UNSIGNED (optype);
unsigned int prec = TYPE_PRECISION (optype);
- if (unsignedp != TYPE_UNSIGNED (mtype)
+ if (optype != TREE_TYPE (mop2)
+ || unsignedp != TYPE_UNSIGNED (mtype)
|| TYPE_PRECISION (mtype) != 2 * prec)
return false;
It's odd that I'm unable to reproduce a similar failure on x86_64.
Perhaps the above paranoid fix isn't the correct solution at all, as
before/with it, I'm seeing:
void g ()
{
int x.0_2;
unsigned int v.1_4;
long long int _6;
long long int _7;
unsigned int _8;
[local count: 1073741824]:
x.0_2 = x;
v.1_4 = v;
_6 = x.0_2 w* v.1_4;
_7 = _6 >> 32;
_8 = (unsigned int) _7;
u = _8;
return;
}
Note the differing operand types to the widening multiplication. Perhaps the
upstream widening multiplication perception is the true source of the problem,
and just not being caught by verify_gimple like MULT_HIGHPART_EXPR is.
More generally, "defensive programming", i.e. the use of seemingly superfluous
tests that confirm assumed invariants isn't always a bad thing (in software
as complex as GCC).
[Bug tree-optimization/102058] [12 regression] 450.soplex regressed on x86_64 with -Ofast -march=generic (by 8-15%)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102058 --- Comment #4 from Richard Biener --- It's all with generic arch/tune but -Ofast which is not the most interesting combination. But we should see to extract a testcase for the reduction and see to gather runtime data on the size() distribution. When vectorized the loop might also turn from nice small to slightly too big for efficient cross iteration OOO scheduling.
[Bug c/87983] Feature: Add a warning when case labels from a different enum than the one in switch(EXPR) are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87983
--- Comment #4 from Ævar Arnfjörð Bjarmason ---
(In reply to Eric Gallager from comment #3)
> Is the expectation that this would come from -Wswitch, -Wswitch-enum,
> -Wenum-compare, -Wenum-conversion, or some new flag?
I think a new flag would be best. The clang compiler has a C++-only
-Wenum-compare-switch flag which will warn about this.
Here's a better and updated testcase showing how it works:
```
#include
enum enum_x { A, B };
enum enum_y { C, D };
int main(void)
{
enum enum_y y = C;
switch (y) {
case A: /* Should warn: switch() on C instead of A */
puts("A");
break;
case D:
puts("B");
break;
}
}
```
And a one-liner showing how gcc, g++, clang and clang++ handle it:
```
$ for cc in gcc g++ clang clang++; do echo $cc: && $cc -Wswitch -Wswitch-enum
-Wenum-compare -o test test.c; ./test; done
gcc:
A
g++:
A
clang:
A
clang++:
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is
deprecated [-Wdeprecated]
test.c:10:12: warning: comparison of different enumeration types in switch
statement ('enum enum_y' and 'enum_x') [-Wenum-compare-switch]
case A: /* Should warn: switch() on C instead of A */
^
1 warning generated.
A
```
(This is with a local GCC 10.* and LLVM 13.*, on a Debian box). Documentation
for the Clang warning:
https://clang.llvm.org/docs/DiagnosticsReference.html#wenum-compare-switch
[Bug rtl-optimization/101995] [9/10/11/12 Regression] regression built-in memset missed-optimization arm -Os since r9-3594
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101995 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug middle-end/104140] [12 Regression] ICE verify_gimple failed: type mismatch in binary expression since r12-6434-g0752c75536e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104140 --- Comment #2 from Roger Sayle --- Ah. risv.md provides a usmulsidi3 expander that populates a usmul_widen_optab, performing a widening multiplication with operands of differing signs. The comment/documentation in tree.def needs to be updated to reflect that the operands of WIDEN_MULT_EXPR may be different signs, but the same precision.
[Bug c++/101990] [12 Regression] ICE after parse error with concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101990 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug c++/101988] [12 Regression] Accepts invalid new-expression of array of deduced class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101988 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/104122] On Zen3, 510.parest_r (built with -Ofast) is faster with generic than with native ISA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104122 --- Comment #4 from Martin Jambor --- (In reply to Martin Jambor from comment #3) > (In reply to Richard Biener from comment #2) > > > I suppose -march=native -mtune=generic is still bad? > > I don't know, I'd have to manually check. > It turns out that (at least on the Ryzen machine) -march=native -mtune=generic is actually 15% better than not using any of the two options.
[Bug debug/103874] [11/12 Regression] ICE in internal_error on riscv64 and -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103874
--- Comment #9 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:68f03ac49cb4f585dbce78dc9e4c4a9ec950e83c
commit r12-6758-g68f03ac49cb4f585dbce78dc9e4c4a9ec950e83c
Author: Jakub Jelinek
Date: Thu Jan 20 11:58:20 2022 +0100
dwarf2out: Fix -gsplit-dwarf on riscv [PR103874]
riscv*-*-* are the only modern targets that !HAVE_AS_LEB128 (apparently
due to some aggressive linker optimizations).
As the following testcase shows, we mishandle in index_rnglists the
!HAVE_AS_LEB128 && !have_multiple_function_sections case.
output_rnglists does roughly:
FOR_EACH_VEC_SAFE_ELT (ranges_table, i, r)
{
...
if (block_num > 0)
{
...
if (HAVE_AS_LEB128)
{
if (!have_multiple_function_sections)
{
// code not using r->*_entry
continue;
}
// code that sometimes doesn't use r->*_entry,
// sometimes r->begin_entry
}
else if (dwarf_split_debug_info)
{
// code that uses both r->begin_entry and r->end_entry
}
else
{
// code not using r->*_entry
}
}
else if (block_num < 0)
{
if (!have_multiple_function_sections)
gcc_unreachable ();
...
}
}
and index_rnglists is what sets up those r->{begin,end}_entry members.
The code did an early if (!have_multiple_function_sections) continue;
which is fine for the HAVE_AS_LEB128 case, because r->*_entry is not
used in that case, but not for !HAVE_AS_LEB128 that uses it anyway.
2022-01-20 Jakub Jelinek
PR debug/103874
* dwarf2out.cc (index_rnglists): For !HAVE_AS_LEB128 and
block_num > 0, index entry even if
!have_multiple_function_sections.
* gcc.dg/debug/dwarf2/pr103874.c: New test.
[Bug debug/103874] [11 Regression] ICE in internal_error on riscv64 and -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103874 Jakub Jelinek changed: What|Removed |Added CC|jakub at redhat dot com| Summary|[11/12 Regression] ICE in |[11 Regression] ICE in |internal_error on riscv64 |internal_error on riscv64 |and -gsplit-dwarf |and -gsplit-dwarf --- Comment #10 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug middle-end/104140] [12 Regression] ICE verify_gimple failed: type mismatch in binary expression since r12-6434-g0752c75536e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104140 --- Comment #3 from Roger Sayle --- Sorry for the noise, but interestingly riscv.md also defines a usmulsi3_highpart instruction, providing highpart multiplication with different operand signedness. So in theory an alternate fix might be to allow/support this in MULT_HIGHPART_EXPR (like in WIDEN_MULT_EXPR). Perhaps a simple fix for GCC 12, and a more intrusive solution (providing improved riscv support) for GCC 13, once we return to stage 1.
[Bug bootstrap/104135] [12 Regression] -Werror=format-diag breaks rtl checking bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104135 --- Comment #5 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:e744aa373d215d1e8b3f4102a71b26b385dababc commit r12-6759-ge744aa373d215d1e8b3f4102a71b26b385dababc Author: Martin Liska Date: Thu Jan 20 09:28:42 2022 +0100 Fix -Werror=format-diag with RTL checking PR bootstrap/104135 gcc/ChangeLog: * emit-rtl.cc (make_insn_raw): Fix -Wformat-diag warnings. * rtl.cc: Partially disable -Wformat-diag for RTL checking error messages.
[Bug c++/104134] Bootstrap with --disable-nls compiling gcc/cp/error.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104134 --- Comment #16 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:6d51a27fb17d9dc4e583c119fd976d39e575180f commit r12-6760-g6d51a27fb17d9dc4e583c119fd976d39e575180f Author: Martin Liska Date: Thu Jan 20 09:30:01 2022 +0100 Fix Werror=format-diag with --disable-nls. PR c++/104134 gcc/cp/ChangeLog: * error.cc (dump_aggr_type): Partially disable the warning.
[Bug c++/104134] Bootstrap with --disable-nls compiling gcc/cp/error.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104134 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #17 from Martin Liška --- Fixed.
[Bug bootstrap/104135] [12 Regression] -Werror=format-diag breaks rtl checking bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104135 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Martin Liška --- Fixed.
[Bug tree-optimization/101908] [12 regression] cray regression with -O2 -ftree-slp-vectorize compared to -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101908
--- Comment #17 from Richard Biener ---
No good idea how to tackle such issues. Possibly a mdreorg pass could for the
code region "near" to the function prologue scan for loads that are known to
access the arguments in a way conflicting with how GCC itself would pass
them with respect to STLF and split those.
--- c-ray-f.s 2022-01-20 12:00:41.660954367 +0100
+++ c-ray-f.s.fixed 2022-01-20 12:00:38.160908539 +0100
@@ -334,8 +334,12 @@
.cfi_def_cfa_offset 160
movupd (%rdi), %xmm5
movsd 16(%rdi), %xmm9
- movupd 184(%rsp), %xmm13
- movupd 160(%rsp), %xmm15
+ movsd 184(%rsp), %xmm13
+ movhpd 192(%rsp), %xmm13
+# movupd 184(%rsp), %xmm13
+ movsd 160(%rsp), %xmm15
+ movhpd 168(%rsp), %xmm15
+# movupd 160(%rsp), %xmm15
movsd 176(%rsp), %xmm10
movaps %xmm5, 16(%rsp)
unpckhpd%xmm5, %xmm5
indeed improves performance back to previous levels. That's the ray_sphere
"prologue", preceeding is only
ray_sphere:
.LFB33:
.cfi_startproc
subq$152, %rsp
At .stv1/.stv2 we see
(note 4 3 11 2 NOTE_INSN_FUNCTION_BEG)
(insn 11 4 13 2 (set (reg:V2DF 174 [ vect_ray_orig_x_87.270 ])
(mem/c:V2DF (reg/f:DI 16 argp) [1 MEM [(double
*)&ray]+0 S16 A64])) 1673 {movv2df_internal}
(nil))
...
(insn 16 15 18 2 (set (reg:V2DF 178 [ vect_ray_dir_x_90.266 ])
(mem/c:V2DF (plus:DI (reg/f:DI 16 argp)
(const_int 24 [0x18])) [1 MEM [(double
*)&ray + 24B]+0 S16 A64])) 1673 {movv2df_internal}
(nil))
at the classic mdreorg place it is
(insn:TI 16 30 11 2 (set (reg:V2DF 49 xmm13 [orig:178 vect_ray_dir_x_90.266 ]
[178])
(mem/c:V2DF (plus:DI (reg/f:DI 7 sp)
(const_int 184 [0xb8])) [1 MEM [(double
*)&ray + 24B]+0 S16 A64])) 1673 {movv2df_internal}
(nil))
(insn 11 16 15 2 (set (reg:V2DF 51 xmm15 [orig:174 vect_ray_orig_x_87.270 ]
[174])
(mem/c:V2DF (plus:DI (reg/f:DI 7 sp)
(const_int 160 [0xa0])) [1 MEM [(double
*)&ray]+0 S16 A64])) 1673 {movv2df_internal}
(nil))
both might have enough info to tell that we load from an argument and how
that argument was passed. But I don't know enough RTL details to say
how difficult it would be to split vector loads from the argument space
if it is "misaligned" compared to the argument passing sequence.
I do wonder though how CLX is fine with such access pattern ;) (did you test
with just -O2?)
[Bug tree-optimization/103721] [12 regression] wrong code generated for loop with conditional since r12-4790-g4b3a325f07acebf4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103721 --- Comment #11 from Aldy Hernandez --- The testcase for PR104067 shows an example where the dominance matters, irregardless of if we reset relations at the backedge point. There we have a path that looks like 9->3->5->...: [local count: 1063004409]: # j_17 = PHI # q_18 = PHI # ivtmp_4 = PHI j_8 = j_17 + 1; if (j_8 == 10) goto ; [34.00%] else goto ; [66.00%] [local count: 701582906]: _1 = (sizetype) j_8; _15 = _1 * 4; _14 = &a + _15; [local count: 1063004409]: # j_2 = PHI # prephitmp_16 = PHI <_14(4), &a(3)> if (prephitmp_16 == q_18) goto ; [0.00%] else goto ; [100.00%] [local count: 1052374367]: goto ; [100.00%] Even if we reset relations and clear the root oracle at the backedge (9->3), we still get the _16 == _18 in BB3, followed by the DEF of _16 in BB5.
[Bug tree-optimization/103721] [12 regression] wrong code generated for loop with conditional since r12-4790-g4b3a325f07acebf4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103721 --- Comment #12 from Aldy Hernandez --- Created attachment 52240 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52240&action=edit proposed untested patch This is a proposed patch that fixes both PRs. Perhaps we can tweak the dominance check in relations_may_be_invalidated to be less aggressive.
[Bug target/101908] [12 regression] cray regression with -O2 -ftree-slp-vectorize compared to -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101908 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Component|tree-optimization |target --- Comment #18 from Richard Biener --- I do think this general issue, using %xmm for argument passing and vectorizing with -O2 will see a lot of people stumbling into such unexpected issues so I fear we have to do something about it.
[Bug target/101908] [12 regression] cray regression with -O2 -ftree-slp-vectorize compared to -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101908
--- Comment #19 from Richard Biener ---
#include
struct X { double x[3]; };
typedef double v2df __attribute__((vector_size(16)));
v2df __attribute__((noipa))
foo (struct X x)
{
return (v2df) {x.x[1], x.x[2] };
}
struct X y;
int main(int argc, char **argv)
{
struct X x = y;
int cnt = atoi (argv[1]);
for (int i = 0; i < cnt; ++i)
foo (x);
return 0;
}
also reproduces it. On both trunk and the branch we see 'foo' using
movups (combine does this as well even when not vectorizing). Using
-mtune-ctrl=^sse_unaligned_load_optimal improves performance of the
micro benchmark more than 4-fold on Zen2. Note that tuning also causes
us to not passing the argument using vector registers even though the
stack slot is aligned (but we use movupd there, we could use an aligned
move - but that's a missed optimization there).
Note doing non-vector argument setup but a misaligned vector load does
_not_ improve the situation, so the cray issue is solely caused by
-O2 enabling vectorization and eventually by the fact that using vector
stores for the argument setup might cause them to be more likely to
not retired compared to doing more scalar stores.
The same behavior can be observed on Haswell.
[Bug tree-optimization/102513] [10/11/12 Regression] Many false positive warnings with recursive function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102513 Jakub Jelinek changed: What|Removed |Added CC||fxue at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Started with r10-5098-g9b14fc3326e087975653b1af8ac54114041cde51
[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664 Eric Gallager changed: What|Removed |Added CC||iains at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #6 from Eric Gallager --- (In reply to Martin Liška from comment #5) > (In reply to Eric Gallager from comment #3) > > Along these lines, there's also some non-portable usage of `expr` in the > > file, too (which I brought up on IRC), but I forget what exactly it was... > > Do you know what exactly is problematic regarding the portability? Ah, I found my IRC log; apparently it was the `expr match` part: 1635762461 3130 hm, looks like I need to use gexpr instead of just-plain expr T 1635762474 3130I guess it's a GNU vs. BSD thing T 1635762672 3130so I guess that's a separate bug to file T 1635762691 3130I guess the g:hash syntax will do for now for the other one I was filing T 1635762767 18 yes, there are some non-portable parts in the customisation … T 1635762803 18 expr is used twice there, is the problem with expr match or with expr x - y T 1635762865 18*iains thought the initial problem was with the match .. but ICBW T 1635762967 18 I guess it can be replaced with echo | grep -q too, but for bash that is unnecessary slowdown...; perhaps gcc-git-customization.sh could check if expr match works and if not, use something different... T 1635763046 3130I think it's the expr match part
[Bug libstdc++/103655] "x" does not exist on windows and dos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103655 --- Comment #2 from Jonathan Wakely --- "We implemented this C11 feature a while ago and backported it to all OSes" That suggests it should become available everywhere, no?
[Bug tree-optimization/102513] [10/11/12 Regression] Many false positive warnings with recursive function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102513 Jakub Jelinek changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||amacleod at redhat dot com --- Comment #4 from Jakub Jelinek --- + Creating a specialized node of encode_block/0. +replacing param #0 block2 with const &block2 +replacing param #1 level with const 4 + Creating a specialized node of encode_block/0. +replacing param #0 block2 with const &block2 +replacing param #1 level with const 3 + Creating a specialized node of encode_block/0. +replacing param #0 block2 with const &block2 +replacing param #1 level with const 2 + Creating a specialized node of encode_block/0. +replacing param #0 block2 with const &block2 +replacing param #1 level with const 1 + Creating a specialized node of encode_block/0. +replacing param #0 block2 with const &block2 +replacing param #1 level with const 0 + Creating a specialized node of encode_block/0. +replacing param #0 block2 with const &block2 +replacing param #1 level with const 4294967295 + Creating a specialized node of encode_block/0. +replacing param #0 block2 with const &block2 +replacing param #1 level with const 4294967294 Maybe the IPA transformation should just use VRP info to guide it. We don't have anything that says level is [0, 5], that is there purely from the fact that the caller calls it with 5, but we know that it isn't -1U: # RANGE [0, 4294967294] _9 = level_19(D) + 4294967295; _23 = encode_block (block2_21(D), _9); _26 = encode_block (block2_21(D), _9); so we shouldn't create that specialized node and those that are needed just because we've created them.
[Bug web/104144] New: [12 Regression] --enable-version-specific-runtime-libs fails due to: Error: unknown architecture `armv9-a'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104144 Bug ID: 104144 Summary: [12 Regression] --enable-version-specific-runtime-libs fails due to: Error: unknown architecture `armv9-a' Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: wirkus at gcc dot gnu.org Target Milestone: --- Since g:32ba7860ccaddd5219e6dae94a3d0653e124c9dd, Armv9 is included in runtime library versions, however, gas configure detection is missing: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++ --enable-checking=release --disable-werror --with-gxx-include-dir=/usr/include/c++/12 --enable-ssp --disable-libssp --disable-libvtv --enable-cet=auto --disable-libcc1 --disable-plugin --with-bugurl=https://bugs.opensuse.org/ '--with-pkgversion=SUSE Linux' --with-slibdir=/usr/arm-suse-linux-gnueabi/sys-root/lib64 --with-system-zlib --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --with-gcc-major-version-only --enable-linux-futex --enable-gnu-indirect-function --program-suffix=-12 --program-prefix=arm-none-eabi- --target=arm-none-eabi --disable-nls --with-sysroot=/usr/arm-suse-linux-gnueabi/sys-root --with-build-sysroot=/usr/arm-suse-linux-gnueabi/sys-root --with-build-time-tools=/usr/arm-suse-linux-gnueabi/bin --with-newlib --enable-multilib --with-multilib-list=aprofile,rmprofile --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-shared --disable-threads --disable-tls --disable-libsanitizer --build=x86_64-suse-linux --host=x86_64-suse-linux ... [ 255s] checking for arm-none-eabi-nm... /home/abuild/rpmbuild/BUILD/gcc-12.0.1+git191144/obj-x86_64-suse-linux/./gcc/nm [ 255s] checking for arm-none-eabi-ranlib... /usr/arm-suse-linux-gnueabi/bin/ranlib [ 255s] checking for arm-none-eabi-strip... /usr/arm-suse-linux-gnueabi/bin/strip [ 255s] checking whether ln -s works... yes [ 255s] checking for arm-none-eabi-gcc... /home/abuild/rpmbuild/BUILD/gcc-12.0.1+git191144/obj-x86_64-suse-linux/./gcc/xgcc -B/home/abuild/rpmbuild/BUILD/gcc-12.0.1+git191144/obj-x86_64-suse-linux/./gcc/ -B/usr/arm-none-eabi/bin/ -B/usr/arm-none-eabi/lib/ -isystem /usr/arm-none-eabi/include -isystem /usr/arm-none-eabi/sys-include --sysroot=/usr/arm-suse-linux-gnueabi/sys-root -mthumb -march=armv9-a -mfloat-abi=soft [ 255s] checking for suffix of object files... configure: error: in `/home/abuild/rpmbuild/BUILD/gcc-12.0.1+git191144/obj-x86_64-suse-linux/arm-none-eabi/thumb/v9-a/nofp/libgcc': [ 255s] configure: error: cannot compute suffix of object files: cannot compile [ 255s] See `config.log' for more details [ 255s] make[1]: *** [Makefile:12902: configure-target-libgcc] Error 1 [ 255s] make[1]: Leaving directory '/home/abuild/rpmbuild/BUILD/gcc-12.0.1+git191144/obj-x86_64-suse-linux' Due to: configure:3566: /home/abuild/rpmbuild/BUILD/gcc-12.0.1+git191144/obj-x86_64-suse-linux/./gcc/xgcc -B/home/abuild/rpmbuild/BUILD/gcc-12.0.1+git191144/obj-x86_64-suse-linux/./gcc/ -B/usr/arm-none-eabi/bin/ -B/usr/arm-none-eabi/lib/ -isystem /usr/arm-none-eabi/include -isystem /usr/arm-none-eabi/sys-include --sysroot=/usr/arm-suse-linux-gnueabi/sys-root -mthumb -march=armv9-a -mfloat-abi=soft -o conftest -g -O2 conftest.c >&5 Assembler messages: Error: unknown architecture `armv9-a' Error: unrecognized option -march=armv9-a configure:3569: $? = 1 configure:3782: checking for suffix of object files configure:3804: /home/abuild/rpmbuild/BUILD/gcc-12.0.1+git191144/obj-x86_64-suse-linux/./gcc/xgcc -B/home/abuild/rpmbuild/BUILD/gcc-12.0.1+git191144/obj-x86_64-suse-linux/./gcc/ -B/usr/arm-none-eabi/bin/ -B/usr/arm-none-eabi/lib/ -isystem /usr/arm-none-eabi/include -isystem /usr/arm-none-eabi/sys-include --sysroot=/usr/arm-suse-linux-gnueabi/sys-root -mthumb -march=armv9-a -mfloat-abi=soft -c -g -O2 conftest.c >&5 Assembler messages: Error: unknown architecture `armv9-a'
[Bug web/104144] [12 Regression] --enable-version-specific-runtime-libs fails due to: Error: unknown architecture `armv9-a'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104144 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-01-20 Host||x86_64-linux-gnu Ever confirmed|0 |1 Target||arm-linux-gnueabi
[Bug target/101882] [9/10/11/12 Regression] modulus with input and output set to a hard register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/104144] [12 Regression] --enable-version-specific-runtime-libs fails due to: Error: unknown architecture `armv9-a'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104144 Richard Biener changed: What|Removed |Added Component|web |target Target Milestone|--- |12.0 --- Comment #1 from Richard Biener --- binutils used in question is 2.37, install.texi does not mention any binutils requirement for arm.
[Bug c++/101874] [12 Regression] ICE with auto specifier for VLAs since r12-1933-ge66d0b7b87d105d2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101874 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/104144] [12 Regression] --enable-version-specific-runtime-libs fails due to: Error: unknown architecture `armv9-a'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104144 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #2 from Christophe Lyon --- For background, I reported this some time ago: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584556.html
[Bug target/101662] [12 Regression] FAIL: gcc.target/i386/pr91446.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101662 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Richard Biener --- Indeed fixed.
[Bug c/101630] [9/10/11/12 Regression] ICE with -Wall: in get_constant, at c-family/c-format.c:325
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101630 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug c++/101532] [12 Regression] ICE in finish_expr_stmt, at cp/semantics.c:859
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101532 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c++/101500] [9/10/11/12 Regression] gcc accepts the code with extra curly braces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101500 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/102513] [10/11/12 Regression] Many false positive warnings with recursive function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102513 Jakub Jelinek changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- In the ipa-cp dump it even mentions it: Node: encode_block/0: param [0]: &block2 [loc_time: 0, loc_size: 0, prop_time: 0, prop_size: 0] ctxs: VARIABLE Bits: value = 0x0, mask = 0xfffc int[256] * [1B, +INF] AGGS VARIABLE param [1]: VARIABLE 5 [loc_time: 147.512, loc_size: 27, prop_time: 760193, prop_size: 216] 4 [loc_time: 147.512, loc_size: 27, prop_time: 143948, prop_size: 189] 3 [loc_time: 147.512, loc_size: 27, prop_time: 31125.7, prop_size: 162] 2 [loc_time: 147.512, loc_size: 27, prop_time: 7822.76, prop_size: 135] 1 [loc_time: 147.512, loc_size: 27, prop_time: 2325.83, prop_size: 108] 0 [loc_time: 147.512, loc_size: 27, prop_time: 825.122, prop_size: 81] 4294967295 [loc_time: 147.512, loc_size: 27, prop_time: 342.227, prop_size: 54] 4294967294 [loc_time: 147.512, loc_size: 27, prop_time: 147.512, prop_size: 27] ctxs: VARIABLE Bits unusable (BOTTOM) unsigned int [0, 4294967294] AGGS VARIABLE but doesn't connect that when the param has value range of [0, 4294967294] and 4294967295 is outside of that range, it doesn't make sense to specialize on it.
[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664 --- Comment #7 from Jonathan Wakely --- https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Limitations-of-Usual-Tools.html#index-g_t_0040command_007bexpr_007d-1813 The expr match regex should not start with ^ (that is implied anyway, and some versions of expr don't like it)
[Bug jit/101491] /usr/local/include/libgccjit++.h conflicts between different GCC installations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101491 Richard Biener changed: What|Removed |Added Summary|[11/12 regression] |/usr/local/include/libgccji |/usr/local/include/libgccji |t++.h conflicts between |t++.h conflicts between |different GCC installations |different GCC installations | Known to fail||7.5.0 Target Milestone|11.3|--- --- Comment #8 from Richard Biener --- GCC 7 contains the same install rule so definitely not a regression from GCC 10.
[Bug c/101478] [10/11/12 Regression] ICE on invalid code: recompute_tree_invariant_for_addr_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101478 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug target/104144] [12 Regression] build fails due to: Error: unknown architecture `armv9-a'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104144 Richard Biener changed: What|Removed |Added Summary|[12 Regression] |[12 Regression] build fails |--enable-version-specific-r |due to: Error: unknown |untime-libs fails due to: |architecture `armv9-a' |Error: unknown architecture | |`armv9-a' | --- Comment #3 from Richard Biener --- Is there a way to disable a specific multilib at configure time?
[Bug target/101428] [10/11/12 Regression] ICE: 'asm' clobber conflict with output operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101428
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #2 from Richard Biener ---
varasm.cc does
/* Do sanity check for overlap between clobbers and respectively
input and outputs that hasn't been handled. Such overlap
should have been detected and reported above. */
if (!clobber_conflict_found && REG_P (clobbered_reg))
{
/* We test the old body (obody) contents to avoid
tripping over the under-construction body. */
for (unsigned k = 0; k < noutputs; ++k)
if (reg_overlap_mentioned_p (clobbered_reg, output_rvec[k]))
internal_error ("% clobber conflict with "
"output operand");
for (unsigned k = 0; k < ninputs - ninout; ++k)
if (reg_overlap_mentioned_p (clobbered_reg, input_rvec[k]))
internal_error ("% clobber conflict with "
"input operand");
}
so the comment suggests it was expected to be diagnosed in a friendlier way
but appearantly that didn't work out. Was this ever working or why is this
marked as regression?
[Bug tree-optimization/101150] [11/12 Regression] null pointer dereference false positive disappears when compiling an additional function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101150 Richard Biener changed: What|Removed |Added Last reconfirmed|2021-06-22 00:00:00 |2022-1-20 Known to work||10.3.1 Priority|P3 |P2 --- Comment #3 from Richard Biener --- Re-confirmed on trunk.
[Bug c++/101051] [10/11/12 Regression] ICE in splice_late_return_type with trailing return type on a conversion operator, caused by r10-6571
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101051 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug preprocessor/100904] [9/10/11/12 Regression] Wrong line location #include error "No such file or directory" – line + 1 [traditional mode as used by gfortran]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100904 Richard Biener changed: What|Removed |Added Last reconfirmed|2021-06-08 00:00:00 |2022-1-20 Priority|P3 |P2 --- Comment #4 from Richard Biener --- Re-confirmed.
[Bug c++/100853] [11/12 Regression] internal compiler error: in cp_tree_equal, at cp/tree.c:4148
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100853 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug c++/100829] [9/10/11/12 Regression] ICE with type that can't be determined since r8-6321-gd78201d30c7c5a8f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100829 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/104145] New: Extra instructions generated for dual float return on ARM64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104145
Bug ID: 104145
Summary: Extra instructions generated for dual float return on
ARM64.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: asd0025 at gmail dot com
Target Milestone: ---
In the following code snippet, inefficient code is generated when returning 2
floats on ARM64/AArch64: https://godbolt.org/z/3G8nMT8W4
```
typedef float f32;
typedef double f64;
template
struct duo
{
A a;
B b;
};
duo stream_load2(const f32* p)
{
f32 a, b;
asm("ldnp %s0, %s1, %2" : "=w"(a), "=w"(b) : "m"(*(const f32(*)[2])p));
return {a, b}; // NOTE: many extra instuctions are generated!
}
duo stream_load2_ldp(const f32* p)
{
return {p[0], p[1]}; // NOTE: inefficient code is generated for this!
}
duo stream_load2(const f64* p)
{
f64 a, b;
asm("ldnp %d0, %d1, %2" : "=w"(a), "=w"(b) : "m"(*(const f64(*)[2])p));
return {a, b}; // NOTE: works as expected!
}
```
GCC output (v6.4+):
```
stream_load2(float const*):
ldnp s1, s0, [x0]
fmovw2, s1
fmovw0, s0
mov x1, 0
bfi x1, x2, 0, 32
bfi x1, x0, 32, 32
lsr x0, x1, 32
lsr w1, w1, 0
fmovs1, w0
fmovs0, w1
ret
stream_load2_ldp(float const*):
ldr d0, [x0]
fmovx1, d0
lsr x0, x1, 32
fmovs1, w0
lsr w0, w1, 0
fmovs0, w0
ret
stream_load2(double const*):
ldnp d0, d1, [x0]
ret
```
Clang output:
```
stream_load2(float const*):
ldnps0, s1, [x0]
ret
stream_load2_ldp(float const*):
ldp s0, s1, [x0]
ret
stream_load2(double const*):
ldnpd0, d1, [x0]
ret
```
[Bug middle-end/104145] Extra instructions generated for dual float return on ARM64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104145 --- Comment #1 from Andrew Pinski --- There might be a dup of this bug already.
[Bug middle-end/104145] Extra instructions generated for dual float return on ARM64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104145 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug testsuite/104146] New: FAIL: libgomp.c/../libgomp.c-c++-common/pr96390.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104146
Bug ID: 104146
Summary: FAIL: libgomp.c/../libgomp.c-c++-common/pr96390.c
execution test
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
I.
I'm running into execution fails in libgomp testing with nvptx accelerator:
...
XPASS: libgomp.c/../libgomp.c-c++-common/pr96390.c (test for excess errors)
FAIL: libgomp.c/../libgomp.c-c++-common/pr96390.c execution test
XPASS: libgomp.c++/../libgomp.c-c++-common/pr96390.c (test for excess errors)
FAIL: libgomp.c++/../libgomp.c-c++-common/pr96390.c execution test
XPASS: libgomp.c++/pr96390.C (test for excess errors)
FAIL: libgomp.c++/pr96390.C execution test
...
In more detail:
...
libgomp: Link error log ptxas application ptx input, line 89; error : Call to
'baz' requires call prototype
ptxas application ptx input, line 89; error : Unknown symbol 'baz'
ptxas fatal : Ptx assembly aborted due to errors
libgomp: cuLinkAddData (ptx_code) error: a PTX JIT compilation failed
libgomp: Cannot map target functions or variables (expected 1, have 4294967295)
FAIL: libgomp.c/../libgomp.c-c++-common/pr96390.c execution test
...
The test-case contains:
...
/* { dg-require-alias "" } */
/* { dg-xfail-if "PR 97102/PR 97106 - .alias not (yet) supported for nvptx" {
offload_target_nvptx } } */
...
The test-case expects a compilation failure, which doesn't happen because ptxas
is not in the path, so the assembler skips verification, and we run into the
execution failure instead.
II.
With this:
...
$ ( export PATH=/home/vries/cuda/11.4.3/bin:$PATH; ./test.sh )
...
I get instead:
...
XFAIL: libgomp.c/../libgomp.c-c++-common/pr96390.c (test for excess errors)
UNRESOLVED: libgomp.c/../libgomp.c-c++-common/pr96390.c compilation failed to
produce executable
...
In more detail:
...
XFAIL: libgomp.c/../libgomp.c-c++-common/pr96390.c (test for excess errors)
Excess errors:
ptxas /tmp/ccGQGD1l.o, line 90; error : Call to 'baz' requires call prototype
ptxas /tmp/ccGQGD1l.o, line 90; error : Unknown symbol 'baz'
ptxas fatal : Ptx assembly aborted due to errors
nvptx-as: ptxas returned 255 exit status
mkoffload: fatal error:
/home/vries/oacc/trunk/install/offload-nvptx-none/bin//x86_64-pc-linux-gnu-accel-nvptx-none-gcc
returned 1 exit status
compilation terminated.
lto-wrapper: fatal error:
/home/vries/oacc/trunk/install/offload-nvptx-none/lib/gcc/x86_64-pc-linux-gnu/12.0.0//accel/nvptx-none/mkoffload
returned 1 exit status
compilation terminated.
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: error:
lto-wrapper failed
UNRESOLVED: libgomp.c/../libgomp.c-c++-common/pr96390.c compilation failed to
produce executable...
[Bug testsuite/104146] FAIL: libgomp.c/../libgomp.c-c++-common/pr96390.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104146
--- Comment #1 from Tom de Vries ---
Adding:
...
/* { dg-xfail-run-if "PR 97102/PR 97106 - .alias not (yet) supported for nvptx"
{ offload_target_nvptx } } */
...
fixes the FAIL.
[Bug target/101428] [10/11/12 Regression] ICE: 'asm' clobber conflict with output operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101428 --- Comment #3 from Arseny Solokha --- (In reply to Richard Biener from comment #2) > Was this ever working or why is this > marked as regression? gcc 9 and earlier accept the code w/o any diagnostic, and AFAICT the snippet you quoted had been changed last time in r223025.
[Bug middle-end/104067] [12 Regression] wrong code compiling QEMU since r12-4790-g4b3a325f07acebf4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104067 Aldy Hernandez changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #7 from Aldy Hernandez --- dup *** This bug has been marked as a duplicate of bug 103721 ***
[Bug tree-optimization/103721] [12 regression] wrong code generated for loop with conditional since r12-4790-g4b3a325f07acebf4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103721 Aldy Hernandez changed: What|Removed |Added CC||bonzini at gnu dot org --- Comment #13 from Aldy Hernandez --- *** Bug 104067 has been marked as a duplicate of this bug. ***
[Bug middle-end/100786] [9/10/11/12 Regression] ICE: in fold_convert_loc with alias attribute and different types and different sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100786 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED Priority|P3 |P2 --- Comment #3 from Richard Biener --- Testing a patch.
[Bug target/100784] [10/11/12 Regression] ICE: Segmentation fault, contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100784 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Richard Biener --- Testing a patch.
[Bug target/104144] [12 Regression] build fails due to: Error: unknown architecture `armv9-a'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104144 --- Comment #4 from Richard Earnshaw --- This sort of problem is going to keep occurring while we continue to have separate distributions of GCC and binutils. There's no way around the fact that support for a new architecture in GCC needs an assembler that understands the new architecture. This is true for all architectures, not just Arm. If a users asks for all the architectural libraries to be built, then I don't see it as unreasonable to require an assembler that can support this as well, so the issue becomes one of documentation, where we might as well just say that the minimum requirements may be increased if you try to use anything beyond the default configuration of the compiler. Anything more is going to result in a completely unwieldy mess of impenetrable dependencies. I don't think there's a way to make the current multilib infrastructure ignore specific sub-architectures. t-multilib is already extremely complex due to the need to reduce the number of variants to something just about tractable for the build system; adding yet more complexity to it would make it almost impossible to manage. I guess it might be possible to make the multilib configure machinery rip out variants that fail during configure, but you'd still need to deal with the mappings and decide what to do if the compiler needed an unbuilt library version. Dropping back to the default multilib would often be completely wrong as it might be an ABI change.
[Bug c/100661] [11/12 Regression] ICE in omp-low.c / refs_may_alias_p_2, at tree-ssa-alias.c:2460
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100661
--- Comment #5 from Richard Biener ---
Can lambdas appear inside #pragma omp in C++? The following is accepted but
each thread seems to get the global 'c', but at least we don't ICE (possibly
because frame lowering is done in the FE).
void
foo (char **x)
{
#pragma omp parallel for
for (int i = 0; i < 16; i++)
{
char c[50];
__builtin_strcpy (c, x[i]);
auto x = [&] () { __builtin_strcat (c, "foo"); };
x();
}
}
[Bug c/100661] [11/12 Regression] ICE in omp-low.c / refs_may_alias_p_2, at tree-ssa-alias.c:2460
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100661 --- Comment #6 from Richard Biener --- Ah, no, for the C++ example c[50] is local to _Z3fooPPc._omp_fn.0 and thus likely fine.
[Bug c++/101405] [12 Regression] internal compiler error: in reshape_init_class, at cp/decl.c:6483
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101405 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c/100661] [11/12 Regression] ICE in omp-low.c / refs_may_alias_p_2, at tree-ssa-alias.c:2460
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100661 --- Comment #7 from Jakub Jelinek --- (In reply to Richard Biener from comment #5) > Can lambdas appear inside #pragma omp in C++? Since OpenMP 5.0 yes. Well, they could appear before as well, but OpenMP 4.5 didn't support C++11, so it wasn't really defined how it behaves. But I think lambdas are fine.
