Bus error gcc compiler for any for ( x in array ) inside Objective-C++ template
Hi,
I've encountered a bus error using Apple's gcc in Xcode 3.1, 3.2
compiling the following code or any containing for( x in y ) is used
inside a template in Objective-C++.
template
class OODictionary {
void boom() {
NSArray *keys = nil;
for ( NSString *key in keys ) {
}
}
};
I've not been able to build with a more recent gcc so I can't tell
if it is still present but figure I'd better let you guys know.
Thanks,
John H.
http://objcpp.johnholdsworth.com
On 8 Sep 2009, at 21:30, John Holdsworth wrote:
Hi,
I've found it very useful to be able to use C++ to extend Objective-C
using a little judicious operator overloading and I notice that
gcc-4.2
now automatically "unboxes" wrapper classes with no warning when
they are messaged - provided an appropriate cast is available.
For example:
class AStringClass {
NSMutaableString *str;
public:
AStringClass( NSMutableString *str ) {
this->str = str;
}
operator NSMutableString * () {
return str;
}
};
This class can now be messaged in gcc4.2 as below without a warning:
AStringClass aString( nil );
[aString doubleValue];
Unfortunately is can also be sent a message which the compiler
is in a position to know is not available given the only cast
available was to a NSMutableString:
[aString count]; // not a valid method for NSMutableString *
This happens as internally as there is an implicit cast to type "id"
in
${GCCROOT}gcc/objc/objc-act,c, function: objc_finish_message_expr
/* APPLE LOCAL begin decay function/array receivers */
#ifndef OBJCPLUS
/* In C need to decay array/function receivers so can be converted
to id. */
struct c_expr exp;
exp.value = receiver;
exp = default_function_array_conversion (exp);
receiver = exp.value;
/* APPLE LOCAL begin radar 3533972 */
#else
if (can_convert_arg (objc_object_type, TREE_TYPE (receiver),
receiver, LOOKUP_NORMAL))
{
/* In rare cases, 'receiver' must be converted to type 'id'
using
user-defined type conversion. 'id' is type of the 1st
argument to
objc_msgSend (id self, SEL op, ...); */
tree cnv_rec = perform_implicit_conversion (objc_object_type,
receiver);
if (cnv_rec && cnv_rec != error_mark_node)
return objc_finish_message_expr (cnv_rec, sel_name,
method_params);
}
/* APPLE LOCAL end radar 3533972 */
#endif
Would it not be possible for the implicit conversion retain the type
which it was forced into using when searching for a match for "id"
and using this as the type of the receiver of the message rather
than "id". I've looked and the code but can't quite get to where
the change (probably quite a small one) would need to be made.
Perhaps even, this is already fixed...
Can anybody help?
John Holdsworth
objcpp.johnholdsworth.com
On 8 Apr 2009, at 14:34, David Ayers wrote:
Am Samstag, den 21.03.2009, 11:59 +0100 schrieb John Holdsworth:
I was wondering if it would be a useful extension to Objective-C
expand the [] operator
to support array and hash references to NSArray and NSDictionary
classes directly to
greatly improve the readability of code:
I'm not an ObjC front end maintainer and have no authority but one
issue
I would have with this feature with gcc proper is that the ObjC front
end would have to learn about the semantics of "NSArray" and
"NSDictionary" which are actually not part of the language but part
of
an external library.
Now gcc already supports the -fconstant-string-class option as one
way
to embed knowledge about an external library into an executable.
But I
would like adding options with all these semantics from a foreign
library into the language implementation.
Maybe this could be done more elegantly with plugin infrastructure
that
that es being currently added: http://gcc.gnu.org/wiki/plugins
Cheers,
David
problems with gcc installation
Hi, I need to intall gcc-2.5.8 on opensolaris. In the "make" step, I get the following message: r...@opensolaris:/export/home/sea/Desktop/gcc-2.5.8# make cc -DIN_GCC -g -I. -I. -I./config \ -DGCC_INCLUDE_DIR=\"/usr/local/gcc258/lib/gcc-lib/i386-sun-sunos5.11/2.5.8/include\" \ -DGPLUSPLUS_INCLUDE_DIR=\"/usr/local/gcc258/lib/g++-include\" \ -DLOCAL_INCLUDE_DIR=\"/usr/local/include\" \ -DCROSS_INCLUDE_DIR=\"/usr/local/gcc258/lib/gcc-lib/i386-sun-sunos5.11/2.5.8/sys-include\" \ -DTOOL_INCLUDE_DIR=\"/usr/local/gcc258/i386-sun-sunos5.11/include\" \ -DTOOLDIR=\"/usr/local/gcc258/i386-sun-sunos5.11/\" \ -c `echo ./cccp.c | sed 's,^\./,,'` cccp.c: In function `bzero': cccp.c:8966: error: argument "b" doesn't match prototype cccp.c:240: error: prototype declaration cccp.c: In function `bcopy': cccp.c:8976: error: argument "b1" doesn't match prototype cccp.c:240: error: prototype declaration cccp.c:8976: error: argument "b2" doesn't match prototype cccp.c:240: error: prototype declaration cccp.c: In function `bcmp': cccp.c:8986: error: argument "b1" doesn't match prototype cccp.c:240: error: prototype declaration cccp.c:8986: error: argument "b2" doesn't match prototype cccp.c:240: error: prototype declaration *** Error code 1 make: Fatal error: Command failed for target `cccp.o' I am trapped in this problem for ages.:-( Can anyone give me some help? Thanks a great deal -- View this message in context: http://www.nabble.com/problems-with-gcc-installation-tp25904582p25904582.html Sent from the gcc - Dev mailing list archive at Nabble.com.
RE: Turning off unrolling to certain loops
Hello,
I faced a similar issue a while ago. I filed a bug report
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712) In the end,
I implemented a simple tree-level unrolling pass in our port
which uses all the existing infrastructure. It works quite well for
our purpose, but I hesitated to submit the patch because it contains
our not-very-elegannt #prgama unroll implementation.
The following two functions do the unrolling. I insert the pass
just after the loop_prefetch pass (4.4)
Cheers,
Bingfeng Mei
/* Perfect unrolling of a loop */
static void tree_unroll_perfect_loop (struct loop *loop, unsigned factor,
edge exit)
{
sbitmap wont_exit;
edge e;
bool ok;
unsigned i;
VEC (edge, heap) *to_remove = NULL;
/* Unroll the loop and remove the exits in all iterations except for the
last one. */
wont_exit = sbitmap_alloc (factor);
sbitmap_ones (wont_exit);
RESET_BIT (wont_exit, factor - 1);
ok = gimple_duplicate_loop_to_header_edge
(loop, loop_latch_edge (loop), factor - 1,
wont_exit, exit, &to_remove, DLTHE_FLAG_UPDATE_FREQ);
free (wont_exit);
gcc_assert (ok);
for (i = 0; VEC_iterate (edge, to_remove, i, e); i++)
{
ok = remove_path (e);
gcc_assert (ok);
}
VEC_free (edge, heap, to_remove);
update_ssa (TODO_update_ssa);
#ifdef ENABLE_CHECKING
verify_flow_info ();
verify_dominators (CDI_DOMINATORS);
verify_loop_structure ();
verify_loop_closed_ssa ();
#endif
}
/* Go through all the loops:
1. Determine unrolling factor
2. Unroll loops in different conditions
-- perfect loop: no extra copy of original loop
-- other loops: the original version of loops to execute the remaining
iterations
*/
static unsigned int rest_of_tree_unroll (void)
{
loop_iterator li;
struct loop *loop;
unsigned ninsns, unroll_factor;
HOST_WIDE_INT est_niter;
struct tree_niter_desc desc;
bool unrolled = false;
initialize_original_copy_tables ();
/* Scan the loops, inner ones first. */
FOR_EACH_LOOP (li, loop, LI_FROM_INNERMOST)
{
est_niter = estimated_loop_iterations_int (loop, false);
ninsns = tree_num_loop_insns (loop, &eni_size_weights);
unroll_factor = determine_unroll_factor (loop, ninsns, &desc, est_niter);
if (unroll_factor != 1)
{
tree niters = number_of_exit_cond_executions(loop);
bool perfect_unrolling = false;
if(niters != NULL_TREE && niters!= chrec_dont_know && TREE_CODE(niters)
== INTEGER_CST){
int num_iters = tree_low_cst(niters, 1);
if((num_iters % unroll_factor) == 0)
perfect_unrolling = true;
}
/* If no. of iterations can be divided by unrolling factor, we have
perfect unrolling */
if(perfect_unrolling){
tree_unroll_perfect_loop(loop, unroll_factor, single_dom_exit(loop));
}
else{
tree_unroll_loop (loop, unroll_factor, single_dom_exit (loop), &desc);
}
unrolled = true;
}
}
free_original_copy_tables ();
/* Need to rebuild call graph due if new function calls are created due to
loop unrolling
FIXME: rebuild cgraph will lose some information like reason of not
inlining*/
if(unrolled)
rebuild_cgraph_edges();
/*debug_cgraph();*/
return 0;
}
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On
> Behalf Of Jean Christophe Beyler
> Sent: 14 October 2009 19:29
> To: Zdenek Dvorak
> Cc: gcc@gcc.gnu.org
> Subject: Re: Turning off unrolling to certain loops
>
> Ok, I've actually gone a different route. Instead of waiting for the
> middle end to perform this, I've directly modified the parser stage to
> unroll the loop directly there.
>
> Basically, I take the parser of the for and modify how it adds the
> various statements. Telling it to, instead of doing in the
> c_finish_loop :
>
> if (body)
> add_stmt (body);
> if (clab)
> add_stmt (build1 (LABEL_EXPR, void_type_node, clab));
> if (incr)
> add_stmt (incr);
> ...
>
> I tell it to add multiple copies of body and incr and the at the end
> add in the loop the rest of it. I've also added support to remove
> further unrolling to these modified loops and will be handling the
> "No-unroll" pragma. I then let the rest of the optimization passes,
> fuse the incrementations together if possible, etc.
>
> The initial results are quite good and seem to work and
> produce good code.
>
> Currently, there are two possibilities :
>
> - If the loop is not in the form we want, for example:
>
> for (;i {
> ...
> }
>
> Do we still unroll even though we have to trust the user that the
> number of unrolling will not break the semantics ?
>
> To handle this, I am adding warnings that will appear if the loop is
> anything but :
>
> for (i=C1; i < C2; i ++)
> {
> ...
> }
>
> Later on, once this is thoroughly tested, I will allow :
>
help: standard name of vector mode
I'm porting gcc , and use its autovectorization. How can I know wether a standard name support a vector mode ? Thanks!
Re: Turning off unrolling to certain loops
Hi,
> I faced a similar issue a while ago. I filed a bug report
> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712) In the end,
> I implemented a simple tree-level unrolling pass in our port
> which uses all the existing infrastructure. It works quite well for
> our purpose, but I hesitated to submit the patch because it contains
> our not-very-elegannt #prgama unroll implementation.
could you please do so anyway? Even if there are some issues with the
#prgama unroll implementation, it could serve as a basis of a usable
patch.
> /* Perfect unrolling of a loop */
> static void tree_unroll_perfect_loop (struct loop *loop, unsigned factor,
> edge exit)
> {
> ...
> }
>
>
>
> /* Go through all the loops:
> 1. Determine unrolling factor
> 2. Unroll loops in different conditions
> -- perfect loop: no extra copy of original loop
> -- other loops: the original version of loops to execute the
> remaining iterations
> */
> static unsigned int rest_of_tree_unroll (void)
> {
...
>tree niters = number_of_exit_cond_executions(loop);
>
>bool perfect_unrolling = false;
>if(niters != NULL_TREE && niters!= chrec_dont_know &&
> TREE_CODE(niters) == INTEGER_CST){
> int num_iters = tree_low_cst(niters, 1);
> if((num_iters % unroll_factor) == 0)
>perfect_unrolling = true;
>}
>
>/* If no. of iterations can be divided by unrolling factor, we have
> perfect unrolling */
>if(perfect_unrolling){
> tree_unroll_perfect_loop(loop, unroll_factor, single_dom_exit(loop));
>}
>else{
> tree_unroll_loop (loop, unroll_factor, single_dom_exit (loop),
> &desc);
>}
It would be better to move this test to tree_unroll_loop, and not
duplicate its code in tree_unroll_perfect_loop.
Zdenek
GCC 4.4.2 Status Report (2009-10-15)
Status == GCC 4.4.2 release tarballs have been uploaded, the 4.4 branch is again open for commits under the usual release branch rules. I'll announce the release once mirrors had some time to download it. Quality Data Priority # Change from Last Report --- --- P11 - 3 P2 88 - 1 P35 + 4 --- --- Total94 0 Previous Report === http://gcc.gnu.org/ml/gcc/2009-09/msg00025.html The next report for 4.4.3 will be sent by Richard.
Storing 16bit values in upper part of 32bit registers
Hi,
I am working with an architecture where the 32bit registers (rN) are
divided into high (rNh) and low (rNl) 16bit sub registers that can in
principle be individually accessed by the instructions in the IS.
However the IS is designed so that it is beneficial to to store 16bit
values in the high part of the registers (rNh) and also the calling
conventions that we want follow require 16bit values to be passed and
returned in rNh.
What would be the "proper way" make the compiler use the upper parts
of these registers for the 16bit operands?
Currently this is done by having the registers in two register classes
('full' and 'high_only') and printing the 'h' in the output template
when the constraint matches the 'high_only' class. This however causes
problems when converting between 16 and 32bit operands. One annoying
example is returning scalar values. E.g. assume that a 32bit variable
(long) is assigned to a 16bit variable (int) like in
int foo(void)
{
long sum;
...
return (int)sum;
}
then we want the low part of sum to be moved to the high part of the
return register r0h. However TARGET_FUNCTION_VALUE only seem to allow
me to return the RTX for register r0 but not the subreg for r0h so the
compiler will not emit the necessary RTL to move the value from the
low part of sum to r0h before the return. This (and probably many
other issues that I am about to discover) makes me think that maybe
this is not the ideal way to do this. I have searched the available
ports but have not been able to find any which seem to use its
registers in a similar way. Any advice or pointers to code to look
into would be much appreciated.
Thanks in advance.
/Markus
Re: Storing 16bit values in upper part of 32bit registers
Hi Marcus,
Though I am novice in gcc , I think I can answer your
question.
As far as I know, your load instruction will take care
of this issue.
You need to restrict your load instruction so that it
will place your return value of function in lower register.
So Ideally , the instruction will be like , load r0h
with the content pointer by that instruction. ( Assuming you have 16
bit load instruction with 16-bit loading capability)
Thanks,
Sumanth G
Markus L wrote:
Hi,
I am working with an architecture where the 32bit registers (rN) are
divided into high (rNh) and low (rNl) 16bit sub registers that can in
principle be individually accessed by the instructions in the IS.
However the IS is designed so that it is beneficial to to store 16bit
values in the high part of the registers (rNh) and also the calling
conventions that we want follow require 16bit values to be passed and
returned in rNh.
What would be the "proper way" make the compiler use the upper parts
of these registers for the 16bit operands?
Currently this is done by having the registers in two register classes
('full' and 'high_only') and printing the 'h' in the output template
when the constraint matches the 'high_only' class. This however causes
problems when converting between 16 and 32bit operands. One annoying
example is returning scalar values. E.g. assume that a 32bit variable
(long) is assigned to a 16bit variable (int) like in
int foo(void)
{
long sum;
...
return (int)sum;
}
then we want the low part of sum to be moved to the high part of the
return register r0h. However TARGET_FUNCTION_VALUE only seem to allow
me to return the RTX for register r0 but not the subreg for r0h so the
compiler will not emit the necessary RTL to move the value from the
low part of sum to r0h before the return. This (and probably many
other issues that I am about to discover) makes me think that maybe
this is not the ideal way to do this. I have searched the available
ports but have not been able to find any which seem to use its
registers in a similar way. Any advice or pointers to code to look
into would be much appreciated.
Thanks in advance.
/Markus
Re: Turning off unrolling to certain loops
You are entirely correct, I hadn't thought that through enough.
So I backtracked and have just merged what Bingfeng Mei has done with
your code and have now a corrected version of the loop unrolling.
What I did was directly modified tree_unroll_loop to handle the case
of a perfect unroll or not internally and then used something similar
to what you had done around that. I added what I think is needed to
stop unrolling of those loops in later passes.
I'll be starting my tests but I can port it to 4.5 if you are
interested to see what I did.
Jc
On Thu, Oct 15, 2009 at 6:00 AM, Zdenek Dvorak wrote:
> Hi,
>
>> I faced a similar issue a while ago. I filed a bug report
>> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712) In the end,
>> I implemented a simple tree-level unrolling pass in our port
>> which uses all the existing infrastructure. It works quite well for
>> our purpose, but I hesitated to submit the patch because it contains
>> our not-very-elegannt #prgama unroll implementation.
>
> could you please do so anyway? Even if there are some issues with the
> #prgama unroll implementation, it could serve as a basis of a usable
> patch.
>
>> /* Perfect unrolling of a loop */
>> static void tree_unroll_perfect_loop (struct loop *loop, unsigned factor,
>> edge exit)
>> {
>> ...
>> }
>>
>>
>>
>> /* Go through all the loops:
>> 1. Determine unrolling factor
>> 2. Unroll loops in different conditions
>> -- perfect loop: no extra copy of original loop
>> -- other loops: the original version of loops to execute the
>> remaining iterations
>> */
>> static unsigned int rest_of_tree_unroll (void)
>> {
> ...
>> tree niters = number_of_exit_cond_executions(loop);
>>
>> bool perfect_unrolling = false;
>> if(niters != NULL_TREE && niters!= chrec_dont_know &&
>> TREE_CODE(niters) == INTEGER_CST){
>> int num_iters = tree_low_cst(niters, 1);
>> if((num_iters % unroll_factor) == 0)
>> perfect_unrolling = true;
>> }
>>
>> /* If no. of iterations can be divided by unrolling factor, we have
>> perfect unrolling */
>> if(perfect_unrolling){
>> tree_unroll_perfect_loop(loop, unroll_factor,
>> single_dom_exit(loop));
>> }
>> else{
>> tree_unroll_loop (loop, unroll_factor, single_dom_exit (loop),
>> &desc);
>> }
>
> It would be better to move this test to tree_unroll_loop, and not
> duplicate its code in tree_unroll_perfect_loop.
>
> Zdenek
>
Re: GCC 4.4.2 Status Report (2009-10-15)
Jakub Jelinek wrote: Status == GCC 4.4.2 release tarballs have been uploaded, the 4.4 branch is again open for commits under the usual release branch rules. I'll announce the release once mirrors had some time to download it. The onlinedocs already point to 4.4.2 but there is a permission issue accessing onlinedocs/gcc-4.4.2/gcc/ (i.e. 403) Regards, Ryan Mansfield
Re: Storing 16bit values in upper part of 32bit registers
On 10/15/2009 07:41 AM, Markus L wrote: However the IS is designed so that it is beneficial to to store 16bit values in the high part of the registers (rNh) and also the calling conventions that we want follow require 16bit values to be passed and returned in rNh. What would be the "proper way" make the compiler use the upper parts of these registers for the 16bit operands? This feature is going to be difficult, but not impossible, and unless your ISA has some really odd features I won't vouch for the code quality. You say you want to canonically represent HImode in the high-part of the register. Additionally, you'll have to represent QImode in the high-part (if not further in the high byte). You'll need to follow the mips port and define TRULY_NOOP_TRUNCATION and the associated truncMN2 patterns. If you do all this, you won't have to do anything with FUNCTION_VALUE etc at all. r~
RE: Turning off unrolling to certain loops
Jc,
How did you implement #pragma unroll? I checked other compilers. The
pragma should govern the next immediate loop. It took me a while to
find a not-so-elegant way to do that. I also implemented #pragma ivdep.
These information are supposed to be passed through both tree and RTL
levels and suvive all GCC optimization. I still have problem in handling
combination of unroll and ivdep.
Bingfeng
> -Original Message-
> From: fearyours...@gmail.com [mailto:fearyours...@gmail.com]
> On Behalf Of Jean Christophe Beyler
> Sent: 15 October 2009 16:34
> To: Zdenek Dvorak
> Cc: Bingfeng Mei; gcc@gcc.gnu.org
> Subject: Re: Turning off unrolling to certain loops
>
> You are entirely correct, I hadn't thought that through enough.
>
> So I backtracked and have just merged what Bingfeng Mei has done with
> your code and have now a corrected version of the loop unrolling.
>
> What I did was directly modified tree_unroll_loop to handle the case
> of a perfect unroll or not internally and then used something similar
> to what you had done around that. I added what I think is needed to
> stop unrolling of those loops in later passes.
>
> I'll be starting my tests but I can port it to 4.5 if you are
> interested to see what I did.
> Jc
>
> On Thu, Oct 15, 2009 at 6:00 AM, Zdenek Dvorak
> wrote:
> > Hi,
> >
> >> I faced a similar issue a while ago. I filed a bug report
> >> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712) In the end,
> >> I implemented a simple tree-level unrolling pass in our port
> >> which uses all the existing infrastructure. It works quite well for
> >> our purpose, but I hesitated to submit the patch because
> it contains
> >> our not-very-elegannt #prgama unroll implementation.
> >
> > could you please do so anyway? Even if there are some
> issues with the
> > #prgama unroll implementation, it could serve as a basis of a usable
> > patch.
> >
> >> /* Perfect unrolling of a loop */
> >> static void tree_unroll_perfect_loop (struct loop *loop,
> unsigned factor,
> >> edge exit)
> >> {
> >> ...
> >> }
> >>
> >>
> >>
> >> /* Go through all the loops:
> >> 1. Determine unrolling factor
> >> 2. Unroll loops in different conditions
> >> -- perfect loop: no extra copy of original loop
> >> -- other loops: the original version of loops to
> execute the remaining iterations
> >> */
> >> static unsigned int rest_of_tree_unroll (void)
> >> {
> > ...
> >> tree niters = number_of_exit_cond_executions(loop);
> >>
> >> bool perfect_unrolling = false;
> >> if(niters != NULL_TREE && niters!= chrec_dont_know
> && TREE_CODE(niters) == INTEGER_CST){
> >> int num_iters = tree_low_cst(niters, 1);
> >> if((num_iters % unroll_factor) == 0)
> >> perfect_unrolling = true;
> >> }
> >>
> >> /* If no. of iterations can be divided by unrolling
> factor, we have perfect unrolling */
> >> if(perfect_unrolling){
> >> tree_unroll_perfect_loop(loop, unroll_factor,
> single_dom_exit(loop));
> >> }
> >> else{
> >> tree_unroll_loop (loop, unroll_factor,
> single_dom_exit (loop), &desc);
> >> }
> >
> > It would be better to move this test to tree_unroll_loop, and not
> > duplicate its code in tree_unroll_perfect_loop.
> >
> > Zdenek
> >
>
>
Question on C++-0x constexpr
I was toying around with constexpr in the standard library and tripped
on this:
// /bin/bin/g++ -std=c++0x -c template_constexpr.cpp
template
class A
{
static constexpr int foo() { return 666; }
};
template
class B
{
static constexpr int foo() { return e.foo(); } // Should the
compiler be able to noodle this out?
static constexpr int bar() { return E::foo(); } // Works fine.
private:
E e;
};
template_constexpr.cpp: In static member function 'static int B::foo()':
template_constexpr.cpp:16:5: error: invalid use of member 'B::e' in
static member function
template_constexpr.cpp:13:39: error: from this location
Question, if you can use a member access operator to access a static
member, shouldn't constexpr work through that method too?
Thanks,
Ed Smith-Rowland
Re: Turning off unrolling to certain loops
I implemented it like this:
- I modified c_parser_for_statement to include a pragma tree node in
the loop with the unrolling request as an argument
- Then during my pass to handle unrolling, I parse the loop to find the pragma.
- I retrieve the unrolling factor and use a merge of Zdenek's
code and yours to perform either a perfect unrolling or and register
it in the loop structure
- During the following passes that handle loop unrolling, I
look at that variable in the loop structure to see if yes or no, we
should allow the normal execution of the unrolling
- During the expand, I transform the pragma into a note that
will allow me to remove any unrolling at that point.
That is what I did and it seems to work quite well.
Of course, I have a few things I am currently considering:
- Is there really a position that is better for the pragma node in
the tree representation ?
- Can other passes actually move that node out of a given loop
before I register it in the loop ?
- Should I, instead of keeping that node through the tree
optimizations, actually remove it and later on add it just before
expansion ?
- Can an RTL pass remove notes or move them out of a loop ?
- Can the tree node or note change whether or not an optimization
takes place?
- It is important to note that after the registration, the pragma
node or note are actually just there to say "don't do anything",
therefore, the number of nodes or notes in the loop is not important
as long as they are not moved out.
Those are my current concerns :-), I can give more information if requested,
Jc
PS: What exactly was your solution to this issue?
On Thu, Oct 15, 2009 at 12:11 PM, Bingfeng Mei wrote:
> Jc,
> How did you implement #pragma unroll? I checked other compilers. The
> pragma should govern the next immediate loop. It took me a while to
> find a not-so-elegant way to do that. I also implemented #pragma ivdep.
> These information are supposed to be passed through both tree and RTL
> levels and suvive all GCC optimization. I still have problem in handling
> combination of unroll and ivdep.
>
> Bingfeng
>
>> -Original Message-
>> From: fearyours...@gmail.com [mailto:fearyours...@gmail.com]
>> On Behalf Of Jean Christophe Beyler
>> Sent: 15 October 2009 16:34
>> To: Zdenek Dvorak
>> Cc: Bingfeng Mei; gcc@gcc.gnu.org
>> Subject: Re: Turning off unrolling to certain loops
>>
>> You are entirely correct, I hadn't thought that through enough.
>>
>> So I backtracked and have just merged what Bingfeng Mei has done with
>> your code and have now a corrected version of the loop unrolling.
>>
>> What I did was directly modified tree_unroll_loop to handle the case
>> of a perfect unroll or not internally and then used something similar
>> to what you had done around that. I added what I think is needed to
>> stop unrolling of those loops in later passes.
>>
>> I'll be starting my tests but I can port it to 4.5 if you are
>> interested to see what I did.
>> Jc
>>
>> On Thu, Oct 15, 2009 at 6:00 AM, Zdenek Dvorak
>> wrote:
>> > Hi,
>> >
>> >> I faced a similar issue a while ago. I filed a bug report
>> >> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712) In the end,
>> >> I implemented a simple tree-level unrolling pass in our port
>> >> which uses all the existing infrastructure. It works quite well for
>> >> our purpose, but I hesitated to submit the patch because
>> it contains
>> >> our not-very-elegannt #prgama unroll implementation.
>> >
>> > could you please do so anyway? Even if there are some
>> issues with the
>> > #prgama unroll implementation, it could serve as a basis of a usable
>> > patch.
>> >
>> >> /* Perfect unrolling of a loop */
>> >> static void tree_unroll_perfect_loop (struct loop *loop,
>> unsigned factor,
>> >> edge exit)
>> >> {
>> >> ...
>> >> }
>> >>
>> >>
>> >>
>> >> /* Go through all the loops:
>> >> 1. Determine unrolling factor
>> >> 2. Unroll loops in different conditions
>> >> -- perfect loop: no extra copy of original loop
>> >> -- other loops: the original version of loops to
>> execute the remaining iterations
>> >> */
>> >> static unsigned int rest_of_tree_unroll (void)
>> >> {
>> > ...
>> >> tree niters = number_of_exit_cond_executions(loop);
>> >>
>> >> bool perfect_unrolling = false;
>> >> if(niters != NULL_TREE && niters!= chrec_dont_know
>> && TREE_CODE(niters) == INTEGER_CST){
>> >> int num_iters = tree_low_cst(niters, 1);
>> >> if((num_iters % unroll_factor) == 0)
>> >> perfect_unrolling = true;
>> >> }
>> >>
>> >> /* If no. of iterations can be divided by unrolling
>> factor, we have perfect unrolling */
>> >> if(perfect_unrolling){
>> >> tree_unroll_perfect_loop(loop, unroll_factor,
>> single_dom_exit(loop));
>> >> }
>> >> else{
>> >> tree_unroll_loop (loop, unroll_factor,
>> single_dom_exit (loop), &desc
Re: help: standard name of vector mode
彭建章 writes: > I'm porting gcc , and use its autovectorization. > How can I know wether a standard name support a vector mode ? The standard names all have modes built into them. If you are porting gcc, then you need to write a define_expand or define_insn in your MD file with a standard name which incorporates the vector mode that you are using. Using the standard name will enable the middle-end of gcc to know about your operation. There are many examples in the existing gcc backends. Ian
Re: GCC 4.4.2 Status Report (2009-10-15)
On Thu, Oct 15, 2009 at 11:43:11AM -0400, Ryan Mansfield wrote: > Jakub Jelinek wrote: >> GCC 4.4.2 release tarballs have been uploaded, the 4.4 branch is again >> open for commits under the usual release branch rules. >> >> I'll announce the release once mirrors had some time to download it. > > The onlinedocs already point to 4.4.2 but there is a permission issue > accessing onlinedocs/gcc-4.4.2/gcc/ (i.e. 403) Thanks for the report, apparently maintainer-scripts/update_web_docs_svn has some code like: today=`date +%d` if test $today = 15; then find $DOCSDIR -type f -maxdepth 1 -print | grep -v index.html | xargs rm for m in $MANUALS; do rm -f $DOCSDIR/$m/*.html $DOCSDIR/$m/*.html.gz done fi which failed (presumably because we want this to only happen for the trunk runs and only on the first run during that day; guess xargs rm should be xargs rm -f). Next time I'll try to avoid releasing on 15th... ;) http://gcc.gnu.org/onlinedocs/gcc-4.4.2/ should work now. Jakub
Re: Question on C++-0x constexpr
On Thu, Oct 15, 2009 at 11:24 AM, Ed Smith-Rowland <3dw...@verizon.net> wrote:
> I was toying around with constexpr in the standard library and tripped on
> this:
>
> // /bin/bin/g++ -std=c++0x -c template_constexpr.cpp
>
> template
> class A
> {
> static constexpr int foo() { return 666; }
> };
>
> template
> class B
> {
> static constexpr int foo() { return e.foo(); } // Should the compiler be
> able to noodle this out?
invalid.
> static constexpr int bar() { return E::foo(); } // Works fine.
> private:
> E e;
> };
>
> template_constexpr.cpp: In static member function 'static int B::foo()':
> template_constexpr.cpp:16:5: error: invalid use of member 'B::e' in
> static member function
> template_constexpr.cpp:13:39: error: from this location
>
>
> Question, if you can use a member access operator to access a static member,
> shouldn't constexpr work through that method too?
only after all other semantics restrictions are met,
BTW: current 'constexpr' is preliminary. There is more to come -- patch
under review.
>
> Thanks,
>
> Ed Smith-Rowland
>
>
Re: checking for debug a plugin on a production compiler?
> a plugin foo.c is compiled as foo.so for that gcc-4.5, but since the plugin
> is probably buggy, it is compiled with ENABLE_CHECKING.
How would you do this? :-)
The plugin should get the ENABLE_CHECKING definition from the
auto-host.h used by the compiler, so they should always agree.
>
> Regards.
>
> Note [*]: I don't pretend knowing when 4.5 will be released, and its release
> date is not the subject of that discussion!
>
> --
> 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} ***
>
Cheers,
--
Rafael Ávila de Espíndola
Re: Bus error gcc compiler for any for ( x in array ) inside Objective-C++ template
John Holdsworth writes:
> I've encountered a bus error using Apple's gcc in Xcode 3.1, 3.2
> compiling the following code or any containing for( x in y ) is used
> inside a template in Objective-C++.
>
> template
> class OODictionary {
> void boom() {
> NSArray *keys = nil;
> for ( NSString *key in keys ) {
> }
> }
> };
>
> I've not been able to build with a more recent gcc so I can't tell
> if it is still present but figure I'd better let you guys know.
I tried your test case with current mainline, and got a bunch of
errors.
/home/iant/foo.mm: In member function ‘void OODictionary::boom()’:
/home/iant/foo.mm:4:3: error: ‘NSArray’ was not declared in this scope
/home/iant/foo.mm:4:12: error: ‘keys’ was not declared in this scope
/home/iant/foo.mm:4:19: error: ‘nil’ was not declared in this scope
/home/iant/foo.mm:5:9: error: ‘NSString’ was not declared in this scope
/home/iant/foo.mm:5:19: error: ‘key’ was not declared in this scope
/home/iant/foo.mm:5:23: error: expected ‘;’ before ‘in’
/home/iant/foo.mm:7:2: error: expected primary-expression before ‘}’ token
/home/iant/foo.mm:7:2: error: expected ‘;’ before ‘}’ token
/home/iant/foo.mm:7:2: error: expected primary-expression before ‘}’ token
/home/iant/foo.mm:7:2: error: expected ‘)’ before ‘}’ token
/home/iant/foo.mm:7:2: error: expected primary-expression before ‘}’ token
/home/iant/foo.mm:7:2: error: expected ‘;’ before ‘}’ token
Since I don't know Objective C++ at all, I don't know whether this is
expected.
In any case, I encourage you to file a bug report with a
self-contained test case. Please follow the directions at
http://gcc.gnu.org/bugs.html . Thanks.
Ian
Re: help: standard name of vector mode
On Thu, 15 Oct 2009, Åí½¨Õ wrote: > I'm porting gcc , and use its autovectorization. > How can I know wether a standard name support a vector mode ? I might misunderstand your question, but the vector modes that are supported are enumerated by the port. See e.g. gcc/config/i386/i386-modes.def, the VECTOR_MODE lines. With that done, the machine description defines the standard-name-patterns for vector insns that apply to the port (which includes those modes as part of the names, as mentioned). brgds, H-P
Re: problems with gcc installation
On Thu, 2009-10-15 at 01:16 -0700, yzysea wrote: > I need to intall gcc-2.5.8 on opensolaris. In the "make" step, I get the > following message: This is the GCC development list, not a list for answering questions about how to compile up and use GCC. Please take your question to the gcc-h...@gcc.gnu.org list, which is the more appropriate list. Why on earth do you want to compile GCC 2.5.8? It was released over 15 years ago. Cheers, Ben
gcc-4.5-20091015 is now available
Snapshot gcc-4.5-20091015 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20091015/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 152876 You'll find: gcc-4.5-20091015.tar.bz2 Complete GCC (includes all of below) gcc-core-4.5-20091015.tar.bz2 C front end and core compiler gcc-ada-4.5-20091015.tar.bz2 Ada front end and runtime gcc-fortran-4.5-20091015.tar.bz2 Fortran front end and runtime gcc-g++-4.5-20091015.tar.bz2 C++ front end and runtime gcc-java-4.5-20091015.tar.bz2 Java front end and runtime gcc-objc-4.5-20091015.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.5-20091015.tar.bz2The GCC testsuite Diffs from 4.5-20091008 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
MicroBlaze update
I have checked in updates on the gcc microblaze branch to bring it up to gcc-4.3.4. There are the following tags: microblaze-4.1.2 -- gcc-4.1.2 with MicroBlaze support microblaze-4.2.4 -- gcc-4.2.4 with MicroBlaze support microblaze-4.3.4 -- gcc-4.3.4 with MicroBlaze support -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
