Re: [c++] Remove redundant inline check
On 4/18/2011 11:47 AM, Jan Hubicka wrote: > Bootstrapped/regtested x86_64-linux, OK? > > * cp/semantics.c (finish_goto_stmt): Do set UNINLINABLE flag on computed > gotos. Provided that we have this check elsewhere in the compiler and are therefore confident we won't accidentally inline such things, this is fine. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
PATCH: Remove README.QMTEST
It was recently pointed out to me that we still have the README.QMTEST file in gcc/testsuite. That file talks about how to use QMTest instead of DejaGNU to test G++ -- but the information there is just not accurate anymore. Various things have bit-rotted since the point at which that was written. Given that nobody is actively working on making this work, it's best just to remove the file. Applied. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713 2011-03-06 Mark Mitchell * README.QMTEST: Remove. [actual diff elided for brevity]
Re: PATCH: Remove README.QMTEST
On 3/6/2011 2:57 PM, Mike Stump wrote: >> It was recently pointed out to me that we still have the >> README.QMTEST file in gcc/testsuite. That file talks about how to >> use QMTest instead of DejaGNU to test G++ > If you were to summarize the 3 most compelling features provided, I'd > be interested. I'm thinking it was parallel testing... That's one. A couple of others: (a) QMTest is a structured system, i.e., you can enumerate all of the tests and ask questions about them. In contrast, with DejaGNU, you can only figure out what tests you have by running them -- we depend on executable .exp files to enumerate tests, not declarative information. For example, try asking DejaGNU "how many tests do I have?", or "how many tests do I have for Solaris targets that aren't applicable to Linux targets?" (b) QMTest has a facility for saving results in structured formats (rather than text-based .log/.sum files) so that they can be processed or queried later. One immediate use of this is that you can compare results today with results yesterday in ways more structured that "diff". Thank you, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: PR debug/47510
On 3/16/2011 1:04 PM, Dodji Seketeli wrote: > Would the RMs (in CC) object to this patch going into 4.6? What would be the justification for that? The bar is pretty high on putting a patch onto a release branch. I don't see any evidence that this is a regression, and a bug that affects debugging is never *that* serious compared to (for example) silent wrong-code generation. In this case, we're dealing with anonymous structs, which aren't very common. This just seems like a run-of-the-mill bug to me. Thank you, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: PR debug/47510
On 3/17/2011 4:08 AM, Dodji Seketeli wrote: > Yesterday after discussing this on IRC, Jakub expressed his personal > opinion by saying the patch could go in 4.6. I mistakenly took it as a > formal approval from the RMs and I committed it. I should have waited > for an approval by email. You don't have to apologize -- an approval from any RM, in any forum (IRC, email, etc.) is sufficient authorization. > It's a regression from 4.5, caused by the fix for PR c++/44188. And, in any case, if it's a regression it's OK with me. Thank you, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Make C1X anonymous structs/unions follow N1549
On 3/18/2011 2:52 PM, Jakub Jelinek wrote: >> This week's London WG14 meeting agreed to disallow the use of typedefs >> in declaring anonymous structure and union fields, as per N1549. This >> patch implements this, restricting the use of typedefs in this case to >> -fms-extensions and -fplan9-extensions as in 4.5 and earlier releases. > I guess it is ok for 4.6.0 too. I think avoiding the ping-pong in behavior between 4.5 and 4.7 is a good call. So, I think the patch is OK for 4.6. Thank you, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: [PATCH, 4.7] PR 48192, Make conditional macros not defined for #ifdef
On 3/18/2011 4:26 PM, Michael Meissner wrote: > This patch makes conditional macros that are used in the PowerPC and SPU ports > not be 'defined' for the #ifdef, #ifndef, and #if defined(...) tests. I think that's a desirable change, from a language semantics point of view, but I would defer to Joseph on this issue; he has a much more comprehensive understanding of the C preprocessing rules than I do. > I would like to backport this to 4.6, 4.5 and maybe 4.4. Are there objections > to backporting it? I have no objection to a backport. Thank you, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
