Re: GCC 4.1.2 RC1

st case work with older versions of GCC? > > (2) Richard Earnshaw objected to applying the patch to 4.1 because it > requires a newer GAS. Paul's counter that the newer GAS is only needed > if your compiler would otherwise crash seems persuasive to me, if true, > but I'd cer

Re: arm-elf-gcc shared flat support

On Fri, 2007-03-30 at 17:57 +0530, vivek tyagi wrote: > Hi , > This is the wrong list for these sorts of questions, you should really be asking on gcc-help. > I am working on Shared flat file support for uClinux (No MMU ARM ).The > gcc version > I am using is 2.95 and 3.4.0.Theory of operation i

Re: Re : Problem with gcc 3.4.0 & 3.4.6 in ARM thumb mode regarding stack buffer allocation

On Thu, 2007-04-12 at 08:59 +, Mick CORNUT wrote: > Hi Andrew, > Ps: I've just tried with gcc 4.1.1, but the problem doesn't occur > since gcc removes the temporary buffer allocation on the stack, > furthermore, we want to keep gcc 3.4.x! Changing the testcase to void trace(int p1, int p2,

Re: Toolchain for Maverick Crunch FPU

On Thu, 2007-04-12 at 14:16 +0300, Kai Ruottu wrote: > Things seem to be that the '-mcpu=ep9312 -mhard-float' combination will > crash the GCC build in both gcc-4.1.2 and gcc-4.2.0-20070316 prerelease > like : -mhard-float doesn't do what you think it does... I think you should be using:

Re: anyone using svk?

On Thu, 2007-04-12 at 14:12 +0100, Rafael Espindola wrote: > Is anyone using svk? I tried to create a local depot by updating the > one pointed on the wiki. Unfortunately it is trying to use too much > ram and crashing. > > I crashes just after stating to work on revision 121126. There are a numb

Re: arm,gcc and dsp instructions

On Fri, 2007-04-20 at 10:24 +0200, Victor Librado wrote: > Hello all, > I`m working with an arm core 9260EJ-S under Linux (Linux kernel 2.6.15; > armv5l-linux toolchain with compiler gnu gcc 3.4.2). I would like to > take advantage of the asm DSP like functions the core provides. I > compile th

Re: GCC mini-summit - compiling for a particular architecture

On Sun, 2007-04-22 at 17:32 -0700, Mark Mitchell wrote: > Steve Ellcey wrote: > >> It came up in a few side conversations. As I understand it, RMS has > >> decreed that the -On optimizations shall be architecture independent. > >> That said, there are "generic" optimizations which really only appl

Re: GCC -On optimization passes: flag and doc issues

On Fri, 2007-04-27 at 22:51 +0200, Joerg Wunsch wrote: > As Steven Bosscher wrote: > > > >The idea behind that tool is great, I only wish the authors had > > >taken a class in portable shell scripting before. It's not that > > >all the world's a Vax these days... > > > Patches welcome, I guess.

Re: GCC -On optimization passes: flag and doc issues

On Tue, 2007-05-01 at 09:07 +0200, Joerg Wunsch wrote: > As Richard Earnshaw wrote: > > > There's no need to hack everything up. As long as you have bash > > installed on your machine, it's straight-forward to run CSiBE on > > *BSD machines: simply invoke

Re: GCC -On optimization passes: flag and doc issues

On Tue, 2007-05-01 at 12:43 +0200, Joerg Wunsch wrote: > As Richard Earnshaw wrote: > > > > That's what I did, but it doesn't help for the non-standard usage > > > of /usr/bin/time (-f option). They even explicitly used > > > /usr/bin/time rather than b

Re: GCC 4.1 Projects

On Mon, 2005-02-28 at 00:05, Zdenek Dvorak wrote: > at the beginning of the stage 1, there always is lot of major changes > queued up. It never lead to unmanageable amount of "breakage and > disruption". Then you clearly haven't tried to maintain a port other than x86-* or *-linux. The fact is

Re: [arm] possible bug in G++ 3.4.x

On Mon, 2005-02-28 at 12:51, Vladimir Ivanov wrote: > Hello all, > > While compiling this: > http://sourceforge.net/projects/raytracer/ > > I think I've spotted a bug in ARM port of G++. > > The problem is that many method functions tend to save all callee-saved FP > registers, while they

Re: [arm] possible bug in G++ 3.4.x

On Tue, 2005-03-01 at 10:54, Vladimir Ivanov wrote: > Hello, > > [Richard]: > Does this mean that GCC-3.4.x won't be fixed? > Most certainly it won't be. 3.4 is in regression-fix only mode and this is not a regression. R.

Re: [arm] possible bug in G++ 3.4.x

On Tue, 2005-03-01 at 15:29, Petko Manolov wrote: > On Tue, 1 Mar 2005, Paul Brook wrote: > > > The "old" arm-none-elf and arm-linux targets still use SJLJ exceptions. They > > will probably never be "fixed" as this would involve an ABI change. > > Didn't understand that. How is all non scratch

Re: Merging calls to `abort'

On Mon, 2005-03-14 at 03:00, Richard Stallman wrote: > This is a difficult choice to make, but at > -O2, I'd prefer that we optimize, and suggest other debugging techniques > intead of relying on the line numbers of abort calls. > > The sole purpose of optimization is to satisfy us

Re: Merging calls to `abort'

On Tue, 2005-03-15 at 09:59, Clifford Wolf wrote: > Hi, > > On Sun, Mar 13, 2005 at 03:01:00PM +0200, Kai Henningsen wrote: > > Most of the rest of the error handling in this project is concerned with > > the absence of the feature I loved in the IBM PL/I compilers under the > > name "SNAP;" -

Re: gcc and vfp instructions

On Tue, 2005-03-22 at 08:51, aram bharathi wrote: > hi, >i like to know whether gcc can generate vfp instructions.. > > main() > { > float a=88.88,b=99.99,c=0; > c=a+b; > printf("%f",c); > } > > i used the following option to compile the above program > > arm-elf-gcc -mfp=2 -S new.c > > but

Re: gcc and vfp instructions

On Fri, 2005-04-01 at 18:09, aram bharathi wrote: > hi > > i have downloaded the gcc4.0 from the gcc web site > and i compiled the above program by the following option > > main() > { > float a=88.88,b=99.99,c=0; > c=a*b; > printf("%f",c); > } > > arm-elf-gcc -mfpu=vfp -S new.c > > but it produ

Re: Obsoleting c4x last minute for 4.0

On Wed, 2005-04-06 at 00:30, Mark Mitchell wrote: > Joe Buck wrote: > > > > But if it won't even build, then users should be warned. > > I suppose -- but we have relatively many configurations that probably > won't build, at least if you start combining various options, and > including langaug

Re: apply_result_size vs FUNCTION_VALUE_REGNO_P

On Thu, 2005-04-07 at 14:49, Eric Botcazou wrote: > Hi Eric, > > The __builtin_apply/__builtin_return mechanism is broken on SPARC in 4.x > because of > > 2004-03-17 Eric Christopher <[EMAIL PROTECTED]> > > * builtins.c (apply_args_size): Use reg_raw_mode. > (apply_result_size): D

Re: apply_result_size vs FUNCTION_VALUE_REGNO_P

On Thu, 2005-04-07 at 15:51, David Edelsohn wrote: > >>>>> Richard Earnshaw writes: > > >> I think the change breaks __builtin_apply/__builtin_return on every > >> platform > >> that can return values in several contiguous registers, because the

Re: apply_result_size vs FUNCTION_VALUE_REGNO_P

On Thu, 2005-04-07 at 19:45, Eric Christopher wrote: > On Thu, 2005-04-07 at 16:48 +0200, Eric Botcazou wrote: > > > That was my thoughts too. You could take a look at how I fixed it on > > > ARM. > > > > Thanks. So basically you bypass the apply_result_mode array entirely, > > which > > is st

Re: Processor-specific code

On Thu, 2005-04-14 at 18:35, Richard Henderson wrote: > On Thu, Apr 14, 2005 at 05:27:16PM +0200, François-Xavier Coudert wrote: > > No, since reading GFORTRAN_FPU_* variables changes the FPU mode when the > > library is loaded, while TR 15580 commands will be ran afterwards (during > > execution

Re: Processor-specific code

On Fri, 2005-04-15 at 15:50, Robert Dewar wrote: > Richard Earnshaw wrote: > > > Not all environments can change the rounding mode dynamically. For > > example, on the FPA co-processor for ARM, rounding is set by the > > instruction selected -- so the concept of having

RE: Processor-specific code

On Fri, 2005-04-15 at 17:49, Dave Korn wrote: > Original Message > >From: Richard Earnshaw > >Sent: 15 April 2005 17:42 > > > On Fri, 2005-04-15 at 15:50, Robert Dewar wrote: > >> Richard Earnshaw wrote: > >> > >>> Not all envir

Re: GCC 4.0 RC2 Available

On Wed, 2005-04-20 at 01:18, Josh Conner wrote: > On Apr 18, 2005, at 3:12 PM, Julian Brown wrote: > > > Results for arm-none-elf, cross-compiled from i686-pc-linux-gnu > > (Debian) > > for C and C++ are here: > > > > http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01301.html > > > > Relative to

RE: Store scheduling with DFA scheduler

On Tue, 2005-04-26 at 12:52, Jon Beniston wrote: > > Jon, > > > (define_insn_reservation "arith" 1 (eq_attr "type" "arith") "x") > > > (define_insn_reservation "loads" 2 (eq_attr "type" "load") "x,m") > > > (define_insn_reservation "stores" 3 (eq_attr "type" > > "store") "x,m*2") > > > > Stores

Re: GCC 4.1: Buildable on GHz machines only?

On Wed, 2005-04-27 at 16:31, David Edelsohn wrote: > The GCC build times are not unreasonable compared to other, > commercial compilers with similar functionality. And the GCC developers > ave plans to address inefficiencies -- GCC 4.0 often is faster than GCC > 3.4. If you are going to ma

Re: GCC 4.1: Buildable on GHz machines only?

On Wed, 2005-04-27 at 17:19, David Edelsohn wrote: > >>>>> Richard Earnshaw writes: > > Richard> On Wed, 2005-04-27 at 16:31, David Edelsohn wrote: > >> The GCC build times are not unreasonable compared to other, > >> commercial compilers with s

Re: GCC 4.1: Buildable on GHz machines only?

On Wed, 2005-04-27 at 17:29, Richard Earnshaw wrote: > On Wed, 2005-04-27 at 17:19, David Edelsohn wrote: > > >>>>> Richard Earnshaw writes: > > > > Richard> On Wed, 2005-04-27 at 16:31, David Edelsohn wrote: > > >> The GCC build times are no

Re: GCC 4.1: Buildable on GHz machines only?

On Wed, 2005-04-27 at 20:57, Steven Bosscher wrote: > On Wednesday 27 April 2005 17:45, Matt Thomas wrote: > > > The features under discussion are new, they didn't exist before. > > > > And because they never existed before, their cost for older platforms > > may not have been correctly assessed. >

Re: GCC 4.1: Buildable on GHz machines only?

On Wed, 2005-04-27 at 21:55, Andrew Pinski wrote: > > However, I can always tell when a GCC build has hit the libjava build > > -- that's when the *whole system* suddenly slows to a crawl. Maybe > > it comes from doing some processing on 5000 foo.o files all at > > once... :-( > > But that is not

Re: GCC 4.1: Buildable on GHz machines only?

On Thu, 2005-04-28 at 02:40, Tom Tromey wrote: > > "Paul" == Paul Koning <[EMAIL PROTECTED]> writes: > > Paul> Maybe. Then again, maybe there are real problems here. The ranlib > Paul> one was already mentioned. And I wonder if libjava really needs to > Paul> bring the host to its knees, as

Re: GCC 4.1: Buildable on GHz machines only?

On Thu, 2005-04-28 at 14:35, Andrew Haley wrote: > Richard Earnshaw writes: > > On Wed, 2005-04-27 at 21:55, Andrew Pinski wrote: > > > > However, I can always tell when a GCC build has hit the libjava build > > > > -- that's when the *whole system* suddenl

Re: GCC 4.1: Buildable on GHz machines only?

On Sat, 2005-05-07 at 13:58, Andi Kleen wrote: > Tom Tromey <[EMAIL PROTECTED]> writes: > > > > Splitting up libgcj.so probably makes sense even for the Linux distro > > case (the one I am most concerned with at the moment), just so that > > apps that don't use AWT or Swing don't really pay for it.

Re: How can I write an empty conversion instruction

On Sat, 2005-05-07 at 04:14, Richard Henderson wrote: > On Fri, May 06, 2005 at 01:59:06PM -0700, Steve Ellcey wrote: > > I was wondering if anyone could tell me how to write an (empty) > > instruction pattern that does a truncate/extend conversion on a register > > 'in place'. > > > > All the con

Re: How can I write an empty conversion instruction

On Mon, 2005-05-09 at 17:11, Richard Henderson wrote: > On Mon, May 09, 2005 at 12:40:48PM +0100, Richard Earnshaw wrote: > > > The best way is to have a post-reload splitter that splits the insn > > > into nothing at all. > > > > Is that really valid? I woul

Re: emit_conditional_move w/o compare insn (was: Full comparison in 'cbranchsi4' leads to error in gcc 4.0)

On Tue, 2005-05-10 at 17:32, Sami Khawam wrote: > Hi Gary, > > Thanks a lot for the tip. > > After debugging, the problem seem to be coming from 'emit_conditional_move' > which is called by 'expand_sdiv_pow2' when converting division-by-constants > into > shifting. > The problem is that the arc

Re: GCC 4.1: Buildable on GHz machines only?

On Mon, 2005-05-16 at 13:19, Robert Dewar wrote: > > > > Also don't forget us embedded people that are *desperately* trying to > > do native compilations using an NFSroot with limited main memory and > > don't have a disk in the hardware design to swap to. > > Why would you work in such a crippl

Re: GCC 4.1: Buildable on GHz machines only?

On Mon, 2005-05-16 at 13:44, Robert Dewar wrote: > Richard Earnshaw wrote: > > > Robert, please stop trying to shoot the messenger. The problems are > > real, and users often cannot 'fix' these problems themselves. Just like > > they can't 'fix

Re: GCC 4.1: Buildable on GHz machines only?

On Mon, 2005-05-16 at 16:17, Steven Bosscher wrote: > On Monday 16 May 2005 16:53, Scott Robert Ladd wrote: > > The problem is, a bloated GCC has no consequences for the majority of > > GCC developers -- their employers have other (and valid) concerns. It's > > less a matter of laziness than it is

Re: GCC 4.1: Buildable on GHz machines only?

On Mon, 2005-05-16 at 17:03, Daniel Berlin wrote: > > if only it were that simple[1]. However, even if the money does get > > spent it's unlikely to help because there are too many developers that > > just DON'T CARE about (or worse, seem to be openly hostile to) making > > the compiler more effi

Re: GCC 4.1: Buildable on GHz machines only?

On Tue, 2005-05-17 at 01:59, Steven Bosscher wrote: > No, I just don't build gfortran as a cross. There are many reasons > why this is a bad idea anyway. Such as?

Re: GCC 4.1: Buildable on GHz machines only?

On Tue, 2005-05-17 at 11:16, Steven Bosscher wrote: > On May 17, 2005 11:29 AM, Richard Earnshaw <[EMAIL PROTECTED]> wrote: > > > On Tue, 2005-05-17 at 01:59, Steven Bosscher wrote: > > > > > No, I just don't build gfortran as a cross. There are many reaso

Re: GCC 4.1: Buildable on GHz machines only?

On Tue, 2005-05-17 at 21:03, Paul Brook wrote: [building of gfortran] > It does require gmp/mpfr on the host, but in most cases the host is native, > and they are dead easy to cross compile anyway. And it's long been my contention that we shouldn't even be doing that. I still feel these packag

Re: GCC 4.1: Buildable on GHz machines only?

On Tue, 2005-05-17 at 23:33, Joseph S. Myers wrote: > It's a de facto standard: don't modify your Subject header from that > test_summary generates; there are plenty of examples on gcc-testresults of > what the headers should look like. You can rewrite the shell script > output by test_summary

Re: [rfc] mainline slush

On Mon, 2005-05-23 at 16:19, Eric Christopher wrote: > > > http://gcc.gnu.org/wiki/GCC%204.1%20Slush > > > > Just to let folks know that mips-elf fails to build newlib. > > There's a segfault in is_gimple_reg_type(), which is being > > passed a null type. I'm not sure if I'll have time to look

Re: [rfc] mainline slush

On Mon, 2005-05-23 at 17:20, Jeffrey A Law wrote: > On Mon, 2005-05-23 at 16:34 +0100, Richard Earnshaw wrote: > > On Mon, 2005-05-23 at 16:19, Eric Christopher wrote: > > > > > http://gcc.gnu.org/wiki/GCC%204.1%20Slush > > > > > > > > Just to le

Re: [rfc] mainline slush

On Mon, 2005-05-23 at 17:36, Jeffrey A Law wrote: > On Mon, 2005-05-23 at 17:25 +0100, Richard Earnshaw wrote: > > However, in the mean-time I'm stuck. I can't build my world anymore, so > > I can't test the compiler > I understand. But realize that I

Re: ARM and __attribute__ long_call error

On Tue, 2005-06-07 at 16:08, Jani Monoses wrote: > Hello > > trying to compile the following simple source file using arm-elf-gcc 4.0 > > void pig(void) __attribute__ ((long_call)); > void pig(void) > { > } > > yields: > > error: conflicting types for 'pig' > error: previous declaration of 'pig

Re: ARM and __attribute__ long_call error

On Wed, 2005-06-08 at 11:11, Jani Monoses wrote: > >>void pig(void) __attribute__ ((long_call)); > >>void pig(void) > >>{ > >>} > > > > Yes, that's the way it's currently coded. > > > > The problem, it seems to me, is that we want to fault: > > > > void pig(void) __attribute__ ((long_cal

Re: ARM and __attribute__ long_call error

On Wed, 2005-06-08 at 11:51, Jani Monoses wrote: > >>Is there anything tricky that prevents an easy implementation? > > > > Yes, internally the routine that's doing the comparison can't > > distinguish declarations from definitions. We need to diagnose > > Is the routine arm_comp_type_attributes

Re: No tail call optimization in Thumb mode?

On Fri, 2005-06-24 at 07:15, Kazu Hirata wrote: > Hi, > > Why is tail call optimization for Thumb disabled on GCC? I am > wondering if this is a TODO item or something that we cannot do > intrinsically. > > "The ARM-THUMB Procedure Call Standard" says "No tail continuation in > Thumb-state" seve

Re: Scheduler questions (related to PR17808)

On Wed, 2005-06-29 at 23:46, Steven Bosscher wrote: > Hi, > > I have a question about the scheduler. Forgive me if I'm totally > missing the point here, this scheduling business is not my thing ;-) > > Consider the following snippet that I've derived from PR17808 with a > few hacks in the compil

Re: Scheduler questions (related to PR17808)

On Thu, 2005-06-30 at 11:22, Steven Bosscher wrote: > For your problem, I think the jump should just be forced somehow to > be the last insn in the block. You can't move things into other > basic blocks if you are not doing interblock scheduling, after all. > For the PR I was looking at, someone w

Re: GCC-3.4.5 status report

On Wed, 2005-08-31 at 12:42, Gabriel Dos Reis wrote: > rtl-optimization: 20 > 17810 internal compiler error: in verify_local_live_at_start for > arm-rtems, arm-linux This is a dup of 15342. I'm just testing a back-port of the fix to the 3.4 branch. R.

Re: A couple more subversion notes

On Thu, 2005-10-20 at 09:58, Arnaud Charlet wrote: > I was talking about a svk set up (as suggested > by the author of the email I was responding to) with a local > mirror of the repository in this message. 8.5G is for the local mirror, > it is not (even) counting the check out which does take almo

Re: arm sof float

On Mon, 2005-11-14 at 16:52, Michael Trimarchi wrote: > Hi all, > I have this function defined twice. One in the libgcc2.c file and one in > gcc/config/arm/ieee754-df.S > __floatdisf > > I have problem during compilation of a arm soft float toolchain. Is > there any fix? > Regards Michael The b

Re: arm sof float

On Mon, 2005-11-14 at 17:17, Michael Trimarchi wrote: > Richard Earnshaw wrote: > > >On Mon, 2005-11-14 at 16:52, Michael Trimarchi wrote: > > > > > >>Hi all, > >>I have this function defined twice. One in the libgcc2.c file and one in > >>gcc

Re: Cirrus arm Maverick Crunch fixes

On Thu, 2005-11-17 at 10:23, Dario Massarin wrote: > I would like to start with this bug report: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24861 > > Could you give me some hints on where is the problem? It just happens that I fixed that last night :-) R.

Re: Link-time optimzation

On Thu, 2005-11-17 at 01:27, Mark Mitchell wrote: > Richard Henderson wrote: > > In Requirement 4, you say that the function F from input files a.o and > > b.o should still be named F in the output file. Why is this requirement > > more than simply having the debug information reflect that both na

Re: Link-time optimzation

On Fri, 2005-11-18 at 09:29, Bernd Schmidt wrote: > > Also, please keep in mind that generating and then assembling debug > > info takes a huge amount of I/O relative to code size. I'd expect much > > more than 1% saving the write-out and write-in on -g. > > So, maybe a simpler strategy could be

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

On Mon, 2005-11-21 at 21:46, Ian Lance Taylor wrote: > > In principle the combiner could make sure that the same number and > type of volatile memory references occur both before and after the > combination, and reject it if not. It would also have to ensure that the volatile memory operation wa

RE: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

On Tue, 2005-11-22 at 15:33, Dave Korn wrote: > Richard Earnshaw wrote: > > On Mon, 2005-11-21 at 21:46, Ian Lance Taylor wrote: > > > >> > >> In principle the combiner could make sure that the same number and > >> type of volatile memory

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

On Tue, 2005-11-22 at 19:10, Robert Dewar wrote: > Dave Korn wrote: > > Robert Dewar wrote: > > > > > Isn't it pretty much implied by point 1, "Not more than one volatile > > memory > > ref appears in the instructions being considered"? > > No, that allows a volatile reference to be combine

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

On Wed, 2005-11-23 at 11:41, Robert Dewar wrote: > Richard Earnshaw wrote: > > > This restriction rules out, for example, using a volatile value as an > > input in many floating point operations (since the operations may trap > > depending on the values read). > > I

Re: Creating a partial mirror of the repository with SVK

On Wed, 2005-11-23 at 21:13, Ludovic Brenta wrote: > I've read the wiki page that explains how to mirror GCC's repository > using SVK, and I would like to pick up just the parts I need so I can > keep the size of the mirror below 4 Gb due to limited disk space. > > Specifically, I need just a few

Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)

On Sun, 2005-11-27 at 03:14, Mike Stump wrote: > On Nov 22, 2005, at 7:52 AM, Richard Earnshaw wrote: > > 3) A volatile load isn't moved across any store that may alias (though > > I'd expect that to be volatile if there's a real risk of aliasning, so > > mayb

Re: Bootstrap comparison failure

On Sun, 2005-12-18 at 16:49, Daniel Jacobowitz wrote: > On Sun, Dec 18, 2005 at 01:28:48PM +0100, Mark Kettenis wrote: > > Looks like the new toplevel bootstrap infrastructure broke > > bootstrapping on OpenBSD. I get a bootstrap comparison which is > > caused by differences in the compilation dir

Re: Add revision number to gcc version?

On Fri, 2005-12-16 at 05:02, H. J. Lu wrote: > > In my patch, gcc/REVISION is created by gcc_update. If you don't use > gcc_update, gcc/REVISION may not be there. > > In any case, when we agree on what to put in gcc/REVISION, I can > provide a new patch. Maybe we should just set up the commit f

Re: Bootstrap comparison failure

On Mon, 2005-12-19 at 13:58, Daniel Jacobowitz wrote: > > I suspect that if you run a bootstrap of gcc on Linux with > > PWDCMD=/bin/pwd it will fail too. > > Yes, I saw a suggestion about this on IRC, but I tried it - it doesn't > fail. The path that matters is not one ever returned by PWDCMD bu

Re: Thumb optimization question

On Mon, 2005-12-26 at 21:41, Ivan Petrov wrote: > I have one question. So... have small sample programm. > > [code] > int bar( int ); > > int foo( int a, int b ) > { >return bar( a + b ); > } > [/code] > > If I compille it with out -thumb parameter, i have very clean code. > > add r0, r1

Re: Xscale big endian tool-chain (how to build it?)

On Sat, 2005-12-31 at 20:26, Karel Gardas wrote: > /home/karel/usr/local/arm-elf1/bin/../lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld: > > ERROR: > /home/karel/usr/local/arm-elf1/bin/../lib/gcc/arm-elf/4.0.1/be/libgcc.a(_dvmd_tls.o) > > uses hardware FP, whereas hello.xg2 uses software FP

Re: Xscale big endian tool-chain (how to build it?)

On Tue, 2006-01-03 at 15:38, Karel Gardas wrote: > OK, if I understand you well, then I should not use -msoft-float for both: > compiling of eCos lib and then for compiling my eCos-based app. The > problem is that this is not right way how to workaround this issue. I've > checked that I'm not u

Re: Xscale big endian tool-chain (how to build it?)

On Tue, 2006-01-03 at 15:52, Karel Gardas wrote: > On Tue, 3 Jan 2006, Richard Earnshaw wrote: > > > On Tue, 2006-01-03 at 15:38, Karel Gardas wrote: > > > >> OK, if I understand you well, then I should not use -msoft-float for both: > >> compiling of eCos lib

Re: Xscale big endian tool-chain (how to build it?)

On Tue, 2006-01-03 at 17:15, Karel Gardas wrote: > I have tried this with binutils 2.16.1 and gcc 4.0.1, but w/o success. The > failure happen during compilation of gcc and it looks like: > > /tmp/arm-elf-build/obj-gcc/gcc/xgcc -B/tmp/arm-elf-build/obj-gcc/gcc/ > -nostdinc -B/tmp/arm-elf-build/

Re: git conversion in progress

On 14/01/2020 11:01, Georg-Johann Lay wrote: > Am 11.01.20 um 02:18 schrieb Joseph Myers: >> I encourage people to continue to work on improving the documentation for >> using git with GCC >> ( and >>

Re: Git question: Rebasing a user branch

On 04/02/2020 23:26, Bill Schmidt wrote: > On 2/4/20 5:09 PM, Andreas Schwab wrote: >> On Feb 04 2020, Bill Schmidt wrote: >> >>> Hm.  If I'm understanding you correctly, this still attempts to create a >>> new branch: >>> >>> wschmidt@marlin:~/newgcc/gcc/config/rs6000$ git push --dry-run >>> users

Re: GCC 9.3 Status Report (2020-03-05)

On 05/03/2020 20:22, Jakub Jelinek wrote: Status == The GCC 9 branch is now frozen for blocking regressions and documentation fixes only, all changes to the branch require a RM approval now. Quality Data Priority # Change from last report ---

Re: List-Id header being stripped

On 09/03/2020 10:30, Florian Weimer wrote: * Richard Bradfield: It appears that since the migration (or whatever happened on the list over the weekend), the List-Id header is also being stripped from outbound mail. The last GCC mail I have where the header is intact was from Friday 6th. There

Re: Not usable email content encoding

On 16/03/2020 13:45, Martin Liška wrote: Hello. I noticed some emails reaching gcc-patc...@gcc.gnu.org use the following quoting: ``` case UNGT_EXPR: case UNGE_EXPR: case UNEQ_EXPR: +    case MEM_REF:    /* Binary operations evaluating both arguments (increment and  =0

Re: blacklisted after announce on GNU cauldron ?

On 23/04/2020 11:09, Olivier Hainque wrote: > Hello, > > Since April 14 or so, I am not receiving any more messages > from the gcc or gcc-patches mailing lists. > > This turns out to coincide with the date I sent to multiple > lists the message announcing the unfortunate cancellation of > the 202

Re: Automatically generated ChangeLog files - PHASE 1

On 12/05/2020 10:05, Martin Liška wrote: > Hi. > > Thanks to Jakub, we finally set up an experimental environment: > gcc.gnu.org/home/gccadmin/gcc-reposurgeon-8.git > > The repository now contains a new pre-commit hook that validates > the git commit format ([1]) and provides a reasonable error m

Re: ChangeLog files - server and client scripts

On 13/05/2020 12:05, Martin Liška wrote: > Hi. > > I'm sending the gcc-changelog relates scripts which should be added to > contrib > folder. The patch contains: > - git_check_commit.py - checking script that verifies git message format > - git_update_version.py - a replacement of > maintainer-scr

Re: [arm] GCC validation: preferred way of running the testsuite?

On 11/05/2020 17:43, Christophe Lyon via Gcc wrote: > Hi, > > > As you may know, I've been running validations of GCC trunk in many > configurations for Arm and Aarch64. > > > I was recently trying to make some cleanup in the new Bfloat16, MVE, CDE, and > ACLE tests because in several configura

Re: New mklog script

On 19/05/2020 15:51, Michael Matz wrote: > Hello, > > On Tue, 19 May 2020, Martin Liška wrote: > >>> The common problems I remember is that e.g. when changing a function comment >>> above some function, it is attributed to the previous function rather than >>> following, labels in function confus

Re: ChangeLog files - server and client scripts (git cherry-pick)

On 20/05/2020 10:27, Jakub Jelinek via Gcc wrote: > On Wed, May 20, 2020 at 11:19:49AM +0200, Thomas Koenig wrote: >> Hm, one question: I find the r11-1234 type commit to be much more >> readable, in ChangeLog files and everywhere else. >> >> Would it be possible to have that format instead of >> "

Re: ChangeLog files - server and client scripts

On 22/05/2020 05:57, Jakub Jelinek wrote: > On Thu, May 21, 2020 at 03:12:21PM -0700, Ian Lance Taylor via Gcc wrote: >> Hi, this unfortunately breaks gccgo development. Significant parts of >> the gccgo sources are simply copied from other repositories. Those >> other repositories do not use Cha

Re: New mklog script

On 25/05/2020 20:41, Jason Merrill via Gcc-patches wrote: > On Mon, May 25, 2020 at 5:23 AM Martin Liška wrote: >> >> On 5/22/20 11:01 PM, Jason Merrill wrote: >>> On Thu, May 21, 2020 at 6:03 PM Jason Merrill wrote: On Fri, May 15, 2020 at 11:39 AM Martin Liška wrote: > > On 5

Re: New mklog script

On 26/05/2020 12:14, Martin Liška wrote: > On 5/26/20 12:23 PM, Richard Earnshaw wrote: >> I thought we had a convention that aliases we added were prefixed with >> 'gcc-'?  This seems to go against that. > > You are right, but this one is so handy ;) > What nam

Re: [IMPORTANT] ChangeLog related changes

On 26/05/2020 12:19, Jakub Jelinek via Gcc wrote: > On Tue, May 26, 2020 at 12:42:41PM +0200, Thomas Koenig wrote: >> Am 26.05.20 um 11:04 schrieb Thomas Koenig via Gcc: >>> Am 26.05.20 um 00:48 schrieb Jakub Jelinek via Gcc: >>> I've turned the strict mode of Martin Liška's hook changes, >>>

Re: New mklog script

On 26/05/2020 14:09, Martin Liška wrote: > On 5/26/20 1:18 PM, Richard Earnshaw wrote: >> On 26/05/2020 12:14, Martin Liška wrote: >>> On 5/26/20 12:23 PM, Richard Earnshaw wrote: >>>> I thought we had a convention that aliases we added were prefixed with >>

Re: [arm] GCC validation: preferred way of running the testsuite?

On 26/05/2020 18:04, Christophe Lyon via Gcc wrote: > On Tue, 19 May 2020 at 13:28, Richard Earnshaw > wrote: >> >> On 11/05/2020 17:43, Christophe Lyon via Gcc wrote: >>> Hi, >>> >>> >>> As you may know, I've been running validations

Re: A problem with one instruction multiple latencies and pipelines

On 07/09/2020 07:08, Qian, Jianhua wrote: > Hi > > I'm adding a new machine model. I have a problem when writing the > "define_insn_reservation" for instruction scheduling. > How to write the "define_insn_reservation" for one instruction that there are > different latencies and pipelines accordi

Re: A problem with one instruction multiple latencies and pipelines

On 14/09/2020 03:53, Qian, Jianhua wrote: >> -Original Message- >> From: Richard Earnshaw >> Sent: Friday, September 11, 2020 9:30 PM >> To: Qian, Jianhua/钱 建华 ; gcc@gcc.gnu.org >> Subject: Re: A problem with one instruction multiple latencies and pipelines &

Re: duplicate arm test results?

On 23/09/2020 11:20, Jakub Jelinek via Gcc wrote: > On Wed, Sep 23, 2020 at 10:22:52AM +0100, Richard Sandiford wrote: >> So that would give: >> >> Results for 8.4.1 20200918 [r8-10517] on arm-none-linux-gnueabihf >> >> and hopefully free up some space at the end for the kind of thing >> you me

Re: Exploiting knowing sizes of string.

On 04/06/15 20:57, Jakub Jelinek wrote: > On Thu, Jun 04, 2015 at 06:36:33PM +0200, Ondřej Bílka wrote: >> On Thu, Jun 04, 2015 at 04:01:50PM +, Joseph Myers wrote: >>> On Thu, 4 Jun 2015, Richard Earnshaw wrote: >>> >>>>> Change that into >>

Re: Static Chain Register on iOS AArch64

On 05/06/15 16:55, Richard Henderson wrote: > On 06/04/2015 03:40 AM, Richard Earnshaw wrote: >> The static chain register is pretty much private to a translation unit... > > That was true when the static chain was restricted to trampolines. > Since Go has started using it for

Re: Static Chain Register on iOS AArch64

On 08/06/15 17:58, Richard Henderson wrote: > On 06/06/2015 06:24 AM, Richard Earnshaw wrote: >> That's going to make it impossible to implement Go closures on AArch32, >> then, since the only call-clobbered register not used for parameter >> passing is r12 (ip) an

Re: set_src_cost lying comment

On 24/06/15 17:47, Jeff Law wrote: > On 06/24/2015 03:18 AM, Alan Modra wrote: >> >> So in these examples we'd really like register moves to cost one >> insn. Hmm, at least, moves from hard regs ought to cost something. > The more I think about it, the more I think that's a reasonable step. > Noth

  1   2   3   4   5   6   >