On 06/26/14 14:13, Jeff Law wrote:
On 06/26/14 02:44, Bin.Cheng wrote:
Hi,
I ran into PR60947, in which GCC understands the return value of
memset is the first argument passed in, according to standard, then
does optimization like below:
movip, sp
stmfdsp!, {r4, r5, r6, r7, r8
tput operand
it self, but perhaps I misunderstand.
So my question is: is the combination of '&' and '+' supported ? If so,
what is the exact semantics ? If not, should we warn or give an error ?
I don't think we can define any reasonable semantics for &+. My
recommendation would be for this to be considered a hard error.
Jeff
developer explicitly ties the input to an earlyclobbered output
and the other inputs are marked as conflicting.
I guess I can see how that is helpful, though I wonder how often it is
helpful in practice.
Regardless, I stand corrected :-)
jeff
he same aarch64-simd.md file, I noticed some
define_expand with constraints, that looks strange)
It sometimes happens when a define_insn is converted into a
define_expand -- folks just forget to remove the pointless constraints.
jeff
e benefit is from
being able to use %ebx when it's not being used for the PIC register.
But it probably wouldn't hurt to optimize placements.
Compute some simple IPA info on whether %ebx is provided/needed
by callers/callees?
Yea. Knowing if the caller/callee have the same value may also be
helpful.
jeff
ip-* since atleast sept 2012, is there a reason they
haven't been removed yet?
I think the interix bits were resurrected back in 2012 and thus
shouldn't be considered obsolete anymore.
Jeff
k you're
doing and consider it pre-approved with some sensible sanity testing.
Jeff
7;t require you do do anything further than removing
yourself as the listed maintainer for the MIPS port
jeff
bother. I did not find anything on the web besides
https://gcc.gnu.org/contribute.html#legal which is somewhat unclear to me being
none-native English speaker.
I've forwarded your message to ass...@gnu.org. Hopefully someone from
the FSF will be in contact shortly.
jeff
.0, the release after that (in 2016) becomes 6.0, etc.
Agreed. It's not 100% perfect, but, IMHO, it's significantly better
than what we're doing now and better than the various alternatives that
have been proposed.
Jeff
er. Presumably
downstream packagers of GCC may want to customize such a feature to
point at their bug trackers (e.g. at Red Hat we have our own bugzilla
instance, with a different set of custom fields).
So the obvious question is how does this relate to Jakub's patch that
Maxim @ Samsung is trying to get reviewed?
Jeff
o the status report emails for each active branch.
Right.
It's also useful to look at historical data. gcc-x.y.1 usually spins ~1
month after the gcc-x.y release. The gcc-x.y.2 usually follows a few
months later in the fall (Sept/Oct).
Jeff
d end user/developer discussions I've had on this
topic over the last few years, a SOname bump would catastrophic.
They've made it painfully clear that a SOname bump would be the worst
thing that has happened in GCC-land in many years, possibly ever.
jeff
or ask for further
benchmarks, etc. The reviewers also use their experience to guide
submissions in the right direction.
So there's no single simple answer. It varies based on many factors.
jeff
deal with this problem. Can you describe in further detail why you
weren't able to get this to work?
What is the most acceptable way of disabling this transformation for a
target that has a conditional negation instruction?
In general, we don't want target dependencies in the gimple/ssa optimizers.
Jeff
On 08/12/14 04:31, Kyrill Tkachov wrote:
On 12/08/14 10:39, Richard Biener wrote:
On Mon, Aug 11, 2014 at 9:56 PM, Jeff Law wrote:
On 08/11/14 07:41, Kyrill Tkachov wrote:
I haven't been able to get combine to match the comparison+xor+neg+plus
RTL and it seems like it would be j
andled the same way.
Jeff
. I think that would significantly simply the
patch as well.
Jeff
mizers we don't want.
I wonder if TER could create the res = (rhs & -cond) + cond form as a
single expression which the gimple->ssa expanders could then emit as a
series of insns or as a conditional negation on targets that have
conditional negation.
jeff
n time, I'm not opposed to pulling out those bits from phi-opt
and making the transformation conditional on target attributes during
expansion.
jeff
lt;,<")
- (match_operand:TF 1 "general_no_elim_operand" "x,*roF"))]
+ (match_operand:TF 1 "nonimmediate_no_elim_operand" "x,*roF"))]
Can you please explain the reason for this change (and a couple of
similar changes to push patterns) ?
I'd recommend dropping them from the WIP postings.
jeff
t of the WIP patches as well.
Jeff
On 08/28/14 02:37, Ilya Enkovich wrote:
2014-08-28 1:39 GMT+04:00 Jeff Law :
On 08/26/14 15:42, Ilya Enkovich wrote:
diff --git a/gcc/calls.c b/gcc/calls.c
index 4285ec1..85dae6b 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -1122,6 +1122,14 @@ initialize_argument_information (int num_actuals
pear until flow (just prior to
combine) and that was documented behaviour. So anything which was run
strictly prior to flow/combine wasn't autoinc aware. That may have
changed somewhat with the autoinc rewrite.
jeff
describe why you think it might be missing it'd be helpful for
evaluation.
My recommendation would be to file a bug report with the reproducer.
m68k isn't nearly as important today as it has been in the past, so
getting developer time to hash through how all this should work for the
coldfire may be difficult.
jeff
on on how to report a violation here:
http://www.gnu.org/licenses/gpl-violation.html
Thanks,
Jeff
ks in advance,
-Jeff
something
like the first X bytes of this memory region are written and the
remaining Y bytes may be written, but I suspect that's not a use case
we're likely to care about.
jeff
On 09/18/14 08:38, Yury Gribov wrote:
On 09/18/2014 05:36 PM, Jeff Law wrote:
On 09/18/14 05:19, Yury Gribov wrote:
Would that modifier mean that the inline asm is unconditionally reading
resp. writing that memory? "m"/"=m" right now is always about might
read or might wr
On 09/18/14 08:32, Richard Biener wrote:
On September 18, 2014 3:36:24 PM CEST, Jeff Law
wrote:
On 09/18/14 05:19, Yury Gribov wrote:
Would that modifier mean that the inline asm is
unconditionally
reading
resp. writing that memory? "m"/"=m" right now is always about
There's another usability enhancement: I'd like to
propose to put all email addresses between '<' and '>', which would
quite ease cut'n'past-ability. What's your oppinion on that? Should I
prepare a patch?
Sure.
Jeff
.
Igor Zamyatin has been doing a fair amount of Cilk+
maintenance/bugfixing and it might make sense for him to own it in the
long term if he's interested.
jeff
t improvement and
one which I think would be quite useful.
Jeff
ould want to look at anyway.
jeff
On 09/23/14 10:03, Jakub Jelinek wrote:
On Tue, Sep 23, 2014 at 10:00:00AM -0600, Jeff Law wrote:
On 09/23/14 08:34, Jakub Jelinek wrote:
On Tue, Sep 23, 2014 at 05:54:37PM +0400, Ilya Enkovich wrote:
use fixed EBX at least until we make sure pseudo PIC doesn't harm debug
info generation
ed).
Can't hurt, but I really don't see how changing from a fixed to an
allocatable register is going to muck up debug info in any significant
way.
jeff
On 09/24/14 00:56, Ilya Enkovich wrote:
2014-09-23 20:10 GMT+04:00 Jeff Law :
On 09/23/14 10:03, Jakub Jelinek wrote:
On Tue, Sep 23, 2014 at 10:00:00AM -0600, Jeff Law wrote:
On 09/23/14 08:34, Jakub Jelinek wrote:
On Tue, Sep 23, 2014 at 05:54:37PM +0400, Ilya Enkovich wrote:
use
On 09/24/14 14:32, Ilya Enkovich wrote:
2014-09-24 19:27 GMT+04:00 Jeff Law :
On 09/24/14 00:56, Ilya Enkovich wrote:
After register allocation we have no idea where GOT address is and
therefore delegitimize_address target hook becomes less efficient and
cannot remove UNSPECs. That's w
w, please update the MAINTAINERS file appropriately.
Thanks for everyone's patience,
Jeff
ut a "porting to ..." document ought to be
started and have something in it about these changes. Both how to fix
the broken code or how to go back to c89.
Jeff
we want/need to consider anything with a
VALUE as not passing the base alias check and defer memrefs_conflict_p?
I really don't know, it's been a long time since I worked with this code
(it predates the introduction of cselib, so that gives you an idea of
how long its been :-)
jeff
On 10/10/14 12:12, Uros Bizjak wrote:
On Fri, Oct 10, 2014 at 7:56 PM, Jeff Law wrote:
On 10/09/14 06:14, Uros Bizjak wrote:
Hello!
I'd like to bring PR 63475 to the attention of RTL maintainers. The
problem in the referred PR exposed the RTL infrastructure problem,
where VALUE expres
tly -- he may miss this thread, but I
wouldn't be surprised if he can give some relevant advice.
jeff
ime you will. Normally it won't matter unless
(as noted above) the expander/pattern has references (particularly
sets/clobbers) of overlapping hard registers.
It's also probably worth investigating why you got the hard register in
the first place as that may indicate something that's wrong or
suboptimal either in the expanders or in the target dependent bits.
Jeff
ence of the hard register operand _may_ point to something else
that we would want to fix.
jeff
registers you need to clobber, then clobber a
pseudo of that class. That can often help register allocation.
jeff
ere I'd
focus my efforts since that probably shouldn't be happening except in
very special circumstances.
jeff
ple of why clobbering hard registers
in patterns is a bad idea.
This has a much greater chance of working if the patterns instead
clobbered a pseudo/scratch where the constraint specifies a class that
has r26/r27 as a member (possibly its only member).
Jeff
easons. But there's dozens of
other backends you could look to convert. I'm attaching the
work-in-progress on the PA backend so you can see a concrete example.
Jeff
diff --git a/gcc/config/pa/pa-protos.h b/gcc/config/pa/pa-protos.h
index 80e1efe..0ba5055 100644
--- a/gcc/config/pa/pa-p
shows
things as you move from the higher level GIMPLE IL into the initial RTL
IL. The GIMPLE IL will look at lot like C code and should have a form
similar to the original input. The RTL will roughly correspond to
instructions.
From there you'll either work forward or backwards into gimple or the
RTL codepaths depending on what your initial analysis shows.
jeff
s a way to inform gcc to use the same hard registers for
operands[0] across those three instructions.
Is it possible?
Or would there be any better way to generate efficient FPU code?
I will appreciate any advice or pointer to further information.
Use a define_insn_and_split, but only split it after register allocation
& reloading.
Jeff
On 11/03/14 09:24, Joseph Myers wrote:
I propose enabling -fextended-identifiers by default for the appropriate
standard versions (i.e. all C++ versions, C99 and above for C - so enabled
by default for C now the default C version is gnu11). Any comments or
objections?
No objections here.
jeff
than 32 store instructions
in flow, but the dependency are actually very simple.
See:
https://gcc.gnu.org/ml/gcc-patches/2001-07/msg01668.html
I don't recall what part of the algorithm was quadratic, but it should
be too hard to find out given the thread references the target & the
testcase.
jeff
asel out of the
extra work for my patch, just curious if the web site guidelines have
gotten bit-rotten after the switch to C++, or if the SC did indeed
consider the issue already and the published policy is accurate.
They've bit-rotted a bit. Interested in cons-ing up an update?
jeff
sions based on liveness, expected
uses, call-crossing liveness, related copies, etc etc.
jeff
when conversion is complete.
I'd be comfortable with a similar mechanism for this work as well.
Option 3: only convert the "easy" accessors: the ones I already did in
the /89 patch kit, as reviewed by Jeff, and rebased by me recently,
which is this 92-patch kit:
"[g
of const_gimple and thus avoids introducing tons of new const_
for all the subclasses).
Right. Mirrors what we've done for INSNs in RTL as well.
jeff
hange here, but the question is what :-)
And I think rolling back and debugging that compiler is the best way to
know get more information to allow this to move forward.
Jeff
I'm pleased to announce that Bernd Schmidt been appointed as maintainer
for the nvptx port he recently contributed to GCC.
Bernd, please add yourself as the maintainer for that port in the
MAINTAINERS file.
Thanks for your patience,
Jeff
Though in the case
of libgcj we just install the file and don't, as far as I can tell,
actually depend on pkg-config.
jeff
there *is* an expert on the GCC buildsystem :(
jeff
I'm pleased to announce that David Malcolm been appointed as maintainer
for the GCC JIT subsystem.
David, please add yourself as the maintainer for that code in the
MAINTAINERS file. I believe you have some patches to review and approve ;-)
Thanks for your patience,
Jeff
and other folks in the Red Hat team to use when the
need arises to dig into these kind of issues.
However, until that box arrives and is setup, this kind of iteration is
the only way he can test Darwin stuff.
Jeff
On 12/09/14 10:10, Vladimir Makarov wrote:
generate the correct code in many cases even for x86. Jeff Law tried
IRA coloring reusage too for reload but whole RA became slower (although
he achieved performance improvements on x86).
Right. After IRA was complete, I'd walk over the unallo
On 12/09/14 14:48, shmeel gutl wrote:
On 09-Dec-14 07:56 PM, Jeff Law wrote:
On 12/09/14 10:10, Vladimir Makarov wrote:
generate the correct code in many cases even for x86. Jeff Law tried
IRA coloring reusage too for reload but whole RA became slower (although
he achieved performance
On 12/10/14 02:02, Ajit Kumar Agarwal wrote:
Right. After IRA was complete, I'd walk over the unallocated
allocnos and split their ranges at EBB boundaries. That created
new allocnos with a smaller ??>>conflict set and reduced the
conflict set for the original unallocated allocnos.
be coordinated with any other projects.
If not, then I will prepare patches to fix the spelling. :)
I think it's supposed to be kept synchronized with binutils/gdb. Not
sure which is the canonical version, but if you fix both at the same
time it really doesn't matter :-)
jeff
On 01/08/15 13:02, Zach Tomkoski wrote:
I have been working on changes to extend the functionality of the
GCC's built in code coverage tool gcov. What steps would I need to go
through to work on getting these additions to be added in to the
upstream releases of GCC?
https://gcc.gnu.org/contribu
broken enough to warrant fixing regardless of
what stage we're in. If indeed it's as simple as disabling that
pattern, the chances for collateral damage are trivially small.
jeff
g in cases where the
pressure is not high.
If you've got data which does this does not regress on a more mainstream
target and that it bootstrapps and regression tests on a mainstream
target (x86_64 is by far the most popular), then I'd seriously consider
approving this.
Jeff
I'm pleased to announce that Marek Polacek has been appointed as a
reviewer for the C front-end.
Marek, please add yourself as a reviewer for the C front end in the
MAINTAINERS file.
Jeff
I'm pleased to announce that Iain Sandoe has been appointed as a
maintainer for the Objective-C and Objective-C++ front-ends.
Iain, please add yourself as a maintainer for those front-ends in the
MAINTAINERS file.
Jeff
h level buckets, how much stuff are we likely
going to have in the miscellaneous bucket. If the misc bucket is still
big then folks are still going to struggle with finding the information
they want/need (or think they want/need).
Jeff
On 01/14/15 23:12, Sandra Loosemore wrote:
On 01/14/2015 08:41 PM, Jeff Law wrote:
With the section being ~60 pages, my first thought is we have way too
many options!
Heh, at least we have documentation for all those options. :-)
But that's not likely to change. Though perhaps the
pr
On 01/17/15 07:34, Gary Funck wrote:
On 01/14/15 23:15:59, Jeff Law wrote:
Sounds good. I think just starting with the list & creating the buckets
with the list. Then post here and we'll iterate and try to nail that down
before you start moving everything in the .texi file.
Som
t.
Or this one.
We could have a whole section on volatile :-)
Variable Attributes might be a better place for the thread-local-storage
stuff.
jeff
al constraints as well to allow loads/stores of
integer registers in FP modes to use the larger offset.
Jeff
ave to filter out that while you're reading.
Jeff
from Frank WRT whether or not we can add more
memory to the existing system. That would be a stopgap as the machine
is nearing its end of life (we typically need to update the system
roughly ever 3 years).
jeff
yesterday.
I had never run into that before.
Are you using anonymous mode, or ssh-authenticated? The former is
usually throttled as the load rises, the latter is not.
jeff
an upgrade takes for the volunteers,
I'm really hoping the extra memory gives us enough headroom to get
through this year.
And yes, the year delay between delivery and setup of the new server was
bad, very bad.
jeff
ed the input and output operand to
be in different registers.
We did similar things for psi->si sign extensions, some truncations,
some negations, prologue/epilogue.
https://stuff.mit.edu/afs/athena/astaff/source/src-8.2/third/gcc/config/mn10200/mn10200.md
Jeff
ify it so its not a bug,
It looks like a bug to me.
Can you please make that change in a local tree and bootstrap/regression
test it?
jeff
kind-of figured something like this would eventually happen. You're
always welcome in this community if you ever get the opportunity to
re-engage at a higher level.
jeff
amounts
of time, energy and frustration tracking down this problem.
I would like to think that the spirit of gcc is about helping engineers
efficiently correct nonstandard pain, rather than inflicting maximal
pain upon engineers violating C standards. :-)
-Jeff
BTW, I'd also be curious to
nformant code and producing code guaranteed not
to do what the programmer intended. But presumably most sane
engineers these days compile with -Wall. :-)
-Jeff
e targets the C-runtime had better also ensure that its headers
aren't decorated with non-null attributes, particularly for the mem* and
str* functions.
jeff
s.
I think the C standard is wrong here. We should extend it, as a QoI
matter, and support null pointers for variable-length inputs and outputs
if the size is 0. But I suspect this is still a minority view.
And it's these kind of uses that scare me the most.
jeff
ant a function that will have that different property,
don't call it memcpy.
Right. If someone wants to take it up with the Austin group, that's
fine. But until/unless the Austin group blesses, I don't think we should
extend as a QoI matter.
jeff
ing,
arithmetic overflow, etc. The standards define the contract between
the compiler/library implementors and the developers. Once the contract
is broken, all bets are off.
jeff
On 02/19/15 14:56, Chris Johns wrote:
On 20/02/2015 8:23 am, Joel Sherrill wrote:
On 2/19/2015 2:56 PM, Sandra Loosemore wrote:
Jakub Jelinek wrote:
On Wed, Feb 18, 2015 at 11:21:56AM -0800, Jeff Prothero wrote:
Starting with gcc 4.9, -O2 implicitly invokes
-fisolate-erroneous-paths
On 02/20/15 10:09, Florian Weimer wrote:
On 02/20/2015 06:01 PM, Jeff Law wrote:
But that's always true -- this isn't any different than aliasing,
arithmetic overflow, etc. The standards define the contract between the
compiler/library implementors and the developers. Once the c
various hooks we have to encourage those
insns to fire together.
Then you'd have a peep2 to actually squash them into a single insn.
Jeff
where exposing the
FMA earlier is helpful as well.
So I think an argument could be easily made that we want to support both.
Jeff
On 02/23/15 11:38, Joseph Myers wrote:
(I wonder if convert_mult_to_fma is something that should move to
match-and-simplify infrastructure.)
Yea, it probably should.
Jeff
ld be appreciated.
I believe you have a patch or two to self-approve ;-)
We'll discuss inclusion of the MPX runtime for GCC 5 separately with the
release managers. We may be too late in the game to make that happen.
So please don't commit the MPX runtime bits yet.
Jeff
I'm pleased to announce that Kirill Yukhin has been appointed as the
maintainer for the vector ISA extensions for the x86 port.
Kirill, if you could add yourself to the MAINTAINERS file for the
additional role, it would be appreciated.
Thanks,
Jeff
#x27;ll be easier for developers
who want to take advantage of MPX to get everything they need from the
GCC release rather than stitching things together from multiple locations.
Jakub, Joseph & Richi have the final say here for inclusion in GCC 5.
Jeff
now for sure without further analysis.
jeff
is almost impossible to overstate.
If the Austin group tightens memcpy to require fewer surprises I think
most developers would ultimately be happy with the result -- a few would
complain about the performance impacts for specific workloads, but I
suspect they'd be in the minority.
jeff
301 - 400 of 1403 matches
Mail list logo
