On 17/11/20 02:12, Jeff Law wrote:
Removing all REG_EQUAL notes for regs that become dead anywhere
That's not what it does.
seems to just be a thinko? All pseudos are dead somewhere! (Yeah okay,
infinite loops, but other than that.)
Yea, but the code which wipes the notes probably has no
On 24/11/2015 16:57, David Edelsohn wrote:
> > > We plan to do a GCC 5.3 release candidate at the end of next week
> > > followed by the actual release a week after that.
> > >
> > > So now is the time to look at your regression bugs in bugzilla and
> > > do some backporting for things already fi
On 20/11/2015 14:14, David Edelsohn wrote:
> On Fri, Nov 20, 2015 at 7:53 AM, Richard Biener wrote:
>>
>> Status
>> ==
>>
>> We plan to do a GCC 5.3 release candidate at the end of next week
>> followed by the actual release a week after that.
>>
>> So now is the time to look at your regress
On 05/06/2015 17:45, Peter Maydell wrote:
>>> ...but things like "(1U << 31)" are entirely valid.
>>
>> They're only valid until someone does a ~ on them. I think it's
>> reasonable to forbid them in our coding standards, if we want to fix
>> ubsan's warning of (1 << 31).
>>
>> I don't think it'
On 05/12/2014 23:47, Jakub Jelinek wrote:
> On Fri, Dec 05, 2014 at 11:34:28PM +0100, Dominique Dhumieres wrote:
>>> As I've tried to explain, that is IMHO wrong though.
>>> If what you are after is the -B stuff too, then perhaps:
>>> ...
>>
>> Sorry but it does not work:
>
> Sorry, make that (j
Il 11/04/2014 07:05, Richard Sandiford ha scritto:
Sure, but this is a bit extreme. I don't see off-hand how a[i]
would generate a branch, for starters.
That's an HI+HI->SI addition, with the higher half stored in (SP+2).
The jump is emitted by cstore in order to compute the carry.
Il 06/02/2013 12:22, Frediano Ziglio ha scritto:
>
> I used an header from Linux which is derived from this GCC header when
> GCC was still GPL2 so GPL3 does not apply. Xen is GPL2 too so there is
> no problem using this header in Xen. The problem is including in the
> public headers.
>
> Actuall
Il 04/02/2013 17:46, Ian Lance Taylor ha scritto:
> On Mon, Feb 4, 2013 at 6:54 AM, Frediano Ziglio
> wrote:
>>
>> I imported some headers from Linux kernel which mainly came from
>> gcov-io.h and the structures used internally by GCC.
>>
>> Our problem is currently about the license. In gcov-io.h
Il 25/01/2013 08:24, Uday P. Khedker ha scritto:
> Exactly. We have been using our training program since 2007 (and have
> been incrementally refining it on a continuously). Our experience has
> been that it has brought down the ramp up period of novices to a couple
> of week.
A couple of weeks is
Lots of errors like the following:
-o build/genrecog.o ../../gcc/genrecog.c
In file included from ../../gcc/rtl.h:29,
from ../../gcc/genoutput.c:92:
../../gcc/vec.h:654: error: default argument missing for parameter 4 of
‘template bool vec_safe_reserve(vec*&,
unsig
On Wed, Nov 21, 2012 at 8:02 PM, Ian Lance Taylor wrote:
>> The main advantage is that you can compile a program with CFLAGS="-O2 -g
>> -fPIE", and libtool's adding of -fPIC for shared libraries will work
>> reliably. If -fPIE can still override -fPIC, the result depends on
>> whether -fPIC comes
Il 14/11/2012 15:27, Ian Lance Taylor ha scritto:
> On Wed, Nov 14, 2012 at 5:36 AM, Richard Earnshaw wrote:
>> On 13/11/12 14:56, Ian Lance Taylor wrote:
>>>
>>> Currently -fPIC -fPIE seems to be the same as -fPIE. Unfortunately,
>>> -fPIE -fPIC also seems to be the same as -fPIE. It seems to m
Il 06/11/2012 03:43, DJ Delorie ha scritto:
> Ian Lance Taylor writes:
>> > Also the fact that GCC is now written in C++ seems to me to be
>> > deserving of a bump to 5.0.
> I see no reason why an internal design change that has no user visible
> effects should have any impact on the version numbe
Il 25/08/2012 17:58, H.J. Lu ha scritto:
> The change was introduced by
>
> http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg01452.html
>
> Paolo, do you remember the reason for this?
Actually, this patch came before bfd started using libtool and hence .libs.
The patch is okay if binutils always uses l
Il 11/06/2012 11:18, Richard Guenther ha scritto:
> > Instead of renaming Stage 3 to Stage 2 at that point we figured that
> > using different terminology would reduce confusion. I am not wedded
> > to Stage A and B, though this seems to be the most straightforward
> > option (over colors, Alpha a
On 01/03/2012 09:48 AM, Jim Meyering wrote:
Paolo Bonzini wrote:
* bootstrap.conf: Add isatty module.
* gnulib: Update to latest.
* lib/colorize.h: Remove argument from should_colorize.
* lib/ms/colorize.h: Likewise.
* lib/colorize-impl.c: Factor isatty call out of here...
* lib/ms/colorize
On 11/21/2011 01:54 AM, Richard Henderson wrote:
> Emulating TLS has nothing to do with exception-handling, nor is
> there something that might throw while calling one of its
> functions.
>
> Ok to fix that?
Not without further study. There was a reason we wanted these
in libgcc_eh.a. I c
On 10/20/2011 07:46 PM, Paulo J. Matos wrote:
However, it failed to compile libgcc with:
../../../../../../../devHost/gcc46/gcc/libgcc/../gcc/libgcc2.c:272:1:
internal compiler error: in df_uses_record, at df-scan.c:3178
This feels like a GCC bug. I will try to get a better look at it tomorrow.
On 09/28/2011 02:14 PM, Georg-Johann Lay wrote:
This leads to unpleasant code. The machine can access all RAM locations by
direct addressing. However, the resulting code is:
foo:
ldi r24,lo8(-86) ; 6 *movqi/2[length = 1]
ldi r30,lo8(-64) ; 34 *movhi/5
On 09/15/2011 06:26 PM, Paolo Bonzini wrote:
There's no reference to a GCC bug report about this in the thread.
Did the folks over at the libdispatch project never think to file one?
I asked them to attach a preprocessed testcase somewhere, but they
haven't done so yet. :(
On 09/15/2011 06:19 PM, Richard Henderson wrote:
I wouldn't go that far. They *used* to be compiler barriers,
but clearly something broke at some point without anyone noticing.
We don't know how many versions are affected until we debug it.
For all we know it broke in 4.5 and 4.4 is fine.
4.4
On Tue, Sep 13, 2011 at 03:52, Geert Bosch wrote:
> No, it is possible, and actually likely. Basically, the issue is write
> buffers.
> The coherency mechanisms come into play at a lower level in the
> hierarchy (typically at the last-level cache), which is why we need fences
> to start with to i
On Mon, Sep 12, 2011 at 20:40, Geert Bosch wrote:
> Assuming that statement is true, that would imply that even for relaxed
> ordering there has to be an optimization barrier. Clearly fences need to be
> used for any atomic accesses, including those with relaxed memory order.
>
> Consider 4 threa
On 09/12/2011 01:22 AM, Andrew MacLeod wrote:
You're right that using lock_test_and_set as an exchange is very wrong
because of the compiler barrier semantics, but I think this is
entirely a red herring in this case. The same problem could happen
with a fetch_and_add or even a lock_release opera
On 09/11/2011 09:00 PM, Geert Bosch wrote:
So, if I understand correctly, then operations using relaxed memory
order will still need fences, but indeed do not require any
optimization barrier. For memory_order_seq_cst we'll need a full
barrier, and for the others there is a partial barrier.
If
On 09/11/2011 04:12 PM, Andrew MacLeod wrote:
tail->value = othervalue // global variable write
atomic_exchange (&var, tail) // acquire operation
although the optimizer moving the store of tail->value to AFTER the
exchange seems very wrong on the surface, it's really
On Sat, Sep 10, 2011 at 03:09, Geert Bosch wrote:
> For example, for atomic objects accessed only from a single processor
> (but possibly multiple threads), you'd not want the compiler to reorder
> memory accesses to global variables across the atomic operations, but
> you wouldn't have to emit
On 09/09/2011 04:22 PM, Andrew MacLeod wrote:
Yeah, some of this is part of the ongoing C++0x work... the memory model
parameter is going to allow certain types of code movement in optimizers
based on whether its an acquire operation, a release operation, neither,
or both.It is ongoing and
On 09/09/2011 10:17 AM, Jakub Jelinek wrote:
> Is the above analysis correct? Or should the users put explicit
> compiler barriers?
I'd say they should be optimization barriers too (and at the tree level
they I think work that way, being represented as function calls), so if
they don't act as
Hi all,
sync builtins are described in the documentations as being full memory
barriers, with the possible exception of __sync_lock_test_and_set.
However, GCC is not enforcing the fact that they are also full
_optimization_ barriers. The RTL produced by builtins does not in
general include a
On 08/17/2011 07:52 AM, Richard Sandiford wrote:
cost = rtx_cost (SET_SRC (set), SET, speed);
return cost> 0 ? cost : COSTS_N_INSNS (1);
This ignores SET_DEST (the problem I'm trying to fix). It also means
that constants that are slightly more expensive than a register --
somewhere in th
On 08/08/2011 10:06 AM, Richard Guenther wrote:
Like if
register unsigned char *ip;
would increase spill cost of ip compared to
unsigned char *ip;
?
Remember we're talking about a function with 11000 pseudos and 4000
allocnos (not to mention a 1500 basic blocks). You cannot really blame
On 08/04/2011 01:10 PM, Andrew Haley wrote:
>> It's the sort of thing that gets done in threaded interpreters,
>> where you really need to keep a few pointers in registers and
>> the interpreter itself is a very long function. gcc has always
>> done a dreadful job of register allocation in s
On 07/27/2011 06:42 PM, H.J. Lu wrote:
+ if (max == 64)
+ var_mask_1[var] = "1LL"
This must be ((HOST_WIDE_INT)1).
Paolo
On 07/27/2011 06:51 AM, Xinliang David Li wrote:
> If we could retain most of the speedups when the optimization works well
> but avoid most of the slowdown in the benchmarks that are currently hurt,
> we could improve the overall SPEC06 score. And hopefully, this would
> also be beneficial
On 07/25/2011 06:42 AM, Xinliang David Li wrote:
FYI the performance impact of this option with SPEC06 (built with
google_46 compiler and measured on a core2 box). The base line number
is FDO, and ref number is FDO + reorder_with_partitioning.
xalancbmk improves> 3.5%
perlbench improves> 1.5
On 07/14/2011 11:11 AM, Richard Guenther wrote:
>> Hm, why? complex operations are lowered after a complex lowering pass
>> has executed. they are still lowered on RTL, so I don't see why we need
>> to destroy them technically.
>
> Because it's PROP_*gimple*_lcx.:)
Shouldn't it then be PR
On 07/13/2011 12:54 PM, Richard Guenther wrote:
> Yes, PROP_gimple_lcx needs to be added to PROP_trees. I cannot approve the
> patch, unfortunately.
Hm, why? complex operations are lowered after a complex lowering pass
has executed. they are still lowered on RTL, so I don't see why we need
On 07/12/2011 06:07 PM, David Malcolm wrote:
On this build of GCC (standard Fedora 15 gcc package of 4.6.0), the
relevant part of cfgexpand.c looks like this:
struct rtl_opt_pass pass_expand =
{
{
RTL_PASS,
"expand", /* name */
[...snip...]
PROP_ssa | PROP_g
On 07/12/2011 10:43 AM, Paulo J. Matos wrote:
Hope this is fun/helpful (and that I'm correctly interpreting the data!)
You are, and it shows some bugs even. gimple_lcx is obviously destroyed
by expand, and I find it unlikely that no pass ever introduces a
critical edge...
But the diagram s
On 07/12/2011 10:00 AM, Eric Botcazou wrote:
But your patch isn't necessary to do that, the C files are already compiled
with the C++ compiler as of today; the only issue is at the linking stage.
The problem is that the patches links gnattools unconditionally with
g++. It should depend on --e
On 07/12/2011 08:54 AM, Arnaud Charlet wrote:
>> I'm not sure because I don't think we want to compile the C files of the Ada
>> > runtime with the C++ compiler. We want to do that only for the compiler.
>
> Right, we definitely don't want to use the C++ compiler for building the
> Ada run-time.
On 07/11/2011 07:56 PM, David Malcolm wrote:
Hope this is fun/helpful (and that I'm correctly interpreting the data!)
You are, and it shows some bugs even. gimple_lcx is obviously destroyed
by expand, and I find it unlikely that no pass ever introduces a
critical edge...
Paolo
On 07/05/2011 06:58 PM, Dimitrios Apostolou wrote:
The level of my understanding of this part is still basic, I've now only
scratched the surface of Dataflow Analysis.
Well you're not looking at df proper, which is mostly a textbook
implementation with some quirks; you're looking at RTL operan
On 06/28/2011 03:52 PM, Vladimir Makarov wrote:
They are complicated, solving NP-problems in heuristic ways.
I totally trust that people like Eric or Richard would _not_ approve
changes to those heuristics without contacting you or others.
On the other hand, I would totally trust them to app
On 05/21/2011 08:07 AM, Matt Turner wrote:
I suppose this is a missed optimization. Is this known, or should I
make a new bug report?
It's always better to do that. In this case, the bug is that when we
compute a range from an ASSERT_EXPR, and the base variable has a known
but symbolic range
On 04/29/2011 04:15 PM, Nathan Froyd wrote:
> * cxx_binding should be 16 bytes, not 20.
Not your fault, but comments like this on SpeedupAreas are so opaque as
to be useless. *Why* should cxx_binding be 16 bytes? Should we take
the next member out and have a VEC someplace instead of chaining?
On 04/27/2011 03:28 PM, Yuan Pengfei wrote:
Any other advice will be appreciated.
I think you can look into llvm-clang. It compiles faster and uses
much less memory than gcc.
It is also a completely different compiler. It doesn't make sense to
compare the two, unless Dimitrios wants to rewr
On 03/30/2011 05:15 PM, Joseph S. Myers wrote:
On Tue, 29 Mar 2011, Joseph S. Myers wrote:
Specifically, I propose removal of all support for building: ash autoconf
automake bash byacc bzip2 diff dosutils fileutils findutils find gawk
gettext gnuserv gzip hello indent libiconv libtool make mmal
On 03/30/2011 05:54 PM, Joseph S. Myers wrote:
Thanks. My inclination is to say that this should be considered an
independent tool in its own repository, as something not required in the
build of any of the other tools. More specifically, utils/mep and
utils/wince look like independent tools ea
On 03/29/2011 01:33 PM, Joseph S. Myers wrote:
But some of
those bug reports refer to target libiberty - which I still maintain
should never be built by GCC - and some to target zlib, which I think
should only be relevant when building Java.
Agreed on both counts.
Paolo
On 03/28/2011 02:27 PM, Michael Matz wrote:
unit size
align 8 symtab 0 alias set -1 canonical type 0x75b29540
which looks ok to me.
It already isn't, why is the alignment 8 if __alignof__
(GENOME_LOC_TYPE_2) is 1?
The aligns are printed in bits. It really is okay
On 03/28/2011 01:06 PM, Richard Guenther wrote:
/* GCC uses 8-byte loads and register passing even though sizeof = 6 */
typedef struct __attribute__((__packed__))
{
unsigned chr:16;
unsigned loc:32;
} GENOME_LOC_TYPE_2;
//#define GENOME_LOC_TYPE GENOME_LOC_TYPE_1
#d
On 03/27/2011 06:27 AM, Ian Lance Taylor wrote:
Nathan Boley writes:
In a much larger application, I was getting a weird segfault that an
assignment to a temporary variable fixed. I distilled the example into
the attached "test_case.c". When I run test_case.c under valgrind I
get a memory read
These targets are using -Os to build target libraries. Perhaps the
right thing to do instead would be to disable some optimizations
selectively in the compiler?
Thanks!
Paolo
On 03/22/2011 08:51 PM, Joseph S. Myers wrote:
Why do a great many targets disable libgcj by default in the toplevel
configure.ac?
Because that dates to before 2004, which IIRC is when toplevel
configure.ac started looking at config-lang.in files.
Paolo
On 03/10/2011 04:47 PM, Nathan Froyd wrote:
[moving to gcc@ to get input from a wider audience]
On Thu, Mar 10, 2011 at 06:47:20AM +0100, Hans-Peter Nilsson wrote:
From: Nathan Froyd
On Thu, Mar 10, 2011 at 04:02:27AM +0100, Hans-Peter Nilsson wrote:
PS. If you really feel for it, I won't stop
On 03/03/2011 05:31 PM, Joern Rennecke wrote:
CUMULATIVE_ARGS is a target-dependent type, and thus every use of it
in the interface of target hooks should be considered a bug.
The very presence of CUMULATIVE_ARGS in the interface is a bug, but I
don't see why introducing more uses should be f
On 03/04/2011 04:03 PM, Diego Novillo wrote:
Sure, but my question was whether I should prepare a patch to fix the
current lack of consistency between the two definitions.
Certainly. I'm not sure it would be acceptable for 4.6, but it is worth
posting it.
Paolo
On 03/03/2011 05:26 PM, Diego Novillo wrote:
On Thu, Mar 3, 2011 at 00:27, Paolo Bonzini wrote:
On 03/02/2011 10:00 PM, Ian Lance Taylor wrote:
That does not sound like the right approach to me. Why not add the new
flags to GCC_FOR_TARGET at top-level? It seems to me that
GCC_FOR_TARGET
On 03/02/2011 10:00 PM, Ian Lance Taylor wrote:
That does not sound like the right approach to me. Why not add the new
flags to GCC_FOR_TARGET at top-level? It seems to me that
GCC_FOR_TARGET should mean the same thing at all levels.
I agree. Why is it incorrect to use those flags when, say,
On 02/24/2011 06:04 PM, Michael Matz wrote:
Funny. As far back as I remember we consistently said that bits of the
same word, but outside the subreg are left with undefined values after
storing into the subreg, except if wrapped with a strict_low_part. In
fact that's the whole point of strict_l
On 01/26/2011 08:56 PM, Diego Novillo wrote:
At Google we use a code review tool which was open sourced a couple of
years ago: Rietveld
(http://code.google.com/appengine/articles/rietveld.html).
The best way of thinking about it is "bugzilla for patches". The
system creates an entry for every p
On 01/26/2011 08:56 PM, Diego Novillo wrote:
At Google we use a code review tool which was open sourced a couple of
years ago: Rietveld
(http://code.google.com/appengine/articles/rietveld.html).
The best way of thinking about it is "bugzilla for patches". The
system creates an entry for every p
On 01/26/2011 03:55 PM, James Murray wrote:
On Wed, 2011-01-26 at 15:40 +0100, Richard Guenther wrote:
Stephane Carrez is listed as maintainer of the port, so he should
know how to contribute fixes to the port upstream.
Yes, but as I said... he is no longer active on this port. His last
publ
On 12/22/2010 03:43 PM, Bingfeng Mei wrote:
Thanks for letting me know this. Since only our target experiences such
issue, I guess no other processors have such requirements of manipulating
BImode. I can live with the workaround now.
Perhaps Blackfin, but it has a BI->SI extension instruction s
On 12/20/2010 12:43 PM, Claudiu Zissulescu wrote:
Hi,
Why don't you use a define_insn "zero_extendbisi2" which generates
your conversion instruction.
You're right that this should be a valid workaround, but Bingfeng
reported a bug indeed.
(zero_extend:SI (reg:BI 120))
should have been tran
> Is there sufficient interest to post the branch patches to gcc-patches as I
> go?
If not that could be a substantial review headache at merge time.
On 18/12/2010, Joern Rennecke wrote:
> I have created the branch:
> svn://gcc.gnu.org/svn/gcc/branches/pr46489-20101217-branch
> to continue work
On 11/17/2010 03:10 AM, Ian Lance Taylor wrote:
Joern Rennecke writes:
I don't see how going to a struct cumulative_args gets us closer
to a viable solution for a multi-target executable, even if you
threw in C++. Having the target describe a type, and shoe-horning
this through a target hook i
On 11/16/2010 10:17 PM, Ian Lance Taylor wrote:
I don't know how we want to get there, but it seems to me that the place
we want to end up is with the target hooks defined to take an argument
of type struct cumulative_args * (or a better name if we can think of
one).
Actually, this doesn't work
On 11/15/2010 11:10 PM, Hans-Peter Nilsson wrote:
There *is* an option to omit the prologue and epologue
controlling the TARGET_PROLOGUE_EPILOGUE; I'm guessing that
could cause confusion.
That's what confused me.
Is that getting in the way of something?
Yes, there is code conditionalized on
On 11/15/2010 04:48 PM, Joseph S. Myers wrote:
* The macro is tested with #if/#ifdef/#ifndef/#elif in a source file
outside of config/ (but including front-end subdirectories). Care is
needed in identifying such macros through grep because of
backslash-newline line continuations and because it's
We currently have 3 non-algorithmic maintainers:
loop optimizer Zdenek Dvorak o...@ucw.cz
loop optimizer Daniel Berlin dber...@dberlin.org
libcpp Tom Tromey tro...@redhat.com
Especially for the loop optimizer, the situation is a
The only targets that are using textual prologues and epilogues are now
arc, cris, pdp11 and vax. ARC should probably have been deprecated long
ago, any plans to convert the others or (for cris) to flip the default?
Paolo
On 11/13/2010 10:08 PM, Xinliang David Li wrote:
Though gcc leads LLVM in performance overrall, there are a couple of
benchmarks gcc is worse: vpr and crafty (64bit and 32bit), parser and
twolf (32bit), vortex (64bit). This needs to be triaged. gcc
miscompiles gcc and eon in 32bit -- is there
On 11/13/2010 05:10 PM, H.J. Lu wrote:
On Sat, Nov 13, 2010 at 8:01 AM, Paolo Bonzini wrote:
On 11/13/2010 04:28 PM, H.J. Lu wrote:
VZEROUPPER is no-nop to executions. But it isn't no-nop for performance.
IIUC it's a noop as GCC uses it. You could use it in 256-bit mode and i
On 11/13/2010 04:28 PM, H.J. Lu wrote:
VZEROUPPER is no-nop to executions. But it isn't no-nop for performance.
IIUC it's a noop as GCC uses it. You could use it in 256-bit mode and
it would be valid, but not a noop.
Paolo
On 11/13/2010 03:34 PM, H.J. Lu wrote:
On Sat, Nov 13, 2010 at 2:27 AM, Paolo Bonzini wrote:
On 11/12/2010 03:25 PM, H.J. Lu wrote:
IRA may move instructions across an unspec_volatile,
Do you have a testcase?
x86 has
;; Clear the upper 128bits of AVX registers, equivalent to a NOP
On 11/12/2010 03:25 PM, H.J. Lu wrote:
IRA may move instructions across an unspec_volatile,
Do you have a testcase?
Paolo
On 11/10/2010 11:58 AM, Georg Lay wrote:
In the old 3.4.x (private port) I introduced a target hook in combine,
just prior to where recog_for_combine gets called. The hook did some
canonicalization of rtx and thereby considerably reduced the number of
patterns that would have been necessary witho
On 11/10/2010 12:47 AM, Joern Rennecke wrote:
I remember that it has been there even before the GNU GCC project started
using cvs. Fortunately, we still have the translated history from RCS
going backeven further... but the earliest mention of find_split_point
in combine.c is shown as having
On 11/09/2010 05:38 PM, Joern Rennecke wrote:
A define_insn will be recognized in all contexts.
Having an insn pattern for an insn that does not actually exist can cause
all kinds of unintended consequences as the optimizers try to generate
and recognize 'optimized' patterns, or when reload does
On 11/09/2010 10:22 AM, Joern Rennecke wrote:
Quoting roy rosen :
What is the difference when writing define_insn_and_split?
From what I understood from the docs then if there is such an insn
then the split does not occur so it would simply match it as an insn
without splitting and at the end w
On 11/05/2010 08:10 AM, Jay K wrote:
the checking for puts_locked...
the fact that asm_fprintf calls putc one character at a time,
which probably benefits from _unlocked.
Honest question: is asm_fprintf in the profile at all, even at -O0?
Paolo
On 11/05/2010 07:00 PM, Ian Lance Taylor wrote:
To the steering committee: I propose Ralf Wildenhues as a new maintainer
for the build machinery.
Ralf often has useful comments for proposed patches to the configure
scripts. He has done good work in upgrading to new versions of autoconf
and libt
On 11/04/2010 11:28 AM, Bingfeng Mei wrote:
I think of adding a warning too. Should I submit a patch?
That's always a good idea. :)
Paolo
On 11/02/2010 12:36 PM, Joern Rennecke wrote:
define_insn_and_split is little more than syntactic sugar to avoid
re-typing the same patterns again.
Yes, on the other hand it was introduced as combiner-splitter patterns
fell out of fashion, substantially replaced by what you call combiner
bri
On 11/02/2010 11:50 AM, Paolo Bonzini wrote:
On 11/01/2010 07:17 PM, Ian Lance Taylor wrote:
Tom Tromey writes:
Ian> This patch puts the code in libiberty, but it could equally well
go in
Ian> gcc. Anybody want to make an argument one way or another?
Ian> +extern const c
On 11/01/2010 07:17 PM, Ian Lance Taylor wrote:
Tom Tromey writes:
"Ian" == Ian Lance Taylor writes:
Ian> This patch puts the code in libiberty, but it could equally well go in
Ian> gcc. Anybody want to make an argument one way or another?
Ian> +extern const char *
Ian> +objfile_attri
On 11/01/2010 11:47 AM, Joern Rennecke wrote:
Quoting Geert Bosch :
On Nov 1, 2010, at 00:30, Joern Rennecke wrote:
But to get that coverage, testers will need to have gnat installed.
Will that become a requirement for middle-end patch regression testing?
No, the language will only be built
On 10/31/2010 08:12 PM, Ian Lance Taylor wrote:
I assume that the reason we do that for intl is because it has complex
interactions with the rest of the C library, so using the wrong intl
library will cause confusing behaviour when the LC_ environment
variables are set. That case does not arise
On 11/02/2010 11:39 AM, Georg Lay wrote:
Paolo Bonzini schrieb:
On 11/02/2010 10:41 AM, Georg Lay wrote:
What I do not understand is*why* this works.
The internals "16.16 How to Split Instructions" mention two flavours
of insn
splitting: One after reload for the scheduler and
On 11/02/2010 10:41 AM, Georg Lay wrote:
What I do not understand is*why* this works.
The internals "16.16 How to Split Instructions" mention two flavours of insn
splitting: One after reload for the scheduler and one during combine stage, the
latter just doing single_set --> 2 * single_set spli
On 10/30/2010 05:30 AM, H.J. Lu wrote:
Will put
if [ Go is enabled ]; then
boot_language=yes
fi
in cp/config-lang.in work?
It's a bit backwards, no?
Paolo
On 10/29/2010 06:18 PM, Georg Lay wrote:
(define_split
[(set (match_operand:SI 0 "register_operand" "")
(and:SI (match_operand:SI 1 "register_operand" "")
(match_operand:SI 2 "const_int_operand" "")))
(clobber (match_operand:SI 3 "register_operand" ""
On 10/29/2010 05:08 PM, Georg Lay wrote:
As far as I understand the internals, peephole2 matches due to predicates and
condition, it does not care for constraints (except for optional match_scratch)
Yes, I was referring as "using constraints in the define_insn". But
you're dong that as far as
On 10/29/2010 12:35 AM, Andrew Pinski wrote:
The important part of the log is:
/bin/sh ./libtool --tag=CC --mode=compile
/Users/regress/tbox/native/build/./gcc/xgcc
-B/Users/regress/tbox/native/build/./gcc/
-B/Users/regress/tbox/objs/powerpc-apple-darwin9.8.0/bin/
-B/Users/regress/tbox/objs/pow
On 10/28/2010 03:10 PM, Georg Lay wrote:
Georg Lay schrieb:
This code is not nice.
;; d8 = d4 * d6
;; d8 = d2
;; d2 = d8
;; return d2
this should be
;; d2 = d4 * d6
;; d8 = d2
;; d2 = d8
;; return d2
It seems to me that some of your peepholes should instead be implemented
using constrain
On 10/28/2010 12:24 PM, Georg Lay wrote:
Emitting a bunch of CLOBBERs in epilogue/sibcall_epilogue works also, at least
for the small example above. But using LOCAL_REGNO seems more natural to me and
that does not clutter RTL.
True. It's a pretty elegant solution, and I missed it in my mail (I
On 10/22/2010 01:16 PM, Georg Lay wrote:
I already tried to fix this by introducing a different return-pattern, i.e. a
PARALLEL of return and bunch of clobbers of unused regs. That fixes this problem
but has many other disadvantages compared to a simple return.
What were this disadvantages?
Pa
1 - 100 of 1076 matches
Mail list logo
