Re: Testing ICEs resulting from profile directed optimization
> > -Original Message- > > From: Jan Hubicka [mailto:hubi...@ucw.cz] > > Sent: 10 October 2013 17:24 > > To: Paulo Matos > > Cc: gcc@gcc.gnu.org > > Subject: Re: Testing ICEs resulting from profile directed optimization > > > > > Hi, > > > > > > I have found an ICE reported as (PR 58682) and I have a fix. > > Cool :) > > > > > However the testcase involved: > > > * compiling a 5 .i files with -fprofile-generate= > > > * running the executable > > > * compiling the same 5 .i files with -fprofile-use=, and only then getting > > the ICE. > > > > > > Is there anything in the GCC testing framework that allows this kind of > > testing as opposed to the straightforward single test compilation? > > > > You probably only want to put those tests into gcc.dg/tree-prof directory. > > Those tests are run > > with FDO. You will need to convert them to .c files. > > > > I have looked at the infrastructure and it seems it only supports single file > tests. You can use dg-additional-sources for multi-file testcases. I am not sure it is what you need, I will try to take a look tomorrow.. Honza > I was not able to reduce the ICE to a single file. The reason for this is > because I need to compile the project, > execute it and compile it again. > > I could in theory simply add the gcda file plus the single .i (transformed > into .c) that causes the ICE but > this would only work for the version of gcc that creates the gcda so it seems > to be a no-go. > > Any suggestions? > > -- > Paulo Matos
Re: Where does the gcc_tg.o linked in tests come from?
On Fri, Oct 11, 2013 at 2:49 PM, Andrew Pinski wrote: > On Fri, Oct 11, 2013 at 2:39 PM, Brooks Moses wrote: >> Where on earth does this gcc_tg.o file come from? I'm completely lost >> here -- I can't find any log that indicates it getting built, or any >> reference to "gcc_tg" in the source tree. And web-searching is no >> help either; the only reference I found was someone else saying they >> didn't know where it came from. > > It comes from dejagnu and only when needs_status_wrapper is set to 1 > in your board file like I have for a bare metal board: >set_board_info needs_status_wrapper 1 > dejagnu calls build_wrapper inside /usr/share/dejagnu/libgloss.exp > which does the building and the setting up the wrapping feature. Ah, no wonder I couldn't find it in the GCC sources. Thanks! - Brooks
Re: Where does the gcc_tg.o linked in tests come from?
On Fri, Oct 11, 2013 at 2:39 PM, Brooks Moses wrote: > I'm trying to reproduce a test failure outside the Dejagnu testsuite, > and I noticed that the file I'm trying to recompile is linked with a > gcc_tg.o file. Based on the missing-symbol errors I get when I don't > include it, it seems to provide things like __wrap_main and so forth. > > Where on earth does this gcc_tg.o file come from? I'm completely lost > here -- I can't find any log that indicates it getting built, or any > reference to "gcc_tg" in the source tree. And web-searching is no > help either; the only reference I found was someone else saying they > didn't know where it came from. It comes from dejagnu and only when needs_status_wrapper is set to 1 in your board file like I have for a bare metal board: set_board_info needs_status_wrapper 1 dejagnu calls build_wrapper inside /usr/share/dejagnu/libgloss.exp which does the building and the setting up the wrapping feature. Thanks, Andrew Pinski > > Thanks for any enlightenment, > - Brooks
Where does the gcc_tg.o linked in tests come from?
I'm trying to reproduce a test failure outside the Dejagnu testsuite, and I noticed that the file I'm trying to recompile is linked with a gcc_tg.o file. Based on the missing-symbol errors I get when I don't include it, it seems to provide things like __wrap_main and so forth. Where on earth does this gcc_tg.o file come from? I'm completely lost here -- I can't find any log that indicates it getting built, or any reference to "gcc_tg" in the source tree. And web-searching is no help either; the only reference I found was someone else saying they didn't know where it came from. Thanks for any enlightenment, - Brooks
Re: delay slot of conditionnal branch with no annuled jump strategy
On 10/11/13 05:51, BELBACHIR Selim wrote: Does this happen systematically with the compare insn or is it isolated? I encountered this problem only once in gcc testsuite (gcc.c-torture/execute/builtins/strncat-chk.c). I think the problem is quite rare because gcc does not put often a parallel compare insn into the delay slot of a conditional jump, and when it happens it's not certain that the register clobbered by the parallel compare is used in the fall-through path after the conditional jump. So I would say the problem is isolated. This looks like a bug in the dbr pass (several of them have been fixed since 4.5.2) but it's impossible to be more precise without further details. The support of annulled instructions is not required for proper operation. My current investigation showed that when I comment the call to 'fill_eager_delay_slots' in ' reorg.c:dbr_schedule' the problem disappear. The problem does not come from the 2 others techniques for filling delay slots : 'fill_simple_delay_slots' or 'relax_delay_slots'. To illustrate the problem previously described in asm, I copied and commented the rtl dumps below : I'd look at the code in resource.c very carefully, it's possible it's not properly handling all the side effects of the parallel. jeff
Re: Invalid tree node causes segfault in diagnostic
> While I am at it, can I patch backends as well? For example > mep/mep.c has an occurrence of tree_code_name[TREE_CODE (... The mep change is pre-approved :-)
RE: Invalid tree node causes segfault in diagnostic
Paulo Matos wrote: >> -Original Message- >> From: Richard Biener [mailto:richard.guent...@gmail.com] >> Sent: 11 October 2013 13:47 >> To: Paulo Matos >> Cc: gcc@gcc.gnu.org >> Subject: Re: Invalid tree node causes segfault in diagnostic >> >> >> Hmm. We have several places accessing tree_code_name without >checking. >> May I suggest to abstract accesses to it with a function call which >can >> do the proper checking and return "" instead? >> > >Sounds good. I will prepare a patch with the change suggested for >review. >While I am at it, can I patch backends as well? For example mep/mep.c >has an occurrence >of tree_code_name[TREE_CODE (... Sure. Tree_code_name should be static inside tree.c after the patch. Thanks, Richard.
Re: function attributes
On Fri, Oct 11, 2013 at 9:20 AM, Nagaraju Mekala wrote: > > I observed that in rs6000 port longcall is implemented by using > CALL_LONG define. > #define CALL_LONG 0x0008 /* always call indirect */ > In the md file they are checking the operand with CALL_LONG > if (INTVAL (operands[3]) & CALL_LONG) > operands[1] = rs6000_longcall_ref (operands[1]); > In my port I dont have suchthing to compare. Can we somehow parse the > tree chain and check the attributes of the functions.. Look at init_cumulative_args in rs6000.c to see how CALL_LONG is set based on the function attribute. Ian
Re: function attributes
Hi Ian,
Thanks for the reply.
Please accept my apologize for including both the mail chains. I
will make sure not to repeat this again.
On Fri, Oct 11, 2013 at 7:32 PM, Ian Lance Taylor wrote:
> On Fri, Oct 11, 2013 at 2:48 AM, Nagaraju Mekala
> wrote:
>>
>> My question is how to find the attributes of a function which we are
>> going to call
>>
>> Problem:
>>
>>Generally while calling a function we use branch instruction
>>
>>ex: br r5,
>>
>> But when we have a function with "super" attribute then I need to
>> call the function with different branch instruction
>>
>> ex: bk r5,
>>
>>
>> In the prologue of the function I was able to get the attribute
>> details using below code
>>
>> super_table_handler_function_p (tree func)
>> {
>> tree a;
>> if (TREE_CODE (func) != FUNCTION_DECL)
>> return 0;
>> a = lookup_attribute ("super", DECL_ATTRIBUTES (func));
>> return a != NULL_TREE;
>> }
>>
>>
>> How to get the information of function attributes even before entering
>> to prologue or during function call itself??
>
>
> Please never send e-mail to both gcc-h...@gcc.gnu.org and
> gcc@gcc.gnu.org. Thanks. This message could have been sent to either
> list, but not both.
>
> To answer your question: look at how the rs6000 port handles the
> longcall attribute.
>
I observed that in rs6000 port longcall is implemented by using
CALL_LONG define.
#define CALL_LONG 0x0008 /* always call indirect */
In the md file they are checking the operand with CALL_LONG
if (INTVAL (operands[3]) & CALL_LONG)
operands[1] = rs6000_longcall_ref (operands[1]);
In my port I dont have suchthing to compare. Can we somehow parse the
tree chain and check the attributes of the functions..
> Ian
Thanks,
Nagaraju
RE: Invalid tree node causes segfault in diagnostic
> -Original Message- > From: Richard Biener [mailto:richard.guent...@gmail.com] > Sent: 11 October 2013 13:47 > To: Paulo Matos > Cc: gcc@gcc.gnu.org > Subject: Re: Invalid tree node causes segfault in diagnostic > > > Hmm. We have several places accessing tree_code_name without checking. > May I suggest to abstract accesses to it with a function call which can > do the proper checking and return "" instead? > Sounds good. I will prepare a patch with the change suggested for review. While I am at it, can I patch backends as well? For example mep/mep.c has an occurrence of tree_code_name[TREE_CODE (... -- Paulo Matos
Re: [RFC] Vectorization of indexed elements
On Fri, Oct 11, 2013 at 03:54:08PM +0100, Vidya Praveen wrote:
> Here's a compilable example:
>
> void
> foo (int *__restrict__ a,
> int *__restrict__ b,
> int *__restrict__ c)
> {
> int i;
>
> for (i = 0; i < 8; i++)
> a[i] = b[i] * c[2];
> }
>
> This is vectorized by duplicating c[2] now. But I'm trying to take advantage
> of target instructions that can take a vector register as second argument but
> use only one element (by using the same value for all the lanes) of the
> vector register.
>
> Eg. mul , , [index]
> mla , , [index] // multiply and add
>
> But for a loop like the one in the C example given, I will have to load the
> c[2] in one element of the vector register (leaving the remaining unused)
> rather. This is why I was proposing to load just one element in a vector
> register (what I meant as "lane specific load"). The benefit of doing this is
> that we avoid explicit duplication, however such a simplification can only
> be done where such support is available - the reason why I was thinking in
> terms of optional standard pattern name. Another benefit is we will also be
> able to support scalars in the expression like in the following example:
>
> void
> foo (int *__restrict__ a,
> int *__restrict__ b,
> int c)
> {
> int i;
>
> for (i = 0; i < 8; i++)
> a[i] = b[i] * c;
> }
So just during combine let the broadcast operation be combined with the
arithmetics? Intel AVX512 ISA has similar feature, not sure what exactly
they are doing for this. That said, the broadcast is likely going to be
hoisted before the loop, and in that case is it really cheaper to have
it unbroadcasted in a vector register rather than to broadcast it before the
loop and just use there?
Jakub
Re: [RFC] Vectorization of indexed elements
On Tue, Oct 01, 2013 at 09:26:25AM +0100, Richard Biener wrote:
> On Mon, 30 Sep 2013, Vidya Praveen wrote:
>
> > On Mon, Sep 30, 2013 at 02:19:32PM +0100, Richard Biener wrote:
> > > On Mon, 30 Sep 2013, Vidya Praveen wrote:
> > >
> > > > On Fri, Sep 27, 2013 at 04:19:45PM +0100, Vidya Praveen wrote:
> > > > > On Fri, Sep 27, 2013 at 03:50:08PM +0100, Vidya Praveen wrote:
> > > > > [...]
> > > > > > > > I can't really insist on the single lane load.. something like:
> > > > > > > >
> > > > > > > > vc:V4SI[0] = c
> > > > > > > > vt:V4SI = vec_duplicate:V4SI (vec_select:SI vc:V4SI 0)
> > > > > > > > va:V4SI = vb:V4SI vt:V4SI
> > > > > > > >
> > > > > > > > Or is there any other way to do this?
> > > > > > >
> > > > > > > Can you elaborate on "I can't really insist on the single lane
> > > > > > > load"?
> > > > > > > What's the single lane load in your example?
> > > > > >
> > > > > > Loading just one lane of the vector like this:
> > > > > >
> > > > > > vc:V4SI[0] = c // from the above scalar example
> > > > > >
> > > > > > or
> > > > > >
> > > > > > vc:V4SI[0] = c[2]
> > > > > >
> > > > > > is what I meant by single lane load. In this example:
> > > > > >
> > > > > > t = c[2]
> > > > > > ...
> > > > > > vb:v4si = b[0:3]
> > > > > > vc:v4si = { t, t, t, t }
> > > > > > va:v4si = vb:v4si vc:v4si
> > > > > >
> > > > > > If we are expanding the CONSTRUCTOR as vec_duplicate at vec_init, I
> > > > > > cannot
> > > > > > insist 't' to be vector and t = c[2] to be vect_t[0] = c[2] (which
> > > > > > could be
> > > > > > seen as vec_select:SI (vect_t 0) ).
> > > > > >
> > > > > > > I'd expect the instruction
> > > > > > > pattern as quoted to just work (and I hope we expand an uniform
> > > > > > > constructor { a, a, a, a } properly using vec_duplicate).
> > > > > >
> > > > > > As much as I went through the code, this is only done using
> > > > > > vect_init. It is
> > > > > > not expanded as vec_duplicate from, for example,
> > > > > > store_constructor() of expr.c
> > > > >
> > > > > Do you see any issues if we expand such constructor as vec_duplicate
> > > > > directly
> > > > > instead of going through vect_init way?
> > > >
> > > > Sorry, that was a bad question.
> > > >
> > > > But here's what I would like to propose as a first step. Please tell me
> > > > if this
> > > > is acceptable or if it makes sense:
> > > >
> > > > - Introduce standard pattern names
> > > >
> > > > "vmulim4" - vector muliply with second operand as indexed operand
> > > >
> > > > Example:
> > > >
> > > > (define_insn "vmuliv4si4"
> > > >[set (match_operand:V4SI 0 "register_operand")
> > > > (mul:V4SI (match_operand:V4SI 1 "register_operand")
> > > > (vec_duplicate:V4SI
> > > > (vec_select:SI
> > > > (match_operand:V4SI 2 "register_operand")
> > > > (match_operand:V4SI 3 "immediate_operand)]
> > > > ...
> > > > )
> > >
> > > We could factor this with providing a standard pattern name for
> > >
> > > (define_insn "vdupi"
> > > [set (match_operand: 0 "register_operand")
> > >(vec_duplicate:
> > > (vec_select:
> > > (match_operand: 1 "register_operand")
> > > (match_operand:SI 2 "immediate_operand]
> >
> > This is good. I did think about this but then I thought of avoiding the need
> > for combiner patterns :-)
> >
> > But do you find the lane specific mov pattern I proposed, acceptable?
>
> The specific mul pattern? As said, consider factoring to vdupi to
> avoid an explosion in required special optabs.
>
> > > (you use V4SI for the immediate?
> >
> > Sorry typo again!! It should've been SI.
> >
> > > Ideally vdupi has another custom
> > > mode for the vector index).
> > >
> > > Note that this factored pattern is already available as vec_perm_const!
> > > It is simply (vec_perm_const:V4SI ).
> > >
> > > Which means that on the GIMPLE level we should try to combine
> > >
> > > el_4 = BIT_FIELD_REF ;
> > > v_5 = { el_4, el_4, ... };
> >
> > I don't think we reach this state at all for the scenarios in discussion.
> > what we generally have is:
> >
> > el_4 = MEM_REF < array + index*size >
> > v_5 = { el_4, ... }
> >
> > Or am I missing something?
>
> Well, but in that case I doubt it is profitable (or even valid!) to
> turn this into a vector lane load from the array. If it is profitable
> to perform a vector read (because we're going to use the other elements
> of the vector as well) then the vectorizer should produce a vector
> load and materialize the uniform vector from one of its elements.
>
> Maybe at this point you should show us a compilable C testcase
> with a loop that should be vectorized using your instructions in
> the end?
Here's a compilable example:
void
foo (int *__restrict__ a,
int *__restrict__ b,
int *__restrict__ c)
{
int i;
for (i = 0; i < 8; i++)
a[i] = b[i] * c[2];
}
This is vecto
GCC IRA support for Register Banks.
Dear All, Did gcc provide any hook to support register bank like Our private target has two banks of register file like A and B registers under Bank-0 and A and B (same name weired ha ) registers under Bank-1. asm sample like load A ,mem-0//By default the register referred from bank-0 load B ,mem-1 add A,B set b1 // select bank-1 load A, mem1-0 load B ,mem1-1 add A,B store A mem1-0 unset b1//revert it back to bank-0 load B mem1-0 //again the register referred from bank-0 add A,B ret Can we represent above reg bank requirement ???,Please let me know if its so . Thanks ~Umesh
Re: GCC 4.8.2 Status Report / plugin related corrections
On Wed, Oct 09, 2013 at 01:04:52PM +0200, Jakub Jelinek wrote:
> Status
> ==
>
> The GCC 4.8.2-rc1 release candidate has been released.
> The branch is frozen now, all changes require release manager approval
> until the final release of GCC 4.8.2 which should happen roughly
> one week after the release candidate.
I still believe that http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00382.html
& http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00036.html
should also go into 4.8
(these two small patches have been accepted into trunk)
Both patches addresses bugs related to plugins.
The first enables a = in a plugin argument, and the second enable .cc files to
gengtype.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: function attributes
On Fri, Oct 11, 2013 at 2:48 AM, Nagaraju Mekala wrote:
>
> My question is how to find the attributes of a function which we are
> going to call
>
> Problem:
>
>Generally while calling a function we use branch instruction
>
>ex: br r5,
>
> But when we have a function with "super" attribute then I need to
> call the function with different branch instruction
>
> ex: bk r5,
>
>
> In the prologue of the function I was able to get the attribute
> details using below code
>
> super_table_handler_function_p (tree func)
> {
> tree a;
> if (TREE_CODE (func) != FUNCTION_DECL)
> return 0;
> a = lookup_attribute ("super", DECL_ATTRIBUTES (func));
> return a != NULL_TREE;
> }
>
>
> How to get the information of function attributes even before entering
> to prologue or during function call itself??
Please never send e-mail to both gcc-h...@gcc.gnu.org and
gcc@gcc.gnu.org. Thanks. This message could have been sent to either
list, but not both.
To answer your question: look at how the rs6000 port handles the
longcall attribute.
Ian
Re: Invalid tree node causes segfault in diagnostic
On Fri, Oct 11, 2013 at 12:57 PM, Paulo Matos wrote: > Hello, > > I have a testcase that, during parsing, generates an invalid tree. This > invalid tree triggers tree_check_failed, which was expecting a string_cst. > tree_check_failed calls internal_error with tree_code_name[TREE_CODE (node)] > without checking that TREE_CODE (node) is valid. > > I attach a patch as a suggestion of a fix. I would like some comments. > > This patch eliminates the segfault and generates the error: > ../../../../../source/adsl-mech/components/common/PsdInfo.c:717:1: internal > compiler error: tree check: expected string_cst, have (invalid code name) in > get_named_section, at varasm.c:415 > > This is obviously another thing I still have to understand why it's happening. > The testcase is still too big (1Mb) and I haven't reproduced it with any > upstream port so I am not reporting a bug yet. Hmm. We have several places accessing tree_code_name without checking. May I suggest to abstract accesses to it with a function call which can do the proper checking and return "" instead? Thanks, Richard. > For the patch attached: > > 2013-10-11 Paulo Matos > > * tree.c (tree_check_failed): Check that TREE_CODE is valid before > passing it to tree_code_name. > > > Paulo Matos > >
[buildrobot] OMP: r203408 probably needs another operator& returning bool
Hi! The recent change probably gave us this[1]: g++ -c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -Ic-family -I../../../../gcc/gcc -I../../../../gcc/gcc/c-family -I../../../../gcc/gcc/../include -I../../../../gcc/gcc/../libcpp/include -I../../../../gcc/gcc/../libdecnumber -I../../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../../gcc/gcc/../libbacktrace-o c-family/c-omp.o -MT c-family/c-omp.o -MMD -MP -MF c-family/.deps/c-omp.TPo ../../../../gcc/gcc/c-family/c-omp.c ../../../../gcc/gcc/c-family/c-omp.c: In function ‘void c_omp_split_clauses(location_t, tree_code, omp_clause_mask, tree, tree_node**)’: ../../../../gcc/gcc/c-family/c-omp.c:634:12: error: could not convert ‘mask.omp_clause_mask::operator&(omp_clause_mask(1ul).omp_clause_mask::operator<<(22))’ from ‘omp_clause_mask’ to ‘bool’ if (mask & (OMP_CLAUSE_MASK_1 << PRAGMA_OMP_CLAUSE_NUM_THREADS)) ^ ../../../../gcc/gcc/c-family/c-omp.c:694:13: error: could not convert ‘mask.omp_clause_mask::operator&(omp_clause_mask(1ul).omp_clause_mask::operator<<(29))’ from ‘omp_clause_mask’ to ‘bool’ if (mask & (OMP_CLAUSE_MASK_1 << PRAGMA_OMP_CLAUSE_SCHEDULE)) ^ ../../../../gcc/gcc/c-family/c-omp.c:696:17: error: could not convert ‘mask.omp_clause_mask::operator&(omp_clause_mask(1ul).omp_clause_mask::operator<<(8))’ from ‘omp_clause_mask’ to ‘bool’ if (mask & (OMP_CLAUSE_MASK_1 ^ ../../../../gcc/gcc/c-family/c-omp.c:732:13: error: could not convert ‘mask.omp_clause_mask::operator&(omp_clause_mask(1ul).omp_clause_mask::operator<<(22))’ from ‘omp_clause_mask’ to ‘bool’ if (mask & (OMP_CLAUSE_MASK_1 << PRAGMA_OMP_CLAUSE_NUM_THREADS)) ^ ../../../../gcc/gcc/c-family/c-omp.c:734:17: error: could not convert ‘mask.omp_clause_mask::operator&(omp_clause_mask(1ul).omp_clause_mask::operator<<(21).omp_clause_mask::operator|(omp_clause_mask(1ul).omp_clause_mask::operator<<(8)))’ from ‘omp_clause_mask’ to ‘bool’ if (mask & ((OMP_CLAUSE_MASK_1 << PRAGMA_OMP_CLAUSE_NUM_TEAMS) ^ ../../../../gcc/gcc/c-family/c-omp.c:743:14: error: could not convert ‘mask.omp_clause_mask::operator&(omp_clause_mask(1ul).omp_clause_mask::operator<<(21))’ from ‘omp_clause_mask’ to ‘bool’ if (mask & (OMP_CLAUSE_MASK_1 ^ ../../../../gcc/gcc/c-family/c-omp.c:754:18: error: could not convert ‘mask.omp_clause_mask::operator&(omp_clause_mask(1ul).omp_clause_mask::operator<<(21))’ from ‘omp_clause_mask’ to ‘bool’ else if (mask & (OMP_CLAUSE_MASK_1 << PRAGMA_OMP_CLAUSE_NUM_TEAMS)) ^ ../../../../gcc/gcc/c-family/c-omp.c:760:18: error: could not convert ‘mask.omp_clause_mask::operator&(omp_clause_mask(1ul).omp_clause_mask::operator<<(8))’ from ‘omp_clause_mask’ to ‘bool’ else if (mask & (OMP_CLAUSE_MASK_1 ^ ../../../../gcc/gcc/c-family/c-omp.c:780:17: error: could not convert ‘mask.omp_clause_mask::operator&(omp_clause_mask(1ul).omp_clause_mask::operator<<(22))’ from ‘omp_clause_mask’ to ‘bool’ if (mask & (OMP_CLAUSE_MASK_1 << PRAGMA_OMP_CLAUSE_NUM_THREADS)) ^ ../../../../gcc/gcc/c-family/c-omp.c:787:13: error: could not convert ‘mask.omp_clause_mask::operator&(omp_clause_mask(1ul).omp_clause_mask::operator<<(29))’ from ‘omp_clause_mask’ to ‘bool’ if (mask & (OMP_CLAUSE_MASK_1 << PRAGMA_OMP_CLAUSE_SCHEDULE)) ^ ../../../../gcc/gcc/c-family/c-omp.c:792:17: error: could not convert ‘mask.omp_clause_mask::operator&(omp_clause_mask(1ul).omp_clause_mask::operator<<(22))’ from ‘omp_clause_mask’ to ‘bool’ if (mask & (OMP_CLAUSE_MASK_1 << PRAGMA_OMP_CLAUSE_NUM_THREADS)) ^ ../../../../gcc/gcc/c-family/c-omp.c:809:13: error: could not convert ‘mask.omp_clause_mask::operator&(omp_clause_mask(1ul).omp_clause_mask::operator<<(21))’ from ‘omp_clause_mask’ to ‘bool’ if (mask & (OMP_CLAUSE_MASK_1 << PRAGMA_OMP_CLAUSE_NUM_TEAMS)) ^ ../../../../gcc/gcc/c-family/c-omp.c:840:13: error: could not convert ‘mask.omp_clause_mask::operator&(omp_clause_mask(1ul).omp_clause_mask::operator<<(29))’ from ‘omp_clause_mask’ to ‘bool’ if (mask & (OMP_CLAUSE_MASK_1 << PRAGMA_OMP_CLAUSE_SCHEDULE)) ^ ../../../../gcc/gcc/c-family/c-omp.c:842:17: error: could not convert ‘mask.omp_clause_mask::operator&(omp_clause_mask(1ul).omp_clause_mask::operator<<(21))’ from ‘omp_clause_mask’ to ‘bool’ if (mask & (OMP_CLAUSE_MASK_1 << PRAGMA_OMP_CLAUSE_NUM_TEAMS)) ^ ../../../../gcc/gcc/c-family/c-omp.c:855:22: error: could not convert ‘mask.omp_clause_mask::operator&(omp_clause_mask(1ul).omp_clause_mask::operator<<(22))’ from ‘omp_clause_mask’ to ‘b
RE: delay slot of conditionnal branch with no annuled jump strategy
> I have a gcc 4.6.1 port that has the same sort of problems. I tried > selectively porting some patches from later 4.6 releases, but they didn't > seem to actually address the issue. I haven't looked at the trunk to see if > there are patches that are more apropos. I looked at the revisions of reorg.c in gitHub since gcc 4.5.2 but I did not see any obvious correction concerning this issue.
RE: delay slot of conditionnal branch with no annuled jump strategy
> Does this happen systematically with the compare insn or is it isolated?
I encountered this problem only once in gcc testsuite
(gcc.c-torture/execute/builtins/strncat-chk.c).
I think the problem is quite rare because gcc does not put often a parallel
compare insn into the delay slot of a conditional jump,
and when it happens it's not certain that the register clobbered by the
parallel compare is used in the fall-through path after the conditional jump.
So I would say the problem is isolated.
> This looks like a bug in the dbr pass (several of them have been fixed since
> 4.5.2) but it's impossible to be more precise without further details. The
> support of annulled instructions is not required for proper operation.
My current investigation showed that when I comment the call to
'fill_eager_delay_slots' in ' reorg.c:dbr_schedule' the problem disappear.
The problem does not come from the 2 others techniques for filling delay slots
: 'fill_simple_delay_slots' or 'relax_delay_slots'.
To illustrate the problem previously described in asm, I copied and commented
the rtl dumps below :
--
* Dumps before dbr scheduling (dump xx.214r.barriers)
--
### compare $R5 to 0 ($R1 is clobbered)
(insn 38 97 39 test.c:14:21 (parallel [
(set:CC (reg:CC 56 $CCI)
(compare:CC (reg:SI 18 $R5 [108])
(const_int 0 [0x0])))
(clobber (reg:SI 18 $R1 [109]))
]) 45 {compare} (expr_list:REG_DEAD (reg:SI 18 $R5 [108])
(nil)))
### conditionnal branch to label 51
(jump_insn 39 38 71 test.c:14:21 (set (pc)
(if_then_else (eq (reg:CC 56 $CCI)
(const_int 0 [0x0]))
(label_ref 51)
(pc))) 131 {jmpif} (expr_list:REG_DEAD (reg:CC 56 $CCI)
(expr_list:REG_BR_PROB (const_int 900 [0x384])
(nil)))
-> 51)
(code_label 71 39 70 6 "" [1 uses])
(note 70 71 41 [bb 3] NOTE_INSN_BASIC_BLOCK)
### increment $R0 in fall-through path
(insn 41 70 43 test.c:16:7 (set (reg/v:SI 16 $R0 [orig:85 len ] [85])
(plus:SI (reg/v:SI 16 $R0 [orig:85 len ] [85])
(const_int 1 [0x1]))) 40 {addsi3_nocompare} (nil))
### I have hidden some insn not very usefull
[...]
### target of the conditionnal jump
(code_label 51 50 52 3 "" [1 uses])
(note 52 51 53 [bb 4] NOTE_INSN_BASIC_BLOCK)
### compare $R4 to $R0 ($R0 is clobbered)
(insn 53 52 56 test.c:19:11 (parallel [
(set:CC (reg:CC 56 $CCI)
(compare:CC (reg/v:SI 20 $R4 [orig:93 size ] [93])
(reg/v:SI 16 $R0 [orig:85 len ] [85])))
(clobber (reg:SI 16 $R0 [117]))
]) 45 {compare} (expr_list:REG_DEAD (reg/v:SI 20 $R4 [orig:93 size ]
[93])
(expr_list:REG_DEAD (reg/v:SI 16 $R0 [orig:85 len ] [85])
(nil
(note 56 53 57 NOTE_INSN_DELETED)
### conditionnal call symbol_ref
(call_insn 57 56 60 test.c:20:16 (cond_exec (leu (reg:CC 56 $CCI)
(const_int 0 [0x0]))
(parallel [
(set (reg:SI 16 $R0)
(call (mem:SI (symbol_ref:SI ("__chk_fail") [flags 0x41]
) [0 S4 A32])
(const_int 0 [0x0])))
(clobber (reg:SI 1 $C1))
])) 161 {call_value_cond} (expr_list:REG_DEAD (reg:SI 1 $C1)
--
* Dumps after dbr scheduling (dump xx.c.215r.db)
--
### compare $R5 to 0 ($R1 is clobbered)
(insn 38 97 121 test.c:14:21 (parallel [
(set:CC (reg:CC 56 $CCI)
(compare:CC (reg:SI 18 $R5 [108])
(const_int 0 [0x0])))
(clobber (reg:SI 18 $R1 [109]))
]) 45 {compare} (expr_list:REG_DEAD (reg:SI 18 $R5 [108])
(nil)))
### conditionnal branch to label 51 with delay slot filled by parallel [compare
$R4 to $R0, clobber $R0].
### the parallel compare was taken from the conditional jump 'target' path and
should not have any side effect
### on the 'fall-through' path. But unfortunately the clobber $R0 has side
effect ...
(insn 121 38 70 test.c:14:21 (sequence [
(jump_insn 39 38 119 test.c:14:21 (set (pc)
(if_then_else (eq (reg:CC 56 $CCI)
(const_int 0 [0x0]))
(label_ref:SI 120)
(pc))) 131 {jmpif} (expr_list:REG_BR_PRED (const_int 48
[0x30])
(expr_list:REG_DEAD (reg:CC 56 $CCI)
(expr_list:REG_BR_PROB (const_int 900 [0x384])
(nil
-> 120)
(insn/s 119 39 70 (parallel [
(set:CC (reg:CC 56 $CCI)
(compare:CC (reg/v:SI 20 $R4 [orig:93 size ] [93])
(reg/v:SI 16 $R0
Invalid tree node causes segfault in diagnostic
Hello, I have a testcase that, during parsing, generates an invalid tree. This invalid tree triggers tree_check_failed, which was expecting a string_cst. tree_check_failed calls internal_error with tree_code_name[TREE_CODE (node)] without checking that TREE_CODE (node) is valid. I attach a patch as a suggestion of a fix. I would like some comments. This patch eliminates the segfault and generates the error: ../../../../../source/adsl-mech/components/common/PsdInfo.c:717:1: internal compiler error: tree check: expected string_cst, have (invalid code name) in get_named_section, at varasm.c:415 This is obviously another thing I still have to understand why it's happening. The testcase is still too big (1Mb) and I haven't reproduced it with any upstream port so I am not reporting a bug yet. For the patch attached: 2013-10-11 Paulo Matos * tree.c (tree_check_failed): Check that TREE_CODE is valid before passing it to tree_code_name. Paulo Matos tree_check_failed.patch Description: tree_check_failed.patch
function attributes
Hi,
I am working on GCC-4.6.4 version ported to a embedded target which
is similar to frv.
My question is how to find the attributes of a function which we are
going to call
Problem:
Generally while calling a function we use branch instruction
ex: br r5,
But when we have a function with "super" attribute then I need to
call the function with different branch instruction
ex: bk r5,
In the prologue of the function I was able to get the attribute
details using below code
super_table_handler_function_p (tree func)
{
tree a;
if (TREE_CODE (func) != FUNCTION_DECL)
return 0;
a = lookup_attribute ("super", DECL_ATTRIBUTES (func));
return a != NULL_TREE;
}
How to get the information of function attributes even before entering
to prologue or during function call itself??
Thanks,
Nag
RE: Testing ICEs resulting from profile directed optimization
> -Original Message- > From: Jan Hubicka [mailto:hubi...@ucw.cz] > Sent: 10 October 2013 17:24 > To: Paulo Matos > Cc: gcc@gcc.gnu.org > Subject: Re: Testing ICEs resulting from profile directed optimization > > > Hi, > > > > I have found an ICE reported as (PR 58682) and I have a fix. > Cool :) > > > However the testcase involved: > > * compiling a 5 .i files with -fprofile-generate= > > * running the executable > > * compiling the same 5 .i files with -fprofile-use=, and only then getting > the ICE. > > > > Is there anything in the GCC testing framework that allows this kind of > testing as opposed to the straightforward single test compilation? > > You probably only want to put those tests into gcc.dg/tree-prof directory. > Those tests are run > with FDO. You will need to convert them to .c files. > I have looked at the infrastructure and it seems it only supports single file tests. I was not able to reduce the ICE to a single file. The reason for this is because I need to compile the project, execute it and compile it again. I could in theory simply add the gcda file plus the single .i (transformed into .c) that causes the ICE but this would only work for the version of gcc that creates the gcda so it seems to be a no-go. Any suggestions? -- Paulo Matos
