> The machine is very strange in modern terms. It doesn't have registers, it
> executes code in reverse Polish, the integer data type is a degenerate form
> of the floating point data type, pointers are magic, there are no page
> tables, and the word size isn't a power of 2, just to start. Oh, an
> I found arm.md and the moveqi insns, but because of the different
> addressing modes of strb and swpb, its not easy to make the change.
> And there must be a compiler option for this, too.
>
> Could somebody please tell me how to implement this change?
Short answer is probably not.
There are a
> > There are a couple of complications that spring to mind. The different
> > addressing modes and the fact that swp clobbers a register are the most
> > immediate ones.
> >
> > You'll need to modify at least the movqi insn patterns, memory
> > constraints and the legitimate address stuff. I'm not
> > (define_insn "*arm_movqi_insn"
> > [(set (match_operand:QI 0 "nonimmediate_operand" "=r,r,r,Q")
> > (match_operand:QI 1 "general_operand" "rI,K,m,+r"))]
> Changing "m" to "Q", narrowing the address modes
> Changing "r" to "+r", (register is globbered)
This is wrong. the "+" applies to th
> The call from Linux-land to eabi-land would not need
> to pass arguments nor return anything and nothing
> would need to be shared between the two pieces of
> code.
So basically you can replace the whole thing with sleep(1); and noone would be
any the wiser.
Paul
> __builtin_frame_address(n) is not required to work for any value other
> than n=0. It's not clear what it means anyway on a function that
> eliminates the frame pointer.
>
> On ARM you *cannot* walk the stack frames without additional
> information. Frames are private to each function and there
On Friday 02 June 2006 16:44, Richard Earnshaw wrote:
> On Fri, 2006-06-02 at 16:35, Daniel Jacobowitz wrote:
> > On Fri, Jun 02, 2006 at 04:32:07PM +0100, Richard Earnshaw wrote:
> > > On Fri, 2006-06-02 at 16:28, Paul Brook wrote:
> > > > I agree that in general
On Sunday 04 June 2006 11:31, Wolfgang Mües wrote:
> Hello Rask,
>
> On Friday 02 June 2006 09:24, Rask Ingemann Lambertsen wrote:
> > There may be a faster way of seeing if the modification is going to
> > work for the DS at all. I noticed from the output template
> > "swp%?b\\t%1, %1, [%M0]" that
On Sunday 04 June 2006 16:26, Wolfgang Mües wrote:
> Paul,
>
> On Sunday 04 June 2006 13:24, Paul Brook wrote:
> > On Sunday 04 June 2006 11:31, Wolfgang Mües wrote:
> > > Splitting the insn
> > >
> > > (define_insn "*arm_movqi_insn"
> > &g
> > Tightening the predicates isn't sufficient (and may not even be
> > neccessary). You need to set the constraints so that the compiler
> > knows *how* to fix invalid instructions.
>
> And if I have 4 different constraints in a single insn, and only one of
> them is needing a temporary register,
> > I still don't see how gcc maintainers would know to make this
> > distinction. Perhaps I'm misunderstanding the distinction between
> > command and display.
>
> for (i=0; i<4; i++)
> {
> C[i] = A[i] + C[i+3];
> }
>
> Auto vectorizer emits three messages.
> 1) This loop is not vectorized beca
> One imagines that one would construct a virtual machine architecture
> framework
gcc already has one. It's called RTL.
> and then write a back-end that would generate "machine code" for
> that virtual machine, which would be a subset of ANSI C. Hey-presto, you
> then have a butt-ugly anythin
> > (1b) If the configure-time prefix does not exist, but is under an NFS
> > mount, the compiler will cause automount traffic, NFS timeouts, etc.
>...
> > However, I think it's clear that the problems in (1) are more severe
> > than the problems in (2), on several grounds:
>
> I actually think the
On Sunday 23 July 2006 19:40, Andrew Pinski wrote:
> > Before Vista, there's no solution short of "cp". However, you still
> > have the --sysroot command-line option. And, if you're worried about
> > Windows, see Paul's response; the problems I've described are
> > particularly bad on Windows, an
On Tuesday 22 August 2006 20:14, Mike Stump wrote:
> I hate to even bring this up, but... should things like:
>
>int m[1 << 27] = {0};
>
> be put in .bss? I'm tempted to say no, if you want that, you have to
> remove {0}.
What makes you say this?
Given that C requires global variables with
On Wednesday 06 September 2006 23:00, Michael Eager wrote:
> GCC passes a linker script to the linker for some
> targets (e.g., powerpc-eabi with -mads). If you specify a
> linker script using -Wl,-T,script.ld, you get both
> passed to the linker and there may be conflicts.
>
> Is there any option
On Tuesday 19 September 2006 06:49, Chandan_Gupta-r65863 wrote:
> Hi
>
> I am doing the assembly coding in ARM7TDMI and using the GNU Assembler.
> In GNU ARM Assembler Quick Reference, I found 2 register Names which I
> am not able to understand, they are ip & fp.
ip is r12 and fp r11.
Paul
On Thursday 21 September 2006 05:51, Mark Mitchell wrote:
> Paul --
>
> In addition to the Thumb-2 bits, I assume you plan to merge the other
> ARM changes on the branch? Is that correct? (For example, what about
> the NEON bits?)
Good point. I've updated the page to include NEON.
I don't think
On Friday 22 September 2006 16:56, Dave Korn wrote:
> On 22 September 2006 16:01, Ian Lance Taylor wrote:
> > [EMAIL PROTECTED] (Jack Howarth) writes:
> >> Looking at the libffi/src/powerpc/ffi.c file, I assume that I should
> >> have the same...
> >>
> >>*next_arg++ = (unsigned long)(char
On Tuesday 26 September 2006 20:09, Dave Korn wrote:
> On 26 September 2006 20:01, max blomme wrote:
> > I'm attempting to port GCC to our companys 32bit microprocessor, and I'm
> > a bit overwhelmed.
> >
> > Looking through some of the documentation (there's quite a lot of it!) I
> > can't seem to
On Wednesday 27 September 2006 21:37, Daniel Berlin wrote:
> I see occasional complaints about the size of mainline merges to
> branches Most people working on branches are only modifying a very
> small subset of the files that are in mainline, and certainly not the
> entire trunk tree.
I'm kinda
> Why? Perhaps I am entirely wrong but can't you just don't update (svn
> up) those directories that are switched until mainline is in an usable
> state?
That's only feasible if you're the only person working on that branch, and you
only ever use one checkout on one machine.
I guess you could us
On Saturday 07 October 2006 03:09, Kaveh R. GHAZI wrote:
> Has there been any thought to including GMP/MPFR in the GCC repository
> like we do for zlib and intl?
>
> Doing so would guarantee users could build fortran and also help me
> with PR middle-end/29335 (an enhancement).
> http://gcc.gnu.org
On Saturday 26 February 2005 17:54, Sam Lauber wrote:
> > > (2) -> Some of us would like DO .1 <- #0
> > >
> > > to be translated into movl $0, v1
>
> v1 is the name of a variable. Needed because the manual
> says that each variable namespace (meshes, spots, tails,
> what-have-yous, hybrids) has 6
> @defmac HARD_REGNO_NREGS (@var{regno}, @var{mode})
> A C expression for the number of consecutive hard registers, starting
> at register number @var{regno}, required to hold a value of mode
> [EMAIL PROTECTED]
> [EMAIL PROTECTED] This macro must never return zero, even if a register
> +cannot
> Yes, I can remember that constraints in a mov-insn can not be
> resolved by other/additional mov-insns.
I think you're doing this the wrong way. You don't have a i->m mov
instruction, so why are you pretending you do?
Why aren't you doing this the same way as pretty much every other target?
On Tuesday 15 January 2008, Balaji V. Iyer wrote:
> Hello Everyone,
> I am currently working on dividing the register file into two
> different processing element. In the first processing element (PE) I
> want to have certain operations (add, sub, mult, div, branch,
> jumps..etc) in first PE
> Well if they do require more than one instruction, the rule has
> no effect ("whenever possible"). If they can be done in one
> instruction (as on the x86), then why not require this, why
> make a special case?
We don't even guarantee consistent behavior for volatile bitfields, so I
really dou
> AFAIK the only reason we don't break this rule is that doing so would
> be grossly inefficient; there's nothing to stop any gcc back-end with
> (say) seriously slow DImode writes from using two SImode writes instead.
I'm fairly sure ARM already breaks this "rule".
Currently it probably only eff
> Since we are talking 100s of tests, it seems like it would be
> easiest to avoid them in the scripts. I just don't know how
> to do that.
You might want to look at how the ARM NEON vector unit is handled
(check_effective_target_arm_neon_ok and check_effective_target_arm_neon_hw).
Paul
On Wednesday 12 March 2008, Joel Sherrill wrote:
> Paul Brook wrote:
> >> Since we are talking 100s of tests, it seems like it would be
> >> easiest to avoid them in the scripts. I just don't know how
> >> to do that.
> >
> > You might want to
On Friday 14 March 2008, Joseph S. Myers wrote:
> On Thu, 13 Mar 2008, Joel Sherrill wrote:
> > > Also, if you use a multilib option in testing, that option goes on the
> > > command line *after* the options specified in dg-options. The tests
> > > may need to use dg-skip-if to skip them if any CP
This list is for development of gcc, not gcc users. In future gcc-help, or
some other arm specific list is the correct place to ask such questions.
> As far as I can tell, there is no way to declare
> that a particular function pointer will point at
> plain ARM code or at Thumb code. I'm more
> t
On Sunday 23 March 2008, Albert Cahalan wrote:
> On Sat, Mar 22, 2008 at 8:24 PM, Paul Brook <[EMAIL PROTECTED]> wrote:
> > This list is for development of gcc, not gcc users. In future gcc-help,
> > or some other arm specific list is the correct place to ask such
> >
> How to tell gcc to insert high, low, and combine operations, when 32
> and 64 bit operations are exchanging values?
CANNOT_CHANGE_MODE_CLASS
Paul
> That only covers call-preserved registers. Testing call-clobbered
> registers is harder (but normally unwind information won't be generated
> for them, so they matter less); for iWMMXt I tried testing using
> -fcall-saved-wr0 -fcall-saved-wr1 ... but found that
> CONDITIONAL_REGISTER_USAGE overr
> Would it be complicated to implement e.g. __builtin_bswap32 on armv6
> with inline semantics (I mean, without generating a library call)?
Probably not.
Paul
> I am running into a problem when I am trying to compile GCC to run on
> a i686-pc-linux-gnu (host) but to build source code for target,
> x86_64-pc-linux-gnu. I have build binutils first with the following
> configure parameters:
> --enable-plugin --with-cpu=generic --host=x86_64-pc-linux-gnu
> Are there any targets with register interlock where
> gcc handles moving instructions between conflicting
> instructions?
>
> Any suggestions on how this might be represented
> in .md files? It doesn't seem that the pipeline
> description would seem appropriate.
This is approximately what ia64
On Saturday 17 May 2008, Mohamed Shafi wrote:
> Hello all,
>
> Recently i noticed that register allocation for the operands in a
> unspec pattern was going wrong.
> This was because there was no conflict between the registers used in
> the unspec pattern and the other registers which should have be
On Tuesday 20 May 2008, Andrew Pinski wrote:
> On Tue, May 20, 2008 at 2:30 PM, Omar Torres <[EMAIL PROTECTED]> wrote:
> > By looking at other ports, I learned that I can detect when this happens
> > by using the reg_overlap_mentioned_p(). Here is one case:
> > (insn 43 115 74 (set (reg:HI 7 %i0h)
I'm looking for help with an if-convert problem.
I have a local arm based target, but with most of the conditional execution
patterns disabled. Before the first if-conversion pass we have the following
RTL:
(set (reg2) (const_int 0))
(set (CC) (compare (reg1) (const_int 0)))
(jump if (CC) (labe
On Saturday 24 May 2008, Doug Kwan (關振德) wrote:
> I saw that MI thunks are always issued in ARM mode. Is there a
> specific reason?
Recent gcc is capable of generating pure Thumb thunks (and always does so for
Thumb-2).
> I think I can replace a
> 20-byte ARM MI thunk with a 4 bytes THUMB equiv
> As far as I know, toolchain is built in this order:
>
> 1. binutils
> 2. C compiler
> 3. libc
No.
That usually only works if you already have the toolchain installed. In which
case ordering is irelevant, you can just build whichever component you want
to update.
A full bootstrap process look
On Friday 27 June 2008, Julian Brown wrote:
> On Fri, 27 Jun 2008 15:52:22 +0530
>
> "Mohamed Shafi" <[EMAIL PROTECTED]> wrote:
> > If the condition in the 'if' instruction is satisfied the processor
> > will execute the next instruction or it will replace with a nop. So
> > this means that i can i
> We are using the MontaVista release of gcc. We had a 30 days license from
> MontaVista for their DevRocket development platform.
>
> We had a big surprise when the license expired. Gcc stopped working from
> the command line and displayed a message stating the license time expired.
>
> I had a
> arm-rtems4.9-gcc -mfpu=neon -mfloat-abi=softfp -mcpu=arm7tdmi -c
> test_neon.c
>
> #if !defined(__ARM_NEON__)
> #error "Neon not supported"
> #endif
>
> void neon_code(void)
> {
> asm volatile ("vldr d18,[fp,#-32]");
> }
Works fine here. Either your assembler is busted, or there is something
On Wednesday 06 August 2008, Joseph S. Myers wrote:
> On Wed, 6 Aug 2008, Joel Sherrill wrote:
> > $ arm-rtems4.9-gcc -mfpu=neon -mfloat-abi=softfp -mcpu=arm7tdmi -c
> > test_neon.c /tmp/ccBzigjD.s: Assembler messages:
> > /tmp/ccBzigjD.s:13: Error: selected processor does not support `vldr
> > d1
> We chose arm-elf as the starting point years. If we need to
> move to arm-eabi as the starting point that is OK. We usually
> just chose the CPU-coff or CPU-elf as a starting point
> for CPU-rtems.
I highly recommend switching to the EABI.
If you want to support recent (Thumb-2) CPUs I'd expe
> > m68k does too, just nobody uses it any more or the ones they use don't
> > have the co-processor or have a different FP instructions now. In
> > fact this where the problem started, i387 just continued in the same
> > fashion.
>
> Huh? m68k still uses extended precisions and will continue to d
> > > result = __macf(operand1, operand2, operand3);
> > >
> > > }
> > >
> > > Requirement : I need the value of operand3 and result to be same
> > > after calling the builtin.
> > > But this is not happening.
> >
> > What do you mean, exactly? C only has call by value, and gcc's
> > bui
On Friday 11 May 2007, Dave Korn wrote:
> On 11 May 2007 19:27, Paul Brook wrote:
> >>> > result = __macf(operand1, operand2, operand3);
> >> After the builtin i want to have the following operations also to
> >> carried out operand3 = result ;
> >
&
> But for the following example
> int a = 1;
> int b = 2;
> int c = 3;
> c = c + a * b;
> the MAC pattern is not getting recognized, instead it is still using
> PLUS and MULT patterns.
Your example is bogus. This is optimized to "c = 5" well before we get to RTL.
Paul
> Bootstrapping GCC on a system is something that would be solved by
> placing GMP and MPFR in the build tree (as has been proposed), and once
> they are built as part of the usual bootstrap, it is irrelevant whether
> they are linked statically or dynamically. On the other hand, when one
> is dis
On Friday 25 May 2007, Thomas Koenig wrote:
> What about a keyword for bugs that
>
> - generate wrong code
> - affect a standard-conforming program
> - are silent (no error message)
We already have one: "wrong-code"
1 and 3 mutually exclusive. ie. if we generate an error, then by definition we
d
On Tuesday 05 June 2007, Ying Yi wrote:
> Hi gcc group,
>
> I added vector compare and mov insns in gcc for our architecture
> (cross_gcc), but when I
> use these insns in c, I have to use builtin functions instead of
> generic vector compare.
>...
> Could someone tell me how to do vector compare i
On Tuesday 03 July 2007, Andreas Schwab wrote:
> "Richmond Tuttle" <[EMAIL PROTECTED]> writes:
> > Is there a command option (for GCC, G++, and/or GAS) that will force
> > .rodata (like jump tables) to be located in the .data section?
>
> You can use a linker script to override the default placemen
The arm backend has support for both gas assembly and the syntax used by
proprietary arm assemblers (controlled by AOF_ASSEMBLER).
I'm told that the only recent users of this feature were the riscos folks, and
that they no longer care.
The only target that uses this code in the FSF tree is arm-
On Friday 03 August 2007, Jonathan S. Shapiro wrote:
> On Fri, 2007-08-03 at 12:46 -0400, Daniel Jacobowitz wrote:
> > On Fri, Aug 03, 2007 at 05:24:28PM +0100, Dave Korn wrote:
> > > I'm a bit surprised too. But it occurs to me that the ARM, unlike
> > > the i386 and m68k, is bi-endian. Perhap
> > Shouldn't it also work by changing the (char *) cast to (unsigned char
> > *), since IIUIC the standard guarantees you're allowed to access any
> > object as an array of unsigned char and not get into aliasing
> > difficulties?
>
> The standard makes the same guarantee about (char *). This i
On Thursday 09 August 2007, Alex Gonzalez wrote:
> Hi,
>
> I'll try to come up with a short test.
>
> I have narrowed it a bit more. The PVAR structure contains a long long
> variable ( with a sizeof 8 and an alignof 8 for my architecture). If I
> take out the long long variable, the compiler uses
> There seem to be solid reasons to permit this, and no very strong ones
> to prohibit it. We can consider it to be a GNU extension for vectors.
> Vectors are of course themselves an extension already.
How are you suggesting it be implemented?
Will the front/middle-end convert it to (vNsf)((vNsi
On Friday 24 August 2007, Ian Lance Taylor wrote:
> Paolo Bonzini <[EMAIL PROTECTED]> writes:
> > 1) neg, abs and copysign operations on vectors. These we can make
> > available via builtins (for - of course you don't need it); we already
> > support them in many back-ends.
>
> Here is my point of
> > I'm partly worried about cross-platform compatibility, and what this
> > imples for other SIMD targets.
>
> Yes. Here's a proposed definition:
I agree this is the only sane definition.
I probably wasn't clear: My main concern is that if we do support this
extension the internals should be
> > That said, second, my understanding of restrict, from reading the c99
> > standard, is that it is perfectly valid for restrict pointers to alias
> > each other during *loads*.. IE you can guarantee any restricted
> > pointer that is stored into can't alias the other restricted pointers.
> > T
> In any case, I guess we should consider my patch withdrawn. Although,
> if the new meaning of "restrict" matches standard Fortran semantics,
> then our Fortran handling must be wrong, since all my patch did was make
> us match our current Fortran semantics.
In Fortran the pointers are not expos
On Monday 22 October 2007, Robert Dewar wrote:
> Erik Trulsson wrote:
> > It is also worth noting that just declaring a variable 'volatile' does
> > not help all that much in making it safer to use in a threded environment
> > if you have multiple CPUs. (There is nothing that says that a multi-CPU
On Sunday 04 November 2007, Mark Mitchell wrote:
> Kenneth Zadeck wrote:
> > To fix this will require a round of copy propagation, most likely in
> > concert with some induction variable detection, since the most
> > profitable place for this will be in loops.
>
> For code size, it will be profitab
On Friday 16 November 2007, Dave Korn wrote:
> On 16 November 2007 05:56, Li Wang wrote:
> > As you said, the coprocessor has no ABI to describe a stack and a
> > function interface, then inline applies. But how could I inline 'main'?
> > And I am sorry for I misuse the word 'elf assembly', what ex
> 7. Add support for loading x86-32 and x86-64 objects in the same
> address space, using a single modified 64-bit libc.
I'm not convinvinced this is practical, or even possible. I'd expect the
restrictions imposed on code to make it work properly to be too onerous for
it to be of any real use.
> > > > Thanks for the quick response!
> > > > I'm sure it seems I like to make hard wok for myself! It gets worse,
> > > > I'm porting Gentoo Linux to iWMMXt with pure EABI kernel and
> > > > userspace. I'm not concerned about being able to run old binaries.
> > > > So is using abi=iwmmxt really
> So I'm asking for a policy here that says when it is OK to resolve old
> bug without progress as WONTFIX or SUSPENDED. Start shooting.
I think this would be a big mistake to reuse an existing state for this.
If/when someone does start caring about that particular feature it'll be
impossible fo
On Wednesday 19 December 2007, Joe Buck wrote:
> On Wed, Dec 19, 2007 at 01:11:11AM +0000, Paul Brook wrote:
> > > So I'm asking for a policy here that says when it is OK to resolve old
> > > bug without progress as WONTFIX or SUSPENDED. Start shooting.
> >
> &g
> My untested (and consequently firmly
> held) hypothesis is that
>
> 1) most combinations of && and || don't need parentheses because
>
> (a && b) || (c && d)
>
> is by far more common than
>
> a && (b || c) && d
>
> and, moreover, broken code fails at runtime, and
I dispute these cla
201 - 274 of 274 matches
Mail list logo
