Re: Merging Apple's Objective-C 2.0 compiler changes
On Tue, Sep 14, 2010 at 17:55, Chris Lattner wrote: > > On Sep 14, 2010, at 7:22 AM, David Edelsohn wrote: > >> On Mon, Sep 13, 2010 at 6:33 PM, Ian Lance Taylor wrote: >>> From the perspective of gcc, I think the goal of clang->gcc would be to >>> replace the current frontends entirely. >> >> Yes, I think it would be interesting to consider how Clang could >> evolve into a portable C/C++(/ObjC/ObjC++) front-end that could be >> used by LLVM and GCC (and other FOSS compilers) -- an alternative to >> the EDG front-end. > > For what it is worth, this is something that the clang folk would certainly > like to see happen. Clang is also already factored such that you don't need > to pull in LLVM IR (and thus the llvm backend and code generator) if you > don't want to. Just convert from clang ASTs to generic or gimple. Doesn't clang depend on LLVM libraries like LLVMSystem and LLVMSupport?
Re: plugin hooks for plugin-provided builtins?
On 09/15/2010 08:54 AM, Arnaud Charlet wrote: Given the current limitations of Gimple, another area to focus on could be task parallelism (rather than data parallelism). In that case a language like [Google] Go (via GCC) might make a better talking point than C or Fortran. An even better starting point would be Ada which has built-in multi-tasking constructs. Arno Hi everybody, At the last GROW workshop in Pisa, I presented Gomet, an extension to GCC which (among other things) performs GIMPLE-to-C translation for parallelization purpose. http://ctuning.org/dissemination/grow10-02.pdf The paper is out of date now with respect to the progress made in Gomet this year, but you may find some information in there anyway. It is definitely possible to achieve such translation, and the information available in the middle-end are sufficient. If the input source code is C, then the biggest required transformation is to adapt the SSA form and lower PHI nodes. Additional glitches (coming from floating point types, array and type sizes in pointer arithmetics, includes) can be overcome. If the input source code is not C, additional work is required to map specific language constructs to C. In Gomet, a subset of Fortran and C++ is supported for free. I did not try Ada, Go or other input languages. Regards, N. BENOIT
Re: plugin hooks for plugin-provided builtins?
On Tue, 14 Sep 2010, Steven Bosscher wrote: > On Tue, Sep 14, 2010 at 5:39 PM, Marcus Daniels wrote: > > On 9/14/10 8:46 AM, Basile Starynkevitch wrote: > >> > >> My current work aims to translate some Gimple into OpenCL source > >> code, thus providing GCC with the ability to take advantage of GPU > >> running their proprietary OpenCL compilers without asking the user to > >> learn OpenCL. > > > > My understanding is that Gimple does not have the notion of data parallel > > operations. > > There was a prototype patch with "middle-end arrays" from Richard > Guenther (see http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01123.html > for the latest revision I'm aware of). > > I suppose the usual things (other priorities, funding) stand in the > way of completing this work. Richi probably can tell more. The most important thing that made me stop working on this (besides priorities, funding, time, etc.) is that for good test coverage the Fortran frontend would need to start using this representation. Which I didn't get around to even try to implement myself. But this is indeed something I like to come back to at some point ... Richard.
Support for range-based "for" in g++?
Hi all, the page at http://gcc.gnu.org/projects/cxx0x.html suggests that g++ 4.6 supports range-based "for" (http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2930.html); however it appears that the construct is actually not recognized in 4.6, and I could find no support for it in gcc/cp/parser.c no cp-tree.def. Could it be that the support was removed when the Concepts branch was forked? (range-based for was based on concepts previously) Otherwise I would suggest that the C++0x support status page is updated accordingly. Best regards, -- rkp
Re: Support for range-based "for" in g++?
On 09/15/2010 11:32 AM, g...@raphael.poss.name wrote: > Hi all, > > the page at http://gcc.gnu.org/projects/cxx0x.html suggests that g++ 4.6 > supports range-based "for" > (http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2930.html); > however it appears that the construct is actually not recognized in 4.6, > and I could find no support for it in gcc/cp/parser.c no cp-tree.def. > Evidently you don't have a current tree. This is the top of the current cp/ChangeLog 2010-09-13 Rodrigo Rivas Costa * semantics.c (finish_for_stmt): Always test flag_new_for_scope. (begin_range_for_stmt): Likewise. 2010-09-11 Rodrigo Rivas Implement range-based for-statements. * cp-tree.def (RANGE_FOR_STMT): New. * cp-tree.h (RANGE_FOR_DECL, RANGE_FOR_EXPR, RANGE_FOR_BODY): New. (cp_convert_range_for): Declare. * pt.c (tsubst_expr): Add RANGE_FOR_STMT. (tsubst_copy_and_build): perform_koenig_lookup takes extra argument. * semantics.c (begin_range_for_stmt): New. (finish_range_for_decl): New. (finish_for_stmt): Accept also RANGE_FOR_STMT. (perform_koenig_lookup): Add extra argument include_std. * parser.c (cp_parser_c_for): New with code from cp_parser_iteration_statement(). (cp_parser_range_for): New. (cp_convert_range_for): New. (cp_parser_iteration_statement): Add range-for support. (cp_parser_condition): Adjust comment. (cp_parser_postfix_expression): perform_koenig_lookup takes extra argument. * dump.c (cp_dump_tree): Add RANGE_FOR_STMT. * cxx-pretty-print.c: Likewise. * lex.c (cxx_init): Likewise. * name-lookup.c (lookup_function_nonclass): Add extra argument include_std. (lookup_arg_dependent): Likewise. * name-lookup.h: Likewise.
Question about alias check in ddg.c
Hello,
When trying to compile the following loop with GCC -r164298 with modulo
scheduling pass enabled on PowerPC I get that the inter loop edges
between the memory instructions are created in the DDG although the
following check in ddg.c exists:
static void
add_inter_loop_mem_dep (ddg_ptr g, ddg_node_ptr from, ddg_node_ptr to)
{
if (!insns_may_alias_p (from->insn, to->insn))
return;
With GCC -r146278 the edges are not created in the DDG.
Looking more closely into the code I see the following differences in ddg.c
between the GCC versions:
The new version of GCC contains:
add_inter_loop_mem_dep () -> ...-> may_alias_p()
while with GCC -r146278:
add_inter_loop_mem_dep () -> ... -> insn_alias_sets_conflict_p()
I do not understand this behavior and I appreciate an explanation.
Thanks,
Revital
void foo( int * __restrict__ dst, int * __restrict__ src1,
int * __restrict__ src2)
{
int x, y;
for( x = 0; x < 100; x+=1 )
{
dst[x] = ( src1[x] * src2[x] ) ;
}
}
RE: Question about alias check in ddg.c
The old insns_may_alias_p is based checking alias set number. But since
4.5, the new alias oracle doesn't rely the alias set number. may_alias_p()
is a new function based on alias oracle. Essentially, it is same as
true_dependence function but excluding offset and TBAA based disambiguation,
which is not valid for cross-iteration memory dependence analysis.
Cheers,
Bingfeng
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Revital1 Eres
> Sent: 15 September 2010 13:28
> To: gcc@gcc.gnu.org
> Subject: Question about alias check in ddg.c
>
>
> Hello,
>
> When trying to compile the following loop with GCC -r164298 with modulo
> scheduling pass enabled on PowerPC I get that the inter loop edges
> between the memory instructions are created in the DDG although the
> following check in ddg.c exists:
>
> static void
> add_inter_loop_mem_dep (ddg_ptr g, ddg_node_ptr from, ddg_node_ptr to)
> {
> if (!insns_may_alias_p (from->insn, to->insn))
> return;
>
> With GCC -r146278 the edges are not created in the DDG.
> Looking more closely into the code I see the following differences in
> ddg.c
> between the GCC versions:
>
> The new version of GCC contains:
>
> add_inter_loop_mem_dep () -> ...-> may_alias_p()
>
> while with GCC -r146278:
>
> add_inter_loop_mem_dep () -> ... -> insn_alias_sets_conflict_p()
>
> I do not understand this behavior and I appreciate an explanation.
>
> Thanks,
> Revital
>
>
> void foo( int * __restrict__ dst, int * __restrict__ src1,
> int * __restrict__ src2)
> {
> int x, y;
>
>for( x = 0; x < 100; x+=1 )
> {
> dst[x] = ( src1[x] * src2[x] ) ;
> }
> }
>
question about lshiftrt:DI when there are no 64bits in the processor
Hi all,
I am porting gcc to a microprocessor. There are no 64bits instructions
in it. I added a small logical shift right optimization to the md
file(see below).
For the statement “k>>32” in which k is 64bits integer, the
“define_expand” should fail because op2 is 32, not 1.
However, I can see the lshiftrt:DI is still generated in rtl dumps
even if I commented out the “define_expand”. If both “define_expand”
and “define_isns” are commented out, the result is correct.
.md file:
;; Special case for long x>>1, which can be expanded
;; using the carry bit shift-in instructions. x<<1 is already
;; expanded by the compiler into x+x, so no rules for long leftshift
;; necessary.
;;
(define_expand "lshrdi3"
[(set (match_operand:DI 0 "register_operand" )
(lshiftrt:DI (match_operand:DI 1 "register_operand")
(match_operand:QI 2 "immediate_operand")))]
""
{
if ( GET_CODE(operands[2]) != CONST_INT ) { FAIL; }
if ( INTVAL(operands[2])!= 1 ) { FAIL; }
})
(define_insn "*lshrdi3S1"
[(set (match_operand:DI 0 "register_operand" "=r")
(lshiftrt:DI (match_operand:DI 1 "register_operand" "r")
(match_operand:QI 2 "immediate_operand""i")))]
""
"lsr.w %H0 %H1 1;\;lsrc.w %M0 %M1 1;"
[(set_attr "cc" "clobber")])
I can find out that the the insn is generated in
pass_jump2(gcc/4.3.2/gcc/cfgcleanup.c).
in p_b.c.137r.into_cfglayout:
;; Start of basic block ( 6) -> 5
;; Pred edge 6 [97.1%]
(code_label 69 44 47 5 57 "" [1 uses])
(note 47 69 50 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(insn 50 47 48 5 p_b.c:491 (clobber (reg:DI 42 [ D.1783 ])) -1
(insn_list:REG_LIBCALL 51 (nil)))
(insn 48 50 49 5 p_b.c:491 (set (subreg:SI (reg:DI 42 [ D.1783 ]) 0)
(lshiftrt:SI (subreg:SI (reg/v:DI 35 [ k ]) 4)
(const_int 0 [0x0]))) 54 {lshrsi3}
(expr_list:REG_NO_CONFLICT (reg/v:DI 35 [ k ])
(nil)))
(insn 49 48 51 5 p_b.c:491 (set (subreg:SI (reg:DI 42 [ D.1783 ]) 4)
(const_int 0 [0x0])) 3 {*mov_mode_insn}
(expr_list:REG_NO_CONFLICT (reg/v:DI 35 [ k ])
(nil)))
(insn 51 49 52 5 p_b.c:491 (set (reg:DI 42 [ D.1783 ])
(reg:DI 42 [ D.1783 ])) 2 {movdi} (insn_list:REG_RETVAL 50
(expr_list:REG_EQUAL (lshiftrt:DI (reg/v:DI 35 [ k ])
(const_int 32 [0x20]))
(nil
but in p_b.c.138r.jump, insns between 47 and 51 are removed and insn51
is changed.
;; Start of basic block ( 5) -> 4
;; Pred edge 5 [97.1%]
(code_label 69 44 47 4 57 "" [1 uses])
(note 47 69 51 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn 51 47 52 4 p_b.c:491 (set (reg:DI 42 [ D.1783 ])
(lshiftrt:DI (reg/v:DI 35 [ k ])
(const_int 32 [0x20]))) 58 {*lshrdi3S1} (nil))
I am wondering what’s the usage of REG_EQUAL? ( I have read gcc
internal, but still don’t quite understand).
Why the instructions (47-51) are replaced by lshiftrt:DI when there is
no lshrdi3 insn defined in md file?
Thanks.
--
-Qifei Fan
RE: Question about alias check in ddg.c
It doesn't fail on my target, which is based on 4.5 and
has backported this patch. I will have a look at PowerPC.
Bingfeng
> -Original Message-
> From: Revital1 Eres [mailto:e...@il.ibm.com]
> Sent: 15 September 2010 13:51
> To: Bingfeng Mei
> Subject: RE: Question about alias check in ddg.c
>
> Hi,
>
> Thanks for the answer. But this means that this is a regression
> compared to
> previous version, right? Do you know if there is an intention to fix it?
>
> Thanks,
> Revital
>
>
>
> From: "Bingfeng Mei"
> To: Revital1 Eres/Haifa/i...@ibmil, "gcc@gcc.gnu.org"
>
> Date: 15/09/2010 02:39 PM
> Subject: RE: Question about alias check in ddg.c
> Sent by: gcc-ow...@gcc.gnu.org
>
>
>
> The old insns_may_alias_p is based checking alias set number. But since
> 4.5, the new alias oracle doesn't rely the alias set number.
> may_alias_p()
> is a new function based on alias oracle. Essentially, it is same as
> true_dependence function but excluding offset and TBAA based
> disambiguation,
> which is not valid for cross-iteration memory dependence analysis.
>
> Cheers,
> Bingfeng
>
> > -Original Message-
> > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf
> Of
> > Revital1 Eres
> > Sent: 15 September 2010 13:28
> > To: gcc@gcc.gnu.org
> > Subject: Question about alias check in ddg.c
> >
> >
> > Hello,
> >
> > When trying to compile the following loop with GCC -r164298 with
> modulo
> > scheduling pass enabled on PowerPC I get that the inter loop edges
> > between the memory instructions are created in the DDG although the
> > following check in ddg.c exists:
> >
> > static void
> > add_inter_loop_mem_dep (ddg_ptr g, ddg_node_ptr from, ddg_node_ptr to)
> > {
> > if (!insns_may_alias_p (from->insn, to->insn))
> > return;
> >
> > With GCC -r146278 the edges are not created in the DDG.
> > Looking more closely into the code I see the following differences in
> > ddg.c
> > between the GCC versions:
> >
> > The new version of GCC contains:
> >
> > add_inter_loop_mem_dep () -> ...-> may_alias_p()
> >
> > while with GCC -r146278:
> >
> > add_inter_loop_mem_dep () -> ... -> insn_alias_sets_conflict_p()
> >
> > I do not understand this behavior and I appreciate an explanation.
> >
> > Thanks,
> > Revital
> >
> >
> > void foo( int * __restrict__ dst, int * __restrict__ src1,
> > int * __restrict__ src2)
> > {
> > int x, y;
> >
> >for( x = 0; x < 100; x+=1 )
> > {
> > dst[x] = ( src1[x] * src2[x] ) ;
> > }
> > }
> >
>
>
>
>
Re: Updating frequencies and dominators
Jan Hubicka writes: > > TODO_rebuild_frequencies only propagate probabilities into frequencies, so > when you don't > have probabilities set, it won't help you. > If you just create such a simple conrolled functions, I guess it is best to > just > assign frequencies and probabilities by hand. > > Honza Thanks, now I got it. That's why it was actually not working very well :) -- PMatos
PHI nodes undefined
Hello, With my current pass moving things around and creating new BBs in some test cases, I find that I get the error: , | fnmatch.i: In function 'fnmatch': | fnmatch.i:3: error: missing PHI def | p_27 = PHI <(20)> ` Is there a way I can rebuild PHI nodes info or what's the best way to keep track of this each time I change the CFG by adding/removing edges and adding new basic blocks? Cheers, -- PMatos
Re: question about lshiftrt:DI when there are no 64bits in the processor
fanqifei writes:
> I am porting gcc to a microprocessor. There are no 64bits instructions
> in it. I added a small logical shift right optimization to the md
> file(see below).
> For the statement “k>>32” in which k is 64bits integer, the
> “define_expand” should fail because op2 is 32, not 1.
> However, I can see the lshiftrt:DI is still generated in rtl dumps
> even if I commented out the “define_expand”. If both “define_expand”
> and “define_isns” are commented out, the result is correct.
> (insn 51 47 52 4 p_b.c:491 (set (reg:DI 42 [ D.1783 ])
> (lshiftrt:DI (reg/v:DI 35 [ k ])
> (const_int 32 [0x20]))) 58 {*lshrdi3S1} (nil))
This means that your lshrdi3S1 insn accepted the shift. You need to
reject invalid operands in the instruction predicate. Otherwise gcc can
generate them via pattern generation. gcc does not exclusively go
through define_expand.
> I am wondering what’s the usage of REG_EQUAL? ( I have read gcc
> internal, but still don’t quite understand).
REG_EQUAL is used for optimizations. When a sequence of insns generates
a result which can be expressed as a simple expression, REG_EQUAL holds
that expression. If gcc later sees that the result is used in a simple
way, it can sometimes use the REG_EQUAL note to simplify the result.
> Why the instructions (47-51) are replaced by lshiftrt:DI when there is
> no lshrdi3 insn defined in md file?
There is an lshrdi3S1 insn which matches a generated pattern.
Ian
Re: PHI nodes undefined
pocma...@gmail.com (Paulo J. Matos) writes: > Is there a way I can rebuild PHI nodes info or what's the best way to > keep track of this each time I change the CFG by adding/removing edges > and adding new basic blocks? I found out I can avoid the whole issue by scheduling my pass to go just before pass_build_ssa, where phi nodes seem to be created. But it would still be nice to know the answer to the above. -- PMatos
Re: question about lshiftrt:DI when there are no 64bits in the processor
fanqifei schrieb:
> Hi all,
>
> I am porting gcc to a microprocessor. There are no 64bits instructions
> in it. I added a small logical shift right optimization to the md
> file(see below).
> For the statement “k>>32” in which k is 64bits integer, the
> “define_expand” should fail because op2 is 32, not 1.
> However, I can see the lshiftrt:DI is still generated in rtl dumps
> even if I commented out the “define_expand”. If both “define_expand”
> and “define_isns” are commented out, the result is correct.
>
> .md file:
>
> ;; Special case for long x>>1, which can be expanded
> ;; using the carry bit shift-in instructions. x<<1 is already
> ;; expanded by the compiler into x+x, so no rules for long leftshift
> ;; necessary.
> ;;
>
> (define_expand "lshrdi3"
> [(set (match_operand:DI 0 "register_operand" )
> (lshiftrt:DI (match_operand:DI 1 "register_operand")
> (match_operand:QI 2 "immediate_operand")))]
> ""
> {
> if ( GET_CODE(operands[2]) != CONST_INT ) { FAIL; }
> if ( INTVAL(operands[2])!= 1 ) { FAIL; }
> })
>
> (define_insn "*lshrdi3S1"
> [(set (match_operand:DI 0 "register_operand" "=r")
> (lshiftrt:DI (match_operand:DI 1 "register_operand" "r")
> (match_operand:QI 2 "immediate_operand""i")))]
> ""
> "lsr.w %H0 %H1 1;\;lsrc.w %M0 %M1 1;"
> [(set_attr "cc" "clobber")])
[...]
> Why the instructions (47-51) are replaced by lshiftrt:DI when there is
> no lshrdi3 insn defined in md file?
You actually /have/ defined an insn that allows lshiftrt:DI patterns for any
constant (even constants that are not known at compile time), namely your
"*lshrdi3S1" insn. Note that many passes construct new RTL out of RTL already
generated and try to match these constructs against some insns, most notably
pass insn-combine, insn splitters. If there is no match nothing happens. If
there is a match (and costs are lower etc.) the old pattern gets replaced by the
new one. In your case that means that you have to disallow anything that has op2
not equal to 1. So you couls rewrite the insn in question to
(define_insn "*lshrdi3S1"
[(set (match_operand:DI 0 "register_operand" "=r")
(lshiftrt:DI (match_operand:DI 1 "register_operand" "r")
(const_int 1)))]
""
...)
or
(define_insn "*lshrdi3S1"
[(set (match_operand:DI 0 "register_operand" "=r")
(lshiftrt:DI (match_operand:DI 1 "register_operand" "r")
(match_operand:QI 2 "const_int_operand""n")))]
"operands[2] == const1_rtx"
...)
or any formulation you prefer.
Re: PHI nodes undefined
On Wed, Sep 15, 2010 at 3:23 PM, Paulo J. Matos wrote: > pocma...@gmail.com (Paulo J. Matos) writes: > >> Is there a way I can rebuild PHI nodes info or what's the best way to >> keep track of this each time I change the CFG by adding/removing edges >> and adding new basic blocks? > > I found out I can avoid the whole issue by scheduling my pass to go just > before pass_build_ssa, where phi nodes seem to be created. > > But it would still be nice to know the answer to the above. You need to manually maintain SSA form. You are probably loosing the original PHI node after the switch when you delete edges. Richard.
[C++0x] Working on user-defined literals.
Greetings, I'm working on user-defined literals for C++-0x. I've gotten to the point where I can declare non-template operator"" and call the resulting function explicitly. I'm working on getting suffixed integers and floats out of the preprocessor to be parsed. Before I continue I was wondering if anyone else is working on this. If I need to continue (check cwg_active.html#1108) I'll probably be asking for help. Thanks, Ed Smith-Rowland
Re: Merging Apple's Objective-C 2.0 compiler changes
On Sep 15, 2010, at 12:23 AM, Kevin André wrote: > On Tue, Sep 14, 2010 at 17:55, Chris Lattner wrote: >> >> On Sep 14, 2010, at 7:22 AM, David Edelsohn wrote: >> >>> On Mon, Sep 13, 2010 at 6:33 PM, Ian Lance Taylor wrote: From the perspective of gcc, I think the goal of clang->gcc would be to replace the current frontends entirely. >>> >>> Yes, I think it would be interesting to consider how Clang could >>> evolve into a portable C/C++(/ObjC/ObjC++) front-end that could be >>> used by LLVM and GCC (and other FOSS compilers) -- an alternative to >>> the EDG front-end. >> >> For what it is worth, this is something that the clang folk would certainly >> like to see happen. Clang is also already factored such that you don't need >> to pull in LLVM IR (and thus the llvm backend and code generator) if you >> don't want to. Just convert from clang ASTs to generic or gimple. > > Doesn't clang depend on LLVM libraries like LLVMSystem and LLVMSupport? Yes, but those are very small libraries that don't pull in the llvm backend, code generator or llvm IR either. -Chris
Re: question about lshiftrt:DI when there are no 64bits in the processor
Thank you, Georg and Ian.
I misunderstood the section16.2 of gcc internal manual and thought
that the nameless insn (with * ) in .md file can be only used during
rtl-->asm.
The generated code is correct now.
Thanks again!
--
-Qifei Fan
On Wed, Sep 15, 2010 at 9:27 PM, Georg Lay wrote:
> fanqifei schrieb:
>> Hi all,
>>
>> I am porting gcc to a microprocessor. There are no 64bits instructions
>> in it. I added a small logical shift right optimization to the md
>> file(see below).
>> For the statement “k>>32” in which k is 64bits integer, the
>> “define_expand” should fail because op2 is 32, not 1.
>> However, I can see the lshiftrt:DI is still generated in rtl dumps
>> even if I commented out the “define_expand”. If both “define_expand”
>> and “define_isns” are commented out, the result is correct.
>>
>> .md file:
>>
>> ;; Special case for long x>>1, which can be expanded
>> ;; using the carry bit shift-in instructions. x<<1 is already
>> ;; expanded by the compiler into x+x, so no rules for long leftshift
>> ;; necessary.
>> ;;
>>
>> (define_expand "lshrdi3"
>> [(set (match_operand:DI 0 "register_operand" )
>> (lshiftrt:DI (match_operand:DI 1 "register_operand")
>> (match_operand:QI 2 "immediate_operand")))]
>> ""
>> {
>> if ( GET_CODE(operands[2]) != CONST_INT ) { FAIL; }
>> if ( INTVAL(operands[2]) != 1 ) { FAIL; }
>> })
>>
>> (define_insn "*lshrdi3S1"
>> [(set (match_operand:DI 0 "register_operand" "=r")
>> (lshiftrt:DI (match_operand:DI 1 "register_operand" "r")
>> (match_operand:QI 2 "immediate_operand" "i")))]
>> ""
>> "lsr.w %H0 %H1 1;\;lsrc.w %M0 %M1 1;"
>> [(set_attr "cc" "clobber")])
> [...]
>> Why the instructions (47-51) are replaced by lshiftrt:DI when there is
>> no lshrdi3 insn defined in md file?
>
> You actually /have/ defined an insn that allows lshiftrt:DI patterns for any
> constant (even constants that are not known at compile time), namely your
> "*lshrdi3S1" insn. Note that many passes construct new RTL out of RTL already
> generated and try to match these constructs against some insns, most notably
> pass insn-combine, insn splitters. If there is no match nothing happens. If
> there is a match (and costs are lower etc.) the old pattern gets replaced by
> the
> new one. In your case that means that you have to disallow anything that has
> op2
> not equal to 1. So you couls rewrite the insn in question to
>
> (define_insn "*lshrdi3S1"
> [(set (match_operand:DI 0 "register_operand" "=r")
> (lshiftrt:DI (match_operand:DI 1 "register_operand" "r")
> (const_int 1)))]
> ""
> ...)
>
> or
>
> (define_insn "*lshrdi3S1"
> [(set (match_operand:DI 0 "register_operand" "=r")
> (lshiftrt:DI (match_operand:DI 1 "register_operand" "r")
> (match_operand:QI 2 "const_int_operand" "n")))]
> "operands[2] == const1_rtx"
> ...)
>
> or any formulation you prefer.
>
Bugzilla outage Friday, September 17, 18:00GMT-21:00GMT
Thanks to sterling work by Frédéric Buclin, the gcc.gnu.org overseers group is preparing to upgrade gcc.gnu.org bugzilla to a current version. We will be taking bugzilla offline on Friday, September 17, for three hours starting at 18:00GMT, 11:00PDT to do a final database upgrade and conversion to the new system. Please let us know if this is an intolerable inconvenience. A demonstration version of the new system may be found at http://gcc.gnu.org/bugzilla-test/ . Ian
Re: Merging Apple's Objective-C 2.0 compiler changes
[ about modifying the license of "GPLv2 or later" or similarly licensed code ] * Ralf Wildenhues wrote on Sun, Sep 12, 2010 at 08:15:57AM CEST: > * Richard Kenner wrote on Sun, Sep 12, 2010 at 12:17:47AM CEST: > > > > It's my understanding that FSF legal department has consistently refused > > > > to answer such questions as this. > > > > > > Do you have a quote for that, please? > > > > How do you quote somebody who DOESN'T answer? FYI, quoting Brett Smith on this issue (with permission) below. Cheers, Ralf When the copyright holder of a program gives you permission to "redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 2 of the License, or (at your option) any later version," they have given you permission to distribute it under the terms of any one or more of the licenses specified. Distributing the work under GPLv2-or-later, GPLv3-or-later, GPLv2-only, GPLv3-only, and so on are all permitted. It works the same way as disjunctive dual licenses: just like you have the option of distributing Perl under the terms of the Artistic License, the GPL, or both, you can do similarly here. If the license grant did not work this way, it would be unable to accomplish its intended goal of easing license compatibility issues when new versions of the GPL are released. With that said: I don't advise taking a GPLv2-or-later program and distributing it under GPLv3-or-later just because you can. That may upset some upstreams, and in general I don't like to see licensing become a point of contention between development teams like this. If you make this change, please do it for a specific reason. There are plenty of good ones (e.g., you've made changes that you want to clearly be under GPLv3, you want future contributors to provide a patent license under section 11, etc.), but developers should ideally have a solid sense of which of them are relevant for their project. Also note that just because you receive a work under GPLv2-or-later and distribute it under GPLv3-or-later doesn't necessarily mean that the previous distributor has new obligations. For example, if you get some GPLv2-or-later source from a distributor that has a tivoized product, you can't distribute that source under GPLv3-or-later and then turn around and ask the previous distributor for Installation Information. They're only on the hook to meet the conditions in one of the licenses they chose, which in this case would be GPLv2.
Re: Merging Apple's Objective-C 2.0 compiler changes
> FYI, quoting Brett Smith on this issue (with permission) below. > > When the copyright holder of a program gives you permission to > "redistribute it and/or modify it under the terms of the GNU General > Public License as published by the Free Software Foundation, either > version 2 of the License, or (at your option) any later version," they > have given you permission to distribute it under the terms of any one or > more of the licenses specified. I don't mean to keep this thread alive longer, but that answer is not to the question we've been discussing. OF COURSE you can "redistribute" a GPLv2-or-later file under GPLv3-or-later. That's never been the question! The question is whether you can RELICENSE a GPLv2-or-later file to be GPLv3-or-later without needing explicit permission of the copyright holder. To understand the difference, note that: > Also note that just because you receive a work under GPLv2-or-later and > distribute it under GPLv3-or-later doesn't necessarily mean that the > previous distributor has new obligations. For example, if you get some > GPLv2-or-later source from a distributor that has a tivoized product, > you can't distribute that source under GPLv3-or-later and then turn > around and ask the previous distributor for Installation Information. > They're only on the hook to meet the conditions in one of the licenses > they chose, which in this case would be GPLv2.
Re: Merging Apple's Objective-C 2.0 compiler changes
On 9/15/2010 4:59 PM, Richard Kenner wrote: I don't mean to keep this thread alive longer, but that answer is not to the question we've been discussing. OF COURSE you can "redistribute" a GPLv2-or-later file under GPLv3-or-later. That's never been the question! The question is whether you can RELICENSE a GPLv2-or-later file to be GPLv3-or-later without needing explicit permission of the copyright holder. To understand the difference, note that: I do not understand the difference between "redistributing a file under a GPLv3-or-later license", and distributing it under a license that is GPLv3-or-later". Note that you can't necessarily even redistribute under GPL v3 if the work does not meet the criteria for such a distribution, e.g. it is Tivoized. Also note that just because you receive a work under GPLv2-or-later and distribute it under GPLv3-or-later doesn't necessarily mean that the previous distributor has new obligations. For example, if you get some GPLv2-or-later source from a distributor that has a tivoized product, you can't distribute that source under GPLv3-or-later and then turn around and ask the previous distributor for Installation Information. They're only on the hook to meet the conditions in one of the licenses they chose, which in this case would be GPLv2. Well of course not, when A distributes B to C under license D, it is A who acquires the responsibility and obligations that acrue because of the distribution.
Re: Merging Apple's Objective-C 2.0 compiler changes
> I do not understand the difference between "redistributing a file > under a GPLv3-or-later license", and distributing it under a license > that is GPLv3-or-later". I'm not sure what the two things you list are, but the two that we're talking about are: (1) Distributing a GPLv2-or-later file as part of a GPV3-only or GPLV3-or-later package. Everybody agrees that you can do that. But when you do, the recipient of the file can choose to further redistribute it under GPLv2 if they want. (2) Changing the text at the front of the file to say "GPLv3-or-later" when it currently says "GPLv2-or-later". FSF *policy* (not the GPL) requires that all files have "GPLv3-or-later" license. The question is what permission you need to change a file that has a "GPLv2-or-later" license into the required one.
Re: Bugzilla outage Friday, September 17, 18:00GMT-21:00GMT
On 09/15/2010 01:44 PM, Ian Lance Taylor wrote: Thanks to sterling work by Frédéric Buclin, the gcc.gnu.org overseers group is preparing to upgrade gcc.gnu.org bugzilla to a current version. We will be taking bugzilla offline on Friday, September 17, for three hours starting at 18:00GMT, 11:00PDT to do a final database upgrade and conversion to the new system. Please let us know if this is an intolerable inconvenience. A demonstration version of the new system may be found at http://gcc.gnu.org/bugzilla-test/ . Ian A quick question: What will happen to svn commits tagged with bug numbers during this outage? Will bugzilla eventually end up with the commit comments we have all come to know and love? David Daney
Re: Bugzilla outage Friday, September 17, 18:00GMT-21:00GMT
David Daney writes: > A quick question: What will happen to svn commits tagged with bug > numbers during this outage? Will bugzilla eventually end up with the > commit comments we have all come to know and love? That is the plan, yes. Ian
Re: Dejagnu testcase behavior unexpected
Thanks for the reply.
I made the changes that you described, but I'm still experiencing the
same behavior--namely that I think that I should see two unexpected
errors since 1) the test case will not compile and 2) the expected
error message is not printed.
Here are the steps to reproduce (assuming that a stage1 compiler has
already been built and that version 4.6.0 20100831 (experimental) of
the GCC is being used):
1) create the file pr99.C at /gcc/testsuite/g++.dg/template.
2) paste the following code in pr99.C:
/*{dg-do compile}*/
template class X {};
template int f(X, X);
template int f(X, X);
int main(void) {
return f(X(), X());/*{ dg-error "int f(X, X)"} */
}
3) from the directory, run the following command:
make -C gcc check-g++ RUNTESTFLAGS=dg.exp=pr99.C
_
What I actually see in the results is:
Running /home/david/gcc/gcc/testsuite/g++.dg/dg.exp ...
FAIL: g++.dg/template/pr99.C (test for excess errors)
=== g++ Summary ===
# of unexpected failures1 //<--SHOULDN'T THIS BE 2 INSTEAD OF 1?
/home/david/gccbuild/gcc/testsuite/g++/../../g++ version 4.6.0
20100831 (experimental) (GCC)
On Tue, Sep 14, 2010 at 5:18 PM, Ian Lance Taylor wrote:
> David Weiser writes:
>
>> I am looking at bug number 99 on
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=99 and I am adding a test
>> case for it.
>> The testcase looks like this:
>> //---start test case
>> /*
>> {do-run compile}
>> */
>
> This should be
>
> /* { dg-do compile } */
>
> or, equivalently for C++,
>
> // { dg-do compile }
>
> Ian
>
--
Thanks,
dw
Re: Merging Apple's Objective-C 2.0 compiler changes
On Sep 15, 2010, at 2:17 PM, Richard Kenner wrote: > FSF *policy* (not the GPL) requires that all files have "GPLv3-or-later" > license. The question is what permission you need to change a file > that has a "GPLv2-or-later" license into the required one. None, the GPL v2 clause grants this right, if it says GPL v2 or later.
array of pointer to function support in GNU C
i've been writing bits of codes where it requires to have an array or
"pointers to functions", so the decision of which function to execute is
indexed... (i know, a lot of you will say "well, that's a VERY specific of a
solution, there's always the problem of binary compatibility when passing
arguments for different argument-taking functions, blah, blah, blah... just
rely on good old fashioned function calls with conditional statements..."
but, pls, forget about that sort of incompatibility...)
even if i hadn't tried it in C++, i know it should work as i've seen some
examples posted on the net. but i'm trying to write my code in GNU C, so it
could be compiled by GCC -- god knows i would never try to compile it in GNU
C++; that gargantuan thing
but whatever i do it i just can't get it to work
code:
some_header.h:
static void *(*oper_table)(void **);
main.c:
int main(void)
{
oper_table[0]; /* just a test. data is not used or modified*/
return 1;
}
error: subscripted value is pointer to function
whereas:
int main(void)
{
void *(*func)(void **);
func;
return 1;
}
compiles just fine
i do realize that i'm depending on dialect-specific features, so i don't
even know if this is supported on my gcc as of version 4.3.3. if it's not a
dialect problem, then this stumps me even more.
--
View this message in context:
http://old.nabble.com/array-of-pointer-to-function-support-in-GNU-C-tp29725303p29725303.html
Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: array of pointer to function support in GNU C
This list is really for the development of GCC, not for getting help in C. That said ... On Sep 15, 2010, at 11:15 PM, ir_idjit wrote: > but whatever i do it i just can't get it to work > code: > > some_header.h: > static void *(*oper_table)(void **); That's a pointer to a function taking a pointer to pointer to void and returning a pointer to void. If you want a pointer to pointer to function (which you need in order to point at an array of function pointers) you should declare it like this: static void *(**oper_table)(void **); Of course, that's still stupid. The correct way to declare it is this: typedef void *(*operation)(void **); static operation *oper_table; Sebastian
