Re: GCC 4.3.0 Status Report (2007-09-04)
DJ Delorie wrote: Also, we never decided if undo was worth the extra overhead. The code is in the patch, but ifdef'd out. URL, please? http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01317.html It looks to me like this probably isn't quite ready for prime-time; I do think we'd want to make the push/pop stuff fully reliable, including warnings emitted from the middle-end. That's not an over-my-dead-body; if other people feel differently, I'm happy to discuss. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GCC 4.2.2 Status Report
Summary === The GCC 4.2.1 release was July 18, so our target for a 4.2.2 release is September 18th. I plan to build RC1 this Sunday, September 9. If all goes well, we'll have 4.2.2 out around the 18th; if not, we'll delay a bit from there. One critical issue: has GCC 4.2.x been fully converted to GPLv3, at this point? If not, we'll have to wait until that is done before we can release, per the FSF's instructions. Quality === Here are the open regressions: Priority # --- P1 26 P2108 P3 3 Total 137 Many of the P1s are ICEs, so at least users know the compiler is broken... We still have the nasty aliasing problems: PR32182 [4.2 Regression] -fstrict-aliasing optimizations cause co... PR32328 [4.2 Regression] -fstrict-aliasing causes skipped code and various other such problems. We also have: PR32327 [4.2 Regression] Incorrect stack sharing causing removal ... though Diego's last comment seems to indicate that's something of a could-happen bug at the moment. In short, I don't see anything here that would prevent a release, though, of course, I'd certainly be happier to get the number of regressions (and, particularly, P1 regressions) down. Previous Report === http://gcc.gnu.org/ml/gcc/2007-07/msg00704.html -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GCC 4.3.0 Status Report (2007-09-04)
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? Are there Stage 1 or Stage 2 patches in need of review? I'll do my best to either (a) convince someone to review them, or (b) review them myself. Quality === Priority # --- P1 43 P2118 P3 4 Total 165 Obviously, that's rather more P1s than we'd like. As I mentioned in my previous status report, of particular concern is that we've got a lot of 4.3-only P1s. I'm sure many of those won't be too hard to fix, but we still need to go and fix them. I'm concerned about getting into a situation where we say well, 4.2 has some bugs, but all of those are fixed in 4.3 and then realize that oh, well, 4.3 has different bugs too, but those are all fixed in 4.4 and so forth. Previous Report === http://gcc.gnu.org/ml/gcc/2007-08/msg00181.html -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-09-04)
DJ Delorie wrote: Mark Mitchell [EMAIL PROTECTED] writes: Are there Stage 1 or Stage 2 patches in need of review? Do you want the diagnostic pragma push/pop patch in? In, if it works. :-) URL, please? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: RFC: Hack to make restrict more useful
Joseph S. Myers wrote: The rules that unmodified memory may alias were a deliberate change in the FDIS relative to the previous public draft; see http://www.open-std.org/jtc1/sc22/wg14/www/docs/n866.htm: That explains why I had no memory of this, despite having researched restrict pretty carefully in earlier drafts. That also explains why other compilers in the field implements restrict as meaning does not alias, independent of what's modified. Danny, does your more comprehensive treatment of restrict still optimize test cases like the one in the PR I filed? In any case, I guess we should consider my patch withdrawn. Although, if the new meaning of restrict matches standard Fortran semantics, then our Fortran handling must be wrong, since all my patch did was make us match our current Fortran semantics. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: RFC: Hack to make restrict more useful
Daniel Berlin wrote: Again, I'd love to just ignore this and say we don't care. Ugh. I think you're right that the standard says that we only get to assume non-aliasing when the pointed-to memory is modified, so all-parameters-restrict is actually weaker than -fargument-noalias. How unfortunate. I've CC'd Joseph in the hopes that his C standards knowledge will suggest a different answer. But we should not do it by saying oh, well, this could never effect anything. It could. You can come up with transformations that break, and they all involve the compiler claiming a and b can't alias when they can. Indeed. The most obvious example is: return a != b; If the compiler knows the pointers don't alias, the compiler will happily, but wrongly, fold that to 1. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: RFC: Hack to make restrict more useful
Richard Guenther wrote: I have a prototype hack which changes checks of flag_argument_noalias != 0 to also check for the presence of restrict on all pointer arguments. This fixes the test case, modulo a C front-end bug which Joseph has volunteered to fix. AFAIK Danny had been fixing restrict on his working agenda lately. No idea what the status on that is, though. I fully concede that my trick isn't a general solution to making full use of restrict. But, given that I think it'll take about 20-50 lines of code, and that it will get a lot of the common cases, I think it's worth it. Do you agree? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: RFC: Hack to make restrict more useful
Richard Guenther wrote:
I fully concede that my trick isn't a general solution to making full
use of restrict. But, given that I think it'll take about 20-50 lines
of code, and that it will get a lot of the common cases, I think it's
worth it. Do you agree?
Yes, I agree. I just was curious on the status of Dannys work and if it
would obsolete what you propose.
OK, great. Here's a draft patch for the trick; this works on the test
case I had, and I'll be testing it now. If it passes testing, and I add
testcases, does this look OK to you?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
2007-09-01 Mark Mitchell [EMAIL PROTECTED]
* function.h (struct function): Add argument_noalias.
* alias.h (argument_noalias): Declare it.
* alias.c (argument_noalias): New function.
(base_alias_check): Use it.
* tree-ssa-structalias.c (intra_create_variable_infos): Use
argument_noalias.
Index: function.h
===
--- function.h (revision 127950)
+++ function.h (working copy)
@@ -473,6 +473,12 @@ struct function GTY(())
function has been gimplified, so we can make sure we're not
creating non GIMPLE tuples after gimplification. */
unsigned gimplified : 1;
+
+ /* 0 if we have not yet determined whether arguments to this
+ function might alias each other. 1 if we have determined they
+ may alias each other. 2 if we have determined they cannot alias
+ each other. */
+ unsigned argument_noalias : 2;
};
/* If va_list_[gf]pr_size is set to this, it means we don't know how
Index: alias.c
===
--- alias.c (revision 127950)
+++ alias.c (working copy)
@@ -1452,6 +1452,56 @@ find_base_term (rtx x)
}
}
+/* Returns an integer indicating to what extent arguments to the
+ current function may alias one-another or global variables. In
+ particular, the return value is:
+
+ 0 if pointer arguments may alias each other.
+ 1 if pointer arguments may not alias each other but may alias
+ global variables.
+ 2 if pointer arguments may not alias each other and may not
+ alias global variables.
+ 3 if pointer arguments may not alias anything.
+
+ Unlike FLAG_ARGUMENT_NOALIAS, the value returned may differ
+ depending on the function presently being processed. */
+
+int
+argument_noalias (void)
+{
+ tree t;
+
+ /* If FLAG_ARGUMENT_NOALIAS tells us that arguments cannot alias, we
+ do not have to try to prove that ourselves. And, if we're
+ outside of a function, there's nothing we can prove. */
+ if (flag_argument_noalias || !cfun)
+return flag_argument_noalias;
+
+ /* If we have not already determined whether this function's
+ arguments can alias each other, figure that out now. */
+ if (!cfun-argument_noalias)
+{
+ /* If all the arguments to the current function are pointers with
+the restrict qualifier, then none of them can point to one
+another. Assume that's the case. */
+ cfun-argument_noalias = 2;
+ for (t = DECL_ARGUMENTS (current_function_decl); t; t = TREE_CHAIN (t))
+ {
+ tree type = TREE_TYPE (t);
+ /* If we find a pointer argument that does not have the
+restrict qualifier, then some of the arguments to this
+function might alias other arguments. */
+ if (POINTER_TYPE_P (type) !TYPE_RESTRICT (type))
+ {
+ cfun-argument_noalias = 1;
+ break;
+ }
+ }
+}
+
+ return cfun-argument_noalias - 1;
+}
+
/* Return 0 if the addresses X and Y are known to point to different
objects, 1 if they might be pointers to the same object. */
@@ -1461,6 +1511,7 @@ base_alias_check (rtx x, rtx y, enum mac
{
rtx x_base = find_base_term (x);
rtx y_base = find_base_term (y);
+ int noalias;
/* If the address itself has no known base see if a known equivalent
value has one. If either address still has no known base, nothing
@@ -1521,10 +1572,11 @@ base_alias_check (rtx x, rtx y, enum mac
|| (GET_CODE (y_base) == ADDRESS GET_MODE (y_base) == Pmode))
return 0;
- if (! flag_argument_noalias)
+ noalias = argument_noalias ();
+ if (! noalias)
return 1;
- if (flag_argument_noalias 1)
+ if (noalias 1)
return 0;
/* Weak noalias assertion (arguments are distinct, but may match globals).
*/
Index: alias.h
===
--- alias.h (revision 127950)
+++ alias.h (working copy)
@@ -28,6 +28,7 @@ extern alias_set_type get_varargs_alias_
extern alias_set_type get_frame_alias_set (void);
extern bool component_uses_parent_alias_set (const_tree);
extern bool alias_set_subset_of (alias_set_type, alias_set_type);
+extern int argument_noalias (void);
/* This alias set can be used to force
Re: RFC: Hack to make restrict more useful
Richard Guenther wrote:
OK, great. Here's a draft patch for the trick; this works on the test
case I had, and I'll be testing it now. If it passes testing, and I add
testcases, does this look OK to you?
Thanks for the speedy and accurate review!
+ bool noalias;
it's an int.
Doh, fixed.
+ /* For each incoming pointer argument arg, ARG = ESCAPED_VARS or a
+ dummy variable if flag_argument_noalias 2. */
What's this comment for?
Brain leakage. I cut-and-paste that from an older version; sorry, will
remove.
+ if (POINTER_TYPE_P (TREE_TYPE (t)) noalias)
noalias 0 I suppose.
If you like. (Since noalias is never negative, this is logically
equivalent.) I've made the change.
{
varinfo_t vi;
tree heapvar = heapvar_lookup (t);
@@ -4579,7 +4583,7 @@ intra_create_variable_infos (void)
heapvar_insert (t, heapvar);
ann = get_var_ann (heapvar);
- if (flag_argument_noalias == 1)
+ if (flag_argument_noalias = 1)
ann-noalias_state = NO_ALIAS;
else if (flag_argument_noalias == 2)
ann-noalias_state = NO_ALIAS_GLOBAL;
That looks wrong. Shouldn't this just replace flag_argument_noalias
for noalias everywhere?
Either will work, but you're right; using noalias is clearer. (In an
earlier version I'd not organized things in the same way, so that
wouldn't have worked.) I'll make those changes too.
As you suggest, I'll finish up testing and wait for Danny's comments.
Thanks!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
RFC: Hack to make restrict more useful
This bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33272 is about a situation in which -fargument-noalias works better than putting restrict on all pointer arguments to a function, even though that should be logically equivalent. Using restrict for all arguments to a function is probably one of the most common cases of restrict; that's what you want for things like the test case I posted, and for other Fortran-ish code. I have a prototype hack which changes checks of flag_argument_noalias != 0 to also check for the presence of restrict on all pointer arguments. This fixes the test case, modulo a C front-end bug which Joseph has volunteered to fix. To make that a real patch, here's what I plan to do: (1) Add a flag to struct function to say all pointer arguments are restrict. (2) Lazily set it, when something wants to check it. (3) Change checks of flag_argument_noalias to call a function argument_noalias() which will return an int with the same meaning as flag_argument_noalias. Does that plan sound OK to folks? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Stage 2 project: new interference graph representation.
Peter Bergner wrote: As a somewhat related follow on to Kenny's new interference graph builder patch (which is still waiting for a full review): http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01729.html I'd like to squeeze in a new representation of the interference graph that in some cases can save a significant amount of memory. That sounds exciting. If you can get it done, and the middle-end maintainers feel confident in the code, it's fine by me. Thanks for the heads-up! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Stage 2 project: upgrade decNumber
Janis Johnson wrote: But it looks like libdecnumber is processed in stage 1. What if the stage 1 compiler doesn't handle C++ comments? Right, decNumber is used in the C compiler and it's the C++ comments that convinced me of the need to modify the sources. While I'm at it I might as well get rid of CRLF (col does that nicely), and after that it's no more work to run it through indent so it will look like our other code. I think it's fine to put this upgrade in, assuming all the usual testing. FWIW, keeping this as much like the upstream sources as possible seems desirable to me; I'd probably do the C++ comments and leave it at that, just to ease future merges. But, that's just my two cents. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: PING SC members [was RE: RFA: GCC 4.2.1: Stabalizing coalesce_list's qsort]
Dave Korn wrote: On 23 August 2007 22:34, Mark Mitchell wrote: I do think that generating the same code, independent of host system, is a very important property of GCC's design, just like generating the same code independent of whether or not we're compiling with -g. Hear, hear. I've always thought these principles were meant to be sacrosanct, but now I try to look it up, I don't see them explicitly listed in either the development methodology, the release criteria, or anywhere else likely-looking. Can the SC please consider adding these requirements explicitly to the list of Design and Development Goals in the mission statement? Or would it make more sense as part of the development methodology, or the portability section of the gcc-specific coding conventions? I don't think this needs to be part of the mission statement; it's more of a technical nitty-gritty than that. But, I think putting into the coding conventions is a good idea. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: recent troubles with float vectors bitwise ops
Paul Brook wrote:
On Friday 24 August 2007, Ian Lance Taylor wrote:
Paolo Bonzini [EMAIL PROTECTED] writes:
1) neg, abs and copysign operations on vectors. These we can make
available via builtins (for - of course you don't need it); we already
support them in many back-ends.
Here is my point of view. People using the vector extensions are
already writing inherently machine specific code, and they are
(ideally) familiar with the instruction set of their processor.
By the same argument, If you're already writing machine specific code then
there shouldn't be a problem using machine specific intrinsics. I admit I've
never been convinced that the generic vector support was sufficient to write
useful code without resorting to machine specific intrinsics.
Our VSIPL++ team is using it for some things. My guess is that it's
probably not sufficient for all things, but probably is sufficient for
many things. Also, I expect some users get (say) a 4x speedup over C
code easily by using the vector extension, and could get an 8x speedup
by using intrinsics, but with a lot more work. So, the vector
extensions give them a sweet spot on the performance/effort/portability
curve.
I'm partly worried about cross-platform compatibility, and what this imples
for other SIMD targets.
Yes. Here's a proposed definition:
Let a and b be floating-point operands of type F, where F is a
floating-point type. Let N be the number of bytes in F. Then, a | b
is defined as:
({ union fi { F f; char bytes[N]; };
union fi au;
union fi bu;
au.f = a;
bu.f = b;
for (i = 0; i N; ++i)
au.bytes[i] |= bu.bytes[i];
au.f; })
If the resulting floating-point value is denormal, NaN, etc., whether or
not exceptions are raised is unspecified.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: recent troubles with float vectors bitwise ops
Andrew Pinski wrote: On 8/24/07, Mark Mitchell [EMAIL PROTECTED] wrote: Let a and b be floating-point operands of type F, where F is a floating-point type. Let N be the number of bytes in F. Then, a | b is defined as: Yes that makes sense, not. I'm not following. Are you agreeing or disagreeing? Since most of the time, you have a mask and that is what is being used. Like masking the the sign bit or doing a selection. The mask is most likely a NaN anyways so having that undefined just does not make sense. I'm not following. What I meant was that if the result was a NaN, whether or not floating-point exceptions were signalled was unspecified. Where does undefined come into it, and what does that have to do with the mask? If we think that no hardware will ever signal an exception in this case, then we can say that the operation never signals an exception. But, I was afraid that might be too strong a constraint. So is this going to be on scalars? If not, then we should still not accept it on vectors. Yes, from a language-design point of view, it should be for both scalars and vectors, so I wrote the strawman definition in terms of scalars. Of course, if where it's actually useful is vectors, then implementing it for vectors is the important case, and whether or not we get around to doing it on scalars is secondary. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: recent troubles with float vectors bitwise ops
Paul Brook wrote: I probably wasn't clear: My main concern is that if we do support this extension the internals should be implemented and documented in such a way that target maintainers (i.e. me) can figure out how to make it work on their favourite target. We should not just quietly flip some bit in the x86 backend. Totally agreed. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: recent troubles with float vectors bitwise ops
Paolo Bonzini wrote: Why did Intel split up these instructions in the first place, is it because they wanted to have a seperate vector units in some cases? I don't know and I don't care that much. To some extent I agree with Andrew Pinski here. Saying that you need support in a generic vector extension for vector float | vector float in order to generate ANDPS and not PXOR, is just wrong. That should be done by the back-end. Rather than accusing Intel of bad ISA design and the GCC maintainers of Altivec prejudice, let's just figure out what to do. We all agree that: (1) On Intel CPUs, it's more efficient to use the floating-point bitwise instructions (2) In C, you can't do a bitwise-or on two floating-point types So, we have two questions: (1) Should GCC's vector extensions permit floating-point bitwise operations? (2) If not, how can a user can get efficient code? Let's assume that the recent change is what we want, i.e., that the answer to (1) is No, these operations should not be part of the vector extensions because they are not valid scalar extensions. So, that means we need to answer (2). One option is for the user to use intrinsics. It's been claimed that results in worse code. There doesn't seem any obvious reason for that, but, if true, we should try to fix it; we don't want to penalize people who are using the intrinsics. So, let's assume using intrinsics is just as efficient, either because it already is, or because we make it so. We still have the problem that users now can't write machine-independent code to do this operation. Assuming the operations are useful for something (and, if it weren't, why would Intel want to have instructions for it, and why would tbp want to use it?), it seems unfortunate to restrict the extension in this way. We could always support the scalar form too, if we want to maintain consistency between the scalar and vector forms. Presumably, the reason this isn't standard C or C++ is because the standards don't specify a floating-point format. At most, they could have made the behavior implementation-defined. But, if nobody thought it was a useful operation, they probably didn't see any point. What are these operation used for? Can someone give an example of a kernel than benefits from this kind of thing? Assuming there's a plausible use, my suggestion is that we just undo the patch that turned off this functionality. If it doesn't well on some systems, and we don't have any volunteers to write a fully generic (e.g., move float operands to integer registers, bitwise operation, move the result back) then we could always issue a sorry. Users may then have to use #ifdefs on some platforms, but that's no worse than using intrinsics. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-08-09)
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-patches/2006-12/msg01441.html I will do re-testing now and see if some new problems has appeared. Thank you for bringing this up. I'd let to get the checker in too. But, I don't really understand the regrename.c patch. Are you saying that regrename.c is broken, and that we need to make these copies because of a real bug? Or just to make the checker happy? If the latter, have you measured the compile-time and memory usage to see what impact that has? We'd like to avoid making the compiler slower just to make the checker happy -- but, of course, it might be worth a small hit to get the checking benefit. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: [RFC] Migrate pointers to members to the middle end
Ollie Wild wrote: Offhand, I don't remember what happened with the various other cases, but my testing at the time wasn't particularly thorough. The feedback I've gotten so far seems overwhelmingly negative, so I think the next step is to revisit the lowering approach, exercise the hell out of it, and see what, if any, limitations pop up. Yes, I agree. Again, thank you for being patient with the process. Let me know when you're at the point where you'd like me to review the front-end lowering patch again; send me a URL, and I'll be happy to do so. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: [RFC] Migrate pointers to members to the middle end
Daniel Berlin wrote: This is the source of my current woes, as this may involve virtual function resolution, which can't be done with the information currently available to the middle end. Ollie, IIRC, you posted an example where, together with your front-end lowering patch (i.e., with the strategy that Daniel is advocating), we don't do some optimization that we could in theory do. Have you worked out why not? Perhaps that would shed some light on whether or not it's tractable to recover this information from our current IR. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-06-29)
Andreas Meier wrote: You have forgotten the regressions with target milestone 4.2.1 and without a target milestone. Thank you for pointing that out. The omission of 4.2.1 is definitely wrong, and I have fixed the front page with this patch. However, there should be no regressions without a target milestone, unless I've explicitly marked them that way, at some point. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713 Index: index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.626 diff -c -5 -p -r1.626 index.html *** index.html 21 Jul 2007 23:13:20 - 1.626 --- index.html 9 Aug 2007 22:52:08 - *** mission statement/a./p *** 127,140 /dtdd a href=http://gcc.gnu.org/ml/gcc/2007-06/msg00954.html;2007-06-29/a (Stage 2). br / a ! href=http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advancedamp;short_desc_type=allwordssubstramp;short_desc=4.3amp;target_milestone=4.0.4amp;target_milestone=4.1.3amp;target_milestone=4.3.0amp;known_to_fail_type=allwordssubstramp;known_to_work_type=allwordssubstramp;long_desc_type=allwordssubstramp;long_desc=amp;bug_file_loc_type=allwordssubstramp;bug_file_loc=amp;gcchost_type=allwordssubstramp;gcchost=amp;gcctarget_type=allwordssubstramp;gcctarget=amp;gccbuild_type=allwordssubstramp;gccbuild=amp;keywords_type=allwordsamp;keywords=amp;bug_status=UNCONFIRMEDamp;bug_status=NEWamp;bug_status=ASSIGNEDamp;bug_status=SUSPENDEDamp;bug_status=WAITINGamp;bug_status=REOPENEDamp;priority=P1amp;priority=P2amp;priority=P3amp;emailtype1=substringamp;email1=amp;emailtype2=substringamp;email2=amp;bugidtype=includeamp;bug_id=amp;votes=amp;chfieldfrom=amp;chfieldto=Nowamp;chfieldvalue=amp;cmdtype=doitamp;order=Reuse+same+sort+as+last+timeamp;field0-0-0=noopamp;type0-0-0=noopamp;value0-0-0=;Serious regressions/a. a ! href=http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advancedamp;short_desc_type=allwordssubstramp;short_desc=4.3amp;target_milestone=4.0.4amp;target_milestone=4.1.3amp;target_milestone=4.3.0amp;known_to_fail_type=allwordssubstramp;known_to_work_type=allwordssubstramp;long_desc_type=allwordssubstramp;long_desc=amp;bug_file_loc_type=allwordssubstramp;bug_file_loc=amp;gcchost_type=allwordssubstramp;gcchost=amp;gcctarget_type=allwordssubstramp;gcctarget=amp;gccbuild_type=allwordssubstramp;gccbuild=amp;keywords_type=allwordsamp;keywords=amp;bug_status=UNCONFIRMEDamp;bug_status=NEWamp;bug_status=ASSIGNEDamp;bug_status=SUSPENDEDamp;bug_status=WAITINGamp;bug_status=REOPENEDamp;emailtype1=substringamp;email1=amp;emailtype2=substringamp;email2=amp;bugidtype=includeamp;bug_id=amp;votes=amp;chfieldfrom=amp;chfieldto=Nowamp;chfieldvalue=amp;cmdtype=doitamp;order=Reuse+same+sort+as+last+timeamp;field0-0-0=noopamp;type0-0-0=noopamp;value0-0-0=;All regressions/a. /dd /dl --- 127,140 /dtdd a href=http://gcc.gnu.org/ml/gcc/2007-06/msg00954.html;2007-06-29/a (Stage 2). br / a ! href=http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advancedamp;short_desc_type=allwordssubstramp;short_desc=4.3amp;target_milestone=4.0.4amp;target_milestone=4.1.3amp;target_milestone=4.2.2amp;target_milestone=4.3.0amp;known_to_fail_type=allwordssubstramp;known_to_work_type=allwordssubstramp;long_desc_type=allwordssubstramp;long_desc=amp;bug_file_loc_type=allwordssubstramp;bug_file_loc=amp;gcchost_type=allwordssubstramp;gcchost=amp;gcctarget_type=allwordssubstramp;gcctarget=amp;gccbuild_type=allwordssubstramp;gccbuild=amp;keywords_type=allwordsamp;keywords=amp;bug_status=UNCONFIRMEDamp;bug_status=NEWamp;bug_status=ASSIGNEDamp;bug_status=SUSPENDEDamp;bug_status=WAITINGamp;bug_status=REOPENEDamp;priority=P1amp;priority=P2amp;priority=P3amp;emailtype1=substringamp;email1=amp;emailtype2=substringamp;email2=amp;bugidtype=includeamp;bug_id=amp;votes=amp;chfieldfrom=amp;chfieldto=Nowamp;chfieldvalue=amp;cmdtype=doitamp;order=Reuse+same+sort+as+last+timeamp;field0-0-0=noopamp;type0-0-0=noopamp;value0-0-0=;Serious regressions/a. a ! href=http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advancedamp;short_desc_type=allwordssubstramp;short_desc=4.3amp;target_milestone=4.0.4amp;target_milestone=4.1.3amp;target_milestone=4.2.2amp;target_milestone=4.3.0amp;known_to_fail_type=allwordssubstramp;known_to_work_type=allwordssubstramp;long_desc_type=allwordssubstramp;long_desc=amp;bug_file_loc_type=allwordssubstramp;bug_file_loc=amp;gcchost_type=allwordssubstramp;gcchost=amp;gcctarget_type=allwordssubstramp;gcctarget=amp;gccbuild_type=allwordssubstramp;gccbuild=amp;keywords_type=allwordsamp;keywords=amp;bug_status=UNCONFIRMEDamp;bug_status=NEWamp;bug_status=ASSIGNEDamp;bug_status=SUSPENDEDamp;bug_status=WAITINGamp;bug_status=REOPENEDamp;emailtype1=substringamp;email1=amp;emailtype2=substringamp;email2=amp;bugidtype=includeamp;bug_id=amp;votes=amp;chfieldfrom=amp;chfieldto=Nowamp;chfieldvalue=amp
GCC 4.3.0 Status Report (2007-08-09)
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 are having trouble getting reviewed? Any comments re. timing for Stage 3? Quality --- At this point, we have 194 P3-or-higher regressions open against 4.3.0: http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advancedshort_desc_type=allwordssubstrshort_desc=4.3target_milestone=4.0.4target_milestone=4.1.3target_milestone=4.2.2target_milestone=4.3.0known_to_fail_type=allwordssubstrknown_to_work_type=allwordssubstrlong_desc_type=allwordssubstrlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=gcchost_type=allwordssubstrgcchost=gcctarget_type=allwordssubstrgcctarget=gccbuild_type=allwordssubstrgccbuild=keywords_type=allwordskeywords=bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=SUSPENDEDbug_status=WAITINGbug_status=REOPENEDpriority=P1priority=P2priority=P3emailtype1=substringemail1=emailtype2=substringemail2=bugidtype=includebug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=nooptype0-0-0=noopvalue0-0-0= I have not yet triaged the many P3 bugs, so I expect that some of these will be downgraded. An interesting fact is that now about half of the 34 P1s re 4.3-only regressions. So, we have been introducing some new and exciting bugs, and we need to fix those. Do we need another 1-week stabilization period? Previous Report --- http://gcc.gnu.org/ml/gcc/2007-06/msg00954.html -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: [RFC] Migrate pointers to members to the middle end
Ollie Wild wrote: On 8/8/07, Michael Matz [EMAIL PROTECTED] wrote: Ollie, thanks for patiently trying out different approaches. I think the primary purpose of the middle end is to provide a representation which captures the semantics of a program at a sufficiently high level to enable efficient optimization. COMPLEX_CST and COMPLEX_TYPE are a good example. In theory, the middle end has enough information to optimize complex arithmetic based solely on the constituent operations on real and imaginary components, but it's easier to deal with the complex number as an atomic unit. I agree. When I discussed this with Ollie, my feeling was that, yes, it's possible to express all this stuff in terms of GIMPLE (in fact, we already do, aside from PTRMEM_CST itself!), but we're essentially obfuscating information and then trying to get it back. Creating RECORD_TYPE instances to represent pointers-to-member-functions and then hoping that the middle end will scalarize the struct, fold all the tests for virtual-ness, dereference the virtual table entry, etc. seems like a lot of work to do de-virtualization. But, the information is in fact there, so I guess we could go that way. Michael and Danny have expressed opinions; does anyone else have one? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Semicolons at the end of member function definitions
Volker Reichelt wrote:
2007-03-26 Dirk Mueller [EMAIL PROTECTED]
* parser.c (cp_parser_member_declaration): Pedwarn
about stray semicolons after member declarations.
It makes
struct A
{
void foo() {};
}
That is indeed still legal in the current working draft. (The reason
that I copied the grammar productions above the parser functions was so
that it would be easy to check things like this...)
Therefore, IMHO the patch is wrong and should be reverted.
Yes, please go ahead and revert it. And, if you have time, please add a
test-case specifically for this case. The previous patch removed
semicolons from lots of valid code, but probably none of those test
cases were specifically for this case.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: Should gcc/DEV-PHASE in gcc 4.2 branch be updated?
H.J. Lu wrote: According to gcc/ChangeLog, gcc 4.2.1 was released on 2007-07-19. Shouldn't gcc/DEV-PHASE in gcc 4.2 branch be marked as prerelease? I've now updated BASE-VER and DEV-PHASE. Good catch, thanks! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GCC 4.2 branch open
The GCC 4.2 branch is now open under the usual release branch rules. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GPL exception for fptr.c and milli64.s
John -- RMS has OK'd adding the license exception to fptr.c and milli64.s. Please apply your patch. It is OK to do this on the 4.2 branch, too, even though that's otherwise locked down for release. However, I will not be doing an RC3, so please make sure that the files still compile with the change. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
4.2 branch frozen for release
I plan to spin the GCC 4.2.1 release tomorrow. Please do not make any further changes to the branch. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GCC 4.2.1 RC2
GCC 4.2.1 RC2 is now available from: ftp://gcc.gnu.org/pub/gcc/snapshots/4.2.1-RC-20070712 Unless severe problems are found with this release candidates, this will become the official GCC 4.2.1 release in the middle of next week. (I'm sorry it took me longer than I hoped to build RC2; I had a couple of aborted builds and some travel that interfered.) As always with release candidates, please do not directly send me email about problems you encounter. Instead, please file issues in the GCC bug-tracking system: http://gcc.gnu.org/bugzilla/ and add me to the CC: list. The GCC 4.2 branch remains frozen to all changes, without my explicit permission. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: RFH: GPLv3
Nick Clifton wrote: Hi Mark, Will someone (or someones) please volunteer to change the various files that mention GPLv2 to mention GPLv3 instead, to change the COPYING file in the gcc/ directory, and to look for other things that need to change? I volunteer. Thank you! It has not yet been decided what to do about files that are part of run-time libraries and are covered by GPL/LGPL + exception. Therefore, no changes to to what ? :-) I assume that there is a missing part of that last sentence which reads these files will take place at the moment. Yes, that's correct. Sorry! I think however that a small change to such files may be necessary. If I change the contents of the COPYING file over to GPLv3, then I think that it might be wise to create a new file - COPYING_v2 - which contains the GPLv2 and which can be referred to in the copyright notice of files which are still under the GPLv2. Good point! I'd suggest doing this first: make a COPYING_v2, then update GPL/LGPL + exception things to point at it, then change COPYING to v3 and update source files that say v2 or later. Please err on the side of caution; it will be harder to go back to V2 if we accidentally make something V3 than it will be to go forward to V3 if we miss something. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: RFH: GPLv3
David Edelsohn wrote: Let me try to stop some confusion and accusations right here. RMS *did not* request or specify GCC 4.3.3 following GCC 4.2.2. That was a proposal from a member of the GCC SC. The numbering of the first GPLv3 release was not a requirement from RMS or the FSF. I don't particularly have a dog in the version number fight. I think it's potentially surprising to have a bug fix release contain a major licensing change -- whether or not it particularly affects users, it's certainly a big deal, as witnessed by the fact that it's at the top of the FSF's priority list! But, if there's a clear consensus here, I'm fine with that. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
RFH: GPLv3
The GCC SC is still discussing a few of the finer points of the transition to GPLv3. However, here are the things that have now been decided: 1. The compiler proper (e.g., files used only in cc1, cc1plus, the driver, etc.) should all be converted to GPLv3 ASAP. Will someone (or someones) please volunteer to change the various files that mention GPLv2 to mention GPLv3 instead, to change the COPYING file in the gcc/ directory, and to look for other things that need to change? 2. GCC 4.2.1 will be the last GPLv2 release. The FSF will permit backports from mainline to GCC 4.2.1, if necessary, to be downlicensed to GPLv2, as part of that release. 3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3. What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to emphasize the GPLv3 switch. The GCC mainline will then be GCC 4.4. It has not yet been decided what to do about files that are part of run-time libraries and are covered by GPL/LGPL + exception. Therefore, no changes to It has also not yet been decided whether backports of bug-fixes from GPLv3 versions of GCC to older GPLv2 versions of GCC (e.g., GCC 4.1) will result in the patched compilers being GPLv3. If you have thoughts about that, you might wish to contact the FSF. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GCC 4.2.1 Status Report (2007-07-10)
Summary --- The next scheduled GCC 4.2.x release is GCC 4.2.1 on July 13th. As of 5PM PDT tomorrow, please consider the 4.2 branch closed to all changes. If you have outstanding changes that have been approved, but not committed, make the commits before that time. I plan to build GCC 4.2.1 RC2 tomorrow evening. I will probably wait until a few days after the 13th to build the final release, in order to make sure that people have had a chance to test out RC2. We still have 3 wrong-code P1s: PR 32182 -fstrict-aliasing ... PR 32327 Incorrect stack sharing... PR 32328 -fstrict-aliasing ... Priority# Change from Last Report --- - --- P1 21 -8 P2 113 0 P3 3 +1 Previous Report --- http://gcc.gnu.org/ml/gcc/2007-07/msg00062.html -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2.1 Status Report (2007-07-10)
Daniel Berlin wrote: PR 32328 -fstrict-aliasing ... This i have a patch for, but it really needs some performance testing. I'm happy to throw it in RC2 if you want to see how it does, with the caveat it may need to be pulled back out if it causes massive performance regressions :) No, I don't want to do that -- but thanks for working on the PR. If you can do some performance testing up front, then I might consider it for a post-RC2 inclusion, even if it means an RC3. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: flag_complex_method = 2 in C++?
Paolo Carlini wrote: Therefore, I'm not sure... I would certainly like to see method 2 becoming the default everywhere, on the other hand, I'm not sure if method 2 isn't too slow as default for C89 (outside fast-math, I repeat). Shall we carry out performance tests perhaps, or peak performance outside fast-math aren't really an issue here? I don't know. Performance tests would certainly be useful. In case of doubt, I would still switch to method 2 as default together with C++0x, in that case the reference C language is C99 and things are very neat... The problem is that this isn't how users think about it. If a user does: gcc test.c g++ test.c and gets different performance between the two, I think we're going to have a C++ is slow bug report. In a certain sense, the user may be right, in that C99/C++ mandate a slower approach than is used by GNU C89. But, because GNU C89 is the default, we still have a problem. Since C99 has defined semantics for this, and C++ is following, it seems reasonable to me to change C89 to always use these semantics. Then, some GNU C89 programs may go a bit slower, but we don't have weird differences between the languages. And, users can use -ffast-math to get the performance back -- in all languages, uniformly. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: flag_complex_method = 2 in C++?
Paolo Carlini wrote: Ah, one final remark wrt C++0x: note that currently, irrespective of the switches, there is *no way* for the user to choose method 2 in C++. I think this is very bad in C++0x mode: essentially, as regards this feature, it cannot track C99 as it *must*. I really hope we can enable method 2 one way or another... Yes, that's certainly bad. To be clear, my preferences, from most preferable to least are: * Method 2 is the default for all C variants, but can be overridden by -ffast-math, or -fcomplex-method. * Method 2 is the default for C99 and C++0x, but not for C89 or C++, but can be overridden by -ffast-math or -fcomplex-method. * Method 2 is the default for C99 and all variants of C++, but can be overridden by -ffast-math or -fcomplex-method. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GCC 4.2.1 RC1
GCC 4.2.1 RC1 is now available from: ftp://gcc.gnu.org/pub/gcc/snapshots/4.2.1-RC-20070703 It may be too bold to call this a release candidate in that I expect more changes to 4.2.1 before we release. However, it is certainly still a good idea to test these packages in your environment. As always with release candidates, please do not directly send me email about problems you encounter. Instead, please file issues in the GCC bug-tracking system: http://gcc.gnu.org/bugzilla/ and add me to the CC: list. I plan to make GCC 4.2.1 RC2 in approximately a week. At that point, the branch will be frozen in preparation for the release. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: RFC: Make dllimport/dllexport imply default visibility
Geoffrey Keating wrote:
GCC's concept of visibility is very different to that of some other
compilers.
Yes, and that may be a problem. For some features, we want to have GNU
semantics that are consistent that across platforms; for others, we want
to match other compilers on a particular platform.
To be clear, I don't have any objection to the semantics you stated,
from the point of view of first principles of language design. But,
they do not match existing practice on various systems -- and I consider
that a serious problem. In particular, ARM SymbianOS is a system that
has specifically defined DLL attributes in terms of ELF visibility.
There's no choice about the semantics on that system, including the fact
that the first S below is a valid class on that system.
Fortunately, for:
In respect of this specific example, the compiler should not give any
effect to the attribute on 'f' in:
struct __attribute__((visibility(hidden))) S {
void f() __attribute__((visibility(default)));
}
because another shared library can define:
struct __attribute__((visibility(default))) S {
void f();
}
we can be generous. In particular, we can do what the user asks with
the first S, i.e., give f default visibility. There's no inherent
problem there. We can then detect that there are two S::f when both
shared libraries are loaded (if we think that's a useful check), or we
can just call it undefined behavior, as it would be if there were no
visibility markers in this example, but there were conflicting
definitions of S::f.
We could of course issue a warning, or, I guess, an error. I see this
as a style issue, so a warning seems better to me, but if Darwin wants
to forbid giving member functions more visibility than their containing
classes, that's not for me to say.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: RFC: Make dllimport/dllexport imply default visibility
Geoffrey Keating wrote: Yes. __attribute__((visibility)) has consistent GNU semantics, and other features (eg. -fvisibility-ms-compat, __dllspec) match other compilers. The only semantics that make sense on SymbianOS are the ones that allow default visibility within a hidden class. So, whether or not there's a command-line option, it's going to be on by default, and therefore is going to be inconsistent with a system on which GCC disallows (or ignores) that. However, since this is a conservative extension to your semantics (all valid programs remain valid and have the same meaning), I don't understand why you think this is a problem. The SymbianOS semantics give the programmer more choices, which, as with most such things, the programmer can use in good ways or bad. The good news is that the change that I made caused the compiler to stop silently ignoring explicit requests from the programmer and without changing the meaning of any valid programs. So, we can (and do) still have consistent GNU semantics across platforms with this change. I hope you don't mean that there are other system's compilers using the '__attribute__((visibility))' syntax in a way that's incompatible with GCC. If there are, I think the appropriate response is a combination of fixincludes and a polite e-mail asking them to stop. I don't know if there are, but I certainly wouldn't be surprised. The GNU attribute syntax is implemented in the EDG front end and there are lots of EDG-based compilers. RealView 3.0.x doesn't support the visibility attribute, but it does support other GNU attributes. __declspec(dllexport) and __attribute__((visibility(default))) are synonyms on SymbianOS. It would be odd for them to be different because dllexport is defined in terms of visibility. It seems unlikely to me that RealView would add the visibility attribute but disallow usage that is valid with the __declspec syntax, but, of course, I can't speak for ARM. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GCC 4.2.1 Status Report (2007-07-03)
Summary --- The next scheduled GCC 4.2.x release is GCC 4.2.1 on July 13th. I plan to make this release unless I am made aware of P1 regressions relative to GCC 4.2.0. At present, there are 29 P1s open against GCC 4.2.x, virtually all of which are also present in GCC 4.3. Thus, you can kill two birds with one stone by attacking these problems. Half of these 29 P1s are C++ problems, including, mostly, ICEs on valid code. I will do what I can to attack those, but I would also appreciate the help of my fellow C++ maintainers (Nathan, Jason) and any other folks who would like to help out. There are also plenty of wrong-code problems, like: PR 32004: can't find a register in class... PR 32327: Incorrect stack sharing causing removal ... PR 32328: -fstrict-aliasing causes skipped code PR 32533: miscompilation with -O3 -ffast-math -ftree-vectorize -march=native Statistics -- P1: 29 P2: 113 P3: 2 Total: 144 Previous Report --- http://gcc.gnu.org/ml/gcc/2007-05/msg00670.html -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: RFC: Make dllimport/dllexport imply default visibility
Geoffrey Keating wrote:
On 03/07/2007, at 7:37 PM, Mark Mitchell wrote:
Geoffrey Keating wrote:
Yes. __attribute__((visibility)) has consistent GNU semantics, and
other features (eg. -fvisibility-ms-compat, __dllspec) match other
compilers.
The only semantics that make sense on SymbianOS are the ones that allow
default visibility within a hidden class.
I think we're talking past each other. What semantics exactly are
these? Who created them? Where are they implemented? Are they
documented? Who documented them? Why can't they be changed?
SymbianOS allows you to declare a member dllimport or dllexport even
though the class is declared with hidden visibility. dllimport and
dllexport imply default visibility.
The semantics, as I described earlier in this thread, are simple: the
visibility you specify for the class is the default for all members,
including vtables and other compiler-generated stuff, but the user may
explicitly override that by specifying a visibility for the member. The
semantics I describe are a conservative extension to the semantics you
describe; they are operationally identical, except that the semantics
you describe forbid giving a member more visibility than its class. The
change that I made was to stop G++ from silently ignoring such a request.
I don't know who created the SymbianOS semantics, but they are
implemented in ARM's RealView compiler, which is the compiler used to
build SymbianOS and most of the applications for that system. Those
semantics go back to pre-ELF SymbianOS but are preserved in the current
ELF-based SymbianOS explicitly in terms of ELF visibility. They're
documented, at least partially, in various places, including the ARM
EABI and the RealView compiler. They can't be changed because there are
millions of lines of code that require them.
So, whether or not there's a
command-line option, it's going to be on by default, and therefore is
going to be inconsistent with a system on which GCC disallows (or
ignores) that.
Maybe, and maybe not. In particular, an option that changes defaults is
one thing, but if the user overrides the default with GCC-specific
syntax and the compiler does something different, that's another thing
altogether.
Here, the compiler was silently ignoring an attribute explicitly given
by the user. I changed the compiler not to ignore the attribute. That
did not alter the GNU semantics, unless we consider it an intentional
feature that we ignored the attribute. (I can't imagine that we would
consider that a feature; if for some reason we are going to refuse to
let users declare members with more visibility than specified for the
class, we should at least issue an error message.)
I hope you don't mean that there are other system's compilers using the
'__attribute__((visibility))' syntax in a way that's incompatible with
GCC. If there are, I think the appropriate response is a combination of
fixincludes and a polite e-mail asking them to stop.
I don't know if there are, but I certainly wouldn't be surprised. The
GNU attribute syntax is implemented in the EDG front end and there are
lots of EDG-based compilers.
This doesn't quite count, because EDG implements it to be compatible
with GCC, and I'm sure if you find it isn't then they'll fix it (or at
least acknowledge it as a bug).
EDG licensees routinely modify the front end. The attribute handling is
specifically designed to be easy to extend. ARM has already confirmed
(on this list) that the RealView behavior is intentional. It seems
unlikely that it will go away.
RealView 3.0.x doesn't support the visibility attribute, but it does
support other GNU attributes.
So it can't conflict.
I don't find that a convincing argument. The two compilers have
different syntaxes for specifying ELF visibility. But, they meant the
same thing in all respects (so far as I know) except for this case. We
could invent some alternative attribute to mark a class hidden, but in
the SymbianOS way that allows you to override the visibility of members,
not in the GNU way that doesn't, but that seems needlessly complex.
Concretely, are you arguing that my patch was a bad change? If so, do
you feel that silently discarding the attribute on members was a good
thing? Do you feel that preventing users from making members more
visible than classes must be an error, rather than just considering it
in questionable taste?
If you have -fvisibility-ms-compat switched on, then
struct S {
void f() __dllspec(dllimport);
};
That, however, is not quite the case in question; rather it's:
struct S __declspec(notshared) {
void f() __declspec(dllimport); // Or dllexport
};
The class itself is explicitly declared with hidden visibility. And, as
far as I know, there's no desire on SymbianOS to make vtables and such
visible, even when class members are not, which seems to be the goal of
-fvisibility-ms-compat.
--
Mark Mitchell
CodeSourcery
[EMAIL
Re: Status of trunk freeze
Steve Kargl wrote: What's the status of the trunk freeze for going from stage 1 to stage 2? AFAICT, the number of regression on trunk has increased since you sent http://gcc.gnu.org/ml/gcc/2007-06/msg00411.html The important question is whether that change reflects more bugs being introduced or just more bugs being found. I think it's the latter, in which case that doesn't indicate that quality is getting worse. There have been a number of commits to trunk that do not address regressions. That's disappointing, if true. My previous message was pretty clear on this point: Other then the merges mentioned above, and documentation improvements, the only patches that should be committed during the lockdown are fixes for regressions. I do think that attention to quality is something that we need to improve. People who are contributing fixes for regressions are doing something which is just as important as people who are contributing new optimizations. I will be sending out a status report shortly. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GCC 4.3.0 Status Report (2007-06-29)
We have spent the last two weeks in lockdown, hopefully fixing regressions. At this point, there are 153 P3 and higher regressions open against GCC 4.3.0. In reviewing those, I was struck by how many are in fact new regressions in 4.3 -- problems that did not occur in previous releases. These include a number of P1 problems such as: * Failure to bootstrap on relatively common platforms (e.g., PR32540) * Failure to correctly compile SPEC benchmarks (e.g., PR32303) * ICEs on various applications See the full list here: http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advancedshort_desc_type=allwordssubstrshort_desc=4.3target_milestone=4.0.4target_milestone=4.1.3target_milestone=4.3.0known_to_fail_type=allwordssubstrknown_to_work_type=allwordssubstrlong_desc_type=allwordssubstrlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=gcchost_type=allwordssubstrgcchost=gcctarget_type=allwordssubstrgcctarget=gccbuild_type=allwordssubstrgccbuild=keywords_type=allwordskeywords=bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=SUSPENDEDbug_status=WAITINGbug_status=REOPENEDpriority=P1priority=P2priority=P3emailtype1=substringemail1=emailtype2=substringemail2=bugidtype=includebug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=nooptype0-0-0=noopvalue0-0-0= It's clear that the dataflow and PTR_PLUS changes, while of course beneficial, have (as we all expected) caused a bit of collateral fallout. I think it's very important that we step up to fix these problems now, while fresh in our minds. That said, I think it's time to enter Stage 2. So, effective immediately, the lockdown is over. As stated previously, I intend to reenter the lockdown mode every so often, in order to help us focus on closing regressions. Danny, I would still appreciate your help in setting up additional fields in Bugzilla that we can use to help make people aware of regresions that they have caused Previous Report: http://gcc.gnu.org/ml/gcc/2007-06/msg00411.html Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: LTO reader support for MEMORY_PARTITION_TAG
Kenneth Zadeck wrote: now that we can compile, i will start looking inside today. At present, lto_read_function_body doesn't set DECL_SAVED_TREE for the function body, so there's nothing for the back end to even try to output. It doesn't look to me like we've got code to try to read that back in at this point. Would you care to take a try at that? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
LTO reader support for MEMORY_PARTITION_TAG
Kenny --
I tried to get the simplest C program containing a function:
void f() {}
to go through LTO today, but the LTO reader says:
./empty-function.o:0: internal compiler error: in lto_static_init_local,
at lto-tree-flags.def:747
Apparently, this is because the static set-up in lto_static_init_local
doesn't handle MEMORY_PARTITION_TAG (and perhaps other new tree nodes
added after the original LTO branch).
For reference, this is how I compiled the file:
./xgcc -B./ -flto -funit-at-a-time -g -c empty-function.c
./lto1 empty-function.o
Would you be able to take a look at that? I would like to be able to
begin pushing forward on getting small functions to go through the compiler.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: ppc64 __attribute__((visibility (hidden))) and multiple TOCs
Jakub Jelinek wrote:
Hi!
extern void bar (void) __attribute__((visibility (hidden)));
void foo (void)
{
bar ();
bar ();
}
compiled on ppc64-linux with -O2 -m64 -mminimal-toc
leads to bl bar without nop in the following instruction
and to sibling call.
Shouldn't -mminimal-toc also forbid omitting nops if
the target call isn't defined in the same file and forbid
sibcalls to such functions?
That would be my recommendation: limit optimizations that require a
short branch to calls to functions in the same translation unit, not
just in the same shared object. But, that's just my two cents; the
Power maintainers might have a different take.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: ppc64 __attribute__((visibility (hidden))) and multiple TOCs
David Edelsohn wrote: /* If defined in this object and visibility is not default, must be local. */ else if (DECL_VISIBILITY (exp) != VISIBILITY_DEFAULT) local_p = true; Why does binds_local_p return true for non-default visibility? I was just about to ask that. It's an intermediate case: more local than default visibility, but not *that* local. If the function is defined, then it probably does bind locally, in that nothing can come along later and replace the definition we saw. I think the DECL_EXTERNAL case should go before the visibility checks in default_binds_local_p_1. A DECL_EXTERNAL entity never binds locally. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: ppc64 __attribute__((visibility (hidden))) and multiple TOCs
Daniel Jacobowitz wrote: I think the DECL_EXTERNAL case should go before the visibility checks in default_binds_local_p_1. A DECL_EXTERNAL entity never binds locally. That isn't the meaning that most callers of this function want, however. They want same shared object, which is what it currently returns; that's what I think of when you ask me if something binds locally, too... I dunno about most, but at least some want to know can this definition be replaced by another one. For example, DECL_REPLACEABLE_P and cgraph_variable_initializer_availability (which quite probably should be using DECL_REPLACEABLE_P). So, perhaps binds_local_p needs to return a tri-state value. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: ppc64 __attribute__((visibility (hidden))) and multiple TOCs
Jakub Jelinek wrote: For replacability the current definition is just fine. Weak functions must be assumed to be always replaceable and non-weak functions which are known to bind within the same executable resp. shared library are not replaceable - linker will issue error if two non-weak symbols with the same name are linked into the same executable resp. shared library and when linking a non-weak symbol and weak symbol the non-weak one will win. Good point -- if there's no definition in the current translation unit, then I guess we aren't going to make any bad assumptions about the contents of the function. So, I guess that just means that the Power back end needs to check for !DECL_EXTERNAL in addition to binds_local_p? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: ppc64 __attribute__((visibility (hidden))) and multiple TOCs
David Edelsohn wrote: Mark Mitchell writes: Mark Good point -- if there's no definition in the current translation unit, Mark then I guess we aren't going to make any bad assumptions about the Mark contents of the function. So, I guess that just means that the Power Mark back end needs to check for !DECL_EXTERNAL in addition to binds_local_p? Are you suggesting that the rs6000 port should override the hook or just swap the order of the tests in the default hook? I was suggesting leaving the hook alone, but modifying the test for the sibling call optimization in rs6000_function_ok_for_sibcall to: !DECL_EXTERNAL (decl) binds_local_p (decl) In other words, per Jakub's argument, consider binds_local_p to be correct (even on Power), but just note in the back end that binds_local_p isn't a sufficient test for being safe for a sibling call. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: A reload inheritance bug
Bernd Schmidt wrote: Mark Shinwell wrote: Do you think it should be the case that, at the point below, _any_ reload with reg_rtx corresponding to a hard register should have the relevant bit set in reload_spill_index? I think so. I'm attaching a patch below. It appears to have no effect on all code I've tried - does it fix your test case? Mark, did you get a chance to try Bernd's patch? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-06-07)
Michael Meissner wrote: I think a gradual approach is the right way. I think this can be done in the stage 2 time frame, but it could be pushed to gcc 4.4 (but we will have the same problem as we have now). The way I see it, the steps would be: 1) Add the basic infrastructure, iterator macros, stdarg_p, prototype_p, etc. to the tree. 2) Change the back ends, 1 by 1 to use the new infrastructure support. 3) Change the front ends, 1 by 1 to use the new infrastructure support. 4) Remove/rename TYPE_ARG_TYPES, and fix any random breakage. 5) Switch the infrastructure underneath to use vectors. Until #4, you are only changing one thing at a time, and can easily verify that the change works. Yes, I think that this is a good plan. We can evaluate whether #4 has to happen on a branch and wait for 4.4 when we get to it. But, 1, 2, 3 I think are non-controversial, and can go into mainline in real time, which is nice. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: RFC: Make dllimport/dllexport imply default visibility
Chris Lattner wrote:
This description also makes sense, but is different than what was
described before. To me, this description/implementation is extremely
problematic, because the extension cannot be described without
describing the implementation (specifically presence of vtables etc),
which is unlike any standard C++ feature.
That's because it's an ELF-level attribute. It's like dirty tricks you
can play with the alias attribute (means two functions can have the
same address) or making things weak (means addresses of objects with
static storage duration can be NULL). These things are all unappealing
from a language theory point of view; they explicitly go behind the back
of the language to do odd things. This is the ugly reality of C/C++,
and also part of why the languages are so useful.
Some more specific questions:
I'll answer with what I think should happen and with what I know about
what G++ does. I'm not sure what RealView does in all of these cases.
1. If a class is hidden, does that default all the members (not just the
metadata) to be notshared?
Yes. (This is what G++ does.)
2. If a class with vtable is hidden, what visibility constraints exist
on virtual methods?
None. In particular, the virtual methods may be imported from another
shared object. (However, if a virtual function is hidden, then the
vtable must also be defined in the same shared object, as otherwise you
will get a link error.)
3. What does 'notshared' on a class without a vtable mean, what effect
does it have?
It means that all the members have hidden visibility, unless otherwise
specified. (This is what G++ does.)
4. If classes with vtables have different behavior than those without,
is this something we want?
There's no difference.
The notshared attribute means that all of the members,
compiler-generated or otherwise, have hidden visibility, unless
otherwise explicitly specified. It doesn't say anything about the type
per se, just about the various members.
5. How does this impact the ODR?
It's beyond the scope of the ODR. Even for two hidden functions f,
each defined in different shared objects, the name of both is ::f --
but is that an ODR violation? We're way outside the standard at this point.
In practice, people use all of these facilities to do things that
explicitly violate the ODR. For example, in an implementation DLL:
struct S {
__attribute__((visibility(hidden))) void f();
__declspec(dllexport) void g();
};
In other DLLs, the header for S looks like:
struct S {
__declspec(dllimport) void g();
};
and f is not even declared. Certainly, the intent is that these are
the same types, but as a literal reading of the standard that's an ODR
violation. (Even if you left f in, it would be an ODR violation in a
literal sense due to the change from dllexport to dllimport, unless you
modify the ODR rules to be more structural than literal. They actually
require token-for-token identity.)
That's why the right way to understand these attributes is purely in
terms of what they do to object files. Yes, that's crossing an
abstraction barrier, and yes, it means that as a programmer, you need to
understand that there's some vtables and stuff out there, but that's
they way people use these bits in practice.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: New LTO branch ready
Daniel Berlin wrote: Hi guys, I have merged all patches touching lto/ into the new lto branch Thank you! Did you also pull over Kenny's LTO-writer code? I'll try to get it compiling soon. I will perform merges from mainline to branch every week or two, unless you guys see a good reason not to That's great, thanks. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-06-07)
Michael Meissner wrote:
I've looked at the changes, and I think with a minor bit of abstraction, we
can
modify the backends so that they don't care how the arguments are implemented.
Thanks for working on this!
However, I think changing the representation of the arguments is a much more
extensive process, and I don't think we should be doing it right now (there
are
around 220 references to TYPE_ARG_TYPES in the machine independant and front
ends parts of the compiler). But it would allow LTO to make these changes on
their branch, and be able to slip in to use the backends without further
change.
I think we want to avoid making the same mistake we did last time:
mixing these changes up with LTO. They will help LTO (by reducing
memory use), but they're logically independent. So, if we're not
comfortable putting the changes on the mainline, they should go on some
new branch.
I agree that introducing the abstractions first, and then switching the
implementation afterwards, is a good idea. That's what Sandra did for
CALL_EXPRs and it worked well. However:
For the third case, it is fairly simple to switch the code to use
num_parm_types and nth_parm_types. This will mean a slight degradation in the
code that handles arguments (for handling argument n, you need to do n-1
pointer chases).
I don't think we can do this on mainline. That's introducing
quadradicity, and someone will have a 100-argument function, and then
we'll be sad. So, I think we need to do something different. One
possibility is:
FOR_EACH_ARG_TYPE(fn_type, arg_type)
{
}
which expands today to something like:
for (arg_iter = TYPE_ARG_TYPES (fn_type),
arg_type = arg_iter ? TREE_VALUE (arg_iter) : NULL_TREE;
arg_iter;
arg_iter = TREE_CHAIN (arg_iter),
arg_type = arg_iter ? TREE_VALUE (arg_iter) : NULL_TREE)
and, later to something like:
for (arg_indx = 0, arg_type = nth_parm_type (fn_type, arg_index);
arg_indx != num_parm_types (fn_type);
++arg_indx)
Then, in both cases, the code can use arg_type in the body of the loop.
I think some of the abstractions, like stdarg_p and prototyped_p, are
unquestionably a good thing, and ought to go in forthwith. That will
reduce the number of places TYPE_ARG_TYPES is used directly. And, we
don't have to create a branch to do that part. So, I'd suggest
preparing patches against mainline for those bits. How does that sound?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: RFC: Make dllimport/dllexport imply default visibility
__attribute__((visibility(hidden))) S {
__attribute__((visibility(default))) void f();
void g();
};
for quite some time. It would be surprising to make that an error now.
The question which prompted this debate was where f has been marked
dllimport rather than with an explicit visibility. But, dllimport
certainly implies default visibility. It would be inconsistent to
accept the case directly above, but not the dllimport case.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: GCC Status Report (2007-06-15)
H. J. Lu wrote: Good. I have another question. Intel BID patch itself doesn't change any sources in DFP nor libdecnummber. The only significant change is to change Makefile in libgcc to use Intel BID library for DFP intrinsics when BID encoding is selected. Currently, DFP is only supported on Linux/PPC, which uses DPD encoding, and Linux/x86, which uses BID encoding. So Intel BID patch only affects Linux/x86 as it changes libgcc/Makefile.in to use Intel BID library. Who has the final say on this patch? The build system maintainers and the x86 maintainers. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Activate -mrecip with -ffast-math?
Bradley Lucier wrote: If -ffinite-math-only is specified, then producing NaN instead of inf should be allowed. Agreed. After all, -finite-math says: Allow optimizations for floating-point arithmetic that assume that arguments and results are not NaNs or +-Infs. Since the compiler can assume the output isn't a NaN or an Inf, it can freely switch one and the other. If -fno-finite-math-only is specified, then the generated code should do the right thing if an argument or result is inf or NaN. Also agreed. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: RFC: Make dllimport/dllexport imply default visibility
Daniel Jacobowitz wrote:
This doesn't make a lick of sense to me. If the type is hidden, how
on earth can it get a member function _of that type_ from another
library? That library would, by definition, have to have a type of
the same name... but it would be a different type.
You and Chris are taking the view that the type has a location. But,
a lot of people don't look at it this way. The things that have
locations are variables (including class data) and functions. After
all, types don't appear in object files; only variables and functions do.
Furthermore, you're taking the view that:
__attribute__((visibility (hidden))
on a type means something about visibility of the type in a linguistic
sense, i.e., that it provides some kind of scoping, perhaps like an
anonymous namespace that is different in each shared library.
But, the visibility attribute is only specified in terms of its effects
on ELF symbols, not as having C++ semantics per se. The hidden
visibility attribute says that all members of the class have hidden
visibility, unless otherwise specified.
We also allow:
struct __attribute__((visibility(hidden))) S {
__attribute__((visibility(default))) void f();
void g();
};
which may seem equally odd: it says that you can call a function from
outside this translation unit even though you can't see the type. But,
code like this is reasonable; it says that within the defining shared
object you can call all the functions, but that elsewhere you can call
f but not g. (That's orthogonal to C++ access specifiers; private
functions can have default visibility, and public ones can have hidden
visibility.)
The above class should be exactly the same as:
struct S {
__attribute__((visibility(default))) void f();
__attribute__((visibility(hidden))) void g();
};
since there is no virtual table or other class data.
As a motivating example for things like the original case I posted, this
is a technique for permitting users to provide member functions for
classes that you provide in a DLL. If your DLL needs some
system-specific routines, one way to get them is to have the user
provide another DLL containing implementations of various functions in
the class hierarchy. That can be more efficient at run-time than
passing in a separate callback object for the DLL to use, because it
avoids indirecting through the vtable of the callback object.
The bottom line is that you're taking the view that a construct with
well-defined semantics (namely, that the GNU visibility attribute map
directly to the ELF visibility without any further linguistic
implications) and which is easy to implement should be considered
invalid, despite conflicting with existing practice of other compilers
and large bodies of application code.
How does that serve our users?
Note: I'm not arguing about issuing a warning about this with -W, if
people want to do that. These mixtures of visibility are certainly not
the typical case.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: GCC Status Report (2007-06-15)
Kaveh R. GHAZI wrote: On Fri, 15 Jun 2007, Mark Mitchell wrote: GCC 4.3 Stage 1 is now closed. [...] As previously discussed, the mainline will be in lockdown for 1-2 weeks, starting midnight tonight. Other then the merges mentioned above, and documentation improvements, the only patches that should be committed during the lockdown are fixes for regressions. Timezone please? PDT? Sorry, I didn't spot this message until the period of ambiguity had passed. In the future, for avoidance of doubt, if I give a date but not a time, interpret it most generously: so long as it is still that date somewhere on earth, you can still do whatever it is that we're about to stop doing. :-) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC Status Report (2007-06-15)
H. J. Lu wrote: Who are those relevant maintainers? Since Intel BID patches only affects DFP intrinsics, which is only supported on Linux/PPC, Linux/ia32 and Linux/x86-64 while Linux/PPC uses DPD encoding, not BID encoding, I assume the relevant maintainers are maintainers for DFP, libgcc and x86 backend. That sounds correct to me. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
RFC: Make dllimport/dllexport imply default visibility
Consider:
struct __attribute__((vsibility (hidden))) S {
void __declspec(dllimport) f();
};
At present, we give f hidden visibility. That seems odd since the
user has explicitly told us that the symbol is coming from another
shared library.
I'm planning to make any dllimport or dllexport attribute imply default
visibility. Is that a bad idea?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: [fixed-point] Fixed-point branch merge plan
Fu, Chao-Ying wrote: As Mark requested, we propose a merge plan for the fixed-point branch as follows. I think this is a good plan. Since there have been no negative comments, let's go with this approach. I've looked at the big patch you posted, and I think it looks very good overall. You will still need approval for the patches at each stage of the merge, though. I am hoping the appropriate maintainers will step up to review each piece. However, if the process gets stuck, let me know, and I will step in to help. Please wait until the PTR_PLUS branch is merged before beginning your merge. However, you may of course start preparing your patches, and posting them for review, if you like. I just want you to let Andrew go first in terms of actually checking in the changes. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GCC Status Report (2007-06-15)
GCC 4.3 Stage 1 is now closed. After this point, major new functionality (i.e., the sort of thing deserving its own branch) that has not already been submitted will be held for GCC 4.4. Hopefully, the PTR_PLUS branch and the fixed-point branch will be merged in the relatively near future. I am also considering the Intel BID patches for 4.3, as those have arrived just under the wire. I would appreciate comments from relevant maintainers about those patches. As previously discussed, the mainline will be in lockdown for 1-2 weeks, starting midnight tonight. Other then the merges mentioned above, and documentation improvements, the only patches that should be committed during the lockdown are fixes for regressions. We will then enter Stage 2. I expect to reenter the lockdown mode every so often (perhaps one week a month) as we move through Stage 2 and Stage 3, in the hopes of a shorter release process than we achieved for 4.2.0. Previous Report: http://gcc.gnu.org/ml/gcc/2007-06/msg00201.html Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: RFC: Make dllimport/dllexport imply default visibility
Bill Wendling wrote:
On Jun 15, 2007, at 12:48 AM, Mark Mitchell wrote:
Consider:
struct __attribute__((vsibility (hidden))) S {
void __declspec(dllimport) f();
};
At present, we give f hidden visibility. That seems odd since the
user has explicitly told us that the symbol is coming from another
shared library.
I'm planning to make any dllimport or dllexport attribute imply default
visibility. Is that a bad idea?
Perhaps I'm mistaken, but the above seems to indicate to me that the
structure (and, therefore, all of its fields) are hidden, one of its
functions is from an external and visible source.
Yes. And, therefore, emitting a undefined reference to S::f with hidden
linkage in the current translation unit causes S::f to have hidden
visibility in the shared object containing this translation unit. For
example, if the translation unit goes on to say:
void g() {
S s;
s.f();
}
we will now have an undefined reference to S::f with hidden visibility.
As a result, S::f will have hidden visibility in the shared object
containing this translation unit. Thus, despite dllimport, the user
cannot actually import a function of a hidden class from another DLL.
That seems bad.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: RFC: Make dllimport/dllexport imply default visibility
Chris Lattner wrote: This construct seems like it should be rejected by the C++ front-end. The source is making two contradictory claims: the struct is not visible outside this library, but part of it is implemented outside of it. I don't think there's a contradiction. The declaration on the structure is the default for the members and applies to the vtable and other class data. There's no reason the members shouldn't be implemented elsewhere, and there's certainly existing code (in Windows, SymbianOS, and other DLL-based operating systems, whether or not there is on GNU/Linux) that implements different class members in different DLLs, while still not exporting the class from its home DLL. One situation where this is useful is when the class members are actually shared between multiple classes, or are also callable as C functions, etc. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: RFC: Make dllimport/dllexport imply default visibility
Andrew Pinski wrote:
Well this allows for easier violating of ODR. I guess I am just a bit
off of what is going on here but I agree with Chris in that this
really should be rejected as you have stuff which is hidden and then
you call a non hidden member function. How can the vtable be hidden
while the member functions not be? I think if you try to throw that
class across boundaries, it will never be caught as the typeinfos are
different.
There's nothing that says that the class even has a vtable. Or, this
might be a static member function. Obviously, if that function tries to
access the vtable, it will fail to link -- but it might very well not
need to access the hidden stuff.
So really I think this is just bad pratice and should at least get a
warning, even though code in real life exists, the code is broken to
say the least.
I'm not sure why you say that the code is broken. It works. As far as
I know it doesn't violate any specification. What's broken about it?
This is valid:
void f() __attribute__((visibility(hidden)));
void g() __attribute__((dllimport));
void f() { g(); };
So is:
struct S {
void f() __attribute__((visibility(hidden));
void g() __attribute__((dllimport));
};
void S::f() { S::g(); };
So, why not:
struct S __attribute__((visibility(hidden)) {
void f();
void g() __attribute__((dllimport));
};
void S::f() { S::g(); };
In any case, in practice, ARM's RealView compiler accepts:
struct __declspec(notshared) S {
__declspec(dllimport) void f();
void g();
};
void S::g() {
f();
}
And, there's a large body of code that uses this.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: RFC: Make dllimport/dllexport imply default visibility
Andrew Pinski wrote:
In any case, in practice, ARM's RealView compiler accepts:
struct __declspec(notshared) S {
__declspec(dllimport) void f();
void g();
};
void S::g() {
f();
}
And, there's a large body of code that uses this.
Because you missed typeinfo is also hidden (not just vtables).
That has nothing to do with the fact that there's a lot of existing code
out there depending on this.
So in an user program you use typeid(S), you will get a link failure.
If f and g are switch around, you will then not get a link failure but
doing a throw S(); with a catch on the outside, will cause the throw
to be caught by a try{ } catch (S a) ...
Sure. But, so what? If you try to access hidden variables from C,
things won't work then too.
You seem to be saying that because you can do things that don't work, we
should disallow a useful construct.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: Merge PTR_PLUS branch?
Andrew Pinski wrote: If you could review the C++ front-end changes, that would be nice. Would you please point me at a URL for those changes? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Merge PTR_PLUS branch?
Andrew -- Now that dataflow has gone in, you have the ball. When you feel that PTR_PLUS is in suitable shape to go in, and the patches have been reviewed, please merge and commit. I know that there have been some reviews of the patches along the way, and the concept has been appropriately approved, so I don't mean for you to get bogged down in the review process. But, I would like a maintainer to approve the commit. I will help review if necessary. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-06-07)
Michael Meissner wrote: On Fri, Jun 08, 2007 at 01:27:39PM -0700, Mark Mitchell wrote: Joseph S. Myers wrote: On Thu, 7 Jun 2007, Mark Mitchell wrote: I am aware of three remaining projects which are or might be appropriate for Stage 1: Do we at this point believe that the people who were working on updating the TYPE_ARG_TYPES changes (from the old LTO branch) for trunk are not now going to have them ready in time? Unfortunately that person has left AMD. Evidently he and I had some miscommunication, becuase I thought those patches had been checked in before he left. I have been told by my management to either resurrect the patches, or create new patches to fix the backends. Can you remind me what changes need to be made? Sorry about this confusion. Thanks for following up. The goal here is to merge the patches on the (old) LTO branch which change the representation of TYPE_ARG_TYPES. At present, that is a TREE_LIST; on the LTO branch, this representation was changed so that it was instead a TREE_VEC, which saves memory and makes accesses more efficient. The work remaining was to get these patches working with all of the various back ends. Some of them directly manipulate FUNCTION_TYPEs, and so need changes. If you would be willing to work on that, that would be terrific! Please let Kazu Hirta [EMAIL PROTECTED] or myself know if you need help. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-06-07)
Andrew Pinski wrote: On 6/7/07, Mark Mitchell [EMAIL PROTECTED] wrote: * PTR_PLUS branch. I believe that this branch should be included in GCC 4.3. Andrew, would you please update me as to its status? In particular, are there any regressions on primary or secondary targets at this point? Here is what is known about the branch on each of the primary/secondary targets: Thanks for the status information. Based on this, I do think that the branch is ready to merge. Once the dataflow merge is done, and things have had a day or two to settle, please merge the PTR_PLUS branch. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
LTO Status Report (2007-06-10)
Besides my duties as RM, I plan to focus my GCC development time on LTO. This project has been dormant for a while, due to a variety of constraints, but we (my fellow Sourcerers and I) will be able to put more effort into LTO in the near future. Kenny plans to work on LTO once dataflow is merged. Google has resources available as well. And, hopefully, other volunteers will be interested as well. So, I think we're in position to kick off a more substantial effort to move this from design to substantial proof of concept. In particular, the goal that Kenny and I have in mind, after consultation with David Edelsohn, is to get to the point where we can build the C benchmarks in SPEC in LTO mode. To kick things off, I've created some pages on the GCC Wiki that go into more detail about concrete tasks required for LTO. Start here: http://gcc.gnu.org/wiki/LinkTimeOptimization and look for the LTO Driver, LTO Reader/Writer, and LTO Representation Changes subpages. There's something here for everyone: 1. Changes to the driver and collect2. 2. Definition of new DWARF attributes. 3. Reading and writing those DWARF attributes. 4. Eliminating hooks and other bits of global state. 5. Eliminating pre-GIMPLE generation/use of RTL. 6. Poking at the ELF symbol table to determine DECL_SECTION_NAME in the LTO reader. and more! Although these Wiki pages are written in an authoritative form, I do not mean to dicate anything. It's just easier to write X does Y than I think X should do Y everywhere. That said, I think one of the ways in which I can be most useful is as an architect and coordinator. So, I would appreciate it if people who wish to make substantive changes to the design sketch ask me about that before changing the Wiki pages. I would also appreciate if people would keep me informed as to what they are working on, so that I can keep track of what's happening, from a high level. Certainly, CodeSourcery will keep the community informed regarding what pieces we are tackling. (Since we're just now restarting the project, nobody has yet been assigned concrete tasks.) At present, I know that Daniel Berlin is currently moving the existing LTO patches forward to a new branch based on the current mainline. Daniel will let us know when the new branch is ready. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-06-07)
Brooks Moses wrote: Several members of the GFortran team (primarily Chris Rickett and Steve Kargl) have been working on a project to add the BIND(C) functionality from the Fortran 2003 standard. This provides for a standard means of linking Fortran code with code that uses standard C linkage conventions, as well as adding some other useful features. Ok. So, if I'm understanding you correctly, it should either go in before the June 15th cutoff for the end of Stage 1, or it should wait until the end of the intermediate lockdown when Stage 2 opens? Correct. When were you expecting to end the lockdown and open Stage 2? I would play it a little bit by ear, but I was anticipating a couple of weeks. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-06-07)
Mike Stump wrote: On Jun 7, 2007, at 10:33 PM, Mark Mitchell wrote: I am aware of three remaining projects which are or might be appropriate for Stage 1: I wasn't sure of the Objective-C 2.0 timing until recently... I'd like to contribute it during stage 2. That's OK with me, but with two caveats: 1. We will not make any efforts to hold up the release for Objective-C issues that may result from this change. You will be on your own to make sure that everything is in good shape. 2. If the patches make changes to non-Objective-C parts of the compiler, the relevant maintainers have veto authority; they can decide the changes are too dangerous. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-06-07)
Joseph S. Myers wrote: On Thu, 7 Jun 2007, Mark Mitchell wrote: I am aware of three remaining projects which are or might be appropriate for Stage 1: Do we at this point believe that the people who were working on updating the TYPE_ARG_TYPES changes (from the old LTO branch) for trunk are not now going to have them ready in time? I don't see any evidence that those changes will be ready. I haven't heard of any progress from the volunteer at AMD who was working on that. However, I also think that those changes could go in during Stage 2, if they are ready by then. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-06-07)
Brooks Moses wrote: Several members of the GFortran team (primarily Chris Rickett and Steve Kargl) have been working on a project to add the BIND(C) functionality from the Fortran 2003 standard. This provides for a standard means of linking Fortran code with code that uses standard C linkage conventions, as well as adding some other useful features. Thanks for making me aware of this project. As with the Objective-C changes, I think that the Fortran team can decide to merge this in Stage 2, so long as its understood that any problems will be theirs to solve. This is one way in which its advantageous to be a secondary language; because we can be more flexible about releasing the compiler with some quality issues for such languages, we can also be more flexible. IMO, for the Fortran front end, regressions-only is an inappropriate criterion for this sort of mode, given that the front end does not have a long history for the wrong-code and ICE-on-valid bugs to be regressions against. I think that's less true than it used to be. It's true that gfortran is new-ish, and I've given the Fortran team a lot of flexibility in past release cycles. But, congratulations are in order: gfortran is now a real Fortran compiler and people really are using it! But, regressions, wrong-code, and ICEs isn't a bad criteria for this intermediate lockdown. I do expect Fortran to honor the regressions-only rule once the 4.3 release branch has been made. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Fixed-point branch?
Fu, Chao-Ying wrote: Right now, the fixed-point support is a configure-time option. Each target can decide to support it or not. I think there is no harm to enable for every target. But, each target needs to modify tm.h tm.c tm-modes.def to set or change some target macros. I would suggest making it a configure-time option, and eliminating the target hook. Then, people can turn it on when they want. If they try to turn it on for a target that doesn't have the necessary support, the compiler will break, and they can fix it. It's hard to pick up a name. Maybe we will change it to the following as Nigel suggested. /* Conversions involving fractional fixed point types without saturation, including: fractional to fractional (of different precision), signed integer to fractional, fractional to signed integer, floating point to fractional, fractional to floating point. */ DEF_RTL_EXPR(FRACT_CONVERT, fract_convert, e, RTX_UNARY) Yes, I think that's better. Thanks! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Fixed-point branch?
Fu, Chao-Ying wrote: I attached a diff file for 14 files of the new structures and documents. You and other maintainers are welcome to check it. Thanks a lot! Thank you for posting this. Things about which I am clueless: What is the difference between a _Fract type and an _Accum type? I'm gathering that _Fract types have no integer part, i.e., they always represent a number between (-1,1), whereas _Accum types contain both an integer and a fractional part. Is there any other difference? Substantive issues: + unsigned saturating_flag : 1; /* FIXME. This new flag increases the size of + tree_common by a full word. */ We need to fix that, if it's true. Grab a bit out of tree_base::spare, if need be. + /* Fixed-point types. */ + if (targetm.fixed_point_supported_p ()) I thought there was an emulation library for fixed-point operations? So, why would this be supported only on some targets? Is there a harm in supporting it everywhere? If there is, should it be enabled per-target, or via a configure-time option? I don't see any constant-folding code for fixed-point; is there no need for that? Is it somewhere else in the codebase? Stylistic points: Every function needs a comment saying what it does, what every argument is, and what the return value is. You have some new functions that are missing comments. + fixed-point - real, Please write as real to fixed point to avoid ambiguity with the errors. +DEF_RTL_EXPR(FIXED_ALL, fixed_all, e, RTX_UNARY) Why FIXED_ALL? That doesn't seem mnemonic. + sat_short_fract_type_node = make_sat_signed_fract_type (SHORT_FRACT_TYPE_SIZE); + sat_fract_type_node = make_sat_signed_fract_type (FRACT_TYPE_SIZE); + sat_long_fract_type_node = make_sat_signed_fract_type (LONG_FRACT_TYPE_SIZE); + sat_long_long_fract_type_node = make_sat_signed_fract_type (LONG_LONG_FRACT_TYPE_SIZE); Can we macroize some of this goo? There are several places in the patch where you have very long sequences of types, modes, etc. I would hope that by naming things consistently, we might be able to compact this a lot, and reduce the chance that we've got something wrong in just one place. Like: #define MAKE_FIXED_TYPE_NODE(KIND, WIDTH, SAT) \ set_##WIDTH_##KIND_type_node = make_##SAT_... and then: #define MAKE_FIXED_TYPE_NODE_FAMILY(KIND) \ MAKE_FIXED_TYPE_NODE(_short, KIND); \ MAKE_FIXED_TYPE_NODE(_, KIND); \ MAKE_FIXED_TYPE_NODE(_long, KIND); \ MAKE_FIXED_TYPE_NODE(_long_long, KIND); and then: MAKE_FIXED_TYPE_NODE_FAMILY(sat, fract); MAKE_FIXED_TYPE_NODE_FAMILY(sat, accum); etc. That's not right, but you get the idea. :-) Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GCC 4.3.0 Status Report (2007-06-07)
I am aware of three remaining projects which are or might be appropriate for Stage 1: * Dataflow branch. Kenny et. al. plan to merge this Monday. * PTR_PLUS branch. I believe that this branch should be included in GCC 4.3. Andrew, would you please update me as to its status? In particular, are there any regressions on primary or secondary targets at this point? * Fixed-point branch. I've looked at the general infrastructure for this branch. While I have some questions and/or concerns, it appears to me that the changes I reviewed are unlikely to affect anything except fixed-point. In other words, the only risk is that the quality of the fixed-point code itself is unsatisfactory, in which case we can always disable it in 4.3. Therefore, I'm inclined to include this branch as well. Are there any objections to that course of action? In the interests of moving forwards, I therefore plan to close this exceptionally long Stage 1 as of next Friday, June 15th. The projects named above may be merged, even though we will be in Stage 2 -- but no other functionality of Stage 1 scope may be included after this point. I am also considering a lockdown period beginning June 15th during which we would go into a regressions-only mode (other than possible merges of the functionality above) in order to begin eliminating some of the problems that have come in with the exciting new infrastructure. Any comments on that course of action? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Something weird with cp/decl.c switch statement
Ian Lance Taylor wrote: And Simon already sent in a tested patch for a couple of days ago: http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00199.html This patch is OK, thanks. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Fixed-point branch?
Fu, Chao-Ying wrote: 2. Joseph, at that point, would you please invest a a little bit of time (a couple of hours) to look at the branch, and provide some feedback? Please provide comments to Chao-Ying, and also please let me know whether you think the work is nearly ready for inclusion? Maybe you could first check if new machine modes, new TREE structures (a saturating bit, fixed-point type, fixed-point constant), new RTL structures (fixed-point constant and operators) are ok. I had not realized that there were so many changes outside of the C front end. I think that it does indeed make sense to have someone look at some of that stuff. I will be happy to take a look. Will you please send me a patch (and CC the list) for the middle-end changes? It doesn't have to apply to mainline cleanly, but that will give me -- and people who know better than I! -- a chance to look over the infrastructure changes. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Fixed-point branch?
Joseph S. Myers wrote: I haven't examined it. When the branch maintainers consider it ready to merge I hope a proposal along the lines of the DFP one http://gcc.gnu.org/ml/gcc/2005-11/msg01128.html will be posted (see also subsequent discussion in that thread, and on the submitted patches). I would like to avoid the situation in which Chao-Ying et. al. work hard to come up with a plan, factor the patches, etc., and then we decide that the code is not going to be ready for 4.3. I had originally pushed this work back to 4.4, but as 4.3's been delayed, perhaps there's an opportunity for it in 4.3. If, however, the work isn't ready, then I'd rather not take up a lot of Chao-Ying's time now; instead, we can just wait for 4.4 to get closer. At the same time, of course, there's not much point in you investing in looking at the branch if Chao-Ying doesn't think it's ready. So, let's do this: 1. Chao-Ying, would you please work on any remaining issues that you feel need resolution. Then, post your merge plan, ala DFP. 2. Joseph, at that point, would you please invest a a little bit of time (a couple of hours) to look at the branch, and provide some feedback? Please provide comments to Chao-Ying, and also please let me know whether you think the work is nearly ready for inclusion? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Volunteer for bug summaries?
Daniel Berlin wrote: 1. Add a field to bugzilla for the SVN revision at which a particular regression was introduced. Display that in bugzilla as a link to the online SVN history browser so that clicking on a link takes us from the PR straight to the checkin. This field value ought to be the most recent revision to the GCC trunk such that the bug did not occur in the previous revision, but does occur in all subsequent revisions. Danny B., would you be willing to do this? Sure. Thanks! There was some subsequent discussion about exactly what ought to be stored. FWIW, I agree that storing a range might be useful, but I think it's important that we impose enough structure that we can easily run queries without having to do a lot of parsing on the field. Just my two cents, though. I have to look into bugzilla 3.0 migration first though. Understood. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
POINTER_PLUS branch status?
Andrew -- I'm trying to firm up GCC 4.3 planning a bit. One of the things I'm considering is whether or not the POINTER_PLUS branch should be merged as part of 4.3. My understanding from looking at your emails is that the branch is in pretty good shape. Would you please give me a summary of the status? Are there regressions on major platforms? Also, does anyone feel that this representation change is a bad thing? Are there any objections to merging this branch in principle, assuming that it's not causing regressions, either in generate code or at compile time? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Fixed-point branch?
Joseph, Richard -- As C maintainers, have either of you looked at Chao-Ying's fixed-point branch? My understanding (from the note on the Wiki page) is that the fixed-point support is now in reasonably good shape, and works on all architectures, using an emulation library. So, I'm wondering if we should get this into GCC 4.3. I'm interested in your impressions of: (a) whether implementing N1169 is likely to be dangerous, in the sense that the committee might eventually adopt a substantially conflicting version of the specification, (b) the quality of the implementation, (c) risks you would forsee to other parts of the compiler. For the purposes of this discussion, I'm less interested in your impressions (if any) of the MIPS back-end changes; those can be looked at by a MIPS maintainer in due course. The first step would be to get this functionality into the C front-end. Chao-Ying, I'm also interested in whether or not these changes have any impact on C++. With your changes, does GNU C++ now accept any fixed-point constructs? If so, are you aware of any effort to standardize any of this functionality in C++? (I think that my preference, in the short term, would be to disable this functionality in C++ -- although, of course, we will eventually want to turn it on so that GNU C++ is as much as possible a superset of GNU C.) Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GCC 4.1.x Status Report (2007-05-28)
At this point, I do not plan to do any further GCC 4.1.x releases. The GCC 4.1.x series was a great success, and is very widely used. I think it's a fine idea for people to continue to apply fixes to the 4.1.x branch, under the usual release-branch rules, so that people interested in longer-term use of GCC 4.1.x can update from there. And, I would of course be happy to turn the branch over to someone else, if there is interest in future releases. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GCC 4.2.1 Status Report (2007-05-28)
I would like to try to keep the GCC 4.2.x release branch on the time-driven release cycle for point releases that is part of the GCC development plan. I left an embarrassing gap in the GCC 4.1.x release cycle, and I plan to avoid that mistake for GCC 4.2.x. Therefore, I plan to make the GCC 4.2.1 release on or about July 13th. As with the 4.2.0 release, I will be most concerned about P1 regressions in 4.2.x, not present in 4.1.x. At present, that looks to be: * PR 30252 miscompilation of sigc++-2.0 based code with -fstrict-aliasing * PR 31360 rtl loop invariant is broken This is a missed-optimization problem, fixed on the mainline -- although the audit trail suggests that there are unresolved problems on ARM, including bad code generation and CSiBE regressions. There are currently 128 P3-and-higher regressions from previous GCC releases that apply to the 4.2 branch. In order to actually make the release July 13th, I've put a note in my calendar to make 4.2.1 RC1 on July 1st. If there are 4.2.x regressions that you're interested in fixing, please do your best to fix them by that date. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GCC 4.3.0 Status Report (2007-05-28)
Now that GCC 4.2.0 is finally out the door, I'm looking at 4.3.0. Stage 1 has been going on a *long* time, and there have been a lot of changes made. (The Wiki page has an impressive list.) We also seem to have the dataflow stuff ready for merge to mainline, and it looks like POINTER_PLUS may also be close. Unfortunately, we've also introduced a lot of regressions: there look to be about 40 new 4.3-only regressions. The combination of those factors (long Stage 1, lots of new infrastructure already in, lots of new regressions) suggests to me that it's time to bring Stage 1 to a close. Therefore, my current thinking is to close Stage 1 on July 1st, giving everyone one more month to push in any major changes. (Even though it's been a long Stage 1, I don't want to make things overly abrupt.) However, I'm certainly open to suggestions. If you feel that's going to exclude some very important functionality, let me know. If you feel that's too long, let me know that too. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Volunteer for bug summaries?
Ian Lance Taylor wrote: [Danny, please see below for a request for your help.] It's a reasonable idea, but overall it would have a negative effect. People tend to ignore PRs that are assigned to somebody else; they assume that person is actually working on them. Conversely, people won't work on a bug simply because it is assigned to them. Right. I'm going to back up and try to explain a bit more about what I'm trying to accomplish. One of the problems I've faced in recent releases is that developers seem not to care too much about fixing bugs, even bugs that they've caused. On the other hand, I know from talking to users that they care a lot about bugs. There's a large class of users whose basic goal from a new version of GCC is to get better run-time performance from their code, without having to change their code. Bugs, and regressions in particular, are a serious problem for these users. I think GCC developers are well-intentioned, but busy. Many of us are working on GCC at least partially as volunteers, and relatively few of us are particularly incentivized to worry about problems we may have caused on systems we don't use, or codebases we don't compile. But, I think that many of us would respond to being nagged about relatively high-priority regressions, and that if we begin to address these problems earlier in the release cycle, that will help the project overall. I also think that a fundamental responsibility for those of us with check-in privileges is to clean up after ourselves. That's why we've said -- correctly, in my opinion -- that the latent bug excuse is no excuse at all; it's each contributor's responsibility to try to ensure that their contributions make the compiler monotonically better. One would hope that once a contributor tracks down a bug as being a latent bug that an appropriate maintainer would help fix the latent bug, but there's only one person who has the obvious responsibility to investigate/fix the problem: the person who contributed the change that caused/exposed it. One of the reasons that we have bug priorities is so that we can ignore unimportant bugs. That's also why I've established a procedure to allow people beside me to flag PRs for downgrading. If you contribute a great new optimization, and it causes us to generate an inferior error message for some obscure test case, then that's a regression -- but we should mark it P4, and you shouldn't have to worry about it. On the other hand, if your great new optimization causes wrong code on a major platform, then you should figure out why, and arrange to fix the problem. In any case, theory aside, here is what I would like to do: 1. Add a field to bugzilla for the SVN revision at which a particular regression was introduced. Display that in bugzilla as a link to the online SVN history browser so that clicking on a link takes us from the PR straight to the checkin. This field value ought to be the most recent revision to the GCC trunk such that the bug did not occur in the previous revision, but does occur in all subsequent revisions. Danny B., would you be willing to do this? 2. Ask volunteers to fill in the field. Independent of what you may think of my philosophical statements above, this is useful data. One of the first things many of us do when trying to debug a new problem is figure out what changed to cause it. And, this is work that even a volunteer without great knowledge of the compiler's internals can help with, perhaps using Janis' scripts to help with testing. 3. Set up a cron job to generate mail to people whose name is in the ChangeLog entries for P3 and higher regressions, with the SVN field filled in. I will volunteer to work on this part of things, but hopefully I can get some help from our SVN and Bugzilla experts. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Volunteer for bug summaries?
I've received some feedback suggesting that some contributors may not always be aware of what open issues are available to work on, and, perhaps more importantly, what regressions they may have caused. Is there a volunteer who would like to help prepare a regular list of P3-and-higher PRs, together with -- where known -- the name of the person responsible for the checkin which caused the regression? Or, is this something that could be automated through Bugzilla, perhaps by adding a pointer to the SVN revision at which the regression was introduced? The goal would be to send a weekly/bi-weekly reminder to the list, and to the responsible parties, to help remind those of us who've caused problems to clean them up. I know that this would help me, both as a developer and as the RM: as RM, it would help me see what's going on, and as a developer, it would encourage me to clean up my messes, even when I'm busy. What do others think? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GCC 4.2 branch open for regression fixes
The GCC 4.2.0 release is done, so the 4.2 branch is now open for checkins under the usual branch rules: regression fixes only. I know that the GCC 4.2.0 release was a long time coming. Thanks to everyone who worked on it, and for the constructive comments and criticisms! I'll be thinking about a possible 4.1.3 release, an upcoming 4.2.1 release, and 4.3.0 planning in the near future and will send a status report at this time. Here's the (boring) set of patches that I checked in as part of the release checklist. While simple, I've made mistakes with these patches before; if you spot any, please let me know! I'll be sending out a release announcement momentarily. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713 Index: ChangeLog === --- ChangeLog (revision 124663) +++ ChangeLog (working copy) @@ -1,3 +1,7 @@ +2007-05-13 Mark Mitchell [EMAIL PROTECTED] + + * gennews (files): Reference GCC 4.2 web pages. + 2007-04-04 Zack Weinberg [EMAIL PROTECTED] * texi2pod.pl: Correct handling of @itemize with no argument. Index: gennews === --- gennews (revision 124623) +++ gennews (working copy) @@ -22,7 +22,9 @@ # Boston, MA 02110-1301, USA. website=http://gcc.gnu.org/ -files=gcc-4.1/index.html gcc-4.1/changes.html +files= +gcc-4.2/index.html gcc-4.2/changes.html +gcc-4.1/index.html gcc-4.1/changes.html gcc-4.0/index.html gcc-4.0/changes.html gcc-3.4/index.html gcc-3.4/changes.html gcc-3.3/index.html gcc-3.3/changes.html Index: gcc-4.2/index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.2/index.html,v retrieving revision 1.1 diff -c -5 -p -r1.1 index.html *** gcc-4.2/index.html 21 Oct 2006 02:54:29 - 1.1 --- gcc-4.2/index.html 14 May 2007 00:46:02 - *** *** 6,15 body h1GCC 4.2 Release Series/h1 ! pNo releaes yet./p /body /html --- 6,54 body h1GCC 4.2 Release Series/h1 ! pMay 13, 2007/p ! ! pThe a href=http://www.gnu.org;GNU project/a and the GCC ! developers are pleased to announce the release of GCC 4.2.0./p ! ! pThis release is a major release, containing new features (as well ! as many other improvements) relative to GCC 4.1.x./p ! ! h2Release History/h2 ! ! dl ! dtGCC 4.2.0/dt ! dda name=4.2.0May 13, 2007/a ! (a href=changes.htmlchanges/a) ! /dd ! ! /dl ! ! h2References and Acknowledgements/h2 ! ! pGCC used to stand for the GNU C Compiler, but since the compiler ! supports several other languages aside from C, it now stands for the ! GNU Compiler Collection./p ! ! pA list of a href=buildstat.htmlsuccessful builds/a is updated ! as new information becomes available./p ! ! pThe GCC developers would like to thank the numerous people that have ! contributed new features, improvements, bug fixes, and other changes as ! well as test results to GCC. ! This a href=http://gcc.gnu.org/onlinedocs/gcc/Contributors.html;amazing ! group of volunteers/a is what makes GCC successful./p ! ! pFor additional information about GCC please refer to the ! a href=../index.htmlGCC project web site/a or contact the ! a href=mailto:gcc@gcc.gnu.org;GCC development mailing list/a./p ! ! pTo obtain GCC please use a href=../mirrors.htmlour mirror sites/a, ! one of the a href=http://www.gnu.org/order/ftp.html;GNU mirror sites/a, ! or a href=../svn.htmlour SVN server/a./p /body /html 2007-05-13 Mark Mitchell [EMAIL PROTECTED] * cpplib.pot: Regenerate. 2007-05-13 Mark Mitchell [EMAIL PROTECTED] * gcc.pot: Regenerate. Index: DEV-PHASE === --- DEV-PHASE (revision 124718) +++ DEV-PHASE (revision 124719) @@ -0,0 +1 @@ +prerelease Index: ChangeLog === --- ChangeLog (revision 124718) +++ ChangeLog (revision 124719) @@ -1,3 +1,8 @@ +2007-05-14 Mark Mitchell [EMAIL PROTECTED] + + * BASE-VER: Set to 4.2.1. + * DEV-PHASE: Set to prerelease. + 2007-05-13 Release Manager * GCC 4.2.0 released. Index: BASE-VER === --- BASE-VER(revision 124718) +++ BASE-VER(revision 124719) @@ -1 +1 @@ -4.2.0 +4.2.1 Index: develop.html === RCS file: /cvs/gcc/wwwdocs/htdocs/develop.html,v retrieving revision 1.79 diff -c -5 -p -r1.79 develop.html *** develop.html14 Feb 2007 08:30:52 - 1.79 --- develop.html14 May 2007 19:19:08 - *** stages of development, branch points, an *** 373,383 | | +-- GCC 4.2 branch created --+ |(Oct 20 2006)\ v v ! GCC
Re: GCC 4.2.0 Status Report (2007-05-11)
Jason Merrill wrote: Mark Mitchell wrote: PR 30252: Wrong code generation, perhaps due to the C++ front end's representation for base classes. Jason, are you actively investigating this one? I haven't been; I've been working on the forced unwind stuff, and looking at the rvalue refs patch. If you want I can work on this first, but I doubt that the patch would be safe enough for the release branch. Yes, that's a good point. Also, has someone actually verified that this is something that would be fixed by the bases-as-fields work? No, I don't think we know. There's speculation in the PR trail, but that's it. I'd appreciate it if you were able to investigate further, but I think I'd best just accept that this will not be fixed for 4.2.0. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2.0 Status Report (2007-05-11)
Kenneth Hoste wrote: I admit this is not a blocking bug, but it seems fairly (very) easy to solve... I still have to figure out how the patch submission framework works (never contributed to an open-source project before), so I didn't get around to solve it myself. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31586 Maybe someone could solve this, so it is solved in GCC 4.2 and others? Yes, this would be an easy bug to fix, and it would be good to do so, but I don't think this is likely before 4.2.0. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GCC 4.2.0 Status Report (2007-05-13)
Thanks to the efforts of Richard G. and others, we've managed to close PR 31797, one of the two I highlighted in my previous status report on Friday. Meanwhile, PR 30252, which is the other issue I highlighted, looks more difficult to solve. In particular, we don't yet understand the cause of the failure. The only changes from RC3 are: +2007-05-12 Richard Guenther [EMAIL PROTECTED] + + PR tree-optimization/31797 + * tree-ssa-forwprop.c (forward_propagate_addr_expr): Do not + propagate into a stmt that has volatile ops. +2007-05-11 Jerry DeLisle [EMAIL PROTECTED] + + PR libfortran/31880 + * io/unix.c (fd_alloc_r_at): Fix calculation of physical offset. +2007-05-07 Ian Lance Taylor [EMAIL PROTECTED] + + PR java/31842 + * java/lang/natString.cc (_Jv_FormatInt): Avoid undefined signed + overflow. Therefore, I'm going to get 4.2.0 out the door. Please consider the 4.2.0 branch completely frozen at this time. I will be working through the release checklist tonight. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2.0 Status Report (2007-05-11)
Jason Merrill wrote: Mark Mitchell wrote: No, I don't think we know. There's speculation in the PR trail, but that's it. I'd appreciate it if you were able to investigate further, but I think I'd best just accept that this will not be fixed for 4.2.0. Or revert the patch that revealed the bug, or apply Richard Guenther's other patch to work around it? Sorry, your message *just* crossed: http://gcc.gnu.org/ml/gcc/2007-05/msg00329.html in which I declared failure. :-) However, the release isn't really released until it's on the FTP sites, of course, so there's still time to talk me into a different course of action. I'm concerned about either of the other approaches, in that we don't fully understand why they work, so we can't really be confident we're not just pushing the bug around. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GCC 4.2.0 Branch Frozen for Release
As per: http://gcc.gnu.org/ml/gcc/2007-05/msg00329.html Therefore, I'm going to get 4.2.0 out the door. Please consider the 4.2.0 branch completely frozen at this time. I will be working through the release checklist tonight. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2.0 Status Report (2007-05-11)
Jason Merrill wrote: Mark Mitchell wrote: I'm concerned about either of the other approaches, in that we don't fully understand why they work, so we can't really be confident we're not just pushing the bug around. Yes. But I would assert that pushing the bug back to where it was in previous releases is better because it's not a regression. I agree in principle -- much better the bugs we know than the ones we don't. But, IIUC, the patch we'd be reverting is from March, 2006, which means that there's potentially a lot more that depends on it. In that sense, I don't even feel confident that reverting the change is a conservative move, likely to lead to less optimal code, but not wrong code. Are you? (That's a serious question; not a rhetorical one.) Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GCC 4.2.0 Status Report (2007-05-11)
Every time I think we're almost there with this release, I seem to manage to get stuck. :-( However, we're very close: the only PRs that I'm waiting for are: PR 30252: Wrong code generation, perhaps due to the C++ front end's representation for base classes. Jason, are you actively investigating this one? PR 31797: An infinite loop in the compiler while building RTEMS. Daniel, I see you've been commenting on this; are you working on the fix? If so, do you have an ETA? Please let me know the status of these soon. If we can't fix 'em, I'll just proceed with what we've got. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.2.0 Status Report (2007-05-11)
Steven Bosscher wrote: On 5/12/07, Mark Mitchell [EMAIL PROTECTED] wrote: PR 31797: An infinite loop in the compiler while building RTEMS. Daniel, I see you've been commenting on this; are you working on the fix? If so, do you have an ETA? Why are you waiting for this one? RTEMS is not a primary or secondary platform. So there is no reason to wait with the release because of this PR, according to the release criteria (xf. http://gcc.gnu.org/gcc-4.2/criteria.html). I'm not particularly interested in it because of its RTEMS-ness. Rather, I'm interested in it because it's a new case of the compiler failing to correctly process valid code, not present in previous versions of GCC. The test case is not RTEMS-specific; it's a problem that looks like it could equally well apply to lots of other code out there making use of volatile storage. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
