Re: ABI compatibility regression: Return values on x86
H.J. Lu writes: > On Mon, Jan 07, 2008 at 06:32:08PM +, Andrew Haley wrote: > > > > So, what now? Can we even agree about what the psABI actually says > > about sign-extending result values? Was what we did before correct, > > or what we do now? I don't believe that it doesn't matter. > > You can follow up with this thread in ia32 psABI discussion group: > > http://groups.google.com/group/ia32-abi/browse_thread/thread/f47e0106b21d9269 Thanks for the reference. The attitude there looks surprisingly complacent, but if Intel and gcc x86 maintainers agree that it doesn't matter I suppose I'll have to defer to the weight of opinion. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903
Re: ABI compatibility regression: Return values on x86
On Tue, Jan 08, 2008 at 01:57:50PM +, Andrew Haley wrote: > H.J. Lu writes: > > On Mon, Jan 07, 2008 at 06:32:08PM +, Andrew Haley wrote: > > > > > > So, what now? Can we even agree about what the psABI actually says > > > about sign-extending result values? Was what we did before correct, > > > or what we do now? I don't believe that it doesn't matter. > > > > You can follow up with this thread in ia32 psABI discussion group: > > > > > http://groups.google.com/group/ia32-abi/browse_thread/thread/f47e0106b21d9269 > > Thanks for the reference. The attitude there looks surprisingly > complacent, but if Intel and gcc x86 maintainers agree that it doesn't > matter I suppose I'll have to defer to the weight of opinion. > My understanding is either way is ia32 psABI compliant. If the caller code generated by gcc is ia32 psABI compliant, that is --- callers need to assume that return value is in %al/%ax and that the upper bits of %eax are undefined. If the caller needs a 32-bit sign- or zero-extended value, it needs to do the extend itself. --- it shouldn't be a problem. H.J.
Re: ABI compatibility regression: Return values on x86
H.J. Lu writes: > On Tue, Jan 08, 2008 at 01:57:50PM +, Andrew Haley wrote: > > H.J. Lu writes: > > > On Mon, Jan 07, 2008 at 06:32:08PM +, Andrew Haley wrote: > > > > > > > > So, what now? Can we even agree about what the psABI actually says > > > > about sign-extending result values? Was what we did before correct, > > > > or what we do now? I don't believe that it doesn't matter. > > > > > > You can follow up with this thread in ia32 psABI discussion group: > > > > > > > > http://groups.google.com/group/ia32-abi/browse_thread/thread/f47e0106b21d9269 > > > > Thanks for the reference. The attitude there looks surprisingly > > complacent, but if Intel and gcc x86 maintainers agree that it doesn't > > matter I suppose I'll have to defer to the weight of opinion. > > > > My understanding is either way is ia32 psABI compliant. If the > caller code generated by gcc is ia32 psABI compliant, that is > > --- > callers need to assume that return value is in %al/%ax and that > the upper bits of %eax are undefined. If the caller needs a 32-bit > sign- or zero-extended value, it needs to do the extend itself. > --- > > it shouldn't be a problem. Sure, but it doesn't say "callers need to assume ... are undefined" in the psABI; AFAICS the Intel engineers just made that up. I suppose you could argue that if it isn't explicitly stated there's no guarantee, but I didn't read it that way. The core problem is that the psABI is very badly worded. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903
Re: ABI compatibility regression: Return values on x86
On Tue, Jan 08, 2008 at 02:20:38PM +, Andrew Haley wrote: > guarantee, but I didn't read it that way. The core problem is that > the psABI is very badly worded. Bad wording isn't the only problem :-(. That is why there is an ia32 psABI discussion group. You can bring up any ia32 psABI issues there. H.J.
RE: __builtin_expect for indirect function calls
On 08 January 2008 15:36, Dave Korn wrote: > On 07 January 2008 21:15, Mark Mendell wrote: > >> A question was raised: Are side effects in the second parameter guaranteed >> to be executed? Is it valid for a compiler to ignore any side effects? > > That perked up my curiosity: > > " The value of C must be a compile-time constant. " > > Can a compile-time constant have run-time side-effects? I couldn't think > up an example off the top of my head... Ah, I thought of one, nevermind, sorry for the noise... cheers, DaveK -- Can't think of a witty .sigline today
RE: __builtin_expect for indirect function calls
On 07 January 2008 21:15, Mark Mendell wrote: > A question was raised: Are side effects in the second parameter guaranteed > to be executed? Is it valid for a compiler to ignore any side effects? That perked up my curiosity: " The value of C must be a compile-time constant. " Can a compile-time constant have run-time side-effects? I couldn't think up an example off the top of my head... cheers, DaveK -- Can't think of a witty .sigline today
hard_regno_nregs == 0 ?
In rtlanal.c we have these lines: nregs_ymode = hard_regno_nregs[xregno][ymode]; ... && (GET_MODE_SIZE (ymode) % nregs_ymode) == 0) The m32c cc1 crashes here because xregno is 1 and ymode is QI, and register 1 cannot hold a QI value (there are no QImode ops that take that register), so hard_regno_nregs[1][QI] is zero, which causes a SIGFPE. Which assumption is wrong? That hard_regno_nregs can be zero (m32c), or that hard_regno_nregs will never be zero (rtlanal)?
Changes in C++ FE regarding pedwarns to be errors are harmful
Hi all, Looks like gcc 4.3 has some rather inconvenient changes in C++ FE, with the latest trunk. Lets see with an example : [~]> cat test.cpp #define foo bar #define foo baz [~]> g++ -c test.cpp test.cpp:2:1: error: "foo" redefined test.cpp:1:1: error: this is the location of the previous definition I don't know the reasoning behind this change but this breaks many C++ programs unless -fpermissive is used. Why? Because everybody loves to install their own config.h (Python, libmp4v2 being nice examples) which just carelessly #define anything its asked for with ifndef ... endif . Now flash back to real world: this breaks any C++ application that uses Python, libmp4v2, libjpeg and possibly many others. And I think this is a real bad behaviour change and I am not sure if its worth all the trouble. So I am asking, would C++ FE maintainers would agree to revert this into a warning as in C FE now. I welcome and value your comments, so please speak up. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
On Tue, Jan 08, 2008 at 11:28:22PM +0200, Ismail Dönmez wrote: > Hi all, > > Looks like gcc 4.3 has some rather inconvenient changes in C++ FE, with the > latest trunk. Lets see with an example : > > [~]> cat test.cpp > #define foo bar > #define foo baz > > [~]> g++ -c test.cpp > test.cpp:2:1: error: "foo" redefined > test.cpp:1:1: error: this is the location of the previous definition > > I don't know the reasoning behind this change but this breaks many C++ > programs unless -fpermissive is used. Why? Because everybody loves to install > their own config.h (Python, libmp4v2 being nice examples) which just > carelessly #define anything its asked for with ifndef ... endif . > > Now flash back to real world: this breaks any C++ application that uses > Python, libmp4v2, libjpeg and possibly many others. And I think this is a > real bad behaviour change and I am not sure if its worth all the trouble. There's certainly an argument that this change is ill-advised. However, your statements in the last paragraph aren't true: most quality open source projects have a "no warnings" rule (or at least try to eliminate warnings), and most programmers know about #undef. Since people have already built whole distros with the gcc from the trunk, clearly they are managing to build C++ applications that use Python, libmp4v2, libjpeg etc.
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
On Jan 8, 2008 10:34 PM, Joe Buck <[EMAIL PROTECTED]> wrote: > On Tue, Jan 08, 2008 at 11:28:22PM +0200, Ismail Dönmez wrote: > > Hi all, > > > > Looks like gcc 4.3 has some rather inconvenient changes in C++ FE, with the > > latest trunk. Lets see with an example : > > > > [~]> cat test.cpp > > #define foo bar > > #define foo baz > > > > [~]> g++ -c test.cpp > > test.cpp:2:1: error: "foo" redefined > > test.cpp:1:1: error: this is the location of the previous definition > > > > I don't know the reasoning behind this change but this breaks many C++ > > programs unless -fpermissive is used. Why? Because everybody loves to > > install > > their own config.h (Python, libmp4v2 being nice examples) which just > > carelessly #define anything its asked for with ifndef ... endif . > > > > Now flash back to real world: this breaks any C++ application that uses > > Python, libmp4v2, libjpeg and possibly many others. And I think this is a > > real bad behaviour change and I am not sure if its worth all the trouble. > > There's certainly an argument that this change is ill-advised. However, > your statements in the last paragraph aren't true: most quality open > source projects have a "no warnings" rule (or at least try to eliminate > warnings), and most programmers know about #undef. Since people have > already built whole distros with the gcc from the trunk, clearly they > are managing to build C++ applications that use Python, libmp4v2, libjpeg > etc. Yep, in the worst case we stick a -fpermissive in. See also PR33907 for more obscure cases of the standard. Richard.
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
Tuesday 08 January 2008 23:34:13 tarihinde Joe Buck şunları yazmıştı: > There's certainly an argument that this change is ill-advised. However, > your statements in the last paragraph aren't true: most quality open > source projects have a "no warnings" rule (or at least try to eliminate > warnings), and most programmers know about #undef. Interesting assumption because knowing about #undef doesn't cut it because autoconf will happily #define without ifndef etc. > Since people have already built whole distros with the gcc from the trunk, > clearly theyare managing to build C++ applications that use > Python,libmp4v2, libjpeg etc. Yes true because they use -fpermissive which will let this error into a warning, which also suggests this change is not good. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
On 1/8/08, Ismail Dönmez <[EMAIL PROTECTED]> wrote: > Tuesday 08 January 2008 23:34:13 tarihinde Joe Buck şunları yazmıştı: > > There's certainly an argument that this change is ill-advised. However, > > your statements in the last paragraph aren't true: most quality open > > source projects have a "no warnings" rule (or at least try to eliminate > > warnings), and most programmers know about #undef. > > Interesting assumption because knowing about #undef doesn't cut it because > autoconf will happily #define without ifndef etc. The other thing is before this change, the C++ front-end was inconstaint with the preprocessor and now it is constaint. So adding -pedantic-errors made those warnings into errors while doing -pedantic-errors -fpermissive will still kept them as errors. As shown by: [EMAIL PROTECTED]:~$ ~/x86-linux-4.0.2/bin/gcc t.cc -pedantic-errors -fpermissive t.cc:2:1: error: "a" redefined t.cc:1:1: error: this is the location of the previous definition [EMAIL PROTECTED]:~$ ~/x86-linux-4.0.2/bin/gcc t.cc t.cc:2:1: warning: "a" redefined t.cc:1:1: warning: this is the location of the previous definition /usr/lib/crt1.o(.text+0x18): In function `_start': ../sysdeps/i386/elf/start.S:98: undefined reference to `main' collect2: ld returned 1 exit status Thanks, Andrew Pinski
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
Hi Manuel, Wednesday 09 January 2008 00:28:54 tarihinde Manuel López-Ibáñez şunları yazmıştı: > I implemented the change as the fix to a bug that was reported by > fellow (and more senior) GCC developers. Let me try to explain > (although, I hoped that it will be fairly clear from > gcc.gnu.org/gcc-4.3/changes.html). Yeah I know this change is documented at least. > We have a series of diagnostics that are important or required by the > standard (or both). Those are called pedwarns. It is an unfortunate > name for two reasons: 1) Not all pedwarns are enabled by -pedantic, > some are enabled by default; and 2) pedwarns can be either warnings or > errors, and what they are depends on command-line options and the > default of each front-end. In fact, pedwarnss are warnings by default > in the C front-end. But they are errors by default in the C++ > front-end unless you use -fpermissive so they are downgraded to > warnings. > > Before GCC 4.3, the C++ preprocessor was ignoring the default of the > C++ front-end. In fact, there was an inconsistence between the > settings of the C++ preprocessor and the settings of the C++ > front-end. It worked for a few things (-pedantic-errors worked fine), > but not for others (the default settings and the effect of > -fpermissive). The inconsistency was evident in the code and if you > played with combinations of -pedantic-errors and -fpermissive. Oh that clears up my confusion. So the right fix would be downgrading this redefinition problem to be pedwarn instead. But I see no point in creating a bug report if its just gonna be closed as invalid, so I hope we can discuss if its feasible to downgrade this error to be a pedwarn. What I see right now this distributions plug -fpermissive in and just go away. But I don't like workarounding gcc this way. I hope we can all agree that downrading this error to be a pedwarn is the correct way to go. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
On 08/01/2008, Ismail Dönmez <[EMAIL PROTECTED]> wrote: > > Oh that clears up my confusion. So the right fix would be downgrading this > redefinition problem to be pedwarn instead. But I see no point in creating a > bug report if its just gonna be closed as invalid, so I hope we can discuss > if its feasible to downgrade this error to be a pedwarn. > > What I see right now this distributions plug -fpermissive in and just go away. > But I don't like workarounding gcc this way. I hope we can all agree that > downrading this error to be a pedwarn is the correct way to go. > I am sorry you didn't understand my email and didn't read it completely. I tried my best. Cheers, Manuel.
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
On 08/01/2008, Ismail Dönmez <[EMAIL PROTECTED]> wrote: > Tuesday 08 January 2008 23:34:13 tarihinde Joe Buck şunları yazmıştı: > > > Since people have already built whole distros with the gcc from the trunk, > > clearly theyare managing to build C++ applications that use > > Python,libmp4v2, libjpeg etc. > > Yes true because they use -fpermissive which will let this error into a > warning, which also suggests this change is not good. > Hi Ismail, I implemented the change as the fix to a bug that was reported by fellow (and more senior) GCC developers. Let me try to explain (although, I hoped that it will be fairly clear from gcc.gnu.org/gcc-4.3/changes.html). We have a series of diagnostics that are important or required by the standard (or both). Those are called pedwarns. It is an unfortunate name for two reasons: 1) Not all pedwarns are enabled by -pedantic, some are enabled by default; and 2) pedwarns can be either warnings or errors, and what they are depends on command-line options and the default of each front-end. In fact, pedwarnss are warnings by default in the C front-end. But they are errors by default in the C++ front-end unless you use -fpermissive so they are downgraded to warnings. Before GCC 4.3, the C++ preprocessor was ignoring the default of the C++ front-end. In fact, there was an inconsistence between the settings of the C++ preprocessor and the settings of the C++ front-end. It worked for a few things (-pedantic-errors worked fine), but not for others (the default settings and the effect of -fpermissive). The inconsistency was evident in the code and if you played with combinations of -pedantic-errors and -fpermissive. I hope you see. It is not that we decided that some warnings should actually be errors. It is that those warnings belong to a group of diagnostics that were supposed to be errors by default. Of course, we can discuss whether those warnings (or a particular one) should be enabled by default, or whether they (or a particular one of them) should belong to that group of diagnostics (pedwarns) or whether pedwarns should be errors by default in C++ front-end. I was hoping those discussions would arise but it didn't happen. It seems people just used -fpermissive or fixed the warning. For your particular example, you could open a regression bug against 4.3 that says: * '"foo' redefined" is not mandated by the standard or it is not serious enough, so it should not be a pedwarn just a normal warning; or * "'foo' redefined", although mandated by the standard, is a nuisance and irrelevant, it should only be active when -pedantic is given and not by default. The fixes to those are one-liners once the correct decision is made. I volunteer (in fact, I have volunteered repeatedly) to implement, test and commit the changes needed. But I don't consider that I have the expertise to make the correct decision. But reverting my patch is just a quick hack that won't fix anything for long, since in the future the preprocessor will probably use the same diagnostic machinery that the front-ends, making impossible the inconsistency described above and, thus, bringing up this whole issue again. I hope I have been clear in my explanation. Cheers, Manuel.
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
On 1/8/08, Ismail Dönmez <[EMAIL PROTECTED]> wrote: > Oh that clears up my confusion. So the right fix would be downgrading this > redefinition problem to be pedwarn instead. But I see no point in creating a > bug report if its just gonna be closed as invalid, so I hope we can discuss > if its feasible to downgrade this error to be a pedwarn. It is already a pedwarn. Just the C++ front-end enables pedwarn as being errors by default and downgrades them as being warnings with -fpermissive. This is the whole point of -fpermissive. Thanks, Andrew Pinski
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
Wednesday 09 January 2008 00:51:32 tarihinde şunları yazmıştınız: > > Oh that clears up my confusion. So the right fix would be downgrading > > this redefinition problem to be pedwarn instead. But I see no point in > > creating a bug report if its just gonna be closed as invalid, so I hope > > we can discuss if its feasible to downgrade this error to be a pedwarn. > > > > What I see right now this distributions plug -fpermissive in and just go > > away. But I don't like workarounding gcc this way. I hope we can all > > agree that downrading this error to be a pedwarn is the correct way to > > go. > > I am sorry you didn't understand my email and didn't read it > completely. I tried my best. Sorry for misunderstanding, Andrew pointed out how I get it all wrong. Reading your mail again, you propose two possible fixes. Like you I am not in the position to see which would be the best solution. So we need C++ FE maintainers to comment if they agree with one of those fixes at least. Though for me the first solution looks more plausible. Thanks again, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
[RFC] porting to gcc-4.3 docs
Hello all. As many know, various linux distributors are working on re-compiling their distros with GCC mainline in the hopes of helping GCC 4.3 stabilize. As part of this effort, many bugs have been filed in GCC bugzilla, and many portability issues have been identified. Attached is a rough cut of a detailed portability document for GCC 4.3, compiled with the assistance of Fedora and Debian activists. (Particular thanks to Jakub J and Martin Michlmayr). Currently it lists the major issues each distribution has found when upgrading (minus ICE type errors). It is our goal to have a detailed guide for users of GCC who wish to upgrade, hosted on the gcc.gnu.org site. Although we'd initially thought of putting this on the GCC wiki, the current thought is a better placement would be to put this alongside the release notes, ie: http://gcc.gnu.org/gcc-4.3/changes.html would be joined by http://gcc.gnu.org/gcc-4.3/porting_to.html This would imply that the porting document would be checked in to wwwdocs and available to all the usual GCC contributors to edit and update. As such, I'd like to get a general indication from the greater GCC community as to this plan. Does this document seem like a good idea? (Previously, we've left this kind of document to the user community. Often the passage of time has not been particularly kind to these links.) Is the suggested placement ok for everybody? If this is ok, some editing of duplicate info from changes.html should take place. I volunteer to do this. And, finally, we'd need an ok from the wwwdocs head dude, Gerald. Thoughts and comments? best, benjamin porting_to_gcc43.html.bz2 Description: application/bzip
Re: [RFC] porting to gcc-4.3 docs
> Attached is a rough cut of a detailed portability document I also put this up here temporarily: http://people.redhat.com/~bkoz/porting_to_gcc43.html -benjamin
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
Hi again, Wednesday 09 January 2008 00:28:54 tarihinde Manuel López-Ibáñez şunları yazmıştı: > For your particular example, you could open a regression bug against > 4.3 that says: > * '"foo' redefined" is not mandated by the standard or it is not > serious enough, so it should not be a pedwarn just a normal warning; > or Looks like this is actually mandated by standard :-( , thats what I am told on #gcc anyway :) > * "'foo' redefined", although mandated by the standard, is a nuisance > and irrelevant, it should only be active when -pedantic is given and > not by default. I am not sure if this is irrelevant for all cases, so the current behaviour looks correct. The right way would be fixing all those apps not installing their config.h and not pollute global namespace but thats a huge task given that many projects are affected. So for now I guess we'll have to stick to -fpermissive. Thanks for your time and patience. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
Re: [RFC] porting to gcc-4.3 docs
On Tue, Jan 08, 2008 at 06:41:37PM -0600, Benjamin Kosnik proposes: > http://gcc.gnu.org/gcc-4.3/changes.html > > would be joined by > > http://gcc.gnu.org/gcc-4.3/porting_to.html > > This would imply that the porting document would be checked in to > wwwdocs and available to all the usual GCC contributors to edit and > update. Fine with me; it should be linked from the "Caveats" section of gcc-4.3/changes.html. > Thoughts and comments? Saw one error: - Another preprocessor warning change is for trailing whitespace after and #endif, code like: #ifdef TEST #endif TEST - s/trailing whitespace after and/extra tokens after an/ It's, of course, legal to have trailing whitespace and comments after an #endif.
about regenerate new configure script file
Hi, All. I don't know How to regenerate a new configure file while added new target on config.sub, and gcc/config.gcc. I am a newcomer in using GCC. Thank you very much. ___ 雅虎邮箱传递新年祝福，个性贺卡送亲朋！ http://cn.mail.yahoo.com/gc/index.html?entry=5&souce=mail_mailletter_tagline
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
On 09/01/2008, Ismail Dönmez <[EMAIL PROTECTED]> wrote: > > Looks like this is actually mandated by standard :-( , thats what I am told on > #gcc anyway :) > Not surprising since it is a pedwarn. It would be nice to point to the relevant sections of the standard in the code as a comment, if you know them. We do this for other pedwarns. > I am not sure if this is irrelevant for all cases, so the current behaviour > looks correct. The right way would be fixing all those apps not installing > their config.h and not pollute global namespace but thats a huge task given > that many projects are affected. > > So for now I guess we'll have to stick to -fpermissive. Thanks for your time > and patience. > Of course there is a third option: * Make pedwarns warnings by default unless -Werror or --pedantic-errors are given (just like the C front-end). I personally think that being pedantic when you have the possibility of being permissive is not nice. In the current situation, it makes completely sense to use -fpermissive always for the user flags (as opposed to flags used during development) in a similar way as it makes sense to never use -Werror for user flags. The next step is asking why -fpermissive is not the default. However, I was not around when this decision was taken, so there may have been very good reasons for the current default. And perhaps those reasons are still relevant nowadays. Cheers, Manuel.
