[Bug tree-optimization/29333] Jump threading getting in the way of PHI-OPT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29333 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #9 from Andrew Pinski --- This actually has been fixed fully since r9-3606.
[Bug c/15360] c99: extern w/initializer; extern w/internal linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15360
--- Comment #10 from Andrei Cherniaev ---
I suggest allow use directive extern without array size.
main.c:
#define size ( 1 )
char arr[size];
int main()
{
return 0;
}
second.c:
extern char arr[];
void f(){
sizeof(arr);
}
It was error:
invalid application of 'sizeof' to incomplete type 'char[]'
I can modify second.c: extern char arr[size];
But I ned export my define to second.c... It is not flexiable.
More than that, I can use mistake: in one file one size and in second size will
another...
main.c:
char arr[1];
int main()
{
return 0;
}
second.c:
extern char arr[999];
void f(){
sizeof(arr);
}
I think gcc should prevent it error. But now I can't see even warning...
So I suggest allow to use directive extern without array size.
[Bug fortran/101337] New: gfortran doesn't diagnose all operands with constraint violations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101337 Bug ID: 101337 Summary: gfortran doesn't diagnose all operands with constraint violations Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: sandra at gcc dot gnu.org Target Milestone: --- In a statement like a = x + y if both x and y violate constraints in the Fortran standard, gfortran only issues a diagnostic for the first invalid operand and ignores the other one. I ran into this in my WIP TS 29113 testsuite https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574115.html particularly in types/c407b-2.f90 and types/c535b-2.f90. I was figuring that since the standard requires implementations to diagnose constraint violations, it was supposed to diagnose *all* constraint violations, not give up after the first one in an expression. :-S This is probably very low on the scale of bang-for-the-buck so I am not really expecting it to be fixed any time soon, but as I've xfailed the tests looking for the omitted diagnostics it would be good to point to an issue recording the bug.
[Bug c/15360] c99: extern w/initializer; extern w/internal linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15360 Andrei Cherniaev changed: What|Removed |Added CC||dungeonlords789 at yandex dot ru --- Comment #9 from Andrei Cherniaev --- Created attachment 51107 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51107=edit extern directive test This project illustrate a problem when i try extern array.
[Bug target/93619] aarch64 target testsuite is so broken with -mcpu=*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93619 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #4 from Andrew Pinski --- No longer working on this.
[Bug rtl-optimization/100328] IRA doesn't model matching constraint well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100328 --- Comment #10 from CVS Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:c64d15224c6dc4dc3b6b3c2c6b6fd5c7e0e9c072 commit r12-2046-gc64d15224c6dc4dc3b6b3c2c6b6fd5c7e0e9c072 Author: Kewen Lin Date: Mon Jul 5 20:54:16 2021 -0500 i386: Disable param ira-consider-dup-in-all-alts [PR100328] With Hongtao's SPEC2017 performance evaluation result here: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573986.html this new parameter ira-consider-dup-in-all-alts has negative effects on i386, this patch is to disable it explicitly on i386. Bootstrapped & regtested on x86_64-redhat-linux. gcc/ChangeLog: PR rtl-optimization/100328 * config/i386/i386-options.c (ix86_option_override_internal): Set param_ira_consider_dup_in_all_alts to 0.
[Bug rtl-optimization/100328] IRA doesn't model matching constraint well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100328 --- Comment #9 from CVS Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:8ffe25eefae57fb3a228a2d31a57af5bdab8911f commit r12-2045-g8ffe25eefae57fb3a228a2d31a57af5bdab8911f Author: Kewen Lin Date: Mon Jul 5 20:53:19 2021 -0500 ira: Support more matching constraint forms with param [PR100328] This patch is to make IRA consider matching constraint heavily, even if there is at least one other alternative with non-NO_REG register class constraint, it will continue and check matching constraint in all available alternatives and respect the matching constraint with preferred register class. One typical case is destructive FMA style instruction on rs6000. Without this patch, for the mentioned FMA instruction, IRA won't respect the matching constraint on VSX_REG since there are some alternative with FLOAT_REG which doesn't have matching constraint. It can cause extra register copies since later reload has to make code to respect the constraint. This patch make IRA respect this matching constraint on VSX_REG which is the preferred regclass, but it excludes some cases where for one preferred register class there can be two or more alternatives, one of them has the matching constraint, while another doesn't have. It also considers the possibility of free register copy. With option Ofast unroll, this patch can help to improve SPEC2017 bmk 508.namd_r +2.42% and 519.lbm_r +2.43% on Power8 while 508.namd_r +3.02% and 519.lbm_r +3.85% on Power9 without any remarkable degradations. It also improved something on SVE as testcase changes showed and Richard's confirmation. Bootstrapped & regtested on powerpc64le-linux-gnu P9, x86_64-redhat-linux and aarch64-linux-gnu. gcc/ChangeLog: PR rtl-optimization/100328 * doc/invoke.texi (ira-consider-dup-in-all-alts): Document new parameter. * ira.c (ira_get_dup_out_num): Adjust as parameter param_ira_consider_dup_in_all_alts. * params.opt (ira-consider-dup-in-all-alts): New. * ira-conflicts.c (process_regs_for_copy): Add one parameter single_input_op_has_cstr_p. (get_freq_for_shuffle_copy): New function. (add_insn_allocno_copies): Adjust as single_input_op_has_cstr_p. * ira-int.h (ira_get_dup_out_num): Add one bool parameter. gcc/testsuite/ChangeLog: PR rtl-optimization/100328 * gcc.target/aarch64/sve/acle/asm/div_f16.c: Remove one xfail. * gcc.target/aarch64/sve/acle/asm/div_f32.c: Likewise. * gcc.target/aarch64/sve/acle/asm/div_f64.c: Likewise. * gcc.target/aarch64/sve/acle/asm/divr_f16.c: Likewise. * gcc.target/aarch64/sve/acle/asm/divr_f32.c: Likewise. * gcc.target/aarch64/sve/acle/asm/divr_f64.c: Likewise. * gcc.target/aarch64/sve/acle/asm/mad_f16.c: Likewise. * gcc.target/aarch64/sve/acle/asm/mad_f32.c: Likewise. * gcc.target/aarch64/sve/acle/asm/mad_f64.c: Likewise. * gcc.target/aarch64/sve/acle/asm/mla_f16.c: Likewise. * gcc.target/aarch64/sve/acle/asm/mla_f32.c: Likewise. * gcc.target/aarch64/sve/acle/asm/mla_f64.c: Likewise. * gcc.target/aarch64/sve/acle/asm/mls_f16.c: Likewise. * gcc.target/aarch64/sve/acle/asm/mls_f32.c: Likewise. * gcc.target/aarch64/sve/acle/asm/mls_f64.c: Likewise. * gcc.target/aarch64/sve/acle/asm/msb_f16.c: Likewise. * gcc.target/aarch64/sve/acle/asm/msb_f32.c: Likewise. * gcc.target/aarch64/sve/acle/asm/msb_f64.c: Likewise. * gcc.target/aarch64/sve/acle/asm/mulx_f16.c: Likewise. * gcc.target/aarch64/sve/acle/asm/mulx_f32.c: Likewise. * gcc.target/aarch64/sve/acle/asm/mulx_f64.c: Likewise. * gcc.target/aarch64/sve/acle/asm/nmad_f16.c: Likewise. * gcc.target/aarch64/sve/acle/asm/nmad_f32.c: Likewise. * gcc.target/aarch64/sve/acle/asm/nmad_f64.c: Likewise. * gcc.target/aarch64/sve/acle/asm/nmla_f16.c: Likewise. * gcc.target/aarch64/sve/acle/asm/nmla_f32.c: Likewise. * gcc.target/aarch64/sve/acle/asm/nmla_f64.c: Likewise. * gcc.target/aarch64/sve/acle/asm/nmls_f16.c: Likewise. * gcc.target/aarch64/sve/acle/asm/nmls_f32.c: Likewise. * gcc.target/aarch64/sve/acle/asm/nmls_f64.c: Likewise. * gcc.target/aarch64/sve/acle/asm/nmsb_f16.c: Likewise. * gcc.target/aarch64/sve/acle/asm/nmsb_f32.c: Likewise. * gcc.target/aarch64/sve/acle/asm/nmsb_f64.c: Likewise. * gcc.target/aarch64/sve/acle/asm/sub_f16.c: Likewise. * gcc.target/aarch64/sve/acle/asm/sub_f32.c: Likewise. *
[Bug tree-optimization/101256] [12 Regression] Wrong code with -O3 since r12-1841-g9fe9c45ae33a2df7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101256 Andrew Pinski changed: What|Removed |Added URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma |il/gcc-patches/2021-July/57 |il/gcc-patches/2021-July/57 |4412.html |4490.html --- Comment #7 from Andrew Pinski --- Updated patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574490.html
[Bug debug/101283] Several tests fail on Darwin with -gctf/gbtf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283 --- Comment #14 from Indu Bhagat --- With the two patches (commit r12-2044-ga3543b5e8002c033b2304d7ac1d1e58218eebb51 + the other in review) only two further failures remain to be looked into: FAIL: gcc.dg/debug/btf/btf-bitfields-3.c scan-assembler-times [\t ]0x2[\t ]+[^\n]*btm_type 1 FAIL: gcc.dg/debug/ctf/ctf-attr-mode-1.c scan-assembler-times [\t ]0x3[\t ]+[^\n]*ctv_typeidx 1 I will look into them next.
[Bug debug/101283] Several tests fail on Darwin with -gctf/gbtf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283 --- Comment #13 from CVS Commits --- The master branch has been updated by Indu Bhagat : https://gcc.gnu.org/g:a3543b5e8002c033b2304d7ac1d1e58218eebb51 commit r12-2044-ga3543b5e8002c033b2304d7ac1d1e58218eebb51 Author: Indu Bhagat Date: Mon Jul 5 17:28:24 2021 -0700 CTF,BTF testsuite: Use -gdwarf-4 for restrict type qualifier [PR101283] DWARF DIEs do not contain DW_TAG_restrict_type when DWARF version is 2. CTF/BTF generation feeds off DWARF DIEs, and as such, CTF records of kind CTF_K_RESTRICT cease to be generated when DWARF version is 2. This patch fixes the failure of these testcases on Darwin by using an explicit -gdwarf-4 in the dg-options. This keeps the CTF record generation for restrict type qualifier tested. PR debug/101283 - Several tests fail on Darwin with -gctf/gbtf 2021-07-05 Indu Bhagat gcc/testsuite/ChangeLog: PR debug/101283 * gcc.dg/debug/btf/btf-cvr-quals-1.c: Use -gdwarf-4 on Darwin targets. * gcc.dg/debug/ctf/ctf-cvr-quals-1.c: Likewise.
[Bug target/101324] powerpc64le: hashst appears before mflr at -O1 or higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324 --- Comment #2 from Segher Boessenkool --- So, even if I use -fno-shrink-wrap and, although rs6000.c has anyway /* If we are inserting ROP-protect instructions, disable shrink wrap. */ if (rs6000_rop_protect) flag_shrink_wrap = 0; we *still* get shrink-wrapping done here?! But that cannot work with the ROP protection stuff.
[Bug target/101324] powerpc64le: hashst appears before mflr at -O1 or higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324 --- Comment #1 from Segher Boessenkool --- Could you attach something that is a valid input to the compiler? Something that does not include the preprocessor directives... did you use -dM? Don't :-) (I can reproduce with this code, but there are many warnings :-) )
[Bug fortran/54753] assumed-rank dummies: Reject assumed-size actuals in in some cases (C535c; in F2018: C839)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54753 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #3 from sandra at gcc dot gnu.org --- I've encountered problems related to this constraint in my WIP TS29113 testsuite, too. https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574115.html This is the types/c535c-*.f90 tests. The wording of the constraint is really confusing to me. I've parsed it to mean that the "it" being referred to as the subject of the requirements in the second half of the sentence is the actual argument, not the dummy argument. c535c-1 is emitting a nonsensical diagnostic on the subroutine definition instead of meaningful diagnostics at the invalid call sites. c535c-2 is failing to produce diagnostics. c535c-3 and c535c-4 are dying with internal compiler errors. Of course it is possible that my Fortran code is buggy as well as my parsing of the constraint. :-S
[Bug debug/101283] Several tests fail on Darwin with -gctf/gbtf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283
--- Comment #12 from Indu Bhagat ---
The intention is to be able to generate CTF/BTF correctly irrespective of the
DWARF version.
The case of DW_TAG_restrict_type is unique though, and looks like we will need
special handling. To be specific, the 'restrict' keyword related failures are:
- gcc.dg/debug/ctf/ctf-cvr-quals-1.c
- gcc.dg/debug/btf/btf-cvr-quals-1.c
DW_TAG_restrict_type is not generated for DWARF-2. So, adding a target specific
option for these looks like a reasonable way forward.
So for the btf testcase, something like -
/* { dg-options "-O0 -gbtf -dA -gdwarf-4" { target { *-*-darwin* } } } */
Next, for some of the *-bitfield-*.c test failures, the issue can be masked
away by forcing -gdwarf-4, yes. But the correct fix can be done in dwarf2ctf.c
and with that, there is not need to force a -gdwarf-4 in those tests.
I will post a patch for these two soon.
[Bug libffi/101336] New: Incorrect target on gnux32 hosts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101336
Bug ID: 101336
Summary: Incorrect target on gnux32 hosts
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libffi
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
configure.host has
i?86-*-* | x86_64-*-* | amd64-*)
TARGETDIR=x86
if test $ac_cv_sizeof_size_t = 4; then
case "$host" in
*-gnux32)
TARGET=X86_64
;;
*)
echo 'int foo (void) { return __x86_64__; }' > conftest.c
if $CC $CFLAGS -Werror -S conftest.c -o conftest.s > /dev/null
2>&1; then
TARGET=X86_64;
else
TARGET=X86;
fi
rm -f conftest.*
;;
esac
else
TARGET=X86_64;
fi
;;
But for gnux32 hosts, -m32 generates ia32 codes. We should always
check __x86_64__ for x86 hosts.
[Bug libstdc++/101268] Refer manual readers to cppreference.com for API details
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101268 --- Comment #4 from Christopher Yeleighton --- (In reply to Jonathan Wakely from comment #1) > (In reply to Christopher Yeleighton from comment #0) > > (I mean patches are not welcome) > > Have you actually tried submitting any? I only see bug reports from you, not > patches. VERBVM CARO FACTVM EST https://gcc.gnu.org/bugzilla/attachment.cgi?id=51106 >
[Bug libstdc++/51539] multiplies ::operator () undocumented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51539 --- Comment #5 from Christopher Yeleighton --- Created attachment 51106 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51106=edit Add Doxygen documentation to items in stl_function.h
[Bug tree-optimization/101039] Some simple fold_cond_expr_with_comparison with CMP 0 is not simplified if expanded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101039 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Andrew Pinski --- Fixed.
[Bug middle-end/101237] HONOR_SIGNED_ZEROS (element_mode (t)) should be moved to just HONOR_SIGNED_ZEROS (t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101237 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |12.0 --- Comment #3 from Andrew Pinski --- Fixed.
[Bug debug/101283] Several tests fail on Darwin with -gctf/gbtf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283 --- Comment #11 from Iain Sandoe --- (In reply to Indu Bhagat from comment #10) > (In reply to Iain Sandoe from comment #9) > > (In reply to Iain Sandoe from comment #8) > > > we are now left with (where I suspect that the remaining fails are an > > > artefact of the way in which Darwin represents offsets instead of > > > relocations in DWARF debug sections): > > > > on a bit more looking, that is probably not the reason - I guess we will > > have to look at what the represented structures are and why they have > > different renderings for Darwin. > > I am looking into these failures one by one. It seems that the issue is as you noted on IRC, that Darwin defaults to generating DWARF-2. I have confirmed that overriding this to DWARF-4 for btf/ctf fixes the test fails - I'll make an interim patch to do this in Darwin's option processing. However, I guess the bottom line question is "do you intend to support versions of DWARF earlier than 4 as a source for BTF/CTF"? The corner-case comes when a user enables both CTF and DWARF, in which case we could be demanding a higher version of DWARF to support CTF than the system tools can handle for the dwarf output.
[Bug tree-optimization/101039] Some simple fold_cond_expr_with_comparison with CMP 0 is not simplified if expanded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101039 --- Comment #3 from CVS Commits --- The master branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:7d6979197274a662da7bdc564314afe8415865c1 commit r12-2041-g7d6979197274a662da7bdc564314afe8415865c1 Author: Andrew Pinski Date: Sat Jun 12 19:45:20 2021 -0700 Port most of the A CMP 0 ? A : -A to match To improve phiopt and be able to remove abs_replacement, this ports most of "A CMP 0 ? A : -A" from fold_cond_expr_with_comparison to match.pd. There is a few extra changes that are needed to remove the "A CMP 0 ? A : -A" part from fold_cond_expr_with_comparison: * Need to handle (A - B) case * Need to handle UN* comparisons. I will handle those in a different patch. Note phi-opt-15.c test needed to be updated as we get ABSU now instead of not getting ABS. When ABSU was added phiopt was not updated even to use ABSU instead of not creating ABS. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. gcc/ChangeLog: PR tree-optimization/101039 * match.pd (A CMP 0 ? A : -A): New patterns. * tree-ssa-phiopt.c (abs_replacement): Delete function. (tree_ssa_phiopt_worker): Don't call abs_replacement. Update comment about abs_replacement. gcc/testsuite/ChangeLog: PR tree-optimization/101039 * gcc.dg/tree-ssa/phi-opt-15.c: Update test to expect ABSU and still not expect ABS_EXPR. * gcc.dg/tree-ssa/phi-opt-23.c: New test. * gcc.dg/tree-ssa/phi-opt-24.c: New test.
[Bug middle-end/101237] HONOR_SIGNED_ZEROS (element_mode (t)) should be moved to just HONOR_SIGNED_ZEROS (t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101237 --- Comment #2 from CVS Commits --- The master branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:3c44b412fec8d5ab7fc064065414314a8ae05c87 commit r12-2038-g3c44b412fec8d5ab7fc064065414314a8ae05c87 Author: Andrew Pinski Date: Mon Jun 28 20:48:44 2021 -0700 Fix PR 101237: Remove element_type call when used with the functions from real HONOR_SIGNED_ZEROS, HONOR_SIGN_DEPENDENT_ROUNDING, and HONOR_SNANS all have an overload for taking a tree type now, so we should do that instead. OK? Bootstrapped and tested on x86_64-linux-gnu. gcc/ChangeLog: PR middle-end/101237 * fold-const.c (negate_expr_p): Remove call to element_mode and TREE_MODE/TREE_TYPE when calling HONOR_SIGNED_ZEROS, HONOR_SIGN_DEPENDENT_ROUNDING, and HONOR_SNANS. (fold_negate_expr_1): Likewise. (const_unop): Likewise. (fold_cond_expr_with_comparison): Likewise. (fold_binary_loc): Likewise. (fold_ternary_loc): Likewise. (tree_call_nonnegative_warnv_p): Likewise. * match.pd (-(A + B) -> (-B) - A): Likewise.
[Bug middle-end/101290] ICE with -O1 on valid code: in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:5976
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101290 --- Comment #2 from joseph at codesourcery dot com --- Anything constructing a constant-size type half the address space or larger in size should be diagnosed.
[Bug tree-optimization/101335] [12 Regression] wrong code at -O2 and above (casts between signed and unsigned)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101335 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org Summary|wrong code at -O2 and above |[12 Regression] wrong code ||at -O2 and above (casts ||between signed and ||unsigned) Target Milestone|--- |12.0
[Bug tree-optimization/101335] wrong code at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101335 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-07-05 Keywords||wrong-code Version|unknown |12.0 Summary|wrong code at -Os and above |wrong code at -O2 and above |on x86_64-linux-gnu | Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Also -fwrapv works around the issue, -fsanitize=undefined does not output any undefined behavior either. EVRP has the first difference. Before EVRP we had: a.0_1 = aD.1942; // -1u _2 = ~a.0_1; //0u c_9 = (intD.6) _2; //0 _3 = c_9 + -10; // -10 d_10 = (unsigned intD.9) _3; //-10u if (_2 < d_10) // 0u < -10u which is true But EVRP: Predicate evaluates to: DON'T KNOW folding with relation > Predicate evaluates to: 0 EVRP:hybrid: Second query simplifed stmt Folded into: if (0 != 0) CUT Looks like this value relation is being used but rather it should have just converted to != rather < with the casts happening: Registering value_relation (_3 < c_9) (bb2) at _3 = c_9 + -10;
[Bug target/100637] [i386] Vectorize 4-byte vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100637 --- Comment #11 from Uroš Bizjak --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:be8749f939a933bca6de19d9cf1a510d5954c2fa commit r12-2036-gbe8749f939a933bca6de19d9cf1a510d5954c2fa Author: Uros Bizjak Date: Mon Jul 5 21:05:10 2021 +0200 i386: Implement 4-byte vector (V4QI/V2HI) constant permutations 2021-07-05 Uroš Bizjak gcc/ * config/i386/i386-expand.c (ix86_split_mmx_punpck): Handle V4QI and V2HI modes. (expand_vec_perm_blend): Allow 4-byte vector modes with TARGET_SSE4_1. Handle V4QI mode. Emit mmx_pblendvb32 for 4-byte modes. (expand_vec_perm_pshufb): Rewrite to use switch statemets. Handle 4-byte dual operands with TARGET_XOP and single operands with TARGET_SSSE3. Emit mmx_ppermv32 for TARGET_XOP and mmx_pshufbv4qi3 for TARGET_SSSE3. (expand_vec_perm_pblendv): Allow 4-byte vector modes with TARGET_SSE4_1. (expand_vec_perm_interleave2): Allow 4-byte vector modes. (expand_vec_perm_pshufb2): Allow 4-byte vector modes with TARGET_SSSE3. (expand_vec_perm_even_odd_1): Handle V4QI mode. (expand_vec_perm_broadcast_1): Handle V4QI mode. (ix86_vectorize_vec_perm_const): Handle V4QI mode. * config/i386/mmx.md (mmx_ppermv32): New insn pattern. (mmx_pshufbv4qi3): Ditto. (*mmx_pblendw32): Ditto. (*mmx_pblendw64): Rename from *mmx_pblendw. (mmx_punpckhbw_low): New insn_and_split pattern. (mmx_punpcklbw_low): Ditto.
[Bug tree-optimization/101335] New: wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101335
Bug ID: 101335
Summary: wrong code at -Os and above on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
[636] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210705 (experimental) [master revision
59748b71805:2d42892d7cd:8e0b3827bbab6bf92d88d00909ecf8fb43365f39] (GCC)
[637] %
[637] % gcctk -O1 small.c; ./a.out
[638] %
[638] % gcctk -Os small.c
[639] % ./a.out
Aborted
[640] % cat small.c
unsigned a = 0x;
int b;
int main()
{
int c = ~a;
unsigned d = c - 10;
if (d > c)
c = 20;
b = -(c | 0);
if (b > -8)
__builtin_abort ();
return 0;
}
[Bug fortran/101334] New: gfortran fails to enforce C838 on disallowed uses of assumed-rank variable names + bogus errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101334 Bug ID: 101334 Summary: gfortran fails to enforce C838 on disallowed uses of assumed-rank variable names + bogus errors Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: sandra at gcc dot gnu.org Target Milestone: --- C838 in the 2018 Fortran standard (originally C535b in TS29113) says: An assumed-rank variable name shall not appear in a designator or expression except as an actual argument that corresponds to a dummy argument that is assumed-rank, the argument of the function C_LOC or C_SIZEOF from the intrinsic module ISO_C_BINDING (18.2), the first dummy argument of an intrinsic inquiry function, or the selector of a SELECT RANK statement. The WIP TS29113 testsuite https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574115.html has tests types/c535b-*.f90 for this. c535b-2 and c535b-3 are failing with several cases of missing diagnostics, or bogus errors. E.g. the latter test case focuses on the 2-argument form of the ASSOCIATED intrinsic and produces errors like Error: 'pointer' argument of 'associated' intrinsic at (1) must be of rank -1 in a context where I think assumed-rank should be allowed (first argument to an intrinsic inquiry function).
[Bug target/90077] musl has no multlib support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90077 Sergei Trofimovich changed: What|Removed |Added CC||slyfox at gcc dot gnu.org --- Comment #4 from Sergei Trofimovich --- Sent https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574482.html for review.
[Bug fortran/101333] New: gfortran fails to enforce C711 on assumed-type actual arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101333 Bug ID: 101333 Summary: gfortran fails to enforce C711 on assumed-type actual arguments Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: sandra at gcc dot gnu.org Target Milestone: --- C711 in the 2018 Fortran standard (originally C407c in TS 29113) says: "An assumed-type actual argument that corresponds to an assumed-rank dummy argument shall be assumed-shape or assumed-rank." gfortran is failing to diagnose violations when an assumed-size array or scalar is passed. Test case is c407-1.f90 from the TS29113 testsuite, WIP version posted here: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574115.html
[Bug fortran/101329] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101329
kargl at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2021-07-05
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC||kargl at gcc dot gnu.org
--- Comment #1 from kargl at gcc dot gnu.org ---
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 27bf3a7eafe..98155ce9d4c 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -5217,6 +5217,12 @@ is_c_interoperable (gfc_expr *expr, const char **msg,
bool c_loc, bool c_f_ptr)
{
*msg = NULL;
+ if (expr->expr_type == EXPR_NULL)
+{
+ *msg = "NULL() is not interoperable";
+ return false;
+}
+
if (expr->ts.type == BT_CLASS)
{
*msg = "Expression is polymorphic";
[Bug fortran/101330] ICE in free_expr0(): Bad expr type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101330
kargl at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-07-05
CC||kargl at gcc dot gnu.org
--- Comment #1 from kargl at gcc dot gnu.org ---
diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
index 357a1e15e01..37056ac035f 100644
--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -1074,7 +1074,6 @@ gfc_match_iterator (gfc_namespace **ns, bool permit_var)
}
if (':' == gfc_peek_ascii_char ())
{
- step = gfc_get_expr ();
if (gfc_match (": %e ", ) != MATCH_YES)
{
gfc_free_expr (begin);
[Bug tree-optimization/101301] Improving sparse switch statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101301
--- Comment #7 from Segher Boessenkool ---
Assuming that you divide the "default" case into ten pieces of 0.01 each,
some slight corrections:
(In reply to Thomas Koenig from comment #6)
> int foo3 (int n)
> {
> if (__builtin_expect_with_probability (n >= 5, 1, 0.55))
> {
> if (__builtin_expect_with_probability (n >= 7, 1, 0.33/0.55))
> {
> if (__builtin_expect_with_probability (n == 7, 1, 0.1/0.33))
> return 7;
> if (__builtin_expect_with_probability (n == 8, 1, 0.1/0.23))
> return 8;
> if (__builtin_expect_with_probability (n == 9, 1, 0.1/0.11))
> return 9;
0.1/0.13 for that last one.
>
> return 0;
> }
> else
> {
> if (__builtin_expect_with_probability (n == 5, 1, 0.1/0.22))
> return 5;
> if (__builtin_expect_with_probability (n == 6, 1, 0.1/0.11))
> return 6;
0.1/0.12
>
> return 0;
> }
> }
> else
> {
> if (__builtin_expect_with_probability (n >= 3, 1, 0.22/0.45))
> {
> if (__builtin_expect_with_probability (n == 3, 1, 0.1/0.22))
> return 3;
> if (__builtin_expect_with_probability (n == 4, 1, 0.1/0.11))
> return 4;
0.1/0.12
>
> return 0;
> }
> else
> {
> if (__builtin_expect_with_probability (n == 1, 1, 0.1/0.23))
> return 1;
> if (__builtin_expect_with_probability (n == 2, 1, 0.1/0.13))
> return 2;
>
> return 0;
> }
> }
> }
>
> the numbers on POWER9 become
>
> [tkoenig@gcc135 ~]$ gcc -O3 bench.c a.c
> [tkoenig@gcc135 ~]$ ./a.out
> foo: 7.134855
> foo2: 7.842507
> foo3: 6.624406
> [tkoenig@gcc135 ~]$ gcc -mcpu=native -O3 bench.c a.c
> [tkoenig@gcc135 ~]$ ./a.out
> foo: 6.458520
> foo2: 7.696735
> foo3: 6.196469
>
> where, on a few runs, the differene betweeh foo and foo3 with -mcpu=native
> sometimes disappears and sometimes is larger (gcc135 is not a benchmark
> machine).
>
> So, I'd say there some advantage in the compiler not lying to itself :-)
Yeah :-) Of course in your testing the nine named cases have the same
probability,
which is not very true in practice (but is there any better guess possible),
and
the "default" case has that same probability for GCC (is there a better
estimate
for that, maybe?)
(I expect there just is some typo or thinko somewhere in the pass, fwiw :-) )
[Bug middle-end/101326] std::optional returns forced through stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101326
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-07-05
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski ---
Take:
struct g {
unsigned long b;
};
struct a
{
struct g g1;
unsigned char c;
};
static inline void h(struct g *a)
{
a->b = 0;
}
static inline void j(struct a *a)
{
h(>g1);
a->c = 1;
}
struct a f(void)
{
struct a a;
j();
return a;
}
CUT
It works, I suspect in the case of std::optional, std::optional is marked as
BLKmode rather than TImode as the struct is marked as "ADDRESSABLE".
[Bug target/101332] [12 Regression] FAIL: g++.dg/opt/pr91838.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101332 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from H.J. Lu --- Dup. *** This bug has been marked as a duplicate of bug 101187 ***
[Bug tree-optimization/101187] enhancement for vector logic right shift with constant bigger than element precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101187 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #5 from H.J. Lu --- *** Bug 101332 has been marked as a duplicate of this bug. ***
[Bug target/101332] New: [12 Regression] FAIL: g++.dg/opt/pr91838.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101332 Bug ID: 101332 Summary: [12 Regression] FAIL: g++.dg/opt/pr91838.C Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: crazylht at gmail dot com Target Milestone: --- Target: x86-64 On x86-64, r12-1764 caused FAIL: g++.dg/opt/pr91838.C with -march=skylake-avx512: [hjl@gnu-skx-1 g++]$ gcc -S /export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/g++.dg/opt/pr91838.C -O2 -Wno-psabi -march=skylake-avx512 [hjl@gnu-skx-1 g++]$ cat pr91838.s .file "pr91838.C" .text .p2align 4 .globl _Z1fDv8_h .type _Z1fDv8_h, @function _Z1fDv8_h: .LFB0: .cfi_startproc vpxor %xmm0, %xmm0, %xmm0 ret .cfi_endproc .LFE0: .size _Z1fDv8_h, .-_Z1fDv8_h .ident "GCC: (GNU) 11.1.1 20210531 (Red Hat 11.1.1-3)" .section.note.GNU-stack,"",@progbits [hjl@gnu-skx-1 g++]$ /export/users/hjl/build/gnu/tools-build/gcc-gitlab-native/build-x86_64-linux/gcc/testsuite/g++8/../../xg++ -B/export/users/hjl/build/gnu/tools-build/gcc-gitlab-native/build-x86_64-linux/gcc/testsuite/g++8/../../ /export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/g++.dg/opt/pr91838.C -fdiagnostics-plain-output -nostdinc++ -I/export/users/hjl/build/gnu/tools-build/gcc-gitlab-native/build-x86_64-linux/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/export/users/hjl/build/gnu/tools-build/gcc-gitlab-native/build-x86_64-linux/x86_64-pc-linux-gnu/libstdc++-v3/include -I/export/gnu/import/git/gitlab/x86-gcc/libstdc++-v3/libsupc++ -I/export/gnu/import/git/gitlab/x86-gcc/libstdc++-v3/include/backward -I/export/gnu/import/git/gitlab/x86-gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++2a -pedantic-errors -Wno-long-long -O2 -Wno-psabi -w -masm=att -ffat-lto-objects -fno-ident -S -o pr91838.s -march=skylake-avx512 [hjl@gnu-skx-1 g++]$ cat pr91838.s .file "pr91838.C" .text .p2align 4 .globl _Z1fDv8_h .type _Z1fDv8_h, @function _Z1fDv8_h: .LFB0: .cfi_startproc movl$2056, %eax vmovd %eax, %xmm2 vpshuflw$0, %xmm2, %xmm1 vpmovzxbw %xmm1, %xmm1 vpmovzxbw %xmm0, %xmm0 vpsrlvw %xmm1, %xmm0, %xmm0 vpmovwb %xmm0, %xmm0 ret .cfi_endproc .LFE0: .size _Z1fDv8_h, .-_Z1fDv8_h .section.note.GNU-stack,"",@progbits [hjl@gnu-skx-1 g++]$
[Bug c++/101331] New: [12 Regression] ICE in sanitize_coverage_p, at asan.h:259
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101331
Bug ID: 101331
Summary: [12 Regression] ICE in sanitize_coverage_p, at
asan.h:259
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20210523 and 20210530 :
$ cat z1.cc
int a[2];
int b = 1;
int c { b && (a[b] = 0) };
$ g++-12-20210704 -c z1.cc -fsanitize-coverage=trace-pc -O2
z1.cc:3:25: internal compiler error: Segmentation fault
3 | int c { b && (a[b] = 0) };
| ^
0xd6677f crash_signal
../../gcc/toplev.c:328
0xaa2a2f sanitize_coverage_p
../../gcc/asan.h:259
0xaa2a2f fold_range_test
../../gcc/fold-const.c:6019
0xaa2a2f fold_truth_andor
../../gcc/fold-const.c:9624
0xa8fbf4 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:11931
0xa954aa fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:13736
0x7297db cp_fold
../../gcc/cp/cp-gimplify.c:2432
0x72ae0c cp_fold_maybe_rvalue(tree_node*, bool)
../../gcc/cp/cp-gimplify.c:2109
0x72f917 cp_convert_and_check(tree_node*, tree_node*, int)
../../gcc/cp/cvt.c:666
0x6e30ca convert_like_internal
../../gcc/cp/call.c:8105
0x6e30ca convert_like
../../gcc/cp/call.c:8160
0x6dfe69 convert_like
../../gcc/cp/call.c:8174
0x6dfe69 perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
../../gcc/cp/call.c:12364
0x88db30 convert_for_assignment
../../gcc/cp/typeck.c:9641
0x88df54 convert_for_initialization(tree_node*, tree_node*, tree_node*, int,
impl_conv_rhs, tree_node*, int, int)
../../gcc/cp/typeck.c:9732
0x89401e digest_init_r
../../gcc/cp/typeck2.c:1253
0x8957d0 digest_init_flags(tree_node*, tree_node*, int, int)
../../gcc/cp/typeck2.c:1266
0x8957d0 store_init_value(tree_node*, tree_node*, vec**, int)
../../gcc/cp/typeck2.c:742
0x751aed check_initializer
../../gcc/cp/decl.c:7167
0x752fe1 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:8101
[Bug middle-end/101326] std::optional returns forced through stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101326 --- Comment #1 from Tamar Christina --- last example for x86 should have been foo():# @foo() xor eax, eax mov dl, 1 ret
[Bug fortran/101330] New: ICE in free_expr0(): Bad expr type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101330 Bug ID: 101330 Summary: ICE in free_expr0(): Bad expr type Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started between 20210523 and 20210530 : $ cat z1.f90 !$omp task affinity (iterator(j=1:2: $ gfortran-12-20210704 -c z1.f90 -fopenmp f951: internal compiler error: free_expr0(): Bad expr type 0x6f7ee9 gfc_report_diagnostic ../../gcc/fortran/error.c:782 0x6f9a57 gfc_internal_error(char const*, ...) ../../gcc/fortran/error.c:1402 0x6fa901 free_expr0 ../../gcc/fortran/expr.c:509 0x6fa948 gfc_free_expr(gfc_expr*) ../../gcc/fortran/expr.c:530 0x743055 gfc_match_iterator ../../gcc/fortran/openmp.c:1082 0x744b89 gfc_match_omp_clauses ../../gcc/fortran/openmp.c:1367 0x74652e match_omp ../../gcc/fortran/openmp.c:3181 0x74e011 match_word ../../gcc/fortran/parse.c:65 0x74fa2f decode_omp_directive ../../gcc/fortran/parse.c:1073 0x753c55 next_free ../../gcc/fortran/parse.c:1325 0x753c55 next_statement ../../gcc/fortran/parse.c:1583 0x758e47 gfc_parse_file() ../../gcc/fortran/parse.c:6533 0x7a5c4f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug fortran/101329] New: ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101329 Bug ID: 101329 Summary: ICE: Invalid expression in gfc_element_size Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 : $ cat z1.f90 program p use iso_c_binding print *, c_sizeof(null()) end $ gfortran-12-20210704 -c z1.f90 f951: internal compiler error: Invalid expression in gfc_element_size. 0x6f7ee9 gfc_report_diagnostic ../../gcc/fortran/error.c:782 0x6f9a57 gfc_internal_error(char const*, ...) ../../gcc/fortran/error.c:1402 0x799c12 gfc_element_size(gfc_expr*, unsigned long*) ../../gcc/fortran/target-memory.c:137 0x799c73 gfc_target_expr_size(gfc_expr*, unsigned long*) ../../gcc/fortran/target-memory.c:166 0x78dc4b gfc_simplify_sizeof(gfc_expr*) ../../gcc/fortran/simplify.c:7550 0x70db3a do_simplify ../../gcc/fortran/intrinsic.c:4657 0x71858a gfc_intrinsic_func_interface(gfc_expr*, int) ../../gcc/fortran/intrinsic.c:5050 0x7691b9 resolve_unknown_f ../../gcc/fortran/resolve.c:2926 0x7691b9 resolve_function ../../gcc/fortran/resolve.c:3270 0x7691b9 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:7104 0x76f5f4 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:7071 0x76f5f4 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11832 0x76df3f gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:10851 0x76e308 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11822 0x770c17 resolve_codes ../../gcc/fortran/resolve.c:17427 0x770cde gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:17462 0x759224 resolve_all_program_units ../../gcc/fortran/parse.c:6403 0x759224 gfc_parse_file() ../../gcc/fortran/parse.c:6655 0x7a5c4f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug fortran/101328] New: ICE in conv_array_index_offset, at fortran/trans-array.c:3425
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101328 Bug ID: 101328 Summary: ICE in conv_array_index_offset, at fortran/trans-array.c:3425 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 : $ cat z1.f90 program p type t integer :: a = 1 end type contains subroutine s(x) type(t), intent(out) :: x(..) end end $ gfortran-12-20210704 -c z1.f90 z1.f90:6:15: 6 |subroutine s(x) | 1 internal compiler error: in conv_array_index_offset, at fortran/trans-array.c:3425 0x7b14bd conv_array_index_offset ../../gcc/fortran/trans-array.c:3425 0x7b1592 gfc_conv_scalarized_array_ref ../../gcc/fortran/trans-array.c:3556 0x7b205c gfc_conv_array_ref(gfc_se*, gfc_array_ref*, gfc_expr*, locus*) ../../gcc/fortran/trans-array.c:3700 0x7de92e gfc_conv_variable ../../gcc/fortran/trans-expr.c:3090 0x7dac4a gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:9025 0x7eafbf gfc_trans_assignment_1 ../../gcc/fortran/trans-expr.c:11346 0x7c941d gfc_init_default_dt(gfc_symbol*, stmtblock_t*, bool) ../../gcc/fortran/trans-decl.c:4298 0x7d14b0 init_intent_out_dt ../../gcc/fortran/trans-decl.c:4364 0x7d14b0 gfc_trans_deferred_vars(gfc_symbol*, gfc_wrapped_block*) ../../gcc/fortran/trans-decl.c:4705 0x7d3292 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:7002 0x7d2fa4 gfc_generate_contained_functions ../../gcc/fortran/trans-decl.c:5892 0x7d2fa4 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6830 0x759926 translate_all_program_units ../../gcc/fortran/parse.c:6464 0x759926 gfc_parse_file() ../../gcc/fortran/parse.c:6733 0x7a5c4f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug fortran/101327] New: ICE in find_array_element, at fortran/expr.c:1355
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101327 Bug ID: 101327 Summary: ICE in find_array_element, at fortran/expr.c:1355 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 : $ cat z1.f90 subroutine s integer, parameter :: n([2]) = [1, 2] type t integer :: a(n(1):n(2)) end type end $ gfortran-12-20210704 -c z1.f90 f951: internal compiler error: in find_array_element, at fortran/expr.c:1355 0x6fe17d find_array_element ../../gcc/fortran/expr.c:1354 0x6fe17d simplify_const_ref ../../gcc/fortran/expr.c:1882 0x6fe85e gfc_simplify_expr(gfc_expr*, int) ../../gcc/fortran/expr.c:2281 0x6feaab simplify_parameter_variable ../../gcc/fortran/expr.c:2110 0x6fe82d gfc_simplify_expr(gfc_expr*, int) ../../gcc/fortran/expr.c:2248 0x6ea784 variable_decl ../../gcc/fortran/decl.c:2640 0x6ea784 gfc_match_data_decl() ../../gcc/fortran/decl.c:6201 0x751bd3 match_word ../../gcc/fortran/parse.c:65 0x751bd3 decode_statement ../../gcc/fortran/parse.c:376 0x75361a next_free ../../gcc/fortran/parse.c:1351 0x75361a next_statement ../../gcc/fortran/parse.c:1583 0x755114 parse_derived ../../gcc/fortran/parse.c:3490 0x755114 parse_spec ../../gcc/fortran/parse.c:4031 0x757aac parse_progunit ../../gcc/fortran/parse.c:6009 0x759560 gfc_parse_file() ../../gcc/fortran/parse.c:6557 0x7a5c4f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug c++/101326] New: std::optional returns forced through stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101326
Bug ID: 101326
Summary: std::optional returns forced through stack
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Target Milestone: ---
The simple example
#include
std::optional foo() {
return 0;
}
shows suboptimal codegen at -O3 -std=c++17.
The values seem to be forced through the stack. On AArch64 we get
foo():
sub sp, sp, #16
mov w0, 1
strbw0, [sp, 8]
mov x0, 0
ldr x1, [sp, 8]
add sp, sp, 16
ret
instead of (what clang gives)
foo():// @foo()
mov w1, #1
mov x0, xzr
ret
On x86 it's the same:
foo():
mov QWORD PTR [rsp-24], 0
mov rax, QWORD PTR [rsp-24]
mov BYTE PTR [rsp-16], 1
mov rdx, QWORD PTR [rsp-16]
ret
vs
foo():// @foo()
mov w1, #1
mov x0, xzr
ret
[Bug target/101325] [12 Regression] arm: Wrong code with MVE vcmpeqq intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101325
--- Comment #1 from Alex Coplan ---
Execution test for the testsuite:
#include
__attribute((noinline,noipa))
unsigned foo(int8x16_t v, int8x16_t w)
{
return vcmpeqq (v, w);
}
int main(void)
{
if (foo (vdupq_n_s8(0), vdupq_n_s8(0)) != 0xU)
__builtin_abort ();
}
[Bug target/101325] New: [12 Regression] arm: Wrong code with MVE vcmpeqq intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101325
Bug ID: 101325
Summary: [12 Regression] arm: Wrong code with MVE vcmpeqq
intrinsic
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
For the following C testcase:
#include
mve_pred16_t foo(int8x16_t v, int8x16_t w)
{
return vcmpeqq (v, w);
}
GCC trunk with -O2 -march=armv8.1-m.main+mve -mfloat-abi=hard gives:
foo:
vcmp.i8 eq, q0, q1
vmrs r0, P0 @ movhi
and r0, r0, #1
bx lr
but the and clears all but the lowest bit of the mask, which is incorrect. GCC
11 and 10 do not appear to be affected. Instead, they generate:
foo:
vcmp.i8 eq, q0, q1
vmrs r0, P0 @ movhi
uxthr0, r0
bx lr
[Bug target/101324] New: powerpc64le: hashst appears before mflr at -O1 or higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324 Bug ID: 101324 Summary: powerpc64le: hashst appears before mflr at -O1 or higher Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: tuliom at ascii dot art.br Target Milestone: --- Created attachment 51105 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51105=edit __memmove_ppc extracted from glibc When using ROP (-mrop-protect), it's expected that generated code reads the value from LR (mflr) and hash it later (hashst). This works well at -O0. However, at -O1 and higher, we're seeing cases where hashst appears before mflr. I'm attaching an example extracted from glibc. You can reproduce the issue with command: gcc -S -O1 -mrop-protect -mcpu=power10 memmove-ppc64.i -o - The generated asm contains the following: __memmove_ppc: .LFB6: .cfi_startproc .localentry __memmove_ppc,1 hashst 0,-40(1) std 28,-32(1) stdu 1,-80(1) .cfi_def_cfa_offset 80 .cfi_offset 28, -32 mr 28,3 subf 9,4,3 cmpld 0,9,5 bge 0,.L17 std 31,72(1) .cfi_offset 31, -8 add 4,4,5 add 31,3,5 cmpldi 0,5,15 ble 0,.L4 mflr 0 ...
[Bug debug/101283] Several tests fail on Darwin with -gctf/gbtf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283 --- Comment #10 from Indu Bhagat --- (In reply to Iain Sandoe from comment #9) > (In reply to Iain Sandoe from comment #8) > > we are now left with (where I suspect that the remaining fails are an > > artefact of the way in which Darwin represents offsets instead of > > relocations in DWARF debug sections): > > on a bit more looking, that is probably not the reason - I guess we will > have to look at what the represented structures are and why they have > different renderings for Darwin. I am looking into these failures one by one.
[Bug testsuite/101321] gcc.dg/debug/btf/btf-bitfields-3.c fail on arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101321 Christophe Lyon changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Christophe Lyon --- Fixed
[Bug testsuite/101321] gcc.dg/debug/btf/btf-bitfields-3.c fail on arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101321 --- Comment #3 from CVS Commits --- The master branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:0ea47850bbb38ea81a34c503533d4dd0f3391f19 commit r12-2005-g0ea47850bbb38ea81a34c503533d4dd0f3391f19 Author: Christophe Lyon Date: Mon Jul 5 11:33:45 2021 + testsuite: gcc.dg/debug/btf/btf-bitfields-3.c requires -fno-short-enums PR debug/101321 arm-eabi uses -fshort-enums by default while arm-linux-gnueabi* do not, like most (all?) other targets, but this test relies -fno-short-enums. Fix it by forcing -fno-short-enums. 2021-07-05 Christophe Lyon PR debug/101321 gcc/testsuite/ * gcc.dg/debug/btf/btf-bitfields-3.c: Add -fno-short-enums.
[Bug target/101177] sh3: internal compiler error: Illegal instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101177 --- Comment #3 from Harold Gutch --- With my patch, the NetBSD/dreamcast build successfully reaches multiuser. Also, note that the rest of the commit looks very much like what the commit message described, but I don't see anything that might explain the inversion in the comparison, leading me to believe that this was a typo that managed to sneak in by accident.
[Bug tree-optimization/101291] [10/11 Regression] turns infinite loop into finite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101291 Richard Biener changed: What|Removed |Added Known to work||12.0 Summary|[10/11/12 Regression] turns |[10/11 Regression] turns |infinite loop into finite |infinite loop into finite --- Comment #11 from Richard Biener --- Fixed on trunk sofar.
[Bug target/101323] New: ICE: Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101323
Bug ID: 101323
Summary: ICE: Segmentation fault signal terminated program cc1
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: powerpc-*-linux-gnu
gcc-12.0.0-alpha20210704 snapshot (g:d07092a61d5a6907b2d92563e810bf5bb8e61c01)
ICEs when compiling the following testcase, reduced from
test/CodeGen/builtins-ppc-pair-mma.c from the clang 12.0.0 test suite, w/
-mcpu=power7:
__vector_pair vp;
void
test75 (__vector_pair *vpp)
{
vp = __builtin_vsx_lxvp (0, vpp);
}
% powerpc-e300c3-linux-gnu-gcc-12.0.0 -mcpu=power7 -c gkczfgfq.c
gkczfgfq.c: In function 'test75':
gkczfgfq.c:6:8: error: '__builtin_vsx_lxvp' requires the '-mmma' option
6 | vp = __builtin_vsx_lxvp (0, vpp);
|^~~
powerpc-e300c3-linux-gnu-gcc-12.0.0: internal compiler error: Segmentation
fault signal terminated program cc1
(gdb) where 20
#0 0x009173bc in set_page_table_entry (p=0x762fc000,
entry=entry@entry=0x23ea120)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_alpha20210704/work/gcc-12-20210704/gcc/ggc-page.c:646
#1 0x00918244 in alloc_page (order=)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_alpha20210704/work/gcc-12-20210704/gcc/ggc-page.c:939
#2 ggc_internal_alloc (size=size@entry=24, f=f@entry=0x0, s=s@entry=0,
n=n@entry=1)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_alpha20210704/work/gcc-12-20210704/gcc/ggc-page.c:1294
#3 0x00dd90b5 in ggc_internal_alloc (s=24)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_alpha20210704/work/gcc-12-20210704/gcc/ggc.h:130
#4 ggc_alloc_rtx_def_stat (s=24)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_alpha20210704/work/gcc-12-20210704/gcc/ggc.h:303
#5 rtx_alloc_stat_v (code=code@entry=SUBREG, extra=extra@entry=0)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_alpha20210704/work/gcc-12-20210704/gcc/rtl.c:222
#6 0x00dd90d7 in rtx_alloc (code=code@entry=SUBREG)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_alpha20210704/work/gcc-12-20210704/gcc/rtl.c:242
#7 0x00a6fb8e in gen_rtx_fmt_ep_stat (arg1=..., arg0=0x762fbfc0,
mode=E_SImode, code=SUBREG) at ./genrtl.h:719
#8 gen_rtx_SUBREG (mode=E_SImode, reg=reg@entry=0x762fbfc0, offset=...)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_alpha20210704/work/gcc-12-20210704/gcc/emit-rtl.c:1023
#9 0x00e23514 in simplify_context::simplify_gen_subreg
(this=this@entry=0x7bfff384, outermode=,
op=op@entry=0x762fbfc0, innermode=innermode@entry=E_OOmode, byte=...)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_alpha20210704/work/gcc-12-20210704/gcc/simplify-rtx.c:7354
#10 0x00a72300 in simplify_gen_subreg (byte=..., innermode=E_OOmode,
op=0x762fbfc0, outermode=)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_alpha20210704/work/gcc-12-20210704/gcc/rtl.h:3401
#11 operand_subword (op=0x762fbfc0, offset=..., validate_address=1,
mode=E_OOmode)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_alpha20210704/work/gcc-12-20210704/gcc/emit-rtl.c:1776
#12 0x00ab2292 in emit_move_multi_word (mode=E_OOmode, x=, y=0x777cefa8)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_alpha20210704/work/gcc-12-20210704/gcc/poly-int.h:671
#13 0x00aadc3f in emit_move_insn (x=x@entry=0x762fbfc0,
y=y@entry=0x777cefa8)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_alpha20210704/work/gcc-12-20210704/gcc/expr.c:4035
#14 0x00a86854 in copy_to_reg (x=x@entry=0x777cefa8)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_alpha20210704/work/gcc-12-20210704/gcc/explow.c:624
#15 0x00a724c8 in operand_subword_force (op=op@entry=0x777cefa8,
offset=offset@entry=..., mode=mode@entry=E_OOmode)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_alpha20210704/work/gcc-12-20210704/gcc/emit-rtl.c:1799
#16 0x00ab237e in emit_move_multi_word (mode=E_OOmode, x=, y=0x777cefa8)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_alpha20210704/work/gcc-12-20210704/gcc/expr.c:3825
#17 0x00aadc3f in emit_move_insn (x=x@entry=0x762fbf78,
y=y@entry=0x777cefa8)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_alpha20210704/work/gcc-12-20210704/gcc/expr.c:4035
#18 0x00a86854 in copy_to_reg (x=x@entry=0x777cefa8)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-12.0.0_alpha20210704/work/gcc-12-20210704/gcc/explow.c:624
#19 0x00a724c8 in operand_subword_force
[Bug tree-optimization/101291] [10/11/12 Regression] turns infinite loop into finite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101291 --- Comment #10 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:38872c6c0db1b10b17d3913b277c499913208d0b commit r12-2003-g38872c6c0db1b10b17d3913b277c499913208d0b Author: Richard Biener Date: Mon Jul 5 11:53:07 2021 +0200 middle-end/101291 - set loop copy of versioned loop This fixes the vectorizer loop versioning code failing to clear niter related info on the scalar loop as it assumed get_loop_copy would work even for the outermost loop. The patch makes that assumption hold by adjusting the loop versioning code. 2021-07-05 Richard Biener PR middle-end/101291 * cfgloopmanip.c (loop_version): Set the loop copy of the versioned loop to the new loop.
[Bug preprocessor/97577] [11/12 Regression] ICE: Segmentation fault (in get_location_from_adhoc_loc) by r11-4128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97577 --- Comment #4 from Arseny Solokha --- % MALLOC_PERTURB_=1 MALLOC_CHECK_=3 gcc-12.0.0 -c tt.c tt.c:5:9: error: #if with no expression 5 | #if M1() | ^ tt.c:7:9: internal compiler error: Segmentation fault 7 | #pragma pack() | ^~~~ (in get_data_from_adhoc_loc).
[Bug tree-optimization/101291] [10/11/12 Regression] turns infinite loop into finite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101291 Richard Biener changed: What|Removed |Added Summary|turns infinite loop into|[10/11/12 Regression] turns |finite |infinite loop into finite Target Milestone|--- |10.4 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Priority|P3 |P2 --- Comment #9 from Richard Biener --- Testing a patch. No testcase, not sure how to test for "infinite loop".
[Bug target/101296] Addition of x86 addsub SLP patterned slowed down 433.milc by 12% on znver2 with -Ofast -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101296 --- Comment #4 from Richard Biener --- Disabling vectorization for mult_su3_nn (the one with the vaddsubpd instructions) still reproduces 433.milc 9180126 73.1 *9180133 69.2 * and thus a 5% slowdown.
[Bug target/101296] Addition of x86 addsub SLP patterned slowed down 433.milc by 12% on znver2 with -Ofast -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101296 --- Comment #3 from Richard Biener --- Created attachment 51104 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51104=edit mult_su3_nn testcase This is the function with the (nearly) only and many vaddsubpd instructions. With the addsub pattern we have 15 addsub and 33 fma, 51 mul, 14 add and 3 sub while without the pattern we have zero addsub and 54 fma, 54 mul, 32 add and 9 sub. Detecting fmaddsub directly in the vectorizer might be worthwhile.
[Bug target/101296] Addition of x86 addsub SLP patterned slowed down 433.milc by 12% on znver2 with -Ofast -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101296
--- Comment #2 from Richard Biener ---
Samples: 884K of event 'cycles:u', Event count (approx.): 96751841
Overhead Samples Command Shared Object Symbol
13.76%119196 milc_peak.amd64 milc_peak.amd64-m64-mine [.]
u_shift_fermion #
10.08% 87085 milc_base.amd64 milc_base.amd64-m64-mine [.]
add_force_to_mom#
9.93% 85891 milc_base.amd64 milc_base.amd64-m64-mine [.]
u_shift_fermion #
9.38% 81331 milc_peak.amd64 milc_peak.amd64-m64-mine [.]
add_force_to_mom#
9.03% 82570 milc_peak.amd64 milc_peak.amd64-m64-mine [.]
mult_su3_na #
8.55% 77803 milc_base.amd64 milc_base.amd64-m64-mine [.]
mult_su3_na #
7.41% 65641 milc_peak.amd64 milc_peak.amd64-m64-mine [.]
mult_su3_nn #
6.26% 55314 milc_base.amd64 milc_base.amd64-m64-mine [.]
mult_su3_nn #
1.48% 12876 milc_peak.amd64 milc_peak.amd64-m64-mine [.]
mult_su3_an #
1.42% 12625 milc_base.amd64 milc_base.amd64-m64-mine [.]
imp_gauge_force.constprop.0 #
1.18% 10602 milc_peak.amd64 milc_peak.amd64-m64-mine [.]
imp_gauge_force.constprop.0 #
1.00% 8853 milc_base.amd64 milc_base.amd64-m64-mine [.]
mult_su3_mat_vec_sum_4dir #
0.94% 8343 milc_peak.amd64 milc_peak.amd64-m64-mine [.]
mult_su3_mat_vec_sum_4dir #
0.94% 8156 milc_base.amd64 milc_base.amd64-m64-mine [.]
mult_su3_an
The odd thing is that for example mult_su3_an reports vastly different
amount of cycles but the assembly is 1:1 identical.
There are in total 16 vaddsubpd instructions in the new variant in
symbols add_force_to_mom (1) and mult_su3_nn (15) but that doesn't
explain the difference seen above.
There are more detected ADDSUB patterns but they do not materialize in the
end, still there's some effect on RA and scheduling in functions like
u_shift_fermion, but the vectorizer dumps do not reveal anything interesting
for this example either.
I was using the following to disable the added pattern:
diff --git a/gcc/tree-vect-slp-patterns.c b/gcc/tree-vect-slp-patterns.c
index 2671f91972d..388b185dc7b 100644
--- a/gcc/tree-vect-slp-patterns.c
+++ b/gcc/tree-vect-slp-patterns.c
@@ -1510,7 +1510,7 @@ addsub_pattern::recognize (slp_tree_to_load_perm_map_t *,
slp_tree *node_)
{
slp_tree node = *node_;
if (SLP_TREE_CODE (node) != VEC_PERM_EXPR
- || SLP_TREE_CHILDREN (node).length () != 2)
+ || SLP_TREE_CHILDREN (node).length () != 2 || 1)
return NULL;
/* Match a blend of a plus and a minus op with the same number of plus and
To sum up - I have no idea why performance has regressed.
[Bug testsuite/101321] gcc.dg/debug/btf/btf-bitfields-3.c fail on arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101321 --- Comment #2 from Christophe Lyon --- OK, makes sense, thanks!
[Bug testsuite/101321] gcc.dg/debug/btf/btf-bitfields-3.c fail on arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101321 Andrew Pinski changed: What|Removed |Added Component|debug |testsuite --- Comment #1 from Andrew Pinski --- >The new test gcc.dg/debug/btf/btf-bitfields-3.c fails on arm-eabi, but works >on arm-linux-gnueabi: So on arm-eabi -fshort-enum is default while on arm-linux-gnueabi it is not. So the testcase needs to have -fno-short-enum added to it.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 ralphengels at gmail dot com changed: What|Removed |Added CC||ralphengels at gmail dot com --- Comment #13 from ralphengels at gmail dot com --- sadly the successfull build of gcc-11 with dwarf exceptions cannot bootstrap gcc-11 as well, though it now fails even in stage 1 the error is different and seems to be equal to one encountered several years back with gcc-4.1.0 -> TARGET_CPU_DEFAULT="" \ HEADERS="auto-host.h ansidecl.h config/i386/xm-mingw32.h" DEFINES="USED_FOR_TARGET " \ /bin/sh ../../gcc-11.1.0/gcc/mkconfig.sh tconfig.h gnatmake: "xsinfo.adb" compilation error echo " S0 : constant String := \"/mingw32/\";" >>tmp-sdefault.adb cat ../../gcc-11.1.0/gcc/config/i386/gmm_malloc.h > mm_malloc.h /bin/sh: line 1: ./xsinfo: No such file or directory (echo "@set version-GCC 11.1.0"; \ if [ "" = "experimental" ]; \ then echo "@set DEVELOPMENT"; \ else echo "@clear DEVELOPMENT"; \ fi) > gcc-vers.texiT make[3]: *** [../../gcc-11.1.0/gcc/ada/Make-generated.in:45: ada/sinfo.h] Error 127 make[3]: *** Waiting for unfinished jobs
[Bug debug/101321] New: gcc.dg/debug/btf/btf-bitfields-3.c fail on arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101321 Bug ID: 101321 Summary: gcc.dg/debug/btf/btf-bitfields-3.c fail on arm-eabi Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Hi, The new test gcc.dg/debug/btf/btf-bitfields-3.c fails on arm-eabi, but works on arm-linux-gnueabi: gcc.dg/debug/btf/btf-bitfields-3.c: [\t ]0x2[\t ]+[^\n]*btm_type found 0 times FAIL: gcc.dg/debug/btf/btf-bitfields-3.c scan-assembler-times [\t ]0x2[\t ]+[^\n]*btm_type 1 The actual contents seems to be: .4byte 0x4 @ btm_type Should the test be updated, or is there a bug in the compiler? (Sorry I'm not familiar with btf)
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #230 from John Buddery --- The mpfr issue seems to be an issue with gcc 4.9.2 compiling later mpfr versions. It builds with 4.7.2, so as a workaround try building mpfr outside the gcc tree using 4.7.2. This may mean you need to build gmp and mpc outside the tree as well. I don't know about the ld crash - see if it occurs when building 11.1 after you get past the mpfr issue. If it does, that binutils patch will probably work with older binutils versions, so you might be able to find one compatible with your ld. I don't think it's the patch itself, as that only affects brl instructions which gcc won't be generating until the 11.1 patch.
[Bug libstdc++/101306] positioning at line anchors is disturbed by the navigation bar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101306 --- Comment #5 from Jonathan Wakely --- MOVED is the appropriate resolution, thanks
[Bug libstdc++/57840] ::std ::result_of is undocumented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57840 --- Comment #10 from Jonathan Wakely --- No that has never been true. The date in the URL is a clue.
[Bug testsuite/101299] bb-slp-74.c fails on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101299 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Richard Biener --- Hopefully fixed. Please re-open if not.
[Bug testsuite/101299] bb-slp-74.c fails on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101299 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:ccb4e0774b3e5859ea1d7f1864b02fa5826c4a79 commit r12-2002-gccb4e0774b3e5859ea1d7f1864b02fa5826c4a79 Author: Richard Biener Date: Mon Jul 5 08:38:29 2021 +0200 testsuite/101299 - add missing vect_double requires to bb-slp-74.c This should fix the FAIL of gcc.dg/vect/bb-slp-74.c on arm. 2021-07-05 Richard Biener PR testsuite/101299 * gcc.dg/vect/bb-slp-74.c: Add vect_double requires.
[Bug target/101311] GCC refuses to use SSE registers to carry out an explicit XOR on a float.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101311
--- Comment #3 from Richard Biener ---
float func(float a)
{
union { float f; unsigned u; } u;
u.f = a;
u.u ^= 0x8000;
return u.f;
}
is the example w/o TBAA issue and down to the point WRT refusing negate via
XOR.
movd%xmm0, %eax
addl$-2147483648, %eax
movd%eax, %xmm0
ret
The core issue (besides transforming XOR to ADD) is that *xorsi_1 does not
have a xmm alternative:
(insn 7 6 11 2 (parallel [
(set (subreg:SI (reg:SF 84 [ ]) 0)
(xor:SI (subreg:SI (reg:SF 88) 0)
(const_int -2147483647 [0x8001])))
(clobber (reg:CC 17 flags))
]) "t.c":6:12 529 {*xorsi_1}
and this we are forced to allocate a GPR. The XOR to ADD is done via
the *lea_general_4 splitters I think. Not sure if adding xmm
alternatives really makes sense but STV doesn't consider the above since
there are subregs involved already and it checks for REG_P instead of
REG_OR_SUBREG_P.
It might be a idea to specifically split the subreg case into yet another
insn variant ...
[Bug testsuite/101299] bb-slp-74.c fails on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101299 Richard Biener changed: What|Removed |Added Version|9.0 |12.0 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2021-07-05 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- I will have a look.
[Bug preprocessor/101298] [11/12 Regression] Inclusion of a file without trailing newline breaks -fdirectives-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101298 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.2 Summary|Inclusion of a file without |[11/12 Regression] |trailing newline breaks |Inclusion of a file without |-fdirectives-only |trailing newline breaks ||-fdirectives-only
