On 02/19/2010 04:18 AM, Paolo Carlini wrote:
> On 02/19/2010 01:07 PM, Paolo Carlini wrote:
>> On 02/19/2010 12:38 PM, Aldy Hernandez wrote:
>>
>>> Since the TM library on ia32 is built with -m486, which doesn't
>>> have 64-bit atomic operations, should we...
>>>
>>> a) Build with -m586 and above
On 03/10/2010 09:02 AM, Frank Isamov wrote:
> How can I tell GCC that that the callee should load from the
> original offset + 4?
You'll want to set FIRST_PARM_OFFSET and INCOMING_FRAME_SP_OFFSET.
r~
On 03/12/2010 09:33 PM, David Miller wrote:
> I couldn't figure out immediately how to fix this as the
> way LTO does spec overriding and such looked non-trivial.
It would not be a bad thing, IMO, if the sparc assembler
were extended to be able to emit any reloc directly, without
needing a specifi
On 03/16/2010 12:28 PM, David Miller wrote:
> It's not the assemblers fault.
>
> We're using %hi() and expecting the assembler to emit a
> PC relative relcation just because the symbol name happens
> to be _GLOBAL_OFFSET_TABLE_ And it will do this, but only
> when -PIC. Changing that is pretty d
On 03/23/2010 05:55 AM, redriver jiang wrote:
> Hi all,
>
> Can this "STARTING_FRAME_OFFSET" macro be defined to be a non-constant
> value ( changes with the "current_function_args_size")?
>
> As the target process has "FP+offset" with postive "offset"( stack
> grows upward, and parameters in sta
On 03/25/2010 04:31 AM, Eric Botcazou wrote:
>> It seems to me that both the gen_lowpart and simplify_shift_const do the
>> wrong things in handling vector type. (zero_extend:SI (subreg:HI (V4HI)) is
>> not equal to (subreg:SI (V4HI)), is it? simplify_shift_const produces
>> (ashift:V4HI (V4HI..)
On 04/08/2010 09:59 AM, Aldy Hernandez wrote:
> The problem is that now the problem is present on a serial make (ala,
> "/src/configure && make").
I've reliably reproduced this. As far as I can tell, it's a problem
of makefile variable expansion in the top-level make.
For the folks just joining
On 04/09/2010 03:16 PM, Jonathan Wakely wrote:
Is the only C++ header that causes a problem?
is exactly equivalent to because it only declares
macros, which are not in namespace std anyway.
So if that's the only problem, using instead of
would solve it.
No, we also use , so avoiding the
Jeff Law wrote:
(mem/c:DI (reg:DI 122 r122 [121]) [64 ivtmp.743+0 S8 A64])
and
(mem/c:DI (reg:DI 122 r122) [64 ivtmp.1640+0 S8 A64])
...
Yes. There's code at the start of nonoverlapping_memrefs_p to handle
these cases, but as Pat pointed out, it doesn't work for large offsets
from the stack/f
Jeff Law wrote:
Presumably mucking around with the MEM_EXPR on the DECL isn't going to
mess up inlining? What about debugging?
I'm certain it won't mess up inlining, because all that is long
done with by the time we're in rtl -- it's all just one big
function by this time.
I wouldn't have tho
Omar Torres wrote:
On Thu, Oct 2, 2008 at 11:59 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
"Omar Torres" <[EMAIL PROTECTED]> writes:
Shouldn't this macro:
#define REAL_VALUE_TO_TARGET_DOUBLE(IN, OUT) \
real_to_target (OUT, &(IN), mode_for_size (64, MODE_FLOAT, 0))
be using DOUBLE_TYP
Andrew Haley wrote:
D.843 = &java.text.Collator.class$$;
D.845 = &_CD_java_text_Collator;
_Jv_InitClass (D.843);
This is always a valid transformation.
i.e. the memory reference is moved to before the call to _Jv_InitClass.
There is no memory reference in the above case, it seems jus
I've created
svn://gcc.gnu.org/svn/gcc/branches/transactional-memory/
for the development of support for transactional memory within gcc.
This branch will track mainline gcc. There are some folks that have
already been working on this project; their page is at
http://www.hipeac.net/node/24
Diego Novillo wrote:
We are currently emitting object files that contain both final code
and IL. I believe this is wasteful and does not really serve a useful
purpose. However, I think we started emitting hybrid object files for
some reason. Does anyone remember why?
If the version of GCC be
Timo Kreuzer wrote:
I am working on x64 SEH for ReactOS. The idea is to use .cfi_escape
codes to mark the code positions where the try block starts / ends and
of the except landing pad. The emitted .eh_frame section is parsed after
linking and converted into Windows compatible unwind info / scope
__builtin_frame_address with non-zero arguments is not supported on most
targets these days. It'll work on x86-64 if you also compile with
-fno-omit-frame-pointer.
That said, you almost certainly want to be using backtrace(3) instead.
r~
Ian Lance Taylor wrote:
Michael Eager <[EMAIL PROTECTED]> writes:
I'm running into a situation where reload is replacing
a pseudo-register in an insn with a memory reference.
The problem is that this is happening in a memory ref.
The initial pattern is something like
(set (reg/v:SI 1) (mem/s:
Michael Eager wrote:
Another possibility is illegal rtl sharing.
If you mean that an rtx would be pointed to by two different
insn's, how would that happen? (Excluding someone mucking
things up deliberately or accidentally.)
Generally this sort of mistake happens in the backend somewhere.
E.
... is the problem one of SPECs ?
I don't think so, unless we can key off -pthread or something.
.. or does every single TLS case need a darwin-specific addition to
reference -lgcc_eh ?
We can add that via tls.exp.
.. I guess also that target-supports.exp would need some modification to
ac
On 06/23/2009 03:27 PM, Steven Bosscher wrote:
Hi,
I have a question about ifcvt.c:dead_or_predicable. This function is
pretty complicated and it's not really clear to me what it is doing.
But I'll have to understand what is going on because there is a bug in
this function that I would like to
On 07/01/2009 08:36 AM, Jean Christophe Beyler wrote:
I tracked it down to the gcse pass. However, I thought I had turned
this off in the definition of a movdi in my machine description. But
apparently this is not sufficient, any ideas?
You probably just changed the constraint letters, but didn
On 07/01/2009 11:28 AM, Jean Christophe Beyler wrote:
Ok, I think I understand, I've been therefore playing with this. I
initially had:
(define_insn "movdi_internal1"
[(set (match_operand:DI 0 "nonimmediate_operand" "=r,r,r,R,T,r,R,o")
(match_operand:DI 1 "general_operand" "r,iF
On 07/01/2009 02:02 PM, Jean Christophe Beyler wrote:
((reload_in_progress | reload_completed) == 0&&
MEM_P (op0)&& !REG_P (op1)))
{
op1 = force_reg (GET_MODE (op0), op1);
emit_move_insn (op0, op1);
return 1;
I wouldn't think you'd actu
On 07/01/2009 02:49 PM, Amitabha Roy wrote:
A search led me to this message
http://gcc.gnu.org/ml/gcc/2005-11/msg00206.html
which says that it is true, or at least was true back then.
Still true today.
r~
On 07/07/2009 02:21 AM, Bingfeng Mei wrote:
Hello,
Our GCC port& VLIW target processor support predication. However, I don't
see the GCC schedule two mutually exclusive blocks (from IF and ELSE ) in
a way that they are independent from each other.
I am wondering if this is a problem of our port
On 07/08/2009 03:11 PM, Larry Evans wrote:
It would be much easier if gdb understood __extension__. Is there a way?
In this case, no. It's protecting a statement expression, which gdb
will never be able to parse.
A better project for helping debug gcc would be to convert all macros
that us
Re: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01404.html
Do you have test cases for this?
Changing can_throw_internal/external to depend on whether or not future
inlining is possible looks *very* wrong to me. Surely the only thing
that matters for new code that might appear "below" this po
On 07/11/2009 05:59 AM, Jan Hubicka wrote:
Well, we can either teach inlinable_call_p to handle your new indirect
calls as "for sure uninlinable", make it conservative and consider all
calls inlinable or we can stop doing the early removal of MUST_NOT_THROW
receivers.
I think this last option w
On 07/11/2009 10:59 AM, Jan Hubicka wrote:
I would like to bring more of EH lowering to tree level (i.e. instead of
relying on RTL to lower RESX instructions into gotos/calls/jumptables do
this at gimple and keep to RTL world only job of constructing landing
pads).
Sure. Should probably turn E
On 06/23/2010 06:03 AM, Alan Modra wrote:
> On Tue, Jun 08, 2010 at 10:27:03PM +0930, Alan Modra wrote:
>> PowerPC64 gcc support for a larger TOC via -mcmodel option.
> [snip]
>
> I'm having second thoughts about the optimization I added to PowerPC64
> gcc with the patch hunk below. Its effect is
On 06/03/2010 05:24 AM, Uros Bizjak wrote:
> ; Current assemblers are broken and do not allow @GOTOFF in
> ; ought but a memory context.
>
> Code, following this comment disables or special-cases
> "pic_symbolic_operands".
>
> I'm investigating, which "current assemblers"
On 06/25/2010 11:09 AM, Rainer Orth wrote:
> The Solaris 8/x86 assembler handles the first form just fine, with
> output identical to gas 2.20.1.
Excellent.
r~
On 06/30/2010 05:06 AM, M. -Eqbal Maraqa wrote:
> f1.c:5:1: error: unrecognizable insn:
> (insn 12 11 13 3 f1.c:4
>(set (mem/c/i:SI (reg/f:SI 23 [ D.1964 ]) [0 +0 S4 A32])
> (mem/c/i:SI (plus:SI (reg/f:SI 19 virtual-stack-vars)
> (const_int -4 [0xff
On 06/30/2010 03:46 PM, Dave Korn wrote:
> Although we could build plugins as Windows DLLs and have GCC load them at
> runtime, if those DLLs needed to refer to anything in the main GCC executable,
> it would have to be specifically linked to import it - and imports on Windows
> have to explicitl
On 06/30/2010 04:21 PM, Jan Hubicka wrote:
>> Long term we could arrange for libbackend.a to become libbackend.dll and
>> have that library be used for plugins. The existing practice of linking
>> back into the main executable is more or less an efficiency hack that
>> happens to work with ELF.
>
On 07/07/2010 08:51 AM, Aldy Hernandez wrote:
> * configure.ac: Call LIBITM_CHECK_64BIT_SYNC_BUILTINS.
> * beginend.cc (begin_transaction): If 64-bit sync builtins are not
> available, use pthread mutexes.
> * acinclude.m4 (LIBITM_CHECK_64BIT_SYNC_BUILTINS): New.
> * c
On 08/05/2010 06:48 AM, Claudiu Zissulescu wrote:
> I want to use a different CALL_USED_REGISTER set per individual
> function. The issue here is to inform a caller about the callee
> CALL_USED_REGISTERS and save/restore at caller level the possible
> altered registers. This should reduce the numb
On 08/09/2010 06:28 AM, Steven Bosscher wrote:
> I would like to convert these remaining define_peepholes to
> define_peephole2s instead. However, I can't find a define_insn that
> produces the bcs or bcc instructions. Could use a little help figuring
> out what insn I should generate in the peepho
On 08/09/2010 07:20 AM, Claudiu Zissulescu wrote:
> I set to zero all CALL_USED_REGISTERS (except the fixed regs), and
> then in the expand_call I set CALL_INSN_FUNCTION_USAGE to the list of
> clobbered registers (given by attribute attached to a function
> declaration). Then, I should be able to
On 08/11/2010 10:59 AM, Ralf W. Grosse-Kunstleve wrote:
> My original posting shows that gfortran and g++ don't do as good
> a job as ifort in generating efficient machine code. Note that the
> loss going from gfortran to g++ isn't as bad as going from ifort to
> gfortran. This gives me hope that t
On 08/17/2010 06:20 AM, roy rosen wrote:
> 2. Is there a way to remove this pass and keep coherency of the
> following passes, so that in the RTL stage I would be able to handle
> complex numbers (CHI/CSI) and not the decomposed code?
By adjusting the rules as to what's legal GIMPLE, yes. This
ma
On 08/18/2010 12:06 PM, Michael Meissner wrote:
> Now, unfortunately, I've been away from the code for about 2 years, and I
> don't
> know whether it has bit-rotted or not.
It hasn't. In fact, the Vectorize _cpp_clean_line thread
contains a patch that uses it. Not quite ready to commit,
but nea
On 08/18/2010 01:02 PM, Michael Meissner wrote:
> Cool. I've been hoping to get the decks cleared, and add the power support as
> well.
Adding ppc support would be Really Nice. At the moment I
appear to be limited to #ifdef __ALTIVEC__.
r~
On 08/23/2010 11:05 AM, Mohamed Shafi wrote:
> sub.s32 srcdstGP, #imm16 // signed 16-bit register to immediate subtract
> sub.u32 srcdstGP, #imm16 // unsigned 16-bit register to immediate subtract
Having both of these is probably not useful. Bernd pointed
out that a 17-bit constant would be more
On 08/30/2010 03:45 AM, Adam Jiang wrote:
> When I read the source in Linux kerne, it was said that stack canary for
> implementing stack protector is defined as an offset to %gs on x86
> architecture. How about stack canary defined on MIPS?
It's not implemented for MIPS.
r~
On 08/30/2010 10:37 AM, Uros Bizjak wrote:
> I'm not familiar in versioning stuff, but since soft-fp symbols are
> part of generic libgcc-std.ver for a long time (before 4.5.0), I
> believe, it is enough to patch only configure files (see i.e. commits
> that enabled soft-fp on mingw/cygwin/-gnu*).
On 08/30/2010 12:25 PM, Uros Bizjak wrote:
> Attached is my best (untested) shot at libgcc-bsd.ver. Someone has
> to write i386/t-freebsd (similar to i386/t-linux) and connect it to
> the build system. The versioning assumes that this will be committed
> to 4.5.x first.
That file looks plausible,
On 09/08/2010 07:15 AM, Paulo J. Matos wrote:
> Hello,
>
> I have noticed that at least in GCC4.3 the switch cases are ordered
> somewhere in a pass, since they arrive at expand pass ordered in
> increasing order.
>
> Can anyone tell me if I can assume this always to happen and where this
> is h
On 09/08/2010 02:25 PM, Paulo J. Matos wrote:
> To submit a patch for a new pass for review, is there any due date for
> inclusion on the next version?
Yes, I recall seeing a message about this.
http://gcc.gnu.org/ml/gcc/2010-08/msg00477.html
> Should I discuss it with someone?
Almost certain
On 09/27/2010 03:47 AM, Luke A. Guest wrote:
> I can't see any mention of unwind in the the t-linux-eabi file, I'm
> probably missing something I just don't unerstand here :D
Because it's in config/arm/t-bpabi.
Do be clear on whether you're working on arm-linux-eabi, i.e. with
the ARM EABI unwind
On 09/27/2010 01:30 PM, DJ Delorie wrote:
> (insn 115 114 117 15 dj.c:256 (parallel [
> (set (reg:SI 12 r12 [139])
> (plus:SI (reg:SI 3 r3 [orig:54 pretmp.923 ] [54])
> (reg:SI 12 r12 [138])))
> (set (reg:CC_ZSC 16 cc)
> (c
On 09/27/2010 03:37 PM, DJ Delorie wrote:
>> I think it's probably a mistake to have the default ADD
>> instruction SET the flags, rather than CLOBBER them.
>
> How else would we optimize away compares?
By having a separate ADD that looks like your current one.
Combine will put them together for
On 09/27/2010 04:21 PM, DJ Delorie wrote:
> Would we have to do that for *all* the math/logic ops, or just add?
All of them of course.
r~
The 64-bit PEI format has a SECREL32 relocation type. It
does not, however, have a SECREL64 relocation type. Which
means that for
> #define DWARF_REF_SIZE \
> (dwarf_version == 2 ? DWARF2_ADDR_SIZE : DWARF_OFFSET_SIZE)
we don't really have something to use for for dwarf2.
I could fake it wi
On 09/28/2010 03:09 AM, Kai Tietz wrote:
> * config/i386/cygming.h (ASM_OUTPUT_DWARF_OFFSET): Output
> addition zero for padding of secrel32 requested for 8 bytes.
>
> I will apply this today, if there aren't any objections.
I've committed the following instead, which I think
On 09/28/2010 09:50 AM, Kai Tietz wrote:
> 2010/9/28 Richard Henderson :
>> On 09/28/2010 03:09 AM, Kai Tietz wrote:
>>> * config/i386/cygming.h (ASM_OUTPUT_DWARF_OFFSET): Output
>>> addition zero for padding of secrel32 requested for 8 bytes.
>
The test program in target-supports.exp is broken, since
it doesn't preclude the use of cleanups instead. Indeed,
the init/cleanup3.C seems to be essentially identical to
the target-supports test.
Any suggestions that doesn't essentially reverse this
situation? I.e. I could switch the target-sup
On 09/29/2010 04:31 PM, Michael Eager wrote:
> float a = 1.0, b = 2.0, x = NaN;
> (a < b) generates the same condition flags as (a < x).
...
> Are there other processors which do this? How do they
> handle generating IEEE std compliant code?
It looks like there is a bunch of code under config
tha
On 10/01/2010 10:58 AM, Sean McGovern wrote:
> Hi,
>
> I was wondering how people manage to get the branch and svn revision into the
> subject of a contrib/test_summary submission. Is it supposed to be detected
> automagically? Or is it something you add with configure --with-pkgversion
> when
Currently we have
STACK_BOUNDARY
-- minimum alignment enforced by hardware.
PREFERRED_STACK_BOUNDARY
-- a preserved alignment greater than what the hw enforces
(defaults to STACK_BOUNDARY)
INCOMING_STACK_BOUNDARY
-- an alignment provided by callers on function entry.
(defaults to PREFE
On 10/04/2010 11:00 AM, Paul Brook wrote:
> Your proposal doesn't make this problem any worse, if anything it's better
> because we don't have to device between S_B and PREFERRED_STACK_BOUNDARY. I'm
> just noting that documenting this as a hardware property is at best
> misleading.
Well, I'm ho
On 10/02/2010 04:03 PM, H.J. Lu wrote:
>> MIN_STACK_BOUNDARY
>> (undocumented; local to i386 atm)
>> -- appears to be the ABI specified stack boundary, i.e.
>> the minimum that must be in place at a call site. This
>> somehow differs from I_S_B due to proliferation of
>> command-line options.
On 10/04/2010 04:24 PM, H.J. Lu wrote:
> As I remembered, -mforce-drap exposed issues with register allocator.
> ix86_force_drap is only referenced in one place in i386.c. I'd like to keep
> it. I don't see why it can't be moved to generic. It may expose problems
> for other targets.
I doubt very
On 10/05/2010 06:54 AM, Joakim Tjernlund wrote:
> Ian Lance Taylor wrote on 2010/10/05 15:47:38:
>> Joakim Tjernlund writes:
>>> While doing relocation work on u-boot I often whish for strings/const data
>>> to be accessible through %pc relative address rather than and ABS address
>>> or through
On 10/05/2010 01:55 PM, Joakim Tjernlund wrote:
> I don't do x86 or alpha so let me ask: If you run the code on an address
> != link address, will it do the right thing?
Yes of course. It wouldn't be -fpic code otherwise.
> I tested the #pragma/no #pragma on PPC and the resulting code
> was the
On 10/05/2010 02:40 PM, Joakim Tjernlund wrote:
> Especially one that doesn't require each function
> to calculate the GOT address in the function prologue(why is that so?)
Because PIC code can be called from non-PIC code and because
the non-PIC code does not load the GOT address.
Avoiding re-com
On 10/18/2010 02:04 PM, Matt Fischer wrote:
> I'm attempting to port some code to gcc, and in a couple of places
> it's using a construct that it doesn't like. A simplified example is
> the following (this is in global scope):
>
> static const int A = 1;
> static const int B = A;
>
> This compil
> +extern objfile_read *
> +objfile_open_read (int descriptor, off_t offset, const char *segment_name,
> +const char **errmsg, int *err);
...
> +extern objfile_write *
> +objfile_start_write (objfile_attributes *ATTRS, const char *segment_name,
> + const char **errm
On 10/30/2010 01:16 AM, Dave Korn wrote:
>> Do we really want to keep re-reading section data for every section
>> lookup we do? Can't we do this in objfile_open_read?
>
> It should only be necessary to do one section lookup per object file anyway.
> Keep extra data hanging around in memory in
On 10/30/2010 11:37 AM, Dave Korn wrote:
>> Uh, really? I thought there were like a half-dozen lto sections...
>
> Which we iterate over just once, and record them all in a hash table from
> the per-section callback, unless I've missed something.
Oh, right. Nevermind then.
r~
On 11/15/2010 11:12 AM, Jakub Jelinek wrote:
> - if (simple_cst_equal(TREE_VALUE (op), memory_identifier_string) == 1)
> + if (strcmp (TREE_STRING_POINTER (TREE_VALUE (link)), "memory") == 0)
I prefer this solution. I think memory_identifier_string is over-engineering.
Patch to remove
On 11/16/2010 09:29 AM, Mark Mitchell wrote:
> The idea here is that (as with libstdc++), we'd send patches to
> gcc-patches@ and gcc-$arch@, but that reviewers for a particular
> back-end would find it easier to keep track of things on the
> architecture-specific lists, and also that this would ma
On 11/23/2010 12:09 PM, Joern Rennecke wrote:
> If we changed BITS_PER_UNIT into an ordinary piece-of-data 'hook', this
> would not only cost a data load from the target vector, but would also
> inhibit optimizations that replace division / modulo / multiply with shift
> or mask operations.
> So ma
On 11/29/2010 03:25 PM, Ian Lance Taylor wrote:
> Basically, the 64-bit calling convention support assumes that the SSE2
> instructions are always available, and silently fails when -mno-sse2 is
> used. I don't really have an opinion as to whether the compiler needs
> to support this case correctl
On 12/22/2010 06:54 AM, Paolo Bonzini wrote:
> 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.
>
> Perh
On 01/06/2011 01:17 AM, Karel Gardas wrote:
> BTW: This is on GCC Compile Farm IA64 machine. Now my question is: how
> to solve this issue? Does GCC already support something Intel
> discusses in 2008 here:
> http://software.intel.com/en-us/articles/short-data-segment-overflow-error-on-linux-64-on-
On 01/06/2011 06:58 AM, Frederic Riss wrote:
> 136 is a pseudo. I have movdf and movsf patterns that accepts
> constants.
This one statement is suspicious to me. Do I read from this that
you have fp move patterns that accept constants but not registers?
Move patterns are special in that they *mus
On 01/20/2011 01:26 PM, Sergei Trofimovich wrote:
> So I would like to have "large data segment" feature!
> Can you elaborate what exactly needs to be implemented?
>
> From what I see:
> 0. We need additional flag for gcc: let's call it -mhuge-pic
>
> 1. We need to force GCC to generate any GP (r
On 01/22/2011 10:48 AM, Sergei Trofimovich wrote:
> I've attached dirty patch. It has not very nice comments, tabs and spaces yet.
Steve perhaps should weigh in here...
> As I understand, TARGET_AUTO_PIC, TARGET_CONSTANT_GP,
> TARGET_NO_PIC should somehow fall into different memory models.
> I do
On 01/24/2011 11:40 AM, Steve Ellcey wrote:
> On Sat, 2011-01-22 at 12:26 -0800, Richard Henderson wrote:
>> On 01/22/2011 10:48 AM, Sergei Trofimovich wrote:
>>> I've attached dirty patch. It has not very nice comments, tabs and spaces
>>> yet.
>>
>>
On Fri, Jan 20, 2006 at 06:39:21PM +0100, Steven Bosscher wrote:
> FWIW, I don't believe this is a "fix", but rather a solid work-around
> for the problem. I'm still trusting rth's superior compiler brain and
> GCC knowledge to ultimately be ingredients in a real fix ;-)
I don't think it's quite
On Thu, Jan 19, 2006 at 09:56:54PM -0500, DJ Delorie wrote:
> Nobody has said anything about this for the last two weeks. Can we
> remove this restriction now?
Have you done any testing on common platforms to see what
happens when you change this?
r~
On Fri, Jan 20, 2006 at 10:18:18PM +0100, Andreas Tobler wrote:
> or with double guard:
>
> #ifdef HAVE_GETLOADAVG
> #ifdef HAVE_SYS_LOADAVG_H
> # include sys/loadavg.h
> #endif
> #endif
This, I guess.
> >Sounds like a typo in the specs for the platform.
>
> Hm, in gcc.c I find a hardcoded -pth
On Fri, Jan 20, 2006 at 04:44:04PM -0500, DJ Delorie wrote:
> It's been in my x86-64 builds for the last few months. That's the
> "gcc" that gets used for everything else. Are there other platforms
> that are likely to have one-bit insv patterns? (of course, that's the
> question nobody answered
On Fri, Jan 20, 2006 at 03:42:57AM -0500, Jakub Jelinek wrote:
> The mem in the sync insn has alias set 0 and no attributes
> except MEM_VOLATLE_P. The reason why sched1 decided to move it anyway
> is that it proved that the MEMs are different:
Ah yes. I'd meant to go back and add a bit or tag t
On Fri, Jan 20, 2006 at 01:26:51PM -0800, Mark Mitchell wrote:
> I guess a secondary question is: is the workaround sufficiently useful
> in many of the problematic cases and sufficiently non-harmful in other
> cases as to merit inclusion, given that we don't have a better solution?
I replied with
On Fri, Jan 20, 2006 at 04:56:38PM -0500, DJ Delorie wrote:
> If you could suggest a proper testing strategy, I'm willing to test it.
Write a small test that is supposed to use one of the set-bit
insns. Verify that it does before and after the patch.
r~
This is reproducible with an i686 cross.
build/genextract ../../src-head/gcc/config/rs6000/rs6000.md \
insn-conditions.md > tmp-extract.c
*** glibc detected *** build/genextract: double free or corruption (fasttop):
0x081cc980 ***
=== Backtrace: =
/lib/libc.so.6[0x9da124]
/lib/libc.
Got it.
r~
* genextract.c (VEC_safe_set_locstr): Take VEC by reference;
update all callers.
Index: genextract.c
===
--- genextract.c(revision 110129)
+++ genextract.c(working copy)
@@ -187,18 +187,
On Mon, Jan 23, 2006 at 10:29:20PM -0500, DJ Delorie wrote:
> Ok, I can't really read ia64 assembler. Before:
Close enough. Thanks for testing.
r~
On Tue, Jan 24, 2006 at 12:56:51PM -0500, DJ Delorie wrote:
> Ok to apply then?
Yes.
r~
On Tue, Jan 24, 2006 at 05:22:12PM +0100, tbp wrote:
> /usr/local/gomp/bin/g++ -fopenmp main.cc -o omp
c++ gomp is not merged to mainline.
r~
On Wed, Jan 25, 2006 at 08:07:34AM +0100, Andreas Tobler wrote:
> * genautomata.c (main): Add insn-config.h and recog.h to the
> include list.
> * Makefile.in (insn-automata.o): Adjust dependencies for the above
> includes.
Ok.
r~
On Fri, Jan 27, 2006 at 12:14:40PM +0100, Bernd Schmidt wrote:
> Is this something that just isn't supposed to work in 3.4?
Probably. I don't remember that code well.
> Current
> mainline behaves differently and gives me TImode registers (which I'd
> rather prefer not to have to deal with eith
On Fri, Jan 27, 2006 at 06:20:41PM -0500, Daniel Berlin wrote:
> Can you try the obvious patch here (surrounding INCOMING_RETURN_ADDR_RTX
> with an ifdef)?
That would be wrong. INCOMING_RETURN_ADDR_RTX is *required*
when defining DWARF2_UNWIND_INFO.
But DWARF2_UNWIND_INFO shouldn't be defined
On Mon, Jan 30, 2006 at 10:31:18AM -0800, H. J. Lu wrote:
> Does that mean DWARF2_UNWIND_INFO should be checked before using
> INCOMING_RETURN_ADDR_RTX instead of checking INCOMING_RETURN_ADDR_RTX?
Yes. But as-quoted, it already is.
r~
On Wed, Feb 01, 2006 at 12:42:35AM -0500, Daniel Berlin wrote:
> Would anyone object to me just telling bugzilla to reject comments >
> 100k in length?
Nope. Tell the user to use the attachment feature.
> (i've chosen 100k to keep arguments about what the "right" length is. I
> believe *everyon
On Thu, Feb 16, 2006 at 03:40:57PM -0400, Aldy Hernandez wrote:
> + htab_t GTY ((param_is (union tree_node))) used_types_hash;
Should be "tree" not the union. You're storing a pointer,
not the union itself.
> +used_types_insert (tree t, struct function *cfun)
Call it something other than cfun
On Wed, Feb 22, 2006 at 10:06:25AM -0700, Jeffrey A Law wrote:
> > > This does highlight one of the issues that keeps nagging at me.
> > > For an enumeration type, presumably we have TYPE_PRECISION set to
> > > the minimum precision necessary to hold all the values in the enum.
> > > What are TYPE_
On Tue, Mar 07, 2006 at 12:34:05PM -0500, Diego Novillo wrote:
> Richard mentioned similar problems with broken libc versions that
> wouldn't initialize TLS properly, but this particular one doesn't seem
> related. Richard, any ideas?
Huh. No, this one doesn't look like the failure I had before.
601 - 700 of 812 matches
Mail list logo
