Re: proposal to make SIZE_TYPE more flexible
On Fri, 20 Dec 2013, DJ Delorie wrote: > Ok, so I've got it checking for existing types and checking the target > for supported modes. Any other features, or is it time for a second > patch? Should I cut out the __int128 parts yet, or do you just want > to see the new code still? I think a patch is more useful once believe feature-complete, which means replacing the __int128 support with the new mechanism. -- Joseph S. Myers jos...@codesourcery.com
Re: proposal to make SIZE_TYPE more flexible
Ok, so I've got it checking for existing types and checking the target for supported modes. Any other features, or is it time for a second patch? Should I cut out the __int128 parts yet, or do you just want to see the new code still? To-Do: C++ parser, C++ mangling. Still no idea what to do about mangling.
Re: proposal to make SIZE_TYPE more flexible
On Fri, 20 Dec 2013, DJ Delorie wrote: > > I think using the macros for type sizes is fine, and float / vector / > > complex types are completely irrelevant to this (so standard_type_bitsize > > should maybe be standard_integer_type_bitsize). > > Whew. Am I missing any in the previous code snippet (char, short, > int, long, long long) ? Those were the ones documented in tm.texi. That's the correct list. > > No, the (TImode, __int128) pair should be handled the same way as all the > > other __intN types rather than special-cased (of course you should ensure > > the patch does not end up changing the set of configurations for which > > __int128 is available). > > So if a target happened to set "long long" to TImode, it wouldn't have > __int128 any more? I'm wondering if any ILP64 target would be > affected (x86-64 isn't, I don't think any others are). No existing target defines LONG_LONG_TYPE_SIZE to more than 64. -- Joseph S. Myers jos...@codesourcery.com
Re: proposal to make SIZE_TYPE more flexible
> I think using the macros for type sizes is fine, and float / vector / > complex types are completely irrelevant to this (so standard_type_bitsize > should maybe be standard_integer_type_bitsize). Whew. Am I missing any in the previous code snippet (char, short, int, long, long long) ? Those were the ones documented in tm.texi. > No, the (TImode, __int128) pair should be handled the same way as all the > other __intN types rather than special-cased (of course you should ensure > the patch does not end up changing the set of configurations for which > __int128 is available). So if a target happened to set "long long" to TImode, it wouldn't have __int128 any more? I'm wondering if any ILP64 target would be affected (x86-64 isn't, I don't think any others are).
Re: proposal to make SIZE_TYPE more flexible
On Fri, 20 Dec 2013, DJ Delorie wrote: > > This seems mostly plausible, though I don't see anything to ensure that > > __intN does not exist at all if the size matches one of the standard C > > types, or if the mode fails targetm.scalar_mode_supported_p. > > What do we check against for this? Is there some table of standard > types we can read the bitsize of in toplev.c, or should we use the > macros as below? What about float/vector/complex types? I assume we > don't check those since the __intN types are integer types. I think using the macros for type sizes is fine, and float / vector / complex types are completely irrelevant to this (so standard_type_bitsize should maybe be standard_integer_type_bitsize). > Also, should we special-case the int128 case so we always get __int128 > if the backend supports TImode? No, the (TImode, __int128) pair should be handled the same way as all the other __intN types rather than special-cased (of course you should ensure the patch does not end up changing the set of configurations for which __int128 is available). -- Joseph S. Myers jos...@codesourcery.com
Re: proposal to make SIZE_TYPE more flexible
> This seems mostly plausible, though I don't see anything to ensure that
> __intN does not exist at all if the size matches one of the standard C
> types, or if the mode fails targetm.scalar_mode_supported_p.
What do we check against for this? Is there some table of standard
types we can read the bitsize of in toplev.c, or should we use the
macros as below? What about float/vector/complex types? I assume we
don't check those since the __intN types are integer types.
Also, should we special-case the int128 case so we always get __int128
if the backend supports TImode?
static bool
standard_type_bitsize (int bitsize)
{
if (bitsize == 128)
return false;
if (bitsize == CHAR_TYPE_SIZE
|| bitsize == SHORT_TYPE_SIZE
|| bitsize == INT_TYPE_SIZE
|| bitsize == LONG_TYPE_SIZE
|| bitsize == LONG_LONG_TYPE_SIZE)
return true;
return false;
}
GNU Tools Cauldron 2014 - Call for Abstracts and Participation
== GNU Tools Cauldron 2014 http://gcc.gnu.org/wiki/cauldron2014 Call for Abstracts and Participation 18-20 July 2014 Cambridge, England == We are pleased to announce another gathering of GNU tools developers. The basic format of this meeting will be similar to the previous meetings. The purpose of this workshop is to gather all GNU tools developers, discuss current/future work, coordinate efforts, exchange reports on ongoing efforts, discuss development plans for the next 12 months, developer tutorials and any other related discussions. This time we will meet in Cambridge, England from 18/Jul/2014 to 20/Jul/2014. Exact details on location and venue will be available shortly. We are inviting every developer working in the GNU toolchain: GCC, GDB, binutils, runtimes, etc. In addition to discussion topics selected at the conference, we are looking for advance submissions. If you have a topic that you would like to present, please submit an abstract describing what you plan to present. We are accepting three types of submissions: - Prepared presentations: demos, project reports, etc. - BoFs: coordination meetings with other developers. - Tutorials for developers. No user tutorials, please. Note that we will not be doing in-depth reviews of the presentations. Mainly we are looking for applicability and to decide scheduling. There will be time at the conference to add other topics of discussion, similarly to what we did at the previous meetings. To register your abstract, send e-mail to tools-cauldron-ad...@googlegroups.com. Your submission should contain the following information: Title: Authors: Abstract: If you intend to participate, but not necessarily present, please let us know as well. Send a message to tools-cauldron-ad...@googlegroups.com stating your intent to participate.
controlling the default C++ dialect
Hey all, this thread started on the libstdc++ list where I asked a couple of questions about patching std::string for C++11 compliance. I have figured how to do that and it yields a library that only works in the C++11 mode. This is not an issue here as we deploy a versioned runtime into a specific path. However, the whole thing is a bit inconvenient to C++ devs as they have to pass -std=c++11 to get anything done. So, my question is - how do I patch the notion of the "default" C++ dialect that gcc has? I have patched "cxx_dialect" in gcc/c-family/c-common.c, yet that is not enough. Is there some other thing that overwrites the default? Thanks in advance, Oleg.
Re: Remove spam in GCC mailing list
Stop banning this sender. Since we want to clean up spam in GCC mailing list. If you want to restore your Mozilla Bugzilla account (seotaewong40), you want to contact Mozilla Bugzilla. You want to add posting permissions to wine-devel mailing list for seotaewong40 gmail com mail address.
GCC 4.9.0 Status Report (2013-12-20)
Status == The trunk remains in Stage 3 until the end of January at which point we enter regression-and-doc-fixes-only mode. Quality is improving slowly as we are still getting a lot of new regressions, both due to increased testing and still merging a lot of code (please slow down and consider pushing back features for GCC 4.10). Quality Data Priority # Change from last report --- --- P1 56- 7 P2 127- 9 P3 21+ 10 --- --- Total 204- 6 Previous Report === http://gcc.gnu.org/ml/gcc/2013-11/msg00435.html The next report will be sent when we leave Stage 3.
Re: proposal to make SIZE_TYPE more flexible
On Thu, 19 Dec 2013, DJ Delorie wrote: > Where is the right place to set the array of "this __intN mode is > enabled" flags? I initially set it in tree.c where __int128 is set > up, but that happens *after* c_parse_init() needs the flag to set up > the RID_* keywords for them. Maybe immediately after the call to init_adjust_machine_modes from do_compile? (It can't actually be inside backend_init, since it needs to happen even if just preprocessing - whether __SIZEOF_INT128__ gets defined depends on __int128 availability, and presumably you'll have such __SIZEOF_INT__ macros for whichever such types are available - in which case no_backend is true.) -- Joseph S. Myers jos...@codesourcery.com
