A rather obvious patch after one realizes that order= doesn't affect shape=.
Build & regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2013-04-07 Tobias Burnus
PR fortran/56849
* iresolve.c (gfc_resolve_reshape): Set shape also
with order=.
2013-04-07 Tobias Burnus
PR fortran/
2013/4/7 Tobias Burnus :
> A rather obvious patch after one realizes that order= doesn't affect shape=.
Right.
> Build & regtested on x86-64-gnu-linux.
> OK for the trunk?
Yes, thanks for the patch!
Cheers,
Janus
Hello,
the attached patch is very incomplete (it passes bootstrap+testsuite on
x86_64-linux-gnu), but it raises a number of questions that I'd like to
settle before continuing.
* Is there any chance of a patch in this direction being accepted?
* May I remove the builtins (from i386.c and the
On 04/06/2013 10:43 PM, Jonathan Wakely wrote:
That wouldn't hurt, but I agree it shouldn't prevent the patch going
in. François, please go ahead and commit it, thanks.
Attached patch applied then. Not exactly the one submitted the 2nd time
because I hadn't fix dg-error line numbers at that t
By the way, the comment in emmintrin.h in front of _mm_sqrt_sd seems
wrong:
/* Return pair {sqrt (A[0), B[1]}. */
It should be instead:
/* Return pair {sqrt (B[0]), A[1]}. */
If you agree I'll fix that independently.
--
Marc Glisse
On Sat, Apr 6, 2013 at 9:29 PM, John David Anglin wrote:
> "-mno-big-switch"
> can go. Probably, nobody will notice...
Like in the attached patch. My PA box appears to have joined the
silicon grave yard last night while trying to bootstrap this patch, so
I could use some help testing this while
Hi all,
here is a patch for an accepts-invalid problem: The Fortran standard
demands that a procedure with a polymorphic dummy arguments can only
be referenced with an explicit interface (see F08:12.4.2.2).
It is nontrivial to detect this in every case (e.g. passing a TYPE
actual to a CLASS forma
2013/4/7 Jeff Law :
> On 04/06/2013 01:42 AM, Chung-Ju Wu wrote:
>>
>> On behalf of Andes Technology Co., we have signed FSF agreement.
>> However, so far I don't have svn write access yet.
>> Would you please help to commit this patch?
>>
>> Thanks again for the approval and I really appreciate yo
* include/bits/forward_list.h: Only include required headers.
(forward_list::reference): Define directly, not using __alloc_traits.
(forward_list::const_reference): Likewise.
std::forward_list is only defined in C++11 so it doesn't need to use
__alloc_traits::reference to b
Committed, obvious.
* c-pragma.c (add_to_renaming_pragma_list): Fix leading comment.
Index: c-pragma.c
===
--- c-pragma.c (revision 197552)
+++ c-pragma.c (working copy)
@@ -478,7 +478,7 @@ handle_pragma_redefine_extname (c
This patch adds a new utility type that wraps a member of type
std::aligned_storage and provides some convenient accessors, to
replace repeated uses of the same code in the library.
The new type should also be used in the other node-based containers
when they gain C++11 allocator support.
I got a note yesterday from someone trying out GCC 4.8 that noted that
the compiler gave the "attribute ignored" warning for all their uses of
[[noreturn]], which is one of the attributes described in the standard.
Fixing this was a simple matter of mapping it onto the GNU noreturn
attribute,
Richard,
You advocate that I should be using an infinite precision
representation and I advocate a finite precision representation where
the precision is taken from the context. I would like to make the
case for my position here, in a separate thread, because the other
thread is just getting too
An unallocated polymorphic variable has the declared type; however, for
static (SAVE) variables, the current code didn't set the value.
(That the end of scope deallocation/_gfortran_caf_deregister is gone for
coarrays (declared in the main program) was a side effect. The
sync/deregistering wil
Janus Weil:
here is a patch for an accepts-invalid problem: The Fortran standard
demands that a procedure with a polymorphic dummy arguments can only
be referenced with an explicit interface (see F08:12.4.2.2).
I concur.
It is nontrivial to detect this in every case (e.g. passing a TYPE
actua
>> It is nontrivial to detect this in every case (e.g. passing a TYPE
>> actual to a CLASS formal arg), but at least we can easily detect it if
>> a polymorphic *actual* argument is involved (which means that the
>> corresponding formal arg must also be polymorphic).
>
>
> Sorry, I cannot follow he
On Fri, 5 Apr 2013, Gerald Pfeifer wrote:
> 2013-04-05 Gerald Pfeifer
>
> * update_web_docs_libstdcxx_svn: No longer ignore all output from
> the actual copy process.
> Check the exit code of the actual copy process; diagnose problems.
I committed this now, after it has been
Janus Weil wrote:
Thus, the only place where the check can be is for:
f => ff
In your example, the explicit interface of "ff" is known thus it should be
testable at resolution time of the proc-pointer assignment.
Right. However, strictly speaking, the pointer assignment as such is
probably
Hi Balaji,
On Wed, 3 Apr 2013, Iyer, Balaji V wrote:
> I would like to add information about the Cilkplus branch into the
> svn.html webpage. Here is the patch for it (I generated it using cvs
> diff -p svn.html). Is this OK to commit? Am I sending this to the
> correct location/mailing l
> -Original Message-
> From: Gerald Pfeifer [mailto:ger...@pfeifer.com]
> Sent: Sunday, April 07, 2013 5:55 PM
> To: Iyer, Balaji V
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [wwwdocs] Updating svn.html
>
> Hi Balaji,
>
> On Wed, 3 Apr 2013, Iyer, Balaji V wrote:
> > I would like
When inline failed because of callee is overwritable, gcc will not report it
in dump file (triggered by -fdump-tree-einline) as other not inlinable cases
do. This patch correct this.
Regtested/bootstrapped on x86_64-linux.
ChangeLog:
2013-04-08 Zhouyi Zhou
* cif-code.def (OVERWRITABL
Hi,
This patch updates the function frequency after calculating branch
probability. This is important because cold function could be promoted
to hot after ipa-inline.
Bootstrapped and passed gcc regression tests.
Okay for google-4_7?
Thanks,
Dehao
--- a/gcc/predict.c
+++ b/gcc/predict.c
@@ -28
In the current implementation, update_all_callee_keys only invokes
update_caller_keys for one edge. For the AutoFDO case, it could cause
important edges not being updated because top-down inline pattern is
very popular in AutoFDO. This patch ensures all edges are updated in
update_caller_keys.
Boo
At 2013-04-02 17:50:03,"Ramana Radhakrishnan" wrote:
>On 04/02/13 10:40, Xinyu Qi wrote:
>> Hi,
>>According to Vladimir Makarov's analysis, the root cause of PR
>> target/54338 is that ALL_REGS doesn't contain IWMMXT_GR_REGS in
>> REG_CLASS_CONTENTS.
>>It seems there is no reason to excl
Ok.
thanks,
David
On Sun, Apr 7, 2013 at 8:07 PM, Dehao Chen wrote:
> Hi,
>
> This patch updates the function frequency after calculating branch
> probability. This is important because cold function could be promoted
> to hot after ipa-inline.
>
> Bootstrapped and passed gcc regression tests.
On Fri, Apr 05, 2013 at 03:00:43PM -0600, Jeff Law wrote:
> On 04/05/2013 02:50 PM, Jakub Jelinek wrote:
> >On Fri, Apr 05, 2013 at 02:42:19PM -0600, Jeff Law wrote:
> >>? I must be missing something, the change causes an early bail out
> >>from try_crossjump_to_edge.
> >>
> >>We don't want to rai
On Mon, Apr 08, 2013 at 08:48:22AM +0200, Marek Polacek wrote:
> > Yea, changing the min value in params.def to 1 would be a better way
> > to fix. Consider that patch pre-approved.
>
> Ok, thanks. I'll apply this one. Regtest/bootstrap pending.
Thanks. Also ok for 4.8.
> 2013-04-08 Marek P
27 matches
Mail list logo
