Re: Enquiry
On 1/30/22 11:58, Jakub Jelinek wrote:
On Sun, Jan 30, 2022 at 10:50:56AM +, Jonathan Wakely wrote:
We could put a trap instruction at the end of the function though, which
would make the result a bit less arbitrary.
I've come around to thinking that's preferable for cases like this.
Depends on which exact cases.
Because for
int foo (int s) { if (s == 123) return 1; }
we want to optimize it into
return 1;
rather than if (s == 123) return 1; else __builtin_trap ();
For debugging we have -fsanitize=undefined
Jakub
I understand completely, it is undefined behaviour. What I had not
realized is that undefined behaviour
is not a property of the function itself, but of the function call when
parameters are specified. That seems
more difficult to handle from the compiler perspective, but if that is
the rule, so be it...
It seems to me that this is a case that just makes things more
complicated for programmers (and compiler developers) for the benefit
of only a small community which will know the precise limits of the
undefined behaviour and would like to play at the boundary of the cliff.
Honestly, for the user perspective (or more exactly a majority of
users), it would be nice if there was a way to catch such situations at
compile time (making of course more strict assumptions on the compiler
side). Of course, I can fire gdb or -fsanitize=undefined, but
whatever can be caught earlier is better I will turn that specific
warning into a an error with -Werrror=XXX for my own usage.
Thank's for the explanations. At least, I learned something. Hope I did
not waste too much of your time.
Theo.
Re: Enquiry
On 1/30/22 12:17, Jonathan Wakely wrote: Meta-comment: a subject line of "Enquiry" is very vague, and most commonly used by spammers and phishers. Your enquiry is about undefined behaviour due to a missing return, which would have been a much better subject. Indeed. Did not realize that. Will make more attention next time. Theo.
Enquiry
Before creating a bug report, I want to check with the GCC community
(all the more that checking that the problem has not yet been reported
is complicated at leat for me).
The following (admitedly buggy) program generates a segmentation
violation on fedora 35 (this is with g++ 11.2.1 20211203 (Red Hat
11.2.1-7) (GCC))
when compiled with -O3 (other versions replacing unisgned by std::string
may trigger the exception instead of the segv)
bool assert_sthg(const unsigned s) {
if (s==123)
throw 1;
}
int main() {
assert_sthg(0);
return 0;
}
When compiling, we indeed get a warning:
test.C:4:1: warning: control reaches end of non-void function
[-Wreturn-type]
I can well understand that the program being buggy that the optimizer is
allowed to do anything including the observed segmentation violation.
Yet the result is quite surprising
The question is, in that case, wouldn't it be better to turn the warning
into an error at -O3 ?
Thank's for any input.
Theo.
Re: Mailing list reconfiguration: VERP Sender: header affected
On 6/3/21 5:10 PM, D. Hugh Redelmeier wrote: | From: Martin Liška | Which we recommend in the ection Filtering here: | https://gcc.gnu.org/lists.html Thanks for the useful information. That document suggests: * ^List-Id: .*<.*.gcc.gnu.org>$ Surely this should be: * ^List-Id: .*<.*.gcc\.gnu\.org>$ Or even: * ^List-Id: .*<.*\.gcc\.gnu\.org>$
Re: [PATCH] Update comment of removed options.
On 9/9/19 1:34 PM, Jonathan Wakely wrote: frepo C++ ObjC++ Deprecated Deprecated in GCC 10. This switch has no effect. >>> >>> This first part looks wrong to me. >>> "deprecated >>> (computing) Obsolescent; said of a construct in a computing language >>> considered old, >>> and planned to be phased out, but still available for use." > > I agree with this definition. If it's deprecated it still needs to be > available for use. > Pedantically, the flag is deprecated but the functionality is removed. If the intent, is to remove the flag after a while, it might be nice to say that the use of the flag is deprecated... 0x12BF16AD4F273D5D.asc Description: application/pgp-keys
Re: RFC: Improving GCC8 default option settings
On 09/12/2017 05:32 PM, Andrew Pinski wrote: > .On Tue, Sep 12, 2017 at 8:29 AM, Theodore Papadopoulo > wrote: >> Another one that might be interesting is -funsafe-loop-optimizations. >> In most cases people write loops assuming simple finite loops (no >> overflow). Crippling optimization for the small amount of people (system >> programmers ?) that use such strange loops seems counterproductive. It >> would be best if such loops can be marked with an attribute in some way >> and that the general case just assumes that all loops are finite... > > -funsafe-loop-optimizations is a nop in GCC 7 and above. > Since https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00956.html . > > Thanks, > Andrew > Thank's for the notice. For some reason, I missed that piece of information... Too bad that making such an assumption generates bogus code in some common cases. Theo. 0x4F273D5D.asc Description: application/pgp-keys
Re: RFC: Improving GCC8 default option settings
Another one that might be interesting is -funsafe-loop-optimizations. In most cases people write loops assuming simple finite loops (no overflow). Crippling optimization for the small amount of people (system programmers ?) that use such strange loops seems counterproductive. It would be best if such loops can be marked with an attribute in some way and that the general case just assumes that all loops are finite... 0x4F273D5D.asc Description: application/pgp-keys
Re: Unifying the GCC Debugging Interface
On 11/21/2012 02:01 AM, Xinliang David Li wrote: Right -- gdb does not know the complete type of std::cout and std::cerr -- try the following program with -g and invoke print, or << in the debugger -- see what you will get: But that also suggest that the debugging experience needs for some improvement Everyone will win if this works better Slightly off topic of course, but... Theo.
Re: wish: generation of type annotation for C++11 code.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/11/2011 08:59 AM, Joe Buck wrote: > On Thu, Nov 10, 2011 at 10:04:34PM -0800, Gabriel Dos Reis wrote: >> On Thu, Nov 10, 2011 at 10:12 AM, Jonathan Wakely >> wrote: >> >>> Adding this to GCC seems like a total waste of time, write a >>> dwarf processor that dumps the info you want. >>> >> >> Agreed. >> >> I suspect there is a misunderstanding of what 'auto' means in >> C++. Furthermore, I think the step is completely backward. > > Yes, the reason I'm delighted with auto is that there are cases > where I do not want to know the type (or I want to write generic > code that will work with different kinds of containers). For > > std::multimap amap; > > when I write > > auto ipair = amap.equal_range(key); for (auto iter = ipair.first; > iter != ipair.second; ++iter) do_something_with(iter->first, > iter->second); > > I explicitly do not want to know the details of the ridiculously > hairy type of ipair. If you want to know, it is > > std::pair::iterator,std::multimap::iterator> > > and that's with the defaulted template parameters omitted. Sorry to jump in But it is when you write auto ipair = amap.equal_range(key); that you may want to know that this type is a pair and that you can write ipair.first and ipair.second. Of course equal_range is not the best example, but I can very well imagine that with the generalization of auto use and with third party libraries it might become very difficult/boring to track the actual return type of a function (imagine a serie of functions all using auto as return type) Theo. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6+NMcACgkQEr8WrU8nPV0B/ACgrXULv56/t8LB8sPlIgc3Le/z fHkAn2+jXqM6L/vauoJe0+XcVYk/6yAe =184J -END PGP SIGNATURE-
Re: Why not contribute? (to GCC)
On 04/24/2010 09:35 PM, Thomas Neumann wrote: What reasons keep you from contributing to GCC? I tried this a while ago, but ultimately gave up because I could not get my patches in. Some were applied, but many never made it. Admittedly they were perhaps not of general interested, there were only improving compatibility of the gcc base with C++ (what Ian Lance Taylor then did later). The most frustrating part was not getting patches rejected (I could then improve them, after all), but having patches ignored. You submit a number of patches, and the result is... nothing. No response at all. Not exactly what encourages gcc as a free time activity. On the other hand I am a professional developer, too (even working on compilers), and I myself would perhaps also be reluctant to spend time on reviewing and merging patches that I do not really care about. So I understand the gcc developers. But it is still frustrating for outsiders. Sorry to reply so late (was away off internet for a while). From my experience, the reasons for not contributing are: - Code complexity: Doing even the simplest stuff in gcc requires quite some time to a newcomer. Occasionnally, I got some good advices which helped to produce a functional patch, but in many cases, having access to a simple hint (just to localize the actual code that needs to be modified) is often difficult. C does not help here (even though I'm fluent in that langage), but I do not want to re-open a war... - Time involvement: I can spend a few days (mostly over the week ends) or hours after work and can spend an equivalent amount of time for dealing with consequences of a patch. I cannot afford to spend weeks of work (except exceptionnaly if this relates to my work). On one occasion, I submitted a prototype patch to remove default template parameters with some questions whether the flag I used was really available and request for comments The only answer I got was to use the new (completely undocumented and un-comprehensible to me after a few days of struggling with it -- this was several years ago) error message system Not even one comment on the usefulness of the feature or on my questions, I decided that the patch would anyway be never accepted (at the time INRIA had no copyright agreement -- and I'm still not sure I'm covered now --), so I abandonned. Since then Paolo IIRC also proposed something (probably much more elaborated than what I did), still such a "trivial" (for me it was some effort) functionality is not available unless I'm wrong. I agree that this is a minor functionality, and typically the kind of effort that might interest a newcomer, but the effort to get accepted is/was just too high. - I'd like to help gcc not to fight/bother gcc people to get some more or less trivial stuff accepted. I can very well understand that they have more important things to do. I must say though that I see some maintainers spending time to answer beginner questions, and I appreciate. - Copyright assignment only comes fourth (and actually may be solved for me). I believe anyhow that most newcomers should first start with very small patches first (one liners, documentation, style, unused variables). But those patch are often ignored (again, I can understand that for a gcc developper that might not be worth the effort). - All in all, I believe that there is gap between skilled developpers and newcomers. Once one is skilled enough the list is very helpful. For newcomers, the answers form the list are just not reliable enough (in terms of useful answers). Again, I have seen recently some effort by a few developpers to anser basic questions and that's good. A slightly better way might be to offer mentorship (eventually pyramidal) on some small projects in order to help people jump in the bandwagon At least this is true for non-compiler people as I'm.
--enable-build-with-cxx bootstrap failure
I just tried to build gcc configuring it on x86_64-unknown-linux-gnu (Fedora 10) with: configure --enable-build-with-cxx --with-arch=core2 --with-tune=core2 --prefix=/usr/local/gcc-svn/ --enable-languages="c,c++" --enable-__cxa_atexit --disable-multilib --enable-libssp and ran into a bootstrap comparison failure... Same code without --enable-build-with-cxx seems fine. This is from trunk, rev 145701. Is this known, or should I file a bug report... By the way, it seems that libelf in fedora 10 seems to be good enough for lto (test are tried and passing with the non-cxx bootstrap). Theo. Here is the relevant part of the bootstrap failure: Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1plus-checksum.o differs Bootstrap comparison failure! x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/vec.o differs x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/eh_globals.o differs x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/eh_alloc.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/pool_allocator.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/locale.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/mt_allocator.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/atomic.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/basic_file.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/pool_allocator.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/locale.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/mt_allocator.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/atomic.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/basic_file.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/future.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/debug.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/locale_init.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/system_error.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/future.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/debug.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/locale_init.o differs x86_64-unknown-linux-gnu/libstdc++-v3/src/system_error.o differs make[2]: *** [compare] Error 1
Re: [PATCH] Adjust develop.html to reflect recent practice
Richard Guenther wrote: As commented to my last status report develop.html does not reflect reality anymore. The following tries to adjust it carefully in this respect. Schedule -Development on our main branch will proceed in three stages. Each -stage will be two months in length. +Development on our main branch will proceed in three stages. Just a minor tweak... Since there are only effectively two stages, wouldn't it be better to state two stages here ? Theo.
Re: My plans on EH infrastructure
I was wondering if loops of form for (i=0; ; i++) a[i] can be assumed finite because eventaully a[i] would get to unallocated memory otherwise. This is however similar to inifinite recursion Correct me if I'm wrong but this is definitely wrong... Assuming a 64bit processor and i to be a 32bits int (eg x86-64), it is possible to allocate a 4Gb array of chars and such a loop is definitely OK. It is somewhat similar to say that this loop: int array[256]; for (unsigned char i=0;;++i) array[i] = XXX; is finite, which is wrong.
Re: openMP gcc vs icc, erratic results with gcc
diego sandoval wrote: Hi everybody, I just started working with openMP, i installed first gcc-4.2.3 and then gcc-4.3.0, both of them having support for openMP. I tried a code to calculate the product \pi*\e. When i compile the code with gcc (both 4.2.3 and 4.3.0) withtout -fopenmp the result is correct. When i try with the -fopenmp option the result is erroneous. I also tried with the intel compiler icc (with -openmp) in order to verify the code correctness . There was no problem. I dont know what is wrong with gcc and this particular code but the results are erratic. If anyone of you can help me ... thanks in advance. I do not know where the problem lies but the good news seems to be that it is either corrected in the development version (gcc version 4.4.0 20080414 (experimental)), and/or it works fine on x86-64 (both 32 and 64 bit)... and I would not have expected such a speedup in the 64bit version (the timings are in milliseconds not in seconds)!! /usr/local/gcc/bin/gcc -fopenmp -O3 taylor.c ./a.out Reached result 8.539734 in 5650.000 seconds /usr/local/gcc/bin/gcc -fopenmp -O3 -m32 taylor.c ./a.out Reached result 8.539734 in 10410.000 seconds
Potential bug with g++ and OpenMP
The piece of code attached to this mail does not compile with 4.3.0 20070113
(sorry this is rather old, but that's what I had available). The
architecture (although not relevant IMHO)
is i686-pc-linux-gnu.
[ Even though this is not relevant here, a similar error happens with
the redhat version gcc-4.1.1 (although the message is slightly
different and more confusing). ]
I get the following error message:
-> g++ -fopenmp Test.C
Test.C: In constructor ‘R::R()’:
Test.C:18: error: invalid use of incomplete type ‘struct R::R()::B’
Test.C:9: error: declaration of ‘struct R::R()::B’
I really do not see why R::B is considered as an incomplete type at
this point (this seems related
to the use of "typename M::E", remove the template on M and everything
works fine).
Before cluttering the bug database, can someone confirm:
1) that indeed it looks like a bug (after all, I have been wrong
before... and I'm only starting with OpenMP),
2) that it still affects mainline.
I'll try to re-test with an up-to-date compiler tonigh (svn update in
progress, but that will take some time).
Thank's
// { dg-do compile }
// { dg-options "-fopenmp" }
//
// Copyright (C) 2007 Free Software Foundation, Inc.
// Contributed by Theodore.Papadopoulo 16 Apr 2007 <[EMAIL PROTECTED]>
#include
template struct A { A() {} };
struct M { typedef double E; };
template
struct R{
R() {
typedef A B;
B b;
#pragma omp parallel for firstprivate(b) schedule(guided)
for (int t=0;t<10;++t);
}
};
int
main() {
R r;
return 0;
}
Re: why are we not using const?
On Tue, 2006-06-27 at 13:51 +0100, Manuel López-Ibáñez wrote: > from comments in the #gcc irc channel, I understood that it is not > advisable for gcc patches to use the const qualifier in function > prototypes. I would like to understand why. Apart from its main > purpose, I believed that the use of 'const' helps the compiler to > optimise the code. Of course, I must be wrong, or the gains must be > very small compared with the reasons for not using 'const', which I > ignore. More than optimization, I think const is good for documentation. It shows at a glance what is supposed to change in the parameters of a function. Not that it gives you garanties, but at least it reflects the intent of the programmer. Theo.
Re: GCC FAIL WITH BASIC STL EXAMPLE
On Tue, 2006-05-02 at 08:26 -0700, trincheira wrote:
> Hello Guys,
>
> I am developing some applications that extensively uses STL. I plan to use
> the
> traits -> iterator_traits to get information about which type do I need to
> return.
> Unfortunately, I've been experienced some problems to use such
> functionality.
>
> This simple test code was extracted from the SGI-STL website, but oddly
> enough it doesn't compile:
> #include
> #include
> #include
> #include
>
> template
> std::iterator_traits::value_type
> last_value(InputIterator first, InputIterator last) {
> std::iterator_traits::value_type result = *first;
> for (++first; first != last; ++first)
> result = *first;
> return result;
> }
>
> using namespace std;
>
> int main()
> {
> std::vector teste(10);
> fill_n(teste.begin(),10,1.2);
> double result = last_value(teste.begin(),teste.end());
> return 0;
> }
I looks like one of your copy paste did not work correctly. There are
bunch of <> that are missing from your program. If it is just in the
email that those parts are missing try inserting a typename before
std::iterator_traits::value_type each time this construction appears...
gcc-prs mailing list archives
This is just to let you know that the gcc-prs mailing list archives seem to fail since June, 2004. Everything since then gives empty archives. If the list is closed (probably subsumed by bugzilla), maybe the best is to freeze the archive http://gcc.gnu.org/ml/gcc-prs/ Theo.
Re: The utility of standard's semantics for overflow
On Wed, 2005-06-29 at 11:32 +0300, Michael Veksler wrote: > This is unlike aliasing, when most lines of code out there, > did not break aliasing rules (even before they were > introduced). Int overflow is violated by most lines of > code I have seen (it is very uncommon to find code that > asserts no overflow before a+b). Believe it or not most uses of integral values are made in such a way that overflow is the exception rather than the rule (at least on general computers where the int arithmetic and the memory is cheap, in embeded system the situtation might differ somewhat even thought I have doubts if the embedded processors are of 32b class, for 8/16b processor the story is of course different). In most cases, the programmers choose the type to allow for all the standard cases and do not look at the possibility of overflow. How many loops are written using ints or unsigned for very small integers where even a short might be sufficient Untill now, there is a widespread assumption that 2^32 or 2^31 is equivalent to infinity for most purposes, because those numbers will never be reached (remember the unix clock ticks within a 32 bit unsigned, which still has a few (counted) years to go) in any practical situation (of course if a user wants to break the code and has switches to provide initial values. So unless you do arithmetics or combinatorics, most of the uses of "wide" (ie > 32b) integral types semantically (ie in the programmer's mind) assume that overflow does not happen in practise in the program.
Re: Do C++ signed types have modulo semantics?
On Tue, 2005-06-28 at 10:02 -0700, Mark Mitchell wrote:
> Joe Buck wrote:
> >
> > int blah(int);
> >
> > int func(int a, int b) {
> > if (b >= 0) {
> > int c = a + b;
> > int count = 0;
> > for (int i = a; i <= c; i++)
> > count++;
> > blah(count);
> > }
> > }
>
> Yes, I understand.
>
> I just didn't imagine that these kinds of opportunities came up very
> often. (Perhaps that's because I routinely write code that can't be
> compiled well, and so don't think about this situation. In particular,
> I often use unsigned types when the underlying quantity really is always
> non-negative, and I'm saddened to learn that doing that would result in
> inferior code.)
The real question is how often anyone is writing a loop (with an
unsigned of signed index) that is designed to wrap
So maybe at the end of this lengthy discussion, one decision to make is
introduce a flag -floop-index-may-wrap and assume by default that loop
indices never, ever go outside of the range of values allowed by the
underlying type (or the opposite if backward compatibility is judged
more important).
A few months ago, problems with integers that may possibly wrap was
found to be a major penalty for STL vectors because loops over iterators
were never unrolled (because the increment on pointers is 4 and the
unroller was not able to decide the finiteness of a loop in such a
case). Zdenek (I hope my memory does not misattribute the work)
corrected that for increments that are powers of 2 (in which case it is
easier to decide whether the loop is finite or not). The fact remains
that the loop unroller currently must be pessimist in many cases
assuming that the loop induction variable may wrap ending up in an
infinite loop
Re: libstdc++ soname and versioning (was: Re: Compiling GCC...)
On Wed, 2005-05-25 at 08:29 -0500, Gabriel Dos Reis wrote: > The project I'm proposing is not to move to C++. Just to move to the > intersection of C and C++, which is what we had agreed on in previous > discussions. Someone needs to implement those decisions, that is what > I'm trying to do (of course, anyone who can help is welcome). I know that, I was trying to find a compromise with respect to Zack's comment on freezing the C++ library ABI and of the potential future benefits. Now, if you need some help, and can set some focussed goals (to someone who does not know gcc internals so well), I can try. I think the work you do is a very useful step. > Then, whether GCC should actually use C++, simple overloading, super > inheritance and hyper though template hackery is completely separate > issue. We may have those discussions but if we're not actually in any > way to be able to test the conjectures, then the whole discussion is > pointless. Again, my mail was more an answer to the point 2) of Zack's idea: that 1) your work would be useful only if there is some transition to C++ and 2) thus a stable C++ library was need. I agree with all the comments you made that what you do is useful even if 1) is not a route that will be followed (at the very least, it opens the possibility). My remark was only concerning the point 2) that do not seem to me a necessary consequence of 1). I waited for someone else to make the comment, and to my surprise the discussion focussed of the need to freeze libstdc++, thus my posting. > When the time comes to actually introduce C++ in GCC, we could have > the discussion of what to freeze. As you may or may not have noticed, > libstdc++ people are trying hard to keep the ABI stable. It also has > its own downsides -- there are bugs that we cannot fix and they are > known and implemented improvements we cannot benefit from. Again I know that (at least to some extent). Again, all my apologies if my mail was hinting the opposite.
Re: libstdc++ soname and versioning
On Wed, 2005-05-25 at 14:48 +0200, Paolo Carlini wrote: > Just a quick comment: this is *already* happening, no doubts. We have > v6 since 3.4.0... I know (well almost) Apologies if my mail was suggesting the opposite. As you might have noticed, I tried to avoid to make too strong statements as I really know that there is some effort but have not followed exactly to what extent this goes. Thank's for clarifying this. If I said almost above is because, as far as I remember, Fedora Core 3, shipped with a 3.4 compiler and a preview 4.0 one that has uses the 3.4 library. Of course that does not necessarily means that ABI has changed but it surely somewhat confused me. On that topic, my point was more to say "give some warranty/promise". I know that all of you are working carefully to avoid ABI changes as much as possible, but as far as I know there is no statement like "The C ++ library will be kept stable till release X.Y". Pick the X and Y you are confortable with, and of course, if there is a huge problem then the promise will be broken. As far as I remember, this happened at least once with core C++ ABI with gcc-3.1, but overall after a very few wrong promises, the ABI is "effectively" frozen (actually there is still a pending core compiler ABI change pending)
Re: libstdc++ soname and versioning (was: Re: Compiling GCC...)
On Wed, 2005-05-25 at 10:37 +0200, Paolo Carlini wrote: > >>Why? To be honest, I keep harping on this mostly because I think it > >>should happen. All the C++-in-GCC noise is a digression. > [.] > In practice, we have got an handful of bugs unfixable within the > current > ABI (mostly already fixed in v7) and a major QoI issue (ref-counted > string vs MT) which certainly we don't want in anything > "definitive" (x). The real problem I think is not really casting an ABI in stone, but merely to have "some stability" over time. Maybe the only thing that is missing is a "commitment" of the C++ library ABI stable over a few (two, three ?) major gcc releases as there is one for the core compiler (and remember it took several releases to achieve it)... I agree that fixing the ABI for good is probably several years away, but user expectation of keeping some stability is also reasonable... I also believe making "some committment" (note that I clearly avoid to state which one and I really understand that already people try to make as little breakage as possible) helps to achieve the goal. So pushing up for a stable ABI is also a good thing. All that being said, I do not know why this C++ transition should be blocked by libstdc++ ABI stability. Given the history the GCC project and the amount of work (and the expected benefits) that would arise just from converting to a simple subset of C++ (class,some simple inheritance and maybe simple templates and no library stuff), I would argue that a lot of benefit could be gained already just with core C++ (ie without the library). And this limits the ABI breakage problem to libsupc++ for which (as I as I know) the problem is much simpler (at least it seems feasible to my unexperienced observer) Obviously, using the C++ library could bring some more benefits, but this seems clearly a second stage which could be done once the stdc++ library will freeze its ABI. SO THE QUESTION IS: is libsupc++ is a state for which its ABI can be freezed easily (I have not followed the topic closely enought to really know, but it really seems to me that the answer is yes). That being said, and to go back to the topic of freezing the libstdc++ ABI, maybe part of this work can be done immediately in the sense that if there are parts of the library (eg list or vector) that are simple enough and in a good state, then maybe it is possible to freeze those (eventually providing a library in two pieces one stable and one unstable), without freezing the whole ABI. Then immediately this part of the standard C++ library becomes usable per Zack's request... But obviously this C++ transition is plain science fiction for now... Still science fiction sometimes brings useful ideas so it needs to be considered. And actually, some science fiction creeps out of books much faster than expected, so I'm still hoping
Re: Proposed resolution to aliasing issue.
On Thu, 2005-05-12 at 10:01 -0700, Mark Mitchell wrote:
> Theodore Papadopoulo wrote:
> > On Wed, 2005-05-11 at 15:30 -0700, Mark Mitchell wrote:
> >
> > Given the following:
> >
> > struct A {
> > B& b1;
> > B& b2;
> > const B& b3;
> >
> > A(B& b): b1(b),b2(b),b3(b) { }
> > };
> >
> > Is the compiler allowed to suppress b2 and/or b3 from the layout of the
> > object. The next question comes when b1,b2 and b3 are in various places
> > in an inheritance path, would it be allowed to only keep the first
> > reference in this path (provided of course that it can be proved that
> > all references are bound to the same object).
>
> Tricky! Because you can't get the address of the reference, or form a
> pointer-to-member, it might be valid to do the optimization you suggest.
> Then again, there might be something lurking that I'm not thinking of.
> In any case, nobody does that optimization, and it would break the ABI.
Yeah I understand that. But one day I might want to evaluate the impact
of this (multiple references) in some of my codes (which of course
include many arrays which is where I would like to avoid some memory
explosion). Obviously, it is always possible to avoid it using simple
programming tricks but this somehow is less clean from the programmer
POV.
Anyway thank's a lot for the answer...
Theo.
Re: Proposed resolution to aliasing issue.
On Wed, 2005-05-11 at 15:30 -0700, Mark Mitchell wrote:
> Wolfgang Bangerth wrote:
> > Mark,
> > it occurred to me that asking the question you pose may use language that
> > is
> > more unfamiliar than necessary. How about this question instead -- assume
> >
> > struct S { int s; };
> > struct X {
> > int i;
> > struct S s;
> > };
> >
> > void g(struct S*);
> > void f() {
> > X x;
> > g(&x.s);
> > }
> >
> > Would the compiler be allowed to realize that X::i is never referenced and
> > therefore a dead variable? I assume the compiler doesn't do that right now,
> > but it would be straightforward for a scalar replacement algorithm to not
> > even allocate stack space for X::i, but only X::s, and hand the address of
> > the only remaining stack object, of type S, to g().
>
> I agree that this is the same issue, in another guise. My point of view
> is that this optimization would not be valid, pending clarification of
> the issues we've been discussing. As soon as any component of "x" is
> addressed, we must assume that all of "x" is addressed -- unless we can
> prove otherwise, by, say, looking at the body of "g".
Just a slightly dis-connected question (probably very academic):
Given the following:
struct A {
B& b1;
B& b2;
const B& b3;
A(B& b): b1(b),b2(b),b3(b) { }
};
Is the compiler allowed to suppress b2 and/or b3 from the layout of the
object. The next question comes when b1,b2 and b3 are in various places
in an inheritance path, would it be allowed to only keep the first
reference in this path (provided of course that it can be proved that
all references are bound to the same object).
gcc@gcc.gnu.org
On Wed, 2005-02-16 at 14:25 +0100, Richard Guenther wrote: > On Wed, 16 Feb 2005, Paul Schlie wrote: > Yes, of course, but it is the C frontent that is producing > &a + (int *)-4, not me. I'm just trying to work around this... > > In fact, it is c-common.c:2289 that does -4 -> (int *)-4 > conversion, but pointer_int_sum is already called with PLUS_EXPR. > build_unary_op unconditionally expands &x[y] to x+y, regardless > of the sign of y. Of course the standard says that they are equal. > But is &x[-1] == x + (int *)4*(int *)-1 ? From this follows that > we have no way to convert this back to &x[-1], as we loose the > sign information by the (int *) cast. Reading this thread, I keep wondering why this cast to an (int*). It should be a simple int no ?? If the intent is to have both operands of the PLUS to have the same type then it might be a counter-example for this rule (but I do understand that it would require specific patterns for pointer addition which is fairly stupid in general) Now, I'm not sure I understand the premisses of the discussion: &a [-4U/4] from &a[-1] are not written the same but still refer to the same value since the overflow happens the same when multiplying (unsigned)(-4) by 4... so I do not really see where is the problem. Then, I must add that I do not know much about the compiler's internals...
