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 w
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
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
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 T
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 does
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
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 ---
>
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 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
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
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. O
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
__
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
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
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:
>
>W
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 n
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
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 sp
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 ---
> may
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93346
--- Comment #3 from andi at firstfloor dot org ---
> The bzhi patterns all match some odd if_then_else only to guard against
> inx & 255 == 0:
Is that guard needed? At least clang doesn't seem to care about it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66229
--- Comment #4 from andi at firstfloor dot org ---
Did some testing. Previously pretty much everything I tried failed.
I don't have mcf, but git, less, gcc LTO+autofdo bootstrap all appear to work
now.
So it's likely fixed.
Would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83375
--- Comment #9 from andi at firstfloor dot org ---
It's in kernel/bpf/core.c
It won't happen every time on a build unless you force 1on1
partitioning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77684
--- Comment #8 from andi at firstfloor dot org ---
> The log shows the same errors:
> spawn [open ...]
> Permission error mapping pages.
> Consider increasing /proc/sys/kernel/perf_event_mlock_kb,
> or try again with a smal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71672
--- Comment #2 from andi at firstfloor dot org ---
On Wed, Apr 12, 2017 at 12:15:26PM +, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71672
>
> Martin Liška changed:
>
>W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66305
--- Comment #4 from andi at firstfloor dot org ---
> --- Comment #3 from lunar at debian dot org ---
> Richard Biener:
> > I think they become deterministic with -frandom-seed=0 for example.
> > They are not deterministic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66305
--- Comment #2 from andi at firstfloor dot org ---
On Wed, May 27, 2015 at 12:21:04PM +, rguenth at gcc dot gnu.org wrote:
> --- Comment #1 from Richard Biener ---
> I think they become deterministic with -frandom-seed=0 for example.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969
--- Comment #8 from andi at firstfloor dot org ---
> only automatic vars may have a VALUE_EXPR, certainly not 'extern const' stuff.
It's an initializer for an automatic var in the source
func_52() {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61635
--- Comment #2 from andi at firstfloor dot org ---
Test case
git clone https://github.com/andikleen/linux-misc -b lto-linus-3.15
Build with the attached kernel config (copy to .config in the build dir) and
4.9
-Andi
On Fri, Jun 27, 2014 at 11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602
--- Comment #24 from andi at firstfloor dot org 2012-05-07 13:08:08 UTC ---
On Mon, May 07, 2012 at 08:54:10AM +, rguenther at suse dot de wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602
>
> --- Comment #23 from rguenthe
33 matches
Mail list logo
