https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114563
--- Comment #8 from andi at firstfloor dot org ---
> > Needs a workload where it matters
>
> PR119387 had
>
> 85.81% 1500713 cc1plus cc1plus [.]
> ggc_internal_alloc(un
>
> for me. Can we keep an index to freelist from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119376
--- Comment #20 from andi at firstfloor dot org ---
> Anyway, working now on the local vars and warnings for that.
Thanks.
I tried it, but so far it doesn't work correctly. I guess I don't
fully understand the subtleties of the alias machinery
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118198
--- Comment #7 from andi at firstfloor dot org ---
If it's solvable for the sanitizers then it's solvable for abort too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117091
--- Comment #15 from andi at firstfloor dot org ---
An upper limit has the problem that very large switches may never get
the bitmasks or the jump clusters. Would be good to have a heuristic
that still works for them.
Bit clustering always wor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117091
--- Comment #14 from andi at firstfloor dot org ---
On 2024-10-17 05:59, rguenther at suse dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117091
>
> --- Comment #13 from rguenther at suse dot de de> ---
> On Thu, 17 Oct 2024, phee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
--- Comment #19 from andi at firstfloor dot org ---
>Is musttail7.c specifically about testing recursive calls?
It is mainly about testing the frontend.
In the middle end tail recursion is implemented quite differently but
the frontend doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
--- Comment #17 from andi at firstfloor dot org ---
This patch should fix it. Please confirm.
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index f92f7f1af9c6..f58aed462971 100644
--- a/gcc/testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
--- Comment #16 from andi at firstfloor dot org ---
On Mon, Sep 30, 2024 at 03:05:11PM +, clyon at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
>
> --- Comment #15 from Christophe Lyon ---
> (In reply to andi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
--- Comment #14 from andi at firstfloor dot org ---
The test relies on the
gcc/testsuite/lib/target-supports.exp:check_effective_target_tail_call
probe matching what the test does. Perhaps the way you are passing options
doesn't pass them to th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116500
--- Comment #7 from andi at firstfloor dot org ---
Thanks. Updated patch. This one seems obvious so I'll commit soon.
diff --git a/gcc/testsuite/gcc.dg/vect/vect-switch-ifcvt-1.c
b/gcc/testsuite/gcc.dg/vect/vect-switch-ifcvt-1.c
index f5352ef8ed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
--- Comment #20 from andi at firstfloor dot org ---
On Tue, Aug 27, 2024 at 05:12:41PM +, hjl.tools at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
>
> --- Comment #19 from H.J. Lu ---
> (In reply to andi from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
--- Comment #18 from andi at firstfloor dot org ---
> > -mgeneral-regs-only works for this case, but breaks SSE.
>
> Why is __attribute__((no_caller_saved_registers)) needed on start?
To maintain the standard ABI to its caller. Otherwise the fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
--- Comment #13 from andi at firstfloor dot org ---
> --- Comment #11 from H.J. Lu ---
> Please provide a small testcase to show the issue.
You mean a test case for no_caller_saved_registers failing with SSE?
It's just
__attribute__((no_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
--- Comment #12 from andi at firstfloor dot org ---
> no_call{er,ee}_saved_registers are i386-specific so how do we handle other
> ports? Are we going to require implementing them for all ports?
It's an optimization, so nothing is required. But
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
--- Comment #9 from andi at firstfloor dot org ---
On Tue, Aug 27, 2024 at 08:02:53AM +, rguenth at gcc dot gnu.org wrote:
> Hmm, why would a tail call need to save extra regs over what the callers
> caller
> already saved? We're returning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
--- Comment #8 from andi at firstfloor dot org ---
On Tue, Aug 27, 2024 at 07:58:30AM +, liuhongt at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
>
> Hongtao Liu changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
--- Comment #4 from andi at firstfloor dot org ---
The change of the subject is incorrect. The transformation
has nothing to do with static function: consider LTO or someone
might write an interpreter spread over multiple files.
> always need to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83324
--- Comment #32 from andi at firstfloor dot org ---
The feature is currently only supported with standard C/C++ attributes
([[clang/gnu::musttail]]), not __attribute__
But given that you have existing code that uses the old syntax
and clang suppo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83324
--- Comment #29 from andi at firstfloor dot org ---
The semantics of -foptimize-sibling-calls do not change. However if your
program depends on sbling calls for correctness it should migrate to the
new attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166
--- Comment #29 from andi at firstfloor dot org ---
> It might be interesting to have statistics on function sizes in
> insn-recog.cc to see if there's any outliers - if it's just very many
> there's nothing to do but split the file up.
Or LTO d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115091
--- Comment #2 from andi at firstfloor dot org ---
On Wed, May 15, 2024 at 06:23:27AM +, rguenth at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115091
>
> --- Comment #1 from Richard Biener ---
> maybe represent th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828
--- Comment #15 from andi at firstfloor dot org ---
> Provided I cannot reproduce on the current kernel, where exactly does this
> come
> from?
Usually I had to do a longer loop of randconfig builds to find it. It only
happens in some specific c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42587
--- Comment #13 from andi at firstfloor dot org ---
> The code in the initial report optimizes to bswap with GCC8.1 and later.
> Is that the test case you meant? GCC8.1 was released on May 2, 2018, well
> before your Nov comment, so maybe you mea
23 matches
Mail list logo
