On 08/27/2012 11:58 AM, Lawrence Crowl wrote:
I wonder if the second discriminator support is easily generalizable
to enabling any derived class being a root class on it own with its
own subtree? If I understand correctly, the GTY syntax would be the
same.
If I understand correctly, you
) whether
the patch should be applied to glibc regardless.
r~
From 9b0aca04145daf0d22d607e88d6fa2df8c49f11b Mon Sep 17 00:00:00 2001
From: Richard Henderson r...@twiddle.net
Date: Thu, 30 Aug 2012 12:02:50 -0700
Subject: [PATCH] alpha: Work around gcc 4.8 aliasing difference/bug
---
ports
I've seen this today both for alpha and s390 cross from x86_64:
libtool: compile: /home/rth/work/gcc/bld-s390/./gcc/xgcc -shared-libgcc
-B/home/rth/work/gcc/bld-s390/./gcc -nostdinc++
-L/home/rth/work/gcc/bld-s390/s390x-linux/libstdc++-v3/src
On 09/04/2012 02:25 PM, Jens Rosenboom wrote:
Hello All,
Do you maybe know how to find out (in legitimize_pic_address() and in
arm_assemble_integer()) whether an address (rtx) is in text/rodata or
in data?
You need to catch this much earlier than this. See the encode_section_info
hook,
On 09/10/2012 01:41 AM, Zhenqiang Chen wrote:
In function maybe_record_trace_start, there is a check:
/* We ought to have the same state incoming to a given trace no
matter how we arrive at the trace. Anything else means we've
got some kind of optimization error. */
On 2012-10-17 10:31, Joern Rennecke wrote:
- What would a good naming scheme be?
- Change the semantics of the HAVE_pattern macros for officially named
patterns so that they are defined as 0 when the pattern is not provided?
That choice would actually force people to change #ifdef
On 2012-10-18 00:39, Joseph S. Myers wrote:
Note: for patterns that involve a machine mode, I think it's better to
generate a macro (or function) that takes the mode as a parameter. This
is because most references to modes such as SImode or DFmode in
architecture-independent code are in
On 2012-10-17 10:31, Joern Rennecke wrote:
- What would a good naming scheme be?
- Change the semantics of the HAVE_pattern macros for officially named
patterns so that they are defined as 0 when the pattern is not provided?
That choice would actually force people to change #ifdef
On 11/20/2012 02:22 AM, Senthil Kumar Selvaraj wrote:
Hi all,
For the AVR target, the FP register spans two registers, yet the DWARF
location information (DW_AT_location) for a local variable refers to only
one
of them.
Looking at the code, I found that based_loc_descr in
On
http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
we have a stale link to
http://www.codesourcery.com/public/cxx-abi/abi.html
What's the new canonical location for this document?
r~
On 12/14/2012 04:20 AM, Richard Biener wrote:
Exposing known rounding modes as new operation codes may sound like
a good idea (well, I went a similar way with trying to make operations with
undefined overflow explicit ... but the fallout was quite large even though
there is only one kind of
On 01/06/2013 01:11 PM, Alan Lehotsky wrote:
Do I need to do something like change my define_expand for addsi3 to be
something like
[ (parallel [ (clobber:CCmode (reg:CCmode CCREG))
(set:SI (match_operand:SI 0 )
(plus:SI
On 01/11/2013 07:20 PM, Michael Eager wrote:
I still think it's a bit odd. Other targets use the comparison
operator (e.g., lt, ge, etc.). Microblaze should as well.
Microblaze can't use the raw comparison operator because of how
the results of the cmp{,u} instructions are defined,
On 05/21/2013 05:40 AM, Andreas Krebbel wrote:
Hi,
I'm currently implementing support for hardware transactional memory
in the S/390 backend and ran into a problem with saving and restoring
the floating point registers.
On S/390 the tbegin instruction starts a transaction. If a
On 05/21/2013 07:28 AM, Torvald Riegel wrote:
The additional prologue/epilogue FPR backups for TXs can only be
avoided if the transaction is fully contained in the function body
(and does not use the FPRs). I call these non-escaping transactions.
That's what __transaction_atomic etc. give
On 05/22/2013 02:23 AM, Andreas Krebbel wrote:
Mmmh ok. Where do you think the other approach (clobber in abort code +
abnormal edge) could break?
It's mostly about the infrastructure of maintaining the edges. It's quite a
lot of code to maintain normal EH + TM edges. We don't even bother
On 05/22/2013 12:43 AM, Jakub Jelinek wrote:
Changing frame grows upward into frame grows downward shouldn't be that
hard, see e.g. rs6000 port, where
#define FRAME_GROWS_DOWNWARD (flag_stack_protect != 0 || flag_asan != 0)
and grep the port where it uses FRAME_GROWS_DOWNWARD.
Basically you
On 05/23/2013 09:28 AM, Richard Earnshaw wrote:
Doing that would add significantly to the cost of setting up the frame.
It shouldn't...
FRAME_GROWS_DOWNWARD
Define this macro to nonzero value if the addresses of local variable slots
are
at negative offsets from the frame pointer.
Yes,
On 05/23/2013 09:43 AM, Richard Earnshaw wrote:
So you're saying the documentation is wrong, or at the very least
misleading... What about dealing with address validation for soft accesses?
Surely we get better code if the SFP ~= HFP since we end up with fewer cases
where we fall back to
On 05/30/2013 04:30 PM, Ryan Johnson wrote:
Is there a way for libgcc_s to interpose on dlopen/dlclose if (and only if)
those are present? If so, the wrappers could increment an atomic version
counter, which would be plenty accurate for invalidating an object header
cache, without requiring
On 2013-06-06 09:18, Paulo Matos wrote:
So while I have:
tsteqb p0, r0, r1
which sets p0 to 0xff is r0 == r1, then the branch looks like
bl p0.bit, label,
where
bl p0.0, L1
branches to L1 is bit 0 of p0 is set.
So I have cmp_qimode, etc but then only cbranchbi4.
You'll be better off with a
On 06/24/2013 12:37 AM, Vineet Gupta wrote:
Aha, I see what's happening. For historical reasons, ARC Linux kernel stack
unwinder relies on .debug_frame (vs. .eh_frame) for stack unwinding. Being non
allocatable it would default to address zero hence the orig absolute
relocations
would work
On 07/24/2013 05:23 AM, Richard Biener wrote:
H.J. Lu hjl.to...@gmail.com wrote:
Hi,
Here is a patch to extend x86-64 psABI to support AVX-512:
Afaik avx 512 doubles the amount of xmm registers. Can we get them callee
saved please?
Having them callee saved pre-supposes that one knows
On 07/24/2013 05:11 AM, hex wrote:
I find a strange things: Whether DIE(Debug Information Entry) of a
static const int member in a class has the attribute
DW_AT_const_value depends on whether there is a virtual function
defined in the class. Is it a expected behavior for GCC? And the
On 07/18/2013 04:48 PM, Tom Tromey wrote:
There may be more missing dependencies. Please try out this branch if
you would. You can report bugs to me, just send the build log.
I've done a couple of builds, and had a browse through the patches on the
branch. It's looking pretty good to me. I
On 08/05/2013 09:57 AM, Jason Baron wrote:
On 08/05/2013 03:40 PM, Marek Polacek wrote:
On Mon, Aug 05, 2013 at 11:34:55AM -0700, Linus Torvalds wrote:
On Mon, Aug 5, 2013 at 11:24 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
Ugh. I can see the attraction of your section thing for
On 09/12/2013 03:22 AM, Víctor Martínez wrote:
Why is sjlj.o the only one built for armv4 while the rest of objects are
armv5t?
Is this behaviour expected? Or is there something wrong trying to configure
gcc
with these options?
There are co-processor instructions in there that can't be
On 10/23/2013 12:30 PM, Iyer, Balaji V wrote:
Hi Jeff et al.,
Here is a link to the updated patch
(https://docs.google.com/file/d/0BzEpbbnrYKsSbVY2X3ZLUnd4OXM/edit?usp=sharing).
We have fixed all the issues that Joseph pointed out in
http://gcc.gnu.org/ml/gcc/2013-10/msg00090.html.
On 10/24/2013 01:43 PM, Iyer, Balaji V wrote:
In file included from ../../../git-master/libcilkrts/runtime/cilk-abi.c:52:0:
../../../git-master/libcilkrts/include/cilk/cilk_api.h:59:9: warning:
#warning Cilk
API is being used with non-Cilk compiler (or Cilk is disabled) [-Wcpp]
#
On 10/28/2013 02:25 AM, Frederic Riss wrote:
Is there a clean way to have the compiler discard the unneeded stack slot?
Not yet. There is a rewrite of the atomic support in gcc to
move away from using builtins, which will allow two outputs
to be ssa allocacted. But this will not be complete
On 10/29/2013 03:06 AM, Richard Biener wrote:
On Mon, Oct 28, 2013 at 7:33 PM, Richard Henderson r...@redhat.com wrote:
On 10/28/2013 02:25 AM, Frederic Riss wrote:
Is there a clean way to have the compiler discard the unneeded stack slot?
Not yet. There is a rewrite of the atomic support
On 11/11/2013 11:57 PM, Richard Biener wrote:
On Mon, Nov 11, 2013 at 2:39 PM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Nov 11, 2013 at 02:13:24PM +0100, Richard Biener wrote:
On Mon, Nov 11, 2013 at 12:39 PM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Nov 11, 2013 at 12:29:29PM +0100,
On 11/20/2013 03:33 AM, Peter Zijlstra wrote:
On Tue, Nov 19, 2013 at 05:02:20PM +, Mathieu Desnoyers wrote:
Unfortunately I don't have a ARM cross-compiler setup ready. Nathan could
test
it for us though.
It might shuffle things around enough to work around the issue, but with the
On 01/16/2014 05:51 AM, Kyrill Tkachov wrote:
Hi Richard,
I noticed that Makefile.in in libatomic sets -march=armv7-a when compiling for
arm linux targets with ifunc support:
@ARCH_ARM_LINUX_TRUE@@HAVE_IFUNC_TRUE@IFUNC_OPTIONS = -march=armv7-a
-DHAVE_KERNEL64
Is there any particular
On 02/14/2014 07:43 AM, Jakub Jelinek wrote:
So, perhaps we should just stop for now oring the copyfrom in and just use
the copyfrom from the very first mapping only, and wait for what the committee
actually agrees on.
Richard, your thoughts on this?
I think stopping the or'ing until the
On 02/28/2014 03:37 AM, Thomas Schwinge wrote:
The process cannot recover from this, trying to continue despite the
error. (It is of course questionable what exactly to do in this case, as
libgomp's internal state may now be corrupt.) So far, such errors may
have been rare (aside from real
On 03/04/2014 01:23 AM, Richard Biener wrote:
Doesn't sound like a bug but a feature. We can move
asm ( : : : memory) around freely up to the next/previous
instruction involving memory.
Asms without outputs are automatically volatile. So there ought be zero change
with and without the
On 03/04/2014 10:12 PM, Yury Gribov wrote:
Asms without outputs are automatically volatile. So there ought be zero
change
with and without the explicit use of the __volatile__ keyword.
That’s what the documentation says but it wasn’t actually true
as of a couple of releases ago, as I
On 04/16/2014 12:01 AM, John Marino wrote:
On 4/16/2014 03:22, Ian Lance Taylor wrote:
On Tue, Apr 15, 2014 at 4:45 AM, Douglas B Rupp r...@adacore.com wrote:
On 04/14/2014 02:01 PM, Ian Lance Taylor wrote:
No I considered that but I think that number will be very small. Will you
concede, in
On 04/16/2014 12:48 PM, Douglas B Rupp wrote:
On 04/16/2014 12:38 PM, Eric Botcazou wrote:
Because GCC would then be already incompatible with the Intel compiler from
which this interface was drawn, way back when the ia64 support was added to
GCC and we redesigned GCC's exception handling.
On 04/16/2014 03:05 PM, Paul Shortis wrote:
Solved... kind of.
*ldsi is one of the patterns movsi is expanded to and as the name suggests it
only handles register loads. I know that at some stages memory references will
pass the register_operand predicate so I changed the predicate for
On 04/17/2014 10:14 AM, DJ Delorie wrote:
_medium_frame:
pushm r6-r12
add #-4, r0, r6 ; marked frame-related (fp = sp - 4)
mov.L r6, r0 ; marked frame-related (sp = fp)
There's your
On 04/18/2014 11:31 PM, Richard Henderson wrote:
On 04/17/2014 10:14 AM, DJ Delorie wrote:
_medium_frame:
pushm r6-r12
add #-4, r0, r6 ; marked frame-related (fp = sp - 4)
mov.L r6, r0
On 04/21/2014 09:53 AM, Jan-Benedict Glaw wrote:
/home/jbglaw/repos/gcc/gcc/config/sparc/sparc.c:4858: error: invalid
conversion from ‘int’ to ‘machine_mode’
Yes, something has changed recently in the build flags to (I believe) remove
-fpermissive. Quite a few backends are affected by this
On 04/21/2014 11:02 AM, Jakub Jelinek wrote:
but I'd say for GCC codebase it is better if we fix
the few users of these macros that pass an int rather than enum machine_mode
to these macros.
I agree. In the aarch64 backend it determined that we were passing a
reg_class_t and not a mode at
On 04/22/2014 12:26 AM, Jakub Jelinek wrote:
I've committed following fix as obvious after testing it with a
x86_64-sparc64-linux cross-compiler.
2014-04-22 Jakub Jelinek ja...@redhat.com
PR target/60910
* config/sparc/sparc.c (sparc_init_modes): Pass enum machine_mode
On 04/30/2014 12:57 AM, Matthias Klose wrote:
Am 16.04.2014 09:02, schrieb r...@redhat.com:
I'll see about puting some rpms somewhere public so that no one else
has to do the whole canadian-cross compile dance.
are these already online? a tarball would be fine too. And is there a
backport
On 05/22/2014 03:12 AM, Jakub Jelinek wrote:
No way. SUBREG_PROMOTED_UNSIGNED_P right now resides in two separate bits,
volatil and unchanging. Right now volatile != 0, unchanging ignored
is -1, volatile == 0, then the value is unchanging.
What I meant is change this representation, e.g. to
On 08/20/2014 08:22 AM, Wilco Dijkstra wrote:
2. Change the mid-end to call arch_frame_pointer_required even when
!flag_omit_frame_pointer.
Um, it does that already. At least as far as I can see from
ira_setup_eliminable_regset and update_eliminables.
It turns out to be much easier to
On 09/03/2014 03:14 PM, Paul Shortis wrote:
(insn 33 84 85 6 (parallel [
(set (reg:HI 1 r1)
(ashift:HI (reg:HI 1 r1)
(const_int 1 [0x1])))
(clobber (reg:CC_NOOV 7 flags))
])
On 11/13/2014 03:55 PM, H.J. Lu wrote:
x86-64 psABI has
name@GOT: specifies the offset to the GOT entry for the symbol name
from the base of the GOT.
name@GOTPLT: specifies the offset to the GOT entry for the symbol name
from the base of the GOT, implying that there is a corresponding PLT
Dominik Vogt and I are trying to get upstream libffi merged
back to gcc, so that we can leverage better support for libgo.
I've done a heavy handed merge into a branch (likely not the
final form), and I'd like it to see wider testing.
Especially Darwin, which is known to be broken upstream.
But
On 12/04/2014 01:54 AM, Richard Biener wrote:
Apart from what Joseph already said using 'sizetype' in the middle-end
for sizes and offsets is really really deep-rooted into the compiler.
What you see above is one aspect - POINTER_PLUS_EXPR offsets
are forced to have sizetype type. But you'd
On 12/10/2014 05:36 AM, Richard Biener wrote:
On Wed, Dec 10, 2014 at 2:24 AM, Richard Henderson r...@redhat.com wrote:
On 12/04/2014 01:54 AM, Richard Biener wrote:
Apart from what Joseph already said using 'sizetype' in the middle-end
for sizes and offsets is really really deep-rooted
On Mon, Jul 16, 2007 at 02:39:39PM -, Wolfram Gloger wrote:
int *p;
p = malloc (4);
*p = 0;
p = realloc (p, 4);
*p = 1;
By that reasoning, consider:
int *p;
p = malloc (4);
*p = 0;
free(p);
p = malloc (4);
*p = 1;
Except that in the first sequence, the value of *p
On 08/01/2011 01:30 PM, Michael Walle wrote:
1) function inlining
2) deferred argument evaluation
3) because our target has no barrel shifter, (arg 10) is emitted as a
function call to libgcc's __ashrsi3 (_in place_!)
4) BAM! dead code elimination optimizes r8 assignment away because
On 08/02/2011 05:22 AM, Richard Guenther wrote:
-fno-tree-ter also unbreaks the ARM test case in PR48863 comment #4.
It's of course only a workaround, not a real fix as nothing prevents
other optimizers from performing the re-scheduling TER does.
I suggest to amend the documentation for
On 08/03/2011 07:02 AM, Richard Guenther wrote:
Reserved registers are a no-go (like %esp), either global or local.
Local register variables referring to anything in fixed_regs
are trivial to handle -- continue to treat them exactly as we
currently do. They won't be clobbered by random code
On 08/16/2011 04:20 AM, Kirill Yukhin wrote:
Hi guys,
the question is still opened. Let me try to explain further.
The new MULX instruction is capable to store result of unsigned
multiply to arbitrary pair of GPRs (one of operands still must be DX).
But I have no idea, how to implement such
On 08/17/2011 06:45 PM, Andrew Pinski wrote:
gcc/libgcc2.c: In function ‘__gnu_mulsc3’:
gcc/libgcc2.c:1928:1: internal compiler error: in scan_trace, at
dwarf2cfi.c:2433
Please submit a full bug report,
I assume that it is because the C6X has more than one delay slot ?
Ug. I knew c6x
On 08/18/2011 08:16 AM, Richard Henderson wrote:
On 08/17/2011 06:45 PM, Andrew Pinski wrote:
gcc/libgcc2.c: In function ‘__gnu_mulsc3’:
gcc/libgcc2.c:1928:1: internal compiler error: in scan_trace, at
dwarf2cfi.c:2433
Please submit a full bug report,
I assume that it is because the C6X
On 08/23/2011 11:37 AM, Konstantin Vladimirov wrote:
Hi, all
Consider architecture, where *any* data register have associated flag
field. I.e. any register may be used as a data store to further use,
and as a flag keeper to further branch.
I don't understand what you mean by data store.
If
On 08/23/2011 01:41 PM, Konstantin Vladimirov wrote:
Yes, it is exactly what I have now -- myself optimization pass with
peephole-like rule for such cases. Is it all, that is possible here?
Certainly you can do more than peepholes. That's why I told you to
look at compare-optimize.c.
May be
On 09/14/2011 01:00 PM, Aldy Hernandez wrote:
This was very painful, and it's still not over. We hadn't merged in
almost 1.5 years, and we're paying for it now...
To be fair, the pause in merging was to have a stable base in which
to finish the Velox project. Of course, that ended 9 months
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 memory barriers in RTL, the *.md patterns should be
fixed. The only exception should be IMHO the __SYNC_MEM_RELAXED
variants
On 09/22/2011 07:47 AM, Bernd Schmidt wrote:
dwarf2cfi should be able to figure this out. I'd need to see RTL dumps
to get an idea what's going on.
Indeed. Please CC me, Alan.
r~
On 09/27/2011 11:45 AM, Iyer, Balaji V wrote:
Hello Everyone,
Is there a test-case which emits the ARRAY_RANGE_REF tree node for C or
C++ Compiler? Can someone tell me an example (or even a line of code) that
will make the compiler create/emit this tree node?
I'm pretty sure this can
On 09/30/2011 01:36 PM, Andrew MacLeod wrote:
http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary
__atomic_store (size_t obj_size, T *mem, T val, enum memory_model model)
I don't like this. I really cannot imagine any situation for which the
compiler can't resolve SIZE to a compile-time constant.
On 10/03/2011 10:54 AM, Andrew MacLeod wrote:
its a library call for arbitrary sized objects... C++ can have any
class declared atomic, so it doesn't have to map to one of those
optimized lock-free routines.
Ah, I get it now. Ew.
r~
These patterns:
(define_insn avx2_lshlqv4di3
[(set (match_operand:V4DI 0 register_operand =x)
(ashift:V4DI (match_operand:V4DI 1 register_operand x)
(match_operand:SI 2 const_0_to_255_mul_8_operand
n)))]
TARGET_AVX2
{
operands[2] = GEN_INT (INTVAL
On 10/05/2011 07:16 PM, David Miller wrote:
From: David Bremner dbrem...@gmail.com
Date: Wed, 5 Oct 2011 19:08:41 -0700
What about treating these instructions as fused multiply-adds with
constant arguments?
Richard Henderson (CC:'d) chatted with me the other day about this and
made
[ Using the UltraSparc Architecture, Draft D0.9.4, 27 Sep 2010.
I believe this is the most recent public manual. It covers
VIS1 and VIS2 but not VIS3. ]
The comment for fpmerge_vis is not correct.
I believe that the operation is representable with
(vec_select:V8QI
(vec_concat:V8QI
On 10/13/2011 12:26 AM, Zoltán Kócsi wrote:
So I don't know if it is a bug (i.e. the compiler is supposed to protect local
reg vars) or just misleading/omitted information in the info page?
It's the documentation that could perhaps be improved.
Local register variables are not protected from
On 10/13/2011 11:26 AM, David Miller wrote:
Therefore, I think this 16 x 16 multiply operation isn't the kind
you think it is, and it's therefore not appropriate to use this in the
compiler for vector multiplies.
Ah, I see the magic word in the docs now: fixed point.
I.e. class MODE_ACCUM not
On 10/13/2011 12:55 PM, David Miller wrote:
-(define_insn vis3_addsub_ss_insnvbits_vis
+(define_insn vis3_addsub_ss_patnamemode
Missing a 3 on the end. Otherwise these look ok.
Unfortunately, that would involve some ABI changes for the VIS
builtins. I'm trending towards considering just
On 10/17/2011 07:09 AM, Bob Breuer wrote:
I don't think this is a free/g_free issue. If I use the following
patch, then I at least get the openbios messages:
diff --git a/cpu-exec.c b/cpu-exec.c
index a9fa608..dfbd6ea 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -180,6 +180,7 @@ static
On 10/17/2011 12:14 PM, Blue Swirl wrote:
IIRC buggy versions of alloca() could also fail without a frame pointer.
(1) GCC always uses a frame pointer for alloca,
(2) Unless you do -fno-builtin-alloca, we always implement it inline.
r~
On 10/17/2011 03:50 AM, Paulo J. Matos wrote:
Hi,
To negate a double word (HImode) register, I used to take the instruction all
the way to assembly generation and then expand into three assembly
instructions like so:
xor %t0, # ; invert bits in top word of op0
nadd %b0, #0;
On 10/19/2011 02:05 PM, Bob Breuer wrote:
Is it possible to force a
stackframe by just adding a suitable attribute to either the setjmp
function prototype, or the function which calls setjmp?
The only thing I can think of that'll be portable to a large number
of versions of GCC is
{
int
On 10/21/2011 06:10 AM, BELBACHIR Selim wrote:
Is it possible to define arithmetic standard parttern with operands matched
by memory_operand only?
No.
r~
On 10/20/2011 07:41 AM, Paulo J. Matos wrote:
(define_insn_and_split neghi_internal
[(set (match_operand:QI 0 register_operand =c)
(neg:QI (match_dup 0)))
(set (match_operand:QI 1 register_operand =c)
(plus:QI
(plus:QI
(ltu:QI (neg:QI
On 10/21/2011 09:13 AM, Peter Bigot wrote:
Are there any existing machine descriptions that do model the carry
flag separately, specifically to model rotate operations that use the
carry flag as the destination and source for the shifted bit? Or is
the best I can do for that is to have the
On 10/21/2011 10:15 AM, Paulo J. Matos wrote:
So I have implemented the nadd and addc as:
(define_insn negqi2
[(set (match_operand:QI 0 register_operand =c)
(neg:QI (match_operand:QI 1 register_operand 0)))
(set (reg:CC_C RCC) (eq (match_dup 1) (const_int 0)))
(clobber
On 10/21/2011 05:49 PM, paul_kon...@dell.com wrote:
There are lots of parts of the compiler that don't optimize well when an
insn has more than one output. For the normal insn, just clobber the flags;
don't include a second SET.
Yes, but... isn't the whole point of CC modeling that you
On 10/27/2011 10:05 PM, David Miller wrote:
I'm getting an ICE on 64-bit sparc for some vector test cases but
I'm not sure where the fix belongs.
When the compiler expands a vecor shift by scalar into a vector
shift by a vector it uses expand_vector_broadcast(), which has
a comment which
On 10/28/2011 06:49 AM, Peter Bigot wrote:
I'm inclined to follow sparc's lead, but is one or another of the choices
more likely to help combine/reload/etc do a better job?
I don't know.
In the case of RX, we don't model CC_REG until after reload, so combine really
doesn't get a shot at it.
On 10/29/2011 05:41 AM, Peter Bigot wrote:
It seems cc0 should probably still be preferred for CISC-style
architectures like the MSP430. I'll give that approach a try.
I think that's somewhat unfair. Take a close look at the RX and
mn10300 ports -- they're what I would call the most
On 11/01/2011 02:59 PM, Hans-Peter Nilsson wrote:
Please, when replying, also send to me, not just the list.
On Tue, 1 Nov 2011, Paulo J. Matos wrote:
On 01/11/11 02:43, Hans-Peter Nilsson wrote:
Not obvious or maybe I was unclear as to what I alluded?
In the below insn-bodies, sub is the
On 11/03/2011 12:54 PM, Iyer, Balaji V wrote:
Is it possible to make sure that the LABELX occurs right after the Call
some_function instruction (and the instruction scheduler moves the label
with the call INSN)? I insert the label right after the call is expanded and
LABELX is being moved
On 11/04/2011 09:01 PM, Joern Rennecke wrote:
Is there a way to have a predicate forward declaration?
No, sadly. Something for a future enhancement in the genfoo.
r~
On 11/12/2011 07:38 AM, Uros Bizjak wrote:
On Fri, Nov 11, 2011 at 8:58 PM, Dominique Dhumieres domi...@lps.ens.fr
wrote:
For the record, Jakub's comment on IRC:
with older gdb you simply had to find the stwcx
or whatever SC insn is, put a breakpoint after
it and continue instead of
On 11/17/2011 12:37 AM, Alan Modra wrote:
- oldval = convert_modes (SImode, mode, oldval, 1);
+ oldval = gen_reg_rtx (SImode);
+ convert_move (oldval, orig, 1);
oldval = expand_simple_binop (SImode, ASHIFT, oldval, shift,
oldval, 1,
On 11/17/2011 02:34 PM, David Edelsohn wrote:
On Thu, Nov 17, 2011 at 3:25 PM, Richard Henderson r...@redhat.com wrote:
On 11/17/2011 12:37 AM, Alan Modra wrote:
- oldval = convert_modes (SImode, mode, oldval, 1);
+ oldval = gen_reg_rtx (SImode);
+ convert_move (oldval, orig, 1
On 11/20/2011 01:28 AM, Hans-Peter Nilsson wrote:
As subject says, in libgcc, why is $(srcdir)/emutls.c in
LIB2ADDEH (and LIB2ADDEHSTATIC and LIB2ADDEHSHARED) instead of
LIB2ADD?
Emulating TLS has nothing to do with exception-handling, nor is
there something that might throw while calling
On 11/21/2011 02:47 AM, Andrew Haley wrote:
On 11/21/2011 04:13 AM, Jeff Law wrote:
This is (arguably) a glibc issue. I'm still investigating.
Attached you'll find the hack from the gcc46 srpms we're using to work
around the problem right now.
Why is isspace() marked throw, anyway?
Not
On 11/22/2011 10:55 AM, Bodart, Mitch L wrote:
What aspect of inline asm processing is preventing gcc from allocating
register eax to both %0 and %1's address in the following test case?
gcc -m32 -S foo.c
foo.c: In function 'foo':
foo.c:20: error: can't find a register in class
On 11/22/2011 12:11 PM, Bodart, Mitch L wrote:
Unfortunately the source change suggestion didn't work, but that's OK because
I can make the asm work by eliminating some register pressure.
Hmm. Well, if you keep that memory clobber there, you don't actually
need to represent the RW memory as
On 11/30/2011 10:07 AM, Andrew MacLeod wrote:
PS. Reflecting upon it, I wonder if it could be a part of the gcc
libraries like libgomp or libitm are. During configuration we could
check to see if there is an existing libatomic in the system, and if
there is NOT, enable building libatomic...
For the past couple of years I've simply ignored these problems by
ritually adding 'echo .NOTPARALLEL: Makefile' to my top-level
issue-the-long-configure-option scripts.
But I suppose the reason why these never get fixed is no one reporting...
This one happened shockingly early.
$ make -j4
On 12/02/2011 06:35 AM, Richard Guenther wrote:
I see. As we do not explicitely model this dependency we probably
get lucky by the if (gimple_has_volatile_ops ()) bail-out; most
passes do.
What are you talking about? Of course we do.
int
read_dependence (const_rtx mem, const_rtx x)
{
1 - 100 of 3251 matches
Mail list logo
