Hi!
I've looked at the spawner_inline.c timeout issue, and it looks like the
problem is that __builtin_setjmp_receiver is a stmt_ends_bb_p call and
insert_backedge_copies then happily inserts statements before the call,
because it can't insert them after the call. But __builtin_setjmp_receiver
is
Hi!
This patch fixes a double free on simd-lane access if
get_vectype_for_scalar_type fails (the new dr is already in datarefs[i]
and if we free_data_ref it, it will be free_data_ref'ed again at the end of
the failed vectorization), fixes handling of clobbers (plugs a memory leak
due to missed fre
Hi!
linemap_location_before_p (which is implemented as a call to
linemap_compare_locations) broke with the addition of IS_ADHOC_LOC,
because it doesn't look through those and thus can happily compare some
0x8... number to normal locus and expect it to work. Most of the other
line-map.c routin
Hi!
I have noticed that with the .deps introduction for gcc/ we've lost
these two dependencies, which autodependency creation isn't aware of,
as the Makefile runs cat on those files and passes the content through
-D option.
Ok for trunk?
2014-02-06 Jakub Jelinek
* Makefile.in (prefix
On Wed, Feb 05, 2014 at 08:42:27PM +0100, Jakub Jelinek wrote:
> So, where do we want to do that instead? E.g. should it be e.g. in
> tree_versionable_function_p directly and let the inliner (if it doesn't do
> already) also treat optimize(0) functions that aren't always_inline as
> noinline?
So,
Hi,
this is variant of patch I am testing (thanks Jakub for the hard analysis).
The dataflow was supposed to be monotonous by keeping the rule that oldvalue
imply new value at each step. This is broken by the approximation done by
and/or operations.
Instead of dropping to true, it seems easier t
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Vietnamese team of translators. The file is available at:
http://translationproject.org/latest/gcc/vi.po
(This file, 'gcc-4.9-b20140202.vi.po
cpplib-4.9-b20140202.vi.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Vietnamese team of translators. The file is available at:
http://translationproject.org/latest/cpplib/vi.po
(This file, 'cpplib-4.9-b20140
On 02/05/2014 02:30 PM, Ulrich Weigand wrote:
> Jakub Jelinek wrote:
>> On Wed, Feb 05, 2014 at 10:26:16PM +0100, Ulrich Weigand wrote:
>>> Actually, now I think the problem originally described there is still
>>> valid: on s390 the CFA is *not* equal to the value at function entry,
>>> but biased
On Wed, 5 Feb 2014, Jeff Law wrote:
> I suspect most folks have a site.exp they drop somewhere and explicitly call
> runtest --tool gcc
* Create site.exp (based on what GCC's makefiles do for build-tree
testing). Note that in some cases you may need different contents for
different testsu
I am really sorry about the delay. I couldn't exactly reproduce the
warning which you described, but I found a place where two nodes were
out of order in optinfo.texi. Could you please apply the following
patch and see if the problem goes away? If it works for you, I will
commit the doc fixes.
Als
Hi,
I would like this patch reviewed and considered for commit when
Stage 1 is active again.
Patch Description:
A C++ thunk's section name is set to be the same as the original function's
section name for which the thunk was created in order to place the two
together. This is done in cp/metho
On 02/05/14 15:10, Matthias Klose wrote:
Am 04.02.2014 03:14, schrieb Mike Stump:
On Feb 3, 2014, at 3:52 PM, Joseph S. Myers wrote:
On Mon, 3 Feb 2014, Andrew Pinski wrote:
On Mon, Feb 3, 2014 at 11:14 AM, Diego Novillo wrote:
On Mon, Feb 3, 2014 at 2:11 PM, Ian Lance Taylor wrote:
If t
On 02/05/14 05:32, Ian Bolton wrote:
2014-02-05 Ian Bolton
testsuite/
* gcc.dg/tree-ssa/pr59597.c: Make called function static so that
expected outcome works for PIC variants too.
This is fine for stage4. Please install.
Thanks,
Jeff
Jakub Jelinek wrote:
> On Wed, Feb 05, 2014 at 10:26:16PM +0100, Ulrich Weigand wrote:
> > Actually, now I think the problem originally described there is still
> > valid: on s390 the CFA is *not* equal to the value at function entry,
> > but biased by 96/160 bytes. So setting the SP to the CFA is
Am 04.02.2014 03:14, schrieb Mike Stump:
> On Feb 3, 2014, at 3:52 PM, Joseph S. Myers wrote:
>> On Mon, 3 Feb 2014, Andrew Pinski wrote:
>>> On Mon, Feb 3, 2014 at 11:14 AM, Diego Novillo wrote:
On Mon, Feb 3, 2014 at 2:11 PM, Ian Lance Taylor wrote:
> If the presence of the build
On Wed, Feb 05, 2014 at 10:26:16PM +0100, Ulrich Weigand wrote:
> Actually, now I think the problem originally described there is still
> valid: on s390 the CFA is *not* equal to the value at function entry,
> but biased by 96/160 bytes. So setting the SP to the CFA is wrong ...
Such biasing happ
On 02/05/14 11:26, Joseph S. Myers wrote:
On Wed, 5 Feb 2014, Jeff Law wrote:
However, it's pretty easy to avoid the headaches and just provide a popcount
routine. I don't think this code is at all performance critical (once per
function being compiled), so a simple popcount should be suffici
On Wed, Feb 05, 2014 at 09:48:12PM +, Iyer, Balaji V wrote:
> > You should put a comment (e.g. a PR reference) in the comment field to
> > explain why you're skipping this test. Most likely, the last arg to
> > dg-skip-if ({
> > "" }) is optional; if so, please omit it.
>
> There isn't a PR
Hello,
I was wondering if the new #pragma target in *mmintrin.h make this
approach more acceptable for 4.10?
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00374.html
On Sun, 7 Apr 2013, Marc Glisse wrote:
Hello,
the attached patch is very incomplete (it passes bootstrap+testsuite on
x86_64
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Rainer Orth
> Sent: Wednesday, February 5, 2014 4:22 PM
> To: Iyer, Balaji V
> Cc: Jakub Jelinek; Paolo Carlini; gcc-patches@gcc.gnu.org
> Subject: Re: regression test issue
>
I wrote and forgot to proof-read:
> Actually, now I think the problem originally described there is still
> valid: on s390 the CFA is *not* equal to the value at function entry,
... CFA is not equal to the *SP* value at function entry ...
> but biased by 96/160 bytes. So setting the SP to the C
On 02/05/2014 11:19 AM, Paolo Carlini wrote:
if (vec_safe_is_empty (vbases))
/* No virtual bases to worry about. */;
else if (!assign_p)
{
if (constexpr_p)
*constexpr_p = false;
*constexpr_p should be false for a constructor of a class with virtual
bases, according
Richard Sandiford wrote:
> In other words, the reason seemed to be that the _Unwind_SetGRPtr in:
>
> #ifdef EH_RETURN_STACKADJ_RTX
> /* Special handling here: Many machines do not use a frame pointer,
> and track the CFA only through offsets from the stack pointer from
> one frame to
"Iyer, Balaji V" writes:
> Index: gcc/testsuite/g++.dg/cilk-plus/CK/catch_exc.cc
> ===
> --- gcc/testsuite/g++.dg/cilk-plus/CK/catch_exc.cc (revision 207437)
> +++ gcc/testsuite/g++.dg/cilk-plus/CK/catch_exc.cc (working cop
On Wed, Feb 05, 2014 at 09:58:32PM +0100, Marek Polacek wrote:
> This is not a regression, on the other hand it's so obvious that
> it could go in nevertheless. Ok?
>
> 2014-02-05 Marek Polacek
>
> PR c/53123
> c-family/
> * c-omp.c (c_finish_omp_atomic): Remove unreachable return
This is not a regression, on the other hand it's so obvious that
it could go in nevertheless. Ok?
2014-02-05 Marek Polacek
PR c/53123
c-family/
* c-omp.c (c_finish_omp_atomic): Remove unreachable return
statement.
diff --git gcc/c-family/c-omp.c gcc/c-family/c-omp.c
i
Richard Henderson writes:
> On 02/05/2014 07:58 AM, Jakub Jelinek wrote:
>> On Wed, Feb 05, 2014 at 03:32:22PM +, Richard Sandiford wrote:
>>> I think at the moment we're relying on the "DW_CFA_offset 15"s to
>>> provide correct %r15 values on eh_return. Every non-leaf function
>>> saves the
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jakub Jelinek
> Sent: Wednesday, February 5, 2014 2:43 PM
> To: Iyer, Balaji V
> Cc: Paolo Carlini; gcc-patches@gcc.gnu.org
> Subject: Re: regression test issue
>
> On Wed, F
On Wed, Feb 05, 2014 at 02:20:05PM +0100, Richard Biener wrote:
> > Using !!optimize to determine if we should switch local ABI to regparm
> > convention isn't compatible with optimize attribute, as !!optimize is
> > whether the current function is being optimized, but for the ABI decisions
> > we
On Wed, Feb 05, 2014 at 07:38:11PM +, Iyer, Balaji V wrote:
> +2014-02-05 Balaji V. Iyer
> +
> + * g++.dg/cilk-plus/CK/catch_exc.cc: Disable test for -O1
> + * c-c++-common/cilk-plus/CK/spawner_inline.c: Likewise.
Ok.
> --- gcc/testsuite/g++.dg/cilk-plus/CK/catch_exc.cc (r
> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Wednesday, February 5, 2014 2:25 PM
> To: Iyer, Balaji V
> Cc: Paolo Carlini; gcc-patches@gcc.gnu.org
> Subject: Re: regression test issue
>
> On Wed, Feb 05, 2014 at 07:08:32PM +, Iyer, Balaji V wrote:
> >
On Wed, Feb 05, 2014 at 07:08:32PM +, Iyer, Balaji V wrote:
> Sorry, I forgot to put [PATCH] in the subject line. Is the patch below OK to
> install?
No. If you want to skip a particular test, you should use dg-skip-if for
that, see http://gcc.gnu.org/onlinedocs/gccint/Directives.html
Sorry, I forgot to put [PATCH] in the subject line. Is the patch below OK to
install?
Thanks,
Balaji V. Iyer.
> -Original Message-
> From: Iyer, Balaji V
> Sent: Wednesday, February 5, 2014 12:02 PM
> To: 'Paolo Carlini'; gcc-patches@gcc.gnu.org
> Subject: RE: regression test issue
>
>
On Wed, 5 Feb 2014, Jeff Law wrote:
> However, it's pretty easy to avoid the headaches and just provide a popcount
> routine. I don't think this code is at all performance critical (once per
> function being compiled), so a simple popcount should be sufficient. No need
> for lookup tables IMHO.
On 02/05/14 03:44, Nick Clifton wrote:
Hi Jeff, Hi Alex,
Sorry - another MN10300 patch - this time for the stack size reported
with -fstack-usage. Currently the value includes the stack frame, but
it does not take into account any registers that might have been
pushed onto the stack
Hi Richard,
Attached is an updated patch for feedback so MSA support to MIPS backend can
be added when open again for next stage1.
It is unfinished in that some comments from your review of the initial patch
have yet to be addressed.
The diff is against svn 207500
Graham
msa.svn.207500
On 02/05/2014 07:58 AM, Jakub Jelinek wrote:
> On Wed, Feb 05, 2014 at 03:32:22PM +, Richard Sandiford wrote:
>> I think at the moment we're relying on the "DW_CFA_offset 15"s to
>> provide correct %r15 values on eh_return. Every non-leaf function
>> saves the stack pointer and the unwind rout
> -Original Message-
> From: Paolo Carlini [mailto:paolo.carl...@oracle.com]
> Sent: Wednesday, February 5, 2014 11:53 AM
> To: Iyer, Balaji V; gcc-patches@gcc.gnu.org
> Subject: Re: regression test issue
>
> Hi,
>
> On 02/05/2014 06:29 AM, Iyer, Balaji V wrote:
> > Hello Everyone,
> >
Hi,
On 02/05/2014 06:29 AM, Iyer, Balaji V wrote:
Hello Everyone,
The following two Cilk Plus tests is timing out at -O1 in my x86_64 box
(-O2, -O3 and -O0 works fine). These tests were working fine till revision
r207047. Can someone please look at this? It looks like a middle-end/bac
Rainer Orth writes:
> Uros Bizjak writes:
>
>> Looks like using builtins should be the correct way, so the original
>> patch is OK.
>>
>> Rainer, can you please add the same cure to sse4_1-floor*.vec tests?
>
> Sure, will do.
Here's what I committed after retesting on i386-pc-solaris2.9,
i386-p
Uros Bizjak writes:
> Looks like using builtins should be the correct way, so the original
> patch is OK.
>
> Rainer, can you please add the same cure to sse4_1-floor*.vec tests?
Sure, will do.
Thanks.
Rainer
--
-
Hi Uros,
> Let's solve this in the way sse4_1-floorf-vec.c solves it and simply add
>
> extern float floorf (float);
>
> after math.h include.
>
> Does this work for you?
it does, but only because the floorf call is optimized away at -O2.
While the Solaris 9 libm contains __floorf, there's no flo
Hi,
On 02/04/2014 12:51 PM, Paolo Carlini wrote:
Hi,
thus I tried to have a look to this issue, while experiencing some
weird problems with the debugger, which slowed me down a lot. I have
been able to figure out that we don't seem to actively set constexpr_p
to true anywhere in implicitly_d
On Wed, Feb 5, 2014 at 5:11 PM, Jakub Jelinek wrote:
>> > gcc.target/i386/avx512f-vrndscaless-2.c currently FAILs on Solaris 9/x86
>> > with gas:
>> >
>> > FAIL: gcc.target/i386/avx512f-vrndscaless-2.c (test for excess errors)
>> > Excess errors:
>> > /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc
On Wed, Feb 05, 2014 at 05:09:31PM +0100, Uros Bizjak wrote:
> On Wed, Feb 5, 2014 at 4:50 PM, Rainer Orth
> wrote:
> > gcc.target/i386/avx512f-vrndscaless-2.c currently FAILs on Solaris 9/x86
> > with gas:
> >
> > FAIL: gcc.target/i386/avx512f-vrndscaless-2.c (test for excess errors)
> > Excess
On Wed, Feb 5, 2014 at 4:50 PM, Rainer Orth
wrote:
> gcc.target/i386/avx512f-vrndscaless-2.c currently FAILs on Solaris 9/x86
> with gas:
>
> FAIL: gcc.target/i386/avx512f-vrndscaless-2.c (test for excess errors)
> Excess errors:
> /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/i386/avx512f
gcc.target/i386/avx512f-vrndscaless-2.c currently FAILs on Solaris 9/x86
with gas:
FAIL: gcc.target/i386/avx512f-vrndscaless-2.c (test for excess errors)
Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/i386/avx512f-vrndscaless-2.
c:21:14: warning: incompatible implicit declarat
On Wed, Feb 05, 2014 at 03:32:22PM +, Richard Sandiford wrote:
> > In a function that doesn't need frame pointer, I'd say this is a serious
> > bloat of the unwind info, you are saving/restoring %r15 not because you have
> > to, but just that it seems to be cheaper for the target. So, I'd say
> >
> > Seems OK to me. I always had an impression that this machinery exists to
> > make decls that are revmoed fro symbol table (optimized out) to land the
> > debug info, but I think this is mostly broken by partitioning anyway, right?
> > Do we stream them at all?
>
> No, we don't stream tho
> > I had a brief look at find_modifiable_mems, which seems to be the only kind
> > of
> > schedule-time dependency breaking that we do. I started writing some new
> > code
> > that would handle REG_ARGS_SIZE, but then considered that wasn't terribly
> > appropriate for stage4.
> >
> > So I've
This time with the patch...
On 02/05/2014 07:40 AM, Richard Henderson wrote:
> On 02/04/2014 09:35 AM, Jan Hubicka wrote:
>>> On 02/04/2014 08:48 AM, Jan Hubicka wrote:
How things are supposed to work in this case? So perhaps we need scheduler
to
understand and move around the ARGS
On 02/04/2014 09:35 AM, Jan Hubicka wrote:
>> On 02/04/2014 08:48 AM, Jan Hubicka wrote:
>>> How things are supposed to work in this case? So perhaps we need scheduler
>>> to
>>> understand and move around the ARGS_SIZE note?
>>
>> I believe we do need to have the scheduler move the notes around.
Jakub Jelinek writes:
> On Tue, Feb 04, 2014 at 12:21:14PM +, Richard Sandiford wrote:
>> Jakub Jelinek writes:
>> >> But then we wouldn't be able to use var-tracking when __builtin_eh_return
>> >> is used, since in that case replacing the (set (reg ...) (mem ...))
>> >> with a (plus ...) wou
On Wed, Feb 5, 2014 at 8:27 AM, Alan Modra wrote:
> Vlad added rs6000_secondary_memory_needed_mode for lra, and in so
> doing broke reload's use of cfun->machine->sdmode_stack_slot in
> rs6000_secondary_memory_needed_rtx (mode was no longer SDmode there).
> Bootstrapped and regression tested powe
> >
>
> I think it would be better, yes. IIRC, We want to re-organize
> indirect_info anyway (I vaguely remember we want to split the
> overloaded offset field into two but forgot the exact reason why but I
> have it written somewhere), I suppose we'll be turning it into a union
> (or class hier
On Wed, 5 Feb 2014, Jan Hubicka wrote:
> >
> > When looking at PR60060, outputting the declaration debug info for
> > a local static variable twice (once via BLOCK_VARS and once via
> > calling the debug hook on all globals) I noticed that the
> > rest_of_decl_compilation call in materialize_cgra
>
> When looking at PR60060, outputting the declaration debug info for
> a local static variable twice (once via BLOCK_VARS and once via
> calling the debug hook on all globals) I noticed that the
> rest_of_decl_compilation call in materialize_cgraph always works
> on the empty lto_global_var_decl
> On Wed, 5 Feb 2014, Jakub Jelinek wrote:
>
> > Hi!
> >
> > Using !!optimize to determine if we should switch local ABI to regparm
> > convention isn't compatible with optimize attribute, as !!optimize is
> > whether the current function is being optimized, but for the ABI decisions
> > we actua
Tested on x86_64-unknown-linux-gnu, applied.
Richard.
2014-02-05 Richard Biener
PR testsuite/60076
* gcc.dg/vect/pr60012.c: Require vect_extract_even_odd and
avoid using unsigned long long.
Index: gcc/testsuite/gcc.dg/vect/pr60012.c
==
On Tue, Feb 4, 2014 at 10:15 PM, Bill Schmidt
wrote:
> Hi,
>
> One final patch in the series, this one for vec_sum2s. This builtin
> requires some additional code generation for the case of little endian
> without -maltivec=be. Here's an example:
>
> va = {-10,1,2,3};0x 0003 00
Ramana wrote:
Attached patch fixes this. Is this OK for trunk?
How has it been tested ?
I was hoping Linaro people could run their magical cbuild on it...
Ok if no regressions.
regards
Ramana
-Y
--
Ramana Radhakrishnan
Principal Engineer
ARM Ltd.
On Tue, Feb 4, 2014 at 2:13 PM, Bill Schmidt
wrote:
> Yet another -maltivec=be patch, this one for the vector pack/unpack
> builtins. For the pack operations, we need to reverse the order of the
> inputs for little endian without -maltivec=be. For the unpack
> operations, we need to replace unp
Marc Glisse writes:
> On Wed, 5 Feb 2014, Andreas Schwab wrote:
>
>> Wrt. the function decl it should probably just be changed to a variable
>> decl. Alignments on function decls are kind of exotic.
>
> Good idea. How about this patch then?
LGTM.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...
Ramana wrote:
The error is caused by unaligned vector load via two vldr instructions:
So, does this mean that we get unaligned vector loads
when munaligned-access is on, using vldr instructions ?
No, when -munaligned-access is on, the backend will enable movmisalign
patterns that generate fr
There's a simple mistake in gimple_duplicate_sese_region that
causes all loop-header copied loops to be thrown away (but soon
re-discovered, hopefully without somebody inbetween messing things up).
Fixed like the following, bootstrapped on x86_64-unknown-linux-gnu,
testing in progress.
Richard.
This little patch fixes a number of dfp failures:
Fail: c-c++-common/dfp/func-vararg-alternate-d32.c execution test
FAIL: c-c++-common/dfp/func-vararg-alternate-d32.c -std=c++11 execution test
FAIL: c-c++-common/dfp/func-vararg-alternate-d32.c -std=c++98 execution test
FAIL: c-c++-common/dfp/func-
I've attached what I ended up committing.
As far as I know the behaviour of this flag has always been this way. So is
this also OK to backport to release branches?
Ok by me. It's a documentation fix to make things more explicit.
And s/=/ again in Changelog :) .
Ramana
Thanks,
James
On Wed, Feb 05, 2014 at 11:02:42AM +, Ramana Radhakrishnan wrote:
> On 01/27/14 10:01, James Greenhalgh wrote:
> >
> > Hi,
> >
> > I've tripped myself over with these three options too many times,
> > actually, their behaviour is very simple.
> >
> > This patch clarifies the language used to de
On Wed, 5 Feb 2014, Jakub Jelinek wrote:
> Hi!
>
> Using !!optimize to determine if we should switch local ABI to regparm
> convention isn't compatible with optimize attribute, as !!optimize is
> whether the current function is being optimized, but for the ABI decisions
> we actually need the cal
On Wed, 5 Feb 2014, Jakub Jelinek wrote:
> Hi!
>
> As the testcase shows, invalid use of noreturn attribute (which we diagnose)
> can result in in empty bb with no successors. This patch fixes
> cleanup_empty_eh not to ICE on these.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok
Hi!
Here is one possible fix for the PR60013 compute_bb_predicates oscillation,
the PR contains long analysis, but to sum it up, the problem is that
we only allow 8 conjuction operands for the predicates and when we reach 8
and want to add some further one, we just throw some of the disjunctions
o
PR59597 reinstated some code to cancel unnecessary jump threading,
and brought with it a testcase to check that the cancelling happened.
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01448.html
With PIC enabled for arm and aarch64, the unnecessary jump threading
already never took place, so there
Hi!
Using !!optimize to determine if we should switch local ABI to regparm
convention isn't compatible with optimize attribute, as !!optimize is
whether the current function is being optimized, but for the ABI decisions
we actually need the caller and callee to agree on the calling convention.
Fi
Hi!
As the testcase shows, invalid use of noreturn attribute (which we diagnose)
can result in in empty bb with no successors. This patch fixes
cleanup_empty_eh not to ICE on these.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2014-02-04 Jakub Jelinek
PR midd
On Wed, 5 Feb 2014, Andreas Schwab wrote:
Marc Glisse writes:
On Wed, 5 Feb 2014, Dominique Dhumieres wrote:
I'll give it a day (it can easily be changed again later).
IMO it would be better (more general) to use a dg-require-effective-target
with the corresponding test(s) in target-suppo
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Dutch team of translators. The file is available at:
http://translationproject.org/latest/gcc/nl.po
(This file, 'gcc-4.9-b20140202.nl.po', ha
On 01/27/14 10:01, James Greenhalgh wrote:
Hi,
I've tripped myself over with these three options too many times,
actually, their behaviour is very simple.
This patch clarifies the language used to describe the options, and
puts them in a logical order. I'm happy to reword again if this
is stil
Marc Glisse writes:
> On Wed, 5 Feb 2014, Dominique Dhumieres wrote:
>
>>> I'll give it a day (it can easily be changed again later).
>>
>> IMO it would be better (more general) to use a dg-require-effective-target
>> with the corresponding test(s) in target-supports-dg.exp.
>
> But which tests?
When looking at PR60060, outputting the declaration debug info for
a local static variable twice (once via BLOCK_VARS and once via
calling the debug hook on all globals) I noticed that the
rest_of_decl_compilation call in materialize_cgraph always works
on the empty lto_global_var_decls vector (we
Hi Jeff, Hi Alex,
Sorry - another MN10300 patch - this time for the stack size reported
with -fstack-usage. Currently the value includes the stack frame, but
it does not take into account any registers that might have been
pushed onto the stack.
The patch below fixes this problem, but
*ping*
Thanks,
James
On Mon, Jan 27, 2014 at 10:01:51AM +, James Greenhalgh wrote:
>
> Hi,
>
> I've tripped myself over with these three options too many times,
> actually, their behaviour is very simple.
>
> This patch clarifies the language used to describe the options, and
> puts them i
Hi Marcus,
> + "ldr\\t%x2, %1\;str\\t%x2, %0\;mov\t%x2,0"
> + [(set_attr "length" "12")])
>
> This pattern emits an opaque sequence of instructions that cannot be
> scheduled, is that necessary? Can we not expand individual
> instructions or at least split ?
Almost all the ports emits a templat
Hi,
On Wed, Feb 05, 2014 at 12:47:30AM +0100, Jan Hubicka wrote:
> > > - if (TREE_CODE (t) != TREE_BINFO)
> > > + /* Try to work out BINFO from virtual table pointer value in
> > > replacements. */
> > > + if (!t && agg_reps && !ie->indirect_info->by_ref)
> >
> > At this point you know that
On Wed, Feb 05, 2014 at 10:43:24AM +0100, Marc Glisse wrote:
> On Wed, 5 Feb 2014, Dominique Dhumieres wrote:
>
> >>I'll give it a day (it can easily be changed again later).
> >
> >IMO it would be better (more general) to use a dg-require-effective-target
> >with the corresponding test(s) in targ
On Wed, 5 Feb 2014, Dominique Dhumieres wrote:
I'll give it a day (it can easily be changed again later).
IMO it would be better (more general) to use a dg-require-effective-target
with the corresponding test(s) in target-supports-dg.exp.
But which tests? One for over/under alignment of func
> I'll give it a day (it can easily be changed again later).
IMO it would be better (more general) to use a dg-require-effective-target
with the corresponding test(s) in target-supports-dg.exp.
Dominique
On Wed, 5 Feb 2014, Jakub Jelinek wrote:
On Wed, Feb 05, 2014 at 09:58:28AM +0100, Marc Glisse wrote:
On Wed, 5 Feb 2014, Jakub Jelinek wrote:
On Wed, Feb 05, 2014 at 09:28:16AM +0100, Andreas Schwab wrote:
Feel free to replace 8 with 16 in the initialization of size (you can
commit it as ob
On Wed, Feb 05, 2014 at 09:58:28AM +0100, Marc Glisse wrote:
> On Wed, 5 Feb 2014, Jakub Jelinek wrote:
>
> >On Wed, Feb 05, 2014 at 09:28:16AM +0100, Andreas Schwab wrote:
> >>>Feel free to replace 8 with 16 in the initialization of size (you can
> >>>commit it as obvious if it works for you).
>
The following improves dumping / messages for vectorizer runtime
alias checks.
Bootstrap / regtest running on x86_64-unknown-linux-gnu. I'll consider
this "documentation" and thus appropriate at this stage.
Richard.
2014-02-05 Richard Biener
* tree-vect-loop.c (vect_analyze_loop_2)
On Wed, 5 Feb 2014, Jakub Jelinek wrote:
On Wed, Feb 05, 2014 at 09:28:16AM +0100, Andreas Schwab wrote:
Feel free to replace 8 with 16 in the initialization of size (you can
commit it as obvious if it works for you).
Are there any targets that may reject an overaligned function decl?
I thi
The following patch moves the code that avoids creating loop
carried data dependences in PRE when later vectorizing to a place
where it can use the optimizations PRE performs (in particular
loop invariant motion). This makes sure it applies for Himeno
when built with -fipa-pta which then allows t
The test g++.dg/cpp0x/constexpr-attribute2.C fails on darwin
with
FAIL: g++.dg/cpp0x/constexpr-attribute2.C (test for excess errors)
Excess errors:
/opt/gcc/_clean/gcc/testsuite/g++.dg/cpp0x/constexpr-attribute2.C:9:40: error:
'init_priority' attribute is not supported on this platform
/opt/gcc/_
On Wed, Feb 05, 2014 at 09:28:16AM +0100, Andreas Schwab wrote:
> > Feel free to replace 8 with 16 in the initialization of size (you can
> > commit it as obvious if it works for you).
>
> Are there any targets that may reject an overaligned function decl?
I think that is very well possible. Why
Marc Glisse writes:
>> /usr/local/gcc/gcc-20140204/gcc/testsuite/g++.dg/cpp0x/constexpr-attribute2.C:32:6:
>> error: alignment for 'void g()' must be at least 16
>
> (I don't know why we error out for this, align specifies a minimal
> alignment, if it ends up more aligned, that's fine)
Probably
96 matches
Mail list logo
