In this bug, the underlying problem was that we had a COMPLEX_EXPR
representing a complex constant rather than a COMPLEX_CST. There was
also the issue that 4.5 didn't deal with this very well, but fixing the
testcase to use COMPLEX_CST (by folding the COMPLEX_EXPR case like we do
everything el
On Apr 19, 2011, at 2:59 PM, Kaz Kojima wrote:
> gcc.dg/torture/pr37868.c fails on SH because of unaligned accesses.
> The patch below skips the test as is done for sparc targets.
I'd pre-approve hoisting these up into the lib/.exp files and checking a
generic target requirement... :-)
> -/* {
On Apr 19, 2011, at 10:29 AM, Georg-Johann Lay wrote:
> Thanks for that hint. There are some more test cases that imply int >=
> 32 bit
>
> Johann
>
> 2011-04-19 Georg-Johann Lay
>
> * gcc.dg/pr42629.c: Add dg-require-effective-target int32plus
> * gcc.c-torture/execute/cmpsi-2.c:
On Apr 19, 2011, at 11:12 AM, Rainer Orth wrote:
> I've had a closer look now and think it's possible (and desirable) to
> define HAVE_GAS_HIDDEN for Darwin, too.
But, they don't have the same thing, therefore, either, you loose out on the
meaning, or, you must have yet another test that means th
Committed the following after regression testing. i will update the test case
when I get the chance.
Jerry
Author: jvdelisle
Date: Wed Apr 20 04:18:25 2011
New Revision: 172753
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172753
Log:
2011-04-19 Jerry DeLisle
PR libgfortran/486
Hi,
while cleaning up the way small functions inliner populate the heap I made
simple
thinko trying to compute summary information used for badness and the badness
values themselves in one loop. Since only FDO badness computation depends on
summaries
this has passed my non-FDO testing.
profileb
Hi,
This patch allows variables whose type transitively contains a union to share
stack slots if -fno-strict-aliasing is used.
Bootstraps on x86_64 with no test regressions. Also tested by changing
flag_strict_aliasing to 0 by default. Bootstraps and no test regressions when
compared to flag
> On Tue, Apr 19, 2011 at 4:49 PM, Jan Hubicka wrote:
> >> Actually, among all the choices, funcdef_no is probably the most dense
> >> one -- it is for function decl with definition only. In LIPO, the
> >
> > Yes, funddef_no is densiest, but we don't really need great density here
> > (in many ot
On Tue, Apr 19, 2011 at 12:19 PM, Diego Novillo wrote:
> On Tue, Apr 19, 2011 at 15:02, Easwaran Raman wrote:
>> This makes the gcc driver pass the --save-temps option to the assembler or
>> assembler wrapper so that post-assembly tools like MAO can be integrated.
>> Bootstraps on x86_64. Ok fo
duplicate_decls was dropping DECL_DISREGARD_INLINE_LIMITS, but leaving
the always_inline attribute in DECL_ATTRIBUTES, leading to confusion.
This patch keeps them in sync.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.5 (not 4.6).
commit 679e5e90918506d6792b8c0b19deff0f1a497298
Author: Ja
On Tue, Apr 19, 2011 at 4:49 PM, Jan Hubicka wrote:
>> Actually, among all the choices, funcdef_no is probably the most dense
>> one -- it is for function decl with definition only. In LIPO, the
>
> Yes, funddef_no is densiest, but we don't really need great density here
> (in many other places w
> Actually, among all the choices, funcdef_no is probably the most dense
> one -- it is for function decl with definition only. In LIPO, the
Yes, funddef_no is densiest, but we don't really need great density here
(in many other places we index arrays by cgraph_uid - it is intended for
that purpo
On Tue, Apr 19, 2011 at 4:30 PM, Jan Hubicka wrote:
>> On Tue, Apr 19, 2011 at 3:57 PM, Jan Hubicka wrote:
>> >> So between hashtab and VEC, which one do you prefer? Either one is fine
>> >> with me.
>> >
>> > I would go with VEC. While the array will have holes, there are not many
>> > since
> On Tue, Apr 19, 2011 at 3:57 PM, Jan Hubicka wrote:
> >> So between hashtab and VEC, which one do you prefer? Either one is fine
> >> with me.
> >
> > I would go with VEC. While the array will have holes, there are not many
> > since
> > the ids are originally assigned sequentially.
> >
> > A
This patch to the Go frontend adjusts statement.cc so that it no longer
includes any gcc headers. All operations are now done via the backend
interface. There are four remaining files which includes gcc header
files: export.cc, expressions.cc, gogo-tree.c, and types.cc. This patch
bootstrapped a
On Tue, Apr 19, 2011 at 3:57 PM, Jan Hubicka wrote:
>> So between hashtab and VEC, which one do you prefer? Either one is fine with
>> me.
>
> I would go with VEC. While the array will have holes, there are not many
> since
> the ids are originally assigned sequentially.
>
> Actually given that
On 04/19/2011 12:07 AM, Jakub Jelinek wrote:
On Mon, Apr 18, 2011 at 03:33:18PM -0700, Jason Merrill wrote:
Well, it means that we do dynamic adjustment at runtime. If we're
able to do devirtualization, we should be able to figure out the
right offset as well, just not in 4.6.
Sure, but how
> So between hashtab and VEC, which one do you prefer? Either one is fine with
> me.
I would go with VEC. While the array will have holes, there are not many since
the ids are originally assigned sequentially.
Actually given that we do IPA pass now, I think you can just remove cgraph->pid
field
> Hi,
>
> I have a backlog of random improvements to the WPA phase of LTO
> compilations, all with the common goal of reducing peak memory usage. I
> was basically dumping all trees that the WPA phase read in, and then tried
> to think about which trees can be merged with already existing ones
So between hashtab and VEC, which one do you prefer? Either one is fine with me.
Thanks,
David
On Tue, Apr 19, 2011 at 3:39 PM, Jan Hubicka wrote:
>>
>> Why is VEC any better in terms of density ? Are you suggesting using a
>> hash table?
> It is not any better, but we usually use VEC for varia
>
> Why is VEC any better in terms of density ? Are you suggesting using a
> hash table?
It is not any better, but we usually use VEC for variably sized arrays like
this one. Not that I would be big fan of its API, but at least it fives
bounds checking that would catch bugs like one you are fixin
Am 19.04.2011 20:17, schrieb Janne Blomqvist:
Now that Jim Meyering has remove the macro that prevented directly
calling free(), and replaced gfc_free() with free(), we can fix this.
Committed as obvious.
Thanks Janne. I had meant to do this, but hadn't gotten a round tuit.
Thomas
Hi,
this finishes the planned ipa-inline.c breakup. The transformation code
is actually quite self contained and separated from heuristics, so ipa-inline.c
now hopefully reads pretty well.
At the way I also revisited comments and dropped the cgraph_ prefixes, like
elsewhere.
Bootstrapped/regtest
All the statements have now been converted to use the backend interface.
This patch changes the Statement class to use the backend interface,
replacing the get_tree method with get_backend. This basically removes
a bunch of calls to a temporary helper function to convert from
Bstatement to tree.
On Tue, Apr 19, 2011 at 2:38 PM, Jan Hubicka wrote:
>> Hi, Insane value profile data may contain indirect call targets with
>> wrong (corrupted) pids. r172276 solves the problem when the pid
>> refers to a bogus target that is still 'alive'. This patch addresses
>> the issue when the bogus target
I can not review tree.c changes. I would probably suggest making crc_byte
inline.
> +#if IN_LIBGCOV
> +
> +/* These functions are guarded by #if to avoid compile time warning. */
> +
> +/* Return the number of words STRING would need including the length
> + field in the output stream itself.
On Tue, Apr 05, 2011 at 05:55:33PM +0200, Michael Matz wrote:
> I have a preference in having just one DECL_RTL field for conceptual
> reasons:
>
> Most DECLs are actually objects (there are some prominent exceptions, but
> those always would be better described with something like NAMED_ENTITY,
Hi,
gcc.dg/torture/pr37868.c fails on SH because of unaligned accesses.
The patch below skips the test as is done for sparc targets.
It's tested with bootstrap and regtest on i686-pc-linux-gnu.
Applied on trunk.
Regards,
kaz
--
2011-04-19 Kaz Kojima
PR testsuite/48676
This patch to the Go frontend uses the backend interface for temporary
variables. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
2011-04-19 Ian Lance Taylor
* go-gcc.cc (Gcc_backend::temporary_variable): New function.
Index: gcc/go/go-gc
> -Original Message-
> From: Georg-Johann Lay [mailto:a...@gjlay.de]
> Sent: Tuesday, April 19, 2011 2:13 PM
> To: Weddington, Eric
> Cc: Richard Henderson; gcc-patches@gcc.gnu.org; Denis Chertykov; Anatoly
> Sokolov
> Subject: Re: [Patch,AVR]: PR18145: do_copy_data & do_clear_bss only if
> Hi, Insane value profile data may contain indirect call targets with
> wrong (corrupted) pids. r172276 solves the problem when the pid
> refers to a bogus target that is still 'alive'. This patch addresses
> the issue when the bogus target is already eliminated or pid is too
> large.
>
> OK aft
On Tue, Apr 19, 2011 at 02:06:13PM -0700, Steve Kargl wrote:
> On Mon, Apr 18, 2011 at 05:54:28PM +0200, Rainer Orth wrote:
> > As already done for the g++.dg/guality driver, I'm also disabling the
> > remaining guality testsuites on Tru64 UNIX: the gcc.dg one doesn't even
> > start:
> >
> > gdb:
On Mon, Apr 18, 2011 at 05:54:28PM +0200, Rainer Orth wrote:
> As already done for the g++.dg/guality driver, I'm also disabling the
> remaining guality testsuites on Tru64 UNIX: the gcc.dg one doesn't even
> start:
>
> gdb: took too long to attach
>
> and the gfortran tests either fail or are un
> What do people think? (regstrapped with and without LTO bootstrap, the
> latter with all languages, the former without Ada, on x86_64-linux).
It would be nice to LTO bootstrap it with Ada as well because this involves
different kinds of type merging. You just need the one-liner at:
http://gc
Georg-Johann Lay schrieb:
When I wrote this patch I looked at the default linker script to see
what goes into .data resp .bss; the hard-coded section maned reflect
.names
that. For the linkonce stuff I found no explanation (grepping the we
The stage 1 work had broken m32c-elf. This at least fixes it so the
build works, along with a few performance tweaks I had sitting around
in my build. Applied.
2011-04-19 DJ Delorie
* config/m32c/m32c.c (m32c_emit_epilogue): Don't try to push
registers if we already know the
Weddington, Eric schrieb:
-Original Message-
From: Richard Henderson [mailto:r...@redhat.com]
Sent: Tuesday, April 19, 2011 1:31 PM
To: Georg-Johann Lay
Cc: gcc-patches@gcc.gnu.org; Weddington, Eric; Denis Chertykov; Anatoly
Sokolov
Subject: Re: [Patch,AVR]: PR18145: do_copy_data & do_c
Hi, Insane value profile data may contain indirect call targets with
wrong (corrupted) pids. r172276 solves the problem when the pid
refers to a bogus target that is still 'alive'. This patch addresses
the issue when the bogus target is already eliminated or pid is too
large.
OK after testing? (S
Hi,
I have a backlog of random improvements to the WPA phase of LTO
compilations, all with the common goal of reducing peak memory usage. I
was basically dumping all trees that the WPA phase read in, and then tried
to think about which trees can be merged with already existing ones very
early
The attached is the revised patch with a warning suggested for cases
when CFG matches, but source locations change.
Ok for trunk?
thanks,
David
On Sun, Apr 17, 2011 at 8:36 AM, Jan Hubicka wrote:
>> Hi, in current FDO implementation, the source file version used in
>> profile-generate needs t
> -Original Message-
> From: Richard Henderson [mailto:r...@redhat.com]
> Sent: Tuesday, April 19, 2011 1:31 PM
> To: Georg-Johann Lay
> Cc: gcc-patches@gcc.gnu.org; Weddington, Eric; Denis Chertykov; Anatoly
> Sokolov
> Subject: Re: [Patch,AVR]: PR18145: do_copy_data & do_clear_bss only
On Tue, Apr 19, 2011 at 12:19 PM, Diego Novillo wrote:
> On Tue, Apr 19, 2011 at 15:02, Easwaran Raman wrote:
>> This makes the gcc driver pass the --save-temps option to the assembler or
>> assembler wrapper so that post-assembly tools like MAO can be integrated.
>> Bootstraps on x86_64. Ok fo
On 04/18/2011 10:20 AM, Georg-Johann Lay wrote:
> +avr_asm_named_section (const char *name, unsigned int flags, tree decl)
> +{
> + if (!avr_need_copy_data_p)
> +avr_need_copy_data_p = ((0 == strncmp (name, ".data", 5)
> + || 0 == strncmp (name, ".rodata", 7)
> +
2011/4/19 Anatoly Sokolov :
>
>
>>>
>>> Please use
>>> ASM_OUTPUT_ALIGNED_DECL_COMMON and ASM_OUTPUT_ALIGNED_DECL_LOCAL macros
>>> here.
>>
>> Confused. These macros are used.
>>
>> Johann
>>
>
> Sorry... Im look on function name not on macro definition.
>
> I agree with the patch. Please wait day
On Tue, Apr 19, 2011 at 15:02, Easwaran Raman wrote:
> This makes the gcc driver pass the --save-temps option to the assembler or
> assembler wrapper so that post-assembly tools like MAO can be integrated.
> Bootstraps on x86_64. Ok for google/main?
>
> 2011-04-19 Easwaran Raman
>
> *
This makes the gcc driver pass the --save-temps option to the assembler or
assembler wrapper so that post-assembly tools like MAO can be integrated.
Bootstraps on x86_64. Ok for google/main?
2011-04-19 Easwaran Raman
* gcc/gcc.c (static const char *asm_options): Pass
--save-t
Please use
ASM_OUTPUT_ALIGNED_DECL_COMMON and ASM_OUTPUT_ALIGNED_DECL_LOCAL macros
here.
Confused. These macros are used.
Johann
Sorry... Im look on function name not on macro definition.
I agree with the patch. Please wait day or two if Denis would not object,
commit patch.
Anatoly.
On Tue, Apr 19, 2011 at 11:30 AM, Xinliang David Li wrote:
> Is change tested this with SPEC? 5 or 6 SPEC2k programs ICE with the
> following error when built with FDO.
>
> internal compiler error: in inline_small_functions, at ipa-inline.c:1361
> Please submit a full bug report,
> with prep
This patch fixes some test cases for PowerPC.
The tests pr39902-2.c, dfp-dd.c, and dfp-td.c reports as errors
when gcc is configured without dfp support. This patch will make the
tests to be reported as unsupported.
The test and-1.c has wrong logic.
In the formula:
y & ~(y & -y)
The part (y & -
Hello world,
this patch fixes the enhancement PR, plus probably a few regressions.
The basic problem was that the code walker got confused when *c, the
pointer to the current gfc_code statement, was changed by inserting
additional code.
Currently regression-testing. OK for trunk if the tests
This patch to the Go frontend uses the backend interface for blocks.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
2011-04-19 Ian Lance Taylor
* go-gcc.cc (class Bblock): Define.
(Gcc_backend::if_statement): Change then_block and el
On Tue, Apr 19, 2011 at 20:53, Jakub Jelinek wrote:
> On Tue, Apr 19, 2011 at 08:46:17PM +0300, Janne Blomqvist wrote:
>> Oh, those macros are nice. I updated the patch to use them instead,
>> except for one case where the usage didn't fit the XCNEW(VEC) API and
>> I used xcalloc directly instead.
Now that Jim Meyering has remove the macro that prevented directly
calling free(), and replaced gfc_free() with free(), we can fix this.
Committed as obvious.
Index: frontend-passes.c
===
--- frontend-passes.c (revision 172727)
+++
Rainer Orth writes:
> Mike Stump writes:
>
>> On Apr 5, 2011, at 1:56 AM, Rainer Orth wrote:
>>> * lto.c (promote_var): Only set VISIBILITY_HIDDEN if
>>> HAVE_GAS_HIDDEN.
>>
>> Oh, at a minimum, if TARGET_ASM_ASSEMBLE_VISIBILITY is set, doing this stuff
>> I think is useful?
>
> No, thi
My bad. I looked at the gcc-4.6.0 tarball and it is indeed there.
-Doug
On Tue, Apr 19, 2011 at 10:36 AM, Paolo Carlini
wrote:
> On 04/19/2011 07:26 PM, Doug Kwan (關振德) wrote:
>>
>> This is used for a freestanding C++ library (i.e., we build
>> libsupc++.a only). This is in trunk but for some
Hi Ralf,
> * Rainer Orth wrote on Mon, Apr 04, 2011 at 08:19:19PM CEST:
>> To avoid this mess, I'm instead setting LD_LIBRARY_PATH in CHECK. While
>> this isn't exactly portable (some platforms, especially Darwin and
>> HP-UX, use different variables), it's at least more widespread than -R.
>
> T
Anatoly Sokolov schrieb:
>
> Hi.
>
>>
>> This patch now uses the same procedure like elfos.h
>>
> ...
>> +#define ASM_OUTPUT_ALIGNED_DECL_COMMON(STREAM, DECL, NAME, SIZE,
>> ALIGN) \
>> + avr_asm_output_aligned_common (STREAM, NAME, SIZE, ALIGN, false)
> ..
>> +#define ASM_OUTPUT_ALIGNED_DECL_LO
On Tue, Apr 19, 2011 at 08:46:17PM +0300, Janne Blomqvist wrote:
> Oh, those macros are nice. I updated the patch to use them instead,
> except for one case where the usage didn't fit the XCNEW(VEC) API and
> I used xcalloc directly instead. Here's what I committed:
For that remaining case there
Hi.
This patch now uses the same procedure like elfos.h
...
+#define ASM_OUTPUT_ALIGNED_DECL_COMMON(STREAM, DECL, NAME, SIZE, ALIGN) \
+ avr_asm_output_aligned_common (STREAM, NAME, SIZE, ALIGN, false)
..
+#define ASM_OUTPUT_ALIGNED_DECL_LOCAL(STREAM, DECL, NAME, SIZE, ALIGN) \
+ avr_as
On Tue, Apr 19, 2011 at 10:46, Jakub Jelinek wrote:
> On Tue, Apr 19, 2011 at 10:41:33AM +0300, Janne Blomqvist wrote:
>> On Mon, Apr 18, 2011 at 23:50, Steve Kargl
>> wrote:
>> > On Mon, Apr 18, 2011 at 11:41:33PM +0300, Janne Blomqvist wrote:
>> >> Hi,
>> >>
>> >> the attached patch replaces gf
Paolo Bonzini writes:
> On 04/04/2011 06:15 PM, Rainer Orth wrote:
>> I haven't found if there are provisions for in-tree gold, though, and
>> still cannot test that.
>
> In-tree gold definitely works (or should).
My problem is simply that gold doesn't work on Solaris at all, either
in-tree or e
Hi Ralf,
>> I haven't found if there are provisions for in-tree gold, though, and
>> still cannot test that.
>
> I'm not quite sure I understand this statement. I built a combined tree
> with gold enabled a while ago (must've been several months now).
> I might be misunderstanding this.
I suppos
On 04/19/2011 07:26 PM, Doug Kwan (關振德) wrote:
This is used for a freestanding C++ library (i.e., we build
libsupc++.a only). This is in trunk but for some reason it is not in
the 4.6 release.
Why do you think so? For sure upon approval you committed it to the
branch too, on March, 15th.
Paol
Hans-Peter Nilsson schrieb:
> On Tue, 19 Apr 2011, Georg-Johann Lay wrote:
>> This patchlet skips some tests for avr because int is just 16 bits there.
>
>> 2011-04-19 Georg-Johann Lay
>>
>> * gcc.c-torture/compile/pr43191.c: Skip avr due to 16-bit int.
>> * gcc.dg/torture/pr43165.c:
This is used for a freestanding C++ library (i.e., we build
libsupc++.a only). This is in trunk but for some reason it is not in
the 4.6 release.
-Doug
On Sat, Apr 16, 2011 at 1:27 PM, Diego Novillo wrote:
> I am committing this patch from Doug Kwan on google/main.
>
> This patch adds cpu_defin
Hi Ralf,
> Can't gcc/gthr-tpf.h go, too? What about gcc/gthr-nks.h?
they are both used: config.gcc (s390x-ibm-tpf*) has thread_file='tpf',
and i[3456x]86-*-netware* uses thread_file='nks'. I checked for
references to the existing gthr-*.h files for the cleanup patch.
Thanks.
Rainer
--
Anatoly Sokolov schrieb:
> Hi.
>
>
>> +
>> +/* Implement `ASM_OUTPUT_ALIGNED_DECL_LOCAL' */
>> +/* Track need of __do_clear_bss */
>
> Put dot and two spaces after the end of a sentence. The same for other
> commens in this patch.
>
>> +
>> +void
>> +avr_asm_output_aligned_decl_local (FILE * st
I reverted the original patch and added the assertion instead.
Thanks,
David
On Sun, Apr 17, 2011 at 2:31 PM, Jan Hubicka wrote:
>> Adding assertion sounds good to me -- the only problem is that problem
>> like this hard to be triggered during testing, thus making assertion
>> less useful as it
On Tue, Apr 19, 2011 at 5:08 AM, Michael Matz wrote:
> Hi,
>
> On Mon, 18 Apr 2011, Easwaran Raman wrote:
>
>> > > @@ -596,7 +581,7 @@
>> > > if (vb->conflicts)
>> > > {
>> > > EXECUTE_IF_SET_IN_BITMAP (vb->conflicts, 0, u, bi)
>> > > - add_stack_var_conflict (a, stack_vars[u].r
Hi!
This patch includes assorted OpenMP 3.1 changes for Fortran.
Haven't changed COPYIN with not allocated allocatables yet, waiting
for explanation on OpenMP forum there.
2011-04-19 Jakub Jelinek
PR fortran/46752
* trans-openmp.c (gfc_omp_clause_copy_ctor): Handle
non
On 04/19/2011 05:24 PM, Mikael Morin wrote:
On Tuesday 19 April 2011 12:36:11 Tobias Burnus wrote:
Build and regtested on x86-64-linux.
OK for the trunk - and after some grace period - for the 4.6 branch?
Yes.
Do you think we could have a case where we have to delay module namespace
resolving a
On Tue, Apr 19, 2011 at 4:59 PM, Jakub Jelinek wrote:
> Since MEM_REF has been added, we can unlike in 4.5 and earlier, arbitrary
> VCEs on the LHS. Reload isn't able to reload
> (strict_low_part (subreg:HI (reg:V2DI ...)))
> on the LHS, while it probably should be taught to do that, such
> movs
On Tue, Apr 19, 2011 at 12:04, Benjamin Kosnik wrote:
>
>> This patch adds cpu_defines.h to the set of files to be installed.
>> Doug, could you describe why we need to do this? Will you be
>> submitting this patch for trunk?
>
> It's already in trunk, see
D'oh. Thanks. Clearly, I was no autop
> This patch adds cpu_defines.h to the set of files to be installed.
> Doug, could you describe why we need to do this? Will you be
> submitting this patch for trunk?
It's already in trunk, see
2011-03-15 Doug Kwan
PR libstdc++/48123
* include/Makefile.am (install-freestandi
On Tuesday 19 April 2011 12:36:11 Tobias Burnus wrote:
> Build and regtested on x86-64-linux.
> OK for the trunk - and after some grace period - for the 4.6 branch?
Yes.
Do you think we could have a case where we have to delay module namespace
resolving as well (which we can't as we have to genera
On Tue, Apr 19, 2011 at 4:59 PM, Richard Sandiford
wrote:
> In the attached testcase, we treat:
>
> sum += x[i][0] * x[i][0] + x[i][1] * x[i][1];
>
> as being two independent strided loads: x[i][0] and x[i][1].
> On targets with appropriate support, we therefore use two interleaved
> loads rath
Hi!
Since MEM_REF has been added, we can unlike in 4.5 and earlier, arbitrary
VCEs on the LHS. Reload isn't able to reload
(strict_low_part (subreg:HI (reg:V2DI ...)))
on the LHS, while it probably should be taught to do that, such
movstrict[qh]i IMHO will only very rarely lead to good code,
unle
Michael Matz wrote:
> On Mon, 18 Apr 2011, Janne Blomqvist wrote:
>
>> (Why we, in the age of non-sucky version control, persist in keeping
>> manual changelog files is beyond me..)
>
> The one single reason why I'm very happy about our ChangeLog file policy
> is that I can grep it easily. Listing
In the attached testcase, we treat:
sum += x[i][0] * x[i][0] + x[i][1] * x[i][1];
as being two independent strided loads: x[i][0] and x[i][1].
On targets with appropriate support, we therefore use two interleaved
loads rather than one, then discard one half of each result.
This does not happe
On Wed, 2011-04-13 at 16:59 +0100, Andrew Stubbs wrote:
> Hi,
>
> This old patch has been carried in the CodeSourcery toolchain for some
> time now. It just adds a few new testcases for vectorization.
>
> OK?
>
> Andrew
OK.
2008-12-03 Daniel Jacobowitz
gcc/testsuite/
* gcc
Hi,
>
> Well, even for the partial inlining case I'd devise a scheme that
> if a call to such a forwarder remains it gets expanded as a call to
> the original (non-split) function (similar to emitting a call to
> the asm-thunk instead of expanding the gimple representation of the
> thunk). I rea
Hi,
while removing use of optimize_function_for_size_p from the ipa-inliner (since
we already
check cgraph_maybe_hot_edge_p that include the test), I noticed that
optimize_function_for_size_p (DECL_STRUCT_FUNCTION (node->decl)) won't give the
expected
results on WPA when DECL_STRUCT_FUNCTION is N
On Tue, 19 Apr 2011, Jan Hubicka wrote:
> > I thought the idea was to use __builtin_va_arg_pack and friends.
> > Of course the inliner would still need to know how to inline such
> > a va-arg forwarder, and we would need a way to expand them (well,
> > or just go the existing special casing). We
> I thought the idea was to use __builtin_va_arg_pack and friends.
> Of course the inliner would still need to know how to inline such
> a va-arg forwarder, and we would need a way to expand them (well,
> or just go the existing special casing). We might need this
> kind of inliner support anyway
On Tue, 19 Apr 2011, Rainer Orth wrote:
> Richard Guenther writes:
>
> > This patch sits in all my development trees because delta uses
> > tmp? named directories for storing intermediate files. This causes
> > a make check to fail.
> >
> > Maybe there is an even better way to create a truly te
Richard Guenther writes:
> This patch sits in all my development trees because delta uses
> tmp? named directories for storing intermediate files. This causes
> a make check to fail.
>
> Maybe there is an even better way to create a truly temporary file
> name (that is even portable), but the fo
This patch sits in all my development trees because delta uses
tmp? named directories for storing intermediate files. This causes
a make check to fail.
Maybe there is an even better way to create a truly temporary file
name (that is even portable), but the following patch simply avoids
using tmp
Hi,
it appears that the (standard DWARF as of version 4) discriminator directive
can confuse non-GDB DWARF 2/3 debuggers, so this patch changes the compiler
to stop emitting it in strict mode.
Tested on i586-suse-linux, OK for the mainline?
2011-04-19 Eric Botcazou
* dwarf2out.c (
On 04/19/2011 09:14 AM, Richard Sandiford wrote:
Tested on x86_64-linux-gnu and arm-linux-gnueabi. OK to install?
OK with me. Thanks for your patience. Just a couple of minor nits below
+ extern const int internal_fn_flags_array[];
+ return internal_fn_flags_array[(int) fn];
+}
+
+exte
On Tue, Apr 19, 2011 at 3:14 PM, Richard Sandiford
wrote:
> Richard Guenther writes:
>>> We really should be able to treat calls to pure internal functions
>>> like calls to pure "real" functions though.
>>>
>>> TBH, I think this is an example of why trying to so hard to avoid a tree
>>> code for
2011-04-19 Jonathan Wakely
PR libstdc++/48521
* include/std/type_traits (result_of): Handle pointer to member.
* include/std/functional (__invoke): Likewise.
(_Function_to_function_pointer): Remove.
(_Reference_wrapper_base): Provide nested types independ
Richard Guenther writes:
>> We really should be able to treat calls to pure internal functions
>> like calls to pure "real" functions though.
>>
>> TBH, I think this is an example of why trying to so hard to avoid a tree
>> code for the internal function is working against us. Most of the patch
>
On Sun, Apr 17, 2011 at 7:14 AM, Jan Hubicka wrote:
> Hi,
> there is now tracking PR48636 for fortran inlining issues. I would suggest
> reporting problems like this there or PR that blocks it instead of sending it
> to different threads so we have track of them. It is quite important to get
> s
On Tue, Apr 19, 2011 at 06:51, Richard Guenther wrote:
> 2011-04-19 Richard Guenther
>
> PR lto/48207
> * tree.c (free_lang_data): Do not reset the decl-assembler-name
> langhook.
>
> * g++.dg/lto/pr48207_0.C: New testcase.
OK, if it's only problematic with debug i
On Tue, 2011-04-19 at 17:41 +0800, Guozhi Wei wrote:
> Reload pass tries to determine the stack frame, so it needs to check the
> push/pop lr optimization opportunity. One of the criteria is if there is any
> far jump inside the function. Unfortunately at this time gcc can't decide each
> instruct
On Tue, 2011-04-19 at 15:17 +0400, Denis Chertykov wrote:
> 2011/4/19 Georg-Johann Lay :
> > Denis Chertykov schrieb:
> >> 2011/4/19 Georg-Johann Lay :
> >>> How can add, sub etc. be split? This would need an explicit
> >>> representation of carry.
> >>
> >> Yes.
> >>
> >> Look at http://gcc.gnu.o
Hi.
+
+/* Implement `ASM_OUTPUT_ALIGNED_DECL_LOCAL' */
+/* Track need of __do_clear_bss */
Put dot and two spaces after the end of a sentence. The same for other
commens in this patch.
+
+void
+avr_asm_output_aligned_decl_local (FILE * stream, const_tree decl
ATTRIBUTE_UNUSED,
+
Hi,
On Mon, 18 Apr 2011, Janne Blomqvist wrote:
> (Why we, in the age of non-sucky version control, persist in keeping
> manual changelog files is beyond me..)
The one single reason why I'm very happy about our ChangeLog file policy
is that I can grep it easily. Listing the changelog of the w
Hi,
On Mon, 18 Apr 2011, Easwaran Raman wrote:
> > > @@ -596,7 +581,7 @@
> > > if (vb->conflicts)
> > > {
> > > EXECUTE_IF_SET_IN_BITMAP (vb->conflicts, 0, u, bi)
> > > - add_stack_var_conflict (a, stack_vars[u].representative);
> > > + add_stack_var_conflict (a, u);
> >
>
On Tue, 19 Apr 2011, Georg-Johann Lay wrote:
> This patchlet skips some tests for avr because int is just 16 bits there.
> 2011-04-19 Georg-Johann Lay
>
> * gcc.c-torture/compile/pr43191.c: Skip avr due to 16-bit int.
> * gcc.dg/torture/pr43165.c: Ditto.
> * gcc.dg/torture/pr4
1 - 100 of 133 matches
Mail list logo
