[Bug rtl-optimization/109592] Failure to recognize shifts as sign/zero extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109592
--- Comment #2 from Feng Wang ---
(In reply to Feng Wang from comment #1)
> Hi Jeff,
>
> I have modified some code according to your suggestion.
> In simplify-rtx.cc I add below part in canonicalize_shift:
> if ((code == ASHIFTRT)
> && is_a (mode, _mode)
> && GET_CODE (op0) == ASHIFT
> && CONST_INT_P (op1)
> && is_a (GET_MODE (op0), _mode)
> && CONST_INT_P (XEXP (op0, 1))
> && (INTVAL (XEXP (op0, 1)) == INTVAL (op1)))
> {
> tem = XEXP (op0, 0);
> if (SUBREG_P(XEXP (op0, 0))
> && is_a (GET_MODE (SUBREG_REG (XEXP (op0,
> 0))),
> _mode)
> && GET_MODE_BITSIZE (inner_mode) > GET_MODE_BITSIZE (int_mode))
> {
> tem = XEXP (XEXP (op0, 0), 0);
> }
>
> if ((INTVAL (op1) + 8 == 32) || (INTVAL (op1) + 8 == 64))
> {
> op0 = lowpart_subreg (E_QImode, tem, GET_MODE(tem));
> return simplify_gen_unary (SIGN_EXTEND, int_mode, op0, int_mode);
> }
>
> if ((INTVAL (op1) + 16 == 32) || (INTVAL (op1) + 16 == 64))
> {
> op0 = lowpart_subreg (E_HImode, tem, GET_MODE(tem));
> return simplify_gen_unary (SIGN_EXTEND, int_mode, op0, int_mode);
> }
> }
>
> and at the same time in fwprop.cc I add below conditions in classify_result
> to judge whether replacement is PROFITABLE
> /* If have load byte or load half pattern, we can covert
> ashiftrt(ashift(object)const)const to load byte or half form object */
> if (GET_CODE(old_rtx) == ASHIFTRT
> && GET_CODE(new_rtx) == SIGN_EXTEND
> && ((GET_MODE(new_rtx) == E_SImode
>&& ((GET_MODE(XEXP(new_rtx, 0)) == E_QImode
> && HAVE_extendqisi2)
> || (GET_MODE(XEXP(new_rtx, 0)) == E_HImode
> && HAVE_extendhisi2)))
> ||(GET_MODE(new_rtx) == E_DImode
>&& ((GET_MODE(XEXP(new_rtx, 0)) == E_QImode
> && HAVE_extendqidi2)
> || (GET_MODE(XEXP(new_rtx, 0)) == E_HImode
> && HAVE_extendhidi2
> return PROFITABLE;
>
> Please check if it is reasonable and look forward to further discussion with
> you.Thanks!
Professional second punch manufacturer supplier.
Hello friend， This is Lin from China Guangdong rijinsheng hardware products co., LTD(Dongguan sunrise hardware products co., LTD). We have been specializing in the production of fastener froming tools for 15 years. Our screw molds offer top-quality materials and reliable durability, with fast delivery times and competitive pricing，and website is www.fastenerdie.com. We look forward to working with you and answering any questions you may have. Sincerely， Mr.Lin | | recesspunch | | recesspu...@163.com |
[Bug target/108812] gcc.target/powerpc/p9-sign_extend-runnable.c fails on power 9 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108812 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by HaoChen Gui : https://gcc.gnu.org/g:af55b56c748b86a2c7e88c3c484dcb2c8602ce7a commit r11-10650-gaf55b56c748b86a2c7e88c3c484dcb2c8602ce7a Author: Haochen Gui Date: Mon Apr 24 10:56:00 2023 +0800 rs6000: correct vector sign extend builtins on Big Endian gcc/ PR target/108812 * config/rs6000/vsx.md (vsx_sign_extend_qi_): Rename to... (vsx_sign_extend_v16qi_): ... this. (vsx_sign_extend_hi_): Rename to... (vsx_sign_extend_v8hi_): ... this. (vsx_sign_extend_si_v2di): Rename to... (vsx_sign_extend_v4si_v2di): ... this. (vsignextend_qi_): Remove. (vsignextend_hi_): Remove. (vsignextend_si_v2di): Remove. (vsignextend_v2di_v1ti): Remove. (*xxspltib__split): Replace gen_vsx_sign_extend_qi_v2di with gen_vsx_sign_extend_v16qi_v2di and gen_vsx_sign_extend_qi_v4si with gen_vsx_sign_extend_v16qi_v4si. * config/rs6000/rs6000.md (split for DI constant generation): Replace gen_vsx_sign_extend_qi_si with gen_vsx_sign_extend_v16qi_si. (split for HSDI constant generation): Replace gen_vsx_sign_extend_qi_di with gen_vsx_sign_extend_v16qi_di and gen_vsx_sign_extend_qi_si with gen_vsx_sign_extend_v16qi_si. * config/rs6000/rs6000-builtin.def (__builtin_altivec_vsignextsb2d): Set ICODE to vsx_sign_extend_v16qi_v2di. (__builtin_altivec_vsignextsb2w): Set ICODE to vsx_sign_extend_v16qi_v4si. (__builtin_altivec_visgnextsh2d): Set ICODE to vsx_sign_extend_v8hi_v2di. (__builtin_altivec_vsignextsh2w): Set ICODE to vsx_sign_extend_v8hi_v4si. (__builtin_altivec_vsignextsw2d): Set ICDE to vsx_sign_extend_si_v2di. (__builtin_altivec_vsignext): Set ICODE to vsx_sign_extend_v2di_v1ti. gcc/testsuite/ PR target/108812 * gcc.target/powerpc/p9-sign_extend-runnable.c: Set corresponding expected vectors for Big Endian. * gcc.target/powerpc/int_128bit-runnable.c: Likewise.
[Bug rtl-optimization/109592] Failure to recognize shifts as sign/zero extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109592
Feng Wang changed:
What|Removed |Added
CC||wangfeng at eswincomputing dot
com
--- Comment #1 from Feng Wang ---
Hi Jeff,
I have modified some code according to your suggestion.
In simplify-rtx.cc I add below part in canonicalize_shift:
if ((code == ASHIFTRT)
&& is_a (mode, _mode)
&& GET_CODE (op0) == ASHIFT
&& CONST_INT_P (op1)
&& is_a (GET_MODE (op0), _mode)
&& CONST_INT_P (XEXP (op0, 1))
&& (INTVAL (XEXP (op0, 1)) == INTVAL (op1)))
{
tem = XEXP (op0, 0);
if (SUBREG_P(XEXP (op0, 0))
&& is_a (GET_MODE (SUBREG_REG (XEXP (op0, 0))),
_mode)
&& GET_MODE_BITSIZE (inner_mode) > GET_MODE_BITSIZE (int_mode))
{
tem = XEXP (XEXP (op0, 0), 0);
}
if ((INTVAL (op1) + 8 == 32) || (INTVAL (op1) + 8 == 64))
{
op0 = lowpart_subreg (E_QImode, tem, GET_MODE(tem));
return simplify_gen_unary (SIGN_EXTEND, int_mode, op0, int_mode);
}
if ((INTVAL (op1) + 16 == 32) || (INTVAL (op1) + 16 == 64))
{
op0 = lowpart_subreg (E_HImode, tem, GET_MODE(tem));
return simplify_gen_unary (SIGN_EXTEND, int_mode, op0, int_mode);
}
}
and at the same time in fwprop.cc I add below conditions in classify_result to
judge whether replacement is PROFITABLE
/* If have load byte or load half pattern, we can covert
ashiftrt(ashift(object)const)const to load byte or half form object */
if (GET_CODE(old_rtx) == ASHIFTRT
&& GET_CODE(new_rtx) == SIGN_EXTEND
&& (GET_MODE(new_rtx) == E_SImode
&& (((GET_MODE(XEXP(new_rtx, 0)) == E_QImode)
&& HAVE_extendqisi2)
|| ((GET_MODE(XEXP(new_rtx, 0)) == E_HImode)
&& HAVE_extendhisi2)))
|| (GET_MODE(new_rtx) == E_DImode
&& (((GET_MODE(XEXP(new_rtx, 0)) == E_QImode)
&& HAVE_extendqidi2)
|| ((GET_MODE(XEXP(new_rtx, 0)) == E_HImode)
&& HAVE_extendhidi2
return PROFITABLE;
Please check if it is reasonable and look forward to further discussion with
you.Thanks!
[Bug tree-optimization/109011] missed optimization in presence of __builtin_ctz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109011 --- Comment #23 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:8311c26757657fe8ffa28ca1539d02d141bb8292 commit r14-182-g8311c26757657fe8ffa28ca1539d02d141bb8292 Author: liuhongt Date: Wed Mar 15 13:41:06 2023 +0800 Add testcases for ffs/ctz vectorization. gcc/testsuite/ChangeLog: PR tree-optimization/109011 * gcc.target/i386/pr109011-b1.c: New test. * gcc.target/i386/pr109011-b2.c: New test. * gcc.target/i386/pr109011-d1.c: New test. * gcc.target/i386/pr109011-d2.c: New test. * gcc.target/i386/pr109011-q1.c: New test. * gcc.target/i386/pr109011-q2.c: New test. * gcc.target/i386/pr109011-w1.c: New test. * gcc.target/i386/pr109011-w2.c: New test.
[Bug libstdc++/109602] Import Gentoo msgfmt patch ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109602 --- Comment #2 from Andrew Pinski --- Second who sets LD_LIBRARY_PATH in the first place. Third these I thought was only done for maintenance mode.
[Bug libstdc++/109602] Import Gentoo msgfmt patch ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109602 --- Comment #1 from Andrew Pinski --- I am 99% sure this patch is not portable at all. In that not all env supports --unset.
[Bug libstdc++/109602] New: Import Gentoo msgfmt patch ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109602 Bug ID: 109602 Summary: Import Gentoo msgfmt patch ? Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: romain.geissler at amadeus dot com Target Milestone: --- Hi, I am wondering, would it make sense to import Gentoo's msgfmt patch ? In some occasion, it seems that the build system of gcc/libstdc++ wrongly sets LD_LIBRARY_PATH when building (in case it helps, in my case it seems to happens only when doing a gcc bootstrap). I am speaking about this patch: https://gitweb.gentoo.org/proj/gcc-patches.git/tree/10.3.0/gentoo/36_all_msgfmt-libstdc++-link.patch?id=6fb906ef2da01327d64cea263887ef34c97c1bbf and more globally about this set of Gentoo bugs https://bugs.gentoo.org/372377 or https://bugs.gentoo.org/843119 It seems at least Alpine Linux also carries this patch: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/gcc/0009-Ensure-that-msgfmt-doesn-t-encounter-problems-during.patch I understand the underlying issue is more that LD_LIBRARY_PATH shouldn't be set, but it seems past investigations didn't really lead to finding this root cause (see bug #105688), so in the meantime, maybe this workaround patch should be imported in upstream tree directly. It's just a proposal, I would understand this is refused. Cheers, Romain
[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #46 from Andrew Church ---
(In reply to Andrew Pinski from comment #45)
> But there is no general agreement at all. If clang behavior agreed with gcc,
> then there would be consensus here. In fact gcc behavior is older than clang
> behavior makes this even more difficult and even points out that if clang
> said it implemented a compatible extension, it did not.
First, a single disagreement does not invalidate a consensus, at least in the
general meaning which I quoted ("the judgment arrived at by most of those
concerned" - note "most" and not "all"). As I discussed earlier, I still see
significantly wider support for the view that void casts should silence
discarded-value warnings, to the extent that I consider it fair to call that
view a consensus.
Second, an equally valid view of the meaning of Clang's behavior differing from
GCC's - barring any deeper knowledge of the LLVM team's decision-making, which
I do not have - is that the LLVM team merged the observed intent behind the
original extension (warn about values which should not be discarded) with its
knowledge of existing practice (use of a void cast to indicate a deliberately
discarded value) to arrive at their choice of behavior. If anything, I'd
suggest that https://bugs.llvm.org/show_bug.cgi?id=51228 being marked WONTFIX
because the developers consider it to be "working as intended" argues for this
view.
> You are basically saying all warnings will be ignored which is true.
That's not what I said, and I disagree at least with that particular phrasing.
I would, however, accept "warnings will be ignored if the user feels the effort
to fix the warning is not worth the benefit". By corollary, users in general
will take the path of least resistance to resolving a warning, and if allowing
void casts to silence specific instances of the warning encourages them to
leave the warning enabled in general, it will result in better code than if the
user gets so frustrated with the warning that they just turn it off completely.
> Using a void cast makes life too easy to ignore this behavior.
It still requires action on the part of the programmer. A programmer who
writes
system("foo");
may want to be warned that the return code from system() is discarded, whereas
a programmer who writes
(void) system("foo");
has clearly stated an intent to discard that return value, and warning about it
anyway is unnecessary noise. (Though an argument could be certainly be made
for a better word than "void", perhaps a construction like "[[discard]]
foo()".)
Is there a risk of cargo-cult syndrome? (A: "Hey B, how do I call this
external foo program?" B: "Just write '(void) system("foo")'.") Certainly.
But the same argument can be made for _any_ workaround, and I suspect that more
complex workarounds would increase, rather than decrease, that risk - the more
complex the code, the less likely the user is to read it and understand what
it's doing.
> If the api user wants to ignore the return
> values while the api developer tells you should not, then really the api
> user will have bugs. This is why the warning is there.
Demonstrably false (see above, and even your own caveat below).
> Now api developers
> have known to place this attribute on things that should not be placed on
> but that is not a compiler issue and the api user should talk with the api
> developer rather than try to change the compiler for their workaround.
Suppose the API developer's response is, "I don't care about your use case, I
want you to do things my way." What is the (non-compiler developer) user to do
then? Look for an alternative library, which may not even exist? Spend the
time to write their own? Disable the warning and accept the risk of bugs in
unrelated code? Look up the workaround du jour and throw it all over their
code base, cargo-cult style?
If I were faced with that choice, I would probably just switch to Clang.
[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 --- Comment #45 from Andrew Pinski --- (In reply to Andrew Church from comment #44) > (In reply to Segher Boessenkool from comment #43) > > That is not the consensus, no. "Consensus" does not mean doing what the > > unthinking masses shout. > > Merriam-Webster disagrees: > con.sen.sus > 1 a: general agreement : UNANIMITY > b: the judgment arrived at by most of those concerned But there is no general agreement at all. If clang behavior agreed with gcc, then there would be consensus here. In fact gcc behavior is older than clang behavior makes this even more difficult and even points out that if clang said it implemented a compatible extension, it did not. > > I specifically clarified that with "wider" to indicate the larger group of > "C compiler users", as opposed to what you seem to mean, "C compiler > developers". And in whatever sense you choose to regard them, the judgment > arrived at by most C compiler users does seem to be "cast to void should > suppress a warning about a discarded value", as I described above. > There is still no general consensus really. Just that the folks who want behavior difference is loud while the ones who are happy with the current behavior are quiet because they don't need to tell their thoughts on it. > > So allowing casts to void > > to suppress this warning means the warning becomes less useful, and people > > will write worse code. That is not something GCC should encourage IMO. > > You seem to think that making the warning harder to work around will > encourage programmers to change their code to fix the warning. In reality, > they are more likely to either (1) disable the warning entirely or (2) > disregard warnings in general, both of which result in considerably worse > code - the situation you say you are trying to avoid. Thus my suggestion to > follow the principle of least surprise and allow a void cast to disable the > warning by default. You are basically saying all warnings will be ignored which is true. Even ones with no false positives are ignored. Using a void cast makes life too easy to ignore this behavior. If the api user wants to ignore the return values while the api developer tells you should not, then really the api user will have bugs. This is why the warning is there. Now api developers have known to place this attribute on things that should not be placed on but that is not a compiler issue and the api user should talk with the api developer rather than try to change the compiler for their workaround.
[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 --- Comment #44 from Andrew Church --- (In reply to Segher Boessenkool from comment #43) > That is not the consensus, no. "Consensus" does not mean doing what the > unthinking masses shout. Merriam-Webster disagrees: con.sen.sus 1 a: general agreement : UNANIMITY b: the judgment arrived at by most of those concerned I specifically clarified that with "wider" to indicate the larger group of "C compiler users", as opposed to what you seem to mean, "C compiler developers". And in whatever sense you choose to regard them, the judgment arrived at by most C compiler users does seem to be "cast to void should suppress a warning about a discarded value", as I described above. > So allowing casts to void > to suppress this warning means the warning becomes less useful, and people > will write worse code. That is not something GCC should encourage IMO. You seem to think that making the warning harder to work around will encourage programmers to change their code to fix the warning. In reality, they are more likely to either (1) disable the warning entirely or (2) disregard warnings in general, both of which result in considerably worse code - the situation you say you are trying to avoid. Thus my suggestion to follow the principle of least surprise and allow a void cast to disable the warning by default.
[Bug rtl-optimization/109476] Missing optimization for 8bit/8bit multiplication / regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476 Roger Sayle changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |roger at nextmovesoftware dot com --- Comment #17 from Roger Sayle --- I've submitted an improved version of my patch for review: https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616527.html
[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 --- Comment #43 from Segher Boessenkool --- (In reply to Andrew Church from comment #40) > My rationale for changing the default behavior is that the wider community > consensus, as evidenced by things like the C++ (and C2x) [[nodiscard]] > specification, the behavior of Clang, and the balance of comments on this > bug, seems to be that casting a discarded return value to void should > suppress any warning about the discarded value; and under the principle of > least surprise, GCC should follow that consensus by default even if it also > provides alternative behaviors. That is not the consensus, no. "Consensus" does not mean doing what the unthinking masses shout. There already are easy ways to deal suppress the error, very direct, and very descriptive ways. A cast to void is round-about, cryptic, and already is cargo-cult, before this attribute existed even! So allowing casts to void to suppress this warning means the warning becomes less useful, and people will write worse code. That is not something GCC should encourage IMO.
[Bug fortran/109500] SIGABRT when calling a function that returns an unallocated value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |14.0 Status|ASSIGNED|RESOLVED --- Comment #24 from anlauf at gcc dot gnu.org --- The argument association issue is fixed for gcc-14. Thanks for the report! PR109575 tracks potential improvements of runtime diagnostics when the function result is not set.
[Bug rtl-optimization/109601] Useless branch not eliminated when writing to a union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109601
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-04-23
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski ---
x86 duplicated the simple return but never unduplicates it:
(jump_insn 27 12 28 3 (simple_return) 1030 {simple_return_internal}
(nil)
-> simple_return)
...
(jump_insn 32 31 33 4 (simple_return) "/app/example.cpp":29:1 -1
(nil)
-> simple_return)
But simple_return was only added in GCC 4.7.0 (r0-111280-g268987713c7105c691)
So something else changed.
There is also a missed optimization earlier because jump2 is way late to be
optimizing this case.
Also this is just an issue with return so it might not be as important as most
people think (the other missed optimization earlier is though).
[Bug fortran/61615] Failure to resolve correct generic with TYPE(C_PTR) arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61615 --- Comment #12 from CVS Commits --- The releases/gcc-12 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:62a4f2fb356cab8cfebfeeac2895b657c32b8dd4 commit r12-9467-g62a4f2fb356cab8cfebfeeac2895b657c32b8dd4 Author: Harald Anlauf Date: Tue Apr 11 16:44:32 2023 +0200 Fortran: resolve correct generic with TYPE(C_PTR) arguments [PR61615,PR99982] gcc/fortran/ChangeLog: PR fortran/61615 PR fortran/99982 * interface.cc (compare_parameter): Enable type and rank checks for arguments of derived type from the intrinsic module ISO_C_BINDING. gcc/testsuite/ChangeLog: PR fortran/61615 PR fortran/99982 * gfortran.dg/interface_49.f90: New test. (cherry picked from commit c482995cc5bac4a2168ea0049041e712544e474b)
[Bug fortran/99982] INTERFACE selects wrong module procedure involving C_PTR and C_FUNPTR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99982 --- Comment #10 from CVS Commits --- The releases/gcc-12 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:62a4f2fb356cab8cfebfeeac2895b657c32b8dd4 commit r12-9467-g62a4f2fb356cab8cfebfeeac2895b657c32b8dd4 Author: Harald Anlauf Date: Tue Apr 11 16:44:32 2023 +0200 Fortran: resolve correct generic with TYPE(C_PTR) arguments [PR61615,PR99982] gcc/fortran/ChangeLog: PR fortran/61615 PR fortran/99982 * interface.cc (compare_parameter): Enable type and rank checks for arguments of derived type from the intrinsic module ISO_C_BINDING. gcc/testsuite/ChangeLog: PR fortran/61615 PR fortran/99982 * gfortran.dg/interface_49.f90: New test. (cherry picked from commit c482995cc5bac4a2168ea0049041e712544e474b)
[Bug fortran/108010] ICE in reduce_unary, at fortran/arith.cc:1345
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108010 --- Comment #6 from CVS Commits --- The releases/gcc-12 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:767d85d69f3d3f718f2a294f8e03be3a8aa65c4b commit r12-9466-g767d85d69f3d3f718f2a294f8e03be3a8aa65c4b Author: Harald Anlauf Date: Wed Dec 7 21:50:23 2022 +0100 Fortran: handle zero-sized arrays in ctors with typespec [PR108010] gcc/fortran/ChangeLog: PR fortran/108010 * arith.cc (reduce_unary): Handle zero-sized arrays. (reduce_binary_aa): Likewise. gcc/testsuite/ChangeLog: PR fortran/108010 * gfortran.dg/pr108010.f90: New test. (cherry picked from commit 7d6512d102a5a4fb3939de95bce38d154512a19f)
[Bug rtl-optimization/109601] Useless branch not eliminated when writing to a union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109601 --- Comment #1 from Andrew Pinski --- jump2 (which is after RA) does this for aarch64: Forwarding edge 2->3 to 5 failed. verify found no changes in insn with uid = 11. Edge 2->4 redirected to 5 scanning new insn with uid = 47. Replacing insn 11 by jump 47 deleting insn with uid = 11. deleting insn with uid = 38. deleting block 3 deleting block 4 Removing jump 47. deleting insn with uid = 47. Merging block 5 into block 2... changing bb of uid 43 changing bb of uid 44 from 5 to 2 changing bb of uid 45 from 5 to 2 Merged blocks 2 and 5. Merged 2 and 5 without moving. For x86_64 does not have this.
[Bug target/109601] New: Useless branch not eliminated when writing to a union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109601 Bug ID: 109601 Summary: Useless branch not eliminated when writing to a union Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: 67 at mniip dot com Target Milestone: --- Created attachment 54909 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54909=edit Minimal testcase On x86_64-pc-linux-gnu the attached code compiles (with -O3) to rather unsatisfying assembly with a branch that does the same thing whether taken or not: > 10: 85 c0 test %eax,%eax > 12: 74 04 je 18 > 14: c3 ret > 15: 0f 1f 00nopl (%rax) > 18: c3 ret I've tested on my machine in GCC 12.2.1, but Compiler Explorer ( https://godbolt.org/z/cW69rfrPc ) shows the same thing happens in a lot of other versions, including trunk (6ab856aa49bef7c04efa6144a5048e129b3a058b). Notably, this doesn't happen in GCC 4.5.3. This seems to happen for a few other targets as well, e.g: arm, riscv32; but not on some others, e.g. aarch64, mips.
[Bug target/99195] Optimise away vec_concat of 64-bit AdvancedSIMD operations with zeroes in aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99195 --- Comment #4 from CVS Commits --- The master branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:3b13c59c835f92b353ef318398e39907cdeec4fa commit r14-178-g3b13c59c835f92b353ef318398e39907cdeec4fa Author: Kyrylo Tkachov Date: Sun Apr 23 14:40:17 2023 +0100 aarch64: Add vect_concat with zeroes annotation to addp pattern Similar to others, the addp pattern can be safely annotated with to create the implicit vec_concat-with-zero variants. Bootstrapped and tested on aarch64-none-linux-gnu and aarch64_be-none-elf. gcc/ChangeLog: PR target/99195 * config/aarch64/aarch64-simd.md (aarch64_addp): Rename to... (aarch64_addp): ... This. gcc/testsuite/ChangeLog: PR target/99195 * gcc.target/aarch64/simd/pr99195_1.c: Add testing for vpadd intrinsics.
[Bug rtl-optimization/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753 --- Comment #18 from Georg-Johann Lay --- (In reply to User99627 from comment #14) > (In reply to fiesh from comment #13) > > * While you failed to provide anything meaningful to the bug report (your > > code snippet is not self-contained valid C code; [...] > > I failed? Yepp. As your test case works without LTO, all you have to do to get a valid test case is to 1) Add -v -save-temps to the command line options. 2) Provide that one pre-complied source file *.ii which triggers the ICE. 3) Provide the one command that avr-g++ issues to compile it. Maybe specifics of avr-g++ like its version are also interesting. These are all printed with -v. The GCC bug reporting instructions explain that, see "Reporting Bugs" in https://gcc.gnu.org/bugs/ This link is also shown when an ICE occurs, cf. your Arduino logs. There is a "What we need" section and also a "What we do not want" and "Detailed bug reporting instructions" section to guide you. > Nothing meaningful? It doesn't help in reproducing the bug. > So installing the Arduino IDE on your machine [...] is asking too much, Speaking for myself: Yes. Arduino will complile all of its core modules, stuff them in libs, and then link all that stuff against the user modules intermingled with other commands like ctags, ranlib and what not. Why should anyone go through all of this if *one* pre-compiled file is enough. Lest alone installing software that has nothing to do with GCC. If it's too compicated for you, who is experienced with Arduino, to add "-v -save-temps" to the compilation options; how is anybody else supposed to figure out how to distill a test case from all of that. A reasonable solution would be to report such problems to the Arduino bug tracker. If the Arduino maintainers would conclude that it's a genuine GCC problem, then they would prepare a proper GCC bug report so that the GCC people can reproduce the problem and work on it. > Shall I post the complete Arduino library, plus the complete set of make and > build commands (which I did!) to finally get some attention? What if it were > a very complex case of internal bug that only requires a complex set of > files for the bug to show itself? As of bug reporting instructions: Please no binaries like libs. There are two cases: non-LTO: This is the easy case. The problem occurs during compilation of one translation unit. Provide the pre-processed source *.ii and the command that operates on it as described above. LTO: By all means, try to find a test case that does not require LTO and thus requires just one translation unit to reproduce. If that fails, provide all involved pre-processed sources and the avr-g++ calls that get you to the bug. For N modules, this will be generation of N objects *.o from their *.ii preprocessed sources, together with one final link that links the modules to the final executable. For 2 modules, it would be something like $ avr-g++ -mmcu=atmega8 -Os -flto -fpreprocessed module1.ii -o module1.o $ avr-g++ -mmcu=atmega8 -Os -flto -fpreprocessed module2.ii -o module2.o $ avr-g++ -mmcu=atmega8 -Os -flto module1.ii module2.ii -o modules.elf IMO it would make sense that the Arduino people had a tool that helped their users to produce valid bug reports. This should be easy for the non-LTO case. For the LTO case, one would highly prefer a testcase as simple as possible, for example by running creduce on *all* modules while keeping the bug alive. https://embed.cs.utah.edu/creduce/ Most of the creduce'd modules would turn out to be empty, thus not required for the testcase. > If I post a complete makefile with build instructions, will this bug > be investigated? A proper bug report as lined out above is a prerequisiteso that the bug will be inverstigated. It's necessary for investigation, but not sufficient. The avr backend is plagued by a lack of supporters and people that are willing to work on it and have the resources to do that.
[Bug other/109600] 13.0.1-0.15.fc39: missing #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109600 --- Comment #3 from Tomasz Kłoczko --- Broken binary packages are still in repo.
[Bug other/109600] 13.0.1-0.15.fc39: missing #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109600 Jonathan Wakely changed: What|Removed |Added See Also||https://bugzilla.redhat.com ||/show_bug.cgi?id=2188608 --- Comment #2 from Jonathan Wakely --- Don't bother, it's already fixed: https://bugzilla.redhat.com/show_bug.cgi?id=2188608
[Bug other/109600] 13.0.1-0.15.fc39: missing #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109600 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andreas Schwab --- Please report that to the provider of the compiler.
[Bug other/109600] New: 13.0.1-0.15.fc39: missing #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109600 Bug ID: 109600 Summary: 13.0.1-0.15.fc39: missing #include Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: kloczko.tomasz at gmail dot com Target Milestone: --- Just noticed that with latest gcc version many packages builds re failing with /usr/lib/gcc/x86_64-redhat-linux/13/include/immintrin.h:135:10: fatal error: amxcomplexintrin.h: No such file or directory 135 | #include | ^~~~
[Bug tree-optimization/109593] [14 Regression] Valgrind error doing build of latest gcc trunk since r14-32-g10e481b154c5fc63
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109593 --- Comment #10 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:5830953a446959c5d8d9b569ffcd3e3bb16a06dc commit r14-174-g5830953a446959c5d8d9b569ffcd3e3bb16a06dc Author: Aldy Hernandez Date: Sun Apr 23 08:04:55 2023 +0200 Handle NANs in frange::operator== [PR109593] This patch... commit 10e481b154c5fc63e6ce4b449ce86cecb87a6015 Return true from operator== for two identical ranges containing NAN. removed the check for NANs, which caused us to read from m_min and m_max which are undefined for NANs. gcc/ChangeLog: PR tree-optimization/109593 * value-range.cc (frange::operator==): Handle NANs.
[Bug tree-optimization/109593] [14 Regression] Valgrind error doing build of latest gcc trunk since r14-32-g10e481b154c5fc63
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109593 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #11 from Aldy Hernandez --- fixed
[Bug tree-optimization/109593] [14 Regression] Valgrind error doing build of latest gcc trunk since r14-32-g10e481b154c5fc63
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109593 --- Comment #9 from David Binderman --- (In reply to Aldy Hernandez from comment #8) > Does this fix the problem on the reporter's side? Looks good to me.
[Bug rtl-optimization/109585] [10/11/12/13/14 regression] Carla/sord miscompiled with -O2 on ARM64 with flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585 Xi Ruoyao changed: What|Removed |Added Summary|Carla/sord miscompiled with |[10/11/12/13/14 regression] |-O2 on ARM64 with flexible |Carla/sord miscompiled with |array member|-O2 on ARM64 with flexible ||array member --- Comment #17 from Xi Ruoyao --- With GCC 9 it was fine, but not GCC 10. I guess we can try a bisect...
[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 --- Comment #42 from Andrew Church --- (In reply to Sam James from comment #41) > Could you send it to the gcc-patches mailing list please? (Even if it is a > PoC). Sent as requested.
[Bug rtl-optimization/109585] Carla/sord miscompiled with -O2 on ARM64 with flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #16 from Xi Ruoyao --- (In reply to Hector Martin from comment #15) > The prior repro was too complex and depended on other environmental stuff > (some other people couldn't repro it on arm64 either), so please ignore it. > If the reduced repro triggers the issue, it's the same bug. I can reproduce the issue with the reduced repro on x86_64-linux-gnu too.
[Bug c/94379] Feature request: like clang, support __attribute((__warn_unused_result__)) on structs, unions, and enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94379
--- Comment #2 from Petr Skocik ---
Excellent!
For optional super extra coolness, this might work (and clang doesn't do this)
with statement expressions too so that statement expression-based macros could
be
marked warn_unused_result through it too.
typedef struct __attribute((__warn_unused_result__)) { int x; }
wur_retval_t;
wur_retval_t foo(void){ int x=41; return (wur_retval_t){x+1}; }
#define foo_macro() ({ int x=41; (wur_retval_t){x+1}; })
void use(void){
foo(); //warn unused result ✓
foo_macro(); //perhaps should "warn unused result" too?
}
[Bug rtl-optimization/109585] Carla/sord miscompiled with -O2 on ARM64 with flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585 --- Comment #15 from Hector Martin --- The prior repro was too complex and depended on other environmental stuff (some other people couldn't repro it on arm64 either), so please ignore it. If the reduced repro triggers the issue, it's the same bug.
[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 --- Comment #41 from Sam James --- (In reply to Andrew Church from comment #40) > Created attachment 54906 [details] > POC patch to add -Wunused-result=strict > Could you send it to the gcc-patches mailing list please? (Even if it is a PoC).
[Bug rtl-optimization/109585] Carla/sord miscompiled with -O2 on ARM64 with flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585 Sam James changed: What|Removed |Added Target|aarch64 |aarch64, x86_64-linux-gnu --- Comment #14 from Sam James --- (In reply to Alexander Monakov from comment #13) > The small repro from comment #5 is reproducible on x86_64 trunk as well with > -O2 -DNDEBUG (as well as on older x86_64 branches without -DNDEBUG). > I'll add x86_64-linux-gnu to target then, hopefully that's alright (unclear b/c it's only the reduced one seemingly).
[Bug c/109597] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109597 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #2 from Sam James --- Also, at this point, please consider trying a newer GCC (either trunk or tip of releases/gcc-13, as there's far newer snapshots, including RCs), even if it wouldn't have helped w/ this bug.
[Bug other/109599] Query for merging files in ar.exe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109599 --- Comment #4 from Andrew Pinski --- (In reply to Jamaika from comment #3) > I'm not referring to the GCC 11.3.1 comment itself. I meant why the .a file > automatically adds and compiles c files from the avx2 and sse2 directories > that I have not added. I have no idea and I suspect you did mention the object files. Since we have no idea the exact command lines being used either. Maybe there is an update to the archive file while inside the avx2/sse2 directories that adds those object files. Note if you are using make, you should look into the makefiles to see what is being done. you can use the -d option there. Also NOTE make is not part of the GCC project either, but than the GNU make project. > I was surprised that ar.exe is not a gcc product. Who is the creator? I mentioned it in my comment: "But first I should note ar is not part of GCC but rather in your case comes from the project called GNU binutils."
[Bug tree-optimization/109593] [14 Regression] Valgrind error doing build of latest gcc trunk since r14-32-g10e481b154c5fc63
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109593 --- Comment #8 from Aldy Hernandez --- Created attachment 54908 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54908=edit untested patch Patch in testing. Does this fix the problem on the reporter's side?
