public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Jason Merrill <jason@redhat.com>
Cc: "Joseph S. Myers" <joseph@codesourcery.com>,
	       Richard Henderson <rth@redhat.com>,
	Tom Tromey <tromey@redhat.com>,
	       Jan Kratochvil <jkratoch@redhat.com>,
	gcc-patches@gcc.gnu.org,
	       Roland McGrath <roland@redhat.com>
Subject: Re: [RFC PATCH] -grecord-gcc-switches (PR other/32998)
Date: Wed, 13 Jul 2011 14:34:00 -0000	[thread overview]
Message-ID: <20110713140642.GW2687@tyan-ft48-01.lab.bos.redhat.com> (raw)
In-Reply-To: <4E1DA42A.3040403@redhat.com>

On Wed, Jul 13, 2011 at 09:56:58AM -0400, Jason Merrill wrote:
> On 07/12/2011 07:46 PM, Jakub Jelinek wrote:
> >The aim is to include just (or primarily) code generation affecting options
> >explicitly passed on the command line.  So that the merging actually works,
> >options or arguments which include filenames or paths shouldn't be added,
> >on Roland's request -D*/-U* options aren't added either (that should be
> >covered by .debug_macinfo)
> 
> ...but only with -g3.

Sure.  But if we put -D*/-U* into DW_AT_producer, -D_FORTIFY_SOURCE=2
on the command line acts the same as #define _FORTIFY_SOURCE 2
before including the first header and the latter wouldn't be recorded.
I'm working on smaller .debug_macinfo right now.

> >Ideally we'd just include explicitly passed options from command line that
> >haven't been overridden by other command line options, and would sort them,
> >so that there are higher chances of DW_AT_producer strings being merged
> >(e.g. -O2 -ffast-math vs. -ffast-math -O2 are now different strings, and
> >similarly -O2 vs. -O3 -O2 vs. -O0 -O1 -Ofast -O2), but I'm not sure if it is
> >easily possible using current option handling framework.
> 
> Why not?  Sorting sounds pretty straightforward to me, though you
> might want to copy the array first.

If the command line options contain options that override each other, then
sorting would drop important information what comes last and thus overrides
other options.  If we would have only options which weren't overridden,
we could sort.  Otherwise -O2 -O0 would be sorted as -O0 -O2 and we'd think
the code was optimized when it wasn't.

> On the other hand, it probably isn't worthwhile; presumably most
> relocatables being linked together will share the same CFLAGS, so
> you'll get a high degree of merging without any sorting.
> 
> >--- gcc/testsuite/lib/dg-pch.exp.jj	2011-01-03 18:58:03.000000000 +0100
> >+++ gcc/testsuite/lib/dg-pch.exp	2011-07-12 23:13:50.943670171 +0200
> >-	dg-test -keep-output "./$bname$suffix" "$otherflags $flags" ""
> >+	dg-test -keep-output "./$bname$suffix" "-gno-record-gcc-switches $otherflags $flags" ""
> 
> Why is this necessary?

It is only necessary if somebody wants to make -grecord-gcc-switches
the default (for bootstrap/regtest I've tweaked common.opt to do that
to test it better).  PCH is a big mess and screws debuginfo in many ways,
in this case it was just small differences in DW_AT_producer, but
we have e.g. ICEs with PCH and -feliminate-dwarf-dups etc.

	Jakub

  reply	other threads:[~2011-07-13 14:07 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-13  0:17 Jakub Jelinek
2011-07-13 14:04 ` Jason Merrill
2011-07-13 14:34   ` Jakub Jelinek [this message]
2011-07-13 14:35     ` Jason Merrill
2011-07-14  9:48       ` Jakub Jelinek
2011-07-14 16:31         ` Jason Merrill
2011-07-14 16:32           ` Jakub Jelinek
2011-07-14 16:40             ` Jason Merrill
2011-07-21 20:22 ` Joseph S. Myers
2011-07-21 20:50   ` Jakub Jelinek
2011-07-21 21:01     ` Joseph S. Myers
2011-07-22 13:27       ` [PATCH] -grecord-gcc-switches (PR other/32998, take 2) Jakub Jelinek
2011-07-22 14:06         ` Joseph S. Myers
2011-07-22 14:11           ` [PATCH] -grecord-gcc-switches (PR other/32998, take 3) Jakub Jelinek
2011-07-22 20:43             ` Jason Merrill

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110713140642.GW2687@tyan-ft48-01.lab.bos.redhat.com \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    --cc=jkratoch@redhat.com \
    --cc=joseph@codesourcery.com \
    --cc=roland@redhat.com \
    --cc=rth@redhat.com \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).