https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910
--- Comment #16 from Andreas Schwab ---
This breaks Ada:
/opt/gcc/gcc-20230414/Build/./gcc/xgcc -B/opt/gcc/gcc-20230414/Build/./gcc/
-B/usr/aarch64-suse-linux/bin/ -B/usr/aarch64-suse-linux/lib/ -isystem
/usr/aarch64-suse-linux/include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109509
Bug ID: 109509
Summary: Huge compile time with forced inlining
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
--- Comment #13 from Richard Biener ---
(In reply to Chip Kerchner from comment #12)
> > having always_inline across a deep call stack can exponentially increase
> > compile-time
>
> Do you think it would be worth requesting a feature to reduc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109502
--- Comment #3 from Richard Biener ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > SLP transforms:
> >
> > g.0_1 = g;
> > _2 = g.0_1 == 0;
> > a_7 = (unsigned int) _2;
> > _3 = a_7 % 6;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108947
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:9d1a6119590ef828f9782a7083d03e535bc2f2cf
commit r13-7178-g9d1a6119590ef828f9782a7083d03e535bc2f2cf
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109504
--- Comment #3 from Hongtao.liu ---
>From pr108883, maybe we shouldnot restrict _Float16 under TARGET_SSE2.
Jakub Jelinek 2023-02-22 12:21:24 UTC
Created attachment 54506 [details]
gcc13-pr108883.patch
Untested fix on the compiler side of emit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109040
--- Comment #9 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:9d1a6119590ef828f9782a7083d03e535bc2f2cf
commit r13-7178-g9d1a6119590ef828f9782a7083d03e535bc2f2cf
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108947
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109504
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.3
Summary|Compilation fa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109508
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109508
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #15 from Wilhelm M ---
Just checked actual gcc 13.0.1 without the patch: then no ICE accurs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #16 from Wilhelm M ---
(In reply to Roger Sayle from comment #14)
> My apologies for the delay/issues. My bootstrap and regression testing of
> this patch (on x86_64-pc-linux-gnu) revealed an issue or two (including the
> reported I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109502
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109504
--- Comment #4 from Jakub Jelinek ---
Yeah. Enable all the time and have say the
targetm.invalid_conversion, targetm.invalid_unary_op, targetm.invalid_binary_op
and something in argument/return value passing reject _Float16/__bf16 in
functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109495
--- Comment #7 from Richard Biener ---
Created attachment 54857
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54857&action=edit
patch
I have tested the attached successfully. Can you think of a case where
we'd have a BLKmode target but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109504
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505
--- Comment #2 from Jose Dapena Paz ---
Information collected:
### g++ -v
aarch64-poky-linux-g++ -v
Using built-in specs.
COLLECT_GCC=./home/dape/Development/yocto/meta-chromium/build/tmp/work/x86_64-linux/gcc-cross-aarch64/12.2.0-r0/recipe-sy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505
--- Comment #3 from Jose Dapena Paz ---
Created attachment 54858
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54858&action=edit
evaluate_prg_hwy.ii (compressed with gzip)
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
The fix for PR108910 reportedly breaks bootstrap with Ada enabled
/opt/gcc/gcc-20230414/Build/./gcc/xgcc -B/opt/gcc/gcc-20230414/Build/./gcc/
-B/usr/aarch64-suse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109510
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910
--- Comment #17 from Richard Biener ---
(In reply to Andreas Schwab from comment #16)
> This breaks Ada:
>
> /opt/gcc/gcc-20230414/Build/./gcc/xgcc -B/opt/gcc/gcc-20230414/Build/./gcc/
> -B/usr/aarch64-suse-linux/bin/ -B/usr/aarch6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109510
Richard Biener changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109510
Eric Botcazou changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109510
--- Comment #3 from Richard Biener ---
(In reply to Eric Botcazou from comment #2)
> > Maybe Eric can clarify which type kinds in Ada can have TYPE_USER_ALIGN and
> > _not_ a TYPE_MAIN_VARIANT without.
>
> All of them, TYPE_USER_ALIGN is suppos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109510
--- Comment #4 from Richard Biener ---
(In reply to Richard Biener from comment #3)
> (In reply to Eric Botcazou from comment #2)
> > > Maybe Eric can clarify which type kinds in Ada can have TYPE_USER_ALIGN
> > > and
> > > _not_ a TYPE_MAIN_VA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109510
--- Comment #5 from Jakub Jelinek ---
(In reply to Richard Biener from comment #3)
> (In reply to Eric Botcazou from comment #2)
> > > Maybe Eric can clarify which type kinds in Ada can have TYPE_USER_ALIGN
> > > and
> > > _not_ a TYPE_MAIN_VAR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109502
--- Comment #5 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:bf24f2db2841b97bc5e86bf9294d61eef32f83b3
commit r13-7180-gbf24f2db2841b97bc5e86bf9294d61eef32f83b3
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109502
Richard Biener changed:
What|Removed |Added
Summary|[12/13 Regression] wrong|[12 Regression] wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109359
--- Comment #4 from Richard Biener ---
(In reply to Jakub Jelinek from comment #3)
> I think the fold-const.cc change is right though.
> I wonder if for constant evaluation (constexpr, constinit) we shouldn't
> arrange for those to be evaluated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109511
Bug ID: 109511
Summary: incorrectly rejects set_exponent with constant
negative exponent
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109510
--- Comment #6 from Eric Botcazou ---
> Btw, we're talking about non-aggregate types here.
Right, I agree that this is unexpected for them, let me investigate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109359
--- Comment #5 from Jakub Jelinek ---
Ah, cp/constexpr.cc already uses fold_binary_initializer_loc if
-fconstexpr-fp-except.
That will turn the -frounding-math temporarily off for binary operations.
For this PR guess we need to use fold_init or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109359
--- Comment #6 from Richard Biener ---
output_constant gets called with
{(float) 1.91390279997419406754488591104745864868164062e-3, (float)
6.3053899606217215841752476990222930908203125e-1}
it then eventually does
/* Eli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
--- Comment #16 from chenglulu ---
(In reply to rguent...@suse.de from comment #15)
> On Thu, 13 Apr 2023, xry111 at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
> >
> > --- Comment #14 from Xi Ruoyao ---
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109359
--- Comment #7 from Jakub Jelinek ---
For the safety net I'd compare TYPE_MODE of the SCALAR_FLOAT_TYPE_Ps, that is
what matters for those whether it is a noop conversion or needs actually some
runtime adjustment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109510
--- Comment #7 from Jakub Jelinek ---
In patch form what I wrote above (completely untested):
--- gcc/config/aarch64/aarch64.cc.jj2023-04-14 09:15:08.470312336 +0200
+++ gcc/config/aarch64/aarch64.cc 2023-04-14 12:08:59.785137542 +0200
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104272
--- Comment #6 from CVS Commits ---
The master branch has been updated by Paul Thomas :
https://gcc.gnu.org/g:b0e85485fbf042abccee5c0a9eb499da386c8db3
commit r13-7181-gb0e85485fbf042abccee5c0a9eb499da386c8db3
Author: Paul Thomas
Date: Fri A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
--- Comment #17 from Richard Biener ---
Isn't this the same issue as seen in another bug, most targets defining
TARGET_PROMOTE_PROTOTYPES to hook_bool_const_tree_true but loongarch not?
That will cause those conversions to be missed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
--- Comment #18 from Xi Ruoyao ---
(In reply to Richard Biener from comment #17)
> Isn't this the same issue as seen in another bug, most targets defining
> TARGET_PROMOTE_PROTOTYPES to hook_bool_const_tree_true but loongarch not?
> That will ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109510
--- Comment #8 from rsandifo at gcc dot gnu.org
---
(In reply to Jakub Jelinek from comment #7)
> In patch form what I wrote above (completely untested):
Sorry in advance for the overly verbose comment, but the timeline here was
that:
- PR1084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109510
--- Comment #9 from Eric Botcazou ---
> How do you get at the alignment the type would have when the user didn't
> specify it? That's what the call ABI is supposed to look at.
>
> /* 1 if the alignment for this type was requested by "aligned"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109510
--- Comment #10 from Eric Botcazou ---
Created attachment 54859
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54859&action=edit
Tentative fix
To be tested.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109507
--- Comment #3 from Jonathan Wakely ---
When you created this bug report there was a red banner at the top of the page
that begins by asking you to read https://gcc.gnu.org/bugs/ and that tells you
to try -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
--- Comment #19 from chenglulu ---
(In reply to Xi Ruoyao from comment #18)
> (In reply to Richard Biener from comment #17)
> > Isn't this the same issue as seen in another bug, most targets defining
> > TARGET_PROMOTE_PROTOTYPES to hook_bool_co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
--- Comment #20 from rguenther at suse dot de ---
On Fri, 14 Apr 2023, xry111 at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
>
> --- Comment #18 from Xi Ruoyao ---
> (In reply to Richard Biener from comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109510
--- Comment #11 from Richard Biener ---
It might be possible to re-write the aarch64 assert to be instead
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index f4ef22ce02f..9da46a5e45d 100644
--- a/gcc/config/aarch64/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109510
--- Comment #12 from rsandifo at gcc dot gnu.org
---
(In reply to Eric Botcazou from comment #10)
> Created attachment 54859 [details]
> Tentative fix
>
> To be tested.
Thanks! This works for me locally and gives clean Ada test results.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109511
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
--- Comment #14 from Chip Kerchner ---
Just one more question and then I'll switch to the new bug.
Would it help any if the functions that are "always_inline" be changed from
non-static to static?
Eigen's approach (where this code originally c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109509
--- Comment #1 from Chip Kerchner ---
Just for note: The same code that has heavy use always_inline compiles about
3X faster in LLVM and uses about 2X less memory to compile.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
--- Comment #15 from rguenther at suse dot de ---
On Fri, 14 Apr 2023, chip.kerchner at ibm dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
>
> --- Comment #14 from Chip Kerchner ---
> Just one more question and then I'll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109183
--- Comment #13 from Allan W. Macdonald ---
Ahhh, so, "to get back the old behaviour" (as @ Richard Biener put it), this
seems to work (at least with my project):
%.d: %.c
gcc -MM -MD -dumpbase '' $<
Not obvious in the gcc 11.3.0 manua
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109509
--- Comment #2 from Richard Biener ---
Possible issues specific to GCC that LLVM maybe avoids are:
Another probably more common with C++ code issue would be that we
inline into not optimized callers which means calls that are
almost trivially u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109509
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109512
Bug ID: 109512
Summary: accepts implicit dummy procedure even with "implicit
none (external)"
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109513
Bug ID: 109513
Summary: Missed Dead Code Elimination when using
__builtin_unreachable
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
--- Comment #16 from Richard Biener ---
Just to make the point, for the testcase when compiling with -O -g I see
> grep 'INLINE_ENTRY' t.ii.031t.einline | wc -l
16976
> grep 'INLINE_ENTRY' t.ii.034t.ccp1 | wc -l
15530
> grep 'INLINE_ENTRY' t.i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108086
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109509
--- Comment #4 from Richard Biener ---
when working on another testcase I noticed our inlining itself creates a lot of
garbage - copies can pile up, esp. when not optimizing. The PR79416 testcase
is similar than yours but using asm("nop") and t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109160
--- Comment #5 from Vincent Saulue-Laborde
---
(In reply to Patrick Palka from comment #4)
> (In reply to Patrick Palka from comment #3)
> > Fixed for GCC 12 so far.
>
> GCC 13*
I confirm that gcc trunk works fine from my side.
Thanks for th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109509
--- Comment #5 from Jan Hubicka ---
For a summary
- PR109491 does not seem to be about integration time. most time is RTL PRE.
- PR108086 has 10% spent in integration and seems to be operand scan issue
- PR99785 is hard to judge given that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104272
Paul Thomas changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109183
--- Comment #14 from Andreas Schwab ---
It doesn't make sense to use both -MM and -MD. Either you want to generate
only dependencies, then use -M or -MM (and -MF to redirect to a file). Or you
want to generate dependencies as side effect of co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79416
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65347
Paul Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
Bug 37336 depends on bug 65347, which changed state.
Bug 65347 Summary: [F03] Final subroutine not called for function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65347
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84472
Paul Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
Bug 37336 depends on bug 84472, which changed state.
Bug 84472 Summary: Missing finalization and memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84472
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86754
Bug 86754 depends on bug 84472, which changed state.
Bug 84472 Summary: Missing finalization and memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84472
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91316
Paul Thomas changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
Bug 37336 depends on bug 91316, which changed state.
Bug 91316 Summary: Derived type finalization failing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91316
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108807
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109514
Bug ID: 109514
Summary: [13 regression] -Werror=dangling-pointer false
positive nn fheroes-1.0.3 (lambdas)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494
--- Comment #5 from Patrick Palka ---
(In reply to Patrick Palka from comment #4)
> I can't reproduce the linker warning or bad output with GCC 12.2 or trunk on
> x86_64-pc-linux-gnu:
>
> $ g++ -std=c++20 -fext-numeric-literals Main.ii Test.ii
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109512
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109507
Aran Clauson changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #4 from Aran Clauson
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109514
Jason Merrill changed:
What|Removed |Added
Last reconfirmed||2023-04-14
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109511
--- Comment #2 from anlauf at gcc dot gnu.org ---
It's even worse, as simplification for arguments X below one gives wrong
results:
set_exponent(0.75, 3)
gives 3., while the runtime version correctly prints 6.00
All gfortran versio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137
--- Comment #25 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jan Hubicka
:
https://gcc.gnu.org/g:9075b0f19eece7d5ddf948204507b5dae9d292c4
commit r12-9400-g9075b0f19eece7d5ddf948204507b5dae9d292c4
Author: Jan Hubicka
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103931
--- Comment #16 from Bernhard Reutner-Fischer ---
> Under the assumption that we have a generic "c_ptr" in a module, we know (?)
> that "c_ptr" is not ambiguous.
>
> Is that right?
When we look at gmodule (when compiled when DModule has a com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137
--- Comment #26 from Jan Hubicka ---
reverted the znver1-3 change on gcc-12 branch. We still may want to fix IRA to
avoid the problem on core_avx512 targets.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109511
--- Comment #3 from anlauf at gcc dot gnu.org ---
Created attachment 54860
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54860&action=edit
Patch
Patch I am testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109009
--- Comment #5 from Surya Kumari Jangala ---
I was analysing and comparing the following test cases:
Test1 (shrink wrapped)
long
foo (long i, long cond)
{
i = i + 1;
if (cond)
bar ();
return i;
}
Test2 (not shrink wrapped)
long
fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109515
Bug ID: 109515
Summary: Diagnostic request: warning on out-of-order structured
bindings names
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109515
Andrew Pinski changed:
What|Removed |Added
Blocks||87403
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #48 from Jakub Jelinek ---
for PHIs with 3+ arguments unless all the arguments but one are the same even
when not doing any smarts seems we emit one more COND_EXPR from what we could.
The
/* Common case. */
case loop emits arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #49 from Jakub Jelinek ---
Plus for 4+ args_len, if we don't find some smart sorting, we should still
consider at least some reassociation between the COND_EXPRs, instead of
emitting for 4 args_len
3 COND_EXPRs where second depends o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109510
--- Comment #13 from CVS Commits ---
The master branch has been updated by Eric Botcazou :
https://gcc.gnu.org/g:94a21e008c4778e446321b1355f61abc75a076be
commit r13-7187-g94a21e008c4778e446321b1355f61abc75a076be
Author: Eric Botcazou
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109510
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910
Bug 108910 depends on bug 109510, which changed state.
Bug 109510 Summary: [13 Regression] bootstrap with Ada broken on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109510
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #50 from Jakub Jelinek ---
Anyway, given that in the sorting the last entry has the maximum number of
occurrences,
I think without trying to do more smarts best would be to avoid evaluating that
last condition for now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109511
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #51 from Jakub Jelinek ---
Dumb untested patch which saves 2 instructions from each of those testcases:
--- gcc/tree-if-conv.cc.jj 2023-04-12 08:53:58.264496474 +0200
+++ gcc/tree-if-conv.cc 2023-04-14 21:02:42.403826690 +0200
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105800
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109511
--- Comment #5 from Sébastien Villemot ---
Thanks for your work on this issue!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2023-04-14
Statu
1 - 100 of 135 matches
Mail list logo
