This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Add option for dumping to stderr (issue6190057)
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- Cc: Michael Meissner <meissner at linux dot vnet dot ibm dot com>, Sharad Singhai <singhai at google dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, Xinliang David Li <davidxl at google dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Andrew Pinski <pinskia at gmail dot com>
- Date: Tue, 2 Oct 2012 11:31:37 +0200
- Subject: Re: [PATCH] Add option for dumping to stderr (issue6190057)
- References: <CAAkRFZ+x+Q6E_6DL8w8JyvHZqGVCxiSc8NDRumc9EhUi1vp++Q@mail.gmail.com> <CAKxPW656sVbeVewS6dZL_d7X+02be16JRZ-4mrXkRLzwyuUxkw@mail.gmail.com> <CAFiYyc3AJ1C92QhZHTk83rZPgLSqwk+=qgYDeY9HG-p4UPRrMA@mail.gmail.com> <CAAkRFZJKbNwtA6cJ+sSn5gm1fdX8cr1yoOZz8RFwQd+5aRU!QyQ@mail.gmail.com> <CAFiYyc0Q+JdNc3piYNsZvPBkK3GHWbibysn3dRe0=P_Fc6JYVw@mail.gmail.com> <CAAkRFZLQjn_QtG6F7ecyjvgjT1yZUaoihseEDzWR2fHcbJ8fkQ@mail.gmail.com> <CAKxPW65+e7jdfo+OphVb2i7SoUOO2_h64oki+qgRn2a=WtFRtw@mail.gmail.com> <CAFiYyc0GgvUx1qh72hrp91CaumVd--kAx7r_fBD9HxrcuM7RMw@mail.gmail.com> <CAKxPW650-x8oOuctZAzOZckw+aphwUTCg-E+svY5oJ369zYSew@mail.gmail.com> <20121001180226.GA21396@ibm-tiger.the-meissners.org> <20121001182723.GA3888@ibm-tiger.the-meissners.org> <CAAiZkiAOLx8NwX_Yrso4DWuk4WnKCjvwToyEMtA8_GMVYHUKTA@mail.gmail.com>
On Mon, Oct 1, 2012 at 8:39 PM, Gabriel Dos Reis
<gdr@integrable-solutions.net> wrote:
> On Mon, Oct 1, 2012 at 1:27 PM, Michael Meissner
> <meissner@linux.vnet.ibm.com> wrote:
>> On Mon, Oct 01, 2012 at 02:02:26PM -0400, Michael Meissner wrote:
>>> Your change on September 30th, breaks the powerpc port because the
>>> REPORT_DETAILS value in the enumeration is no longer there, and the
>>> rs6000_density_test function was using that. Please in the future, when you
>>> are making global changes, grep for uses of enum values in all of the machine
>>> dependent directories so we can avoid breakage like this.
>>
>> Also, in looking at the changes, given we are already up to 28 TDF_ flags, I
>> would recommend immediately adding a new type that is the TDF flagword type.
>> Thus it will be a lot simpler when we add 4 more TDF flags and have to change
>> the type from int to HOST_WIDE_INT.
>
> Agreed that we need an abstraction here.
Some TLC as well - the flags have various meanings (some control dumping,
some, like TDF_TREE, seem to be unrelated - the MSG ones probably don't
need the same number-space as well, not all flags are used anymore -
TDF_MEMSYMS?).
But yes, an abstraction is needed. But I wouldn't suggest HOST_WIDE_INT
but int -> uint32_t instead (possibly going uint64_t).
Richard.
> -- Gaby