Re: implementation question
On Wed, Apr 30, 2014 at 7:49 PM, Daniel Gutson wrote: > Hi, > >assuming the need to generate code in which > almost everything is used 3x (e.g. 3x registers, > 3 times data, etc.) for a specific purpose (*) for any > given target, > what would be the best way to implement it? > > (let's name this 3ple-voting behavior) > > a) as a forked backend target of each target (e.g. > a 3ple-voting version of x86, a 3ple-voting version > of ARM, etc.) > > b) as a late GIMPLE phase pluging? > > (*) The need comes from radiation bit-flipping > tolerant software (the interested reader may > check http://en.wikipedia.org/wiki/Single_event_upset). > I am interested in SEUs affecting microprocessor registers > and data. > There is a voting technique in which > the subjects under protection are triplicated, so on each operation, > a check is performed whether the three are equal, or two are equal > (in which case the third is fixed), or the three are distinct. > > Would a late GIMPLE phase plugin suffice? > I think that I should manage to get the RTL tree > with the necessary nodes triplicated and let > the backend do its job, right? Or, am I forgetting > any backend pass that may optimize/get screwed > because of this? It really depends on how "3x" should materialize in the end. How do you triplicate ops with side-effects? If you only triplicate ops without side-effects what is the sink that keeps the duplicated ops live? Richard. > Thanks! > >Daniel.
Re: jump_table_data and active_insn_p
On Mon, Mar 17, 2014 at 12:51 PM, Paulo Matos wrote:
> Why is jump_table_data an active_insn?
> int
> active_insn_p (const_rtx insn)
> {
> return (CALL_P (insn) || JUMP_P (insn)
> || JUMP_TABLE_DATA_P (insn) /* FIXME */
> || (NONJUMP_INSN_P (insn)
> && (! reload_completed
> || (GET_CODE (PATTERN (insn)) != USE
> && GET_CODE (PATTERN (insn)) != CLOBBER;
> }
>
> It is clear that someone [Steven Bosscher] thought it needs fixing but what's
> the problem with just removing it from the OR-expression?
Places using active_insn_p, next_active_insn, prev_active_insn, etc.,
need to be audited to make sure it's safe to remove JUMP_TABLE_DATA
from the OR-expression.
I've done most of that work, but it needs finishing and for that I
need to find some time.
See http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03122.html
Ciao!
Steven
Re: implementation question
On 05/05/2014 08:47 AM, Richard Biener wrote: > It really depends on how "3x" should materialize in the end. > How do you triplicate ops with side-effects? If you only > triplicate ops without side-effects what is the sink that keeps > the duplicated ops live? The vote, surely. CSE would be absolutely determined to get rid of all this redundant work. I guess it'd all have to be done very late or we'd need a new node that CSE can't see through. Would it be enough to mark all nodes that go into the vote as volatile? I guess not: we wouldn't want to generate extra memory traffic. Andrew.
Re: How to access points-to information for function pointers
In some cases, GCC's pta pass does not dump the points-to information for
function pointers which are formal parameters.
Why is it so?
Also it does not store the information for the corresponding SSA name.
However, it dumps pointer information for the parameter variable as
.constprop.0.arg0 = { val1 val2 }
This is the value which should have been stored with the formal parameter.
Is there any way of accessing this value?
Also what is this new variable .constprop.0.arg0 which is
getting created?
It is not a local variable. How do we then access its value?
On Tuesday 29 April 2014 02:47 PM, Richard Biener wrote:
On Tue, Apr 29, 2014 at 8:26 AM, Swati Rathi wrote:
On Monday 28 April 2014 02:46 PM, Richard Biener wrote:
On Sat, Apr 26, 2014 at 4:07 PM, Richard Biener
wrote:
On April 26, 2014 12:31:34 PM CEST, Swati Rathi
wrote:
On Friday 25 April 2014 11:11 PM, Richard Biener wrote:
On April 25, 2014 5:54:09 PM CEST, Swati Rathi
wrote:
Hello,
I am trying to print points-to information for SSA variables as
below.
for (i = 1; i < num_ssa_names; i++)
{
tree ptr = ssa_name (i);
struct ptr_info_def *pi;
if (ptr == NULL_TREE
|| SSA_NAME_IN_FREE_LIST (ptr))
continue;
pi = SSA_NAME_PTR_INFO (ptr);
if (pi)
dump_points_to_info_for (file, ptr);
}
-
My test program is given below :
int main()
{
int *p, i, j;
void (*fp1)();
if (i)
{
p = &i;
fp1 = fun1;
}
else
{
p = &j;
fp1 = fun2;
}
fp1();
printf ("\n%d %d\n", *p, i);
return 0;
}
-
I get the output as :-
p_1, points-to vars: { i j }
fp1_2, points-to vars: { }
-
Why is the pointees for function pointer not getting dumped?
It's just not saved.
Can we modify the code to preserve values for function pointer SSA
names?
Sure.
Index: gcc/tree-ssa-structalias.c
===
--- gcc/tree-ssa-structalias.c (revision 209782)
+++ gcc/tree-ssa-structalias.c (working copy)
@@ -6032,7 +6032,8 @@ set_uids_in_ptset (bitmap into, bitmap f
if (TREE_CODE (vi->decl) == VAR_DECL
|| TREE_CODE (vi->decl) == PARM_DECL
- || TREE_CODE (vi->decl) == RESULT_DECL)
+ || TREE_CODE (vi->decl) == RESULT_DECL
+ || TREE_CODE (vi->decl) == FUNCTION_DECL)
{
/* If we are in IPA mode we will not recompute points-to
sets after inlining so make sure they stay valid. */
Thanks a lot. :) This is of great help.
note that there isn't a convenient way to go back from a bit in the
points-to bitmap to the actual FUNCTION_DECL refered to.
The bitmap is set by identifying the bit using DECL_PT_UID.
For variables, referenced_var_lookup returns the associated variable.
Note that this table is gone from recent GCC.
For FUNCTION_DECL's, all we need to do is store a mapping between uid and
FUNCTION_DECL.
Is this correct?
Correct.
Richard.
Richard.
What is the reason that it is not preserved for function pointers?
Nobody uses this information.
Another alternative approach would be to replicate the code (of
pass_ipa_pta) and use the information before deleting it.
Is there any other way to access this information?
You can of course recompute it when needed.
Richard.
How can I access this information?
Regards,
Swati
GCC 4.8.3 Status Report (2014-05-05)
Status == After releasing GCC 4.9.0 it is now time to think about a GCC 4.8.3 release. The branch remains in release-branch mode for now until we do a first release candidate somewhen next week. This means you have about a week to do backports of important regression fixes - now that GCC 4.9.0 is out you should become more careful of what you backport, avoiding any risk if you can point people to GCC 4.9.0 as a workaround. After GCC 4.8.3 is out the 4.7 branch will also see a last release before it is closed. Quality Data Priority # Change from last report --- --- P10 P2 100+ 30 P3 42- 31 --- --- Total 142- 1 Previous Report === http://gcc.gnu.org/ml/gcc/2013-10/msg00170.html The next report will be sent by the one doing GCC 4.8.3 RC1
Re: How to access points-to information for function pointers
On Mon, May 5, 2014 at 11:38 AM, Swati Rathi wrote:
>
> In some cases, GCC's pta pass does not dump the points-to information for
> function pointers which are formal parameters.
>
> Why is it so?
Depends on the case.
> Also it does not store the information for the corresponding SSA name.
>
> However, it dumps pointer information for the parameter variable as
> .constprop.0.arg0 = { val1 val2 }
>
> This is the value which should have been stored with the formal parameter.
>
> Is there any way of accessing this value?
> Also what is this new variable .constprop.0.arg0 which is
> getting created?
> It is not a local variable. How do we then access its value?
It is the internal representation variable used in the points-to solving
algorithm. You can't access that outside of the pass.
Do you have a (simple) testcase that shows the issue?
Richard.
>
>
> On Tuesday 29 April 2014 02:47 PM, Richard Biener wrote:
>>
>> On Tue, Apr 29, 2014 at 8:26 AM, Swati Rathi
>> wrote:
>>>
>>> On Monday 28 April 2014 02:46 PM, Richard Biener wrote:
On Sat, Apr 26, 2014 at 4:07 PM, Richard Biener
wrote:
>
> On April 26, 2014 12:31:34 PM CEST, Swati Rathi
> wrote:
>>
>> On Friday 25 April 2014 11:11 PM, Richard Biener wrote:
>>>
>>> On April 25, 2014 5:54:09 PM CEST, Swati Rathi
>>
>> wrote:
Hello,
I am trying to print points-to information for SSA variables as
>>
>> below.
for (i = 1; i < num_ssa_names; i++)
{
tree ptr = ssa_name (i);
struct ptr_info_def *pi;
if (ptr == NULL_TREE
|| SSA_NAME_IN_FREE_LIST (ptr))
continue;
pi = SSA_NAME_PTR_INFO (ptr);
if (pi)
dump_points_to_info_for (file, ptr);
}
-
My test program is given below :
int main()
{
int *p, i, j;
void (*fp1)();
if (i)
{
p = &i;
fp1 = fun1;
}
else
{
p = &j;
fp1 = fun2;
}
fp1();
printf ("\n%d %d\n", *p, i);
return 0;
}
-
I get the output as :-
p_1, points-to vars: { i j }
fp1_2, points-to vars: { }
-
Why is the pointees for function pointer not getting dumped?
>>>
>>> It's just not saved.
>>
>> Can we modify the code to preserve values for function pointer SSA
>> names?
>
> Sure.
Index: gcc/tree-ssa-structalias.c
===
--- gcc/tree-ssa-structalias.c (revision 209782)
+++ gcc/tree-ssa-structalias.c (working copy)
@@ -6032,7 +6032,8 @@ set_uids_in_ptset (bitmap into, bitmap f
if (TREE_CODE (vi->decl) == VAR_DECL
|| TREE_CODE (vi->decl) == PARM_DECL
- || TREE_CODE (vi->decl) == RESULT_DECL)
+ || TREE_CODE (vi->decl) == RESULT_DECL
+ || TREE_CODE (vi->decl) == FUNCTION_DECL)
{
/* If we are in IPA mode we will not recompute points-to
sets after inlining so make sure they stay valid. */
>>>
>>> Thanks a lot. :) This is of great help.
>>>
>>>
note that there isn't a convenient way to go back from a bit in the
points-to bitmap to the actual FUNCTION_DECL refered to.
>>>
>>> The bitmap is set by identifying the bit using DECL_PT_UID.
>>> For variables, referenced_var_lookup returns the associated variable.
>>
>> Note that this table is gone from recent GCC.
>>
>>> For FUNCTION_DECL's, all we need to do is store a mapping between uid and
>>> FUNCTION_DECL.
>>> Is this correct?
>>
>> Correct.
>>
>> Richard.
>>
Richard.
>> What is the reason that it is not preserved for function pointers?
>
> Nobody uses this information.
>
>> Another alternative approach would be to replicate the code (of
>> pass_ipa_pta) and use the information before deleting it.
>>
>> Is there any other way to access this information?
>
> You can of course recompute it when needed.
>
> Richard.
>
How can I access this information?
Regards,
Swati
>
>
>
Re: How to access points-to information for function pointers
On Monday 05 May 2014 04:37 PM, Richard Biener wrote:
On Mon, May 5, 2014 at 11:38 AM, Swati Rathi wrote:
In some cases, GCC's pta pass does not dump the points-to information for
function pointers which are formal parameters.
Why is it so?
Depends on the case.
Also it does not store the information for the corresponding SSA name.
However, it dumps pointer information for the parameter variable as
.constprop.0.arg0 = { val1 val2 }
This is the value which should have been stored with the formal parameter.
Is there any way of accessing this value?
Also what is this new variable .constprop.0.arg0 which is
getting created?
It is not a local variable. How do we then access its value?
It is the internal representation variable used in the points-to solving
algorithm. You can't access that outside of the pass.
Do you have a (simple) testcase that shows the issue?
Here is a testcase :
---
__attribute__ ((noinline)) void fun3(void (*fp) ())
{
fp();
}
void fun1()
{
printf("\nin fun1\n");
}
int main()
{
fun3(fun1);
}
---
Points-to information of formal argument fp is not dumped.
However, the value for fun3.arg0 = { fun1 } is being dumped.
Richard.
On Tuesday 29 April 2014 02:47 PM, Richard Biener wrote:
On Tue, Apr 29, 2014 at 8:26 AM, Swati Rathi
wrote:
On Monday 28 April 2014 02:46 PM, Richard Biener wrote:
On Sat, Apr 26, 2014 at 4:07 PM, Richard Biener
wrote:
On April 26, 2014 12:31:34 PM CEST, Swati Rathi
wrote:
On Friday 25 April 2014 11:11 PM, Richard Biener wrote:
On April 25, 2014 5:54:09 PM CEST, Swati Rathi
wrote:
Hello,
I am trying to print points-to information for SSA variables as
below.
for (i = 1; i < num_ssa_names; i++)
{
tree ptr = ssa_name (i);
struct ptr_info_def *pi;
if (ptr == NULL_TREE
|| SSA_NAME_IN_FREE_LIST (ptr))
continue;
pi = SSA_NAME_PTR_INFO (ptr);
if (pi)
dump_points_to_info_for (file, ptr);
}
-
My test program is given below :
int main()
{
int *p, i, j;
void (*fp1)();
if (i)
{
p = &i;
fp1 = fun1;
}
else
{
p = &j;
fp1 = fun2;
}
fp1();
printf ("\n%d %d\n", *p, i);
return 0;
}
-
I get the output as :-
p_1, points-to vars: { i j }
fp1_2, points-to vars: { }
-
Why is the pointees for function pointer not getting dumped?
It's just not saved.
Can we modify the code to preserve values for function pointer SSA
names?
Sure.
Index: gcc/tree-ssa-structalias.c
===
--- gcc/tree-ssa-structalias.c (revision 209782)
+++ gcc/tree-ssa-structalias.c (working copy)
@@ -6032,7 +6032,8 @@ set_uids_in_ptset (bitmap into, bitmap f
if (TREE_CODE (vi->decl) == VAR_DECL
|| TREE_CODE (vi->decl) == PARM_DECL
- || TREE_CODE (vi->decl) == RESULT_DECL)
+ || TREE_CODE (vi->decl) == RESULT_DECL
+ || TREE_CODE (vi->decl) == FUNCTION_DECL)
{
/* If we are in IPA mode we will not recompute points-to
sets after inlining so make sure they stay valid. */
Thanks a lot. :) This is of great help.
note that there isn't a convenient way to go back from a bit in the
points-to bitmap to the actual FUNCTION_DECL refered to.
The bitmap is set by identifying the bit using DECL_PT_UID.
For variables, referenced_var_lookup returns the associated variable.
Note that this table is gone from recent GCC.
For FUNCTION_DECL's, all we need to do is store a mapping between uid and
FUNCTION_DECL.
Is this correct?
Correct.
Richard.
Richard.
What is the reason that it is not preserved for function pointers?
Nobody uses this information.
Another alternative approach would be to replicate the code (of
pass_ipa_pta) and use the information before deleting it.
Is there any other way to access this information?
You can of course recompute it when needed.
Richard.
How can I access this information?
Regards,
Swati
Re: implementation question
On Mon, May 5, 2014 at 11:28 AM, Andrew Haley wrote: > On 05/05/2014 08:47 AM, Richard Biener wrote: >> It really depends on how "3x" should materialize in the end. >> How do you triplicate ops with side-effects? If you only >> triplicate ops without side-effects what is the sink that keeps >> the duplicated ops live? > > The vote, surely. CSE would be absolutely determined to get rid of > all this redundant work. I guess it'd all have to be done very late > or we'd need a new node that CSE can't see through. > > Would it be enough to mark all nodes that go into the vote as volatile? > I guess not: we wouldn't want to generate extra memory traffic. Well, it can end up using the exact same registers 3 times and spilling the result to the stack anyway. It has to be done before register allocation I suppose, and thus postreload-cse will come along ... Richard. > Andrew. >
Re: How to access points-to information for function pointers
On Mon, May 5, 2014 at 1:27 PM, Swati Rathi wrote:
> On Monday 05 May 2014 04:37 PM, Richard Biener wrote:
>>
>> On Mon, May 5, 2014 at 11:38 AM, Swati Rathi
>> wrote:
>>>
>>> In some cases, GCC's pta pass does not dump the points-to information for
>>> function pointers which are formal parameters.
>>>
>>> Why is it so?
>>
>> Depends on the case.
>>
>>> Also it does not store the information for the corresponding SSA name.
>>>
>>> However, it dumps pointer information for the parameter variable as
>>> .constprop.0.arg0 = { val1 val2 }
>>>
>>> This is the value which should have been stored with the formal
>>> parameter.
>>>
>>> Is there any way of accessing this value?
>>> Also what is this new variable .constprop.0.arg0 which is
>>> getting created?
>>> It is not a local variable. How do we then access its value?
>>
>> It is the internal representation variable used in the points-to solving
>> algorithm. You can't access that outside of the pass.
>>
>> Do you have a (simple) testcase that shows the issue?
>
>
> Here is a testcase :
>
> ---
> __attribute__ ((noinline)) void fun3(void (*fp) ())
> {
> fp();
> }
>
> void fun1()
> {
> printf("\nin fun1\n");
> }
>
> int main()
> {
> fun3(fun1);
> }
> ---
>
> Points-to information of formal argument fp is not dumped.
> However, the value for fun3.arg0 = { fun1 } is being dumped.
Ah, that's just an issue of the dumping. We dump alias info
at the definition place but there isn't one for the formal argument.
Somewhen in the past I had patches to address this.
Richard.
>
>
>>
>> Richard.
>>
>>>
>>> On Tuesday 29 April 2014 02:47 PM, Richard Biener wrote:
On Tue, Apr 29, 2014 at 8:26 AM, Swati Rathi
wrote:
>
> On Monday 28 April 2014 02:46 PM, Richard Biener wrote:
>>
>> On Sat, Apr 26, 2014 at 4:07 PM, Richard Biener
>> wrote:
>>>
>>> On April 26, 2014 12:31:34 PM CEST, Swati Rathi
>>> wrote:
On Friday 25 April 2014 11:11 PM, Richard Biener wrote:
>
> On April 25, 2014 5:54:09 PM CEST, Swati Rathi
wrote:
>>
>> Hello,
>>
>> I am trying to print points-to information for SSA variables as
below.
>>
>> for (i = 1; i < num_ssa_names; i++)
>> {
>> tree ptr = ssa_name (i);
>> struct ptr_info_def *pi;
>>
>> if (ptr == NULL_TREE
>> || SSA_NAME_IN_FREE_LIST (ptr))
>> continue;
>>
>> pi = SSA_NAME_PTR_INFO (ptr);
>> if (pi)
>> dump_points_to_info_for (file, ptr);
>> }
>>
>> -
>> My test program is given below :
>>
>> int main()
>> {
>> int *p, i, j;
>> void (*fp1)();
>>
>> if (i)
>> {
>> p = &i;
>> fp1 = fun1;
>> }
>> else
>> {
>> p = &j;
>> fp1 = fun2;
>> }
>>
>> fp1();
>>
>> printf ("\n%d %d\n", *p, i);
>> return 0;
>> }
>> -
>> I get the output as :-
>>
>> p_1, points-to vars: { i j }
>> fp1_2, points-to vars: { }
>> -
>>
>> Why is the pointees for function pointer not getting dumped?
>
> It's just not saved.
Can we modify the code to preserve values for function pointer SSA
names?
>>>
>>> Sure.
>>
>> Index: gcc/tree-ssa-structalias.c
>> ===
>> --- gcc/tree-ssa-structalias.c (revision 209782)
>> +++ gcc/tree-ssa-structalias.c (working copy)
>> @@ -6032,7 +6032,8 @@ set_uids_in_ptset (bitmap into, bitmap f
>>
>> if (TREE_CODE (vi->decl) == VAR_DECL
>> || TREE_CODE (vi->decl) == PARM_DECL
>> - || TREE_CODE (vi->decl) == RESULT_DECL)
>> + || TREE_CODE (vi->decl) == RESULT_DECL
>> + || TREE_CODE (vi->decl) == FUNCTION_DECL)
>>{
>> /* If we are in IPA mode we will not recompute points-to
>> sets after inlining so make sure they stay valid. */
>
> Thanks a lot. :) This is of great help.
>
>
>> note that there isn't a convenient way to go back from a bit in the
>> points-to bitmap to the actual FUNCTION_DECL refered to.
>
>>
Re: gcc 4.9.0 do not build on OSX
On 4/05/2014 12:34 pm, Andrew Pinski wrote:
On Sat, May 3, 2014 at 5:48 PM, Chris Johns wrote:
On 3/05/2014 10:57 pm, Franzi Edo. wrote:
Hi,
I am trying to build a gcc-4.9.0 ARM cross compiler on OSX Mavericks
unsuccessfully.
My toolchain works fine with the previous version 4.8.2 but on the 4.9.0 I
have this error during the gcc building pass 1.
/opt/uKOS/Packages/gcc-4.9.0/gcc/config/arm/neon.md:3486:10917: fatal
error:
bracket nesting level exceeded maximum of 256
/opt/uKOS/Packages/gcc-4.9.0/gcc/config/arm/neon.md:3486:10917: note: use
-fbracket-depth=N to increase maximum nesting level
32 warnings and 1 error generated.
make[1]: *** [insn-attrtab.o] Error 1
make: *** [all-gcc] Error 2
Error building gcc pass 1
There is some large conditionals inside insn-attrtab.c but I don't see
any which have more than 30 depth of parenthesis. The max level of {}
is 4 in that file too.
I have generated a preprocessed source file as asked by clang and it is
attached to the PR I raised there. The file shows 288 brackets at line
51623 in the file.
So this sounds like a bug in clang. Please report it to them.
The PR is http://llvm.org/bugs/show_bug.cgi?id=19650.
Chris
Re: gcc 4.9.0 do not build on OSX
On Mon, May 05, 2014 at 11:45:46PM +1000, Chris Johns wrote:
> On 4/05/2014 12:34 pm, Andrew Pinski wrote:
> >On Sat, May 3, 2014 at 5:48 PM, Chris Johns wrote:
> >>On 3/05/2014 10:57 pm, Franzi Edo. wrote:
> >>>
> >>>Hi,
> >>>I am trying to build a gcc-4.9.0 ARM cross compiler on OSX Mavericks
> >>>unsuccessfully.
> >>>My toolchain works fine with the previous version 4.8.2 but on the 4.9.0 I
> >>>have this error during the gcc building pass 1.
> >>>
> >>>/opt/uKOS/Packages/gcc-4.9.0/gcc/config/arm/neon.md:3486:10917: fatal
> >>>error:
> >>> bracket nesting level exceeded maximum of 256
> >>>/opt/uKOS/Packages/gcc-4.9.0/gcc/config/arm/neon.md:3486:10917: note: use
> >>> -fbracket-depth=N to increase maximum nesting level
> >>>32 warnings and 1 error generated.
> >>>make[1]: *** [insn-attrtab.o] Error 1
> >>>make: *** [all-gcc] Error 2
> >>>Error building gcc pass 1
> >
> >There is some large conditionals inside insn-attrtab.c but I don't see
> >any which have more than 30 depth of parenthesis. The max level of {}
> >is 4 in that file too.
>
> I have generated a preprocessed source file as asked by clang and it
> is attached to the PR I raised there. The file shows 288 brackets
> at line 51623 in the file.
>
> >So this sounds like a bug in clang. Please report it to them.
>
> The PR is http://llvm.org/bugs/show_bug.cgi?id=19650.
Looking at that line, guess it would be better if the generator (is that
genattrtab?) generated a switch rather than
if ((x == 1) || ((x == 2) || ((x == 3) || ((x == 4) || ((x == 5)...)
(at least I believe GCC doesn't yet transform a series of if conditions into
a switch (it optimizes the other direction)).
And, even if it doesn't generate a switch for say some attribute compared to
more than 10 values, there is no point in adding the extra ()s when
the operator || and operator || used in the rhs of it are the same.
Jakub
SH -ml not turning into -EL to ld
Hi We have a few build failures on the RTEMS target where it appears that the -ml argument to make a relocatable is not turned into a -EL argument to ld by gcc 4.8.2. This is the output of invoking gcc with "-v". Below that I invoked the same LD command with -EL on the command line and it worked. Any ideas or suggestions? $ sh-rtems4.11-gcc --pipe -B../../../../.././lib/ -B../../../../.././simsh2e/lib/ -specs bsp_specs -qrtems -m2e -ml -O2 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -qnolinkcmds -nostdlib -r -o cache.rel ../shared/src/cache_rel-cache_aligned_malloc.o ../shared/src/cache_rel-cache_manager.o -v Using built-in specs. Reading specs from ../../../../.././simsh2e/lib/bsp_specs rename spec endfile to old_endfile rename spec startfile to old_startfile rename spec link to old_link COLLECT_GCC=sh-rtems4.11-gcc COLLECT_LTO_WRAPPER=/users/joel/rtems-4.11-work/tools/libexec/gcc/sh-rtems4.11/4.8.2/lto-wrapper Target: sh-rtems4.11 Configured with: ../gcc-4.8.2/configure --prefix=/users/joel/rtems-4.11-work/tools --bindir=/users/joel/rtems-4.11-work/tools/bin --exec_prefix=/users/joel/rtems-4.11-work/tools --includedir=/users/joel/rtems-4.11-work/tools/include --libdir=/users/joel/rtems-4.11-work/tools/lib --libexecdir=/users/joel/rtems-4.11-work/tools/libexec --mandir=/users/joel/rtems-4.11-work/tools/share/man --infodir=/users/joel/rtems-4.11-work/tools/share/info --datadir=/users/joel/rtems-4.11-work/tools/share --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=sh-rtems4.11 --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --verbose --with-newlib --with-system-zlib --disable-nls --without-included-gettext --disable-win32-registry --enable-version-specific-runtime-libs --disable-lto --enable-newlib-io-c99-formats --enable-newlib-iconv --enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,iso_ir_111,koi8_r,koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,utf_16,utf_16be,utf_16le,utf_8,win_1250,win_1251,win_1252,win_1253,win_1254,win_1255,win_1256,win_1257,win_1258 --enable-threads --disable-plugin --enable-languages=c,c++ Thread model: rtems gcc version 4.8.2 20131016 (RTEMS 4.11-RSB-6fe63b3f553bb3157c7b8256917152ca36450fd4-1,gcc-4.8.2/newlib-2.1.0) (GCC) COMPILER_PATH=../../../../.././simsh2e/lib/:/users/joel/rtems-4.11-work/tools/libexec/gcc/sh-rtems4.11/4.8.2/:/users/joel/rtems-4.11-work/tools/libexec/gcc/sh-rtems4.11/4.8.2/:/users/joel/rtems-4.11-work/tools/libexec/gcc/sh-rtems4.11/:/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/:/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/:/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/../../../../sh-rtems4.11/bin/ LIBRARY_PATH=/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/ml/m2e/:/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/../../../../sh-rtems4.11/lib/ml/m2e/:../../../../.././simsh2e/lib/:/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/:/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/../../../../sh-rtems4.11/lib/ COLLECT_GCC_OPTIONS='-pipe' '-B' '../../../../.././lib/' '-B' '../../../../.././simsh2e/lib/' '-specs=bsp_specs' '-qrtems' '-m2e' '-ml' '-O2' '-g' '-Wall' '-Wmissing-prototypes' '-Wimplicit-function-declaration' '-Wstrict-prototypes' '-Wnested-externs' '-qnolinkcmds' '-nostdlib' '-r' '-o' 'cache.rel' '-v' /users/joel/rtems-4.11-work/tools/libexec/gcc/sh-rtems4.11/4.8.2/collect2 -dc -dp -N -o cache.rel -r -L/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/ml/m2e -L/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/../../../../sh-rtems4.11/lib/ml/m2e -L../../../../.././simsh2e/lib -L/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2 -L/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/../../../../sh-rtems4.11/lib ../shared/src/cache_rel-cache_aligned_malloc.o ../shared/src/cache_rel-cache_manager.o /users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/../../../../sh-rtems4.11/bin/ld: ../shared/src/cache_rel-cache_aligned_malloc.o: compiled for a little endian system and target is big endian /users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/../../../../sh-rtems4.11/bin/ld: ../shared/src/cache_rel-cache_aligned_malloc.o: uses instructions which are incompatible with instructions used in previous modules /users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/../../../../sh-rtems4.11/bin/ld: failed to merge target specific data of file ../shared/src/cache_rel-cache_aligned_malloc.o /users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/../../../../sh-rtems4.11/bin/ld: ../shared/src/cache_rel-cache_manager.o: compiled for a little endian system and target is big endian /users/joe
Re: SH -ml not turning into -EL to ld
Following up to myself... I don't know exactly how to fix
this but I think I have pulled the right thread.
gcc/config/sh/superh.h defined SUBTARGET_LINK_SPEC which
appears to have the right arguments.
sh-rtems4.11-gcc -dumpspecs shows that *link ends with
"%(subtarget_link_spec} which seems correct. But that is
defined to nothing when I think it should be
"%{ml:-EL}%{mb|!ml:-EB}"
configure.gcc shows that sh-superh-elf includes these which
are not in the sh-rtems*) target:
tm_file="${tm_file} sh/superh.h"
extra_options="${extra_options} sh/superh.opt" ;;
Do we need to add those? Anything else we might be missing?
On 5/5/2014 11:37 AM, Joel Sherrill wrote:
> Hi
>
> We have a few build failures on the RTEMS target where it appears
> that the -ml argument to make a relocatable is not turned into a
> -EL argument to ld by gcc 4.8.2.
>
> This is the output of invoking gcc with "-v". Below that I invoked
> the same LD command with -EL on the command line and it
> worked.
>
> Any ideas or suggestions?
>
> $ sh-rtems4.11-gcc --pipe -B../../../../.././lib/
> -B../../../../.././simsh2e/lib/ -specs bsp_specs -qrtems -m2e -ml -O2
> -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration
> -Wstrict-prototypes -Wnested-externs -qnolinkcmds -nostdlib -r -o
> cache.rel ../shared/src/cache_rel-cache_aligned_malloc.o
> ../shared/src/cache_rel-cache_manager.o -v
> Using built-in specs.
> Reading specs from ../../../../.././simsh2e/lib/bsp_specs
> rename spec endfile to old_endfile
> rename spec startfile to old_startfile
> rename spec link to old_link
> COLLECT_GCC=sh-rtems4.11-gcc
> COLLECT_LTO_WRAPPER=/users/joel/rtems-4.11-work/tools/libexec/gcc/sh-rtems4.11/4.8.2/lto-wrapper
> Target: sh-rtems4.11
> Configured with: ../gcc-4.8.2/configure
> --prefix=/users/joel/rtems-4.11-work/tools
> --bindir=/users/joel/rtems-4.11-work/tools/bin
> --exec_prefix=/users/joel/rtems-4.11-work/tools
> --includedir=/users/joel/rtems-4.11-work/tools/include
> --libdir=/users/joel/rtems-4.11-work/tools/lib
> --libexecdir=/users/joel/rtems-4.11-work/tools/libexec
> --mandir=/users/joel/rtems-4.11-work/tools/share/man
> --infodir=/users/joel/rtems-4.11-work/tools/share/info
> --datadir=/users/joel/rtems-4.11-work/tools/share
> --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=sh-rtems4.11
> --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --verbose
> --with-newlib --with-system-zlib --disable-nls
> --without-included-gettext --disable-win32-registry
> --enable-version-specific-runtime-libs --disable-lto
> --enable-newlib-io-c99-formats --enable-newlib-iconv
> --enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,iso_ir_111,koi8_r,koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,utf_16,utf_16be,utf_16le,utf_8,win_1250,win_1251,win_1252,win_1253,win_1254,win_1255,win_1256,win_1257,win_1258
> --enable-threads --disable-plugin --enable-languages=c,c++
> Thread model: rtems
> gcc version 4.8.2 20131016 (RTEMS
> 4.11-RSB-6fe63b3f553bb3157c7b8256917152ca36450fd4-1,gcc-4.8.2/newlib-2.1.0)
> (GCC)
> COMPILER_PATH=../../../../.././simsh2e/lib/:/users/joel/rtems-4.11-work/tools/libexec/gcc/sh-rtems4.11/4.8.2/:/users/joel/rtems-4.11-work/tools/libexec/gcc/sh-rtems4.11/4.8.2/:/users/joel/rtems-4.11-work/tools/libexec/gcc/sh-rtems4.11/:/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/:/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/:/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/../../../../sh-rtems4.11/bin/
> LIBRARY_PATH=/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/ml/m2e/:/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/../../../../sh-rtems4.11/lib/ml/m2e/:../../../../.././simsh2e/lib/:/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/:/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/../../../../sh-rtems4.11/lib/
> COLLECT_GCC_OPTIONS='-pipe' '-B' '../../../../.././lib/' '-B'
> '../../../../.././simsh2e/lib/' '-specs=bsp_specs' '-qrtems' '-m2e'
> '-ml' '-O2' '-g' '-Wall' '-Wmissing-prototypes'
> '-Wimplicit-function-declaration' '-Wstrict-prototypes'
> '-Wnested-externs' '-qnolinkcmds' '-nostdlib' '-r' '-o' 'cache.rel' '-v'
> /users/joel/rtems-4.11-work/tools/libexec/gcc/sh-rtems4.11/4.8.2/collect2
> -dc -dp -N -o cache.rel -r
> -L/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/ml/m2e
> -L/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/../../../../sh-rtems4.11/lib/ml/m2e
> -L../../../../.././simsh2e/lib
> -L/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2
> -L/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/../../../../sh-rtems4.11/lib
> ../shared/src/cache_rel-cache_aligned_malloc.o
> ../shared/src/cache_
Improving Memory Leak Detection
I was trying to regress a bug at work to make sure it was fixed. The comments in the bug were saying that valgrind was showing some memory leaks. Went through the reproduction steps and saw that the particular leak mentioned in the bug was gone but that valgrind was reporting more leaks. After a discussion with the developer, I see that these other mis-reported leaks are due to a common coding practice. The practice is to not worry about the cleanup of one-time allocations or cleanups on 'exit' calls. Im not sure I agree with the practice because it generates noise for the memory profiling tools, and to me seems a little lazy. For early exits im not sure if there is a good solution to eliminate the noise, but for one-time allocations I believe there is. The solution to me is in the language and base libraries. Valgrind is tracing calls to specific memory allocation functions if I am not mistaken. I believe a good solution to eliminate some of this type of one time allocation noise is to use a special function for one-time allocations to variables and enforce that in the language. For C++, a type modifier similar to 'const' that would indicate to the compiler that the one-time allocation function should be used to create the object. For C style mallocs or calls to 'malloc' the compiler could enforce the use of the specific malloc function with the modifier to help eliminate memory leak noise. Myron
merging the wide-int branch
We are now ready to merge the wide-int branch.The branch was broken into small pieces and each of the area maintainers has approved their pieces. The branch has been tested and runs regression free on three 64 bit platforms: x86, ppc, and s390 and on three 32 bit platforms: x86, arm and s390.The range of these includes both big and little endian for both sizes. The testing has included all supported front ends. Our plan, unless we hear any objections, is to merge tomorrow, on Tuesday May 6.While I am sure there will be some fallout, there are wide-int maintainers on all time zones so we should be able to address any issues in a hurry. Thanks, Kenny
Re: [GSoC] questions about graphite_clast_to_gimple.c
Hi Tobias,
thank you for your reply! I have questions about types. Could you
please answer them?
Questions related to “type_for_interval”:
1. What happens in these lines?
int precision = MAX (mpz_sizeinbase (bound_one, 2),
mpz_sizeinbase (bound_two, 2));
if (precision > BITS_PER_WORD)
{
gloog_error = true;
return integer_type_node;
}
Do we try to count maximum number of value bits in bound_one and
bound_two? Why can't it be greater than BITS_PER_WORD?
2. Why do we want to generate signed types as much as possible?
3. Why do we always have enough precision in case of precision <
wider_precision?
Questions related to “clast_to_gcc_expression”:
4. What is the idea behind this code?
if (POINTER_TYPE_P (TREE_TYPE (name)) != POINTER_TYPE_P (type))
name = convert_to_ptrofftype (name);
5. Why do we check POINTER_TYPE_P(type)? (“type” has tree type and the
manual says that a tree is a pointer type)
Questions related to “max_precision_type”:
6. Why is type1, for example, is the maximal precision type in case of
truth of POINTER_TYPE_P (type1)?
7. Why do we have enough precision for p2 in case of p1 > p2 and signed type1?
8. Why do we always build signed integer type in the line: “type =
build_nonstandard_integer_type (precision, false);”?
Questions related to “type_for_clast_red”:
9. Why do we use this code in case of clast_red_sum?
value_min (m1, bound_one, bound_two);
value_min (m2, b1, b2);
mpz_add (bound_one, m1, m2);
Can bound_one be greater then bound_two? (We also consider two cases
in “type_for_interval”)
10. Why do we assume that new bounds are min(bound_one, bound_two) and
min(b1, b2) in case of clast_red_min?
--
Cheers, Roman Gareev
