Re: gcc 3.3.6 and multilib
The problem was not in the patch, which I've applied. Patch is good. The problem was in t-mips config file. Now I have a gcc 3.3.6 compiler working with multilib correctly. Thanks
Difference between vec_shl_ and ashl3
Hello,
Could anyone explain to me what is difference between vec_shl_ and
ashl3 patterns? It seems to me that both shift a vector operand 1
with scalar operand 2. I tried to understand some targets' implemenation,
e.g., ia64 as follows, and cannot grasp their difference. Does the "whole
vector shift" of vec_shl means treating a vector as a long scalar? Thanks in
advance.
(define_insn "lshr3"
[(set (match_operand:VECINT24 0 "gr_register_operand" "=r")
(lshiftrt:VECINT24
(match_operand:VECINT24 1 "gr_register_operand" "r")
(match_operand:DI 2 "gr_reg_or_5bit_operand" "rn")))]
""
"pshr.u %0 = %1, %2"
[(set_attr "itanium_class" "mmshf")])
(define_expand "vec_shr_"
[(set (match_operand:VECINT 0 "gr_register_operand" "")
(lshiftrt:DI (match_operand:VECINT 1 "gr_register_operand" "")
(match_operand:DI 2 "gr_reg_or_6bit_operand" "")))]
""
{
operands[0] = gen_lowpart (DImode, operands[0]);
operands[1] = gen_lowpart (DImode, operands[1]);
})
Cheers,
Bingfeng Mei
Broadcom UK
Re: Difference between vec_shl_ and ashl3
"Bingfeng Mei" writes: > Could anyone explain to me what is difference between > vec_shl_ and ashl3 patterns? It seems to me > that both shift a vector operand 1 with scalar operand 2. The difference is that with a vector mode gcc will look for the standard name vec_shl_MODE, and with a non-vector mode gcc will look for the standard name lshlMODE or ashlMODE. > I tried to understand some targets' implemenation, e.g., ia64 as > follows, and cannot grasp their difference. The name which matters is vec_shr_. The fact that the ia64 names the real insn mode3 does not imply that that insn name is actually used by anything. vec_shr_ is a define_expand which is expands into a pattern which is recognized by the mode3 insn. The name of the mode3 insn could change or be removed and everything would work. Ian
RE: Difference between vec_shl_ and ashl3
Ian, Thanks for prompt reply. Just out of curiosity. Isn't this naming convention for shift instructions inconsistent with other patterns? For example, we can define add3 and GCC will automatically use it by vectorization or in plus expression of two vector types. Why does shift need special names? Bingfeng > -Original Message- > From: Ian Lance Taylor [mailto:i...@google.com] > Sent: 10 February 2009 14:31 > To: Bingfeng Mei > Cc: gcc@gcc.gnu.org > Subject: Re: Difference between vec_shl_ and > ashl3 > > "Bingfeng Mei" writes: > > > Could anyone explain to me what is difference between > > vec_shl_ and ashl3 patterns? It > seems to me > > that both shift a vector operand 1 with scalar operand 2. > > The difference is that with a vector mode gcc will look for > the standard > name vec_shl_MODE, and with a non-vector mode gcc will look for the > standard name lshlMODE or ashlMODE. > > > I tried to understand some targets' implemenation, e.g., ia64 as > > follows, and cannot grasp their difference. > > The name which matters is vec_shr_. The fact that the > ia64 names > the real insn mode3 does not imply that that insn name > is actually > used by anything. vec_shr_ is a define_expand which is expands > into a pattern which is recognized by the mode3 insn. > The name of > the mode3 insn could change or be removed and everything would > work. > > Ian > >
Re: GCC 4.4.0 Status Report (2009-02-09)
On Mon, Feb 9, 2009 at 1:57 PM, Joseph S. Myers wrote: > Status > == > > Trunk remains in Stage 4 (regression and documentation fixes mode). > > GCC 4.4 will be branched when there are no open P1 regressions for 4.4 > and the runtime library sources have been converted to GPLv3 with the > new licensing exception; the number of P1, P2 and P3 regressions has > been below 100 for some time. Gcc doesn't follow x86-64 psABI: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39082 I'd like to see it fixed in 4.4. -- H.J.
Re: Difference between vec_shl_ and ashl3
"Bingfeng Mei" writes: > Thanks for prompt reply. Just out of curiosity. Isn't this naming > convention for shift instructions inconsistent with other patterns? > For example, we can define add3 and GCC will > automatically use it by vectorization or in plus expression of two > vector types. Why does shift need special names? It is inconsistent. I think it sort of accidentally fell out of using different tree codes for vector shift operations and normal shift operations. That difference exists so that the vectorizer can easily use vector shift instructions when reducing to a result, although I suspect that that difference could probably be eliminated as well. Ian
Re: Difference between vec_shl_ and ashl3
Bingfeng Mei wrote: > Hello, > Could anyone explain to me what is difference between > vec_shl_ and ashl3 patterns? It seems to me > that both shift a vector operand 1 with scalar operand 2. I tried to > understand some targets' implemenation, e.g., ia64 as follows, and > cannot grasp their difference. Does the "whole vector shift" of > vec_shl means treating a vector as a long scalar? Thanks in advance. vec_shl_ is indeed treating a vector as a long scalar, while lshr3 is for SIMD shifts. Only for shifts, the second argument can be an integer mode specifying that the shift count has to be the same for all SIMD elements. Notice that in the vec_shr_ you pasted, the shift is carried out in DImode > [(set (match_operand:VECINT 0 "gr_register_operand" "") > (lshiftrt:DI (match_operand:VECINT 1 "gr_register_operand" "") > (match_operand:DI 2 "gr_reg_or_6bit_operand" "")))] > "" while in the lshr3 it is carried out in the vector mode: > [(set (match_operand:VECINT24 0 "gr_register_operand" "=r") > (lshiftrt:VECINT24 > (match_operand:VECINT24 1 "gr_register_operand" "r") > (match_operand:DI 2 "gr_reg_or_5bit_operand" "rn")))] Paolo
possible buffer overflow in calls.c?
hello! as this is my first time adding some noise to this list, let me briefly introduce myself: Jaka; member of a team porting gcc to the NEC SX architecture ( http://code.google.com/p/sx-gcc/ ). really close now to a working C compiler, only a few testcases still failing. however, I have a problem with the ported SX gcc on a 64-bit host (x86_64); it crashes due to memory corruption in glibc ( http://code.google.com/p/sx-gcc/issues/detail?id=107 ). now, imho, the crash can be attributed to a buffer overflow that occurs constantly, but only manifests itself in a crash when the circumstances are just right, in calls.c:emit_library_call_value_1(). let me explain ... in emit_library_call_value_1(), local var stack_usage_map_buf is allocated with stack_usage_map_buf = XNEWVEC (char, highest_outgoing_arg_in_use); stack_usage_map = stack_usage_map_buf; allocating a buffer with 1 char for each byte of stack required for outgoing args. then in a loop iterating over args, upper and lower bounds for indexing a part of that buffer are calculated with: #ifdef ARGS_GROW_DOWNWARD /* stack_slot is negative, but we want to index stack_usage_map with positive values. */ upper_bound = -argvec[argnum].locate.offset.constant + 1; lower_bound = upper_bound - argvec[argnum].locate.size.constant; #else lower_bound = argvec[argnum].locate.offset.constant; upper_bound = lower_bound + argvec[argnum].locate.size.constant; #endif the problem with this code is that argvec[argnum].locate.offset is the offset to the actual arg on the stack *excluding* any padding, while argvec[argnum].locate.size contains the size *including* any possible padding (according to comments on struct locate_and_pad_arg_data in expr.h). therefore, upper_bound for the last arg can be up to a stack slot size too large than the space allocated for stack_usage_map. thus a later loop, marking the stack space if (ACCUMULATE_OUTGOING_ARGS) for (i = lower_bound; i < upper_bound; i++) stack_usage_map[i] = 1; writes past the end of the buffer. observing this writes with a few printouts confirms that this happens regularly, on 32- and 64-bit hosts, but most of the time does not cause problems (the testcase I mention is the only one that crashes the compiler, and even that one only on 64-bit hosts, while printouts clearly show that writes past buffer end occur regularly when calling emit_library_call_value_1()). now, the above bounds calculation should imho use slot_offset instead of offset, which would account for the padding: #ifdef ARGS_GROW_DOWNWARD /* stack_slot is negative, but we want to index stack_usage_map with positive values. */ upper_bound = -argvec[argnum].locate.slot_offset.constant + 1; lower_bound = upper_bound - argvec[argnum].locate.size.constant; #else lower_bound = argvec[argnum].locate.slot_offset.constant; upper_bound = lower_bound + argvec[argnum].locate.size.constant; #endif so, the above explanation seems ok and the proposed fix seems ok for our port. however, I'm a bit puzzled at how this could have gone unnoticed, and not causing any major problems at all for so long. I am also a bit reluctant to claim that gcc has had this bug in its sources for ... well ... years ... now, could someone in the know comment on this, and either give me a positive nod stating that this is indeed a bug that needs fixing, or tell me that I don't really have a clue and explain what is wrong with my above reasoning and what could it be that I am doing wrong ... btw, base for our port are gcc 4.2.2 sources, however 4.2.4, 4.3.3 and current trunk sources contain exactly the same code that is described above. thanks in advance & best regards, jaKa -- email: j...@xlab.si w3:http://www.gmajna.net/svojat/jaka/
Re: Constant folding and Constant propagation
I am looking at a related problem in GCSE, GCC 4.3 whereby constants are propagated to their use irrespective of the final instruction cost of generating them (machine cycles or instruction count). Global constant propagation effectively voids common expressions that form large constants, identified by global CSE. This is especially true of SYMBOl_REF constants like section-anchors generated while indexing global arrays. For the GCC port I work on, I have fixed this by weighing the rtx_cost of propagating a register copy Vs propagating the constant into an insn. I have an initial patch for this problem. Rahul Vijay Kharche
Removal of -I- and the functionality of -iquote.
In a recent upgrade, we noticed that -I- functionality is being replaced with -iquote. This -iquote does not have the same functionality as -I- and is removing a strong function that is needed. -I- provides the ability to have include files (.h) reference files in the same directory and yet use the Makefile path structure to actually find the .h file. This means that when doing a Master/Dev area development structure that a programmer can take the secondary include file into the Dev area and not have to worry about the initial header file not finding the file. Example: Consider a large Include file directory that has the following files: toplevel.h secondary.h toplevel.h has a include "secondary.h" line in it to make toplevel always compile. Programmer X then needs to make changes to secondary.h. Copies the file to his/her development area and then changes the file. The Makefiles properly search the Development area Include directories before it searches the Master area Include directories. Without -I- toplevel.h will always find the secondary.h file in MASTER even though the Makefile explicitly told the compiler to search for the secondary.h in the Development area. The new functionality of -iquote does not provide the same functionality or ease of use. Please consider either expanding -iquote to include the search include system of -I- or keep -I- around. Chris Litchfield
Re: Removal of -I- and the functionality of -iquote.
>In a recent upgrade, we noticed that -I- functionality is being >replaced with -iquote. This -iquote does not have the same >functionality as -I- and is removing a strong function that is needed. I wasn't around for the decision to remove the "don't search the directory containing the current file" feature, but I can tell you that it is impossible to use this feature safely on many current operating systems, because the system header files expect that the directory containing the current file *will* be searched. I even see instances of this expectation in gcc itself (specifically, libstdc++) -- $ echo '#include ' | gcc -E -I- -x c++ - > /dev/null In file included from /usr/include/c++/4.3/tr1/cmath:63, from :1: /usr/include/c++/4.3/tr1/gamma.tcc:55:35: error: special_function_util.h: No such file or directory zw
Re: possible buffer overflow in calls.c?
Jaka Močnik writes: > in emit_library_call_value_1(), local var stack_usage_map_buf is > allocated with > > stack_usage_map_buf = XNEWVEC (char, highest_outgoing_arg_in_use); > stack_usage_map = stack_usage_map_buf; > > allocating a buffer with 1 char for each byte of stack required for > outgoing args. > > then in a loop iterating over args, upper and lower bounds for indexing > a part of that buffer are calculated with: > > #ifdef ARGS_GROW_DOWNWARD > /* stack_slot is negative, but we want to index stack_usage_map >with positive values. */ > upper_bound = -argvec[argnum].locate.offset.constant + 1; > lower_bound = upper_bound - argvec[argnum].locate.size.constant; > #else > lower_bound = argvec[argnum].locate.offset.constant; > upper_bound = lower_bound + argvec[argnum].locate.size.constant; > #endif > > the problem with this code is that argvec[argnum].locate.offset is the > offset to the actual arg on the stack *excluding* any padding, while > argvec[argnum].locate.size contains the size *including* any possible > padding (according to comments on struct locate_and_pad_arg_data in > expr.h). therefore, upper_bound for the last arg can be up to a stack > slot size too large than the space allocated for stack_usage_map. I don't quite see it. highest_outgoing_args_in_use is at least as large as args_size.constant, and that counts the locate.size for each argument. So it should always include the extra padding. That said, it would not be shocking if there were a bug in this code. It's not particularly common to use emit_library_call_value_1 with code that passes parameters on the stack. And it's even less common to use it with parameters that require padding when they are pushed on the stack. So a miscalculation in such a scenario could survive for quite along time. Ian
