query: -fshort-enums is default on which targets ?
Hi, The description about the option -fshort-enums on gcc.gnu.org says, that "-fshort-enums is the default on some targets, as required by the platform ABI." 1) Can anyone tell me, on which all targets, this is default? 2) Or if anyone can tell me any document through which I can find the list of those target. 3) I believe that this can also be found out by looking into gcc source code. Can anyone help to by telling me the approximate section of code, where I should look for this? --gaurav
GCC 4.0.2 Status
Now that Benjamin and Eric have fixed the Solaris issues in libstdc++ (yay!), I know of no reason not to spin a release. I'm going to take a final pass through the open PRs and look for show-stoppers. Is anyone aware of regressions from previous 4.0.x releases that are wrong-code, ice-on-valid, or rejects-valid? That will be the class of bugs that would concern me most. I plan to create the release later today. I don't plan to do an RC4, unless people think that's absolutely necessary. However, I would encourage people to do a quick run-through from CVS to make sure that libstdc++, in particular, is working for them. Any thoughts on this plan? Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: query: -fshort-enums is default on which targets ?
"Gaurav Gautam, Noida" <[EMAIL PROTECTED]> writes:
> 1) Can anyone tell me, on which all targets, this is default?
$ grep -r TARGET_DEFAULT_SHORT_ENUMS gcc
gcc/config/arm/arm.c:#undef TARGET_DEFAULT_SHORT_ENUMS
gcc/config/arm/arm.c:#define TARGET_DEFAULT_SHORT_ENUMS arm_default_short_enums
gcc/doc/tm.texi:@deftypefn {Target Hook} bool TARGET_DEFAULT_SHORT_ENUMS (void)
gcc/target-def.h:#define TARGET_DEFAULT_SHORT_ENUMS hook_bool_void_false
gcc/target-def.h: TARGET_DEFAULT_SHORT_ENUMS, \
gcc/ChangeLog-2004: (TARGET_DEFAULT_SHORT_ENUMS): Define.
gcc/ChangeLog-2004: * target-def.h (TARGET_DEFAULT_SHORT_ENUMS): New.
gcc/ChangeLog-2004: (TARGET_INITIALIZER): Add TARGET_DEFAULT_SHORT_ENUMS.
gcc/ChangeLog-2004: TARGET_DEFAULT_SHORT_ENUMS. Update the description.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
reload_in conflicts (Was: Re: [patch RFC] SH: PR target/21623)
Kaz Kojima wrote: Joern RENNECKE <[EMAIL PROTECTED]> wrote: Sorry, I forgot that this is specified to depend on fpscr, and that we are running optimize_mode_switching before reload now. This makes this solution unusable for TARGET_FMOVD. This means we need to go the secondary / tertiary reload route. (At least for TARGET_FMOVD - we can use a special constraint to mean FP_REGS if !TARGET_FMOVD and NO_REGS if TARGET_FMOVD.) I'll try it, though the secondary/tertiary reload stuff may be beyond me. Hmm, I see we have a conflict on reload_insi. There can only be one reload pattern per direction and mode. And push_secondary_reload only generates tertiary reloads on behalf of reload patterns. I suppose we could have push_secondary_reload set t_class in the (icode == CODE_FOR_nothing) case. That would make it simple to write ports where multiple temporary registers are needed. On the other hand, we'd have to make sure that we get the actual reload emitting right, since we now created a new case - and there'd still be the problem of possible clashes where you genuinely need two conflicting reload patterns . An approach that soves these issues would be to change push_secondary_reload to parse multi-alternative reload patterns. Now that we have multi-character constraints, we can use a special constraint in the place of a predicate. So push_secondary_reload could first try to find a match that satisfies not only the operand[in_p] constraint for the to-be-reloaded operand, but also has an operand[!in_p] constraint (insn_class) matching the reload_class, and an operand[2] constraint matching the secondary reload class. If that fails, it can choose the first match where the operand[in_p] constraint matches the operand and the operand[!in_p] constraint matches reload_class. For backward compatibility, we can treat a single-alternative reload pattern like we do now, i.e. consider it matching if the operand predicate matches, no matter what the constraints say.
Re: GCC 4.0.2 Status
On Tue, Sep 27, 2005 at 07:58:46AM -0700, Mark Mitchell wrote: > Now that Benjamin and Eric have fixed the Solaris issues in libstdc++ > (yay!), I know of no reason not to spin a release. I'm going to take a > final pass through the open PRs and look for show-stoppers. Is anyone > aware of regressions from previous 4.0.x releases that are wrong-code, > ice-on-valid, or rejects-valid? That will be the class of bugs that > would concern me most. The libstdc++ ChangeLog looks like 2005-09-25 Benjamin Kosnik <[EMAIL PROTECTED]> Eric Botcazou <[EMAIL PROTECTED]> * include/ext/mt_allocator.h (__per_type_pool<...true>::_S_initialize_once): Always call _M_initialize_once. (__common_pool<...true>::_S_initialize_once): Same. 2005-09-20 Release Manager * GCC 4.0.2 released. Will it be updated before 4.0.2 is released? H.J.
Re: GCC 4.0.2 Status
H. J. Lu wrote: > On Tue, Sep 27, 2005 at 07:58:46AM -0700, Mark Mitchell wrote: > >>Now that Benjamin and Eric have fixed the Solaris issues in libstdc++ >>(yay!), I know of no reason not to spin a release. I'm going to take a >>final pass through the open PRs and look for show-stoppers. Is anyone >>aware of regressions from previous 4.0.x releases that are wrong-code, >>ice-on-valid, or rejects-valid? That will be the class of bugs that >>would concern me most. > > > The libstdc++ ChangeLog looks like > > 2005-09-25 Benjamin Kosnik <[EMAIL PROTECTED]> > Eric Botcazou <[EMAIL PROTECTED]> > > * include/ext/mt_allocator.h > (__per_type_pool<...true>::_S_initialize_once): Always call > _M_initialize_once. > (__common_pool<...true>::_S_initialize_once): Same. > > 2005-09-20 Release Manager > > * GCC 4.0.2 released. > > Will it be updated before 4.0.2 is released? Yes. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: reload-branch created
Daniel Jacobowitz wrote: Hey Bernd, Has there been any news or progress on reload-branch lately? It removes a lot of code that I'd dearly love to see gone... Unfortunately not. I just don't have the time to work on too many extra projects at the moment :-( Of course, others could always volunteer to work on it... Bernd
gcc-3.4-20050927 is now available
Snapshot gcc-3.4-20050927 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050927/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 3.4 CVS branch with the following options: -rgcc-ss-3_4-20050927 You'll find: gcc-3.4-20050927.tar.bz2 Complete GCC (includes all of below) gcc-core-3.4-20050927.tar.bz2 C front end and core compiler gcc-ada-3.4-20050927.tar.bz2 Ada front end and runtime gcc-g++-3.4-20050927.tar.bz2 C++ front end and runtime gcc-g77-3.4-20050927.tar.bz2 Fortran 77 front end and runtime gcc-java-3.4-20050927.tar.bz2 Java front end and runtime gcc-objc-3.4-20050927.tar.bz2 Objective-C front end and runtime gcc-testsuite-3.4-20050927.tar.bz2The GCC testsuite Diffs from 3.4-20050920 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-3.4 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.
Some Question abou libstdc++
Dear, Our organization is planning a big project which is a Linux-Embedded system and will be sold as products in the market. It is necessary for us to choose a C++ Stand Library product. From internet, we found your C++ Stand Library product -- libstdc++, and we are very interested in it, so we have a few important questions to ask though some of the answers to them might be found in your website, but we are a little afraid whether the information might be out-of-date. We will really appreciate your help if you could help us find the answers to the following questions: 1. We would like to know wether we have to obtain some special license or patent to be allowed to use libstdc++ commercially because we will use libstdc++ in our product to be sold in the market. Though we know that libstd++ is under the GPL, we are still not quite sure what to do with the situation of commercial use. By the way, Should we use the LGPL for the libstdc++? If so, could you tell us the operation flow and how much money we have to pay for it if necessary. 2. Who or which group is the author of libstdc++? And which develop mode of the libstdc++ ? For Example: 1 manager,2 developer ... 3. Which test method of the libstdc++? (I find the test scripts in the src code.Is it used the test scripts in the development.) 4. Which Company or person provide the commercially support? And how much does it cost? Maybe some of questions are not suitable, but any informations will help us a lot. Thank you very much again! Wish a successful further cooperation! Best regards Zhan Zhaohua 2005.9.28 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Some Question abou libstdc++
Zhan Zhaohua <[EMAIL PROTECTED]> writes: Many of your questions are answered here: http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html and here: http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/license.html > 1. We would like to know wether we have to obtain > some special license or patent to be allowed to use > libstdc++ > > commercially because we will use libstdc++ in our > product to be sold in the market. Though we know that > libstd++ is under the GPL, we are still not quite sure > what to do with the situation of commercial use. > By the way, Should we use the LGPL for the > libstdc++? > If so, could you tell us the operation flow and > how much money we have to pay for it if necessary. You do not have to pay any money. libstdc++ is not exactly under the GPL; there is an exception to the GPL that covers libstdc++. See the reference above. > 2. Who or which group is the author of libstdc++? And > which develop mode of the libstdc++ ? For Example: 1 > manager,2 > > developer ... libstdc++ is a free software project. There is no manager in the traditional sense. There are mantainers. The MAINTAINERS file currently lists Paolo Carlini, Gabriel Dos Reis, Ulrich Drepper, Phil Edwards, Benjamin Kosnik and Loren J. Rittle. For a complete list of contributors, see the ChangeLog files in the source code. > 3. Which test method of the libstdc++? (I find the > test scripts in the src code.Is it used the test > scripts in the > > development.) The libstdc++ testsuite is included in the code and used with development. > 4. Which Company or person provide the commercially > support? And how much does it cost? There are several companies which provide commercial support for libstdc++, including but not limited to Red Hat, CodeSourcery, Specifix, and Wasabi Systems. Please contact them directly to learn what they offer and what it costs. Ian
