Hello Vlad,
The attached patch back-ports to the LRA branch (or foward-ports,
depending on how you look at it :-) all the changes made on the trunk
to LRA.
Bootstrapped&tested on powerpc64-unknown-linux-gnu[1] and
ia64-unknown-linux-gnu[2], and cross-built and tested mipsisa64-elf
[3].
[1] http:
To be clear - I was awaiting a formal submission but indicating that I
would OK it when it was made. I completely missed the posting of 16th
December.
OK by me for trunk, followed by 4.6 and 4.7.
Cheers
Paul
On 11 January 2013 21:51, Mikael Morin wrote:
> Le 11/01/2013 21:31, Janus Weil a écr
Le 11/01/2013 21:31, Janus Weil a écrit :
Thanks for your review (which I read as an OK for all branches,
right?).
Well, from my point of view it is OK, but I was actually hoping Tobias
would ack it himself.
On Fri, 11 Jan 2013 09:58:49 +0100
Dodji Seketeli wrote:
> Thank you Dave for this documentation patch that looks OK to my casual
> eyes. Let's CC the documentation maintainers.
>
> Dave Johansen a écrit:
>
> >
> > +GCC plugin support is available in GCC version 4.5.0 and
> > +later.
Maybe
PING.
Slightly updated patch attached, which further improves the generic
size fallback that is used when the element size is not 2/4/8 bytes.
Changing the us_perf benchmark to use real(10), with the v2 patch the
performance is:
Unformatted sequential write/read performance test
Record size
Hi Mikael,
>> Ping! (What do we do with this little bugger?)
>>
>> @Paul: Was your comment 19 in the PR meant as an OK for my patch
>> (submitted here: http://gcc.gnu.org/ml/fortran/2012-12/msg00097.html),
>> or was it just a general agreement with the previous comments?
>>
> FWIW, I regard the pa
Le 01/01/2013 21:18, Thomas Koenig a écrit :
Hello world,
the attached patch replaces ANY(a, b, c) with a .or. b .or c,
leading to reduced execution time. It also handles ALL, PRODUCT
and SUM.
This fixes a bug noted by Michael Metcalf.
Regression-tested. OK for trunk?
A few comments below.
Hi!
As discussed in the PR, the extra verification of location blocks Richard
posted recently fails on some Fortran testcases. The problem is that
ADDR_EXPRs in static const var initializers contain locations (fixed by the
trans-expr.c hunks), and that gimple-fold makes the ADDR_EXPRs shared, so
On Fri, Jan 11, 2013 at 9:53 PM, Andrew Pinski wrote:
> On Fri, Jan 11, 2013 at 8:17 AM, George Thomas
> wrote:
>> Hi,
>>
>> I am sending a patch which solves the debugging issue (PR 54218).
>>
>> The fix is to allocate stack space only once for parameters in expand pass.
>>
>> The patch is attac
Le 07/01/2013 16:07, Tobias Burnus a écrit :
diff --git a/gcc/fortran/options.c b/gcc/fortran/options.c
index e05b935..0e0a71d 100644
--- a/gcc/fortran/options.c
+++ b/gcc/fortran/options.c
@@ -845,6 +845,7 @@ gfc_handle_option (size_t scode, const char *arg, int value,
break;
case O
Le 10/01/2013 20:39, Janus Weil a écrit :
Ping! (What do we do with this little bugger?)
@Paul: Was your comment 19 in the PR meant as an OK for my patch
(submitted here: http://gcc.gnu.org/ml/fortran/2012-12/msg00097.html),
or was it just a general agreement with the previous comments?
FWIW, I
Somebody within IBM pointed out to me that the documentation for the x86
__builtin_ia32_padd256b and __builtin_ia32_pavgb256 were missing a space
between the type and the __builtin name. I committed this patch as obvious to
the trunk, and will update gcc 4.7 shortly.
2013-01-11 Michael Meissner
Another issue that was noticed was __builtin_ia32_packssdw256 did not have the
initial '__'. I committed this patch as obvious to both the trunk and GCC 4.7.
2013-01-11 Michael Meissner
* doc/extend.texi (X86 Built-in Functions): Add missing '__' in
front of __builtin_ia32_pac
On Fri, 11 Jan 2013, Richard Sandiford wrote:
> BTW Maciej, sorry to be prickly about this, but: where I live, "I insist"
> has a very domineering ring to it, at least in this kind of context.
> The implication tends to be that "having insisted, I really expect it to
> happen, simply because it is
Jason Merrill writes:
> On 01/11/2013 05:38 AM, Dodji Seketeli wrote:
>> but when I read the code, it looks like this is not necessary. Am I
>> missing something? In any case, I haven't put that code in the new
>> coerce_innermost_template_parms. Is that OK?
>
> I agree that it seems unnecessa
On Fri, Jan 11, 2013 at 8:17 AM, George Thomas
wrote:
> Hi,
>
> I am sending a patch which solves the debugging issue (PR 54218).
>
> The fix is to allocate stack space only once for parameters in expand pass.
>
> The patch is attached. Could someone suggest if its right ?
I have just a formattin
Hi,
I am sending a patch which solves the debugging issue (PR 54218).
The fix is to allocate stack space only once for parameters in expand pass.
The patch is attached. Could someone suggest if its right ?
Thanks,
George
54218.patch
Description: Binary data
On Thu, Jan 10, 2013 at 11:00 PM, Dave Johansen wrote:
> 2013-01-10 Dave Johansen
>
> * gcc/doc/plugins.texi: Added gcc.4.5.0 or later note to
> Plugins documentation.
OK.
Diego.
On 01/11/2013 05:38 AM, Dodji Seketeli wrote:
but when I read the code, it looks like this is not necessary. Am I
missing something? In any case, I haven't put that code in the new
coerce_innermost_template_parms. Is that OK?
I agree that it seems unnecessary. But to be safe, let's leave
l
On Fri, Jan 11, 2013 at 4:16 AM, Georg-Johann Lay wrote:
>>
>> * fixed-bit.c (SATFRACT) : Only
>> declare / set min_low, min_high if TO_MODE_UNSIGNED == 0.
>> (SATFRACT) : Only declare / set min_low,
>> min_high if FROM_MODE_UNSIGNED == 0 and TO_MODE_UNSIGNED == 0.
This is
On Wed, Dec 12, 2012 at 6:21 AM, H.J. Lu wrote:
> On Thu, Nov 29, 2012 at 9:38 AM, H.J. Lu wrote:
>> Hi,
>>
>> When GCC is configured with --with-build-config="bootstrap-asan", all
>> -flto tests will fail since -fsanitize=address is used to compile
>> liblto_plugin.so and linker isn't compiled w
On Wed, Dec 12, 2012 at 6:20 AM, H.J. Lu wrote:
> On Thu, Nov 29, 2012 at 9:40 AM, H.J. Lu wrote:
>> Hi,
>>
>> When GCC is configured with --with-build-config="bootstrap-asan", all
>> -flto tests will fail since -fsanitize=address is used to compile host
>> libiberty, which is used to create libl
For PHIs we call walk_tree with a function that expects to be
called from walk_gimple_op ...
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2013-01-11 Richard Biener
* tree-cfg.c (verify_node_sharing_1): Split out from ...
(verify_node_sharing): ... h
On Sat, Dec 8, 2012 at 9:13 AM, H.J. Lu wrote:
> On Thu, Nov 22, 2012 at 6:45 AM, H.J. Lu wrote:
>> Hi,
>>
>> libasan should come first before any language-specific
>> adjustment/addition. Otherwise, we got
>>
>> g++ -fsanitize=address -static-libasan ...
>>
>> /usr/local/bin/ld: error:
>> /expo
On Fri, 11 Jan 2013, Andreas Schwab wrote:
> Jakub Jelinek writes:
>
> > + __asm ("" : "=r" (cf) : "0" (ucf1.ll));
>
> gcc/testsuite/gcc.c-torture/compile/pr55921.c:17:3: error: 'asm' operand has
> impossible constraints
> gcc/testsuite/gcc.c-torture/compile/pr55921.c:19:3: error: 'asm' opera
Hi!
I committed this patch:
2013-01-11 Jan-Benedict Glaw
* config.sub: Update from config repo.
Index: config.sub
===
--- config.sub (revision 195104)
+++ config.sub (working copy)
@@ -4,7 +4,7 @@
# 2000, 2001, 2002
Jakub Jelinek writes:
> + __asm ("" : "=r" (cf) : "0" (ucf1.ll));
gcc/testsuite/gcc.c-torture/compile/pr55921.c:17:3: error: 'asm' operand has
impossible constraints
gcc/testsuite/gcc.c-torture/compile/pr55921.c:19:3: error: 'asm' operand has
impossible constraints
OK? This still triggers t
Kirill,
Could you commit patch?
2013-01-11 Vladimir Yakovlev
* config/i386/i386-c.c (ix86_target_macros_internal): New case.
(ix86_target_macros_internal): Likewise.
* config/i386/i386.c (m_CORE2I7): Removed.
(m_CORE_HASWELL): New macro.
(m_CORE_ALL):
On Fri, Jan 11, 2013 at 1:14 PM, Vladimir Yakovlev wrote:
> I sent the patch. Send it once more.
>
> 2013/1/11 Jakub Jelinek :
>> On Fri, Jan 11, 2013 at 03:25:47PM +0400, Vladimir Yakovlev wrote:
>>> I've fixed Changelog. Can we commit the patch to trunk now?
>>>
>>> 2012-12-27 Vladimir Yakovlev
Georg-Johann Lay wrote:
> Variables min_high and min_low are set but not used which cases build
> warnings,
> fixed by this patch.
Better attach the patch...
> Build fine for i686-pc-linux-gnu and avr-unknown-none, the latter definitely
> using this code.
>
> Ok for trunk?
>
> Johann
>
>
>
I sent the patch. Send it once more.
2013/1/11 Jakub Jelinek :
> On Fri, Jan 11, 2013 at 03:25:47PM +0400, Vladimir Yakovlev wrote:
>> I've fixed Changelog. Can we commit the patch to trunk now?
>>
>> 2012-12-27 Vladimir Yakovlev
>>
>> * config/i386/i386-c.c (ix86_target_macros_internal):
Jakub Jelinek writes:
> On Fri, Jan 11, 2013 at 11:41:34AM +0100, Dodji Seketeli wrote:
>> Gabriel Dos Reis writes:
>>
>> > On Thu, Jan 10, 2013 at 9:22 AM, Dodji Seketeli wrote:
>> >>
>> >> Also, I am not sure if this patch would be appropriate for commit, now
>> >> that we are in 'regression
On Fri, Jan 11, 2013 at 03:25:47PM +0400, Vladimir Yakovlev wrote:
> I've fixed Changelog. Can we commit the patch to trunk now?
>
> 2012-12-27 Vladimir Yakovlev
>
> * config/i386/i386-c.c (ix86_target_macros_internal): New case.
> (ix86_target_macros_internal): Likewise.
>
>
I've fixed Changelog. Can we commit the patch to trunk now?
2012-12-27 Vladimir Yakovlev
* config/i386/i386-c.c (ix86_target_macros_internal): New case.
(ix86_target_macros_internal): Likewise.
* config/i386/i386.c (m_CORE2I7): Removed.
(m_CORE_HASWELL): New ma
On 11/01/13 12:02, Greta Yorsh wrote:
> Tom, are you going to apply this patch?
Greta,
While testing I've ran into several issues with timeouts (not related to this
patch) that I needed to address, so it took me a bit, but I started the latest
build & test run yesterday evening so I expect to ch
On Fri, 11 Jan 2013, Jakub Jelinek wrote:
> On Fri, Jan 11, 2013 at 12:06:04PM +0100, Richard Biener wrote:
> >
> > VRP no longer (since 4.1.2 at least) can optimize vrp06.c in one go
> > because we happen to chose a symbolic range when
>
> Just FYI, GCC never optimized that apparently, at least
On Thu, 10 Jan 2013, Manuel López-Ibáñez wrote:
> I haven't heard any complaints about the caret diagnostics being
> enabled by default, so I am tempted to think it will stay like it is
> for GCC 4.8. This patch documents that and also the new -Wpedantic.
> OK?
Nice!
+By default, each diagnos
On Fri, Jan 11, 2013 at 12:06:04PM +0100, Richard Biener wrote:
>
> VRP no longer (since 4.1.2 at least) can optimize vrp06.c in one go
> because we happen to chose a symbolic range when
Just FYI, GCC never optimized that apparently, at least in r10
(vrp06.c has been added in r100478) vrp did
VRP no longer (since 4.1.2 at least) can optimize vrp06.c in one go
because we happen to chose a symbolic range when
Intersecting
[j_12(D), j_12(D)] EQUIVALENCES: { i_9(D) j_12(D) i_24 i_26 } (4
elements)
and
[10, 30] EQUIVALENCES: { i_9(D) i_26 } (2 elements)
to
[j_12(D), j_12(D)] EQUI
Tom, are you going to apply this patch?
There are similar failures on arm-none-eabi after r195008:
FAIL: gcc.dg/torture/pr55890-3.c -O0 (internal compiler error)
FAIL: gcc.dg/torture/pr55890-3.c -O0 (test for excess errors)
FAIL: gcc.dg/torture/pr55890-3.c -O1 (internal compiler error)
FAIL: gcc
On Fri, Jan 11, 2013 at 11:41:34AM +0100, Dodji Seketeli wrote:
> Gabriel Dos Reis writes:
>
> > On Thu, Jan 10, 2013 at 9:22 AM, Dodji Seketeli wrote:
> >>
> >> Also, I am not sure if this patch would be appropriate for commit, now
> >> that we are in 'regression-only' mode. But seeing this al
Gabriel Dos Reis writes:
> On Thu, Jan 10, 2013 at 9:22 AM, Dodji Seketeli wrote:
>>
>> Also, I am not sure if this patch would be appropriate for commit, now
>> that we are in 'regression-only' mode. But seeing this alias-template
>> related thing not working hurts me. :) So at worst I'll sc
Gabriel Dos Reis writes:
> On Thu, Jan 10, 2013 at 9:22 AM, Dodji Seketeli wrote:
>
>> But during the instantiation of the *members* of test, we try to
>> instantiate Alias>, without coercing (and thus without
>> folding) the argument {the_truth}. We do this using
>> instantiate_alias_template,
On Fri, Jan 11, 2013 at 10:08 AM, Eric Botcazou wrote:
> Hi,
>
> the Ada part of the Ada front-end is compiled with -gnata, which boils down to
> a form of dynamic type checking for the AST, i.e. something roughly equivalent
> to Tree checking for the front-ends of the C family of compilers. This
On Thu, 10 Jan 2013, Eric Botcazou wrote:
> > The problem with this intermediate inconsistency is that ...
> >
> > > That's why only the final result should matter and need be correct.
> >
> > ... this can't be ensured anymore. In some cases the inconsistency
> > between the mem attributes and
Variables min_high and min_low are set but not used which cases build warnings,
fixed by this patch.
Build fine for i686-pc-linux-gnu and avr-unknown-none, the latter definitely
using this code.
Ok for trunk?
Johann
* fixed-bit.c (SATFRACT) : Only
declare / set min_low, min_hig
This fixes PR44061 by computing a false range for __builtin_constant_p
of parameters in VRP.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2012-01-11 Richard Guenther
PR tree-optimization/44061
* tree-vrp.c (extract_range_basic): Compute zer
"Maciej W. Rozycki" writes:
> And in any case I insist that the instructions are correctly marked in
> the opcode table.
I agree that it would be better to exclude the unimplemented instructions.
Jürgen: if you're happy to submit a patch along those lines, I promise
to review it.
BTW Maciej, s
Hi,
The patch is to adjust ARM uclinux libgcc config order of arm/t-bpabi and t-
arm since LIB1ASMFUNCS defined in t-bpabi is overridden in t-arm.
Is it OK for trunk, 4.8 and 4.7?
Thanks!
-Zhenqiang
2012-03-11 Zhenqiang Chen
* config.host (arm*-*-uclinux*): Move arm/t-arm before arm/
Hi,
the Ada part of the Ada front-end is compiled with -gnata, which boils down to
a form of dynamic type checking for the AST, i.e. something roughly equivalent
to Tree checking for the front-ends of the C family of compilers. This patch
aligns the Ada compiler with them by disabling it in --
Thank you Dave for this documentation patch that looks OK to my casual
eyes. Let's CC the documentation maintainers.
Dave Johansen a écrit:
> Currently, the plugin documentation doesn't mention that it requires
> gcc 4.5 or later. The patch to add this statement is attached and
> here's the Cha
51 matches
Mail list logo
