RE: GCC 4.5.0 Status Report (2009-05-05)

On Wed, 2009-05-06 at 17:55 +0200, Michael Matz wrote: > Hi, > > On Wed, 6 May 2009, Richard Earnshaw wrote: > > > > The easiest solution would be to just make a note that you need the > > > PIC register and then, when expanding the prologue emit the necessary

Re: Setting ARM PIC register (Was: RE: GCC 4.5.0 Status Report (2009-05-05))

es sense as PIC register setup > >> usually is something the prologue does, like all the other register > >> setups necessary. > > Richard Earnshaw: > > That won't work because the PIC register on ARM is a pseudo, so > > generating it during prologue generati

Re: Setting ARM PIC register (Was: RE: GCC 4.5.0 Status Report (2009-05-05))

On Wed, 2009-05-06 at 18:29 +0200, Michael Matz wrote: > Hi, > > On Wed, 6 May 2009, Paolo Bonzini wrote: > > > Looks like something like this could be useful to avoid code > > duplications in the backends: > > > > void > > emit_insn_at_top (rtx insn) > > { > > rtx scan; > > > > gcc_assert

Re: ARM Neon Tests Failing on non-Neon Target

On Fri, 2010-04-30 at 15:26 +, Joseph S. Myers wrote: > On Fri, 30 Apr 2010, Joel Sherrill wrote: > > > > For EABI, this is done > > > with .cpu, .arch and .fpu directives; for non-EABI you may need to write > > > specs to pass command-line options to the assembler. Creating an > > > arm-r

Re: arm-elf float-abi defaults...

On Tue, 2010-05-11 at 17:40 -0400, DJ Delorie wrote: > > I discovered that if you build a plain arm-elf toolchain, the default > float-abis for gcc and gas don't match. I added this patch locally to > make it "just work" but it seems to me it would be better to have the > defaults match, although

Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

On Sun, 2010-05-23 at 05:11 +0100, Martin Guy wrote: > On 5/11/10, Mark Mitchell wrote: > > Richard Earnshaw wrote: > > > > > Speaking of which, we should probably formally deprecate the old arm-elf > > > derived targets in 4.6 so that we can remove them in 4.7

Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

On Sun, 2010-05-23 at 23:15 +0200, Steven Bosscher wrote: > On Sun, May 23, 2010 at 10:27 PM, Mark Mitchell wrote: > > Martin Guy wrote: > > > >> Dropping FPA support from GCC effectively makes the OABI unusable, and > >> often we are forced to use that by the environment supplied to us. Are > >>

Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

On Mon, 2010-05-24 at 12:42 +0200, Steven Bosscher wrote: > On 5/24/10, Richard Earnshaw wrote: > > > > On Sun, 2010-05-23 at 23:15 +0200, Steven Bosscher wrote: > >> On Sun, May 23, 2010 at 10:27 PM, Mark Mitchell > >> wrote: > >> > Martin Guy wr

Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

ly > a matter for the relevant maintainers, which in this case means target > maintainers together with OS maintainers (or target maintainers alone if > noone is maintaining the OS ports to ARM). > > On Mon, 24 May 2010, Richard Earnshaw wrote: > > > OABI should be on

Re: Deprecating ARM FPA support

On Mon, 2010-05-24 at 06:40 -0500, Joel Sherrill wrote: > The question we would like answered is what impact this > has on our code base. What changes will we have to > make to accomodate this? Register usage changes, stack > frame changes, etc. By far the biggest change is to the layout of 64-

Re: Using C++ in GCC is OK

On Mon, 2010-05-31 at 08:40 -0700, Mark Mitchell wrote: > Eric Botcazou wrote: > > >> We do require long long for 32->64 cross compilers. > > > > Right, only in this case, and I don't see why this should be changed with > > the > > transition to C++, that's orthogonal. > > I agree. We need i

Re: Using C++ in GCC is OK

On Mon, 2010-05-31 at 10:02 -0700, Mark Mitchell wrote: > I think virtual functions are on the edge; quite useful, but do result > in the compiler adding a pointer to data objects and in uninlinable > indirect calls at run-time. Therefore, I would avoid them in the > initial subset of C++ used in

Re: Using C++ in GCC is OK

On Mon, 2010-05-31 at 08:22 -0400, Robert Dewar wrote: > Gcc is very widespread at this point. Yes, there is the issue > of completely new targets, but these can be easily handled by > building cross-compilers. Provided that the object format for binaries is published and that we can therefore cre

Re: Using C++ in GCC is OK

On Wed, 2010-06-02 at 19:50 +0200, Jakub Jelinek wrote: > On Wed, Jun 02, 2010 at 06:17:25PM +0100, Richard Earnshaw wrote: > > > > On Mon, 2010-05-31 at 10:02 -0700, Mark Mitchell wrote: > > > I think virtual functions are on the edge; quite useful, but do result > &

Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

On Mon, 2010-06-28 at 01:37 +0100, Martin Guy wrote: > On 6/27/10, Gerald Pfeifer wrote: > > On Mon, 24 May 2010, Richard Kenner wrote: > > > I think that's a critical distinction. I can't see removing a port just > > > because it's not used much (or at all) because it might be valuable for >

Re: RFC: ARM Cortex-A8 and floating point performance

On Wed, 2010-06-16 at 08:09 -0700, Andrew Pinski wrote: > > Sent from my iPhone > > On Jun 16, 2010, at 6:04 AM, Richard Guenther > wrote: > > > On Wed, Jun 16, 2010 at 5:52 PM, Siarhei Siamashka > > wrote: > >> Hello, > >> > >> Currently gcc (at least version 4.5.0) does a very poor job >

Re: Triplet for ARM Linux HardFP ABI

On Mon, 2010-07-12 at 10:23 -0400, Joern Rennecke wrote: > Quoting Andrew Stubbs : > > > Hi All, > > Hi, long time no see... > > > So here are my suggestions: > > > > arm-linux-gnueabihf > >or maybe > > arm-linux-gnueabi-hf > > I don't like the inflation of dashes - it breaks scripts t

Re: Triplet for ARM Linux HardFP ABI

On Mon, 2010-07-12 at 16:03 +0100, Paul Brook wrote: > > 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 o

Re: Triplet for ARM Linux HardFP ABI

On Mon, 2010-07-12 at 09:19 -0700, Mark Mitchell wrote: > Richard Earnshaw wrote: > > > The reason why a new triplet is required is that config.guess needs to > > generate it when running native. Config.guess is the only way to > > communicate the information needed fo

Re: Question on ARM legitimate address for DImode

On Tue, 2010-12-21 at 12:12 +0800, Jie Zhang wrote: > Hi, > > While working on a bug, I found some code in ARM port that I don't > understand. > > In ARM_LEGITIMIZE_RELOAD_ADDRESS and arm_legitimize_address, we allow a > very small offset for DImode addressing. > > In ARM_LEGITIMIZE_RELOAD_AD

Re: [ARM] Implementing doloop pattern

On Thu, 2010-12-30 at 18:56 +0200, Revital1 Eres wrote: > Hello, > > The attached patch is my latest attempt to model doloop for arm. > I followed Chung-Lin Tang suggestion and used subs+jump similar to your > patch. > On crotex-A8 I see gain of 29% on autocor benchmark (telecom suite) with > SMS

Re: GCC 4.1.1/4.2.0 build failure with current binutils (iWMMXt)

On Sun, 2006-05-07 at 10:06, Steven Newbury wrote: > I have built an EABI/iWMMXt Gentoo based system. The toolchain I used is > modified to add a Linux/EABI/iWMMXt target. It has been fine until I changed > my binutils from an earlier snapshot to a current version Gentoo 2.16.92, > csl-2_17-branc

Re: CC0 questions

On Tue, 2006-05-09 at 22:16, Richard Kenner wrote: > Can there be two consecutive insns that use cc0 after cc0 is set? > > No. Yes. But only very very late in the compilation, once all normal re-ordering and optimization has been completed. I think it's probably final that folds out

Re: RFD: Integrate shorten_branches, machine-dependent constant pool placement and small-scale hot/cold partitioning

On Sun, 2006-05-14 at 17:09, Joern RENNECKE wrote: > The constant pool placement that sh_reorg does has somewhat hapazard > results. It does not take execution frequencies into account, so if > you are unlucky, you can end up with a constant table wedged into some > hoit spot of the code, which

Re: Problem about gcc 4.1 + binutil 2.16.92 + glibc 2.4 + ARM EABI

d in many cases will never go on the stack since they will live entirely in registers). Please direct any follow-ups to [EMAIL PROTECTED] This is off-topic for this list. R. -- Richard Earnshaw Email: [EMAIL PROTECTED] ARM Ltd Phone: +44 1223 400569 (D

Re: comparing DejaGNU results

On Thu, 2006-06-01 at 03:43, Mike Stump wrote: > Mine was designed to do two things, figure out if the results are > interesting and not send email, if they are not, and to show > engineers the `interesting' detailed results in priority order. It's > meant to be run daily, and on good days,

Re: Expansion of __builtin_frame_address

On Thu, 2006-06-01 at 16:05, Mark Shinwell wrote: > Mark Mitchell wrote: > > Mark Shinwell wrote: > >> As for the remaining problem, I suggest that we could: > >> > >> (i) always return the hard frame pointer, and disable FP elimination in > >> the current function; or > >> > >> (iii) ...the same a

Re: Expansion of __builtin_frame_address

On Fri, 2006-06-02 at 14:57, Mark Shinwell wrote: > Richard Earnshaw wrote: > > I'm not keen on this. On some machines a frame pointer is *very* > > expensive, both in terms of the code required to set it up, and the > > resulting loss of a register which affects cod

Re: Expansion of __builtin_frame_address

On Fri, 2006-06-02 at 15:30, Mark Shinwell wrote: > However when dealing with __builtin_frame_address, we must return the > correct value from this function no matter what the value of count. This > patch therefore forces use of a hard FP in such situations. Eh? The manual explicitly says that

Re: Expansion of __builtin_frame_address

On Fri, 2006-06-02 at 16:28, Paul Brook wrote: > I agree that in general you need ancillary information way to get a backtrace > on Arm. However if you assume only Arm code code and -fno-omit-frame-pointer > then you can walk the frames. Given this assumption I think it make sense to > have _b_f

Re: Expansion of __builtin_frame_address

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 you need ancillary information way to get a > > > backtrace &

Re: Expansion of __builtin_frame_address

On Fri, 2006-06-02 at 16:46, Mark Mitchell wrote: > Richard, I can't tell from your comments how you think _b_f_a(0) should > be implemented on ARM. We could use Mark's logic (forcing a hard frame > pointer), but stuff it into INITIAL_FRAME_ADDRESS_RTX. We could also > try to reimplement the thin

Re: Modifying ARM code generator for elimination of 8bit writes - need help

On Sun, 2006-06-04 at 22:01, Rask Ingemann Lambertsen wrote: > On Sun, Jun 04, 2006 at 12:24:53PM +0100, Paul Brook wrote: > > > For the record these hacks are unlikely to ever be acceptable in mainline > > gcc. > > They're relatively invasive changes who's only purpose is to support > > fundam

Re: Modifying ARM code generator for elimination of 8bit writes - need help

On Mon, 2006-06-05 at 12:47, Wolfgang Mües wrote: > > /* Output the address of an operand. */ > > #define ARM_PRINT_OPERAND_ADDRESS(STREAM, X)\ > > { \ > > int is_minus = GET_CODE (X) == MINUS;

Re: ARM gcc 4.1 optimization bug.

On Tue, 2006-06-06 at 15:05, Dirk Behme wrote: > Fengwei Yin wrote: > > Hi Daniel, > > I have already reported this bug. The bug number is #27363. > > I also tried the gcc snapshot 4.1.1-20060421. The bug is not > > fixed in this version too. > > > > On 5/1/06, Daniel Jacobowitz <[EMAIL PROTECTED]

Re: [RFC] Optimization Diary

On Wed, 2006-06-07 at 01:36, Geoffrey Keating wrote: > On 06/06/2006, at 5:25 PM, Andrew Pinski wrote: > > >> On 06/06/2006, at 5:20 PM, Andrew Pinski wrote: > >> > Right above, you said "We control the debug output machinery > generating this, and can simply tell it to only deal in one

Re: Modifying ARM code generator for elimination of 8bit writes - need help

On Wed, 2006-06-07 at 06:22, Wolfgang Mües wrote: > Rask, > > On Tuesday 06 June 2006 21:33, Rask Ingemann Lambertsen wrote: > > > > + swp%?b\\t%1, %1, %0\;ldr%?b\\t%1, %0" > > > > > > You should get a price for cleverness here! > > > > Thanks! Indeed it looks good until you think of volatile va

Re: The default -mpic-register for -mthumb

On Mon, 2006-06-26 at 17:48, Shaun Jackman wrote: > The default -mpic-register (on ARM/Thumb) is r10. In -mthumb mode, r10 > is not available to the math instructions as a direct argument. On top > of that, preserving r10 complicates the function prologue. Does it > make more sense to use a directl

Re: Which patch added R_ARM_GOTOFF32 support?

>Sorry, it was written quite a while ago. I don't know. > > > > Do you know who added this feature? What is you, or perhaps Nick > > Clifton or Richard Earnshaw? If I could find the person and the file > > that added this feature, I could probably track down the p

Re: [uClinux-dev] Re: XIP on an ARM processor (R_ARM_GOTOFF32)

On Wed, 2006-06-28 at 16:51, Shaun Jackman wrote: > On 6/27/06, David McCullough <[EMAIL PROTECTED]> wrote: > > AFAIK, you need to drop the -FPIC in favour of -fpic everywhere. > > >From the GCC manual, -fpic vs. -fPIC `makes a difference on the m68k, > PowerPC and SPARC.' For my purposes, it mak

Re: SP must be 8 byte aligned on entry to AAPCS-conforming functions

On Mon, 2006-07-03 at 02:10, Bridge Wu wrote: > Hello, > > When I built blob with arm-iwmmxt-linux-gnueabi toolchain, I found the > SP value before invoking number() in printf() may be 0 or 4 modulo 8. > If SP is 0 modulo 8, printf worked well, but while SP is 4 modulo 8, > printf failed. It canno

RE: Modifying ARM code generator for elimination of 8bit writes - need help

On Thu, 2006-07-20 at 12:04, Dave Korn wrote: > On 20 July 2006 07:03, Wolfgang Mües wrote: > > > Hello Rask, > > > > On Wednesday 19 July 2006 13:24, Rask Ingemann Lambertsen wrote: > >> I've spotted a function named emit_set_insn() in arm.c. It might be > >> the problem, because it uses gen_rtx

Re: Including GMP/MPFR in GCC repository?

On Tue, 2006-10-10 at 04:22, Mark Mitchell wrote: > Kaveh R. GHAZI wrote: > > Has there been any thought to including GMP/MPFR in the GCC repository > > like we do for zlib and intl? > > I do not think we should be including more such packages in the GCC > repository. It's complicated from an FS

Re: Details for svn test repository

On Thu, 2005-02-10 at 18:41, Joseph S. Myers wrote: > On Thu, 10 Feb 2005, Daniel Berlin wrote: > > > The only way to properly do this then is to just hack up the rcs files > > with the old-gcc data, where approriate, and increment all the other > > revision numbers. > > So does anyone wish to wr

Re: Using up double diskspace for working copies (Was Re: Details for svn test repository)

On Fri, 2005-02-11 at 16:35, Joern RENNECKE wrote: > Actually, having one copy of the entire repository might be cheaper than > having > several dozen double checkouts. But then, having no firm, easily memorized > revision numbers is certainly a much larger issue. I understand that > distribut

Re: Using up double diskspace for working copies (Was Re: Details for svn test repository)

On Fri, 2005-02-11 at 17:11, Joern RENNECKE wrote: > Moreover, I often want just a quick look at the source, and a checkout > has quite > a long latency for that. It ought to be less bad for SVN than CVS, particularly for older code, and branches. Though I agree it's not going to be zero. > An

Re: Details for svn test repository

On Sat, 2005-02-12 at 02:53, Daniel Berlin wrote: > On Fri, 2005-02-11 at 18:40 -0800, Mike Stump wrote: > > On Friday, February 11, 2005, at 05:29 PM, Daniel Berlin wrote: > > > I'll keep the last branchpoint of each branch for the initial import > > > > Won't work either... Sometimes we reuses

Re: Re, interworking problem

On Tue, 2005-02-22 at 10:09, aram bharathi wrote: > hi, > normally in thumb mode add instruction supports immediate > values in the range of 0-255( same source and destination register) > . i like to increase the range(for architecture analysis as > curriculam project). i have added this instr

Re: ARM/AAarch64: NEON intrinsics in the kernel

On 21/05/13 10:32, Ard Biesheuvel wrote: Hello all, I am currently exploring various ways of using NEON instructions in kernel mode. One of the ways of doing so is using NEON intrinsics, which we would like to support in the kernel, but unfortunately, at the moment we can't because the support h

Re: Porting libsanitizer to aarch64

On 22/05/13 21:19, Richard Henderson wrote: On 05/22/2013 12:43 AM, Jakub Jelinek wrote: Changing frame grows upward into frame grows downward shouldn't be that hard, see e.g. rs6000 port, where #define FRAME_GROWS_DOWNWARD (flag_stack_protect != 0 || flag_asan != 0) and grep the port where it u

Re: Porting libsanitizer to aarch64

On 23/05/13 17:36, Jakub Jelinek wrote: On Thu, May 23, 2013 at 05:28:29PM +0100, Richard Earnshaw wrote: FWIW, I would actually recommend against conditionalizing FRAME_GROWS_DOWNWARD for a new port. Just make it _always_ grow down and save yourself the additional code bloat in the backend

Re: powf(float,float) function from math.h on ARM32-bit platform

On 30/07/13 12:59, hemant wrote: I have written a std code for ARM 32-bit platform using math.h library and float=powf(float,float) function. When I give input to my system as 100 ^ 4.4 it gives me answer as 630957632. (as float) whereas calculator in WindowsXP gives answer as 630957344.480

Re: __ARM_ARCH_2__

On 08/08/13 08:20, zhaobin xv wrote: > Hi > > In linux/arch/arm/boot/ > compressed/head.S: > > > #ifndef __ARM_ARCH_2__ > /* > * Booting from Angel - need to enter SVC mode and disable > * FIQs/IRQs (numeric definitions from angel arm.h source). > * We only do

Re: ARM calling conventions generated in gcc with different optimizations

On 23/09/13 16:23, Vasily Golubev wrote: > Thank you a lot for your answer, Mr. Radhakrishnan! > > I think it was my mistake to use phrase "I will save LR at some > place"... I mean I can catch the first instruction of any function > precisely. And save LR value at that time to my local storage. A

Re: Getting the ARC port reviewed and accepted

On 02/10/13 14:59, Richard Biener wrote: > The main reason for technical review of a port is to avoid that it uses > deprecated mechanisms and thus blocks removal of them. Like > accepting a port that uses target macros when a corresponding > target hook exists, or accepting a port that uses reloa

Re: ARM: VFPv3-D16 vs. VFPv3-D32

On 17/10/13 08:56, Joey Ye wrote: > There is no macro to indicate VFP variances. Probably you can check > CPU variance instead. As I know Cortex-R only support D16. > Checking __ARM_ARCH_PROFILE == 'R' would tell you that it's R profile and therefore only 16 regs. R. > Joey > > On Thu, Oct 17,

Re: ARM: VFPv3-D16 vs. VFPv3-D32

On 17/10/13 13:46, Sebastian Huber wrote: > On 2013-10-17 14:24, Richard Earnshaw wrote: >> On 17/10/13 08:56, Joey Ye wrote: >>>> There is no macro to indicate VFP variances. Probably you can check >>>> CPU variance instead. As I know Cortex-R only support D16. &g

Re: Still fails with strict-volatile-bitfields

On 09/01/14 08:26, Bernd Edlinger wrote: > Hi, > > On Thu, 9 Jan 2014 15:01:54, Yoey Ye wrote: >> >> Sandra, Bernd, >> >> Can you take a look at >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59734 >> >> It seems a siimple case still doesn't work as expected. Did I miss anything? >> >> Thanks, >>

Re: Still fails with strict-volatile-bitfields

On 10/01/14 08:49, Bernd Edlinger wrote: > On Thu, 9 Jan 2014 16:22:33, Richard Earnshaw wrote: >> >> On 09/01/14 08:26, Bernd Edlinger wrote: >>> Hi, >>> >>> On Thu, 9 Jan 2014 15:01:54, Yoey Ye wrote: >>>> >>>> Sandra, Bernd,

Re: Still fails with strict-volatile-bitfields

On 10/01/14 13:45, Richard Biener wrote: > On Fri, Jan 10, 2014 at 2:30 PM, Bernd Edlinger > wrote: >> On, Fri, 10 Jan 2014 09:41:06, Richard Earnshaw wrote: >>> >>> On 10/01/14 08:49, Bernd Edlinger wrote: >>>> On Thu, 9 Jan 2014 16:22:33, Richard Ear

Re: ARM inline assembly usage in Linux kernel

On 19/02/14 23:19, Andrew Pinski wrote: > On Wed, Feb 19, 2014 at 3:17 PM, Renato Golin wrote: >> On 19 February 2014 11:58, Richard Sandiford >> wrote: >>> I agree that having an unrecognised asm shouldn't be a hard error until >>> assembly time though. Saleem, is the problem that this is being

Re: [GCC Steering Committee] Android sub-port reviewer

On 01/04/12 20:57, Maxim Kuvyrkov wrote: > On 29/03/2012, at 5:38 PM, Maxim Kuvyrkov wrote: > >> I volunteer as the reviewer for Android sub-port. >> >> Android/Bionic support is an extension over Linux port and is being >> gradually added for more and more architectures. I wrote the original >

Re: Fwd: Using movw/movt rather than minipools in ARM gcc

On 27/04/12 21:24, David Sehr wrote: > Hello All, > > We are using gcc trunk as of 4/27/12, and are attempting to add > support to the ARM gcc compiler for Native Client. > We are trying to get gcc -march=armv7-a to use movw/movt consistently > instead of minipools. The motivation is for > a new t

Re: No documentation of -fsched-pressure-algorithm

On 02/05/12 14:13, nick clifton wrote: > Hi Richard, > >> Well, given the replies from you, Ian and Vlad (when reviewing the patch), >> I feel once again in a minority of one here :-) but... I just don't >> think we should be advertising this sort of stuff to users. > > OK, what about Ian's sugge

Re: ARM GCC 4.8 test suite

On 20/06/12 15:27, Sebastian Huber wrote: > Hi, > > maybe it makes sense to look at some test suite comments since now all non > EABI > configurations have been removed (is this correct?). > No, not quite. All configurations using the FPA have been removed. That's not quite the same thing. N

Re: -fPIC -fPIE

On 13/11/12 14:56, Ian Lance Taylor wrote: Currently -fPIC -fPIE seems to be the same as -fPIE. Unfortunately, -fPIE -fPIC also seems to be the same as -fPIE. It seems to me that, as is usual with conflicting options, we should use the one that appears last on the command line. Do we have an e

Re: -fPIC -fPIE

On 21/11/12 22:47, Ian Lance Taylor wrote: On Wed, Nov 21, 2012 at 1:20 PM, Paolo Bonzini wrote: On Wed, Nov 21, 2012 at 8:02 PM, Ian Lance Taylor wrote: The main advantage is that you can compile a program with CFLAGS="-O2 -g -fPIE", and libtool's adding of -fPIC for shared libraries will wo

Re: RFC: [ARM] Disable peeling

On 07/12/12 15:13, Christophe Lyon wrote: Hi, As ARM supports unaligned vector accesses for almost no penalty, I'd like to disable loop peeling on ARM targets. I have ran benchmarks on cortex-A9 (hard-float) and noticed these significant improvements: * 1.5% improvement on a popular embedded be

Re: RFC: [ARM] Disable peeling

On 11/12/12 09:45, Richard Biener wrote: On Mon, Dec 10, 2012 at 10:07 PM, Andi Kleen wrote: Jan Hubicka writes: Note that I think Core has similar characteristics - at least for string operations it fares well with unalignes accesses. Nehalem and later has very fast unaligned vector load

Re: RFC: [ARM] Disable peeling

On 11/12/12 09:56, Richard Biener wrote: On Tue, Dec 11, 2012 at 10:48 AM, Richard Earnshaw wrote: On 11/12/12 09:45, Richard Biener wrote: On Mon, Dec 10, 2012 at 10:07 PM, Andi Kleen wrote: Jan Hubicka writes: Note that I think Core has similar characteristics - at least for string

Re: Deprecate i386 for GCC 4.8?

On 13/12/12 11:24, Steven Bosscher wrote: On Thu, Dec 13, 2012 at 11:43 AM, John Marino wrote: I don't speak for FreeBSD, but dropping them from Tier 1 support because they don't use a GPLv3 *BASE* compiler is a bit vindictive. FreeBSD has dropped GCC for future releases so there's no reason f

Re: Hoist across FP control register setting

On 06/02/13 08:38, Ye Joey wrote: Following case attempts to set floating point control register and execute floating point operation afterward. However, it doesn't works as expected with -Os, as GCC hoists multiply operation beyond FP control register setting. As there is no register dependence

Re: GCC 4.2.0 RC3 Available

> Mark Mitchell wrote: > > GCC 4.2.0 RC3 is now available from: > > > > ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501 > > > > This build now contains the fixes for the Ada build problem present in RC2. > > > > At this point, I have no plans for an RC4. However, I am reviewing the > > va

Re: Object attribute tagging

On Tue, 2007-06-19 at 01:50 +, Joseph S. Myers wrote: > The ARM EABI says that only standard entries under "aeabi" should affect > link-compatibility of object files, not vendor entries such as "gnu", but > in the absence of corresponding standards for other processors I don't > think we can

Re: RFC: Make dllimport/dllexport imply default visibility

On Mon, 2007-06-18 at 10:04 -0700, Mark Mitchell wrote: > > I suspect that the realview compiler accepts > > this as an oversight or a bug, not as an intentional feature. > > Let's ask. > > Richard E., is the fact that RealView 3.0SP1 accepts: > > class __declspec(notshared) S { > __declsp

Re: no_new_pseudos

g on here anymore. There are 199 uses of it in the backends; compared to 32 in the front end. So it is quite heavily used by MD code. R. -- Richard Earnshaw Email: [EMAIL PROTECTED] ARM Ltd Phone: +44 1223 400569 (Direct + VoiceMail) 110 Fulbourn Road

Re: no_new_pseudos

On Mon, 2007-07-09 at 09:30 -0700, Ian Lance Taylor wrote: > Paolo Bonzini <[EMAIL PROTECTED]> writes: > > > > I am going to argue that it was a bug that we did not allow new > > > pseudos after flow had ran. And that we should have always allowed > > > pseudos before the register allocator. Sin

Re: gcc-cvs mails for personal/vendor branches for merge commits

On 15/01/2020 16:30, Joseph Myers wrote: On Wed, 15 Jan 2020, Jason Merrill wrote: On 1/15/20 9:56 AM, Joseph Myers wrote: On Wed, 15 Jan 2020, Jakub Jelinek wrote: Or, if that is not possible, disable gcc-cvs mail for vendor and private branches altogether? I think this is desirable. gcc

Re: gcc-cvs mails for personal/vendor branches for merge commits

On 16/01/2020 14:11, Jakub Jelinek wrote: On Thu, Jan 16, 2020 at 12:40:02PM +0100, Joel Brobecker wrote: I think there's a similar issue not just for merges but for non-fast-forward pushes as well. As a glibc example, consider and the

[PATCH, v2] wwwdocs: e-mail subject lines for contributions

[updated, following some comments from Gerald, main differences are slight tweaks to the html markup and changing "email" to "e-mail"] This patch proposes some new (additional) rules for email subject lines when contributing to GCC. The goal is to make sure that, as far as possible, the subject

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

On 21/01/2020 15:04, Jakub Jelinek wrote: On Tue, Jan 21, 2020 at 02:52:00PM +, Richard Earnshaw (lists) wrote: [updated, following some comments from Gerald, main differences are slight tweaks to the html markup and changing "email" to "e-mail"] This patch proposes

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

On 21/01/2020 15:39, Jakub Jelinek wrote: On Tue, Jan 21, 2020 at 03:33:22PM +, Richard Earnshaw (lists) wrote: Some examples would be useful I'd say, e.g. it is unclear in what way you want the PR number to be appended, shall it be something: whatever words describe it PR12345 or some

Re: git: remote: *** The first line of a commit message should be a short description of the change, not a single word.

On 21/01/2020 16:14, Jonathan Wakely wrote: On Tue, 21 Jan 2020 at 16:03, Martin Liška wrote: Can you please remove the hook for user branches likes: $ git push origin me/filter-non-common Enumerating objects: 27, done. Counting objects: 100% (27/27), done. Delta compression using up to 16 th

Re: git: remote: *** The first line of a commit message should be a short description of the change, not a single word.

On 21/01/2020 16:43, Nathan Sidwell wrote: On 1/21/20 11:38 AM, Richard Earnshaw (lists) wrote: On 21/01/2020 16:14, Jonathan Wakely wrote: On Tue, 21 Jan 2020 at 16:03, Martin Liška wrote: Can you please remove the hook for user branches likes: $ git push origin me/filter-non-common

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

On 21/01/2020 17:20, Jason Merrill wrote: On 1/21/20 10:40 AM, Richard Earnshaw (lists) wrote: On 21/01/2020 15:39, Jakub Jelinek wrote: On Tue, Jan 21, 2020 at 03:33:22PM +, Richard Earnshaw (lists) wrote: Some examples would be useful I'd say, e.g. it is unclear in what way you

[PATCH] wwwdocs: document scripts to access personal and vendor spaces

This patch documents some of the scripts that I've published for managing the personal and vendor spaces on the server. It also covers some of the other features that those scripts enable, so that it's all in one place. This is a complete rewrite of the material I had written previously since

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

On 22/01/2020 09:07, Jakub Jelinek wrote: On Tue, Jan 21, 2020 at 06:50:13PM +, Richard Earnshaw (lists) wrote: Doesn't this use of [] have the same problem with git am? No, because only 'leading' [] blocks are removed - git mailinfo --help I've used openmp: Teach o

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

On 21/01/2020 19:26, Segher Boessenkool wrote: Hi! Thanks for doing this. On Tue, Jan 21, 2020 at 02:52:00PM +, Richard Earnshaw (lists) wrote: This patch proposes some new (additional) rules for email subject lines when contributing to GCC. The goal is to make sure that, as far as

Add News-feed item for git transition

We're missing a statement on the main news feed about the git transition. diff --git a/htdocs/index.html b/htdocs/index.html index 41bcfe18..ef85cc97 100644 --- a/htdocs/index.html +++ b/htdocs/index.html @@ -54,6 +54,10 @@ mission statement. News +GCC source repository converted to git. +

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

On 22/01/2020 16:28, Marek Polacek wrote: On Wed, Jan 22, 2020 at 04:05:37PM +, Richard Sandiford wrote: "Richard Earnshaw (lists)" writes: On 21/01/2020 17:20, Jason Merrill wrote: On 1/21/20 10:40 AM, Richard Earnshaw (lists) wrote: On 21/01/2020 15:39, Jakub Jelinek wrot

[PATCH, v3] wwwdocs: e-mail subject lines for contributions

[updated based on v2 discussions] This patch proposes some new (additional) rules for email subject lines when contributing to GCC. The goal is to make sure that, as far as possible, the subject for a patch will form a good summary when the message is committed to the repository if applied with

Re: Wrong GCC PR2020 annotated for "[committed, libgomp,amdgcn] Fix plugin-gcn.c bug"

On 23/01/2020 15:28, Jakub Jelinek wrote: On Thu, Jan 23, 2020 at 04:23:01PM +0100, Thomas Schwinge wrote: Hi! On 2020-01-23T12:46:24+, Andrew Stubbs wrote: I've committed this patch to fix a bug in the OpenMP argument parsing.

Re: [PATCH] wwwdocs: document scripts to access personal and vendor spaces

On 21/01/2020 18:58, Richard Earnshaw (lists) wrote: This patch documents some of the scripts that I've published for managing the personal and vendor spaces on the server.  It also covers some of the other features that those scripts enable, so that it's all in one place.  This is

Re: [PATCH] wwwdocs: document scripts to access personal and vendor spaces

On 24/01/2020 11:04, Jonathan Wakely wrote: On 23/01/20 16:23 +, Richard Earnshaw (lists) wrote: On 21/01/2020 18:58, Richard Earnshaw (lists) wrote: This patch documents some of the scripts that I've published for managing the personal and vendor spaces on the server.  It also c

Re: [PATCH] wwwdocs: document scripts to access personal and vendor spaces

On 24/01/2020 12:19, Jonathan Wakely wrote: On 24/01/20 11:48 +, Richard Earnshaw (lists) wrote: On 24/01/2020 11:04, Jonathan Wakely wrote: On 23/01/20 16:23 +, Richard Earnshaw (lists) wrote: On 21/01/2020 18:58, Richard Earnshaw (lists) wrote: This patch documents some of the

Re: [PATCH] wwwdocs: document scripts to access personal and vendor spaces

On 24/01/2020 15:12, Jonathan Wakely wrote: On 24/01/20 15:09 +, Jonathan Wakely wrote: On 24/01/20 13:55 +, Richard Earnshaw (lists) wrote: On 24/01/2020 12:19, Jonathan Wakely wrote: On 24/01/20 11:48 +, Richard Earnshaw (lists) wrote: On 24/01/2020 11:04, Jonathan Wakely wrote

Re: GCC Multi-Threading Ideas

On 24/01/2020 10:27, Jonathan Wakely wrote: On Fri, 24 Jan 2020 at 03:39, Nicholas Krause wrote: Sorry for the second message Allan but make -j does not scale well beyond 4 or 8 threads and that's considering a 4 core or 8 machine. The problem has to do with large build machines with CPUs with

Re: Git ChangeLog policy for GCC Testsuite inquiry

On 25/01/2020 16:11, Jeff Law wrote: On Sat, 2020-01-25 at 10:50 -0500, Nathan Sidwell wrote: On 1/24/20 4:36 PM, Jeff Law wrote: On Fri, 2020-01-24 at 20:32 +0100, Eric Botcazou wrote: I strongly prefer to move towards relying on the git log. In my experience the output of git log is a tota

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On 22/01/2020 17:45, Richard Earnshaw (lists) wrote: [updated based on v2 discussions] This patch proposes some new (additional) rules for email subject lines when contributing to GCC.  The goal is to make sure that, as far as possible, the subject for a patch will form a good summary when the

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On 03/02/2020 11:54, Alexander Monakov wrote: On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: I've not seen any follow-up to this version. Should we go ahead and adopt this? Can we please go with 'committed' (lowercase) rather than all-caps COMMITTED? Spelling this with

<    1   2   3   4   5   6   >