that, IMHO, they are actively harmful to GCC and the free software
movement in general.
I don't relish the idea of forking GCC again. Been there, done that, it
was painful. But again, I think we're at a point where it's necessary
again.
Jeff
On 4/14/2021 10:55 AM, Christopher Dimech wrote:
Sent: Thursday, April 15, 2021 at 4:35 AM
From: "Toon Moene"
To: "Jeff Law" , "Richard Biener" , "Jonathan Wakely"
, "Jonathan Wakely via Gcc" , "Thomas Koenig"
Subject: Re: GCC as
On 4/14/2021 2:39 PM, Ian Lance Taylor wrote:
On Wed, Apr 14, 2021 at 9:08 AM Jeff Law via Gcc wrote:
once or twice when physical violence with threatened, but that's about
it (aside from spammers). I don't think we want to get too deep into
moderation and the like -- IMHO it sh
in
outside advisors for what ultimately became the steering committee.
You may not buy it, but that's OK. That's ultimately your decision to
make.
I do buy it. It's consistent with what I've seen over nearly three
decades of dealing with GNU tools and what I've *directly observed* as
part of the leadership and management teams.
Jeff
find them quite
valuable, so I'm sad to see you dropping yourself from the gcc@ list.
jeff
not aware of anywhere in the US that is a monoculture in the way you
seem to be implying. And if you really believe there are those kinds of
monocultures , then you're showing a high degree of ignorance.
FTR, I've never resided on the west coast of the US or in the
traditionally defined New England states.
Jeff
h to the
gcc-patches mailing list for design/implementation review. For new
contributors, if the patch is acceptable, someone will commit it for
you. Over time if you make several contributions, then we'll set you up
with write access to the repository.
jeff
egal difficulties at
least now out of the way?
Read the DCO. If you can satisfy the terms of the DCO, then yes it
would help. But DCO still has requirements that may not be easily met
unless you are the author or know the author and can communicate with them.
jeff
On 6/9/2021 9:34 AM, Aldy Hernandez wrote:
On 6/9/21 2:09 PM, Richard Biener wrote:
On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc
wrote:
Hi Jeff. Hi folks.
What started as a foray into severing the old (forward) threader's
dependency on evrp, turned into a rewrite o
On 6/9/2021 2:39 PM, Aldy Hernandez wrote:
On 6/9/21 9:47 PM, Jeff Law wrote:
On 6/9/2021 9:34 AM, Aldy Hernandez wrote:
On 6/9/21 2:09 PM, Richard Biener wrote:
On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc
wrote:
Hi Jeff. Hi folks.
What started as a foray into severing
On 6/9/2021 5:48 AM, Aldy Hernandez wrote:
Hi Jeff. Hi folks.
What started as a foray into severing the old (forward) threader's
dependency on evrp, turned into a rewrite of the backwards threader
code. I'd like to discuss the possibility of replacing the current
backwards thr
ft of DOM is just forward jump threading. Revamp &
simplify. Then either make it a distinct pass or as a sub-pass of FRE.
But one could just as easily look at adding threading to FRE and just
killing DOM and its jump threading.
Jeff
On 6/14/2021 11:39 PM, Aldy Hernandez wrote:
On 6/15/21 6:03 AM, Jeff Law wrote:
On 6/14/2021 12:40 AM, Richard Biener wrote:
I bet it's going to be tougher to remove DOM's threader. It knows how
to do thinks like resolve memory references using temporary
equivalences
I am pleased to announce that the GCC Steering Committee has appointed
Aldy Hernandez and Ian MacLeod as maintainers for the VRP subsystem
(EVRP, VRP, Ranger).
Aldy/Andrew, please update the MAINTAINERS file appropriately.
Thanks,
jeff
On 6/21/2021 8:40 AM, Aldy Hernandez wrote:
On 6/9/21 2:09 PM, Richard Biener wrote:
On Wed, Jun 9, 2021 at 1:50 PM Aldy Hernandez via Gcc
wrote:
Hi Jeff. Hi folks.
What started as a foray into severing the old (forward) threader's
dependency on evrp, turned into a rewrite o
ever tried to build microblaze to generate stabs,
and I can't see a good reason why anyone would. Including dbxelf.h
seems wrong. I don't have an answer why other arch's do that.
Avoiding dbxelf would be advisable. We're really only supporting stabs
for for aix anymore. We need to start excising dbxelf from all the
places it's being used.
jeff
On 7/22/2021 8:12 AM, Joel Sherrill wrote:
On Wed, Jul 21, 2021 at 10:08 PM Jeff Law wrote:
On 7/21/2021 6:31 PM, Michael Eager wrote:
On 7/21/21 5:22 PM, Joel Sherrill wrote:
On Wed, Jul 21, 2021, 7:12 PM Michael Eager mailto:ea...@eagercon.com>> wrote:
On 7/21/21 2:28 PM
f
stringop-overflow failures which should hit your inbox shortly.
Jeff
threaded a path we hadn't previously and by some
chain of events exposed a out of bounds write that needs to be fixed.
Jeff
t.61.i.gz
Description: GNU Zip compressed data
efined in their ISA,
but not in the MD file.
jeff
torization. THe threader doesn't have any cost
model for what is effectively loop peeling, loop rotatation, loop header
copying and the like. Zdenek argued those belong in the loop
optimizers, not jump threading and I broadly agree with that assessment.
Jeff
simple. The backwards threader uses a different block
copier and CFG update mechanism that does not support commonizing
threads from multiple paths to the same target. So each jump thread
ends up with a copy of the path which can lead to excessive code bloat.
THe forward threader knows how to commonize those paths so cut down on
the duplicates and thus can accept larger blocks without having such a
negative impact on code size.
I think today "backwards" vs, "forwards" only refers to the way we find
threading opportunities.
Correct.
jeff
dity/costing metrics
and thus
classify threading opportunities in a different way?
Jeff, do you have any insight here?
This is precisely what you're cleaning up.
I think today "backwards" vs, "forwards" only refers to the way we find
threading opportunities.
end
of its useful life. FRE has a lot more going for it.
But the same way DOM can register jump threading opportunities FRE
could do as well.
I'd advise against that and instead look towards a model where no pass
has integrated jump threading and the only jump threading module we have
is the backwards threader.
jeff
On 9/10/2021 10:05 AM, Aldy Hernandez wrote:
On 9/10/21 5:43 PM, Jeff Law wrote:
On 9/9/2021 3:21 AM, Aldy Hernandez wrote:
/* If this path does not thread through the loop latch, then we are
using the FSM threader to find old style jump threads. This
is good, except
On 9/27/2021 7:52 AM, Aldy Hernandez wrote:
[CCing Jeff and list for broader audience]
On 9/27/21 2:53 PM, Maxim Kuvyrkov wrote:
Hi Aldy,
Your patch seems to slow down 471.omnetpp by 8% at -O3. Could you
please take a look if this is something that could be easily fixed?
First of all
nstall/prerequisites.html
to s/1.4.4/1.5.3/g && git commit -m 'bump dejagnu required version' ?
All kinds of people. Submit a patch and I bet it'll get approved. More
than anything I suspect it's out-of-sight-out-of-mind at this point
holding us back.
jeff
ments which exist merely to compute the conditional we
thread are going to be removed and we need not worry about the cost of
copying them which allowed us to thread many cases we had missed before
without increasing codesize.
Anyway, those are the research areas to look at first, then we'll figure
out what the next steps are.
JEff
but this
case is simple enough that we don't need to query the target's
capabilities, look at stack usage, worry about argument mappings, etc.
jeff
e are the only ones I would consistently ignore from
GCC.
Jeff
e triggering that you do not
want to trigger.
Could we think of the optimization opportunity in a different way?
(A << B) eq/ne 0 -> A eq/ne (0U >> B)
And I would expect the 0U >> B to get simplified to 0.
Would looking at things that way help?
jeff
On 11/24/2021 12:41 PM, Zdenek Sojka wrote:
Hello Jeff,
-- Původní e-mail --
Od: Jeff Law via Gcc
Komu: Paul Floyd , gcc@gcc.gnu.org
Datum: 24. 11. 2021 20:33:02
Předmět: Re: distinguishing gcc compilation valgrind false positives
On 11/24/2021 12:15 PM, Paul Floyd
gets released but see
little value in doing so.
What do others think? (Any important caveats I might have missed?)
I think it's well past time we do this. There may be a bit of pain
with cherry-picking across the rename point, but we should just deal
with it.
jeff
On 1/7/2022 7:49 AM, Jeff Law wrote:
On 1/7/2022 3:25 AM, Martin Jambor wrote:
Hi,
Would anyone be terribly against mass renaming all *.c files (that are
actually C++ files) within the gcc subdirectory to ones with .cc suffix?
We already have 47 files with suffix .cc directly in the gcc
ut of registers on all of them. The key property
is the size/alignment of the argument differs depending on if it's pass
in a register (get promoted) or passed in memory (not promoted). I'm
not immediately aware of another ABI with that feature. Though I
haven't really gone looking.
jeff
e (I don' t have
the # handy, but it's probably on the Wuninitialized tracker).
Jeff
etter since we'd like most tests to fail if somehow their stacks were
executable.
Committed to the trunk.
Jeff
commit 6b7441a46c771aa6ecdc0c8ed96197417d036b9a
Author: Jeff Law
Date: Sun Apr 24 13:38:14 2022 -0400
[committed] exec-stack warning for test which wants executa
week. Essentially all the nested function tests
are failing on some targets due to the same linker warning.
Either pruning or adding the option to all those tests is going to be
necessary ;(
jeff
On 4/25/2022 8:42 AM, Nick Clifton wrote:
Hi Jeff,
I used -z execstack rather than --no-warn-execstack as the former
is recognized by older versions of ld, but the latter is a new option.
Thanks for it.
Unfortunately, I should have looked at the other failures that have
popped up over the
On 4/25/2022 9:26 AM, Nick Clifton wrote:
Hi Jeff,
Just FYI - I am also looking at adding in another warning. This
time for
when the linker creates a PT_LOAD segment which has all of the RWX
flags
set. At the moment my testing seems to show that it only causes
problems
when a
On 4/25/2022 8:37 AM, Jeff Law wrote:
On 4/25/2022 6:56 AM, Martin Liška wrote:
I used -z execstack rather than --no-warn-execstack as the former is
recognized by older versions of ld, but the latter is a new option.
Thanks for it.
Unfortunately, I should have looked at the other
validation of a couple targets in my tester which completed yesterday.
Jeff
On 4/28/2022 9:29 AM, Jakub Jelinek wrote:
On Thu, Apr 28, 2022 at 09:25:43AM -0600, Jeff Law via Gcc wrote:
On 4/28/2022 8:59 AM, Jakub Jelinek via Gcc wrote:
Status
==
We have reached zero P1 regressions today and releases/gcc-12 branch has
been created. GCC 12.1-rc1 will be built
ature optimization) and probably just an oversight thinking
that a block with no real insns could be totally ignored.
jeff
x27;t place an eval in BB2 because that
will cause evaluations on 2->4->6 which didn't have any evaluations.
There isn't a great place in GCC to handle this right now. If the
constraints were relaxed in PRE, then we'd have a chance, but getting
the cost model right is going to be tough.
Jeff
gimple, but never was able to
convince myself the implementation was correct or that integrating it
was a good thing. It's almost certainly going to cause performance
regressions elsewhere so it may end up doing more harm than good. I
don't really know.
https://courses.cs.washington.edu/courses/cse501/06wi/reading/click-pldi95.pdf
Jeff
On 10/18/22 20:09, Vineet Gupta wrote:
On 10/18/22 16:36, Jeff Law wrote:
There isn't a great place in GCC to handle this right now. If the
constraints were relaxed in PRE, then we'd have a chance, but
getting the cost model right is going to be tough.
It would have been better
On 10/19/22 01:46, Richard Biener wrote:
On Wed, Oct 19, 2022 at 5:44 AM Jeff Law via Gcc wrote:
On 10/18/22 20:09, Vineet Gupta wrote:
On 10/18/22 16:36, Jeff Law wrote:
There isn't a great place in GCC to handle this right now. If the
constraints were relaxed in PRE, then we
LF IT, just say that. Don't
blame overseers.
Project leadership needs to make this decision. The sourceware
overseers should neither make the decision nor decide how high the bar
needs to be for any given project.
Jeff
ocked full migration of sourceware to LF IT.
They can make those decisions for the projects they lead. But making
the decision or setting criteria for other projects is highly unreasonable.
Jeff
ltiple hats, but it's not really
complicated. Each project makes a decision, by whatever means project
leadership has in place to make decisions. overseers then honors those
requests to stay or go. It's a pretty simple separation of
responsibilities. It need not be contentious in any way shape or form.
Jeff
to get this in earlier for GCC 13. It is literally a "do-nothing"
patch.
Just a note, I won't object if someone wants to move this forward.
jeff
and dies. So it's effectively a temporary. Combine
will re-use that temporary as the clobbered operand.
Jeff
pect to safely shift them back in.
The semantics of a paradoxical subreg are that the bits outside the
inner mode are don't cares. Of course you *may* need to go back to a
compiler a that point in time to see the problematical case.
Jeff
e register isn't live at the
point where you want to do the insertion.
Or is that the core of the problem -- that life analysis is inaccurate
or unavailable?
Jeff
might know as well since I think they discussed it at
length a little while back.
jeff
nt to come back to GCC development, you'll
always be welcome Martin!
jeff
ime to fix before leaving Red Hat. We burn a fair amount of builder
time due to this issue right now.
jeff
a trend in processor design to reduce/remove the
misalignment penalties (thus eliminating the driver for increasing data
alignment), that's been primarily in high end designs.
jeff
On 3/31/23 03:11, Vineet Gupta wrote:
Hi Jeff, Kito,
I need some ideas to proceed with PR/109279: pertaining to longer term
direction and short term fix.
First the executive summary:
long long f(void)
{
return 0x0101010101010101ull;
}
Up until gcc 12 this used to generate const pool
hed to-date didn't seem important enough to
me to warrant porting to this branch. But if someone thinks otherwise,
I won't object to them being cherry-picked.
jeff
e we are
relative to the current gcc-13 bits. Doing an occasional forced update
isn't that bad (I've worked with this kind of flow for shared topic
branches in the past). But if you feel strongly, I can live with a
merge flow as well.
Jeff
On 5/2/23 22:36, Varun Kumar E via Gcc wrote:
Hello,
https://godbolt.org/z/P3M8s8jqh
The above case shows that gcc first decreases the stack pointer and then
probes.
As mentioned by Jeff Law (reference
<https://developers.redhat.com/blog/2019/04/30/stack-clash-mitigation-in-gcc-why-fst
Sounds fine Thomas. Thanks.
-- Jeff J.
On Mon, May 15, 2023 at 4:01 AM Thomas Schwinge
wrote:
> Hi!
>
> On 2023-05-08T21:50:56+0200, I wrote:
> > Ping: OK to push to newlib main branch the attached
> > "For GCC, newlib combined tree, newlib build-tree testing, u
On 6/1/23 20:38, Vineet Gupta wrote:
Hi Jeff,
I finally got around to collecting various observations on PR/109279 -
more importantly the state of large constants in RV backend, apologies
in advance for the long email.
It seems the various commits in area have improved the original test
regs which should give us some
chance at seeing the value reuse if/when IRA/LRA muck things up.
I'll be out of office for the rest of week, will look into this once I'm
back.
NP.
jeff
king run to run
comparisons of the testsuite virtually impossible.
I did convert to LRA. But I didn't check to see if that brought
stability to the testsuite though.
jeff
instruction lengths.
Generally true, but not so on the m68k unless something significant has
changed.
On the m68k all this stuff is handled by the assembler.
jeff
I am pleased to announce that the GCC Steering Committee has appointed
Ju-Zhe Zhong and Robin Dapp as reviewers for the RISC-V port.
Ju-Zhe and Robin, can you both updated your MAINTAINERS entry appropriately.
Thanks,
Jeff
ne_insn "return" ...)`.
Many ports define trivial returns. But it's much more common to need a
prologue and epilogue. Those are typically define_expands which
generate all the code to set up a stack frame and tear a stack frame
down+return.
Jeff
to be limited to global ranges since
as you note, we're in a mixed IL state and ranger is probably going to
be confused as hell.
Jeff
icit-function-declaration?
Jeff
(of course) not given with a non-lto libgfortran.
Yea. This certainly can happen with LTO. These warnings would
definitely be something worth investigating.
Essentially the inlining enabled by LTO can expose a different set of
diagnostics.
Jeff
uld be read only and cause a trap if written to. if the
branch is never taken there would be no writes
Right. See ifcvt_memrefs_wont_trap. That probably could be extended
to capture additional cases. But I'm not sure that'll be sufficient for
Hanke's problem.
Jeff
d look to see the first pass where the condition gets removed
using -fdump-tree-all-details. That should give you strong hints about
what to look at next.
Conceptually something has determined that _2 never has the value 0
which through backwards propagation would indicate that __builtin_clz
never returns the value 32.
Jeff
re considering this behavior as a bug, I prefer to ask the community to
understand if there is any aspect I have missed in my reasoning.
It would help if you included the debugging dumps.
Jeff
trying to port those changes over. Any
such effort would likely be better spent nailing down issues on the trunk.
jeff
#x27;t useful at all
IMHO. Now you can get dynamic instructions from various QEMU plugins at
which point the data becomes much more interesting -- though you have to
be careful interpreting that as well.
Jeff
ropping/converting during gimplification with a checker
that verifies they don't sneak back in. Then we can start to expunge
them from gimple passes. Feels like a gcc-15+ problem to me.
jeff
I suspect that something in the virt->phys logic just doesn't know how
to check for mem constraints in user asms.
I looked briefly, it appears the code just punts rewriting all user
asms, but maybe I missed something.
I wouldn't lose any sleep if we had a way to simply disable strub for rl78.
Jeff
On 12/8/23 19:18, Alexandre Oliva wrote:
Hello, Jeff, DJ,
Thanks for the info.
On Dec 7, 2023, Jeff Law wrote:
On 12/6/23 15:03, DJ Delorie wrote:
Alexandre Oliva writes:
This looks like a latent bug in the port.
I'm not surprised, that port was weird.
This was just a plai
, so I wouldn't lose any sleep if it
got deprecated across the board. While my tester includes nds32le-elf
and nds32be-elf, there's no gdbsim, so those targets don't provide much,
if any, additional coverage over targets in the tester.
Jeff
from including nds32.
jeff
before the deadline, but are still going through the review/iterate process.
Jeff
rtainly measured in months
for an experienced GCC developer. Good luck.
jeff
about the number and types of arguments.
Having said that, there is a GCC internals manual which describes the
RTL language, the format of backend patterns, expanders, etc. While the
vast majority will not be relevant to your effort, it is likely worth
bookmarking it for future reference.
jeff
match.)
I've very much prefer to move to a pull-request model.
jeff
#x27;s been
fairly stable, but its not doing in-depth testing.
jeff
ternally. But boy I want to get away from email and to a
pull request kind of flow.
jeff
On 5/1/24 2:04 PM, Jason Merrill wrote:
On 5/1/24 12:15, Jeff Law wrote:
On 4/22/24 9:24 PM, Tom Tromey wrote:
Jason> Someone mentioned earlier that gerrit was previously tried
Jason> unsuccessfully.
We tried it and gdb and then abandoned it. We tried to integrate it
in
So a test which passes today, will flip to failing tomorrow
while some other test of tests will go the other way.
jeff
On 5/21/24 8:02 AM, Paul Koning wrote:
On May 21, 2024, at 9:57 AM, Jeff Law wrote:
On 5/21/24 12:05 AM, Richard Biener via Gcc wrote:
On Mon, May 20, 2024 at 4:45 PM Gerald Pfeifer wrote:
On Wed, 5 Jul 2023, Joern Rennecke wrote:
I haven't worked with these targets in year
ky ABIs where direct and
indirect calls can have different calling conventions.
Jeff
the LRA conversion, getting a degree of stability in the
testsuite would be a huge step forward.
jeff
On 6/4/24 8:51 PM, Erick Kuo-Chen Huang(黃國鎭) via Gcc-help wrote:
Hi,
We would like to know which GCC version start to support RISC-V RVV1.0 ?
We appreciate for your help.
gcc-14.
Jeff
ts, but it can be made to work.
Jeff
rior to LRA and LRA needs to insert
any code, that inserted code may clobber the CC state. This is
discussed in the reload-to-LRA transition wiki page.
jeff
from a security standpoint.
#3 isn't great, but it's not terrible either.
Jeff
e point is that in some functions,
combine is almost exclusively producing these rtxes with clobber
const_int, but almost no meaningful combinations. Like in:
Perhaps, but the convention of using a (clobber (const_int 0)) for cases
where combine gets "lost" has been around for decades.
Jeff
On 7/24/24 11:25 AM, Artemiy Volkov wrote:
Hi Juzhe, Demin, Jeff,
This email is intended to continue the discussion started in
https://marc.info/?l=gcc-patches&m=170927452922009&w=2 about combining vfmv.v.f
and vfmxx.vv instructions into the scalar-vector form vfmxx.vf.
There was a
1301 - 1400 of 1421 matches
Mail list logo
