On 09/15/2015 01:21 PM, David Malcolm wrote:
On Tue, 2015-09-15 at 10:39 -0700, Mike Stump wrote:
On Sep 14, 2015, at 3:37 PM, Jeff Law wrote:
Maybe GCC-6 can bump the required
dejagnu version to allow for getting rid of all these superfluous
load_gcc_lib? *blink* :)
I'd support that
s is main reason why @gnu.org or @gmail.com style addresses
are preferred over employer addresses when there's > 1 address on file.
Jeff
ps. Good to hear from you... It's been a long time.
'm comfortable telling developers on
those platforms that they need to update. It's not like every *user*
needs dejagnu, it's just for the testing side of things.
jeff
s more conveniently.
It's worth spending all this effort on the source repo because it's
more important than the wwwdocs repo.
Right. Getting the source repo converted is the big prize here. THe
www docs are a relatively small issue in comparison.
jeff
you dug there would be enough folks who've moved employment
over time and others who may change employers over time.
Agreed. In fact, I would say that most of the contributors over time
have more than one address due to employment changes.
Jeff
t decision
isn't really productive.
What is productive is discussion on how to make that migration successful.
Jeff
n svn,
but that's just me.
GIT is dramatically more complex and takes a bit of time to get used to.
I'm certain I don't exploit GIT as much as I could, but I do know it
makes classes of problems I have to solve regularly much easier.
Jeff
On 09/17/2015 10:24 AM, Richard Earnshaw wrote:
[ snip ]
No, I'm not going to do that work; and personally, I don't think it's
worth holding up the switch to wait for that to be done.
Agreed.
Jeff
10_38 = poly[1];
_24 = MEM[(double *)&poly + 8B];
beause DOM has a similar issue preventing it from CSEing those two.
Presumably you're referring to the last two statements? If so, yes, I
wouldn't expect DOM to handle that. I don't think its hasher is
prepared to try and hash those two RHS expressions to the same value.
jeff
single
execution on the target.
If you're allocating your slot late (past the gimple/rtl border), then
there isn't a significant difference (ie, no reuse/sharing the slot).
So if you're lazily allocating the slot, it shouldn't really matter
which you use.
jeff
ize to be updated accordingly?
If not, then would switching to "assign_stack_temp" be very likely to
solve the problem?
Neither inherently affects debug information. So if one is working and
the other not, there's a deeper problem elsewhere.
Jeff
rly
late in the optimizer pipeline. Redundant extension removal doesn't
remove it.
jeff
ly knows best what's currently possible with dump numbers in
the pass manager. He's on PTO this week.
ISTM that whatever we're currently doing that if a pass is inserted by a
plug-in that pass #s ought to auto-magically update themselves.
jeff
t sure what's needed. Essentially the attribute is just another
way to ensure we exploit the vector library when possible.
It also seems to me that showing that example on the libmvec page would
be advisable.
jeff
On 10/07/2015 11:22 AM, Joseph Myers wrote:
On Wed, 7 Oct 2015, Jeff Law wrote:
I'm not sure why this attribute isn't documented, but clearly that should be
fixed.
I assume the reasoning was: we document support for Cilk+ (and what's
included in Cilk+ is externally docume
On 10/07/2015 11:34 AM, Ramana Radhakrishnan wrote:
On Wed, Oct 7, 2015 at 6:22 PM, Joseph Myers wrote:
On Wed, 7 Oct 2015, Jeff Law wrote:
I'm not sure why this attribute isn't documented, but clearly that should be
fixed.
I assume the reasoning was: we document support for
32 ? "signed char" : 0)
./config/newlib-stdint.h:#define INT64_TYPE (LONG_TYPE_SIZE == 64 ?
"long int" : LONG_LONG_TYPE_SIZE == 64 ? "long long int" : INT_TYPE_SIZE
== 64 ? "int" : 0)
./config/newlib-stdint.h:#define UINT8_TYPE (CHAR_TYPE_SIZE == 8 ?
"unsigned char" : 0)
./config/newlib-stdint.h:#define UINT16_TYPE (SHORT_TYPE_SIZE == 16 ?
"short unsigned int" : INT_TYPE_SIZE == 16 ? "unsigned int" :
CHAR_TYPE_SIZE == 16 ? "unsigned char" : 0)
./config/newlib-stdint.h:#define UINT32_TYPE (STDINT_LONG32 ? "long
unsigned int" : INT_TYPE_SIZE == 32 ? "unsigned int" : SHORT_TYPE_SIZE
== 32 ? "short unsigned int" : CHAR_TYPE_SIZE == 32 ? "unsigned char" : 0)
./config/newlib-stdint.h:#define UINT64_TYPE (LONG_TYPE_SIZE == 64 ?
"long unsigned int" : LONG_LONG_TYPE_SIZE == 64 ? "long long unsigned
int" : INT_TYPE_SIZE == 64 ? "unsigned int" : 0)
./config/newlib-stdint.h:#define INT_LEAST8_TYPE (INT8_TYPE ? INT8_TYPE
: INT16_TYPE ? INT16_TYPE : INT32_TYPE ? INT32_TYPE : INT64_TYPE ?
INT64_TYPE : 0)
./config/newlib-stdint.h:#define INT_LEAST16_TYPE (INT16_TYPE ?
INT16_TYPE : INT32_TYPE ? INT32_TYPE : INT64_TYPE ? INT64_TYPE : 0)
./config/newlib-stdint.h:#define INT_LEAST32_TYPE (INT32_TYPE ?
INT32_TYPE : INT64_TYPE ? INT64_TYPE : 0)
./config/newlib-stdint.h:#define UINT_LEAST8_TYPE (UINT8_TYPE ?
UINT8_TYPE : UINT16_TYPE ? UINT16_TYPE : UINT32_TYPE ? UINT32_TYPE :
UINT64_TYPE ? UINT64_TYPE : 0)
./config/newlib-stdint.h:#define UINT_LEAST16_TYPE (UINT16_TYPE ?
UINT16_TYPE : UINT32_TYPE ? UINT32_TYPE : UINT64_TYPE ? UINT64_TYPE : 0)
./config/newlib-stdint.h:#define UINT_LEAST32_TYPE (UINT32_TYPE ?
UINT32_TYPE : UINT64_TYPE ? UINT64_TYPE : 0)
./config/avr/avr-stdint.h:#define INT64_TYPE (INT_TYPE_SIZE == 16 ?
"long long int" : 0)
./config/avr/avr-stdint.h:#define UINT64_TYPE (INT_TYPE_SIZE == 16 ?
"long long unsigned int" : 0)
You might legitimately ask why something like h8300-rtems doesn't hit
this. I believe it's because the h8300 has a constant SHORT_TYPE_SIZE,
which is enough to simplify things to the point where GCC knows NULL
isn't going to get passed to strlen. Contrast to the avr where
SHORT_TYPE_SIZE varies.
Thoughts or suggestions?
jeff
mp; conflict
information, then we'd be able to query that and perhaps be able to make
different choices.
I wonder if the web-izer pass could help here or something based on it.
Essentially what you want to do is a range split.
Jeff
0 internals over the last 25+ years.
Jeff
R_NUM_P (N) \
&& FIXED_REGNO_P (N) && REGNO_REG_CLASS (N) != NO_REGS))
Which would appear to make pseudos & non-fixed hard registers be same
WRT CHEAP_REGNO -- punting to rtx_cost for both, presumably.
Jeff
this, it also uses @anchor to
ensure that any external links to the old names will still resolve
correctly. Is this the standard? Or do we just let them fail?
For people who find the HTML easier to review:
Looks good to me.
IIRC, you didn't have commit access, so I'll go ahead and commit this
for you.
Thanks!
jeff
mple, "a5" is a particularly bad choice these days on the
m68k as it's the PIC register. It may be advisable to just use r for
some value of N and try to be processor agnostic here.
Segher's comments are valuable as well. I think if you integrate his
and mine the result ought to be ready to commit.
jeff
However, if you have, then he doesn't
need to re-confirm.
Jeff
going processor
agnostic here and using r for some value of N rather than using
severely dated m68k examples.
WRT your hope to limit this to only uses in extended asms. That'd be
nice, but that's never been an explicit limitation. I would strongly
hesitate to add that limitation at this point in time.
Jeff
rhaps something like this.
Defining a register variable does not reserve the register. The
register remains available to hold unrelated values in places where the
variable is not live according to dataflow analysis.
jeff
On 10/20/2015 03:12 AM, Segher Boessenkool wrote:
On Mon, Oct 19, 2015 at 11:14:30PM -0600, Jeff Law wrote:
+All global register variable declarations must precede all function
+definitions. If such a declaration appears after function definitions,
+the declaration would be too late to prevent
On 10/20/2015 03:29 AM, Segher Boessenkool wrote:
On Mon, Oct 19, 2015 at 11:25:27PM -0600, Jeff Law wrote:
+Defining a register variable does not reserve the register; it
+remains available for other uses in places where flow control determines
+the variable's value is not live. For
rtainly help if you can
thoroughly describe the path by which you get the double-free.
Conceptually I agree with you, but I'd have to sit down with a debugger
to really be sure.
Jeff
On 10/20/2015 09:13 AM, Segher Boessenkool wrote:
On Mon, Oct 19, 2015 at 11:22:06PM -0600, Jeff Law wrote:
WRT your hope to limit this to only uses in extended asms. That'd be
nice, but that's never been an explicit limitation. I would strongly
hesitate to add that limitation at
hat my
review would be worthless.
jeff
On 10/20/2015 10:05 AM, Andrew Haley wrote:
On 10/20/2015 05:00 PM, Jeff Law wrote:
But the technical reality is I can't see a use outside the extended asm.
I can. In the past (and probably still today) GCC did an awful job of
allocating registers in a large function. This was visible
till helped by local register variables.
Jeff
On 10/20/2015 10:39 AM, Andrew Haley wrote:
On 10/20/2015 05:22 PM, Jeff Law wrote:
On 10/20/2015 10:15 AM, Andrew Haley wrote:
But in that case, what do we guarantee.
We certainly don't guarantee that those objects will be in their
requested register at any point other than at th
On 10/20/2015 11:11 AM, Segher Boessenkool wrote:
On Tue, Oct 20, 2015 at 10:22:53AM -0600, Jeff Law wrote:
bz21182 has a testcase that's still helped by local register variables.
I tried it out, and it now is much worse *with* the reg vars than
without (and -O2 vs. -O3 makes no differen
On 10/20/2015 01:16 PM, Pierre-Marie de Rodat wrote:
On 10/20/2015 12:01 PM, Jeff Law wrote:
* The patch series for transition to standard DWARF for Ada
(https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01857.html). There are 8
patches, each one depending on the previous one, except the 6/8 one
ing to re-visit
this. Perhaps after we resolve the local/global stuff so we know what
we really want to say.
Jeff has already checked in the patch for this menu page
I think what's left is fine. About all we really want to do is vector
folks to one of the two pages. One could argue that we sh
On 10/20/2015 01:40 PM, Segher Boessenkool wrote:
On Tue, Oct 20, 2015 at 12:01:26PM -0600, Jeff Law wrote:
On 10/20/2015 11:11 AM, Segher Boessenkool wrote:
On Tue, Oct 20, 2015 at 10:22:53AM -0600, Jeff Law wrote:
bz21182 has a testcase that's still helped by local register variables
x27;ve
changed it to r12, which works on my x64.
r12 seems fine to me.
I think with adding back the blurb about stuff we'd like to change and
a5->r12 this will be ready to go. Please send an updated patch and I'll
get it installed.
jeff
ll be switching from a development to a bugfixing
mindset shortly as the gcc6 development window closes. Hopefully
someone will take a look at this particular issue at that time.
jeff
x27;s something the callee can
rely on, particularly when interoperating with a non-GCC compiler.
Does the ABI say anything about sub-word argument handling on the caller
or callee side?
jeff
I've left the rest alone for the moment, but how would
you feel about:
"Registers are a scarce resource on most systems and allowing the"
That sounds fine.
I installed this patch from David with an update to use the "Registers
are a scarce resource ..." text.
Thanks David & Segher.
jeff
hub with detail instructions how to reproduce the results.
I don't even recall that work being on the Red Hat/Cygnus internal CVS repo.
But even if I found the code, I guess it would be easier to write it
from the scratch than make it working in the current environment.
Completely agree here.
jeff
development patches to have been posted for review, hence most folks are
busy trying to wrap up their development work.
Jeff
On 10/25/2015 09:41 PM, David Wohlferd wrote:
Does gcc's inline asm support multi-alternative constraints? Or are
they only supported for md?
The fact that it is doc'ed with the other constraints
(https://gcc.gnu.org/onlinedocs/gcc/Constraints.html) says it works for
inline. But https://gcc.gn
Joern would be the best sponsor since he's had the most interactions
with you.
jeff
ing to make any sense. Worse yet, some ports don't use "reload"
anymore, but the new code still supports ? and ! to some degree for
compatibility's sake.
We ought to bury those modifiers into the developer manual and avoid
them in the user manual completely.
jeff
rrently no one seems sure and everything is getting totally inconsistent.
I think we should move to the 3rd form when possible. I didn't even
know the language supported unnamed arguments in this way until recently :-)
Bringing some consistency to this will be nice.
jeff
to describe how the alternative is chosen from the non-md
docs. Now it just says the compiler will choose the most efficient
alternative.
Other than the line about "All operands for a single instruction must
have the same number of alternatives", the 'internals' docs (which also
includes this file) should be unaffected.
This looks fine. I'll install it momentarily.
jeff
deprecated according to
comments, my question is how to generate jump_table_data then? Is
jump_table_data not supported in emit_insn_*?
I presume you mean reorder_insns not record_insns :-)
I'd start by using reorder_insns to make sure you have your other logic
right, then look to eliminate its use.
jeff
few may be md-only, but generally folks have found that getting access
to the target's constraints to be useful in asms. I was hesitant to
document them initially because it made it much easier for someone to
setup a situation where the compiler couldn't generate correct code.
Those issues have (mostly) been fixed through the years.
Jeff
regular C programmer, sorry).
Yes, this would be fine. In fact, removing duplicates of this nature is
a good thing.
jeff
}).
They do not clobber the flags. Observe:
Ouch. i386 shows the same thing for basic asm.
Sadly, I suspect this isn't consistent across targets.
Jeff
On 11/11/2015 02:19 AM, David Wohlferd wrote:
On 11/9/2015 1:52 PM, Jeff Law wrote:
On 11/07/2015 12:50 AM, David Wohlferd wrote:
- Starting with 'modifiers', "=+&" and (reluctantly) "%" seem reasonable
for inline asm. But both "#*" seem sketchy.
sm.
Sadly, I suspect this isn't consistent across targets.
Bigger ouch. I'll follow up on this after the discussion about changing
basic asm is complete (which may render this moot).
It likely depends on how the target models the flags.
jeff
On 11/17/2015 03:07 PM, Andrew Pinski wrote:
On Wed, Nov 18, 2015 at 5:31 AM, Jeff Law wrote:
On 11/16/2015 10:55 PM, David Wohlferd wrote:
- There is no standard that says it must do this.
True. But these after all are extensions and extensions have been
notoriously under-documented
emory use in DSE, but I haven't audited the optimizers thoroughly. In
fact, the whole point behind the PR in question is there's at least one
optimizer that is missing that check.
Jeff
On 11/20/2015 04:14 AM, Andrew Haley wrote:
On 20/11/15 10:37, David Wohlferd wrote:
The intent for 24414 is to change basic asm such that it will become
(quoting jeff) "an opaque blob that read/write/clobber any register or
memory location." Such being the case, "memory&quo
o me that it would be better to remove the feature, forcing
what must be an extremely small number of users to audit and update to
extended asm.
That might be a little drastic. Though if we want to go this direction,
the first step is to deprecate for a major release cycle. It would be
interesting to see how much stuff would complain/break.
jeff
ptimizers throughout GCC. And I suspect most are getting it
wrong in one way or another.
Jeff
d
failures. This is why Jeff didn't fix this in 1999. So, if we really
do want to clobber "all" registers in basic asm it'll take a lot of
work.
Exactly. In retrospect, I probably should have generated more tests for
those conditions back in '99. Essentially they'd do
clobbering memory at the tree level
already, before expanding to RTL.
And that IMHO, ought to be considered a bug.
Jeff
On 11/23/2015 10:12 PM, Segher Boessenkool wrote:
On Mon, Nov 23, 2015 at 09:48:42PM -0700, Jeff Law wrote:
On 11/23/2015 07:22 PM, Segher Boessenkool wrote:
Here is a test that shows that on at least PowerPC the basic asm is
identical to the extended asm without clobber (compile with -O2 -S
used. Can we revert the change
until the Solaris port is correctly done?
What part of this requires bits to run? I see AC_COMPILE_IFELSE, but
not anything which obviously requires running the resulting code.
jeff
On 11/30/2015 05:25 PM, Ulrich Drepper wrote:
On Mon, Nov 30, 2015 at 6:57 PM, Jeff Law wrote:
What part of this requires bits to run? I see AC_COMPILE_IFELSE, but not
anything which obviously requires running the resulting code.
Without AC_USE_SYSTEM_EXTENSIONS one gets:
configure.ac:111
reorg
may muck up the schedule badly.
If that's the case you might test disallowing operations with > 1 cycle
latency in delay slots and see how that effects a wider range of benchmarks.
Jeff
convinced either way on that.
jeff
tely remove basic asm within functions."
I understand Richard's position and while I think it has some merit, I
think it's probably taking things too far at this time.
Jeff
ntially you've got a native toolchain, but with one or more
multilibs that can't actually be executed.
Which in turn suggests looking more closely at Matthias's suggestion.
Jeff
ding will show up in gcc-6 for the
C++ front-end.
jeff
t
that we haven't done it is simply a bug.
The fact that someone might lose the ability to do memory optimizations
across asm ("") or asm ("#") or asm ("nop") is not reason to keep the
status quo.
Sadly, I'm putting most of this discussion into my gcc-7 queue anyway.
Jeff
just fine.
And Intel's ICC.
jeff
making sure I executed the process correctly. --joel
I think we just mark them as obsolete in gcc/config.gcc for this release
and make a note in the release notes (which may not exist yet).
We'd remove the configuration bits in the next release.
jeff
ings the effective address back into the
object. That kind of scheme wrecks havoc with segmented targets where
the segment selection may be from the base register rather than the full
effective address.
jeff
port, when it's completed post it to gcc-patches where
it'll get reviewed.
It is almost always the case that for new ports, once they've addressed
the review comments, will be integrated and the developer will be named
as their official maintainer.
jeff
apologize if I'm belaboring the point here, but I think that
-Wmisleading-indentation should make use of blank lines of code.
I've posted patches to do so here, firstly here:
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03225.html
which was rejected thusly by Jeff:
I would argue that each
e proposed Fedora mass rebuild.
Jeff
nation would be to go with changing INSN to NULL though. It
seems to match the overall intent here better.
Jeff
h changing INSN to NULL though. It
seems to match the overall intent here better.
I agree and, as I said, I saw no impact on codegen for all of
SPEC2006 on arm. It just improved the testcase I described above.
I'll evaluate this patch on aarch64 and x86_64 and hopefully it has a
low impact there as well.
Sounds good.
jeff
hem off select the best and deprecate/remove the others.
I didn't follow sel-sched development closely, so forgive me if the
questions are simplistic/naive, but what are the main benefits of
sel-sched and is it at a point (performance-wise) where it could
conceivably replace the aging haifa scheduler infrastructure?
Jeff
tectures to help generate code with
fewer data dependencies and thus more opportunities to exploit the
superscalar nature of your processor.
jeff
On 01/14/2016 10:45 PM, Igor Shevlyakov wrote:
Thanks Jeff,
I really hoped that I missed something and there was better answer.
Nope, not really. Though thinking about it, you might want to look into
Bernd's work from 2012 in the haifa scheduler -- it's got some
intelligence for
se selection of the pipeline is static
based on the registers used, you have to look at this as a register
allocation problem.
You might dig out the old Cygnus releases. They may provide clues,
particularly on the register allocation tweak.
Jeff
cygnus releases of the r5900
toolchain. It had functional access to the second hi/lo register pair.
jeff
scrape together a working system with
it.
Look for a change from me in local-alloc.c, circa 1998. At least I
think that's where I had to twiddle things.
jeff
owing when the loop invariant can be forward
propagated back into the memory reference -- and for complex RTL like
you cited, you ultimately determine that no it can't be propagated and
thus increase its invariant cost?
jeff
e the case that we're not doing this properly
for indirect calls from a quick scan of m68k_function_arg.
The only way to know for sure would be to examine it under the debugger.
Jeff
somehow get at the actual
DECL called.
I think that's a good thing -- however, I suspect there's m68k backend
issues that need to be addressed here. So I think we're roughly on the
same page.
jeff
e ill-formed to a
certain degree.
jeff
? Does ppc64el actually have separate address
and data registers?
Ignore other targets. There's nothing really shared across them when it
comes to the low level implementation details of an ABI like this.
jeff
owledge that is specific to combine or is it just a
series of transformations that we could make available (preferably
moving it to simplify-rtx).
If we can factor the transformation out and shove it into simplify-rtx,
then it could be used elsewhere.
jeff
On 01/26/2016 09:36 AM, Bin.Cheng wrote:
On Tue, Jan 26, 2016 at 4:26 PM, Jeff Law wrote:
On 01/26/2016 02:28 AM, Bin.Cheng wrote:
Yes, loop invariant now increased invariant cost if the invariant
can't be propagated into address expression. Problem is we check
propagation by s
gcc side. Please
send me those and I will fill and send them back.
Contact ass...@gnu.org to get the forms you need.
Most of the time I would recommend getting past-and-future contributions
as well as an employer disclaimer.
jeff
roject, but one positive vote
against two doubtful or negative votes is not what I would call "consensus".
Given overall contribution history within the GCC project, Richi and
myself carry more weight than Thorsten & Andreas.
jeff
portable to be used on function pointers on all architectures gcc
supports. Furthermore, this hides the fact that the use case is not
supported by playing games with the optimizer, whereas Jeff and Richard
try to get this use case supported.
If gcc decides that the m68k backend should not be adjusted
gcc-bugs database.
I know someone (probably Andreas) with some work was able to get GCC
working with Ada. However, they didn't push to get all those changes
upstreamed.
It's one of the reasons why I think we should at least explore a more a
solution within GCC iteslf.
Jeff
create a chroot, populate it with build dependencies
extracted from the source package, then build within the chroot. You
can arrange to get a different glibc during instantiation of the chroot,
or upgrade it after the chroot is fully instantiated.
I'm sure there's a way to do this with containers too.
jeff
w
pseudos. Though you might also look into why something would be calling
the divmod expander after reload started -- that seems rather odd.
Jeff
ard reg was a stopgap. I don't think we've
got the level of consistency we want for PIC register as a pseudo
throughout the generic code or hte x86 backend.
My recollection is that it doesn't appear in the IL as a hard register
anymore.
jeff
se rpmlint things seem like more trouble then they're worth.
There's good reasons why a package might ship empty files.
jeff
es an error on empty files, and
sysroot-suffix.h is empty at least for m68k.
I would think the safest thing to do would be to make it a blank line.
jeff
101 - 200 of 1403 matches
Mail list logo
