[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #17 from Eric Botcazou --- Thanks for the data point. We have a working 11.2 compiler on the same platform configured with: ../src/configure --enable-languages=ada,c,c++ --enable-checking=release --enable-threads=win32 --enable-lto --enable-large-address-aware --with-fpmath=sse --disable-sjlj-exceptions --enable-frame-pointer --disable-nls --disable-libstdcxx-pch --disable-libada --enable-libstdcxx Would it be possible for you to add --enable-frame-pointer to the options?
[Bug tree-optimization/102622] [9/10/12 Regression] Wrong code with -O1 and above due to phiopt and signed one bit integer types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102622 --- Comment #20 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:882d806c1a8f9d2d2ade1133de88d63e5d4fe40c commit r12-4276-g882d806c1a8f9d2d2ade1133de88d63e5d4fe40c Author: Andrew Pinski Date: Sun Oct 10 01:28:59 2021 + tree-optimization: [PR102622]: wrong code due to signed one bit integer and "a?-1:0" So it turns out this is kinda of a latent bug but not really latent. In GCC 9 and 10, phi-opt would transform a?-1:0 (even for signed 1-bit integer) to -(type)a but the type is an one bit integer which means the negation is undefined. GCC 11 fixed the problem by checking for a?pow2cst:0 transformation before a?-1:0 transformation. When I added the transformations to match.pd, I had swapped the order not paying attention and I didn't expect anything of it. Because there was no testcase failing due to this. Anyways this fixes the problem on the trunk by swapping the order in match.pd and adding a comment of why the order is this way. I will try to come up with a patch for GCC 9 and 10 series later on which fixes the problem there too. Note I didn't include the original testcase which requires the vectorizer and AVX-512f as I can't figure out the right dg options to restrict it to avx-512f but I did come up with a testcase which shows the problem and even more shows the problem with the 9/10 series as mentioned. OK? Bootstrapped and tested on x86_64-linux-gnu. PR tree-optimization/102622 gcc/ChangeLog: * match.pd: Swap the order of a?pow2cst:0 and a?-1:0 transformations. Swap the order of a?0:pow2cst and a?0:-1 transformations. gcc/testsuite/ChangeLog: * gcc.c-torture/execute/bitfld-10.c: New test.
[Bug tree-optimization/102622] [9/10 Regression] Wrong code with -O1 and above due to phiopt and signed one bit integer types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102622 Andrew Pinski changed: What|Removed |Added URL|https://gcc.gnu.org/piperma | |il/gcc-patches/2021-October | |/581251.html| Summary|[9/10/12 Regression] Wrong |[9/10 Regression] Wrong |code with -O1 and above due |code with -O1 and above due |to phiopt and signed one|to phiopt and signed one |bit integer types |bit integer types Keywords|patch | Known to work||12.0 --- Comment #21 from Andrew Pinski --- Fixed on the trunk. I will come up with a patch for GCC 9 and 10 branches in the next few days since it won't be even close to a backport of this patch.
[Bug tree-optimization/102622] [9/10 Regression] Wrong code with -O1 and above due to phiopt and signed one bit integer types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102622 --- Comment #22 from Andrew Pinski --- Here is the simple patch which I will test for both GCC 10 and GCC 9. The question becomes does it make sense to make the same change to GCC 11 even if it cannot be hit. diff --git a/gcc/tree-ssa-phiopt.c b/gcc/tree-ssa-phiopt.c index 9ed26a3d45f..a6c197defea 100644 --- a/gcc/tree-ssa-phiopt.c +++ b/gcc/tree-ssa-phiopt.c @@ -770,9 +770,12 @@ conditional_replacement (basic_block cond_bb, basic_block middle_bb, if ((integer_zerop (arg0) && integer_onep (arg1)) || (integer_zerop (arg1) && integer_onep (arg0))) neg = false; + /* For signed one bit types, the negation is not needed and + should be avoided and is the same as 1 case for non-signed + one bit types. */ else if ((integer_zerop (arg0) && integer_all_onesp (arg1)) || (integer_zerop (arg1) && integer_all_onesp (arg0))) -neg = true; +neg = TYPE_PRECISION (TREE_TYPE (arg0)) != 1; else return false;
[Bug debug/102441] [10/11/12 Regression] Incorrect location list in debug info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102441
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:9583b26f3701ea0456405d84f9a898451a2f7452
commit r12-4277-g9583b26f3701ea0456405d84f9a898451a2f7452
Author: Jakub Jelinek
Date: Sun Oct 10 12:13:22 2021 +0200
var-tracking: Fix a wrong-debug issue caused by my r10-7665 var-tracking
change [PR102441]
Since my r10-7665-g33c45e51b4914008064d9b77f2c1fc0eea1ad060 change, we get
wrong-debug on e.g. the following testcase at -O2 -g on x86_64-linux for
the
x parameter:
void bar (int *r);
int
foo (int x)
{
int r = 0;
bar (&r);
return r;
}
At the start of function, we have
subq$24, %rsp
leaq12(%rsp), %rdi
instructions. The x parameter is passed in %rdi, but isn't used in the
function and so the leaq instruction overwrites %rdi without remembering
%rdi anywhere. Before the r10-7665 change (which was trying to fix a large
(3% for 32-bit, 1% for 64-bit x86-64) debug info/loc growth introduced with
r10-7515), the leaq insn above resulted in a MO_VAL_SET micro-operation
that
said that the value of sp + 12, a cselib_sp_derived_value_p, is stored into
the %rdi register. The r10-7665 change added a change to add_stores that
added no micro-operation for the leaq store, with the rationale that the sp
based values can be and will be always computable some other more compact
and primarily more stable way (cfa based expression like DW_OP_fbreg, that
is the same in the whole function). That is true. But by throwing the
micro-operation on the floor, we miss another important part of the
MO_VAL_SET, in particular that the destination of the store, %rdi in this
case, now has a different value from what it had before, so the vt_*
dataflow code thinks that even after the leaq instruction %rdi still holds
the x argument value (and changes it to DW_OP_entry_value (%rdi) only in
the
middle of the call to bar). Previously and with the patches below,
the location for x changes already at the end of leaq instruction to
DW_OP_entry_value (%rdi).
My first attempt to fix this was instead of dropping the MO_VAL_SET add
a MO_CLOBBER operation:
--- gcc/var-tracking.c.jj 2021-05-04 21:02:24.196799586 +0200
+++ gcc/var-tracking.c 2021-09-24 19:23:16.420154828 +0200
@@ -6133,7 +6133,9 @@ add_stores (rtx loc, const_rtx expr, voi
{
if (preserve)
preserve_value (v);
- return;
+ mo.type = MO_CLOBBER;
+ mo.u.loc = loc;
+ goto log_and_return;
}
nloc = replace_expr_with_values (oloc);
so don't track that the value lives in the loc destination, but track
that the previous value doesn't live there anymore. That failed bootstrap
miserably, the vt_* code isn't prepared to see MO_CLOBBER of a MEM that
isn't tracked (e.g. has MEM_EXPR on it that the var-tracking code wants
to track, i.e. track_p in add_stores). On the other side, thinking about
it more, in the most common case where a cselib_sp_derived_value_p value
is stored into the sp register (and which is the reason why PR94495
testcase got larger), dropping the micro-operation on the floor is the
right thing, because we have that cselib_sp_derived_value_p tracking, any
reads from the sp hard register will be treated as
cselib_sp_derived_value_p.
Then I've tried 3 different patches described below and in the end
what is committed is patch2.
Additionally, I've gathered statistics from cc1plus by always reverting the
var-tracking.c change after finished bootstrap/regtest and rebuilding the
stage3 var-tracking.o and cc1plus, such that it would be comparable.
dwlocstat and .debug_{info,loclists} section sizes detailed below.
patch3 uses MO_VAL_SET (i.e. essentially reversion of the r10-7665
change) when destination is not a REG_P and !track_p, otherwise if
destination is sp drops the micro-operation on the floor (i.e. no change),
otherwise adds a MO_CLOBBER.
patch1 is similar, except it checks for destination not equal to sp and
!track_p, i.e. for !track_p REG_P destinations other than sp it will use
MO_VAL_SET rather than MO_CLOBBER.
Finally, patch2, the shortest patch, uses MO_VAL_SET whenever destination
is not sp and otherwise drops the micro-operation on the floor.
All the 3 patches don't affect the PR94495 testcase, all the changes
there were caused by stores of sp based values into %rsp.
While the patch2 (and patch1 which results in exactly the same sizes)
causes the largest debug loclists/info growth from the 3, it is still quite
minor (0.651% on 64-bit and 0.114% on 32-bit) compared
to the 1% and 3% PR94495 was trying to solve, and I actually think it is
the
best thing to
[Bug debug/102441] [10/11/12 Regression] Incorrect location list in debug info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102441
--- Comment #5 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:309827c85f14011166178c6efcb721d87a4577bb
commit r11-9093-g309827c85f14011166178c6efcb721d87a4577bb
Author: Jakub Jelinek
Date: Sun Oct 10 12:13:22 2021 +0200
var-tracking: Fix a wrong-debug issue caused by my r10-7665 var-tracking
change [PR102441]
Since my r10-7665-g33c45e51b4914008064d9b77f2c1fc0eea1ad060 change, we get
wrong-debug on e.g. the following testcase at -O2 -g on x86_64-linux for
the
x parameter:
void bar (int *r);
int
foo (int x)
{
int r = 0;
bar (&r);
return r;
}
At the start of function, we have
subq$24, %rsp
leaq12(%rsp), %rdi
instructions. The x parameter is passed in %rdi, but isn't used in the
function and so the leaq instruction overwrites %rdi without remembering
%rdi anywhere. Before the r10-7665 change (which was trying to fix a large
(3% for 32-bit, 1% for 64-bit x86-64) debug info/loc growth introduced with
r10-7515), the leaq insn above resulted in a MO_VAL_SET micro-operation
that
said that the value of sp + 12, a cselib_sp_derived_value_p, is stored into
the %rdi register. The r10-7665 change added a change to add_stores that
added no micro-operation for the leaq store, with the rationale that the sp
based values can be and will be always computable some other more compact
and primarily more stable way (cfa based expression like DW_OP_fbreg, that
is the same in the whole function). That is true. But by throwing the
micro-operation on the floor, we miss another important part of the
MO_VAL_SET, in particular that the destination of the store, %rdi in this
case, now has a different value from what it had before, so the vt_*
dataflow code thinks that even after the leaq instruction %rdi still holds
the x argument value (and changes it to DW_OP_entry_value (%rdi) only in
the
middle of the call to bar). Previously and with the patches below,
the location for x changes already at the end of leaq instruction to
DW_OP_entry_value (%rdi).
My first attempt to fix this was instead of dropping the MO_VAL_SET add
a MO_CLOBBER operation:
--- gcc/var-tracking.c.jj 2021-05-04 21:02:24.196799586 +0200
+++ gcc/var-tracking.c 2021-09-24 19:23:16.420154828 +0200
@@ -6133,7 +6133,9 @@ add_stores (rtx loc, const_rtx expr, voi
{
if (preserve)
preserve_value (v);
- return;
+ mo.type = MO_CLOBBER;
+ mo.u.loc = loc;
+ goto log_and_return;
}
nloc = replace_expr_with_values (oloc);
so don't track that the value lives in the loc destination, but track
that the previous value doesn't live there anymore. That failed bootstrap
miserably, the vt_* code isn't prepared to see MO_CLOBBER of a MEM that
isn't tracked (e.g. has MEM_EXPR on it that the var-tracking code wants
to track, i.e. track_p in add_stores). On the other side, thinking about
it more, in the most common case where a cselib_sp_derived_value_p value
is stored into the sp register (and which is the reason why PR94495
testcase got larger), dropping the micro-operation on the floor is the
right thing, because we have that cselib_sp_derived_value_p tracking, any
reads from the sp hard register will be treated as
cselib_sp_derived_value_p.
Then I've tried 3 different patches described below and in the end
what is committed is patch2.
Additionally, I've gathered statistics from cc1plus by always reverting the
var-tracking.c change after finished bootstrap/regtest and rebuilding the
stage3 var-tracking.o and cc1plus, such that it would be comparable.
dwlocstat and .debug_{info,loclists} section sizes detailed below.
patch3 uses MO_VAL_SET (i.e. essentially reversion of the r10-7665
change) when destination is not a REG_P and !track_p, otherwise if
destination is sp drops the micro-operation on the floor (i.e. no change),
otherwise adds a MO_CLOBBER.
patch1 is similar, except it checks for destination not equal to sp and
!track_p, i.e. for !track_p REG_P destinations other than sp it will use
MO_VAL_SET rather than MO_CLOBBER.
Finally, patch2, the shortest patch, uses MO_VAL_SET whenever destination
is not sp and otherwise drops the micro-operation on the floor.
All the 3 patches don't affect the PR94495 testcase, all the changes
there were caused by stores of sp based values into %rsp.
While the patch2 (and patch1 which results in exactly the same sizes)
causes the largest debug loclists/info growth from the 3, it is still quite
minor (0.651% on 64-bit and 0.114% on 32-bit) compared
to the 1% and 3% PR94495 was trying to solve, and I actually think it is
the
best
[Bug c++/61355] gcc doesn't normalize type in non-type template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61355 --- Comment #6 from Ivan Sorokin --- (In reply to Patrick Palka from comment #5) > Fixed for GCC 12. Thanks!
[Bug debug/102441] [10 Regression] Incorrect location list in debug info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102441 Jakub Jelinek changed: What|Removed |Added Summary|[10/11/12 Regression] |[10 Regression] Incorrect |Incorrect location list in |location list in debug info |debug info | --- Comment #6 from Jakub Jelinek --- Fixed for 11.3+ and 12.1+ so far.
[Bug testsuite/102677] New: Extra testsuite failures with glibc 2.34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102677 Bug ID: 102677 Summary: Extra testsuite failures with glibc 2.34 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com Target Milestone: --- On Fedora/35 x86-64 with glibc 2.34, I got extra failures: FAIL: 17_intro/headers/c++1998/49745.cc (test for excess errors) FAIL: 30_threads/jthread/95989.cc execution test FAIL: gcc.dg/analyzer/analyzer-verbosity-2a.c (test for excess errors) FAIL: gcc.dg/analyzer/analyzer-verbosity-3a.c (test for excess errors) FAIL: gcc.dg/analyzer/edges-1.c (test for excess errors) FAIL: gcc.dg/analyzer/file-1.c (test for excess errors) FAIL: gcc.dg/analyzer/file-2.c (test for excess errors) FAIL: gcc.dg/analyzer/file-paths-1.c (test for excess errors) FAIL: gcc.dg/analyzer/file-pr58237.c (test for excess errors) FAIL: gcc.dg/analyzer/pr99716-1.c (test for excess errors) FAIL: g++.dg/asan/asan_test.C -O2 (test for excess errors) FAIL: gfortran.dg/PR93963.f90 -O2 execution test FAIL: gfortran.dg/PR93963.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/PR93963.f90 -O3 -g execution test FAIL: gfortran.dg/PR93963.f90 -Os execution test comparing against Fedora/34 x86-64 with glibc 2.33.
[Bug libstdc++/49745] error: ‘int truncate’ redeclared as different kind of symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49745 H.J. Lu changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #21 from H.J. Lu --- This now fails with glibc 2.34: /export/gnu/import/git/gitlab/x86-gcc-lam/libstdc++-v3/testsuite/17_intro/headers/c++1998/49745.cc:22: error: 'int truncate' redeclared as different kind of entity In file included from /usr/include/bits/sigstksz.h:24, from /usr/include/signal.h:328, from /export/build/gnu/tools-build/gcc-lam-sde/build-x86_64-linux/x86_64-pc-linux-gnu/libstdc++-v3/include/csignal:42, from /export/build/gnu/tools-build/gcc-lam-sde/build-x86_64-linux/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/stdc++.h:43, from : /usr/include/unistd.h:1022: note: previous declaration 'int truncate(const char*, __off_t)' compiler exited with status 1 FAIL: 17_intro/headers/c++1998/49745.cc (test for excess errors)
[Bug tree-optimization/102676] Failure to optimize out malloc/nothrow allocation that's only used for bool checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102676 --- Comment #2 from Gabriel Ravier --- Well, I think the assumption LLVM is making is that the allocation, being unused, can just be eliminated and considered to have always succeeded. I don't see how that would contradict the standard, although I suppose some would consider it a bad thing to do for the compiler (although in that case you might as well rule out all optimizations that elide allocations).
[Bug middle-end/102566] [i386] GCC should emit LOCK BTS for simple bit-test-and-set operations with std::atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566 H.J. Lu changed: What|Removed |Added Attachment #51559|0 |1 is obsolete|| --- Comment #27 from H.J. Lu --- Created attachment 51580 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51580&action=edit The new v4 patch Changes in v4: 1. Bypass redundant check when inputs have been transformed to the equivalent canonical form with valid bit operation.
[Bug middle-end/102669] [12 Regression] FAIL: gnat.dg/unroll1.adb scan-rtl-dump-times loop2_unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102669 H.J. Lu changed: What|Removed |Added CC||crazylht at gmail dot com Ever confirmed|0 |1 Last reconfirmed||2021-10-10 Status|UNCONFIRMED |NEW --- Comment #1 from H.J. Lu --- It is likely caused by r12-4240.
[Bug c++/102678] New: GCC fails to compile immediately invoked lambda inside fold expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102678
Bug ID: 102678
Summary: GCC fails to compile immediately invoked lambda inside
fold expression
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: michael.gerhold at web dot de
Target Milestone: ---
The following code
#include
#include
#include
template
void printAlternatives([[maybe_unused]] const std::variant& variant)
{
([&]() {
// holds_alternative(variant); // <- enable to make it compile
T element{};
std::cout << element << "\n";
}(), ...);
}
int main() {
std::variant variant;
printAlternatives(variant);
}
does not compile and gives the following error message:
error: operand of fold expression has no unexpanded parameter packs
But the code does compile both on MSVC and Clang.
Live example on compiler explorer: https://godbolt.org/z/zEqW4njW3
[Bug c++/102678] GCC fails to compile immediately invoked lambda inside fold expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102678 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 100035. *** This bug has been marked as a duplicate of bug 100035 ***
[Bug c++/100035] Parameter packs not expanded with local variable in lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100035 Andrew Pinski changed: What|Removed |Added CC||michael.gerhold at web dot de --- Comment #1 from Andrew Pinski --- *** Bug 102678 has been marked as a duplicate of this bug. ***
[Bug c++/100035] Parameter packs not expanded with local variable in lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100035 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-10-10 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=92911 --- Comment #2 from Andrew Pinski --- Confirmed, very similar to PR 92911.
[Bug c++/92910] Valid lambda inside variadic template does not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92910 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |8.0
[Bug c++/92911] Valid lambda inside variadic template does not compile (2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92911 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection --- Comment #2 from Andrew Pinski --- Seems fixed in GCC 10+ and GCC 9.4.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #18 from Óscar Fuentes --- Adding --enable-frame-pointer makes no difference. No change either adding --enable-large-address-aware --with-fpmath=sse --disable-sjlj-exceptions --enable-frame-pointer --disable-libada --enable-libstdcxx Another data point: for the test mentioned on Comment 16, if I replace libstdc++.dll with the same file from gcc 10, the test works.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #19 from Óscar Fuentes --- When I say that --enable-frame-pointer makes no difference, I'm talking about the build failure that prompted this bug report. The build still fails with /C/_/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/xgcc -B/C/_/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/ -B/mingw32/i686-w64-mingw32/bin/ -L/mingw32/i686-w64-mingw32/lib -L/mingw32/lib -isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/include -B/mingw32/i686-w64-mingw32/bin/ -B/mingw32/i686-w64-mingw32/lib/ -isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/i686-w64-mingw32/sys-include -fno-checking -c -g -O2 -D__USE_MINGW_ACCESS -Wno-pedantic-ms-format -fno-checking -gtoggle -gnatpg -W -Wall -g -O1 -fno-inline \ -nostdinc -I- -I. -Iada/generated -Iada -Iada/gcc-interface -I../../gcc-11.2.0/gcc/ada -I../../gcc-11.2.0/gcc/ada/gcc-interface -Iada/libgnat -I../../gcc-11.2.0/gcc/ada/libgnat ../../gcc-11.2.0/gcc/ada/libgnat/a-except.adb -o ada/libgnat/a-except.o make[3]: *** [../../gcc-11.2.0/gcc/ada/gcc-interface/Make-lang.in:1052: ada/libgnat/a-except.o] Error 1
[Bug tree-optimization/102679] New: Failure to optimize out 64-bit multiplication to 32-bit multiplication when possible in circumstances involving modifying a 64-bit variable that gets converted to 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102679
Bug ID: 102679
Summary: Failure to optimize out 64-bit multiplication to
32-bit multiplication when possible in circumstances
involving modifying a 64-bit variable that gets
converted to 32-bit
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
#include
int32_t mac(int32_t *b, int64_t sqr)
{
sqr += (int64_t)*b * *b;
return sqr;
}
This can be optimized to remove the `(int64_t)` cast. This optimization is done
by LLVM, but not by GCC.
[Bug tree-optimization/102679] Failure to optimize out 64-bit multiplication to 32-bit multiplication when possible in circumstances involving modifying a 64-bit variable that gets converted to 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102679
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
If you have everything in one stmt, gcc handles that too, see
int foo (int *b, long long sqr)
{
sqr += (long long)*b * *b;
return sqr;
}
int bar (int *b, long long sqr)
{
return sqr + (long long)*b * *b;
}
The reason why it isn't done in foo too is that we don't have a type demotion
pass but do that on GENERIC only in the FEs. But the type demotion pass would
then need to be accompanied by a type promotion pass that would promote for
vectorization and expansion purposes when promotions are beneficial.
And, the demotions (whether the ones we do currently in the FE or those that
would be done in the type demotion pass) have some drawbacks too, in particular
e.g. that for signed integer arithmetics the demoted arithmetic needs to be
done in unsigned type / wrapping behavior.
I think we have some dups of this, don't remember the bug numbers though.
[Bug c++/102680] New: lambda-expression in template-argument plus templateed using leads to further using-directive being ignored within template scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102680 Bug ID: 102680 Summary: lambda-expression in template-argument plus templateed using leads to further using-directive being ignored within template scope Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hq.ks at web dot de Target Milestone: --- Created attachment 51581 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51581&action=edit minimalist reproducer Take: 0) a class template with two arguments 1) a templated using-directive containing a lambda-expression as a template parameter to (0) 2) a using declaration within another template scope, which depends on template parameters and makes use of (1) 3) any use of the type alias defined by (2) With GCC 9.4.0, from my observation, the behavior is identical to the using directive (2) not being there at all: it will complain about the alias not naming a type, and if a conflicting definition of the same type is added, it will accept it. (It will parse the RHS of (2) for errors, though.) -Wall -Wextra does not turn up any warnings. Generally, I would expect exactly one of the following to happen: a) (2) gives a compiler error b) Below (2), and in its scope, the alias is usable as a type name. I am not a C++ language lawyer, so I can't really vouch that my reproducer is in fact valid C++20, but even if it is not, the principle of least surprise would imply raising an error at (2). Cheers, Philipp > g++ --version # compiled from tarball g++ (GCC) 9.4.0 > uname -a Linux hostname 4.9.0-15-amd64 #1 SMP Debian 4.9.258-1 (2021-03-08) x86_64 GNU/Linux
[Bug fortran/102521] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102521 --- Comment #6 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:74ccca380cde5e79e082d39214b306a90ded0344 commit r12-4278-g74ccca380cde5e79e082d39214b306a90ded0344 Author: Harald Anlauf Date: Sun Oct 10 20:11:43 2021 +0200 Fortran: handle initialization of derived type parameter arrays from scalar gcc/fortran/ChangeLog: PR fortran/99348 PR fortran/102521 * decl.c (add_init_expr_to_sym): Extend initialization of parameter arrays from scalars to handle derived types. gcc/testsuite/ChangeLog: PR fortran/99348 PR fortran/102521 * gfortran.dg/parameter_array_init_8.f90: New test.
[Bug fortran/99348] ICE in resolve_structure_cons, at fortran/resolve.c:1286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99348 --- Comment #5 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:74ccca380cde5e79e082d39214b306a90ded0344 commit r12-4278-g74ccca380cde5e79e082d39214b306a90ded0344 Author: Harald Anlauf Date: Sun Oct 10 20:11:43 2021 +0200 Fortran: handle initialization of derived type parameter arrays from scalar gcc/fortran/ChangeLog: PR fortran/99348 PR fortran/102521 * decl.c (add_init_expr_to_sym): Extend initialization of parameter arrays from scalars to handle derived types. gcc/testsuite/ChangeLog: PR fortran/99348 PR fortran/102521 * gfortran.dg/parameter_array_init_8.f90: New test.
[Bug fortran/99348] ICE in resolve_structure_cons, at fortran/resolve.c:1286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99348 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug tree-optimization/102679] Failure to optimize out 64-bit multiplication to 32-bit multiplication when possible in circumstances involving modifying a 64-bit variable that gets converted to 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102679 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug c++/102680] lambda-expression in template-argument plus templateed using leads to further using-directive being ignored within template scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102680 --- Comment #1 from hq.ks at web dot de --- https://www.overleaf.com/learn/latex/Matrices On 10/10/2021 20.51, pinskia at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102680 > > Andrew Pinski changed: > > What|Removed |Added > > Keywords||accepts-invalid, > ||rejects-valid >
[Bug c++/102680] lambda-expression in template-argument plus templateed using leads to further using-directive being ignored within template scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102680 --- Comment #2 from hq.ks at web dot de --- Ooops, terribly sorry, wanted to send that to someone else. On 10/10/2021 20.56, Philipp Klenze wrote: > https://www.overleaf.com/learn/latex/Matrices > > On 10/10/2021 20.51, pinskia at gcc dot gnu.org wrote: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102680 >> >> Andrew Pinski changed: >> >> What |Removed |Added >> >> >> Keywords| |accepts-invalid, >> | |rejects-valid >>
[Bug fortran/65141] ISO_10646 constant parameters convert kind when used with substring references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65141 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Status|NEW |RESOLVED Known to work||11.2.1, 12.0 Known to fail||10.3.1, 4.8.5, 4.9.3, ||5.2.0, 6.0 Resolution|--- |DUPLICATE --- Comment #5 from anlauf at gcc dot gnu.org --- The testcase in comment#0 works for me with 12.0 and 11.2.1, the same versions that work for me with PR67972. I also do not see anything unexpected for the other cases. I'll mark this one as a duplicate. Please correct me if I'm wrong and open a new PR with more details. *** This bug has been marked as a duplicate of bug 67972 ***
[Bug fortran/67972] Substrings of arrays of unicode strings are of type DEFAULT rather than ISO_10646
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67972 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||zbeekman at gmail dot com --- Comment #3 from anlauf at gcc dot gnu.org --- *** Bug 65141 has been marked as a duplicate of this bug. ***
[Bug fortran/65144] Problems printing, reading and accessing substrings of ISO_10646 character variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65144 Bug 65144 depends on bug 65141, which changed state. Bug 65141 Summary: ISO_10646 constant parameters convert kind when used with substring references https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65141 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug fortran/88488] ICE in gfc_trans_array_constructor_subarray, at fortran/trans-array.c:1646
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88488 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from anlauf at gcc dot gnu.org --- Fixed at r12-4278. Looks very similar to the PRs fixed there.
[Bug target/102672] [AArch64] Failure to optimize to using stp instead of 2 strs when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102672 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-10-10 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Depends on||82142 --- Comment #3 from Andrew Pinski --- PR 82142 is simular. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82142 [Bug 82142] struct zeroing should use wide stores instead of avoiding overwriting padding
[Bug bootstrap/102675] [12 regression] Bootstrap fails in libsanitizer: 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102675 --- Comment #2 from Gerald Pfeifer --- (In reply to H.J. Lu from comment #1) > That file is FreeBSD specific. Can you use a local patch to force > /usr/include/md5.h, like > > #include_next I tried replacing #include by #include_next ; that did not lead to any change. Using #include "/usr/include/md5.h" restored bootstrap. This confirms my hypothesis that it's GCC's md5.h being picked up that is the issue for this regression.
[Bug bootstrap/102675] [12 regression] Bootstrap fails in libsanitizer: 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102675 --- Comment #3 from H.J. Lu --- (In reply to Gerald Pfeifer from comment #2) > (In reply to H.J. Lu from comment #1) > > That file is FreeBSD specific. Can you use a local patch to force > > /usr/include/md5.h, like > > > > #include_next > > I tried replacing #include by #include_next ; that did > not lead to any change. > > Using #include "/usr/include/md5.h" restored bootstrap. > > This confirms my hypothesis that it's GCC's md5.h being picked up that > is the issue for this regression. Does this file use any GCC specific header files? If not, you can filter out GCC specific -Ixxx from CXX and CXXFLAGS for this file. Or can you prepend -Isystem-headr-directory to CXXFLAGS for this file?
[Bug bootstrap/102675] [12 regression] Bootstrap fails in libsanitizer: 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102675 --- Comment #4 from H.J. Lu --- Another possibility is to add a configure test to locate the system and include it instead of .
[Bug tree-optimization/102622] [9/10 Regression] Wrong code with -O1 and above due to phiopt and signed one bit integer types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102622 Andrew Pinski changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2021-October ||/581259.html Keywords||patch --- Comment #23 from Andrew Pinski --- GCC 10 branch patch submitted: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581259.html Once I approved I will backport to GCC 9.
[Bug tree-optimization/47770] wrong code -O2 -ftree-loop-if-convert-stores -fno-tree-reassoc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47770 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug tree-optimization/51778] ICE during bootstrap when adding -ftree-loop-if-convert-stores to boo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51778 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Target Milestone|--- |7.0 Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- r7-4646 removed -ftree-loop-if-convert-stores option support.
[Bug tree-optimization/46029] -ftree-loop-if-convert-stores causes FAIL: libstdc++-v3/testsuite/ext/pb_ds/example/tree_intervals.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46029 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |7.0 Status|ASSIGNED|RESOLVED Resolution|--- |WONTFIX --- Comment #8 from Andrew Pinski --- r7-4646 removed -ftree-loop-if-convert-stores option support. Note it might have been fixed with r6-5362.
[Bug target/88096] wrong inline AVX512F optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88096 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Since this only report of this, I am going to mark this as a dup of bug 86735 which means it was a binutils bug. *** This bug has been marked as a duplicate of bug 86735 ***
[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735 Andrew Pinski changed: What|Removed |Added CC||thomas at monjalon dot net --- Comment #34 from Andrew Pinski --- *** Bug 88096 has been marked as a duplicate of this bug. ***
[Bug c++/67795] Wrong code generated for conditional expression with cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67795 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=64372 --- Comment #14 from Andrew Pinski --- Looks fixed for GCC 10+. I am suspecting by the patch which fixed PR 64372.
[Bug target/102543] -march=cascadelake performs odd alignment peeling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102543 --- Comment #7 from Hongtao.liu --- SPEC2017 data on CLX seems to ok after changing unaligned sse store cost. fprate: 503.bwaves_rBuildSame 507.cactuBSSN_r -0.22 508.namd_r -0.02 510.parest_r-0.28 511.povray_r-0.20 519.lbm_r BuildSame 521.wrf_r -0.58 526.blender_r -0.30 527.cam4_r 1.07 538.imagick_r0.01 544.nab_r -0.09 549.fotonik3d_r BuildSame 554.roms_r BuildSame intrate: 500.perlbench_r -0.25 502.gcc_r -0.15 505.mcf_r BuildSame 520.omnetpp_r1.03 523.xalancbmk_r -0.13 525.x264_r -0.05 531.deepsjeng_r -0.27 541.leela_r -0.24 548.exchange2_r -0.06 557.xz_r-0.10 999.specrand_ir 2.69
[Bug analyzer/102671] -Wanalyzer-null-dereference false positive when compiling GNU Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102671
--- Comment #1 from eggert at cs dot ucla.edu ---
Created attachment 51582
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51582&action=edit
2nd test case illustrating the bug
I'm attaching a second test case, also taken from GNU Emacs, illustrating the
same bug or at least something similar. Compile it on the same platform with:
gcc -fanalyzer -O2 -S analyzer-null-dereference-2.i
and the output will be the following. The false alarm is incorrect here, too. I
plan to modify Emacs to disable the warnings in the two source-code files that
are generating these false alarms.
analyzer-null-dereference-2.i: In function 'Ftime_convert':
analyzer-null-dereference-2.i:36:13: warning: dereference of NULL 'time'
[CWE-476] [-Wanalyzer-null-dereference]
36 | return ((a->size & (PSEUDOVECTOR_FLAG | PVEC_TYPE_MASK))
|~^~
'Ftime_convert': events 1-4
|
| 72 | Ftime_convert (struct lisp *time)
| | ^
| | |
| | (1) entry to 'Ftime_convert'
| 73 | {
| 74 | decode_time_components (time ? XCDR (time) : time);
| | ~~
| | |
| | (2) following 'false' branch (when 'time' is NULL)...
| | (3) ...to here
| | (4) calling 'decode_time_components' from 'Ftime_convert'
|
+--> 'decode_time_components': events 5-7
|
| 43 | if (! VECTORLIKEP (a))
| | ~
| | |
| | (6) following 'true' branch...
|..
| 65 | decode_time_components (struct lisp *low)
| | ^~
| | |
| | (5) entry to 'decode_time_components'
|..
| 69 | }
| | ~
| | |
| | (7) ...to here
|
<--+
|
'Ftime_convert': events 8-11
|
| 36 | return ((a->size & (PSEUDOVECTOR_FLAG | PVEC_TYPE_MASK))
| |~~~
| | |
| | (10) ...to here
| | (11) dereference of NULL 'time'
|..
| 43 | if (! VECTORLIKEP (a))
| | ~
| | |
| | (9) following 'false' branch...
|..
| 74 | decode_time_components (time ? XCDR (time) : time);
| | ^~
| | |
| | (8) returning to 'Ftime_convert' from 'decode_time_components'
|
[Bug rtl-optimization/45223] RTL PRE GCSE pass hoists trapping insn out of loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45223 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=101373, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=101868 --- Comment #8 from Andrew Pinski --- So I think this has been fully fixed for GCC 12 via r12-2254 (aka PR 101373).
[Bug rtl-optimization/71793] Volatile local variable passed by value is (wrongly?) optimised away, but the containing loop is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71793 Andrew Pinski changed: What|Removed |Added URL|http://stackoverflow.com/qu | |estions/38235112| --- Comment #5 from Andrew Pinski --- http://stackoverflow.com/questions/38235112
[Bug middle-end/102669] [12 Regression] FAIL: gnat.dg/unroll1.adb scan-rtl-dump-times loop2_unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102669 --- Comment #2 from Hongtao.liu --- (In reply to H.J. Lu from comment #1) > It is likely caused by r12-4240. Yes, add -fno-tree-vectorize to it.
[Bug tree-optimization/102681] New: AArch64 bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681 Bug ID: 102681 Summary: AArch64 bootstrap failure Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: fxue at os dot amperecomputing.com Target Milestone: --- This occurs after commit "Loosen loop crossing restriction in threader" (ec0124e0acb556cdf5dba0e8d0ca6b69d9537fcc). In function ‘void mark_stack_region_used(poly_uint64, poly_uint64)’, inlined from ‘rtx_def* emit_library_call_value_1(int, rtx, rtx, libcall_type, machine_mode, int, rtx_mode_t*)’ at ../../gcc/calls.c:4536:29: ../../gcc/calls.c:206:26: error: ‘const_upper’ may be used uninitialized in this function [-Werror=maybe-uninitialized] 206 | stack_usage_map[i] = 1; | ~~~^~~ ../../gcc/calls.c: In function ‘rtx_def* emit_library_call_value_1(int, rtx, rtx, libcall_type, machine_mode, int, rtx_mode_t*)’: ../../gcc/calls.c:202:39: note: ‘const_upper’ was declared here 202 | unsigned HOST_WIDE_INT const_lower, const_upper; | ^~~
[Bug middle-end/102669] [12 Regression] FAIL: gnat.dg/unroll1.adb scan-rtl-dump-times loop2_unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102669 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #3 from Eric Botcazou --- The proposed change is OK.
[Bug middle-end/102669] [12 Regression] FAIL: gnat.dg/unroll1.adb scan-rtl-dump-times loop2_unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102669 --- Comment #4 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:6d97315a4e1acb992580e84065c66d09d1342a77 commit r12-4280-g6d97315a4e1acb992580e84065c66d09d1342a77 Author: liuhongt Date: Mon Oct 11 13:14:13 2021 +0800 Adjust testcase for O2 vectorization enabling. gcc/testsuite/ChangeLog: PR middle-end/102669 * gnat.dg/unroll1.adb: Add -fno-tree-vectorize.
[Bug middle-end/102669] [12 Regression] FAIL: gnat.dg/unroll1.adb scan-rtl-dump-times loop2_unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102669 --- Comment #5 from Hongtao.liu --- Fixed in GCC12.
[Bug middle-end/100316] [11/12 Regression] __clear_cache() does not support NULL-pointer arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100316
--- Comment #3 from CVS Commits ---
The master branch has been updated by Kito Cheng :
https://gcc.gnu.org/g:4e5bc4e4506a7ae7bb88fc925a425652a1da6b2d
commit r12-4281-g4e5bc4e4506a7ae7bb88fc925a425652a1da6b2d
Author: Kito Cheng
Date: Thu Oct 7 16:17:13 2021 +0800
[PR/target 100316] Allow constant address for __builtin___clear_cache.
__builtin___clear_cache was able to accept constant address for the
argument, but it seems no longer accept recently, and it even not
accept constant address which is hold in variable when optimization is
enable:
```
void foo3(){
void *yy = (void*)0x1000;
__builtin___clear_cache(yy, yy);
}
```
So this patch make BEGIN and END accept VOIDmode, like cselib_lookup_mem
did per
Jim Wilson's suggestion.
```
static cselib_val *
cselib_lookup_mem (rtx x, int create)
{
...
addr_mode = GET_MODE (XEXP (x, 0));
if (addr_mode == VOIDmode)
addr_mode = Pmode;
```
Changes v2 -> v3:
- Use gcc_assert rather than error, maybe_emit_call_builtin___clear_cache
is
internal use only, and we already checked the type in other place.
Changes v1 -> v2:
- Check is CONST_INT intead of cehck mode, no new testcase, since
constant value with other type like CONST_DOUBLE will catched by
front-end.
e.g.
Code:
```c
void foo(){
__builtin___clear_cache(1.11, 0);
}
```
Error message:
```
clearcache-double.c: In function 'foo':
clearcache-double.c:2:27: error: incompatible type for argument 1 of
'__builtin___clear_cache'
2 | __builtin___clear_cache(1.11, 0);
| ^~~~
| |
| double
clearcache-double.c:2:27: note: expected 'void *' but argument is of type
'double'
```
gcc/ChangeLog:
PR target/100316
* builtins.c (maybe_emit_call_builtin___clear_cache): Allow
CONST_INT for BEGIN and END, and use gcc_assert rather than
error.
gcc/testsuite/ChangeLog:
PR target/100316
* gcc.c-torture/compile/pr100316.c: New.
[Bug target/102483] Reduction of 4 chars can be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102483
--- Comment #4 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #3)
> Also for reduc_umin/umax/smin/smax_scal_v4qi.
After providing expanders for reduc_umin/umax/smin/smax_scal_v4qi, perfomance
for below functions are a little bit faster than before for -O2 -march=haswell,
-O2 -march=skylake-avx512 and -Ofast -march=skylake-avx512.
char
__attribute__((noipa, optimize("Ofast"),target("sse4.1")))
reduce_add (char* p)
{
char sum = 0;
for (int i = 0; i != 4; i++)
sum += p[i];
return sum;
}
#define MAX(a, b) ((a) > (b) ? (a) : (b))
#define MIN(a, b) ((a) > (b) ? (b) : (a))
unsigned char
__attribute__((noipa))
reduce_umax (unsigned char* p)
{
unsigned char sum = p[0];
for (int i = 0; i != 4; i++)
sum = MAX(sum, p[i]);
return sum;
}
unsigned char
__attribute__((noipa))
reduce_umin (unsigned char* p)
{
unsigned char sum = p[0];
for (int i = 0; i != 4; i++)
sum = MIN(sum, p[i]);
return sum;
}
char
__attribute__((noipa))
reduce_smax (char* p)
{
char sum = p[0];
for (int i = 0; i != 4; i++)
sum = MAX(sum, p[i]);
return sum;
}
char
__attribute__((noipa))
reduce_smin (char* p)
{
char sum = p[0];
for (int i = 0; i != 4; i++)
sum = MIN(sum, p[i]);
return sum;
}
[Bug middle-end/100316] [11/12 Regression] __clear_cache() does not support NULL-pointer arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100316 Kito Cheng changed: What|Removed |Added CC||kito at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |kito at gcc dot gnu.org
[Bug tree-optimization/102681] AArch64 bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681 Aldy Hernandez changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||msebor at gcc dot gnu.org --- Comment #1 from Aldy Hernandez --- This is a limitation in the warning. It's discussed here: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/580860.html
[Bug middle-end/102669] [12 Regression] FAIL: gnat.dg/unroll1.adb scan-rtl-dump-times loop2_unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102669 Eric Botcazou changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Eric Botcazou --- .
