[Bug c/70967] doc: Please document rotate idiom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70967 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-01-10 --- Comment #1 from Andrew Pinski --- Confirmed, though I don't know where in the documenation would be a good place to put it.
[Bug target/52991] [6/7/8 Regression] attribute packed broken on mingw32?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991 Andrew Pinski changed: What|Removed |Added Target Milestone|6.5 |8.0
[Bug target/61813] __attribute__((__packed__)) does not pack struct containing uint16_t with uint32_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61813 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 52991. *** This bug has been marked as a duplicate of bug 52991 ***
[Bug target/52991] [6/7/8 Regression] attribute packed broken on mingw32?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991 Andrew Pinski changed: What|Removed |Added CC||steven.spark at gmail dot com --- Comment #36 from Andrew Pinski --- *** Bug 61813 has been marked as a duplicate of this bug. ***
[Bug target/55428] [9/10/11/12 Regression] -mms-bitfields hides -mno-align-double option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55428 Andrew Pinski changed: What|Removed |Added Summary|-mms-bitfields hides|[9/10/11/12 Regression] |-mno-align-double option|-mms-bitfields hides ||-mno-align-double option Known to fail||4.4.7 Target Milestone|--- |9.5 Keywords||ABI, wrong-code
[Bug middle-end/71849] bitfield placement of overly aligned type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71849 Andrew Pinski changed: What|Removed |Added Keywords||ABI, wrong-code Component|c |middle-end Last reconfirmed||2022-01-10 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. ICC and clang have the same ABI here while GCC is different.
[Bug d/103944] [12 Regression] Testsuite hang due to libphobos/testsuite/libphobos.gc/forkgc2.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103944 --- Comment #2 from Jakub Jelinek --- Even running it by hand gets stuck: /builddir/build/BUILD/gcc-12.0.0-20220106/obj-i686-redhat-linux/./gcc/gdc -B/builddir/build/BUILD/gcc-12.0.0-20220106/obj-i686-redhat-linux/./gcc/ -B/usr/i686-redhat-linux/bin/ -B/usr/i686-redhat-linux/lib/ -isystem /usr/i686-redhat-linux/include -isystem /usr/i686-redhat-linux/sys-include -fmessage-length=0 -fno-show-column -Wall -O2 -fexceptions -g -grecord-gcc-switches -Wall -Wp,-D_GLIBCXX_ASSERTIONS -mtune=generic -msse2 -mfpmath=sse -msse2 -mstackrealign -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fcf-protection -mshstk -fversion=CET -fversion=Shared -fpreview=dip1000 -fno-release -funittest -nostdinc -B/builddir/build/BUILD/gcc-12.0.0-20220106/obj-i686-redhat-linux/i686-redhat-linux/libphobos/src -I/builddir/build/BUILD/gcc-12.0.0-20220106/obj-i686-redhat-linux/i686-redhat-linux/libphobos/libdruntime -I/builddir/build/BUILD/gcc-12.0.0-20220106/libphobos/libdruntime -I/builddir/build/BUILD/gcc-12.0.0-20220106/libphobos/src /builddir/build/BUILD/gcc-12.0.0-20220106/libphobos/testsuite/libphobos.gc/forkgc2.d -fstack-protector-strong -fno-diagnostics-show-caret -fdiagnostics-color=never -B/builddir/build/BUILD/gcc-12.0.0-20220106/obj-i686-redhat-linux/i686-redhat-linux/libphobos/src -B/builddir/build/BUILD/gcc-12.0.0-20220106/obj-i686-redhat-linux/i686-redhat-linux/libphobos/libdruntime/gcc -B/builddir/build/BUILD/gcc-12.0.0-20220106/obj-i686-redhat-linux/i686-redhat-linux/libphobos/src/.libs -L/builddir/build/BUILD/gcc-12.0.0-20220106/obj-i686-redhat-linux/i686-redhat-linux/libphobos/src/.libs -lm -o ./forkgc2.exe LD_LIBRARY_PATH=../../src/.libs/ ./forkgc2.exe
[Bug c/59485] may_alias attribute ignored in internal references while defining aggregate types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59485 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection --- Comment #1 from Andrew Pinski --- Seems fixed in GCC 7+.
[Bug tree-optimization/103802] [12 regression] recip-3.c fails after r12-6087 on Power m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103802
--- Comment #7 from rguenther at suse dot de ---
On Fri, 7 Jan 2022, luoxhu at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103802
>
> --- Comment #6 from luoxhu at gcc dot gnu.org ---
> (In reply to Richard Biener from comment #5)
> > So the point is that P is invariant but we do not hoist it because it's
> > computed in a (estimated) cold block? I notice that the condition is
> > invariant, too, so
> > in principle we could hoist as
> >
> > if (d > 0.01)
> > P = ( W < E ) ? (W - E)/d : (E - W)/d;
> > for (i=0; i < 2; i++ )
> > if( d > 0.01 )
> > F[i] += P;
>
>
> Yes. But this loop only iterates twice, so bbs in loop is colder than
> preheader.
> -funswitch-loops should move the condition out of loop, but also need increase
> the loop iteration count:
>
> "/home/luoxhu/workspace/gcc-master/gcc/testsuite/gcc.dg/tree-ssa/recip-3.c:16:14:
> note: Not unswitching, loop is not expected to iterate"
>
> >
> > alternatively one might argue that invariant expressions (unconditionally
> > computed or in a special way under invariant conditions) should be costed
> > differently.
> >
> > I think best would be to restore the original intent of the testcase which
> > was added with the fix for PRs 23109, 23948 and 24123. I suppose there
> > we saw the invariant hoisted(?) and the loop unrolled so I would suggest
> > to either apply the hoisting or the unrolling manually to the testcase.
> > (just look at the PRs whether you get a better idea of the origin of the
> > testcase).
>
> To restore the original intent of the testcase, increase the loop count is
> better than "either apply the hoisting or unrolling". Change it from "2" to
> at
> least "5" will turn the cold bb to hot bb, then the two divides could be
> hoisted out in LIM pass again(Verified below change could both pass on
> power-m32 and x86-i686):
>
> (It is much reasonable than the other two directions as loop iteration count
> is
> not key for the test code.)
>
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/recip-3.c
> b/gcc/testsuite/gcc.dg/tree-ssa/recip-3.c
> index 641c91e..a1d2d87 100644
> --- a/gcc/testsuite/gcc.dg/tree-ssa/recip-3.c
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/recip-3.c
> @@ -1,7 +1,7 @@
> /* { dg-do compile } */
> /* { dg-options "-O1 -fno-trapping-math -funsafe-math-optimizations
> -fdump-tree-recip" } */
>
> -double F[2] = { 0.0, 0.0 }, e;
> +double F[5] = { 0.0, 0.0 }, e;
>
> /* In this case the optimization is interesting. */
> float h ()
> @@ -13,7 +13,7 @@ float h ()
> d = 2.*e;
> E = 1. - d;
>
> - for( i=0; i < 2; i++ )
> + for( i=0; i < 5; i++ )
> if( d > 0.01 )
> {
> P = ( W < E ) ? (W - E)/d : (E - W)/d;
> @@ -23,4 +23,4 @@ float h ()
> F[0] += E / d;
> }
>
> -/* { dg-final { scan-tree-dump-times " / " 5 "recip" } } */
> +/* { dg-final { scan-tree-dump-times " / " 1 "recip" } } */
That looks reasonable to me.
[Bug libffi/42275] pkg-config (.pc) file missing in libffi (lost during import)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42275 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |5.0 Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- Fixed in GCC 5 since r5-6314.
[Bug debug/100530] [9/10/11/12 Regression] ICE with -g: in add_dwarf_attr with __seg_gs (Alternative address-space) global variable since r8-4385-ga297ccb52e0c894e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100530 --- Comment #8 from Richard Biener --- PR#101975 contains some analysis.
[Bug libstdc++/103951] [C++2b] string_view range constructor, "exception specification ... depends on itself"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103951 --- Comment #3 from Jonathan Wakely --- This would be solved by http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2499r0.html but I think the std::lib code is behaving exactly as the C++23 draft requires.
[Bug libcc1/67128] Makefile.in, libcc1 and --enable-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67128 --- Comment #9 from Jonathan Wakely --- (In reply to Szőts Ákos from comment #3) > Option "--with-pic" doesn't work, but the suggested workaround in the > original post does. I think using --disable-shared --with-pic *should* work, but it doesn't because of PR 58638.
[Bug middle-end/38663] OpenMP directive causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38663 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.6.0 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=44132 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #8 from Andrew Pinski --- This was mostly fixed in GCC 4.6.0 with the rewrite of the emulated TLS support. Darwin still uses emulated TLS even today.
[Bug libstdc++/100912] powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100912 --- Comment #10 from Qiu Chaofan --- Hi, does GCC plan to switch to IEEE-quad as default `long double` semantics (or at least fully support it but under an option)? If so, I guess this should be a blocker. If GCC 12 supports it well, other compilers like Clang can emit warning if enabling abi=ieeelongdouble but linking against older libstdcxx version.
[Bug libstdc++/100912] powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100912 --- Comment #11 from Jonathan Wakely --- This absolutely needs to be (and will be) fixed for GCC 12 anyway, whether the default is switched or not.
[Bug ipa/60235] Inlining fails with template specialization and -fPIC on Linux AMD64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60235 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Component|middle-end |ipa CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Target Milestone|--- |5.0 --- Comment #8 from Andrew Pinski --- -fno-semantic-interposition was added in GCC 5 for the code generation you want.
[Bug ipa/60235] Inlining fails with template specialization and -fPIC on Linux AMD64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60235 --- Comment #9 from Andrew Pinski --- (In reply to Andrew Pinski from comment #8) > -fno-semantic-interposition was added in GCC 5 for the code generation you > want. I should say it was added by r5-1555.
[Bug tree-optimization/100359] missed optimization for dead code elimination at -O3 (vs. -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100359 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:92e114d66e93d60dcef97c66cddbae38b657d768 commit r12-6402-g92e114d66e93d60dcef97c66cddbae38b657d768 Author: Richard Biener Date: Wed Jan 5 16:29:53 2022 +0100 tree-optimization/100359 - restore unroll at -O3 This fixes a mistake done with r8-5008 when introducing allow_peel to the unroll code. The intent was to allow peeling that doesn't grow code but the result was that with -O3 and UL_ALL this wasn't done. The following instantiates the desired effect by adjusting ul to UL_NO_GROWTH if peeling is not allowed. 2022-01-05 Richard Biener PR tree-optimization/100359 * tree-ssa-loop-ivcanon.c (try_unroll_loop_completely): Allow non-growing peeling with !allow_peel and UL_ALL. * gcc.dg/tree-ssa/pr100359.c: New testcase.
[Bug tree-optimization/100359] missed optimization for dead code elimination at -O3 (vs. -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100359 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed for GCC 12.
[Bug rtl-optimization/52773] internal error: in replace_pseudos_in, at reload1.c:577
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52773 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |5.0 Keywords||ice-on-valid-code
[Bug middle-end/59553] emit_library_call_value_1 generates usage of virtual_outgoing_args_rtx when virtuals_instantiated is 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59553 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- An almost exact dup of bug 52773 which was fixed in GCC 5 by r5-6559. The fix uses stack_pointer_rtx always instead of virtual_outgoing_args_rtx. *** This bug has been marked as a duplicate of bug 52773 ***
[Bug rtl-optimization/52773] internal error: in replace_pseudos_in, at reload1.c:577
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52773 Andrew Pinski changed: What|Removed |Added CC||makhaloff at gmail dot com --- Comment #14 from Andrew Pinski --- *** Bug 59553 has been marked as a duplicate of this bug. ***
[Bug target/58901] vax bootstrap fails on subreg reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58901 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.0
[Bug middle-end/30798] mode_dependent_address_p not checked when simplifying subreg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30798 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=58901 Target Milestone|--- |11.0 Resolution|--- |FIXED --- Comment #5 from Andrew Pinski --- Looks fixed in GCC 11 by PR 58901 which describes a very similar case.
[Bug c/103920] No warning for large structs passed by value ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103920 --- Comment #2 from Richard Biener --- Also consider void f1 (const S s, S * __restrict q); where obeying the warning would create a false alias when called as f1 (x, &x); whether passing by value or reference is more efficient also depends on the context - if the aggregate doesn't live in memory at (all) callers and register passing conventions are in effect then passing by reference requires materializing the argument on the stack.
[Bug testsuite/103935] [12 regression] g++.dg/vect/slp-pr98855.cc fails after r12-6273
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103935
--- Comment #2 from Richard Biener ---
Well, it was
// This used to work on { target x86_64-*-* i?86-*-* } but a fix in SLP
// discovery makes us trip over the threshold again.
// { dg-final { scan-tree-dump-times "not vectorized: vectorization is not prof
itable" 2 "slp1" { xfail *-*-* } } }
and it was xfailed, but you changed it to
// { dg-final { scan-tree-dump "not vectorized: vectorization is not profitable
" "slp1" } }
// { dg-final { scan-tree-dump-not "vectorizing stmts using SLP" "slp1" } }
no longer xfailed. I suggest to re-add the { xfail *-*-* } to the
profitability
check.
[Bug tree-optimization/103941] uavgv2qi3_ceil is not used (SLP costing and patterns vs live stmts)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103941 Richard Biener changed: What|Removed |Added Target||x86_64-*-* i?86-*-* Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Last reconfirmed||2022-01-10 Blocks||53947 Summary|uavgv2qi3_ceil is not used |uavgv2qi3_ceil is not used ||(SLP costing and patterns ||vs live stmts) Keywords||missed-optimization --- Comment #1 from Richard Biener --- t.c:8:11: note: Costing subgraph: t.c:8:11: note: node 0x409a000 (max_nunits=2, refcnt=1) t.c:8:11: note: op template: ur[0] = _23; t.c:8:11: note: stmt 0 ur[0] = _23; t.c:8:11: note: stmt 1 ur[1] = _35; t.c:8:11: note: children 0x409a088 t.c:8:11: note: node 0x409a088 (max_nunits=2, refcnt=1) t.c:8:11: note: op template: patt_58 = (unsigned char) patt_56; t.c:8:11: note: stmt 0 patt_58 = (unsigned char) patt_56; t.c:8:11: note: stmt 1 patt_71 = (unsigned char) patt_69; t.c:8:11: note: children 0x409a110 t.c:8:11: note: node 0x409a110 (max_nunits=2, refcnt=1) t.c:8:11: note: op template: patt_56 = .AVG_CEIL (_16, _18); t.c:8:11: note: stmt 0 patt_56 = .AVG_CEIL (_16, _18); t.c:8:11: note: stmt 1 patt_69 = .AVG_CEIL (_28, _30); t.c:8:11: note: children 0x409a220 0x409a198 t.c:8:11: note: node 0x409a220 (max_nunits=2, refcnt=1) t.c:8:11: note: op template: _16 = ua[0]; t.c:8:11: note: stmt 0 _16 = ua[0]; t.c:8:11: note: stmt 1 _28 = ua[1]; t.c:8:11: note: node 0x409a198 (max_nunits=2, refcnt=1) t.c:8:11: note: op template: _18 = ub[0]; t.c:8:11: note: stmt 0 _18 = ub[0]; t.c:8:11: note: stmt 1 _30 = ub[1]; t.c:8:11: note: Cost model analysis: _23 1 times scalar_store costs 12 in body _35 1 times scalar_store costs 12 in body (unsigned char) _22 1 times scalar_stmt costs 4 in body (unsigned char) _34 1 times scalar_stmt costs 4 in body ua[0] 1 times vector_load costs 12 in body ub[0] 1 times vector_load costs 12 in body .AVG_CEIL (_16, _18) 1 times vector_stmt costs 4 in body _23 1 times vector_store costs 12 in body ua[0] 1 times vec_to_scalar costs 4 in epilogue ua[1] 1 times vec_to_scalar costs 4 in epilogue ub[0] 1 times vec_to_scalar costs 4 in epilogue ub[1] 1 times vec_to_scalar costs 4 in epilogue t.c:8:11: note: Cost model analysis for part in loop 0: Vector cost: 56 Scalar cost: 32 t.c:8:11: missed: not vectorized: vectorization is not profitable. it looks like somehow the scalar costing is off and the scalar loads from ua and ub are considered live. Possibly an artifact of patterns. It's vectorized fine with -fno-vect-cost-model. I will have a look, eventually not for GCC 12. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug fortran/103942] [10 Regression] invalid memory reference with allocatable string and class(*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103942 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug c++/103943] [11/12 Regression] ICE building qualified name inside class with variadic CTAD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103943 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug driver/103949] gcc fails to provide a standard conforming C11 or C++17 environment even when specifying -std=c11 or -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103949 --- Comment #9 from Jonathan Wakely --- (In reply to Jörn Heusipp from comment #8) > > Note in newer versions of glibc, libpthread is all intergrated into libc and > > there is no issues again. > > > > For Mac OS X/darwin you don't need -lm -pthread because libc has it. > > Two examples where it works by chance is not sufficient to invalidate my > point about the general case. But it does mean the problem you're raising doesn't exist on two of GCC's primary platforms. So the problem is "fixing itself" for many users. > > >gcc libstdc++ implements std::thread. So what's your point again? > > > > Because it implements it on top of pthreads. > > Yeah, so that is an implementation detail because of which I am required to > pass -pthread. Why should the user of gcc even care how std::thread is > implemented? It literally makes no sense. You are supporting my point. It's like that because linking to libpthread has historically caused performance degradation for C++ programs, due to reference counting in shared_ptr and the COW std::string using slower atomic ops if libpthread is linked into the executable. So if the compiler implicitly added -lpthread to every C++ program using C++11 or later, it would hurt the performance of single-threaded programs. It matters less for the std::string reference counting now, because most people use the SSO string not the COW string, but it still affects std::shared_ptr. With recent glibc versions we have a better way to detect whether the process is single-threaded, and no longer make it depend on whether libpthread is linked in or not. And with very recent versions, you don't need -pthread at all. > Debian MinGW-w64 gcc is built in 2 flavours. One with Win32 and one with > posix threading model support. The version with posix threading model > support uses pthreads, and knows how to implement std::thread. Why is GCC > assuming single-threaded in that context? The fact the runtime is capable of supporting threads doesn't mean a given program compiled by the user actually uses threads. I understand your complaint, but I think it's unlikely we're going to change anything in GCC. The docs do not say that -std=c++17 is sufficient to get a fully C++17 conforming environment, so strictly speaking this report is not a bug. You're complaining about something we don't aim for anyway. The implementation documents that you need to add certain other flags for some features: https://gcc.gnu.org/onlinedocs/libstdc++/manual/using.html#manual.intro.using.flags This isn't ideal, but it's not easy to fix. And as already stated, some platforms are changing so it Just Works anyway.
[Bug driver/103949] gcc fails to provide a standard conforming C11 or C++17 environment even when specifying -std=c11 or -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103949 --- Comment #10 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #9) > (In reply to Jörn Heusipp from comment #8) > > Debian MinGW-w64 gcc is built in 2 flavours. One with Win32 and one with > > posix threading model support. The version with posix threading model > > support uses pthreads, and knows how to implement std::thread. Why is GCC > > assuming single-threaded in that context? > > The fact the runtime is capable of supporting threads doesn't mean a given > program compiled by the user actually uses threads. Oh I missed the part about __STDCPP_THREADS__ not being defined for mingw-w64. That seems like it's worth a distinct bug report that can focus just on that.
[Bug testsuite/103935] [12 regression] g++.dg/vect/slp-pr98855.cc fails after r12-6273
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103935
--- Comment #3 from Uroš Bizjak ---
(In reply to Richard Biener from comment #2)
> no longer xfailed. I suggest to re-add the { xfail *-*-* } to the
> profitability check.
You mean xfail for non-x86 targets?
[Bug tree-optimization/35341] Early exit loop with short known trip count not unrolled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35341 --- Comment #2 from Andrew Pinski --- Currently we get at -O2: Estimating sizes for loop 1 BB: 3, after_exit: 0 size: 1 _1 = i_13 * 2; Induction variable computation will be folded away. size: 1 _2 = a[_1]; size: 1 _3 = a[i_13]; size: 1 _4 = _2 + _3; size: 1 a[_1] = _4; size: 2 if (_4 == 10) BB: 6, after_exit: 1 BB: 4, after_exit: 0 size: 1 i_10 = i_13 + 1; Induction variable computation will be folded away. size: 1 ivtmp_7 = ivtmp_12 - 1; Induction variable computation will be folded away. size: 2 if (ivtmp_7 != 0) Exit condition will be eliminated in peeled copies. Exit condition will be eliminated in last copy. Constant conditional. size: 11-5, last_iteration: 11-5 Loop size: 11 Estimated size after unrolling: 20 Not unrolling loop 1: size would grow. We do unroll at -O3.
[Bug tree-optimization/103948] Vectorizer does not use vec_cmpMN without vcondMN pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103948
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #5 from Richard Biener ---
I guess that tree-vect-generic.c is not up-to-date with gimple-isel.cc. We
should probably somehow factor out relevant pieces.
Note vector lowering will see
_1 = a_2(D) > b_3(D);
_4 = VEC_COND_EXPR <_1, { -1, -1 }, { 0, 0 }>;
and clearly a
if (expand_vec_cond_expr_p (type, TREE_TYPE (a1), code))
that's just type/code based cannot know expanding just a comparison will work
fine. It does look like expand_vector_condition from vector lowering needs
some work. Maybe the following works though:
diff --git a/gcc/tree-vect-generic.c b/gcc/tree-vect-generic.c
index 6afb6999cd7..5814a71a5bb 100644
--- a/gcc/tree-vect-generic.c
+++ b/gcc/tree-vect-generic.c
@@ -1052,7 +1052,9 @@ expand_vector_condition (gimple_stmt_iterator *gsi,
bitmap dce_ssa_names)
}
}
- if (expand_vec_cond_expr_p (type, TREE_TYPE (a1), code))
+ if (expand_vec_cond_expr_p (type, TREE_TYPE (a1), code)
+ || (integer_all_onesp (b) && integer_zerop (c)
+ && expand_vec_cmp_expr_p (type, TREE_TYPE (a1), code)))
{
gcc_assert (TREE_CODE (a) == SSA_NAME || TREE_CODE (a) == VECTOR_CST);
return true;
obviously missing would be the case
cmp ? { 0, 0 } : { -1, -1 } via code inversion, not sure if we canonicalize
that way already and not sure if expansion later will pick that up correctly.
A vector mode with just vec_cmp and not vcond will be good to have to cover
all this with testcases ... ;)
If the above works it's pre-approved.
[Bug middle-end/103950] [9/10/11/12 Regression] printf("\xff") incorrectly optimized to putchar(-1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103950 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/103948] Vectorizer does not use vec_cmpMN without vcondMN pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103948
--- Comment #6 from Uroš Bizjak ---
(In reply to Richard Biener from comment #5)
> I guess that tree-vect-generic.c is not up-to-date with gimple-isel.cc. We
> should probably somehow factor out relevant pieces.
>
> Note vector lowering will see
>
> _1 = a_2(D) > b_3(D);
> _4 = VEC_COND_EXPR <_1, { -1, -1 }, { 0, 0 }>;
>
> and clearly a
>
> if (expand_vec_cond_expr_p (type, TREE_TYPE (a1), code))
>
> that's just type/code based cannot know expanding just a comparison will
> work fine. It does look like expand_vector_condition from vector lowering
> needs
> some work. Maybe the following works though:
>
> diff --git a/gcc/tree-vect-generic.c b/gcc/tree-vect-generic.c
> index 6afb6999cd7..5814a71a5bb 100644
> --- a/gcc/tree-vect-generic.c
> +++ b/gcc/tree-vect-generic.c
> @@ -1052,7 +1052,9 @@ expand_vector_condition (gimple_stmt_iterator *gsi,
> bitmap dce_ssa_names)
> }
> }
>
> - if (expand_vec_cond_expr_p (type, TREE_TYPE (a1), code))
> + if (expand_vec_cond_expr_p (type, TREE_TYPE (a1), code)
> + || (integer_all_onesp (b) && integer_zerop (c)
> + && expand_vec_cmp_expr_p (type, TREE_TYPE (a1), code)))
> {
>gcc_assert (TREE_CODE (a) == SSA_NAME || TREE_CODE (a) == VECTOR_CST);
>return true;
>
> obviously missing would be the case
> cmp ? { 0, 0 } : { -1, -1 } via code inversion, not sure if we canonicalize
> that way already and not sure if expansion later will pick that up correctly.
>
> A vector mode with just vec_cmp and not vcond will be good to have to cover
> all this with testcases ... ;)
>
> If the above works it's pre-approved.
Using the patch from Comment #2, the following testcase from Comment #0 can be
used:
--cut here--
typedef signed char vec __attribute__((vector_size(2)));
vec lt (vec a, vec b) { return a < b; }
--cut here--
vectorizes with -msse4 and fails to vectorize with -msse2.
I'll try your proposed patch from Comment #5 later today and report here.
[Bug driver/103949] gcc fails to provide a standard conforming C11 or C++17 environment even when specifying -std=c11 or -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103949 --- Comment #11 from Andrew Pinski --- (In reply to Jonathan Wakely from comment #10) > Oh I missed the part about __STDCPP_THREADS__ not being defined for > mingw-w64. That seems like it's worth a distinct bug report that can focus > just on that. I don't think that is a bug though because that mingw toolchain was configured with --enable-threads=single in that case (so libstdc++ does not have the full support). Most likely it needs to be configured with --enable-threads=win32 to support that.
[Bug driver/103949] gcc fails to provide a standard conforming C11 or C++17 environment even when specifying -std=c11 or -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103949 --- Comment #12 from Andrew Pinski --- See also https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/29e406ed.c6291.1541803dcf9.Coremail.lh_mouse%40126.com/ . Mingw thread support is always lacking behind because there are not enough developers doing development there so
[Bug testsuite/103935] [12 regression] g++.dg/vect/slp-pr98855.cc fails after r12-6273
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103935
--- Comment #4 from Richard Biener ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to Richard Biener from comment #2)
> > no longer xfailed. I suggest to re-add the { xfail *-*-* } to the
> > profitability check.
>
> You mean xfail for non-x86 targets?
Yes (if it now works consistently on x86 targets)
[Bug middle-end/103950] [9/10/11/12 Regression] printf("\xff") incorrectly optimized to putchar(-1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103950 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #5 from Andrew Pinski --- I will fully test my fix over next weekend.
[Bug middle-end/101530] ICE: 'verify_gimple' failed: non-top-level 'bit_field_ref' with __builtin_shufflevector()[0]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101530 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:be59671c5624fe8bf21ddb0192e97ebdfa4db381 commit r12-6403-gbe59671c5624fe8bf21ddb0192e97ebdfa4db381 Author: Richard Biener Date: Wed Jan 5 15:13:33 2022 +0100 middle-end/101530 - fix shufflevector lowering This makes __builtin_shufflevector lowering force the result of the BIT_FIELD_REF lowpart operation to a temporary as to fulfil the IL verifier constraint that BIT_FIELD_REFs should be always in outermost handled component position. Trying to enforce this during gimplification isn't as straight-forward as here where we know we're dealing with an rvalue. FAIL: c-c++-common/torture/builtin-shufflevector-1.c -O0 execution test 2022-01-05 Richard Biener PR middle-end/101530 gcc/c-family/ * c-common.c (c_build_shufflevector): Wrap the BIT_FIELD_REF in a TARGET_EXPR to force a temporary. gcc/testsuite/ * c-c++-common/builtin-shufflevector-3.c: New testcase.
[Bug middle-end/101530] ICE: 'verify_gimple' failed: non-top-level 'bit_field_ref' with __builtin_shufflevector()[0]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101530 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Richard Biener --- Fixed.
[Bug driver/103949] gcc fails to provide a standard conforming C11 or C++17 environment even when specifying -std=c11 or -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103949 --- Comment #13 from Jörn Heusipp --- (In reply to Jonathan Wakely from comment #10) > Oh I missed the part about __STDCPP_THREADS__ not being defined for > mingw-w64. That seems like it's worth a distinct bug report that can focus > just on that. I have reported https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003382 for the debian package.
[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 --- Comment #16 from Francois-Xavier Coudert --- Part 1/3 committed: IEEE_CLASS now recognises signaling NaNs on targets that provide the issignaling macro (from TS 18661-1:2014). https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=492954263e39346287a5a2a32bcc5312466a0ee1
[Bug fortran/82968] gfortran.dg/ieee/ieee_6.f90 fails at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82968 Francois-Xavier Coudert changed: What|Removed |Added Target Milestone|--- |12.0
[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 Francois-Xavier Coudert changed: What|Removed |Added Target Milestone|--- |12.0
[Bug target/64821] [AArch64] Improve target folding for vsqrt_f64 intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64821 Andrew Pinski changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2022-January ||/588012.html --- Comment #8 from Andrew Pinski --- Patch submitted: https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588012.html
[Bug driver/103949] gcc fails to provide a standard conforming C11 or C++17 environment even when specifying -std=c11 or -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103949 --- Comment #14 from Jonathan Wakely --- What is the output of x86_64-w64-mingw32-g++-posix -v
[Bug target/103465] [12 regression] -freorder-blocks-and-partition broken on 64-bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465 --- Comment #29 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:8234b0dcb2484f836d0fb8f12aa6b04f5e66db6f commit r12-6405-g8234b0dcb2484f836d0fb8f12aa6b04f5e66db6f Author: Eric Botcazou Date: Mon Jan 10 12:40:10 2022 +0100 Properly enable -freorder-blocks-and-partition on 64-bit Windows The PR uncovered that -freorder-blocks-and-partition was working by accident on 64-bit Windows, i.e. the middle-end was supposed to disable it with SEH. After the change installed on mainline, the middle-end properly disables it, which is too bad since a significant amount of work went into it for SEH. gcc/ PR target/103465 * coretypes.h (unwind_info_type): Swap UI_SEH and UI_TARGET.
[Bug driver/103949] gcc fails to provide a standard conforming C11 or C++17 environment even when specifying -std=c11 or -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103949 --- Comment #15 from Jörn Heusipp --- (In reply to Jonathan Wakely from comment #14) > What is the output of x86_64-w64-mingw32-g++-posix -v manx@appendix:~$ x86_64-w64-mingw32-g++-posix -v Using built-in specs. COLLECT_GCC=x86_64-w64-mingw32-g++-posix COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-w64-mingw32/10-posix/lto-wrapper Target: x86_64-w64-mingw32 Configured with: ../../src/configure --build=x86_64-linux-gnu --prefix=/usr --includedir='/usr/include' --mandir='/usr/share/man' --infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules --libdir='/usr/lib/x86_64-linux-gnu' --libexecdir='/usr/lib/x86_64-linux-gnu' --disable-maintainer-mode --disable-dependency-tracking --prefix=/usr --enable-shared --enable-static --disable-multilib --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --libdir=/usr/lib --enable-libstdcxx-time=yes --with-tune=generic --with-headers --enable-version-specific-runtime-libs --enable-fully-dynamic-string --enable-libgomp --enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-lto --enable-threads=posix --program-suffix=-posix --program-prefix=x86_64-w64-mingw32- --target=x86_64-w64-mingw32 --with-as=/usr/bin/x86_64-w64-mingw32-as --with-ld=/usr/bin/x86_64-w64-mingw32-ld --enable-libatomic --enable-libstdcxx-filesystem-ts=yes --enable-dependency-tracking Thread model: posix Supported LTO compression algorithms: zlib gcc version 10-posix 20210110 (GCC) manx@appendix:~$
[Bug tree-optimization/96779] Failure to optimize comparison of negative version of self
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96779 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug c/103960] New: Clang's -Wunknown-attributes is more useful than -Wattributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103960 Bug ID: 103960 Summary: Clang's -Wunknown-attributes is more useful than -Wattributes Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: diagnostic Severity: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- (This is really c-family not c) GCC's -Wattributes is used for both completely unknown attributes (e.g. the user has a typo, or they use a new attribute on an old GCC) and for misplaced attributes (e.g. a function attribute on a variable). This leaves users wondering what they've done wrong. For example, GCC 9 prints this because 'access' was added in GCC 10: f.c:5:1: warning: ‘access’ attribute directive ignored [-Wattributes] 5 | __attribute__ ((access (read_only, 1))) bool my_func (const MyStruct * const self); | ^ This doesn't tell the user *why* it was ignored. Did they just use the wrong grammar? You have to be quite familiar with GCC to know that using it in the wrong place would give a different diagnostic: f.c:5:1: warning: ‘access’ attribute only applies to function types [-Wattributes] 5 | bool my_func (const MyStruct * const __attribute__ ((access (read_only, 1))) self); | ^~~~ Apart from the caret being in the wrong place, this is pretty good. But for unknown attributes our diagnostic is vague about what the problem is. Clang's -Wunknown-attributes is more explicit: f.c:5:17: warning: unknown attribute 'access' ignored [-Wunknown-attributes] __attribute__ ((access (read_only, 1))) bool my_func (const MyStruct * const self); ^ This tells you clearly that clang simply doesn't recognize the 'access' attribute. Could we just add the word "unknown" to the diagnostic for unrecognised attributes?
[Bug driver/103949] gcc fails to provide a standard conforming C11 or C++17 environment even when specifying -std=c11 or -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103949 --- Comment #16 from Jonathan Wakely --- (In reply to Jörn Heusipp from comment #15) > --enable-threads=posix --program-suffix=-posix Then it should be defining __STDCPP_THREADS__=1, odd.
[Bug c++/101532] [12 Regression] ICE in finish_expr_stmt, at cp/semantics.c:859
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101532
--- Comment #3 from Andrew Pinski ---
Note it is not lambda related at all, here is a (invalid) C++98 case were we
ICE too:
class A {
~A() {}
};
template class B {
A f = 1;
};
B c;
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #77 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:4fde88e5dd152fe866a97b12e0f8229970d15cb3 commit r12-6406-g4fde88e5dd152fe866a97b12e0f8229970d15cb3 Author: Jonathan Wakely Date: Fri Jan 7 15:21:03 2022 + libstdc++: Add -nostdinc++ for c++17 sources [PR100017] When building a build!=host compiler, the just-built gcc can't be used to build the target libstdc++ (because it is built for the host triplet, not the build triplet). The top-level configure.ac sets up the build flags for libstdc++ (and other "raw_cxx" libs) like this: GCC_TARGET_TOOL(c++ for libstdc++, RAW_CXX_FOR_TARGET, CXX, [gcc/xgcc -shared-libgcc -B$$r/$(HOST_SUBDIR)/gcc -nostdinc++ -L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src -L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src/.libs -L$$r/$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs], c++) The -nostdinc++ flag is only used for the IN-TREE-TOOL, i.e. when using the just-built gcc/xgcc compiler. This means that the cross-compiler used to build libstdc++ will add its own libstdc++ headers to the include path. That results in the #include in src/c++17/floating_to_chars.cc and src/c++17/floating_from_chars.cc doing #include_next and finding the libstdc++ fenv.h wrapper from the host compiler. Because that has the same include guard as the in the libstdc++ we're trying to build, we never reach the underlying from libc. That results in several errors of the form: error: 'fenv_t' has not been declared in '::' The most correct fix would be to add -nostdinc++ to the RAW_CXX_FOR_TARGET variable in configure.ac, or the RAW_CXX_TARGET_EXPORTS variable in Makefile.tpl. Another solution would be to make the libstdc++ wrapper use _GLIBCXX_INCLUDE_NEXT_C_HEADERS like our and other C header wrappers. For now though, the simplest and safest solution is to just add -nostdinc++ to the CXXFLAGS used for src/c++17/*.cc, which is what this does. libstdc++-v3/ChangeLog: PR libstdc++/100017 * src/c++17/Makefile.am (AM_CXXFLAGS): Add -nostdinc++. * src/c++17/Makefile.in: Regenerate.
[Bug libstdc++/103866] AM_PROG_LIBTOOL not compatible with GCC_NO_EXECUTABLES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103866 --- Comment #12 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:68c2e9e9234cb301e9e81792cad233a41e797792 commit r12-6409-g68c2e9e9234cb301e9e81792cad233a41e797792 Author: Jonathan Wakely Date: Thu Jan 6 13:54:53 2022 + libstdc++: Fix and simplify freestanding configuration [PR103866] This fixes the --disable-hosted-libstdcxx build so that it works with --without-headers. Currently you need to also use --with-newlib, which is confusing for users who aren't actually using newlib. The AM_PROG_LIBTOOL checks are currently skipped for --with-newlib and --with-avrlibc builds, with this change they are also skipped when using --without-headers. It would be nice if using --disable-hosted-libstdcxx automatically skipped those checks, but GLIBCXX_ENABLE_HOSTED comes too late to make the AM_PROG_LIBTOOL checks depend on $is_hosted. The checks for EOF, SEEK_CUR etc. cause the build to fail if there is no available. Unlike most headers, which get a HAVE_FOO_H macro, is in autoconf's default includes, so every check tries to include it unconditionally. This change skips those checks for freestanding builds. Similarly, the checks for types done by GCC_HEADER_STDINT try to include and fail for --without-headers builds. This change skips the use of GCC_HEADER_STDINT for freestanding. We can probably stop using GCC_HEADER_STDINT entirely, since only one file uses the gstdint.h header that is generated, and that could easily be changed to use instead. That can wait for stage 1. We also need to skip the GLIBCXX_CROSSCONFIG stage if --without-headers was used, since we don't have any of the functions it deals with. The end result of the changes above is that it should not be necessary for a --disable-hosted-libstdcxx --without-headers build to also use --with-newlib. Finally, compile libsupc++ with -ffreestanding when --without-headers is used, so that will use instead of expecting it to come from libc. libstdc++-v3/ChangeLog: PR libstdc++/103866 * acinclude.m4 (GLIBCXX_COMPUTE_STDIO_INTEGER_CONSTANTS): Do nothing for freestanding builds. (GLIBCXX_ENABLE_HOSTED): Define FREESTANDING_FLAGS. * configure.ac: Do not use AC_LIBTOOL_DLOPEN when configured with --without-headers. Do not use GCC_HEADER_STDINT for freestanding builds. * libsupc++/Makefile.am (HOSTED_CXXFLAGS): Use -ffreestanding for freestanding builds. * configure: Regenerate. * Makefile.in: Regenerate. * doc/Makefile.in: Regenerate. * include/Makefile.in: Regenerate. * libsupc++/Makefile.in: Regenerate. * po/Makefile.in: Regenerate. * python/Makefile.in: Regenerate. * src/Makefile.in: Regenerate. * src/c++11/Makefile.in: Regenerate. * src/c++17/Makefile.in: Regenerate. * src/c++20/Makefile.in: Regenerate. * src/c++98/Makefile.in: Regenerate. * src/filesystem/Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate.
[Bug middle-end/103950] [9/10/11/12 Regression] printf("\xff") incorrectly optimized to putchar(-1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103950 --- Comment #6 from Thorsten Otto --- A similar fix will be needed in gimple_fold_builtin_fputs
[Bug libstdc++/103866] AM_PROG_LIBTOOL not compatible with GCC_NO_EXECUTABLES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103866 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |12.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #13 from Jonathan Wakely --- This should be fixed on trunk now. Please comment here if it isn't working for you.
[Bug c/103960] Clang's -Wunknown-attributes is more useful than -Wattributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103960 --- Comment #1 from Andrew Pinski --- So it looks like the warning is coming from the front-end though and not from c-family :). I noticed this because take: struct MyStruct; [[gg (read_only, 1)]] int my_func (const struct MyStruct * const self); - CUT The C front-end produces: :2:1: warning: 'gg' attribute ignored [-Wattributes] While the C++ front-end produces: :2:70: warning: 'gg' attribute directive ignored [-Wattributes]
[Bug c/103960] Clang's -Wunknown-attributes is more useful than -Wattributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103960 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-01-10 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- But yes I agree GCC's warning should be much better.
[Bug c/103961] New: gcc-12 apparently miscompiles libcap's cap_to_text() function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103961 Bug ID: 103961 Summary: gcc-12 apparently miscompiles libcap's cap_to_text() function Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: manuel.lauss at googlemail dot com Target Milestone: --- Created attachment 52152 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52152&action=edit preprocessed source file gcc-12 apparently miscompiles the libcap-2.62 function "cap_to_text()". I've seen it manifest with "ls" segfaulting in certain directories: $ ls *** buffer overflow detected ***: terminated Aborted (core dumped) #0 __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 44return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0; (gdb) bt #0 __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x7f34f856932f in __pthread_kill_internal (signo=6, threadid=) at pthread_kill.c:78 #2 0x7f34f8518e42 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x7f34f8503457 in __GI_abort () at abort.c:79 #4 0x7f34f855d5a8 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7f34f8690291 "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:155 #5 0x7f34f85fb042 in __GI___fortify_fail (msg=msg@entry=0x7f34f8690237 "buffer overflow detected") at fortify_fail.c:26 #6 0x7f34f85f9b60 in __GI___chk_fail () at chk_fail.c:28 #7 0x7f34f85f96d5 in ___sprintf_chk (s=s@entry=0x7fff9f08c6c2 ",", flag=flag@entry=1, slen=slen@entry=0, format=format@entry=0x7f34f86dc085 "%c%s%s%s") at sprintf_chk.c:37 #8 0x7f34f86da882 in sprintf (__fmt=0x7f34f86dc085 "%c%s%s%s", __s=) at /usr/include/bits/stdio2.h:38 #9 cap_to_text (caps=0x5643cf9b1a38, length_p=0x0) at cap_text.c:431 #10 0x5643cf983285 in ?? () If I replace the cap_text.o file from the gcc-12 build with one from a gcc-11.3 build, the error disappears. It also disappears when ls is run under strace. -fno-tree-vectorize does NOT help. Find attached the preprocessed cap_text.i file from libcap-2.62, as well as .S files of gcc-11.3 and 12.0 gcc version 12.0.0 20220110 (experimental) (Gentoo 12.0.0_pre p2, commit 92e114d66e93d60dcef97c66cddbae38b657d768)
[Bug c/103960] Clang's -Wunknown-attributes is more useful than -Wattributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103960 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=64332 --- Comment #3 from Andrew Pinski --- Note the location issue is PR 64332.
[Bug c/103961] gcc-12 apparently miscompiles libcap's cap_to_text() function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103961 --- Comment #1 from Manuel Lauss --- Created attachment 52153 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52153&action=edit gcc-11.3 output
[Bug c/103961] gcc-12 apparently miscompiles libcap's cap_to_text() function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103961 --- Comment #2 from Manuel Lauss --- Created attachment 52154 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52154&action=edit gcc-12.0 output
[Bug middle-end/103950] [9/10/11/12 Regression] printf("\xff") incorrectly optimized to putchar(-1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103950 --- Comment #7 from Andrew Pinski --- (In reply to Thorsten Otto from comment #6) > A similar fix will be needed in gimple_fold_builtin_fputs Yes agreed. gimple_fold_builtin_strstr should do the same, though I don't know if it will matter but it is better to be safe than sorry there.
[Bug tree-optimization/103941] uavgv2qi3_ceil is not used (SLP costing and patterns vs live stmts)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103941 --- Comment #2 from Richard Biener --- I think I've seen this before - the use in the conversion is elided in the vector path via recognizing a pattern of a pattern - that makes it not part of the SLP tree and thus left as SLP_TYPE (..) = loop_vect, fooling the live computation. vect_detect_hybrid_slp now does this in a more correct way but the original worklist seeding has to be done differently for BB SLP.
[Bug middle-end/103961] [12 Regression] gcc-12 apparently miscompiles libcap's cap_to_text() function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103961 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug c/64332] wrong location for Wattributes warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64332 Jonathan Wakely changed: What|Removed |Added Last reconfirmed|2014-12-16 00:00:00 |2022-1-10 --- Comment #7 from Jonathan Wakely --- Simpler repro for the bad location still present on trunk: void f (int __attribute__ ((invalid)) i); f.c:1:1: warning: ‘invalid’ attribute directive ignored [-Wattributes] 1 | void f (int __attribute__ ((invalid)) i); | ^~~~
[Bug middle-end/103961] [12 Regression] gcc-12 apparently miscompiles libcap's cap_to_text() function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103961
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-01-10
Ever confirmed|0 |1
--- Comment #3 from Andrew Pinski ---
Looks like GCC is getting confused due to:
p--;
I don't get:
[cap_text.c:419:3] # PT = anything
_104 = p_65 + 18446744073709551615;
All other places just have # PT = { D.4523 } (escaped)
D.4523 being buf decl.
[Bug middle-end/103961] [12 Regression] gcc-12 apparently miscompiles libcap's cap_to_text() function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103961 --- Comment #4 from Andrew Pinski --- There is a bogus warning too: cap_text.c:431:11: warning: '%c' directive writing 1 byte into a region of size 0 [-Wformat-overflow=] In file included from /usr/include/stdio.h:894, from cap_text.c:13: In function 'sprintf', inlined from 'cap_to_text' at cap_text.c:431:11: /usr/include/bits/stdio2.h:38:10: note: '__builtin___sprintf_chk' output between 2 and 5 bytes into a destination of size 0 And the gimple looks wrong: _164 = __sprintf_chkD.1304 (p_141, 1, 0, [cap_text.c:431:11] "%c%s%s%s", _31, iftmp.56_86, iftmp.55_85, iftmp.54_84); For GCC 11 we had: _164 = __sprintf_chkD.1270 (p_141, 1, 18446744073709551615, [cap_text.c:431:11] "%c%s%s%s", _33, iftmp.56_90, iftmp.55_89, iftmp.54_88);
[Bug middle-end/103961] [12 Regression] gcc-12 apparently miscompiles libcap's cap_to_text() function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103961 Andrew Pinski changed: What|Removed |Added Keywords|alias |needs-bisection, ||needs-reduction --- Comment #5 from Andrew Pinski --- I will try a reduction maybe over the weekend if nobody gets to it before me.
[Bug middle-end/103961] [12 Regression] gcc-12 apparently miscompiles libcap's cap_to_text() function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103961 --- Comment #6 from Andrew Pinski --- Note it is even wrong at -O1 -fno-thread-jumps .
[Bug c/103962] New: 'long double' to 'int' cast modifies rounding bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103962
Bug ID: 103962
Summary: 'long double' to 'int' cast modifies rounding bits
Product: gcc
Version: 9.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: master_szumi at o2 dot pl
Target Milestone: ---
Target: powerpc
Following code:
$ cat main2.c
#include
// #define FIX
int main() {
double a=54;
double b=10;
long double g=3;
int i = 0;
printf("%f\n", a/b);
i=g;
#ifdef FIX
__asm__("mtfsb0 31\n\t");
#endif
printf("%f\n", a/b);
return 0;
}
Compiled with:
/usr/bin/powerpc-e500v2-linux-gnu-gcc main2.c
Prints:
# ./a.out
5.40
5.39
IMO Rounding bit should be restored after 'cast' operation but they are not.
[Bug tree-optimization/103961] [12 Regression] gcc-12 apparently miscompiles libcap's cap_to_text() function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103961 Andrew Pinski changed: What|Removed |Added Component|middle-end |tree-optimization --- Comment #7 from Andrew Pinski --- objsz1 produces: Computing maximum subobject size for p_61: Visiting use-def links for p_61 Visiting use-def links for p_139 Visiting use-def links for p_64 Visiting use-def links for p_29 Visiting use-def links for p_63 Visiting use-def links for p_62 Visiting use-def links for p_141 Found a dependency loop at p_61 Need to reexamine p_141 Visiting use-def links for p_144 Visiting use-def links for p_141 Reexamining p_141 p_141: maximum subobject size 0 Simplified [/usr/include/bits/stdio2.h:38:10] _161 = __builtin_object_sizeD.1280 (p_61, 1); to 18446744073709551615 Simplified [/usr/include/bits/stdio2.h:38:10] _163 = __builtin_object_sizeD.1280 (p_141, 1); to 0 Simplified [/usr/include/bits/stdio2.h:38:10] _165 = __builtin_object_sizeD.1280 (p_62, 1); to 18446744073709551615 Computing maximum subobject size for p_66: Visiting use-def links for p_66 Visiting use-def links for p_123 Visiting use-def links for p_67 Visiting use-def links for p_136 Visiting use-def links for p_126 Simplified [/usr/include/bits/stdio2.h:38:10] _168 = __builtin_object_sizeD.1280 (p_66, 1); to 18446744073709551615 Computing maximum subobject size for p_125: Visiting use-def links for p_125 Simplified [/usr/include/bits/stdio2.h:38:10] _170 = __builtin_object_sizeD.1280 (p_125, 1); to 18446744073709551615 The 0 for _163/p_141 is wrong.
[Bug target/103962] 'long double' to 'int' cast modifies rounding bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103962 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-01-10 Ever confirmed|0 |1 Component|c |target Status|UNCONFIRMED |WAITING --- Comment #1 from Andrew Pinski --- Can you provide the full output of: /usr/bin/powerpc-e500v2-linux-gnu-gcc -v ?
[Bug target/103962] 'long double' to 'int' cast modifies rounding bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103962 --- Comment #2 from Jakub Szumacher --- n$ /usr/bin/powerpc-e500v2-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/powerpc-e500v2-linux-gnu-gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/powerpc-e500v2-linux-gnu/9.4.0/lto-wrapper Target: powerpc-e500v2-linux-gnu Configured with: /var/tmp/portage/cross-powerpc-e500v2-linux-gnu/gcc-9.4.0/work/gcc-9.4.0/configure --host=x86_64-pc-linux-gnu --target=powerpc-e500v2-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/powerpc-e500v2-linux-gnu/gcc-bin/9.4.0 --includedir=/usr/lib/gcc/powerpc-e500v2-linux-gnu/9.4.0/include --datadir=/usr/share/gcc-data/powerpc-e500v2-linux-gnu/9.4.0 --mandir=/usr/share/gcc-data/powerpc-e500v2-linux-gnu/9.4.0/man --infodir=/usr/share/gcc-data/powerpc-e500v2-linux-gnu/9.4.0/info --with-gxx-include-dir=/usr/lib/gcc/powerpc-e500v2-linux-gnu/9.4.0/include/g++-v9 --with-python-dir=/share/gcc-data/powerpc-e500v2-linux-gnu/9.4.0/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 9.4.0 p1' --disable-esp --enable-libstdcxx-time --enable-poison-system-directories --with-sysroot=/usr/powerpc-e500v2-linux-gnu --disable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-fixed-point --enable-e500-double --enable-targets=all --enable-libgomp --disable-libssp --disable-libada --disable-systemtap --disable-vtable-verify --disable-libvtv --enable-lto --without-isl --enable-default-pie --enable-default-ssp Thread model: posix gcc version 9.4.0 (Gentoo 9.4.0 p1)
[Bug target/103962] 'long double' to 'int' cast modifies rounding bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103962 --- Comment #3 from Jakub Szumacher --- # cat /proc/cpuinfo processor : 0 cpu : e500v2 clock : 799.92MHz revision: 2.3 (pvr 8021 0023) bogomips: 133.33 timebase: Memory : 1024 MB
[Bug tree-optimization/103961] [12 Regression] gcc-12 apparently miscompiles libcap's cap_to_text() function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103961
--- Comment #8 from Richard Biener ---
(In reply to Andrew Pinski from comment #3)
> Looks like GCC is getting confused due to:
> p--;
>
>
> I don't get:
> [cap_text.c:419:3] # PT = anything
> _104 = p_65 + 18446744073709551615;
>
> All other places just have # PT = { D.4523 } (escaped)
>
> D.4523 being buf decl.
I think that might be ranger adding nonnull to a pointer where we previously
have no points-to info at all (which means anything as well). The above
stmt is introduced by PRE:
- [local count: 982087419]:
- goto ; [100.00%]
+ [local count: 982087419]:
+ goto ; [100.00%]
+
+ [local count: 37309945]:
+ [cap_text.c:419:3] _104 = p_65 + 18446744073709551615;
- [local count: 39298952]:
+ [local count: 39298952]:
# PT = { D.4523 } (escaped)
- # p_228 = PHI
- [cap_text.c:419:3] # PT = { D.4523 } (escaped)
- p_149 = p_228 + 18446744073709551615;
+ # p_228 = PHI
+ # PT = { D.4523 } (escaped)
+ # prephitmp_82 = PHI <_104(29), p_210(91)>
which could indeed have preserved points-to info (but it would need to be
tracked in the expression sets so that's not too easy).
[Bug target/103962] 'long double' to 'int' cast modifies rounding bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103962 --- Comment #4 from Andrew Pinski --- Unless gentoo has patches, e500v2 support is gone. Only e500mc support is left from GCC 9+.
[Bug target/103962] 'long double' to 'int' cast modifies rounding bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103962 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #5 from Andrew Pinski --- powerpc*-*-*spe support was removed with r9-4728 . This means all of e500 and e500v2 support. e500mc support is still there though.
[Bug libstdc++/103955] std::to_chars(char*, char*, double, std::chars_format, int precision) crashes for the two maximal int precision values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103955 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Target Milestone|--- |11.3
[Bug d/103944] [12 Regression] Testsuite hang due to libphobos/testsuite/libphobos.gc/forkgc2.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103944 Iain Buclaw changed: What|Removed |Added Target||i686-redhat-linux --- Comment #3 from Iain Buclaw --- I'm able to reproduce either, I'll see if there's a 32-bit native machine around to test.
[Bug libstdc++/100017] [11 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 Stam Markianos-Wright changed: What|Removed |Added CC||stammark at gcc dot gnu.org --- Comment #78 from Stam Markianos-Wright --- Thank you, Jonathan! Is that commit OK to be backported to gcc-11, as well?
[Bug d/103944] [12 Regression] Testsuite hang due to libphobos/testsuite/libphobos.gc/forkgc2.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103944 --- Comment #4 from Jakub Jelinek --- Note, it isn't just i686-linux, I was getting the hangs on x86_64-linux, s390x-linux or armv7hl-linux-gnueabi too. Wonder whether it is -fstack-clash-protection -fcf-protection -fcf-protection related or perhaps glibc version dependent (in the builds where it reproduces we are using a very recent glibc snapshot (e.g. one with _dl_find_object in there in case the test uses unwind info in some way)).
[Bug d/103944] [12 Regression] Testsuite hang due to libphobos/testsuite/libphobos.gc/forkgc2.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103944 --- Comment #5 from Jakub Jelinek --- The process when it hangs is stuck on pthread_mutex_lock called from _D4core4sync5mutex5Mutex__T12lock_nothrowTCQBpQBnQBlQBiZQBdMFNbNiNeZv in libgphobos.so.3. #0 0xf7ee6579 in __kernel_vsyscall () #1 0xf73af173 in __lll_lock_wait () from /var/lib/mock/fedora-rawhide-i686/root/lib/libc.so.6 #2 0xf73b5f41 in pthread_mutex_lock@@GLIBC_2.0 () from /var/lib/mock/fedora-rawhide-i686/root/lib/libc.so.6 #3 0xf77b41d0 in ?? () #4 0xf7e0cff4 in ?? () where 0xf77b41d0 is inside of _D4core4sync5mutex5Mutex__T12lock_nothrowTCQBpQBnQBlQBiZQBdMFNbNiNeZv
[Bug libstdc++/77760] get_time needs to set tm_wday amd tm_yday
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77760 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a8d3c98746098e2784be7144c1ccc9fcc34a0888 commit r12-6410-ga8d3c98746098e2784be7144c1ccc9fcc34a0888 Author: Jakub Jelinek Date: Mon Jan 10 15:38:47 2022 +0100 libstdc++: Add %j, %U, %w, %W time_get support, fix %y, %Y, %C, %p [PR77760] glibc strptime passes around some state, what fields in struct tm have been set and what needs to be finalized through possibly recursive calls, and at the end performs various finalizations, like applying %p so that it works for both %I %p and %p %I orders, or applying century so that both %C %y and %y %C works, or computation of missing fields from others (e.g. from %Y and %j one can compute tm_mon, tm_mday and tm_wday, from %Y %U %w, %Y %W %w, %Y %U %a, or %Y %W %w one can compute tm_mon, tm_mday, tm_yday or e.g. from %Y %m %d one can compute tm_wday and tm_yday. As the finalization is quite large and doesn't need to be a template (doesn't depend on any iterators or char types), I've put it into libstdc++, and left some padding in the state struct, so that perhaps in the future we can track some more state without changing ABI. Unfortunately, there is an ugly problem that the standard mandates that get method calls the do_get virtual method and I don't see how we can cary on any state in between those calls (even if we did an ABI change for the facets, the methods are const, so that I think multiple threads could use the same time_get objects and we couldn't store state in there). There is a hack for that for GCC (seems to work with ICC too, doesn't work with clang++) if the do_get method isn't overriden we can pass the state around. For both do_get_year and per IRC discussions also for %y, the behavior is if 1-2 digits are parsed, the year is treated according to POSIX 2008 %y rules (0-68 is 2000-2068, 69-99 is 1969-1999), if 3-4 digits are parsed, it is treated as %Y. 2022-01-10 Jakub Jelinek PR libstdc++/77760 * include/bits/locale_facets_nonio.h (__time_get_state): New struct. (time_get::_M_extract_via_format): Declare new method with __time_get_state& as an extra argument. * include/bits/locale_facets_nonio.tcc (_M_extract_via_format): Add __state argument, set various fields in it while parsing. Handle %j, %U, %w and %W, fix up handling of %y, %Y and %C, don't adjust tm_hour for %p immediately. Add a wrapper around the method without the __state argument for backwards compatibility. (_M_extract_num): Remove all __len == 4 special cases. (time_get::do_get_time, time_get::do_get_date, time_get::do_get): Zero initialize __state, pass it to _M_extract_via_format and finalize it at the end. (do_get_year): For 1-2 digit parsed years, map 0-68 to 2000-2068, 69-99 to 1969-1999. For 3-4 digit parsed years use that as year. (get): If do_get isn't overloaded from the locale_facets_nonio.tcc version, don't call do_get but call _M_extract_via_format instead to pass around state. * config/abi/pre/gnu.ver (GLIBCXX_3.4.30): Export _M_extract_via_format with extra __time_get_state and __time_get_state::_M_finalize_state. * src/c++98/locale_facets.cc (is_leap, day_of_the_week, day_of_the_year): New functions in anon namespace. (mon_yday): New var in anon namespace. (__time_get_state::_M_finalize_state): Define. * testsuite/22_locale/time_get/get/char/4.cc: New test. * testsuite/22_locale/time_get/get/wchar_t/4.cc: New test. * testsuite/22_locale/time_get/get_year/char/1.cc (test01): Parse 197 as year 197AD instead of error. * testsuite/22_locale/time_get/get_year/char/5.cc (test01): Parse 1 as year 2001 instead of error. * testsuite/22_locale/time_get/get_year/char/6.cc: New test. * testsuite/22_locale/time_get/get_year/wchar_t/1.cc (test01): Parse 197 as year 197AD instead of error. * testsuite/22_locale/time_get/get_year/wchar_t/5.cc (test01): Parse 1 as year 2001 instead of error. * testsuite/22_locale/time_get/get_year/wchar_t/6.cc: New test.
[Bug c++/103963] New: Coroutine return type must not be copy- or move-constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103963
Bug ID: 103963
Summary: Coroutine return type must not be copy- or
move-constructible
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
This is a valid program:
```
#include
class task {
public:
class task_promise {
public:
task get_return_object() { return
task{handle_type::from_promise(*this)}; }
auto initial_suspend() { return std::suspend_always{}; }
auto final_suspend() noexcept { return std::suspend_never{}; }
void return_void() {}
void unhandled_exception() {}
};
using handle_type = std::coroutine_handle;
handle_type handle;
auto await_ready() { return false; }
auto await_suspend(handle_type) { return handle; }
void await_resume() { handle.resume(); }
using promise_type = task_promise;
task(handle_type h) : handle(h) {}
task(const task&) = delete;
task& operator=(const task&) = delete;
task(task&&) = delete;
task& operator=(task&&) = delete;
};
int main() {
task f = []() -> task { co_return; }();
task g = [&f]() -> task { co_await f; }();
g.handle.resume();
}
```
The code is accepted in MSVC, but not in GCC.
GCC 11.2 complains on the missing move-constructor:
error: use of deleted function 'task::task(task&&)'
and GCC trunk - on the missing copy-constructor:
error: use of deleted function 'task::task(const task&)'
Demo: https://gcc.godbolt.org/z/1c7fajqn8
Related discussion: https://stackoverflow.com/q/70641924/7325599
[Bug rtl-optimization/98782] [11/12 Regression] Bad interaction between IPA frequences and IRA resulting in spills due to changes in BB frequencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782 --- Comment #37 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:909a4b4764c4f270f09ccb2a950c91b21ed7b33a commit r12-6412-g909a4b4764c4f270f09ccb2a950c91b21ed7b33a Author: Richard Sandiford Date: Mon Jan 10 14:47:07 2022 + ira: Add comments and fix move_spill_restore calculation This patch adds comments to describe each use of ira_loop_border_costs. I think this highlights that move_spill_restore was using the wrong cost in one case, which came from tranposing [0] and [1] in the original (pre-ira_loop_border_costs) ira_memory_move_cost expressions. The difference would only be noticeable on targets that distinguish between load and store costs. gcc/ PR rtl-optimization/98782 * ira-color.c (color_pass): Add comments to describe the spill costs. (move_spill_restore): Likewise. Fix reversed calculation.
[Bug rtl-optimization/98782] [11/12 Regression] Bad interaction between IPA frequences and IRA resulting in spills due to changes in BB frequencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782 --- Comment #38 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:d54565d87ff79b882208dfb29af50232033c233d commit r12-6413-gd54565d87ff79b882208dfb29af50232033c233d Author: Richard Sandiford Date: Mon Jan 10 14:47:07 2022 + ira: Add ira_subloop_allocnos_can_differ_p color_pass has two instances of the same code for propagating non-cap assignments from parent loops to subloops. This patch adds a helper function for testing when such propagations are required for correctness and uses it to remove the duplicated code. A later patch will use this in ira-build.c too, which is why the function is exported to ira-int.h. No functional change intended. gcc/ PR rtl-optimization/98782 * ira-int.h (ira_subloop_allocnos_can_differ_p): New function, extracted from... * ira-color.c (color_pass): ...here.
[Bug rtl-optimization/98782] [11/12 Regression] Bad interaction between IPA frequences and IRA resulting in spills due to changes in BB frequencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782 --- Comment #39 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:01f3e6a40e7202310abbeb41c345d325bd69554f commit r12-6415-g01f3e6a40e7202310abbeb41c345d325bd69554f Author: Richard Sandiford Date: Mon Jan 10 14:47:08 2022 + ira: Consider modelling caller-save allocations as loop spills If an allocno A in an inner loop L spans a call, a parent allocno AP can choose to handle a call-clobbered/caller-saved hard register R in one of two ways: (1) save R before each call in L and restore R after each call (2) spill R to memory throughout L (2) can be cheaper than (1) in some cases, particularly if L does not reference A. Before the patch we always did (1). The patch adds support for picking (2) instead, when it seems cheaper. It builds on the earlier support for not propagating conflicts to parent allocnos. gcc/ PR rtl-optimization/98782 * ira-int.h (ira_caller_save_cost): New function. (ira_caller_save_loop_spill_p): Likewise. * ira-build.c (ira_propagate_hard_reg_costs): Test whether it is cheaper to spill a call-clobbered register throughout a loop rather than spill it around each individual call. If so, treat all call-clobbered registers as conflicts and... (propagate_allocno_info): ...do not propagate call information from the child to the parent. * ira-color.c (move_spill_restore): Update accordingly. * ira-costs.c (ira_tune_allocno_costs): Use ira_caller_save_cost. gcc/testsuite/ * gcc.target/aarch64/reg-alloc-3.c: New test.
[Bug rtl-optimization/98782] [11/12 Regression] Bad interaction between IPA frequences and IRA resulting in spills due to changes in BB frequencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782 --- Comment #40 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:037cc0b4a6646cc86549247a3590215ebd5c4c43 commit r12-6416-g037cc0b4a6646cc86549247a3590215ebd5c4c43 Author: Richard Sandiford Date: Mon Jan 10 14:47:09 2022 + ira: Handle "soft" conflicts between cap and non-cap allocnos This patch looks for allocno conflicts of the following form: - One allocno (X) is a cap allocno for some non-cap allocno X2. - X2 belongs to some loop L2. - The other allocno (Y) is a non-cap allocno. - Y is an ancestor of some allocno Y2 in L2. - Y2 is not referenced in L2 (that is, ALLOCNO_NREFS (Y2) == 0). - Y can use a different allocation from Y2. In this case, Y's register is live across L2 but is not used within it, whereas X's register is used only within L2. The conflict is therefore only "soft", in that it can easily be avoided by spilling Y2 inside L2 without affecting any insn references. In principle we could do this for ALLOCNO_NREFS (Y2) != 0 too, with the callers then taking Y2's ALLOCNO_MEMORY_COST into account. There would then be no "cliff edge" between a Y2 that has no references and a Y2 that has (say) a single cold reference. However, doing that isn't necessary for the PR and seems to give variable results in practice. (fotonik3d_r improves slightly but namd_r regresses slightly.) It therefore seemed better to start with the higher-value zero-reference case and see how things go. On top of the previous patches in the series, this fixes the exchange2 regression seen in GCC 11. gcc/ PR rtl-optimization/98782 * ira-int.h (ira_soft_conflict): Declare. * ira-color.c (max_soft_conflict_loop_depth): New constant. (ira_soft_conflict): New function. (spill_soft_conflicts): Likewise. (assign_hard_reg): Use them to handle the case described by the comment above ira_soft_conflict. (improve_allocation): Likewise. * ira.c (check_allocation): Allow allocnos with "soft" conflicts to share the same register. gcc/testsuite/ * gcc.target/aarch64/reg-alloc-4.c: New test.
[Bug d/103944] [12 Regression] Testsuite hang due to libphobos/testsuite/libphobos.gc/forkgc2.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103944 --- Comment #6 from Iain Buclaw --- (In reply to Jakub Jelinek from comment #4) > Note, it isn't just i686-linux, I was getting the hangs on x86_64-linux, > s390x-linux or armv7hl-linux-gnueabi too. > Wonder whether it is > -fstack-clash-protection -fcf-protection -fcf-protection > related or perhaps glibc version dependent (in the builds where it > reproduces we are using a very recent glibc snapshot (e.g. one with > _dl_find_object in there in case the test uses unwind info in some way)). CET is turned on by default now IIRC for X86/64, so I doubt it'd be -fcf-protection.
[Bug rtl-optimization/98782] [11 Regression] Bad interaction between IPA frequences and IRA resulting in spills due to changes in BB frequencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782 rsandifo at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Summary|[11/12 Regression] Bad |[11 Regression] Bad |interaction between IPA |interaction between IPA |frequences and IRA |frequences and IRA |resulting in spills due to |resulting in spills due to |changes in BB frequencies |changes in BB frequencies Status|ASSIGNED|RESOLVED --- Comment #41 from rsandifo at gcc dot gnu.org --- Hopefully fixed on trunk, much too invasive to backport. Thanks Vlad for the reviews.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 98782, which changed state. Bug 98782 Summary: [11 Regression] Bad interaction between IPA frequences and IRA resulting in spills due to changes in BB frequencies https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/103964] New: [9/10/11/12 Regression] OVS miscompilation since r0-92313-g5006671f1aaa63cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103964
Bug ID: 103964
Summary: [9/10/11/12 Regression] OVS miscompilation since
r0-92313-g5006671f1aaa63cd
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Following testcase is miscompiled e.g. with -g -Og -fno-strict-aliasing
starting with r0-92313-g5006671f1aaa63cd - this is a self-contained testcase
from https://gcc.gnu.org/pipermail/gcc-help/2021-December/141021.html
With current trunk and -g -Og -fno-strict-aliasing (-Og chosen as something
that does just a few optimizations), I see on current gcc trunk the fre1 pass
optimizing:
- _69 = start.prev;
# DEBUG list_ => NULL
- last_49 = _69 + 18446744073709551552;
- # DEBUG last => last_49
+ # DEBUG last => &MEM [(void *)&start + -64B]
# DEBUG BEGIN_STMT
- printf ("first: %p \nlast: %p\n", first_47, last_49);
+ printf ("first: %p \nlast: %p\n", first_47, &MEM [(void
*)&start + -64B]);
We have earlier:
start.prev = &start;
start.next = &start;
and .prev stores in between are:
MEM[(struct ovs_list *)member_59 + 64B].prev = _48;
...
MEM[(struct ovs_list *)pos_32 + 64B].prev = _15;
I bet the alias oracle assumes that pos_32, being an struct member pointer,
can't overwrite start.prev where start is much smaller than that (has just
struct ovs_list type).
That MEM[(struct ovs_list *)pos_32 + 64B].prev = _15; is actually what
overwrites start.prev.
# pos_32 = PHI
and
_6 = start.next;
_7 = (long unsigned int) _6;
_8 = _7 + 18446744073709551552;
pos_61 = (struct member *) _8;
and
_11 = pos_32->elem.next;
_12 = (long unsigned int) _11;
_13 = _12 + 18446744073709551552;
pos_62 = (struct member *) _13;
If it wouldn't use uintptr_t in there, I'd say it is clearly UB, doing pointer
arithmetics out of bounds of the start object. With uintptr_t it just
materializes a pointer known to point outside of the start object.
For -fstrict-aliasing, I think it is just fine to treat it as UB, for
-fno-strict-aliasing I don't know.
I'm afraid Linux kernel and various other projects that copied such
questionable code from it use it heavily.
/* How to build:
>> gcc -O2 -g -o example2 example2.c ^C
>> ./example2
start: 0x7ffc13ba2800
first: 0x1ba32f0
last: 0x7ffc13ba27c0
list is broken!
Start: 0x7ffc13ba2800. start->next: 0x1ba3330, start->next->next: 0x1ba3390,
start->prev: 0x1ba3390
>> gcc -g -o example2 example2.c
>> ./example2
start: 0x7ffd84d91660
first: 0x23b52f0
last: 0x23b5350
Same for clang.
*/
#include
#include
#include
#include
#include
#include
// from include/openvswitch/util.h //
#define INIT_CONTAINER(OBJECT, POINTER, MEMBER)
\
((OBJECT) = NULL, ASSIGN_CONTAINER(OBJECT, POINTER, MEMBER))
#define OVS_TYPEOF(OBJECT) typeof(OBJECT)
#define OBJECT_OFFSETOF(OBJECT, MEMBER) offsetof(typeof(*(OBJECT)), MEMBER)
#define OBJECT_CONTAINING(POINTER, OBJECT, MEMBER)
\
((OVS_TYPEOF(OBJECT))(
\
void*)((char*)(POINTER)-OBJECT_OFFSETOF(OBJECT, MEMBER)))
#define OBJECT_MEMBER(POINTER, OBJECT, MEMBER)
\
((OVS_TYPEOF(&POINTER->MEMBER))
\
((uintptr_t) POINTER + OBJECT_OFFSETOF(POINTER, MEMBER)))
#define ASSIGN_CONTAINER(OBJECT, POINTER, MEMBER)
\
((OBJECT) = OBJECT_CONTAINING(POINTER, OBJECT, MEMBER), (void)0)
#define HMAP_FOR_EACH(NODE, MEMBER, HMAP)
\
HMAP_FOR_EACH_INIT(NODE, MEMBER, HMAP, (void)0)
#define HMAP_FOR_EACH_INIT(NODE, MEMBER, HMAP, ...)
\
for (INIT_CONTAINER(NODE, hmap_first(HMAP), MEMBER), __VA_ARGS__;
\
(NODE != OBJECT_CONTAINING(NULL, NODE, MEMBER)) ||
\
((NODE = NULL), 0);
\
ASSIGN_CONTAINER(NODE, hmap_next(HMAP, &(NODE)->MEMBER), MEMBER))
#define LIST_FOR_EACH(ITER, MEMBER, LIST)
\
for (INIT_CONTAINER(ITER, (LIST)->next, MEMBER);
\
&(ITER)->MEMBER != (LIST);
\
ASSIGN_CONTAINER(ITER, (ITER)->MEMBER.next, MEMBER))
// from lib/list.c / include/openvswitch/list.h /
struct ovs_list {
struct ovs_list* prev; /* Previous list element. */
struct ovs_list* next; /* Next list element. */
};
static inline void ovs_list_init(struct ovs_list* list)
{
list->next = list->prev = list;
}
static inline void ovs_list_insert(struct ovs_list* before,
struct
[Bug tree-optimization/103964] [9/10/11/12 Regression] OVS miscompilation since r0-92313-g5006671f1aaa63cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103964 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #1 from Florian Weimer --- The kernel version of the macro is called list_for_each_entry. There's a Stackoverflow question about this issue: Does Linux kernel list implementation cause UB? https://stackoverflow.com/questions/64859526/does-linux-kernel-list-implementation-cause-ub
[Bug c/103965] New: optimizer (-O2) changes behavior in cast-to-container iteration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103965
Bug ID: 103965
Summary: optimizer (-O2) changes behavior in cast-to-container
iteration
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: amorenoz at redhat dot com
Target Milestone: ---
Created attachment 52155
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52155&action=edit
test case that returns 0 when working fine and 1 when broken
Hi,
The attached test-case has been extracted from openvswitch source code. Macros
have been expanded and code has been simplified as much as possible.
The problematic code is a cast-to-container list iteration that uses a
stack-allocated list element without containing object:
struct member {
int padding[14];
int order;
struct ovs_list elem;
};
[...]
struct ovs_list start;
struct member *member *members[2];
for (i = 0; i < 2; i++) {
struct member* pos;
member = members[i];
for (((pos) = ((void*)0),
((pos) = ((typeof(pos))(void*)((uintptr_t)((&start)->next) -
__builtin_offsetof(struct member,
elem);
&(pos)->elem != (&start);
((pos) = ((typeof(pos))(void*)((uintptr_t)((pos)->elem.next) -
__builtin_offsetof(struct member,
elem) {
if (member->order > pos->order) {
break;
}
}
ovs_list_insert(&pos->elem, &member->elem);
}
When "-O2" is used, gcc seems to just optimize out one of the iterations.
Interestingly, replacing the pointer arithmetics with integer arithmetics still
makes the code fail.
Is this a bug in gcc? or is this just invalid C code? and if so, why?
[Bug c/103965] optimizer (-O2) changes behavior in cast-to-container iteration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103965 amorenoz at redhat dot com changed: What|Removed |Added CC||amorenoz at redhat dot com, ||fweimer at redhat dot com, ||jakub at redhat dot com --- Comment #1 from amorenoz at redhat dot com --- /cc jakub
[Bug c/103965] optimizer (-O2) changes behavior in cast-to-container iteration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103965 --- Comment #2 from amorenoz at redhat dot com --- Jakub and Florian have kindly assisted in trying to understand the problem and will likely be able to provide more insightful comments
