Re: Simplification of relational operations (was [patch for PR18942])
Hi, > I'm looking at a missed optimizations in combine and it is similar to the one > you've fixed in PR18942 > (http://thread.gmane.org/gmane.comp.gcc.patches/81504). > > I'm trying to make GCC optimize > (leu:SI > (plus:SI (reg:SI) (const_int -1)) > (const_int 1)) > > into > > (leu:SI > (reg:SI) > (const_int 2)) > > Your patch for PR18942 handles only EQ/NE comparisons, and I wonder if there > is a reason not to handle LEU/GEU, LTU/GTU comparisons as well. I'm a bit > fuzzy whether signed comparisons can be optimized here as well, but I can't > see the problem with unsigned comparisons. > > Any reason why this optimization would be unsafe? the reason I handled only EQ/NE patterns is that you do not need to worry about overflows there. For ordering predicates, x - 1 <= 1 is not equivalent to x <= 2 if x = 0 (the former becomes MAX_UNSIGNED_INT <= 1, which is false), Zdenek
Re: Simplification of relational operations (was [patch for PR18942])
On Fri, Dec 02, 2011 at 03:33:06PM +1300, Maxim Kuvyrkov wrote: > I'm looking at a missed optimizations in combine and it is similar to the > one you've fixed in PR18942 > (http://thread.gmane.org/gmane.comp.gcc.patches/81504). > > I'm trying to make GCC optimize > (leu:SI > (plus:SI (reg:SI) (const_int -1)) > (const_int 1)) > > into > > (leu:SI > (reg:SI) > (const_int 2)) > . > > Your patch for PR18942 handles only EQ/NE comparisons, and I wonder if > there is a reason not to handle LEU/GEU, LTU/GTU comparisons as well. I'm > a bit fuzzy whether signed comparisons can be optimized here as well, but > I can't see the problem with unsigned comparisons. Consider reg:SI being 0? Then (leu:SI (plus:SI (reg:SI) (const_int -1)) (const_int 1)) is 0, but (leu:SI (reg:SI) (const_int 2)) is 1. You could transform this if you have a guarantee that reg:SI will not be 0 (and, in your general > Regarding the testcase, the general pattern > > (set (tmp1) (plus:SI (reg:SI) (const_int A)) > (set (tmp2) (leu:SI (tmp1) (const_int B)) case that reg:SI isn't 0 .. A-1). Jakub
Re: Working with frontend-specific aspects of GCC from a GCC plugin
On Wed, Nov 30, 2011 at 02:54:26PM -0700, Tom Tromey wrote:
> One idea that came up was to redeclare the FE-specific functions as
> 'weak', then check to see if they are available at runtime before
> calling them. It seems like a pain to me, since you have to rewrite the
> declarations, but I guess it could work. You could maybe write a plugin
> to write out the declarations :)
You don't need to rewrite them.
You can either use
extern __typeof (decl_as_string) decl_as_string __attribute__((weak));
(which has the downside that all references to decl_as_string from that CU
will be weak), or
static __typeof (decl_as_string) weak_decl_as_string __attribute__((weakref
("decl_as_string")));
where only the occurrences of weak_decl_as_string will be weak, if you
use decl_as_string in the CU somewhere, it will be strong.
But as others said, please look at langhooks first.
Jakub
Re: A new stack protector option?
On Tue, Nov 29, 2011 at 03:53:50PM -0800, Han Shen(沈涵) wrote: > Hi, I propose to add to gcc a new option regarding stack protector - > "-fstack-protector-strong", in addition to current gcc's > "-fstack-protector-all", which protects ALL functions, and > "-fstack-protector", which protects functions that have a big > (signed/unsigned) char array or have alloca called. Isn't -fstack-protector --param ssp-buffer-size=4 (or =2) enough for you? Jakub
Re: volatile correctness: combine vs. target.md
On Thu, Dec 1, 2011 at 10:40 PM, Georg-Johann Lay wrote: > Ian Lance Taylor wrote: > >> Georg-Johann Lay writes: >> >>> If general_operand can be perceived as >>> >>> (define_predicate "general_operand" >>> (ior (match_operand 0 "memory_operand") >>> (match_operand 0 "register_operand") >>> (match_operand 0 "immediate_operand"))) >>> >>> how can low_io_mem ever match? >> >> >> >> Oh, I see, I did misunderstand your question. Sorry about that. >> >> In general combine is just going to honor what your backend is asking >> for. If your backend says that it is OK to combine a volatile memory >> operand, then that is what combine is going to do. > > > Supplying an insn is the backend's way of telling that it is capable of > performing a specific operation. > > In the present case, the backend tells that it has a "Conditional Jump > depending on a bit in the I/O area". > > It does *not* say "It is ok to infringe volatile correctness" and move one > volatile memory access across an other one or similar memory annotation like > memory clobber by means of inline assembly or built-in barrier. > > >> It's certainly OK in >> general to combine across a volatile memory operand, as is happening >> here. I guess you are asking whether combine should have another check: >> if some operand in the insn is a volatile MEM, and it will cross a >> volatile MEM not mentioned in the combine, should combine reject that >> combination. > > > It's never correct to exchange volatile accesses. That's not true. volatile accesses to different memory locations have no special dependence. If it happens that GCC doesn't do this kind of things then this is only because most passes don't thouch volatile stmts at all (thus the reports for sub-optimal code with volatile - we don't even try to do legal transformations). Richard.
Dimensions of array parameters
Hello,
Parameters that have an array type (fixed-length or variable-length) are
internally converted to have a pointer type instead (this is with 4.6.)
For example:
static int
bar (int foo[12])
{
return foo[2];
}
is turned into:
bar (unsigned int x, int * foo)
...
Is there a way array dimension info could be preserved?
I though using a REFERENCE_TYPE to an ARRAY_TYPE for ‘foo’ here could do
it, but the C front-end doesn’t support references.
Thanks,
Ludo’.
Suspicion of regression in uninitialized value detection
Hello,
I suspect a regression in uninitialized value detection, but before
opening a bug I request your advices on the following problem:
I build the following code :
#include
#include
int main( int argc, char **argv )
{
int j;
int rtn;
int k,t;
j = atoi( argv[1] );
if ( j > 5 )
{
rtn = 10;
}
k=t;
printf("rtn = %d\n", rtn);
exit(0);
}
With gcc 4.0:
bash-4.2$ gcc-4.0 -O2 -Wall ./test_gcc2.c -o test_gcc
./test_gcc2.c: In function 'main':
./test_gcc2.c:17: warning: 't' is used uninitialized in this function
./test_gcc2.c:7: warning: 'rtn' may be used uninitialized in this function
With gcc 4.6.1, the warning on rtn disappears :
bash-4.2$ gcc -O2 -Wall ./test_gcc2.c -o test_gcc
./test_gcc2.c: In function ‘main’:
./test_gcc2.c:8:8: attention : variable ‘k’ set but not used
[-Wunused-but-set-variable]
./test_gcc2.c:17:5: attention : ‘t’ is used uninitialized in this
function [-Wuninitialized]
Do I need to pass special options to gcc 4.6.1 to enable this
detection or is it a gcc problem ?
Regards
Patrice
C++: rvalue references for *this
[I am not on this list, so please cc me.] On the link below it says that Bronek Kozicki has been working on C++ rvalue references for *this. What is the progress of this feature? I am on OS X 10.7.2, and GCC 4.6.2 compiled. Clang 3.0 has this feature, but not others, like lambda expressions, that GCC has. It is in fact a nice feature. Hans http://gcc.gnu.org/projects/cxx0x.html
RE: volatile correctness: combine vs. target.md
... >> It's never correct to exchange volatile accesses. > >That's not true. volatile accesses to different memory locations >have no special dependence. If it happens that GCC doesn't >do this kind of things then this is only because most passes >don't thouch volatile stmts at all (thus the reports for sub-optimal >code with volatile - we don't even try to do legal transformations). I'm confused. Do you mean that in Volatile int *a, *b; Int j, k; J = *a; k = *b; it is ok to fetch *b before *a? I can't think of any device driver writer who would expect that. paul
Re: C++: rvalue references for *this
On 12/02/2011 11:17 AM, Hans Aberg wrote: [I am not on this list, so please cc me.] On the link below it says that Bronek Kozicki has been working on C++ rvalue references for *this. What is the progress of this feature? Let's ask him, seems the obvious thing to do. Paolo.
Re: volatile correctness: combine vs. target.md
On Fri, Dec 2, 2011 at 5:46 AM, wrote: > > ... > >> It's never correct to exchange volatile accesses. > > > >That's not true. volatile accesses to different memory locations > >have no special dependence. If it happens that GCC doesn't > >do this kind of things then this is only because most passes > >don't thouch volatile stmts at all (thus the reports for sub-optimal > >code with volatile - we don't even try to do legal transformations). > > I'm confused. Do you mean that in > Volatile int *a, *b; > Int j, k; > J = *a; k = *b; > it is ok to fetch *b before *a? I can't think of any device driver writer > who would expect that. While I don't have the reproducing case to hand, I did find a situation where something like: volatile unsigned int counter; // tied to system clock volatile unsigned int ioport; t0 = counter; // stuff with ioport t1 = counter; ended up being: //stuff with ioport t0 = counter; t1 = counter; This might have been due to misbehavior of a machine role in my target, but at the time I convinced myself that technically the move was legal even though it completely invalidated the timing I was trying to do. Peter
Re: volatile correctness: combine vs. target.md
On Fri, Dec 2, 2011 at 1:14 PM, Peter Bigot wrote: > On Fri, Dec 2, 2011 at 5:46 AM, wrote: >> >> ... >> >> It's never correct to exchange volatile accesses. >> > >> >That's not true. volatile accesses to different memory locations >> >have no special dependence. If it happens that GCC doesn't >> >do this kind of things then this is only because most passes >> >don't thouch volatile stmts at all (thus the reports for sub-optimal >> >code with volatile - we don't even try to do legal transformations). >> >> I'm confused. Do you mean that in >> Volatile int *a, *b; >> Int j, k; >> J = *a; k = *b; >> it is ok to fetch *b before *a? I can't think of any device driver writer >> who would expect that. It's ok in terms of GCC internals. Whether it's ok in terms of the C language specification I don't know (but I think it is ok). Whether it is desirable is another question - and whether such desired behavior is easy to implement is another one. > While I don't have the reproducing case to hand, I did find a > situation where something like: > > volatile unsigned int counter; // tied to system clock > volatile unsigned int ioport; > t0 = counter; > // stuff with ioport > t1 = counter; > > ended up being: > > //stuff with ioport > t0 = counter; > t1 = counter; > > This might have been due to misbehavior of a machine role in my > target, but at the time I convinced myself that technically the move > was legal even though it completely invalidated the timing I was > trying to do. Yes, I think it is valid. Richard. > Peter
Re: volatile correctness: combine vs. target.md
On Fri, Dec 2, 2011 at 5:46 AM, wrote: > > > > ... >>> > >> It's never correct to exchange volatile accesses. >> > > >> > >That's not true. volatile accesses to different memory locations >> > >have no special dependence. If it happens that GCC doesn't >> > >do this kind of things then this is only because most passes >> > >don't thouch volatile stmts at all (thus the reports for sub-optimal >> > >code with volatile - we don't even try to do legal transformations). > > > > I'm confused. Do you mean that in > >Volatile int *a, *b; > >Int j, k; > >J = *a; k = *b; > > it is ok to fetch *b before *a? I can't think of any device driver writer > > who would expect that. On 12/02/2011 12:27 PM, Richard Guenther wrote: > It's ok in terms of GCC internals. Whether it's ok in terms > of the C language specification I don't know (but I think it is ok). It's not. 5.1.2.3 Program execution Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment. Evaluation of an expression may produce side effects. At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place. (A summary of the sequence points is given in annex C.) ... The least requirements on a conforming implementation are: — At sequence points, volatile objects are stable in the sense that previous accesses are complete and subsequent accesses have not yet occurred. So, in here: Volatile int *a, *b; Int j, k; J = *a; k = *b; the fetch from *a must complete before the sequence point that is the semicolon. Andrew.
Re: Suspicion of regression in uninitialized value detection
Sorry for the noise, the problem is already tracked here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
Le 2 décembre 2011 10:42, Patrice Bouchand a écrit :
> Hello,
>
> I suspect a regression in uninitialized value detection, but before opening
> a bug I request your advices on the following problem:
>
> I compile the following code :
>
> #include
> #include
>
> int main( int argc, char **argv )
> {
> int j;
> int rtn;
> int k,t;
>
> j = atoi( argv[1] );
>
> if ( j > 5 )
> {
> rtn = 10;
> }
>
> k=t;
>
> printf("rtn = %d\n", rtn);
>
> exit(0);
> }
>
>
> With gcc 4.0:
>
> bash-4.2$ gcc-4.0 -O2 -Wall ./test_gcc2.c -o test_gcc
> ./test_gcc2.c: In function 'main':
> ./test_gcc2.c:17: warning: 't' is used uninitialized in this function
> ./test_gcc2.c:7: warning: 'rtn' may be used uninitialized in this function
>
> With gcc 4.6.1, the warning on rtn disappears :
>
> bash-4.2$ gcc -O2 -Wall ./test_gcc2.c -o test_gcc
> ./test_gcc2.c: In function ‘main’:
> ./test_gcc2.c:8:8: attention : variable ‘k’ set but not used
> [-Wunused-but-set-variable]
> ./test_gcc2.c:17:5: attention : ‘t’ is used uninitialized in this function
> [-Wuninitialized]
>
>
> Do I need to pass special options to gcc 4.6.1 to enable this detection or
> is it a gcc problem ?
>
> Regards
>
> Patrice
>
Re: volatile correctness: combine vs. target.md
Richard Guenther wrote: > On Thu, Dec 1, 2011 at 10:40 PM, Georg-Johann Lay wrote: >> Ian Lance Taylor wrote: >> >>> Georg-Johann Lay writes: >>> If general_operand can be perceived as (define_predicate "general_operand" (ior (match_operand 0 "memory_operand") (match_operand 0 "register_operand") (match_operand 0 "immediate_operand"))) how can low_io_mem ever match? >>> >>> >>> Oh, I see, I did misunderstand your question. Sorry about that. >>> >>> In general combine is just going to honor what your backend is asking >>> for. If your backend says that it is OK to combine a volatile memory >>> operand, then that is what combine is going to do. >> >> Supplying an insn is the backend's way of telling that it is capable of >> performing a specific operation. >> >> In the present case, the backend tells that it has a "Conditional Jump >> depending on a bit in the I/O area". >> >> It does *not* say "It is ok to infringe volatile correctness" and move one >> volatile memory access across an other one or similar memory annotation like >> memory clobber by means of inline assembly or built-in barrier. >> >> >>> It's certainly OK in >>> general to combine across a volatile memory operand, as is happening >>> here. I guess you are asking whether combine should have another check: >>> if some operand in the insn is a volatile MEM, and it will cross a >>> volatile MEM not mentioned in the combine, should combine reject that >>> combination. >> >> It's never correct to exchange volatile accesses. > > That's not true. volatile accesses to different memory locations > have no special dependence. If it happens that GCC doesn't > do this kind of things then this is only because most passes > don't thouch volatile stmts at all (thus the reports for sub-optimal > code with volatile - we don't even try to do legal transformations). > > Richard. Disagree. If A and B are two different volatile memory locations, then: Writing or even reading A might change B. A common case where reading A induces changes is reading a latch. A common case where writing A also affects B is if A controls hardware configuration of a module like hardware port, I/O module or internal hardware like hardware timer, PLL, VCO, WDT or whatever. If you change the I/O setup of a port from high-Z to pullup or pulldown or push-pull by writing its configuration register A, you will see port registers B react and change their values. Just as Paul Koning did say: exchange accessing A and B is wrong in general. Or look at software where different tasks synchronize themselves using locks or semaphores to communicate. If A says "data in B is ready for consumption" and you exchange A and B you really have a problem. Johann
Re: volatile correctness: combine vs. target.md
On Fri, Dec 2, 2011 at 1:59 PM, Andrew Haley wrote: > On Fri, Dec 2, 2011 at 5:46 AM, wrote: >> > >> > ... > >> It's never correct to exchange volatile accesses. >>> > > >>> > >That's not true. volatile accesses to different memory locations >>> > >have no special dependence. If it happens that GCC doesn't >>> > >do this kind of things then this is only because most passes >>> > >don't thouch volatile stmts at all (thus the reports for sub-optimal >>> > >code with volatile - we don't even try to do legal transformations). >> > >> > I'm confused. Do you mean that in >> > Volatile int *a, *b; >> > Int j, k; >> > J = *a; k = *b; >> > it is ok to fetch *b before *a? I can't think of any device driver writer >> > who would expect that. > > On 12/02/2011 12:27 PM, Richard Guenther wrote: >> It's ok in terms of GCC internals. Whether it's ok in terms >> of the C language specification I don't know (but I think it is ok). > > It's not. > > 5.1.2.3 Program execution > > Accessing a volatile object, modifying an object, modifying a file, or > calling a function that does any of those operations are all side > effects, which are changes in the state of the execution > environment. Evaluation of an expression may produce side effects. At > certain specified points in the execution sequence called sequence > points, all side effects of previous evaluations shall be complete and > no side effects of subsequent evaluations shall have taken place. (A > summary of the sequence points is given in annex C.) > > ... > > The least requirements on a conforming implementation are: — At > sequence points, volatile objects are stable in the sense that > previous accesses are complete and subsequent accesses have not yet > occurred. > > So, in here: > > Volatile int *a, *b; > Int j, k; > J = *a; k = *b; > > the fetch from *a must complete before the sequence point that is the > semicolon. I see. As we do not explicitely model this dependency we probably get lucky by the if (gimple_has_volatile_ops ()) bail-out; most passes do. Richard. > Andrew.
Re: volatile correctness: combine vs. target.md
On 02/12/2011 13:59, Andrew Haley wrote: On Fri, Dec 2, 2011 at 5:46 AM, wrote: ... It's never correct to exchange volatile accesses. That's not true. volatile accesses to different memory locations have no special dependence. If it happens that GCC doesn't do this kind of things then this is only because most passes don't thouch volatile stmts at all (thus the reports for sub-optimal code with volatile - we don't even try to do legal transformations). I'm confused. Do you mean that in Volatile int *a, *b; Int j, k; J = *a; k = *b; it is ok to fetch *b before *a? I can't think of any device driver writer who would expect that. On 12/02/2011 12:27 PM, Richard Guenther wrote: It's ok in terms of GCC internals. Whether it's ok in terms of the C language specification I don't know (but I think it is ok). It's not. 5.1.2.3 Program execution Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment. Evaluation of an expression may produce side effects. At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place. (A summary of the sequence points is given in annex C.) ... The least requirements on a conforming implementation are: — At sequence points, volatile objects are stable in the sense that previous accesses are complete and subsequent accesses have not yet occurred. So, in here: Volatile int *a, *b; Int j, k; J = *a; k = *b; the fetch from *a must complete before the sequence point that is the semicolon. Andrew. That is my understanding of volatile. It would be fine to re-order the accesses in the expression "j = *a + *b", since there is no sequence point between them. But with a semicolon between them, they /must/ be correctly ordered. Without this ordering requirement, "volatile" would be almost useless - and C as a language would be useless for anything involving device drivers or embedded development. And since file IO, library calls, volatile "asm" functions, and external functions are "side effects" in the same sense, if it is legal to re-order volatiles then it is legal to re-order these other "side effects" - making C totally useless. The C compiler can generate code and re-order anything it wants, as long as the resulting program acts as though it executed the source code directly on the C "virtual machine" in terms of the side effects - all side effects must occur in the order given in the source code, and with the values specified in the source code.
Re: volatile correctness: combine vs. target.md
On 01/12/2011 21:40, Georg-Johann Lay wrote: > It's not unusual because: > > * It's not unusual to write down SFRs as violatile memory like > (*((volatile unsigned int*) 0x1234)) or as a cast to a composite > that reflects the SFRs bit(field)s. > > * It's not unusual that microcontrollers can access specific parts > of memory -- in particular I/O -- with special instructions. Great. Now I'm going to be hearing Tom Jones in my head for the rest of the day! :) (ObTopic: Andrew H's definition of volatile is completely right AIUI and the case reported by Peter B is definitely a very bad bug. Volatile operations are externally visible and must be executed in source-code order.) cheers, DaveK
MELT plugin 0.9.2 rc1 for GCC 4.6 (& future 4.7) available
Hello All,
It is my pleasure to announce the MELT plugin 0.9.2 release candidate 1
December XXth, 2011: Release of MELT plugin 0.9.2 for gcc-4.6 (& future gcc-4.7)
dedicated to the memory of John McCarthy
http://en.wikipedia.org/wiki/John_McCarthy_(computer_scientist)
MELT is a high-level domain specific language to extend GCC (GPLv3 licensed,
FSF oopyrighted)
You can download the gzipped source tar archive, from
http://gcc-melt.org/melt-0.9.2-rc1-plugin-for-gcc-4.6.tgz of size 4187121
bytes and md5sum fcc815967094a35f70a4f8e575ab3ca7 (december 02nd 2011). It
is extracted from MELT branch svn revision 181905 The version number 0.9.2
of the MELT plugin is unrelated to the version of the GCC compiler (4.6 or
4.7) for which it is supposed to work. Bug reports and patches are welcome
(to the gcc-m...@googlegroups.com list).
### NEWS for MELT 0.9.2
Several bug fixes.
New features:
cloning of values
=
The CLONE_WITH_DISCRIMINANT primitive -whose implementation is mostly
generated- enables creating new values, nearly clones of old
ones. Usage is
(clone_with_discriminant )
If the new discriminant is compatible with the old value's
discriminant, a new value is allocated. If it is not compatible nor
not a discriminant, the old value is returned. In particular, it is
possible to use
(clone_with_discriminant (lambda ) discr_debug_closure)
to make a debugging closure.
debugging closures
==
The DEBUG macro (and the underlying MELT_DEBUG_FUN which you should
not use directly) handles closure with the DISCR_DEBUG_CLOSURE
discriminant specially (somehow like C++ manipulators for
ostream-s). If an argument is a debugging closure of exactly the
DISCR_DEBUG_CLOSURE discriminant, the next argument is displayed using
that debugging closure.
Walking SSA use-def chains
==
The primitives WALK_USE_DEF_CHAIN_BREADTH_FIRST &
WALK_USE_DEF_CHAIN_DEPTH_FIRST enables to walk thru the use-def chains
in SSA passes.
More support notably for Gimple & Tree
==
Several functions, cmatchers, primitives have been defined, notably
GIMPLE_ASSIGN_TO, WALK_USE_DEF_CHAIN_BREADTH_FIRST &
WALK_USE_DEF_CHAIN_DEPTH_FIRST, EACHGIMPLEPHI_IN_BASICBLOCK
New MELT hooks for PLUGIN_FINISH_TYPE & PLUGIN_FINISH_DECL
==
MELT functions can be registered using
REGISTER_FINISH_TYPE_HOOK_FIRST, REGISTER_FINISH_TYPE_HOOK_LAST,
REGISTER_FINISH_DECL_HOOK_FIRST, REGISTER_FINISH_DECL_HOOK_LAST. The
argument is a boxed tree value. The PLUGIN_FINISH_DECL don't exist in
GCC 4.6 (only in GCC 4.7 and later).
New MELT hooks for other events
===
MELT functions can be register for PLUGIN_ALL_PASSES_START,
PLUGIN_ALL_PASSES_END, PLUGIN_ALL_IPA_PASSES_START,
PLUGIN_ALL_IPA_PASSES_END, PLUGIN_EARLY_GIMPLE_PASSES_START,
PLUGIN_EARLY_GIMPLE_PASSES_END event using
REGISTER_ALL_IPA_PASSES_END_HOOK_FIRST
REGISTER_ALL_IPA_PASSES_END_HOOK_LAST
REGISTER_ALL_IPA_PASSES_START_HOOK_FIRST
REGISTER_ALL_IPA_PASSES_START_HOOK_LAST
REGISTER_ALL_PASSES_END_HOOK_FIRST
REGISTER_ALL_PASSES_END_HOOK_LAST
REGISTER_ALL_PASSES_START_HOOK_FIRST
REGISTER_ALL_PASSES_START_HOOK_LAST
REGISTER_EARLY_GIMPLE_PASSES_END_HOOK_FIRST
REGISTER_EARLY_GIMPLE_PASSES_END_HOOK_LAST
REGISTER_EARLY_GIMPLE_PASSES_START_HOOK_FIRST
REGISTER_EARLY_GIMPLE_PASSES_START_HOOK_LAST
More runtime code generated
===
More runtime code is generated internally.
Bug reports and suggestions are always welcome on gcc-m...@googlegroups.com
or on gcc@gcc.gnu.org. Patches are welcome on gcc-m...@googlegroups.com and
on gcc-patc...@gcc.gnu.org with [MELT] tag.
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} ***
Re: Dimensions of array parameters
On Fri, 2 Dec 2011, Ludovic Court�s wrote: > Is there a way array dimension info could be preserved? Perhaps you could explain the actual problem you are trying to solve? The value of such a dimension is specified in the C standard to be checked for constraint violations (such as being <= 0) but otherwise ignored; in particular, unless "static" is inside the [], the actual pointer passed may be NULL or point to an array smaller than the specified dimension. -- Joseph S. Myers jos...@codesourcery.com
Re: volatile correctness: combine vs. target.md
On Fri, Dec 2, 2011 at 9:26 AM, Dave Korn wrote: > On 01/12/2011 21:40, Georg-Johann Lay wrote: > >> It's not unusual because: >> >> * It's not unusual to write down SFRs as violatile memory like >> (*((volatile unsigned int*) 0x1234)) or as a cast to a composite >> that reflects the SFRs bit(field)s. >> >> * It's not unusual that microcontrollers can access specific parts >> of memory -- in particular I/O -- with special instructions. > > Great. Now I'm going to be hearing Tom Jones in my head for the rest of the > day! :) > > (ObTopic: Andrew H's definition of volatile is completely right AIUI and the > case reported by Peter B is definitely a very bad bug. Volatile operations > are externally visible and must be executed in source-code order.) My case was probably a flaw in my machine description. Like many microcontrollers (including AVR), the msp430 maps peripherals as volatile memory references, and supports instructions that operate directly on that memory. The original msp430 back-end did a dirty trick with special predicates that temporarily set the global "volatile_ok" flag in order to trick gcc into generating acceptable code (combining a sequence of load/modify/store insns into a single RMW insn); I found that to be untrustworthy and replaced it with peepholes. Richard's comment that moving unrelated volatiles around each other is acceptable to core gcc, if not C, may have enabled the issue I saw, but as far as I'm concerned it was a bug in my stuff, even if I was confused enough to think for a while it might be technically allowed. Peter > > cheers, > DaveK >
Re: Dimensions of array parameters
Hi, "Joseph S. Myers" skribis: > On Fri, 2 Dec 2011, Ludovic Courtès wrote: > >> Is there a way array dimension info could be preserved? > > Perhaps you could explain the actual problem you are trying to solve? I’m just thinking that, if that information were preserved, GCC could do static bound checking and/or generate bound checking code. WDYT? Thanks, Ludo’.
Re: Dimensions of array parameters
On Fri, 2 Dec 2011, Ludovic Court�s wrote: > I'm just thinking that, if that information were preserved, GCC could do > static bound checking and/or generate bound checking code. As I noted, that would be contrary to the language semantics unless [static] is used. -- Joseph S. Myers jos...@codesourcery.com
Re: Dimensions of array parameters
ludovic.cour...@inria.fr (Ludovic Courtès) writes: > "Joseph S. Myers" skribis: > >> On Fri, 2 Dec 2011, Ludovic Courtès wrote: >> >>> Is there a way array dimension info could be preserved? >> >> Perhaps you could explain the actual problem you are trying to solve? > > I’m just thinking that, if that information were preserved, GCC could do > static bound checking and/or generate bound checking code. The ABI for a C function does not provide any way to pass down the dimensions of an array. Any such change would mean that you would have to recompiled the whole world, including the C library. In practice that is not going to happen. GCC can already generate bounds checking code via -fmudflap. It works by recording the bounds in the memory area, not in the function arguments. There is also Valgrind and AddresSanitizer. Ian
Re: volatile correctness: combine vs. target.md
> > -Original Message- > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of > Richard Guenther > Sent: Friday, December 02, 2011 9:35 AM > To: Andrew Haley > Cc: gcc@gcc.gnu.org > Subject: Re: volatile correctness: combine vs. target.md > > On Fri, Dec 2, 2011 at 1:59 PM, Andrew Haley wrote: >> On Fri, Dec 2, 2011 at 5:46 AM, wrote: ... It's never correct to exchange volatile accesses. >> >> That's not true. volatile accesses to different memory locations >> have no special dependence. If it happens that GCC doesn't do >> this kind of things then this is only because most passes don't >> thouch volatile stmts at all (thus the reports for sub-optimal >> code with volatile - we don't even try to do legal transformations). I'm confused. Do you mean that in Volatile int *a, *b; Int j, k; J = *a; k = *b; it is ok to fetch *b before *a? I can't think of any device driver writer who would expect that. >> >> On 12/02/2011 12:27 PM, Richard Guenther wrote: >>> It's ok in terms of GCC internals. Whether it's ok in terms of the C >>> language specification I don't know (but I think it is ok). >> >> It's not. >> >> 5.1.2.3 Program execution >> >> Accessing a volatile object, modifying an object, modifying a file, or >> calling a function that does any of those operations are all side >> effects, which are changes in the state of the execution environment. >> Evaluation of an expression may produce side effects. At certain >> specified points in the execution sequence called sequence points, all >> side effects of previous evaluations shall be complete and no side >> effects of subsequent evaluations shall have taken place. (A summary >> of the sequence points is given in annex C.) >> >> ... >> >> The least requirements on a conforming implementation are: - At >> sequence points, volatile objects are stable in the sense that >> previous accesses are complete and subsequent accesses have not yet >> occurred. >> >> So, in here: >> >> Volatile int *a, *b; >> Int j, k; >> J = *a; k = *b; >> >> the fetch from *a must complete before the sequence point that is the >> semicolon. > > I see. As we do not explicitely model this dependency we probably get lucky > by the if (gimple_has_volatile_ops ()) bail-out; most passes do. That sounds scary, if I understood you correctly. It sounds like GCC conforms to the standard only by accident rather than by design, which means that it might stop conforming to the standard by accident. Does this need cleanup -- for example, explicitly modeling the required sequencing so optimization passes are more likely to see that and get it right? For that matter, if "most" passes do, does that mean that we already have a bug if some pass that doesn't do this happens to get presented with a suitably constructed input? paul
Re: volatile correctness: combine vs. target.md
Paul Koning writes: >> I see. As we do not explicitely model this dependency we probably get lucky >> by the if (gimple_has_volatile_ops ()) bail-out; most passes do. > > That sounds scary, if I understood you correctly. It sounds like GCC > conforms to the standard only by accident rather than by design, which means > that it might stop conforming to the standard by accident. Does this need > cleanup -- for example, explicitly modeling the required sequencing so > optimization passes are more likely to see that and get it right? > > For that matter, if "most" passes do, does that mean that we already have a > bug if some pass that doesn't do this happens to get presented with a > suitably constructed input? This is a matter of how gcc has evolved over the years. It is certainly the case that gcc is designed to support volatile operations as defined by the standard. What Richard is referring to is a notion of explicit dependencies between instructions, which did not exist for the first 10 or 15 years of gcc's life. These explicit dependencies are now used to model things like memory aliasing which gcc did not support in the early days. The volatile qualifier remains supported, by design, just as it always has been, by checks for volatile in low-level routines. E.g., search for volatile (or VOLATILE) in gcc/alias.c. There are indeed GIMPLE level passes which need to explicitly check gimple_has_volatile_ops. That would remain true whether or we not we do a better job of expressing volatile dependencies explicitly. It would be better to have explicit volatile dependencies. But it is not a requirement for generating correct code. It is of course possible that there are bugs in the way that gcc handles volatile. Since many people use gcc in areas that require volatile to be handled correctly, not least the Linux kernel developers, I would expect such bugs to be reported quickly. Note that the issue that started this thread is not a case in which gcc is mishandling volatile in general. It is an AVR specific issue in which the AVR backend and the gcc combine pass disagree on how volatile memory operands should be handled. Ian
Re: [Patch,AVR] Was/Fix: error linking lto1 for target avr
Denis Chertykov wrote: > 2011/11/29 Georg-Johann Lay : >> Ian Lance Taylor wrote: >>> Georg-Johann Lay writes: >>> So if a frontend can define address spaces and it is a generic feature, the question is how to get the name of an address space in a generic, language independent way. >>> We could decide that all frontends that use address spaces must define a >>> printable name for each address space. That would mean changing the >>> middle-end address space interface to give a name to each address space. >>> The current middle-end address space interface does not require that >>> address spaces have a name. I was not involved in the addition of >>> address spaces to gcc, and I don't know why they followed the path they >>> did. >>> >>> Ian >> Presumably they chose that approach to keep it simple or it is even a >> performance issue to move the name around. >> >> I attached a patch but I fail to find the right configure options for >> gcc/binutils as the testsuite complains >> >> ./avr/bin/ld: bad -plugin option >> >> Configured gcc with --enable-lto and binutils 2.21 with --enable-plugin. >> >> Maybe the patch can be pre-approved so that the others can proceed with >> their work? > > Better to complete this work. > > Denis. http://gcc.gnu.org/ml/gcc-patches/2011-11/msg02574.html I now switched back to --disable-lto as I could not resolve the problems that appear to be a collect2 issue, see http://gcc.gnu.org/ml/gcc-help/2011-12/msg00016.html What I can do is: * build the compiler with the patch and with LTO enabled and without getting a linker error for c_addr_space_name. * I cannot get usable results from testsuite because of collect2 breakage * Testsuite passes fine with the patch and --disable-lto the only regression that I get is gcc.c-torture/execute/vector-subscript-1.c which is because of bogus testcase that assumes sizeof(int) = 4 and passes with the fix Index: gcc/testsuite/gcc.c-torture/execute/vector-subscript-1.c === --- gcc/testsuite/gcc.c-torture/execute/vector-subscript-1.c (revision 181932) +++ gcc/testsuite/gcc.c-torture/execute/vector-subscript-1.c (working copy) @@ -49,7 +49,7 @@ int main( int argc, char* argv[] ) if (*f(&val3, 3 ) != 4) __builtin_abort (); - __builtin_memcpy(a, &val3, 16); + __builtin_memcpy(a, &val3, sizeof(a)); for(i = 0; i < 4; i++) if (a[i] != i+1) __builtin_abort (); or - __builtin_memcpy(a, &val3, 16); + __builtin_memcpy(a, &val3, 4*sizeof(int)); Ok for trunk? Johann * config/avr/avr.h (ADDR_SPACE_PGM, ADDR_SPACE_PGM1, ADDR_SPACE_PGM2, ADDR_SPACE_PGM3, ADDR_SPACE_PGM4, ADDR_SPACE_PGM5, ADDR_SPACE_PGMX): Write as enum. (avr_addrspace_t): New typedef. (avr_addrspace): New declaration. * config/avr/avr-c.c (avr_toupper): New static function. (avr_register_target_pragmas, avr_cpu_cpp_builtins): Use avr_addrspace to get address space information. * config/avr/avr.c (avr_addrspace): New variable. (avr_out_lpm, avr_pgm_check_var_decl, avr_insert_attributes, avr_asm_named_section, avr_section_type_flags, avr_asm_select_section, avr_addr_space_address_mode, avr_addr_space_convert, avr_emit_movmemhi): Use it. (avr_addr_space_pointer_mode): Forward to avr_addr_space_address_mode. (avr_pgm_segment): Remove.
Re: C++: rvalue references for *this
On 02/12/2011 12:11, Paolo Carlini wrote: On 12/02/2011 11:17 AM, Hans Aberg wrote: [I am not on this list, so please cc me.] On the link below it says that Bronek Kozicki has been working on C++ rvalue references for *this. What is the progress of this feature? Let's ask him, seems the obvious thing to do. Hi it's close to completion, I'm hoping remaining 5% of work does not strech to 50%. Basically what is missing in mechanism in gcc/cp/call.c to actually bind implicit *this object to rvalue or lvalue, and the difficuly here is that "this" object is internally defined and bound as a pointer, and not as a reference as prescribed by the standard. Well there is also a question of paperwork (disclaimer of rights) from my employer which does not seem very forthcoming. I wanted this piece of work to be in version 4.7 but frankly this seems unrealistic now. B.
Re: C++: rvalue references for *this
On 2 Dec 2011, at 19:54, Bronek Kozicki wrote: > On 02/12/2011 12:11, Paolo Carlini wrote: >> On 12/02/2011 11:17 AM, Hans Aberg wrote: >>> [I am not on this list, so please cc me.] >>> >>> On the link below it says that Bronek Kozicki has been working on C++ >>> rvalue references for *this. What is the progress of this feature? >> Let's ask him, seems the obvious thing to do. > > Hi > > it's close to completion, I'm hoping remaining 5% of work does not strech to > 50%. Basically what is missing in mechanism in gcc/cp/call.c to actually bind > implicit *this object to rvalue or lvalue, and the difficuly here is that > "this" object is internally defined and bound as a pointer, and not as a > reference as prescribed by the standard. > > Well there is also a question of paperwork (disclaimer of rights) from my > employer which does not seem very forthcoming. > > I wanted this piece of work to be in version 4.7 but frankly this seems > unrealistic now. Thanks for the reply. I found that in a dynamic polymorphy (class hierarchy with virtual functions), one can nicely use it for complementary pure and mutative versions. A workaround might be simply giving them different names. Hans
Re: A new stack protector option?
Hi, Jakub, thanks! The thing is that ssp-buffer-size controls array-size limit, but we also want to protect attacks via struct/union, and other frame address casting. One of the places I've wanted to have stack protector was in routines that fill a structure from some binary input stream. In most attacks this includes an array overflow, but I've seen weird code where code is trying to be smart and fill a potentially variable-sized structure (e.g. a union of possible structures), and just blasts the stack with an unbound memcpy, even when those structures contain no arrays. It's significantly more rare than the cases with arrays, but these do need to be protected (for us). -Han On Fri, Dec 2, 2011 at 12:54 AM, Jakub Jelinek wrote: > > On Tue, Nov 29, 2011 at 03:53:50PM -0800, Han Shen(沈涵) wrote: > > Hi, I propose to add to gcc a new option regarding stack protector - > > "-fstack-protector-strong", in addition to current gcc's > > "-fstack-protector-all", which protects ALL functions, and > > "-fstack-protector", which protects functions that have a big > > (signed/unsigned) char array or have alloca called. > > Isn't -fstack-protector --param ssp-buffer-size=4 (or =2) enough for you? > > Jakub
gcc-4.6-20111202 is now available
Snapshot gcc-4.6-20111202 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20111202/ 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 181951 You'll find: gcc-4.6-20111202.tar.bz2 Complete GCC MD5=63387c4b845b19a93cc4450ea181df3b SHA1=9d03d7eb3d4c26bc23a750d61e6ecd8573721bd8 Diffs from 4.6-2025 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.
Re: volatile correctness: combine vs. target.md
On 12/02/2011 06:35 AM, Richard Guenther wrote:
> I see. As we do not explicitely model this dependency we probably
> get lucky by the if (gimple_has_volatile_ops ()) bail-out; most
> passes do.
What are you talking about? Of course we do.
> int
> read_dependence (const_rtx mem, const_rtx x)
> {
> return MEM_VOLATILE_P (x) && MEM_VOLATILE_P (mem);
> }
et al.
r~
libsupc++/exception cannot find bits/atomic_lockfree_defines.h
I just merged from trunk and several of my C++ tests are failing with the error: In file included from <...>/libstdc++-v3/libsupc++/new:42:0, from <...>/gcc/testsuite/g++.dg/pph/x5dynarray3.h:5:<...>/libstdc++-v3/libsupc++/exception:40:42: fatal error: bits/atomic_lockfree_defines.h: No such file or directory compilation terminated. I see that there is a file atomic_lockfree_defines.h, but it's in libstdc++-v3/libsupc++/atomic_lockfree_defines.h. Does this ring a bell? Thanks. Diego.
Re: libsupc++/exception cannot find bits/atomic_lockfree_defines.h
On 12/02/2011 06:59 PM, Diego Novillo wrote: I just merged from trunk and several of my C++ tests are failing with the error: In file included from <...>/libstdc++-v3/libsupc++/new:42:0, from <...>/gcc/testsuite/g++.dg/pph/x5dynarray3.h:5:<...>/libstdc++-v3/libsupc++/exception:40:42: fatal error: bits/atomic_lockfree_defines.h: No such file or directory compilation terminated. I see that there is a file atomic_lockfree_defines.h, but it's in libstdc++-v3/libsupc++/atomic_lockfree_defines.h. Does this ring a bell? bkoz rewrote all the libstdc++ support. I'd guess your missing an update or something since I didnt see anything like what you are seeing with a scratch build and full testsuite run yesterday... ? Andrew
Re: Simplification of relational operations (was [patch for PR18942])
On 2/12/2011, at 9:45 PM, Jakub Jelinek wrote: > On Fri, Dec 02, 2011 at 03:33:06PM +1300, Maxim Kuvyrkov wrote: >> I'm looking at a missed optimizations in combine and it is similar to the >> one you've fixed in PR18942 >> (http://thread.gmane.org/gmane.comp.gcc.patches/81504). >> >> I'm trying to make GCC optimize >> (leu:SI >> (plus:SI (reg:SI) (const_int -1)) >> (const_int 1)) >> >> into >> >> (leu:SI >> (reg:SI) >> (const_int 2)) >> . >> >> Your patch for PR18942 handles only EQ/NE comparisons, and I wonder if >> there is a reason not to handle LEU/GEU, LTU/GTU comparisons as well. I'm >> a bit fuzzy whether signed comparisons can be optimized here as well, but >> I can't see the problem with unsigned comparisons. > > Consider reg:SI being 0? Then (leu:SI (plus:SI (reg:SI) (const_int -1)) > (const_int 1)) > is 0, but (leu:SI (reg:SI) (const_int 2)) is 1. > You could transform this if you have a guarantee that reg:SI will not be 0 > (and, in your general > >> Regarding the testcase, the general pattern >> >> (set (tmp1) (plus:SI (reg:SI) (const_int A)) >> (set (tmp2) (leu:SI (tmp1) (const_int B)) > > case that reg:SI isn't 0 .. A-1). Jacub, Zdenek, Thank you for explaining the overflow in comparisons. In fact, the unsigned overflow is intentionally used in expanding of switch statements to catch the 'default:' case in certain switch statements with just one conditional branch. -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics
