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/back-end
issue.
WARNING: program timed out.
FAIL: g++
Richard wrote:
What about updated patch?
Ok if it passes bootstrap and regtesting.
It does, commited in r207497.
-Y
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 0002 0001 fff6
vb = {100,101,102,-103}; 0x ff99 00
+cc jakub
On Tue, Feb 4, 2014 at 4:59 PM, Paul Pluzhnikov wrote:
> Greetings,
>
> The gcc.dg/vect/no-vfa-vect-depend-2.c failed for us, when linked with
> gold, but not when linked with BFD ld.
>
> The problem appears to be off-by-one error causing array out of bounds
> access, fixed by attached
The attached change fixes a problem found in the libcap-ng package.
TLS call arguments
were not being pre expanded. As a result, the register arguments were
being clobbered.
After fixing pa_legitimate_constant_p() to return false for all TLS
references, I found that the
code in pa_emit_mo
Greetings,
The gcc.dg/vect/no-vfa-vect-depend-2.c failed for us, when linked with
gold, but not when linked with BFD ld.
The problem appears to be off-by-one error causing array out of bounds
access, fixed by attached patch.
OK for trunk?
Thanks,
gcc/testsuite/ChangeLog:
2014-02-04 Paul Plu
> Hi,
>
> On Mon, Feb 03, 2014 at 12:52:49AM +0100, Jan Hubicka wrote:
> > Hi,
> > this patch fixes the bug in extr_type_from_vtbl_ptr_store that made it to
> > consider store of construction virtual table or virtual table of virtual
> > base
> > as store of type's virtual table.
> >
> > In the
Hi,
On Mon, Feb 03, 2014 at 12:52:49AM +0100, Jan Hubicka wrote:
> Hi,
> this patch fixes the bug in extr_type_from_vtbl_ptr_store that made it to
> consider store of construction virtual table or virtual table of virtual base
> as store of type's virtual table.
>
> In the testcase we have after
Hi,
The attached patch uses a callback function to unify the integer and
floating-point scaling in gcov-tool. (Also fix a bug in fp scaling of
ic and dc counters in earlier code).
Tested with spec2006 profiles.
OK for checking in?
Thanks,
-Rong
2014-02-04 Rong Xu
* gcc/gcov-tool.c
> > - 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 !ie->indirect_info->polymorphic is set and
> thus ie->indirect_info->by_ref is
Hi,
I tried to rebuild firefox without visibilities that leads to about 10fold
increase
in LTO time, mostly by ltrans. What happens is that by the old rule that
DECL_ONE_ONLY is duplicated into each partition that needs it we end up
duplicating
things everywhere. Moreover we mark tem all as used_
Hi,
On Fri, Jan 31, 2014 at 07:22:55AM +0100, Jan Hubicka wrote:
...
> PR ipa/59831
> * gimple-fold.c (gimple_extract_devirt_binfo_from_cst): Remove.
> * ipa-devirt.c (get_poymorphic_call_info_for_decl): Break out from ...
> (get_polymorphic_call_info): ... here.
>
On Tue, 4 Feb 2014, Richard Sandiford wrote:
> So here I just provide simple C functions for each operation that has
> hard-float support. We can then restrict the softfp stuff to functions
> that really do need softfp support, meaning that softfp_exclude_libgcc2 := n
> should always be OK. As a
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
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59913
The patch was successfully tested and bootstrapped on x86/x86-64 and arm.
Committed as rev. 207485.
2014-02-04 Vladimir Makarov
PR bootstrap/59913
* lra-constraints.c (need_for_split_p): Use mo
ok.
David
On Tue, Feb 4, 2014 at 11:28 AM, Rong Xu wrote:
> Hi,
>
> The attached patch fixes the duplicated definition error in
> gcov-tool.c in profiledbootstrap.
>
> Google branch only and tested with profiledbootstrap.
>
> Ok for checking in?
>
> -Rong
On 02/04/14 10:45, nick clifton wrote:
Hi Jeff,
But how/why did an extended register get selected to begin with?
It happens in reload.c:find_valid_class().
HARD_REGNO_MODE_OK and other macros/hooks ought to be preventing this
relatively early.
Ah - and that is the problem. mn10300_hard_r
Ok. Thanks, Teresa
On Tue, Feb 4, 2014 at 10:59 AM, Rong Xu wrote:
> Here is the revised patch that integrates Teresa' comments.
> Ok for checking in?
>
> -Rong
>
> On Thu, Jan 30, 2014 at 1:20 PM, Rong Xu wrote:
>> Comments are inlined. New patch attached to this email.
>>
>> -Rong
>>
>> On Thu
Hi,
The attached patch fixes the duplicated definition error in
gcov-tool.c in profiledbootstrap.
Google branch only and tested with profiledbootstrap.
Ok for checking in?
-Rong
Index: gcov-tool.c
===
--- gcov-tool.c (revision 2074
Hi,
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 unpackh with unpackl, and vice versa, for
little endian with
)));
+void* my_realloc(void*, unsigned) __attribute__((alloc_size(two)));
+
+typedef char vec __attribute__((vector_size(size)));
+
+void f(char*) __attribute__((nonnull(pos)));
+
+void g() __attribute__((aligned(size)));
/usr/local/gcc/gcc-20140204/gcc/testsuite/g++.dg/cpp0x/constexpr-attribute2.C:32:6
Here is the revised patch that integrates Teresa' comments.
Ok for checking in?
-Rong
On Thu, Jan 30, 2014 at 1:20 PM, Rong Xu wrote:
> Comments are inlined. New patch attached to this email.
>
> -Rong
>
> On Thu, Jan 30, 2014 at 12:39 PM, Xinliang David Li
> wrote:
>> On Wed, Jan 29, 2014 at
"Joseph S. Myers" writes:
> I note that you're not using t-softfp-excl. Logically, it's best to use
> the libgcc2.c functions in the cases where hardware floating point is
> involved (when they are providing conversions to/from DImode/TImode, and
> to/from unsigned, based on conversions to/fro
Jakub Jelinek writes:
> On Tue, Feb 04, 2014 at 04:59:54PM +, Richard Sandiford wrote:
>> Right, that was my point. So by relying on unwind info in var-tracking.c
>> we're getting the wrong answer for the stack offset after the LM(G)
>> instruction. It sounds like we're going to pretend it's
cpplib-4.9-b20140202.eo.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 Esperanto team of translators. The file is available at:
http://translationproject.org/latest/cpplib/eo.po
(This file, 'cpplib-4.9-b201402
Hi Jeff,
But how/why did an extended register get selected to begin with?
It happens in reload.c:find_valid_class().
HARD_REGNO_MODE_OK and other macros/hooks ought to be preventing this
relatively early.
Ah - and that is the problem. mn10300_hard_regno_mode_ok is allowing
extended regis
On 02/04/2014 09:35 AM, Jan Hubicka wrote:
> I am not terribly familiar with the code, will you look into it or shall I
> give it a try?
I'm looking at it. Was there a PR for the Go bootstrap failure?
r~
> 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.
If we need notes on non-stack adjusting insn
On Tue, Feb 04, 2014 at 04:59:54PM +, Richard Sandiford wrote:
> Right, that was my point. So by relying on unwind info in var-tracking.c
> we're getting the wrong answer for the stack offset after the LM(G)
> instruction. It sounds like we're going to pretend it's right anyway
> for expedien
> Hi!
>
> On this testcase the TU is -O0, but a particular function is -O2.
> The -O0 means odr_hash isn't created, but during fold_gimple_call
> we call possible_polymorphic_call_targets because -fdevirtualize
> is true in the current function (as it is -O2) and ICE because
> we assume odr_hash c
Hi,
I went ahead and comitted Markus' patch. I updated the testcase to use hidden
visibility.
With default visibility the gimple-fold change will enable devirtualization.
Honza
Index: ChangeLog
===
--- ChangeLog (revision 207477)
On Tue, 4 Feb 2014, Marek Polacek wrote:
> Starting with revision 206620, if we have LHS op= RHS and RHS has
> side effects, we preevaluate RHS first, which means that we wrap it
> in C_MAYBE_CONST_EXPR_EXPR + SAVE_EXPR. This regressed -Wconversion,
> since we now issue bogus warnings. The reaso
> Hi,
>
> On 02/04/2014 06:43 AM, Jan Hubicka wrote:
> >Hi,
> >this patch solves the actual ICE in PR59831 by using ipa-devirt instead of
> >gimple_extract_devirt_binfo_from_cst as discussed in the first post.
> >
> >Honza
> >
> > PR ipa/59831
> > * ipa-cp.c (ipa_get_indirect_edge_target_1
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.
r~
> Hi!
>
> As described in the PR, while build_function_decl_skip_args
> takes care of changing the type from METHOD_TYPE to FUNCTION_TYPE
> if removing first argument (this), the FE may have other special arguments
> that it is aware of (such as in-charge etc.) and if the this argument
> is not re
Starting with revision 206620, if we have LHS op= RHS and RHS has
side effects, we preevaluate RHS first, which means that we wrap it
in C_MAYBE_CONST_EXPR_EXPR + SAVE_EXPR. This regressed -Wconversion,
since we now issue bogus warnings. The reason is that conversion_warning
doesn't grok C_MAYBE_
Jakub Jelinek writes:
> On Tue, Feb 04, 2014 at 03:38:51PM +, Richard Sandiford wrote:
>> What do you want var-tracking to do about the __builtin_eh_return case
>> though? It isn't correct to say that the instruction adds the frame size
>> to the stack pointer then, since the loaded value inc
Hi,
Revision 206943 caused a regression on g++.dg/opt/pr52727.C, which wasn't
caught by my automated tester since SSE2 and SSE math are enabled by
default. This patch adds -march=i686 for ia32 when compiling
g++.dg/opt/pr52727.C, which is required to reproduce the bug. OK to
install?
Thanks.
H
> On 01/01/2014 06:23 AM, Jan Hubicka wrote:
> > last_sp_adjust = 0;
> > + /* We no longer adjust stack size. Whoever adjusted it earlier
> > +hopefully got the note right. */
> > + note = find_reg_note (insn, REG_ARGS_SIZE, NULL_RTX);
> > + if (note)
Hi,
PR 55260 has been reopened because there is still one use of wrong
info, this time in cgraph_edge_brings_all_agg_vals_for_node when
checking whether aggregate lattices are set to bottom which can lead
to index out of bounds assert failures or even potentially ignoring
bottom lattices.
Fixed t
Committed to branch dmalcolm/jit:
The following commit adds a way to create an array type from an existing
type:
/* Given type "T", get type "T[N]" (for a constant N). */
extern gcc_jit_type *
gcc_jit_context_new_array_type (gcc_jit_context *ctxt,
gcc_jit_
> On Tue, Feb 4, 2014 at 6:52 AM, Jan Hubicka wrote:
> > Hi,
> > while merging nodes in lto-symtab, we need to copy the force_output and
> > forced_by_abi flags.
> > Thanks to Markus who noticed the issue.
>
> Don't we need to choose the forced_by_abi variant if there are variants
> without that
How about putting the fail label at the end of the function so the
cleanup code is only in one place? OK either way.
Jason
Hi Venkat,
On 22 January 2014 16:57, Venkataramanan Kumar
wrote:
> Hi Marcus,
>
> After we changed the frame growing direction (downwards) in Aarch64,
> the back-end now generates stack smashing set and test based on
> generic code available in GCC.
>
> But most of the ports (i386, spu, rs6000, s
On 01/01/2014 06:23 AM, Jan Hubicka wrote:
> last_sp_adjust = 0;
> + /* We no longer adjust stack size. Whoever adjusted it earlier
> + hopefully got the note right. */
> + note = find_reg_note (insn, REG_ARGS_SIZE, NULL_RTX);
> + if (note)
>
On Tue, Feb 04, 2014 at 03:38:51PM +, Richard Sandiford wrote:
> What do you want var-tracking to do about the __builtin_eh_return case
> though? It isn't correct to say that the instruction adds the frame size
> to the stack pointer then, since the loaded value includes the eh_return
> adjust
On 29/01/14 11:19, Andreas Krebbel wrote:
> Hi,
>
> the attached patch adds a prototype for __udiv_w_sdiv to longlong.h if
> needed. This fixes tons of build warnings on s390 32 bit in glibc.
>
> Ok?
>
> Bye,
>
> -Andreas-
>
>
> 2014-01-29 Andreas Krebbel
>
> * longlong.h: Add __ud
On 02/03/14 05:41, Kugan wrote:
With the 2013-09-21 version of trunk, attached test case results in bus
error when simultaneously enabling both -mno-unaligned-access and
-ftree-vectorize.
The error is caused by unaligned vector load via two vldr instructions:
vldr d16, [r3, #-16]
vldr d17, [
On Tue, 4 Feb 2014, Rainer Orth wrote:
> > The patch to libgo/ltmain.sh is now committed to mainline.
>
> I've now committed the rest, thanks.
>
> Btw., what's the procedure for syncing the toplevel ltmain.sh these
> days? AFAIK there's both the old CVS src repo as well as the new
> binutils-gd
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 Tue, Feb 4, 2014 at 3:32 PM, Yury Gribov wrote:
> Richard wrote:
>>
>> I think you can't rely on pointer equivalence of the lookup_attribute
>> result so you want instead of
>
>
> Thanks, makes sense.
>
>
>> Please also name CIF_OPTION_MISMATCH as CIF_ATTRIBUTE_MISMATCH
>> and say "function att
Commited in 207472.
-Maxim
On Tue, Feb 04, 2014 at 06:44:22PM +0400, Maxim Ostapenko wrote:
> Hi,
>
> > FAIL: g++.dg/tsan/default_options.C -O2 execution test
> >
> > Both these tests don't report anything (well, default_options.C
> > prints DONE),
> > simply succeed (with dg-shouldfail that is a failure)
>
> I've finall
Intrinsic subprograms in Pure packages were not marked as Pure, which was
actually unintended. The spec of einfo was also not up-to-date, which is
now fixed.
Tested on x86_64-pc-linux-gnu, committed on trunk
2014-02-04 Arnaud Charlet
* g-souinf.ads: Subprograms in this unit are actual
On Tue, 4 Feb 2014, Dominique Dhumieres wrote:
> With the petches (an a minor fix in gcc/lto/lto.c) the remaining failures
> are
>
> FAIL: gfortran.dg/debug/pr35154-dwarf2.f -gdwarf-2 scan-assembler
> (DW_AT_name: "label"|"label[^\n]*"[^\n]*DW_AT_name)
> FAIL: gfortran.dg/debug/pr35154-dwarf2.f
This patch adds a legality check that in a loop over a container that only has
a constant indexing aspect, elements are constant within the loop, and attempts
to modify them are appripriately rejected.
Compiling p.adb must yield:
p.adb:15:07: left hand side of assignment must be a variable
--
Hi,
> FAIL: g++.dg/tsan/default_options.C -O2 execution test
>
> Both these tests don't report anything (well, default_options.C
> prints DONE),
> simply succeed (with dg-shouldfail that is a failure)
I've finally fixed g+.dg/tsan/default_options.C test (the check
dg-shouldfail should be remo
Richard wrote:
I think you can't rely on pointer equivalence of the lookup_attribute
result so you want instead of
Thanks, makes sense.
Please also name CIF_OPTION_MISMATCH as CIF_ATTRIBUTE_MISMATCH
and say "function attribute mismatch" in the description.
Done.
What about updated patch?
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 ...) would be incorrect -- the value
With the petches (an a minor fix in gcc/lto/lto.c) the remaining failures
are
FAIL: gfortran.dg/debug/pr35154-dwarf2.f -gdwarf-2 scan-assembler (DW_AT_name:
"label"|"label[^\n]*"[^\n]*DW_AT_name)
FAIL: gfortran.dg/debug/pr35154-dwarf2.f -gdwarf-2 -g3 scan-assembler
(DW_AT_name: "label"|"label[
On 2014.02.04 at 14:18 +0100, Paolo Carlini wrote:
> .. to wit, for 27_io/basic_stringbuf/sputbackc/char/9425.cc:
>
> 0xbb482f crash_signal
> /scratch/Gcc/svn-dirs/trunk/gcc/toplev.c:337
> 0x10ce353 contains_struct_check
> /scratch/Gcc/svn-dirs/trunk/gcc/tree.h:2822
> 0x10ce353 ipa_get_i
.. to wit, for 27_io/basic_stringbuf/sputbackc/char/9425.cc:
0xbb482f crash_signal
/scratch/Gcc/svn-dirs/trunk/gcc/toplev.c:337
0x10ce353 contains_struct_check
/scratch/Gcc/svn-dirs/trunk/gcc/tree.h:2822
0x10ce353 ipa_get_indirect_edge_target_1
/scratch/Gcc/svn-dirs/trunk/gcc/ipa-cp.c
Hi,
On 02/04/2014 06:43 AM, Jan Hubicka wrote:
Hi,
this patch solves the actual ICE in PR59831 by using ipa-devirt instead of
gimple_extract_devirt_binfo_from_cst as discussed in the first post.
Honza
PR ipa/59831
* ipa-cp.c (ipa_get_indirect_edge_target_1): Use ipa-devirt
On Tue, 4 Feb 2014, Jakub Jelinek wrote:
> On Tue, Feb 04, 2014 at 01:57:19PM +0100, Richard Biener wrote:
> > > @@ -1691,6 +1691,13 @@ vect_finish_stmt_generation (gimple stmt
> > > }
> > >
> > >gimple_set_location (vec_stmt, gimple_location (stmt));
> > > +
> > > + /* While EH edges
On Tue, Feb 04, 2014 at 01:57:19PM +0100, Richard Biener wrote:
> > @@ -1691,6 +1691,13 @@ vect_finish_stmt_generation (gimple stmt
> > }
> >
> >gimple_set_location (vec_stmt, gimple_location (stmt));
> > +
> > + /* While EH edges will generally prevent vectorization, stmt might
> > +
On Tue, 4 Feb 2014, Jakub Jelinek wrote:
> Hi!
>
> As discussed in the PR, this patch disallows cloning of
> non-optimized functions, which doesn't work properly e.g. because
> -O0 functions don't have vdef/vuses, but also doesn't sound like
> something people would like to happen if they say par
On Tue, 4 Feb 2014, Jakub Jelinek wrote:
> Hi!
>
> If a load or store is in EH tables, but doesn't have EH edges out of it,
> e.g. for must-not-throw regions, we weren't cleaning it up and adding
> MASK_{LOAD,STORE} into EH region instead.
> Similarly, the vectorizer needs to add the vectorized s
On Tue, Feb 04, 2014 at 01:43:01PM +0100, Richard Biener wrote:
> On Tue, 4 Feb 2014, Jakub Jelinek wrote:
>
> > Hi!
> >
> > As described in the PR, while build_function_decl_skip_args
> > takes care of changing the type from METHOD_TYPE to FUNCTION_TYPE
> > if removing first argument (this), the
Hi!
On this testcase the TU is -O0, but a particular function is -O2.
The -O0 means odr_hash isn't created, but during fold_gimple_call
we call possible_polymorphic_call_targets because -fdevirtualize
is true in the current function (as it is -O2) and ICE because
we assume odr_hash can be used saf
Hi!
As discussed in the PR, this patch disallows cloning of
non-optimized functions, which doesn't work properly e.g. because
-O0 functions don't have vdef/vuses, but also doesn't sound like
something people would like to happen if they say particular function
shouldn't be optimized. If everythin
Hi!
If a load or store is in EH tables, but doesn't have EH edges out of it,
e.g. for must-not-throw regions, we weren't cleaning it up and adding
MASK_{LOAD,STORE} into EH region instead.
Similarly, the vectorizer needs to add the vectorized stmts to the same
EH region as the corresponding {,mask
On Tue, 4 Feb 2014, Jakub Jelinek wrote:
> Hi!
>
> As described in the PR, while build_function_decl_skip_args
> takes care of changing the type from METHOD_TYPE to FUNCTION_TYPE
> if removing first argument (this), the FE may have other special arguments
> that it is aware of (such as in-charge
Hi!
Apparently at least on invalid #pragma omp declare reduction,
when parsing the type-ids, the parser may allocate some declarators
of the declarator_obstack, which results in ICE at the end of translation
unit when declarator_obstack is not in the initial empty state.
Fixed thusly, bootstrappe
Hi!
ubsan/overflow-1.c test ICEs on ppc32, because lopart is SImode, and we
attempt to do a DImode left shift on it by 32.
We don't really care about the upper bits, those are all shifted away
anyway, so this patch fixes it by adding a paradoxical SUBREG, which results
in better generated code com
Hi!
As described in the PR, while build_function_decl_skip_args
takes care of changing the type from METHOD_TYPE to FUNCTION_TYPE
if removing first argument (this), the FE may have other special arguments
that it is aware of (such as in-charge etc.) and if the this argument
is not removed, but the
Hi!
We shouldn't copy the inbranch artificial argument. Also,
if clone_info->inbranch, then inbranch_specified is necessarily true,
thus (i & 1) will be always 0 and in that case we still need room for the
extra argument.
Committed to trunk.
2014-02-04 Jakub Jelinek
PR other/58712
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 ...) would be incorrect -- the value we're loading from the
>> stack will have had a variable adjustment applied
Jakub Jelinek writes:
> On Tue, Feb 04, 2014 at 11:33:57AM +, Richard Sandiford wrote:
>> > So, how does the lmg insn look like in RTL dump on some problematic
>> > testcase?
>> > insn_stack_adjust_offset_pre_post already uses REG_FRAME_RELATED_EXPR,
>> > which is also a kind of CFI note (the
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_declare_fn (besides the unrelated case of
inheritin
On Tue, Feb 04, 2014 at 11:33:57AM +, Richard Sandiford wrote:
> > So, how does the lmg insn look like in RTL dump on some problematic
> > testcase?
> > insn_stack_adjust_offset_pre_post already uses REG_FRAME_RELATED_EXPR,
> > which is also a kind of CFI note (the oldest one), so likely the is
ond))) t c;
> +
> +void* my_calloc(unsigned, unsigned) __attribute__((alloc_size(pos,two)));
> +void* my_realloc(void*, unsigned) __attribute__((alloc_size(two)));
> +
> +typedef char vec __attribute__((vector_size(size)));
> +
> +void f(char*) __attribute__((nonnull(pos)))
Jakub Jelinek writes:
> On Tue, Feb 04, 2014 at 10:47:49AM +, Richard Sandiford wrote:
>> I wondered whether we could model the load of the stack pointer as an
>> addition in cases where that is safe (e.g. it would require !calls_eh_return
>> at least). But that would only work in functions t
This patch adds return and simple_return patterns to the s390 backend,
which eanbles shrink-wrapping and conditional returns to be used.
Perhaps the only subtle thing is the handling of call-clobbered base
registers. The idea is to emit the initialising main_pool pattern in
both early_mach -- at
This patch fixes the CFA notes used when an epilogue restores a GPR from
an FPR. It also makes sure that s390_optimize_prologue preserves the
CFA information.
Tested in the same way as the previous patch. OK to install?
Thanks,
Richard
gcc/
* config/s390/s390.c (s390_restore_gprs_from
On Tue, 4 Feb 2014, Richard Biener wrote:
> On Tue, 4 Feb 2014, Dominique Dhumieres wrote:
>
> > Richard,
> >
> > With your patch at http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00144.html
> > I get multiple ICEs when testing with
> > check-gfortran RUNTESTFLAGS="--target_board=unix'{-m32/-flto,
On Tue, 4 Feb 2014, Dominique Dhumieres wrote:
> Richard,
>
> With your patch at http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00144.html
> I get multiple ICEs when testing with
> check-gfortran RUNTESTFLAGS="--target_board=unix'{-m32/-flto,-m64/-flto}'"
>
> They are of the kind
>
> lto1: intern
s390_emit_prologue performs some optimisations on the function before
emitting the prologue. It also rewrites constant pool accesses to make
the base register explicit.
Doing this in the prologue pattern makes the interaction with direct
returns and simple_returns less obvious, so this patch spli
Richard,
With your patch at http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00144.html
I get multiple ICEs when testing with
check-gfortran RUNTESTFLAGS="--target_board=unix'{-m32/-flto,-m64/-flto}'"
They are of the kind
lto1: internal compiler error: in mentions_vars_p, at lto/lto.c:972
Note that
On Tue, Feb 04, 2014 at 10:47:49AM +, Richard Sandiford wrote:
> I wondered whether we could model the load of the stack pointer as an
> addition in cases where that is safe (e.g. it would require !calls_eh_return
> at least). But that would only work in functions that don't need a frame
> poi
Hi!
This backports upstream fix for __tsan_default_options.
Committed to trunk.
2014-02-04 Jakub Jelinek
PR sanitizer/60055
* tsan/tsan_flags.cc (__tsan_default_options): Add
SANITIZER_INTERFACE_ATTRIBUTE. Backport from upstream r200747.
* tsan/tsan_rtl.cc (__
Sorry, looks like I missed the stage 3 deadline by a day, but:
we'd like to add support for shrink-wrapping and conditional returns
to s390(x) for 4.9. Doing this showed up a problem with the way that
var-tracking handles the load-multiple instruction that s390 uses in
many function epilogues.
st
On 01/27/2014 08:09 PM, Jeff Law wrote:
+ if (dereference)
+ warning_at ((gimple_location (use_stmt)
+? gimple_location (use_stmt)
+: gimple_phi_arg_location (phi, i)),
+
Hi,
On 02/04/2014 10:55 AM, Rainer Orth wrote:
Paolo Carlini writes:
a very minor ICE on invalid regression, but since we explicitly allow for
redeclarations (also see comments in declare_global_var) we may as well
avoid crashing, at least in mainline. Tested x86_64-linux.
The test FAILs on
AFAICT the gcc.dg/binop-xor1.c test is XPASSing everywhere since about
20131114:
XPASS: gcc.dg/binop-xor1.c scan-tree-dump-times optimized "^" 1
To reduce testsuite noise, I'd like to apply the following patch.
Tested with the appropriate runtest invocations on i386-pc-solaris2.11
and x86_64-
On 03/02/14 10:22, Ramana Radhakrishnan wrote:
On 02/03/14 09:58, Renlin Li wrote:
Hi all,
This is a simple patch which fix a type error found in
gcc/testsuite/gcc.target/arm/ftest-armv7a-thumb.c
Okay for trunk?
Ok.
Hi all,
I've committed this as r207457.
Kyrill
Ramana
Regards,
Renli
Paolo Carlini writes:
> a very minor ICE on invalid regression, but since we explicitly allow for
> redeclarations (also see comments in declare_global_var) we may as well
> avoid crashing, at least in mainline. Tested x86_64-linux.
The test FAILs on Solaris which doesn't have __cxa_atexit:
FAI
On Tue, 28 Jan 2014, Jakub Jelinek wrote:
> On Tue, Jan 28, 2014 at 10:40:51AM +0100, Richard Biener wrote:
> > The patch doesn't make much sense to me. I think the problem is that
> > NAMELIST_DECL is output in a ref section (LTO_namelist_decl_ref) but
> > the output routine writes other refs (v
Ian Lance Taylor writes:
>> Could you please take care of that, provided the RMs approve? The patch
>> was ok two weeks ago and is completely Solaris-specific, so I'd like to
>> get it into the 4.9.0 release.
>
> I was just waiting for you to commit it elsewhere.
And I was waiting for you to co
Hi, I was wondering if it's a good idea to add -Wheader-guard option
that warns on mismatches between #ifndef and #define lines
in header guard, similar to -Wheader-guard in clang-3.4 ?
(http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html)
I have implemented patch for -Wheader-guard (p
1 - 100 of 110 matches
Mail list logo
