> 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
> gcc/ChangeLog
> 2014-03-08 Sebastian Huber
>
> * 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 +20818,8 @@ These @samp{-m}
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 attache
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
gcc/tests
On Sat, Mar 15, 2014 at 2:19 PM, Tim Shen wrote:
> Booted, tested, and committed.
Oops, forgot to attach the committed version.
--
Regards,
Tim Shen
commit a4decc3a0f37bf24aaf50b7a0c7dba92c0ca45bb
Author: tim
Date: Fri Mar 14 14:50:12 2014 -0400
2014-03-15 Tim Shen
* in
On Fri, Mar 14, 2014 at 3:04 PM, Jonathan Wakely 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 Foo and so
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 powerp
Dear All,
The fortran part looks fine to me.
Thanks for the patch,gents
Paul
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 at
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 com
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 expansi
> > 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 i
>> 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
On Sat, Mar 15, 2014 at 5:09 AM, Mike Stump wrote:
> On Mar 14, 2014, at 7:45 PM, Alexandre Oliva 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 the specific
> problem... trim
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 (fortran
15 matches
Mail list logo
