[Bug tree-optimization/67962] Optimization opportunity with conditional swap to two MIN/MAX in phiopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67962 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #3 from Andrew Pinski --- Mine, but for gcc 13. The main problem I see if two cmov might be slower than a branch on x86_64 processors.
[Bug tree-optimization/85509] fails to promote local static to const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85509 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement --- Comment #6 from Andrew Pinski --- For some reason CCP1 is not able to do it but CCP2 can; though CCP2 is after inlining so IPA so nothing is done with respect to inlining and such. CCP1 dump: Visiting statement: # VUSE <.MEM_13> PerformSafely.3_3 = _ZZL7RunTestvE13PerformSafelyD.2380; which is likely CONSTANT Lattice value changed to VARYING. Adding SSA edges to worklist. CCP2 dump: Visiting statement: # VUSE <.MEM_8> # PT = nonlocal escaped null PerformSafely.2_2 = _ZZ7RunTestvE13PerformSafelyD.2379; which is likely CONSTANT Lattice value changed to CONSTANT _Z7PerformIL_ZL9SumSafelyRiRKiEEbS0_S2_D.2380. Adding SSA edges to worklist. marking stmt to be not simulated again
[Bug rtl-optimization/97756] [9/10/11/12 Regression] Inefficient handling of 128-bit arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97756
--- Comment #7 from Hongtao.liu ---
(In reply to Patrick Palka from comment #3)
> Perhaps related to this PR: On x86_64, the following basic wrapper around
> int128 addition
>
> __uint128_t f(__uint128_t x, __uint128_t y) { return x + y; }
>
> gets compiled (/w -O3, -O2 or -Os) to the seemingly suboptimal
>
> movq%rdi, %r9
> movq%rdx, %rax
> movq%rsi, %r8
> movq%rcx, %rdx
> addq%r9, %rax
> adcq%r8, %rdx
> ret
>
> Clang does:
>
> movq%rdi, %rax
> addq%rdx, %rax
> adcq%rcx, %rsi
> movq%rsi, %rdx
> retq
Remove addti3/ashlti3 from i386.md also helps this.
[Bug tree-optimization/36352] missed "inlining" of static untouched variable in linked once function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36352
--- Comment #3 from Andrew Pinski ---
Here is a testcase without templates:
inline int f(void)
{
static int t = 1;
return t;
}
int g(void)
{
return f();
}
[Bug tree-optimization/94836] Failure to optimize condition based on known value of static variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94836 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization
[Bug target/51838] Inefficient add of 128 bit quantity represented as 64 bit tuple to 128 bit integer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51838
--- Comment #2 from Hongtao.liu ---
(In reply to Andrew Pinski from comment #1)
> We do get slightly better now:
> xorl%eax, %eax
> movq%rdi, %r8
> xorl%edi, %edi
> addq%rsi, %rax
> adcq%rdi, %rdx
> addq%rax, (%r8)
> adcq%rdx, 8(%r8)
> ret
>
> Note on arch64 we do get good code:
> ldp x3, x4, [x0]
> addsx3, x3, x1
> adc x4, x4, x2
> stp x3, x4, [x0]
> ret
The interest thing is when i remove addti3 and ashlti3 from i386.md, GCC
generates optimal code.
void foo(__uint128_t *x, unsigned long long y, unsigned long long z)
{
*x += y + ((__uint128_t) z << 64);
}
void foo1(__uint128_t *x, unsigned long long y, unsigned long long z)
{
*x += (__uint128_t) z << 64;
}
void foo2(__uint128_t *x, unsigned long long y, unsigned long long z)
{
*x += (__uint128_t) z << 3;
}
void foo3(__uint128_t *x, __uint128_t *y)
{
*x += *y;
}
diff --git a/origin.s b/test.s
index 08274ba..764241a 100644
--- a/origin.s
+++ b/test.s
@@ -6,13 +6,8 @@
foo:
.LFB0:
.cfi_startproc
- xorl%eax, %eax
- movq%rdi, %r8
- xorl%edi, %edi
- addq%rsi, %rax
- adcq%rdi, %rdx
- addq%rax, (%r8)
- adcq%rdx, 8(%r8)
+ addq%rsi, (%rdi)
+ adcq%rdx, 8(%rdi)
ret
.cfi_endproc
.LFE0:
@@ -23,9 +18,7 @@ foo:
foo1:
.LFB1:
.cfi_startproc
- xorl%eax, %eax
- addq%rax, (%rdi)
- adcq%rdx, 8(%rdi)
+ addq%rdx, 8(%rdi)
ret
.cfi_endproc
.LFE1:
@@ -36,13 +29,13 @@ foo1:
foo2:
.LFB2:
.cfi_startproc
- movq%rdx, %rax
- movq%rdx, %r8
- salq$3, %rax
- xorl%edx, %edx
- shldq $3, %r8, %rdx
- addq%rax, (%rdi)
- adcq%rdx, 8(%rdi)
+ movq(%rdi), %rcx
+ movq%rdx, %rsi
+ shrq$61, %rsi
+ leaq(%rcx,%rdx,8), %rax
+ cmpq%rcx, %rax
+ movq%rax, (%rdi)
+ adcq%rsi, 8(%rdi)
ret
.cfi_endproc
.LFE2:
@@ -53,9 +46,10 @@ foo2:
foo3:
.LFB3:
.cfi_startproc
- movq(%rsi), %rax
+ movq(%rdi), %rax
+ addq(%rsi), %rax
movq8(%rsi), %rdx
- addq%rax, (%rdi)
+ movq%rax, (%rdi)
adcq%rdx, 8(%rdi)
ret
.cfi_endproc
(END)
[Bug tree-optimization/47205] GCC emits optimized out noinline function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47205 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization --- Comment #4 from Andrew Pinski --- So after the final IPA pass we never update the cgraph again and prune out unused functions. PR 94818 is another example, there might be a few others.
[Bug lto/48200] Implement function attribute for symbol versioning (.symver)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 Andrew Pinski changed: What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|FIXED |--- --- Comment #47 from Andrew Pinski --- (In reply to Mark Wielaard from comment #45) > Note that the hack in comment 43 doesn't really work with elfutils since the > .symver attribute doesn't work exactly like the assembly construct with @@@. > The @@@ symver variant see > https://sourceware.org/binutils/docs/as/Symver.html > > The third usage of the .symver directive is: > > .symver name, name2@@@nodename > > When name is not defined within the file being assembled, it is treated as > name2@nodename. When name is defined within the file being assembled, the > symbol name, name, will be changed to name2@@nodename. > > Which means it is renamed, so that it doesn't clash when used in a version > map file. Reopen for this part of the discussion since I misunderstood it at first.
[Bug lto/48200] Implement function attribute for symbol versioning (.symver)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #46 from Andrew Pinski --- LTO was fixed at r10-5568. I think we can close this as fixed for GCC 10.
[Bug c/100789] [9/10/11/12 Regression] ICE with __transaction_relaxed and left shit signed overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100789 Andrew Pinski changed: What|Removed |Added Summary|[9/10/11/12 Regression] |[9/10/11/12 Regression] ICE |ICE: in gimplify_expr, at |with __transaction_relaxed |gimplify.c:14750|and left shit signed ||overflow --- Comment #4 from Andrew Pinski --- Most likely due to this part of the patch from c-typeck.c: + else if (TREE_CODE (op0) == INTEGER_CST + && maybe_warn_shift_overflow (location, op0, op1) + && flag_isoc99) + int_const = false;
[Bug c/100789] [9/10/11/12 Regression] ICE: in gimplify_expr, at gimplify.c:14750
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100789 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.5 Summary|ICE: in gimplify_expr, at |[9/10/11/12 Regression] |gimplify.c:14750|ICE: in gimplify_expr, at ||gimplify.c:14750 Keywords||ice-on-valid-code --- Comment #3 from Andrew Pinski --- The code is valid if you use -fgnu-tm and it works with the C++ front-end too.
[Bug target/57636] cr16: ICE while building libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57636 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.9.2 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Andrew Pinski --- (In reply to Yaakov Selkowitz from comment #6) > This is working in 4.9.2, so it seems that indeed fixed it. So closing.
[Bug tree-optimization/102087] [12 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in determine_exit_conditions, at tree-ssa-loop-manip.c:1049 since r12-3136-g3673dcf6d6baeb67
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102087
--- Comment #10 from Jiu Fu Guo ---
Drafted a patch:
diff --git a/gcc/tree-ssa-loop-niter.c b/gcc/tree-ssa-loop-niter.c
index 7af92d1c893..5c77c8b7d51 100644
--- a/gcc/tree-ssa-loop-niter.c
+++ b/gcc/tree-ssa-loop-niter.c
@@ -1482,7 +1482,7 @@ number_of_iterations_until_wrap (class loop *, tree type,
affine_iv *iv0,
affine_iv *iv1, class tree_niter_desc *niter)
{
tree niter_type = unsigned_type_for (type);
- tree step, num, assumptions, may_be_zero;
+ tree step, num, assumptions, may_be_zero, span;
wide_int high, low, max, min;
may_be_zero = fold_build2 (LE_EXPR, boolean_type_node, iv1->base,
iv0->base);
@@ -1513,6 +1513,8 @@ number_of_iterations_until_wrap (class loop *, tree type,
affine_iv *iv0,
low = wi::to_wide (iv0->base);
else
low = min;
+
+ niter->control = *iv1;
}
/* {base, -C} < n. */
else if (tree_int_cst_sign_bit (iv0->step) && integer_zerop (iv1->step))
@@ -1533,6 +1535,8 @@ number_of_iterations_until_wrap (class loop *, tree type,
affine_iv *iv0,
high = wi::to_wide (iv1->base);
else
high = max;
+
+ niter->control = *iv0;
}
else
return false;
@@ -1556,6 +1560,14 @@ number_of_iterations_until_wrap (class loop *, tree
type, affine_iv *iv0,
niter->assumptions, assumptions);
niter->control.no_overflow = false;
+ niter->control.base = fold_build2 (MINUS_EXPR, niter_type,
+niter->control.base, niter->control.step);
+ span = fold_build2 (MULT_EXPR, niter_type, niter->niter,
+ fold_convert (niter_type, niter->control.step));
+ niter->bound = fold_build2 (PLUS_EXPR, niter_type, span,
+ fold_convert (niter_type, niter->control.base));
+ niter->bound = fold_convert (type, niter->bound);
+ niter->cmp = NE_EXPR;
return true;
}
This patch supports the case even the 'bound' is not a const.
[Bug testsuite/60192] Test case gcc.dg/tree-ssa/sra-12.c fails on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60192 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |6.0 Component|middle-end |testsuite --- Comment #3 from Andrew Pinski --- Fixed by r6-4105.
[Bug c++/60318] Documentation bug: C++ Misunderstandings: Implicit Copy-Assignment for Virtual Bases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60318 Andrew Pinski changed: What|Removed |Added URL|http://gcc.gnu.org/onlinedo | |cs/gcc/Copy-Assignment.html | Keywords||documentation --- Comment #1 from Andrew Pinski --- http://gcc.gnu.org/onlinedocs/gcc/Copy-Assignment.html
[Bug c++/102123] Internal Compiler Error occurs during template deduction in use with templates as template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102123
--- Comment #1 from Andrew Pinski ---
template typename Template, typename... Args>
struct _dummy_forwarder {
using type = Template;
};
template typename Template, typename... Args>
using dummy_forwarder = typename _dummy_forwarder::type;
template
struct Test {
template using _dummy = U;
using Element = dummy_forwarder<_dummy, T>;
Element _elem;
constexpr Test(const Element elem) : _elem(elem) { }
};
template
Test(T) -> Test;
consteval void test() {
const auto t = Test(1);
}
[Bug target/56986] config/epiphany/epiphany.opt:108: "floatig"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56986 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-08-30 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/102123] New: Internal Compiler Error occurs during template deduction in use with templates as template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102123 Bug ID: 102123 Summary: Internal Compiler Error occurs during template deduction in use with templates as template parameters Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: friedkeenan at protonmail dot com Target Milestone: --- Minimal example: https://godbolt.org/z/P86MY1ccz Compiles fine with clang. Compiles with gcc if you specify `Test`, though the deduction guide should make them equivalent. Possibly related to Bug 93425
[Bug fortran/56985] gcc/fortran/resolve.c:920: "'%s' in cannot appear in COMMON ..."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56985
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-08-30
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
if (UNLIMITED_POLY (csym))
gfc_error_now ("%qs in cannot appear in COMMON at %L "
"[F2008:C5100]", csym->name, >declared_at);
Should most likely be:
if (UNLIMITED_POLY (csym))
gfc_error_now ("Variable %qs in cannot appear in COMMON at %L "
"[F2008:C5100]", csym->name, >declared_at);
[Bug go/47726] language go can not build for mingw target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47726 Andrew Pinski changed: What|Removed |Added Keywords||build Severity|critical|normal
[Bug bootstrap/39572] x86_64-*-openbsd* is not supported yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39572 Andrew Pinski changed: What|Removed |Added CC||kgardas at objectsecurity dot com --- Comment #5 from Andrew Pinski --- *** Bug 27396 has been marked as a duplicate of this bug. ***
[Bug target/27396] It seems that x86_64-unknown-openbsd3.9 is completely unsupported.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27396 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Andrew Pinski --- Dup of bug 39572. *** This bug has been marked as a duplicate of bug 39572 ***
[Bug testsuite/102122] contrib/compare_tests reports different result with identical sum input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102122 --- Comment #1 from qingzhe huang --- I can see now this is maybe a testcase "gcc.dg/Wvla-parameter-2.c" issue: Do we expect XFAIL and PASS happen at the same time? For example, the input can be simplified as following: XFAIL: gcc.dg/Wvla-parameter-2.c pr? (test for warnings, line 40) PASS: gcc.dg/Wvla-parameter-2.c pr? (test for warnings, line 40) I guess compare_tests doesn't expect such case can occur, right?
[Bug target/52838] [x32] missed optimization for pointer return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52838 Andrew Pinski changed: What|Removed |Added Component|rtl-optimization|target Target||x86_64 Severity|normal |enhancement Keywords||missed-optimization
[Bug target/52848] [x32] *load_tp_x32 in i386.md isn't necessary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52848 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization --- Comment #1 from Andrew Pinski --- I think this was fixed with r8-2518.
[Bug testsuite/102122] New: contrib/compare_tests reports different result with identical sum input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102122 Bug ID: 102122 Summary: contrib/compare_tests reports different result with identical sum input Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: nickhuang99 at hotmail dot com Target Milestone: --- Created attachment 51373 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51373=edit identical sum file if I compare two identical sum input, compare_tests reports: Tests that now fail, but worked before (4 tests): : gcc.dg/Wvla-parameter-2.c pr? (test for warnings, line 40) : gcc.dg/Wvla-parameter-2.c pr? (test for warnings, line 42) : gcc.dg/Wvla-parameter-2.c pr? (test for warnings, line 44) : gcc.dg/Wvla-parameter-2.c pr? (test for warnings, line 46) Tests that now work, but didn't before (4 tests): : gcc.dg/Wvla-parameter-2.c pr? (test for warnings, line 40) : gcc.dg/Wvla-parameter-2.c pr? (test for warnings, line 42) : gcc.dg/Wvla-parameter-2.c pr? (test for warnings, line 44) : gcc.dg/Wvla-parameter-2.c pr? (test for warnings, line 46) What I suspect is the "XFAIL:" part confuses report.
[Bug testsuite/49175] vect/pr48172.c execution failure for ARM GNU/Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49175 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |4.7.0 Resolution|--- |FIXED --- Comment #4 from Andrew Pinski --- Fixed by r0-108958 . The bug was only there for a few weeks and was fixed by the time this bug report was filed even :). The problem was "dg-do run" overode what vect.exp figured out. https://gcc.gnu.org/pipermail/gcc-patches/2011-May/313648.html
[Bug target/60062] [4.7 Regression] wrong code (for code with the optimize attribute) at -O1 and above on x86_64-linux-gnu in 32-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60062 Andrew Pinski changed: What|Removed |Added CC||vas.gurevich at gmail dot com --- Comment #13 from Andrew Pinski --- *** Bug 47457 has been marked as a duplicate of this bug. ***
[Bug target/47457] g++ calls without optimisation incorrectly from explicitly optimised code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47457 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Keywords||wrong-code Status|NEW |RESOLVED --- Comment #7 from Andrew Pinski --- Dup of bug 60062 which was fixed for GCC 4.8.3. *** This bug has been marked as a duplicate of bug 60062 ***
[Bug tree-optimization/47004] missed optimization in length comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47004 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |5.0 Keywords||missed-optimization Known to work||5.1.0 Status|NEW |RESOLVED Known to fail||4.9.4 --- Comment #3 from Andrew Pinski --- Fixed for GCC 5 by r5-3799. We get a VRP range now of: _4: [0, +INF(OVF)] For: if (f_2(D) <= l_3(D)) goto ; else goto ; : _4 = l_3(D) - f_2(D); Which is exactly as we had expected.
[Bug middle-end/40589] efficiency problem with V2HI add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40589
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
Target Milestone|--- |4.9.1
--- Comment #2 from Andrew Pinski ---
Fixed for GCC 5 by r5-1564 and backported to GCC 4.9.1.
The code now looks like:
/* For very wide vectors, try using a smaller vector mode. */
tree compute_type = type;
if (op
&& (!VECTOR_MODE_P (TYPE_MODE (type))
|| optab_handler (op, TYPE_MODE (type)) == CODE_FOR_nothing))
{
Which solved this exact issue:
N=4 V2HI
N=8 DImode
N=16 TImode
N=32 BLKmode
N=64 BLKmode
[Bug middle-end/24929] long long shift/mask operations should be better optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24929 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.3.0 Resolution|--- |FIXED Status|NEW |RESOLVED Keywords||missed-optimization --- Comment #8 from Andrew Pinski --- Fixed a long time ago.
[Bug tree-optimization/39249] FAIL: g++.dg/ipa/iinline-1.C scan-ipa-dump inline "String::funcOne[^\n]*inline copy in int main"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39249 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Known to work||4.5.4 --- Comment #3 from Andrew Pinski --- So the reason why it was failing on arm was because on arm, the constructors return this. But I don't know what change fixed it for 4.5+.
[Bug middle-end/36282] [4.7 Regression] Spurious warning "asm declaration ignored due to conflict with previous rename"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36282 Andrew Pinski changed: What|Removed |Added CC||Petr.Salinger at seznam dot cz --- Comment #14 from Andrew Pinski --- *** Bug 37266 has been marked as a duplicate of this bug. ***
[Bug c/37266] extra #pragma weak breaks function aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37266 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 36282 which was fixed in GCC 4.8.3 and GCC 4.9+. *** This bug has been marked as a duplicate of bug 36282 ***
[Bug preprocessor/36887] Please report #pragma GCC poison" location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36887 --- Comment #3 from Andrew Pinski --- Simplified testcase: #pragma GCC poison a int a; GCC outputs: :2:5: error: attempt to use poisoned "a" 2 | int a; | ^ But not the location of the #pragma which would be useful to debug why it was poisoned.
[Bug target/86209] Peephole does not happen because the type of zero/sign extended operands is not the same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209 --- Comment #15 from Andrew Pinski --- Hmm, I wonder why expand is generating subreg in place for the add in one case and not the other.
[Bug target/82533] inefficient code generation for copy loop on falkor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82533 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Andrew Pinski --- Falkor is no longer a product so closing as won't fix.
[Bug target/82260] [x86] Unnecessary use of 8-bit registers with -Os. slightly slower and larger code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82260 Andrew Pinski changed: What|Removed |Added Known to fail||7.5.0 Target Milestone|--- |8.0 Status|ASSIGNED|RESOLVED Known to work||8.1.0 Resolution|--- |FIXED --- Comment #8 from Andrew Pinski --- Fixed.
[Bug tree-optimization/102121] switch conversion to load table should do integer compression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102121 --- Comment #1 from Andrew Pinski --- float compression is another one that should be done but I am less worried about that.
[Bug tree-optimization/102121] New: switch conversion to load table should do integer compression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102121
Bug ID: 102121
Summary: switch conversion to load table should do integer
compression
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
int f(int a)
{
switch (a)
{
case 0:
return 100;
case 1:
return 200;
case 3:
return 250;
case 4:
return 0;
case 5:
return 7;
case 6:
return 3;
}
return 0;
}
int f1(int a)
{
unsigned char t = 0;
switch (a)
{
case 0:
t=100;
break;
case 1:
t = 200u;
break;
case 3:
t = 250u;
break;
case 4:
t = 0;
break;
case 5:
t = 7;
break;
case 6:
t = 3;
break;
}
asm("":"+r"(t));
return t;
}
These two functions should have the same assembly and the load table should be
using byte loads for both.
[Bug fortran/100662] intrinsic::ieee_arithmetic fails on aarch, powerpc architectures on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662 --- Comment #15 from Andreas Tobler --- Regarding comment #10, Steve is right with his guess, configure doesn't find the fenv functionalities needed. The reason is pretty simple, for aarch64 and powerpc, they are not public. A quick trial showed that if they are visible, then gfortran is 'happy' and nearly all ieee testcases pass. I did not investigate the failing parts. The big issue is, how can we make them available to libm. This is an OS issue and not a gcc issue. The only thing I'm confused in gcc land, as Steve as well, why is the file named fpu-glibc and not fpu-fenv? Regarding the OS issue, it might take a while to (re)solve this.
[Bug target/88571] AVX512: when calculating logical expression with all values in kN registers, do not use GPRs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88571 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Target Milestone|--- |11.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Andrew Pinski --- Fixed by r11-2796 and r11-2795
[Bug tree-optimization/68131] missed optimization and warning for broken overflow check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68131 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |8.0 Known to work||8.1.0 Resolution|--- |FIXED Status|NEW |RESOLVED Known to fail||7.5.0 --- Comment #4 from Andrew Pinski --- Fixed by r8-3771. There is no overflow here as unsigned short gets prompted to int and such.
[Bug target/87976] [i386] Sub-optimal code generation for _mm256_set1_epi64()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87976 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED Target Milestone|--- |9.0 --- Comment #6 from Andrew Pinski --- All fixed for GCC 9. g: .LFB5273: .cfi_startproc vmovq xmm1, rdi vpbroadcastqymm0, xmm1 jmp f .cfi_endproc .LFE5273: .size g, .-g .ident "GCC: (Compiler-Explorer-Build) 9.1.0"
[Bug ipa/102118] [12 Regression] ice in merge, at ipa-modref-tree.h:203
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102118 Andrew Pinski changed: What|Removed |Added CC||marxin at gcc dot gnu.org Target Milestone|--- |12.0 Keywords||ice-on-valid-code Summary|ice in merge, at|[12 Regression] ice in |ipa-modref-tree.h:203 |merge, at ||ipa-modref-tree.h:203 Component|c |ipa
[Bug c++/102120] expected tree that contains 'decl common' structure, have 'identifier_node' in dump_aggr_type, at cp/error.c:786
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102120 --- Comment #1 from Andrew Pinski --- It is ICEing while printing out the error message :).
[Bug c++/102120] New: expected tree that contains 'decl common' structure, have 'identifier_node' in dump_aggr_type, at cp/error.c:786
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102120
Bug ID: 102120
Summary: expected tree that contains 'decl common' structure,
have 'identifier_node' in dump_aggr_type, at
cp/error.c:786
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
Input:
union U {
int value;
constexpr ~U() noexcept { }
};
constexpr int z() {
U* array = new U[5];
int result = array[3].value;
delete[] array;
return result;
}
constexpr int zz = z();
Compile with -std=c++20.
Expected output (I get this if I remove the union's dtor, or change the array
to a single object):
:13:21: in 'constexpr' expansion of 'z()'
:13:22: error: the content of uninitialized storage is not usable in a
constant expression
13 | constexpr int zz = z();
| ^
:7:23: note: allocated here
7 | U* array = new U[5];
| ^
Actual output on GCC 11.2:
'
:13: confused by earlier errors, bailing out
Yes, those two lines are the entirety of its output.
GCC trunk is slightly better, but still asks for a bug report:
'
:13:21: in 'constexpr' expansion of 'z()'
tree check: expected tree that contains 'decl common' structure, have
'identifier_node' in dump_aggr_type, at cp/error.c:786
13 | constexpr int zz = z();
| ^
0x1f30289 internal_error(char const*, ...)
???:0
0x6bb645 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
???:0
0x1f4c781 pp_format(pretty_printer*, text_info*)
???:0
0x1f2eeb5 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
???:0
0x1f2fde9 error(char const*, ...)
???:0
0xae3d0a store_init_value(tree_node*, tree_node*, vec**, int)
???:0
0x89b0c9 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
???:0
0x9d09a5 c_parse_file()
???:0
0xb55af2 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug libstdc++/102026] The comment on the instantiation description of __variant::__gen_vtable_impl can be updated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102026 --- Comment #3 from 康桓瑋 --- It seems that all lambdas used in can remove the mutable keyword since there are no members that need to be "mutable" inside the lambda.
[Bug d/102094] d: ICE in gimple_register_canonical_type_1, at lto/lto-common.c:430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102094 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Iain Buclaw --- Fix committed.
[Bug d/102094] d: ICE in gimple_register_canonical_type_1, at lto/lto-common.c:430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102094 --- Comment #2 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:07984707be4eb9aea55dafbbc796790b8b8ac700 commit r12-3206-g07984707be4eb9aea55dafbbc796790b8b8ac700 Author: Iain Buclaw Date: Sat Aug 28 16:57:03 2021 +0200 d: ICE in gimple_register_canonical_type_1, at lto/lto-common.c:430 (PR102094) User defined types have the TYPE_CXX_ODR_P flag set, but closure frames did not. This mismatch led to an ICE in the conflict detection for ODR and interoperable non-ODR types. As a given closure frame is tied explicitly to a function, it already conforms to ODR. PR d/102094 gcc/d/ChangeLog: * d-codegen.cc (build_frame_type): Set TYPE_CXX_ODR_P. gcc/testsuite/ChangeLog: * gdc.dg/lto/pr102094_0.d: New test.
[Bug c++/102119] New: ICE when accessing an uninitialised variable in a dynamic array of unions in a constexpr context.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102119
Bug ID: 102119
Summary: ICE when accessing an uninitialised variable in a
dynamic array of unions in a constexpr context.
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc_report_187375 at mailfence dot com
Target Milestone: ---
Source code:
==
union U {
int value;
constexpr U() noexcept { }
constexpr ~U() noexcept { }
};
constexpr int z() {
U* array = new U[5];
int result = array[3].value;
delete[] array;
return result;
}
constexpr int zz = z();
int main() { }
==
Compilation output (compiled with: gcc -v -save-temps -std=c++20):
==
Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/gcc-11.2.0/bin/g++
Target: x86_64-linux-gnu
Configured with: ../gcc-11.2.0/configure
--prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu
--enable-languages=c,c++,fortran,ada,go,d --enable-ld=yes --enable-gold=yes
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id
--enable-lto --enable-plugins --enable-threads=posix
--with-pkgversion=Compiler-Explorer-Build-gcc--binutils-2.36.1
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.2.0 (Compiler-Explorer-Build-gcc--binutils-2.36.1)
COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' '/app/output.s'
'-masm=intel' '-S' '-v' '-save-temps' '-std=c++20' '-shared-libgcc'
'-mtune=generic' '-march=x86-64' '-dumpdir' '/app/'
/opt/compiler-explorer/gcc-11.2.0/bin/../libexec/gcc/x86_64-linux-gnu/11.2.0/cc1plus
-E -quiet -v -imultiarch x86_64-linux-gnu -iprefix
/opt/compiler-explorer/gcc-11.2.0/bin/../lib/gcc/x86_64-linux-gnu/11.2.0/
-D_GNU_SOURCE -masm=intel -mtune=generic -march=x86-64 -std=c++20
-fdiagnostics-color=always -g -fworking-directory -fpch-preprocess -o
/app/output.ii
ignoring nonexistent directory
"/opt/compiler-explorer/gcc-11.2.0/bin/../lib/gcc/x86_64-linux-gnu/11.2.0/../../../../x86_64-linux-gnu/include"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-11.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/11.2.0/../../../../include/c++/11.2.0"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-11.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/11.2.0/../../../../include/c++/11.2.0/x86_64-linux-gnu"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-11.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/11.2.0/../../../../include/c++/11.2.0/backward"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-11.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/11.2.0/include"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-11.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/11.2.0/include-fixed"
ignoring nonexistent directory
"/opt/compiler-explorer/gcc-11.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/11.2.0/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/opt/compiler-explorer/gcc-11.2.0/bin/../lib/gcc/x86_64-linux-gnu/11.2.0/../../../../include/c++/11.2.0
/opt/compiler-explorer/gcc-11.2.0/bin/../lib/gcc/x86_64-linux-gnu/11.2.0/../../../../include/c++/11.2.0/x86_64-linux-gnu
/opt/compiler-explorer/gcc-11.2.0/bin/../lib/gcc/x86_64-linux-gnu/11.2.0/../../../../include/c++/11.2.0/backward
/opt/compiler-explorer/gcc-11.2.0/bin/../lib/gcc/x86_64-linux-gnu/11.2.0/include
/opt/compiler-explorer/gcc-11.2.0/bin/../lib/gcc/x86_64-linux-gnu/11.2.0/include-fixed
/usr/local/include
/opt/compiler-explorer/gcc-11.2.0/bin/../lib/gcc/../../include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' '/app/output.s'
'-masm=intel' '-S' '-v' '-save-temps' '-std=c++20' '-shared-libgcc'
'-mtune=generic' '-march=x86-64' '-dumpdir' '/app/'
/opt/compiler-explorer/gcc-11.2.0/bin/../libexec/gcc/x86_64-linux-gnu/11.2.0/cc1plus
-fpreprocessed /app/output.ii -quiet -dumpdir /app/ -dumpbase output.cpp
-dumpbase-ext .cpp -masm=intel -mtune=generic -march=x86-64 -g -std=c++20
-version -fdiagnostics-color=always -o /app/output.s
GNU C++20 (Compiler-Explorer-Build-gcc--binutils-2.36.1) version 11.2.0
(x86_64-linux-gnu)
compiled by GNU C version 7.5.0, GMP version 6.1.0, MPFR version 3.1.6,
MPC version 1.0.3, isl version isl-0.18-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++20 (Compiler-Explorer-Build-gcc--binutils-2.36.1) version 11.2.0
[Bug c/102118] New: ice in merge, at ipa-modref-tree.h:203
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102118
Bug ID: 102118
Summary: ice in merge, at ipa-modref-tree.h:203
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C code:
typedef struct {
int large_page_addr;
long n_used_entries
} CPUTLBDesc;
typedef struct {
long mask
} CPUTLBDescFast;
typedef struct {
CPUTLBDesc d[8];
CPUTLBDescFast f[]
} CPUTLB;
typedef int RISCVCPU;
CPUTLB *tlb_flush_page_bits_locked___trans_tmp_8,
*tlb_flush_page_bits_locked___trans_tmp_6,
*tlb_flush_page_bits_locked___trans_tmp_4;
void tlb_flush_page_bits_locked(int *env, int midx) {
{
int *__trans_tmp_5 = env;
{
RISCVCPU *arch_cpu = __trans_tmp_5;
tlb_flush_page_bits_locked___trans_tmp_4 = arch_cpu;
}
}
CPUTLBDesc *d = _flush_page_bits_locked___trans_tmp_4->d[midx];
{
int *__trans_tmp_7 = env;
{
RISCVCPU *arch_cpu = __trans_tmp_7;
tlb_flush_page_bits_locked___trans_tmp_6 = arch_cpu;
}
}
if (tlb_flush_page_bits_locked___trans_tmp_6->f[midx].mask)
if (d->large_page_addr) {
int *__trans_tmp_3 = env;
{
{
RISCVCPU *arch_cpu = __trans_tmp_3;
tlb_flush_page_bits_locked___trans_tmp_8 = arch_cpu;
}
tlb_flush_page_bits_locked___trans_tmp_8->d[midx].n_used_entries--;
}
}
}
compiled by recent gcc trunk and compiler flag -O1, does this:
during GIMPLE pass: modref
bug752.c: In function ‘tlb_flush_page_bits_locked’:
bug752.c:43:1: internal compiler error: in merge, at ipa-modref-tree.h:203
43 | }
| ^
0xae7448 modref_access_node::merge(modref_access_node const&, bool)
../../trunk.git/gcc/ipa-modref-tree.h:203
The code was fine at git hash 3ac6b5cff1eca4e1 and broken at hash
e28ac73af20028f8
[Bug middle-end/101996] libatomic: RISC-V 64: Infinite recursion in __atomic_compare_exchange_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101996 Alpine User changed: What|Removed |Added Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED --- Comment #7 from Alpine User --- Sorry for not updating this. Yes, this is indeed a bug caused by the fact that Alpine's RISC-V GCC links against libatomic by default. See https://gitlab.alpinelinux.org/alpine/aports/-/issues/12948 for the downstream discussion. What seems to help is running the libatomic configure script as `gcc_no_link=yes ./configure`. I think this bug report can be closed in the meantime as this is not an upstream GCC bug.
[Bug target/102117] s390: Inefficient code for 64x64=128 signed multiply for <= z13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102117
--- Comment #1 from Jens Seifert ---
Sorry small bug in optimal sequence.
__int128 imul128_opt(long long a, long long b)
{
unsigned __int128 x = (unsigned __int128)(unsigned long long)a;
unsigned __int128 y = (unsigned __int128)(unsigned long long)b;
unsigned long long t1 = (a >> 63) & b;
unsigned long long t2 = (b >> 63) & a;
unsigned __int128 u128 = x * y;
unsigned long long hi = (u128 >> 64) - (t1 + t2);
unsigned long long lo = (unsigned long long)u128;
unsigned __int128 res = hi;
res <<= 64;
res |= lo;
return (__int128)res;
}
_Z11imul128_optxx:
.LFB1:
.cfi_startproc
ldgr%f2,%r12
.cfi_register 12, 17
ldgr%f0,%r13
.cfi_register 13, 16
lgr %r13,%r3
mlgr%r12,%r4
srag%r1,%r3,63
ngr %r1,%r4
srag%r4,%r4,63
ngr %r4,%r3
agr %r4,%r1
sgrk%r4,%r12,%r4
stg %r13,8(%r2)
lgdr%r12,%f2
.cfi_restore 12
lgdr%r13,%f0
.cfi_restore 13
stg %r4,0(%r2)
br %r14
.cfi_endproc
[Bug target/102117] New: s390: Inefficient code for 64x64=128 signed multiply for <= z13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102117
Bug ID: 102117
Summary: s390: Inefficient code for 64x64=128 signed multiply
for <= z13
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.seifert at de dot ibm.com
Target Milestone: ---
__int128 imul128(long long a, long long b)
{
return (__int128)a * (__int128)b;
}
creates sequence with 3 multiplies:
_Z7imul128xx:
.LFB0:
.cfi_startproc
ldgr%f2,%r12
.cfi_register 12, 17
ldgr%f0,%r13
.cfi_register 13, 16
lgr %r13,%r3
mlgr%r12,%r4
srag%r1,%r3,63
msgr%r1,%r4
srag%r4,%r4,63
msgr%r4,%r3
agr %r4,%r1
agr %r12,%r4
stmg%r12,%r13,0(%r2)
lgdr%r13,%f0
.cfi_restore 13
lgdr%r12,%f2
.cfi_restore 12
br %r14
.cfi_endproc
The following sequence only requires 1 multiply:
__int128 imul128_opt(long long a, long long b)
{
unsigned __int128 x = (unsigned __int128)(unsigned long long)a;
unsigned __int128 y = (unsigned __int128)(unsigned long long)b;
unsigned long long t1 = (a >> 63) & a;
unsigned long long t2 = (b >> 63) & b;
unsigned __int128 u128 = x * y;
unsigned long long hi = (u128 >> 64) - (t1 + t2);
unsigned long long lo = (unsigned long long)u128;
unsigned __int128 res = hi;
res <<= 64;
res |= lo;
return (__int128)res;
}
_Z11imul128_optxx:
.LFB1:
.cfi_startproc
ldgr%f2,%r12
.cfi_register 12, 17
ldgr%f0,%r13
.cfi_register 13, 16
lgr %r13,%r3
mlgr%r12,%r4
lgr %r1,%r3
srag%r3,%r3,63
ngr %r3,%r1
srag%r1,%r4,63
ngr %r4,%r1
agr %r3,%r4
sgrk%r3,%r12,%r3
stg %r13,8(%r2)
lgdr%r12,%f2
.cfi_restore 12
lgdr%r13,%f0
.cfi_restore 13
stg %r3,0(%r2)
br %r14
.cfi_endproc
[Bug c++/102116] New: structured binding is returned from a function as rvalue in C++20 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102116
Bug ID: 102116
Summary: structured binding is returned from a function as
rvalue in C++20 mode
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: ---
In the following program:
```
#include
#include
struct A {
A(const int &) { std::cout << "A(const int &) "; }
A(int &&) { std::cout << "A(int &&) "; }
};
A foo() {
auto [y] = std::make_tuple(1);
return y;
}
int main() { foo(); }
```
GCC selects "A(int &&)" constructor starting from C++20 mode, demo:
https://gcc.godbolt.org/z/5q779vE6T
I asked why on stack-overflow:
https://stackoverflow.com/questions/68941451/shall-structured-binding-be-returned-from-a-function-as-rvalue-in-c20
and the answer was that GCC being wrong here.
Could you please confirm it or explain why the behavior of the program changes
in C++20 mode?
[Bug target/93990] [x86] Silly code generation for _addcarry_u32/_addcarry_u64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93990 Andrew Pinski changed: What|Removed |Added Status|REOPENED|NEW Severity|normal |enhancement --- Comment #5 from Andrew Pinski --- _addcarry_u64(0, a, c, ) can definitely be folded into __builtin_uadd_overflowll/.ADD_OVERFLOW without any troubles. The second _addcarry_u64 here since the result is not used can be folded into just an a few adds. That leaves if there case where the first argument is non-zero and the result is used. I think going the route that Jakub mentions is best for this last case.
[Bug tree-optimization/89059] Once we emit switchconf tables, we don't optimize them anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89059 --- Comment #4 from Jakub Jelinek --- It is way too early, but on the other side the inlining decisions want to know if the switch is optimizable in certain way. So one possibility would be to lower as we currently do, but add optimizations to simplify and/or convert to some other form later after IPA. And another would be to just do the analysis phase of switches shortly before inlining and note (either in flags on GIMPLE_SWITCH or in an on-the-side data structure or whatever) what way we'd optimize the switch, take it into account during inlining cost computations and lower for real after IPA only. Though, e.g. if we decide to go with a value table for a switch in an inline function and if in all the inline copies we still decide to use the same value table, it would be nice to share the tables. But, if in each inlined copy VRP has different ranges and we can build different tables, we shouldn't share them... And there is another PR that we should use range info (ranger at this point) in the switch lowering decisions.
[Bug target/80689] 128 bit loads generated for structure copying with gcc 7.1.0 and leads to STLF stalls in avx2 targets.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80689 --- Comment #10 from Andrew Pinski --- Even LLVM does this same thing.
[Bug tree-optimization/101932] Vectorizer failed due to argument types differ for ldexp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101932 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug middle-end/90262] Inline small constant memmoves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90262 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed|2019-04-28 00:00:00 |2021-8-29
[Bug tree-optimization/93326] switch optimisation of multiple jumptables into a lookup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93326 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2020-01-20 00:00:00 |2021-8-29 Severity|normal |enhancement --- Comment #5 from Andrew Pinski --- So for the -fPIC case, we don't want to increase the number of runtime relocations done. The number of runtime locations will happen in the constable load table. I think we don't want to change that. Now for the -fno-PIC case and the second testcase, the splitting of the loop happens too late and we don't run the switch conversion code (we only run it once before (non-early) inlining). There is another bug about us running the switch conversion code too early too.
