AW: [PATCH] Skip re-computing the mips frame info after reload completed

Matthew Fortune writes: > Has the patch been tested beyond just building GCC? I can do a > test run for you if you don't have things set up to do one yourself. I built a cross-gcc with all languages and a cross-glibc, but I have not set up an emulation environment, so if you could give it a test

Re: Patch RFA: Add option -fcollectible-pointers, use it in ivopts

On Sat, Jan 23, 2016 at 5:42 PM, Sandra Loosemore wrote: > > I think these option descriptions are supposed to end in a period. Thanks for the doc comments; will fix before submitting if the overall patch is approved. Ian

Re: [PATCH, rs6000] Fix PR63354

On Sun, 2016-01-24 at 02:18 +0100, Jan-Benedict Glaw wrote: > On Thu, 2016-01-21 23:42:40 -0600, Bill Schmidt > wrote: > > On Thu, 2016-01-21 at 21:21 -0600, Bill Schmidt wrote: > > > The testcase will need a slight adjustment, as currently it fails on > > > powerpc64 with -m32 testing. Working

Re: [doc, 3/n] invoke.texi: move "Code Gen Options" before target-specific options

On Wed, 13 Jan 2016, Sandra Loosemore wrote: Here is the next installment of my series to make things easier to find in invoke.texi. I've checked in this patch to move the "Code Gen Options" up in the file so that all target-independent options are documented ahead of the target-specific ones.

Re: [PATCH] Fix constexpr evaluation of comparisons involving pointer-to-members

On Sun, Jan 10, 2016 at 10:19 PM, Patrick Palka wrote: > On Mon, Dec 21, 2015 at 6:07 PM, Patrick Palka wrote: >> We are currently failing to fold equality comparisons involving >> PTRMEM_CSTs since (I think) r229018 thus making this a GCC 6 regression. >> This regression shows up in the boost te

[wwwdocs] Rotate the oldest three news items

Looking at our homepage based on Jakub's question last week, there is some work to to make up for the new server configuration, but either way we should rotate older news off that page. Applied. Gerald Index: index.html === RCS file

[wwwdocs] Convert gcc-4.9/porting_to.html to using gcc.css (instead of individual style= clauses)

With this, like similar pages, we now have the colors back. Applied. Gerald Index: gcc-4.9/porting_to.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/porting_to.html,v retrieving revision 1.7 diff -u -r1.7 porting_to.html --- gcc

Wonly-top-basic-asm

I'm not sure which 'subsystem maintainer' to include on this as it affects parsers for both C and c++. I've also cc'ed people from the discussion thread. While that ~100 message thread on the gcc list about pr24414 didn't come to any final conclusions about clobbering registers for basic asm,

RE: [PATCH] Skip re-computing the mips frame info after reload completed

Bernd Edlinger writes: > this patch skips the redundant re-computing of the frame info after reload > completed. > > I looked at all available targets initial_elimination_offset functions: > > All of them currently use either a trivial function of > crtl->outgoing_args_size, > get_frame_size (

Re: [Patch, Fortran] PR69397 and PR6844 Internal Compiler Errors2

Hi Jerry, The attached patch with new test cases fixes these by replacing gcc_assert and updating the error message depending on whether resolving an initialization expression or not. Regression tested on x86-64. OK for trunk? OK. Thanks for the patch! Thomas

[Patch, Fortran] PR69397 and PR6844 Internal Compiler Errors2

Ha all, The attached patch with new test cases fixes these by replacing gcc_assert and updating the error message depending on whether resolving an initialization expression or not. Regression tested on x86-64. OK for trunk? Jerry 2016-01-23 Jerry DeLisle PR fortran/69397

Re: [PATCH] PR69329 --with-build-config=bootstrap-asan fails because LSAN_OPTIONS is not honored

On Sun, Jan 24, 2016 at 03:53:37PM +0300, Mikhail Maltsev wrote: > Hi all! > > --with-build-config=bootstrap-asan build currently fails, because address > sanitizer now has memory leak detection enabled by default. bootstrap-asan > contains > > export LSAN_OPTIONS="detect_leaks=0" > > but unfor

Re: [patch, fortran] Inline MATMUL(A,TRANSPOSE(B)), PR 66094

On 01/23/2016 01:26 PM, Thomas Koenig wrote: Hi Toon, However, today I *did* run the test harness with your modification: ... Thanks for the testing! So, what do people think? Is the patch OK for trunk? As far as I am able to determine, this is working. We still have 3 months (until mi

Re: [PATCH] [ARC] Add basic support for double load and store instructions

On 22/01/16 11:59, Claudiu Zissulescu wrote: Thank u for the feedback. I hope this new patch solves the outstanding issues. Please find it attached. This is OK.

[PATCH] PR69329 --with-build-config=bootstrap-asan fails because LSAN_OPTIONS is not honored

Hi all! --with-build-config=bootstrap-asan build currently fails, because address sanitizer now has memory leak detection enabled by default. bootstrap-asan contains export LSAN_OPTIONS="detect_leaks=0" but unfortunately this environment variable is set in top-level Makefile and is not propagat

Re: [PATCH] PR 68283 [5/6 Regression] ice: gfc_variable_attr(): Bad array reference

Hi Dominique, I thought this one had been dealt with a long time since... OK for trunk and 5-branch. Thanks for dealing with it! A Paul On 24 January 2016 at 12:22, Dominique d'Humières wrote: > Dear all, > > Is the following patch OK for trunk and the gcc5 branch? see the thread > starting

[PATCH] PR 68283 [5/6 Regression] ice: gfc_variable_attr(): Bad array reference

Dear all, Is the following patch OK for trunk and the gcc5 branch? see the thread starting at https://gcc.gnu.org/ml/fortran/2015-11/msg00057.html and https://gcc.gnu.org/ml/fortran/2015-11/msg00072.html. Dominique Index: gcc/fortran/ChangeLog ==

[PATCH, aarch64] Fix pr69305 -- addti miscompilation

As Jakub notes in the PR, the representation for add_compare and sub_compare were wrong. And several of the add_carryin patterns were duplicates. This adds a CC_Cmode for which only the Carry bit is valid. The patch appears to generate moderately decent code. For gcc7 we should look into why

[aarch64] Improve TImode constant moves

This looks to be an incomplete transition of the aarch64 backend to CONST_WIDE_INT. I haven't checked to see if it's a regression from gcc5, but I suspect not, since there should have been similar checks for CONST_DOUBLE. This is probably gcc7 fodder, but it helped me debug another TImode PR.

Re: [PATCH, PR69110] Don't return NULL access_fns in dr_analyze_indices

On January 23, 2016 7:44:23 PM GMT+01:00, Sebastian Pop wrote: >On Sat, Jan 23, 2016 at 12:28 PM, Tom de Vries >wrote: >> That was my original patch, and Richard commented: 'I think avoiding >a NULL >> access_fns is ok but it should be done unconditionally, not only for >the >> DECL_P case'. In