some (20040709-2.c, etc.) fail with a linker error now, instead of
Hmm, packed structs. If gcc is generating mis-aligned accesses using
lwa or ld, that would be another TARGET_64BIT vs TARGET_POWERPC64
bug, wouldn't it?
I have analysed it, patch on the way. The problem is LO_SUMs of
How does that work?
The binaries have to get the all the machines of the clusters
somewhere.
Does this assume you are using NFS or similar for your build
directory?
Won't the overhead of using that instead of local disk kill most
of the
parallelization benefit of a cluster over a single
I think I found a bug in gcc 4.7.3 in gcc/caller-save.c at line 158 :
gcc_assert (cached_reg_save_code[reg][mode]);
should be :
gcc_assert (cached_reg_save_code[reg][mode] != -1);
because cached_reg_save_code contains INSN_CODES that can be equal to 0
This is PR55036.
Segher
FWIW:
__asm__(\t0:\n
\tstr wzr, [%2, #4]!\n
\tsub %1, %1, #1\n
\tcbnz %1, 0b\n
: =m(*p), +r(len) : r(p));
+r(p) as well, you're modifying %2.
Cheers,
Segher
On Tue, Jul 22, 2014 at 08:44:41AM +0100, Richard Sandiford wrote:
So why
not just stick to the current scheme and have 5.0.0, 5.0.1, 5.0.2 etc.?
Yes, why would we use a different numbering scheme now? There is no change
in development / release planning, unless I missed something. Is this
On Tue, Aug 05, 2014 at 01:32:00PM +0930, Alan Modra wrote:
On Mon, Aug 04, 2014 at 05:54:04PM -0700, Carrot Wei wrote:
Another problem is in the definition of insn pattern *movdi_internal64.
(define_insn *movdi_internal64
[(set (match_operand:DI 0 nonimmediate_operand
On Tue, Aug 12, 2014 at 04:16:34PM +0100, Kyrill Tkachov wrote:
I managed to get combine to recognise this pattern:
(set (match_operand:GPI 0 register_operand =r)
(plus:GPI (xor:GPI (neg:GPI (match_operand:GPI 1
register_operand r))
(match_operand:GPI 2
On Wed, Aug 13, 2014 at 03:57:31PM +0100, Richard Earnshaw wrote:
The problem with the frankenmonster patterns is that they tend to
proliferate into the machine description, and before you know where you
are the back-end is full of them.
Furthermore, they are very sensitive to the greedy
On Mon, Sep 22, 2014 at 05:26:04PM +0200, Jakub Jelinek wrote:
I've been considering that too, but not sure what info people find valuable
and what they don't.
The ten million Running blablablalba.exp ... messages on a very parallel
run aren't helpful in my opinion. There might be more but
On Mon, Sep 22, 2014 at 05:49:12PM +0200, Jakub Jelinek wrote:
On Mon, Sep 22, 2014 at 10:44:06AM -0500, Segher Boessenkool wrote:
On Mon, Sep 22, 2014 at 05:26:04PM +0200, Jakub Jelinek wrote:
I've been considering that too, but not sure what info people find
valuable
and what
On Thu, Oct 02, 2014 at 09:52:31PM +0200, Jan-Benedict Glaw wrote:
It seems that a full bootstrap including Ada got broken somewhere in
the range of r215789 .. r215799.
I'm bisecting it (on powerpc64-linux, where it also shows up); it needs
full bootstrapping every time, so will be another one
On Thu, Oct 02, 2014 at 07:32:10PM -0500, Segher Boessenkool wrote:
On Thu, Oct 02, 2014 at 09:52:31PM +0200, Jan-Benedict Glaw wrote:
It seems that a full bootstrap including Ada got broken somewhere in
the range of r215789 .. r215799.
I'm bisecting it (on powerpc64-linux, where it also
On Thu, Oct 23, 2014 at 06:52:20PM +0100, Charles Baylis wrote:
( tl;dr: How do I handle intrinsic or builtin functions where there
are restrictions on the arguments which can't be represented in a C
function prototype? Do other ports have this problem, how do they
solve it? Language extension
On Thu, Nov 13, 2014 at 01:14:41PM +0100, Richard Biener wrote:
It might be that RTL alias analysis / CSE give up too early here
(we don't optimize across asm() on the GIMPLE level at all ... heh).
I didn't look where it gives up (even though appearantly it does).
The cse1 pass doesn't carry
On Tue, Nov 25, 2014 at 08:18:39AM -0800, David Kang wrote:
(define_expand fix_sfsi2
The proper name is fixsfsi2, no underscore. You might want
fix_truncsfsi2 instead though.
Segher
On Tue, Nov 25, 2014 at 10:45:06AM -0800, David Kang wrote:
Is the logical operators described similarly?
I tried seqf2, cmpseqf2, and one_cmplseqf2 for eq of two floating
point numbers as it is shown below.
But none of them work.
(define_expand seqf2
[(set (match_operand:SI 0
On Thu, Dec 11, 2014 at 03:13:50PM +0800, Bin.Cheng wrote:
So I am wondering if I can rely on INSN_LUID checking orders of
difference instruction. If it can be done, I can easily differentiate
live range shrink and extend.
Further question is, if we don't insert new insns, can I use INSN_LUID
Given the age of paranoia (the version included
with RTEMS is from Cygnus circa 1993), does this
sound familiar or is this a new issue?
What happens if you use -mno-fused-madd option?
Same result for me using RTEMS on psim. Eric N. will
have to give a Mac report.
I tested it (the source
* I would like to do the same for __builtin_ctz, but there is a catch.
The synthetic ctz sequence in terms of popcount (as presently
implemented by ia64.md, and potentially usable for at least i386 and
rs6000 as well if moved to optabs.c) produces the canonical behavior at
zero, but the synthetic
I suppose you're using (assuming 32-bit)
ctz(x) := 31 - clz(x -x)
now, which gives -1 for 0; and the version you're looking for is
ctz(x) := 32 - clz(~x (x-1))
which gives 32 for 0.
(Straight from the venerable PowerPC Compiler Writer's Guide, btw).
What does the popcount
I suppose you're using (assuming 32-bit)
ctz(x) := 31 - clz(x -x)
now, which gives -1 for 0; and the version you're looking for is
ctz(x) := 32 - clz(~x (x-1))
which gives 32 for 0.
Thanks! That's, unfortunately, one more instruction, although I guess
a lot of chips have a ~b as
I think the cost would be something like:
+case POPCOUNT:
+ *total = COSTS_N_INSNS (3);
+ return false;
Is that the cost when using popcountb? It is a lot more
expensive when that instruction isn't available (like on
most current machines).
The rest (i.e. CLZ, CTZ)
I think the cost would be something like:
+case POPCOUNT:
+ *total = COSTS_N_INSNS (3);
+ return false;
Segher Is that the cost when using popcountb? It is a lot more
Segher expensive when that instruction isn't available (like on
Segher most current machines).
Yes, but
So, my open questions to the list are, what is/should be the preferred
way to bootstrap a cross compiler/glibc environment?
This likely isn't the preferred way, but the following builds
a cross toolchain for all but a few Linux targets:
$SRC/src/configure \
--target=$TARGET
4. Use the minimal cross-compiler produced in step 3 to configure
glibc and do make install-headers to get glibc headers. At this
point you should be able to delete the minimal cross-compiler, it's
job has been done.
5. Make distclean and then configure, make, and install a normal gcc
Thanks, I git cloned buildall and it sure looks simple (now that you
have made it work) :-!
Good to see it is useful to more people than just me :-)
Although, that combination of options was not exactly obvious at first
glance.
Heh. Almost all of it is just disable what we don't need.
(Stephen typoed the gcc address, forwarding)
From: Segher Boessenkool [EMAIL PROTECTED]
Date: 21 augustus 2007 17:10:30 GMT+02:00
To: Stephen M. Kenton [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Why is building a cross compiler out-of-the-box always
broken?
I got 17 minimal
Segher - If remember right, cris was one of the targets that did not
build for you. This might help.
No idea if it would help or not -- it currently dies with
an ICE while building __mulvdi3:
/home/segher/src/gcc/libgcc/../gcc/libgcc2.c: In function '__mulvdi3':
Bootstrap of current trunk on powerpc64-linux fails in libstdc++
building system_error.lo. The code that fails was added a few days
ago,
but the failure seems to be the same as the one reported in PR 31490.
I
verified that the patch from comment #10 of that PR allows bootstrap of
load r3, q + 0
load r4, q + 4
store r3, p + 0
store r4, p + 4
load r3, q + 4
load r4, q + 8
store r3, p + 4
store r4, p + 8
These last four lines should be
load r3, q + 8
load r4, q + 12
store r3, p + 8
store r4, p + 12
Did you just typo it or do you have a
The Linux kernel, and probably some user-space applications and
libraries
as well, depend on GCC guaranteeing (a variant of) the following:
any access to a naturally aligned scalar object in memory
that is not a bit-field will be performed by a single machine
instruction
This seems somewhat like other issues we have dealt with concerning
thread safety. Perhaps an entire section addressing code generation
issues related to correct multi-threaded semantics.
I like that idea. But, we need to decide what those correct semantics
_are_.
Or we can wait for that to
The Linux kernel, and probably some user-space applications and
libraries
as well, depend on GCC guaranteeing (a variant of) the following:
any access to a naturally aligned scalar object in memory
that is not a bit-field will be performed by a single machine
instruction
The Linux kernel, and probably some user-space applications and
libraries
as well, depend on GCC guaranteeing (a variant of) the following:
any access to a naturally aligned scalar object in memory
that is not a bit-field will be performed by a single machine
instruction
The Linux kernel, and probably some user-space applications and
libraries
as well, depend on GCC guaranteeing (a variant of) the following:
any access to a naturally aligned scalar object in memory
that is not a bit-field will be performed by a single machine
instruction
As I said before, I think any words of this form SHOULD NOT be added.
All it does is add words to the documentation that provide NO
guarantee of anything -- but in a way that will confuse those who
don't read it carefully enough into thinking that they DID get some
sort of guarantee.
The idea
The online docs at
http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Other-Builtins.html
has a confusing (to me) example of __builtin_expect. Could someone
take a look at this?
start quote from above-referenced page
Since you are limited to integral expressions for exp, you should
use
Hi Jon,
I'd like to try to optimise double word left shifts of sign/zero
extended
operands if a widening multiply instruction is available. For the
following
code:
long long f(long a, long b)
{
return (long long)a b;
}
I'd like to optimise this to something like:
(long long) a * (1
I just discovered a behaviour in gcc-4, which I don't understand: code
unsigned int x;
if (x 0)
do_something();
compiled with -Wall doesn't produce a warning, and the call to
do_something() is silently dropped, whereas if x is of type unsigned
char,
I get as
I'm suggesting that there's no big difference between unsigned char and
unsigned int (and unsigned long...) in this case, and, therefore
compiler's behaviour should be consistent.
But there is a difference.
When x is an unsigned int, the expression x 0 is equivalent to
(unsigned int)
FAIL: gcc.target/powerpc/ppc-and-1.c scan-assembler rlwinm [0-9]+,
[0-9]+,0,0,30
FAIL: gcc.target/powerpc/ppc-and-1.c scan-assembler rlwinm [0-9]+,
[0-9]+,0,29,30
FAIL: gcc.target/powerpc/ppc-negeq0-1.c scan-assembler-not cntlzw
are a tad confusing because if I do...
gcc-4 -O2 -m64 -S -c
GCC passes a linker script to the linker for some
targets (e.g., powerpc-eabi with -mads). If you specify a
linker script using -Wl,-T,script.ld, you get both
passed to the linker and there may be conflicts.
Is there any option to GCC which says to not pass
the predefined linker script to the
If you use your own linker scripts, you really shouldn't use gcc
to do the linking step; call ld directly, instead. gcc has no
idea what your linker script does, so it might well call ld with
the wrong options...
There are a number of targets which pass linker scripts
to ld, along with
A linker script passed to the gcc driver should override the one
which the driver would pass by default.
Yes, and if current GCC has some problems with that, those bugs should
be fixed. Sorry if I gave the impression that this would be user
error.
The linker script which is
specified must
Probably no one uses these old processors anymore, and support for them
is getting in the way of other work in the rs6000 port.
Let's remove it in 4.6. Okay?
Segher
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.5/changes.html,v
retrieving revision 1.90
diff -u -r1.90 changes.html
--- changes.html
Please make another attempt at the language of the statement without
editorializing about the name of the port.
Sorry about that. Like this?
Segher
diff -u -p -r1.90 changes.html
--- changes.html27 Apr 2010 13:53:21 - 1.90
+++ changes.html28 May 2010 04:09:20 -
[Now using the text suggested by David.]
Probably no one uses these old processors anymore, and support for them
is getting in the way of other work in the rs6000 port.
Let's remove it in 4.6. Okay?
Segher
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.5/changes.html,v
retrieving revision 1.90
Hi all,
Jeremy has set up a Patchwork instance for us at
http://patchwork.ozlabs.org/project/gcc/list/ .
It is feeding from gcc-patches; the plan is to make it
automatically recognise what patches went into the tree,
probably by snooping the gcc-cvs list.
You can also manually change patch
It is feeding from gcc-patches; the plan is to make it
automatically recognise what patches went into the tree,
probably by snooping the gcc-cvs list.
This is quite interesting, thanks for setting it up.
All kudos go to Jeremy, I merely try to push people :-)
I can see already that to be
Yes it does. If you tell us how the git pots-commit hook works, we
could try to implement a version for svn and GCC.
This is what I've used for git:
[...@pororo helloworld]$ cat .git/hooks/post-applypatch
#!/bin/bash
sha=$(git rev-parse HEAD)
hash=$(git show $sha
Two things: 1) we should make the [bracket] prefixes more standard for
patches destined to feature branches;
Another point about (1): I believe patchwork should *not* track most of
the branch patches, and the commit detection shouldn't care about
release branch commits, only trunk. This is
[I proposed removing RIOS support, since it heavily gets in the way
for my project exposing the XER[CA] flag].
My argument is simply this, sorry if it wasn't clear in the last
email, bottom line up front:
- It can just as easily be removed in the future if it is broken for
more than one release
Actually, I was thinking about the case g(a(), b());.
Let's imagine the gimplified code (because of your change) looks like:
t1 = a();
t2 = b();
g(t1, t2);
Are we always sure that t1 and t2 will not be pushed again in the
CALL_EXPR by further transformations?
No, and that's a good thing.
Do you think - theoretically - that a compiler could help compiling
software, which would in turn use the power of the GPU to make some of
the computations?
Theoretically -- yes. Of course. But...
Like now we have compiler options like -mmmx -msse -msse2 -msse3
-m3dnow - would it be possible
There is a typo in french translation of error messages (at least in
4.0 release and in 4.1 snapshot of 05/05/15).
It affects gcc/po/fr.po and libcpp/po/fr.po :
sasn effet should be sans effet
sasn lien should be sans lien
(The word sasn does not exist in french language).
Yep. But translations
There's also a fair amount of code whih relies on -1 ==
(int)0x.
Or is there any truly portable and efficient way to convert a sequence
of bytes (in big-endian order) to a signed integer?
Of course there is. Assuming no padding bits:
int conv(unsigned char *c)
{
unsigned int
Better use a union for the (final) conversion, i.e
int conv(unsigned char *c)
{
unsigned int i;
union {
unsigned int u;
int i;
} u;
u.u = 0;
for (i = 0; i sizeof u; i++)
u.u = (u.u 8) + c[i];
return u.i;
}
This is not portable, though;
The question is in fact: what is a section for GCC? Is it just a way
to
group functions together to improve memory cache efficiency; or is the
GCC user authorised to use sections to forbid access to some functions
at link time?
For user-declared (attribute) sections, GCC just outputs
the
It could still be done, even if we inline.
There is nothing that prevents us from adding space to the stack
allocation only at that point, it's just not coded in gcc to do that.
...and take the stack alloc back after the inlined call is finished.
This is what the original example needs; it
| Beyond the -Werror would have barfed rationale, I have more
evidence
| that %p works everywhere we host GCC. If you look at the sources,
| there are already a few uses of %p that have snuck in. So if it was
a
| problem we would have known by now.
|
| Do we assert for any other C90 features
On 10 sep 2005, at 02:03, Richard Henderson wrote:
On Sat, Sep 10, 2005 at 01:00:04AM +0930, Alan Modra wrote:
2) Next, I defined parallels to keep things together. Like the
following, with another for DImode.
This seems most reasonable to me.
Especially as the ABI states that the write
Especially as the ABI states that the write of the backlink
and the stack pointer update _have_ to be done in one insn.
That's on allocation. Deallocation isn't so critical. You just need
to
ensure the backchain is written before updating sp.
Yes, but your example generated code showed
int f(int *);
int verbosity;
int *arr;
int last;
void g ()
{
int i;
if (last 4000) {
if (verbosity = 4) f(verbosity);
for (i = 0; i = last; i++) arr[i] = i;
}
}
If last != 0, arr+i cannot point to last for any i,
as last is not part of
Is there any reasonably simple way to find out why the C++ version is
slower? I can use something like oprofile, of course, but I thought
gcc can
somehow give statistics about its internal times, which might be
more useful
for a first approximation.
I think you're thinking about the -Q
1c1ebc41fca45f497e019a5ab433c68d23010f31 Mon Sep 17 00:00:00 2001
Message-Id:
1c1ebc41fca45f497e019a5ab433c68d23010f31.1422864485.git.seg...@kernel.crashing.org
From: Segher Boessenkool seg...@kernel.crashing.org
Date: Sat, 12 Oct 2013 15:41:50 -0700
Subject: [PATCH] Make mergeable read-only sections per-function
On Fri, Mar 13, 2015 at 11:36:47PM +0300, Max Filippov wrote:
2. alloca seems to make an additional 16-bytes padding to each stack
allocation: alloca(1) results in moving sp down by 32 bytes, alloca(17)
moves it by 48 bytes, etc.
This sounds like PR 50938, 47353, 34548, maybe more?
On Fri, Mar 13, 2015 at 05:54:48PM +0300, Max Filippov wrote:
2. alloca seems to make an additional 16-bytes padding to each stack
allocation: alloca(1) results in moving sp down by 32 bytes, alloca(17)
moves it by 48 bytes, etc.
This sounds like PR 50938, 47353, 34548, maybe more?
On Thu, Mar 12, 2015 at 03:09:52PM -0700, David Wohlferd wrote:
Ahh. So perhaps as I suspected: this is more commonly used on non-i386
platforms. So clearly removing this is out of the question.
glibc uses it for PowerPC and s390 at least (I only grepped for 3,
quotes included -- there may
On Tue, Apr 21, 2015 at 12:27:40AM +0200, Steven Bosscher wrote:
On Mon, Apr 20, 2015 at 10:11 PM, Vladimir Makarov wrote:
I might be wrong but I think you have a bloated code because you use
scratches. I already told several times that usage of scratch is always a
bad idea. It was a bad
On Tue, Apr 21, 2015 at 11:55:33PM -0400, Vladimir Makarov wrote:
The combiner can add or remove clobbers of scratches whenever needed,
but it cannot do that for clobbers of pseudos.
Yes, I think there are some pitfalls with scratches in other passes.
Probably. But this one is documented
On Mon, May 04, 2015 at 12:33:38PM -0700, Richard Henderson wrote:
(1) Each target defines a set of constraint strings,
(2) A new target hook post-processes the asm_insn, looking for the
new constraint strings. The hook expands the condition prescribed
by the string, adjusting the
On Tue, May 05, 2015 at 08:37:01AM -0700, Linus Torvalds wrote:
On Tue, May 5, 2015 at 6:50 AM, Segher Boessenkool
seg...@kernel.crashing.org wrote:
Since it is pre-processed, there is no real reason to overlap this with
the constraints namespace; we could have e.g. =@[xy] (and @[xy
On Fri, Apr 03, 2015 at 09:25:57AM -0600, Jeff Law wrote:
On 04/03/2015 07:45 AM, Diego Novillo wrote:
Not quite. The output of the debug dumpers is not really meant to be fed
back to the compiler. They are debug dumps only. They do not contain
enough information for code generation or
On Fri, May 29, 2015 at 12:09:42AM +0930, Alan Modra wrote:
It's really annoying when you fix a combine bug and get worse code..
Heh. You've been on the receiving end of that a lot lately :-/
void foo (signed char *p) { if (*p != 0) *p = 1; }
before after
foo:
On Fri, May 29, 2015 at 12:41:20PM +0930, Alan Modra wrote:
I'll tell you one of the reasons why they are
slower, as any decent hardware engineer could probably figure this out
themselves anyway. The record form instructions are cracked into two
internal ops, the basic arithmetic/logic op,
On Fri, May 29, 2015 at 11:20:08PM +0930, Alan Modra wrote:
On Fri, May 29, 2015 at 07:58:38AM -0500, Segher Boessenkool wrote:
On Fri, May 29, 2015 at 12:41:20PM +0930, Alan Modra wrote:
+/* Describe how rtl operations on registers behave on this target when
+ operating on less than
On Mon, Jun 01, 2015 at 11:33:18AM +0930, Alan Modra wrote:
Unifying andsi_mask with anddi_mask, and the fact that constraints for
const_int see VOIDmode rather than the operand mode is why we get
rldicr rather than rlwinm. Easily fixed by separating the si/di
patterns, and with a little more
On Tue, Jun 02, 2015 at 08:49:37AM +0930, Alan Modra wrote:
In andmode3 expander I think you want the following since
and64_2_operand covers the extra double-rotate cases, not all DImode.
- if ((MODEmode == DImode !and64_2_operand (operands[2],
MODEmode))
- || (MODEmode
On Sat, May 30, 2015 at 10:47:27AM +0930, Alan Modra wrote:
I think this is too simplistic though. For example, AND with -7 is not
zero-extended (rlwinm rD,rA,0,31,28 sets the high 32 bits of rD to the
low
32 bits of rA).
We take some pains in rs6000.md to ensure that the
On Mon, Jun 29, 2015 at 05:16:39PM +0930, Alan Modra wrote:
Note that we already have insn_rtx_cost, and it returns a minimum cost
for a SET, so register move insns get a cost of 1 insn. However,
despite insn_rtx_cost starting life in combine.c, even combine doesn't
use it in all whole insn
On Mon, Jul 06, 2015 at 04:45:35PM -0400, DJ Delorie wrote:
Combine gets as far as this:
Trying 5 - 9:
Failed to match this instruction:
(parallel [
(set (mem/v/j:QI (const_int 240 [0xf0]) [0 MEM[(volatile union
un_per0 *)240B].BIT.no4+0 S1 A16])
(ior:QI (mem/v/j:QI
On Thu, May 21, 2015 at 08:06:04PM +0930, Alan Modra wrote:
FAIL: gcc.target/powerpc/ti_math1.c scan-assembler-times adde 1
is seen on powerpc64le-linux since somewhere between revision 218587
and 218616. See
https://gcc.gnu.org/ml/gcc-testresults/2014-12/msg01287.html and
On Thu, May 21, 2015 at 11:34:14AM -0700, Richard Henderson wrote:
On 05/21/2015 05:39 AM, Segher Boessenkool wrote:
Trying 18, 9 - 24:
Failed to match this instruction:
(set (reg:DI 4 4 [+8 ])
(plus:DI (plus:DI (reg:DI 5 5 [ val+8 ])
(reg:DI 76 ca
On Fri, May 22, 2015 at 11:48:42AM +0930, Alan Modra wrote:
I think we should add to
the canonicalisation rules so that fixed regs sort after other regs.
That requires a lot of testing.
What if you have two hard regs as above? Which of reg 5 and reg 76
sorts first? If they are sorted
On Mon, Jul 06, 2015 at 04:58:36PM -0500, Segher Boessenkool wrote:
On Mon, Jul 06, 2015 at 04:45:35PM -0400, DJ Delorie wrote:
Combine gets as far as this:
Trying 5 - 9:
Failed to match this instruction:
(parallel [
(set (mem/v/j:QI (const_int 240 [0xf0]) [0 MEM[(volatile
On Tue, Jul 07, 2015 at 07:53:49PM +0200, Martin Jambor wrote:
I've been asked to look into the item one of
http://permalink.gmane.org/gmane.linux.kernel/1990397 and found out
that at least shrink-wrapping happily moves prologue past an asm
statement which can be bad if the asm statement
On Sun, Aug 16, 2015 at 06:33:40PM -0700, David Wohlferd wrote:
On systems where an underscore is normally prepended to the name of a C
-function or variable, this feature allows you to define names for the
+variable, this feature allows you to define names for the
linker that do not start
On Sun, Aug 16, 2015 at 06:33:40PM -0700, David Wohlferd wrote:
As a followup to my update to the inline asm docs, I'm cleaning up the
docs for 'Asm Labels.' The changes I want to make are pretty
straight-forward (attached; comments welcome). But then I came across
this line of code (from
On Wed, Aug 19, 2015 at 02:08:16PM -0700, David Wohlferd wrote:
My intent here is to break this clearly into two @subsubheadings:
'Assembler names for data' and 'Assembler names for functions'. Since
data is the first section, I removed the word 'function' here.
I missed that, sorry. Or, did
On Mon, Aug 17, 2015 at 09:55:48PM -0700, David Wohlferd wrote:
On systems where an underscore is normally prepended to the name of a C
-function or variable, this feature allows you to define names for the
+variable, this feature allows you to define names for the
linker that do not start
On Fri, Aug 21, 2015 at 07:54:11PM -0400, David Malcolm wrote:
In the git world, the first line of the commit message has special
meaning, being treated as the title of the commit.
It would be nice if we could use a real commit message, not just a short
title line; for example,
On Wed, Aug 19, 2015 at 11:02:14PM -0700, David Wohlferd wrote:
how about replacing the existing
text (It does not make sense to use this feature with a non-static
local variable since such variables do not have assembler names.) with
Do not use this feature with a non-static local variable.
On Sun, Aug 23, 2015 at 12:26:25PM -0400, Eric S. Raymond wrote:
One way to do it would be to mine the list archives for not just names
but name-date pairs. With a little scripting work that could be processed
into a sequence of map files, each one valid for a known span of dates. The
only
On Sat, Aug 22, 2015 at 10:59:31AM -0400, David Malcolm wrote:
+pThe log message for a checkin should be a single line giving a
+descriptive title for the checkin, followed by a blank line, followed by
+the complete ChangeLog entry for the change. This is the git convention;
+giving
On Thu, Aug 20, 2015 at 03:31:52PM -0400, David Malcolm wrote:
If we're going to migrate to git (I hope so), can we also please
*slightly* revise the policy on commit messages, to add meaningful
titles to commits?
Currently:
https://www.gnu.org/software/gcc/svnwrite.html#checkin says:
On Tue, Jun 30, 2015 at 02:16:19PM +0930, Alan Modra wrote:
On Mon, Jun 29, 2015 at 09:34:40AM -0500, Segher Boessenkool wrote:
On Mon, Jun 29, 2015 at 05:16:39PM +0930, Alan Modra wrote:
Note that we already have insn_rtx_cost, and it returns a minimum cost
for a SET, so register move
On Thu, Oct 22, 2015 at 12:38:16AM -0700, David Wohlferd wrote:
> An updated Local Register Variables patch is attached with the changes
> discussed. It also includes removing the extra space after '.' that
> Segher has been giving me grief about and Jeff's request re Globals:
You must have
On Tue, Oct 20, 2015 at 09:14:51PM -0700, David Wohlferd wrote:
> >Abot the patches themselves... Hard to review again, sigh...
>
> I know, and I'm sorry.
>
> I just can't see any way to completely re-org the text without the patch
> becoming a nightmare. I was hoping the html links would
On Sun, Nov 08, 2015 at 04:10:01PM -0800, David Wohlferd wrote:
> It seems like a doc update is what is needed to close PR24414 (Old-style
> asms don't clobber memory).
What is needed to close the bug is to make the compiler work properly.
Whether that means clobbering memory or not, I don't
On Fri, Nov 06, 2015 at 03:29:43PM -0700, Jeff Law wrote:
> It's never easy to predict whether or not something like this will be
> contentious. Worst case is you post, it's contentious, we iterate a bit
> and reach some kind of resolution (ok, worst case is no resolution is
> reached, but
1 - 100 of 6713 matches
Mail list logo
