The patch adds a new internal-only intrinsic caf_send, which replaces
assignments to coindexed variables, i.e.
caf[i] = rhs
becomes
_F.caf_send (caf[i], rhs, async=.false.)
The idea is that this replacement makes it easier to do optimizations in
the front-end optimization pass
On Sat, Mar 15, 2014 at 5:09 AM, Mike Stump mikest...@comcast.net wrote:
On Mar 14, 2014, at 7:45 PM, Alexandre Oliva aol...@redhat.com wrote:
In some cases, the resulting executable code is none, but the debug stmts
add up to millions.
I'd like to think there is a better theoretic answer to
Regtests cleanly on x86_64-unknown-linux-gnu. Ok for trunk or wait for
next stage1?
Looks good to me - and simple enough for the 4.9 trunk.
Thanks, committed as r208590.
Cheers,
Janus
Then you should document that by stating that the pattern is guaranteed
to be invoked only for addresses (and may not clobber the condition
code).
Ok, will do.
Thanks.
Hoping isn't sufficient IMO here, you need to rename/rework
emit_add3_insn and possibly stop the compiler if the
Hi!
Here is an updated patch for what Tobias has posted earlier:
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00043.html
While that version bootstrapped/regtested fine, most of the Fortran
tests ICEd, primarily because the 3 operand __builtin_expect wasn't being
removed from the IL and for
I'm resending this because I forgot to dupe to gcc-patches and I'd like
one thread.
This should be pure commentary and documentation.
I hope I got all these. I grepped for DR and added
_GLIBCXX_RESOLVE_LIB_DEFECTS where it seemed needed.
I did not add in cases where DR mentions were more
Jerry DeLisle wrote:
The attached patch fixes this problem by first reading the next available char
to see if EOF is encountered. If so, issue the EOF error. If not use eat_line
to find the end of the line. If the end of the line is at the end of the file,
it will be caught on any subsequent
Dear All,
The fortran part looks fine to me.
Thanks for the patch,gents
Paul
This backports the fixes for wrong-code bugs PR57425 and PR57569,
both marked as 4.8 regressions, from mainline to 4.8 branch.
Tested since June last year on x86_64, powerpc64, sparc64, armv5tel,
and m68k without regressions. According to Bill Schmidt it also
fixes a wrong-code problem for
On Fri, Mar 14, 2014 at 3:04 PM, Jonathan Wakely jwak...@redhat.com wrote:
If all the tests pass this is OK for trunk, thanks.
Booted, tested, and committed.
N.B. the patch is fine but I don't think we usually say
@brief Class FooBar. Does some Foo and some Bar.
just
@brief Does some
On Sat, Mar 15, 2014 at 2:19 PM, Tim Shen timshe...@gmail.com wrote:
Booted, tested, and committed.
Oops, forgot to attach the committed version.
--
Regards,
Tim Shen
commit a4decc3a0f37bf24aaf50b7a0c7dba92c0ca45bb
Author: tim timshe...@gmail.com
Date: Fri Mar 14 14:50:12 2014 -0400
PR c++/60391
* parser.c (cp_parser_skip_to_end_of_block_or_statement): Unwind generic
function scope as per cp_parser_skip_to_end_of_statement.
PR c++/60391
* g++.dg/cpp1y/pr60391.C: New testcase.
---
gcc/cp/parser.c | 4
This is a follow-up to
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00959.html
which implemented the workaround for the data cache nullify issues on LEON3.
The errata sheet wasn't crystal clear and didn't say anything about delay
slots, but it appears that they can come into play so the
gcc/ChangeLog
2014-03-08 Sebastian Huber sebastian.hu...@embedded-brains.de
* doc/invoke.texi (mapp-regs): Clarify.
OK modulo:
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 2ee091a..12b43fa 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -20818,7
Are the global registers 5 and 6 really available for the operating
system or uses GCC or the linker them for a special purpose? Is it
possible to document this somewhere in to standard documentation and not
only in a header file?
This is documented in the ABIs so I think that the comment is
15 matches
Mail list logo
