Re: [PATCH] PR fortran/67987 -- character lengths cannot be negative

> F90 is over 26 years old. There has been 3 major revisions that > have superceded F90 (F95, F03, and F08). All of those revisions > include the text that you pointed out to me. Why is it surprising > that a compiler conforms to the standard? > > "Simplify, simplify, simplify." Henry David

Re: Add VIEW_CONVERT_EXPR to operand_equal_p

> Well, it would (I think) ICE on assigning a packed variant to a non-packed > variant of a strict that happens to get a non-BLKmode when not packed. Is "it" GIMPLE here? My sentence was not very clear, I meant that I don't see why GIMPLE would have to care about whether there is a VCE or not in

Re: Add VIEW_CONVERT_EXPR to operand_equal_p

On October 17, 2015 11:26:43 AM GMT+02:00, Eric Botcazou wrote: >> Well, it would (I think) ICE on assigning a packed variant to a >non-packed >> variant of a strict that happens to get a non-BLKmode when not >packed. > >Is "it" GIMPLE here? My sentence was not very clear, I meant that I >don't

[PATCH] PR middle-end/68002: introduce -fkeep-static-functions

In some cases (e.g. coverage testing) it is useful to emit code for static functions even if they are never used, which currently is not possible at -O1 and above. The following patch introduces a flag for this, which basically triggers the same code that keeps those functions alive at -O0. Than

[PATCH] MSP430: persistent data is FRAM, not flash

2015-10-17 Clemens Ladisch * doc/extend.texi (MSP430 Variable Attributes): Correct memory type for persistent data. --- gcc/doc/extend.texi |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/gcc/doc/extend.texi +++ b/gcc/doc/extend.texi @@ -5889,7 +5889,7 @@ Any va

Re: Add VIEW_CONVERT_EXPR to operand_equal_p

> >And AFAIK nobody answered the question: what do we gain by making this > >change? > >So far I have only seen breakages, suspicious fixes and code > >duplication... > > Honza wants the structural equality predicate (operand_equal_p) complete > (optimistically) for GIMPLE. There are two indepen

Re: [PATCH][C++] Fix PR67333

On 10/06/2015 04:46 PM, Jason Merrill wrote: > Hi, sorry for the slow response. Please feel free to ping once a week. > > On 08/27/2015 02:27 PM, Mikhail Maltsev wrote: >> + if (TREE_THIS_VOLATILE (t) && (!DECL_P (t) || want_rval)) > > Why the !DECL_P check? Pulling the value out of a volatile

[Patch, fortran] PR67177, 67977 and memory leaks in move_alloc

Dear All, I was moved by a report on clf of memory leaks in move_alloc to investigate the cause. This turned out to be trivial but led to the above PRs, which themselves were trivial. The result is the attached patch. I am aware that I have not investigated the further ramifications that I can ima

Re: [PATCH] Correctly fill up cgraph_node::local.versionable flag.

> Hello. > > I've been working on HSA branch, where we have a cloning pass running with all > optimization levels. The patch makes computation of > cgraph_node::local.versionability > independent on IPA CP and uses the flag to verify that a function can be > cloned. > > The patch can bootstrap

Re: [Patch, fortran] PR67177, 67977 and memory leaks in move_alloc

On Sat, Oct 17, 2015 at 09:49:45PM +0200, Paul Richard Thomas wrote: > > I was moved by a report on clf of memory leaks in move_alloc to > investigate the cause. This turned out to be trivial but led to the > above PRs, which themselves were trivial. The result is the attached > patch. I am aware

Re: [PATCH 1/9] ENABLE_CHECKING refactoring

On 10/12/2015 11:57 PM, Jeff Law wrote: >>> -#ifdef ENABLE_CHECKING >>> +#if CHECKING_P >> >> I fail to see the point of this change. > I'm guessing (and Mikhail, please correct me if I'm wrong), but I think he's > trying to get away from ENABLE_CHECKING and instead use a macro which is > always de