Sell Cisco Systems equipment items
Hello, We have following original Cisco,Card,GBIC/SFP,WIC,cables items for sale If you are interested, pls feel free to contact me. example of the products: CWDM-SFP-1G 38dB (Ultra long-haul)--1510nm,1530nm,1550nm,1570nm,1590nm,1610nm WS-G5483, GLC-SX-MM SFP-GE-L WS-G5487, WS-G5484, WS-G5486, GLC-SX-MM, GLC-LH-SM, GLC-ZX-SM, GLC-T, .. NM-2FE2W-T1, NM-2FE2W-E1, NM-2FE2W-V2, WIC-1T, WIC-2T, WIC-2A/S, WIC-1B/ST, WIC-1ENET, VWIC-1MFT-T1, VWIC-1MFT-E1, VWIC-2MFT-T1, VWIC-2MFT-E1, VWIC-1MFT-G703, VWIC-2MFT-G703, VWIC-1MFT-T1-DI, VWIC-2MFT-T1-DI, NM-1E, NM-4E, .. WS-C2950-24, WS-C2950T-24, WS-C2950G-24-EI, WS-C2950G-48-EI, .. CONSOLE CABLE, CAB-STACK-1M/3M, CAB-V35MT, CAB-V35FC, CAB-SS-V.35MT, CAB-SS-V.35FC, CAB-SS-232MT, CAB-SS-232FC, CAB-232MT, CAB-232FC, CAB-SS-X21MT, CAB-SS-X21FC, CAB-X21MT, .. MEM-npe400-512MB, MEM-3660-128mb, MEM2600-32D, MEM2600-16FS, MEM2600XM-64D, MEM-S1-128MB, MEM-S2-256MB, MEM-S2-512MB, MEM-MSFC-128MB, MEM2801-256D, MEM3800-256D, MEM3800-512, MEM3745-256D, MEM1841-256D, MEM180X-256D, WS-X6K-MSFC2-KIT, and so on. Regards Helen.Zhou NEWSTAR NETWORKING TECHNOLOGY www.nstnetwork.com MSN: [EMAIL PROTECTED] Email: [EMAIL PROTECTED] AOL helenxuezhou Icq 320-880-606
implementing exception handlers in a front end
Hi, I'm currently trying to implement the exception handling in GNU Modula-2 and was wondering which of the following two routes to use. I was initially enthusiastic about using __builtin_setjmp/ __builtin_longjmp as Modula-2 exceptions can be implemented with these mechanisms - and it would also be tantalisingly easy to code.. However, upon searching this list I see that there are a number of problems with __builtin_setjmp and __builtin_longjmp and have begun to examine TRY_CATCH_EXPR nodes instead. It seems that if this later route is taken then the front end also needs to add: DEFTREECODE (THROW_EXPR, "throw", tcc_unary, 1) to its language tree.def and gimplify this. Before I embark on this I'd like to ask whether using __builtin_longjmp/__builtin_setjmp is definitely the wrong way to go? regards, Gaius
Re: implementing exception handlers in a front end
On Wed, Jul 9, 2008 at 3:32 PM, Gaius Mulley <[EMAIL PROTECTED]> wrote: > > Hi, > > I'm currently trying to implement the exception handling in GNU > Modula-2 and was wondering which of the following two routes to use. > I was initially enthusiastic about using __builtin_setjmp/ > __builtin_longjmp as Modula-2 exceptions can be implemented with these > mechanisms - and it would also be tantalisingly easy to code.. > > However, upon searching this list I see that there are a number of > problems with __builtin_setjmp and __builtin_longjmp and have begun > to examine TRY_CATCH_EXPR nodes instead. It seems that if this later > route is taken then the front end also needs to add: > > DEFTREECODE (THROW_EXPR, "throw", tcc_unary, 1) > > to its language tree.def and gimplify this. Before I embark on this > I'd like to ask whether using __builtin_longjmp/__builtin_setjmp is > definitely the wrong way to go? Definitely. You will be not able to handle/throw exceptions from other languages if the target ABI doesn't use sjlj exceptions (which only a few use). Richard.
Re: Trouble with gdb 6.8 on Irix
Joel Brobecker wrote: > > If you care about GDB on mips-irix, I strongly advise caring about GCC as > > well, or finding someone to care about it. Right now, it is on the list > > of targets to be deprecated in GCC 4.4 because we wish to remove fixproto > > and it is one of the few targets still using fixproto (so someone would > > need to stop it from using fixproto, and make fixincludes do any necessary > > fixes fixproto does at present for this target). > I can ask Olivier or Eric if they have some time to have a look. I can have a preliminary look, though I'm not familiar with the details of what fixproto is doing exactly on this target. We still care about this target today, I still have on my list to followup on patch adjustment suggestions issued not so long ago, and I'd be happy to post the testresults we had. Olivier
Re: implementing exception handlers in a front end
"Richard Guenther" <[EMAIL PROTECTED]> writes: > > to its language tree.def and gimplify this. Before I embark on this > > I'd like to ask whether using __builtin_longjmp/__builtin_setjmp is > > definitely the wrong way to go? > > Definitely. You will be not able to handle/throw exceptions from other > languages if the target ABI doesn't use sjlj exceptions (which only > a few use). many thanks for the reply, yes I hadn't considered the issue of inter-language exception handling - this makes the TRY_CATCH_EXPR route highly attractive.. regards, Gaius
Recent libstdc++ regressions
Hi, just to be sure people notice: there are new (1-2 days max) regressions in libstdc++, caused by compiler changes. See, for example: http://gcc.gnu.org/ml/gcc-testresults/2008-07/msg00824.html I can look a bit more into this in the next days, but again I pretty much exclude this has been caused by library changes, that's why this heads up... Paolo.
Re: Recent libstdc++ regressions
This is likely to have been my patch. I'm minimizing the check_construct_destroy failure right now. If someone could give me some idea of what is causing the execution failures while i do that, i may be able to fix them faster :) On Wed, Jul 9, 2008 at 10:31 AM, Paolo Carlini <[EMAIL PROTECTED]> wrote: > Hi, > > just to be sure people notice: there are new (1-2 days max) regressions in > libstdc++, caused by compiler changes. See, for example: > > http://gcc.gnu.org/ml/gcc-testresults/2008-07/msg00824.html > > I can look a bit more into this in the next days, but again I pretty much > exclude this has been caused by library changes, that's why this heads up... > > Paolo. > >
Is that OK to borrow code from coreutils?
Hi, libgfortran calls fork/exec /bin/chmod to parse argument to chmod. Is that OK to borrow code from coreutils which implements /bin/chmod to properly implement chmod? coreutils is under GPLv3 while libgfortran is under GPLv2 + exception. Is that possible to get permission from the FSF to borrow code from coreutils? Thanks. -- H.J.
Re: Is that OK to borrow code from coreutils?
On Wed, Jul 09, 2008 at 01:07:10PM -0700, H.J. Lu wrote: > libgfortran calls fork/exec /bin/chmod to parse argument to chmod. > Is that OK to borrow code from coreutils which implements /bin/chmod > to properly implement chmod? coreutils is under GPLv3 while libgfortran > is under GPLv2 + exception. Is that possible to get permission from > the FSF to borrow code from coreutils? If the consensus of the Fortran maintainers is that this is the right thing to do, the SC can ask the FSF for permission.
Re: Is that OK to borrow code from coreutils?
On Wed, Jul 9, 2008 at 1:17 PM, Joe Buck <[EMAIL PROTECTED]> wrote: > On Wed, Jul 09, 2008 at 01:07:10PM -0700, H.J. Lu wrote: >> libgfortran calls fork/exec /bin/chmod to parse argument to chmod. >> Is that OK to borrow code from coreutils which implements /bin/chmod >> to properly implement chmod? coreutils is under GPLv3 while libgfortran >> is under GPLv2 + exception. Is that possible to get permission from >> the FSF to borrow code from coreutils? > > If the consensus of the Fortran maintainers is that this is the right > thing to do, the SC can ask the FSF for permission. > I don't know if this counts: http://gcc.gnu.org/ml/fortran/2008-07/msg00046.html -- H.J.
Re: Is that OK to borrow code from coreutils?
On Wed, Jul 09, 2008 at 01:17:43PM -0700, Joe Buck wrote: > On Wed, Jul 09, 2008 at 01:07:10PM -0700, H.J. Lu wrote: > > libgfortran calls fork/exec /bin/chmod to parse argument to chmod. > > Is that OK to borrow code from coreutils which implements /bin/chmod > > to properly implement chmod? coreutils is under GPLv3 while libgfortran > > is under GPLv2 + exception. Is that possible to get permission from > > the FSF to borrow code from coreutils? > > If the consensus of the Fortran maintainers is that this is the right > thing to do, the SC can ask the FSF for permission. Presumably one could just take the code from the last GPLv2 version of coreutils, as well... I can't imagine /bin/chmod sees a lot of churn.
Re: Is that OK to borrow code from coreutils?
On Wed, Jul 09, 2008 at 04:26:43PM -0400, Jack Lloyd wrote: > On Wed, Jul 09, 2008 at 01:17:43PM -0700, Joe Buck wrote: > > On Wed, Jul 09, 2008 at 01:07:10PM -0700, H.J. Lu wrote: > > > libgfortran calls fork/exec /bin/chmod to parse argument to chmod. > > > Is that OK to borrow code from coreutils which implements /bin/chmod > > > to properly implement chmod? coreutils is under GPLv3 while libgfortran > > > is under GPLv2 + exception. Is that possible to get permission from > > > the FSF to borrow code from coreutils? > > > > If the consensus of the Fortran maintainers is that this is the right > > thing to do, the SC can ask the FSF for permission. > > Presumably one could just take the code from the last GPLv2 version of > coreutils, as well... I can't imagine /bin/chmod sees a lot of churn. I think that even for that, approval is needed (though it should just be a formality, it's not like RMS is going to say no).
Re: Is that OK to borrow code from coreutils?
On Wed, Jul 09, 2008 at 01:24:44PM -0700, H.J. Lu wrote: > On Wed, Jul 9, 2008 at 1:17 PM, Joe Buck <[EMAIL PROTECTED]> wrote: > > On Wed, Jul 09, 2008 at 01:07:10PM -0700, H.J. Lu wrote: > >> libgfortran calls fork/exec /bin/chmod to parse argument to chmod. > >> Is that OK to borrow code from coreutils which implements /bin/chmod > >> to properly implement chmod? coreutils is under GPLv3 while libgfortran > >> is under GPLv2 + exception. Is that possible to get permission from > >> the FSF to borrow code from coreutils? > > > > If the consensus of the Fortran maintainers is that this is the right > > thing to do, the SC can ask the FSF for permission. > > > > I don't know if this counts: > > http://gcc.gnu.org/ml/fortran/2008-07/msg00046.html I suggest preparing a patch as usual (as if there were no issue) and posting to gcc-patches. The SC can then ask RMS to bless it (pointing him to the patch so he knows exactly what he is blessing), and it can go in. I don't think he would object. Note that this isn't just GPLv2 vs 3 or anything like that, I think we generally need permission when moving code from one project to another. I presume this is just the code that parses the symbolic modes to get the numeric modes?
Re: Is that OK to borrow code from coreutils?
On Wed, Jul 09, 2008 at 01:24:44PM -0700, H.J. Lu wrote: > On Wed, Jul 9, 2008 at 1:17 PM, Joe Buck <[EMAIL PROTECTED]> wrote: > > On Wed, Jul 09, 2008 at 01:07:10PM -0700, H.J. Lu wrote: > >> libgfortran calls fork/exec /bin/chmod to parse argument to chmod. > >> Is that OK to borrow code from coreutils which implements /bin/chmod > >> to properly implement chmod? coreutils is under GPLv3 while libgfortran > >> is under GPLv2 + exception. Is that possible to get permission from > >> the FSF to borrow code from coreutils? > > > > If the consensus of the Fortran maintainers is that this is the right > > thing to do, the SC can ask the FSF for permission. > > > > I don't know if this counts: > > http://gcc.gnu.org/ml/fortran/2008-07/msg00046.html > Do you have an application that shows that the current implementation of chmod() is a bottleneck? -- Steve
Re: Is that OK to borrow code from coreutils?
On Wed, Jul 09, 2008 at 01:52:27PM -0700, Steve Kargl wrote: > On Wed, Jul 09, 2008 at 01:24:44PM -0700, H.J. Lu wrote: > > On Wed, Jul 9, 2008 at 1:17 PM, Joe Buck <[EMAIL PROTECTED]> wrote: > > > On Wed, Jul 09, 2008 at 01:07:10PM -0700, H.J. Lu wrote: > > >> libgfortran calls fork/exec /bin/chmod to parse argument to chmod. > > >> Is that OK to borrow code from coreutils which implements /bin/chmod > > >> to properly implement chmod? coreutils is under GPLv3 while libgfortran > > >> is under GPLv2 + exception. Is that possible to get permission from > > >> the FSF to borrow code from coreutils? > > > > > > If the consensus of the Fortran maintainers is that this is the right > > > thing to do, the SC can ask the FSF for permission. > > > > > > > I don't know if this counts: > > > > http://gcc.gnu.org/ml/fortran/2008-07/msg00046.html > > > > Do you have an application that shows that the current > implementation of chmod() is a bottleneck? Yes, this might be a case of "if it ain't broke, don't fix it".
Re: Is that OK to borrow code from coreutils?
Joe Buck <[EMAIL PROTECTED]> writes: > Note that this isn't just GPLv2 vs 3 or anything like that, I think we > generally need permission when moving code from one project to > another. The chmod parser is actually coming from gnulib, whose sole purpose is to be shared among GNU projects. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Is that OK to borrow code from coreutils?
On Wed, Jul 9, 2008 at 1:59 PM, Joe Buck <[EMAIL PROTECTED]> wrote: > On Wed, Jul 09, 2008 at 01:52:27PM -0700, Steve Kargl wrote: >> On Wed, Jul 09, 2008 at 01:24:44PM -0700, H.J. Lu wrote: >> > On Wed, Jul 9, 2008 at 1:17 PM, Joe Buck <[EMAIL PROTECTED]> wrote: >> > > On Wed, Jul 09, 2008 at 01:07:10PM -0700, H.J. Lu wrote: >> > >> libgfortran calls fork/exec /bin/chmod to parse argument to chmod. >> > >> Is that OK to borrow code from coreutils which implements /bin/chmod >> > >> to properly implement chmod? coreutils is under GPLv3 while libgfortran >> > >> is under GPLv2 + exception. Is that possible to get permission from >> > >> the FSF to borrow code from coreutils? >> > > >> > > If the consensus of the Fortran maintainers is that this is the right >> > > thing to do, the SC can ask the FSF for permission. >> > > >> > >> > I don't know if this counts: >> > >> > http://gcc.gnu.org/ml/fortran/2008-07/msg00046.html >> > >> >> Do you have an application that shows that the current >> implementation of chmod() is a bottleneck? > > Yes, this might be a case of "if it ain't broke, don't fix it". > It is broken: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36755 The implementation in libgfortran is incorrect. It doesn't handle signal nor check return from wait to match pid. -- H.J.
Re: Is that OK to borrow code from coreutils?
On Wed, Jul 09, 2008 at 02:20:55PM -0700, H.J. Lu wrote: > On Wed, Jul 9, 2008 at 1:59 PM, Joe Buck <[EMAIL PROTECTED]> wrote: > > On Wed, Jul 09, 2008 at 01:52:27PM -0700, Steve Kargl wrote: > >> > >> Do you have an application that shows that the current > >> implementation of chmod() is a bottleneck? > > > > Yes, this might be a case of "if it ain't broke, don't fix it". > > > > It is broken: Do you have an application that shows that it is broken? > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36755 I've read the PR. > The implementation in libgfortran is incorrect. It doesn't > handle signal nor check return from wait to match pid. In that chmod() is not defined by the Fortran Standard, how can you infer that libgfortran's implementation is incorrect? In fact, the authorative documentation would be the g77 manual (because gfortran provides chmod solely for backwards compatibility). It clear states: Note that this currently works by actually invoking /bin/chmod (or the chmod found when the library was configured) and so might fail in some circumstances and will, anyway, be slow. -- Steve
Re: Is that OK to borrow code from coreutils?
On Wed, Jul 09, 2008 at 11:16:33PM +0200, Andreas Schwab wrote: > Joe Buck <[EMAIL PROTECTED]> writes: > > > Note that this isn't just GPLv2 vs 3 or anything like that, I think we > > generally need permission when moving code from one project to > > another. > > The chmod parser is actually coming from gnulib, whose sole purpose is > to be shared among GNU projects. > It is GPLv2. This is not acceptable for gfortran's runtime library unless one can get permission to add the exception. -- Steve
Re: Is that OK to borrow code from coreutils?
On Wed, Jul 09, 2008 at 02:38:51PM -0700, Steve Kargl wrote: > On Wed, Jul 09, 2008 at 11:16:33PM +0200, Andreas Schwab wrote: > > Joe Buck <[EMAIL PROTECTED]> writes: > > > > > Note that this isn't just GPLv2 vs 3 or anything like that, I think we > > > generally need permission when moving code from one project to > > > another. > > > > The chmod parser is actually coming from gnulib, whose sole purpose is > > to be shared among GNU projects. > > > > It is GPLv2. This is not acceptable for gfortran's runtime > library unless one can get permission to add the exception. If the gfortran team so decides, the SC can ask RMS for the needed permission. But I'm not sure this is an important issue.
Re: Is that OK to borrow code from coreutils?
On Wed, Jul 9, 2008 at 2:29 PM, Steve Kargl <[EMAIL PROTECTED]> wrote: > On Wed, Jul 09, 2008 at 02:20:55PM -0700, H.J. Lu wrote: >> On Wed, Jul 9, 2008 at 1:59 PM, Joe Buck <[EMAIL PROTECTED]> wrote: >> > On Wed, Jul 09, 2008 at 01:52:27PM -0700, Steve Kargl wrote: >> >> >> >> Do you have an application that shows that the current >> >> implementation of chmod() is a bottleneck? >> > >> > Yes, this might be a case of "if it ain't broke, don't fix it". >> > >> >> It is broken: > > Do you have an application that shows that it is broken? > >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36755 > > I've read the PR. > >> The implementation in libgfortran is incorrect. It doesn't >> handle signal nor check return from wait to match pid. > > In that chmod() is not defined by the Fortran Standard, > how can you infer that libgfortran's implementation is > incorrect? > Please read a decent UNIX system book or look how system () is implemented in glibc. -- H.J.
gcc-4.2-20080709 is now available
Snapshot gcc-4.2-20080709 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080709/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 137674 You'll find: gcc-4.2-20080709.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20080709.tar.bz2 C front end and core compiler gcc-ada-4.2-20080709.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20080709.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20080709.tar.bz2 C++ front end and runtime gcc-java-4.2-20080709.tar.bz2 Java front end and runtime gcc-objc-4.2-20080709.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20080709.tar.bz2The GCC testsuite Diffs from 4.2-20080702 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Is that OK to borrow code from coreutils?
On Wed, Jul 9, 2008 at 11:48 PM, H.J. Lu <[EMAIL PROTECTED]> wrote: >> In that chmod() is not defined by the Fortran Standard, >> how can you infer that libgfortran's implementation is >> incorrect? >> > > Please read a decent UNIX system book or look how > system () is implemented in glibc. Well, there's a helpful answer! You obviously want to change libgfortran for some reason. It seems only normal to me that you make an effort to explain why you think this is necessary. AFAIK the chmod in libgfortran, and in libg2c before that, has never been a problem for anyone. And with the basic rule "If it ain't broke, don't fix it" in mind, there is no reason to change the implementation to something more sophisticated. So what problem are you trying to solve? Got a test case? Please don't point back to the PR again, you're not explaining the problem there either, only the symptom. Surely, you didn't wonder off into libgfortran land if you didn't have a piece of real world code that has issues with the current libgfortran chmod? ;-) Gr. Steven
Re: C++ Warnings on trunk
> In this case, I argue that this code is always compiled with a C > compiler, and should never be compiled by a C++ compiler. Therefore, > I believe it is wrong for this code to be compiled with the > -Wc++-compat warning enabled. This should be fixed somewhere in the > configure script and/or Makefile. I agree. Aren't there some potential nasty problems here with the shared libgcc being compiled with a C++ compiler and the ABI changing one day? (The C ABI, could, too, but it's much less likely.) Ben
Re: Is that OK to borrow code from coreutils?
On Wed, Jul 09, 2008 at 07:17:58PM -0400, Mark Mielke wrote: > Joe Buck wrote: > >On Wed, Jul 09, 2008 at 04:26:43PM -0400, Jack Lloyd wrote: > > > >>On Wed, Jul 09, 2008 at 01:17:43PM -0700, Joe Buck wrote: > >> > >>Presumably one could just take the code from the last GPLv2 version of > >>coreutils, as well... I can't imagine /bin/chmod sees a lot of churn. > >> > > > >I think that even for that, approval is needed (though it should just > >be a formality, it's not like RMS is going to say no). > > > > I'd like to understand this reasoning. I thought the entire purpose of > GPL was to allow other GPL projects to freely derive from the software, > and to prevent non-GPL projects from deriving from this software, > protecting the freedom of the software. In this case, GPLv2 => GPLv2. If > RMS needs a formality request, then this is not in the spirit of the GPL > at all, as the use is not free. Anyone is free to combine GPL code, modify it, and distribute the result. However, for that code to become part of the official GCC, there are additional requirements as well as policies to comply with. So anyone is *not* free to scribble on the official GCC source tree. The GNU project is larger than just GCC, so when code is moved from one piece to another, it raises questions like which side is the master copy, avoiding "cut and paste" meaning that bugs on one side don't get missed on the other side, etc.
Re: C++ Warnings on trunk
On Wed, Jul 9, 2008 at 6:50 PM, Ben Elliston <[EMAIL PROTECTED]> wrote: >> In this case, I argue that this code is always compiled with a C >> compiler, and should never be compiled by a C++ compiler. Therefore, >> I believe it is wrong for this code to be compiled with the >> -Wc++-compat warning enabled. This should be fixed somewhere in the >> configure script and/or Makefile. > > I agree. Aren't there some potential nasty problems here with the > shared libgcc being compiled with a C++ compiler and the ABI changing > one day? (The C ABI, could, too, but it's much less likely.) if libgcc is at the intersection of GNU C and GNU C++ -- which it should be -- there is no problem that the C++ ABI will change without the C ABI also changing. -- Gaby
Re: Is that OK to borrow code from coreutils?
Steven Bosscher wrote: On Wed, Jul 9, 2008 at 11:48 PM, H.J. Lu <[EMAIL PROTECTED]> wrote: In that chmod() is not defined by the Fortran Standard, how can you infer that libgfortran's implementation is incorrect? Please read a decent UNIX system book or look how system () is implemented in glibc. Well, there's a helpful answer! You obviously want to change libgfortran for some reason. It seems only normal to me that you make an effort to explain why you think this is necessary. AFAIK the chmod in libgfortran, and in libg2c before that, has never been a problem for anyone. And with the basic rule "If it ain't broke, don't fix it" in mind, there is no reason to change the implementation to something more sophisticated. So what problem are you trying to solve? Got a test case? Please don't point back to the PR again, you're not explaining the problem there either, only the symptom. Surely, you didn't wonder off into libgfortran land if you didn't have a piece of real world code that has issues with the current libgfortran chmod? ;-) I vote that the PR be closed as invalid and drop this whole subject. I have reviewed the PR and this thread. Ripples in the pond and butterfly wings. Jerry
Re: C++ Warnings on trunk
On Tue, 8 Jul 2008, Kaveh R. Ghazi wrote: > From: "NightStrike" <[EMAIL PROTECTED]> > > > On 7/8/08, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > >> NightStrike <[EMAIL PROTECTED]> writes: > >> > >> > I was under the impression that these would be cleaned up before the > >> > -W options were applied to the trunk. > >> > >> It's pretty hard to clean up all the warnings for every possible > >> target. Also these are only warnings--this code is not compiled with > >> -Werror. > >> > >> In this case, I argue that this code is always compiled with a C > >> compiler, and should never be compiled by a C++ compiler. Therefore, > >> I believe it is wrong for this code to be compiled with the > >> -Wc++-compat warning enabled. This should be fixed somewhere in the > >> configure script and/or Makefile. > > > > Is someone currently taking care of that? > > Yeah, it's on my list. http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00772.html
Re: C++ Warnings on trunk
On 7/10/08, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote: > > Yeah, it's on my list. > > http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00772.html Thanks!
Re: C++ Warnings on trunk
On Tue, 8 Jul 2008, Andreas Schwab wrote: > "Kaveh Ghazi" <[EMAIL PROTECTED]> writes: > > > Right, here's the original link where I mention it: > > http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01658.html > > > > This involves a cast from one type to another through a void*. I haven't > > been able to convince myself that this is completely safe. If someone > > understands why the code is violating type-safety intentionally and can > > explain why it's always safe, I would be happy to insert the appropriate > > cast and fix it. > > The two types bitmap_element and bitmap_head share a common initial > sequence, and when following through ->heads only the first pointer is > ever used. If you define a union type containing the two structs and > make it visible at any point using that cast that would make it > completely safe to the letter of the standard (6.5.2.3#5). > Andreas. Thanks for the explanation. However I don't understand why these conditions make it "safe". First, while these two structs share an initial sequence of members, they don't seem to mean the same thing, i.e. they are of type bitmap_element and named next/prev vs first/current. Second, we can't guarantee that only the first pointer is ever used because in both cases the bitmap object escapes back out of the function and we have no control over how it's handled. It seems to me that the union trick is just a way to violate type-safety without seeing any warnings, same as casting to void* was. :-) Needless to say, I don't understand this (IMHO convoluted) part of the bitmap implementation. So I'd rather leave it to someone who does. Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
