Mailing list archive header wrong for fortran
Hi, Jack Howarth pointed out to me that when you look at the archives for the [EMAIL PROTECTED] list at http://gcc.gnu.org/ml/fortran/current/, you get this header: This is the mail archive of the [EMAIL PROTECTED] mailing list for the Fortran 95 project. Note the [EMAIL PROTECTED] This should of course be [EMAIL PROTECTED] Who can fix this? Gr. Steven
Re: Mailing list archive header wrong for fortran
On Wed, 27 Jul 2005, Steven Bosscher wrote: > Jack Howarth pointed out to me that when you look at the archives for > the [EMAIL PROTECTED] list at http://gcc.gnu.org/ml/fortran/current/, > you get this header: > > This is the mail archive of the [EMAIL PROTECTED] mailing list for the > Fortran 95 project. > > Note the [EMAIL PROTECTED] This should of course be > [EMAIL PROTECTED] Who can fix this? [EMAIL PROTECTED] should be able to help. Gerald
Latent PTA bug?
Hi all!
I reduced my array aliasing libstdc++ failures to the following
testcase:
struct iterator
{
int* ptr;
iterator(int* _ptr) : ptr(_ptr) {}
};
struct container {
int* first;
container(int* _first) : first(_first) {}
iterator begin() { return iterator(first); }
};
bool includes(const iterator&);
bool test4()
{
int array[] = {2, 4};
container con(array);
return includes(con.begin());
}
the weird thing now is, that the alias1 dump contains
# SFT.2_19 = V_MAY_DEF ;
# SFT.4_20 = V_MAY_DEF ;
D.1797_16 = includes (&D.1794);
i.e. it misses the V_MAY_DEF for SFT.1 (array, UID 1783, int[2], is
addressable, sub-vars: { SFT.2 SFT.1 }), while the alias2 dump
is ok:
# SFT.1_9 = V_MAY_DEF ;
# SFT.2_19 = V_MAY_DEF ;
# SFT.4_20 = V_MAY_DEF ;
D.1797_16 = includes (&D.1794);
unfortunately, at that time DCE already decided to remove the
array[1] initialization.
The difference seems to be in the Pointed-to sets; alias1 contains
SFT.0_10
SFT.3_6
SFT.4_14
SFT.5_12
_first_5, its value escapes, points-to vars: { SFT.2 }
D.1810_8, points-to vars: { SFT.2 }
_ptr_9, its value escapes, points-to vars: { SFT.2 }
while alias2 is only
SFT.0_10
SFT.3_6
SFT.4_14
SFT.5_12
_ptr_8, points-to vars: { }
So maybe from there we miscompute flow-insensitive alias information
which differs in only
- SFT.1, UID 1815, int, is addressable, default def: SFT.1_3
+ SFT.1, UID 1815, int, is addressable, call clobbered, default def: SFT.1_3
I attached the two alias dumps for reference. Maybe you can point
out what is going wrong - I'm somewhat lost here.
Thanks,
Richard.
;; Function bool test4() (_Z5test4v)
Points-to analysis
Constraints:
ANYTHING = &ANYTHING
READONLY = &ANYTHING
INTEGER = &ANYTHING
ANYOFFSET = &ANYOFFSET
_first_5 = &array
con = _first_5
D.1810_8 = con
_ptr_9 = D.1810_8
D.1809 = _ptr_9
D.1796 = D.1809
D.1794 = D.1796
D.1797_16 = &ANYTHING
Collapsing static cycles and doing variable substitution:
Collapsing con into _first_5
Collapsing D.1810_8 into _first_5
Collapsing _ptr_9 into _first_5
Collapsing D.1809 into _first_5
Collapsing D.1796 into _first_5
Collapsing D.1794 into _first_5
Solving graph:
Points-to sets
NULL = { }
ANYTHING = { ANYTHING }
READONLY = { ANYTHING }
INTEGER = { ANYTHING }
ANYOFFSET = { ANYOFFSET }
_first_5 = { array }
array = { }
array.1 = { }
con = { array }
D.1810_8 = { array }
_ptr_9 = { array }
D.1809 = { array }
D.1796 = { array }
D.1794 = { array }
D.1797_16 = { ANYTHING }
test4: Total number of aliased vops: 0
Referenced variables in test4: 17
Variable: SFT.0, UID 1814, int *, default def: SFT.0_10
Variable: SFT.1, UID 1815, int, is addressable, default def: SFT.1_3
Variable: _first, UID 1808, int *
Variable: D.1809, UID 1809, struct iterator, sub-vars: { SFT.0 }
Variable: D.1810, UID 1810, int *
Variable: _ptr, UID 1811, int *
Variable: , UID 1782, int
Variable: array, UID 1783, int[2], is addressable, sub-vars: { SFT.2 SFT.1 }
Variable: con, UID 1784, struct container, sub-vars: { SFT.3 }
Variable: SFT.2, UID 1816, int, is addressable, call clobbered, default def:
SFT.2_1
Variable: SFT.3, UID 1817, int *, default def: SFT.3_6
Variable: SFT.4, UID 1818, int *, is addressable, call clobbered, default def:
SFT.4_14
Variable: SFT.5, UID 1819, int *, default def: SFT.5_12
Variable: D.1794, UID 1794, struct iterator, is addressable, sub-vars: { SFT.4 }
Variable: D.1795, UID 1795, int
Variable: D.1796, UID 1796, struct iterator, sub-vars: { SFT.5 }
Variable: D.1797, UID 1797, bool
Pointed-to sets for pointers in bool test4()
SFT.0_10
SFT.3_6
SFT.4_14
SFT.5_12
_first_5, its value escapes, points-to vars: { SFT.2 }
D.1810_8, points-to vars: { SFT.2 }
_ptr_9, its value escapes, points-to vars: { SFT.2 }
Flow-insensitive alias information for bool test4()
Aliased symbols
SFT.1, UID 1815, int, is addressable, default def: SFT.1_3
array, UID 1783, int[2], is addressable, sub-vars: { SFT.2 SFT.1 }
SFT.2, UID 1816, int, is addressable, call clobbered, default def: SFT.2_1
SFT.4, UID 1818, int *, is addressable, call clobbered, default def: SFT.4_14
D.1794, UID 1794, struct iterator, is addressable, sub-vars: { SFT.4 }
Dereferenced pointers
Type memory tags
Flow-sensitive alias information for bool test4()
SSA_NAME pointers
Name memory tags
Registering new PHI nodes in block #-1
Registering new PHI nodes in block #0
Updating SSA information for statement array[0] = 2;
Updating SSA information for statement array[1] = 4;
Updating SSA information for statement con.first = _first_5;
Updating SSA information for statement D.1810_8 = con.first;
Updating SSA information for statement D.1809.ptr = _ptr_9;
Updating SSA information for statement D.1796 = D.1809;
Updating SSA information for statement D.1794 = D.1796;
Updating SSA information for statement D.1797_16 = includes (&D.1794);
Symbols to be put in SSA form
array con D.1794 D.1809 SFT.0 SFT.1 SFT.2 SFT.3 SFT.4
Incremental SSA up
Minor documentation problem
Hello, I downloaded gcc 4.0.1 and created the manual with 'make dvi'. While browsing through it, I noticed the option -ftree-dse, which is mentioned in paragraph 3.1 (Options summary) and in paragraph 3.10 (Options That Control Optimization) under -O1. However, this option is not documented in the manual. What does it do? Thank you, Ioannis
Re: Latent PTA bug?
On Wed, 2005-07-27 at 13:08 +0200, Richard Guenther wrote:
> Hi all!
>
> I reduced my array aliasing libstdc++ failures to the following
> testcase:
>
> struct iterator
> {
> int* ptr;
> iterator(int* _ptr) : ptr(_ptr) {}
> };
>
> struct container {
> int* first;
> container(int* _first) : first(_first) {}
> iterator begin() { return iterator(first); }
> };
>
> bool includes(const iterator&);
>
> bool test4()
> {
> int array[] = {2, 4};
> container con(array);
> return includes(con.begin());
> }
>
> the weird thing now is, that the alias1 dump contains
>
> # SFT.2_19 = V_MAY_DEF ;
> # SFT.4_20 = V_MAY_DEF ;
> D.1797_16 = includes (&D.1794);
We get this right, you are doing something wrong in the conversion:
PTA calculates the set to be (in alias2):
_ptr_8 = { array }
and in alias1:
_ptr_9 = { array }
Which is right.
It looks like you aren't converting your new subvars right, or
something.
--Dan
Re: Latent PTA bug?
On Wed, Jul 27, 2005 at 01:08:38PM +0200, Richard Guenther wrote:
> Points-to sets
>
> _first_5 = { array }
> array = { }
> array.1 = { }
> con = { array }
> D.1810_8 = { array }
> _ptr_9 = { array }
> D.1809 = { array }
> D.1796 = { array }
> D.1794 = { array }
> D.1797_16 = { ANYTHING }
>
[ ... ]
> Points-to sets
>
> con = { array }
> array = { }
> array.1 = { }
> _ptr_8 = { array }
> D.1809 = { array }
> D.1796 = { array }
> D.1794 = { array }
> D.1797_16 = { ANYTHING }
>
PT solutions are correct. It seems like you are not translating
them correctly in find_what_p_points_to().
Re: Latent PTA bug?
C testcase ;)
typedef struct { int *p; } X;
void includes(const X *);
void test4(void)
{
int array[2] = { 2, 4 };
X i;
int * _p;
_p = array;
i.p = _p;
includes(&i);
}
if you change that to
i.p = array;
it works... !? But I note this in the failing case:
Pointed-to sets for pointers in test4
SFT.2_6
_p_5, its value escapes, points-to vars: { SFT.1 }
i.e. while we see that the temporary pointer points to array[0], for
SFT.2_6 (i.p) we don't see anything? So if we'd see { SFT.1 } here, too,
we'd be wrong in both cases. -> aka my bug, correct? So why don't
we get the points-to set for SFT.2_6?
Richard.
Re: Latent PTA bug?
On Wed, Jul 27, 2005 at 03:09:09PM +0200, Richard Guenther wrote:
> i.e. while we see that the temporary pointer points to array[0], for
> SFT.2_6 (i.p) we don't see anything? So if we'd see { SFT.1 } here, too,
> we'd be wrong in both cases. -> aka my bug, correct?
>
What is SFT.1? array[0]? Yes, that's your bug. may-alias sets
should have all of array's SFTs.
> So why don't we get the points-to set for SFT.2_6?
>
The solver does not operate on SFTs. Both _p_5 and i should
point to array here.
Re: Mailing list archive header wrong for fortran
On Wed, Jul 27, 2005 at 12:14:38PM +0200, Gerald Pfeifer wrote: >On Wed, 27 Jul 2005, Steven Bosscher wrote: >> Jack Howarth pointed out to me that when you look at the archives for >> the [EMAIL PROTECTED] list at http://gcc.gnu.org/ml/fortran/current/, >> you get this header: >> >> This is the mail archive of the [EMAIL PROTECTED] mailing list for the >> Fortran 95 project. >> >> Note the [EMAIL PROTECTED] This should of course be >> [EMAIL PROTECTED] Who can fix this? > >[EMAIL PROTECTED] should be able to help. I'm fixing this now. cgf
Re: Latent PTA bug?
On Wed, 27 Jul 2005, Diego Novillo wrote:
> On Wed, Jul 27, 2005 at 03:09:09PM +0200, Richard Guenther wrote:
>
> > i.e. while we see that the temporary pointer points to array[0], for
> > SFT.2_6 (i.p) we don't see anything? So if we'd see { SFT.1 } here, too,
> > we'd be wrong in both cases. -> aka my bug, correct?
> >
> What is SFT.1? array[0]? Yes, that's your bug. may-alias sets
> should have all of array's SFTs.
>
> > So why don't we get the points-to set for SFT.2_6?
> >
> The solver does not operate on SFTs. Both _p_5 and i should
> point to array here.
This seems to fix it. Am I poking at the right place? ;)
*** set_uids_in_ptset (bitmap into, bitmap f
*** 3246,3252
else if (TREE_CODE (vi->decl) == VAR_DECL
|| TREE_CODE (vi->decl) == PARM_DECL)
{
! if (found_anyoffset
&& var_can_have_subvars (vi->decl)
&& get_subvars_for_var (vi->decl))
{
--- 3294,3301
else if (TREE_CODE (vi->decl) == VAR_DECL
|| TREE_CODE (vi->decl) == PARM_DECL)
{
! if ((found_anyoffset
! || TREE_CODE (TREE_TYPE (vi->decl)) == ARRAY_TYPE)
&& var_can_have_subvars (vi->decl)
&& get_subvars_for_var (vi->decl))
{
Re: Latent PTA bug?
On Wed, 2005-07-27 at 16:02 +0200, Richard Guenther wrote:
> On Wed, 27 Jul 2005, Diego Novillo wrote:
>
> > On Wed, Jul 27, 2005 at 03:09:09PM +0200, Richard Guenther wrote:
> >
> > > i.e. while we see that the temporary pointer points to array[0], for
> > > SFT.2_6 (i.p) we don't see anything? So if we'd see { SFT.1 } here, too,
> > > we'd be wrong in both cases. -> aka my bug, correct?
> > >
> > What is SFT.1? array[0]? Yes, that's your bug. may-alias sets
> > should have all of array's SFTs.
> >
> > > So why don't we get the points-to set for SFT.2_6?
> > >
> > The solver does not operate on SFTs. Both _p_5 and i should
> > point to array here.
>
> This seems to fix it. Am I poking at the right place? ;)
More or less.
What you want to say is that when we have &array, that we add anyoffset
to the points-to set, like we do with taking the address of the
structure.
Re: Minor documentation problem
"Ioannis E. Venetis" <[EMAIL PROTECTED]> writes: > I downloaded gcc 4.0.1 and created the manual with 'make dvi'. While > browsing through it, I noticed the option -ftree-dse, which is > mentioned in paragraph 3.1 (Options summary) and in paragraph 3.10 > (Options That Control Optimization) under -O1. > > However, this option is not documented in the manual. What does it do? It does dead store elimination. To quote from tree-ssa-dce.c: A dead store is a store into a memory location which will later be overwritten by another store without any intervening loads. In this case the earlier store can be deleted. Not describing this option is a documentation bug. If you feel like it, please submit a patch or a bug report (http://gcc.gnu.org/bugzilla/). Thanks. Ian
Inserting a call statement
Hi
I am trying to insert a function call "foo" inside the tree list.
Inside this particular loop
for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi))
{
//if a particular condition is satisfied I do the following
tree id = get_identifier ("foo");
tree t = build_function_type_list (void_type_node,NULL_TREE);
tree decl = build_decl (FUNCTION_DECL, id, t);
tree call = build_function_call_expr (decl, NULL);
bsi_insert_before(&bsi,call,BSI_CHAIN_END); // I have tried
BSI_NEW_STMT
}
Although the node is created properly, an assertion in
tree-flow-inline.h fails. Can someone help me identify the issue here.
i will appreciate that
thanks
Re: Inserting a call statement
On Wed, 2005-07-27 at 12:33 -0400, drizzle drizzle wrote:
> Hi
> I am trying to insert a function call "foo" inside the tree list.
>
>
> Inside this particular loop
> for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi))
> {
>
> //if a particular condition is satisfied I do the following
>
> tree id = get_identifier ("foo");
> tree t = build_function_type_list (void_type_node,NULL_TREE);
> tree decl = build_decl (FUNCTION_DECL, id, t);
> tree call = build_function_call_expr (decl, NULL);
>bsi_insert_before(&bsi,call,BSI_CHAIN_END); // I have tried
> BSI_NEW_STMT
>
>
> }
>
>
> Although the node is created properly, an assertion in
> tree-flow-inline.h fails. Can someone help me identify the issue here.
> i will appreciate that
What assert do you trigger?
>
> thanks
Re: Inserting a call statement
On Wednesday 27 July 2005 17:33, drizzle drizzle wrote:
> Hi
> I am trying to insert a function call "foo" inside the tree list.
>
>
> Inside this particular loop
> for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi))
> {
>
> //if a particular condition is satisfied I do the following
>
> tree id = get_identifier ("foo");
> tree t = build_function_type_list (void_type_node,NULL_TREE);
> tree decl = build_decl (FUNCTION_DECL, id, t);
> tree call = build_function_call_expr (decl, NULL);
>bsi_insert_before(&bsi,call,BSI_CHAIN_END); // I have tried
> BSI_NEW_STMT
>
>
> }
>
>
> Although the node is created properly, an assertion in
> tree-flow-inline.h fails. Can someone help me identify the issue here.
> i will appreciate that
You don't appear to be recording the FUNCTION_DECL anywhere, which probably
means cgraph doesn't know about it.
Paul
Re: Inserting a call statement
Its inside this function
static inline var_ann_t
var_ann (tree t)
from the error dump itseems to the following assertion
gcc_assert (DECL_P (t))
thanks
On 7/27/05, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-07-27 at 12:33 -0400, drizzle drizzle wrote:
> > Hi
> > I am trying to insert a function call "foo" inside the tree list.
> >
> >
> > Inside this particular loop
> > for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi))
> > {
> >
> > //if a particular condition is satisfied I do the following
> >
> > tree id = get_identifier ("foo");
> > tree t = build_function_type_list (void_type_node,NULL_TREE);
> > tree decl = build_decl (FUNCTION_DECL, id, t);
> > tree call = build_function_call_expr (decl, NULL);
> >bsi_insert_before(&bsi,call,BSI_CHAIN_END); // I have tried
> > BSI_NEW_STMT
>
>
> >
> >
> > }
> >
> >
> > Although the node is created properly, an assertion in
> > tree-flow-inline.h fails. Can someone help me identify the issue here.
> > i will appreciate that
>
> What assert do you trigger?
>
> >
> > thanks
>
>
Re: Inserting a call statement
On Wed, 2005-07-27 at 12:58 -0400, drizzle drizzle wrote: > Its inside this function > > static inline var_ann_t > var_ann (tree t) > > from the error dump itseems to the following assertion > gcc_assert (DECL_P (t)) > > > thanks > I'm gonna need a lot more info than that. Maybe you should attach your patch so we can look at it.
Re: Inserting a call statement
On Wed, 2005-07-27 at 17:54 +0100, Paul Brook wrote:
> On Wednesday 27 July 2005 17:33, drizzle drizzle wrote:
> > Hi
> > I am trying to insert a function call "foo" inside the tree list.
> >
> >
> > Inside this particular loop
> > for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi))
> > {
> >
> > //if a particular condition is satisfied I do the following
> >
> > tree id = get_identifier ("foo");
> > tree t = build_function_type_list (void_type_node,NULL_TREE);
> > tree decl = build_decl (FUNCTION_DECL, id, t);
> > tree call = build_function_call_expr (decl, NULL);
> > bsi_insert_before(&bsi,call,BSI_CHAIN_END); // I have tried
> > BSI_NEW_STMT
> >
> >
> > }
> >
> >
> > Although the node is created properly, an assertion in
> > tree-flow-inline.h fails. Can someone help me identify the issue here.
> > i will appreciate that
>
> You don't appear to be recording the FUNCTION_DECL anywhere, which probably
> means cgraph doesn't know about it.
>
This is the least of his worries :)
tree-profile doesn't record it either.
Most of the tree opts that add function calls don't update the cgraph
edges right now.
Re: Inserting a call statement
Thanks for your help. I am attaching my patch. Most of the code dont
modify anything. The code I am talking about is ia small piece in
tree-data-ref.c in a function insert_annotations. The only
modification in the rest of the code is that an extra variable refid
is set for particular array references. This variable triggers the
annotation. Apart from that my guess is the rest of the code can be
ignored. I would appreciate any suggestions.
thanks
On 7/27/05, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-07-27 at 17:54 +0100, Paul Brook wrote:
> > On Wednesday 27 July 2005 17:33, drizzle drizzle wrote:
> > > Hi
> > > I am trying to insert a function call "foo" inside the tree list.
> > >
> > >
> > > Inside this particular loop
> > > for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi))
> > > {
> > >
> > > //if a particular condition is satisfied I do the following
> > >
> > > tree id = get_identifier ("foo");
> > > tree t = build_function_type_list (void_type_node,NULL_TREE);
> > > tree decl = build_decl (FUNCTION_DECL, id, t);
> > > tree call = build_function_call_expr (decl, NULL);
> > > bsi_insert_before(&bsi,call,BSI_CHAIN_END); // I have tried
> > > BSI_NEW_STMT
> > >
> > >
> > > }
> > >
> > >
> > > Although the node is created properly, an assertion in
> > > tree-flow-inline.h fails. Can someone help me identify the issue here.
> > > i will appreciate that
> >
> > You don't appear to be recording the FUNCTION_DECL anywhere, which probably
> > means cgraph doesn't know about it.
> >
>
> This is the least of his worries :)
>
> tree-profile doesn't record it either.
> Most of the tree opts that add function calls don't update the cgraph
> edges right now.
>
>
>
patch
Description: Binary data
Re: Inserting a call statement
On Wed, 2005-07-27 at 13:39 -0400, drizzle drizzle wrote: > Thanks for your help. I am attaching my patch. Most of the code dont > modify anything. The code I am talking about is ia small piece in > tree-data-ref.c in a function insert_annotations. The only > modification in the rest of the code is that an extra variable refid > is set for particular array references. This variable triggers the > annotation. Apart from that my guess is the rest of the code can be > ignored. I would appreciate any suggestions. I need dynprof.h
Questions about the new M32C target
Hi everyone, I was excited to find out that gcc now supports the Renesas M16C/M32C architecture. I have compiled binutils and gcc from the CVS sources. However, there are several questions that I have: 1. Does anyone know if or when there will be a libc supporting this target, and which one that will be (newlib?)? 2. After building the compiler, I can create object files but not executables. ld claims there are linker scripts missing (the files ld wants are r8c.ld, m16c.ld and m32c.ld, depending on CPU). Will these be added to gcc or are you supposed to write your own? 3. There has been a project to add M16C support to gcc, but it was apparently abandoned because the M16C architecture has two different addressing modes, while gcc presumably does not support different pointer sizes. See this discussion for details: http://lists.gnu.org/archive/html/m16c-dev/2003-11/msg1.html How has this issue been addressed in the current version? Thanks
Re: Questions about the new M32C target
> 1. Does anyone know if or when there will be a libc supporting this > target, and which one that will be (newlib?)? newlib/libgloss patches are next on my list. There's a simulator and gdb port on the way too. I have a couple of hardware boards as well, which I'll use for testing and whatnot. > 2. After building the compiler, I can create object files but not > executables. ld claims there are linker scripts missing (the files ld > wants are r8c.ld, m16c.ld and m32c.ld, depending on CPU). Will these > be added to gcc or are you supposed to write your own? They'll be in libgloss. I just got the word on copyrights (BSD) and need to hook in the init-ram-from-rom stuff. > 3. There has been a project to add M16C support to gcc, but it was > apparently abandoned because the M16C architecture has two different > addressing modes, while gcc presumably does not support different > pointer sizes. See this discussion for details: > http://lists.gnu.org/archive/html/m16c-dev/2003-11/msg1.html > > How has this issue been addressed in the current version? The problem is that gcc doesn't support two different pointer widths *in the same compilation*. So, I made it a command line option which to use. I started a couple of threads about single-pointer assumptions in gcc back when I discovered that. R8C and M16C modes (-mcpu=r8c, -mcpu=m16c) use 16 bit pointers. The M16C allows code to live outside the first 64k; the linker generates call thunks to accomodate requests for 16 bit pointers to them. M32CM and M32C modes (-mcpu=m32cm, -mcpu=m32c) use 24 bit pointers in a 32 bit word (PSImode), but a 16 bit "size_t". It's a little weird but results in the best overall code. The assembler has %dsp8() and %dsp16() modifiers for disp[a0] type addressing for when you know that the variable is in the first 256 or 64k bytes, but gcc does not currently use them. I'm hoping at some point in the future to add linker relaxing so that these will be used automatically.
Re: how to write a define_peephole2 that uses custom registers in nios2
Liu Haibin wrote: (match_operand:SI 2 "register_operand" "r") But the problem is it uses normal register, like r8, r9. How can I write the define_peephole2 so that it uses custom registers? See the "Constraints" section of the documentation. "r" means a general register. If you want a custom register, then you need to use a contraint letter that maps to a custom register. If the port does not already support custom registers, then you need to modify many of the register allocation related macros to add support for the custom registers. See the "Registers" and "Register Classes" sections of the documentation. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
FW: wow, check this out !
-Original Message- From: Mark Sent: Monday, Jul 9, 2005 5:14 PM To: Olga Cc: Vera Subject: wow, check this out ! http://teeny.servehttp.com/
Error repair in the C++ parser
I'm fixing a problem with ObjC++ going beserk upon encountering
a syntax error, specifically not finding a '{' at the beginning
of a method definition. Is there a safe, established way of
repairing the token stream, i.e., inserting the '{' at that point?
That way, I could print an ObjC++-specific error message
(e.g., "missing `{' at beginning of Objective-C method definition"),
but then fix things up so that the generic C++ compound-statement
parsing logic doesn't get confused further.
Thanks in advance,
--Zem
--
Ziemowit Laski 1 Infinite Loop, MS 301-2K
Mac OS X Compiler GroupCupertino, CA USA 95014-2083
Apple Computer, Inc. +1.408.974.6229 Fax .5477
Re: rfa (x86): 387<=>sse moves
On Tue, Jul 26, 2005 at 11:10:56PM -0700, Dale Johannesen wrote: > Yes, it is. The following fixes my problem, and causes a couple of > 3DNow-specific regressions > in the testsuite which I need to look at, but nothing serious; I think > it's gotten far enough to post > for opinions. This is intended to go on top of Paolo's patch > http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01044.html > It may, of course, run afoul of inaccuracies in the patterns on various > targets, haven't tried any performance testing yet. Looks plausible. Let us know what you wind up with wrt those regressions and testing. r~
-Wstrict-aliasing=2 does not warn about all problems
Hi Jim, the documentation for -Wstrict-aliasing=2 says: It warns about all code which might break the strict aliasing rules that the compiler is using for optimization. This warning catches all cases, but it will also give a warning for some ambiguous cases that are safe. However, there are a number of cases of aliasing which it does not catch. For example, see PR 23106. In general, the warning is disabled by casts through void* or char*. Also, the warning only applies to casts of the address of a variable. In general, I think the risky code is when we see some ordering of these three statements: p2 = (TYPE *) p1; *p2; *p1; However, computing that is probably non-trivial. Anyhow, I think we need to change the documentation for -Wstrict-aliasing=2. It warns about more possible problems than -Wstrict-aliasing, but it does not warn about all possible problems. Any thoughts? Ian
Re: rfa (x86): 387<=>sse moves
On Jul 27, 2005, at 2:18 PM, Richard Henderson wrote: On Tue, Jul 26, 2005 at 11:10:56PM -0700, Dale Johannesen wrote: Yes, it is. The following fixes my problem, and causes a couple of 3DNow-specific regressions in the testsuite which I need to look at, but nothing serious; I think it's gotten far enough to post for opinions. This is intended to go on top of Paolo's patch http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01044.html It may, of course, run afoul of inaccuracies in the patterns on various targets, haven't tried any performance testing yet. Looks plausible. Let us know what you wind up with wrt those regressions and testing. With the latest version of Paolo's patch (in PR 19653) the regressions are gone. Spec is going to take a bit longer, I haven't gotten GMP to build yet on x86 Darwinsince the FP benchmarks are the interesting ones for this I should work through it.
Re: GCC 4.0.1 testsuite uses installed g++ instead of newly bootstrapped g++
Hi all, I did not receive a reply to my earlier message. Have I posted it to the wrong list? If so, what is the right list for this message? Thanks On Sat, 23 Jul 2005 07:23 pm, Paul C. Leopardi wrote: > How do I make the tests find the bootstrapped g++? Shouldn't the test just > do this automatically? How is the test supposed to find find the > bootstrapped g++? Is it done via an environment variable? Which environment > variable? What sets the value of this variable? Is it a script or a > program? > > What have I configured wrong, if anything? If this really is a bug, then > why does the test work for Andreas Jaeger and not for me? > http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00112.html > > Should I file another bug report and hope that I don't kust get WORKSFORME? > Best regards
Re: GCC 4.0.1 testsuite uses installed g++ instead of newly bootstrapped g++
"Paul C. Leopardi" <[EMAIL PROTECTED]> writes: > Hi all, > I did not receive a reply to my earlier message. Have I posted it to the > wrong > list? If so, what is the right list for this message? > Thanks > > On Sat, 23 Jul 2005 07:23 pm, Paul C. Leopardi wrote: > > How do I make the tests find the bootstrapped g++? Shouldn't the test just > > do this automatically? How is the test supposed to find find the > > bootstrapped g++? Is it done via an environment variable? Which environment > > variable? What sets the value of this variable? Is it a script or a > > program? > > > > What have I configured wrong, if anything? If this really is a bug, then > > why does the test work for Andreas Jaeger and not for me? > > http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00112.html > > > > Should I file another bug report and hope that I don't kust get WORKSFORME? > > Best regards This is probably the right list. It's just that nobody happened to reply. gcc is a volunteer effort, particularly when it comes to answering questions on the mailing lists. In this case, it's hard to write a useful reply since you didn't provide any informative details. It is true that running the testsuite will normally use a newly built compiler, without requiring it to be installed. However, you didn't provide critical information like precisely what you did, precisely what happened, what you expected to happen instead, what version of the compiler you were building, and what host you were running on. So it's hard to know what to say. Or, in other words, WORKSFORME. Ian
Re: GCC 4.0.1 testsuite uses installed g++ instead of newly bootstrapped g++
On Jul 27, 2005, at 5:21 PM, Paul C. Leopardi wrote: How do I make the tests find the bootstrapped g++? You don't it already does. Shouldn't the test just do this automatically? Yes. How is the test supposed to find find the bootstrapped g++? Carefully, see the source code. Is it done via an environment variable? Sorta but not really. Which environment variable? GXX_UNDER_TEST is an example of one of the variables that plays into this, it happens to be an environment variable. What sets the value of this variable? We will expect you to be able to find the code and read it. The code you want to read is over in gcc/gcc/testsuite/lib/g++.exp, you should be able to tell us what sets it and when after you spend 10 seconds reading the code. In addition to that code, check out *.exp, and ../.*/*.exp and then dejagnu/lib/*.exp and dejagnu/config/*.exp, after that, you'll be an expert. Is it a script or a program? Yes, more a script. What have I configured wrong, if anything? Don't know. If this really is a bug, then why does the test work for Andreas Jaeger and not for me? Don't know. http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00112.html Should I file another bug report and hope that I don't kust get WORKSFORME? No. Wild ass guess, did you type make -k check?
Re: GCC 4.0.1 testsuite uses installed g++ instead of newly bootstrapped g++
Hi Lance, Thanks for your prompt reply. Point by point, below. Best regards, Paul Leopardi On Thu, 28 Jul 2005 10:26 am, Ian Lance Taylor wrote: > "Paul C. Leopardi" <[EMAIL PROTECTED]> writes: > > Hi all, > > I did not receive a reply to my earlier message. Have I posted it to the > > wrong list? If so, what is the right list for this message? > > Thanks > > > > On Sat, 23 Jul 2005 07:23 pm, Paul C. Leopardi wrote: > > > How do I make the tests find the bootstrapped g++? Shouldn't the test > > > just do this automatically? How is the test supposed to find find the > > > bootstrapped g++? Is it done via an environment variable? Which > > > environment variable? What sets the value of this variable? Is it a > > > script or a program? > > > > > > What have I configured wrong, if anything? If this really is a bug, > > > then why does the test work for Andreas Jaeger and not for me? > > > http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00112.html > > > > > > Should I file another bug report and hope that I don't kust get > > > WORKSFORME? Best regards > > This is probably the right list. It's just that nobody happened to > reply. gcc is a volunteer effort, particularly when it comes to > answering questions on the mailing lists. OK. I understand this. I also know that getting my problem resolved is going to be a cooperative effort, probably involving hours and hours of work on my part. I have already spent many hours on this, having bootstrapped and tested g++ 3.4 and 4.0.1 numerous times. It's just that I don't know enough about how the test code is supposed to work to be able to resolve a problem when I see it. In paricular, I have not seen a detailed example of the c++ test working, and so cannot compare with my own case. > In this case, it's hard to write a useful reply since you didn't > provide any informative details. I gave links to threads on this and other mailing lists, and referenced bug 15356. I also gave excerpts of test output. Other than that, I did not want to bombard the list with megabytes of "-v -v" test output which may not be needed. Rather I wanted to wait for guidance on what details to provide. > It is true that running the > testsuite will normally use a newly built compiler, without requiring > it to be installed. However, you didn't provide critical information > like precisely what you did, I said (via the URL links) that I bootstrapped gcc 4.0.1 on SUSE Linux 9.2 AMD64, and tested gcc and g++, and that gcc worked and g++ did not work. Contents of http://lists.suse.com/archive/suse-amd64/2005-Jul/0156.html From: "Paul C. Leopardi" <[EMAIL PROTECTED]> Date: Thu, 21 Jul 2005 11:49:54 +1000 Message-Id: <[EMAIL PROTECTED]> Subject: [suse-amd64] Configuring gcc 4.0.1 Hi all, I'm using SUSE 9.2 AMD64, and have downloaded the latest gcc and am about to bootstrap. Is there anyone who can help me with configuration, bootstrap, test and install? I've run into problems with the testsuite and I don't know whether I have done something wrong or am seeing a bug. I also don't know if what I see is specific to SUSE AMD64, or specific to the current state of my PC. First question: Is there anything wrong with the parameters I am giving to configure? (see below) Best regards My current gcc: [EMAIL PROTECTED]:~/src/gcc/gcc-4.0.1-obj> gcc -v Reading specs from /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.4/specs Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --enable-languages=c,c++,f77,objc,java,ada --disable-checking --libdir=/usr/lib64 --enable-libgcj --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib64 --with-system-zlib --enable-shared --enable-__cxa_atexit x86_64-suse-linux Thread model: posix gcc version 3.3.4 (pre 3.3.5 20040809) I've run configure in the directory ~/src/gcc/gcc-4.0.1-obj as [EMAIL PROTECTED]:~/src/gcc/gcc-4.0.1-obj> ../gcc-4.0.1/configure --prefix=/usr/local/gcc/gcc-4.0.1 --enable-threads=posix --disable-libgcj --with-system-zlib --enable-shared --enable-__cxa_atexit --enable-languages=c,c++ x86_64-suse-linux This looks like it worked, but gave the warning: configure: warning: x86_64-suse-linux: invalid host type Contents of http://lists.suse.com/archive/suse-amd64/2005-Jul/0171.html From: "Paul C. Leopardi" <[EMAIL PROTECTED]> Date: Sat, 23 Jul 2005 00:59:47 +1000 Message-Id: <[EMAIL PROTECTED]> Subject: [suse-amd64] Testing gcc 4.0.1 Hi all, This is a follow-up to "Configuring gcc 4.0.1". I made sure that I no longer had CXX defined in my .bashrc, and then started from scratch: Created gcc-4.0.1-obj Ran ./configure Ran make bootstrap Ran make -k check The gcc result looks OK. The g++ result does not. === g++ Summary === # of expected passes 9113 # of unexpected failures 2166 # of unexpected successes 16 # of expected failure
Re: GCC 4.0.1 testsuite uses installed g++ instead of newly bootstrapped g++
"Paul C. Leopardi" <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED]:~/src/gcc/gcc-4.0.1-obj> ../gcc-4.0.1/configure > --prefix=/usr/local/gcc/gcc-4.0.1 --enable-threads=posix --disable-libgcj > --with-system-zlib --enable-shared --enable-__cxa_atexit > --enable-languages=c,c++ x86_64-suse-linux > > This looks like it worked, but gave the warning: > > configure: warning: x86_64-suse-linux: invalid host type This is not good, of course, though I doubt it is causing any of your problems. In general if you are building a native compiler you should not need to specify any configuration triplet at all. Can you confirm that the executables gcc/g++ and gcc/cc1plus exist? What does site.exp look like in the gcc/testsuite subdirectory? Does it have the line "set TESTING_IN_BUILD_TREE 1"? Which version of dejagnu do you have installed? Ian
Re: GCC 4.0.1 testsuite uses installed g++ instead of newly bootstrapped g++
Mike,
Thanks. Reply below.
Best regards, Paul Leopardi
On Thu, 28 Jul 2005 10:40 am, Mike Stump wrote:
> On Jul 27, 2005, at 5:21 PM, Paul C. Leopardi wrote:
> >> What sets the value of this variable?
>
> We will expect you to be able to find the code and read it. The code
> you want to read is over in gcc/gcc/testsuite/lib/g++.exp, you should
> be able to tell us what sets it and when after you spend 10 seconds
> reading the code.
From what I see in that file, proc g++_init sets the compiler via
GXX_UNDER_TEST, proc g++_target_compile uses GXX_UNDER_TEST to invoke the
compiler, and proc g++_version can be used to print and therefore verify the
compiler version.
> In addition to that code, check out *.exp, and ../.*/*.exp and then
> dejagnu/lib/*.exp and dejagnu/config/*.exp, after that, you'll be an
> expert.
OK. Looks like a long term project.
> Wild ass guess, did you type make -k check?
Yes. Is there something wrong with that?
In output of make -k check, I did notice that autogen is missing, causing an
"Error 2", but the test carries on regardless. Is this OK?
make[1]: Entering directory `/home/leopardi/src/gcc/gcc-4.0.1-obj/fixincludes'
autogen
-T ../../gcc-4.0.1/fixincludes/check.tpl
../../gcc-4.0.1/fixincludes/inclhack.def
make[1]: autogen: Command not found
make[1]: *** [check] Error 127
make[1]: Leaving directory `/home/leopardi/src/gcc/gcc-4.0.1-obj/fixincludes'
make: *** [check-fixincludes] Error 2
make[1]: Entering directory `/home/leopardi/src/gcc/gcc-4.0.1-obj/gcc'
Making a new config file...
SUSE packaged autogen for SUSE Linux 9.3, but not for my version, SUSE Linux
9.2. Should I just stop now, install autogen and try again?
http://www.novell.com/products/linuxpackages/professional/autogen.html
http://rpm.pbone.net/index.php3/stat/4/idpl/1805805/com/autogen-5.6.5-3.i586.rpm.html
Also, gcc summary says:
=== gcc Summary ===
# of expected passes34550
# of unexpected successes 1
# of expected failures 105
# of untested testcases 28
# of unsupported tests 433
/home/leopardi/src/gcc/gcc-4.0.1-obj/gcc/xgcc version 4.0.1
I guess that the last line of gcc summary is printed by proc
default_gcc_version in gcc.exp.
The preamble to g++ testing says:
make[1]: [check-gcc] Error 1 (ignored)
(rootme=`${PWDCMD-pwd}`; export rootme; \
srcdir=`cd ../../gcc-4.0.1/gcc; ${PWDCMD-pwd}` ; export srcdir ; \
cd testsuite; \
EXPECT=expect ; export EXPECT ; \
if [ -f ${rootme}/../expect/expect ] ; then \
TCL_LIBRARY=`cd .. ; cd ../../gcc-4.0.1/gcc/../tcl/library ;
${PWDCMD-pwd}` ; \
export TCL_LIBRARY ; fi ; \
runtest --tool g++ )
Test Run By leopardi on Sat Jul 23 00:05:15 2005
Native configuration is x86_64-suse-linux-gnu
Is the command "runtest --tool g++" correct? I noticed that proc g++_init
contains the code:
if ![info exists GXX_UNDER_TEST] then {
if [info exists TOOL_EXECUTABLE] {
set GXX_UNDER_TEST $TOOL_EXECUTABLE;
Does "runtest --tool g++" set TOOL_EXECUTABLE to "g++" ?
Finally, in the output of "make -k check", g++ summary says:
=== g++ Summary ===
# of expected passes9113
# of unexpected failures2166
# of unexpected successes 16
# of expected failures 54
# of unresolved testcases 61
# of untested testcases 54
# of unsupported tests 90
/usr/bin/g++ version 3.3.4 (pre 3.3.5 20040809)
I guess that the last line of g++ summary is printed by proc g++_version in
g++.exp. Does this imply that proc g++_init has set the compiler via
GXX_UNDER_TEST to either "/usr/bin/g++" or more likely, "g++" ?
Re: GCC 4.0.1 testsuite uses installed g++ instead of newly bootstrapped g++
"Paul C. Leopardi" <[EMAIL PROTECTED]> writes:
> The preamble to g++ testing says:
>
> make[1]: [check-gcc] Error 1 (ignored)
> (rootme=`${PWDCMD-pwd}`; export rootme; \
> srcdir=`cd ../../gcc-4.0.1/gcc; ${PWDCMD-pwd}` ; export srcdir ; \
> cd testsuite; \
> EXPECT=expect ; export EXPECT ; \
> if [ -f ${rootme}/../expect/expect ] ; then \
>TCL_LIBRARY=`cd .. ; cd ../../gcc-4.0.1/gcc/../tcl/library ;
> ${PWDCMD-pwd}` ; \
> export TCL_LIBRARY ; fi ; \
> runtest --tool g++ )
> Test Run By leopardi on Sat Jul 23 00:05:15 2005
> Native configuration is x86_64-suse-linux-gnu
>
> Is the command "runtest --tool g++" correct? I noticed that proc g++_init
> contains the code:
> if ![info exists GXX_UNDER_TEST] then {
> if [info exists TOOL_EXECUTABLE] {
> set GXX_UNDER_TEST $TOOL_EXECUTABLE;
> Does "runtest --tool g++" set TOOL_EXECUTABLE to "g++" ?
No. (Although --tool_executable=g++ would.) But --tool g++ is
correct. GXX_UNDER_TEST is normally set by the clauses after the ones
you showed.
> Finally, in the output of "make -k check", g++ summary says:
>
> === g++ Summary ===
>
> # of expected passes 9113
> # of unexpected failures 2166
> # of unexpected successes 16
> # of expected failures54
> # of unresolved testcases 61
> # of untested testcases 54
> # of unsupported tests90
> /usr/bin/g++ version 3.3.4 (pre 3.3.5 20040809)
>
> I guess that the last line of g++ summary is printed by proc g++_version in
> g++.exp. Does this imply that proc g++_init has set the compiler via
> GXX_UNDER_TEST to either "/usr/bin/g++" or more likely, "g++" ?
GXX_UNDER_TEST has been set to /usr/bin/g++.
Ian
Re: GCC 4.0.1 testsuite uses installed g++ instead of newly bootstrapped g++
On Thu, Jul 28, 2005 at 10:53:02AM +1000, Paul C. Leopardi wrote: > [EMAIL PROTECTED]:~/src/gcc/gcc-4.0.1-obj> ../gcc-4.0.1/configure > --prefix=/usr/local/gcc/gcc-4.0.1 --enable-threads=posix --disable-libgcj > --with-system-zlib --enable-shared --enable-__cxa_atexit > --enable-languages=c,c++ x86_64-suse-linux > > This looks like it worked, but gave the warning: > > configure: warning: x86_64-suse-linux: invalid host type It is a known issue: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122570 It shouldn't cause any problems. H.J.
Re: GCC 4.0.1 testsuite uses installed g++ instead of newly bootstrapped g++
Hi all, a quick follow-up below. Best regards, Paul Leopardi On Thu, 28 Jul 2005 12:04 pm, Paul C. Leopardi wrote: > In output of make -k check, I did notice that autogen is missing, causing > an "Error 2", but the test carries on regardless. Is this OK? ... > SUSE packaged autogen for SUSE Linux 9.3, but not for my version, SUSE > Linux 9.2. Should I just stop now, install autogen and try again? I checked http://gcc.gnu.org/install/prerequisites.html Under "Tools/packages necessary for modifying GCC" it has autogen version 5.5.4 (or later) My fault, but... I'm just testing my bootstrap and am not intending to modify gcc, so I didn't pay attention to this section. Especially since the boostrap of gcc and g++ seemed to go OK this time. I now see that many of the other packages listed are also prerequsites for testing gcc and not only prerequisties for modifying gcc. Maybe the heading should say: "Tools/packages necessary for testing or modifying GCC" to save newbies like me from hours and hours of pain and frustration?
Re: GCC 4.0.1 testsuite uses installed g++ instead of newly bootstrapped g++
"Paul C. Leopardi" <[EMAIL PROTECTED]> writes: > I checked http://gcc.gnu.org/install/prerequisites.html > Under "Tools/packages necessary for modifying GCC" it has > > autogen version 5.5.4 (or later) > > My fault, but... I'm just testing my bootstrap and am not intending to modify > gcc, so I didn't pay attention to this section. Especially since the boostrap > of gcc and g++ seemed to go OK this time. I now see that many of the other > packages listed are also prerequsites for testing gcc and not only > prerequisties for modifying gcc. > > Maybe the heading should say: > > "Tools/packages necessary for testing or modifying GCC" > > to save newbies like me from hours and hours of pain and frustration? No, autogen is generally not required to test the compiler. That isn't the problem you are encountering. Ian
Re: PLEASE HELP!!
If you really need to just jump into it you can try Chinook (http://www.degarrah.com/chinookfree.php). It's a cross platform IDE that ships with GCC/GDB and is free. Chris louise kelliher wrote: Hiya, im wondering if you could help me, Im at my wits end and need to cover c programming before I start a foundation internet technology course in September. I have been trying for 2 weeks and cant get past the first page. Please could you tell me how to download gcc -v on a windows xp computer. I found a list but none of them said MinGW-1.1.tar.gz and now I think Ive downloaded the wrong one as it wont work, and also I dont know how to create a directory. Please help me. Thanks for your time. Louise Kelliher
