On Tue, 20 Mar 2012, Tristan Gingold wrote:
>
> On Mar 20, 2012, at 5:01 PM, Richard Guenther wrote:
>
> > On Tue, 20 Mar 2012, Tristan Gingold wrote:
> >
> >>
> >> On Mar 20, 2012, at 3:19 PM, Richard Guenther wrote:
> >>
> >> [...]
> >>>
> >>> I'd rather get away from using a global main_i
On Tue, 20 Mar 2012, Martin Jambor wrote:
> Hi,
>
> On Tue, Mar 20, 2012 at 04:08:31PM +0100, Richard Guenther wrote:
> > On Tue, 20 Mar 2012, Martin Jambor wrote:
> >
> > > Hi,
> > >
> > > this patch which removes one of only two FIXMEs in tree-sra.c has been
> > > sitting in my patch queue fo
This fixes PR52636 now that we treat all constants as constants
we need to convert them to the appropriate vector type.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2012-03-20 Richard Guenther
PR tree-optimizer/52636
* tree-vect-slp.c (vect_get_cons
On Mar 20, 2012, at 6:17 PM, Jan Hubicka wrote:
>> On Tue, 20 Mar 2012, Tristan Gingold wrote:
>>
>>>
>>> On Mar 15, 2012, at 10:37 AM, Richard Guenther wrote:
>>>
On Wed, 14 Mar 2012, Tristan Gingold wrote:
>>> [?]
>>>
Well. To make this work in LTO the "main" function (thus
Hi,
This patch (for 4.6) fixes a wrong subword index computation in
store_bit_field_1 for big endian targets when value is at least 4 times
bigger than a word (DI REG value with HI words).
It fixes a regression on gcc.c-torture/execute/bitfld-3.c for my current
backend port.
http://gcc.gnu.org/b
On Mon, Mar 19, 2012 at 2:19 AM, Andrew Pinski wrote:
> On Sun, Mar 18, 2012 at 6:12 PM, William J. Schmidt
> wrote:
>> Greetings,
>>
>> Now that we're into stage 1 again, I'd like to submit the first round of
>> changes for dominator-based strength reduction, which will address
>> issues from PR
On Thu, Mar 15, 2012 at 3:45 PM, Kai Tietz wrote:
> 2012/3/15 Richard Guenther :
>> On Thu, Mar 15, 2012 at 2:46 PM, Kai Tietz wrote:
>>> 2012/3/15 Richard Guenther :
On Thu, Mar 15, 2012 at 2:09 PM, Kai Tietz wrote:
> Hi,
>
> this is the second part of the patch for this proble
2012/3/21 Richard Guenther :
> On Thu, Mar 15, 2012 at 3:45 PM, Kai Tietz wrote:
>> 2012/3/15 Richard Guenther :
>>> On Thu, Mar 15, 2012 at 2:46 PM, Kai Tietz wrote:
2012/3/15 Richard Guenther :
> On Thu, Mar 15, 2012 at 2:09 PM, Kai Tietz
> wrote:
>> Hi,
>>
>> this is
On Wed, Mar 21, 2012 at 10:56 AM, Kai Tietz wrote:
> 2012/3/21 Richard Guenther :
>> On Thu, Mar 15, 2012 at 3:45 PM, Kai Tietz wrote:
>>> 2012/3/15 Richard Guenther :
On Thu, Mar 15, 2012 at 2:46 PM, Kai Tietz wrote:
> 2012/3/15 Richard Guenther :
>> On Thu, Mar 15, 2012 at 2:09 PM
Hi,
On Tue, Mar 20, 2012 at 08:16:04PM +0100, Georg-Johann Lay wrote:
> Martin Jambor wrote:
> > Hi,
> >
> > this is another iteration of my attempts to fix expansion of
> > misaligned memory accesses on strict-alignment platforms (which was
> > suggested by Richi in
> > http://gcc.gnu.org/ml/gcc
On 19/03/12 14:48, Richard Earnshaw wrote:
OK.
Committed.
Andrew
Semantically the neon intrinsic vgetq_lane_[su]64 returns a 64 bit
sub-object of a 128-bit vector; there's no real need for the intrinsic
to map onto a specific machine instruction.
Indeed, if force a particular instruction that moves the result into a
core register, but then want to use the resul
On Wed, Mar 21, 2012 at 12:04:18AM -0400, Jason Merrill wrote:
> This also seems like it might be a candidate for 4.7.0. What do you
> think, Jakub?
Ok for 4.7.0.
Jakub
> -Original Message-
> From: Georg-Johann Lay
> Sent: Tuesday, March 20, 2012 1:56 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Denis Chertykov; Weddington, Eric
> Subject: Re: [Patch,AVR]: Hack around PR rtl-optimization/52543, Take
#2
>
> And here is the patch...
>
> Georg-Johann Lay wrote
On 03/21/2012 09:06 AM, Richard Guenther wrote:
2012-03-20 Richard Guenther
PR tree-optimizer/52636
Typo ;)
Paolo.
Martin Jambor wrote:
> Hi,
>
> On Tue, Mar 20, 2012 at 08:16:04PM +0100, Georg-Johann Lay wrote:
>> Martin Jambor wrote:
>>> Hi,
>>>
>>> this is another iteration of my attempts to fix expansion of
>>> misaligned memory accesses on strict-alignment platforms (which was
>>> suggested by Richi in
>>
Mike Stump writes:
> diff --git a/gcc/doc/rtl.texi b/gcc/doc/rtl.texi
> index de45a22..0c6dc45 100644
> --- a/gcc/doc/rtl.texi
> +++ b/gcc/doc/rtl.texi
> @@ -1530,7 +1530,9 @@ Represents either a floating-point constant of mode
> @var{m} or an
> integer constant too large to fit into @code{HOST_
On Wed, 2012-03-21 at 10:33 +0100, Richard Guenther wrote:
> On Mon, Mar 19, 2012 at 2:19 AM, Andrew Pinski wrote:
> > On Sun, Mar 18, 2012 at 6:12 PM, William J. Schmidt
> > wrote:
> >> Greetings,
> >>
> >> Now that we're into stage 1 again, I'd like to submit the first round of
> >> changes for
Hi,
On Tue, 20 Mar 2012, Mike Stump wrote:
> > Actually you did. I've tried yesterday to come up with a text that
> > would do the same (because I agree with you that deleting the assert
> > changes the spec of the function,
>
> The spec of the function is the text above the definition of the
On Wed, 21 Mar 2012, William J. Schmidt wrote:
> On Wed, 2012-03-21 at 10:33 +0100, Richard Guenther wrote:
> > On Mon, Mar 19, 2012 at 2:19 AM, Andrew Pinski wrote:
> > > On Sun, Mar 18, 2012 at 6:12 PM, William J. Schmidt
> > > wrote:
> > >> Greetings,
> > >>
> > >> Now that we're into stage 1
On 21/03/12 13:40, William J. Schmidt wrote:
> On Wed, 2012-03-21 at 10:33 +0100, Richard Guenther wrote:
>> On Mon, Mar 19, 2012 at 2:19 AM, Andrew Pinski wrote:
>>> On Sun, Mar 18, 2012 at 6:12 PM, William J. Schmidt
>>> wrote:
Greetings,
Now that we're into stage 1 again, I'd li
Steven Bosscher wrote:
> On Tue, Mar 20, 2012 at 8:54 PM, Georg-Johann Lay wrote:
>> Dropping the first patch which does not work because at expand-time there
>> must not be pre-/post-modify addressing :-(
>
> Have you tried to fix that, instead? Or at least ask around a bit to
> see what people
On Wed, 2012-03-21 at 13:57 +, Richard Earnshaw wrote:
> On 21/03/12 13:40, William J. Schmidt wrote:
> >
> > And it becomes even more difficult with more complex scenarios.
> > Consider:
> >
> > a = x + (3 * s);
> > b = x + (5 * s);
> > c = x + (7 * s);
> >
> > The framework I've developed
Hi!
On Thu, 15 Mar 2012 11:57:00 -0400, Carlos O'Donell
wrote:
> On Thu, Mar 15, 2012 at 11:05 AM, Thomas Schwinge
> wrote:
> > On 26 Feb 2012 18:17:52 -, drep...@sourceware.org wrote:
> >> http://sources.redhat.com/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=4efeffc1d583597e4f52985b9747269e4
Hi,
I need to use do_while_loop_p, but I'm not sure its functionality is what
I expected it to be.
This is the part that I do not understand:
/* If the header contains just a condition, it is not a do-while loop. */
stmt = last_and_only_stmt (loop->header);
if (stmt
&& gimple_code (st
As reported in PR other/52626, make check in fixincludes is currently
failing since I neglected to adapt the baseline for the Solaris 8
removal ;-( I always meant to run make check, but forgot.
On the other hand, it would be really helpful if fixincludes make check
could emit DejaGnu-style fixinc
On Mar 21, 2012, at 6:47 AM, Michael Matz wrote:
> Actually, I wouldn't.
Ok, thanks for explaining. In light of that, I'd just say, I want to change
the spec, the details don't change any for me, only the terminology I might
use. The problem is the spec is causing aborts on valid code, and hen
Another latent issue exposed on IA-64 (both Linux and VMS) by GCC 4.7: the LC
(Loop Counter) register isn't preserved by the unwinder.
The compiler generates unwind info for LC and unwind-ia64.c:uw_install_context
restores it if this is deemed necessary. The hitch is that "deemed necessary"
me
Hi Rainer,
On Wed, Mar 21, 2012 at 9:25 AM, Rainer Orth
wrote:
> As reported in PR other/52626, make check in fixincludes is currently
> failing since I neglected to adapt the baseline for the Solaris 8
> removal ;-( I always meant to run make check, but forgot.
>
> On the other hand, it would b
Fix x1mbstate_t.h.
This patch fixes the parser segmentation fault caused by a name
lookup failure (details in
http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01369.html).
I am not 100% sure that this is the right fix, but Jason seems to
think that the theory behind this is fine (parser does no allow
in tree-mudflap.c to change usage of fold_conver to build_int_cst
http://gcc.gnu.org/wiki/Partial_Transitions. I am not 100% sure this is correct
but maybe someone can shed some light.
---
gcc/tree-mudflap.c | 38 --
1 files changed, 20 insertions(+), 18 de
On 03/21/2012 01:35 PM, Aldy Hernandez wrote:
In the test below, we cannot cache either [x] or [y] neither before
the load of flag1 nor the load of flag2. This is because the
corresponding store/release can flush a different value of x or y:
+ if (__atomic_load_n (&flag1, __ATOMIC_ACQUIRE))
On 03/21/2012 01:35 PM, Aldy Hernandez wrote:
The pass at fault here is the combine stack adjustment RTL pass. I
have not looked into why this is happening, but I wanted to get this
test into the branch lest we forget about it.
Is this OK for the branch? Is my understanding correct?
Fine
Hi,
I am bumping up the default param value of function size limit for
auto cloning. Since auto cloning happens on inlined functions, the
original value does not catch some cases in one of our benchmarks.
Automatic function versioning is only available in the
google/gcc-4_6 branch. I am work
In the test below, we cannot cache either [x] or [y] neither before the
load of flag1 nor the load of flag2. This is because the corresponding
store/release can flush a different value of x or y:
+ if (__atomic_load_n (&flag1, __ATOMIC_ACQUIRE))
+i = x + y;
+
+ if (__atomic_load_n (&flag
ok.
thanks,
David
On Wed, Mar 21, 2012 at 11:20 AM, Sriraman Tallam wrote:
> Hi,
>
> I am bumping up the default param value of function size limit for
> auto cloning. Since auto cloning happens on inlined functions, the
> original value does not catch some cases in one of our benchmarks.
>
>
Hello!
Attached patch enables alpha to use generic config/elfos.h headers on
linux and *bsd targets. The most important difference to generic
elfos.h is in
* config/alpha/elf.h (TARGET_ASM_FILE_START_FILE_DIRECTIVE): Undefine.
and
* config/alpha/alpha.h (NO_DOLLAR_IN_LABEL): Und
Hello,
The test case for this bug triggeres O(extern_delcs**2) behavior
because value_member traverses the pending_assemble_externals list
from start to end for every new extern decl.
The solution I've picked, is to add a pointer set, and while there I
made pending_assemble_externals a VEC instea
On 02.03.12 17:28, David Edelsohn wrote:
On Fri, Mar 2, 2012 at 11:04 AM, Andreas Tobler wrote:
the attached patch adds support for powerpc64-*-freebsd*.
Results are/were sent to the test results list.
A few words about the patch.
I have chosen the way to add separate freebsd* files because F
Richard Guenther writes:
> This patch makes us preserve loop structures from the start of tree
> loop optimizers to the end of RTL loop optimizers. It uses a new
> property, PROP_loops to indicate we want to preserve them and
> massages loop_optimizer_init/finalize to honor that.
>
> On the RTL s
On 3/21/12 3:30 PM, Steven Bosscher wrote:
+/* FIXME: Trunk is at GCC 4.8 now and the above problem still hasn't been
+ addressed properly. This caused PR 52640 due to O(external_decls**2)
+ lookups in the pending_assemble_externals queue in assemble_external.
+ Paper over with this point
Hello,
There is no reason for the ObjC front end to call assemble_external on
these symbols, the middle-end handles this just fine via
add_builtin_function.
Bootstrapped&tested on powerpc64-unknown-linux-gnu. OK for trunk?
Ciao!
Steven
objc/
* objc-act (objc_build_ivar_assignment): Do n
Hi Steven,
On 21 Mar 2012, at 21:09, Steven Bosscher wrote:
There is no reason for the ObjC front end to call assemble_external on
these symbols, the middle-end handles this just fine via
add_builtin_function.
Ah, that's the bit I'd yet to figure out ...
Bootstrapped&tested on powerpc64-unkn
On Wed, Mar 21, 2012 at 10:23 PM, Iain Sandoe
wrote:
>> objc/
>> * objc-act (objc_build_ivar_assignment): Do not call
>> assemble_external.
>> (objc_build_global_assignment): Likewise.
>> (objc_build_strong_cast_assignment): Likewise.
>> * objc-next-runtime-abi-01.c: Cl
On Mar 21, 2012, at 6:17 AM, Richard Sandiford wrote:
> Sounds good.
Cool, a path forward.
> For this I think we should make plus_constant a wrapper:
Ah, yes, much better, thanks. I'd expanded the comments on plus_constant_mode
so that one might have a better idea why the code is that way and
PING
On Wed, Mar 14, 2012 at 01:03, Janne Blomqvist
wrote:
> Hi,
>
> the attached patch implements a few fixes and cleanups for the MOD and
> MODULO intrinsics.
>
> - When the arguments are constant, use mpfr_fmod instead of the naive
> algorithms which are numerically unstable for large argument
2012-03-21 Harshit Chopra
Minor changes:
i386.c: made check_should_patch_current_function C90 compatible.
i386.md: Added '\t' to bytes generated by
ix86_output_function_nops_prologue_epilogue for proper formatting
of assembly.
patch-functions-*.c: Fixed
On Mar 21, 2012, at 10:16 AM, Bruce Korb wrote:
> Patch welcome! I, myself, don't know what "emit DejaGnu-style
> fixincludes.{sum, log} files" would mean.
Rather simple... In a file called fixinclude.sum, put
PASS: unique string
or
FAIL: unique string
one per line, as many times as you
On Mar 21, 2012, at 2:46 PM, Mike Stump wrote:
> echo "# of expected failures$(cat $file | grep 'FAIL:' | wc -l)"
Oh, and if you expect perfection, you should use:
echo "# of unexpected failures$(cat $file | grep 'FAIL:' | wc -l)"
instead.
> This patch (for 4.6) fixes a wrong subword index computation in
> store_bit_field_1 for big endian targets when value is at least 4 times
> bigger than a word (DI REG value with HI words).
>
> It fixes a regression on gcc.c-torture/execute/bitfld-3.c for my current
> backend port.
>
> http://gcc.
On Mar 21, 2012, at 2:09 PM, Steven Bosscher wrote:
> There is no reason for the ObjC front end to call assemble_external on
> these symbols,
> OK for trunk?
Ok. Watch for hate mail from Jack, if you guess wrong. :-)
On Mar 21, 2012, at 2:32 PM, Steven Bosscher wrote:
> In any case, if there's nothing left to fix for PR24777, I suppose it
> can be closed as FIXED.
I see all sorts of FIXME: in c-decl.c still... Anyway, someone needs to sort
out what is done and remains undone and update the FIXMEs... I don't
On 03/21/12 12:28, Uros Bizjak wrote:
> Hello!
>
> Attached patch enables alpha to use generic config/elfos.h headers on
> linux and *bsd targets. The most important difference to generic
> elfos.h is in
>
> * config/alpha/elf.h (TARGET_ASM_FILE_START_FILE_DIRECTIVE): Undefine.
This one ca
On Wed, Mar 21, 2012 at 11:11 PM, Mike Stump wrote:
> On Mar 21, 2012, at 2:32 PM, Steven Bosscher wrote:
>> In any case, if there's nothing left to fix for PR24777, I suppose it
>> can be closed as FIXED.
>
> I see all sorts of FIXME: in c-decl.c still... Anyway, someone needs to sort
> out wha
On Wed, Mar 21, 2012 at 1:13 AM, Ian Lance Taylor wrote:
> On Tue, Mar 20, 2012 at 2:06 PM, Steven Bosscher wrote:
>>
>> This patch splits a couple of pieces of cse_insn out to new functions.
>> There are no functional changes, and no code generation differences as
>> far as I could tell on x86_64
On Thu, Mar 22, 2012 at 12:09 AM, Steven Bosscher wrote:
> (cse_find_path): Micro-optimization, reorder one condition to
> avoid a reference to cfun.
Ah, and please ignore this bit. I don't know what I was thinking...
On 21 Mar 2012, at 22:45, Steven Bosscher wrote:
On Wed, Mar 21, 2012 at 11:11 PM, Mike Stump
wrote:
On Mar 21, 2012, at 2:32 PM, Steven Bosscher wrote:
In any case, if there's nothing left to fix for PR24777, I suppose
it
can be closed as FIXED.
I see all sorts of FIXME: in c-decl.c st
On Thu, Mar 22, 2012 at 12:53 AM, Iain Sandoe
wrote:
> conceptually, the issue is that there are multiple sets of built-ins
> (potentially, one set for each runtime, and the sets are of different
> sizes). Thus, it's not just a case of turning these into regular built-ins,
> without some mechani
On 22 Mar 2012, at 00:00, Steven Bosscher wrote:
On Thu, Mar 22, 2012 at 12:53 AM, Iain Sandoe
wrote:
conceptually, the issue is that there are multiple sets of built-ins
(potentially, one set for each runtime, and the sets are of different
sizes). Thus, it's not just a case of turning thes
Hi,
this diagnostic issue is about not even trying to print expressions in
error messages involving operators, and print operand types instead.
Just as an example, for:
struct X { int x; };
void trigger (X x []) { x [01] = 0; }
we currently print:
error: no match for ‘operator=’ in ‘*(x + 4
Committed to google/gcc-4_6 after validation.
On 2012/03/21 05:07:33, davidxl wrote:
ok for google branches after checkin validation.
David
http://codereview.appspot.com/5851044/
Hi,
This patch is to XFAIL scev-3.c and scev-5.c.
The bug is going to be fixed after Richard Guenther fix a serials of
problems related to POINTER_PLUS_EXPR and sizetype precision.
Thanks,
-Jiangning
ChangeLog for testsuite:
2012-03-21 Jiangning Liu
PR tree-optimization/52563
Submitted to google/gcc-4_6.
Thanks,
-Sri.
On Wed, Mar 21, 2012 at 11:38 AM, Xinliang David Li wrote:
> ok.
>
> thanks,
>
> David
>
> On Wed, Mar 21, 2012 at 11:20 AM, Sriraman Tallam wrote:
>> Hi,
>>
>> I am bumping up the default param value of function size limit for
>> auto cloning. Since
On Wed, Mar 21, 2012 at 7:22 PM, Paolo Carlini wrote:
> Hi,
>
> this diagnostic issue is about not even trying to print expressions in error
> messages involving operators, and print operand types instead. Just as an
> example, for:
>
> struct X { int x; };
> void trigger (X x []) { x [01] = 0; }
I committed this patch to add some notes about Go to
gcc-4.7/changes.html on the web site.
Ian
Index: gcc-4.7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
retrieving revision 1.100
diff -u -r1.100 changes
65 matches
Mail list logo
