* GCC 3.0.3 @ 2001-11-21 18:24 Mark Mitchell 2001-11-21 22:25 ` Joe Buck ` (3 more replies) 0 siblings, 4 replies; 29+ messages in thread From: Mark Mitchell @ 2001-11-21 18:24 UTC (permalink / raw) To: gcc Please remember that Dec 1. is the freeze date for changes going into GCC 3.0.3. Non-documentation changes will require my approval after that point. I have received some important bug reports from people. I will be posting a list of those shortly. We will try to fix these before the release if possible. Thank you, -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GCC 3.0.3 2001-11-21 18:24 GCC 3.0.3 Mark Mitchell @ 2001-11-21 22:25 ` Joe Buck 2001-11-21 23:26 ` Mark Mitchell ` (2 more replies) 2001-11-23 14:48 ` Stephane Carrez ` (2 subsequent siblings) 3 siblings, 3 replies; 29+ messages in thread From: Joe Buck @ 2001-11-21 22:25 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc > Please remember that Dec 1. is the freeze date for changes going into > GCC 3.0.3. Non-documentation changes will require my approval after > that point. > > I have received some important bug reports from people. I will be > posting a list of those shortly. We will try to fix these before the > release if possible. I'd like to see the fix to PR #4447 back-ported from the trunk to 3.0.3. Actually I don't think any porting is needed, as it's a fix to mangle.c, which hasn't had many changes; no, it doesn't change the ABI because hitting the relevant code caused a core dump before. This PR is an ICE and a regression from 2.95.x. I believe that the relevant patch is 2001-11-17 Kriang Lerdsuwanakij <lerdsuwa@users.sourceforge.net> * mangle.c (write_expression): Handle CAST_EXPR, STATIC_CAST_EXPR, CONST_CAST_EXPR. * operators.def: Add CAST_EXPR, STATIC_CAST_EXPR, CONST_CAST_EXPR. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GCC 3.0.3 2001-11-21 22:25 ` Joe Buck @ 2001-11-21 23:26 ` Mark Mitchell 2001-11-22 0:04 ` Joe Buck 2001-11-29 12:28 ` Mark Mitchell 2001-11-23 14:47 ` fix for PR 4447: is this really correct? Joe Buck 2001-11-29 11:51 ` GCC 3.0.3 Joe Buck 2 siblings, 2 replies; 29+ messages in thread From: Mark Mitchell @ 2001-11-21 23:26 UTC (permalink / raw) To: Joe Buck; +Cc: gcc > I'd like to see the fix to PR #4447 back-ported from the trunk to 3.0.3. > Actually I don't think any porting is needed, as it's a fix to mangle.c, > which hasn't had many changes; no, it doesn't change the ABI because > hitting the relevant code caused a core dump before. > > This PR is an ICE and a regression from 2.95.x. > > I believe that the relevant patch is > > 2001-11-17 Kriang Lerdsuwanakij <lerdsuwa@users.sourceforge.net> > > * mangle.c (write_expression): Handle CAST_EXPR, STATIC_CAST_EXPR, > CONST_CAST_EXPR. > * operators.def: Add CAST_EXPR, STATIC_CAST_EXPR, CONST_CAST_EXPR. Yes, this is OK. Please apply the patch. Thanks, -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GCC 3.0.3 2001-11-21 23:26 ` Mark Mitchell @ 2001-11-22 0:04 ` Joe Buck 2001-11-22 0:14 ` Mark Mitchell 2001-11-29 13:51 ` Joe Buck 2001-11-29 12:28 ` Mark Mitchell 1 sibling, 2 replies; 29+ messages in thread From: Joe Buck @ 2001-11-22 0:04 UTC (permalink / raw) To: Mark Mitchell; +Cc: Joe Buck, gcc I wrote: > > I'd like to see the fix to PR #4447 back-ported from the trunk to 3.0.3. > > Actually I don't think any porting is needed, as it's a fix to mangle.c, > > which hasn't had many changes; no, it doesn't change the ABI because > > hitting the relevant code caused a core dump before. > > > > This PR is an ICE and a regression from 2.95.x. > > > > I believe that the relevant patch is > > > > 2001-11-17 Kriang Lerdsuwanakij <lerdsuwa@users.sourceforge.net> > > > > * mangle.c (write_expression): Handle CAST_EXPR, STATIC_CAST_EXPR, > > CONST_CAST_EXPR. > > * operators.def: Add CAST_EXPR, STATIC_CAST_EXPR, CONST_CAST_EXPR. Mark writes: > Yes, this is OK. Please apply the patch. I don't have write access, so we'll need a volunteer to apply the patch. Joe ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GCC 3.0.3 2001-11-22 0:04 ` Joe Buck @ 2001-11-22 0:14 ` Mark Mitchell 2001-11-22 2:58 ` Joe Buck 2001-11-29 14:25 ` Mark Mitchell 2001-11-29 13:51 ` Joe Buck 1 sibling, 2 replies; 29+ messages in thread From: Mark Mitchell @ 2001-11-22 0:14 UTC (permalink / raw) To: Joe Buck; +Cc: gcc > I don't have write access You should. > so we'll need a volunteer to apply the patch. If you produce the patch and ChangeLog, and test it, I will apply it for you. Thanks, -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GCC 3.0.3 2001-11-22 0:14 ` Mark Mitchell @ 2001-11-22 2:58 ` Joe Buck 2001-11-22 7:35 ` Mark Mitchell 2001-11-29 16:15 ` Joe Buck 2001-11-29 14:25 ` Mark Mitchell 1 sibling, 2 replies; 29+ messages in thread From: Joe Buck @ 2001-11-22 2:58 UTC (permalink / raw) To: Mark Mitchell; +Cc: Joe Buck, gcc I wrote > > I don't have write access Mark writes: > You should. I currently only have GNATS write access, not CVS write. > > so we'll need a volunteer to apply the patch. > > If you produce the patch and ChangeLog, and test it, > I will apply it for you. It appears that Kriang's change to the trunk applies cleanly to the 3.0 version. I'll bootstrap and run tests, and if all goes well you'll get it tomorrow. Assuming no problems, the changelog entry should just be the one from Kriang, which I will re-send. Joe ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GCC 3.0.3 2001-11-22 2:58 ` Joe Buck @ 2001-11-22 7:35 ` Mark Mitchell 2001-11-29 17:16 ` Mark Mitchell 2001-11-29 16:15 ` Joe Buck 1 sibling, 1 reply; 29+ messages in thread From: Mark Mitchell @ 2001-11-22 7:35 UTC (permalink / raw) To: Joe Buck; +Cc: gcc --On Thursday, November 29, 2001 04:14:59 PM -0800 Joe Buck <jbuck@synopsys.COM> wrote: > I wrote >> > I don't have write access > > Mark writes: >> You should. > > I currently only have GNATS write access, not CVS write. Sorry, I was too terse; I meant "you should arrange to have CVS write access". :-) > > I'll bootstrap and run tests, and if all goes well you'll get > it tomorrow. Assuming no problems, the changelog entry should > just be the one from Kriang, which I will re-send. Thanks. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GCC 3.0.3 2001-11-22 7:35 ` Mark Mitchell @ 2001-11-29 17:16 ` Mark Mitchell 0 siblings, 0 replies; 29+ messages in thread From: Mark Mitchell @ 2001-11-29 17:16 UTC (permalink / raw) To: Joe Buck; +Cc: gcc --On Thursday, November 29, 2001 04:14:59 PM -0800 Joe Buck <jbuck@synopsys.COM> wrote: > I wrote >> > I don't have write access > > Mark writes: >> You should. > > I currently only have GNATS write access, not CVS write. Sorry, I was too terse; I meant "you should arrange to have CVS write access". :-) > > I'll bootstrap and run tests, and if all goes well you'll get > it tomorrow. Assuming no problems, the changelog entry should > just be the one from Kriang, which I will re-send. Thanks. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GCC 3.0.3 2001-11-22 2:58 ` Joe Buck 2001-11-22 7:35 ` Mark Mitchell @ 2001-11-29 16:15 ` Joe Buck 1 sibling, 0 replies; 29+ messages in thread From: Joe Buck @ 2001-11-29 16:15 UTC (permalink / raw) To: Mark Mitchell; +Cc: Joe Buck, gcc I wrote > > I don't have write access Mark writes: > You should. I currently only have GNATS write access, not CVS write. > > so we'll need a volunteer to apply the patch. > > If you produce the patch and ChangeLog, and test it, > I will apply it for you. It appears that Kriang's change to the trunk applies cleanly to the 3.0 version. I'll bootstrap and run tests, and if all goes well you'll get it tomorrow. Assuming no problems, the changelog entry should just be the one from Kriang, which I will re-send. Joe ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GCC 3.0.3 2001-11-22 0:14 ` Mark Mitchell 2001-11-22 2:58 ` Joe Buck @ 2001-11-29 14:25 ` Mark Mitchell 1 sibling, 0 replies; 29+ messages in thread From: Mark Mitchell @ 2001-11-29 14:25 UTC (permalink / raw) To: Joe Buck; +Cc: gcc > I don't have write access You should. > so we'll need a volunteer to apply the patch. If you produce the patch and ChangeLog, and test it, I will apply it for you. Thanks, -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GCC 3.0.3 2001-11-22 0:04 ` Joe Buck 2001-11-22 0:14 ` Mark Mitchell @ 2001-11-29 13:51 ` Joe Buck 1 sibling, 0 replies; 29+ messages in thread From: Joe Buck @ 2001-11-29 13:51 UTC (permalink / raw) To: Mark Mitchell; +Cc: Joe Buck, gcc I wrote: > > I'd like to see the fix to PR #4447 back-ported from the trunk to 3.0.3. > > Actually I don't think any porting is needed, as it's a fix to mangle.c, > > which hasn't had many changes; no, it doesn't change the ABI because > > hitting the relevant code caused a core dump before. > > > > This PR is an ICE and a regression from 2.95.x. > > > > I believe that the relevant patch is > > > > 2001-11-17 Kriang Lerdsuwanakij <lerdsuwa@users.sourceforge.net> > > > > * mangle.c (write_expression): Handle CAST_EXPR, STATIC_CAST_EXPR, > > CONST_CAST_EXPR. > > * operators.def: Add CAST_EXPR, STATIC_CAST_EXPR, CONST_CAST_EXPR. Mark writes: > Yes, this is OK. Please apply the patch. I don't have write access, so we'll need a volunteer to apply the patch. Joe ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GCC 3.0.3 2001-11-21 23:26 ` Mark Mitchell 2001-11-22 0:04 ` Joe Buck @ 2001-11-29 12:28 ` Mark Mitchell 1 sibling, 0 replies; 29+ messages in thread From: Mark Mitchell @ 2001-11-29 12:28 UTC (permalink / raw) To: Joe Buck; +Cc: gcc > I'd like to see the fix to PR #4447 back-ported from the trunk to 3.0.3. > Actually I don't think any porting is needed, as it's a fix to mangle.c, > which hasn't had many changes; no, it doesn't change the ABI because > hitting the relevant code caused a core dump before. > > This PR is an ICE and a regression from 2.95.x. > > I believe that the relevant patch is > > 2001-11-17 Kriang Lerdsuwanakij <lerdsuwa@users.sourceforge.net> > > * mangle.c (write_expression): Handle CAST_EXPR, STATIC_CAST_EXPR, > CONST_CAST_EXPR. > * operators.def: Add CAST_EXPR, STATIC_CAST_EXPR, CONST_CAST_EXPR. Yes, this is OK. Please apply the patch. Thanks, -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 29+ messages in thread
* fix for PR 4447: is this really correct? 2001-11-21 22:25 ` Joe Buck 2001-11-21 23:26 ` Mark Mitchell @ 2001-11-23 14:47 ` Joe Buck 2001-11-24 20:36 ` Kriang Lerdsuwanakij 2001-11-30 11:20 ` Joe Buck 2001-11-29 11:51 ` GCC 3.0.3 Joe Buck 2 siblings, 2 replies; 29+ messages in thread From: Joe Buck @ 2001-11-23 14:47 UTC (permalink / raw) To: gcc, lerdsuwa I wrote: > I'd like to see the fix to PR #4447 back-ported from the trunk to 3.0.3. > Actually I don't think any porting is needed, as it's a fix to mangle.c, > which hasn't had many changes; no, it doesn't change the ABI because > hitting the relevant code caused a core dump before. > > This PR is an ICE and a regression from 2.95.x. > I believe that the relevant patch is > > 2001-11-17 Kriang Lerdsuwanakij <lerdsuwa@users.sourceforge.net> > > * mangle.c (write_expression): Handle CAST_EXPR, STATIC_CAST_EXPR, > CONST_CAST_EXPR. > * operators.def: Add CAST_EXPR, STATIC_CAST_EXPR, CONST_CAST_EXPR. Mark approved, assuming the usual testing requirements are met. I've now verified that this fix doesn't break any C++ or libstdc++ tests (other tests aren't relevant since this only affects cc1plus). But I am now not sure that this fix is quite correct, though it does improve things. Here's the testcase: ---------------------------------------------- template<bool B,int I> class T { public: T(int); }; template<bool B1,bool B2,int I1,int I2> T<(B1&&B2),I1+I2-int(B1&&B2)> func(T<B1,I1> a, T<B2,I2> b) { return T<(B1&&B2),I1+I2-int(B1&&B2)> (I1+I2); } void foo(T<true,3> a, T<true,4>b) { func(a, b); } ---------------------------------------------- gcc 3.0 through 3.0.2 get an ICE in the name mangler. With Kriang's patch, the code compiles, but doing nm -p crash.o | c++filt on Solaris gives 0000000000 T foo(T<true, 3>, T<true, 4>) 0000000000 T T<(true)&&(true), ((3)+(4))-(operator int((true)&&(true)))> func<true, true, 3, 4>(T<true, 3>, T<true, 4>) rather than 0000000000 T foo(T<true, 3>, T<true, 4>) 0000000000 T T<true, 6> func<true, true, 3, 4>(T<true, 3>, T<true, 4>) as I would expect. It may be that the oddball expression for the return type will not affect correctness and will just contribute to bloat instead (for the purpose of "linkonce" directives, instantiations that are really the same will look different). But it looks wrong. Comments? I may still want this for 3.0.3, because it does make some cases that ICE'd before work correctly (in my fixed-point computation examples the relevant functions are inline so these oddball symbols probably won't even appear). ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: fix for PR 4447: is this really correct? 2001-11-23 14:47 ` fix for PR 4447: is this really correct? Joe Buck @ 2001-11-24 20:36 ` Kriang Lerdsuwanakij 2001-11-30 23:02 ` Kriang Lerdsuwanakij ` (2 more replies) 2001-11-30 11:20 ` Joe Buck 1 sibling, 3 replies; 29+ messages in thread From: Kriang Lerdsuwanakij @ 2001-11-24 20:36 UTC (permalink / raw) To: Joe Buck, gcc Hi I have checked the ABI specifications (http://www.codesourcery.com/cxx-abi/abi.html) before starting on this patch. And this bloat mangling behavior is what the ABI intended. Following is from the specification with relevant clause capitalized: An expression, e.g., "B<(J+1)/2>", is encoded with a prefix traversal of the operators involved, delimited by "X...E". The operators are encoded using their two letter mangled names. For example, "B<(J+1)/2>", if J is the third template parameter, becomes "1BI Xdv pl T1_ Li1E Li2E E E" (the blanks are present only to visualize the decomposition). Note that the expression is mangled WITHOUT CONSTANT FOLDING OR OTHER SIMPLIFICATION, and without parentheses, which are implicit in the prefix representation. Except for the parentheses, therefore, it represents the source token stream. (C++ Standard reference 14.5.5.1 p. 5.) In fact, expressions (involving any operator except type casts) are already mangled that way without my patch. I can't think of an example that causes ambiguity if constant folding is performed but it looks possible :) --Kriang At 11:20 30/11/01 -0800, Joe Buck wrote: >But I am now not sure that this fix is quite correct, though it does >improve things. > >Here's the testcase: >---------------------------------------------- >template<bool B,int I> >class T { >public: > T(int); >}; > >template<bool B1,bool B2,int I1,int I2> >T<(B1&&B2),I1+I2-int(B1&&B2)> >func(T<B1,I1> a, T<B2,I2> b) { > return T<(B1&&B2),I1+I2-int(B1&&B2)> (I1+I2); >} > >void foo(T<true,3> a, T<true,4>b) { > func(a, b); >} >---------------------------------------------- > >gcc 3.0 through 3.0.2 get an ICE in the name mangler. With Kriang's >patch, the code compiles, but doing > >nm -p crash.o | c++filt > >on Solaris gives > > >0000000000 T foo(T<true, 3>, T<true, 4>) >0000000000 T T<(true)&&(true), ((3)+(4))-(operator int((true)&&(true)))> >func<true, true, 3, 4>(T<true, 3>, T<true, 4>) > >rather than > >0000000000 T foo(T<true, 3>, T<true, 4>) >0000000000 T T<true, 6> func<true, true, 3, 4>(T<true, 3>, T<true, 4>) > >as I would expect. It may be that the oddball expression for the return >type will not affect correctness and will just contribute to bloat instead >(for the purpose of "linkonce" directives, instantiations that are really >the same will look different). But it looks wrong. > >Comments? I may still want this for 3.0.3, because it does make some >cases that ICE'd before work correctly (in my fixed-point computation >examples the relevant functions are inline so these oddball symbols >probably won't even appear). ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: fix for PR 4447: is this really correct? 2001-11-24 20:36 ` Kriang Lerdsuwanakij @ 2001-11-30 23:02 ` Kriang Lerdsuwanakij 2001-12-01 16:08 ` Joe Buck 2001-12-01 17:32 ` Alexandre Oliva 2 siblings, 0 replies; 29+ messages in thread From: Kriang Lerdsuwanakij @ 2001-11-30 23:02 UTC (permalink / raw) To: Joe Buck, gcc Hi I have checked the ABI specifications ( http://www.codesourcery.com/cxx-abi/abi.html ) before starting on this patch. And this bloat mangling behavior is what the ABI intended. Following is from the specification with relevant clause capitalized: An expression, e.g., "B<(J+1)/2>", is encoded with a prefix traversal of the operators involved, delimited by "X...E". The operators are encoded using their two letter mangled names. For example, "B<(J+1)/2>", if J is the third template parameter, becomes "1BI Xdv pl T1_ Li1E Li2E E E" (the blanks are present only to visualize the decomposition). Note that the expression is mangled WITHOUT CONSTANT FOLDING OR OTHER SIMPLIFICATION, and without parentheses, which are implicit in the prefix representation. Except for the parentheses, therefore, it represents the source token stream. (C++ Standard reference 14.5.5.1 p. 5.) In fact, expressions (involving any operator except type casts) are already mangled that way without my patch. I can't think of an example that causes ambiguity if constant folding is performed but it looks possible :) --Kriang At 11:20 30/11/01 -0800, Joe Buck wrote: >But I am now not sure that this fix is quite correct, though it does >improve things. > >Here's the testcase: >---------------------------------------------- >template<bool B,int I> >class T { >public: > T(int); >}; > >template<bool B1,bool B2,int I1,int I2> >T<(B1&&B2),I1+I2-int(B1&&B2)> >func(T<B1,I1> a, T<B2,I2> b) { > return T<(B1&&B2),I1+I2-int(B1&&B2)> (I1+I2); >} > >void foo(T<true,3> a, T<true,4>b) { > func(a, b); >} >---------------------------------------------- > >gcc 3.0 through 3.0.2 get an ICE in the name mangler. With Kriang's >patch, the code compiles, but doing > >nm -p crash.o | c++filt > >on Solaris gives > > >0000000000 T foo(T<true, 3>, T<true, 4>) >0000000000 T T<(true)&&(true), ((3)+(4))-(operator int((true)&&(true)))> >func<true, true, 3, 4>(T<true, 3>, T<true, 4>) > >rather than > >0000000000 T foo(T<true, 3>, T<true, 4>) >0000000000 T T<true, 6> func<true, true, 3, 4>(T<true, 3>, T<true, 4>) > >as I would expect. It may be that the oddball expression for the return >type will not affect correctness and will just contribute to bloat instead >(for the purpose of "linkonce" directives, instantiations that are really >the same will look different). But it looks wrong. > >Comments? I may still want this for 3.0.3, because it does make some >cases that ICE'd before work correctly (in my fixed-point computation >examples the relevant functions are inline so these oddball symbols >probably won't even appear). ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: fix for PR 4447: is this really correct? 2001-11-24 20:36 ` Kriang Lerdsuwanakij 2001-11-30 23:02 ` Kriang Lerdsuwanakij @ 2001-12-01 16:08 ` Joe Buck 2001-12-02 3:12 ` Kriang Lerdsuwanakij 2001-12-01 17:32 ` Alexandre Oliva 2 siblings, 1 reply; 29+ messages in thread From: Joe Buck @ 2001-12-01 16:08 UTC (permalink / raw) To: Kriang Lerdsuwanakij; +Cc: Joe Buck, gcc Kriang writes: > I have checked the ABI specifications > (http://www.codesourcery.com/cxx-abi/abi.html) > before starting on this patch. And this bloat mangling behavior is what > the ABI intended. OK. Mark had approved applying this patch to the 3_0_release branch, so I guess it is the thing to do. I don't understand why the ABI is written this way, though. It seems odd, and since the expression must be constant, I don't see why it was thought better to leave it unevaluated. But, are you confident that all operators are now covered, or is it possible that there's another ICE lurking out there if a user tries a complicated expression? Joe ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: fix for PR 4447: is this really correct? 2001-12-01 16:08 ` Joe Buck @ 2001-12-02 3:12 ` Kriang Lerdsuwanakij 2001-12-03 9:42 ` Mark Mitchell 0 siblings, 1 reply; 29+ messages in thread From: Kriang Lerdsuwanakij @ 2001-12-02 3:12 UTC (permalink / raw) To: Joe Buck; +Cc: gcc Joe Buck wrote: > > OK. Mark had approved applying this patch to the 3_0_release branch, > so I guess it is the thing to do. I don't understand why the ABI is > written this way, though. It seems odd, and since the expression must > be constant, I don't see why it was thought better to leave it unevaluated. > > But, are you confident that all operators are now covered, or is it > possible that there's another ICE lurking out there if a user tries a > complicated expression? > > Joe The only operator missing is the reinterpret_cast operator. Handling it is somewhat messy especially when converting pointers and references - like mangling reinterpret_cast'ing pointer should be encoded as casting to void * followed by casting to the desired type (in conformance with functional equivalent rule in 14.5.5.1 para 5-8). I think it's not so important for 3.0.3. However, I plan to submit an implementation for 3.1. --Kriang ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: fix for PR 4447: is this really correct? 2001-12-02 3:12 ` Kriang Lerdsuwanakij @ 2001-12-03 9:42 ` Mark Mitchell 0 siblings, 0 replies; 29+ messages in thread From: Mark Mitchell @ 2001-12-03 9:42 UTC (permalink / raw) To: lerdsuwa, Joe Buck; +Cc: gcc > I think it's not so important for 3.0.3. However, I plan to submit an > implementation for 3.1. I didn't think reinterpret_cast was legal in a template parameter. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: fix for PR 4447: is this really correct? 2001-11-24 20:36 ` Kriang Lerdsuwanakij 2001-11-30 23:02 ` Kriang Lerdsuwanakij 2001-12-01 16:08 ` Joe Buck @ 2001-12-01 17:32 ` Alexandre Oliva 2 siblings, 0 replies; 29+ messages in thread From: Alexandre Oliva @ 2001-12-01 17:32 UTC (permalink / raw) To: Kriang Lerdsuwanakij; +Cc: Joe Buck, gcc On Dec 1, 2001, Kriang Lerdsuwanakij <lerdsuwa@users.sourceforge.net> wrote: > I have checked the ABI specifications > (http://www.codesourcery.com/cxx-abi/abi.html) > before starting on this patch. And this bloat mangling behavior is > what the ABI intended. Right. The C++ Standard paragraph referenced in that paragraph of the ABI requires this behavior in the mangling of overloads of function templates. Constant folding is still applied to template arguments *referenced* within the definition of the template function, before overload resolution (in case of references to template functions) or specialization resolution (in case of template classes), and encodings of such referenced symbols may be constant-folded. But the template function names must enable one to tell the sequence of tokens used in the template function definition, except for template argument names. > (C++ Standard reference 14.5.5.1 p. 5.) -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{cygnus.com, redhat.com} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist *Please* write to mailing lists, not to me ^ permalink raw reply [flat|nested] 29+ messages in thread
* fix for PR 4447: is this really correct? 2001-11-23 14:47 ` fix for PR 4447: is this really correct? Joe Buck 2001-11-24 20:36 ` Kriang Lerdsuwanakij @ 2001-11-30 11:20 ` Joe Buck 1 sibling, 0 replies; 29+ messages in thread From: Joe Buck @ 2001-11-30 11:20 UTC (permalink / raw) To: gcc, lerdsuwa I wrote: > I'd like to see the fix to PR #4447 back-ported from the trunk to 3.0.3. > Actually I don't think any porting is needed, as it's a fix to mangle.c, > which hasn't had many changes; no, it doesn't change the ABI because > hitting the relevant code caused a core dump before. > > This PR is an ICE and a regression from 2.95.x. > I believe that the relevant patch is > > 2001-11-17 Kriang Lerdsuwanakij <lerdsuwa@users.sourceforge.net> > > * mangle.c (write_expression): Handle CAST_EXPR, STATIC_CAST_EXPR, > CONST_CAST_EXPR. > * operators.def: Add CAST_EXPR, STATIC_CAST_EXPR, CONST_CAST_EXPR. Mark approved, assuming the usual testing requirements are met. I've now verified that this fix doesn't break any C++ or libstdc++ tests (other tests aren't relevant since this only affects cc1plus). But I am now not sure that this fix is quite correct, though it does improve things. Here's the testcase: ---------------------------------------------- template<bool B,int I> class T { public: T(int); }; template<bool B1,bool B2,int I1,int I2> T<(B1&&B2),I1+I2-int(B1&&B2)> func(T<B1,I1> a, T<B2,I2> b) { return T<(B1&&B2),I1+I2-int(B1&&B2)> (I1+I2); } void foo(T<true,3> a, T<true,4>b) { func(a, b); } ---------------------------------------------- gcc 3.0 through 3.0.2 get an ICE in the name mangler. With Kriang's patch, the code compiles, but doing nm -p crash.o | c++filt on Solaris gives 0000000000 T foo(T<true, 3>, T<true, 4>) 0000000000 T T<(true)&&(true), ((3)+(4))-(operator int((true)&&(true)))> func<true, true, 3, 4>(T<true, 3>, T<true, 4>) rather than 0000000000 T foo(T<true, 3>, T<true, 4>) 0000000000 T T<true, 6> func<true, true, 3, 4>(T<true, 3>, T<true, 4>) as I would expect. It may be that the oddball expression for the return type will not affect correctness and will just contribute to bloat instead (for the purpose of "linkonce" directives, instantiations that are really the same will look different). But it looks wrong. Comments? I may still want this for 3.0.3, because it does make some cases that ICE'd before work correctly (in my fixed-point computation examples the relevant functions are inline so these oddball symbols probably won't even appear). ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GCC 3.0.3 2001-11-21 22:25 ` Joe Buck 2001-11-21 23:26 ` Mark Mitchell 2001-11-23 14:47 ` fix for PR 4447: is this really correct? Joe Buck @ 2001-11-29 11:51 ` Joe Buck 2 siblings, 0 replies; 29+ messages in thread From: Joe Buck @ 2001-11-29 11:51 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc > Please remember that Dec 1. is the freeze date for changes going into > GCC 3.0.3. Non-documentation changes will require my approval after > that point. > > I have received some important bug reports from people. I will be > posting a list of those shortly. We will try to fix these before the > release if possible. I'd like to see the fix to PR #4447 back-ported from the trunk to 3.0.3. Actually I don't think any porting is needed, as it's a fix to mangle.c, which hasn't had many changes; no, it doesn't change the ABI because hitting the relevant code caused a core dump before. This PR is an ICE and a regression from 2.95.x. I believe that the relevant patch is 2001-11-17 Kriang Lerdsuwanakij <lerdsuwa@users.sourceforge.net> * mangle.c (write_expression): Handle CAST_EXPR, STATIC_CAST_EXPR, CONST_CAST_EXPR. * operators.def: Add CAST_EXPR, STATIC_CAST_EXPR, CONST_CAST_EXPR. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GCC 3.0.3 2001-11-21 18:24 GCC 3.0.3 Mark Mitchell 2001-11-21 22:25 ` Joe Buck @ 2001-11-23 14:48 ` Stephane Carrez 2001-11-23 15:52 ` Jakub Jelinek ` (2 more replies) 2001-11-24 21:15 ` Toon Moene 2001-11-29 10:24 ` Mark Mitchell 3 siblings, 3 replies; 29+ messages in thread From: Stephane Carrez @ 2001-11-23 14:48 UTC (permalink / raw) To: Mark Mitchell, jakub; +Cc: gcc Hi Mark and Jakub, Can we backport the following patch on 3.0 branch: http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00591.html 2001-11-09 Jakub Jelinek <jakub@redhat.com> * config/sparc/sparc.md (movdf): Avoid calling validize_mem during or after reload. It fixes PR/4410 (verified on 3.0.2/Solaris 8). It is a regression from 2.95.3. Thanks, Stephane (cut&paste from web below) --- gcc/config/sparc/sparc.md.jj Wed Oct 24 21:25:07 2001 +++ gcc/config/sparc/sparc.md Fri Nov 9 15:28:04 2001 @@ -3255,6 +3255,11 @@ && fp_zero_operand (operands[1], DFmode)) goto movdf_is_ok; + /* We are able to build any DF constant in integer registers. */ + if (REGNO (operands[0]) < 32 + && (reload_completed || reload_in_progress)) + goto movdf_is_ok; + operands[1] = validize_mem (force_const_mem (GET_MODE (operands[0]), operands[1])); } ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GCC 3.0.3 2001-11-23 14:48 ` Stephane Carrez @ 2001-11-23 15:52 ` Jakub Jelinek 2001-11-30 11:47 ` Jakub Jelinek 2001-11-30 11:27 ` Stephane Carrez 2001-12-03 8:34 ` Mark Mitchell 2 siblings, 1 reply; 29+ messages in thread From: Jakub Jelinek @ 2001-11-23 15:52 UTC (permalink / raw) To: Stephane Carrez; +Cc: Mark Mitchell, gcc On Fri, Nov 30, 2001 at 08:26:58PM +0100, Stephane Carrez wrote: > Can we backport the following patch on 3.0 branch: > > http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00591.html > > 2001-11-09 Jakub Jelinek <jakub@redhat.com> > > * config/sparc/sparc.md (movdf): Avoid calling validize_mem during > or after reload. > > > It fixes PR/4410 (verified on 3.0.2/Solaris 8). > It is a regression from 2.95.3. Installed on branch (including corresponding testcase). Jakub ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GCC 3.0.3 2001-11-23 15:52 ` Jakub Jelinek @ 2001-11-30 11:47 ` Jakub Jelinek 0 siblings, 0 replies; 29+ messages in thread From: Jakub Jelinek @ 2001-11-30 11:47 UTC (permalink / raw) To: Stephane Carrez; +Cc: Mark Mitchell, gcc On Fri, Nov 30, 2001 at 08:26:58PM +0100, Stephane Carrez wrote: > Can we backport the following patch on 3.0 branch: > > http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00591.html > > 2001-11-09 Jakub Jelinek <jakub@redhat.com> > > * config/sparc/sparc.md (movdf): Avoid calling validize_mem during > or after reload. > > > It fixes PR/4410 (verified on 3.0.2/Solaris 8). > It is a regression from 2.95.3. Installed on branch (including corresponding testcase). Jakub ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GCC 3.0.3 2001-11-23 14:48 ` Stephane Carrez 2001-11-23 15:52 ` Jakub Jelinek @ 2001-11-30 11:27 ` Stephane Carrez 2001-12-03 8:34 ` Mark Mitchell 2 siblings, 0 replies; 29+ messages in thread From: Stephane Carrez @ 2001-11-30 11:27 UTC (permalink / raw) To: Mark Mitchell, jakub; +Cc: gcc Hi Mark and Jakub, Can we backport the following patch on 3.0 branch: http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00591.html 2001-11-09 Jakub Jelinek <jakub@redhat.com> * config/sparc/sparc.md (movdf): Avoid calling validize_mem during or after reload. It fixes PR/4410 (verified on 3.0.2/Solaris 8). It is a regression from 2.95.3. Thanks, Stephane (cut&paste from web below) --- gcc/config/sparc/sparc.md.jj Wed Oct 24 21:25:07 2001 +++ gcc/config/sparc/sparc.md Fri Nov 9 15:28:04 2001 @@ -3255,6 +3255,11 @@ && fp_zero_operand (operands[1], DFmode)) goto movdf_is_ok; + /* We are able to build any DF constant in integer registers. */ + if (REGNO (operands[0]) < 32 + && (reload_completed || reload_in_progress)) + goto movdf_is_ok; + operands[1] = validize_mem (force_const_mem (GET_MODE (operands[0]), operands[1])); } ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GCC 3.0.3 2001-11-23 14:48 ` Stephane Carrez 2001-11-23 15:52 ` Jakub Jelinek 2001-11-30 11:27 ` Stephane Carrez @ 2001-12-03 8:34 ` Mark Mitchell 2 siblings, 0 replies; 29+ messages in thread From: Mark Mitchell @ 2001-12-03 8:34 UTC (permalink / raw) To: Stephane Carrez, jakub; +Cc: gcc --On Friday, November 30, 2001 08:26:58 PM +0100 Stephane Carrez <Stephane.Carrez@worldnet.fr> wrote: > Hi Mark and Jakub, > > Can we backport the following patch on 3.0 branch: > > http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00591.html Yes, thanks. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GCC 3.0.3 2001-11-21 18:24 GCC 3.0.3 Mark Mitchell 2001-11-21 22:25 ` Joe Buck 2001-11-23 14:48 ` Stephane Carrez @ 2001-11-24 21:15 ` Toon Moene 2001-11-30 23:39 ` Toon Moene 2001-11-29 10:24 ` Mark Mitchell 3 siblings, 1 reply; 29+ messages in thread From: Toon Moene @ 2001-11-24 21:15 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc Mark Mitchell wrote: > Please remember that Dec 1. is the freeze date for changes going into > GCC 3.0.3. Non-documentation changes will require my approval after > that point. > > I have received some important bug reports from people. I will be > posting a list of those shortly. We will try to fix these before the > release if possible. I definitely want to fix fortran/4885. It's a regression from gcc-2.95 (actually a libf2c problem that's probably introduced by the ftruncate change requested by the GAMESS developers). I work on it tomorrow (1st of Dec.). -- Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction) ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GCC 3.0.3 2001-11-24 21:15 ` Toon Moene @ 2001-11-30 23:39 ` Toon Moene 0 siblings, 0 replies; 29+ messages in thread From: Toon Moene @ 2001-11-30 23:39 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc Mark Mitchell wrote: > Please remember that Dec 1. is the freeze date for changes going into > GCC 3.0.3. Non-documentation changes will require my approval after > that point. > > I have received some important bug reports from people. I will be > posting a list of those shortly. We will try to fix these before the > release if possible. I definitely want to fix fortran/4885. It's a regression from gcc-2.95 (actually a libf2c problem that's probably introduced by the ftruncate change requested by the GAMESS developers). I work on it tomorrow (1st of Dec.). -- Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction) ^ permalink raw reply [flat|nested] 29+ messages in thread
* GCC 3.0.3 2001-11-21 18:24 GCC 3.0.3 Mark Mitchell ` (2 preceding siblings ...) 2001-11-24 21:15 ` Toon Moene @ 2001-11-29 10:24 ` Mark Mitchell 3 siblings, 0 replies; 29+ messages in thread From: Mark Mitchell @ 2001-11-29 10:24 UTC (permalink / raw) To: gcc Please remember that Dec 1. is the freeze date for changes going into GCC 3.0.3. Non-documentation changes will require my approval after that point. I have received some important bug reports from people. I will be posting a list of those shortly. We will try to fix these before the release if possible. Thank you, -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2001-12-03 17:42 UTC | newest] Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-11-21 18:24 GCC 3.0.3 Mark Mitchell 2001-11-21 22:25 ` Joe Buck 2001-11-21 23:26 ` Mark Mitchell 2001-11-22 0:04 ` Joe Buck 2001-11-22 0:14 ` Mark Mitchell 2001-11-22 2:58 ` Joe Buck 2001-11-22 7:35 ` Mark Mitchell 2001-11-29 17:16 ` Mark Mitchell 2001-11-29 16:15 ` Joe Buck 2001-11-29 14:25 ` Mark Mitchell 2001-11-29 13:51 ` Joe Buck 2001-11-29 12:28 ` Mark Mitchell 2001-11-23 14:47 ` fix for PR 4447: is this really correct? Joe Buck 2001-11-24 20:36 ` Kriang Lerdsuwanakij 2001-11-30 23:02 ` Kriang Lerdsuwanakij 2001-12-01 16:08 ` Joe Buck 2001-12-02 3:12 ` Kriang Lerdsuwanakij 2001-12-03 9:42 ` Mark Mitchell 2001-12-01 17:32 ` Alexandre Oliva 2001-11-30 11:20 ` Joe Buck 2001-11-29 11:51 ` GCC 3.0.3 Joe Buck 2001-11-23 14:48 ` Stephane Carrez 2001-11-23 15:52 ` Jakub Jelinek 2001-11-30 11:47 ` Jakub Jelinek 2001-11-30 11:27 ` Stephane Carrez 2001-12-03 8:34 ` Mark Mitchell 2001-11-24 21:15 ` Toon Moene 2001-11-30 23:39 ` Toon Moene 2001-11-29 10:24 ` Mark Mitchell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).