Re: Problem compiling libstdc++ is current 4.0.2 cvs (volatile strikes again)
The error makes perfect sense. __pthread_mutex has only one
assignment operator for it (implicitly generated by the compiler):
__pthread_mutex operator=(const __pthread_mutex).
When you try to pass a volatile __pthread_mutex (named as
pthread_mutex_t), the compiler can't pass it to the assignment
operator - because then `volatile' would be stripped off the
reference.
I have created a small test case to demonstrate this:
typedef volatile struct A{} Av;
void foo()
{
Av x;
x = Av();
}
This test gives an error with any compiler I could tested it with:
gcc-2.96, gcc-3.2.1, gcc-4.0.0, xlC-6.0.0
Interestingly enough, it gives an error with the native
compiler too (based on teh EDG front-end).
To fix this for GCC, I will fixincludes the volatile away.
Do you know why the type itself is defined as volatile, as opposed to
I don't, but I shall ask the person who wrote the header file.
declaring only relevant variables as volatile? What system is it anyway?
System V Release 5 (UnixWare / OpenServer 6).
Kean
Re: Problem compiling libstdc++ is current 4.0.2 cvs (volatile strikes again)
--- Kean Johnston [EMAIL PROTECTED] wrote: System V Release 5 (UnixWare / OpenServer 6). Your system is NOT supported by GCC, please read http://www.fsf.org/licensing/sco/ ___ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
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 stdio.h
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
stdio.h. 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 stdio.h
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
stdio.h. 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: [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 stdio.h
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.
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=974tstart=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/a./p will become GCC 4.1.0 (a href=gcc-4.1/changes.htmlcurrent changes/a) /dtdd Branch status: - a href=http://gcc.gnu.org/ml/gcc/2005-05/msg00224.html;2005-05-04/a - (a href=develop.html#stage2stage 2/a; open for all maintainers). + a href=http://gcc.gnu.org/ml/gcc/2005-07/msg00954.html;2005-07-22/a + (a href=develop.html#stage3stage 3/a; open for bug fixes). /dd /dl
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: [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: 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, ATT 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 path, 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
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: | 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: 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 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.
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., RD dept. \X/ http://www.develer.com/
[Bug c/23054] Segmentation fault when large static array is declared
--- Additional Comments From relf at os2 dot ru 2005-07-25 07:34 --- (In reply to comment #1) This is not a bug. You are overflowing the stack. Should it be more intelligent error message like Stack overflow ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23054
[Bug c/20303] [4.0 only] Can't push more than 16 nested visibility
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-25 07:39 --- Subject: Bug 20303 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-25 07:38:58 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: visibility-d.c Log message: PR middle-end/20303 * gcc.dg/visibility-d.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5812r2=1.5813 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/visibility-d.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20303
[Bug libstdc++/23053] Const-correctness issue in TR1 hashtable
--- Additional Comments From chris at bubblescope dot net 2005-07-25 07:46 --- Actually according to the TR1 spec (n1745 at least), there should be a non-const version which returns an iterator, and a const version which returns a const_iterator. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23053
[Bug fortran/20063] n*'xxxx' disables padding
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-25 07:51 --- Subject: Bug 20063 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-25 07:51:12 Modified files: gcc/fortran: ChangeLog data.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.fortran-torture/execute: data_4.f90 Log message: PR fortran/20063 * data.c (gfc_assign_data_value_range): Call create_character_initializer if last_ts is a character type. * gfortran.fortran-torture/execute/data_4.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gccr1=1.501r2=1.502 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/data.c.diff?cvsroot=gccr1=1.13r2=1.14 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5813r2=1.5814 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/data_4.f90.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20063
[Bug libstdc++/23053] Const-correctness issue in TR1 hashtable
--- Additional Comments From chris at bubblescope dot net 2005-07-25 07:52 --- Apologises, I misread the problem. Ignore my previous comment. Yes, I agree that find_node (which is a private function) should be const. An identical problem exists calling equal_range -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23053
[Bug libstdc++/23053] Const-correctness issue in TR1 hashtable
--- Additional Comments From pcarlini at suse dot de 2005-07-25 08:39 --- Ok, thanks. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-07-25 08:39:08 date|| Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23053
[Bug fortran/20063] n*'xxxx' disables padding
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-25 08:47 --- Subject: Bug 20063 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-07-25 08:47:01 Modified files: gcc/fortran: ChangeLog data.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.fortran-torture/execute: data_4.f90 Log message: PR fortran/20063 * data.c (gfc_assign_data_value_range): Call create_character_initializer if last_ts is a character type. * gfortran.fortran-torture/execute/data_4.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.335.2.94r2=1.335.2.95 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/data.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.11r2=1.11.10.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.299r2=1.5084.2.300 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/data_4.f90.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20063
[Bug libstdc++/22515] operator(istream, string/CharT*) can be faster
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-25 08:47 --- Subject: Bug 22515 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-25 08:47:34 Modified files: libstdc++-v3 : ChangeLog libstdc++-v3/src: istream.cc libstdc++-v3/include/bits: basic_string.h libstdc++-v3/include/std: std_istream.h std_streambuf.h Added files: libstdc++-v3/testsuite/performance/27_io: ifstream_extract_chars.cc libstdc++-v3/testsuite/27_io/basic_istream/extractors_character/char: 4.cc libstdc++-v3/testsuite/27_io/basic_istream/extractors_character/wchar_t: 4.cc Log message: 2005-07-24 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/22515 * include/bits/basic_string.h: Declare the specialization operator(basic_istreamchar, basic_stringchar). * include/std/std_istream.h: Declate the specialization operator(basic_istreamchar, char*). * include/std/std_streambuf.h (basic_streambuf): Add friend declarations for the above. * src/istream.cc: Define the above. * testsuite/27_io/basic_istream/extractors_character/char/4.cc: New. * testsuite/27_io/basic_istream/extractors_character/wchar_t/4.cc: Likewise. * testsuite/performance/27_io/ifstream_extract_chars.cc: Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gccr1=1.3061r2=1.3062 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/src/istream.cc.diff?cvsroot=gccr1=1.9r2=1.10 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/basic_string.h.diff?cvsroot=gccr1=1.81r2=1.82 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/std/std_istream.h.diff?cvsroot=gccr1=1.19r2=1.20 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/std/std_streambuf.h.diff?cvsroot=gccr1=1.51r2=1.52 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/performance/27_io/ifstream_extract_chars.cc.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/basic_istream/extractors_character/char/4.cc.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/basic_istream/extractors_character/wchar_t/4.cc.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22515
[Bug libstdc++/22515] operator(istream, string/CharT*) can be faster
--- Additional Comments From pcarlini at suse dot de 2005-07-25 08:50 --- Fixed for 4.1.0. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22515
[Bug libstdc++/22634] partial_sum is too constrained
--- Additional Comments From chris at bubblescope dot net 2005-07-25 09:03 --- I'm not personally 100% sure that this should be fixed, I've used partial_sum where I've assumed this behaviour, and adding the things in the output type would have broken... I've attached the work-around I personally use to this kind of problem, which is wrapping the iterator in another iterator which changes the value_type. Feel free to use this code if you like. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22634
[Bug libstdc++/22634] partial_sum is too constrained
--- Additional Comments From gdr at integrable-solutions dot net 2005-07-25 09:51 --- Subject: Re: partial_sum is too constrained chris at bubblescope dot net [EMAIL PROTECTED] writes: | I'm not personally 100% sure that this should be fixed, I've used | partial_sum where I've assumed this behaviour, I have codes that naturally fits partial_sum(), but will break if ported to STL with the current implementation -- and yes, I do have valid reasons to move the codes to use STL. And I think a fix is needed to match the language semantics. I don't believe in tower of wrappers where the specification is clearly not precise enough and arguably needs adjustments. '2' + '4', has type int. Period. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22634
[Bug middle-end/22608] LAPACK - BLAS test errors.
--- Additional Comments From 27roses at daum dot net 2005-07-25 10:23
---
Here is details of the build procedure.
linux-2.4.20-31.9
AMD Athlon XP 2500+
[EMAIL PROTECTED] root]# gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-
checking --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux
Thread model: posix
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
[EMAIL PROTECTED] root]# which gcc
/usr/bin/gcc
[EMAIL PROTECTED] root]#mkdir temp
[EMAIL PROTECTED] root]#cd temp
[EMAIL PROTECTED] temp]# /home/downloads/gcc-4.0.1/configure
--prefix=/usr/local/gcc-
4.0.1-F90
..
.
checking for MPFR... yes
The following languages will be built: c,c++,f95,java,objc
*** This configuration is not supported in the following subdirectories:
target-libada
(Any other directories should still work fine.)
..
.
[EMAIL PROTECTED] CLAPACK]$gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /home/downloads/gcc-4.0.1/configure --prefix=/usr/local/gcc-
4.0.1-noF --enable-languages=c,c++,objc,treelang
Thread model: posix
gcc version 4.0.1
[EMAIL PROTECTED] CLAPACK]$cp INSTALL/make.inc.LINUX ./make.inc
[EMAIL PROTECTED] CLAPACK]$export LD_LIBRARY_PATH=/usr/local/gcc-4.0.1-F90
[EMAIL PROTECTED] CLAPACK]$export LIBRARY_PATH=/usr/local/gcc-4.0.1-F90
[EMAIL PROTECTED] CLAPACK]$make f2clib
..
.
ranlib libI77.a
cp libI77.a ..
make[1]: exit `/home/ami/temp/CLAPACK/F2CLIBS/libI77' directory
[EMAIL PROTECTED] CLAPACK]$make blaslib
[EMAIL PROTECTED] CLAPACK]$cd BLAS/TESTING; make -f Makeblat2 ; \
cd .. ; \
./xblat2s sblat2.in ; \
./xblat2d dblat2.in ; \
./xblat2c cblat2.in ; \
./xblat2z zblat2.in ; \
cd TESTING; make -f Makeblat3 ; \
cd .. ; \
./xblat3s sblat3.in ; \
./xblat3d dblat3.in ; \
./xblat3c cblat3.in ; \
./xblat3z zblat3.in
..
.
../../blas_LINUX.a ../../F2CLIBS/libF77.a ../../F2CLIBS/libI77.a -lm -
lc -o ../xblat3z
[EMAIL PROTECTED] BLAS]$ cat CBLAT2.SUMM
TESTS OF THE COMPLEX LEVEL 2 BLAS
THE FOLLOWING PARAMETER VALUES WILL BE USED:
FOR N 0 1 2 3 5 9
FOR K 0 1 2 4
FOR INCX AND INCY 1 2-1-2
FOR ALPHA ( .0, .0) ( 1.0, .0) ( .7, -.9)
FOR BETA ( .0, .0) ( 1.0, .0) ( 1.3,-1.1)
ROUTINES PASS COMPUTATIONAL TESTS IF TEST RATIO IS LESS THAN 16.00
RELATIVE MACHINE PRECISION IS TAKEN TO BE 1.1E-19
CGEMV PASSED THE TESTS OF ERROR-EXITS
*** - COMPUTED RESULT IS LESS THAN HALF ACCURATE ***
EXPECTED RESULTCOMPUTED RESULT
1 (.551243, -.533049E-01) (.551243, -.533049E-01)
2 ( -.816325E-01,.389502) ( -.816325E-01,.389502)
*** CGEMV FAILED ON CALL NUMBER:
10: CGEMV ('N', 2, 1,( .7, -.9), A, 3, X, 1,( .0, .0), Y, 1)
.
CGBMV PASSED THE TESTS OF ERROR-EXITS
*** FATAL ERROR - COMPUTED RESULT IS LESS THAN HALF ACCURATE ***
EXPECTED RESULTCOMPUTED RESULT
1 (.446175, -.597479E-01) (.446175, -.597480E-01)
2 (.186813, -.929071E-01) (.186813, -.929071E-01)
*** CGBMV FAILED ON CALL NUMBER:
.
END OF TESTS
I can find 'FATAL ERRORs' in CBLAT3.SUMM, SBLAT2.SUMM, SBLAT3.SUMM .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22608
[Bug middle-end/22608] LAPACK - BLAS test errors.
--- Additional Comments From 27roses at daum dot net 2005-07-25 10:53 --- There is some miss spelling in my last connents. NOT 'gcc-4.0.1-noF' BUT 'gcc-4.0.1-F90' SORRY! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22608
[Bug c++/22545] [3.4/4.0/4.1 Regression] ICE with pointer to class member user defined conversion operator
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-25
11:47 ---
Smaller testcase:
==
struct A
{
operator A*();
};
void foo(int A::* p)
{
A() -* p;
}
==
--
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Keywords||monitored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22545
[Bug c/23058] New: visibility attribute does not work for aliased symbols
When a function or variable has its assembler name given through an
__asm__, the __attribute__((__visibility__(default))) present on the
same declaration is ignored.
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /freebsd/gnu/linuxarchive/gcc-4.0.1/configure
--prefix=/packages/gnu-inst-gcc/4.0.1 --enable-shared
--enable-version-specific-runtime-libs --enable-nls --enable-threads=posix
--enable-__cxa_atexit --with-as=/packages/gnu/bin/as
--with-ld=/packages/gnu/bin/ld
Thread model: posix
gcc version 4.0.1
$ cat bug.c
extern
int hidden_var
__asm__(my_hidden_var);
extern __attribute__((__visibility__(default)))
int exported_var
__asm__(my_exported_var);
extern
int hidden_func (void)
__asm__(my_hidden_func);
extern __attribute__((__visibility__(default)))
int exported_func (void)
__asm__(my_exported_func);
int my_hidden_var = 0;
int my_exported_var = 0;
int my_hidden_func (void) { return 0; }
int my_exported_func (void) { return 0; }
$ gcc -c -fvisibility=hidden bug.c
$ readelf --syms bug.o
Symbol table '.symtab' contains 11 entries:
Num:Value Size TypeBind Vis Ndx Name
0: 0 NOTYPE LOCAL DEFAULT UND
1: 0 FILELOCAL DEFAULT ABS bug.c
2: 0 SECTION LOCAL DEFAULT1
3: 0 SECTION LOCAL DEFAULT2
4: 0 SECTION LOCAL DEFAULT3
5: 0 SECTION LOCAL DEFAULT5
6: 0 SECTION LOCAL DEFAULT4
7: 4 OBJECT GLOBAL HIDDEN3 my_hidden_var
8: 0004 4 OBJECT GLOBAL HIDDEN3 my_exported_var
9: 10 FUNCGLOBAL HIDDEN1 my_hidden_func
10: 000a10 FUNCGLOBAL HIDDEN1 my_exported_func
$ gcc -shared -o bug.so bug.o nm bug.so | grep my_
0476 t my_exported_func
15e4 b my_exported_var
046c t my_hidden_func
15e0 b my_hidden_var
As you can see, the symbols my_exported_func, my_exported_var are not
exported from bug.so, because their visibility was HIDDEN in bug.o.
Known workaround: If I write int exported_var = 0; instead of
int my_exported_var = 0;, and int exported_func (void) { return 0; }
instead of int my_exported_func (void) { return 0; }, the problem
disappears.
--
Summary: visibility attribute does not work for aliased symbols
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bruno at clisp dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23058
[Bug target/17828] -O2 -fPIC doesn't work with switches in linkonce functions and new binutils
--- Additional Comments From olh at suse dot de 2005-07-25 11:53 --- Is there a workaround (some --foo option for gcc/ld) for these link errors? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17828
[Bug c++/21440] [4.0/4.1 Regression] ICE with statement-as-expression
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-25
11:57 ---
Shorter testcase:
===
struct A
{
~A();
};
void foo()
{
A a = ({ A b; b; });
}
===
--
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Keywords||monitored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21440
[Bug tree-optimization/23059] New: ICE: verify_ssa failed with -O3 -ftree-vectorize -Woverloaded-virtual
When I compile my application with the actual snapshot of gcc41 I get an ICE when I enable autovectorisation and -Woverloaded-virtual. last working snapshot is: gcc-4.1-20050625 first failing snapshot is: gcc-4.1-20050702 Michael Cieslinski g++41h -O3 -ftree-vectorize -Woverloaded-virtual -c FiltMgr.ii -o FiltMgr.o FiltMgr.ii: In member function 'EVT FilterMgr::calcKernel()': FiltMgr.ii:13912: error: definition in block 14 does not dominate use in block 19 for SSA_NAME: TMT.1129_15 in statement: TMT.1129_526 = PHI TMT.1129_15(19), TMT.1129_15(18); PHI argument TMT.1129_15 for PHI node TMT.1129_526 = PHI TMT.1129_15(19), TMT.1129_15(18); FiltMgr.ii:13912: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. g++41h -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.1-20050723/configure --prefix=/usr/local/gcc41h --program-suffix=41h --with-arch=opteron --enable-languages=c,c++ --enable-checking Thread model: posix gcc version 4.1.0 20050723 (experimental) -- Summary: ICE: verify_ssa failed with -O3 -ftree-vectorize - Woverloaded-virtual Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: micis at gmx dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23059
[Bug tree-optimization/23059] ICE: verify_ssa failed with -O3 -ftree-vectorize -Woverloaded-virtual
--- Additional Comments From micis at gmx dot de 2005-07-25 12:22 --- Created an attachment (id=9359) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9359action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23059
[Bug c/23054] Segmentation fault when large static array is declared
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-25 12:36 --- (In reply to comment #2) Should it be more intelligent error message like Stack overflow ? That is still not a GCC bug, report this enhancement to the OS you are using since that is where the message is comming from. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23054
[Bug middle-end/23058] visibility attribute does not work for aliased symbols
-- What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23058
[Bug fortran/20063] n*'xxxx' disables padding
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-25 12:53 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20063
[Bug c++/22603] [4.0.1 Regression] ICE in pop_binding, at cp/name-lookup.c:380
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-25
12:58 ---
Here's a similar example with valid code:
struct A
{
templateint struct B
{
void foo(const struct C);
};
};
GCC 4.0.0 is not affected - the problem was introduced between 4.0.0 and 4.0.1.
--
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Severity|minor |normal
Keywords||ice-on-valid-code, monitored
Known to fail|4.1.0 |4.0.1
Known to work|3.4.4 |3.4.4 4.0.0 4.1.0
Summary|[4.0 Regression] internal |[4.0.1 Regression] ICE in
|compiler error: in |pop_binding, at cp/name-
|pop_binding, at cp/name-|lookup.c:380
|lookup.c:380|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22603
[Bug c++/22604] [4.0/4.1 Regression] ICE after invalid covariant return
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-25
13:11 ---
Here's an example that only contains one error:
==
struct A;
struct B
{
virtual A* foo();
};
namespace N
{
struct A : B
{
virtual A* foo(); // should be ::A*
};
}
==
--
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Keywords||monitored
Summary|[4.0/4.1 Regression]|[4.0/4.1 Regression] ICE
|internal compiler error |after invalid covariant
|after invalid covariant |return
|return |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22604
[Bug c++/20549] [3.4/4.0/4.1 Regression] ICE in resolve_overloaded_unification on invalid code
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-25 13:22 --- *** This bug has been marked as a duplicate of 21592 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20549
[Bug c++/21352] [3.4 Regression] ICE with passing template function type as template type
-- Bug 21352 depends on bug 20549, which changed state. Bug 20549 Summary: [3.4/4.0/4.1 Regression] ICE in resolve_overloaded_unification on invalid code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20549 What|Old Value |New Value Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21352
[Bug c++/21592] [3.4/4.0/4.1 Regression] ICE in resolve_overloaded_unification/arg_assoc
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-25 13:22 --- *** Bug 20549 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21592
[Bug c++/21592] [3.4/4.0/4.1 Regression] ICE in resolve_overloaded_unification/arg_assoc
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-25
13:26 ---
Just for completeness, a slightly reduced version of the testcase from
PR 20549:
===
templatetypename T void unique(T,T);
struct A
{
int begin();
};
templateint void foo()
{
unique(A().begin);
}
===
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21592
[Bug c++/22405] [4.0.1/4.1 Regression] ICE in when instantiating a template function, for illegal code
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-25 13:40 --- The problem now also appears on the 4.0 branch. -- What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Keywords||monitored Known to fail|4.1.0 |4.0.1 4.1.0 Known to work|4.0.1 4.0.0 3.4.0 |4.0.0 3.4.0 Summary|[4.1 Regression] ICE in when|[4.0.1/4.1 Regression] ICE |instantiating a template|in when instantiating a |function, for illegal code |template function, for ||illegal code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22405
[Bug c++/22405] [4.0.1/4.1 Regression] ICE in when instantiating a template function, for illegal code
-- What|Removed |Added Target Milestone|4.1.0 |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22405
[Bug c++/22454] [4.0/4.1 Regression] ICE with operator in default argument in template class
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-25
13:54 ---
Here's an example with valid code:
=
templateint struct A
{
A(void(A::*)() = A::operator+);
void operator+ ();
};
=
--
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Keywords|ice-on-invalid-code |ice-on-valid-code, monitored
Summary|[4.0/4.1 Regression]|[4.0/4.1 Regression] ICE
|'template class/operator|with operator in default
|overloading/default |argument in template class
|argument' internal compiler |
|error |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22454
[Bug c++/22454] [4.0/4.1 Regression] ICE with operator in default argument in template class
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-25 13:56 --- Btw, apart from the missing semicolon at the end of the class, the original example was valid, too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22454
[Bug libstdc++/22634] partial_sum is too constrained
--- Additional Comments From squell at alumina dot nl 2005-07-25 14:01 --- (In reply to comment #13) I've attached the work-around I personally use to this kind of problem, which is wrapping the iterator in another iterator which changes the value_type. I tried this approach as well :) I called it a 'cast_iterator'. However, writing a full iterator class is involved, especially if you don't want to restrict the iterator class to 'input_iterator_tag'. Second, I felt it was 'writing to the implementation'. I know that libstdc++ uses the 'value_type' to determine the type, but this doesn't mean other implementations use it! In the end, it is a non-solution. If you've want the non-expanding behaviour, this will always be possible by simply using a function object. For example; std::partial_sum(begin, end, std::pluschar()) This is *guaranteed* not to expand. ~Marc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22634
[Bug swing/22567] JCheckBox's check box is missing
--- Additional Comments From timo dot lindfors at iki dot fi 2005-07-25 14:02 --- Actual results have changed between builds 2005-07-22T100134+ and 2005-07-23T221620+. Now the output is: java.lang.NullPointerException at gnu.java.awt.peer.gtk.GdkFontMetrics.init (GdkFontMetrics.java:69) at gnu.java.awt.peer.gtk.GtkToolkit.getFontMetrics (GtkToolkit.java:350) at javax.swing.plaf.basic.BasicGraphicsUtils.getPreferredButtonSize (BasicGraphicsUtils.java:612) at javax.swing.plaf.basic.BasicButtonUI.getPreferredSize (BasicButtonUI.java:212) at javax.swing.JComponent.getPreferredSize (JComponent.java:1029) at javax.swing.JRootPane$RootLayout.preferredLayoutSize (JRootPane.java:278) at java.awt.Container.preferredSize (Container.java:626) at java.awt.Container.getPreferredSize (Container.java:613) at javax.swing.JComponent.getPreferredSize (JComponent.java:1035) at java.awt.BorderLayout.calcCompSize (BorderLayout.java:655) at java.awt.BorderLayout.calcSize (BorderLayout.java:700) at java.awt.BorderLayout.preferredLayoutSize (BorderLayout.java:454) at java.awt.Container.preferredSize (Container.java:626) at java.awt.Container.getPreferredSize (Container.java:613) at javax.swing.JFrame.getPreferredSize (JFrame.java:136) at java.awt.Window.pack (Window.java:267) at testcase.init (testcase.java:12) at testcase.main (testcase.java:6) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22567
[Bug libstdc++/22634] partial_sum is too constrained
--- Additional Comments From squell at alumina dot nl 2005-07-25 14:04 --- Mentally fix the typographical errors in that last post. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22634
[Bug swing/22567] JCheckBox's check box is missing
--- Additional Comments From roman at kennke dot org 2005-07-25 14:17 --- Whoops, this was an accident. I don't really know why the Gtk peers can't cope with that. I checked in a fix for that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22567
[Bug c++/20724] function overload resolution fails when any template is declared
--- Additional Comments From bangerth at dealii dot org 2005-07-25 14:25 --- As for the initial testcase (Andrew's testcase in comment #1), - gcc3.3 rejects it with and without the template declaration - icc rejects it with and without the template declaration - gcc3.4 (and later) rejects it with the template, but accepts it without the template calling ::foo I believe that the later gcc compilers are in error. They should reject the code. Anyone has other opinions? W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20724
[Bug testsuite/22624] gcc.dg/tree-ssa/flatten-2.c scan-assembler-not indirect.[: \t\n] fails
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-25 14:26 --- Subject: Bug 22624 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-25 14:26:37 Modified files: gcc/testsuite : ChangeLog gcc/testsuite/gcc.dg/tree-ssa: flatten-2.c Log message: 2005-07-25 Richard Guenther [EMAIL PROTECTED] PR testsuite/22624 * gcc.dg/tree-ssa/flatten-2.c: Fix label patterns. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5816r2=1.5817 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/flatten-2.c.diff?cvsroot=gccr1=1.2r2=1.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22624
[Bug testsuite/22624] gcc.dg/tree-ssa/flatten-2.c scan-assembler-not indirect.[: \t\n] fails
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-07-25 14:26 --- Fixed (again). Hopefully. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22624
[Bug tree-optimization/23059] [4.1 Regression] ICE: verify_ssa failed with -O3 -ftree-vectorize -Woverloaded-virtual
-- What|Removed |Added Keywords||ice-on-valid-code Summary|ICE: verify_ssa failed with |[4.1 Regression] ICE: |-O3 -ftree-vectorize - |verify_ssa failed with -O3 - |Woverloaded-virtual |ftree-vectorize - ||Woverloaded-virtual Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23059
[Bug c++/22464] [3.4/4.0/4.1 Regression] ICE on classes in template functions which attempt closure
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-25 14:37 --- If one removes the class instance helper, the code compiles. This is an accepts-invalid bug (which also appeared in gcc 3.4.0). -- What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Keywords||accepts-invalid, monitored Known to fail||3.4.0 4.0.0 4.1.0 Known to work||3.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22464
[Bug swing/22567] JCheckBox's check box is missing
--- Additional Comments From timo dot lindfors at iki dot fi 2005-07-25 14:45 --- The testcase works flawlessly now, thanks! -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22567
[Bug libstdc++/22284] [4.1 Regression] ia64 exception handling broken
--- Additional Comments From sje at cup dot hp dot com 2005-07-25 15:04 --- I tested the proposed patch on IA64 HP-UX and Linux and it did fix the EH problems I saw without the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22284
[Bug other/22337] [4.1 Regression] zone collector does not build
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-25 15:14 --- Subject: Bug 22337 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-25 15:14:21 Modified files: gcc: ChangeLog ggc-zone.c Log message: 2005-07-25 Serge Belyshev [EMAIL PROTECTED] PR other/22337 * ggc-zone.c (ggc_alloc_zone_stat): Do not use CHUNK_OVERHEAD. (ggc_print_statistics): Initialize variable before use. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9537r2=2.9538 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ggc-zone.c.diff?cvsroot=gccr1=2.27r2=2.28 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22337
[Bug other/22337] [4.1 Regression] zone collector does not build
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-25 15:14 --- Fixed, I applied the fix. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22337
[Bug c++/23055] overload resolution does not find templated function
--- Additional Comments From bangerth at dealii dot org 2005-07-25 15:21
---
This basically boils down to this question:
-
template class struct S { typedef int type; };
template class T
int foo(T, typename ST::type * ret);
int j = foo(1, 0);
--
icc accepts this, gcc doesn't. I believe it should. The question is whether
the second of the arguments, of type int, should be converted to the
expected int*. During template deduction, no conversions are performed. I.e.
if we had declared foo as foo(T,T*), then we should reject the call. However,
the template type T is used in a non-deductible context in the second argument
of foo, so the type of T should be deduced only based on the first argument,
to type int then.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23055
[Bug fortran/23060] New: %VAL construct not implemented
The %VAL construct is used for passing arguments by value, rather than the usual by reference or descriptor. It is vital for interoperability with other languages such as C. This feature is available in g77: http://gcc.gnu.org/onlinedocs/gcc-3.4.4/g77/_0025VAL_0028_0029.html#_0025VAL_0028_0029 My interest in this feature comes from the world of astronomy where we have a large legacy code base (~1 Million SLOC) written in Fortran 77, (see http://cvsweb.starlink.ac.uk) where this feature is used for efficiently accessing large data arrays using mmap, complex data structures, and for accessing dynamic memory. -- Summary: %VAL construct not implemented Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: p dot w dot draper at durham dot ac dot uk CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: i386-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23060
[Bug c++/23055] overload resolution does not find templated function
--- Additional Comments From gdr at integrable-solutions dot net
2005-07-25 15:28 ---
Subject: Re: overload resolution does not find templated function
bangerth at dealii dot org [EMAIL PROTECTED] writes:
| This basically boils down to this question:
| -
| template class struct S { typedef int type; };
|
| template class T
| int foo(T, typename ST::type * ret);
|
| int j = foo(1, 0);
| --
| icc accepts this, gcc doesn't. I believe it should.
Agreed. This is a GCCbug.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23055
[Bug tree-optimization/13761] [tree-ssa] component refs to the same struct should not alias
--- Additional Comments From steven at gcc dot gnu dot org 2005-07-25
15:28 ---
The example from comment #3 now optimizes to identical inner loops:
;; Function foo (foo)
foo ()
{
int i.54;
int lsm_tmp.32;
int lsm_tmp.31;
int i;
int D.1628;
int D.1627;
int D.1623;
int x.0;
bb 0:
x.0 = x;
D.1623 = x.0 * x.0;
lsm_tmp.32 = y;
i.54 = 0;
L0:;
lsm_tmp.32 = (int) ((unsigned int) D.1623 + (unsigned int) lsm_tmp.32);
i.54 = i.54 + 1;
if (i.54 != 10) goto L0; else goto L12;
L12:;
y = lsm_tmp.32;
D.1627 = global.x;
D.1628 = D.1627 * D.1627;
lsm_tmp.31 = global.y;
i = 0;
L3:;
lsm_tmp.31 = (int) ((unsigned int) lsm_tmp.31 + (unsigned int) D.1628);
i = i + 1;
if (i != 10) goto L3; else goto L5;
L5:;
global.y = lsm_tmp.31;
return;
}
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution||FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13761
[Bug tree-optimization/20121] Aliasing lameness results in missing common subexpressions
-- Bug 20121 depends on bug 13761, which changed state. Bug 13761 Summary: [tree-ssa] component refs to the same struct should not alias http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13761 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20121
[Bug tree-optimization/16538] Missed jump threading opportunity with struct fields (but RTL thread_jumps does catch it)
-- Bug 16538 depends on bug 13761, which changed state. Bug 13761 Summary: [tree-ssa] component refs to the same struct should not alias http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13761 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16538
[Bug tree-optimization/20121] Aliasing lameness results in missing common subexpressions
-- Bug 20121 depends on bug 13761, which changed state. Bug 13761 Summary: [tree-ssa] component refs to the same struct should not alias http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13761 What|Old Value |New Value Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20121
[Bug tree-optimization/13761] [tree-ssa] component refs to the same struct should not alias
--- Additional Comments From steven at gcc dot gnu dot org 2005-07-25 15:31 --- Oddly, the test case from comment #1 is not fixed. Sorry for the inconvenience. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13761
[Bug tree-optimization/16538] Missed jump threading opportunity with struct fields (but RTL thread_jumps does catch it)
-- Bug 16538 depends on bug 13761, which changed state. Bug 13761 Summary: [tree-ssa] component refs to the same struct should not alias http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13761 What|Old Value |New Value Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16538
[Bug fortran/23060] %VAL construct not implemented
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-25 15:34 --- Confirmed. -- What|Removed |Added OtherBugsDependingO||19292 nThis|| Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-07-25 15:34:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23060
[Bug tree-optimization/13761] [tree-ssa] component refs to the same struct should not alias
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-07-25 15:40 --- Yes, it won't be fixed till 4.2, or the aliasing branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13761
[Bug middle-end/21105] [4.0/4.1 Regression] Compiling of large array fails
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-25 15:50 --- Hmm, Jim posted a patch here: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00377.html but never applied it. -- What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2005- |patches/2005- |05/msg00121.html|05/msg00377.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21105
[Bug target/21723] [4.0 Regression] ICE while building libgfortran
-- What|Removed |Added Known to work||4.1.0 Summary|[4.0/4.1 Regression] ICE|[4.0 Regression] ICE while |while building libgfortran |building libgfortran Target Milestone|4.1.0 |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21723
[Bug treelang/23061] New: treelang testsuite fails with -m64
In http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg01345.html there are treelang test suite failures like this: Test Run By chj on Mon Jul 25 03:19:50 2005 Native configuration is sparc64-unknown-linux-gnu === treelang tests === Schedule of variations: unix/-m64 unix Running target unix/-m64 Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /usr/local/src/branch/gcc/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /usr/local/src/branch/gcc/gcc/testsuite/treelang/compile/compile.exp ... set_ld_library_path_env_vars: ld_library_path=:/usr/local/src/branch/objdir/gcc:/usr/local/src/branch/objdir/gcc/64 set_ld_library_path_env_vars: ld_library_path=.::/usr/local/src/branch/objdir/gcc:/usr/local/src/branch/objdir/gcc/64 Executing on host: /usr/local/src/branch/objdir/gcc/xgcc -B/usr/local/src/branch/objdir/gcc/ /usr/local/src/branch/gcc/gcc/testsuite/treelang/compile/autofunc.tree-S -m64 -o autofunc.s(timeout = 9000) /usr/local/src/branch/gcc/gcc/testsuite/treelang/compile/autofunc.tree:0: error: -mlong-double-64 not allowed with -m64 compiler exited with status 1 output is: /usr/local/src/branch/gcc/gcc/testsuite/treelang/compile/autofunc.tree:0: error: -mlong-double-64 not allowed with -m64 FAIL: treelang/compile/autofunc.tree (test for errors, line 2) FAIL: treelang/compile/autofunc.tree (test for excess errors) Excess errors: /usr/local/src/branch/gcc/gcc/testsuite/treelang/compile/autofunc.tree:0: error: -mlong-double-64 not allowed with -m64 Maybe a mulitlib problem hitting only 4.0 branch and not mainline... -- Summary: treelang testsuite fails with -m64 Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: treelang AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: christian dot joensson at gmail dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: sparc64-unknown-linux-gnu GCC host triplet: sparc64-unknown-linux-gnu GCC target triplet: sparc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23061
[Bug fortran/23062] New: %VAL construct not implemented
The %VAL construct is used for passing arguments by value, rather than the usual by reference or descriptor. It is vital for interoperability with other languages such as C. This feature is available in g77: http://gcc.gnu.org/onlinedocs/gcc-3.4.4/g77/_0025VAL_0028_0029.html#_0025VAL_0028_0029 My interest in this feature comes from the world of astronomy where we have a large legacy code base (~1 Million SLOC) written in Fortran 77, (see http://cvsweb.starlink.ac.uk) where this feature is used for efficiently accessing large data arrays using mmap, complex data structures, and for accessing dynamic memory. -- Summary: %VAL construct not implemented Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: p dot w dot draper at durham dot ac dot uk CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: i386-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23062
