Jakub Jelinek writes:
> 2012-12-19 Jakub Jelinek
>
> * c-c++-common/asan/null-deref-1.c: Add -fno-shrink-wrap to
> dg-options.
This looks OK to me, thanks.
--
Dodji
"Maciej W. Rozycki" writes:
>> > I disabled 64 bit FPU instructions by "-msoft-float". This works, but
>> > using "-msingle-float" fails. This would be the better
>> > configuration. There are still 64 bit FPU instructions used (e.g. "dmfc1
>> > $2,$f0" when using "long double" multiplication). So
Jeff Law writes:
> On 01/07/2013 02:52 PM, Richard Sandiford wrote:
>
>>> I disabled 64 bit FPU instructions by "-msoft-float". This works, but
>>> using "-msingle-float" fails. This would be the better
>>> configuration. There are still 64 bit FPU instructions used (e.g. "dmfc1
>>> $2,$f0" when u
Richard Sandiford writes:
> "Jürgen Urban" writes:
>> ll, sc, dmult, ddiv, cvt.w.s, 64 bit FPU instructions.
>> ll and sc is disabled with "-mno-llsc" and works.
>> cvt.w.s is replaced by trunc.w.s. This seems to work.
>
> Probably showing my ignorance, but I couldn't see this in the patch.
Maci
On Tue, Jan 8, 2013 at 12:26 AM, Jakub Jelinek wrote:
> On Mon, Jan 07, 2013 at 05:52:23PM +0100, Uros Bizjak wrote:
>> TBH, I'm not that familiar with the RTL infrastructure enough to
>> answer these questions. While I can spend some time on this problem,
>> and probably waste quite some reviewer
On Tue, Jan 08, 2013 at 07:20:19AM +0100, Paul Richard Thomas wrote:
> Dear Steve,
>
> Thanks - committed as revision 195004.
>
> I should also have asked if it's OK for 4.6 and 4.7?
>
Yes, it is okay with the usual 2 to 3 days
of cooking on trunk before committing. Of
course, as you noted the
Dear Steve,
Thanks - committed as revision 195004.
I should also have asked if it's OK for 4.6 and 4.7?
Cheers
Paul
On 8 January 2013 00:12, Steve Kargl wrote:
> On Mon, Jan 07, 2013 at 11:57:27PM +0100, Paul Richard Thomas wrote:
>> Dear All,
>>
>> This is a rather 'obvious' fix that returns
Hi,
AARCH64 back-end defines REVERSE_CONDITION but not REVERSIBLE_CC_MODE.
REVERSE_CONDITION is used only in case REVERSIBLE_CC_MODE (mode) is
nonzero.
Please find attached the patch that defines REVERSIBLE_CC_MODE for
aarch64 back-end. Please review the patch and let me know if there should be
Hi,
ASM_FPRINTF_EXTENSIONS was copied from the arm back-end and is not
needed. Please find attached the patch that replaces "%r" in asm_fprintf
with reg_names. The definition of "ASM_FPRINTF_EXTENSIONS" is
removed as it is no longer needed.
Please review the patch and let me know if there should
On 01/07/2013 02:52 PM, Richard Sandiford wrote:
I disabled 64 bit FPU instructions by "-msoft-float". This works, but
using "-msingle-float" fails. This would be the better
configuration. There are still 64 bit FPU instructions used (e.g. "dmfc1
$2,$f0" when using "long double" multiplication).
On Mon, 7 Jan 2013, Richard Sandiford wrote:
> > ll, sc, dmult, ddiv, cvt.w.s, 64 bit FPU instructions.
> > ll and sc is disabled with "-mno-llsc" and works.
> > cvt.w.s is replaced by trunc.w.s. This seems to work.
>
> Probably showing my ignorance, but I couldn't see this in the patch.
This h
On 8 January 2013 00:17, Jonathan Wakely wrote:
> On 3 January 2013 05:14, Gerald Pfeifer wrote:
>> On Sat, 15 Dec 2012, Jonathan Wakely wrote:
>>> Committed to wwwdocs.
>>
>> Thanks, Jonathan.
>>
>> Where it says, "Added --disable-libstdcxx-verbose configure
>> option", would it make sense to add
On 3 January 2013 05:14, Gerald Pfeifer wrote:
> On Sat, 15 Dec 2012, Jonathan Wakely wrote:
>> Committed to wwwdocs.
>
> Thanks, Jonathan.
>
> Where it says, "Added --disable-libstdcxx-verbose configure
> option", would it make sense to add a half-sentence that describes the
> purpose of this opti
On Mon, Jan 07, 2013 at 05:52:23PM +0100, Uros Bizjak wrote:
> TBH, I'm not that familiar with the RTL infrastructure enough to
> answer these questions. While I can spend some time on this problem,
> and probably waste quite some reviewer's time, the problem is not that
> trivial as I hoped to be,
On Mon, Jan 07, 2013 at 11:57:27PM +0100, Paul Richard Thomas wrote:
> Dear All,
>
> This is a rather 'obvious' fix that returns gfortran to full
> compliance in the IVS testsuite. The testcase checks that various
> other combinations of arguments to elemental procedures work
> correctly.
>
> I
Dear All,
This is a rather 'obvious' fix that returns gfortran to full
compliance in the IVS testsuite. The testcase checks that various
other combinations of arguments to elemental procedures work
correctly.
I gave up trying to find which commit caused the problem because there
were so many can
On Sun, 7 Oct 2012, Mark Kettenis wrote:
> Adds the necessary support bits to libgcc. All other mainstream
> i386/amd64 targets already have this.
>
> Tested on i386-unknown-openbsd5.2 and x86_64-unknown-openbsd5.2.
> Fixes a couple of testcases.
>
>
> libgcc/:
>
> 2012-10-06 Mark Kettenis
To meet standards (and server configuration) on www.gnu.org where
our web pages are hosted as well, I added a trivial file gcc.html
to our web pages:
This redirects to our index page and should _not_ be referenced
anywhere within our control, be it from our own web pages or
externally, it is sol
On Sun, 25 Mar 2012, Dodji Seketeli wrote:
> Fixed thus. I hope it is not too late, now that 4.7 is out.
It's never too late. :-)
> * htdocs/gcc-4.7/changes.html: Update for
> -ftrack-macro-expansion and -Wunused-local-typedefs.
I just applied a patch with some markup additions
Going through some older mails (as some may have noticed), I found
this patch which Iain was had done, and which I had reviewed, but
which somehow did not make it in.
Applied now, with some fuzzing manually adjusted.
Gerald
--- changes.html.orig 2012-10-03 07:02:42.198917592 -1000
+++ changes.
On Thu, 20 Dec 2012, Tobias Burnus wrote:
> The following patch updates the Fortran part of the GCC 4.8 release
> notes at http://gcc.gnu.org/gcc-4.8/changes.html#fortran
Nice! I had a look and made a couple of editorial changes which
should not change any of the statements. If you'd like to se
Hello Uros,
I tried to use your suggestion and use DEFAULT_SECTION_THRESHOLD
in i386.opt, however this doesn't work for me. It seems the default is
always
65536 regardless of what I define in rdos.h. Therefore, I kept the design
as it was before.
Changing name to TARGET_RDOS seems reasonable,
"Jürgen Urban" writes:
> ll, sc, dmult, ddiv, cvt.w.s, 64 bit FPU instructions.
> ll and sc is disabled with "-mno-llsc" and works.
> cvt.w.s is replaced by trunc.w.s. This seems to work.
Probably showing my ignorance, but I couldn't see this in the patch.
> I disabled 64 bit FPU instructions by
On Thu, 2012-11-15 at 13:39 -0800, Andrew Pinski wrote:
> > I was posting it for Steve's benefit really. I was in the process of
> > updating the patch to the trunk and trying it out there before doing a
> > formal submission :). As I found out the testcase needs to be changed
> > to work with t
Hi!
evaluate_stmt can be crashed similarly to what you've fixed today.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2013-01-07 Jakub Jelinek
PR middle-end/55890
* tree-ssa-ccp.c (evaluate_stmt): Use gimple_call_builtin_p.
* gcc.dg/torture/pr558
Hi!
As mentioned in the PR, the actual important bug has been fixed in
range_fits_type_p by Richard Sandiford recently, so here are just two minor
nits. An extension of a signed src_type to unsigned wider type is fine only
if the vr doesn't have negative min or max, so always assuming we can exte
On 7 January 2013 16:39, Rainer Orth wrote:
> As reported in the PR, the AIX assembler also accepts the -nH option,
> but with completely different semantics. To avoid this, the current
> patch restricts checking the option to Solaris targets.
>
> Bootstrapped without regressions on i386-pc-solari
Function __gcov_indirect_call_profiler_atomic (which contains call to
the atomic function) is always emitted in libgcov.
Since we only link libatomic when -fprofile-gen-atomic is specified,
we have to make the atomic function weak -- otherwise, there is a
unsat for regular FDO gen build (of course,
On Mon, 2013-01-07 at 20:38 +, Richard Sandiford wrote:
>
> Ah, sorry, this reminded me of a patch I'd written a year ago and never
> got around to sanity-checking. Does it fix the problem for you?
>
> Richard
It fixes my small test case, I will try it on the full testsuite
overnight.
Ste
I did notice that the hardware didn't work the same way as the
documentation... this would explain it. Yes, please apply it :-)
Jeff Law writes:
> On 01/06/2013 03:56 PM, "Jürgen Urban" wrote:
>> Hello,
>>
>> I created a patch from scratch to support MIPS r5900 used in the
>> Playstation 2, but I have some problems with it. The attached patch
>> only works with the latest binutils from CVS. The binutils forces the
>> compi
On Mon, Jan 7, 2013 at 8:45 PM, Jeff Law wrote:
> Before diving into the patch I think we should figure out why we see such
> different effects of eliminating these paths from the CFG. Your assertion
> is eliminating them will result in more false positives and less
> optimization while my assert
On Mon, 2013-01-07 at 20:30 +, Richard Sandiford wrote:
> "Steve Ellcey " writes:
> > While testing all the variations of my mips-mti-elf target I found that
> > a number of debug tests like gcc.dg/debug/trivial.c fail when compiled
> > using a stabs debug flag (-gstabs3 for example) and -mips
Richard Sandiford writes:
> "Steve Ellcey " writes:
>> While testing all the variations of my mips-mti-elf target I found that
>> a number of debug tests like gcc.dg/debug/trivial.c fail when compiled
>> using a stabs debug flag (-gstabs3 for example) and -mips16. While running
>> the GNU simula
On 01/03/2013 04:42 PM, Rong Xu wrote:
> It links libatomic when -fprofile-gen-atomic is specified for FDO
> instrumentation build. Here I assume libatomic is always installed.
> Andrew: do you think if this is reasonable?
>
> It also disables the functionality if target does not support weak
> (i
"Steve Ellcey " writes:
> The MIPS documentation describes a -mmad (-mno-mad) flag, but it is
> incorrectly
> implemented as -mad (-mno-ad) instead. This patch changes the implementation
> to match the documentation. This means that users who are currently using the
> -mad or -mno-ad flags woul
On Mon, 7 Jan 2013, Richard Sandiford wrote:
> "Joseph S. Myers" writes:
> > On Sun, 6 Jan 2013, Richard Sandiford wrote:
> >
> >> Anyway, here's my attempt a script to convert to ranges and, if enabled,
> >> to include the current year. The script only updates FSF copyright notices
> >> and lea
"Steve Ellcey " writes:
> While testing all the variations of my mips-mti-elf target I found that
> a number of debug tests like gcc.dg/debug/trivial.c fail when compiled
> using a stabs debug flag (-gstabs3 for example) and -mips16. While running
> the GNU simulator I get:
>
> mips-core: 1 byte
HI,
On Mon, Jan 7, 2013 at 12:21 PM, Richard Sandiford
wrote:
> It was just a question of whether to submit the fixincludes/ and gcc/
> parts as one patch (as I'd originally done) or as two separate patches.
> Two separate patches probably makes more sense and I think is what
> Joseph was suggest
Bruce Korb writes:
> On Mon, Jan 7, 2013 at 11:49 AM, Richard Sandiford
> wrote:
>>> I think a patch for each directory will need posting separately for review
>>> of such things as whether any imported / generated files are mistakenly
>>> changed.
>>
>> So fixincludes/ separate from gcc/, and ev
On Mon, Jan 7, 2013 at 11:49 AM, Richard Sandiford
wrote:
>> I think a patch for each directory will need posting separately for review
>> of such things as whether any imported / generated files are mistakenly
>> changed.
>
> So fixincludes/ separate from gcc/, and every library separate? OK.
S
This is a tentative patch that adds symbols that can be used as predicates in
the linker script.
Background is binutils PR14406: Data in address space __flash1 must be located
in such a way that the high byte (hh8) of the address is 0x1. This is needed
because avr-gcc sets RAMPZ to 0x1 before rea
I think that's right, since the ISR return restores the flag register,
which has the bank select bits in it.
"Joseph S. Myers" writes:
> On Sun, 6 Jan 2013, Richard Sandiford wrote:
>
>> Anyway, here's my attempt a script to convert to ranges and, if enabled,
>> to include the current year. The script only updates FSF copyright notices
>> and leaves others alone. I've tried my best to make sure that li
On 01/05/2013 01:10 PM, Steven Bosscher wrote:
Presumably BB7 was created in response to the builtin_unreachable?
Yes. The block only contains the BB_UNREACHABLE call. It is cleaned up
at the end of the GIMPLE passes pipeline, in the fold-all-builtins
pass (most __builtin_unreachable calls are
The MIPS documentation describes a -mmad (-mno-mad) flag, but it is incorrectly
implemented as -mad (-mno-ad) instead. This patch changes the implementation
to match the documentation. This means that users who are currently using the
-mad or -mno-ad flags would have to change. If we want we cou
While testing all the variations of my mips-mti-elf target I found that
a number of debug tests like gcc.dg/debug/trivial.c fail when compiled
using a stabs debug flag (-gstabs3 for example) and -mips16. While running
the GNU simulator I get:
mips-core: 1 byte read to unmapped address 0xe820
>>> We would like to propose changing AVX generic mode tuning to
>>> generate 128-bit AVX instead of 256-bit AVX.
>>
>> You indicate a 3% reduction on bulldozer with avx256.
>> How does avx128 compare to -mno-avx -msse4.2?
> Will the next AMD generation have a useable avx256?
>>
>> I'm not keen on
Dominique Dhumieres wrote:
(1) Is there any hint of -fno-whole-file misbehavior (as suggested by the
second point of the "Reasoning")?
The middle end is simply not prepared for having multiple declaration
for a single file ("translation unit"), which leads to wrong
optimizations and thus to w
2013/1/7 Georg-Johann Lay
>
> Currently, data in address space __memx is allocated to .progmem.data, i.e.
> the
> same section as for __flash resp. progmem. However, there os no need that
> __memx goes onto the same section and wastes precious memory in the first 64
> Ki.
>
> The patch puts __m
On Fri, Jan 4, 2013 at 6:56 AM, H.J. Lu wrote:
> On Fri, Jan 4, 2013 at 2:06 AM, Andreas Schwab wrote:
>> "H.J. Lu" writes:
>>
>>> On Thu, Jan 3, 2013 at 10:09 AM, Andreas Schwab
>>> wrote:
"H.J. Lu" writes:
> diff --git a/libjava/Makefile.am b/libjava/Makefile.am
> index c6
On 01/07/2013 02:16 AM, Tom de Vries wrote:
> - /* If MODE is no wider than a single word, we return a paradoxical
> - SUBREG. */
> + /* If MODE is no wider than a single word, we return a
> + lowpart or paradoxical SUBREG. */
>if (GET_MODE_SIZE (mode) <= UNITS_PER_WORD)
> -retu
On Fri, Jan 04, 2013 at 02:21:43PM +0100, Richard Biener wrote:
> The other way would be
>
> Index: gcc/fold-const.c
> ===
> --- gcc/fold-const.c(revision 194900)
> +++ gcc/fold-const.c(working copy)
> @@ -900,9 +900,9 @@ asso
Hello,
Le 04/01/2013 13:51, Tobias Burnus a écrit :
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 2610784..146154e 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -3291,22 +3291,21 @@ gfc_check_assign (gfc_expr *lvalue, gfc_expr *rvalue,
int conform)
gfc_try
gfc_check
On 01/06/2013 03:56 PM, "Jürgen Urban" wrote:
Hello,
I created a patch from scratch to support MIPS r5900 used in the
Playstation 2, but I have some problems with it. The attached patch
only works with the latest binutils from CVS. The binutils forces the
compiler to use r5900 compatible instruc
Jakub Jelinek writes:
> 2012-12-21 Jakub Jelinek
>
> * varasm.c (output_constant_def_contents): For asan_protect_global
> protected strings, adjust DECL_ALIGN if needed, before testing for
> anchored symbols.
> (place_block_symbol): Adjust size for asan protected STRING
And another bug: we were building an AGGR_INIT_EXPR in non-dependent
code, and then failing to handle it properly in fold_non_dependent_expr.
Fixed by not creating AGGR_INIT_EXPR in templates. As a result, we
end up with a CALL_EXPR to the address of a constructor, and we need to
avoid an err
On Sun, Jan 6, 2013 at 5:22 PM, Jakub Jelinek wrote:
>> --- df-problems.c (revision 194945)
>> +++ df-problems.c (working copy)
>> @@ -3916,6 +3916,10 @@ can_move_insns_across (rtx from, rtx to, rtx acros
>> break;
>>if (NONDEBUG_INSN_P (insn))
>> {
>> + /* Do no
As reported in the PR, the AIX assembler also accepts the -nH option,
but with completely different semantics. To avoid this, the current
patch restricts checking the option to Solaris targets.
Bootstrapped without regressions on i386-pc-solaris2.10 with Sun as
(-Wa,-nH is added), x86_64-unknown-
> -Original Message-
> From: Georg-Johann Lay [mailto:a...@gjlay.de]
> Sent: Monday, January 07, 2013 9:17 AM
> To: Weddington, Eric
> Cc: gcc-patches@gcc.gnu.org; Denis Chertykov; Gerald Pfeifer
> Subject: Re: [patch,doc,avr] ad PR54461: Document --with-avrlibc
>
>
> I used a different f
Sorry for the late and lengthy answer. To make the story short, I think
the decision to remove -fno-whole-file should be based on the answer to the
following questions:
(1) Is there any hint of -fno-whole-file misbehavior (as suggested by the
second point of the "Reasoning")?
As said in my comm
On Fri, 21 Dec 2012, Alexander Ivchenko wrote:
> Hi,
>
> Thank you very much for your input! Please, take a look at the updated
> version:
> I fixed coding style, moved documentation for TARGET_LIBC_HAS_FUNCTION
> to target.def.
> Removed TARGET_C99_FUNCTIONS and TARGET_HAS_SINCOS and all their
Weddington, Eric wrote:
> Georg-Johann Lay Sent
>> Document --with-avrlibc
>>
>>> This option is only supported for the AVR target and only for non-RTEMS
>>> configurations, which currently use newlib. The option is supported
>>> since version
>
> I forgot to mention that it looks like there mig
On Fri, 7 Dec 2012, Terry Guo wrote:
> 2012-12-07 Terry Guo
>
> * gcc/Makefile.in (s-mlib): New argument MULTILIB_REUSE.
> * gcc/doc/fragments.texi: Document MULTILIB_REUSE.
> * gcc/gcc.c (multilib_reuse): New internal spec.
> (set_multilib_dir): Also search mul
gcc.dg/lto/pr55525 currently FAILs on Solaris with Sun ld for the 32-bit
multilib:
FAIL: gcc.dg/lto/pr55525 c_lto_pr55525_0.o-c_lto_pr55525_1.o link, -flto -w
UNRESOLVED: gcc.dg/lto/pr55525 c_lto_pr55525_0.o-c_lto_pr55525_1.o execute
-flto -w
ld: fatal: symbol 's' has differing sizes:
On Mon, 7 Jan 2013, Steven Bosscher wrote:
> Hello,
>
> As-is, tree-ssa-sink.c can only sink GIMPLE_ASSIGN statements. This
> patch lets tree-ssa-sink.c sink pure calls also.
>
> This allows the pass to sink the call to use in the following test
> case (new test case, ssa-sink-10.c to be):
>
>
On Wed, 19 Dec 2012, H.J. Lu wrote:
> +#ifdef CROSS_DIRECTORY_STRUCTURE
> + = concat(target_machine, "-", ld_suffixes[i], NULL);
Missing space before '('.
The patch is OK with that fixed.
--
Joseph S. Myers
jos...@codesourcery.com
On Sun, 6 Jan 2013, Richard Sandiford wrote:
> Anyway, here's my attempt a script to convert to ranges and, if enabled,
> to include the current year. The script only updates FSF copyright notices
> and leaves others alone. I've tried my best to make sure that licences
> and imported FSF sources
Hello,
As-is, tree-ssa-sink.c can only sink GIMPLE_ASSIGN statements. This
patch lets tree-ssa-sink.c sink pure calls also.
This allows the pass to sink the call to use in the following test
case (new test case, ssa-sink-10.c to be):
-- 8<
/* { dg-do compile
> -Original Message-
> From: Georg-Johann Lay
> Sent: Monday, January 07, 2013 8:28 AM
> To: Weddington, Eric
> Cc: gcc-patches@gcc.gnu.org; Denis Chertykov; Gerald Pfeifer
> Subject: Re: [patch,doc,avr] ad PR54461: Document --with-avrlibc
>
> > +This option is only supported for the AVR
Weddington, Eric wrote:
>
> Georg-Johann Lay Sent
>> Document --with-avrlibc
>>
>> This addendum adds --with-avrlibc to the (web) documentation.
>>
>> It inserts the explanation after --with-newlib which seems to be a
>> reasonable place.
>>
>> Ok to apply?
>>
>
> Change:
>
> +This option i
This bumps the minor version, LTO bytecode from 4.7 is not compatible
with one from 4.8.
Committed as obvious.
Thanks,
Richard.
2013-01-07 Richard Biener
* lto-streamer.h (LTO_minor_version): Bump to 2.
Index: gcc/lto-streamer.h
=
> -Original Message-
> From: Georg-Johann Lay
> Sent: Monday, January 07, 2013 8:02 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Denis Chertykov; Weddington, Eric; Gerald Pfeifer
> Subject: [patch,doc,avr] ad PR54461: Document --with-avrlibc
>
> This addendum adds --with-avrlibc to the (web)
gfortran uses (via the driver) the separated version of the flag, e.g.
-fintrinsic-modules-path /usr/lib64/gcc/x86_64-suse-linux/4.8/finclude
However, the current version also supports a joined version, which comes
- very confusingly - without "=":
-fintrinsic-module-pat
This addendum adds --with-avrlibc to the (web) documentation.
It inserts the explanation after --with-newlib which seems to be a reasonable
place.
Ok to apply?
Johann
PR target/PR54461
* doc/install.texi (Cross-Compiler-Specific Options): Document
--with-avrlibc.
Index:
On 07/01/13 10:36, James Greenhalgh wrote:
bool aarch64_bitmask_imm (HOST_WIDE_INT val, enum machine_mode);
-bool aarch64_const_double_zero_rtx_p (rtx);
+bool aarch64_float_const_zero_rtx_p (rtx);
bool aarch64_constant_address_p (rtx);
Can we keep these in alphabetical order please?
Otherw
On 07/01/13 10:54, James Greenhalgh wrote:
Hi,
This patch fixes the definitions of the vld1* intrinsics
to take a const-qualified argument.
I've tested this on aarch64-none-elf with no regressions.
Is this OK to commit?
Thanks,
James Greenhalgh
---
2013-01-07 James Greenhalgh
*
On 07/01/13 13:11, Tejas Belagod wrote:
Hi,
The attached patch implements vec_init for AArch64. This has been tested on
aarch64-none-elf with no regressions. OK for aarch64-4.7-branch?
Thanks,
Tejas Belagod
ARM.
2013-01-07 Tejas Belagod
gcc/
* config/aarch64/aarch64-simd.md (vec_i
On 07/01/13 13:11, Tejas Belagod wrote:
Hi,
The attached patch implements vec_init for AArch64. This has been tested on
aarch64-none-elf with no regressions. OK for trunk?
Thanks,
Tejas Belagod
ARM.
2013-01-07 Tejas Belagod
gcc/
* config/aarch64/aarch64-simd.md (vec_init): New.
Currently, data in address space __memx is allocated to .progmem.data, i.e. the
same section as for __flash resp. progmem. However, there os no need that
__memx goes onto the same section and wastes precious memory in the first 64 Ki.
The patch puts __memx data into .progmemx.data so that a linke
On Mon, 7 Jan 2013, Jakub Jelinek wrote:
Won't the above preclude parsing 2147483640 up to 2147483647 ?
Because then in the last iteration count 214748364 > (INT_MAX - 9) / 10.
You're right -- thanks for catching that! Below is a patch with a more
precise check.
Nickolai.
--- libiberty/cpl
On Mon, 7 Jan 2013, Jakub Jelinek wrote:
> On Mon, Jan 07, 2013 at 03:06:50PM +0100, Richard Biener wrote:
> > *** gcc/tree-ssa-strlen.c (revision 194970)
> > --- gcc/tree-ssa-strlen.c (working copy)
> > *** adjust_last_stmt (strinfo si, gimple stm
> > *** 809,818
> >
> >
Early * ping * the patch below, i.e.
http://gcc.gnu.org/ml/fortran/2013-01/msg00033.html
Other pending patches by me:
http://gcc.gnu.org/ml/fortran/2013-01/msg00049.html
http://gcc.gnu.org/ml/fortran/2013-01/msg00025.html
Other pending patches by …
Thomas: http://gcc.gnu.org/ml/fortran/2013-01/
On Mon, Jan 07, 2013 at 03:06:50PM +0100, Richard Biener wrote:
> *** gcc/tree-ssa-strlen.c (revision 194970)
> --- gcc/tree-ssa-strlen.c (working copy)
> *** adjust_last_stmt (strinfo si, gimple stm
> *** 809,818
>
> if (!is_gimple_call (last.stmt))
> return;
On Mon, 7 Jan 2013, Jakub Jelinek wrote:
> On Mon, Jan 07, 2013 at 02:55:48PM +0100, Richard Biener wrote:
> > *** gcc/testsuite/gcc.dg/torture/pr55890-1.c(revision 0)
> > --- gcc/testsuite/gcc.dg/torture/pr55890-1.c(working copy)
> > ***
> > *** 0
> > --- 1,6
On Mon, Jan 07, 2013 at 02:55:48PM +0100, Richard Biener wrote:
> *** gcc/testsuite/gcc.dg/torture/pr55890-1.c (revision 0)
> --- gcc/testsuite/gcc.dg/torture/pr55890-1.c (working copy)
> ***
> *** 0
> --- 1,6
> + /* { dg-do compile } */
> +
> + extern void *memmove(void *,
Since we freely propagate function addresses we can end up with
call statements with mismatched number and type of arguments
than what the function decl referenced says. This is a problem
for builtin decls and all code that tries to examine their
arguments (which may not be there or be of bogus t
The following fixes a fallout of fixing PR55862 - the fix for it
merely papered over the issue that we inconsistently prune
expressions in clean (). Fixing that allows us to revert the
original PR55862 fix and thus fix PR55888.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Rich
Hi,
The attached patch implements vec_init for AArch64. This has been tested on
aarch64-none-elf with no regressions. OK for trunk?
Thanks,
Tejas Belagod
ARM.
2013-01-07 Tejas Belagod
gcc/
* config/aarch64/aarch64-simd.md (vec_init): New.
* config/aarch64/aarch64-protos.h
Hi,
The attached patch implements vec_init for AArch64. This has been tested on
aarch64-none-elf with no regressions. OK for aarch64-4.7-branch?
Thanks,
Tejas Belagod
ARM.
2013-01-07 Tejas Belagod
gcc/
* config/aarch64/aarch64-simd.md (vec_init): New.
* config/aarch64/aar
2013/1/7 Georg-Johann Lay :
> This patch is a rewrite of t-avr so that STAMP is not needed.
>
> Ada triggers a mistimed re-build of targets using STAMP which causes PR55243
> because the respective places in gnattools ada/gcc-interface don't set STAMP.
>
> With this patch, files that were formerly
This patch is a rewrite of t-avr so that STAMP is not needed.
Ada triggers a mistimed re-build of targets using STAMP which causes PR55243
because the respective places in gnattools ada/gcc-interface don't set STAMP.
With this patch, files that were formerly auto-generated must be generated by
ha
Hello!
The same definition now lives in defaults.h, included through tm.h.
2013-01-07 Uros Bizjak
* config/i386/i386.c (DEFAULT_PCC_STRUCT_RETURN): Remove.
Tested on x86_64-pc-linux-gnu, committed to mainline SVN.
Uros.
Index: config/i386/i386.c
Dear Tobias,
It looks good to me. OK for trunk
Thanks for the patch - we'll have regressions down below 20 by
tonight. I am rather certain that I have the correct fix for PR55618.
Let's see if we can get to single figures, once more, by the end of
the month!
Paul
On 7 January 2013 10:13, Tobia
Hi,
This patch fixes the definitions of the vld1* intrinsics
to take a const-qualified argument.
I've tested this on aarch64-none-elf with no regressions.
Is this OK to commit?
Thanks,
James Greenhalgh
---
2013-01-07 James Greenhalgh
* config/aarch64/arm_neon.h (vld1_dup_*): Make
> Pasto: applied on mainline only.
Similar patch that removes a useless test (always true) and adjust a comment.
Tested on x86_64-suse-linux, applied on mainline.
2013-01-07 Eric Botcazou
* gcc-interface/decl.c (gnat_to_gnu_entity) : Adjust
comment about type extension with
Hi,
Currently, the AArch64 port loads all floating-point values via a
constant pool. For some cases, we can do a better job.
This patch adds support for loading immediates which are either +0.0
or a value which can be represented in a "quarter-precision" format.
That is to say, an 8-bit floating
Ping.
http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01113.html
Thanks,
Kyrill
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Kyrylo Tkachov
> Sent: 18 December 2012 13:34
> To: gcc-patches@gcc.gnu.org
> Cc: Ramana Radhakri
Ping.
http://gcc.gnu.org/ml/gcc-patches/2012-12/msg0.html
Thanks,
Kyrill
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Kyrylo Tkachov
> Sent: 18 December 2012 13:33
> To: gcc-patches@gcc.gnu.org
> Cc: Ramana Radhakri
[with CC to gcc-patches]
Original Message
Subject: [PATCH] Fix PR55876 - Make generation of paradoxical subreg in
widen_operand more robust
Date: Mon, 07 Jan 2013 11:13:49 +0100
From: Tom de Vries
To: Richard Henderson
CC: Steve Ellcey , Andrew Pinski
Richard,
Consider test-
1 - 100 of 106 matches
Mail list logo
