Re: Problem compiling libstdc++ is current 4.0.2 cvs (volatile strikes again)
Your system is NOT supported by GCC, please read http://www.fsf.org/licensing/sco/ Perhaps you should read README.SCO at the top of the GCC tree? And for your information, SCO is supported by GCC. I am the maintainer, and a few malcontents like yourself aside, I have had little trouble doing so. Please do not confuse my personal contribution to open source with my employers position based on a legal matter that they are using the courts to address. I wish you much success and happiness. Kean
Re: Problem compiling libstdc++ is current 4.0.2 cvs (volatile strikes again)
--- Kean Johnston wrote: > Perhaps you should read README.SCO at the top of the > GCC tree? README.SCO contains: " The GCC team has been urged to drop support for SCO Unix from GCC, as a protest against SCO's irresponsible aggression against free software and GNU/Linux. We have decided to take no action at this time, as we no longer believe that SCO is a serious threat. For more on the FSF's position regarding SCO's attacks on free software, please read: http://www.fsf.org/licensing/sco/ " May be YOU should read it. ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
Re: Problem compiling libstdc++ is current 4.0.2 cvs (volatile strikes again)
The GCC team has been urged to drop support for SCO Unix from GCC, as a protest against SCO's irresponsible > aggression against free software and GNU/Linux. > We have decided to take no action at this time, as we no longer believe that SCO is a serious threat. What part of *NO ACTION* was unclear to you? For more on the FSF's position regarding SCO's attacks on free software, please read: http://www.fsf.org/licensing/sco/ Where in any of those pages does it state that GCC is not supported on SCO? Or that *any other GNU project* is not supported on SCO? I was taught never to enter a battle of wits with an unarmed opponent, so I shall simply exercise my right to ignore any future drivel from you. # find . -name ChangeLog\* | xargs grep -iE 'Haren|themis' | wc -l 0 # find . -name ChangeLog\* | xargs grep -iE 'kean|jkj' | wc -l 21 I rest my case. Kean
Re: Problem compiling libstdc++ is current 4.0.2 cvs (volatile strikes again)
--- Kean Johnston wrote: > > The GCC team has been urged to drop support for > SCO > > Unix from GCC, as a protest against SCO's > irresponsible > > aggression against free software and GNU/Linux. > > We have decided to take no action at this time, > as we > > no longer believe that SCO is a serious threat. > > What part of *NO ACTION* was unclear to you? You missed "The GCC team has been urged to drop support for SCO Unix from GCC, as a protest against SCO's irresponsible aggression against free software". ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
[BUG] gcc-3.4.5-20050531 (i386): __FUNCTION__ as a part of the printf's format argument
Such an example can't be compiled:
#include
void x()
{
printf(__FUNCTION__ "\n");
}
$ gcc printf.c -o fprintf
printf.c: In function `x':
printf.c:5: error: syntax error before string constant
Then, the problem is not printf-specific and is not depend of
. The next example gives the same error:
void y(const char *f, ...);
void z()
{
y(__FUNCTION__ "\n");
}
If some args are present in the ellipsis section (i.e. y(__FUNCTION__
": %s\n", "xxx")), the problem doesn't vanish. And, if __FILE__ is
used instead of __FUNCTION__, the problem is absent.
Re: [BUG] gcc-3.4.5-20050531 (i386): __FUNCTION__ as a part of the printf's format argument
On 7/25/05, Denis Zaitsev <[EMAIL PROTECTED]> wrote:
> Such an example can't be compiled:
>
>
> #include
>
> void x()
> {
> printf(__FUNCTION__ "\n");
> }
>
>
> $ gcc printf.c -o fprintf
> printf.c: In function `x':
> printf.c:5: error: syntax error before string constant
__FUNCTION__ expands to a variable. Use
printf("%s\n", __FUNCTION__);
instead. Btw, this list is for the development _of_ gcc, not with gcc.
Use gcc-help for that.
Richard.
>
> Then, the problem is not printf-specific and is not depend of
> . The next example gives the same error:
>
>
> void y(const char *f, ...);
> void z()
> {
> y(__FUNCTION__ "\n");
> }
>
>
> If some args are present in the ellipsis section (i.e. y(__FUNCTION__
> ": %s\n", "xxx")), the problem doesn't vanish. And, if __FILE__ is
> used instead of __FUNCTION__, the problem is absent.
>
Re: [BUG] gcc-3.4.5-20050531 (i386): __FUNCTION__ as a part of the printf's format argument
Richard Guenther wrote: >Btw, this list is for the development _of_ gcc, not with gcc. >Use gcc-help for that. > > By the way, since we have to point out that *so often*, maybe there is something wrong on our part: I wonder whether changing the names of those lists would help!?!? I don't know: gcc-development, gcc-users, ... Paolo.
Re: Problem compiling libstdc++ is current 4.0.2 cvs (volatile strikes again)
Haren Visavadia <[EMAIL PROTECTED]> writes: | --- Kean Johnston wrote: | > > The GCC team has been urged to drop support for | > SCO | > > Unix from GCC, as a protest against SCO's | > irresponsible | > > aggression against free software and GNU/Linux. | > > We have decided to take no action at this time, | > as we | > > no longer believe that SCO is a serious threat. | > | > What part of *NO ACTION* was unclear to you? | | You missed "The GCC team has been urged to drop | support for SCO Unix from GCC, as a protest against | SCO's irresponsible aggression against free software". Please stop your nonsensical selective quotes. If you're going to quote, please do so fully. Otherwise, refrain from spreading FUD. -- Gaby
Re: [BUG] gcc-3.4.5-20050531 (i386): __FUNCTION__ as a part of the printf's format argument
On Mon, Jul 25, 2005 at 10:51:23AM +0200, Richard Guenther wrote:
> On 7/25/05, Denis Zaitsev <[EMAIL PROTECTED]> wrote:
> > Such an example can't be compiled:
> >
> >
> > #include
> >
> > void x()
> > {
> > printf(__FUNCTION__ "\n");
> > }
> >
> >
> > $ gcc printf.c -o fprintf
> > printf.c: In function `x':
> > printf.c:5: error: syntax error before string constant
>
> __FUNCTION__ expands to a variable. Use
>
> printf("%s\n", __FUNCTION__);
>
> instead. Btw, this list is for the development _of_ gcc, not with gcc.
> Use gcc-help for that.
Ok, but such a code used to be compiled succesively with gcc for
years. Then, some change _in_ gcc has occured. That is why I've
posted to here.
Really, I've met the problem, when I was compiling the X Window System
system. The sources contain a lot of such an examples.
Re: [BUG] gcc-3.4.5-20050531 (i386): __FUNCTION__ as a part of the printf's format argument
Paolo Carlini wrote: By the way, since we have to point out that *so often*, maybe there is something wrong on our part: I wonder whether changing the names of those lists would help!?!? I don't know: gcc-development, gcc-users, ... one problem is that people often say something like: Btw, this list is for the development _of_ gcc, not with gcc. Use gcc-help for that. and then go on to answer any way, which somewhat undermines the msg, and encourages similar questions. i know that people are trying to be helpful, which is understandable, but ... also there is official gcc info suggesting asking this list for general help if gcc-help does not answer.
Re: [BUG] gcc-3.4.5-20050531 (i386): __FUNCTION__ as a part of the printf's format argument
Ok, but such a code used to be compiled succesively with gcc for years. Then, some change _in_ gcc has occured. That is why I've posted to here. Yes, it was deprecated in 3.1 (released three years ago) and removed in 3.3 (released two years ago). Paolo
GCC-3.4.5 status report
Hi, The SC has agreed me taking up the GCC-3.4.5 ball. I'm planning for two releases from the GCC-3.4.x series this year: (a) GCC-3.4.5 on September 30, and (b) GCC-3.4.6 on December, 15. The number of bugs (regressions) currently targetted for 3.4.5 is quite huge: 125 according to my counting and 150 according to bugzilla-query; more on that later. As usual, the C++ front-end is the winner for the highest number of regressions. Out of those, 7 have been marked release-critical by bugmasters: rtl-optimization/11707 Zdenek Dvorak c/16676 - c++/17655- c++/17972- middle-end/18956 - c++/19208Giovanni Bajo c++/21232- Where individual names appear, that bugzilla indicates they are assigned the bug in question. The full list of bugs is produced below. Maintainers, please look into any of those and see which ones you can fix or give guidance for fixes in ways that are suitable for a stable branch. Note to Dan: bugzilla-query, for "index gcc * 3.4.5", reports that it founds "150 bugs", where in fact only 125 are sent (and that number matches what the web interface reports). Would you be willing to check bugzilla-query counts? Thanks in advance. >From this week-end till end of August, I'll be travelling in Europe. Though I expect connectivity during that period of time, I may temporarilly be kept away from machines and network during August 15-22 (due to personal happy events!). Thanks to Dan's improvement for bugzilla-query, my mail agent will be watching gcc-3.4.5-bug-related acitivities. Note to all: from now on, please consider any snapshot from GCC-3.4.x as a release candidate, e.g. please test them as you would for any tarball I would have labelled "prerelease" or "release candidate". Happy hacking, bootstrap: 2 18532 libgcc.mk isn't parallel build safe for multilib 22213 quoting of dir-variable in mklibgcc.in c: 9 16676 ICE with nested functions and -g1, blocks glibc 20187 wrong code for ((unsigned char)(unsigned long long)((a?a:1)&(a*b)))?0:1) 20239 ICE on empty preprocessed input 21536 C99 array of variable length use causes segmentation fault 21873 infinite warning loop on bad array initializer 21899 enum definition accepts values to be overriden 22291 clash with built-in function ffs 22458 ICE on missing brace 22589 ICE casting to long long c++: 51 11224 warning "value computed is not used" no longer emitted 14500 most specialized function template vs. non-template function 14950 always_inline does not mix with templates and -O0 16002 Strange error message with new parser 16021 Tests for container swap specialisations FAIL in debug mode 16030 stdcall function decoration vs LTHUNK alias in multiple inheritanc 16042 ICE with array assignment 16276 G++ generates local references to linkonce sections 16405 Temporary aggregate copy not elided 16572 Wrong filename/line number were reported by g++ in inlining's warning messages 17248 __always_inline__ throws "unimplemented" in -O0 mode 17332 Missed inline opportunity 17413 local classes as template argument 18155 typedef in template declaration not rejected 17609 spurious error message after using keyword 17655 ICE with using a C99 initializer in an if-condition 17972 const/pure functions result in bad asm 18124 ICE with invalid template template parameter 18273 Fail to generate debug info for member function. 18368 C++ error message regression 18378 ICE when returning a copy of a packed member 18445 ice during overload resolution in template instantiation 18462 Segfault on declaration of large array member 18466 int ::i; accepted 18512 ICE on invalid usage of template base class 18514 Alternate "asm" name ignored for redeclared builtin function imported into namespace std 18545 ICE when returning undefined type 18625 triple error message for invalid typedef 18738 typename not allowed with non-dependent qualified name 19043 -fpermissive gives bad loop initializations 19063 ICE on invalid template parameter 19208 Spurious error about variably modified type 19395 invalid scope qualifier allowed in typedef 19396 Invalid template in typedef accepted 19397 ICE with invalid typedef 19441 Bad error message with invalid destructor declaration 19628 g++ no longer accepts __builtin_constant_p in constant-expressions 19710 ice on invalid one line C++ code 19734 Another ICE on invalid destructor call 19762 ICE in invalid explicit instantiation of a destructor 19764 ICE on explicit instantiation of a non-template destructor 19932 FAIL: g++.old-deja/g++.jason/rfg12.C (test for excess errors) 19982 The left side of the "=" operator must be an lvalue. 20152 ICE compiling krusader-1.5.1 with latest CVS gcc 20153 ICE when C++ template function contains anonymous union 2038
Re: front-end that translate C++ to C
Hi all, Are there any open-source(or free) front-end which translates C++ to C? I could find some commercial things - Comeau, AT&T Cfront, etc., but these have many limitations(especially, It's too difficult to get cfront because there are few cfront-based compiler at present) LLVM ( http://llvm.cs.uiuc.edu/ ) ? It use modified gcc 3.4 as C/C++ frontend and it can emits portable C code. Vladimir
[wwwdocs] Re: GCC-3.4.5 status report
Installed. If you prefer a different summary (I haven't changed the existing one), please let me know. Gerald Index: index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.508 diff -u -3 -p -r1.508 index.html --- index.html 18 Jul 2005 14:24:50 - 1.508 +++ index.html 25 Jul 2005 10:44:21 - @@ -40,7 +40,7 @@ mission statement. GCC 3.4.4 (released 2005-05-18) Branch status: - http://gcc.gnu.org/ml/gcc/2005-04/msg01693.html";>2005-04-29 + http://gcc.gnu.org/ml/gcc/2005-07/msg01037.html";>2005-07-25 (open for regression and documentation fixes only).
Re: Someone broke complex arithmetic
On Tue, 19 Jul 2005, FX Coudert wrote: >> Don't folk run the gfortran testsuite??? > No. People don't regtest with gfortran enabled. That's a pity, since it only > adds little time to the total build and testing time. I believe on of the reasons people often do not build with gfortran enabled is that this requires additional libraries which are not part of common system configurations and do not come with GCC either. Gerald
FW: error: expected unqualified-id before '(' token with gcc 3.4.3
Hello
I have taken the opensoruce from
http://www-personal.engin.umich.edu/~wagnerr/ConfigFile.html for reading
configuration file. It perfectly works fine with gcc 3.2.3 and it fail
to compile with gcc 3.4.3 on RHEL 4
I am getting following error
g++ -Wno-trigraphs -Wno-unused -Wno-deprecated -Wpointer-arith
-fno-common -fno-strict-aliasing -fexceptions -DOC_GCC_C -DOC_GCC_OBJC
-DOC_GCC_CPP -fPIC -D_GNU_SOURCE -DOC_GNUSTEP -DOC_LITTLE_ENDIAN
-DPEGASUS_PLATFORM_LINUX_IX86_GNU -DDEBUG
-DDINDICATION_DIR=\"/var/cache/pegasus\" -O -g -O2
"-DCM_WHATSTRING=\"evtfrmw IndicationProvider
CM_WHATSTRING_PLACEHOLDER_XX
\"" -fpermissive
-I/opt/OC/OCSDK_supportability_W8_00/include
-I/opt/OC/OCSDK_supportability_W6_00/include -I/opt/tog-pegasus/include
-Ibuild/evtfrmw/code/IndicationProvider -Imod_exp/evtfrmw/export/libAis
-c build/evtfrmw/code/IndicationProvider/OCEventProvider.cpp -o
build/evtfrmw/code/IndicationProvider/OCEventProvider.o
In file included from
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/sstre
am:640,
from
build/evtfrmw/code/IndicationProvider/ConfigFile.h:50,
from
build/evtfrmw/code/IndicationProvider/OCEventProvider.cpp:12:
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/bits/
sstream.tcc: In member function `virtual typename
std::basic_stringbuf<_CharT, _Traits, _Alloc>::int_type
std::basic_stringbuf<_CharT, _Traits, _Alloc>::overflow(typename
_Traits::int_type)':
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/bits/
sstream.tcc:104: error: expected unqualified-id before '(' token
cons: *** [build/evtfrmw/code/IndicationProvider/OCEventProvider.o]
Error 1
cons: errors constructing
build/evtfrmw/code/IndicationProvider/OCEventProvider.o
Can anybody encounted this problem? Any idea where to fix this problem?
I have found the same error reported by somebody on Solaris
http://www.opensolaris.org/jive/thread.jspa?threadID=974&tstart=0 with
no responses
Thanks in Advance
Regards
Ramesh
Re: GCC 4.1 Status Report (2005-07-22)
On Fri, 22 Jul 2005, Mark Mitchell wrote: > We have been in Stage 3 for a little while now. I'm sure a few more > patches that were proposed in Stage 2 will find their way into 4.1, > but we're approximately feature-complete at this point. I just committed the following update for our main page. If you'd like to change "open for bug fixes" to something more strict, please let me know. Gerald Index: index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.511 diff -u -3 -p -r1.511 index.html --- index.html 25 Jul 2005 10:45:58 - 1.511 +++ index.html 25 Jul 2005 11:11:27 - @@ -65,8 +65,8 @@ mission statement. will become GCC 4.1.0 (current changes) Branch status: - http://gcc.gnu.org/ml/gcc/2005-05/msg00224.html";>2005-05-04 - (stage 2; open for all maintainers). + http://gcc.gnu.org/ml/gcc/2005-07/msg00954.html";>2005-07-22 + (stage 3; open for bug fixes).
Re: [BUG] gcc-3.4.5-20050531 (i386): __FUNCTION__ as a part of the printf's format argument
On Mon, Jul 25, 2005 at 11:35:27AM +0200, Paolo Bonzini wrote: > > Ok, but such a code used to be compiled succesively with gcc for > > years. Then, some change _in_ gcc has occured. That is why I've > > posted to here. > > Yes, it was deprecated in 3.1 (released three years ago) and removed in > 3.3 (released two years ago). Really, things are not _so_ dramatical... This is a cite from extend.tex: * These identifiers are not preprocessor macros. In GCC 3.3 and * earlier, in C only, __FUNCTION__ and __PRETTY_FUNCTION__ were * treated as string literals; they could be used to initialize char * arrays, and they could be concatenated with other string literals. * GCC 3.4 and later treat them as variables, like __func__. So, the behaviour is changed for 3.4, and is not changed for 3.3. And it is STILL not changed - 3.3 is alive - isn't it?
Re: PING [4.1 regression, patch] build i686-pc-mingw32
Coming back to this topic. Nobody has answered to one of my questions: if the mingw/cygwin maintainers can't approve such a patch, who can? FX
Re: [wwwdocs] Re: GCC-3.4.5 status report
Gerald Pfeifer <[EMAIL PROTECTED]> writes: | Installed. If you prefer a different summary (I haven't changed the | existing one), please let me know. That is fine. Thanks! -- Gaby
gcc 3.3.6 - stack corruption questions
Hey folks. I'm having some trouble with a process compiled with gcc 3.3.6. This code is pretty complex and has several features that are not typically in use because they involve non-production test cases. The problem is I'm getting core dumps (SEGV) that appears to come from this code when I know it shouldn't be in the execution path. The code in question is switched on by a command line argument only, and the process is managed by a parent process that monitors and manages it's execution - reporting crashes and restarting it if necessary. Here's my environment: gcc 3.3.6 built on SunOS 5.8 sun4u sparc SUNW,Ultra-60, app built on the same platform and execution on SunOS 5.8 sun4u sparc SUNW,UltraSPARC-IIi-cEngine. The entire codebase is written in C, and is compiled as follows: /usr/local/gcc-3.3.6/bin/gcc -ggdb -g3 -Wall -D_REENTRANT -Wno-multichar -Wno-unused-function -D_SOLARIS -DUSE_DEV_POLL -mcpu=ultrasparc -O2 -DTIMING=1 -DDB_TIMING=1 -Icommon/include -I/opt/oracle/8.1.7/include -I/opt/oracle/8.1.7/rdbms/public -c -o store.o store.c These problems have popped up time and again over the last 6 years, going as far back as gcc 2.95, but gdb has never been able to tell me any more than where the problem came from (the Solaris pstack utility always agrees with gdb). These problems are only repeated under longer execution times, and only after some thousands or even millions of transactions. The application is supposed to provide 99.97% availability, so having this happen 12 times over the course of a weekend is a bit concerning. Sometimes a build will prove wonderfully stable, but then a very small code change made to tweak some behavior will completely destabilize it. Recently, I added a handler to catch segfaults and bus errors to try to extract more info through the ucontext interface. I am able to get a little explicit detail, but not much new information. Problem with this is it doesn't preserve the originating stack as well. At this point, I'm at a loss as to where to start. This is a pretty important codebase (to my employer, anyway) and the frequency of these inexplicable problems is starting to cause some concern. Any suggestions as to where to go next? If I've forgotten any potentially useful information please don't hesitate to request it. Please CC me directly, as I am not on the dev list. Thanks for your time. Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :þ http://www.keyslapper.net Ô¿Ô¬ Key fingerprint = C5E7 4762 F071 CE3B ED51 4FB8 AF85 A2FE 80C8 D9A2 Flugg's Law: When you need to knock on wood is when you realize that the world is composed of vinyl, naugahyde and aluminum.
Re: gcc 3.3.6 - stack corruption questions
Louis LeBlanc <[EMAIL PROTECTED]> wrote: > The problem is I'm getting core dumps (SEGV) that appears to come from > this code when I know it shouldn't be in the execution path. The code > in question is switched on by a command line argument only, and the > process is managed by a parent process that monitors and manages it's > execution - reporting crashes and restarting it if necessary. Looks like a bug hidden in your code. Several things you could try: - valgrind - GCC 4.0 with -fmudflap - GCC 4.1 CVS with -fstack-protect -- Giovanni Bajo
Re: PING [4.1 regression, patch] build i686-pc-mingw32
On Mon, Jul 25, 2005 at 03:37:55PM +0200, Fran?ois-Xavier Coudert wrote: >Coming back to this topic. > >Nobody has answered to one of my questions: if the mingw/cygwin >maintainers can't approve such a patch, who can? Presumably, people with blanket write privs and people responsible for the build machinery. cgf
Re: gcc 3.3.6 - stack corruption questions
On 07/25/05 05:15 PM, Giovanni Bajo sat at the `puter and typed: > Louis LeBlanc <[EMAIL PROTECTED]> wrote: > > > The problem is I'm getting core dumps (SEGV) that appears to come from > > this code when I know it shouldn't be in the execution path. The code > > in question is switched on by a command line argument only, and the > > process is managed by a parent process that monitors and manages it's > > execution - reporting crashes and restarting it if necessary. > > Looks like a bug hidden in your code. Several things you could try: > > - valgrind > - GCC 4.0 with -fmudflap > - GCC 4.1 CVS with -fstack-protect > -- Thanks for the tips. Since I'm on Solaris, I don't think Valgrind is an option (Linux and FreeBSD on x86/PowerPC/AMD64 only). I will check out the gcc versions and features you mention. Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :þ http://www.keyslapper.net Ô¿Ô¬ Key fingerprint = C5E7 4762 F071 CE3B ED51 4FB8 AF85 A2FE 80C8 D9A2 Turnaucka's Law: The attention span of a computer is only as long as its electrical cord.
Re: [BUG] gcc-3.4.5-20050531 (i386): __FUNCTION__ as a part of the printf's format argument
On Monday, July 25, 2005, at 01:58 AM, Paolo Carlini wrote: By the way, since we have to point out that *so often*, maybe there is something wrong on our part: I wonder whether changing the names of those lists would help!?!? I don't know: gcc-development, gcc-users, ... No, randomly changing mainline list names will confuse the thousands of people that are not confused. Better to ask them why they thought this list was a good idea, and then track down the root of the problem, and then fix that. In the past when I did it, it could be traced to people telling them, or to the web site directly. For example, we could completely remove all references to the gcc mailing list from the web site, and invite people after the post a single good patch to gcc-help. :-) Or, maybe just put it on a page called contributing work to gcc. Most using gcc that just want help would not even go to such a page.
Re: [BUG] gcc-3.4.5-20050531 (i386): __FUNCTION__ as a part of the printf's format argument
Mike Stump <[EMAIL PROTECTED]> writes: | On Monday, July 25, 2005, at 01:58 AM, Paolo Carlini wrote: | > By the way, since we have to point out that *so often*, maybe there is | > something wrong on our part: I wonder whether changing the names of | > those lists would help!?!? I don't know: gcc-development, gcc-users, | > ... | | No, randomly changing mainline list names will confuse the thousands | of people that are not confused. I agree changing the list name isn't a proper long term, fix. After all, people doing development *with* GCC might also think tha gcc-development is the proper place ot sned mails instad of gcc-help :-) -- Gaby
Re: [BUG] gcc-3.4.5-20050531 (i386): __FUNCTION__ as a part of the printf's format argument
Gabriel Dos Reis wrote: > After >all, people doing development *with* GCC might also think tha >gcc-development is the proper place ot sned mails instad of gcc-help >:-) > > Yes ;-) On the other hand, some people may believe that gcc-help is the right list to arrange donations and other activies helping the gcc project :-) Paolo.
Re: [BUG] gcc-3.4.5-20050531 (i386): __FUNCTION__ as a part of the printf's format argument
The first step is to have clear documentation. I sent a message to someone who would posted a question and he replied by pointing to a clear statement that said tried gcc-help first if you have questions and if that doesn't work try gcc, and that's what he did!
Re: [BUG] gcc-3.4.5-20050531 (i386): __FUNCTION__ as a part of the printf's format argument
On Jul 25, 2005, at 1:58 AM, Paolo Carlini wrote: Richard Guenther wrote: Btw, this list is for the development _of_ gcc, not with gcc. Use gcc-help for that. By the way, since we have to point out that *so often*, maybe there is something wrong on our part: I wonder whether changing the names of those lists would help!?!? I don't know: gcc-development, gcc-users, ... Perhaps adding something similar to the above to the description of the gcc list on the web page would help. What's there seems clear enough to me, but perhaps a bigger hammer would help other people.
Re: GCC-3.4.5 status report
On Mon, 2005-07-25 at 11:41 +0200, Gabriel Dos Reis wrote: > Hi, > > The SC has agreed me taking up the GCC-3.4.5 ball. > I'm planning for two releases from the GCC-3.4.x series this year: > (a) GCC-3.4.5 on September 30, and > (b) GCC-3.4.6 on December, 15. > > The number of bugs (regressions) currently targetted for 3.4.5 is > quite huge: 125 according to my counting and 150 according to > bugzilla-query; more on that later. As usual, the C++ front-end is > the winner for the highest number of regressions. Out of those, 7 have > been marked release-critical by bugmasters: > > rtl-optimization/11707 Zdenek Dvorak > c/16676 - > c++/17655- > c++/17972- > middle-end/18956 - > c++/19208Giovanni Bajo > c++/21232- > > Where individual names appear, that bugzilla indicates they are > assigned the bug in question. > > The full list of bugs is produced below. Maintainers, please look > into any of those and see which ones you can fix or give guidance for > fixes in ways that are suitable for a stable branch. > > Note to Dan: bugzilla-query, for "index gcc * 3.4.5", reports that it > founds "150 bugs", where in fact only 125 are sent (and that number > matches what the web interface reports). Fixed. It was counting a slightly higher number of bugs than it actually sent (it does some of the query filtering client-side in the script)
Re: -fprofile-generate and -fprofile-use
I have done quite a few experiments with this to narrow down the problem. The performance numbers are slower compared to *No Feedback optimization with just -O3* Here are some of them. All the experiments were done on a new build-area in order to eliminate effects of old feedback files. 1. I built the app using -O3 and -fprofile-generate to generate the feedback data. I then ran the workload and then recompiled the app using -O3 and -fprofile-use [app was 20% slower] 2. I built the app using -O3 and -fprofile-generate to generate the feedback data. I then ran the workload and then recompiled the app using -O3 and -fprofile-use -fno-vpt -fno-unroll-loops -fno-peel-loops -fno-tracer (Which is turn off all the flags used by -fprofile-use) [App was still 20% slower] 3. I have tried selectively turning of some of the other flags in the above list as well, but the performance regression persists. 4. I tried with the older flags namely -fprofile-arcs and -fbranch-probabilities still no help. Can someone help me out on how to proceed with this. Thanks -girish --- Jan Hubicka <[EMAIL PROTECTED]> wrote: > > I started with a clean slate in my build > environment > > and did not have any residual files hanging > around. > > Are the steps I have indicated in my earlier email > > correct. Is there a way I can break down the > problem > > into a smaller sub-set of flags and eliminate the > flag > > causing the performance problem. What I mean is > since > > -fprofile-generate and -fprofile-use enable a > bunch of > > flags, would it make sense to avoid profiling and > try > > out some of the individual flags on a trial and > error > > basis. If so what would be the flags to start the > It would be probably better to just turn off the > individual > optimizations with -fprofile-use (for optimizations > that are implied by > this flag there should be no need to re-profile each > time). > If you can find particular optimization that gets > out of control, it > would be lot easier to fix it... > > Honza > > trials with. > > > > -girish > > > > --- Jan Hubicka <[EMAIL PROTECTED]> wrote: > > > > > > On Wed, Jul 20, 2005 at 10:45:01AM -0700, > girish > > > vaitheeswaran wrote: > > > > > > --- Steven Bosscher <[EMAIL PROTECTED]> > wrote: > > > > > > > > > > > > > On Wednesday 20 July 2005 18:53, girish > > > vaitheeswaran wrote: > > > > > > > > I am seeing a 20% slowdown with > feedback > > > optimization. > > > > > > > > Does anyone have any thoughts on this. > > > > > > > > > > > > > > My first thought is that you should > probably > > > first > > > > > > > tell what compiler > > > > > > > you are using. > > > > > > > > > > I am using gcc 3.4.3 > > > > > -girish > > > > > > > > Which platform? I've seen slower code for > > > profile-directed optimizations > > > > on powerpc64-linux with GCC 4.0 and mainline. > > > It's a bug, but I haven't > > > > looked into it enough to provide a small test > case > > > for a problem report. > > > > > > Actually I would be very interested in seeing > > > testcases such as those. > > > (and the Girish' slowdown too if possible). In > > > general some slowdowns > > > in side corners are probably unavoidable but > both > > > 3.4.3 and 4.0 seems to > > > have pretty consistent improvements with > profiling > > > at least for SPEC and > > > i386 I am testing pretty regularly. > > > Such slodowns usually indicate problems like > > > incorrectly updated profile > > > or incorrectly readed in profile because of > > > missmatch in CFGs in between > > > profile and feedback run that are rather > dificult to > > > notice and hunt > > > down... > > > > > > Honza > > > > > > > > Janis > > > >
Re: front-end that translate C++ to C
On Mon, 2005-07-25 at 14:01 +0400, Vladimir A. Merzliakov wrote: > > Hi all, > > > > Are there any open-source(or free) front-end which translates C++ to C? > > I could find some commercial things - Comeau, AT&T Cfront, etc., but > > these have many limitations(especially, It's too difficult to get cfront > > because there are few cfront-based compiler at present) > LLVM ( http://llvm.cs.uiuc.edu/ ) ? > > It use modified gcc 3.4 as C/C++ frontend and it can emits portable C code. Depends what you mean by portable. You can't take the output of the gcc llvm frontend on one platform, and run it on another, like cfront could. The sizes, alignments, etc, of things will be different, where people use sizeof(x), etc, in their code. Unless you hacked up the C frontend to give you sizeof_expr, etc. Chris? --Dan
Re: GCC-3.4.5 status report
Daniel Berlin <[EMAIL PROTECTED]> writes: | Fixed. | It was counting a slightly higher number of bugs than it actually sent | (it does some of the query filtering client-side in the script) Thanks. -- Gaby
Re: GCC-3.4.5 status report
The full list of bugs is produced below. Maintainers, please look into any of those and see which ones you can fix or give guidance for fixes in ways that are suitable for a stable branch. Do I still have time / opportunity to refresh the SCO ports? If Sept 30 is the deadline I will definately be able to make it. I have the thing bootstrapping, and I am working my way through the regression suites to understand and either fix, or at least understand why I am ignoring, any failures. Kean
Re: front-end that translate C++ to C
> "Dan" == Daniel Berlin <[EMAIL PROTECTED]> writes: Dan> You can't take the output of the gcc llvm frontend on one platform, and Dan> run it on another, like cfront could. Dan> The sizes, alignments, etc, of things will be different, where people Dan> use sizeof(x), etc, in their code. Dan> Unless you hacked up the C frontend to give you sizeof_expr, etc. Even then you would run into '#if WORDS_BIGENDIAN' and the like... Tom
Can't find values-Xa.o when cross compiling
Hello All I've built gcc-3.4.4 as a linux to Solaris (on SPARC) cross compiler. If I change my path to include my new compiler executables, I can compile and link a simple "hello world" program. However, I want to be able to specify the target architecture and compiler version number with gcc's -b and -V flags. When I try to build my program using these flags, the system can't find values-Xa.o: [EMAIL PROTECTED] helloworld]$ g++ -b sparc-sun-solaris2.9 -V 3.4.4 hello.cxx /cdl/apps/.software/linux/gcc-3.4.4-x86-sparc/lib/gcc/sparc-sun-solaris2.9/3.4.4/../../../../sparc-sun-solaris2.9/bin/ld: values-Xa.o: No such file: No such file or directory collect2: ld returned 1 exit status [EMAIL PROTECTED] helloworld]$ The file is in $sysroot/usr/lib (and $sysroot/usr/ccs/lib too). $sysroot was set as configure option when built gcc. According to the docs, itlooks like $sysroot should be searched for the library & object files, but it doesn't seem to work. Even if I specify the path to the linker with -Wl,-L , it still can't find the file. However, if I directly call gcc instead of using -b and -V to call sparc-sun-solaris2.9-gcc, it works... Any ideas why this might be? My gcc package is configured as:[EMAIL PROTECTED] helloworld]$ gcc -vReading specs from/cdl/apps/.software/linux/gcc-3.4.4-x86-sparc/lib/gcc/sparc-sun-solaris2.9/3.4.4/specsConfigured with:../gcc-3.4.4/configure --host=i686-pc-linux-gnu --target=sparc-sun-solaris2.9 --with-sysroot=/cdl/apps/.software/linux/gcc-3.4.4-x86-sparc-build/sysroot --with-gnu-as --with-gnu-ld --prefix=/cdl/apps/.software/linux/gcc-3.4.4-x86-sparc --enable-languages=c,c++Thread model: posixgcc version [EMAIL PROTECTED] helloworld]$ Thanks Mark Mark Cuss, B. Sc. Real Time Systems Analyst System Administrator CDL Systems Ltd Suite 230 3553 - 31 Street NW Calgary, AB, Canada Phone: 403 289 1733 ext 226Fax: 403 289 3967> www.cdlsystems.com
Re: GCC-3.4.5 status report
Kean Johnston <[EMAIL PROTECTED]> writes: | > The full list of bugs is produced below. Maintainers, please look | > into any of those and see which ones you can fix or give guidance for | > fixes in ways that are suitable for a stable branch. | Do I still have time / opportunity to refresh the SCO ports? This being a stable release branch, I'll consider only regressions fixes. Is that the case? -- Gaby
Re: GCC-3.4.5 status report
Gabriel Dos Reis wrote: Kean Johnston <[EMAIL PROTECTED]> writes: | > The full list of bugs is produced below. Maintainers, please look | > into any of those and see which ones you can fix or give guidance for | > fixes in ways that are suitable for a stable branch. | Do I still have time / opportunity to refresh the SCO ports? This being a stable release branch, I'll consider only regressions fixes. Is that the case? I guess it depends on how pedantic we want to define 'regression'. I did a mostly-working port circa 3.4.1, but it had some problems, but teh last known-to-be-working-well port was 2.95.3. I have people baying for 3.4 all the time. So its technicalyl a regression from 2.95.3, and almost one from 3.4.1 :) Kean
Re: GCC-3.4.5 status report
Kean Johnston <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis wrote: | > Kean Johnston <[EMAIL PROTECTED]> writes: | > | > The full list of bugs is produced below. Maintainers, please | > look | > | > into any of those and see which ones you can fix or give guidance for | > | > fixes in ways that are suitable for a stable branch. | > | Do I still have time / opportunity to refresh the SCO ports? | > This being a stable release branch, I'll consider only regressions | > fixes. Is that the case? | I guess it depends on how pedantic we want to define | 'regression'. I did a mostly-working port circa 3.4.1, but | it had some problems, but teh last known-to-be-working-well | port was 2.95.3. I have people baying for 3.4 all the time. | So its technicalyl a regression from 2.95.3, and almost one | from 3.4.1 :) Here is how Mark and I have agreed on those sort of things. If such a patch is accepted in 3.4.x but not in 4.0.x, then we've introduced a regression in 4.0.x. So, the way we deal with it is that, the patch is first applied to 4.0.x, then to 3.4.x retrospectively. Is that workable for you? (I applied a more enthusiastic policy for 3.3.3, but that is only because of the particularity of the 3.3.x series when I took it). -- Gaby
Re: GCC-3.4.5 status report
Here is how Mark and I have agreed on those sort of things. If such a patch is accepted in 3.4.x but not in 4.0.x, then we've introduced a regression in 4.0.x. So, the way we deal with it is that, the patch is first applied to 4.0.x, then to 3.4.x retrospectively. Is that workable for you? Absolutely. I actually did all the workin in a 4.0.2 cvs tree, and Im backporting it to my 3.4.5 tree. Kean
Re: GCC-3.4.5 status report
Kean Johnston <[EMAIL PROTECTED]> writes: | > Here is how Mark and I have agreed on those sort of things. If such a | > patch is accepted in 3.4.x but not in 4.0.x, then we've introduced a | > regression in 4.0.x. So, the way we deal with it is that, the patch | > is first applied to | > 4.0.x, then to 3.4.x retrospectively. Is that workable for you? | Absolutely. I actually did all the workin in a 4.0.2 cvs tree, and | Im backporting it to my 3.4.5 tree. Ok. -- Gaby
Re: front-end that translate C++ to C
LLVM ( http://llvm.cs.uiuc.edu/ ) ? It use modified gcc 3.4 as C/C++ frontend and it can emits portable C code. Depends what you mean by portable. You can't take the output of the gcc llvm frontend on one platform, and run it on another, like cfront could. "emits portable C code" just copied from "LLVM Overview" at http://llvm.cs.uiuc.edu/ :) Vladimir
Re: front-end that translate C++ to C
On Mon, 25 Jul 2005, Daniel Berlin wrote: On Mon, 2005-07-25 at 14:01 +0400, Vladimir A. Merzliakov wrote: Hi all, Are there any open-source(or free) front-end which translates C++ to C? I could find some commercial things - Comeau, AT&T Cfront, etc., but these have many limitations(especially, It's too difficult to get cfront because there are few cfront-based compiler at present) LLVM ( http://llvm.cs.uiuc.edu/ ) ? It use modified gcc 3.4 as C/C++ frontend and it can emits portable C code. Depends what you mean by portable. You can't take the output of the gcc llvm frontend on one platform, and run it on another, like cfront could. The sizes, alignments, etc, of things will be different, where people use sizeof(x), etc, in their code. Unless you hacked up the C frontend to give you sizeof_expr, etc. It isn't portable in that sense. Like Tom Tromey mentions, anything that deals with code that comes out of the preprocessor isn't "portable" in that way. It is portable in the sense of being able to use any standard ANSI C compiler to compile the code, which gives you a pretty portable C++ implementation. We have had quite a few people say they are using LLVM as a replacement for old and out-dated CFront-based vendor C++ front-ends. Using LLVM in this way allows them to use the GCC 3.4 parser and libstdc++ which is usually far better than what they are dealing with. Getting IPO and the other advantages that LLVM provides is just a perk that people with embedded devices (or other systems with constrained resources) particularly enjoy. -Chris -- http://nondot.org/sabre/ http://llvm.org/
Re: PING [4.1 regression, patch] build i686-pc-mingw32
> Presumably, people with blanket write privs and people responsible for > the build machinery. Yup, that's them. I did a little historical digging on this item, and the original trigger was http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00280.html where Paolo needed to switch from symlinks to hardlinks for toplevel bootstrapping. So, I think we've confused the issue enough that we may be making bad decisions (or at least *I* am confused and may make bad decisions ;). Paolo, could you go back and think about the bootstrapping problem from MinGW's perspective? Danny, could you summarize which build features MinGW supports? (I assume cp and $(SHELL) but not symlinks, hardlinks, or #!). DJGPP and Cygwin shouldn't be a problem here; they both support symlinks and #! but I don't think they support hardlinks.
Re: PING [4.1 regression, patch] build i686-pc-mingw32
On Mon, Jul 25, 2005 at 04:48:45PM -0400, DJ Delorie wrote: >> Presumably, people with blanket write privs and people responsible for >> the build machinery. > >Yup, that's them. > >I did a little historical digging on this item, and the original >trigger was http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00280.html >where Paolo needed to switch from symlinks to hardlinks for toplevel >bootstrapping. So, I think we've confused the issue enough that we >may be making bad decisions (or at least *I* am confused and may make >bad decisions ;). > >Paolo, could you go back and think about the bootstrapping problem >from MinGW's perspective? > >Danny, could you summarize which build features MinGW supports? (I >assume cp and $(SHELL) but not symlinks, hardlinks, or #!). DJGPP and >Cygwin shouldn't be a problem here; they both support symlinks and #! >but I don't think they support hardlinks. For shell commands, the MSys build environment supports pretty much everything that Cygwin does, which would be everything currently in that makefile rule. The problem is that when gcc executes, it uses (eventually) the unadulterated Windows CreateProcess call which does not understand cygwin/MSys symlinks or '#!' shell scripts or any other type of shell script. It would understand a .bat or .cmd file, but adding .bat or .cmd file processing to Makefile.in is probably not something that we want to do. Hard links would be supported by everything since Windows understands hard links at the OS level and Cygwin/MSys can create them (in some cases). They aren't a generic solution, however, as the makefile rule demonstrates. Maybe one solution would be to patch pex-win32 for mingw so that it could understand '#!' style shell scripts? That would at least allow bootstrapping. It wouldn't be useful generic pure-windows installation, but presumably a user wouldn't have to worry about that because everything would be installed correctly. cgf
Re: PING [4.1 regression, patch] build i686-pc-mingw32
> Maybe one solution would be to patch pex-win32 for mingw so that it > could understand '#!' style shell scripts? That would at least > allow bootstrapping. That would be wonderful, and that's exactly the right place to put it too. I'm assuming I can persuade one of you to do that? ;-) I'm going to define pex-win32.c as being within the realm of the mingw maintainership (if you hadn't assumed that already). > It wouldn't be useful generic pure-windows installation, It would still be *available* though, so you could (for example) wrap your assembler in a shell script for debugging purposes, and gcc could still run it. Plus binutils uses it (windres, dlltool), so same minor benefit there.
Re: PING [4.1 regression, patch] build i686-pc-mingw32
On Mon, Jul 25, 2005 at 05:23:54PM -0400, DJ Delorie wrote: >>Maybe one solution would be to patch pex-win32 for mingw so that it >>could understand '#!' style shell scripts? That would at least allow >>bootstrapping. > >That would be wonderful, and that's exactly the right place to put it >too. I'm assuming I can persuade one of you to do that? ;-) > >I'm going to define pex-win32.c as being within the realm of the mingw >maintainership (if you hadn't assumed that already). I'd be happy to implement this. I'd like to get Danny's opinion on this first, though, in case I missed something. cgf
Re: gcc front end
On Tuesday 19 July 2005 10:34, Sean PH wrote: > Hello, > > I'm currently working on implementing a tool chain for a 'pet > language' of mine called O (for Obscure, since my preferred name was > taken). You can see the [unfinished] language specification here: > > http://sean.heybryan.org/spec0_unfinished.pdf > > Note that the implementation notes chapter isn't filled in since I > havn't gotten around to finding a back-end for the compiler yet. gcc > looks like a very good option, however the documentation is quite > 'preliminary' and I am having trouble understanding some things. Would > anyone there be willing to help me on this, even just to talk about > gcc's features and how I would apply my language constructs to them at > first? I am approaching a point at which I have a full parse tree of > the language available and will be ready to dive into connecting it to > a back end, so this would be much appreciated. I think that you should take a look at the GCC front end HOWTO. Some parts of it are out of date but most of it is quite useful. Studing other front ends is also helpfull. I have made a very small Hello World front end to show what is the smallest program that can link with the gcc middle end. I is not completely documented, but I think that it can be usefull. It is at http://svn.gna.org/viewcvs/gsc/branches/hello-world/ A much more mature example is the treelang front end that comes with gcc. I also think that the fortran front end is a very good reference. > Sorry for any grammar errors, they're unintentional as I just pulled > an all-nighter :). > > Thanks, Sean Purser-Haskell Wen you have more specific question feel free to ask. :) Rafael Ávila de Espíndola pgpB5VNEhghGD.pgp Description: PGP signature
Re: [C++ RFC] Debug info for anonymous aggregates
On Jul 23, 2005, at 8:44 PM, Mark Mitchell wrote: Actually, I think the best fix would be just not to set DECL_IGNORED_P in the first place, and let the debug-generators sort it out. OK. I'll see how dbxout reacts. - Devang
Re: gcc 3.3.6 - stack corruption questions
On 07/25/05 05:15 PM, Giovanni Bajo sat at the `puter and typed: > Louis LeBlanc <[EMAIL PROTECTED]> wrote: > > > The problem is I'm getting core dumps (SEGV) that appears to come from > > this code when I know it shouldn't be in the execution path. The code > > in question is switched on by a command line argument only, and the > > process is managed by a parent process that monitors and manages it's > > execution - reporting crashes and restarting it if necessary. > > Looks like a bug hidden in your code. Several things you could try: > > - valgrind > - GCC 4.0 with -fmudflap > - GCC 4.1 CVS with -fstack-protect I've not gotten the chance to build with gcc4.0.1 yet (still building), but I've tried a couple other things with 3.3.6 that you might find interesting, maybe something will raise a flag. I added the -fstack-check switch to my makefile and recompiled with various optimizations. I was pretty surprised at the file sizes that showed up: No Optimization: -rwxr-xr-x 1 leblanc daemon 1128660 Jul 25 16:25 myprocess* Optimized with -O2 -rwxr-xr-x 1 leblanc daemon 1058228 Jul 25 17:36 myprocess* Optimized with -O3 -rwxr-xr-x 1 leblanc daemon 1129792 Jul 25 17:32 myprocess* I would have expected much different results. Shouldn't the file sizes be smaller (at least a little) with the -O3 switch? Maybe there's a loop unrolled to make it faster, resulting in a larger codebase? Anyway, the code that generated these files (identical between the three, except the compilation flags) appears to be hitting something with the optimizer that doesn't like my code. Those with optimization (the last 2) core on less than 50K transactions - both in calls to pthread_mutex_unlock(). I have verified that the mutex passed in is valid (it would have been locked and unlocked some 70K times before failing in my last test). The unoptimized version completed a 401,900 transaction test with no problem. All day, I've been playing with different things, BTW, all these executables were compiled with -ggdb -g3 -Wall. Thanks to everyone who sent ideas so far. Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :þ http://www.keyslapper.net Ô¿Ô¬ Key fingerprint = C5E7 4762 F071 CE3B ED51 4FB8 AF85 A2FE 80C8 D9A2 Udall's Fourth Law: Any change or reform you make is going to have consequences you don't like.
RE: PING [4.1 regression, patch] build i686-pc-mingw32
From: Christopher Faylor Sent: Tuesday, July 26, 2005 9:33 AM > > On Mon, Jul 25, 2005 at 05:23:54PM -0400, DJ Delorie wrote: > >>Maybe one solution would be to patch pex-win32 for mingw so that it > >>could understand '#!' style shell scripts? That would at > least allow > >>bootstrapping. > > > >That would be wonderful, and that's exactly the right place > to put it > >too. I'm assuming I can persuade one of you to do that? ;-) > > > >I'm going to define pex-win32.c as being within the realm of > the mingw > >maintainership (if you hadn't assumed that already). > > I'd be happy to implement this. I'd like to get Danny's > opinion on this first, though, in case I missed something. Thanks Chris, I don't see any obvious problems. yet. Danny > > cgf >
Re: GCC 4.1 Status Report (2005-07-22)
Gerald Pfeifer wrote: On Fri, 22 Jul 2005, Mark Mitchell wrote: We have been in Stage 3 for a little while now. I'm sure a few more patches that were proposed in Stage 2 will find their way into 4.1, but we're approximately feature-complete at this point. I just committed the following update for our main page. If you'd like to change "open for bug fixes" to something more strict, please let me know. No, I think that's perfect. Thanks! -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: gcc 3.3.6 - stack corruption questions
Louis LeBlanc <[EMAIL PROTECTED]> wrote: > I added the -fstack-check switch to my makefile and recompiled with > various optimizations. I was pretty surprised at the file sizes that > showed up: > > No Optimization: > -rwxr-xr-x 1 leblanc daemon 1128660 Jul 25 16:25 myprocess* > > Optimized with -O2 > -rwxr-xr-x 1 leblanc daemon 1058228 Jul 25 17:36 myprocess* > > Optimized with -O3 > -rwxr-xr-x 1 leblanc daemon 1129792 Jul 25 17:32 myprocess* > > I would have expected much different results. Shouldn't the file > sizes be smaller (at least a little) with the -O3 switch? Maybe > there's a loop unrolled to make it faster, resulting in a larger > codebase? Or inlining, or many other things. If you care about size, use -Os. -- Giovanni Bajo
Re: gcc 3.3.6 - stack corruption questions
Louis LeBlanc wrote: I would have expected much different results. Shouldn't the file sizes be smaller (at least a little) with the -O3 switch? Maybe there's a loop unrolled to make it faster, resulting in a larger codebase? you generally expect -O3 files to be larger. inlining does not save space. Indeed in the context of Ada, where well thought out inlining is acheived by -O2 -gnatn (and the use of pragma Inline), we often see -O3 executables being not only larger but slower, presumably due to increased icache pressure. The unoptimized version completed a 401,900 transaction test with no problem. All day, I've been playing with different things, there are many bugs, most notably uninitialed vars, that show up only when you turn on optimization.
Re: gcc 3.3.6 - stack corruption questions
O Jul 25, 2005, at 3:50 PM, Robert Dewar wrote: The unoptimized version completed a 401,900 transaction test with no problem. All day, I've been playing with different things, there are many bugs, most notably uninitialed vars, that show up only when you turn on optimization. Also violations of strict aliasing rules are common. -Wuninitialized -fno-strict-aliasing [after the -O] will exercise those two. Also, mixed builds with some -O0 and some -O3 files should narrow it down.
Re: volatile semantics
On Sun, Jul 17, 2005 at 11:56:46AM -0700, Geoffrey Keating wrote: > "D. Hugh Redelmeier" <[EMAIL PROTECTED]> writes: > > An object that has volatile-qualified type may be modified in ways > > unknown to the implementation or have other unknown side > > effects. Therefore any expression referring to such an object shall be > > evaluated strictly according to the rules of the abstract machine > > The word you missed is 'Therefore'. If an implementation can > determine that an object is not modified unknown to the > implementation, the implementation need not evaluate it strictly > according to the rules of the abstract machine. I don't read it that way. I read it as "whatever the implementation may think, it can _not_ determine whether the object may be modified/has side effects unknown to it". OG.
gcc 4.0.1 regressions with friend injection
We are seeing tons of regressions (9 of 2377 for fink, over 100 or so
out of 8000 was it for internal projects) in the build state of
projects with code like:
class bar {
friend class foo;
void baz(foo *x) {}
};
from 4.0.0 in 4.0.1. This is really unfortunate. What we really
need is a warning (that can be easily turned off with a -Wno- switch)
for the next 2 years, and then an error, if you must. Doing this
from x.0.0 to x.0.1 is, uhm, well, more costly than if it had been
done in 4.0.0. :-(
Thoughts?
Re: gcc 4.0.1 regressions with friend injection
Mike Stump <[EMAIL PROTECTED]> writes:
| We are seeing tons of regressions (9 of 2377 for fink, over 100 or so
| out of 8000 was it for internal projects) in the build state of
| projects with code like:
|
| class bar {
|friend class foo;
|void baz(foo *x) {}
| };
|
| from 4.0.0 in 4.0.1. This is really unfortunate. What we really
| need is a warning (that can be easily turned off with a -Wno- switch)
| for the next 2 years, and then an error, if you must. Doing this
| from x.0.0 to x.0.1 is, uhm, well, more costly than if it had been
| done in 4.0.0. :-(
|
| Thoughts?
This area has been a historical weakness of GCC, causing us to reject
valid-code or accept valid-code-with-wrong-semantics. As you point
out above, it can can the overload set and such. Because the point of
declaration is far away from the point of possible overload
resolution, it is not all clear when an "invalid declaration accepted
for past bug compayibility" should be or not be part of the overload
set. You can warn, but it you turn it off, it is not obvious what the
semantics should be.
(This reminds me of the "implicit typename" stuff)
-- Gaby
rfa (x86): 387<=>sse moves
With -march=pentium4 -mfpmath=sse -O2, we get an extra move for code
like
double d = atof(foo);
int i = d;
callatof
fstpl -8(%ebp)
movsd -8(%ebp), %xmm0
cvttsd2si %xmm0, %eax
(This is Linux, Darwin is similar.) I think the difficulty is that for
(set (reg/v:DF 58 [ d ]) (reg:DF 8 st)) 64 {*movdf_nointeger}
regclass decides SSE_REGS is a zero-cost choice for 58. Which looks
wrong, as that requires a store and load from memory. In fact, memory
is
the cheapest overall choice for 58 (taking its use into account also),
and
gcc will figure that out correctly if a more reasonable assessment is
given
to SSE_REGS. The immediate cause is the #Y's in the constraint:
"=f#Y,m ,f#Y,*r ,o ,Y*x#f,Y*x#f,Y*x#f ,m
"
and there's probably a simple fix, but it eludes me. Advice? Thanks.
Re: gcc 4.0.1 regressions with friend injection
Which leads me to the old saying that friends don't let friends use friends.
On 26 Jul 2005 03:07:49 +0200, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
> Mike Stump <[EMAIL PROTECTED]> writes:
>
> | We are seeing tons of regressions (9 of 2377 for fink, over 100 or so
> | out of 8000 was it for internal projects) in the build state of
> | projects with code like:
> |
> | class bar {
> |friend class foo;
> |void baz(foo *x) {}
> | };
> |
> | from 4.0.0 in 4.0.1. This is really unfortunate. What we really
> | need is a warning (that can be easily turned off with a -Wno- switch)
> | for the next 2 years, and then an error, if you must. Doing this
> | from x.0.0 to x.0.1 is, uhm, well, more costly than if it had been
> | done in 4.0.0. :-(
> |
> | Thoughts?
>
> This area has been a historical weakness of GCC, causing us to reject
> valid-code or accept valid-code-with-wrong-semantics. As you point
> out above, it can can the overload set and such. Because the point of
> declaration is far away from the point of possible overload
> resolution, it is not all clear when an "invalid declaration accepted
> for past bug compayibility" should be or not be part of the overload
> set. You can warn, but it you turn it off, it is not obvious what the
> semantics should be.
>
> (This reminds me of the "implicit typename" stuff)
>
> -- Gaby
>
Re: Pointers in comparison expressions
On 23/07/2005, at 6:12 PM, Paul Schlie wrote: Geoffrey Keating wrote: Mirco Lorenzon wrote: .., are comparisons in the following program legal code? No. ... void *a, *b; ... if (a < b) Because 'a' and 'b' are not part of the same array, the behaviour is undefined. Although I don't mean to contest the conclusion, I do find it curious that as all pointer values referencing unique objects must be correspondingly unique, it would follow that they will be correspondingly ordered with respect to each other. Therefore although technically undefined, it seems quite reasonable to expect an implementation to support ordered inequality comparisons between arbitrary pointers to equivalent effective types? Consider an implementation which does garbage collection and compaction. In such an implementation, it might be quite inconvenient to have to maintain a consistent ordering for all pointers. As it would seem otherwise impossible for an implementation to support the ability to write code which enables the relative comparison of generalized memory pointers unless one were to explicitly declare a union of an array of all potentially allocateable memory, and all explicitly and implicitly declared objects; which doesn't seem reasonable? Although the C language doesn't guarantee the availability of such support, there is nothing that prevents an implementation from saying that it supports it, and in fact GCC does say that it supports it, through the use of a construct like ((intptr_t) a) < ((intptr_t) b) smime.p7s Description: S/MIME cryptographic signature
Re: GCC-3.4.5 status report
Gabriel Dos Reis wrote: > The full list of bugs is produced below. Maintainers, please look > into any of those and see which ones you can fix or give guidance for > fixes in ways that are suitable for a stable branch. This m68k patch: http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00783.html was approved here by the m68k maintainer: http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01427.html I believe those PRs are 3.4 regressions, despite not being marked so in Bugzilla. Fixing them is quite critical to m68k users and doesn't affect other targets. Am I still in time for 3_4-branch? -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/
