> On Fri, 29 Aug 2008, Jan Hubicka wrote:
>
> > Hi,
> > tonight testing on x86_64, i386 and IA-64 didn't seem to bring any new
> > surprises, so I've comitted the following patch.
> > I will also update changes page of 4.4.
> >
> > * doc/i
> > On Fri, 29 Aug 2008, Jan Hubicka wrote:
> >
> > > Hi,
> > > tonight testing on x86_64, i386 and IA-64 didn't seem to bring any new
> > > surprises, so I've comitted the following patch.
> > > I will also update changes page of 4.
> On 5/2/07, Sjodin, Jan <[EMAIL PROTECTED]> wrote:
> >Thanks for all the responses. It seems like LTO will have to wait for
> >the tuples or there will be a lot of throw-away code.
>
> If you really only can think of LTO as the reader/writer, then perhaps
> yes. But if you read back this thread,
> Zdenek Dvorak <[EMAIL PROTECTED]> writes:
>
> > The problem is, that it does not give any speedups (it is almost
> > completely compile-time neutral for compilation of preprocessed
> > gcc sources). I will check whether moving also edges to pools
> > changes anything, but so far it does not see
> Hello,
>
> as discussed in http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01133.html,
> it might be a good idea to try moving cfg to alloc pools. The patch
> below does that for basic blocks (each function has a separate pool
> from that its basic blocks are allocated). At the moment, the patch
> I would like to get some more information about pr32374.
>
> I do not know what virtual_stack_vars are and there is no documentation
> in the doc directory.
It is documented:
@findex VIRTUAL_STACK_VARS_REGNUM
@cindex @code{FRAME_GROWS_DOWNWARD} and virtual registers
@item VIRTUAL_STACK_VARS_REG
> Same here (OpenSUSE 10.2, gcc 4.1.3), also for rev. 126127.
This was caused by accidental commit of mine (ie I've commited cse.c
with sharing changes). It is reverted now.
Honza
> Kenneth Zadeck wrote:
> >I do not remember if it was stevenb or bonzini that observed that
> >because of changes that came with the dataflow branch it is now trivial
> >to get rid of no_new_pseudos.
>
> For the record, this was Steven's observation. And Kenner confirming
> that this was the or
> On 09 July 2007 20:48, Nicolas Alt wrote:
>
> > Hi!
> >
> > On the AMD64 / x86-64Bit architecture, some arguments of a functions
> > are passed using registers, but there seem to be two different
> > conventions out there. The standard ABI uses 6 registers, but
> > Microsoft compilers use only
> > Windows and GCC ABIs are on x86-64 more different than that (they was
> > historically developed in parallel). GCC 4.3 will support attribute for
> > this calling convention contributed by Kai Tiez and Richard Henderson,
> > but before that there is not much to do...
> Note: My name is Kai Tiet
> >
> > For MS I would probably suggest ms_abi (it makes it cleaner that the
> > attribute is affecting calling convetion). For our abi I am not sure, we
> > can sysv_abi or something else...
>
> I will prepare an patch for it. For me "ms_abi" and "sysv_abi" is fine.
I would say that it is in ge
>
> I am on that tricky thing ;) I think I need in i386.c an global variable
> "ix86_amd64_abi" which helds the the current function abi. This means also
> that I have to use instead of TARGET_64BIT_MS_ABI this variable. This var
> may initioalized by init_cumulative_args and the overriden
> R
> >
> > I am on that tricky thing ;) I think I need in i386.c an global variable
> > "ix86_amd64_abi" which helds the the current function abi. This means also
> > that I have to use instead of TARGET_64BIT_MS_ABI this variable. This var
> > may initioalized by init_cumulative_args and the over
>
> I thank you very much for your great help. Currently I am stucked on
> x86_function_value_regno_p (macro FUNCTION_VALUE_REGNO_P). It is not clear
> what's to do here for the FIRST_FLOAT_REG case. Maybe I could use the
> ms_abi variant for sysv_abi as default too. But I think, it breaks 87 f
> Jan Hubicka wrote on 11.07.2007 14:01:54:
>
> > >
> > > I thank you very much for your great help. Currently I am stucked on
> > > x86_function_value_regno_p (macro FUNCTION_VALUE_REGNO_P). It is not
> clear
> > > what's to do here f
Hi,
to add some extra data
> At the summit, I discovered two things about the internal representation
> of debugging information:
>
> 1) According to Honza, the instances of the BLOCK tree type take 30% of
> the space in a compilation.
this large portion appears on C++ testcases doing a lot of in
> On Mon, Jul 23, 2007 at 07:33:46PM +0200, Jan Hubicka wrote:
> > The particular problem here is that the abstract origin pointers points
> > to the blocks within functions they was constructed from. These are used
> > by dwarf2out to output abstract copy of the function and
> Jan Hubicka wrote:
> >Thanks for explanation - the space optimization seems relatively
> >chalenging to implement, in particular because the variables in scope
> >might change in between the time abstract copy is output and the time
> >the block referencing to the bl
> Hi Jan.
>
> What do you expect DECL_SAVED_TREE to have in cgraph_analyze_functions:
>
> /* ??? It is possible to create extern inline function and later using
>weak alias attribute to kill its body. See
>gcc.c-torture/compile/2009-1.c */
> if (!DECL_SAVED_TREE (
> Hi Kai,
>
> so, could you resolve the remaining issues? Or have you kind of
> paused the project?
>
> Cheers,
> Nicolas
>
>
> On Jul 12, 2007, at 2:14 , Kai Tietz wrote:
>
> >Hi,
> >
> >I am nearly through :) The remaining macros left to be ported are
> >REGPARM_MAX and SSE_REGPARM_MAX. Th
> > The test there is sort of hack, I would just remove it at this stage and
> > we can work out better fix for that testcase later. I hope that with my
> > plans for declaration merging pass we can get round such weird side
> > effects of in place declaration replacement.
>
> Will do.
>
> How a
>
> Recently I have tried to run Spec2000 fortran benchmarks
> with -fwhole-program and -combine flags. It looks like
> there was no effect of really combining files into
> one program, i.e. they are processed separately at ipa level.
>
> I wonder what's the reason for this.
> Pointing to relevan
>
> Summary
> ---
>
> We entered Stage 2 on July 6th. I plan to put us into Stage 3 on
> September 10th. At that point, we will accept only bug-fixes -- no
> more new features until Stage 1 for GCC 4.4.
>
> Are there any folks out there who have projects for Stage 1 or Stage 2
> that they
> Jan Hubicka wrote:
>
> > One thing I would like to see in is the sharing checker. The criteria
> > of bootstrap/regtesting on primary platforms is almost met now with
> > exception of regmove pass that I sent patch for some time ago.
> > http://gcc.gnu.org/ml/gcc
>
> Is popcount really slow on PowerPC? (Compared to clz?) Ideally one
> would choose between the two expansions based on RTL costs, but the only
> architectures it matters for are i386 and powerpc, and neither of them
> define the cost of either clz or popcount.
Of course adding a popcount
> Someone has committed a patch that is causing both
> gfortran.dg/do_3.F90 and gfortran.dg/c_char_tests.f03
> to fail at -O3 on amd64-*-freebsd. A quick inspection
> of fortran/ChangeLog doesn't yield a pointer to any
> particular commit. This may be caused by some middle-end
> change, but I won
> > Because of the famous duplicated declaration problem
>
> This sentence is reminding me that I forgot to send the following update:
>
> As I said I was going to give it a shot over the week-end, here's an
> update on this: it won't make it into 4.3, because it's a big change
> and my current p
> >> As I said I was going to give it a shot over the week-end, here's an
> >> update on this: it won't make it into 4.3, because it's a big change
> >> and my current patch is triggering a very long string of
> > Huh, still I would be interested in seeing the patch.
>
> It's based on Michal Matz'
> Jan Hubicka wrote:
> >Thanks, I sent the patch for testing and lets see if it solves the
> >problem.
>
> If the testsuite passes, and you intend to commit this, please add a FIXME.
Sadly, the testsuite regressions don't seems to be fixed. I will try to
figure out to
Hi,
I am looking into what parts of frontend stil depends on frontend inline
decision (ie DECL_INLINE now ignored by middle end). All these uses
strike wrong, given that inlining decisions are independent on it.
These divergences for example requires us to enable expensive
-finline-functions for -
> > Sadly, the testsuite regressions don't seems to be fixed. I will try to
> > figure out tomorrow why the function is still being inlined.
>
> The test case gfortran.dg/do_3.F90 pass with -fno-strict-overflow
> (see http://gcc.gnu.org/ml/fortran/2007-09/msg00116.html).
> I have posted at http:/
> Summary
> ===
>
> We are closing in on Stage 3, previously announced for September 10th.
> At this point, I'm not aware of any reason to delay that date. Are
> there any Stage 2 patches that people don't think will be submitted by
> that point?
I am still planning to do some retuning of in
> > The testcase was indeed previously not inlined at all. Shall we add
> > -fno-strict-overflow to the testcase then?
>
> This what I would do, but I am not qualified to make the call.
> In addition my working setup is totally broken right now
> (at stage1). Could you do the addition to the tes
> (Sorry, first one bounced from gcc@ because it was over 400k)
>
> Hi Jan,
>
> On sparc-sun-solaris2.10, I'm getting new bootstrap failures in stage2
> complaining several times about rtl sharing. I've included four .i files
> for modules that ICEed during stage2, and the cc1 invocations below.
> Hi,
> I already have fix for this just waiting for Andreas Tobler to verify
> that it does what expected. If you could give it a try, it would be
> nice.
>
> The problem is
>
> /* Called when INSN is being moved from a location near the target of a jump.
>We leave a marker of the form (us
> Jan Hubicka <[EMAIL PROTECTED]> writes:
>
> > Producing USE expressions embedding whole INSN. The comment promise
> > that those will be removed before reorg ends, but they are not. This
> > patch just adds simple code to remove them in very last dbr_schedule
> Jan Hubicka <[EMAIL PROTECTED]> writes:
>
> > > Jan Hubicka <[EMAIL PROTECTED]> writes:
> > >
> > > > Producing USE expressions embedding whole INSN. The comment promise
> > > > that those will be removed before reorg ends, but they
> Jan Hubicka wrote:
>
> > For C++ there are number of cases I need to go through dealing with
> > attempts to not instantiate non-inline methods that won't be needed.
>
> I'm not sure exactly what cases you're referring to, but please be
> careful. Fo
> Jan Hubicka wrote:
>
> > I am basically trying to avoid need for DECL_INLINE (while keeping
> > DECL_DECLARED_INLINE and DECL_UNINLINABLE for frontend use) - inliner is
> > now doing all the job himself to figure out what is or isn't needed.
>
> That certa
> At revision 128228, the patch enables me to go from stage1 to stage3, but
> bootstrap
> still fails with:
>
> libtool: compile: /opt/gcc/darwin_buildw/gcc/gcj
> -B/opt/gcc/darwin_buildw/powerpc-apple-darwin8/ppc64/libjava/
> -B/opt/gcc/darwin_buildw/gcc/ -fclasspath=
> -fbootclasspath=../..
>
>
> This second patch also allows bootstrap to complete on my sparc box.
Thanks for testing and good news,
I will commit the patch
Honza
>
> Thanks,
> --Kaveh
> --
> Kaveh R. Ghazi[EMAIL PROTECTED]
> On Sat, 8 Sep 2007, Andrew Pinski wrote:
> > Rerun the command without the ">/dev/null 2>&1", libtool likes to say
> > that PIC mode will give the same output as non PIC mode (which is not
> > always true).
>
> Blind me. Obviously that redirection removed all traces of the real
> error. Ahem.
> Jan Hubicka wrote:
>
> > I am still planning to do some retuning of inliner (our inline limits
> > wasn't revisited for inclusion of SSA optimizers).
>
> Assuming that the tuning is essentially twiddling constants, I'm not
> overly worried. If you
> Andreas Jaeger <[EMAIL PROTECTED]> writes:
>
> > bootstrap with current svn head fails for me on Linux/x86-64:
> ...
> > cc1: warnings being treated as errors
> > /cvs/gcc-svn/trunk/gcc/treelang/treetree.c:1191: error:
> > ???treelang_expand_function??? defined but not used
> > make[3]: *** [tr
> Kai Tietz wrote:
>
> > See
> > http://www.nabble.com/-PING%5E2-PATCH-%3A-Preparations-for-SYSV-MS-ABI-attributes-in-backend-tf4414541.html
> > http://www.nabble.com/-PATCH-%3A-Implementation-for-SYSV-MS-ABI-attributes-in-i386-may-before-stage--3-tf4428449.html
>
> Thanks for letting me know. I
> On 9/17/07, Uros Bizjak <[EMAIL PROTECTED]> wrote:
> > Hello!
> >
> > I have tripped over a problem, where #defines from libc
> > (bits/mathinline.h) interfere badly with gcc's intrinsics.
> >
> > The problem (note the #include):
> >
> > --cut here--
> > #include
> >
> > double test (double x)
>
> Jan, I'm converting the call graph builder code for tuples and in the
> process I ran into calls to lang_hooks.callgraph.analyze_expr(). From
> what I've seen:
>
> 1- The third argument to that function (DECL), is not used by any callback.
>
> 2- In fact, if it was used, we'd ICE because the f
Hi,
thanks for writting the proposal. It seems that at least in general
terms we are all in sync.
> At this point we are interested in getting feedback on the general idea.
> There is some refactoring that will be needed inside the call-graph
> manager and some aspects of the design may not even n
Hi,
>
> Jan, wrt the optimization plan coming out of the analysis phase, and the
> various pieces of header/summary information, what do you think are the
> major pieces we need?
The cgraph used to be organized on a separate analysis, propagation and
modify stages and the passes in implemented
> Hello,
>
> I have a SIMPLE_IPA_PASS that parses the program multiple times. As it
> parses gimple, it builds a data structure with the information
> collected that will provide some invariants to future iterations over
> the program.
>
> I was looking into adding a new feature that would take a
> ==5404== Conditional jump or move depends on uninitialised value(s)
> ==5404== at 0x25DAAD7: incorporate_penalties (ipa-cp.c:3282)
> ==5404== by 0x25DAAD7: good_cloning_opportunity_p(cgraph_node*, sreal,
> sreal, profile_count, int) (ipa-cp.c:3340)
I looked at this one (since it is in code
> >
> > diff --git a/gcc/ipa-prop.h b/gcc/ipa-prop.h
> > index 42842d9466a..1d0c115465c 100644
> > --- a/gcc/ipa-prop.h
> > +++ b/gcc/ipa-prop.h
> > @@ -623,8 +623,8 @@ ipa_node_params::ipa_node_params ()
> > : descriptors (NULL), lattices (NULL), ipcp_orig_node (NULL),
> >known_csts (vNULL),
>
> I can confirm that zero-initializing node_is_self_scc prevents the
> uninitialised use warnings in incorporate_penalties (ipa-cp.c:3282)
Great, I will commit the patch. But I also wonder if there are any
remaining unitialized warnings in ipa code?
Honza
>
> Thanks,
> Zdenek
>
>
> Hi,
> In function ref_maybe_used_by_call_p_1, there is below code snippet
> /* The following builtins do not read from memory. */
> case BUILT_IN_FREE:
> ...
>return false;
>
> I am confused because free function does read from (and even write to)
> memory
> Hi,
>
> I would like to use ipa_ref in the PASS_LIST all_late_ipa_passes to query
> the statement (ref->stmt) of where a global variable is used. However, I am
> having some problems achieving this.
>
> What I do is:
>
> 1. Check that ipa_ref->referring has a body and is not inlined.
> 2. get_
Ankur,
> I was browsing the list of submitted GSoC projects this year and the
> project regarding bypassing assembler when generating LTO object files
> caught my eye.
I apologize for late reply. I would be very happy to mentor this
project.
>
> I already have a gcc built from source (sync-ed wit
Hi,
>
>
> > On 08-Apr-2022, at 6:32 PM, Jan Hubicka wrote:
> >
> > Ankur,
> >> I was browsing the list of submitted GSoC projects this year and the
> >> project regarding bypassing assembler when generating LTO object files
> >> caught my ey
Hello,
We are pleased to invite you all to the next GNU Tools Cauldron,
taking place in Paris on September 16-18, 2022. We are looking forward
to meet you again after three years!
As for the previous instances, we have setup a wiki page for
details:
https://gcc.gnu.org/wiki/cauldron2022
> On Sat, May 14, 2022 at 7:03 PM Jan Hubicka via Gcc wrote:
> >
> > Hello,
> >
> > We are pleased to invite you all to the next GNU Tools Cauldron,
> > taking place in Paris on September 16-18, 2022. We are looking forward
> > to meet you again after three
s and developers, would you be
> interested to take on the responsibility of maintaining the
> AutoFDO-specific portions of the code, with guidance and mentorship
> from other GCC maintainers, especially the ones responsible for gcov
> and PDO?
I missed the patches (it would help t
Hello,
> Hello,
>
> We are pleased to invite you all to the next GNU Tools Cauldron,
> taking place in Paris on September 16-18, 2022. We are looking forward
> to meet you again after three years!
>
> As for the previous instances, we have setup a wiki page for
> details:
>
> https://gcc.g
ERS b/MAINTAINERS
> index 18edc86df67..a61d3ae06df 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -230,7 +230,6 @@ docstring relicensing Gerald Pfeifer
>
> docstring relicensingJoseph Myers
>
> predict.def Jan Hubicka
Hello,
> Hi! I've been interested in compiler development for a while, and would love
> to
> work with any of you as part of GSoC, or even just as a side-project on my
> own.
>
> I'm an 18 year-old student going into university next year with a passion for
> all
> things open source and low lev
Hi,
>
> It seems to me that the most correct fix is to add to
> walk_polymorphic_call_targets a check that the obtained possible target
> is still referenced_from_vtable_p() - because the alias that was
> originally a virtual function is referenced from a vtable that at this
> point is also known
Hello,
> While going through the patch and simple-object.c I understood that the
> file simple-object.c is used to handle the object file format. However,
> this file does not contain all the architecture information required for
> LTO object files, so the workaround used in the patch is to read th
ing
implementation. Adding support for other object formats can be done
incrementally.
Honza
>
> On Tue, 4 Apr 2023 at 04:35, Jan Hubicka wrote:
>
> > Hello,
> > > While going through the patch and simple-object.c I understood that the
> > > file simple-o
ld be better too, I think grammar is not critical here.
Thanks a lot for making and submitting the proposal.
Honza
>
> On Tue, 4 Apr 2023 at 15:55, Jan Hubicka wrote:
>
> > Hello,
> > > Thanks, Jan for the Reply! I have completed a draft proposal for this
> > > pr
> Hi Everyone,
Hello,
> I am working on the GSOC project "Bypass Assembler when generating LTO
> object files." My mentors and I have decided to work on the ELF files
> first, so I will add .symtab along with the symbol __gnu_lto_slim to
> the ELF file as a first step.
> When I was going through th
> Hi,
Hi,
I am sorry for late reaction.
> I am working on the GSOC project "Bypass Assembler when generating LTO
> object files." So as a first step, I am adding .symtab along with
> __gnu_lto_slim symbol into it so that at a later stage, it can be
> recognized that this object file has been produc
> > > +simple_object_write_add_symbol(simple_object_write *sobj, const char
> > *name,
> > > +size_t size, unsigned int align);
> >
> > Symbols has much more properties in addition to sizes and alignments.
> > We will eventually need to get dwarf writting, so we will need to
> > support them. Howev
> Hi,
>
> I have added the patch (
> https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623379.html ) on the
> devel/bypass-asm branch.
> Although I am able to build using the --disable-bootstrap option but while
> doing a bootstrapped build, I am getting these errors ( as warnings while
> doing
> > If I comment it out as above patch, then O3/PGO can get 16% and 12%
> > performance
> > improvement compared to O2 on x86.
> >
> > O2 O3 PGO
> > cycles 2,497,674,824 2,104,993,224 2,199,753,593
> > instructions1
> Hi!
>
> On 2023-09-07T19:00:49-0400, James Hu via Gcc wrote:
> > I noticed that adding incremental LTO was a GSoC project that was not
> > claimed this cycle (
> > https://summerofcode.withgoogle.com/programs/2023/organizations/gnu-compiler-collection-gcc).
> > I was curious about working on th
> Hello,
> I am working on a project to produce the LTO object file from the compiler
> directly. So far, we have
> correctly outputted .symtab along with various .debug sections. The only
> thing remaining is to
> correctly output attribute values and their corresponding values in the
> .debug_inf
> Hello,
Hi,
> I have almost completed the output of relocation entries. The only thing
> that remains is to output the corresponding symbols in .symtab. In my
> current design, I store the info about relocation entry and the symbol
> name. However, the problem I am facing with this approach is tha
> On Dez 01 2023, Richard Biener via Gcc wrote:
>
> > Hmm, so why's it then referenced and not "GCed"?
>
> This has nothing to do with garbage collection. It's just the way
> libgcc avoids having too many source files. It would be exactly the
> same if every function were in its own file.
THe
> > The problem is testing. If gcc would re-number the basic blocks then
> > tests comparing hard-coded test paths would break, even though the path
> > coverage itself would be just fine (and presumably the change to the
> > basic block indices), which would add an unreasonable maintenance
> > bur
Hello,
we are pleased to invite you all to the next GNU Tools Cauldron,
taking place in Prague, Czech Republic, on September 14-16, 2024.
As for the previous instances, we have setup a wiki page for
details:
https://gcc.gnu.org/wiki/cauldron2024
Like last year, we are having to charge for
Hello,
we are pleased to invite you all to the next GNU Tools Cauldron,
taking place in Prague, Czech Republic, on September 14-16, 2024.
As for the previous instances, we have setup a wiki page for
details:
https://gcc.gnu.org/wiki/cauldron2024
Like last year, we are having to charge for
> On Sat, Sep 14, 2024 at 1:17 PM Ghorban M. Tavakoly via Gcc
> wrote:
> >
> > >> Is there any change to have some LTO progress indicator information in
> > upstream GCC output? Do I need to report a bug?
> > Is there any chance ... (sorry for typo)
>
> You can add -Q to the command line which ma
> Ping (https://gcc.gnu.org/pipermail/gcc/2024-August/244625.html).
Hi,
> > * Proposed Solution *
> >
> > * Extending IPA-CP:
> >
> > 1. Add return jump function data structures
> > - This involves updating ipa_node_params to contain information
> > regarding the
> > return statements of
601 - 681 of 681 matches
Mail list logo
