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 bur...@net-b.de
PR fortran/56849
* iresolve.c (gfc_resolve_reshape): Set shape also
with order=.
2013-04-07 Tobias Burnus
2013/4/7 Tobias Burnus bur...@net-b.de:
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
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
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 I'm
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
2013/4/7 Jeff Law l...@redhat.com:
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
* 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
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
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
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
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
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 here. At
On Fri, 5 Apr 2013, Gerald Pfeifer wrote:
2013-04-05 Gerald Pfeifer ger...@pfeifer.com
* 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,
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
-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 to add
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 yizhouz...@ict.ac.cn
*
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
@@
22 matches
Mail list logo
