On 07/12/2011 06:07 PM, David Malcolm wrote:
On this build of GCC (standard Fedora 15 gcc package of 4.6.0), the
relevant part of cfgexpand.c looks like this:
struct rtl_opt_pass pass_expand =
{
{
RTL_PASS,
"expand", /* name */
[...snip...]
PROP_ssa | PROP_g
Hi All!
As you may see pta_flags enum in i386.c is almost full. So there is a
risk of overflow in quite near future. Comment in source code advises
"widen struct pta flags" which is now defined as unsigned. But it
looks not optimal.
What will be the most proper solution for this problem?
Thanks
Hello all,
I seek a tree attribute which tells that a "pointer" (in the
C/middle-end sense) does not alias with any other variable in the
translation unit (i.e. like "restrict"), but on the other hand, it
should prevent code movements and value assumptions across (impure)
function calls - as
On Wed, Jul 13, 2011 at 11:49 AM, Paolo Bonzini wrote:
> On 07/12/2011 06:07 PM, David Malcolm wrote:
>>
>> On this build of GCC (standard Fedora 15 gcc package of 4.6.0), the
>> relevant part of cfgexpand.c looks like this:
>>
>> struct rtl_opt_pass pass_expand =
>> {
>> {
>> RTL_PASS,
>> "e
On Wed, Jul 13, 2011 at 12:30 PM, Tobias Burnus wrote:
> Hello all,
>
> I seek a tree attribute which tells that a "pointer" (in the C/middle-end
> sense) does not alias with any other variable in the translation unit (i.e.
> like "restrict"), but on the other hand, it should prevent code movement
On 12 July 2011 18:29, Diego Novillo wrote:
> On 11-07-12 12:52 , Philip Herron wrote:
>
>> Would Gcc internals documentation count or is it more for a whole
>> project documentation work? I probably missed the thing about this in
>> London since i had to leave on the Sunday morning.
>>
>> I am ki
Michael Meissner wrote:
> On Mon, Jul 11, 2011 at 12:38:34PM +0200, Georg-Johann Lay wrote:
>> How do I write a pre-reload combine + pre-reload split correctly?
>> I'd like to avoid clobber reg.
>>
>> Thanks much for any hint.
>
> The move patterns are always kind of funny, particularly during reg
On Wed, Jul 13, 2011 at 07:09, Philip Herron wrote:
> I am quite interested in applying for this but not quite sure what my
> proposal should be like. Should i just discuss my interest in
> front-end and middle-end stuff and the lack of documentation currently
> etc.
Given that you are volunteer
On 07/13/2011 12:57 PM, Richard Guenther wrote:
On Wed, Jul 13, 2011 at 12:30 PM, Tobias Burnus wrote:
Example 2: Coarray with sync. The SYNC is not directly called, but via a
wrapper function to increase the fun factor.
subroutine sub(coarray)
integer :: coarray[*]
coarray = 5
This brings in the cp_binding_level change I made recently on
trunk.
Tested on x86_64.
Diego.
On 07/13/2011 12:54 PM, Richard Guenther wrote:
> Yes, PROP_gimple_lcx needs to be added to PROP_trees. I cannot approve the
> patch, unfortunately.
Hm, why? complex operations are lowered after a complex lowering pass
has executed. they are still lowered on RTL, so I don't see why we need
Igor Zamyatin writes:
> As you may see pta_flags enum in i386.c is almost full. So there is a
> risk of overflow in quite near future. Comment in source code advises
> "widen struct pta flags" which is now defined as unsigned. But it
> looks not optimal.
>
> What will be the most proper solution
Tobias Burnus writes:
> Would it? How does the compiler know that between "call
> SYNC_calling_proc()" the value of "coarray" could change? Hmm,
> seemingly, that's indeed the case, looking at the optimized dump of
> the example above:
The C99 restrict qualifier doesn't mean that some random fun
Hello,
I have written a simple ipa pass and would like to make use of Link time
optimisation. My pass requires access to the function bodies and ideally I
would like the driver function to be called once at link time and have
access to functions in all of the files as if they were one compilatio
On 07/13/2011 03:27 PM, Ian Lance Taylor wrote:
The C99 restrict qualifier doesn't mean that some random function can
change the memory to which the pointer points; it means that assignments
through pointer 1 can't change the memory to which pointer 2 points.
That is, restrict is all about whethe
On 07/13/2011 03:46 PM, Tobias Burnus wrote:
On 07/13/2011 03:27 PM, Ian Lance Taylor wrote:
[...]
it doesn't say anything about functions, and in general a call to a
function can change any memory pointed to by any pointer.
I misread the paragraph - in particular the last sentence. In Fortra
Hi all,
As part of a testsuite script I am parsing GCC's output and I noticed
that format specifier %qs quotes the string by surrounding it with
unicode characters. I can't find where this %qs is defined so that I can
try and override it to quote with '%s' or `%s'. Anything but unicode.
Any
Hello,
I have written a simple ipa pass and would like to make use of Link time
optimisation. My pass requires access to the function bodies and ideally I
would like the driver function to be called once at link time and have
access to functions in all of the files as if they were one compilatio
On 13 July 2011 15:18, Paulo J. Matos wrote:
> Hi all,
>
> As part of a testsuite script I am parsing GCC's output and I noticed that
> format specifier %qs quotes the string by surrounding it with unicode
> characters. I can't find where this %qs is defined so that I can try and
> override it to q
Tobias Burnus writes:
> In that sense, I do not seem to need a new flags for
> asynchronous/coarrays - which are handled by TYPE_QUAL_RESTRICT, but I
> need a new flag for normal (noncoarray, nonasychronous) variables,
> which are passed by value or are allocatable - and where a function
> call w
On Wed, 13 Jul 2011 15:55:58 +0100
Jonathan Wakely wrote:
> On 13 July 2011 15:18, Paulo J. Matos wrote:
> > Hi all,
> >
> > As part of a testsuite script I am parsing GCC's output and I noticed that
> > format specifier %qs quotes the string by surrounding it with unicode
> > characters. I can't
"Paulo J. Matos" writes:
> As part of a testsuite script I am parsing GCC's output and I noticed
> that format specifier %qs quotes the string by surrounding it with
> unicode characters. I can't find where this %qs is defined so that I
> can try and override it to quote with '%s' or `%s'. Anythi
On Wed, Jul 13, 2011 at 10:22, AJM-2 wrote:
> My question is whether LTO can be used in this way, to have a simple ipa
> pass called once at link time with access to the function bodies, and if so
> how is this achieved? cgraph_function_body_availability seems to only be
> half the story.
Yes,
What you say is in line with my understanding, however when I instrument the
execute function of ipa-function-and-variable-visibility
(local_function_and_variable_visibility()) I note that:
gcc -flto a.c b.c
causes the pass to be called twice (presumably once per file).
If I split the compilatio
Hello,
If local_function_and_variable_visibility was not a simple IPA pass it
would not have been called once per file but once per function (as it is
with GIMPLE pass).
I feel this is normal that this pass is run 2 times because it is run
before any link operations.
However, I don't know ex
Hello,
sorry to answer that late (I didn't saw your mail in my mailbox + I
was preparing me for RMLL/Libre software meeting).
Your solution looks to be a nice one, I am goiing to try it and I will
post the result of my experiment. I was not aware of that hook.
Thanks!
Pierre Vittet
He
On Wed, Jul 13, 2011 at 01:42:29PM +0200, Georg-Johann Lay wrote:
> All the trouble arises because there is no straight forward way to
> write the right insn condition, doesn't it?
>
> Working around like that will work but it is obfuscating the code, IMHO.
Given I don't know the AVR port, I don'
On Wed, Jul 13, 2011 at 5:54 PM, AJM-2 wrote:
>
> What you say is in line with my understanding, however when I instrument the
> execute function of ipa-function-and-variable-visibility
> (local_function_and_variable_visibility()) I note that:
>
> gcc -flto a.c b.c
> causes the pass to be called t
Putting my "simple IPA pass" adjacent to IPA-PTA does cause it to be called
as expected. However for each node in the call graph (with
cgraph_function_body_availability returning AVAIL_AVAILABLE),
gimple_has_body_p is always false.
The call graph data seems to be available, but the documentation
On Wed, Jul 13, 2011 at 10:09 PM, AJM-2 wrote:
>
> Putting my "simple IPA pass" adjacent to IPA-PTA does cause it to be called
> as expected. However for each node in the call graph (with
> cgraph_function_body_availability returning AVAIL_AVAILABLE),
> gimple_has_body_p is always false.
>
> The
Hi,
Has anyone used cachecc1 (http://cachecc1.sourceforge.net/) to
cache gcc bootstraps of in recent years? The project looks rather stale,
2004. I would love to accelerate bootstraps of gcc rebuilds to test
snapshots more frequently. Is there any interest in getting this to work?
(I'm part
31 matches
Mail list logo
