On 08/18/2011 11:23 AM, Richard Guenther wrote:
Yeah, well. That's really a question for language lawyers;) I agree
that it would be nice to have mask ? val0 : val1 behave the same
for scalars and vectors. The question is whether for vectors you
define it on the bit-level (which makes it
On 08/24/2011 12:06 AM, Joseph S. Myers wrote:
This patch, relative to a tree with my patch
http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01930.html applied,
reduces the number of explicit compilation rules in gcc/ and
subdirectory makefiles by using CFLAGS-$@ settings when a target needs
extra
On 08/24/2011 12:06 AM, Joseph S. Myers wrote:
This patch, relative to a tree with my patch
http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01930.html applied,
reduces the number of explicit compilation rules in gcc/ and
subdirectory makefiles by using CFLAGS-$@ settings when a target needs
extra
On 08/24/2011 12:58 PM, Rainer Orth wrote:
With both ways, the output of hg log --debug looks like this:
extra: branch=gcc-4_6-branch
extra:
convert_revision=svn:138bc75d-0d04-0410-961f-82ee72b054a4/branches/gcc-4_6-branch@177861
extra: branch=default
extra:
On 08/18/2011 11:37 PM, Joseph S. Myers wrote:
C1X provides a standard way of declaring non-returning functions, with
the _Noreturn keyword and a header stdnoreturn.h defining a macro
noreturn to expand to _Noreturn. This patch implements this syntax
and header. Bootstrapped with no
On 08/22/2011 07:11 PM, Rainer Orth wrote:
installed, thanks.
Do I need to sync the config and libiberty parts to src manually or does
this happen by some sort of magic?
I'll take care of that.
Paolo
On 08/19/2011 09:11 PM, Rainer Orth wrote:
2011-07-31 Rainer Orthr...@cebitec.uni-bielefeld.de
config:
* picflag.m4: New file.
gcc:
* configure.ac (GCC_PICFLAG_FOR_TARGET): Call it.
(PICFLAG_FOR_TARGET): Substitute.
* aclocal.m4: Regenerate.
On 08/22/2011 04:45 PM, H.J. Lu wrote:
Can I check in this patch to address AIX issue first?
I will submit a patch to test .section .init_array later?
Thanks.
Yes.
Paolo
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
On 08/16/2011 04:59 AM, Rainer Orth wrote:
None of them uses any of those macros, so I think we're safe.
Yes, I checked the same now. Looks like we're good.
I'll review the other patches soon, but they are _huge_! :)
Paolo
On 08/16/2011 09:52 AM, Arnaud Charlet wrote:
I've often had serious trouble when I tried to run make
gnatlib/gnatlib-shared in gcc/ada.
Apparently someone in the past removed too many things from the Makefile
which broke partly this support (probably thinking that with libada/Makefile,
On 08/16/2011 09:44 AM, Rainer Orth wrote:
So passing PICFLAG down to the gcc/ada/gcc-interface Makefile and not
just via libada/Makefile is indeed important.
This seems to be easy: unless I'm mistaken, it should suffice to just
call GCC_PICFLAG in gcc/configure.ac and substitute the result
On 08/16/2011 09:53 AM, Rainer Orth wrote:
actually makes some sense---so the general approach in your patch is good.
Indeed, but IMO it makes sense in general, not only for SPARC, but for
all targets that distinguish between -fpic and -fPIC.
The patch is okay.
You mean as is, with all
On 08/16/2011 01:08 PM, Arnaud Charlet wrote:
Please post them.
OK, here they are. FWIW, I have no idea how these changes will play with
libada (in particular the stamp-tools handling), so I suspect these changes
may require a bit of adjustment to be suitable.
Wouldn't you use these targets
On 08/16/2011 10:16 AM, Rainer Orth wrote:
Agreed. I'd prefer to first complete the build side of the migration
from gcc (mostly target headers left now, which seems to be somewhat
involved on first check), then deal with the libgcc-only macros, and
only then look into cleaning up the end
On 08/15/2011 10:30 AM, Rainer Orth wrote:
This patch almost completes the build side of the libgcc moves. It
moves the libgcc_tm_file support to libgcc/config.host (tm_file), where
it belongs. It builds on a patch Paolo posted some time ago, with some
minor corrections (introducing the
On 08/15/2011 10:53 AM, Rainer Orth wrote:
* The general approach between libtool and libiberty differs. Unless
otherwise specified (PIC is the default or doesn't work for some
reason), libtool defaults to -fPIC, while libiberty has a strange
mixture of -fPIC/-fpic and nothing, without
On 08/15/2011 02:05 PM, Joseph S. Myers wrote:
This patch almost completes the build side of the libgcc moves. It
moves the libgcc_tm_file support to libgcc/config.host (tm_file), where
it belongs. It builds on a patch Paolo posted some time ago, with some
minor corrections
On 08/11/2011 08:24 PM, H.J. Lu wrote:
On Thu, Aug 11, 2011 at 11:19 AM, H.J. Luhjl.to...@gmail.com wrote:
On Thu, Aug 11, 2011 at 8:23 AM, Rainer Orth
r...@cebitec.uni-bielefeld.de wrote:
Paolo Bonzinibonz...@gnu.org writes:
On 08/10/2011 06:05 PM, Rainer Orth wrote:
True: it is
On 08/12/2011 02:13 PM, H.J. Lu wrote:
We may have a race condition here.
I opened:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50047
Does the attached patch work?
Can you provide a patch instead of the whole Makefile.in?
Sorry, that was not intended.
Paolo
2011-08-12 Paolo Bonzini
.
Paolo
2011-08-12 Paolo Bonzini bonz...@gnu.org
* Makefile.in (install-unwind_h): Create $(gcc_objdir)/include/unwind.h
atomically.
Index: Makefile.in
===
--- Makefile.in (revision 177688)
+++ Makefile.in (working copy)
@@ -991,8
On 08/12/2011 05:50 PM, H.J. Lu wrote:
Thanks, you are correct.
It should work.
Thanks.
I prefer to wait for testing results to commit it, the breakage is minor.
Paolo
On 08/12/2011 06:25 PM, H.J. Lu wrote:
I prefer to wait for testing results to commit it, the breakage is minor.
It bootstraps successfully with make -j12 on a 24 core machine.
Thanks.
Committed.
Paolo
On 08/10/2011 01:14 PM, Rainer Orth wrote:
* At the moment, SHLIB_LINK is used in gcc/Makefile.in and the various
Make-lang.in fragments to check if the target supports a shared
libgcc_s. I've introduced gcc/config/t-slibgcc (from t-slibgcc-dummy)
for this, which sets SHLIB = true,
On 08/10/2011 06:50 PM, Pedro Alves wrote:
On Wednesday 10 August 2011 17:05:08, Rainer Orth wrote:
Paolo Bonzinibonz...@gnu.org writes:
True: it is called once per multilib.
Just to doublecheck, are we sure that unwind.h is always the same?
Yep: it's unwind-generic.h for
On 08/11/2011 04:25 PM, Joseph S. Myers wrote:
The actual problem are not the runtime libraries, which already know to
search $builddir/.../libgcc for unwind.h and related files. The
copyback is only for the benefit of the testsuite (gcc.target, g++.dg,
gnat.dg, and gcc.dg) where I was
On 08/11/2011 05:26 PM, Rainer Orth wrote:
Actually I think the installation of all the installed target headers
should move to libgcc's Makefiles (and the headers themselves should move
under the libgcc/ directory).
Agreed, added to my ever-growing todo list for the libgcc move. This
On Thu, Aug 11, 2011 at 20:19, H.J. Lu hjl.to...@gmail.com wrote:
On Thu, Aug 11, 2011 at 8:23 AM, Rainer Orth
r...@cebitec.uni-bielefeld.de wrote:
Paolo Bonzini bonz...@gnu.org writes:
On 08/10/2011 06:05 PM, Rainer Orth wrote:
True: it is called once per multilib.
Just
On 08/10/2011 01:42 PM, Rainer Orth wrote:
* Centralize the determination of PICFLAG. Currently, three libraries
inside the gcc tree are built PIC without libtool: libgcc, libiberty,
and libgnat/libgnarl.
libiberty/configure.ac has a hardcoded list of PICFLAG that could be
moved to
On 08/10/2011 03:56 PM, Rainer Orth wrote:
Joseph S. Myersjos...@codesourcery.com writes:
This is strange: they copy explicitly goes into $(gcc_objdir): from
libgcc/Makefile.in:
install-unwind_h:
cp unwind.h $(gcc_objdir)/include/unwind.h
chmod a+r
On 08/10/2011 06:05 PM, Rainer Orth wrote:
True: it is called once per multilib.
Just to doublecheck, are we sure that unwind.h is always the same?
Yep: it's unwind-generic.h for almost all targets, just a few arm
targets use config/arm/unwind-arm.h for all multilibs.
Patch doing rm -f
On 08/09/2011 04:22 PM, Richard Guenther wrote:
This fixes PR49907 - ok for trunk?
Ping.
Thanks,
Richard.
Ok.
Paolo
On 08/09/2011 02:14 PM, Rainer Orth wrote:
OK for the MIPS parts.
Paolo, are you ok with the build parts?
Yes.
Paolo
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/08/2011 02:21 PM, Rainer Orth wrote:
IRIX 6.5 bootstrap was broken this weekend: gengtype failed to link in
stage2 since it was linked with -lstdc++ (for graphite, from HOST_LIBS),
but LDFLAGS (which provides the necessary -L option) is missing.
With this patch, the bootstrap continues.
On 08/08/2011 03:47 PM, Rainer Orth wrote:
This patch was bootstrapped without regressions on i386-pc-solaris2.10
and i386-pc-solaris2.11. It probably needs more testing on other
non-posix platforms.
Did you include Ada?
Paolo
On 08/08/2011 03:47 PM, Rainer Orth wrote:
This patch moves gthr*.h and related code to toplevel libgcc. Unlike
the other outstanding patches (libgcc1, libgcc2, crtstuff, shlib), it is
pretty independent from the rest, so I'm posting it first. It was
developed last, so there may be conflicts
On 08/08/2011 02:30 PM, Rainer Orth wrote:
While preparing the patch to move gthr* to toplevel libgcc, I noticed
that we still have half-hearted support for the posix95 thread model.
No port uses it as the default, and the posix95 subdir in libgomp/config
isn't referenced anywhere and cannot be
On 08/08/2011 05:42 PM, John David Anglin wrote:
** _DCE_THREADS is used to select gthr-dce.h, but again dce is the
only/default model on hppa[12]*-*-hpux10* (pa-hpux10.h), so the
special-casing can be removed.
DCE threads and thread single are both supported. There are
multilibs for both.
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 such
On 08/06/2011 12:43 PM, Mikael Morin wrote:
On Friday 05 August 2011 21:48:34 Paolo Bonzini wrote:
On Fri, Aug 5, 2011 at 20:18, Mikael Morinmikael.mo...@sfr.fr wrote:
I suppose it is this patch that breaks bootstrap
The culprit is indeed r177447.
Adding a -I flag? I suppose that makes
On 08/05/2011 02:31 PM, Richard Guenther wrote:
This extends VRP to handle BIT_NOT_EXPR by composing ~X as
-X - 1 (which should give us anti-range handling for free).
Just a small detail, but why not -1 - X which saves the NEGATE_EXPR? :)
Paolo
On 08/06/2011 05:07 PM, Mikael Morin wrote:
On Saturday 06 August 2011 16:31:48 Paolo Bonzini wrote:
Can you try this instead?
It works. Thanks
Committed, thanks.
Paolo
On 08/03/2011 03:46 PM, Rainer Orth wrote:
Ok for mainline if they pass?
I think the avr-lib.h and h8300-lib.h files should be modified to only
define the constants when compiling fp-bit, because they pollute the
namespace.
Both avr and h8300 only use floats, so you can wrap them in
On 08/03/2011 04:01 PM, Rainer Orth wrote:
Configure tests could also make a better replacement for softfp_wrap_start
and softfp_wrap_end.
We've got two uses left right now:
* libgcc/config/arm/t-softfp has #ifdef __ARM_ARCH_6M__. One could
probably use AC_EGREP_CPP([__ARM_ARCH_6M__], ,
On 08/05/2011 12:07 AM, Maciej W. Rozycki wrote:
2011-08-04 Maciej W. Rozyckima...@linux-mips.org
config/
* zlib.m4 (AM_ZLIB): Check for compressBound instead of
zlibVersion.
Ok.
Paolo
On 08/05/2011 03:19 AM, Ramana Radhakrishnan wrote:
cmp r0, #43
it ne
cmpne r1, #45
it ne
movne r0, r1
bx lr
[...] there could be a single it block to handle both
and thus you could make this even better with
cmp r0, #43
On 08/05/2011 01:46 PM, Rainer Orth wrote:
How should we proceed with this patch, especially given the quite
moderate comments from most affected target maintainers?
ARM is the only target we should care a bit about. Any chance you can try
cross-compiling it (with a combined tree it
On Fri, Aug 5, 2011 at 20:18, Mikael Morin mikael.mo...@sfr.fr wrote:
I suppose it is this patch that breaks bootstrap on 86_64-unknown-freebsd8.2:
/home/mik/gcc4x/src/gcc/crtstuff.c:64:28: fatal error: unwind-dw2-fde.h: No
such file or directory
Fixed by the the following pat^Whack
Index:
On 08/03/2011 02:46 PM, Richard Guenther wrote:
If that's reasonable then adding the malloc attribute should be, too.
Making aliasing stricter for -D_FORTIFY_SOURCE=2 sounds wrong though.
Paolo
On 08/01/2011 09:10 PM, Dimitrios Apostolou wrote:
Keeping my patch exactly the same, just changing the
hook_void_hard_reg_set to receive a (HOST_WIDEST_FAST_INT *) arg and
doing the necessary typecasts, added an extra 3 M instructions.
But the ix86_live_on_entry is only called 1233x times
On 08/01/2011 03:51 PM, Rainer Orth wrote:
Here's an updated version of the patch, containing two changes:
* Solaris 8 doesn't support KSTAT_DATA_STRING.
* I've updated the list of known cpu types, based on the
/platform/sun4?/kernel/cpu{, /sparcv9} entries found in Solaris 8, 9,
10 and
On 08/01/2011 05:57 PM, Dimitrios Apostolou wrote:
I don't fully understand the output from -fdump-tree-all, but my
conclusion based also on profiler output and objdump, is that both
unrolling and inlining is happening in both versions. Nevertheless I can
see that assembly output is a bit
On Sat, Jul 30, 2011 at 19:21, Dimitrios Apostolou ji...@gmx.net wrote:
I don't intend for this to go mainline, Jakub has explained on IRC that
certain ABIs make it slower to pass structs and we wouldn't want that.
This can be fixed by marking the functions as always_inline. They
should be
On Sun, Jul 31, 2011 at 14:44, Jakub Jelinek ja...@redhat.com wrote:
But I really think it is a mistake to change HARD_REG_SET itself, at least
before we are actually there to be able to have a full multi-target cc1 (if
that is a goal).
I'd agree, but tm.h was already removed from target.h.
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
Ok, you removed ignore_address_wrap_around, so we're almost there.
On 07/28/2011 07:59 PM, H.J. Lu wrote:
@@ -712,7 +715,16 @@ convert_modes (enum machine_mode mode, enum machine_mode
oldmode, rtx x, int uns
if (GET_CODE (x) == SUBREG SUBREG_PROMOTED_VAR_P (x)
GET_MODE_SIZE
On 07/29/2011 08:34 AM, Paolo Bonzini wrote:
+ temp = rtl_hooks.gen_lowpart_no_emit (mode, x);
This line is obviously spurious, sorry.
+ if (no_emit)
+ return rtl_hooks.gen_lowpart_no_emit (mode, x);
+ else
+return gen_lowpart (mode, x);
Paolo
On 07/29/2011 03:27 PM, Laurynas Biveinis wrote:
Pinging yet again...
2011/7/22 Laurynas Biveinislaurynas.bivei...@gmail.com:
PING again...
2011/5/28 Laurynas Biveinislaurynas.bivei...@gmail.com:
PING
http://codereview.appspot.com/4250047
http://gcc.gnu.org/ml/gcc/2011-01/msg00363.html
On 07/28/2011 12:59 AM, H.J. Lu wrote:
Regarding correctness: you're converting a SImode operation to DImode by
pushing in the zero_extend operation. What makes you think that base +
constant offset won't overflow in any case?
You have not answered this.
And also: what are you
On 07/28/2011 11:30 AM, Uros Bizjak wrote:
convert_memory_address_addr_space has a special PLUS/MULT case for
POINTERS_EXTEND_UNSIGNED 0. ?It turns out that it is also needed
for all Pmode != ptr_mode cases. ?OK for trunk?
2011-06-11 ?H.J. Lu ?hongjiu...@intel.com
? ? ? ?PR
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 to
On 07/27/2011 07:29 PM, H.J. Lu wrote:
If IRNORE_ADDRESS_WRAP_AROUND is TRUE, we
+ also permute the conversion and addition of a constant. It is used to
+ optimize cases where overflow of base + constant offset won't happen or
+ its behavior is implementation-defined for a given target.
On 07/27/2011 06:17 PM, Joseph S. Myers wrote:
--- gcc/target.h 2011-04-06 11:08:17 +
+++ gcc/target.h 2011-07-27 10:27:56 +
@@ -50,6 +50,7 @@
#define GCC_TARGET_H
#include tm.h
+#include hard-reg-set.h
#include insn-modes.h
Please send a patch against current
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/13/2011 07:48 PM, H.J. Lu wrote:
Here is the patch. OK for trunk?
Again, at least you should explain clearly _why_ you need
ignore_address_wrap_around. You said elsewhere x32 should be first
clean, then fast.
if (GET_CODE (x) == SUBREG SUBREG_PROMOTED_VAR_P (x)
to try other simplifications if gen_lowpart_no_emit
fails; for now, I'm just avoiding a NULL pointer dereference.
2011-07-25 Paolo Bonzini bonz...@gnu.org
* rtlhooks.c (gen_lowpart_no_emit_general): Remove.
* rtlhooks-def.h (gen_lowpart_no_emit_general): Remove prototype
On Mon, Jul 25, 2011 at 21:03, Dimitrios Apostolou ji...@gmx.net wrote:
* hard-reg-set.h (TEST_HARD_REG_BIT, SET_HARD_REG_BIT,
CLEAR_HARD_REG_BIT): Added some assert checks for test, set and clear
operations of HARD_REG_SETs, enabled when RTL checks are on. Runtime
overhead was measured
On Sat, Jul 23, 2011 at 02:32, Richard Henderson r...@redhat.com wrote:
Does anyone object to me committing the patch as-is, with the
understanding that either Paulo or myself will, before too long,
clean up the DF interface as described above?
I would kind of object for a pass that is enabled
On Fri, Jul 22, 2011 at 02:09, Richard Henderson r...@redhat.com wrote:
I should mention here that I suspect the Cleanest solution is
to make DF_DEFER_INSN_RESCAN imply that we also shouldn't grab
data from the blocks those new insns are in either. In this
way one can create the block, link
On Wed, Jul 20, 2011 at 18:35, Rainer Orth r...@cebitec.uni-bielefeld.de
wrote:
I've hacked around this by wrapping the AM_ICONV calls in
AC_LANG_{PUSH, POP}(C++), but I think this exposes a fundamental
issue: the configure tests must be performed with the compiler used
for the build.
On 07/14/2011 08:40 PM, Rainer Orth wrote:
I've got a preliminary NetWare removal patch ready (yet untested), but
have a couple of questions:
* Given that there's a considerable amount of NetWare support still in
src, toplevel support has to stay. On the other hand, the reference
in
On 07/15/2011 11:37 AM, Jakub Jelinek wrote:
While __sync_lock_test_and_set isn't a full barrier on all targets,
I hope it doesn't matter, because the inline caller has already done one
__sync_val_compare_and_swap which is a full barrier.
Why not take the occasion to add the __sync_swap
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
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 |
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:45 PM, Rainer Orth wrote:
+crt0.o: $(srcdir)/config/i386/netware-crt0.c
+ $(crt_commpile) $(CRTSTUFF_T_CFLAGS) -c $
Typo here. Otherwise looks good, thanks.
Paolo
On 07/12/2011 06:37 PM, Rainer Orth wrote:
The next easy step in toplevel libgcc migration is moving
i386/crtprec.c. I noticed that -mpc{32, 64, 80} wasn't supported on
Solaris/x86 yet and corrected that. The only testcase using the switch
was adapted to also do so on Darwin/x86 (which already
On 07/11/2011 05:54 PM, H.J. Lu wrote:
The key is the
XEXP (x, 1) == convert_memory_address_addr_space
(to_mode, XEXP (x, 1), as)
test. It ensures basically that the constant has 31-bit precision, because
otherwise the constant would change from e.g. (const_int
On 07/13/2011 06:13 PM, Thomas Schwinge wrote:
Alternatively, gcc_GAS_CHECK_FEATURE could be changed to emit the
temporary file by using a shell here-doc, which is what AC_TRY_COMPILE is
doing, for example.
Change instead echo ifelse(...) conftest.s to
AS_ECHO([m4_if(...)]) conftest.s
in
On Wed, Jul 13, 2011 at 18:39, H.J. Lu hjl.to...@gmail.com wrote:
Why? Certainly Y = 8 has 31-bit (or less) precision. So it has the same
representation in SImode and DImode, and the test above on XEXP (x, 1)
succeeds.
And then we permute conversion and addition, which leads to the issue
Why? Certainly Y = 8 has 31-bit (or less) precision. So it has the same
representation in SImode and DImode, and the test above on XEXP (x, 1)
succeeds.
And then we permute conversion and addition, which leads to the issue you
raised above. In another word, the current code permutes
Ok.
Paolo
On Wed, Jul 13, 2011 at 19:17, Thomas Schwinge tho...@schwinge.name wrote:
Hallo!
On Wed, 13 Jul 2011 18:23:50 +0200, Paolo Bonzini bonz...@gnu.org wrote:
On 07/13/2011 06:13 PM, Thomas Schwinge wrote:
Alternatively, gcc_GAS_CHECK_FEATURE could be changed to emit the
temporary
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/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.
But
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
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
On 07/11/2011 02:04 AM, H.J. Lu wrote:
With my original change, I got
(const:DI (plus:DI (symbol_ref:DI (iplane.1577) [flags 0x2]
var_decl 0x70857960 iplane)
(const_int -4 [0xfffc])))
I think it is safe to permute the conversion and addition operation
if one operand
On Sat, Jul 9, 2011 at 23:31, H.J. Lu hjl.to...@gmail.com wrote:
On Sat, Jul 9, 2011 at 2:18 PM, Paolo Bonzini bonz...@gnu.org wrote:
On 07/05/2011 04:27 PM, H.J. Lu wrote:
diff --git a/gcc/explow.c b/gcc/explow.c
index 7387dad..b343bf8 100644
--- a/gcc/explow.c
+++ b/gcc/explow.c
On 07/05/2011 04:27 PM, H.J. Lu wrote:
diff --git a/gcc/explow.c b/gcc/explow.c
index 7387dad..b343bf8 100644
--- a/gcc/explow.c
+++ b/gcc/explow.c
@@ -383,18 +383,13 @@ convert_memory_address_addr_space (enum machine_mode
to_mode ATTRIBUTE_UNUSED,
case PLUS:
case MULT:
-
On 07/08/2011 05:51 AM, Dimitrios Apostolou wrote:
+ /* first write DF_REF_BASE */
This is not necessary. These uses are written to use_vec, while the
uses from REG_EQUIV and REG_EQUAL are written to eq_use_vec (see
df_ref_create_structure).
Also, anyway this wouldn't work because
df-scan.c has this code to deal with group sets:
/* It is legal to have a set destination be a parallel. */
if (GET_CODE (dst) == PARALLEL)
{
int i;
for (i = XVECLEN (dst, 0) - 1; i = 0; i--)
{
rtx temp = XVECEXP (dst, 0, i);
if (GET_CODE (temp)
On 07/08/2011 12:33 PM, Rainer Orth wrote:
The next patch in the line of toplevel libgcc moves proved to be
completely trivial: fixed-bit.[ch] is moved over with corresponding
include and Makefile changes.
Tested with a C-only --enable-fixed-point non-bootstrap build/test on
mips-sgi-irix6.5.
On 07/08/2011 01:31 PM, Rainer Orth wrote:
And another easy one: moving libgcov over to libgcc.
Bootstrapped without regressions on i386-pc-solaris2.11 and
x86_64-unknown-linux-gnu.
Ok for mainline?
After this one, and once the problems with the unwinder move are sorted
out, I've got a few
On 07/08/2011 12:43 PM, Richard Sandiford wrote:
The docs also say that the first expr_list can be null:
If @var{lval} is a @code{parallel}, it is used to represent the case of
a function returning a structure in multiple registers. Each element
of the @code{parallel} is an
On 07/08/2011 03:05 PM, Dimitrios Apostolou wrote:
Paolo, something else, in df_mark_reg() is it ever possible for regno to
be = FIRST_PSEUDO_REGISTER? An assert I've put doesn't trigger for my
simple test :-)
From reading the docs of EH_RETURN_STACKADJ_RTX and EH_RETURN_HANDLER_RTX,
it
On 07/08/2011 11:05 AM, Dimitrios Apostolou wrote:
On Fri, 8 Jul 2011, Jakub Jelinek wrote:
On Fri, Jul 08, 2011 at 06:20:04AM +0300, Dimitrios Apostolou wrote:
The attached patch does two things for df_get_call_refs():
* First it uses HARD_REG_SETs for defs_generated and
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
Did you even _think_ of looking at the sh configury, and do something
vaguely similar for x86?
You should not duplicate t-linux64 at all. Instead, in config.gcc set
m64/m32 as the default value for with_multilib_list on i386 biarch and
x86_64. Pass $with_multilib_list to t-linux64 using
On Thu, Jul 7, 2011 at 17:12, Uros Bizjak ubiz...@gmail.com wrote:
On Thu, Jul 7, 2011 at 5:02 PM, H.J. Lu hjl.to...@gmail.com wrote:
Did you even _think_ of looking at the sh configury, and do something
vaguely similar for x86?
You should not duplicate t-linux64 at all. Instead, in
401 - 500 of 1512 matches
Mail list logo
