for getting profiling times in millsecond resolution.
Hi, I want to get the profiling data of an application in linux. Now I am using -pg options of gcc for generating the profile data. then used gprof for generating profiles. Here I am getting only in terms of seconds. But I want in millisecond resolution. can anybody help me. Thanks regards Jayaraj
Re: New brach 'yara-branch' is created
Hi Vladimir, On Sat, 18 Mar 2006, Vladimir N. Makarov wrote: What I am going to do in short perspective is o work on code quality of some SPECINT tests (e.g. reload is doing better job for crafty with many multi-registers than YARA) I haven't looked at the new branch yet, so forgive me if this is obvious or handled already. In my attempt I found that the only way to handle multi-word registers well was to really track (and allocate) partially live registers, i.e. separate words in a whole multi-word web. That was what the whole subweb mess was coming from, which was slowing down the whole allocator quite a bit. Ciao, Michael.
Leaf functions and noreturn calls
Good morning everyone!
Here's a simple testcase that illustrates what I'm observing in gcc-3.3.3
-snip-
extern void abort (void) __attribute ((noreturn));
int foo (int a, int b)
{
if (a 25)
abort ();
return (a + b);
}
int bar (int a, int b)
{
if (a 25)
a++;
return (a + b);
}
-snip-
Function bar() is clearly a leaf function, so at stackframe layout time I
get called with current_function_is_leaf == 1, and since it uses no
nonvolatile registers I get a function with no stackframe, no registers saved,
no prologue and nothing but a ret insn in the epilog.
Function foo() is not regarded as a leaf function, because it calls abort,
and so my prologue generation code believes it has to create a stack frame
just to save the link register.
However, abort is clearly marked noreturn:-
-snip-
;(call_insn 13 31 14 0x0 (parallel [
;(call (mem:SI (symbol_ref:SI (abort)) [0 S4 A32])
;(const_int 0 [0x0]))
;(clobber (reg:SI 15 r15))
;]) 36 {call} (nil)
;(expr_list:REG_UNUSED (reg:SI 15 r15)
;(expr_list:REG_NORETURN (const_int 0 [0x0])
;(expr_list:REG_EH_REGION (const_int 0 [0x0])
;(nil
;(nil))
-snip-
and without this call it would clearly be a leaf function, and since this call
is noreturn we could in fact still treat it as a leaf function.
Is there some complication that I haven't realised why noreturn function
calls can't be disregarded in deciding whether or not a function is leaf?
Taking a look at leaf_function_p, I see that it specifically discounts
sibcalls; why not noreturncalls as well?
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: gcc-4.2-20060304 is now available
On Sun, 19 Mar 2006, Laurent GUERBY wrote: Are statistics for GCC download available somewhere? I suspect in these days of broadband that just about everyone gets the full tarball (especially for releases...). The FreeSD ports, for example, by default do not build gfortran nor Java at this point and have never built Ada. And I doubt that many are building Ada, regardless of the platform they are using. gfortran weights in less than one megabyte, thus isn't of too much concern. Java with close to 10MB and Adad with some 4.5MB are kind of heavy, though. Keep in mind that depending on the part of the world many may still be using modem lines. Gerald
Re: FUNCTION_OK_FOR_SIBCALL vs INITIAL_FRAME_POINTER_OFFSET
On Sat, Mar 11, 2006 at 12:41:32AM -, Dave Korn wrote: So, what if the decision it needs to make depends on the stack frame size of the current function? How can this possibly be? When the sibcall is done, the current function's stack frame is removed. r~
RE: FUNCTION_OK_FOR_SIBCALL vs INITIAL_FRAME_POINTER_OFFSET
On 20 March 2006 14:45, Richard Henderson wrote: Hi Richard :) On Sat, Mar 11, 2006 at 12:41:32AM -, Dave Korn wrote: So, what if the decision it needs to make depends on the stack frame size of the current function? How can this possibly be? When the sibcall is done, the current function's stack frame is removed. r~ If the stack frame size is 32kB, I need to use a temporary register in the epilogue to assemble the lo/hi parts of the frame size before adding it to the SP. In the non-sibcall version of the epilogue[*] it uses one of the arg-passing volatiles as a scratch register, but of course in a sibcall epilogue that register might have been pre-loaded with an argument for the sibcall which we don't want to trash. So rather than get hairy with trying to allocate scratch regs, I was just going to refuse sibcalls for functions with huge stack frames. Hence my curiosity. cheers, DaveK [*] - Which has until now been the only version for our custom target; it's still using fprintfs in TARGET_ASM_FUNCTION_EPILOGUE, and I'm going one step at a time to bring it up to scratch. -- Can't think of a witty .sigline today
Re: FUNCTION_OK_FOR_SIBCALL vs INITIAL_FRAME_POINTER_OFFSET
On Mon, Mar 20, 2006 at 02:56:00PM -, Dave Korn wrote: If the stack frame size is 32kB, I need to use a temporary register in the epilogue to assemble the lo/hi parts of the frame size before adding it to the SP. In the non-sibcall version of the epilogue[*] it uses one of the arg-passing volatiles as a scratch register, but of course in a sibcall epilogue that register might have been pre-loaded with an argument for the sibcall which we don't want to trash. So rather than get hairy with trying to allocate scratch regs, I was just going to refuse sibcalls for functions with huge stack frames. Hence my curiosity. Ah, interesting. In this case I'd deny sibcalls to functions that use all of the available scratch registers for arguments. We do something similar for i386 indirect sibcalls -- deny unless there's a free register for the jump. r~
Re: Leaf functions and noreturn calls
On Mon, Mar 20, 2006 at 12:57:14PM -, Dave Korn wrote: Taking a look at leaf_function_p, I see that it specifically discounts sibcalls; why not noreturncalls as well? Because generally losing unwind information from noreturn calls is a lose when it comes to debugging. r~
Re: New brach 'yara-branch' is created
Michael Matz wrote: Hi Vladimir, On Sat, 18 Mar 2006, Vladimir N. Makarov wrote: What I am going to do in short perspective is o work on code quality of some SPECINT tests (e.g. reload is doing better job for crafty with many multi-registers than YARA) I haven't looked at the new branch yet, so forgive me if this is obvious or handled already. In my attempt I found that the only way to handle multi-word registers well was to really track (and allocate) partially live registers, i.e. separate words in a whole multi-word web. That was what the whole subweb mess was coming from, which was slowing down the whole allocator quite a bit. It is not done this way yet. I thought about that too and hope it can help crafty.
Re: New brach 'yara-branch' is created
Paolo Bonzini wrote: Michael Matz wrote: Hi Vladimir, On Sat, 18 Mar 2006, Vladimir N. Makarov wrote: What I am going to do in short perspective is o work on code quality of some SPECINT tests (e.g. reload is doing better job for crafty with many multi-registers than YARA) The lower-subreg patch that Richard Henderson posted, and that comes up again and again from time to time, may also help. It does require a bit of hacking in the MDs (mostly removing the DImode patterns for logical operations since the middle-end is able to synthesize them on its own). Thanks for the information. I'll look at this.
RE: FUNCTION_OK_FOR_SIBCALL vs INITIAL_FRAME_POINTER_OFFSET
On 20 March 2006 15:14, Richard Henderson wrote: On Mon, Mar 20, 2006 at 02:56:00PM -, Dave Korn wrote: If the stack frame size is 32kB, I need to use a temporary register in the epilogue to assemble the lo/hi parts of the frame size before adding it to the SP. In the non-sibcall version of the epilogue[*] it uses one of the arg-passing volatiles as a scratch register, but of course in a sibcall epilogue that register might have been pre-loaded with an argument for the sibcall which we don't want to trash. So rather than get hairy with trying to allocate scratch regs, I was just going to refuse sibcalls for functions with huge stack frames. Hence my curiosity. Ah, interesting. In this case I'd deny sibcalls to functions that use all of the available scratch registers for arguments. Heh, of course, lateral thinking, attack the conflict from the opposite direction! We do something similar for i386 indirect sibcalls -- deny unless there's a free register for the jump. Mmmf. In that case, of course, you absolutely /have/ to have a register available and no two ways about it. But in the direct-sibcall case, this test will generate false positives since if the stackframe is small enough I don't need a register at all and the sibcall should be ok. And I expect it to be the case that 99% of all functions /will/ have small stack frames, and so this will deny every sibcall to a function using the full set of arg passing regs when they'll almost all be ok. So I guess if I want to make the most of the opportunities for sibcalls, I still need hope that get_frame_size() is valid at F_O_F_S time and make a best-guess at the size of the frame, and if it goes from 32k to 32k by the time I actually come to emit the sibcall epilogue I'll just have to abort. Do you happen to know off the top of your head when get_frame_size() becomes valid? cheers, DaveK -- Can't think of a witty .sigline today
RE: Leaf functions and noreturn calls
On 20 March 2006 15:31, Richard Henderson wrote: On Mon, Mar 20, 2006 at 12:57:14PM -, Dave Korn wrote: Taking a look at leaf_function_p, I see that it specifically discounts sibcalls; why not noreturncalls as well? Because generally losing unwind information from noreturn calls is a lose when it comes to debugging. r~ Ah, good point. You want to know where abort() was called from indeed! However, I might still want to make it an option for cases where debugging isn't going to be important; it seems to me that the generated code should still be valid. cheers, DaveK -- Can't think of a witty .sigline today
Re: New brach 'yara-branch' is created
The lower-subreg patch that Richard Henderson posted, and that comes
up again and again from time to time, may also help. It does require
a bit of hacking in the MDs (mostly removing the DImode patterns for
logical operations since the middle-end is able to synthesize them on
its own).
Thanks for the information. I'll look at this.
Here is an updated patch; the code is also cleaned up a bit to comply
better with the GCC coding standards.
The big TODO item there, is that the pass has a bald-faced assumption
that [every] subreg [of a multi-word reg] is actually inside an operand,
and is thus replacable. This might be false if the target plays games
with subregs in the patterns. Perhaps a better approach is to mirror
what regrename does wrt recognizing the insn, iterating over the
operands, smashing the operands out and iterating over the resulting
pattern. Note that regrename as far as I understand does *much* more
than what this pass should do.
Paolo
Index: Makefile.in
===
--- Makefile.in (revision 108713)
+++ Makefile.in (working copy)
@@ -972,7 +978,7 @@ OBJS-common = \
insn-extract.o insn-opinit.o insn-output.o insn-peep.o insn-recog.o \
integrate.o intl.o jump.o langhooks.o lcm.o lists.o local-alloc.o \
loop.o mode-switching.o modulo-sched.o optabs.o options.o opts.o \
- params.o postreload.o postreload-gcse.o predict.o\
+ params.o postreload.o postreload-gcse.o predict.o lower-subreg.o \
insn-preds.o pointer-set.o \
print-rtl.o print-tree.o profile.o value-prof.o var-tracking.o
\
real.o recog.o reg-stack.o regclass.o regmove.o regrename.o \
@@ -1722,6 +1767,8 @@ langhooks.o : langhooks.c $(CONFIG_H) $(
$(TREE_H) toplev.h tree-inline.h $(RTL_H) insn-config.h $(INTEGRATE_H) \
langhooks.h $(LANGHOOKS_DEF_H) $(FLAGS_H) $(GGC_H) $(DIAGNOSTIC_H) intl.h \
$(TREE_GIMPLE_H)
+lower-subreg.o : lower-subreg.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \
+ $(MACHMODE_H) $(RTL_H) bitmap.h
tree.o : tree.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) \
$(FLAGS_H) function.h $(PARAMS_H) \
toplev.h $(GGC_H) $(HASHTAB_H) $(TARGET_H) output.h $(TM_P_H) langhooks.h \
Index: dwarf2out.c
===
--- dwarf2out.c (revision 108713)
+++ dwarf2out.c (working copy)
@@ -8892,6 +8892,31 @@ concat_loc_descriptor (rtx x0, rtx x1)
return cc_loc_result;
}
+/* Return a descriptor that describes the concatenation of N locations. */
+
+static dw_loc_descr_ref
+concatn_loc_descriptor (rtx concatn)
+{
+ dw_loc_descr_ref cc_loc_result = NULL;
+ unsigned int i, n = XVECLEN (concatn, 0);
+
+ for (i = 0; i n; ++i)
+{
+ dw_loc_descr_ref ref;
+ rtx x = XVECEXP (concatn, 0, i);
+
+ ref = loc_descriptor (x);
+ if (ref == NULL)
+ return NULL;
+
+ add_loc_descr (cc_loc_result, ref);
+ ref = new_loc_descr (DW_OP_piece, GET_MODE_SIZE (GET_MODE (x)), 0);
+ add_loc_descr (cc_loc_result, ref);
+}
+
+ return cc_loc_result;
+}
+
/* Output a proper Dwarf location descriptor for a variable or parameter
which is either allocated in a register or in a memory location. For a
register, we just generate an OP_REG and the register number. For a
@@ -8929,6 +8954,10 @@ loc_descriptor (rtx rtl)
loc_result = concat_loc_descriptor (XEXP (rtl, 0), XEXP (rtl, 1));
break;
+case CONCATN:
+ loc_result = concatn_loc_descriptor (rtl);
+ break;
+
case VAR_LOCATION:
/* Single part. */
if (GET_CODE (XEXP (rtl, 1)) != PARALLEL)
Index: emit-rtl.c
===
--- emit-rtl.c (revision 108713)
+++ emit-rtl.c (working copy)
@@ -846,13 +846,12 @@ gen_reg_rtx (enum machine_mode mode)
return val;
}
-/* Generate a register with same attributes as REG, but offsetted by OFFSET.
+/* Update NEW with same attributes as REG, but offsetted by OFFSET.
Do the big endian correction if needed. */
-rtx
-gen_rtx_REG_offset (rtx reg, enum machine_mode mode, unsigned int regno, int
offset)
+static void
+update_reg_offset (rtx new, rtx reg, int offset)
{
- rtx new = gen_rtx_REG (mode, regno);
tree decl;
HOST_WIDE_INT var_size;
@@ -894,7 +893,7 @@ gen_rtx_REG_offset (rtx reg, enum machin
if ((BYTES_BIG_ENDIAN || WORDS_BIG_ENDIAN)
decl != NULL
offset 0
- GET_MODE_SIZE (GET_MODE (reg)) GET_MODE_SIZE (mode)
+ GET_MODE_SIZE (GET_MODE (reg)) GET_MODE_SIZE (GET_MODE (new))
((var_size = int_size_in_bytes (TREE_TYPE (decl))) 0
var_size GET_MODE_SIZE (GET_MODE (reg
{
@@ -938,6 +937,27 @@ gen_rtx_REG_offset (rtx reg, enum machin
REG_ATTRS (new) = get_reg_attrs (REG_EXPR (reg),
REG_OFFSET (reg) +
using libmudflap with non-instrumented shared libraries
Using libmudflap to test a program that uses libxml2, I found that if
a program access a constant pointer in a non-instrumented library,
mudflap thinks that a read violation has occurred.
A simple test that illustrates this is:
a.c:
-
char *p = abc;
-
b.c:
#include stdio.h
extern char *p;
int main() {
char a = p[0];
printf(%c\n,a);
return 0;
}
compile and link with
gcc -shared -fPIC a.c -o liba.so
gcc -fmudflap -lmudflap b.c -la -L. -o b
When b is run, mudflap prints:
***
mudflap violation 1 (check/read): time=1142875338.034838 ptr=0xb7e2a521 size=1
pc=0xb7e34317 location=`b.c:5 (main)'
/usr/lib/libmudflap.so.0(__mf_check+0x37) [0xb7e34317]
./b(main+0x7a) [0x80487f2]
/usr/lib/libmudflap.so.0(__wrap_main+0x176) [0xb7e34ed6]
number of nearby objects: 0
-
Given how mudflap works, it would be very hard to avoid this false
positive. It would be nice if this limitation was documented.
Thanks,
Rafael
Re: New brach 'yara-branch' is created
Paolo Bonzini [EMAIL PROTECTED] writes: The lower-subreg patch that Richard Henderson posted, and that comes up again and again from time to time, may also help. It does require a bit of hacking in the MDs (mostly removing the DImode patterns for logical operations since the middle-end is able to synthesize them on its own). Thanks for the information. I'll look at this. Here is an updated patch; the code is also cleaned up a bit to comply better with the GCC coding standards. I'll note that I also have an updated version of this patch, which I have not been posting due to copyright assignment issues. I think my version is a bit better since it recognizes the insn and walks over the operands, rather than walking over the whole pattern. I have very good results on some test cases. In general, though, for best results on i386 the register allocator needs to be improved to track subreg deaths independently. I've started that work, but not completed it. If anybody wants to look at my patch, let me know privately. I am hoping that the copyright assignment issue will be resolved Real Soon Now. Ian
Re: NOPs inserting problem in GCC 4.1.x
Ling-hua Tseng [EMAIL PROTECTED] writes: Because I need to use the feature of `length' attribute (i.e., use get_attr_length() in machine description), I have to insert NOPs explicitly before performing the pass 58 (shorten) such that the shorten pass can calculate the length of insns exactly. Can I direct move the reorg pass to the under of shorten pass by modifying the passes.c? One typical trick is to insert the nops in TARGET_ASM_FUNCTION_PROLOGUE, and then call insn_insn_lengths (); shorten_branches (get_insns ()); to recompute everything. Yes, it's ugly. Ian
Re: using libmudflap with non-instrumented shared libraries
rafael.espindola wrote: [...] extern char *p; [...] char a = p[0]; [...] compile and link with gcc -shared -fPIC a.c -o liba.so gcc -fmudflap -lmudflap b.c -la -L. -o b Did the compiler give you a warning about inability to track the lifetime of p? It should have. - FChE
Re: using libmudflap with non-instrumented shared libraries
Did the compiler give you a warning about inability to track the lifetime of p? It should have. No. Not even with -Wall -O2. gcc -v: gcc (GCC) 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9) - FChE Thanks, Rafael
Re: iWMMXt/Linux EABI toolchain
Hello again Daniel and all! I'm still working on building the iWMMXt/EABI/NPTL toolchain. I've got to the stage where I have everything built upto the final linking of glibc. Sadly despite making a lot of progress and fixing many problems I am now stuck. As I previously discovered the current gcc-trunk will not build glibc with this configuration due to inlining when it should not, so I decided to try 4.1.0. It mostly works though I had to make a few changes to enable my configuration. I have also ended up patching 4.1.0 with the missing ARM EABI changes from trunk while trying to get everthing to work. My current and hopefully final hurdle is attached. The missing symbols are certainly present in the target libc.a, any idea what I need to fix? Using built-in specs. Target: arm-iwmmxt-linux-gnueabi Configured with: /var/tmp/portage/gcc-4.1.0/work/gcc-4.1.0/configure --prefix=/usr --bindir=/usr/arm-iwmmxt-linux-gnueabi/gcc-bin/4.1.0 --includedir=/usr/lib/gcc/arm-iwmmxt-linux-gnueabi/4.1.0/include --datadir=/usr/share/gcc-data/arm-iwmmxt-linux-gnueabi/4.1.0 --mandir=/usr/share/gcc-data/arm-iwmmxt-linux-gnueabi/4.1.0/man --infodir=/usr/share/gcc-data/arm-iwmmxt-linux-gnueabi/4.1.0/info --with-gxx-include-dir=/usr/lib/gcc/arm-iwmmxt-linux-gnueabi/4.1.0/include/g++-v4 --host=i686-pc-linux-gnu --target=arm-iwmmxt-linux-gnueabi --build=i686-pc-linux-gnu --disable-altivec --with-arch=iwmmxt --with-cpu=iwmmxt --disable-multilib --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --disable-multilib --disable-libmudflap --enable-java-awt=gtk --enable-shared --enable-threads=posix --enable-languages=c,c++,java --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.1.0 Steve ___ Yahoo! Photos NEW, now offering a quality print service from just 8p a photo http://uk.photos.yahoo.com build.log Description: 988914365-build.log
alias time explosion
I'm not sure when this happened, but I noticed on the weekend that there has been an explosion in the time spent during the alias analysis phase. using cplusplus-grammer.ii, it use to compile on my machine in about 55 seconds, and its now up to about 150 seconds. A quick gprof indicated about 60% of compile time is being spent in bitmap_bit_p, called from compute_may_aliases. someone made it WAY slow :-) Andrew
Re: alias time explosion
On Mar 20, 2006, at 5:18 PM, Andrew MacLeod wrote: I'm not sure when this happened, but I noticed on the weekend that there has been an explosion in the time spent during the alias analysis phase. using cplusplus-grammer.ii, it use to compile on my machine in about 55 seconds, and its now up to about 150 seconds. A quick gprof indicated about 60% of compile time is being spent in bitmap_bit_p, called from compute_may_aliases. someone made it WAY slow :-) Could it be that 2 more passes of may_alias was added? -- Pinski
Re: FSF Policy re. inclusion of source code from other projects in GCC
Mark == Mark Mitchell [EMAIL PROTECTED] writes: Mark The FSF and GCC SC have decided to move fastjar to savannah, and Mark stop including it in future GCC releases, which will clarify Mark this situation. Will someone please volunteer to migrate Mark fastjar out of our repository? I'll take it out later this week. I am leaning toward putting it into the rhug repository on sourceware.org, simply because then we (the gcj hackers) won't have to go through some long project registration process. Speak up if you have a particular problem with this. Tom
Re: FSF Policy re. inclusion of source code from other projects in GCC
Tom Tromey wrote: I am leaning toward putting it into the rhug repository on sourceware.org, simply because then we (the gcj hackers) won't have to go through some long project registration process. Speak up if you have a particular problem with this. Thanks! I would prefer it go on savannah, which is more clearly unaffiliated with any particular commercial entity. The discussion on the SC list did mention moving it to savannah, but I don't think we specifically said it had to be savannah; we were using that as an example. I don't think I have any special authority to make this call, though, and I'm not trying to accuse anyone of anything whatsoever, so please don't interpret that request as some kind of dig. Nor do I in any way fail to appreciate Red Hat's support of free software by donating the machine. So, this is definitely in the my-two-cents category. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Ada subtypes and base types
On Sat, 2006-03-18 at 10:24 +0100, Laurent GUERBY wrote:
On Fri, 2006-03-17 at 12:51 -0700, Jeffrey A Law wrote:
I'm not suggesting the FEs deduce more types and track ranges;
that would be rather absurd. What I'm saying is that exposing
these types outside the FE is most likely costing you both on
the compile-time side and on the run-time side.
About optimization, in most languages with array bounds and
range checks, the FE will build a structure with bounds
and code like the following for a typical array loop (sorry
for poor C):
struct {
int low,high; /* no alias */
double *data;
} X;
int first_i=X.low+2;
int last_i=X.high-3;
int i;
if (first_i=last_i) {
for(i=first_i;i=last_i;i++) {
if (iX.low||iX.high) raise_bound_error(); /* CHECK */
do_something(array_with_bounds[i]);
}
}
The interesting thing performance wise would be to be able to remove the
CHECK in the BE.
Is there some optimization pass able to do that?
And when +2 and -3 are replaced by +x and -y and we
know through typing that x=0 and y=0?
Not sure, mostly because of the structure accesses and my lack
of knowledge about the symbolic range support. I know we have
symbolic range support, but haven't looked to see how good it
really is. What we're doing now is certainly better than what
DOM did for symbolic ranges (nothing).
Note that this is closely related to some of the bounds checking
elimination we want to support for Java one day IIRC.
Note also that if i, first_i and/or last_i are globals, then the
odds of these kind of tests being deleted go down considerably
as they're likely call-clobbered by the call to do_something.
Jeff
Re: Multiple errors with GCOV
I don't see any progress on GCOV, so I assume it's up to me to fix these bugs. I'm writing here to cooperate with GCOV developers to avoid duplicate work. There are two gcov maintainers listed in the GCC maintainers file: gcovJan Hubicka [EMAIL PROTECTED] gcovNathan Sidwell [EMAIL PROTECTED] You might like to drop them a mail message specifically (in case they haven't seen your message on the list). Generally speaking, if you find genuine gcov bugs, then your patches will be welcome. Thanks, Ben
Re: alias time explosion
On Mon, 2006-03-20 at 18:55 -0500, Andrew Pinski wrote: On Mar 20, 2006, at 5:18 PM, Andrew MacLeod wrote: I'm not sure when this happened, but I noticed on the weekend that there has been an explosion in the time spent during the alias analysis phase. using cplusplus-grammer.ii, it use to compile on my machine in about 55 seconds, and its now up to about 150 seconds. A quick gprof indicated about 60% of compile time is being spent in bitmap_bit_p, called from compute_may_aliases. someone made it WAY slow :-) Could it be that 2 more passes of may_alias was added? I don't think so. I would expect that to double or triple the time spent in alias analysis, not the entire compile time. This is a 200% increase in compiler time... going from 50 seconds to 150 is pretty significant. And since its almost all in bitmap_bit_p, it sounds algorithmic to me... btw, this was on a 3.0 Ghz P4 running linux with a checkout from mainline this morning built with no checking... Doing a quick check back, on 01/23 shows similar time (71% of compiler time spent in alias analysis, 97 seconds out of 135). The previous compiler to that which I have laying around is 10/30/05, and it shows a much more sensible 6.32 seconds in alias analysis. It looks like sometime between 10/30 and 01/23 alias analysis got out of hand. Odd it hasn't been noted before. Andrew
Aliasing sets on Arrays Types
Take the following C code:
typedef long atype[];
typedef long atype1[];
int NumSift (atype *a, atype1 *a1)
{
(*a)[0] = 0;
(*a1)[0] = 1;
return (*a)[0];
}
Shouldn't the aliasing set for the type atype be the same as atype1?
In NumSift, shouldn't the store to (*a1)[0] interfere with (*a)[0] so
that we
don't return 0 always?
Here is a full testcase for testing (I don't get any warnings with -W
-Wall -pedantic):
typedef long atype[];
typedef long atype1[];
int NumSift (atype *a, atype1 *a1)
{
(*a)[0] = 0;
(*a1)[0] = 1;
return (*a)[0];
}
int main(void)
{
long a[2];
if (!NumSift(a, a))
__builtin_abort ();
return 0;
}
And this is a regression from 3.4.0 if this is a bug.
Also note this was generated from looking at Daniel Berlin's Array
Reference
for Pointers patch.
Thanks,
Andrew Pinski
[Bug libffi/26744] vararg functions support in libffi is not supported
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-20 08:08 --- Confirmed, this is an enhancement because this is no support at all in libffi for var args. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|powerpc-apple-darwin8.5.0 | GCC host triplet|powerpc-apple-darwin8.5.0 | Last reconfirmed|-00-00 00:00:00 |2006-03-20 08:08:56 date|| Summary|ffi_call can't pass |vararg functions support in |floating-point values to a |libffi is not supported |function which has variable | |argument list. | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26744
[Bug c/26765] New: ICE in in extract_insn, at recog.c:2036
GCC trunk gets this ICE when building glibc. The ICE happens on gcc 4.1 too.
This happens when -O2 is turned on. Here is a reduced testcase to reproduce the
problem.
example.c
==
__thread int *a = 0;
void foo (void)
{
extern int *b;
b = (int *) ((*a));
}
how to reproduce
mips-elf-gcc -O2 -c example.c
example.c: In function 'foo':
example.c:7: error: unrecognizable insn:
(insn 14 13 15 3 (set (reg/f:SI 193)
(mem/c/i:SI (lo_sum:SI (reg:SI 195)
(const:SI (unspec:SI [
(symbol_ref:SI (a) [flags 0x22] var_decl
0xb7c4a840 a)
] 114))) [2 a+0 S4 A32])) -1 (nil)
(nil))
example.c:7: internal compiler error: in extract_insn, at recog.c:2036
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
Summary: ICE in in extract_insn, at recog.c:2036
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raj dot khem at gmail dot com
GCC build triplet: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: mips-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26765
[Bug libstdc++/25409] STL mt_allocator crash in global construcutor
--- Comment #7 from neil at fnxweb dot com 2006-03-20 08:48 --- Fair enough; for the record, I did spend an obscene amount of time trying to make the example more straightforward, but *any* simplification over what I attached worked OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25409
[Bug fortran/26766] New: [F2003] Recursive I/O still (again) broken
Hi, I just checked recursive I/O which was addressed in PR 19352. It is declared resolved, but still fails with this example: program gfcbug32 implicit none character (len=4) :: str write (str, '(a)') foo (-1) write (*,*) Test 1:, str write (str, '(a)') foo (1234) write (*,*) Test 2:, str contains function foo (i) result (s) integer, intent(in) :: i character (len=4) :: s if (i 0) then s = 1234 else ! Internal I/O, allowed recursive in f2003, see section 9.11 write (s, '(i4.4)') i end if end function foo end program gfcbug32 I get: At line 6 of file gfcbug32.f90 Fortran runtime error: End of record Test 1:1234 Cheers, -ha -- Summary: [F2003] Recursive I/O still (again) broken Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de GCC host triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26766
[Bug java/26042] ICE in mark_reference_fields, at java/boehm.c:105
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-03-20 09:09 --- I wonder why this seems to be ppc specific. powerpc64 works, as does i686. 3.3.3 also fails, so probably not a regression. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.0 4.2.0 3.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26042
[Bug c++/26767] New: Optimization level -O3 changes the program behavior
Following program generates different outputs for -O1 and -O3 optimization
levels.
#include stdio.h
typedef struct _airInfo{
unsigned int craftNo : 16;
unsigned int onAir:1;
unsigned int numCrew:2;
unsigned int numPassenger:2;
unsigned int onLand:1;
unsigned int fuelTank:2;
unsigned int height: 8;
} airInfo_t ;
#pragma pack(1)
typedef struct _atmosphere {
int temp:24;
int humidity:24;
int pressure:24;
int altitude:24;
}atmosphere_t;
typedef struct _mixedInfo {
airInfo_tai;
atmosphere_t atm;
}mixedInfo_t;
#pragma pack()
int main() {
mixedInfo_t mi ;
mi.ai.height = 17;
mi.ai.craftNo = 1;
mi.ai.onAir= 0;
mi.ai.numCrew = 2;
mi.ai.numPassenger = 2;
mi.ai.onLand = 0;
mi.ai.fuelTank = 0;
printf(ai in num = %u\n, (*((unsigned int *)(mi.ai ;
return 0 ;
}
// Output from program when compiled with -O1
$ g++ -O1 test1.cxx ; ./a.out
ai in num = 286523393
// Output from program when compiled with -O3
$ g++ -O3 test1.cxx ; ./a.out
ai in num = 1310720
--
Summary: Optimization level -O3 changes the program behavior
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mor_gopal at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26767
[Bug c++/26767] Optimization level -O3 changes the program behavior
--- Comment #1 from mor_gopal at yahoo dot com 2006-03-20 10:00 --- Following details are added. // g++ version info $ g++ -v Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=x86_64-redhat-linux Thread model: posix gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.1) // System info $uname -a Linux NEW1_dev_opteron 2.6.9-11.EL #1 Fri May 20 18:15:25 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26767
[Bug c++/26767] Optimization level -O3 changes the program behavior
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-03-20 10:08 --- *** This bug has been marked as a duplicate of 21920 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26767
[Bug c/21920] alias violating
--- Comment #87 from rguenth at gcc dot gnu dot org 2006-03-20 10:08 --- *** Bug 26767 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||mor_gopal at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug tree-optimization/26763] [4.1 Regression] wrong final value of induction variable calculated
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-20 10:15 --- Confirmed. -fno-tree-loop-optimize makes it work. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-20 10:15:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26763
[Bug c/26768] New: fixinclude supplied file doesn't declare some constants in float.h
the float.h hader gets just replaced with another version, it doesn't patch the system one. Some constants like #define FP_PLUS_ZERO 2 are thus not defined. I was told that on newer os versions this doesn't get noticed since these are duplicated in math.h which gets patched. -- Summary: fixinclude supplied file doesn't declare some constants in float.h Product: gcc Version: 3.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: multix at gmail dot com GCC build triplet: powerpc-ibm-aix4.2.1.0 GCC host triplet: powerpc-ibm-aix4.2.1.0 GCC target triplet: powerpc-ibm-aix4.2.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26768
[Bug fortran/25034] allows passing of contained subprograms as actual argument
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-03-20 12:49 --- (In reply to comment #2) Isn't this just a dup of bug 20861? ... and, in fact, was fixed by the patch for 20861. I will set this one as resolved tonight. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25034
[Bug c++/26690] ICE in get_callee_fndecl, at tree.c:5806 with OpenMP
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-03-15 13:00:21 |2006-03-20 14:23:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26690
[Bug c++/26691] Wrong code for constructor with default value
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-03-15 12:58:26 |2006-03-20 14:24:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26691
[Bug libgomp/26651] [gomp] #omp for ordered leaks memory
--- Comment #2 from rth at gcc dot gnu dot org 2006-03-20 16:43 --- Failing to call GOMP_loop_end. -- rth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-03-15 15:59:22 |2006-03-20 16:43:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26651
[Bug target/26768] fixinclude supplied file doesn't declare some constants in float.h
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-20 17:02 --- float.h is a standard header required to be supplied by the compiler and FP_PLUS_ZERO is non standard. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |target Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26768
[Bug libstdc++/21405] Template inlines have global visibility
--- Comment #12 from cristipp at excite dot com 2006-03-20 17:07 --- (In reply to comment #11) There is an one defintion rule in C++ unlike most other languages which have weak symbols. And if you are working around it by using hidden symbols well you are asking to run into troubles. I don't believe that C++ has to say (should say) anything that pertains to shared libraries. Moreover, symbol versions were added as workarounds for problems created by the ELF format semantics. This is a platform specific problem, not a pure C++ problem. However, to have the gnu toolchain to properly support C++ on ELF platforms, adding proper versioning for *all* symbols, including template-originated symbols is a must. I'm not sure if this is a task for g++ of for the linker or for both, but someone should eventually acknowledge that there is a problem and start looking for solutions... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21405
[Bug fortran/26766] [F2003] Recursive I/O still (again) broken
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-20 17:20 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||20585 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|i686-pc-cygwin | Last reconfirmed|-00-00 00:00:00 |2006-03-20 17:20:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26766
[Bug target/26765] ICE in in extract_insn, at recog.c:2036
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-20 17:30 --- First this is a bug but glibc does not support mips-elf as a target though, it does support mips-linux-gnu though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26765
[Bug libstdc++/21405] Template inlines have global visibility
--- Comment #13 from hjl at lucon dot org 2006-03-20 17:30 --- FWIW, the current GNU binutils and glibc treat the weak definition in shared libraries as strong. There is even a whole set of testsuite for this in the GNU binutils. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21405
[Bug target/26765] ICE in in extract_insn with __thread and optimization
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-20 17:56 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i386-redhat-linux | GCC host triplet|i386-redhat-linux | GCC target triplet|mips-unknown-elf|mips-*-elf Last reconfirmed|-00-00 00:00:00 |2006-03-20 17:56:56 date|| Summary|ICE in in extract_insn, at |ICE in in extract_insn with |recog.c:2036|__thread and optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26765
[Bug libstdc++/21405] Template inlines have global visibility
--- Comment #14 from cristipp at excite dot com 2006-03-20 18:32 --- The problem is not how the dynamic linker treats 'weak' symbols. The problem is that template originating functions having no version numbers. It just happen that template originating functions are also marked as weak (if I understand correctly). In other words, if I have a regular C/C++ function, I can attach version strings to it, whereas it I have a C++ template function I cannot attach version strings to it, or more precisely to instances of it. I don't really care whether symbols are 'weak' or 'strong', I only care of proper versioning for *all* C++ symbols. I believe that this situation was clearly described by the original bug reporter 10 months ago. For some reason nobody seems to acknowledge that there is a problem, the main line of reasoning so far being that 'C++ standard says only unique (weak) names are valid'. However, that flies in the face of the whole synmbol versioning mechanism, weak symbols or not. Afterall, versioning for symbols was introduced precisely to allow multiple instances of the same symbol to be valid in a shared object context. Please feel free to correct me on any g++ internal details on which I am no expert. However, the root problem is there and is a show-stopper for any attempt of distributing pre-compiled C++ shared object binaries. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21405
[Bug fortran/26769] New: TRANSPOSE() requires _gfortran_transpose_i10 for REAL(10) arrays
The following program fails to link: [scala] test/fortran cat transpose_10.f90 real(10) :: a(3,3) a = 1.0_10 a(1,3) = 0.0_10 print *, transpose(a) end [scala] test/fortran gfc transpose_10.f90 /tmp/ccaMoldQ.o(.text+0x1b2): In function `MAIN__': : undefined reference to `_gfortran_transpose_i10' collect2: ld returned 1 exit status -- Summary: TRANSPOSE() requires _gfortran_transpose_i10 for REAL(10) arrays Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26769
[Bug libstdc++/21405] Template inlines have global visibility
--- Comment #15 from pluto at agmk dot net 2006-03-20 19:34 --- see PR19664, PR20218, PR20297. -- pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21405
[Bug fortran/26769] TRANSPOSE() requires _gfortran_transpose_i10 for REAL(10) arrays
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-03-20 19:33 --- Same for reshape, as noted on the mailing list. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-20 19:33:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26769
[Bug libstdc++/21405] Template inlines have global visibility
--- Comment #16 from pluto at agmk dot net 2006-03-20 19:35 --- (In reply to comment #15) see PR19664, PR20218, PR20297. ops, this is the note for C#10. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21405
[Bug pch/14933] missing pre-compiled header depends with -MD
--- Comment #5 from pedz at easesoftware dot net 2006-03-20 19:40 --- This is also on 4.0.2. This is marked as Serverity of enhancement. Can we change that to normal? -- pedz at easesoftware dot net changed: What|Removed |Added CC||pedz at easesoftware dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14933
[Bug c++/11070] [3.4 regression] ICE in regenerate_decl_from_template after forgotten template for disambiguation
--- Comment #7 from cvs-commit at developer dot classpath dot org 2006-03-20 20:03 --- Subject: Bug 11070 CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Chris Burdess [EMAIL PROTECTED]06/03/20 19:54:35 Modified files: . : ChangeLog gnu/xml/stream : XMLParser.java Log message: 2006-03-20 Chris Burdess [EMAIL PROTECTED] Fixes PR 11070 * gnu/xml/stream/XMLParser.java: Permit U+fffd as XML Char. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.6830tr2=1.6831r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/gnu/xml/stream/XMLParser.java.diff?tr1=1.27tr2=1.28r1=textr2=text -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11070
[Bug fortran/26769] TRANSPOSE() requires _gfortran_transpose_i10 for REAL(10) arrays
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-03-20 20:13 --- The way to solve is is to add transpose_r_10.c and reshape_r_10.c to libgfortran's Makefile.am, then regenerating (which I am always a little afraid of :-) and modifying the front end to call the 'r' version if there is no corresponding 'i' version. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26769
[Bug tree-optimization/26629] tree load PRE does not work on array references
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-20 21:00 --- Subject: Bug 26629 Author: pinskia Date: Mon Mar 20 21:00:18 2006 New Revision: 112227 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112227 Log: 2006-03-20 Andrew Pinski [EMAIL PROTECTED] PR tree-opt/26629 * tree-ssa-pre (phi_translate): Handle ARRAY_REF's operands. (valid_in_set): Handle ARRAY_REF. Change if min_variant or VH to asserts. (create_component_ref_by_pieces): Handle ARRAY_REF. (create_expression_by_pieces): Likewise. (can_PRE_operation): ARRAY_REFs can now be PRE'd. 2006-03-20 Andrew Pinski [EMAIL PROTECTED] PR tree-opt/26629 * gcc.dg/tree-ssa/loadpre12.c: New test. * gcc.dg/tree-ssa/loadpre13.c: New test. * gcc.dg/tree-ssa/loadpre14.c: New test. * gcc.dg/tree-ssa/loadpre15.c: New test. * gcc.dg/tree-ssa/loadpre16.c: New test. * gcc.dg/tree-ssa/loadpre17.c: New test. * gcc.dg/tree-ssa/loadpre18.c: New test. * gcc.dg/tree-ssa/loadpre19.c: New test. * gcc.dg/tree-ssa/loadpre20.c: New test. * gcc.dg/tree-ssa/loadpre21.c: New test. * gcc.dg/tree-ssa/loadpre22.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/loadpre12.c trunk/gcc/testsuite/gcc.dg/tree-ssa/loadpre13.c trunk/gcc/testsuite/gcc.dg/tree-ssa/loadpre14.c trunk/gcc/testsuite/gcc.dg/tree-ssa/loadpre15.c trunk/gcc/testsuite/gcc.dg/tree-ssa/loadpre16.c trunk/gcc/testsuite/gcc.dg/tree-ssa/loadpre17.c trunk/gcc/testsuite/gcc.dg/tree-ssa/loadpre18.c trunk/gcc/testsuite/gcc.dg/tree-ssa/loadpre19.c trunk/gcc/testsuite/gcc.dg/tree-ssa/loadpre20.c trunk/gcc/testsuite/gcc.dg/tree-ssa/loadpre21.c trunk/gcc/testsuite/gcc.dg/tree-ssa/loadpre22.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26629
[Bug tree-optimization/26629] tree load PRE does not work on array references
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-20 21:00 --- Fixed in rev 112227. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26629
[Bug c++/26770] New: hidden visibility for symbols from anonymous namespaces.
unnamed namespace restricts the visibility of the defined entities to the source file in which the anonymous namespace is defined. IMHO gcc should hide by default symbols from anonymous namespaces. current gcc behaviour exports useless anon. symbols: ... g DF .text ... Base (anonymous namespace)::internalImplementation(int) -- Summary: hidden visibility for symbols from anonymous namespaces. Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net GCC build triplet: * GCC host triplet: * GCC target triplet: * http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26770
[Bug c++/26770] hidden visibility for symbols from anonymous namespaces.
--- Comment #1 from pluto at agmk dot net 2006-03-20 21:08 --- Created an attachment (id=11074) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11074action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26770
[Bug c++/26770] hidden visibility for symbols from anonymous namespaces.
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-20 21:11 --- *** This bug has been marked as a duplicate of 21581 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26770
[Bug c++/21581] (optimisation) Functions in anonymous namespaces should default to hidden visibility
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-03-20 21:11 --- *** Bug 26770 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21581
[Bug tree-optimization/26771] New: [4.2 regression] ICE with -fmudflap
The following code snippet causes an ICE on mainline when compiled with
-fmudflap -O2:
===
extern C
{
extern void __mf_unregister (void*, __SIZE_TYPE__, int) throw();
}
struct A
{
int i;
A(int j) : i(j) { }
};
struct B
{
B(const B);
};
struct C
{
B b;
int i;
void foo(int, B) {}
~C() { foo(i, b); }
};
struct D
{
C* p;
~D() { delete p; }
};
struct E
{
B b;
int i;
void bar(A);
void baz(D) { bar(A(i)); }
};
int f0(char*);
inline bool f1(char* p, char* q, int)
{
return p ? p : q;
}
inline bool f2(char* p)
{
return f1(p, 0, f0(p));
}
void f2(E e)
{
if (f2(0)) e.baz(D());
}
===
--
Summary: [4.2 regression] ICE with -fmudflap
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26771
[Bug tree-optimization/26771] [4.2 regression] ICE with -fmudflap
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-20 21:52 --- The ICE is after VRP. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26771
[Bug tree-optimization/26771] [4.2 regression] ICE with -fmudflap
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-20 21:54 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-20 21:54:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26771
[Bug fortran/20935] failed assertion for maxloc(n, mask=.true.)
--- Comment #7 from tkoenig at gcc dot gnu dot org 2006-03-20 21:56 --- Subject: Bug 20935 Author: tkoenig Date: Mon Mar 20 21:56:00 2006 New Revision: 112230 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112230 Log: 2006-03-20 Thomas Koenig [EMAIL PROTECTED] PR fortran/20935 * iresolve.c (gfc_resolve_maxloc): If mask is scalar, prefix the function name with an s. If the mask is scalar or if its kind is smaller than gfc_default_logical_kind, coerce it to default kind. (gfc_resolve_maxval): Likewise. (gfc_resolve_minloc): Likewise. (gfc_resolve_minval): Likewise. (gfc_resolve_product): Likewise. (gfc_resolve_sum): Likewise. 2006-03-20 Thomas Koenig [EMAIL PROTECTED] PR fortran/20935 * m4/iforeach.m4: Add SCALAR_FOREACH_FUNCTION macro. * m4/ifunction.m4: Add SCALAR_ARRAY_FUNCTION macro. * m4/minloc0.m4: Use SCALAR_FOREACH_FUNCTION. * m4/minloc1.m4: Use SCALAR_ARRAY_FUNCTION. * m4/maxloc0.m4: Use SCALAR_FOREACH_FUNCTION. * m4/maxloc1.m4: Use SCALAR_ARRAY_FUNCTION. * m4/minval.m4: Likewise. * m4/maxval.m4: Likewise. * m4/product.m4: Likewise. * m4/sum.m4: Likewise. * minloc0_16_i16.c : Regenerated. * minloc0_16_i4.c : Regenerated. * minloc0_16_i8.c : Regenerated. * minloc0_16_r10.c : Regenerated. * minloc0_16_r16.c : Regenerated. * minloc0_16_r4.c : Regenerated. * minloc0_16_r8.c : Regenerated. * minloc0_4_i16.c : Regenerated. * minloc0_4_i4.c : Regenerated. * minloc0_4_i8.c : Regenerated. * minloc0_4_r10.c : Regenerated. * minloc0_4_r16.c : Regenerated. * minloc0_4_r4.c : Regenerated. * minloc0_4_r8.c : Regenerated. * minloc0_8_i16.c : Regenerated. * minloc0_8_i4.c : Regenerated. * minloc0_8_i8.c : Regenerated. * minloc0_8_r10.c : Regenerated. * minloc0_8_r16.c : Regenerated. * minloc0_8_r4.c : Regenerated. * minloc0_8_r8.c : Regenerated. * minloc1_16_i16.c : Regenerated. * minloc1_16_i4.c : Regenerated. * minloc1_16_i8.c : Regenerated. * minloc1_16_r10.c : Regenerated. * minloc1_16_r16.c : Regenerated. * minloc1_16_r4.c : Regenerated. * minloc1_16_r8.c : Regenerated. * minloc1_4_i16.c : Regenerated. * minloc1_4_i4.c : Regenerated. * minloc1_4_i8.c : Regenerated. * minloc1_4_r10.c : Regenerated. * minloc1_4_r16.c : Regenerated. * minloc1_4_r4.c : Regenerated. * minloc1_4_r8.c : Regenerated. * minloc1_8_i16.c : Regenerated. * minloc1_8_i4.c : Regenerated. * minloc1_8_i8.c : Regenerated. * minloc1_8_r10.c : Regenerated. * minloc1_8_r16.c : Regenerated. * minloc1_8_r4.c : Regenerated. * minloc1_8_r8.c : Regenerated. * maxloc0_16_i16.c : Regenerated. * maxloc0_16_i4.c : Regenerated. * maxloc0_16_i8.c : Regenerated. * maxloc0_16_r10.c : Regenerated. * maxloc0_16_r16.c : Regenerated. * maxloc0_16_r4.c : Regenerated. * maxloc0_16_r8.c : Regenerated. * maxloc0_4_i16.c : Regenerated. * maxloc0_4_i4.c : Regenerated. * maxloc0_4_i8.c : Regenerated. * maxloc0_4_r10.c : Regenerated. * maxloc0_4_r16.c : Regenerated. * maxloc0_4_r4.c : Regenerated. * maxloc0_4_r8.c : Regenerated. * maxloc0_8_i16.c : Regenerated. * maxloc0_8_i4.c : Regenerated. * maxloc0_8_i8.c : Regenerated. * maxloc0_8_r10.c : Regenerated. * maxloc0_8_r16.c : Regenerated. * maxloc0_8_r4.c : Regenerated. * maxloc0_8_r8.c : Regenerated. * maxloc1_16_i16.c : Regenerated. * maxloc1_16_i4.c : Regenerated. * maxloc1_16_i8.c : Regenerated. * maxloc1_16_r10.c : Regenerated. * maxloc1_16_r16.c : Regenerated. * maxloc1_16_r4.c : Regenerated. * maxloc1_16_r8.c : Regenerated. * maxloc1_4_i16.c : Regenerated. * maxloc1_4_i4.c : Regenerated. * maxloc1_4_i8.c : Regenerated. * maxloc1_4_r10.c : Regenerated. * maxloc1_4_r16.c : Regenerated. * maxloc1_4_r4.c : Regenerated. * maxloc1_4_r8.c : Regenerated. * maxloc1_8_i16.c : Regenerated. * maxloc1_8_i4.c : Regenerated. * maxloc1_8_i8.c : Regenerated. * maxloc1_8_r10.c : Regenerated. * maxloc1_8_r16.c : Regenerated. * maxloc1_8_r4.c : Regenerated. * maxloc1_8_r8.c : Regenerated. * maxval_i16.c : Regenerated. * maxval_i4.c : Regenerated. * maxval_i8.c : Regenerated. * maxval_r10.c : Regenerated. * maxval_r16.c : Regenerated. * maxval_r4.c : Regenerated. * maxval_r8.c : Regenerated. * minval_i16.c
[Bug c++/26773] New: array initialization
Program
#include stdio.h
struct A
{
A() { printf( %p %p\n, buf[0], this ); }
A( int j ) : i(j) { printf( %p %p\n, buf[0], this ); }
A( const A a ) : i(a.i) { printf( %p %p\n, buf[0], this ); }
A operator =( const A a ) { printf( %p %p\n, buf[0], this ); return
*this; }
A operator =( int j ) { printf( %p %p\n, buf[0], this ); return *this; }
~A() { printf( %p %p\n, buf[0], this ); }
int i;
char buf[2];
};
struct B
{
A a1;
};
const A a1 = 1;
int main()
{
printf( -- 0\n );
{
const B b[] = { {a1} };
}
printf( -- 1\n );
{
const B b;
}
printf( -- 2\n );
return 0;
}
give output like
0x8049b1c 0x8049b18
-- 0
0xbfd9a6a8 0xbfd9a6a4 // !!!
0xbfd9a6b8 0xbfd9a6b4 // !!!
-- 1
0xbfd9a6a8 0xbfd9a6a4
0xbfd9a6a8 0xbfd9a6a4
-- 2
0x8049b1c 0x8049b18
i.e. *this and buf[0] are differ in dtor and ctor in case of array
initialization with aggregate.
--
Summary: array initialization
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hidden_peak at mail dot ru
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=26773
[Bug c++/26773] [3.4 Regression] array initialization
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-20 22:35 --- Fixed in 4.0.0, 3.4.6 was the last release of 3.4.x. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||wrong-code Known to fail||3.0.4 3.4.0 3.3.3 Known to work||2.95.3 4.1.0 4.2.0 4.0.0 Resolution||FIXED Summary|array initialization|[3.4 Regression] array ||initialization Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26773
[Bug target/26765] ICE in in extract_insn with __thread and optimization
--- Comment #3 from raj dot khem at gmail dot com 2006-03-21 01:20 --- (In reply to comment #1) First this is a bug but glibc does not support mips-elf as a target though, it does support mips-linux-gnu though. True. I found it on mips-linux-gnu but because I verified the reduced testcase on baremetal (mips-elf) thats why the target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26765
[Bug c++/17314] Error message wrongly shows declared rather than inherited access
--- Comment #12 from jason at gcc dot gnu dot org 2006-03-21 02:48 --- tweak summary -- jason at gcc dot gnu dot org changed: What|Removed |Added Summary|Error message wrongly shows |Error message wrongly shows |declared rather than|declared rather than |inherited visibility|inherited access http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17314
[Bug c++/19238] cannot change visibility of static variable in function template
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-12-28 20:29:56 |2006-03-21 02:49:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19238
[Bug java/26042] ICE in mark_reference_fields, at java/boehm.c:105
--- Comment #6 from bje at gcc dot gnu dot org 2006-03-21 02:54 --- Based on an investigation of the problem by myself and Tom, it appears to be due to the object layout chosen for PPC32 (and presumably other) targets. -- bje at gcc dot gnu dot org changed: What|Removed |Added CC||janis187 at us dot ibm dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26042
[Bug c++/19238] cannot change visibility of static variable in function template
--- Comment #5 from jason at gcc dot gnu dot org 2006-03-21 03:19 --- Subject: Bug 19238 Author: jason Date: Tue Mar 21 03:19:06 2006 New Revision: 112239 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112239 Log: PR c++/21764 * c-pragma.c (visstack): Move out of handle_pragma_visibility. (push_visibility, pop_visibility): Likewise. * c-pragma.h: Declare them. * cp/name-lookup.h (struct cp_binding_level): Add has_visibility bitfield. * cp/name-lookup.c: Include c-pragma.h. (push_namespace_with_attribs): Split out from push_namespace. Push visibility if appropriate. Set TREE_PUBLIC on namespaces. (leave_scope): Pop visibility if appropriate. * cp/parser.c (cp_parser_declaration, cp_parser_namespace_name): Allow attributes on namespace declarations. PR c++/19238 * cp/decl.c (cp_finish_decl): Call determine_visibility later. (start_preparsed_function): Likewise. * cp/cp-tree.h (CP_TYPE_CONTEXT, TYPE_NAMESPACE_SCOPE_P): New macros. (TYPE_CLASS_SCOPE_P, TYPE_FUNCTION_SCOPE_P): New macros. * cp/decl2.c (determine_visibility_from_class): Split out from... (determine_visibility): ...here. Handle function scope and nested classes. (import_export_decl): Move visibility handling to determine_visibility_from_class. Added: trunk/gcc/testsuite/g++.dg/ext/visibility/local1.C trunk/gcc/testsuite/g++.dg/ext/visibility/namespace1.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-pragma.c trunk/gcc/c-pragma.h trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/decl2.c trunk/gcc/cp/name-lookup.c trunk/gcc/cp/name-lookup.h trunk/gcc/cp/parser.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19238
[Bug c++/21764] visibility attributes on namespace scope
--- Comment #11 from jason at gcc dot gnu dot org 2006-03-21 03:19 --- Subject: Bug 21764 Author: jason Date: Tue Mar 21 03:19:06 2006 New Revision: 112239 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112239 Log: PR c++/21764 * c-pragma.c (visstack): Move out of handle_pragma_visibility. (push_visibility, pop_visibility): Likewise. * c-pragma.h: Declare them. * cp/name-lookup.h (struct cp_binding_level): Add has_visibility bitfield. * cp/name-lookup.c: Include c-pragma.h. (push_namespace_with_attribs): Split out from push_namespace. Push visibility if appropriate. Set TREE_PUBLIC on namespaces. (leave_scope): Pop visibility if appropriate. * cp/parser.c (cp_parser_declaration, cp_parser_namespace_name): Allow attributes on namespace declarations. PR c++/19238 * cp/decl.c (cp_finish_decl): Call determine_visibility later. (start_preparsed_function): Likewise. * cp/cp-tree.h (CP_TYPE_CONTEXT, TYPE_NAMESPACE_SCOPE_P): New macros. (TYPE_CLASS_SCOPE_P, TYPE_FUNCTION_SCOPE_P): New macros. * cp/decl2.c (determine_visibility_from_class): Split out from... (determine_visibility): ...here. Handle function scope and nested classes. (import_export_decl): Move visibility handling to determine_visibility_from_class. Added: trunk/gcc/testsuite/g++.dg/ext/visibility/local1.C trunk/gcc/testsuite/g++.dg/ext/visibility/namespace1.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-pragma.c trunk/gcc/c-pragma.h trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/decl2.c trunk/gcc/cp/name-lookup.c trunk/gcc/cp/name-lookup.h trunk/gcc/cp/parser.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21764
[Bug c++/22063] link failure involving symbol visibility
--- Comment #4 from jason at gcc dot gnu dot org 2006-03-21 03:24 --- I believe that 'hidden' references must bind to a definition in the current .so, so this is not a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22063
[Bug c++/17470] Visibility attribute ignored for explicit template instantiation
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-12-28 20:19:16 |2006-03-21 03:29:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17470
[Bug c++/21243] typeinfo visibility of template class instantiation can not be changed with attribute
--- Comment #2 from jason at gcc dot gnu dot org 2006-03-21 04:03 --- Probably the same bug as 17470. -- jason at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||17470 AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-12-28 19:37:16 |2006-03-21 04:03:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21243
[Bug c/26774] New: Out of memory compiling 9-line Delta-reduced Linux kernel driver msp3400.c
The attached 9-line file causes a checking=all build of GCC 4.1.0 to exhaust memory, on both Ubuntu Linux 5.04/2.6.10-6-386 and Mac OSX 10.4.5. It's a Delta-reduced version of a preprocessed version of the Linux Kernel file drivers/media/video/msp3400.c, which exhibited the same behavior. The original compilation was being done by a test script outside the kernel tree, so the compilation encountered errors; the preprocessed file is invalid C, as is the Delta-reduced version. My checking=all builds of GCC 4.0.1 (patched) and 4.02 each give a segmentation fault. GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2) gives up cleanly: confused by earlier errors, bailing out. On the non-reduced preprocessed file, with my patched checking build of 4.0.1, I instead get the following, which seems like PR22028, which is presumably fixed: internal compiler error: tree check: expected class type, have exceptional (error_mark) in gimplify_type_sizes, at gimplify.c:4368 Here's the session; I'll attached the preprocessed file and the Delta-reduction. I used ulimit on Ubuntu to save time; fully exhausting memory on OSX (where ulimit doesn't seem to work) with the unreduced file took half an hour, but memory use gets above 50MB fairly quickly. 3 ulimit -m 5 -v 5 [EMAIL PROTECTED] scripts 20:11:53 4 /opt/gcc410-chk-all/bin/gcc -v ../cpp/bugfiles/GCC_bugfiles/error/122285_msp3400_min.i Using built-in specs. Target: i686-pc-linux-gnu Configured with: /opt/Gcc-4.1.0-dist/configure --enable-checking=all --prefix=/opt/gcc410-chk-all --enable-languages=c,c++ --with-comment=PalmSource checking=all build by Flash Sheridan 3/17/06 Thread model: posix gcc version 4.1.0 /home/opt/gcc410-chk-all/bin/../libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1 -fpreprocessed ../cpp/bugfiles/GCC_bugfiles/error/122285_msp3400_min.i -quiet -dumpbase 122285_msp3400_min.i -mtune=pentiumpro -auxbase 122285_msp3400_min -version -o /tmp/ccV7UEre.s GNU C version 4.1.0 (i686-pc-linux-gnu) compiled by GNU C version 3.3.5 (Debian 1:3.3.5-8ubuntu2). GGC heuristics: --param ggc-min-expand=0 --param ggc-min-heapsize=0 Compiler executable checksum: a68040354320563d9f0f04c1edf3c815 ../cpp/bugfiles/GCC_bugfiles/error/122285_msp3400_min.i:3: warning: struct i2c_client declared inside parameter list ../cpp/bugfiles/GCC_bugfiles/error/122285_msp3400_min.i:3: warning: its scope is only this definition or declaration, which is probably not what you want ../cpp/bugfiles/GCC_bugfiles/error/122285_msp3400_min.i:4: error: field driver has incomplete type ../cpp/bugfiles/GCC_bugfiles/error/122285_msp3400_min.i:6: error: two or more data types in declaration specifiers ../cpp/bugfiles/GCC_bugfiles/error/122285_msp3400_min.i:6: warning: struct i2c_client declared inside parameter list ../cpp/bugfiles/GCC_bugfiles/error/122285_msp3400_min.i:8: warning: initialization from incompatible pointer type virtual memory exhausted: Cannot allocate memory [EMAIL PROTECTED] scripts 20:14:31 --- PalmSource bug #122285 http://pobox.com/~flash Quality Lead for Compilers and Debuggers PalmSource, Inc. Tools Quality Management -- Summary: Out of memory compiling 9-line Delta-reduced Linux kernel driver msp3400.c Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: flash at pobox dot com GCC host triplet: i686-pc-linux-gnu, powerpc-apple-darwin8.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26774
[Bug c/26774] Out of memory compiling 9-line Delta-reduced Linux kernel driver msp3400.c
--- Comment #1 from flash at pobox dot com 2006-03-21 04:22 --- Created an attachment (id=11075) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11075action=view) Delta-reduced version -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26774
[Bug c/26774] Out of memory compiling 9-line Delta-reduced Linux kernel driver msp3400.c
--- Comment #2 from flash at pobox dot com 2006-03-21 04:23 --- Created an attachment (id=11076) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11076action=view) Unreduced preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26774
[Bug tree-optimization/21829] [4.1/4.2 Regression] missed jump threading after unroller
--- Comment #6 from law at redhat dot com 2006-03-21 05:09 --- Subject: Re: [4.1/4.2 Regression] missed jump threading after unroller On Sat, 2006-02-11 at 00:59 +, pinskia at gcc dot gnu dot org wrote: --- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-11 00:59 --- The problem with this one after Jeff's recent patches is that we have: L13:; D.1402_17 = 0; if (D.1402_17 == 1) goto L15; else goto L14; L15:; x_18 = 1; # x_19 = PHI 0(2), 0(3), x_18(4); L14:; Which causes us not to be able to the jump threading as we do a CCP in VRP and then we get: bb 2: if (v_8 0) goto L13; else goto L14; L13:; D.1402_17 = 0; goto bb 8 (L18); # x_19 = PHI 0(2); L14:; u_20 = 1; ivtmp.26_21 = 1; ivtmp.26_3 = 1; u_14 = 1; x_13 = 0; if (v_8 = 0) goto L1; else goto L3; So we need to be able to do some CCP and some DCE before invoking VRP. As I mentioned earlier, the problem is inherent with non-iterating dominator optimizations -- namely that we can't guarantee that for block BB that we will visit all of BB's predecessors before visiting BB when BB is at a dominance frontier. The net result is that we may still be propagating values into a PHI node for a block which has already been visited. Those propagations may result in the PHI turning into a degenerate too late for the dominator optimizer to discover the degenerate PHI and record the appropriate equivalence for the LHS of the degenerate PHI. I had added support for a stripped down copy-prop to run after DOM to pick up these kind of optimization opportunities rooted at degenerate PHI nodes that were trivial copies. (previously we had been running the full-blown copy-prop pass). However, that code does not catch this case because our PHI looks like x_2 = PHI (0 (BB1), 0 (BB2)) ie, it's a constant initialization, not a PHI-copy. I had played with running a similarly stripped down CCP after DOM, but that's really expensive compile-time wise. I then experimented with speeding up the propagation engine. While I may have found a couple of micro-opts, I wasn't able to find anything which was going to give us a big enough improvement to make running a phi-only CCP a viable option from a compile-time standpoint. I then proceeded to implement a concept that had been floating around in the back of my mind. Namely a specialized PHI const/copy optimizer which used a dominator walk plus a worklist of statements/phis to revisit after the DOM walk (which allows us to detect secondary effects). It turns out this specialized PHI optimization pass is as effective as running copy-prop and CCP on PHI nodes after DOM. Better yet, it is a teeny tiny slowdown compared to just running the stripped down copyprop. ie, for an almost unmeasurable slowdown we can do both constant and copy propagation instead of just copy propagation. Net result is in this PR we're able to clean up the extraneous modulo operation and propagate its result as well. Note that the resulting code could be simplified even more, namely iterating VRP could allow simplification of a relational into an equality test. That's simply not going to happen. We'll have to live with less than 100% optimized code. Bootstrapped and regression tested on i686-pc-linux-gnu. --- Comment #7 from law at redhat dot com 2006-03-21 05:09 --- Created an attachment (id=11077) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11077action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21829
[Bug tree-optimization/21829] [4.1/4.2 Regression] missed jump threading after unroller
--- Comment #8 from law at redhat dot com 2006-03-21 05:10 --- Today's patch picks up the missed const-propagation and allows simplification of the modulo operation. THere's still the opportunitity to use range information to simplify a conditional. However, fixing that is just basically iterating VRP in response to CFG changes -- not something we're going to do as it's simply too expensive. Thus I'm changing the state of this bug to WONTFIX. -- law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21829
[Bug target/26607] [4.1/4.2 Regression] Illegal inlined assembler on config/rs6000/darwin-ldouble.c
-- amodra at bigpond dot net dot au changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-21 05:14:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26607
[Bug fortran/26766] [F2003] Recursive I/O still (again) broken
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-03-21 06:05
---
Looking at -fdump-tree-original, should the internal unit descriptors in foo
and in main have the same value?
foo (__result, .__result, i)
{
if (*i 0)
{
_gfortran_copy_string (4, __result, 4, 1234);
}
else
{
{
struct __st_parameter_dt dt_parm.0;
dt_parm.0.common.filename = pr26766.f90;
dt_parm.0.common.line = 15;
dt_parm.0.internal_unit = (char *) __result;
dt_parm.0.internal_unit_len = 4;
dt_parm.0.internal_unit_desc = 0B;-- here ---
dt_parm.0.common.unit = 0;
dt_parm.0.format = (i4.4);
dt_parm.0.format_len = 6;
dt_parm.0.common.flags = 20480;
_gfortran_st_write (dt_parm.0);
_gfortran_transfer_integer (dt_parm.0, (int4 *) i, 4);
_gfortran_st_write_done (dt_parm.0);
}
}
MAIN__ ()
{
char str[1:4];
static void foo (char[1:4] , int4, int4 );
_gfortran_set_std (70, 127, 0);
{
struct __st_parameter_dt dt_parm.1;
dt_parm.1.common.filename = pr26766.f90;
dt_parm.1.common.line = 4;
dt_parm.1.internal_unit = str;
dt_parm.1.internal_unit_len = 4;
dt_parm.1.internal_unit_desc = 0B; -- and Here ---
dt_parm.1.common.unit = 0;
dt_parm.1.format = (a);
dt_parm.1.format_len = 3;
dt_parm.1.common.flags = 20480;
_gfortran_st_write (dt_parm.1);
{
char str.2[4];
int4 C.906 = 1234;
foo ((char[1:4] *) str.2, 4, C.906);
_gfortran_transfer_character (dt_parm.1, (char[1:4] *) str.2, 4);
}
_gfortran_st_write_done (dt_parm.1);
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26766
[Bug c/26775] New: a stack pointer is not recovered correctly when using alloca.
When an alloca() is used with large auto variable area, a stack pointer is not recovered correctly. -- Summary: a stack pointer is not recovered correctly when using alloca. Product: gcc Version: 3.4.6 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: inaoka dot kazuhiro at renesas dot com GCC target triplet: m32r http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26775
[Bug c/26775] a stack pointer is not recovered correctly when using alloca.
--- Comment #1 from inaoka dot kazuhiro at renesas dot com 2006-03-21 07:51 --- Created an attachment (id=11078) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11078action=view) testcase m32r-linux-gnu-gcc -S alloca.c Asm output has the following code. ; EPILOGUE ld24 r4,#32768 add sp,r4 == NG (a stack pointer must be recovered with fp.) pop fp jmp lr -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26775
[Bug c/26775] a stack pointer is not recovered correctly when using alloca.
--- Comment #2 from inaoka dot kazuhiro at renesas dot com 2006-03-21 07:52 --- Created an attachment (id=11079) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11079action=view) ng output NG case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26775
[Bug target/26776] New: A stack frame can't be recovered when using large auto variable area.
A stack frame can't be recovered when using large auto variable area. /tmp/ccJXOHSj.s: Assembler messages: /tmp/ccJXOHSj.s:68: Error: bad instruction `ld24 r4,#16777216' /tmp/ccJXOHSj.s:83: Error: bad instruction `ld24 r4,#16777216' /tmp/ccJXOHSj.s:278: Error: bad instruction `ld24 r4,#16777216' /tmp/ccJXOHSj.s:305: Error: bad instruction `ld24 r4,#16777216' -- Summary: A stack frame can't be recovered when using large auto variable area. Product: gcc Version: 3.4.6 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: inaoka dot kazuhiro at renesas dot com GCC target triplet: m32r http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26776
[Bug target/26776] A stack frame can't be recovered when using large auto variable area.
--- Comment #1 from inaoka dot kazuhiro at renesas dot com 2006-03-21 07:58 --- Created an attachment (id=11080) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11080action=view) testcase m32r-linux-gnu-gcc -c large.c /tmp/ccJXOHSj.s: Assembler messages: /tmp/ccJXOHSj.s:68: Error: bad instruction `ld24 r4,#16777216' /tmp/ccJXOHSj.s:83: Error: bad instruction `ld24 r4,#16777216' /tmp/ccJXOHSj.s:278: Error: bad instruction `ld24 r4,#16777216' /tmp/ccJXOHSj.s:305: Error: bad instruction `ld24 r4,#16777216' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26776
