Sure. Put back Init(SSP_TLS) and rebase to r197955.
If no further feedback, please merge.
2013-04-15 Andrew Hsieh
* config/i386/i386.opt: New option mstack-protector-guard=.
* config/i386/i386-opts.h: Add enum stack_protector_guard.
* config/i386/i386.h: Introduce TARG
Hi,
>> Same issue as my previous reply applies here.
Thanks for the suggestion.
Please find attached the modified patch as per your suggestions.
Please review the same and let me know if there should be any
further modifications in it.
Thanks,
Naveen
--- gcc/config/aarch64/aarch64.md 2013-04-
>> If you're going to do it in one file you'll need to use
>> scan-assembler-times.
Hi,
Thanks for the suggestion.
Please find attached the modified patch as per your suggestions.
Please review the same and let me know if there should be any
further modifications in it.
Thanks,
Naveen
--- gcc/
On Fri, Apr 12, 2013 at 6:46 PM, Steven Bosscher wrote:
>> Can we reorganize insn-notes.def so that the 3 classes are clearly separated
>> (and optionally define a NOTE_INSN_CLASS macro so that we don't need to
>> enumerate the notes each time)?
>
> That's probably a good idea, yes.
This didn't re
On Wed, 10 Apr 2013, Gabriel Dos Reis wrote:
On Wed, Apr 10, 2013 at 1:42 PM, Manuel López-Ibáñez
wrote:
On 9 April 2013 15:21, Jakub Jelinek wrote:
white). The default is still -fdiagnostics-color=never, can be changed
later on.
Apart from my comments elsewhere
(http://gcc.gnu.org/ml/gcc
This updates one link (sources.redhat.com now redirects to
sourceware.org), remove one generic one that used to point to
sun.com. And, while at it, I noticed that gcc should read GCC.
Applied to mainline; I'll probably backport to the 4.8 branch
later.
Gerald
2013-04-15 Gerald Pfeifer
> -Original Message-
> From: David Daney [mailto:ddaney.c...@gmail.com]
> Sent: Friday, April 12, 2013 7:29 PM
> To: Moore, Catherine
> Cc: Rozycki, Maciej; gcc-patches@gcc.gnu.org; Richard Sandiford
> Subject: Re: [Patch] [MIPS] Fix Many warnings in MIPS port (Was: [PATCH]
> [MIPS] micro
From: Eric Botcazou
Date: Sun, 14 Apr 2013 10:39:59 +0200
> To my great surprise, this PR shows that the SPARC back-end allows QImode and
> HImode values to live in FP registers, but can neither load nor move them.
> This can result in an unrecognizable move insn between FP registers or an
> il
Early *ping*.
For a usage, see for instance Open MPI, which since 1.7.0 uses it. From
their trunk version:
http://svn.open-mpi.org/svn/ompi/trunk/config/ompi_fortran_check_ignore_tkr.m4
http://svn.open-mpi.org/svn/ompi/trunk/ompi/mpi/fortran/use-mpi-ignore-tkr/mpi-ignore-tkr-interfaces.h.in
To
Hi Mikael,
- (void) gfc_expr_walker (&fcn, callback_reduction, NULL);
why remove this?
Because it is not needed, as the test case _46 shows. No need
to run this twice, it doesn't get better :-)
It is a leftover from when the callback function returned 1.
gfc_internal_error ("Illegal i
Hello,
This patch splits mips_reorg.c in a pre-dbr_schedule part and a new,
machine specific post-dbr_schedule pass. With this patch,
cleanup_barriers and dbr_schedule can be static functions again.
Cross-built&tested mips-sim. OK for trunk?
Ciao!
Steven
* config/mips/mips.c: Include tr
Hello,
Le 14/04/2013 11:57, Thomas Koenig a écrit :
> Hello world,
>
> the attached patch completely fixes the regression,
> PR 56782.
>
typo: it's PR 56872 everywhere.
> Regression-tested. OK for trunk and 4.8?
>
> Thomas
>
> 2013-04-14 Thomas Koenig
>
> PR fortran/56782
>
Hello,
My new delay branch scheduler uses TODO_verify_rtl_sharing but it
turns out that verify_rtl_sharing doesn't handle SEQUENCEs correctly:
Clearing the used-flags is done correctly, but verifying insns in the
SEQUENCE fails. The problem is that every insn in the SEQUENCE is
marked used via PAT
Hi Mikael,
Bootstrapped (with asan) and regression tested on x86_64-linux.
OK for trunk/4.8?
OK for both.
Thanks for the patch!
Thomas
Hello,
this fixes a case where an unfinished SELECT TYPE statement was leading
to an ICE because at the time the statement was rejected, the compiler
tried to free some symbols that had already freed with the SELECT TYPE
namespace.
The fix moves the namespace allocation and cleanup out of
gfc_mat
On 04/14/2013 03:33 AM, Gabriel Dos Reis wrote:
Does DR 1402 resolution generalization need a Standard committee validation
first ?
I cannot see why we would want otherwise :-)
-- Gaby
I rather wonder if gcc only accept modifications that has been validated
by the Standard committee first or
On Tue, Apr 9, 2013 at 3:46 AM, John David Anglin wrote:
> > Seems to cause a reload problem:
> Problem may be in not removing the continuation character "\" from various
> macro definitions.
Right, ASM_OUTPUT_ADDR_VEC_ELT and ASM_OUTPUT_ADDR_DIFF_ELT had a
trailing '\' that I should have removed.
Am 13.04.2013 20:21, schrieb Andreas Schwab:
> This enables building java for aarch64.
Afaics, the aarch64 changes for boehm-gc are not yet checked in. Aren't these
needed as a prerequisite?
On 04/13/2013 07:21 PM, Andreas Schwab wrote:
> # of unexpected failures 29
Looks basically OK. What were the failures, though?
Andrew.
Hello world,
the attached patch completely fixes the regression,
PR 56782.
Regression-tested. OK for trunk and 4.8?
Thomas
2013-04-14 Thomas Koenig
PR fortran/56782
* frontend-passes.c (copy_walk_reduction_arg): Do not
call the expression walker with callb
> I don't recall ever working on this aspect of reorg. The obvious worry
> is that with reorg moving stuff around those notes may not be valid
> anymore in the general case.
Yes, in the general case I agree that's too dangerous. In this particular
case, i.e. backward scan only, this might be pl
To my great surprise, this PR shows that the SPARC back-end allows QImode and
HImode values to live in FP registers, but can neither load nor move them.
This can result in an unrecognizable move insn between FP registers or an
illegal fdtox instruction in 64-bit mode as shown by the submitted tes
Hi,
this is a regression present on the mainline and 4.8 branch and introduced by
the latest series of sizetype changes. Associated adjustments were made in
the various front-ends for it, most notably Ada which was the most affected,
but this issue slipped through the cracks in the form of a b
> This is a quadratic algorithm and as such not ok. We already have
> aliasing_component_refs_p in tree-ssa-alias.c which is supposed to be
> the non-quadratic replacement. It's not used via decl_refs_may_alias_p,
> so that may be the thing to fix.
aliasing_component_refs_p isn't powerful enough
24 matches
Mail list logo