Re: why GCC does implicit promotion to unsigned char?
On Thu, Jan 26, 2012 at 4:58 PM, David Brown wrote:
> On 26/01/2012 12:53, Konstantin Vladimirov wrote:
>>
>> Hi,
>>
>> If I know what I am doing, and my code itself guarantees, that there
>> will be no overflows and UB here, can I switch off this signed char to
>> unsigned char expansion in favor of signed char to signed int
>> expansion?
>>
>
> The big question here is why you are using an unqualified "char" for
> arithmetic in the first place. The signedness of plain "char" varies by
> target (some default to signed, some to unsigned) and by compiler flags. If
> you want to write code that uses signed chars, use "signed char". Or even
> better, use type "int8_t".
>
> However, as has been pointed out, the problem is that signed arithmetic
> doesn't wrap - it must be turned into unsigned arithmetic to make it safe.
> An alternative is to tell gcc that signed arithmetic is 2's compliment and
> wraps, by using the "-fwrapv" flag or "int8_t char sum_A_B(void)
> __attribute__((optimize("wrapv")));" on the specific function.
Note that semantic changing optimize attributes do not work reliably.
Richard.
> mvh.,
>
> David
>
>
>
>> ---
>> With best regards, Konstantin
>>
>> On Thu, Jan 26, 2012 at 3:04 PM, Jakub Jelinek wrote:
>>>
>>> On Thu, Jan 26, 2012 at 02:27:45PM +0400, Konstantin Vladimirov wrote:
Consider code:
char A;
char B;
char sum_A_B ( void )
{
char sum = A + B;
return sum;
}
[repro.c : 6:8] A.0 = A;
[repro.c : 6:8] A.1 = (unsigned char) A.0;
[repro.c : 6:8] B.2 = B;
[repro.c : 6:8] B.3 = (unsigned char) B.2;
[repro.c : 6:8] D.1990 = A.1 + B.3;
[repro.c : 6:8] sum = (char) D.1990;
[repro.c : 8:3] D.1991 = sum;
[repro.c : 8:3] return D.1991;
}
It looks really weird. Why gcc promotes char to unsigned char
internally?
>>>
>>>
>>> To avoid triggering undefined behavior.
>>> A + B in C for char A and B is (int) A + (int) B, so either we'd have to
>>> promote it to int and then demote, or we just cast it to unsigned and do
>>> the
>>> addition in 8-bit. If we don't do that, e.g. for
>>> A = 127 and B = 127 we'd trigger undefined behavior of signed addition.
>>> In unsigned char 127 + 127 is valid.
>>>
>>> Jakub
>>
>>
>
Re: why GCC does implicit promotion to unsigned char?
On 27/01/2012 10:02, Richard Guenther wrote:
On Thu, Jan 26, 2012 at 4:58 PM, David Brown wrote:
On 26/01/2012 12:53, Konstantin Vladimirov wrote:
Hi,
If I know what I am doing, and my code itself guarantees, that there
will be no overflows and UB here, can I switch off this signed char to
unsigned char expansion in favor of signed char to signed int
expansion?
The big question here is why you are using an unqualified "char" for
arithmetic in the first place. The signedness of plain "char" varies by
target (some default to signed, some to unsigned) and by compiler flags. If
you want to write code that uses signed chars, use "signed char". Or even
better, use type "int8_t".
However, as has been pointed out, the problem is that signed arithmetic
doesn't wrap - it must be turned into unsigned arithmetic to make it safe.
An alternative is to tell gcc that signed arithmetic is 2's compliment and
wraps, by using the "-fwrapv" flag or "int8_t char sum_A_B(void)
__attribute__((optimize("wrapv")));" on the specific function.
Note that semantic changing optimize attributes do not work reliably.
Richard.
Is there any more information about that somewhere? Certainly I expect
there to be issues when trying to turn on and off options like
"-fshort-enums" or "-freg-struct-return" - just as you can expect
problems linking modules that have been compiled with different flags
like that. But others like "-fwrapv", "-fargument-alias", or
"-finstrument-functions" can logically be applied to a single function.
If there are problems with changing these (with attributes or
pragmas), then perhaps they should be disabled, or the potential
problems documented in the manual?
mvh.,
David
Re: why GCC does implicit promotion to unsigned char?
On Fri, Jan 27, 2012 at 10:40 AM, David Brown wrote:
> On 27/01/2012 10:02, Richard Guenther wrote:
>>
>> On Thu, Jan 26, 2012 at 4:58 PM, David Brown
>> wrote:
>>>
>>> On 26/01/2012 12:53, Konstantin Vladimirov wrote:
Hi,
If I know what I am doing, and my code itself guarantees, that there
will be no overflows and UB here, can I switch off this signed char to
unsigned char expansion in favor of signed char to signed int
expansion?
>>>
>>> The big question here is why you are using an unqualified "char" for
>>> arithmetic in the first place. The signedness of plain "char" varies by
>>> target (some default to signed, some to unsigned) and by compiler flags.
>>> If
>>> you want to write code that uses signed chars, use "signed char". Or even
>>> better, use type "int8_t".
>>>
>>> However, as has been pointed out, the problem is that signed arithmetic
>>> doesn't wrap - it must be turned into unsigned arithmetic to make it
>>> safe.
>>> An alternative is to tell gcc that signed arithmetic is 2's compliment
>>> and
>>> wraps, by using the "-fwrapv" flag or "int8_t char sum_A_B(void)
>>> __attribute__((optimize("wrapv")));" on the specific function.
>>
>>
>> Note that semantic changing optimize attributes do not work reliably.
>>
>> Richard.
>>
>
> Is there any more information about that somewhere? Certainly I expect
> there to be issues when trying to turn on and off options like
> "-fshort-enums" or "-freg-struct-return" - just as you can expect problems
> linking modules that have been compiled with different flags like that. But
> others like "-fwrapv", "-fargument-alias", or "-finstrument-functions" can
> logically be applied to a single function. If there are problems with
> changing these (with attributes or pragmas), then perhaps they should be
> disabled, or the potential problems documented in the manual?
Well, the implementation is simply a bit naiive in accepting all options
and not all code is prepared to handle functions which differ in optimization
options. For example inlining happily will inline a -fwrapv function into
a -fno-wrapv function and later assume the inlined copy does have -fno-wrapv
semantics. The safe implementation here would have been to disallow
any inlining between functions that have any optimize attribute/pragma,
but that of course would defeat most of its use.
That said, using the attribute for debugging might be of help, but I would
not rely on it in any way.
Richard.
> mvh.,
>
> David
>
>
RE: ICE building compiler
Hi, Whilst investigating an ICE with the Blackfin compiler, I bumped in to a bit of code which seems questionable: in reload1.c:reload() we call select_reload_regs() and then check if failure was set. However, looking at find_reload_regs() (called via select_reload_regs()), the only time we set failure is immediately after a call to spill_failure() which doesn't return. Is spill_failure the correct function to be using here? It seems like the intention of the code was to note the spill_failure and then try and then try and fix it by jumping to the "failed:" label. Cheers, Stu
Re: why GCC does implicit promotion to unsigned char?
On 27/01/2012 10:56, Richard Guenther wrote:
On Fri, Jan 27, 2012 at 10:40 AM, David Brown wrote:
On 27/01/2012 10:02, Richard Guenther wrote:
On Thu, Jan 26, 2012 at 4:58 PM, David Brown
wrote:
On 26/01/2012 12:53, Konstantin Vladimirov wrote:
Hi,
If I know what I am doing, and my code itself guarantees, that there
will be no overflows and UB here, can I switch off this signed char to
unsigned char expansion in favor of signed char to signed int
expansion?
The big question here is why you are using an unqualified "char" for
arithmetic in the first place. The signedness of plain "char" varies by
target (some default to signed, some to unsigned) and by compiler flags.
If
you want to write code that uses signed chars, use "signed char". Or even
better, usetype "int8_t".
However, as has been pointed out, the problem is that signed arithmetic
doesn't wrap - it must be turned into unsigned arithmetic to make it
safe.
An alternative is to tell gcc that signed arithmetic is 2's compliment
and
wraps, by using the "-fwrapv" flag or "int8_t char sum_A_B(void)
__attribute__((optimize("wrapv")));" on the specific function.
Note that semantic changing optimize attributes do not work reliably.
Richard.
Is there any more information about that somewhere? Certainly I expect
there to be issues when trying to turn on and off options like
"-fshort-enums" or "-freg-struct-return" - just as you can expect problems
linking modules that have been compiled with different flags like that. But
others like "-fwrapv", "-fargument-alias", or "-finstrument-functions" can
logically be applied to a single function. If there are problems with
changing these (with attributes or pragmas), then perhaps they should be
disabled, or the potential problems documented in the manual?
Well, the implementation is simply a bit naiive in accepting all options
and not all code is prepared to handle functions which differ in optimization
options. For example inlining happily will inline a -fwrapv function into
a -fno-wrapv function and later assume the inlined copy does have -fno-wrapv
semantics. The safe implementation here would have been to disallow
any inlining between functions that have any optimize attribute/pragma,
but that of course would defeat most of its use.
That said, using the attribute for debugging might be of help, but I would
not rely on it in any way.
Richard.
That makes a lot of sense - thanks for the explanation. I had naively
been thinking that it should be safe to change "-fwrapv" for a function
- but inlining parts of other functions with different "-fwrapv"
settings would make things a lot more complicated.
Using a pragma to set -fwrapv at the start of a C file (before any
#include's that contained inline functions) would presumably be safe,
acting just the command line switch.
On the other hand, LTO might cause trouble there too...
For my own use, I would always put a flag like that in the makefile, and
almost always apply it globally to all files in the program - but not
everyone works like that, and it's nice to know the possibilities and
limitations.
GCC 4.7.0 Status Report (2012-01-27)
Status == GCC is now in stage4, only regression and documentation fixes are being accepted. The trunk will remain in this state until it is sufficiently stable for release. Then we will create the 4.7 branch and do a first release candidate. The overall status looks nice, please keep up the good work on bugfixing, especially for P1 bugs where we have still a few of them, and keep testing the compiler and reporting any bugs. Quality Data Priority # Change from Last Report --- --- P15 - 8 P2 64 - 20 P3 11 - 5 --- --- Total80 - 33 Previous Report === http://gcc.gnu.org/ml/gcc/2012-01/msg00071.html The next report will be sent by Joseph.
ANNOUNCE: MELT plugin 0.9.3 release for GCC 4.6 (& probably 4.7)
Hello All,
It is my pleasure to announce the release of MELT plugin 0.9.3 for GCC 4.6 (&
4.7 when available)
Please download the gzipped tar archive from
http://gcc-melt.org/melt-0.9.3-plugin-for-gcc-4.6.tgz
(file of 4233531 bytes and md5sum 8df30ba643b11a78a607cde67cdcb073)
[w.r.t. previous release cancidates, I corrected some bugs]
###
NEWS for 0.9.3 MELT plugin for gcc-4.6 (and future gcc-4.7)
January 27th, 2012
New features:
Language improvements
=
Ability to define a named value with the (DEFINE ) construct
More support notably for Gimple & Tree
==
Added more cmatchers etc.
Runtime improvement
===
Generation of timestamping C file foo+melttime.h included from
generated descriptor file foo+meltdesc.c from foo.melt
Numerous bug fixes
##
Bugs reports are welcome.
Regards.
--
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} ***
Recovering REG_EXPR information after temporary expression replacement
A member of our team was working on some switch statement optimizations,
and ran into a situation that seems a little curious on the face of it.
Consider these two test variants:
int
test_switch_1 (unsigned int *index, int i)
{
switch (*index)
{
case 0:
return i;
case 1:
return i+1;
case 2:
return i+2;
default:
return i+3;
}
}
int
test_switch_2 (unsigned int *index, int i)
{
switch (*index)
{
case 0:
return i;
case 1:
return i+1;
case 2:
return i+2;
default:
return *index+3;
}
}
For the second case we see the following from expand. The key point is
that reg:SI 120 has a REG_EXPR of D.2004, which allows getting type
information from the original decl of D.2004:
;; D.2004_3 = *index_2(D);
(insn 7 6 0 (set (reg:SI 120 [ D.2004 ])
(mem:SI (reg/v/f:SI 123 [ index ]) [2 *index_2(D)+0 S4 A32]))
t2.i:4 -1
(nil))
;; switch (D.2004_3) , case 0: , case 1: , case 2:
>
(insn 8 7 9 (set (reg:CCUNS 125)
(compare:CCUNS (reg:SI 120 [ D.2004 ])
(const_int 1 [0x1]))) t2.i:4 -1
(nil))
However, for the first case, temporary expression replacement has
effectively removed the assignment to D.2004_3 (single local immediate
use permits replacement), so instead we see:
;; switch (D.2004_3) , case 0: , case 1: , case 2:
>
(insn 7 6 8 (set (reg:SI 124)
(mem:SI (reg/v/f:SI 122 [ index ]) [2 *index_2(D)+0 S4 A32]))
t1.i:4 -1
(nil))
(insn 8 7 9 (set (reg:CC 125)
(compare:CC (reg:SI 124)
(const_int 1 [0x1]))) t1.i:4 -1
(nil))
The REG_EXPR is missing for reg:SI 124, so the type information for
D.2004 can't be recovered.
I am not very familiar with all the ins and outs of expand, so it's not
clear to me whether this is necessary. It seems to me that it would be
theoretically possible to attach the REG_EXPR data here when doing the
TER lookup while expanding the switch, but perhaps there are reasons why
that's difficult.
It would be a nice enhancement if the REG_EXPR could be preserved in
such cases. Does anyone know if there's something that would prevent
this?
Thanks!
Bill
Construction Management Question
Hi Webmaster, I created my own Construction Management education site called http://www.constructionmanagementdegree.com, a personal project that I've finally gotten to a stage that is "presentable". I would like to submit my website for your review and inclusion in the resource section of your site: http://gcc.gnu.org/projects/cli.html I created http://www.constructionmanagementdegree.com as a resource for new college students to find in-depth and unbiased information about picking the right Construction Management degree to fit their needs. I spent a good amount of time researching each school and providing information to find the best program to fit their needs. I'm hoping that after you take a look, you'll think its a valuable enough resource to include a link to my site in your list of resources. I'd appreciate the opportunity to answer any questions, or take any other steps in order to get my site's link listed. Thank you for taking a look! Chuck Lorrell
Divide_1 testsuite fail due to a problem in the unwinding code
Hi,
while debugging the java failure Divide_1 on s390 I stumbled over
some weird behaviour in the unwinding code.
In the testcase a divide by zero is triggered intentionally. So that
the java sigfpe handler is invoked in __divdi3:
Divide_1::probe_1() -> __divdi3
|SIGFPE
V
catch_fpe -> _Jv_Throw
After doing the instruction parsing in order to figure out whether
it's actually the INT_MIN/-1 case or not an exception is thrown.
During _Unwind_RaiseException the handler is found in probe_1 and in
order to re-find it in phase2 the CFA! is recorded in the private_2 field
of the exception.
Starting with this IRA patch:
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00028.html
__divdi3 does *not* need a stack frame at all.
So the CFAs of __divdi3 and probe_1 are the same!
This triggers the assertion in _Unwind_RaiseException_Phase2 which
assumes that it is about to pass the frame with the handler without
actually finding one.
The CFA does not appear sufficient to identify the unwinding state. It
has been changed from using the IP with this patch:
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01252.html
Ulrich pointed out that also using the IP isn't a good choice since it
will fail in other circumstances (e.g. with recursive calls). GDB
seems to use a combination of both (+a target specific value on some
architectures). We probably have to do similiar things here to fix this?!
Perhaps it would also be possible to just count the number of stack
frames in phase1 in order to use that information in phase2?! However,
I'm not sure whether invoking the destructors in phase2 could mess up
that information.
To my understanding this can only happen if there is control flow from
a leaf function which in turn should only occur with signals. Perhaps
we could modify the CFA "a bit" for the frame where the signal
occurred? There is already a hack in uw_identify_context which does
this for the signal frame:
static inline _Unwind_Ptr
uw_identify_context (struct _Unwind_Context *context)
{
/* The CFA is not sufficient to disambiguate the context of a function
interrupted by a signal before establishing its frame and the context
of the signal itself. */
if (STACK_GROWS_DOWNWARD)
return _Unwind_GetCFA (context) - _Unwind_IsSignalFrame (context);
else
return _Unwind_GetCFA (context) + _Unwind_IsSignalFrame (context);
}
Any ideas?
Bye,
-Andreas-
Re: Divide_1 testsuite fail due to a problem in the unwinding code
On 27/01/2012 16:46, Andreas Krebbel wrote: > Divide_1::probe_1() -> __divdi3 >|SIGFPE >V > catch_fpe -> _Jv_Throw > > After doing the instruction parsing in order to figure out whether > it's actually the INT_MIN/-1 case or not an exception is thrown. > > During _Unwind_RaiseException the handler is found in probe_1 and in > order to re-find it in phase2 the CFA! is recorded in the private_2 field > of the exception. > > Starting with this IRA patch: > http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00028.html > __divdi3 does *not* need a stack frame at all. > > So the CFAs of __divdi3 and probe_1 are the same! > > This triggers the assertion in _Unwind_RaiseException_Phase2 which > assumes that it is about to pass the frame with the handler without > actually finding one. Wouldn't it work to just let the unwind loop continue running if the next frame's CFA is the same as the current one's? cheers, DaveK
Re: Divide_1 testsuite fail due to a problem in the unwinding code
On 01/27/2012 04:46 PM, Andreas Krebbel wrote: > while debugging the java failure Divide_1 on s390 I stumbled over > some weird behaviour in the unwinding code. > > In the testcase a divide by zero is triggered intentionally. So that > the java sigfpe handler is invoked in __divdi3: > > Divide_1::probe_1() -> __divdi3 >|SIGFPE >V > catch_fpe -> _Jv_Throw > > After doing the instruction parsing in order to figure out whether > it's actually the INT_MIN/-1 case or not an exception is thrown. > > During _Unwind_RaiseException the handler is found in probe_1 and in > order to re-find it in phase2 the CFA! is recorded in the private_2 field > of the exception. > > Starting with this IRA patch: > http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00028.html > __divdi3 does *not* need a stack frame at all. > > So the CFAs of __divdi3 and probe_1 are the same! I'm confused. But __divdi3 should have been compiled with enough unwinder data that it can be found; it should not matter whether __divdi3 has a stack frame or not. So why doesn't __divdi3 have a CFA of its own? Andrew.
Re: Divide_1 testsuite fail due to a problem in the unwinding code
On 27/01/2012 16:58, Dave Korn wrote: > On 27/01/2012 16:46, Andreas Krebbel wrote: >> So the CFAs of __divdi3 and probe_1 are the same! >> >> This triggers the assertion in _Unwind_RaiseException_Phase2 which >> assumes that it is about to pass the frame with the handler without >> actually finding one. > > Wouldn't it work to just let the unwind loop continue running if the next > frame's CFA is the same as the current one's? (Answering myself) No, it won't be enough; it would solve that particular inlining case but not if there was a stack of recursive calls through one or more intermediate functions. I think adopting the GDB convention of IP+CFA to identify the context is probably necessary after all. cheers, DaveK
Re: Divide_1 testsuite fail due to a problem in the unwinding code
> To my understanding this can only happen if there is control flow from
> a leaf function which in turn should only occur with signals. Perhaps
> we could modify the CFA "a bit" for the frame where the signal
> occurred? There is already a hack in uw_identify_context which does
> this for the signal frame:
>
> static inline _Unwind_Ptr
> uw_identify_context (struct _Unwind_Context *context)
> {
> /* The CFA is not sufficient to disambiguate the context of a function
> interrupted by a signal before establishing its frame and the context
> of the signal itself. */
> if (STACK_GROWS_DOWNWARD)
> return _Unwind_GetCFA (context) - _Unwind_IsSignalFrame (context);
> else
> return _Unwind_GetCFA (context) + _Unwind_IsSignalFrame (context);
> }
Why does this "hack" not work? It was precisely devised for this purpose.
--
Eric Botcazou
Re: Divide_1 testsuite fail due to a problem in the unwinding code
On 27/01/2012 17:01, Andrew Haley wrote: > On 01/27/2012 04:46 PM, Andreas Krebbel wrote: >> Starting with this IRA patch: >> http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00028.html >> __divdi3 does *not* need a stack frame at all. >> >> So the CFAs of __divdi3 and probe_1 are the same! > > I'm confused. > > But __divdi3 should have been compiled with enough unwinder data > that it can be found; it should not matter whether __divdi3 has > a stack frame or not. > > So why doesn't __divdi3 have a CFA of its own? Unless I've misunderstood, it's because the CFA *is* the stack frame (base?) pointer. cheers, DaveK
Re: Divide_1 testsuite fail due to a problem in the unwinding code
On 01/27/2012 05:14 PM, Dave Korn wrote: > On 27/01/2012 17:01, Andrew Haley wrote: >> On 01/27/2012 04:46 PM, Andreas Krebbel wrote: > >>> Starting with this IRA patch: >>> http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00028.html >>> __divdi3 does *not* need a stack frame at all. >>> >>> So the CFAs of __divdi3 and probe_1 are the same! >> >> I'm confused. >> >> But __divdi3 should have been compiled with enough unwinder data >> that it can be found; it should not matter whether __divdi3 has >> a stack frame or not. >> >> So why doesn't __divdi3 have a CFA of its own? > > Unless I've misunderstood, it's because the CFA *is* the stack frame (base?) > pointer. Ah, it's not that it has no stack frame, it's that it has no stack adjustment at all, not even a push? Andrew.
Re: Divide_1 testsuite fail due to a problem in the unwinding code
On 27/01/2012 17:16, Andrew Haley wrote: > On 01/27/2012 05:14 PM, Dave Korn wrote: >> On 27/01/2012 17:01, Andrew Haley wrote: >>> On 01/27/2012 04:46 PM, Andreas Krebbel wrote: Starting with this IRA patch: http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00028.html __divdi3 does *not* need a stack frame at all. So the CFAs of __divdi3 and probe_1 are the same! >>> I'm confused. >>> >>> But __divdi3 should have been compiled with enough unwinder data >>> that it can be found; it should not matter whether __divdi3 has >>> a stack frame or not. >>> >>> So why doesn't __divdi3 have a CFA of its own? >> Unless I've misunderstood, it's because the CFA *is* the stack frame >> (base?) >> pointer. > > Ah, it's not that it has no stack frame, it's that it has no > stack adjustment at all, not even a push? Well the return address might get pushed but if the CFA is the stack frame base rather than current stack pointer, that won't change. So I expect this could happen with inline and nested functions too. (Or do nested functions set up a stack frame? I don't know.) cheers, DaveK
Re: Recovering REG_EXPR information after temporary expression replacement
Hi,
On Fri, 27 Jan 2012, William J. Schmidt wrote:
>
> int
> test_switch_1 (unsigned int *index, int i)
> {
> switch (*index)
...
> However, for the first case, temporary expression replacement has
> effectively removed the assignment to D.2004_3 (single local immediate
> use permits replacement), so instead we see:
>
>
> ;; switch (D.2004_3) , case 0: , case 1: , case 2:
> >
>
> (insn 7 6 8 (set (reg:SI 124)
> (mem:SI (reg/v/f:SI 122 [ index ]) [2 *index_2(D)+0 S4 A32]))
> t1.i:4 -1
With TER there is no decl anymore to associate the pseudo with.
Conceptually, what's expanded is "*index", not an assignment to a pseudo.
The move into a pseudo (and the creation of that very pseudo) is done by
copy_to_reg in expand_case.
> It would be a nice enhancement if the REG_EXPR could be preserved in
> such cases. Does anyone know if there's something that would prevent
> this?
The hack below works in this specific situation (TERed into a switch), and
adds a REG_EXPR when an TERed SSA name ever expanded into a pseudo (i.e.
also for some more generic situations).
Ciao,
Michael.
Index: expr.c
===
--- expr.c (revision 183559)
+++ expr.c (working copy)
@@ -8991,8 +8991,13 @@ expand_expr_real_1 (tree exp, rtx target
&& stmt_is_replaceable_p (SSA_NAME_DEF_STMT (exp)))
g = SSA_NAME_DEF_STMT (exp);
if (g)
- return expand_expr_real (gimple_assign_rhs_to_tree (g), target, tmode,
-modifier, NULL);
+ {
+ rtx r = expand_expr_real (gimple_assign_rhs_to_tree (g), target,
+ tmode, modifier, NULL);
+ if (REG_P (r) && !REG_EXPR (r))
+ set_reg_attrs_for_decl_rtl (SSA_NAME_VAR (exp), r);
+ return r;
+ }
ssa_name = exp;
decl_rtl = get_rtx_for_ssa_name (ssa_name);
Index: stmt.c
===
--- stmt.c (revision 183559)
+++ stmt.c (working copy)
@@ -2381,7 +2381,11 @@ expand_case (gimple stmt)
do_pending_stack_adjust ();
if (MEM_P (index))
- index = copy_to_reg (index);
+ {
+ index = copy_to_reg (index);
+ if (TREE_CODE (index_expr) == SSA_NAME)
+ set_reg_attrs_for_decl_rtl (SSA_NAME_VAR (index_expr), index);
+ }
/* We generate a binary decision tree to select the
appropriate target code. This is done as follows:
Re: Divide_1 testsuite fail due to a problem in the unwinding code
On 01/27/2012 05:18 PM, Dave Korn wrote: > On 27/01/2012 17:16, Andrew Haley wrote: >> On 01/27/2012 05:14 PM, Dave Korn wrote: >>> On 27/01/2012 17:01, Andrew Haley wrote: On 01/27/2012 04:46 PM, Andreas Krebbel wrote: > Starting with this IRA patch: > http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00028.html > __divdi3 does *not* need a stack frame at all. > > So the CFAs of __divdi3 and probe_1 are the same! I'm confused. But __divdi3 should have been compiled with enough unwinder data that it can be found; it should not matter whether __divdi3 has a stack frame or not. So why doesn't __divdi3 have a CFA of its own? >>> Unless I've misunderstood, it's because the CFA *is* the stack frame >>> (base?) >>> pointer. >> >> Ah, it's not that it has no stack frame, it's that it has no >> stack adjustment at all, not even a push? > > Well the return address might get pushed but if the CFA is the stack frame > base rather than current stack pointer, that won't change. Yabbut, in such functions the dwarf debug info can set the CFA to be SP. I'm pretty sure I've seen that done in frameless functions. Andrew.
[GCC steering committee] TILEPro/TILE-Gx port maintainership
I would like to propose myself as the maintainer for the TILEPro and TILE-Gx gcc ports. The gcc ports are currently under review, with the corresponding binutils available in the lastest binutils release (2.22), and the corresponding glibc port has been accepted. I am the primary author of both ports and have the hardware to test against both ports. Thanks, Walter Lee Tilera Corporation
Re: Divide_1 testsuite fail due to a problem in the unwinding code
[answering to self...] > Why does this "hack" not work? It was precisely devised for this purpose. Probably because you don't set fs->signal_frame in the fallback routine: /* SIGILL, SIGFPE and SIGTRAP are delivered with psw_addr after the faulting instruction rather than before it. Don't set FS->signal_frame in that case. */ if (!signo || (*signo != 4 && *signo != 5 && *signo != 8)) fs->signal_frame = 1; You might need to un-overload fs->signal_frame then. -- Eric Botcazou
Re: [GCC steering committee] TILEPro/TILE-Gx port maintainership
I'm raising this on the steering committee, Walter. Gerald
Re: [GCC steering committee] TILEPro/TILE-Gx port maintainership
Great. Thanks! Walter On 1/27/2012 1:31 PM, Gerald Pfeifer wrote: I'm raising this on the steering committee, Walter. Gerald
Re: Recovering REG_EXPR information after temporary expression replacement
Great, thanks! Results are good on this specific test case. Seems like
a nice thing to add in 4.8.
On Fri, 2012-01-27 at 18:40 +0100, Michael Matz wrote:
> Hi,
>
> On Fri, 27 Jan 2012, William J. Schmidt wrote:
>
> >
> > int
> > test_switch_1 (unsigned int *index, int i)
> > {
> > switch (*index)
> ...
> > However, for the first case, temporary expression replacement has
> > effectively removed the assignment to D.2004_3 (single local immediate
> > use permits replacement), so instead we see:
> >
> >
> > ;; switch (D.2004_3) , case 0: , case 1: , case 2:
> > >
> >
> > (insn 7 6 8 (set (reg:SI 124)
> > (mem:SI (reg/v/f:SI 122 [ index ]) [2 *index_2(D)+0 S4 A32]))
> > t1.i:4 -1
>
> With TER there is no decl anymore to associate the pseudo with.
> Conceptually, what's expanded is "*index", not an assignment to a pseudo.
> The move into a pseudo (and the creation of that very pseudo) is done by
> copy_to_reg in expand_case.
>
> > It would be a nice enhancement if the REG_EXPR could be preserved in
> > such cases. Does anyone know if there's something that would prevent
> > this?
>
> The hack below works in this specific situation (TERed into a switch), and
> adds a REG_EXPR when an TERed SSA name ever expanded into a pseudo (i.e.
> also for some more generic situations).
>
>
> Ciao,
> Michael.
> Index: expr.c
> ===
> --- expr.c(revision 183559)
> +++ expr.c(working copy)
> @@ -8991,8 +8991,13 @@ expand_expr_real_1 (tree exp, rtx target
> && stmt_is_replaceable_p (SSA_NAME_DEF_STMT (exp)))
> g = SSA_NAME_DEF_STMT (exp);
>if (g)
> - return expand_expr_real (gimple_assign_rhs_to_tree (g), target, tmode,
> - modifier, NULL);
> + {
> + rtx r = expand_expr_real (gimple_assign_rhs_to_tree (g), target,
> + tmode, modifier, NULL);
> + if (REG_P (r) && !REG_EXPR (r))
> + set_reg_attrs_for_decl_rtl (SSA_NAME_VAR (exp), r);
> + return r;
> + }
>
>ssa_name = exp;
>decl_rtl = get_rtx_for_ssa_name (ssa_name);
> Index: stmt.c
> ===
> --- stmt.c(revision 183559)
> +++ stmt.c(working copy)
> @@ -2381,7 +2381,11 @@ expand_case (gimple stmt)
> do_pending_stack_adjust ();
>
> if (MEM_P (index))
> - index = copy_to_reg (index);
> + {
> + index = copy_to_reg (index);
> + if (TREE_CODE (index_expr) == SSA_NAME)
> + set_reg_attrs_for_decl_rtl (SSA_NAME_VAR (index_expr), index);
> + }
>
> /* We generate a binary decision tree to select the
>appropriate target code. This is done as follows:
>
Re: Divide_1 testsuite fail due to a problem in the unwinding code
On Fri, Jan 27, 2012 at 06:08:23PM +0100, Eric Botcazou wrote:
> > To my understanding this can only happen if there is control flow from
> > a leaf function which in turn should only occur with signals. Perhaps
> > we could modify the CFA "a bit" for the frame where the signal
> > occurred? There is already a hack in uw_identify_context which does
> > this for the signal frame:
> >
> > static inline _Unwind_Ptr
> > uw_identify_context (struct _Unwind_Context *context)
> > {
> > /* The CFA is not sufficient to disambiguate the context of a function
> > interrupted by a signal before establishing its frame and the context
> > of the signal itself. */
> > if (STACK_GROWS_DOWNWARD)
> > return _Unwind_GetCFA (context) - _Unwind_IsSignalFrame (context);
> > else
> > return _Unwind_GetCFA (context) + _Unwind_IsSignalFrame (context);
> > }
>
> Why does this "hack" not work? It was precisely devised for this purpose.
Mmmh. But actually it is the stack frame of _divdi3 and not the signal
frame which gets the wrong cfa assigned from here. Not sure though,
perhaps it's time to draw a picture ;)
-Andreas-
Re: Divide_1 testsuite fail due to a problem in the unwinding code
On 01/27/2012 06:16 PM, Andrew Haley wrote: > On 01/27/2012 05:14 PM, Dave Korn wrote: >> On 27/01/2012 17:01, Andrew Haley wrote: >>> On 01/27/2012 04:46 PM, Andreas Krebbel wrote: >> Starting with this IRA patch: http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00028.html __divdi3 does *not* need a stack frame at all. So the CFAs of __divdi3 and probe_1 are the same! >>> >>> I'm confused. >>> >>> But __divdi3 should have been compiled with enough unwinder data >>> that it can be found; it should not matter whether __divdi3 has >>> a stack frame or not. >>> >>> So why doesn't __divdi3 have a CFA of its own? >> >> Unless I've misunderstood, it's because the CFA *is* the stack frame >> (base?) >> pointer. > > Ah, it's not that it has no stack frame, it's that it has no > stack adjustment at all, not even a push? Exactly. Since IRA got clever enough _divdi3 doesn't touch the stack pointer at all. -Andreas- > > Andrew. >
Re: Divide_1 testsuite fail due to a problem in the unwinding code
> Mmmh. But actually it is the stack frame of _divdi3 and not the signal > frame which gets the wrong cfa assigned from here. Not sure though, > perhaps it's time to draw a picture ;) The restored context inherits the signal flag set in the frame description and its CFA points to within _divdi3. The case you're describing is equivalent to the case for which I ajusted uw_identify_context (that was for stack checking, where a signal can be raised before establishing the frame; there is no frame at all here so the signal is also sort of raised before establishing it). The problem is very likely that the signal frame isn't marked as such. -- Eric Botcazou
Re: Recovering REG_EXPR information after temporary expression replacement
On Fri, 2012-01-27 at 18:40 +0100, Michael Matz wrote: > The hack below works in this specific situation (TERed into a switch), and > adds a REG_EXPR when an TERed SSA name ever expanded into a pseudo (i.e. > also for some more generic situations). FYI, I bootstrapped and regtested your patch on powerpc64-linux and did not see any regressions. Peter
gcc-4.6-20120127 is now available
Snapshot gcc-4.6-20120127 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120127/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 183650 You'll find: gcc-4.6-20120127.tar.bz2 Complete GCC MD5=76c1a3b03a0cc94862a3d20ee8722880 SHA1=cbe76a47e2cbd7b1a293ff998eaf30aeadedf0d2 Diffs from 4.6-20120120 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 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.
