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
The avr-rtems port will not build using a trunk compiler on a system
with a reasonably modern glibc.
If we look at newlib-stdint.h, we have these wonderfully convoluted
conditionals like:
#define INT8_TYPE (CHAR_TYPE_SIZE == 8 ? "signed char" : 0)
They get more complex, but essentially they
On 10/13/2015 07:12 AM, Dominik Vogt wrote:
In some cases, the work of the cse1 pass is counterproductive, as
we noticed on s390x. The effect described below is present since
at least 4.8.0. Note that this may not become manifest in a
performance issue problem on all platforms. Also note that
On 10/14/2015 09:16 AM, Luke A. Guest wrote:
I forgot, I'm not interested in using C, so SDCC is out of the question.
I don't think anyone is actively developing a Z80 port for the trunk.
I spec'd one out a long time ago for Cygnus/Red Hat, but we never
pursued the port. The register model o
On 10/13/2015 03:03 PM, Vladimir Makarov wrote:
I checked my article
ftp://ftp.uvsq.fr/pub/gcc/summit/2004/Fighting%20Register%20Pressure.pdf
and GVN gave mostly 0.2% on eon only. The current environment is quite
different (IRA, LRA) so the results might be different too.
Yea, but if anyth
On 10/12/2015 04:06 PM, David Wohlferd wrote:
Note that there is nothing actually "wrong" with the existing text. It
does not provide inaccurate information or miss key details. The
problem is that (from a compiler user's point of view) the text is hard
to follow. It reads as though people just
On 10/12/2015 05:07 PM, David Wohlferd wrote:
- There are unsourced, unsubstantiated reports that on some platforms,
certain things might or might not work.
Back when this was written (circa 1996), this would have been considered
helpful information -- having a system routine clobber a register
On 10/19/2015 03:42 PM, Segher Boessenkool wrote:
+After defining a global register variable, for the duration of
+the current compilation:
It's probably better to say "for the current compilation unit"? There now
is LTO and whatnot.
Which raises the question, what happens for LTO? Do we stre
On 10/12/2015 05:09 PM, David Wohlferd wrote:
Patch 3/3 is the update for the Local Register Variables page (attached).
This patch starts with a question. Looking at bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64951 (register variable
with template function) is this a bug that will be fixe
On 10/19/2015 03:55 PM, Segher Boessenkool wrote:
On Mon, Oct 12, 2015 at 04:09:34PM -0700, David Wohlferd wrote:
I was hoping to modify the text to say that local register variables can
"only" be used to call Extended asm. This would greatly simplify this
section.
But it is not true: they ca
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
On 10/20/2015 03:43 AM, Konstantin Vladimirov wrote:
Hi,
--- sched-int.h ---
/* Information about the dependency. */
struct _dep
{
struct dep_replacement *replace;
};
typedef dep_def *dep_t;
--- sched-deps.c ---
static void
copy_dep (dep_t to, dep_t from)
{
memcpy (to, from,
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
On 10/20/2015 09:42 AM, Pierre-Marie de Rodat wrote:
Hi Richard,
On 10/16/2015 05:09 AM, Richard Biener wrote:
This means it is time to get things you want to have in GCC 6 finalized
and reviewed. As usual there may be exceptions to late reviewed features
but don't count on that. Likewise tar
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
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 the asm statements.
OK, but this usage did work in the past: that it now doesn't is a
regression.
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
On 10/20/2015 10:14 PM, 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 make that
easier, but I guess not
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
On 10/20/2015 10:16 PM, David Wohlferd wrote:
- Eventually the compiler may work differently than it does now.
That is helpful. It's a way signaling that things may change and that
depending on the precise syntax and semantics may be unwise.
From time to time, particularly with GCC extension
On 10/20/2015 10:35 PM, David Wohlferd wrote:
> Given the way the optimizers and register allocation work,
> I don't think we can make guarantees around [Andrew's] use
> of the feature. It happens to still work and may work
> forever, but I'm not going to set it in stone.
If the only usage
On 10/20/2015 02:26 PM, Steve Ellcey wrote:
I have a question about the TARGET_PROMOTE_PROTOTYPES macro. This macro
says that types like short or char should be promoted to ints when
passed as arguments, even if there is a prototype for the argument.
Now when I look at the code generated on MI
On 10/21/2015 05:27 AM, Segher Boessenkool wrote:
On Tue, Oct 20, 2015 at 09:24:48PM -0700, David Wohlferd wrote:
+Registers can be a limited resource on some systems and allowing the
They are a limited resource on almost all systems. "Scarce resource"?
"Scarce" it is. I've left the rest al
On 10/22/2015 09:08 AM, Vladimir Makarov wrote:
On 10/22/2015 06:05 AM, Dominik Vogt wrote:
On Tue, Oct 13, 2015 at 05:03:36PM -0400, Vladimir Makarov wrote:
[snip]
I checked my article
ftp://ftp.uvsq.fr/pub/gcc/summit/2004/Fighting%20Register%20Pressure.pdf
and GVN gave mostly 0.2% on eon on
On 10/22/2015 01:38 AM, 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:
> Signaling that this stuff may change
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
On 10/28/2015 08:30 AM, Claudiu Zissulescu wrote:
Hello,
I am working on ARC GCC backend and I have a number of successful
contributions. To easy up my interaction with the ARC maintainer, I would like
to apply for the write after approval right. However, it is unclear for me who
will be the
On 10/30/2015 09:09 PM, David Wohlferd wrote:
I have updated the non-md text with (most of) the changes I think it
needs (attached). These changes are pleasantly minor, mostly just
adding some example text and a bit of formatting.
However. Trying to actually use the information on this page i
On 11/05/2015 02:32 AM, Bernd Schmidt wrote:
When reviewing patches I'm never quite sure which of the following we
should be using:
some_target_hook (tree decl, machine_mode mode ATTRIBUTE_UNUSED)
some_target_hook (tree decl, machine_mode ARG_UNUSED (mode))
some_target_hook (tree decl, machine
On 11/02/2015 11:30 PM, David Wohlferd wrote:
I think the fundamental problem here is we ought not be exposing those
modifiers to the user. They're inherently tied to the details of the
register allocation and reloading passes.
This is what I'm thinking as well.
I agree.
The only reason I d
On 11/08/2015 11:20 PM, Bin.Cheng wrote:
Hi,
I used below code snippet to generate jump_table_data:
//setup label refs
start_sequence ();
emit_jump_table_data(gen_rtx_
ADDR_DIFF_VEC (CASE_VECTOR_MODE,
base_label_ref,
label_refs...))
insns = get_insns ();
end_sequence
On 11/07/2015 12:50 AM, David Wohlferd wrote:
- Starting with 'modifiers', "=+&" and (reluctantly) "%" seem reasonable
for inline asm. But both "#*" seem sketchy.
Right. =+& are no-brainer yes, as are the constants 0-9. % is probably
OK as well.
#* are similar to !? in that they are inhere
On 11/10/2015 07:46 PM, Bradley Lucier wrote:
The routines declared as
static bool
is_too_expensive (const char *pass)
in both cprop.c and gcse.c are identical except for two comment lines.
I'd like to modify is_too_expensive, which implied to me that there
should be only one copy of the routi
On 11/15/2015 06:23 PM, David Wohlferd wrote:
On 11/9/2015 1:32 AM, Segher Boessenkool wrote:
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
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.
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 through the years.
- I'm only aware of 1 person who has ever asked for this change. And the
request
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
On 11/17/2015 06:28 PM, Segher Boessenkool wrote:
_Does_ basic asm as currently implemented have a memory clobber? If not,
it seems we can just remove basic asm completely and everything would
still work the same!
You'd have to dig into the various optimizers -- I know that it has a
memory use
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" is not sufficient:
#d
On 11/20/2015 06:05 AM, Richard Henderson wrote:
I'd be perfectly happy to deprecate and later completely remove basic
asm within functions.
Because IMO it's essentially useless. It has no inputs, no outputs, and
no way to tell the compiler what machine state has been changed. We can
say tha
On 11/20/2015 07:56 AM, Segher Boessenkool wrote:
When basic asm changes, I expect that having a way to "just do what it
used to do" is going to be useful for some people.
24414 says the documented behaviour hasn't been true for at least
fourteen years. It isn't likely anyone is relying on tha
On 11/23/2015 03:04 AM, Andrew Haley wrote:
On 21/11/15 12:56, David Wohlferd wrote:
So, what now?
While I'd like to take the big step and start kicking out warnings for
non-top-level right now, that may be too bold for phase 3. A more
modest step for v6 would just provide a way to find them (
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 and
-fno-ipa-icf if you want to have it easier to read). In this case,
the basic asm is treated as not clobber
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
On 11/28/2015 08:42 AM, Ulrich Drepper wrote:
After the Solaris vtv port was added my build of the x86 gcc with x32
support fails. The build is special since the kernel doesn't have x32
support and I cannot directly run x32 binaries (they are run in a kvm
kernel). This is used to work well by c
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
On 12/01/2015 02:11 PM, Steve Ellcey wrote:
With the current top-of-tree we now generate:
addiu $4,$4,1
$L8:
lbu $3,-1($4)
addiu $5,$5,1
beq $3,$0,$L7
lbu $2,-1($5) # This is a branch delay slot
beq $3,$2,$L8
addiu
On 12/01/2015 04:25 PM, Joseph Myers wrote:
On Tue, 1 Dec 2015, David Wohlferd wrote:
Saying it's dead in the docs is the first step to making it dead in the code.
This patch just implements an optional warning (unless #3,4 crank it up to a
default warning), but the intent is that eventually (v
On 12/01/2015 03:29 PM, David Wohlferd wrote:
On 11/30/2015 4:01 AM, Andrew Haley wrote:
>> There is a way for people to be clear about what they want to clobber,
>> and that's to use extended asm. The way to clear up the ambiguity
is to
>> start deprecating basic asm, not to add to the confu
On 12/01/2015 07:17 AM, Ulrich Drepper wrote:
On Tue, Dec 1, 2015 at 2:39 AM, Matthias Klose wrote:
that might be another instance of
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02064.html
Does something like this help?
No, same problem as before. This macro doesn't actually generate any
c
On 12/08/2015 12:32 PM, Jodi A. Miller wrote:
Good Afternoon,
My colleagues and I are doing a study on compilers. We have some
questions related to gcc and the compilation process that we were
hoping you could help us with.
In a general sense, we were wondering what optimizations may be
occurr
On 12/15/2015 01:42 PM, paul_kon...@dell.com wrote:
On Dec 15, 2015, at 7:52 AM, Bernd Schmidt
wrote:
On 12/14/2015 09:10 AM, Segher Boessenkool wrote:
That, and adding a memory clobber degrades performance for a lot
of existing basic asm that does not expect the clobber, e.g.
asm(""), asm("
On 12/17/2015 03:39 AM, Andrew Haley wrote:
On 17/12/15 01:41, David Wohlferd wrote:
On the contrary, I would be surprised to learn that there are ANY
compilers (other than clang) that support gcc's extended asm format.
Prepare to be surprised: Sun Studio compilers seem to support it
just fine
On 01/04/2016 02:01 PM, Joel Sherrill wrote:
Hi
It has come time for RTEMS to obsolete three targets: avr-rtems*,
h8300-rtems*, and m32r-rtems* in gcc and binutils. They have been
removed from the RTEMS master.
Since we were dealing with more than one, I thought I would ask for
advice on making
On 01/06/2016 08:17 AM, Ian Lance Taylor wrote:
The bug report https://golang.org/issue/13662 describes a case in
which ivopts appears to be breaking garbage collection for the Go
compiler. There is an array allocated in memory, and there is a loop
over that array. The ivopts optimization is ta
On 01/05/2016 09:34 PM, Nguyễn Sinh Ngọc wrote:
Now, I'm planning to make a GCC port for a new 8 bits
microcontroller. And I want to add it into official GCC source. But
the normal account not have the privilege to add a new target through
git.
Can you tell me how to do this?
Develop your port,
On 01/11/2016 07:53 AM, David Malcolm wrote:
In Chapter 31 of "Code Complete" (I'm looking at the 2nd edition),
McConnell discusses the use of whitespace in code layout; he talks about
both blank lines and indentation as being useful for providing hints to
the human reader about the structure o
On 01/13/2016 06:17 AM, Matthias Klose wrote:
Here are some first results from a distro test rebuild using GCC 6. A
snapshot of the current Ubuntu development series was taken on 20151218
for all architectures (amd64, arm64, armhf, i386/i686, powerpc, ppc64el,
s390x), and rebuilt unmodified using
On 01/13/2016 04:33 AM, Kyrill Tkachov wrote:
I've been able to get it to do the right thing by changing the line
where it initially folds the source of the SET. That is line 4639 in
cse.c: /* Simplify and foldable subexpressions in SRC. Then get the
fully- simplified result, which may not nece
On 01/14/2016 03:15 AM, Kyrill Tkachov wrote:
There are cases where calls to fold_rtx with a non-NULL insn don't
end up modifying src, ending up in src to not be always equal to
src_folded (I added an assert to that effect and saw it trigger). It
seems that fold_rtx is not *guaranteed* to modify
On 01/14/2016 12:07 AM, Andrey Belevantsev wrote:
Hello Bernd,
On 13.01.2016 21:25, Bernd Schmidt wrote:
There are a few open PRs involving sel-sched, and I'd like to start a
discussion about removing it. Having two separate schedulers isn't a very
good idea in the first place IMO, and since ia
On 01/14/2016 04:47 PM, Igor Shevlyakov wrote:
Guys,
I'm trying to make compiler to generate better code on superscalar
in-order machine but can't find the right way to do it.
Imagine the following code:
long f(long* p, long a, long b)
{
long a1 = a << 2;
long a2 = a1 + b;
return p[a1
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 dependency br
On 01/19/2016 05:04 AM, Woon yung Liu wrote:
Hi,
I'm am trying to complete support for the MIPS R5900, by adding support for its
second
interger multiplication/division pipe. GCC currently supports only the first
one.My target at this moment is the public GCC v5.3.0 release.
To get the 2
On 01/19/2016 04:59 AM, Woon yung Liu wrote:
In my current attempt at adding support for the TI mode, the MMI
definitions are added into a MD file for the R5900 and some functions
(i.e. mips_output_move) were modified to allow certain moves for the
TI mode of the R5900 target. However, while it
On 01/19/2016 09:22 AM, Woon yung Liu wrote:
Right now, I do have an old homebrew GCC v3.2.2 port to study as
well, but I didn't follow everything from it because I didn't want to
risk including obsolete constructs. Thanks for the information on the
old Cygnus port. I'll try to scrape together
On 01/25/2016 11:42 AM, Bin.Cheng wrote:
Yuri Rumyantsev suggested we may add a hook to handle GOT related
instruction propagation specially so it won't be hoisted out. Is a
hook at this stage sounds feasible?
I think that would be a mistake. ISTM this really needs to be cost driven.
Also
On 01/26/2016 12:01 AM, Richard Biener wrote:
On January 25, 2016 10:47:10 PM GMT+01:00, Michael Karcher
wrote:
Hello gcc developers,
as discussed in https://ghc.haskell.org/trac/ghc/ticket/11395 (and
forwarded as PR c/69221), ghc generates non-compliant C code that is
not
compiled as intende
On 01/26/2016 01:41 AM, Richard Biener wrote:
What I wanted to say is that we preserve the function type used for
the actual call at least until RTL expansion in gimple_call_fntype.
I fixed most of the call expansion code to honor that but back ends
may of course screw up as they still may someh
On 01/26/2016 02:21 AM, John Paul Adrian Glaubitz wrote:
Hi Richard!
On 01/26/2016 08:01 AM, Richard Biener wrote:
I developed a gcc patch that does not change the code generation for
conforming programs but fixes this non-conforming use-case by always
taking the actual return type in the call
On 01/26/2016 03:59 AM, John Paul Adrian Glaubitz wrote:
On 01/26/2016 11:07 AM, Andreas Schwab wrote:
John Paul Adrian Glaubitz writes:
Having gcc allow to work with such code would actually allow us
to bootstrap ghc on m68k again which would be awesome :).
The ghc code just needs to be fi
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 simply replacing use with def in memory reference then
verifying result insn with verify_changes. Apparently
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
On 01/21/2016 11:04 AM, Shiv Shankar Dayal wrote:
Hi,
I am a C/C++ programmer with 10 years of professional programming
experience. I have been using gcc since version 2.
I am not a compiler expert but would like to start contributing to gcc
for which I need forms which require submission from
On 01/27/2016 02:40 PM, Michael Karcher wrote:
On 27.01.2016 11:33, Richard Biener wrote:
On Tue, Jan 26, 2016 at 9:54 PM, Michael Karcher
wrote:
On 26.01.2016 21:47, Richard Biener wrote:
I would still prefer the more obvious approach of using the target hook
transition.
I intended to exp
On 01/27/2016 03:07 PM, Michael Karcher wrote:
Why can't ghc produce code like:
int bar ()
{
int (*foo1)() = foo;
asm("":"+r"(foo1));
return foo1();
}
Thank you for the first suggestion about what ghc can do to avoid the
problem without the need to change the internally used Cmm languag
On 01/28/2016 03:11 AM, Florian Weimer wrote:
On 01/27/2016 04:17 PM, Richard Biener wrote:
We are trying to support
t.c
---
void *foo();
int bar()
{
return ((int (*)())foo) ();
}
t2.c
-
int foo () { return 0; }
thus doing a direct call to a function with a (wrong) prototype via a fu
On 02/01/2016 12:07 PM, Bin.Cheng wrote:
On Mon, Feb 1, 2016 at 6:08 PM, Andreas Schwab wrote:
"Bin.Cheng" writes:
Seems to me Andrew was right in comment of PR69559, that we simply
couldn't bootstrap GCC with sysroot.
The main use of sysroot is to build a cross compiler, which you cannot
On 02/05/2016 05:35 AM, Woon yung Liu wrote:
The current (GCC 5.3.0) MIPS divmod4 pattern emits an expand
that allocates a temporary register (hi+lo) and emits other
instructions, depending if whether the target is a 32-bit or 64-bit
MIPS target.
However, it uses gen_rtx_REG to allocate the hi+
On 02/09/2016 07:27 AM, Bin.Cheng wrote:
On Fri, Feb 5, 2016 at 10:32 AM, Ilya Enkovich wrote:
2016-02-04 19:16 GMT+03:00 Bin.Cheng :
On Thu, Feb 4, 2016 at 3:18 PM, Ilya Enkovich wrote:
2016-02-04 17:12 GMT+03:00 Bin.Cheng :
Hi,
I noticed that pic_offset_table_rtx is initialized twice in G
On 02/17/2016 04:20 AM, David Howells wrote:
Hi,
Do the macro_list and fixinc.sh files need to be installed? Does anything
outside of gcc actually use them? If macro_list is a zero length file, can it
be left out of the installation (fixinc.sh seems to test for its presence
before trying to us
On 02/17/2016 04:23 AM, David Howells wrote:
Does sysroot-suffix.h need to be installed even when it's empty? Does
anything outside of gcc actually use it? Can it be left out or given a blank
line? I notice that not all targets produce such a file.
The reason I ask is that rpmlint gives an er
On 02/22/2016 08:55 AM, David Edelsohn wrote:
csmith has uncovered a latent bug in the the PowerPC port for a
combiner pattern involving extendqihi2 (the alternative in the pattern
has never triggered for real code in over 10 years). Basic extendqihi2
works correctly (the instructions extend to e
On 02/22/2016 11:52 AM, Bin.Cheng wrote:
Hi,
I still don't quite follow this method. If I pop up chroot
environment with new glibc, it's still possible that the new glibc
isn't compatible with the default gcc in chroot. Won't this a
chicken-egg problem because we want to build our gcc against n
On 02/24/2016 01:42 PM, Alexander Monakov wrote:
On Wed, 24 Feb 2016, DJ Delorie wrote:
The real question is: are stack arguments call-clobbered or
call-preserved? Does the answer depend on the "pure" attribute?
Stack area holding stack arguments should belong to the callee for tail-calls
to
On 02/26/2016 12:18 PM, Joel Sherrill wrote:
On 2/26/2016 11:50 AM, Jonathan Wakely wrote:
On 26 February 2016 at 17:25, Joel Sherrill wrote:
Hi
Is there something special needed to commit via git? I got an odd
error pushing some minor RTEMS patches and wondered what the proper
procedure was
On 02/24/2016 05:14 AM, Richard Biener wrote:
Note that if a user writes
if (p == d)
{
... do lots of stuff via p ...
}
GCC might rewrite accesses to p as accesses to d and thus expose
those opportunities. Is that a transform that isn't valid then or is
the code written by th
On 02/26/2016 06:40 AM, Kyrill Tkachov wrote:
Hi all,
I'm looking at a case where some RTL passes create an RTL expression of
the form:
(subreg:QI (and:SI (reg:SI x1)
(const_int 31)) 0)
which I'd like to simplify to:
(and:QI (subreg:QI (reg:SI x1) 0)
(const_int 31))
I can
On 03/04/2016 08:05 AM, Richard Biener wrote:
does that mean that the shift amount should be DImode?
Seems like a more flexible approach would be for the midend to be able
to handle these things...
Or macroize for all integer modes?
That's probably worth exploring. I wouldn't be at all surpris
On 03/04/2016 09:33 AM, Kyrill Tkachov wrote:
On 04/03/16 16:21, Jeff Law wrote:
On 03/04/2016 08:05 AM, Richard Biener wrote:
does that mean that the shift amount should be DImode?
Seems like a more flexible approach would be for the midend to be able
to handle these things...
Or macroize
On 03/07/2016 03:44 AM, Kyrill Tkachov wrote:
The RTL documentation for ASHIFT and friends says that the shift amount
must be:
"a fixed-point mode or be a constant with mode @code{VOIDmode}; which
mode is determined by the mode called for in the machine description
entry for the left-shift ins
On 03/08/2016 11:49 AM, Richard Henderson wrote:
On 03/07/2016 02:49 PM, Jeff Law wrote:
On 03/07/2016 03:44 AM, Kyrill Tkachov wrote:
The RTL documentation for ASHIFT and friends says that the shift amount
must be:
"a fixed-point mode or be a constant with mode @code{VOIDmode}; which
On 03/08/2016 02:59 PM, David Malcolm wrote:
On Tue, 2016-03-08 at 21:00 +, Manuel López-Ibáñez wrote:
On 8 March 2016 at 16:47, David Malcolm wrote:
Isn't this what -fopt-info does?
https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html
Yes.
One difference is that in this proposal,
On 03/10/2016 01:18 PM, Richard Biener wrote:
On March 10, 2016 6:02:58 PM GMT+01:00, "H.J. Lu" wrote:
On Thu, Mar 10, 2016 at 6:57 AM, H.J. Lu wrote:
On Thu, Mar 10, 2016 at 5:49 AM, Jakub Jelinek
wrote:
On Thu, Mar 10, 2016 at 05:43:27AM -0800, H.J. Lu wrote:
free_dominance_info (CDI_DO
On 03/10/2016 08:00 PM, H.J. Lu wrote:
On Thu, Mar 10, 2016 at 1:30 PM, H.J. Lu wrote:
On Thu, Mar 10, 2016 at 1:24 PM, Jeff Law wrote:
On 03/10/2016 01:18 PM, Richard Biener wrote:
On March 10, 2016 6:02:58 PM GMT+01:00, "H.J. Lu"
wrote:
On Thu, Mar 10, 2016 at 6:57 AM, H.J.
Is it just me, or does find_removable_extensions leak bitmap data for
INIT, KILL, GEN and TMP?
It calls bitmap_initialize on all of them, but never clears the bitmaps...
Am I missing something?
jeff
101 - 200 of 1376 matches
Mail list logo
