On Thu, 26 Dec 2019, Alexandre Oliva wrote:
> On Dec 25, 2019, Alexandre Oliva wrote:
>
> > 3. do not take the executable name into account when it shares the
> > basename with an input file; combine executable basename with input name
> > otherwise. this makes gcc -o foo[.exe] -g -gsplit-dwarf
On Dec 25, 2019, Alexandre Oliva wrote:
> 3. do not take the executable name into account when it shares the
> basename with an input file; combine executable basename with input name
> otherwise. this makes gcc -o foo[.exe] -g -gsplit-dwarf foo.c output
> foo.dwo rather than foo-foo.dwo, which
On Nov 7, 2019, Alexandre Oliva wrote:
> compiling a single source idir/ibase.iext:
> -o odir/obase.oext specified: default -dumpdir odir -dumpbase obase.iext
> -o obase.oext specified: default -dumpbase obase.iext
> -o ibase.oext implied: default -dumpbase ibase.iext
> compiling multipl
On Dec 9, 2019, Richard Biener wrote:
> On Tue, 3 Dec 2019, Alexandre Oliva wrote:
>> I'm considering rejecting command lines that specify both an explicit
>> -dumpdir and -save-temps=cwd, and in the absence of an explicit
>> -dumpdir, arranging for -save-temps=cwd or -save-temps=obj to overrid
On Tue, 3 Dec 2019, Alexandre Oliva wrote:
> On Nov 14, 2019, Alexandre Oliva wrote:
>
> > In order to address this, I propose we add an internal option (not for
> > the driver), -dumpbase-ext, that names the extension to be discarded
> > from dumpbase to form aux output names.
>
> Here's a WIP
On Nov 14, 2019, Alexandre Oliva wrote:
> In order to address this, I propose we add an internal option (not for
> the driver), -dumpbase-ext, that names the extension to be discarded
> from dumpbase to form aux output names.
Here's a WIP patch that implements much of the desired semantics.
I'm
On Wed, 20 Nov 2019, Alexandre Oliva wrote:
> On Nov 6, 2019, Alexandre Oliva wrote:
>
> > (CALLEE_FROM_CGRAPH_P): New.
> > (dump_final_callee_vcg, dump_final_node_vcg): New.
>
> I goofed in the testing of this last-minute change. It only works with
> optimization disabled. With any
On Nov 6, 2019, Alexandre Oliva wrote:
> (CALLEE_FROM_CGRAPH_P): New.
> (dump_final_callee_vcg, dump_final_node_vcg): New.
I goofed in the testing of this last-minute change. It only works with
optimization disabled. With any optimization enabled,
pass_remove_cgraph_callee_edges r
On Nov 15, 2019, Richard Biener wrote:
> Hmm, -dwo-base-name to the rescue? ;)
I'd rather have less rather than more complexity. I.e., make the
objcopy command match the dumpdir location, that defaults to the output
location. The more such options we have, the harder it is to document,
underst
On Fri, 15 Nov 2019, Alexandre Oliva wrote:
> On Nov 14, 2019, Alexandre Oliva wrote:
>
> > %{!c:%{!S:-dumpbase %b}
>
> Uhh, I failed to adjust this one to add the executable output name to
> dumpbase.
>
> Anyway, getting the right semantics out of specs is providing to be a
> lot trickier tha
On Nov 14, 2019, Alexandre Oliva wrote:
> %{!c:%{!S:-dumpbase %b}
Uhh, I failed to adjust this one to add the executable output name to
dumpbase.
Anyway, getting the right semantics out of specs is providing to be a
lot trickier than I had anticipated. I'm now pondering a single spec
function
On Nov 8, 2019, Eric Gallager wrote:
> If you're touching the -auxbase option... is that related to the other
> options starting with -aux at all?
'fraid they're entirely unrelated. We're talking about how the compiler
names aux and dump output files, which is not related with the contents
of
On Nov 8, 2019, Richard Biener wrote:
> Wow, thanks for the elaborate write-up! I wonder if we can
> cut&paste this into documentation somewhere appropriate, maybe
> there's already a section for "auxiliary compiler outputs".
Sure, that makes sense.
>> I'm a little hesitant, this amounts to q
On 11/8/19, Richard Biener wrote:
> On Thu, 7 Nov 2019, Alexandre Oliva wrote:
>
>> On Nov 7, 2019, Richard Biener wrote:
>>
>> > (also raises the question why we have both -dumpbase and -auxbase ...)
>>
>> https://gcc.gnu.org/ml/gcc-patches/2002-08/msg00294.html
>>
>> This was before -dumpdir,
On Thu, 7 Nov 2019, Alexandre Oliva wrote:
> On Nov 7, 2019, Richard Biener wrote:
>
> > (also raises the question why we have both -dumpbase and -auxbase ...)
>
> https://gcc.gnu.org/ml/gcc-patches/2002-08/msg00294.html
>
> This was before -dumpdir, however.
>
> Here's the current logic for
On Nov 7, 2019, Richard Biener wrote:
> (also raises the question why we have both -dumpbase and -auxbase ...)
https://gcc.gnu.org/ml/gcc-patches/2002-08/msg00294.html
This was before -dumpdir, however.
Here's the current logic for aux_base_name:
-c or -S with -o [odir/]obase.oext: [odir/]ob
On Thu, 7 Nov 2019, Alexandre Oliva wrote:
> On Nov 7, 2019, Richard Biener wrote:
>
> > So how's -dumpbase handled?
>
> It's part of the gcc driver interface, and lto-wrapper passes it to gcc
> for -fltrans compilations. -auxbase isn't, so one of the alternatives I
> suggested involved our t
On Nov 7, 2019, Richard Biener wrote:
> So how's -dumpbase handled?
It's part of the gcc driver interface, and lto-wrapper passes it to gcc
for -fltrans compilations. -auxbase isn't, so one of the alternatives I
suggested involved our taking auxbase from dumpdir & dumpbase for
-fltrans compila
On Thu, 7 Nov 2019, Alexandre Oliva wrote:
> On Nov 7, 2019, Richard Biener wrote:
>
> > A simple test shows we currently only pass -auxbase-strip /tmp/cc...o
> > to the LTRANS lto1 invocation plus -dumpbase cc...o
>
> This -auxbase-strip argument is introduced by the gcc driver that runs
> lt
On Nov 6, 2019, Thomas Schwinge wrote:
>> which is a valid VCG file (you can launch your favorite VCG
>> viewer on it unmodified)
> What should be my "favorite VCG viewer"?
-ENOCLUE, I'm afraid. I honestly don't even know which one Eric used
back when he first attempted to contribute this fea
On Nov 7, 2019, Richard Biener wrote:
> A simple test shows we currently only pass -auxbase-strip /tmp/cc...o
> to the LTRANS lto1 invocation plus -dumpbase cc...o
This -auxbase-strip argument is introduced by the gcc driver that runs
lto1, based on the -o (tmp ltrans .o) argument, but this dri
On Wed, 6 Nov 2019, Alexandre Oliva wrote:
> On Nov 4, 2019, Richard Biener wrote:
>
> > I wonder why we shouldn't simply adjust aux_base_name to something
> > else for -flto [in the driver].
>
> About that, having tried to make sense of the current uses of
> aux_base_name and of lto-wrapper,
Hi Alexandre!
On 2019-10-26T01:35:43-0300, Alexandre Oliva wrote:
> This was first submitted many years ago
> https://gcc.gnu.org/ml/gcc-patches/2010-10/msg02468.html
>
> The command line option -fcallgraph-info is added and makes the
> compiler generate another output file (xxx.ci) for each comp
On Nov 4, 2019, Richard Biener wrote:
> I wonder why we shouldn't simply adjust aux_base_name to something
> else for -flto [in the driver].
About that, having tried to make sense of the current uses of
aux_base_name and of lto-wrapper, three main possibilities occur to me:
a) adjust the drive
be picked up. Thanks!
introduce -fcallgraph-info option
This was first submitted many years ago
https://gcc.gnu.org/ml/gcc-patches/2010-10/msg02468.html
The command line option -fcallgraph-info is added and makes the
compiler generate another output file (xxx.ci) for each compilation
unit (or LTO par
des for externals, accidentally
> dropped in the transition to incremental generation of the .ci file.
>
> Regstrapped on x86_64-linux-gnu. Ok to install?
OK for the rest.
Thanks,
Richard.
>
> introduce -fcallgraph-info option
>
> This was first submitted many years ago
>
d in the transition to incremental generation of the .ci file.
Regstrapped on x86_64-linux-gnu. Ok to install?
introduce -fcallgraph-info option
This was first submitted many years ago
https://gcc.gnu.org/ml/gcc-patches/2010-10/msg02468.html
The command line option -fcallgraph-info is added
On Wed, 30 Oct 2019, Alexandre Oliva wrote:
> On Oct 28, 2019, Joseph Myers wrote:
>
> > We have a test in the testsuite that all option help text consistently
> > ends with '.' (see gcc.misc-tests/help.exp). I'd have expected these
> > options, lacking that '.', to cause that test to fail.
>
On Wed, 30 Oct 2019, Alexandre Oliva wrote:
> On Oct 28, 2019, Richard Biener wrote:
>
> > I guess you need to elaborate on 'per-file'. With LTO as far as I
> > understand you'll get the graph per LTRANS unit (did you check
> > where the output is generated?).
>
> Yeah, I guess this was not de
On Oct 28, 2019, Richard Biener wrote:
> I guess you need to elaborate on 'per-file'. With LTO as far as I
> understand you'll get the graph per LTRANS unit (did you check
> where the output is generated?).
Yeah, I guess this was not designed with LTO in mind; it probably even
predates LTO. We
On Oct 28, 2019, Joseph Myers wrote:
> We have a test in the testsuite that all option help text consistently
> ends with '.' (see gcc.misc-tests/help.exp). I'd have expected these
> options, lacking that '.', to cause that test to fail.
Here's the patch. Tested on x86_64-linux-gnu. Ok to i
On Oct 28, 2019, Joseph Myers wrote:
> We have a test in the testsuite that all option help text consistently
> ends with '.' (see gcc.misc-tests/help.exp). I'd have expected these
> options, lacking that '.', to cause that test to fail.
Thanks. I've fixed the common.opt changes, and I'll su
On Sat, 26 Oct 2019, Alexandre Oliva wrote:
> Regstrapped on x86_64-linux-gnu. Ok to install?
I have only a peripheral comment:
> diff --git a/gcc/common.opt b/gcc/common.opt
> index cc279f411d796..63d646fba2b42 100644
> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -1091,6 +1091,14 @@ fbtr-
On Sun, 27 Oct 2019, Alexandre Oliva wrote:
> On Oct 26, 2019, Alexandre Oliva wrote:
>
> > E.g., the reason we gather expanded calls rather than just use
> > cgraph_edges is that the latter would dump several "calls" that are
> > builtins expanded internally by the compiler, and would NOT dump
On Oct 26, 2019, Alexandre Oliva wrote:
> E.g., the reason we gather expanded calls rather than just use
> cgraph_edges is that the latter would dump several "calls" that are
> builtins expanded internally by the compiler, and would NOT dump other
> ops that are expanded as (lib)calls.
It occurr
Hi, Richi,
On Oct 26, 2019, Richard Biener wrote:
> How does it relate to the LTO-dump utility we have now which can in
> theory provide a more complete view?
Erhm... Not at all, AFAICT. The only vague resemblance I see is in the
presence of the word "callgraph" in the description of what bot
On October 26, 2019 6:35:43 AM GMT+02:00, Alexandre Oliva
wrote:
>This was first submitted many years ago
>https://gcc.gnu.org/ml/gcc-patches/2010-10/msg02468.html
>
>The command line option -fcallgraph-info is added and makes the
>compiler generate another output file (xxx.ci) for each compilati
This was first submitted many years ago
https://gcc.gnu.org/ml/gcc-patches/2010-10/msg02468.html
The command line option -fcallgraph-info is added and makes the
compiler generate another output file (xxx.ci) for each compilation
unit, which is a valid VCG file (you can launch your favorite VCG
vie
38 matches
Mail list logo
