> I'm trying to understand what you mean, but your comments are rather
> obscure. Which file do you think I should change? Just tell me where to
> look and I'll do it.
glibc/ports/sysdeps/unix/sysv/linux/arm/eabi/sigrestorer.S Currently has:
.fnstart
.save {r0-r15}
.pad #
> On 10/27/2011 02:15 AM, Paul Brook wrote:
> >>>> So, suggestions welcome. Is there a nice way to detect a signal
> >>>> frame?
> >
> > That just makes me ask why are you're trying to detect a signal frame in
> > the first place?
>
>
> >> So, suggestions welcome. Is there a nice way to detect a signal frame?
That just makes me ask why are you're trying to detect a signal frame in the
first place?
> > Libunwind also reads the IP to detect signal frames on ARM Linux:
> > http://git.savannah.gnu.org/gitweb/?p=libunwind.git;a=b
> Hi,
>
> I was having a look to this long standing, and unconfirmed, PR:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36778
>
> and the rationale makes sense to me. What do you think, shall we have
> -Wfatal-warnings too, together with -Wfatal-errors?
>
> AFAICS, the patch would be rat
> 2) Is there any reason we shouldn't prevent GCSE from propagating
> constants that we know will be split?
IIUC this will increase register pressure. i.e. it will probably be a win for
simple loops, but risks catastrophic spills in the inner loop of more
complicated code.
Paul
> What about liveness? No hard reg, pseudo, mem will live avross the
> unspec volatile. Right?
Wrong. A volatile unspec may use/change machine state not directly accessible
by gcc. Any use of or changes to the machine state modelled by gcc should be
explicit in the pattern.
i.e. if your patter
> Hi All,
>
> Is it possible to define UNITS_PER_SIMD_WORD as a global variable and
> to set this varibale using a pragma (even once for a compilation) and
> that way to be able to compile one file with UNITS_PER_SIMD_WORD = 8
> and another file with UNITS_PER_SIMD_WORD = 16?
No. This is an inter
> > Does the Go language define a specific ABI convention for returning
> > two values from a function thru registers? If yes, how does GCC
> > implement it? Or is it some future work?
>
> The Go language does not define an ABI for returning multiple values.
> The gccgo frontend implements it by s
> [quote]
> Target Hook: int TARGET_SCHED_ISSUE_RATE (void)
> [snip]
> Although the insn scheduler can define itself the possibility of issue
> an insn on the same cycle, the value can serve as an additional
> constraint to issue insns on the same simulated processor cycle
> [snip]
> [/quote]
>
>
> > 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 hoping to document that it *is* a h
> I would like to reduce this to
>
> STACK_BOUNDARY
>
> -- minimum alignment enforced by hardware.
>...
> -- unchanged
This may be determined by factors other than hardware. For example the ARM
EABI requires that the stack be 8-byte aligned at public entry points. However
within a functio
> A while back I posted a question about adding edit-and-continue
> abilities. Since then I've begun work on a rapid development compiler
> (rdc) which has these abilities, but I've had some thoughts I'd like to
> share, and receive some feedback from the GCC experts:
>
> What if a subset of GCC
> > In fact we might want to move switch optimization up to the tree level
> > (just because it's way easier to deal with there). Thus, lower switch
> > to a mixture of binary tree & jump-tables (possibly using perfect
> > hashing).
>
> Doing the optimisation at the tree-level was exactly my init
> Hi,
> I wish to selectively enable specific optimizations to observe its effect
> on the source. My project requires me to do this analysis. It seemed, the
> -f* flags would enable me to do that. But it turns out that individual
> optimizations can't be enabled like that, and all the optimization
> > PR45112. See also http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00283.html
>
> Thanks a lot for info.
> If I got the discussion right, it's ok for the definition to use more
> strict alignment than the declaration.
Not quite. Any mismatch is user error, and may cause nasal daemons.
Whether thi
> I have run into variable alignment issues, which turned out to be
> caused by forward declaration w/o the aligned attribute repeated.
> Could someone explain this please? If it's a bug to not include the
> aligned attribute in the forward declaration, would it be hard to add
> a warning for that
> Ian Lance Taylor writes:
> > Unfortunately, as far as I know, no such solution was ever adopted for
> > the x86 family. So this does not help your immediate problem, and will
> > not help it until somebody implements such an approach for x86.
>
> The Sun assembler, linker, and runtime linker i
> However, although no one currently sells FPA hardware, it is widely
> supported as the only floating point model emulated by the Linux
> kernel, and people have to use it when compiling stuff to run on OABI
> systems, which include boards currently on the market based on ARMv4
> (no t) such as th
> > It really does seem like a hack to use triplets in this way; I think
> > Paul's point that anything that depends on the toolchain triplet to
> > determine ABI is inherently busted is pretty persuasive.
>
> Which means the whole GNU way of doing this has always been busted,
> since that's essen
> .../configure --prefix=...
>
> must build a native compiler that conforms to the native ABI of the
> machine.
By my reading at least ppc, mips and sparc allow the default ABI to be changed
via --with-float, but none of them have a separate target triplet for this
purpose.
> > It's wort
> Both Linaro and Debian are considering supporting the ARM hard-float
> variant of the EABI, at least as an unofficial port. This ABI is not
> compatible with the gnueabi currently in use for most ARM Linux distros,
> but has a number of performance advantages.
>
> This means that we need to choo
> So my next question is what support is there in the various formats,
> technologies and runtime libraries to provide a backwards compatible
> solution, such that a binary from one system when put on another can
> have any hardware incompatibilities detected at the soonest opportunity,
> for examp
> > > Is there a way to get GCC to only use the FPU when we explicitly want
> > > to use it (i.e. when we use doubles/floats)? Is -msoft-float my only
> > > option here? Is there any sort of #pragma that could do the same
> > > thing as -msoft-float (I didn't see one)?
> >
> > To absolutely
On Thursday 07 January 2010, Richard Earnshaw wrote:
> On Wed, 2010-01-06 at 18:26 +0000, Paul Brook wrote:
> > On Wednesday 06 January 2010, Carrot Wei wrote:
> > > So thumb2 can also use the instructions similar to thumb1, right? It
> > > potentially has better perfor
On Wednesday 06 January 2010, Carrot Wei wrote:
> So thumb2 can also use the instructions similar to thumb1, right? It
> potentially has better performance and smaller code size.
Technically yes, however in ARMv7 the relevant instruction (add.n , pc)
is deprecated.
Paul
> > > Or use the more modern iterators approach.
> >
> > Aren't iterators for generating multiple insns (e.g. movsi and movdi)
> > from the same pattern, whereas in this case we have a single insn that
> > needs to accept many different operand combinartions?
>
> Yes, but that is often better, I
> > > I am doing a port in GCC 4.4.0 for a 32 bit target. As a part of
> > > scheduling framework i have to write the move patterns with more
> > > clarity, so that i could control the scheduling with the help of
> > > attributes. Re-writting the pattern resulted in movsi pattern with 41
> > > alte
On Monday 21 December 2009, Mohamed Shafi wrote:
> Hi all,
>
> I am doing a port in GCC 4.4.0 for a 32 bit target. As a part of
> scheduling framework i have to write the move patterns with more
> clarity, so that i could control the scheduling with the help of
> attributes. Re-writting the patter
> Here is a problem that '#' is a symbol used in my chip assembler as
> prefix before immediate. Like: MOV R0 #0x123.
> ...
> Is there any solution to solve this?
Make your assembler accept # as as a comment stat only if it appears at the
start of a line. There are several other targets (e.g. A
> Nothing you've said changes the fact that there are a class of users
> for whom that information is vital and we ought to spend some time
> thinking about how to provide the information in a form they can
> digest. GCC dumps as they exist today are largely useless for a non-GCC
> developer to u
> > Almost certainly not. As far as I'm concerned arm-elf is obsolete, and in
> > maintenance only mode. You should be using arm-eabi.
>
> I'm possibly (probably?) wrong, but as far as I know, it forces alignment
> of 64-bit datum (namely, doubles and long longs) to 8 byte boundaries,
> which does
> Since this will be arm-rtems multilib's when submitted,
> which variants and matches need to be added so we have
> the right libraries for all CPU model arguments. ld is
> complaining at least about libc.a mismatches for these variations.
>
> does not use Maverick instructions, whereas a.out
> I am happy to construct all of this on a Unix system with the various
> tools (m4 etc) available.
>
> But from the Unix system, I need to be able to generate the
> above very simple compile script, which is a precursor to creating
> very simple JCL steps (trust me, you don't want to see what
> S
> Do we want to enable more multilibs in arm-elf?
Almost certainly not. As far as I'm concerned arm-elf is obsolete, and in
maintenance only mode. You should be using arm-eabi.
IMHO building lots of multilibs by default significantly increases toolchain
size and build time for little actual ben
> > Both. By my reading the ABI you're trying to implement does not provide
> > the guarantees required to use iwmmxt instructions. There are ways around
> > this, but none of them are simple or pretty. The simplest answer is
> > "don't do that".
>
> Hi Paul,
>
> Thanks for the answer, but I'm not
> So, question time again : could this be in my port, or a more
> fundamental issue as Dave hints ?
Both. By my reading the ABI you're trying to implement does not provide the
guarantees required to use iwmmxt instructions. There are ways around this,
but none of them are simple or pretty. The s
On Wednesday 06 May 2009, DJ Delorie wrote:
> Is there an opaque vector type? Something that can be assigned
> to/from other vector types of the same size, without warning?
>
> I'm working on a coprocessor which has separate SIMD arithmetic
> operations for each data size, but only one SIMD logica
On Tuesday 10 March 2009, DJ Delorie wrote:
> One of our customers has a chip with memory-mapped peripheral
> registers that need to be accessed in a specific mode. The registers
> represent bitfields within the hardware, so a volatile struct is an
> obvious choice to represent them in C.
>
> Comm
On Friday 27 February 2009, Dave Korn wrote:
> Julian Brown wrote:
> > Unfortunately backtraces don't currently terminate cleanly if code
> > without unwind data is reached: CodeSourcery are currently working on
> > fixing the linker so that non-unwindable regions are marked properly,
> > which we
> >> As I understand it, the ARM kernel can now do something similar. So,
> >> the only use for a __builtin_return_address(N) that used the frame
> >> pointer chain would be if the code were compiled with nonstandard
> >> options.
> >
> > Correct.
>
> Well, but wouldn't it still be nice if __bui
On Wednesday 25 February 2009, Andrew Haley wrote:
> Uwe Kleine-König wrote:
> > currently[1] __builtin_return_address for ARM only works with level == 0.
> >
> > For ftrace in the linux kernel it would be great to implement that for
> > level > 0 (provided that framepointers or unwind information
On Friday 06 February 2009, Ian Lance Taylor wrote:
> Jean Christophe Beyler writes:
> > All of these have an outer code of SET. Therefore, I'm not quite
> > positive of how I'm supposed to implement my rtx_cost function. Since
> > I don't seem to get a choice between a set 0xcb03 and a (plus 0xca
> > On Thumb-2 we found that the overhead of a function call was often
> > smaller than the cost of lengthening branches in the caller.
> > It turns out that, over a fair selection of applications, programmers
> > tend to write "nice" sized functions. After inlining we have big nasty
> > blocks of
> For -Os it should be enough to set PARAM_STACK_FRAME_GROWTH
> to zero. Inlining at -Os should already only happen if it decreases
> (overall!) code-size. Thus, inlining a function that is called once and
> that does not need to be emitted will always be an overall code-size
> win.
>
> > A side
On Tuesday 30 December 2008, Balaji V. Iyer wrote:
> I forgot to mention one important part..I am using GCC 4.0.2
The first thing you should to is update to current gcc (preferably svn trunk).
4.0.2 is really old and hasn't been maintained for quite some time. There's
a good chance things have
On Monday 08 December 2008, Alexandre Pereira Nunes wrote:
> A patch follows. I didn't take care of the scheduling case the correct
> way, tought (aliased to clz class).
Please read http://gcc.gnu.org/contribute.html
In particular you need a copyright assignment, ChangeLog entry, and testing.
Yo
On Tuesday 18 November 2008, DJ Delorie wrote:
> > I think a more relevant question is whether it's ok to pass 0, {NULL} for
> > argc, argv.
>
> You can do that on desktop linux, you know:
>
> execl(some_prog_name, NULL);
>
> argv[0] is NOT guaranteed to be non-NULL:
>
> ISO/IEC 9899:1999(E)
> What are the expectations here? Do we expect simulators to set up
> argv[0]? (the m32c BSP acts like you're on real hardware) Do we expect
> simulators to blithely ignore NULL pointer references?
I think a more relevant question is whether it's ok to pass 0, {NULL} for
argc, argv. If yes then
> When the offsets stored in the instructions are used, they refer to
> offsets from the address of the instruction (IA) plus 8 bytes. Are the
> pool_ranges also calculated from IA+8, from the address of the
> instruction itself or even from the address of the following
> instruction (IA+4)?
>
> In
> The real heart of the matter though is that most of the people that
> contribute to gcc aren't themselves users of these targets, and so it's
> only natural that they don't know about or care about the status of any
> target-specific issues. What has worried me lately however is how much
> ELF-s
> > the code you provided tries to allocate a huge chunk of memory on the
> > stack.
> Interesting. At least. There should be a warning from gcc.
The limit is nothing to do with GCC. It is an OS setting (ulimit -s).
Paul
On Thursday 13 November 2008, Michael Meissner wrote:
> On Thu, Nov 13, 2008 at 09:14:06PM +0100, Paul Chavent wrote:
> > Hi.
> >
> > I wonder why there aren't any endianess attributes ?
> >
> > For example we could write this :
> > int x __attribute__ ((endianess (lil))) = 0;
> >
> > Is it a silly
> >> Would you be willing to consider supporting the PE object formats on the
> >> ARM based port of ReactOS?
> >
> > I'd really rather not. You should be using an EABI based target and a
> > postlinker, like SymbianOS does.
> >
> > See
> > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.do
On Thursday 09 October 2008, Farlie A wrote:
> Hi,
>
> Would you be willing to consider supporting the PE object formats on the
> ARM based port of ReactOS?
I'd really rather not. You should be using an EABI based target and a
postlinker, like SymbianOS does.
See
http://infocenter.arm.com/help/
> 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
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
> 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
> 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
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
> 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 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
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 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)
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
> 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
> 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
> 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
> 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
> 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
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
> >
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 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
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
> 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
> 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
> 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
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
> 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?
> @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
> 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
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
> 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
> > > > 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
> 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.
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
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 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
> 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
> > 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
> > 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
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
> 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 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
> > 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 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
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 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
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 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
> 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
1 - 100 of 274 matches
Mail list logo
