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. So it looks like the slowdown is caused by one of the profile based optimizations that are enabled by default (basic block reordering or register allocation). If you are getting such a noticable slodown, it probably means that your app has pretty small inner loop. Can you just look into assembly generated for it with and without profiling and try to spot what is gong wrong? Thanks, Honza 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: GCC-3.4.5 status report
Bernardo Innocenti [EMAIL PROTECTED] writes: | 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? Yes. -- Gaby
Re: PING [4.1 regression, patch] build i686-pc-mingw32
Paolo, could you go back and think about the bootstrapping problem from MinGW's perspective? I had considered cygwin, that had some problems because of the executable-file extension. I had also thought of using batch files via config.build, but got stuck because Windows. does not have as far as I know, the equivalent of $@; and anyway it seems strange to need a batch file where everything else is msys-based. So yes, I think the solution of hacking pex-win32.c is great. Paolo
Re: rfa (x86): 387=sse moves
Dale Johannesen wrote:
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
Try the attached patch. It gave a 3% speedup on -mfpmath=sse for
tramp3d. Richard Henderson asked for SPEC testing, then it may go in.
Paolo
2005-07-14 Paolo Bonzini [EMAIL PROTECTED]
* reload.c (find_reloads): Take PREFERRED_OUTPUT_RELOAD_CLASS
into account.
(push_reload): Allow PREFERRED_*_RELOAD_CLASS to liberally
return NO_REGS.
* doc/tm.texi (Register Classes): Document what it means
if PREFERRED_*_RELOAD_CLASS return NO_REGS.
* config/i386/i386.c (ix86_preferred_reload_class): Force
using SSE registers (and return NO_REGS for floating-point
constants) if math is done with SSE.
(ix86_preferred_output_reload_class): New.
* config/i386/i386-protos.h (ix86_preferred_output_reload_class): New.
* config/i386/i386.h (PREFERRED_OUTPUT_RELOAD_CLASS): New.
* config/i386/i386.md: Remove # register preferences.
Index: reload.c
===
RCS file: /cvs/gcc/gcc/gcc/reload.c,v
retrieving revision 1.273
diff -c -r1.273 reload.c
*** reload.c25 Jun 2005 02:00:53 - 1.273
--- reload.c14 Jul 2005 08:07:56 -
***
*** 1231,1245
/* Narrow down the class of register wanted if that is
desirable on this machine for efficiency. */
! if (in != 0)
! class = PREFERRED_RELOAD_CLASS (in, class);
/* Output reloads may need analogous treatment, different in detail. */
#ifdef PREFERRED_OUTPUT_RELOAD_CLASS
! if (out != 0)
! class = PREFERRED_OUTPUT_RELOAD_CLASS (out, class);
#endif
/* Make sure we use a class that can handle the actual pseudo
inside any subreg. For example, on the 386, QImode regs
can appear within SImode subregs. Although GENERAL_REGS
--- 1231,1254
/* Narrow down the class of register wanted if that is
desirable on this machine for efficiency. */
! {
! enum reg_class preferred_class = class;
!
! if (in != 0)
! preferred_class = PREFERRED_RELOAD_CLASS (in, class);
/* Output reloads may need analogous treatment, different in detail. */
#ifdef PREFERRED_OUTPUT_RELOAD_CLASS
! if (out != 0)
! preferred_class = PREFERRED_OUTPUT_RELOAD_CLASS (out, preferred_class);
#endif
+ /* Discard what the target said if we cannot do it. */
+ if (preferred_class != NO_REGS
+ || (optional type == RELOAD_FOR_OUTPUT))
+ class = preferred_class;
+ }
+
/* Make sure we use a class that can handle the actual pseudo
inside any subreg. For example, on the 386, QImode regs
can appear within SImode subregs. Although GENERAL_REGS
***
*** 3443,3457
/* If we can't reload this value at all, reject this
alternative. Note that we could also lose due to
!LIMIT_RELOAD_RELOAD_CLASS, but we don't check that
here. */
if (! CONSTANT_P (operand)
! (enum reg_class) this_alternative[i] != NO_REGS
! (PREFERRED_RELOAD_CLASS (operand,
! (enum reg_class)
this_alternative[i])
! == NO_REGS))
! bad = 1;
/* Alternative loses if it requires a type of reload not
permitted for this insn. We can always reload SCRATCH
--- 3452,3477
/* If we can't reload this value at all, reject this
alternative. Note that we could also lose due to
!LIMIT_RELOAD_CLASS, but we don't check that
here. */
if (! CONSTANT_P (operand)
! (enum reg_class) this_alternative[i] != NO_REGS)
! {
! if (PREFERRED_RELOAD_CLASS
! (operand, (enum reg_class) this_alternative[i])
! == NO_REGS)
! bad = 1;
!
! #ifdef PREFERRED_OUTPUT_RELOAD_CLASS
! if (operand_type[i] == RELOAD_FOR_OUTPUT
! PREFERRED_OUTPUT_RELOAD_CLASS
! (operand, (enum reg_class) this_alternative[i])
!== NO_REGS)
! bad = 1;
! #endif
! }
!
/* Alternative loses if it requires a type of reload not
permitted for this insn. We can always reload SCRATCH
Index: doc/tm.texi
===
RCS file: /cvs/gcc/gcc/gcc/doc/tm.texi,v
retrieving revision 1.441
diff -p -u -r1.441 tm.texi
*** doc/tm.texi 13 Jul 2005
how to write a define_peephole2 that uses custom registers in nios2
Hi, nios2 has a set of custom registers for custom instructions. They all start with c, like custom 1 c4, c2, c0 I want to define a peephole to replace a sequence of codes with this above custom instruction. custom instruction is defined as following in nios2.md (define_insn custom_inii [(set (match_operand:SI 0 register_operand =r) (unspec_volatile:SI [(match_operand:SI 1 custom_insn_opcode N) (match_operand:SI 2 register_operand r) (match_operand:SI 3 register_operand r)] CUSTOM_INII))] custom\\t%1, %0, %2, %3 [(set_attr type custom)]) But the problem is it uses normal register, like r8, r9. How can I write the define_peephole2 so that it uses custom registers? Thanks Haibin
Please help with __attribute__ weak
I need to declare a symbol which is weaker in the executable than in any
external static or dynamic library.
In other words, the executable provides some fallback function
implementation (in my example, for write). But if the linker or
dynamic linker resolves it, the symbol definition from an external
library must be used.
I use:
__f_write_weak_alias(int __fd, __const __ptr_t __buf, size_t __n)
__attribute__((weak, alias (write))); /* alias declaration */
int write(int __fd, __const __ptr_t __buf, size_t __n) {
printf(Abort\n);
} /* fallback implementation */
But even though write is resolved, calling the __f_write_weak_alias
just prints Abort i. e. the symbol write was not overridden by the
library definition.
What is the right way to do this?
Thanks for any advice.
Dimitry Golubovsky
Middletown, CT
Re: Please help with __attribute__ weak
On Tue, Jul 26, 2005 at 07:19:43AM -0400, Dimitry Golubovsky wrote: I need to declare a symbol which is weaker in the executable than in any external static or dynamic library. In other words, the executable provides some fallback function implementation (in my example, for write). But if the linker or dynamic linker resolves it, the symbol definition from an external library must be used. The weak symbol is different from the normal one only during creating executable or shared library if it is in a relocatable file. You can't use weak symbol for your purpose. But you can mark your symbol in shared library protected. H.J.
Re: Please help with __attribute__ weak
Dimitry Golubovsky wrote: I need to declare a symbol which is weaker in the executable than in any external static or dynamic library. In other words, the executable provides some fallback function implementation (in my example, for write). But if the linker or dynamic linker resolves it, the symbol definition from an external library must be used. H. J. Lu wrote: The weak symbol is different from the normal one only during creating executable or shared library if it is in a relocatable file. You can't use weak symbol for your purpose. But you can mark your symbol in shared library protected. = Well, libraries are not created by me, so I cannot rely on any possibility to mark symbols in it. Besides, this is for an automated tool which may deal with tens of functions at once (this is for a Haskell FFI generator known as `hsffig' that I am developing). If there is no way to declare overridable symbols in executables, then perhaps placing all those fallback stub functions in a separate static library (.a) and telling the linker to use it last (after all default and user-specified libraries) could do the job, couldn't it? This is less desirable though, as it complicates the linker command line, but if there is no way to do this via declaration in C code, I'll go with the library. -- Dimitry Golubovsky Anywhere on the Web
Re: Please help with __attribute__ weak
On Tue, Jul 26, 2005 at 10:16:48AM -0400, Dimitry Golubovsky wrote: Dimitry Golubovsky wrote: I need to declare a symbol which is weaker in the executable than in any external static or dynamic library. In other words, the executable provides some fallback function implementation (in my example, for write). But if the linker or dynamic linker resolves it, the symbol definition from an external library must be used. H. J. Lu wrote: The weak symbol is different from the normal one only during creating executable or shared library if it is in a relocatable file. You can't use weak symbol for your purpose. But you can mark your symbol in shared library protected. = Well, libraries are not created by me, so I cannot rely on any possibility to mark symbols in it. Besides, this is for an automated tool which may deal with tens of functions at once (this is for a Haskell FFI generator known as `hsffig' that I am developing). If there is no way to declare overridable symbols in executables, then perhaps placing all those fallback stub functions in a separate static library (.a) and telling the linker to use it last (after all default and user-specified libraries) could do the job, couldn't it? Yes. H.J.
Re: Is there a way to exclude a dir from multilibing?
All, Is there a way to exclude a given directory, for example, libjava, from multilibing? There are certainly cases where it may make sense to have the C/C++ runtime be multilibbed one way, but not have libjava multilibed the same way. I looked for something like this in the docs and didn't find it but perhaps someone knows some voodoo I can use? No there is no way. Multilibbed means all libraries and really supposed to be used with different ABIs and not different APIs. -- Pinski
Re: -fprofile-generate and -fprofile-use
Jan, That's going to be rather difficult given that the app has over 1000 files. Is there a way I can turn off the default options one at a time ? Thx -girish --- Jan Hubicka [EMAIL PROTECTED] wrote: 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. So it looks like the slowdown is caused by one of the profile based optimizations that are enabled by default (basic block reordering or register allocation). If you are getting such a noticable slodown, it probably means that your app has pretty small inner loop. Can you just look into assembly generated for it with and without profiling and try to spot what is gong wrong? Thanks, Honza 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
#pragma support to guide autovectorizer
I was wondering if any addition work had been completed toward pragma support for the autovectorization branch (see http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01560.html)? Thanks.. Chad Rosier
Re: How to make an application look somewhere other than /lib for ld-linux.so.2
Ok - thanks. For #1, if I build with --static, then no libraries can be linked in dynamically at runtime... I need to do this for some custom Qt libraries and plugins, so I can't just make a completely static executable. This is unfortunate - the resulting binaries would be big, but they'd work on any distro. #2 - I'd never heard of LSB or lsbcc... I've just done a google and turned up an article on an IBM website on building binary-compatible Linux applications... Thanks for the pointer on this one - it looks like this may be the way to go. Mark - Original Message - From: Daniel Kegel [EMAIL PROTECTED] To: gcc@gcc.gnu.org; Mark Cuss [EMAIL PROTECTED] Sent: Thursday, July 14, 2005 4:07 PM Subject: How to make an application look somewhere other than /lib for ld-linux.so.2 Mark Cuss [EMAIL PROTECTED] wrote: I'm trying to get myself a group of libraries that I can distribute with my program so that they'll run on any distro. I run into problems all the time when different distros have different versions of system libraries like libstdc++, libgcc, libc, etc. ... Is there a way to somehow configure gcc build executables that look elsewhere for ld-linux.so.2, or is what I'm trying to do simply not possible? I'd really like to have a set of libraries with my program so that it's binary compatible with other distros... there must be a way. If anyone has any tips or advice I'd appreciate it. There are two official ways to go: 1) Build static binaries. (If your apps use libnss*.a, you may want to configure your toolchain's glibc with --enable-static-nss; I'm doing that now for one project. Don't tell drepper.) 2) Build your apps with lsbcc. That will link to the LSB's frozen version of libstdc++, etc. #1 is doable right now. #2 is, too, but requires your users to install your distro's LSB runtime package. - Dan
Re: How to make an application look somewhere other than /lib for ld-linux.so.2
I appreciate your help, but I don't really appreciate the way you insinuate that I didn't do some leg work before running off to the mailing list. I *DID* RTFM, thank you very much. I found the -rpath option, tried it, and it didn't work. I mentioned this in my original post - I was confused as to why the option didn't do what it was supposed to do, so I posed the question here as I figured the experts here would now why the option didn't work and would perhaps provide a solution. I'm pretty certain that I'm not the only person who struggles with the Oh, that app was built on RH 8 so it won't run on RH 7.3 problems, so I'm trying to find a solution where I can configure my build system in such a way that I can distribute a set of libraries with my applications to that it will run on any distro - at least all of the Red Hats, Fedora Cores, and RHELs anyways. Mark - Original Message - From: Kai Ruottu [EMAIL PROTECTED] To: Mark Cuss [EMAIL PROTECTED] Cc: gcc@gcc.gnu.org Sent: Friday, July 15, 2005 4:27 AM Subject: Re: How to make an application look somewhere other than /lib for ld-linux.so.2 Mark Cuss kirjoitti: Hello all I apologize if this is off topic for this list - I wasn't sure exactly where to ask but I thought this would be a good place to start: Something for newbies like gcc-help? I'm trying to get myself a group of libraries that I can distribute with my program so that they'll run on any distro. On SuSEs, Mandrakes, Debians,...? Or on only Red Hats and Fedoras? I run into problems all the time when different distros have different versions of system libraries like libstdc++, libgcc, libc, etc. Excluding libstdc++*.so's all these should be backwards compatible with old apps produced on old systems... But usually only among the same company. So Red Hat 8.0 should run apps made for Red Hat 6.x and 7.x and maybe even older apps made for Red Hat. This is what one could expect, an opsys made for company use must be stable in the sense that in some time frame all apps made for it should run... In the (bad?) Windoze, SCO, UnixWare, Solaris2 etc. worlds this backwards-compatability issue has always taken seriously. But I remember in 1994 the (Finnish) Linux experts to tell that Linux WILL NEVER have any backwards compatability or any binary compatability between its distros! People are assumed to rebuild all apps to the new Linux installations! People like me who thought things like the then new Novell UnixWare to be a good thing because it claimed compatability with almost every source and binary made that far, were doomed as being heretics... But Linux entering into the company world has caused pressure for binary compatability a'la MS, SCO,... So nowadays one can download a new Firefox 1.0.5 for Linux/x86 and expect it to work OK on one's Red Hat, SuSE, Debian and so on !!! That this is possible, must be a horrible disappointment to the old Linux users... To make this application run on a Red Hat 7.3 machine, At least the backwards compatability for apps made for Red Hat 7.3 has this far seemed perfect... Alls the apps made for RHL 7.3 on RH 8.0 by me have run OK both on RH 8.0 and on RH 7.x too... So my advice is to produce the apps for the least common nominator. Maybe Red Hat 7.3 could be this for RH 7.x, 8.0 and 9, and for the Fedora Cores. But I have no experience about the SuSEs. Maybe one must have a similar least common nominator toolchain for those... So - the question is: How do I do this? Even though LD_LIBRARY_PATH points to ./ as it's first entry, ldd still looks in /lib first for ld-linux.so.2. I've tried the rpath option to ld at link time, but that doesn't work either. It seems that thing is somehow hardcoded to look in /lib for this library. Trying the backwards compatability sounds being the natural thing for me. Generally those native GCCs used as the production tools for any apps (excluding the GCCs) is from the ass, IMHO... Instead one should produce portable GCCs so that when one has produced several GCCs for the then installed host, one could just copy them to the (backwards compatible) new Linux distro. Without rebuilding them. Heretics maybe, but struggling with trying to produce egcs-1.1.2 for RHL 6.2 target using gcc-3.4 or something on Fedora is really not seen as any alternative by me if needing to produce apps for RH 6.2 on Fedora... Sometimes in the past I understood that native GCCs are from the ass and after that I have produced only crosscompilers for everything, even for the native target... On my RHL 8.0 all the GCCs for RHL 8.0 target are crosscompilers for RHL 8.0. And made for the current least common nominator runtime host, RHL 7.3... Is there a way to somehow configure gcc build executables that look elsewhere for ld-linux.so.2, or is what I'm trying to do simply not possible? I'd really like to have a set of libraries with my program so that it's binary compatible with other
Re: How to make an application look somewhere other than /lib for ld-linux.so.2
Oh! I didn't know you could do that! Thanks very much! Mark - Original Message - From: Haren Visavadia [EMAIL PROTECTED] To: Mark Cuss [EMAIL PROTECTED] Cc: gcc@gcc.gnu.org Sent: Tuesday, July 26, 2005 1:29 PM Subject: Re: How to make an application look somewhere other than /lib for ld-linux.so.2 --- Mark Cuss wrote: For #1, if I build with --static, then no libraries can be linked in dynamically at runtime... I need to do this for some custom Qt libraries and plugins, so I can't just make a completely static executable. This is unfortunate - the resulting binaries would be big, but they'd work on any distro. This is possible by using something like -Wl,-Bdynamic, (insert list of libraries to be dynamically linked),-Bstatic For example, if you want to dynamically link against Qt library and glibc and rest of it being static, you can use -Wl,-Bdynamic,-lqt-mt,-lc,-Bstatic ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
Annotations in tree
Hi, I am trying to find out how to insert annotations for certain array references identified in tree-loop-linear.c so that when converting to RTL they can be handled differently. I find that simply inserting a flag in the tree node is not enough as optimizations later on can lead to the node being removed. Can any tell me what else can I do ? I will appreciate all help dz
Re: gcc 3.3.6 - stack corruption questions
On 07/26/05 12:28 AM, Giovanni Bajo sat at the `puter and typed: 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. Well, I don't care about size that much. This isn't an embedded app, and performance and stability usually contend with each other for the primary concern. I did finally get a build with 4.0.1. I certainly was surprised at some of the things I found, but it did help a lot. Funny thing is that the same compiler flags provide a much bigger executable with 4.0.1 than with 3.3.6, but it doesn't core trying to release a thread lock. I've also confirmed that this happens without contention because one of the apps that uses this code actually only runs a single thread. I used the following flags: -ggdb -g3 -Wall -fstack-check -fno-strict-aliasing -O2 -mcpu=ultrasparc The -fmudflaps flag requires some odd linking I haven't figured out yet, so I'm skipping it for now. I also found, to my delight and surprise, that the same code appears to perform between 10% and 20% better - in a rough, fairly imprecise environment. I still cannot find the cause of the core I get with the 3.3.6 version though. What I do get with 4.0.1 is some warnings I'd never seen before: disk.c: In function 'disk_find': disk.c:281: warning: frame size too large for reliable stack checking disk.c:281: warning: try reducing the number of local variables I was initially getting this for about 20 of my functions. I know very well that I'm using some large stacks, so I wasn't surprised about that, I was just surprised that the threshold here appears to be quite low (is it around 8K? - please clarify for me if you know). This process does some pretty heavy text management for URL transforms and transaction logging, so several routines statically allocate some fairly large character buffers for this. When I first saw these warnings, I went through and moved a few buffers to different scopes and changed a couple to dynamic allocations, since they weren't needed in all cases. This helped eliminate most of these (down to 6 functions), but some still require these buffers for all transactions, so it doesn't make much sense (to me, anyway) to allocate them dynamically. The source file that is still generating a core with 3.3.6 did have a couple of these warnings (in different functions, not the one that was coring), but they were easily accomodated, and even though the warnings are gone in the 4.0.1 build, it still cores with the 3.3.6 build unless I turn off optimization for that file. I know it's confusing, but I'm trying to use the behavior from the two compiler versions to make the code itself better, rather than just picking the compiler that seems to work. I was actually hoping to get more discernable info in the 3.3.6 build core after these changes, but the core hasn't actually changed. Looking at the gcc docs, I noticed the -fstack-limit flags, but I'm not real clear if or how they can help, or exactly how they're used. I am using the gcc linker, so the method described in the docs should be fine if it applies, but it looks like an absolute address is needed for the lower bound. Any pointers on where I can get clarification on these flags and the default stack size limits? If I should be taking this to a usenet group or some other forum instead of here, please let me know. Once again, many thanks to all those that have provided input so far. It's been very helpful. 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 QOTD: If you keep an open mind people will throw a lot of garbage in it.
Re: gcc 3.3.6 - stack corruption questions
Louis LeBlanc wrote: I also found, to my delight and surprise, that the same code appears to perform between 10% and 20% better - in a rough, fairly imprecise environment. why surprise?
Re: Annotations in tree
I am not sure if I unerstand ...can you elaborate please ? So what I need is if I identify say a reference a[i] inside a loop, I want to identify the corresponding RTL. What I find now is that these get transformed for example D.1065_17 = a_matrix[i_24][k_30]; // I have identified this sum_12 = D.1065_17 + sum_31; gets coalesced back into sum = a_matrix[i][k] + sum; before it is expaned into rtl.. How do I keep track that it is indeed the same array reference though it has gone through some transformation. ( One another tranformation is generating a pointer to it instead of using the array). Sumesh On 7/26/05, Diego Novillo [EMAIL PROTECTED] wrote: On Tue, Jul 26, 2005 at 04:21:51PM -0400, drizzle drizzle wrote: I am trying to find out how to insert annotations for certain array references identified in tree-loop-linear.c so that when converting to In the ARRAY_REFs themselves? I would build a hash table on the side. If it's on the DECLs, you could use var_ann() to add annotations.
Re: Annotations in tree
On Tue, 2005-07-26 at 18:39 -0400, drizzle drizzle wrote: I am not sure if I unerstand ...can you elaborate please ? So what I need is if I identify say a reference a[i] inside a loop, I want to identify the corresponding RTL. What are you trying to do at the RTL level with array references? They don't last that long.
Re: Annotations in tree
What doesnt exist very long - the references ? At RTL level, I just want to insert a counter for each one of these. One alternative I saw is inserting a dummy functiion call. Would that work ? If so, for a given name, how do I create a corresponding function expression for it ? thanks for the answers On 7/26/05, Daniel Berlin [EMAIL PROTECTED] wrote: On Tue, 2005-07-26 at 18:39 -0400, drizzle drizzle wrote: I am not sure if I unerstand ...can you elaborate please ? So what I need is if I identify say a reference a[i] inside a loop, I want to identify the corresponding RTL. What are you trying to do at the RTL level with array references? They don't last that long.
gcc-3.4-20050726 is now available
Snapshot gcc-3.4-20050726 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050726/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 3.4 CVS branch with the following options: -rgcc-ss-3_4-20050726 You'll find: gcc-3.4-20050726.tar.bz2 Complete GCC (includes all of below) gcc-core-3.4-20050726.tar.bz2 C front end and core compiler gcc-ada-3.4-20050726.tar.bz2 Ada front end and runtime gcc-g++-3.4-20050726.tar.bz2 C++ front end and runtime gcc-g77-3.4-20050726.tar.bz2 Fortran 77 front end and runtime gcc-java-3.4-20050726.tar.bz2 Java front end and runtime gcc-objc-3.4-20050726.tar.bz2 Objective-C front end and runtime gcc-testsuite-3.4-20050726.tar.bz2The GCC testsuite Diffs from 3.4-20050719 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-3.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Annotations in tree
On Tue, 2005-07-26 at 19:42 -0400, drizzle drizzle wrote: What doesnt exist very long - the references ? By RTL, they've been expanded to pointer accesses. At RTL level, I just want to insert a counter for each one of these. Why do it at the rtl level. Why not do it at the tree level?
Re: Annotations in tree
tree level is fine too, it was just that the RTL level already had a host of counters being inserted. One implementation question if I may ask, so at the tree level how do I create a call to my function. I know how to insert it into the tree but some how all my creations attempts with build_function_call fail. thanks once again ... On 7/26/05, Daniel Berlin [EMAIL PROTECTED] wrote: On Tue, 2005-07-26 at 19:42 -0400, drizzle drizzle wrote: What doesnt exist very long - the references ? By RTL, they've been expanded to pointer accesses. At RTL level, I just want to insert a counter for each one of these. Why do it at the rtl level. Why not do it at the tree level?
Re: Annotations in tree
On Tue, 2005-07-26 at 20:08 -0400, drizzle drizzle wrote: tree level is fine too, it was just that the RTL level already had a host of counters being inserted. One implementation question if I may ask, so at the tree level how do I create a call to my function. build_function_call_expr. Look at what tree-profile.c does. I know how to insert it into the tree but some how all my creations attempts with build_function_call fail. thanks once again ... On 7/26/05, Daniel Berlin [EMAIL PROTECTED] wrote: On Tue, 2005-07-26 at 19:42 -0400, drizzle drizzle wrote: What doesnt exist very long - the references ? By RTL, they've been expanded to pointer accesses. At RTL level, I just want to insert a counter for each one of these. Why do it at the rtl level. Why not do it at the tree level?
gcc binary
Hi, Where can I download gcc binary code for Linux? What's URL? Thanks. simon __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: gcc binary
On Tue, Jul 26, 2005 at 09:15:20PM -0700, Simon Tsai wrote: Where can I download gcc binary code for Linux? What's URL? You're best off using the gcc package that is designed to work with your distribution. Please ask a list that is devoted to your GNU/Linux distribution to find out how to do that.
Re: gcc binary
Simon Tsai [EMAIL PROTECTED] writes: Where can I download gcc binary code for Linux? What's URL? This is actually the wrong mailing list for this question. Can you tell us why you wrote to this list, so that we can encourage people to write to the correct list instead? Thanks. The right mailing list would be [EMAIL PROTECTED] You can find some binaries on http://gcc.gnu.org. Look at the selections on the left hand side. Click on binaries. Most Linux distributions include gcc anyhow. Whatever distro you are using probably has a way to download some version of gcc. Ian
Re: How to make an application look somewhere other than /lib for ld-linux.so.2
Mark Cuss wrote: I'm pretty certain that I'm not the only person who struggles with the Oh, that app was built on RH 8 so it won't run on RH 7.3 problems, so I'm trying to find a solution where I can configure my build system in such a way that I can distribute a set of libraries with my applications to that it will run on any distro - at least all of the Red Hats, Fedora Cores, and RHELs anyways. Perhaps you can just ship a bunch of object files and do the final linking only as a part of your installation process. Of course, since the C++ ABI changed with GCC 3.x, you might want to bundle the C++ libraries, but leave out everything else. It would also mean that end-users have to have binutils, and perhaps make, installed on their machines as a pre-requisite. Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Re: How to make an application look somewhere other than /lib for ld-linux.so.2
Mark Cuss wrote: I'm pretty certain that I'm not the only person who struggles with the Oh, that app was built on RH 8 so it won't run on RH 7.3 problems, so I'm trying to find a solution where I can configure my build system in such a way that I can distribute a set of libraries with my applications to that it will run on any distro - at least all of the Red Hats, Fedora Cores, and RHELs anyways. Why restrict yourself to a small subset of the list of distros? With a little bit of effort you can handle Debian, Ubuntu, SuSE, Mandrake and others too. This question was asked a while go on another mailing list. I posted what I do there in that list. Here is a pointer to an archive of my method of platform independence. Basically I bundle all of the libraries and wrap the executable in a script wrapper. http://subversion.tigris.org/servlets/ReadMsg?listName=usersmsgNo=32310 This is off-topic for this list. But I am happy to discuss the issues with you either directly or in a more appropriate forum. Bob
[Bug libmudflap/20003] libmudflap.cth
--- Additional Comments From gschafer at zip dot com dot au 2005-07-26 06:07 --- (In reply to comment #1) Fixed at least in 4.0.1. No it's not. Please see these results for example (all from different folks): http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg01370.html http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg01310.html http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00831.html http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00621.html http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00603.html Here is an example of what shows up in the log file: Overriding timeout = 20 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500 1600 1700 1800 1900 2000 2100 2200 2300 2400 2500 2600 2700 2800 2900 3000 3100 3200 3300 3400 3500 3600 3700 3800 3900 4000 4100 4200 4300 4400 4500 4600 4700 4800 4900 5000 FAIL: libmudflap.cth/pass40-frag.c execution test FAIL: libmudflap.cth/pass40-frag.c output pattern test Output pattern 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500 1600 1700 1800 1900 2000 2100 2200 2300 2400 2500 2600 2700 2800 2900 3000 3100 3200 3300 3400 3500 3600 3700 3800 3900 4000 4100 4200 4300 4400 4500 4600 4700 4800 4900 5000 5100 5200 5300 5400 5500 5600 5700 5800 5900 6000 6100 6200 6300 6400 6500 6600 6700 6800 6900 7000 7100 7200 7300 7400 7500 7600 7700 7800 7900 8000 8100 8200 8300 8400 8500 8600 8700 8800 8900 9000 9100 9200 9300 9400 9500 9600 9700 9800 9900 1 Please reopen bug. Thanks. -- What|Removed |Added CC||gschafer at zip dot com dot ||au http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20003
[Bug libmudflap/23069] New: libmudflap.cth timeouts too short
In these files:
libmudflap/testsuite/libmudflap.cth/pass3{7,9}-frag.c
the timeout is overridden to 3 seconds. This is way too short if for example
running the testsuite with -j3 on an SMP box. It results in many timeouts as per
these examples:
http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg01114.html
http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00451.html
I'm not sure what the ideal timeout should be but 20 seconds made the timeouts
go away for me. Thanks.
--
Summary: libmudflap.cth timeouts too short
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libmudflap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gschafer at zip dot com dot au
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23069
[Bug c/23070] New: CALL_V4_CLEAR_FP_ARGS flag not properly set
When a prototyped function of var-arg is called without any arguments
to the variable part, crxor 6,6,6 is not generated. -O0
-mno-prototype does NOT resolve the problem either.
test.c
int test(const char *a, ...);
void test1(const char *a)
{ test(a, 0); }
void test2(const char *a)
{ test(a); }
test.s
.file test.c
.section.text
.align 2
.globl test1
.type test1, @function
test1:
stwu 1,-24(1)
mflr 0
stw 31,20(1)
stw 0,28(1)
mr 31,1
stw 3,8(31)
lwz 3,8(31)
li 4,0
crxor 6,6,6== has it
bl test
lwz 11,0(1)
lwz 0,4(11)
mtlr 0
lwz 31,-4(11)
mr 1,11
blr
.size test1, .-test1
.align 2
.globl test2
.type test2, @function
test2:
stwu 1,-24(1)
mflr 0
stw 31,20(1)
stw 0,28(1)
mr 31,1
stw 3,8(31)
lwz 3,8(31)
bl test == does not have
lwz 11,0(1)
lwz 0,4(11)
mtlr 0
lwz 31,-4(11)
mr 1,11
blr
.size test2, .-test2
.ident GCC: (GNU) 3.4.3
--
Summary: CALL_V4_CLEAR_FP_ARGS flag not properly set
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tong_ho at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: powerpc-eabi-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23070
[Bug tree-optimization/23068] [4.1 Regression] errors in comparison operator for char
--- Additional Comments From Jean-pierre dot vial at wanadoo dot fr
2005-07-26 06:36 ---
(In reply to comment #1)
I cannot reproduce it on 20050725. What options are you using to create the
executable.
I tried with -O0, -O1, -O2, and -O3 and no success.
no bug with -O0 or -O1
bug with -O2 and -O3
incidentally, if the code is modified as
unsigned char c,d;
d=128;
for (c=127;c130;c++){
printf(test : (char) %d = 128 result %d\n,c,c=128);
printf(test : (char) %d 128 result %d\n,c,c128);
everything works fine
I am presently re-compiling version 20050725 in case of
hardware bug during my first compilation of the compiler.
I will see if this fixes the problem.
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23068
[Bug target/23071] New: Darwin alignment ignores attribute packed for first 'double' element of a struct
Darwin ignores the alignment/packed attributes on this structure, forcing the
structure to have 8-byte alignment and 16-byte size:
---
struct Test {
double D __attribute__((packed,aligned(4)));
short X;
};
---
Ian Lance Taylor did a great analysis of the history of this, tracking it back
to a patch by David Edelsohn in 1996. The analysis is here:
http://gcc.gnu.org/ml/gcc-help/2005-07/msg00280.html
-Chris
--
Summary: Darwin alignment ignores attribute packed for first
'double' element of a struct
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: dje at watson dot ibm dot com
ReportedBy: sabre at nondot dot org
CC: gcc-bugs at gcc dot gnu dot org,ian at airs dot com
GCC host triplet: powerpc-darwin-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23071
[Bug tree-optimization/19049] not vectorizing a fortran loop
--- Additional Comments From irar at il dot ibm dot com 2005-07-26 07:07 --- The data dependence issue was solved by this patch http://gcc.gnu.org/ml/gcc- patches/2005-07/msg01195.html (committed). However, this loop is still not vectorizable because of noncontinuous access. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19049
[Bug tree-optimization/22486] Upcasts are not folded away
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-26 07:35 --- Subject: Bug 22486 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-26 07:34:58 Modified files: gcc: ChangeLog fold-const.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg/tree-ssa: upcast-1.c Log message: 2005-07-26 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/22486 * fold-const.c (fold_unary): Fold away useless component references of the form (T *)T.x, if the address doesn't change. * gcc.dg/tree-ssa/upcast-1.c: New testcase. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9546r2=2.9547 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gccr1=1.609r2=1.610 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5822r2=1.5823 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/upcast-1.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22486
[Bug tree-optimization/22486] Upcasts are not folded away
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-07-26 07:37 --- In principle this is fixed. Of course we either need a tree-combiner or forwprop on steroids to catch all cases. Which would make this bug a duplicate. Closed Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22486
[Bug tree-optimization/22504] [4.1 Regression] benchmark - galgel fails at runtime with miscompare output
--- Additional Comments From steven at gcc dot gnu dot org 2005-07-26 08:26 --- These are the only bugs I could find in expand_complex_addition: Index: tree-complex.c === RCS file: /cvs/gcc/gcc/gcc/tree-complex.c,v retrieving revision 2.39 diff -u -3 -p -r2.39 tree-complex.c --- tree-complex.c 25 Jul 2005 23:04:33 - 2.39 +++ tree-complex.c 26 Jul 2005 08:26:07 - @@ -844,7 +844,7 @@ expand_complex_addition (block_stmt_iter case PAIR (VARYING, ONLY_IMAG): rr = ar; - ri = gimplify_build2 (bsi, MINUS_EXPR, inner_type, ai, bi); + ri = gimplify_build2 (bsi, code, inner_type, ai, bi); break; case PAIR (ONLY_REAL, VARYING): @@ -858,7 +858,7 @@ expand_complex_addition (block_stmt_iter if (code == MINUS_EXPR) goto general; rr = br; - ri = gimplify_build2 (bsi, MINUS_EXPR, inner_type, ai, bi); + ri = gimplify_build2 (bsi, code, inner_type, ai, bi); break; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22504
[Bug treelang/23072] New: multiple runs of treelang testsuite does not work...
In http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg01369.html and test results of mine not yet posted, I see that if one tries to run the treelang test suite multiple times, e.g., with different compile options such as for multilibbed builds, the first run is done but not more... To me, this happens also on the 4.0 branch. -- Summary: multiple runs of treelang testsuite does not work... Product: gcc Version: 4.1.0 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=23072
07 Cok Gec olabilir
Okul Oncesi Couk ve Anne Baba Egitimi Okul Oncesi Cocuklar Icın Hazırlanmis Odullu CD'leri Gordunuzmu? http://www.cocukdunyasi.net
[Bug tree-optimization/22598] [4.1 Regression] 23_containers/set/explicit_instantiation/3.cc fails
--- Additional Comments From hp at gcc dot gnu dot org 2005-07-26 09:44 --- I'm betting it's the same bug that is visible with 1.cc (again, 1.cc indeed FAILs, does not PASS) on mmix-knuth-mmixware (cutnpaste from log): /home/hp/combined/mmix-regobj/mmix-knuth-mmixware/libstdc++-v3/include/bits/stl_set.h: In member fu\ nction 'std::pairtypename std::_Rb_tree_Key, _Key, std::_Identity_Key, _Compare, typename _Allo\ c::rebind_Key::other::const_iterator, bool std::set_Key, _Compare, _Alloc::insert(const _Key\ ) [with _Key = int, _Compare = std::lessint, _Alloc = std::allocatorint]':^M /home/hp/combined/mmix-regobj/mmix-knuth-mmixware/libstdc++-v3/include/bits/stl_set.h:318: internal\ compiler error: tree check: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:46\ 6^M PASSED with Mon Jul 18 16:34:10 UTC 2005 FAILS with Mon Jul 25 22:33:14 UTC 2005 -- What|Removed |Added CC||hp at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22598
[Bug c++/19932] [3.4 Regression] FAIL: g++.old-deja/g++.jason/rfg12.C (test for excess errors)
--- Additional Comments From giovannibajo at libero dot it 2005-07-26 09:46 --- What is the value of 'type' when error() is called? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19932
[Bug libstdc++/23053] Const-correctness issue in TR1 hashtable
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-26 09:46 --- Subject: Bug 23053 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-07-26 09:46:23 Modified files: libstdc++-v3 : ChangeLog libstdc++-v3/include/tr1: hashtable Added files: libstdc++-v3/testsuite/tr1/6_containers/unordered/hashtable: 23053.cc Log message: 2005-07-26 Dave Odell [EMAIL PROTECTED] PR libstdc++/23053 * include/tr1/hashtable (hashtable::find_node): Const-ify. * testsuite/tr1/6_containers/unordered/hashtable/23053.cc: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.2917.2.69r2=1.2917.2.70 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/tr1/6_containers/unordered/hashtable/23053.cc.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/tr1/hashtable.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.3r2=1.3.4.1 -- 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-26 09:48 --- Fixed for 4.0.2. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23053
[Bug tree-optimization/23073] New: [4.1 regression] testsuite failure, gcc.dg/tree-ssa/ifc-20040816-2.c
PASSes with Mon Jul 18 16:34:10 UTC 2005. FAILs with Mon Jul 25 22:33:14 UTC 2005. gcc.log says: Executing on host: /home/hp/combined/mmix-regobj/gcc/xgcc -B/home/hp/combined/mmix-regobj/gcc/ /hom\ e/hp/combined/combined/gcc/testsuite/gcc.dg/tree-ssa/ifc-20040816-2.c -c -O2 -ftree-vectorize -fd\ ump-tree-ifcvt-stats -fno-show-column -S -isystem /home/hp/combined/mmix-regobj/mmix-knuth-mmixwar\ e/./newlib/targ-include -isystem /home/hp/combined/combined/newlib/libc/include -o ifc-20040816-2.\ s(timeout = 300) /home/hp/combined/combined/gcc/testsuite/gcc.dg/tree-ssa/ifc-20040816-2.c: In function 'foo':^M /home/hp/combined/combined/gcc/testsuite/gcc.dg/tree-ssa/ifc-20040816-2.c:11: internal compiler err\ or: Segmentation fault^M .i forthcoming. -- Summary: [4.1 regression] testsuite failure, gcc.dg/tree-ssa/ifc- 20040816-2.c Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: mmix-knuth-mmixware http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23073
[Bug tree-optimization/23073] [4.1 regression] testsuite failure, gcc.dg/tree-ssa/ifc-20040816-2.c
--- Additional Comments From hp at gcc dot gnu dot org 2005-07-26 09:58 --- Created an attachment (id=9362) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9362action=view) preprocessed testcase /home/hp/combined/mmix-regobj/gcc/cc1 -fpreprocessed ifc-20040816-2.i -quiet -dumpbase ifc-2004081\ 6-2.c -auxbase-strip ifc-20040816-2.s -O2 -version -ftree-vectorize -fdump-tree-ifcvt-stats -fno-sh\ ow-column -o ifc-20040816-2.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23073
[Bug tree-optimization/22236] [4.1 Regression] wrong code for casts and scev
--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr
2005-07-26 10:06 ---
Subject: Re: [4.1 Regression] wrong code for casts and scev
After inlining, we end up with a loop containing the following code:
b.0_3 = (signed char) b_8;
D.1621_4 = (int) b.0_3;
a_5 = (signed char) D.1621_4;
D.1640_6 = (int) a_5;
b_7 = D.1640_6 - 127;
if (b_7 1) goto L3; else goto L9;
that is equivalent to:
b_7 = ((int) (signed char) (int) (signed char) b_8) - 127;
if (b_7 1) goto L3; else goto L9;
with b_8 = (unsigned char) {1, +, 1}
b_7 = ((int) (signed char) (int) (signed char) {(uchar)1, +, (uchar)1}) -
127;
if (b_7 1) goto L3; else goto L9;
A sequence of unsigned char 1, 2, ..., 255 has to be converted to
signed char that would wrap with -fwrapv: 1, 2, ..., 127, -128, ...
So here is a patch that keeps the cast if the sequence wraps. The
remaining problem is that with this patch, chrec_convert gets more
picky about the things that it transforms: in some of the testcases of
the vectorizer, we get some fails because the number of iterations is
not known, making scev_probably_wraps_p to return true, and finally
the conversion is kept.
I have bootstrapped this patch on x86_64, but there are some
regressions:
FAIL: gcc.dg/vect/vect-46.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-50.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-50.c scan-tree-dump-times Vectorizing an unaligned
access 2
FAIL: gcc.dg/vect/vect-50.c scan-tree-dump-times Alignment of access forced
using peeling 1
FAIL: gcc.dg/vect/vect-52.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-52.c scan-tree-dump-times Vectorizing an unaligned
access 2
FAIL: gcc.dg/vect/vect-58.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-58.c scan-tree-dump-times Alignment of access forced
using peeling 1
FAIL: gcc.dg/vect/vect-60.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-60.c scan-tree-dump-times Vectorizing an unaligned
access 2
FAIL: gcc.dg/vect/vect-92.c scan-tree-dump-times vectorized 1 loops 3
FAIL: gcc.dg/vect/vect-92.c scan-tree-dump-times Alignment of access forced
using peeling 3
In all these cases, the loop bound is a parameter. If IP-constant
propagation is not used, chrec_convert has not enough information for
removing the cast. I propose to modify all these testcases to make
the loop bound explicit.
FAIL: gcc.dg/vect/vect-77.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-77.c scan-tree-dump-times Vectorizing an unaligned
access 1
FAIL: gcc.dg/vect/vect-78.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-78.c scan-tree-dump-times Vectorizing an unaligned
access 1
For these two regressions, the problem is the same: we end with an
evolution: ib_16 + (aint *) ((long unsigned int) {off_11, +, 1}_1 * 4)
in which the casts cannot be removed because the offset is not known,
and even if the number of iterations is known, chrec_convert cannot
prove that it does not overflow. I propose to propagate the offset
by hand, or to wait for ipcp ;-)
FAIL: gcc.dg/vect/vect-87.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-87.c scan-tree-dump-times Alignment of access forced
using peeling 1
FAIL: gcc.dg/vect/vect-88.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-88.c scan-tree-dump-times Alignment of access forced
using peeling 1
For these two testcases we'll need IP-value range propagation. I
think that we'll have to modify these testcases by inlining the code.
Dorit, could you look at vect-{77,78,87,88}.c testcases? Thanks.
* tree-cfg.c (print_succ_bbs): Correctly print successors.
* tree-chrec.c (chrec_convert): Call scev_probably_wraps_p for checking
that the iv does not wrap before converting the iv.
* tree-ssa-loop-ivcanon.c: Correct typo in comment.
* tree-ssa-loop-ivopts.c (idx_find_step): Add a fixme note.
* tree-ssa-loop-niter.c (scev_probably_wraps_p): Check that AT_STMT is
not null.
(convert_step): Add a comment.
Index: tree-cfg.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-cfg.c,v
retrieving revision 2.211
diff -d -u -p -r2.211 tree-cfg.c
--- tree-cfg.c 12 Jul 2005 13:20:28 - 2.211
+++ tree-cfg.c 26 Jul 2005 09:59:38 -
@@ -4454,7 +4454,7 @@ static void print_pred_bbs (FILE *, basi
static void print_succ_bbs (FILE *, basic_block bb);
-/* Print the predecessors indexes of edge E on FILE. */
+/* Print on FILE the indexes for the predecessors of basic_block BB. */
static void
print_pred_bbs (FILE *file, basic_block bb)
@@ -4463,11 +4463,11 @@ print_pred_bbs (FILE *file, basic_block
edge_iterator ei;
FOR_EACH_EDGE (e, ei, bb-preds)
-fprintf (file, bb_%d, e-src-index);
+fprintf (file, bb_%d , e-src-index);
}
-/* Print the successors indexes of
[Bug debug/20161] [4.0/4.1 Regression] ICE with dwarf for incomplete element type argument
--- Additional Comments From steven at gcc dot gnu dot org 2005-07-26
10:18 ---
Let's try this patch then.
Index: passes.c
===
RCS file: /cvs/gcc/gcc/gcc/passes.c,v
retrieving revision 2.105
diff -u -3 -p -r2.105 passes.c
--- passes.c19 Jul 2005 18:45:56 - 2.105
+++ passes.c26 Jul 2005 10:12:55 -
@@ -175,7 +175,10 @@ rest_of_decl_compilation (tree decl,
timevar_pop (TV_VARCONST);
}
- else if (TREE_CODE (decl) == TYPE_DECL)
+ else if (TREE_CODE (decl) == TYPE_DECL
+ /* Like in rest_of_type_compilation, avoid confusing the debug
+ information machinery when there are errors. */
+ !(sorrycount || errorcount))
{
timevar_push (TV_SYMOUT);
debug_hooks-type_decl (decl, !top_level);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20161
[Bug tree-optimization/22236] [4.1 Regression] wrong code for casts and scev
--- Additional Comments From richard dot guenther at gmail dot com 2005-07-26 10:38 --- Subject: Re: [4.1 Regression] wrong code for casts and scev You should also add the (two) testcases from the PR. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22236
[Bug tree-optimization/22591] [4.0/4.1 Regression] std::swap() followed by list::erase() produces incorrect list::begin()
--- Additional Comments From steven at gcc dot gnu dot org 2005-07-26 10:39 --- I can reproduce this with the C test case from comment #24 on x86_64-linux with -march=nocona. With -march=k8 that test case does _not_ abort. -- What|Removed |Added GCC target triplet|i686-pc-linux-gnu | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591
[Bug tree-optimization/22591] [4.0/4.1 Regression] std::swap() followed by list::erase() produces incorrect list::begin()
--- Additional Comments From steven at gcc dot gnu dot org 2005-07-26 10:43 --- Well I'll be damned! $ ./xgcc -B. t.c -O2 -march=nocona $ ./a.out Aborted $ ./xgcc -B. t.c -O2 -march=nocona -da -fdump-tree-all $ ./a.out $ $ ./xgcc -B. t.c -O2 -march=nocona -S -da $ mv t.s t.s.with_dumps $ ./xgcc -B. t.c -O2 -march=nocona -S $ diff -u t.s t.s.with_dumps --- t.s 2005-07-26 12:42:14.447531418 +0200 +++ t.s.with_dumps 2005-07-26 12:42:03.501170603 +0200 @@ -26,19 +26,20 @@ .type ListSwap, @function ListSwap: .LFB4: - movq(%rdi), %rcx - testq %rcx, %rcx + cmpq$0, (%rdi) je .L8 + movq(%rdi), %rdx movq(%rsi), %rax movq%rax, (%rdi) - movq%rcx, (%rsi) + movq%rdx, (%rsi) movq8(%rdi), %rdx movq8(%rsi), %rax movq%rax, 8(%rdi) movq%rdx, 8(%rsi) + movq(%rdi), %rdx movq8(%rdi), %rax movq%rdi, (%rax) - movq%rdi, 8(%rcx) + movq%rdi, 8(%rdx) movq(%rsi), %rdx movq8(%rsi), %rax movq%rsi, (%rax) wtf?! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591
[Bug tree-optimization/22591] [4.0/4.1 Regression] std::swap() followed by list::erase() produces incorrect list::begin()
--- Additional Comments From steven at gcc dot gnu dot org 2005-07-26
11:18 ---
My version of t.c:
===
void abort ();
typedef struct _Node
{
struct _Node *next, *prev;
} Node;
void __attribute__ ((noinline)) append (Node * q, Node * p)
{
p-next = q;
p-prev = q;
q-next = p;
q-prev = p;
}
inline void
swap (Node ** a, Node ** b)
{
Node *tmp = *a;
*a = *b;
*b = tmp;
}
/* Miscompilation seems to happen here. If one removes the if condition
(which should be true) the program works fine. */
void
ListSwap (Node * x, Node * y)
{
Node *tmp;
if (x-next)
{
swap (x-next, y-next);
swap (x-prev, y-prev);
x-next-prev = x-prev-next = x;
y-next-prev = y-prev-next = y;
}
}
int
main ()
{
Node A, A1, B, B1;
append (A, A1);
append (B, B1);
ListSwap (A, B);
if (A != A.next-prev)
abort ();
}
===
compiled with:
$ ./xgcc -B. t.c -O2 -m32 -march=pentium4 -da -fdump-tree-vars
gives me this for ListSwap:
===
ListSwap (x, y)
{
struct Node * * a;
struct Node * * b;
struct Node * tmp;
struct Node * * a;
struct Node * * b;
struct Node * tmp;
struct _Node * D.1621;
struct _Node * D.1614;
bb 0:
D.1614 = x-next;
if (D.1614 != 0B) goto L0; else goto L1;
L0:;
a = x-next;
b = y-next;
tmp = *a;
*a = *b;
*b = tmp;
a = x-prev;
b = y-prev;
tmp = *a;
*a = *b;
*b = tmp;
x-prev-next = x;
D.1614-prev = x;
D.1621 = y-next;
y-prev-next = y;
D.1621-prev = y;
L1:;
return;
}
===
Look at D.1614. It is loaded befoe the conditional, and later there is
a store to D.1614-prev. But isn't x-next already something else by
then? After all, x-next and y-next are swapped. I checked with Serge
Belyshev and he agrees this looks fishy:
/QUOTE/
a = x-next;
b = y-next;
...
*a = *b;
this changes x-next
D.1614-prev = x;
but this still uses old value of x-next
/QUOTE/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591
[Bug tree-optimization/22591] [4.0/4.1 Regression] std::swap() followed by list::erase() produces incorrect list::begin()
--- Additional Comments From steven at gcc dot gnu dot org 2005-07-26
11:43 ---
Smaller test case:
==
void abort ();
typedef struct _Node
{
struct _Node *next, *prev;
} Node;
inline void
swap (Node ** a, Node ** b)
{
Node *tmp = *a;
*a = *b;
*b = tmp;
}
/* Miscompilation seems to happen here. If one removes the if condition
(which should be true) the program works fine. */
void
ListSwap (Node * x, Node * y)
{
Node *tmp;
if (x-next)
{
swap (x-next, y-next);
x-next-prev = x-prev-next = x;
}
}
==
Gives this .vars dump:
==
ListSwap (x, y)
{
struct Node * * a;
struct Node * * b;
struct Node * tmp;
struct _Node * D.1610;
bb 0:
D.1610 = x-next;
if (D.1610 != 0B) goto L0; else goto L1;
L0:;
a = x-next;
b = y-next;
tmp = *a;
*a = *b;
*b = tmp;
x-prev-next = x;
D.1610-prev = x;
L1:;
return;
}
==
In the .t22.ccp dump the function still looks OK:
D.1610_10 = x_1-next;
D.1613_11 = x_1-prev;
D.1613_11-next = x_1;
D.1614_12 = D.1613_11-next;
D.1610_10-prev = D.1614_12;
Then .t23.fre causes the problem because the wrong alias info is wrong:
D.1610_10 = D.1610_2;
D.1613_11 = x_1-prev;
D.1613_11-next = x_1;
D.1614_12 = D.1613_11-next;
D.1610_10-prev = D.1614_12;
Note btw how FRE does not replace D.1614_12 with x_1, which is a missed
optimization.
The alias info is already wrong when it is computed, so at least it is not
some kind of weird updating problem:
ListSwap (xD.1605, yD.1606)
{
struct NodeD.1598 * * aD.1660;
struct NodeD.1598 * * bD.1661;
struct NodeD.1598 * tmpD.1662;
struct NodeD.1598 * D.1663;
struct NodeD.1598 * tmpD.1609;
struct _Node * D.1614;
struct _Node * D.1613;
struct _Node * * D.1612;
struct _Node * * D.1611;
struct _Node * D.1610;
# BLOCK 0
# PRED: ENTRY (fallthru)
# VUSE TMT.31D.1669_13;
D.1610_2 = xD.1605_1-nextD.1596;
if (D.1610_2 != 0B) goto L0; else goto L1;
# SUCC: 1 (true) 2 (false)
# BLOCK 1
# PRED: 0 (true)
L0:;
D.1611_4 = yD.1606_3-nextD.1596;
D.1612_5 = xD.1605_1-nextD.1596;
aD.1660_6 = (struct NodeD.1598 * *) D.1612_5;
bD.1661_7 = (struct NodeD.1598 * *) D.1611_4;
# VUSE TMT.32D.1670_14;
tmpD.1662_8 = *aD.1660_6;
# VUSE TMT.32D.1670_14;
D.1663_9 = *bD.1661_7;
# TMT.32D.1670_15 = V_MAY_DEF TMT.32D.1670_14;
*aD.1660_6 = D.1663_9;
# TMT.32D.1670_16 = V_MAY_DEF TMT.32D.1670_15;
*bD.1661_7 = tmpD.1662_8;
# VUSE TMT.31D.1669_13;
D.1610_10 = xD.1605_1-nextD.1596;
# VUSE TMT.31D.1669_13;
D.1613_11 = xD.1605_1-prevD.1597;
# TMT.31D.1669_17 = V_MAY_DEF TMT.31D.1669_13;
D.1613_11-nextD.1596 = xD.1605_1;
# VUSE TMT.31D.1669_17;
D.1614_12 = D.1613_11-nextD.1596;
# TMT.31D.1669_18 = V_MAY_DEF TMT.31D.1669_17;
D.1610_10-prevD.1597 = D.1614_12;
# SUCC: 2 (fallthru)
# BLOCK 2
# PRED: 0 (false) 1 (fallthru)
L1:;
return;
# SUCC: EXIT
}
Notice that the stores to *a and *b are not killing TMT.31D.1669_13. That
is wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591
[Bug tree-optimization/22591] [4.0/4.1 Regression] wrong alias information causes an incorrect redundant load elimination
-- What|Removed |Added Priority|P2 |P1 Summary|[4.0/4.1 Regression]|[4.0/4.1 Regression] wrong |std::swap() followed by |alias information causes an |list::erase() produces |incorrect redundant load |incorrect list::begin() |elimination http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591
[Bug target/18170] [4.0/4.1 Regression] m32r-elf-as, m32r-linux-as debug relocation error for c++
--- Additional Comments From steven at gcc dot gnu dot org 2005-07-26 12:01 --- What should we do with this bug? If m32r is no longer affected, then what is? Maybe suspend this one or close it as WONTFIX? -- What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18170
[Bug middle-end/21953] [4.1 Regression] Many tmpdir-gcc.dg-struct-layout-1 tests fail on Tru64 UNIX V5.1B
--- Additional Comments From steven at gcc dot gnu dot org 2005-07-26 12:03 --- Rainer, can you look into those failures a bit more closely? Maybe you can see in the testsuite log how they fail? -- What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21953
[Bug fortran/23074] New: g77-style typeless BOZ constants not implemented
In g77 you define a typeless BOZ constant that can be assigned to any other type, using the formats ''X, ''Z etc. This allows PARAMETERs to be defined like: PROGRAM TLBOZ DOUBLE PRECISION inf, nan PARAMETER ( inf = '7FF0'Z ) PARAMETER ( nan = 'FFF8'X ) print *, inf, nan END The relevant g77 description is at: http://gcc.gnu.org/onlinedocs/gcc-3.4.1/g77/Constants.html This is related to bug 18026. -- Summary: g77-style typeless BOZ constants not implemented Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: enhancement 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=23074
[Bug c/23075] New: Redundant / bogus warning
Compiling
int foo (void)
{
return;
}
with -ansi -pedantic gives two warnings; with GCC 3.3 it only gave one. As a
QOI issue 3.3's behaviour is superior - warning about control reaching the end
of the function is a bit odd.
--
Summary: Redundant / bogus warning
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23075
[Bug c/23075] Redundant / bogus warning
--- Additional Comments From neil at gcc dot gnu dot org 2005-07-26 12:13 --- I meant to add -Wall to the warning list. -- What|Removed |Added Summary|Redundant / bogus warning |Redundant / bogus warning http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23075
[Bug target/23070] CALL_V4_CLEAR_FP_ARGS flag not properly set
-- What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23070
[Bug tree-optimization/23059] [4.1 Regression] ICE: verify_ssa failed with -O3 -ftree-vectorize -Woverloaded-virtual
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 12:54 --- Created an attachment (id=9363) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9363action=view) Smaller testcase -- What|Removed |Added Attachment #9359 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23059
[Bug tree-optimization/23059] [4.1 Regression] ICE: verify_ssa failed with -O3 -ftree-vectorize -Woverloaded-virtual
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 12:58 --- Confirmed, I cannot reduce the testcase any further. Removing any little unneeded code makes the bug go away. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-07-26 12:58:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23059
[Bug c/23076] New: GNU C extension / attribute destructor + static : invalid storage class for function
The follwing program:
#include stdio.h
#define LOG
FILE *log_file;
int f2 (int x)
{
#ifdef LOG
static long toto = 0;
static const char *fname = __func__;
static void __attribute__ ((destructor)) f (void) {
fprintf (log_file, %s: toto=%ld\n, fname, toto);
}
toto += x;
#endif
return 42;
}
int main ()
{
log_file = fopen (toto.log, w);
f2 (3);
return 0;
}
failed to compile with GCC 4.0.0 and GCC 4.0.1:
morpork tmp 69 % /localdisk/gcc-4.0.1/bin/gcc tgcc.c
tgcc.c: In function 'f2':
tgcc.c:12: error: invalid storage class for function 'f'
morpork tmp 68 % /localdisk/gcc-4.0.1/bin/gcc --version
gcc (GCC) 4.0.1
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
whereas it works perfectly with GCC 3.2.x, 3.3.x and GCC 3.4.x.
--
Summary: GNU C extension / attribute destructor + static :
invalid storage class for function
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ppelissi at caramail dot com
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=23076
[Bug fortran/23074] g77-style typeless BOZ constants not implemented
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 13:03 --- This isn't just related, this is a dup of PR 18026. *** This bug has been marked as a duplicate of 18026 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23074
[Bug fortran/18026] boz initialization of REALs fails
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 13:03 --- *** Bug 23074 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||p dot w dot draper at durham ||dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18026
==operator gives unexpected result using -O0
Hello,
I do apologize if my ignorance is the problem here, but I am having a strange
problem with the version of gcc included in suse 9.3: gcc version 3.3.5
20050117 (prerelease) (SUSE Linux). The same problem was observed with gcc
3.3.1. I have not tried later versions, but I can't find the problem in
bugzilla so I assume it is either so trivial that I should be ashamed or
unknown. It is an intel XEON processor.
It seems to me that if a,b, and c are float or double values and if a has been
assigned b*c
then
a == (b*c)
should return true since a should contain the same bitpattern as the temporary
being assigned the value of b*c. Is it not so?
Never the less, the following piece of code does not work as expected when
compiling with -O0. It works FINE when compiling with -O1 or higher.
---
#include iostream
using namespace std;
int main()
{
double b = 9.5245435435564536;
double c = 7.98786542345446565;
double a = b*c;
//Does not work.
cout (a == (b*c)) endl;
// Works
double d = b*c;
cout (a == d) endl;
}
---
With O0 the output is
0
1
With O1, O2 or O3 the output is
1
1
as one would expect.
I have made a similar program in C and I also changed double to float. It
makes no difference. Nor does the actual float/double values. The
optimization flag seems to decide what happens.
Any insight would be appreciated.
Andreas
[Bug c/23076] GNU C extension / attribute destructor + static : invalid storage class for function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 13:05 --- Just remove the static and it will work. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Summary|GNU C extension / attribute |GNU C extension / attribute |destructor + static : |destructor + static : |invalid storage class for |invalid storage class for |function|function http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23076
[Bug c/23076] GNU C extension / attribute destructor + static : invalid storage class for function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 13:06 --- I should note static functions inside a function is invalid code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23076
[Bug tree-optimization/22591] [4.0/4.1 Regression] wrong alias information causes an incorrect redundant load elimination
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-07-26
13:10 ---
I have (with whatever load of patches applied...)
;; Function ListSwap (ListSwap)
ListSwap (x, y)
{
struct Node * tmp;
struct _Node * D.1292;
bb 0:
tmp = x-next;
if (tmp != 0B) goto L0; else goto L1;
L0:;
x-next = y-next;
y-next = tmp;
D.1292 = x-next;
x-prev-next = x;
D.1292-prev = x;
L1:;
return;
}
--
What|Removed |Added
Priority|P1 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591
[Bug c/23075] [4.0/4.1 Regression] Redundant / bogus warning
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 13:11 --- Confirmed, one warning comes from the front-end and the other bogus warning comes from the middle-end. I have not looked to see if we set TREE_NO_WARNING on the return and if the middle-end looks at that flag but I think that might be a way around the issue. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2005-07-26 13:11:36 date|| Summary|Redundant / bogus warning |[4.0/4.1 Regression] ||Redundant / bogus warning Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23075
[Bug tree-optimization/23073] [4.1 regression] testsuite failure, gcc.dg/tree-ssa/ifc-20040816-2.c
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||ice-on-valid-code Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23073
[Bug tree-optimization/22598] [4.1 Regression] 23_containers/set/explicit_instantiation/3.cc fails
-- What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22598
[Bug tree-optimization/21445] [meta-bug] we need a reassociate pass
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-07-26 13:14 --- We have one now :) -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21445
[Bug tree-optimization/19104] in range test not noticed
-- Bug 19104 depends on bug 21445, which changed state. Bug 21445 Summary: [meta-bug] we need a reassociate pass http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21445 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19104
[Bug tree-optimization/15878] a b ~a ~b not optimized at the tree level
-- Bug 15878 depends on bug 21445, which changed state. Bug 21445 Summary: [meta-bug] we need a reassociate pass http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21445 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15878
[Bug tree-optimization/19105] fold does not spot anti-range test
-- Bug 19105 depends on bug 21445, which changed state. Bug 21445 Summary: [meta-bug] we need a reassociate pass http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21445 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19105
[Bug tree-optimization/16157] gcc fails to optimize redundant expression (reassocation)
-- Bug 16157 depends on bug 21445, which changed state. Bug 21445 Summary: [meta-bug] we need a reassociate pass http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21445 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16157
[Bug tree-optimization/17955] Perform associative optimization when it is safe
-- Bug 17955 depends on bug 21445, which changed state. Bug 21445 Summary: [meta-bug] we need a reassociate pass http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21445 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17955
[Bug target/23067] Incorrect struct layout on darwin
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 13:14 --- Confirmed based on what Apple's GCC does and what Geoff said. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-07-26 13:14:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23067
[Bug debug/20253] [3.4 regression]: Macro debug info broken due to lexer change
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-07-26 13:16 --- This has moved very much off my radar since it was fixed in 4.1.0 and 4.0.0 -- What|Removed |Added AssignedTo|dberlin at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Known to fail|3.4.0 4.0.0 |3.4.0 Known to work|3.3.3 3.2.3 4.1.0 |3.3.3 3.2.3 4.1.0 4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20253
[Bug tree-optimization/22591] [4.0/4.1 Regression] wrong alias information causes an incorrect redundant load elimination
--- Additional Comments From pcarlini at suse dot de 2005-07-26 13:17 --- Yes, but why P1 - P2?!? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591
[Bug tree-optimization/19581] Missed store motion on the tree level
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-07-26 13:18 --- Richard guenther is working on aliasing for arrays, i'll leave this one for him -- What|Removed |Added CC||rguenth at gcc dot gnu dot ||org AssignedTo|dberlin at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19581
[Bug tree-optimization/22488] [4.1 Regression] ICE: in first_vi_for_offset, at tree-ssa-structalias.c:2585 with -O3
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-07-26 13:21 --- http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01608.html does not help -- What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22488
[Bug target/23071] Darwin alignment ignores attribute packed for first 'double' element of a struct
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 13:21 --- I still don't believe this is a bug. As the alignment of whole struct is still 8 as double is first, even if the alignment of that double is 4. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org GCC host triplet|powerpc-darwin-*| GCC target triplet||powerpc-darwin, powerpc-aix http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23071
[Bug fortran/23074] g77-style typeless BOZ constants not implemented
--- Additional Comments From p dot w dot draper at durham dot ac dot uk 2005-07-26 13:28 --- Andrew, I've said this is related to bug 18026, rather than a duplicate, as the actual format used for these typeless BOZ constants is none standard and not the same as in bug 18026. As in gfortran, g77 typed constants have the format X'', whereas these are ''X, the difference may not be apparent at first glance. If you missed this point please reopen or merge this report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23074
[Bug tree-optimization/19581] Missed store motion on the tree level
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-07-26
13:29 ---
For a reduced array with only 4 elements (I know - this should be a --param) we
now get in .vars (with the array aliasing patch):
f (n)
{
int n.39;
unsigned int ivtmp.33;
int lsm_tmp.32;
int lsm_tmp.31;
int lsm_tmp.30;
int lsm_tmp.29;
bb 0:
n.39 = n - 1;
if (n.39 != 0) goto L6; else goto L2;
L6:;
lsm_tmp.29 = r[2];
lsm_tmp.30 = r[1];
lsm_tmp.31 = r[3];
lsm_tmp.32 = r[0];
ivtmp.33 = 0;
L0:;
lsm_tmp.32 = lsm_tmp.32 + lsm_tmp.31;
lsm_tmp.30 = lsm_tmp.32 + lsm_tmp.30;
lsm_tmp.29 = lsm_tmp.30 + lsm_tmp.29;
lsm_tmp.31 = lsm_tmp.31 + lsm_tmp.29;
ivtmp.33 = ivtmp.33 + 1;
if (ivtmp.33 != (unsigned int) n.39) goto L0; else goto L10;
L10:;
r[2] = lsm_tmp.29;
r[1] = lsm_tmp.30;
r[3] = lsm_tmp.31;
r[0] = lsm_tmp.32;
L2:;
return;
}
and the asm loop looks like
.L4:
addl%edx, %eax
incl%esi
addl%eax, %ecx
addl%ecx, %ebx
addl%ebx, %edx
cmpl%edi, %esi
jne .L4
as in exactly what you want. Don't hold your breath for 4.1, though.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2005-06-09 16:37:28 |2005-07-26 13:29:06
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19581
[Bug tree-optimization/22236] [4.1 Regression] wrong code for casts and scev
--- Additional Comments From dorit at il dot ibm dot com 2005-07-26 13:59
---
Subject: Re: [4.1 Regression] wrong code for casts and
scev
Hi Sebastian,
The modifications you suggest will make the tests uninteresting - they were
introduced with unknown loop-bound/offset on purpose. In fact, for most of
these tests there are already versions with explicit constant values for
the loop-bound/offset -
vect-46.c with explicit loop-bound becomes vect-40.c
vect-50.c with explicit loop-bound becomes vect-44.c
vect-52.c with explicit loop-bound becomes vect-48.c
vect-58.c with explicit loop-bound becomes vect-54.c
vect-60.c with explicit loop-bound becomes vect-56.c
vect-77.c and vect-78.c with explicit offset become vect-75.c
and vect-92.c also uses unknown loop-bound on purpose.
Can we change something else in the tests to make the evolution-analyzer
return something saner? by changing types of variables? by using some flag?
(by the way, where does it fail the vectorizer? (what are the last things
that dump details reports?))
dorit
FAIL: gcc.dg/vect/vect-46.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-50.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-50.c scan-tree-dump-times Vectorizing an
unaligned access 2
FAIL: gcc.dg/vect/vect-50.c scan-tree-dump-times Alignment of access
forced using peeling 1
FAIL: gcc.dg/vect/vect-52.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-52.c scan-tree-dump-times Vectorizing an
unaligned access 2
FAIL: gcc.dg/vect/vect-58.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-58.c scan-tree-dump-times Alignment of access
forced using peeling 1
FAIL: gcc.dg/vect/vect-60.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-60.c scan-tree-dump-times Vectorizing an
unaligned access 2
FAIL: gcc.dg/vect/vect-92.c scan-tree-dump-times vectorized 1 loops 3
FAIL: gcc.dg/vect/vect-92.c scan-tree-dump-times Alignment of access
forced using peeling 3
In all these cases, the loop bound is a parameter. If IP-constant
propagation is not used, chrec_convert has not enough information for
removing the cast. I propose to modify all these testcases to make
the loop bound explicit.
FAIL: gcc.dg/vect/vect-77.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-77.c scan-tree-dump-times Vectorizing an
unaligned access 1
FAIL: gcc.dg/vect/vect-78.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-78.c scan-tree-dump-times Vectorizing an
unaligned access 1
For these two regressions, the problem is the same: we end with an
evolution: ib_16 + (aint *) ((long unsigned int) {off_11, +, 1}_1 * 4)
in which the casts cannot be removed because the offset is not known,
and even if the number of iterations is known, chrec_convert cannot
prove that it does not overflow. I propose to propagate the offset
by hand, or to wait for ipcp ;-)
FAIL: gcc.dg/vect/vect-87.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-87.c scan-tree-dump-times Alignment of access
forced using peeling 1
FAIL: gcc.dg/vect/vect-88.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-88.c scan-tree-dump-times Alignment of access
forced using peeling 1
For these two testcases we'll need IP-value range propagation. I
think that we'll have to modify these testcases by inlining the code.
Dorit, could you look at vect-{77,78,87,88}.c testcases? Thanks.
* tree-cfg.c (print_succ_bbs): Correctly print successors.
* tree-chrec.c (chrec_convert): Call scev_probably_wraps_p for
checking
that the iv does not wrap before converting the iv.
* tree-ssa-loop-ivcanon.c: Correct typo in comment.
* tree-ssa-loop-ivopts.c (idx_find_step): Add a fixme note.
* tree-ssa-loop-niter.c (scev_probably_wraps_p): Check that AT_STMT is
not null.
(convert_step): Add a comment.
Index: tree-cfg.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-cfg.c,v
retrieving revision 2.211
diff -d -u -p -r2.211 tree-cfg.c
--- tree-cfg.c 12 Jul 2005 13:20:28 - 2.211
+++ tree-cfg.c 26 Jul 2005 09:59:38 -
@@ -4454,7 +4454,7 @@ static void print_pred_bbs (FILE *, basi
static void print_succ_bbs (FILE *, basic_block bb);
-/* Print the predecessors indexes of edge E on FILE. */
+/* Print on FILE the indexes for the predecessors of basic_block BB. */
static void
print_pred_bbs (FILE *file, basic_block bb)
@@ -4463,11 +4463,11 @@ print_pred_bbs (FILE *file, basic_block
edge_iterator ei;
FOR_EACH_EDGE (e, ei, bb-preds)
-fprintf (file, bb_%d, e-src-index);
+fprintf (file, bb_%d , e-src-index);
}
-/* Print the successors indexes of edge E on FILE. */
+/* Print on FILE the indexes for the successors of basic_block BB. */
static void
print_succ_bbs (FILE *file, basic_block bb)
@@ -4476,7 +4476,7 @@ print_succ_bbs (FILE *file,
[Bug target/23071] Darwin alignment ignores attribute packed for first 'double' element of a struct
--- Additional Comments From dje at gcc dot gnu dot org 2005-07-26 14:08 --- The ABI specifies the alignment of the entire record is doubleword if the first field is an FP double, regardless of the alignment of the type itself. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23071
[Bug tree-optimization/22591] [4.0/4.1 Regression] wrong alias information causes an incorrect redundant load elimination
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-07-22 08:23:53 |2005-07-26 14:26:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591
[Bug libobjc/22606] Exceptions cannot be thrown from -forward::
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-26 14:27 --- Subject: Bug 22606 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-26 14:27:33 Modified files: gcc/testsuite : ChangeLog libobjc: ChangeLog Makefile.in Added files: gcc/testsuite/objc.dg: try-catch-11.m Log message: 2005-07-26 Andrew Pinski [EMAIL PROTECTED] PR libobjc/22606 * Makefile.in (ALL_CFLAGS): Add -fexceptions. 2005-07-26 Andrew Pinski [EMAIL PROTECTED] PR libobjc/22606 * objc.dg/try-catch-11.m: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5823r2=1.5824 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/objc.dg/try-catch-11.m.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libobjc/ChangeLog.diff?cvsroot=gccr1=1.168r2=1.169 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libobjc/Makefile.in.diff?cvsroot=gccr1=1.48r2=1.49 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22606
[Bug libobjc/22606] Exceptions cannot be thrown from -forward::
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 14:28 --- Fixed, added your testcase also. Also I noticed that your testcase fails with the next runtime, oh well. Not my bug. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22606
[Bug middle-end/21992] [4.1 regression] testsuite failure: many objc execution tests fail, first objc/execute/_cmd.m execution
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 14:32 --- I think I see the same thing at -O2 on a couple of tests on ppc-darwin. Is the execution a missing symbol? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21992
[Bug c/23077] New: Invalid code with O2 flag (bad alias analysis?)
Source code:
#include stdio.h
int main (int argc, char * argv[])
{
unsigned int t[2] = {1, 1};
*((double *)t) = 0.0;
printf(%d\n, t[1]);
}
This code prints 1 insted of 0 when with: gcc foo.c -o foo -O2
Output of gcc -v foo.c -o foo2 -O2:
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/specs
Configured with: /var/tmp/portage/gcc-3.4.4/work/gcc-3.4.4/configure
--enable-version-specific-runtime-libs --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.4.4
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.4
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.4/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.4/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include/g++-v3
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --disable-libunwind-exceptions --disable-multilib
--disable-libgcj --enable-languages=c,c++,f77 --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 3.4.4 (Gentoo 3.4.4, ssp-3.4.4-1.0, pie-8.7.8)
/usr/libexec/gcc/i686-pc-linux-gnu/3.4.4/cc1 -quiet -v foo.c -quiet -dumpbase
foo.c -mtune=pentiumpro -auxbase foo -O2 -version -o /tmp/ccFePbg2.s
ignoring nonexistent directory /usr/local/include
ignoring nonexistent directory
/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include
/usr/include
End of search list.
GNU C version 3.4.4 (Gentoo 3.4.4, ssp-3.4.4-1.0, pie-8.7.8) (i686-pc-linux-gnu)
compiled by GNU C version 3.4.4 (Gentoo 3.4.4, ssp-3.4.4-1.0,
pie-8.7.8).
GGC heuristics: --param ggc-min-expand=90 --param ggc-min-heapsize=113127
/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../i686-pc-linux-gnu/bin/as -V
-Qy -o /tmp/ccokr9zW.o /tmp/ccFePbg2.s
GNU assembler version 2.16.1 (i686-pc-linux-gnu) using BFD version 2.16.1
/usr/libexec/gcc/i686-pc-linux-gnu/3.4.4/collect2 --eh-frame-hdr -m elf_i386
-dynamic-linker /lib/ld-linux.so.2 -o foo2
/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../crt1.o
/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../crti.o
/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/crtbegin.o
-L/usr/lib/gcc/i686-pc-linux-gnu/3.4.4 -L/usr/lib/gcc/i686-pc-linux-gnu/3.4.4
-L/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../i686-pc-linux-gnu/lib
-L/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/../../.. /tmp/ccokr9zW.o -lgcc -lgcc_eh
-lc -lgcc -lgcc_eh /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/crtend.o
/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../crtn.o
I suspect that the alias analysis use an incorrect size for double.
--
Summary: Invalid code with O2 flag (bad alias analysis?)
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nicos at maunakeatech dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23077
[Bug c/23077] Invalid code with O2 flag (bad alias analysis?)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 14:36 --- No this is not bad alias analysis, You are invoking undefined code by violating aliasing rules in C/C++. This is a dup of bug 21920. *** This bug has been marked as a duplicate of 21920 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23077
[Bug c/21920] alias violating
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 14:37 --- *** Bug 23077 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||nicos at maunakeatech dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug tree-optimization/22591] [4.0/4.1 Regression] wrong alias information causes an incorrect redundant load elimination
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-07-26 14:46 --- (In reply to comment #31) Smaller test case: This works for me. The original test case does abort, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22591
[Bug tree-optimization/22236] [4.1 Regression] wrong code for casts and scev
--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr
2005-07-26 15:15 ---
Subject: Re: [4.1 Regression] wrong code for casts and scev
Dorit Naishlos wrote:
The modifications you suggest will make the tests uninteresting - they were
introduced with unknown loop-bound/offset on purpose. In fact, for most of
these tests there are already versions with explicit constant values for
the loop-bound/offset -
Okay, I won't modify any of these testcases.
vect-46.c with explicit loop-bound becomes vect-40.c
vect-50.c with explicit loop-bound becomes vect-44.c
vect-52.c with explicit loop-bound becomes vect-48.c
vect-58.c with explicit loop-bound becomes vect-54.c
vect-60.c with explicit loop-bound becomes vect-56.c
vect-77.c and vect-78.c with explicit offset become vect-75.c
and vect-92.c also uses unknown loop-bound on purpose.
Can we change something else in the tests to make the evolution-analyzer
return something saner? by changing types of variables? by using some flag?
I don't think it is possible to properly convert these ivs without
knowing an approximation of the number of iterations.
We can get this either from -fipcp, but this would make the testcases
redundant as you said, or having the IP alias analysis that tells us
that the only pointers passed to main1 () in vect-46 point to data
whose size is 256, and from this extract an estimation of the number
of iterations, or last solution explained below.
(by the way, where does it fail the vectorizer? (what are the last things
that dump details reports?))
compiling vect-46.c produces the following:
(...
(set_scalar_evolution
(scalar = D.2054_15)
(scalar_evolution = (afloat * restrict) {0, +, 4}_1 + pb_14))
)
/home/seb/mainline/gcc/gcc/testsuite/gcc.dg/vect/vect-46.c:30: note: Access
function of ptr: (afloat * restrict) {0, +, 4}_1 + pb_14
/home/seb/mainline/gcc/gcc/testsuite/gcc.dg/vect/vect-46.c:30: note: not
vectorized: ptr is loop invariant.
/home/seb/mainline/gcc/gcc/testsuite/gcc.dg/vect/vect-46.c:30: note: not
vectorized: unhandled data ref: D.2055_16 = *D.2054_15
/home/seb/mainline/gcc/gcc/testsuite/gcc.dg/vect/vect-46.c:30: note: bad data
references.
/home/seb/mainline/gcc/gcc/testsuite/gcc.dg/vect/vect-46.c:30: note: vectorized
0 loops in function.
Now that we keep the cast, (afloat * restrict) {(uint) 0, +, (uint)
4}_1 + pb_14 cannot be folded into {(afloat * restrict)pb_14, +,
(afloat * restrict)4}_1, that's why the vectorizer cannot recognize
the pattern.
The main problem is that the code in the loop contains a cast of the
signed iv i_18 to unsigned:
bb_2 (preds = {bb_3 bb_1 }, succs = {bb_3 bb_5 })
{
# TMT.5_17 = PHI TMT.5_27(3), TMT.5_26(1);
# i_18 = PHI i_24(3), 0(1);
L0:;
D.2050_6 = (long unsigned int) i_18;
D.2051_7 = D.2050_6 * 4;
D.2052_8 = (afloat * restrict) D.2051_7;
D.2053_10 = D.2052_8 + pa_9;
D.2054_15 = D.2052_8 + pb_14;
# VUSE TMT.5_17;
D.2055_16 = *D.2054_15;
D.2056_21 = D.2052_8 + pc_20;
# VUSE TMT.5_17;
D.2057_22 = *D.2056_21;
D.2058_23 = D.2055_16 * D.2057_22;
# TMT.5_27 = V_MAY_DEF TMT.5_17;
*D.2053_10 = D.2058_23;
i_24 = i_18 + 1;
if (n_3 i_24) goto L9; else goto L11;
}
The solution is to have an estimation of the loop bound based on the
fact that i_24 and i_18 do not wrap. From this estimation, I think
that the other vars D.2050_6, D.2051_7 and D.2052_8 can be proved to
not wrap. I'm working on some code for estimating niter from signed
non wrapping ivs.
Sebastian
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22236
[Bug tree-optimization/23073] [4.1 regression] testsuite failure, gcc.dg/tree-ssa/ifc-20040816-2.c
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-07-26
15:21 ---
Confirmed.
The following testcase crashes on i686-pc-linux-gnu when compiled with
-O -ftree-vectorize -msse2:
==
void foo(int* __restrict__ p, int* __restrict__ q)
{
int i;
for (i=0; i2; ++i)
p[i] = q[i] = 0;
}
==
--
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||monitored
Last reconfirmed|-00-00 00:00:00 |2005-07-26 15:21:56
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23073
[Bug tree-optimization/23073] [4.1 regression] testsuite failure, gcc.dg/tree-ssa/ifc-20040816-2.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-26 15:26 --- Here is the backtrace: #0 0x00424b88 in fwrite () from /lib/tls/libc.so.6 #1 0x081381fd in vect_analyze_data_refs_alignment (loop_vinfo=0xa3bebb0) at /home/peshtigo/ pinskia/src/gnu/gcc/src/gcc/tree-vect-analyze.c:1063 #2 0x0813b078 in vect_analyze_loop (loop=0xa385bb0) at /home/peshtigo/pinskia/src/gnu/gcc/src/ gcc/tree-vect-analyze.c:1863 #3 0x08134088 in vectorize_loops (loops=0xa39d850) at /home/peshtigo/pinskia/src/gnu/gcc/src/ gcc/tree-vectorizer.c:2024 #4 0x0812be24 in tree_vectorize () at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/tree-ssa-loop.c: 194 Someone is writting to vect_dump without checking to see if it is opened. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23073
