[Bug middle-end/27080] gcc should emit .type directives for used undeclared extern variables and functions

--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-08 04:06 --- I should note people do tricks and one of them would cause an error being emitting, maybe it should maybe not. But even emitting used ones can go up in the .s file size causing more compile time issues. -- pinsk

[Bug middle-end/27080] gcc should emit .type directives for used extern variables and functions

--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-08 04:05 --- If we do it for all extern functions and variables, it would be about 1000 .types which are not useful. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug middle-end/27080] New: gcc should emit .type directives for extern variables and functions

It doesn't right now, but in a perfect world ld could complain if one object referred to a symbol of type object while another referred to the same symbol of type function. Of course, in order for ld to do this, gcc would have to actually emit .type directives for extern variables and functions. I

[Bug libstdc++/27079] Memory leak in std::string?..

--- Comment #4 from sakovacs at freemail dot hu 2006-04-08 02:58 --- sorry, please disregard my last post, submitted too early... Thanks for the very fast reply. I agree, that such a leakage would be very unlikely. It must be something else, but I don't understand what, I've modified th

[Bug tree-optimization/19590] IVs with the same evolution not eliminated

--- Comment #9 from dberlin at gcc dot gnu dot org 2006-04-08 02:53 --- Actually, it's not really expensive at all. It's certainly not N^2. The new SCC value numberer for PRE i'm working on gets this case right (and this is in fact, one of the advantages of SCC based value numbering). Y

[Bug libstdc++/27079] Memory leak in std::string?..

--- Comment #3 from sakovacs at freemail dot hu 2006-04-08 02:53 --- Thanks for the very fast reply. I agree, that such a leakage would be very unlikely. It must be something else, but I don't understand what, I've modified the code: #include #include int max = 100; void bad() {

[Bug tree-optimization/23094] store ccp, or store copy prop misses an optimization

--- Comment #8 from pinskia at gcc dot gnu dot org 2006-04-08 02:32 --- Store copy prop has the same issue, testcase: void foo (int *p, int *q, int t) { *p = t; *q = t; if (*p != 1) link_error (); } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23094

[Bug tree-optimization/19590] IVs with the same evolution not eliminated

--- Comment #8 from pinskia at gcc dot gnu dot org 2006-04-08 02:26 --- Comparing the IVs themselves take no time, now figuring out which one are equal to which set could take some time, at max O(n^2) time. Now n is going to be small for most cases anyways. -- pinskia at gcc dot gnu

[Bug target/16798] PowerPC - Opportunity to use recording form instruction.

--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-08 02:20 --- I should note that there are some PPC cores where most recording are microcoded. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug libstdc++/27079] Memory leak in std::string?..

--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-08 02:16 --- Also it might be glibc holding on to the memory for a little bit before releasing it back to the kernel. Anyways use a real leak finder and what is said in the FAQ and you should find that libstdc++ does not leak.

[Bug libstdc++/27079] Memory leak in std::string?..

--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-08 02:14 --- Please read: http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html#4_4_leak -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27079

[Bug libstdc++/27079] New: Memory leak in std::string?..

Am I doing something wrong here? Or is it really a memory leak in STL?... #include #include int max = 400; void bad() { std::vector v; for (int x = 0; x < max; x++) { v.push_back(new std::string("test")); } for (uint x = 0; x < max; x++) { delete v.at(x);

[Bug c++/27078] [4.1/4.2 Regression] Duplicate error message for ambiguous enum

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27078

[Bug c++/27078] [4.1/4.2 Regression] Duplicate error message for ambiguous enum

--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-08 02:03 --- I take the back it is a regression from 4.1.0, it fails there too but it does not produce the duplicated error message in 4.0.3 though. -- pinskia at gcc dot gnu dot org changed: What|Removed

[Bug c++/27078] [4.2 Regression] Duplicate error message for ambiguous enum

--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-08 02:02 --- Confirmed, a regression from 4.0.2 and 4.1.0 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug c++/27078] New: Duplicate error message for ambiguous enum

This C++ file: enum E1 { V }; namespace { enum E2 { V }; } int foo() { return static_cast(V); } when compiled with current mainline produces a doubled error message: foo.cc: In function ‘int foo()’: foo.cc:3: error: reference to ‘V’ is ambiguous foo.cc:1: error: candidates are: E1 V foo.cc:2: er

[Bug middle-end/14840] fold tree_code_type[CST] and tree_code_length[CST] in GCC itself

--- Comment #9 from pinskia at gcc dot gnu dot org 2006-04-08 01:46 --- This is not a missed optimization, just a compile time fix really. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added --

[Bug tree-optimization/24333] missed div optimizations

--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-08 01:41 --- x/x is done for fp now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24333

[Bug target/23983] the altivec builtins should be marked as pure/const

--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-08 01:29 --- I am going to look into this some more since well PPC/Cell/PS3 is my thing now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug ada/27068] complilation abandoned on NML Ada test server

--- Comment #2 from wshackle at yahoo dot com 2006-04-08 00:19 --- Subject: Re: complilation abandoned on NML Ada test server The compile that failed occured in rcslib/src/test which which references files in rcslib/src/ada -- Will --- pinskia at gcc dot gnu dot org <[EMAIL PROTECT

[Bug libfortran/26890] SIZE parameter interacts with same variable in IO list character length specification.

--- Comment #12 from jvdelisle at gcc dot gnu dot org 2006-04-07 23:05 --- Subject: Bug 26890 Author: jvdelisle Date: Fri Apr 7 23:05:12 2006 New Revision: 112769 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112769 Log: 2006-04-07 Jerry DeLisle <[EMAIL PROTECTED]>

[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64

--- Comment #17 from wilson at gcc dot gnu dot org 2006-04-07 23:04 --- Subject: Bug 26483 Author: wilson Date: Fri Apr 7 23:04:15 2006 New Revision: 112768 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112768 Log: For PR 26483, IA-64 denorm failure due to unwanted rounding. *

[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64

--- Comment #16 from wilson at tuliptree dot org 2006-04-07 23:00 --- Subject: Re: Wrong parsing of doubles when interpreted on ia64 On Tue, 2006-04-04 at 13:46, andreast at gcc dot gnu dot org wrote: > --- Comment #15 from andreast at gcc dot gnu dot org 2006-04-04 20:46

[Bug libfortran/26890] SIZE parameter interacts with same variable in IO list character length specification.

--- Comment #11 from sje at cup dot hp dot com 2006-04-07 22:36 --- I think putting pad back to where it was is a good first step and I will see if there is room on a 64 bit machine, I think we need some kind of test to make sure that pad is always equal to or greater than the size of st

[Bug libfortran/26890] SIZE parameter interacts with same variable in IO list character length specification.

--- Comment #10 from jvdelisle at gcc dot gnu dot org 2006-04-07 22:23 --- I put some prints at the top of get_unit in unit.c to take a look. After putting the padding back where it was originally in io.h: The DTP Size of p: 132 Size of pad: 200 Size of char *: 4 Size if int: 4 This

[Bug fortran/19101] missing & in character continuation not caught

--- Comment #14 from jvdelisle at gcc dot gnu dot org 2006-04-07 21:20 --- Fixed now on 4.1.1 and 4.2 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/19101] missing & in character continuation not caught

--- Comment #13 from jvdelisle at gcc dot gnu dot org 2006-04-07 21:12 --- Subject: Bug 19101 Author: jvdelisle Date: Fri Apr 7 21:12:41 2006 New Revision: 112764 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112764 Log: 2006-04-07 Jerry DeLisle <[EMAIL PROTECTED]>

[Bug fortran/19101] missing & in character continuation not caught

--- Comment #12 from jvdelisle at gcc dot gnu dot org 2006-04-07 21:07 --- Subject: Bug 19101 Author: jvdelisle Date: Fri Apr 7 21:07:52 2006 New Revision: 112763 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112763 Log: 2006-04-07 Jerry DeLisle <[EMAIL PROTECTED]>

[Bug target/27077] [x86, 4.1] builtin strlen poor performance

--- Comment #2 from rdabrowa at poczta dot onet dot pl 2006-04-07 20:07 --- Execution times (in seconds) for different lengths: stringfrom lengthbuiltin library -- 0 0.480.07 5 0.570.11 100.65

[Bug libfortran/26890] SIZE parameter interacts with same variable in IO list character length specification.

--- Comment #9 from jvdelisle at gcc dot gnu dot org 2006-04-07 19:17 --- st_parameter_dt are declared by the front end which then passes to the library functions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26890

[Bug target/27077] [x86, 4.1] builtin strlen poor performance

--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-07 19:12 --- Your benchmark only deals with one sized strings, you should try with multiple different sized strings like include one which is zero lengthed, one which is 2k-2M in length and try bechmarking that. You might get a

[Bug c/27077] New: [x86, 4.1] builtin strlen poor performance

Code below, when compiled with -fno-builtin option works 5 times faster: #include #include int main(int argc, char *argv[]) { char s[20] = ""; int i, len; memset(s, 'a', sizeof(s)-1); for(i = 0; i < 1000; ++i) len = strlen(s);

[Bug libfortran/26890] SIZE parameter interacts with same variable in IO list character length specification.

--- Comment #8 from sje at cup dot hp dot com 2006-04-07 18:55 --- I am not sure why it was created the way it was or why it doesn't just use sizeof(p). I haven't looked back into SVN/email to see if there are any comments on why it was done the way it was done. Do you know where struc

[Bug libfortran/26890] SIZE parameter interacts with same variable in IO list character length specification.

--- Comment #7 from jvdelisle at gcc dot gnu dot org 2006-04-07 18:50 --- Another thought. If comment #5 about size of p is true, why not set pad to sizeof(p)? Why was it so oddly constructed in the first place? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26890

[Bug libfortran/26890] SIZE parameter interacts with same variable in IO list character length specification.

--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-04-07 18:42 --- We posted a question about that on the list. Not knowing the purpose of pad, I took a guess. Let me know what you learn. Appreciate your testing this and reporting. -- http://gcc.gnu.org/bugzilla/show_bug.

[Bug bootstrap/27074] Bootstrap fails on i686-pc-linux-gnu

--- Comment #2 from amylaar at gcc dot gnu dot org 2006-04-07 18:07 --- (In reply to comment #1) > File this first with gdb as it is gdb's sources which are have the warning in > it, if they say the warning is bogus, file a real bug report with the > preprocessed source. When you look

[Bug target/27076] During installation of gcc-3.4.0 compiler getting an error "make[1]: *** [getpwd.o] Error 1"

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27076

[Bug target/27076] During installation of gcc-3.4.0 compiler getting an error "make[1]: *** [getpwd.o] Error 1"

--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-07 17:15 --- ../../gcc-3.4.0/libiberty/getpwd.c:74: storage size of `dotstat' isn't known ../../gcc-3.4.0/libiberty/getpwd.c:74: storage size of `pwdstat' isn't known Why are you trying to compile 3.4.0, when there is 3.4.6 to

[Bug libfortran/26890] SIZE parameter interacts with same variable in IO list character length specification.

--- Comment #5 from sje at cup dot hp dot com 2006-04-07 17:02 --- I believe this patch is causing a bunch of IO failures on ia64-hp-hpux11.23. Specifically, the setting of "pad" looks bad to me. pad, in this case, is not a padding on the end of the structure but a parallel array of ch

[Bug classpath/20247] Lack java.util.concurrent.LinkedBlockingQueue

--- Comment #7 from tromey at gcc dot gnu dot org 2006-04-07 16:50 --- Yes, we can use most of these sources, just not all of them. I have a patch here which does it. And we already have stubbed declarations for most of the needed VM support. To finish we need: 1. A script which takes

[Bug c/27076] New: During installation of gcc-3.4.0 compiler getting an error "make[1]: *** [getpwd.o] Error 1"

Hi, I am trying to install gcc compiler 3.4.0 on Red Hat Advance Server 2.1. Current gcc version is 3.2.2-5 which is seems to bugy as I have tried to compile and install some other packages and was getting error messages which denoting that it is a problem with bugy gcc compiler version which had

[Bug target/27075] [4.1 Regression] Compiler generate incorrect assembler for __sync_fetch-* builtins on e500 aka SPE

--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-07 16:00 --- g, well this is why reusing the operand is not a good idea anyways this is a regression from when the builtins came in which was 4.1.0. Well confirmed, a simple testcase is: int f(int *a, int b) { return __sy

[Bug target/27075] Compiler generate incorrect assembler

--- Comment #6 from edmar at freescale dot com 2006-04-07 15:54 --- The problem is how %y is defined in rs6000.c (print_operand) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27075

[Bug target/27075] Compiler generate incorrect assembler

--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-07 15:52 --- But I don't see anything obviously wrong in sync.md, like missing a y (aka %y1 or %y0 is used correctly). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27075

[Bug target/27075] Compiler generate incorrect assembler

--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-07 15:48 --- hmm: lwarx 9,0(3) That is definitely wrong. It should have been "lwarx 9, 0, 3". (This is a real compiler issue). -- pinskia at gcc dot gnu dot org changed: What|Removed

[Bug target/27075] Compiler generate incorrect assembler

--- Comment #3 from edmar at freescale dot com 2006-04-07 15:45 --- Created an attachment (id=11222) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11222&action=view) Aseembler file generated by the compiler Assembler file generated by the compiler -- http://gcc.gnu.org/bugzil

[Bug target/27075] Compiler generate incorrect assembler

--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-07 15:33 --- Can you attach the atomicity.s also? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27075

[Bug c/27075] Compiler generate incorrect assembler

--- Comment #1 from edmar at freescale dot com 2006-04-07 15:32 --- Created an attachment (id=11221) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11221&action=view) Intermediate file of the failing code Intermediate file that generates the wrong syntax assembler. -- http://g

[Bug c/27075] New: Compiler generate incorrect assembler

I get an assembler error, when trying to build gcc for the gnuspe target. I am using binutils-2.16.1. I don't know when this problem started because this particular target had other failure that was fixed last week. /local/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/./gcc/cc1plus -E -quiet -no

[Bug bootstrap/27074] Bootstrap fails on i686-pc-linux-gnu

--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-07 15:11 --- File this first with gdb as it is gdb's sources which are have the warning in it, if they say the warning is bogus, file a real bug report with the preprocessed source. -- pinskia at gcc dot gnu dot org changed:

internal compiler error: Segmentation fault: 11

cc -O -pipe -funroll-loops -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/usr/src/tmp/usr\" -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1plus/../..

[Bug tree-optimization/23855] loop header should also be pulled out of the inner loop too

--- Comment #14 from rakdver at gcc dot gnu dot org 2006-04-07 13:20 --- (In reply to comment #11) > I updated the patch for current mainline, but it still has issues for some > common uses of loops: > > void foo(int *ie, int *je, double *x) > { > int i, j; > for (j=0; j<*je; ++j)

[Bug tree-optimization/23855] loop header should also be pulled out of the inner loop too

--- Comment #13 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2006-04-07 12:57 --- Subject: Re: loop header should also be pulled out of the inner loop too > I updated the patch for current mainline, but it still has issues for some > common uses of loops: > > void foo(int

[Bug bootstrap/27074] New: Bootstrap fails on i686-pc-linux-gnu

See http://gcc.gnu.org/ml/gcc/2006-04/msg00055.html -- Summary: Bootstrap fails on i686-pc-linux-gnu Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: bootstrap AssignedTo:

[Bug rtl-optimization/27073] invalid gcse manipulation of REG_EQUIV notes

-- rsandifo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot |dot org

[Bug rtl-optimization/27073] New: invalid gcse manipulation of REG_EQUIV notes

arm-eabi-gcc -Os -mthumb produces wrong code for the following testcase: void __attribute__((noinline)) foo (int *p, int d1, int d2, int d3, short count, int s1, int s2, int s3, int s4, int s5) { int n = count; while (n--) { *p++ = s1;

[Bug tree-optimization/15911] VRP/DOM does not like TRUTH_AND_EXPR

--- Comment #19 from rguenth at gcc dot gnu dot org 2006-04-07 12:23 --- Jeff, can you send me the patch-in-progress you have for this? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15911

[Bug tree-optimization/23855] loop header should also be pulled out of the inner loop too

--- Comment #12 from rguenth at gcc dot gnu dot org 2006-04-07 12:01 --- So what I now have is (ahh, a PROP_loops would be so nice...) pass_ch pass_split_crit_edges pass_pre [cfg_cleanup to re-merge critical edges] pass_hoist_guards which works nice for this scenario, still

[Bug tree-optimization/23855] loop header should also be pulled out of the inner loop too

--- Comment #11 from rguenth at gcc dot gnu dot org 2006-04-07 11:34 --- I updated the patch for current mainline, but it still has issues for some common uses of loops: void foo(int *ie, int *je, double *x) { int i, j; for (j=0; j<*je; ++j) for (i=0; i<*ie; ++i) x[i+j] =

[Bug classpath/20247] Lack java.util.concurrent.LinkedBlockingQueue

--- Comment #6 from roman at kennke dot org 2006-04-07 11:11 --- whoops sorry, I missed the first couple of lines, which hopefully means that most of the code is indeed public domain: The software comprising JSR166 was written by Doug Lea with assistance from members of JCP JSR-166 Expe

[Bug classpath/20247] Lack java.util.concurrent.LinkedBlockingQueue

--- Comment #5 from roman at kennke dot org 2006-04-07 11:08 --- This is not really public domain: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/readme?rev=1.1&content-type=text/vnd.viewcvs-markup This code is covered by the nearly-but-not-exactly-free nuclear-bsd licens

[Bug classpath/24481] SecureRandom.setSeed has no impact

--- Comment #4 from david at jpackage dot org 2006-04-07 11:06 --- I experienced a similar problem. I created a new SecureRandom with SecureRandom sr = new SecureRandom(); Then, multiple calls to sr.nextBytes() produced the same bytes each time. -- http://gcc.gnu.org/bugzilla/s

[Bug classpath/20247] Lack java.util.concurrent.LinkedBlockingQueue

--- Comment #4 from david at jpackage dot org 2006-04-07 10:56 --- FYI, the JSR 166 Concurrency Utilities sources are in the public domain. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20247

[Bug fortran/25746] Elemental assignment gives wrong result

--- Comment #4 from paul dot richard dot thomas at cea dot fr 2006-04-07 10:16 --- > Patch to fix elemental subroutine dependences. This is still a little bit ragged insofar as it produces and excess of temporaries and that it still gets one case wrong: x(1:2) = x(2:3) is broken. Howev

[Bug fortran/25746] Elemental assignment gives wrong result

--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-04-07 10:13 --- Created an attachment (id=11220) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11220&action=view) Patch to fix elemental subroutine dependences. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2

[Bug tree-optimization/26919] [4.1 regression] ICE in cgraph_estimate_size_after_inlining with a large number of arguments

--- Comment #15 from rguenth at gcc dot gnu dot org 2006-04-07 08:13 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNE

[Bug tree-optimization/26919] [4.1 regression] ICE in cgraph_estimate_size_after_inlining with a large number of arguments

--- Comment #14 from rguenth at gcc dot gnu dot org 2006-04-07 08:12 --- Subject: Bug 26919 Author: rguenth Date: Fri Apr 7 08:12:41 2006 New Revision: 112750 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112750 Log: 2006-04-07 Richard Guenther <[EMAIL PROTECTED]>

[Bug tree-optimization/26135] store copyprop not effective

--- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-07 08:05 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug tree-optimization/26135] store copyprop not effective

--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-07 08:04 --- Subject: Bug 26135 Author: rguenth Date: Fri Apr 7 08:04:26 2006 New Revision: 112749 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112749 Log: 2006-04-07 Richard Guenther <[EMAIL PROTECTED]> PR