[Bug target/27827] [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #59 from paolo dot bonzini at lu dot unisi dot ch 2006-08-10 06:52 --- Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3 > Thanks for the response, but I believe you are conflating two issues (as is > this flag, which is why this is bad news). Different answers to the question > "what is this sum" does not ruin IEEE compliance. I am referring to IEEE 754, > which is a standard set of rules for storage and arithmetic for floating point > (fp) on modern hardware. You are also confusing -funsafe-math-optimizations with -ffast-math. The latter is a "one catch all" flag that compiles as if there were no FP traps, infinities, NaNs, and so on. The former instead enables "unsafe" optimizations but not "catastrophic" optimizations -- if you consider meaningless results on badly conditioned matrixes to not be catastrophic... A more or less complete list of things enabled by -funsafe-math-optimizations includes: Reassociation: - reassociation of operations, not only for the vectorizer's sake but also in the unroller (see around line 1600 of loop-unroll.c) - other simplifications like a/(b*c) for a/b/c - expansion of pow (a, b) to multiplications if b is integer Compile-time evaluation: - doing more aggressive compile-time evaluation of floating-point expressions (e.g. cabs) - less accurate modeling of overflow in compile-time expressions, for formats such as 106-bit mantissa long doubles Math identities: - expansion of cabs to sqrt (a*a + b*b) - simplifications involving trascendental functions, e.g. exp (0.5*x) for sqrt (exp (x)), or x for tan(atan(x)) - moving terms to the other side of a comparison, e.g. a > 4 for a + 4 > 8, or x > -1 for 1 - x < 2 - assuming in-domain arguments of sqrt, log, etc., e.g. x for sqrt(x)*sqrt(x) - in turn, this enables removing math functions from comparisons, e.g. x > 4 for sqrt (x) > 2 Optimization: - strength reduction of a/b to a*(1/b), both as loop invariants and in code like vector normalization - eliminating recursion for "accumulator"-like functions, i.e. f (n) = n + f(n-1) Back-end operation: - using x87 builtins for transcendental functions There may be bugs, but in general these optimizations are safe for infinities and NaNs, but not for signed zeros or (as I said) for very badly conditioned data. > I am unaware of their being any rules on compilation. > Rules are determined by the language standards. I believe that C mandates no reassociation; Fortran allows reassociation unless explicit parentheses are present in the source, but this is not (yet) implemented by GCC. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug tree-optimization/17687] sincos can be folded at the tree level
--- Comment #7 from bonzini at gnu dot org 2006-08-10 06:28 --- Was this implemented? There is an expand_builtin_sincos, but I think it cannot remove TREE_ADDRESSABLE on the arguments, making most of the performance advantages go away... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17687
[Bug target/28672] [4.2 Regression]: Gcc went into infinite loop when building libstdc++
--- Comment #3 from hjl at lucon dot org 2006-08-10 06:22 --- This patch http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00238.html causes the gcc to hang. Gdb backtrace looks like (gdb) bt #0 htab_find_slot_with_hash (htab=0x602cce30, element=0x25417b20, hash=30308, insert=NO_INSERT) at /net/gnu-13/export/gnu/src/gcc-next/gcc/libiberty/hashtab.c:635 #1 0x408f8310 in delete_variable_part (set=0x6053c630, loc=0x25779b80, decl=0x25417b20, offset=0) at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/var-tracking.c:2232 #2 0x408f8b80 in var_regno_delete (set=0x6053c630, regno=) at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/var-tracking.c:916 #3 0x408fb1c0 in vt_find_locations () at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/var-tracking.c:1729 #4 0x408fc210 in variable_tracking_main () at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/var-tracking.c:2951 #5 0x40788b80 in ia64_reorg () at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/config/ia64/ia64.c:8549 #6 0x4090e330 in rest_of_handle_machine_reorg () at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/reorg.c:3816 #7 0x4071b830 in execute_one_pass (pass=0x60008d88) at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/passes.c:864 #8 0x4071bbb0 in execute_pass_list (pass=0x60008d88) at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/passes.c:911 #9 0x4071bc00 in execute_pass_list (pass=0x600076c0) at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/passes.c:912 ---Type to continue, or q to quit--- #10 0x4071bc00 in execute_pass_list (pass=0x60007678) at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/passes.c:912 #11 0x4022e960 in tree_rest_of_compilation (fndecl=0x24e7ddc0) at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/tree-optimize.c:418 #12 0x401342a0 in expand_body (fn=0x24e7ddc0) at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/cp/semantics.c:3072 #13 0x40794a30 in cgraph_expand_function (node=0x24f23e90) at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/cgraphunit.c:1194 #14 0x407967f0 in cgraph_optimize () at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/cgraphunit.c:1259 #15 0x400ac070 in cp_finish_file () at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/cp/decl2.c:3341 #16 0x400038a0 in finish_file () at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/cp/cp-lang.c:144 #17 0x401e8e00 in c_common_parse_file ( set_yydebug=) at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/c-opts.c:1165 #18 0x406c6240 in toplev_main (argc=, argv=) at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/toplev.c:999 #19 0x40202c40 in main (argc=17, argv=0x6fffb5a8) at /net/gnu-13/export/gnu/src/gcc-next/gcc/gcc/main.c:35 (gdb) -- hjl at lucon dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-10 06:22:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28672
[Bug target/28672] [4.2 Regression]: Gcc went into infinite loop when building libstdc++
--- Comment #2 from hjl at lucon dot org 2006-08-10 06:16 --- Created an attachment (id=12050) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12050&action=view) A tescase This is the best I can get so far. Gcc hangs with -O2 -g. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28672
[Bug fortran/28496] Error during array initialization
--- Comment #3 from pault at gcc dot gnu dot org 2006-08-10 04:56 --- I can see what the problem is - when I wrote this section of code in expr.c, I did the conditions for "step" and "finish" correctly but for "begin", I wrote: /* Obtain the start value for the index. */ if (begin->value.integer) mpz_set (ctr[d], begin->value.integer); else instead of /* Obtain the start value for the index. */ if (begin) mpz_set (ctr[d], begin->value.integer); else This you can demonstrate by changing a(:) to a(1:) I'll try to get a patch out of the door today and to commit it under the obvious rule. Thanks Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-07-26 19:52:36 |2006-08-10 04:56:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28496
[Bug fortran/25828] [f2003] ACCESS='STREAM' io support
--- Comment #5 from patchapp at dberlin dot org 2006-08-10 04:35 --- Subject: Bug number PR25828 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00300.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25828
[Bug fortran/28660] Spurious warning: 'ubound.6' is used uninitialized in this function
--- Comment #4 from pault at gcc dot gnu dot org 2006-08-10 04:29 --- (In reply to comment #3) > order the declarations or something. > > Paul > Having slept on it, I realise that this will not work because the statement order should not matter. I think that there will have to be a final resolution stage to resolve the sym_root symbol tree; assigning each symbol a number, corresponding to it's position in a chain of dependences. Then, trans-decl.c(generate_local_vars) will have to be called within a loop over depency level. I am not sure that I have time to do this right now but I will think some more about it. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28660
[Bug libstdc++/28671] [4.2 regression] undefined reference to `__sync_fetch_and_add_4'
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |blocker Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28671
[Bug target/28672] [4.2 Regression]: Gcc went into infinite loop when building libstdc++
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-10 02:08 --- Testcase? Do you ever follow directions? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Keywords||wrong-code Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28672
[Bug target/28672] New: [4.2 Regression]: Gcc went into infinite loop when building libstdc++
With revision 116045, gcc mainline went into infinite loop when compiling libstdc++-v3/src/wlocale-inst.cc. -- Summary: [4.2 Regression]: Gcc went into infinite loop when building libstdc++ Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC target triplet: ia64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28672
[Bug libstdc++/28671] [4.2 regression] undefined reference to `__sync_fetch_and_add_4'
--- Comment #8 from pcarlini at suse dot de 2006-08-10 00:05 --- (In reply to comment #6) > Ok, misunderstanding about the compiler flags -- -march=i586 was used to build > the compiler, strigi was built without any -march= tags (making the default > i386, I guess). > > Using -march=i586 in strigi makes the problem go away, and the problem is 100% > reproducable even when compiling a simple test app without -march=i586. Ok, that makes sense and then, yes, it's the issue I was fearing in that message. The problem seems to be that the autoconf test GLIBCXX_ENABLE_ATOMIC_BUILTINS is *always* run (irrespective of the details of configure.host), thus _GLIBCXX_ATOMIC_BUILTINS defined for your GCC build flags, and then you have always to use -march=i486 (or higher) when compiling your code. Annoying to say the least. We don't want that. Thanks for your report. -- pcarlini at suse dot de changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-10 00:05:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28671
[Bug libstdc++/28671] [4.2 regression] undefined reference to `__sync_fetch_and_add_4'
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-09 23:58 --- Can you give your exact commands use to build GCC? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28671
[Bug libstdc++/28671] [4.2 regression] undefined reference to `__sync_fetch_and_add_4'
--- Comment #6 from bero at arklinux dot org 2006-08-09 23:55 --- Ok, misunderstanding about the compiler flags -- -march=i586 was used to build the compiler, strigi was built without any -march= tags (making the default i386, I guess). Using -march=i586 in strigi makes the problem go away, and the problem is 100% reproducable even when compiling a simple test app without -march=i586. Maybe it's just the combination of compiling the compiler (and libstdc++) with -march=i586 and then compiling an app without it -- bero at arklinux dot org changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28671
[Bug libstdc++/28671] [4.2 regression] undefined reference to `__sync_fetch_and_add_4'
--- Comment #5 from pcarlini at suse dot de 2006-08-09 23:48 --- Benjamin, in case this problem is confirmed (and some strange details of the PR are sorted out), can you please double check that we are not incurring in the issue I was fearing here: http://gcc.gnu.org/ml/libstdc++/2006-07/msg00088.html ??? Thanks a lot! -- pcarlini at suse dot de changed: What|Removed |Added CC||bkoz at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28671
[Bug libstdc++/28671] [4.2 regression] undefined reference to `__sync_fetch_and_add_4'
--- Comment #4 from pcarlini at suse dot de 2006-08-09 23:30 --- One additional remark: if the entire software package is really built with -march=i586, then, in any case, the __sync_fetch_and_add call at line 47 of atomicity.h is expanded in line and the link problem cannot occur as reported. About this, I agree with Andrew. But really, I would suggest reinstalling GCC in a totally clean way and trying again. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28671
[Bug libstdc++/28671] [4.2 regression] undefined reference to `__sync_fetch_and_add_4'
--- Comment #3 from pcarlini at suse dot de 2006-08-09 23:08 --- First, a general remark: this kind of error must never happen, irrespective of the options used to build user code and/or GCC. Then, it looks like _GLIBCXX_ATOMIC_BUILTINS is defined for that installation of GCC. In turn, this is not supposed to happen for ?86, *any* ?. Either something is wrong in the installation (something was forced overriding the configure choices) or there are glitches in the recent changes from Benjamin. Note, if the library is really at fault in that way, any trivial program using string will not link, no complex applications are needed to reproduce. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28671
[Bug target/27827] [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #58 from whaley at cs dot utsa dot edu 2006-08-09 23:01 --- Andrew, >Except for the fact IEEE compliant fp does not allow for reordering at all >except >in some small cases. For an example is (a + b) + (-a) is not the same as (a + >(-a)) + b, >so reordering will invalid IEEE fp for larger a and small b. Yes maybe we >should split out >the option for unsafe math fp op for reordering but that is different issue. Thanks for the response, but I believe you are conflating two issues (as is this flag, which is why this is bad news). Different answers to the question "what is this sum" does not ruin IEEE compliance. I am referring to IEEE 754, which is a standard set of rules for storage and arithmetic for floating point (fp) on modern hardware. I am unaware of their being any rules on compilation. I.e. whether re-orderings are allowed is beyond the standard. It rather is a set of rules that discusses for floating point operations (FLOPS) how rounding must be done, how overflow/underflow must be handled, etc. Perhaps there is another IEEE standard concerning compilation that you are referring to? Now of course, floating point arithmetic in general (and IEEE-compliant fp in specific) is not associative, so indeed (a+b+c) != (c+b+a). However, both sequences are valid answers to "what are these 3 things summed up", and both are IEEE compliant if each addition is compliant. What non-IEEE means is that the individual flops are no longer IEEE compliant. This means that overflow may not be handled, or exceptional conditions may cause unknown results (eg., divide by zero), and indeed we have no way at all of knowing what an fp add even means. An example of a non-IEEE optimization is using 3DNow! vectorization, because 3DNow! does not follow the IEEE standard (for instance, it handles overflow only by saturation, which violates the standard). SSE (unless you turn IEEE compliance off manually) is IEEE compliant, and this is why you see computational guys like myself using it, and not using 3DNow!. To a computational scientist, non-IEEE is catastophic, and "may change the answer" is not. "May change the answer" in this case simply means that I've got a different ordering, which is also a valid IEEE fp answer, and indeed may be a "better" answer than the original ordering (depending on the data; no way to know this w/o looking at the data). Non-IEEE means that I have no way of knowing what kind of rounding was done, how flop was done, if underflow (or gradual overflow!) occurred, etc. It is for this reason that optimizations which are non-IEEE are a killer for computational scientists, and reorders are no big deal. In the first you have no idea what has happened with the data, and in the second you have an IEEE-compliant answer, which has known properties. It has been my experience that most compiler people (and I have some experience there, as I got my PhD in compilation) are more concerned with integer work, and thus not experts on fp computation. I've done fp computational work for the majority of my research for the last decade, so I thought I might be able to provide useful input to bridge the camps, so to speak. In this case, I think that by lumping "cause different IEEE-compliant answers" in with "use non-IEEE arithmetic" you are preventing all serious fp users from utilizing the optimizations. Since vectorization is of great importance on modern machines, this is bad news. Obviously, I may be wrong in what I say, but if reordering makes something non-IEEE I'm going to have some students mad at me for teaching them the wrong stuff :) Has this made my point any clearer, or do you still think I am wrong? If I'm wrong, maybe you can point to the part of the IEEE standard that discusses orderings violating the standard (as opposed to the well-known fact that all implemented fp arithemetic is non-associative)? After you do this, I'll have to dig up my copy of the thing, which I don't think I've seen in the last 2 years (but I did scope some of books that cover it, and didn't find anything about compilation). Thanks, Clint -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug libstdc++/28671] [4.2 regression] undefined reference to `__sync_fetch_and_add_4'
--- Comment #2 from bero at arklinux dot org 2006-08-09 22:54 --- -O2 -march=i586 -mcpu=i686 -fomit-frame-pointer -- bero at arklinux dot org changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28671
[Bug libstdc++/28671] [4.2 regression] undefined reference to `__sync_fetch_and_add_4'
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-09 22:51 --- What options are being used to compile the software with? if -march=i386, then this is not a bug with the compiler. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28671
[Bug libstdc++/28671] New: [4.2 regression] undefined reference to `__sync_fetch_and_add_4'
This happens when trying to compile strigi 0.3.2 (http://www.vandenoever.info/software/strigi/) with gcc trunk from today results in Linking CXX executable dummyindexer CMakeFiles/dummyindexer.dir/dummyindexer.o: In function `__exchange_and_add': /usr/lib/gcc/i586-pc-linux-gnu/4.2.0/../../../../include/c++/4.2.0/bits/atomicity.h:47: undefined reference to `__sync_fetch_and_add_4' /usr/lib/gcc/i586-pc-linux-gnu/4.2.0/../../../../include/c++/4.2.0/bits/atomicity.h:47: undefined reference to `__sync_fetch_and_add_4' CMakeFiles/dummyindexer.dir/dummyindexer.o: In function `__exchange_and_add': /usr/lib/gcc/i586-pc-linux-gnu/4.2.0/../../../../include/c++/4.2.0/bits/stl_vector.h:120: undefined reference to `__sync_fetch_and_add_4' CMakeFiles/dummyindexer.dir/dummyindexer.o: In function `__exchange_and_add': /usr/lib/gcc/i586-pc-linux-gnu/4.2.0/../../../../include/c++/4.2.0/bits/atomicity.h:47: undefined reference to `__sync_fetch_and_add_4' /usr/lib/gcc/i586-pc-linux-gnu/4.2.0/../../../../include/c++/4.2.0/bits/atomicity.h:47: undefined reference to `__sync_fetch_and_add_4' CMakeFiles/dummyindexer.dir/indexer.o:/usr/lib/gcc/i586-pc-linux-gnu/4.2.0/../../../../include/c++/4.2.0/bits/atomicity.h:47: more undefined references to `__sync_fetch_and_add_4' follow collect2: ld returned 1 exit status -- Summary: [4.2 regression] undefined reference to `__sync_fetch_and_add_4' Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bero at arklinux dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28671
[Bug c++/28670] New: reject valid? conversion from ‘int’ to non-scalar type ‘Y’ requested.
struct X { X( int ); };
struct Y { Y( X const& ); };
void test()
{
Y y1( 1 ); // conversion works fine.
Y y2 = 2; // error: conversion from ‘int’ to non-scalar
// type ‘Y’ requested.
}
msvc accepts both variants, g++ only one.
is it a bug in g++ or in msvc?
--
Summary: reject valid? conversion from ‘int’ to non-
scalar type ‘Y’ requested.
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC build triplet: x86-64-linux
GCC host triplet: x86-64-linux
GCC target triplet: x86-64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28670
[Bug fortran/28600] [4.2 regression] ICE on character pointer assignment
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28600
[Bug fortran/20541] TR 15581: ALLOCATABLE components
--- Comment #15 from eedelman at gcc dot gnu dot org 2006-08-09 21:55 --- Created an attachment (id=12049) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12049&action=view) Updated patch Fix the problem reported by Jack. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Attachment #11975|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
[Bug target/27827] [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #57 from pinskia at physics dot uc dot edu 2006-08-09 21:46 --- Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3 > > > > --- Comment #56 from whaley at cs dot utsa dot edu 2006-08-09 21:33 > --- > Dorit, > > >This flag is needed in order to allow vectorization of reduction (summation > >in your case) of floating-point data. > > OK, but this is a bd flag to require. From the computational scientist's > point of view, there is a *vast* difference between reordering (which many > aggressive optimizations imply) and failing to have IEEE compliance. Almost > no > computational scientist will use non-IEEE code (because you have essentially > no > idea if your answer is correct), but almost all will allow reordering. So, it > is really important to separate the non-IEEE optimizations from the IEEE > compliant ones. Except for the fact IEEE compliant fp does not allow for reordering at all except in some small cases. For an example is (a + b) + (-a) is not the same as (a + (-a)) + b, so reordering will invalid IEEE fp for larger a and small b. Yes maybe we should split out the option for unsafe math fp op for reordering but that is different issue. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
Re: [Bug target/27827] [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
> > > > --- Comment #56 from whaley at cs dot utsa dot edu 2006-08-09 21:33 > --- > Dorit, > > >This flag is needed in order to allow vectorization of reduction (summation > >in your case) of floating-point data. > > OK, but this is a bd flag to require. From the computational scientist's > point of view, there is a *vast* difference between reordering (which many > aggressive optimizations imply) and failing to have IEEE compliance. Almost > no > computational scientist will use non-IEEE code (because you have essentially > no > idea if your answer is correct), but almost all will allow reordering. So, it > is really important to separate the non-IEEE optimizations from the IEEE > compliant ones. Except for the fact IEEE compliant fp does not allow for reordering at all except in some small cases. For an example is (a + b) + (-a) is not the same as (a + (-a)) + b, so reordering will invalid IEEE fp for larger a and small b. Yes maybe we should split out the option for unsafe math fp op for reordering but that is different issue. -- Pinski
[Bug target/27827] [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #56 from whaley at cs dot utsa dot edu 2006-08-09 21:33 --- Dorit, >This flag is needed in order to allow vectorization of reduction (summation >in your case) of floating-point data. OK, but this is a bd flag to require. From the computational scientist's point of view, there is a *vast* difference between reordering (which many aggressive optimizations imply) and failing to have IEEE compliance. Almost no computational scientist will use non-IEEE code (because you have essentially no idea if your answer is correct), but almost all will allow reordering. So, it is really important to separate the non-IEEE optimizations from the IEEE compliant ones. If vectorization requires me to throw a flag that says it causes non-IEEE arithmetic, I can't use it, and neither can anyone other than, AFAIK, some graphics guys. IEEE is the "contract" between the user and the computer, that bounds how much error there can be, and allows the programmer to know if a given algorithm will produce a usable result. Non-IEEE is therefore the death-knell for having any theoretical or a priori understanding of accuracy. So, while reordering and non-IEEE may both seem unsafe, a reordering just gives different results, which are still known to be within normal fp error, while non-IEEE means there is no contract between the programmer at all, and indeed the answer may be arbitrarily bad. Further, behavior under exceptional conditions is not maintained, and so the answer may actually be undetectably nonsensical, not merely inaccurate. Having an oddly colored pixel doesn't hurt the graphics guy, but sending a satellite into the atmosphere, or registering cancer in a clean MRI are rather more serious . . . So, mixing the two transformation types on one flag means that vectorization is unusable to what must be the majority of it's audience. Maybe I should open this as another bug report "flag mixes normal and catastrophic optimizations"? >Not really, I'm afraid - there is something that's not entirely supported >in gcc yet - see details in PR20794 Hmm. I'd tried the __attribute__, but I must have mistyped it, because it didn't work before on pointers. However, it just did in the MMBENCHV tarfile. However, the code still didn't use aligned load to access the vectors (using multiple movlpd/movhpd instead) . . . Even more scary, having the attribute calls does not change the genned assembly at all. Does the vectorization phase get this alignment info passed to it? Aligned loads can be as much as twice as fast as unaligned, and if you have to choose amongst loops in the midst of a deep loop nest, these factors can actually make vectorization a loser . . . Thanks, Clint -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug c++/28669] %s substituted with static/non- can't be properly translated
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-09 21:08 --- 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-08-09 21:08:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28669
[Bug target/28247] [4.1/4.2 regression] libstdc++ cannot be build with Solaris threads
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2006-08-09 20:03 --- poog% uname -a SunOS poog 5.9 Generic_117171-12 sun4u sparc SUNW,Sun-Fire-V250 poog% gcc/xgcc -v Using built-in specs. Target: sparc64-sun-solaris2.9 Configured with: /home/eric/svn/gcc-4_1-branch/configure sparc64-sun-solaris2.9--prefix=/opt/build/eric/gcc-4_1-branch --with-local-prefix=/opt/build/eric/local --enable-languages=c,c++ --enable-shared --enable-threads=solaris --disable-multilib --disable-nls Thread model: solaris gcc version 4.1.2 20060806 (prerelease) -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28247
[Bug c++/28669] New: %s substituted with static/non- can't be properly translated
In cp/decl.c there is this code.
error ("%smember function %qD cannot have cv-qualifier",
(ctype ? "static " : "non-"), decl);
The first string, "%smember ..." is available for translation in the po-file,
but not the parts substituted, static and non-. And even if they were, it
surely will not work in all languages to compose a sentence like this. Two
complete strings should be there instead.
--
Summary: %s substituted with static/non- can't be properly
translated
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: goeran at uddeborg dot se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28669
[Bug target/28665] [4.1/4.2 regression] libstdc++ cannot be build with Solaris threads
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-08-09 19:17 --- The file you've attached is incorrectly patched. Please get it from a snapshot or the SVN repository. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28665
[Bug target/28668] internal compiler error: in find_reloads, at reload.c:3690
--- Comment #3 from pinskia at physics dot uc dot edu 2006-08-09 19:16 --- Subject: Re: internal compiler error: in find_reloads, at reload.c:3690 > > > > --- Comment #2 from bonomo at sal dot wisc dot edu 2006-08-09 19:14 > --- > Subject: Re: internal compiler error: in find_reloads, at > reload.c:3690 > > > Ah! This is not really a gcc bug then. That's a bit of > a relief. It is most likely a GCC bug but with the port to the target and not in the common parts of GCC. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28668
Re: [Bug target/28668] internal compiler error: in find_reloads, at reload.c:3690
> > > > --- Comment #2 from bonomo at sal dot wisc dot edu 2006-08-09 19:14 > --- > Subject: Re: internal compiler error: in find_reloads, at > reload.c:3690 > > > Ah! This is not really a gcc bug then. That's a bit of > a relief. It is most likely a GCC bug but with the port to the target and not in the common parts of GCC. -- Pinski
[Bug target/28668] internal compiler error: in find_reloads, at reload.c:3690
--- Comment #2 from bonomo at sal dot wisc dot edu 2006-08-09 19:14 --- Subject: Re: internal compiler error: in find_reloads, at reload.c:3690 Ah! This is not really a gcc bug then. That's a bit of a relief. Rich On Wed, 9 Aug 2006, pinskia at gcc dot gnu dot org wrote: > > > --- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-09 19:08 > --- > 6809 is not in the FSF GCC at all. > Contact the person who you got the compiler from. > > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28668
[Bug c/28668] New: internal compiler error: in find_reloads, at reload.c:3690
Tied to version 3.4.5, unable to try with current build. Here is the output, followed by part of the preprocessed source: Output: [EMAIL PROTECTED] flt]$ /usr/users/bonomo/gnu/cross/m6809/bin/gcc -v -save-temps -Wall -B/usr/users/bonomo/gnu/cros s/m6809/bin/ -S -c test.c^M Reading specs from /usr/users/bonomo/gnu/cross/lib/gcc/m6809/3.4.5/specs Configured with: ../../src/gcc-3.4.5/configure --target=m6809 --program-suffix=09 --nfp --enable-obsolete --sr cdir=../../src/gcc-3.4.5 --disable-threads --disable-multilib --disable-nls --enable-languages=c Thread model: single gcc version 3.4.5 /usr/users/bonomo/gnu/cross/libexec/gcc/m6809/3.4.5/cc1 -E -quiet -v -iprefix /usr/users/bonomo/gnu/cross/m68 09/bin/../lib/gcc/m6809/3.4.5/ -isystem /usr/users/bonomo/gnu/cross/m6809/bin/include test.c -Wall -o test.i ignoring nonexistent directory "/usr/users/bonomo/gnu/cross/m6809/bin/include" ignoring nonexistent directory "/usr/users/bonomo/gnu/cross/m6809/bin/../lib/gcc/m6809/3.4.5/include" ignoring nonexistent directory "/usr/users/bonomo/gnu/cross/m6809/bin/../lib/gcc/m6809/3.4.5/../../../../m6809 /sys-include" ignoring nonexistent directory "/usr/users/bonomo/gnu/cross/m6809/bin/../lib/gcc/m6809/3.4.5/../../../../m6809 /include" ignoring nonexistent directory "/usr/users/bonomo/gnu/cross/lib/gcc/m6809/3.4.5/../../../../m6809/sys-include" ignoring nonexistent directory "/usr/users/bonomo/gnu/cross/lib/gcc/m6809/3.4.5/../../../../m6809/include" #include "..." search starts here: #include <...> search starts here: /usr/users/bonomo/gnu/cross/lib/gcc/m6809/3.4.5/include End of search list. /usr/users/bonomo/gnu/cross/libexec/gcc/m6809/3.4.5/cc1 -fpreprocessed test.i -quiet -dumpbase test.c -auxbas e test -Wall -version -o test.s GNU C version 3.4.5 (m6809) compiled by GNU C version 4.0.1 20050727 (Red Hat 4.0.1-5). GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64349 In file included from global.h:19, from test.c:29: clib.h:23: warning: conflicting types for built-in function 'bcopy' clib.h:24: warning: conflicting types for built-in function 'bzero' clib.h:26: warning: conflicting types for built-in function 'fputs' clib.h:35: warning: conflicting types for built-in function 'strlen' In file included from global.h:20, from test.c:29: wisplib.h:28: warning: conflicting types for built-in function 'exit' test.c:82: warning: return type defaults to `int' test.c: In function `main': test.c:88: warning: overflow in implicit constant conversion test.c:92: warning: control reaches end of non-void function test.c: At top level: test.c:98: warning: return type defaults to `int' test.c: In function `do_wisp': test.c:113: warning: implicit declaration of function `init_wp' test.c:114: warning: implicit declaration of function `init_fil' test.c:115: warning: implicit declaration of function `cam_init' test.c:124: warning: implicit declaration of function `do_cmd' test.c: At top level: test.c:138: warning: return type defaults to `int' test.c: In function `do_cmd': test.c:147: warning: overflow in implicit constant conversion test.c:151: warning: implicit declaration of function `do_pmt' test.c:154: warning: implicit declaration of function `do_cam' test.c:157: warning: implicit declaration of function `do_discrete' test.c:160: warning: implicit declaration of function `do_filter' test.c:163: warning: implicit declaration of function `do_focus' test.c:166: warning: implicit declaration of function `do_pfa' test.c:172: warning: implicit declaration of function `do_shutter' test.c:175: warning: implicit declaration of function `do_wvplt' test.c: At top level: test.c:193: warning: return type defaults to `int' test.c: In function `do_cam': test.c:201: warning: implicit declaration of function `printf' test.c:211: warning: implicit declaration of function `cam_parrd' test.c:214: warning: control reaches end of non-void function test.c: At top level: test.c:220: warning: return type defaults to `int' test.c: In function `do_filter': test.c:224: warning: implicit declaration of function `mv_filter' test.c:231: warning: control reaches end of non-void function test.c: At top level: test.c:237: warning: return type defaults to `int' test.c: In function `do_focus': test.c:242: warning: comparison is always true due to limited range of data type test.c:242: warning: comparison is always true due to limited range of data type test.c:243: warning: implicit declaration of function `mv_focus' test.c:248: warning: control reaches end of non-void function test.c: At top level: test.c:254: warning: return type defaults to `int' test.c: In function `do_shutter': test.c:258: warning: implicit declaration of function `mv_shutter' test.c:265: warning: control reaches end of non-void function test.c: At top level: test.c:271: warning: return type defaults to `int' test.c: In function `do_wvplt': test.c:276: warning: implicit declaration of function `rotate' test.c:287: warning: control
[Bug target/27827] [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #55 from dorit at il dot ibm dot com 2006-08-09 19:10 --- Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3 > > Here's some questions I need to figure out: > (1) Why do I have to throw the -funsafe-math-optimizations flag to > enable this? >-- I see where the .vect file warns of it, but it refers to an SSA line, > so I'm not sure what's going on. This flag is needed in order to allow vectorization of reduction (summation in your case) of floating-point data. This is because vectorization of reduction changes the order of the computation, which may result in different behavior (instead of summing this way: ((a0+a1)+a2)+a3)+a4)+a5)+a6)+a7, we sum this way (((a0+a2)+a4)+a6)+(((a1+a3)+a5)+a7) > (2) Is there any pragma or assertion, etc, that I can put in the code to > notify the compiler that certain pointers point to 16-byte aligned data? > -- Only the output array (C) is possibly misaligned in ATLAS > Not really, I'm afraid - there is something that's not entirely supported in gcc yet - see details in PR20794. dorit > Thanks, > Clint > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827 > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
Re: [Bug target/27827] [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
> > Here's some questions I need to figure out: > (1) Why do I have to throw the -funsafe-math-optimizations flag to > enable this? >-- I see where the .vect file warns of it, but it refers to an SSA line, > so I'm not sure what's going on. This flag is needed in order to allow vectorization of reduction (summation in your case) of floating-point data. This is because vectorization of reduction changes the order of the computation, which may result in different behavior (instead of summing this way: ((a0+a1)+a2)+a3)+a4)+a5)+a6)+a7, we sum this way (((a0+a2)+a4)+a6)+(((a1+a3)+a5)+a7) > (2) Is there any pragma or assertion, etc, that I can put in the code to > notify the compiler that certain pointers point to 16-byte aligned data? > -- Only the output array (C) is possibly misaligned in ATLAS > Not really, I'm afraid - there is something that's not entirely supported in gcc yet - see details in PR20794. dorit > Thanks, > Clint > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827 >
[Bug target/28668] internal compiler error: in find_reloads, at reload.c:3690
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-09 19:08 --- 6809 is not in the FSF GCC at all. Contact the person who you got the compiler from. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28668
[Bug c++/28641] [4.1/4.2 regression] ICE calling template function with invalid template parameter
--- Comment #2 from lmillward at gcc dot gnu dot org 2006-08-09 18:47 --- Partially fixed on mainline, the testcase now ICE's in the same place as PR 24791. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28641
[Bug c++/28639] [4.1/4.2 regression] ICE trying to print error on invalid template parameter
--- Comment #2 from lmillward at gcc dot gnu dot org 2006-08-09 18:47 --- Partially fixed on mainline, the testcase now ICE's in the same place as PR 24791. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28639
[Bug c++/28637] [4.1 regression] ICE on invalid template parameter
--- Comment #3 from lmillward at gcc dot gnu dot org 2006-08-09 18:45 --- Fixed on mainline. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2 regression] ICE on |[4.1 regression] ICE on |invalid template parameter |invalid template parameter http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28637
[Bug c++/28638] [4.1 regression] ICE on invalid template parameter
--- Comment #2 from lmillward at gcc dot gnu dot org 2006-08-09 18:45 --- Fixed on mainline. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2 regression] ICE on |[4.1 regression] ICE on |invalid template parameter |invalid template parameter http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28638
[Bug c++/28640] [4.1 regression] ICE redeclaring template with invalid parameter
--- Comment #2 from lmillward at gcc dot gnu dot org 2006-08-09 18:44 --- Fixed on mainline. Will be fixed on 4.1 branch when the patch for PR 27668 is reverted. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2 regression] ICE|[4.1 regression] ICE |redeclaring template with |redeclaring template with |invalid parameter |invalid parameter http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28640
[Bug c++/28640] [4.1/4.2 regression] ICE redeclaring template with invalid parameter
--- Comment #1 from lmillward at gcc dot gnu dot org 2006-08-09 18:43 --- Subject: Bug 28640 Author: lmillward Date: Wed Aug 9 18:43:06 2006 New Revision: 116043 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116043 Log: 2006-08-09 Lee Millward <[EMAIL PROTECTED]> PR c++/28637 * pt.c (coerce_template_parms): Copy across the invalid template arguments to the new template inner arguments. (retrieve_specialization): Robustify. * g++.dg/template/void3.C: New test. PR c++/28638 * pt.c (coerce_template_template_parms): Robustify. * g++.dg/template/void4.C: New test. PR c++/28639 * error.c (dump_template_parms): Robustify. PR c++/28640 * pt.c (redeclare_class_template): Robustify * g++.dg/template/void5.C: New test. PR c++/28641 * pt.c (type_unification_real): Robustify. Added: trunk/gcc/testsuite/g++.dg/template/void3.C trunk/gcc/testsuite/g++.dg/template/void4.C trunk/gcc/testsuite/g++.dg/template/void5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28640
[Bug c++/28638] [4.1/4.2 regression] ICE on invalid template parameter
--- Comment #1 from lmillward at gcc dot gnu dot org 2006-08-09 18:43 --- Subject: Bug 28638 Author: lmillward Date: Wed Aug 9 18:43:06 2006 New Revision: 116043 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116043 Log: 2006-08-09 Lee Millward <[EMAIL PROTECTED]> PR c++/28637 * pt.c (coerce_template_parms): Copy across the invalid template arguments to the new template inner arguments. (retrieve_specialization): Robustify. * g++.dg/template/void3.C: New test. PR c++/28638 * pt.c (coerce_template_template_parms): Robustify. * g++.dg/template/void4.C: New test. PR c++/28639 * error.c (dump_template_parms): Robustify. PR c++/28640 * pt.c (redeclare_class_template): Robustify * g++.dg/template/void5.C: New test. PR c++/28641 * pt.c (type_unification_real): Robustify. Added: trunk/gcc/testsuite/g++.dg/template/void3.C trunk/gcc/testsuite/g++.dg/template/void4.C trunk/gcc/testsuite/g++.dg/template/void5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28638
[Bug c++/28641] [4.1/4.2 regression] ICE calling template function with invalid template parameter
--- Comment #1 from lmillward at gcc dot gnu dot org 2006-08-09 18:43 --- Subject: Bug 28641 Author: lmillward Date: Wed Aug 9 18:43:06 2006 New Revision: 116043 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116043 Log: 2006-08-09 Lee Millward <[EMAIL PROTECTED]> PR c++/28637 * pt.c (coerce_template_parms): Copy across the invalid template arguments to the new template inner arguments. (retrieve_specialization): Robustify. * g++.dg/template/void3.C: New test. PR c++/28638 * pt.c (coerce_template_template_parms): Robustify. * g++.dg/template/void4.C: New test. PR c++/28639 * error.c (dump_template_parms): Robustify. PR c++/28640 * pt.c (redeclare_class_template): Robustify * g++.dg/template/void5.C: New test. PR c++/28641 * pt.c (type_unification_real): Robustify. Added: trunk/gcc/testsuite/g++.dg/template/void3.C trunk/gcc/testsuite/g++.dg/template/void4.C trunk/gcc/testsuite/g++.dg/template/void5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28641
[Bug c++/28639] [4.1/4.2 regression] ICE trying to print error on invalid template parameter
--- Comment #1 from lmillward at gcc dot gnu dot org 2006-08-09 18:43 --- Subject: Bug 28639 Author: lmillward Date: Wed Aug 9 18:43:06 2006 New Revision: 116043 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116043 Log: 2006-08-09 Lee Millward <[EMAIL PROTECTED]> PR c++/28637 * pt.c (coerce_template_parms): Copy across the invalid template arguments to the new template inner arguments. (retrieve_specialization): Robustify. * g++.dg/template/void3.C: New test. PR c++/28638 * pt.c (coerce_template_template_parms): Robustify. * g++.dg/template/void4.C: New test. PR c++/28639 * error.c (dump_template_parms): Robustify. PR c++/28640 * pt.c (redeclare_class_template): Robustify * g++.dg/template/void5.C: New test. PR c++/28641 * pt.c (type_unification_real): Robustify. Added: trunk/gcc/testsuite/g++.dg/template/void3.C trunk/gcc/testsuite/g++.dg/template/void4.C trunk/gcc/testsuite/g++.dg/template/void5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28639
[Bug c++/28637] [4.1/4.2 regression] ICE on invalid template parameter
--- Comment #2 from lmillward at gcc dot gnu dot org 2006-08-09 18:43 --- Subject: Bug 28637 Author: lmillward Date: Wed Aug 9 18:43:06 2006 New Revision: 116043 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116043 Log: 2006-08-09 Lee Millward <[EMAIL PROTECTED]> PR c++/28637 * pt.c (coerce_template_parms): Copy across the invalid template arguments to the new template inner arguments. (retrieve_specialization): Robustify. * g++.dg/template/void3.C: New test. PR c++/28638 * pt.c (coerce_template_template_parms): Robustify. * g++.dg/template/void4.C: New test. PR c++/28639 * error.c (dump_template_parms): Robustify. PR c++/28640 * pt.c (redeclare_class_template): Robustify * g++.dg/template/void5.C: New test. PR c++/28641 * pt.c (type_unification_real): Robustify. Added: trunk/gcc/testsuite/g++.dg/template/void3.C trunk/gcc/testsuite/g++.dg/template/void4.C trunk/gcc/testsuite/g++.dg/template/void5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28637
[Bug fortran/28600] [4.2 regression] ICE on character pointer assignment
--- Comment #7 from jakub at gcc dot gnu dot org 2006-08-09 18:36 --- Go with your version, you posted first ;). I added the comment just to support your patch, that I independently came to a (almost) same fix. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28600
[Bug fortran/28600] [4.2 regression] ICE on character pointer assignment
--- Comment #6 from pault at gcc dot gnu dot org 2006-08-09 18:27 ---
(In reply to comment #5)
> It was caused by the openmp changes, but guess usually the parent routine
> at least touches the dummy argument and therefore it would be added to the
> right context.
> I was testing:
> --- trans-decl.c.jj 2006-08-09 15:39:36.0 +0200
> +++ trans-decl.c2006-08-09 15:44:35.0 +0200
> @@ -884,7 +884,10 @@ gfc_get_symbol_decl (gfc_symbol * sym)
> if (TREE_CODE (length) == VAR_DECL
> && DECL_CONTEXT (length) == NULL_TREE)
> {
> - gfc_add_decl_to_function (length);
> + if (sym->ns->proc_name->backend_decl == current_function_decl)
> + gfc_add_decl_to_function (length);
> + else
> + gfc_add_decl_to_parent_function (length);
> gfc_defer_symbol_init (sym);
> }
> }
> before I saw Paul's patch on gcc-patches, guess both versions will DTRT.
>
Your call or mine, Jakub? I suggest a tall glass of beer and arm wrestling for
the honours...
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28600
[Bug target/28132] [4.1 Regression] ICE instantiate_virtual_regs_in_insn when -fforce-addr -O1 used
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-09 18:16 --- *** Bug 28667 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28132
[Bug target/28667] ICE with -fforce-addr
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-09 18:16 --- This is a dup of bug 28132. *** This bug has been marked as a duplicate of 28132 *** -- 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=28667
[Bug target/28132] [4.1 Regression] ICE instantiate_virtual_regs_in_insn when -fforce-addr -O1 used
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28132
[Bug target/28667] New: ICE with -fforce-addr
/* { dg-do compile } */
/* { dg-options "-O2 -fforce-addr" } */
extern int foo (void *, long, double *);
extern int bar (void *, double, long *);
extern double copysign (double, double);
extern double floor (double);
int
test (void *a, long *b, long *c)
{
double x, z;
if (!foo (a, b[0], &x))
return 0;
z = copysign (floor (x + 0.5), x);
return bar (a, z, c);
}
ICEs on i686 with:
A.c: In function 'test':
A.c:18: error: unrecognizable insn:
(insn 48 78 49 4 (parallel [
(set (mem/i:DF (reg/f:SI 80) [0 S8 A32])
(neg:DF (mem/i:DF (reg/f:SI 81) [0 S8 A32])))
(use (const_int 0 [0x0]))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(nil))
A.c:18: internal compiler error: in instantiate_virtual_regs_in_insn, at
function.c:1555
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
The ICE is not present on mainline, guess since the
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01526.html
change where the MEM is forced into register during expand time.
--
Summary: ICE with -fforce-addr
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: i686-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28667
[Bug fortran/28662] fpp call of gfortran: -traditional-cpp versus newer macros like #x
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de 2006-08-09 18:10 --- > One problem without using -tranditional-cpp is that some tokens in C are not > tokens in Fortran so you could get the wrong result. This is why > -tranditional-cpp is used. I though the -lang-fortran, which is passed (according to gfortran -###), takes care of this? > There is no standard for Preprocessed Fortran Source at all. Well, that I assumed. But it is still (somehow) based on ISO C's preprocessor. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28662
[Bug java/28663] [4.2 regression] gcj fails to binary-compile eclipse's javac
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28663
[Bug fortran/28600] [4.2 regression] ICE on character pointer assignment
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28600
[Bug fortran/28662] fpp call of gfortran: -traditional-cpp versus newer macros like #x
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-09 18:03 --- One problem without using -tranditional-cpp is that some tokens in C are not tokens in Fortran so you could get the wrong result. This is why -tranditional-cpp is used. There is no standard for Preprocessed Fortran Source at all. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28662
[Bug target/24367] unrecognizable insn with -fPIC -O2 -funroll-loops
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-09 17:56 --- My patch just exposed a latent bug as it does nothing that was not already done before RTH removed the folding. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24367
[Bug target/24367] unrecognizable insn with -fPIC -O2 -funroll-loops
--- Comment #1 from janis at gcc dot gnu dot org 2006-08-09 17:48 --- A regression hunt using an s390-linux cross compiler on powerpc-linux, with the submitter's testcase and options, identified this patch: http://gcc.gnu.org/viewcvs?view=rev&rev=88869 r88869 | pinskia | 2004-10-11 03:42:09 + (Mon, 11 Oct 2004) -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24367
[Bug fortran/28660] Spurious warning: 'ubound.6' is used uninitialized in this function
--- Comment #3 from pault at gcc dot gnu dot org 2006-08-09 17:47 --- uuuhhh! This is horrible and is a reflection of the symtree being ordered as a binary tree. If 'r' is renamed 'zr', the order of translation is changed and the code runs correctly; albeit still with an unrequited ubound. I think that we are going to have to make use of the sym->declared_at to try to order the declarations or something. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28660
[Bug target/28665] [4.1/4.2 regression] libstdc++ cannot be build with Solaris threads
--- Comment #2 from jr at e-integration dot net 2006-08-09 16:52 ---
Created an attachment (id=12048)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12048&action=view)
/gcc-4.1.1/gcc/gthr-solaris.h Solaris threads header file
bootstrap fails:
Here's my configure:
/gcc-4.1.1/configure sparc64-sun-solaris2.9 \
--prefix=${PKG_BASE}/compiler/GNU/gcc41/gcc-4.1.1 \
--with-gmp --with-mpfr \
--enable-threads=solaris \
--enable-static --enable-shared \
--enable-haifa --with-dwarf2 \
--enable-nls --with-cpu=v9 \
--with-included-gettext \
--with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld \
--enable-languages=c,c++,objc,fortran
Note: Using CPPFLAGS, CFLAGS, and CXXFLAGS for GMP and MPFR
libraries/includes.
GMP is a 64-bit 4.2.1 build
MPFR is a 64-bit 2.2.0 build
make bootstrap output:
make[4]: Leaving directory
`/misc/reloc/root-unified/j/jtaisto/gcc-build/gcc'
./xgcc -B./
-B/opt/OIT/pkg/compiler/GNU/gcc41/gcc-4.1.1/sparc64-sun-solaris2.9/bin/
-isystem
/opt/OIT/pkg/compiler/GNU/gcc41/gcc-4.1.1/sparc64-sun-solaris2.9/include
-isystem
/opt/OIT/pkg/compiler/GNU/gcc41/gcc-4.1.1/sparc64-sun-solaris2.9/sys-include
-L/unified/j/jtaisto/gcc-build/gcc/../ld -O2 -O2 -g -O2 -DIN_GCC-W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I -I/gcc-4.1.1/gcc
-I/gcc-4.1.1/gcc/ -I/gcc-4.1.1/gcc/../include -I./../intl
-I/gcc-4.1.1/gcc/../libcpp/include -Iyes/include -Iyes/include
-fexceptions -c /gcc-4.1.1/gcc/unwind-dw2.c -o libgcc/./unwind-dw2.o
In file included from ./gthr-default.h:1,
from /gcc-4.1.1/gcc/gthr.h:114,
from /gcc-4.1.1/gcc/unwind-dw2.c:42:
/gcc-4.1.1/gcc/gthr-solaris.h:74: error: weak declaration of
'__gthrw_thr_keycreate' must be public
/gcc-4.1.1/gcc/gthr-solaris.h:75: error: weak declaration of
'__gthrw_thr_getspecific' must be public
/gcc-4.1.1/gcc/gthr-solaris.h:76: error: weak declaration of
'__gthrw_thr_setspecific' must be public
/gcc-4.1.1/gcc/gthr-solaris.h:77: error: weak declaration of
'__gthrw_thr_create' must be public
/gcc-4.1.1/gcc/gthr-solaris.h:78: error: weak declaration of
'__gthrw_thr_self' must be public
/gcc-4.1.1/gcc/gthr-solaris.h:80: error: weak declaration of
'__gthrw_mutex_init' must be public
/gcc-4.1.1/gcc/gthr-solaris.h:81: error: weak declaration of
'__gthrw_mutex_destroy' must be public
/gcc-4.1.1/gcc/gthr-solaris.h:82: error: weak declaration of
'__gthrw_mutex_lock' must be public
/gcc-4.1.1/gcc/gthr-solaris.h:83: error: weak declaration of
'__gthrw_mutex_trylock' must be public
/gcc-4.1.1/gcc/gthr-solaris.h:84: error: weak declaration of
'__gthrw_mutex_unlock' must be public
make[3]: *** [libgcc/./unwind-dw2.o] Error 1
make[3]: Leaving directory
`/misc/reloc/root-unified/j/jtaisto/gcc-build/gcc'
make[2]: *** [stmp-multilib] Error 2
make[2]: Leaving directory
`/misc/reloc/root-unified/j/jtaisto/gcc-build/gcc'
make[1]: *** [stage1_build] Error 2
make[1]: Leaving direct
[Bug target/28665] [4.1/4.2 regression] libstdc++ cannot be build with Solaris threads
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-09 16:44 --- What don't you understand that this was already fixed for the next release of 4.1.x aka 4.1.2? *** This bug has been marked as a duplicate of 28247 *** -- 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=28665
[Bug target/28247] [4.1/4.2 regression] libstdc++ cannot be build with Solaris threads
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-08-09 16:44 --- *** Bug 28665 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jr at e-integration dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28247
[Bug target/28665] New: [4.1/4.2 regression] libstdc++ cannot be build with Solaris threads
+++ This bug was initially created as a clone of Bug #28247 +++ gcc 4.1.1 cannot buld on Solaris 9 sparc: $ ./configure --prefix=/home/gcc --enable-threads=solaris --enable-languages=c,c++ --enable-shared=libstdc++ --disable-multilib --disable-nls sparc64-sun-solaris2.9 $ make ... /home/devel/tmp/gcc-4.1.1/objdir/./gcc/xgcc -shared-libgcc -B/home/devel/tmp/gcc-4.1.1/objdir/./gcc -nostdinc++ -L/home/devel/tmp/gcc-4.1.1/objdir/sparc64-sun-solaris2.9/libstdc++-v3/src -L/home/devel/tmp/gcc-4.1.1/objdir/sparc64-sun-solaris2.9/libstdc++-v3/src/.libs -B/home/gcc/sparc64-sun-solaris2.9/bin/ -B/home/gcc/sparc64-sun-solaris2.9/lib/ -isystem /home/gcc/sparc64-sun-solaris2.9/include -isystem /home/gcc/sparc64-sun-solaris2.9/sys-include -I/home/devel/tmp/gcc-4.1.1/libstdc++-v3/../gcc -I/home/devel/tmp/gcc-4.1.1/objdir/sparc64-sun-solaris2.9/libstdc++-v3/include/sparc64-sun-solaris2.9 -I/home/devel/tmp/gcc-4.1.1/objdir/sparc64-sun-solaris2.9/libstdc++-v3/include -I/home/devel/tmp/gcc-4.1.1/libstdc++-v3/libsupc++ -g -O2 -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -c ../../../../libstdc++-v3/libsupc++/eh_alloc.cc -fPIC -DPIC -o eh_alloc.o /home/devel/tmp/gcc-4.1.1/objdir/sparc64-sun-solaris2.9/libstdc++-v3/include/sparc64-sun-solaris2.9/bits/gthr-default.h:437: warning: unused parameter 'key' /home/devel/tmp/gcc-4.1.1/objdir/sparc64-sun-solaris2.9/libstdc++-v3/include/sparc64-sun-solaris2.9/bits/gthr-default.h: In function 'int __gthread_setspecific(__gthread_key_t, const void*)': /home/devel/tmp/gcc-4.1.1/objdir/sparc64-sun-solaris2.9/libstdc++-v3/include/sparc64-sun-solaris2.9/bits/gthr-default.h:456: warning: cast from type 'const void*' to type 'void*' casts away constness /home/devel/tmp/gcc-4.1.1/objdir/sparc64-sun-solaris2.9/libstdc++-v3/include/sparc64-sun-solaris2.9/bits/gthr-default.h: In function 'int __gthread_recursive_mutex_init_function(__gthread_recursive_mutex_t*)': /home/devel/tmp/gcc-4.1.1/objdir/sparc64-sun-solaris2.9/libstdc++-v3/include/sparc64-sun-solaris2.9/bits/gthr-default.h:491: error: '__gthrw_mutex_init' was not declared in this scope /home/devel/tmp/gcc-4.1.1/objdir/sparc64-sun-solaris2.9/libstdc++-v3/include/sparc64-sun-solaris2.9/bits/gthr-default.h: In function 'int __gthread_recursive_mutex_lock(__gthread_recursive_mutex_t*)': /home/devel/tmp/gcc-4.1.1/objdir/sparc64-sun-solaris2.9/libstdc++-v3/include/sparc64-sun-solaris2.9/bits/gthr-default.h:499: error: '__gthrw_thr_self' was not declared in this scope /home/devel/tmp/gcc-4.1.1/objdir/sparc64-sun-solaris2.9/libstdc++-v3/include/sparc64-sun-solaris2.9/bits/gthr-default.h: In function 'int __gthread_recursive_mutex_trylock(__gthread_recursive_mutex_t*)': /home/devel/tmp/gcc-4.1.1/objdir/sparc64-sun-solaris2.9/libstdc++-v3/include/sparc64-sun-solaris2.9/bits/gthr-default.h:517: error: '__gthrw_thr_self' was not declared in this scope make[4]: *** [eh_alloc.lo] Error 1 make[4]: Leaving directory `/home/devel/tmp/gcc-4.1.1/objdir/sparc64-sun-solaris2.9/libstdc++-v3/libsupc++' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/devel/tmp/gcc-4.1.1/objdir/sparc64-sun-solaris2.9/libstdc++-v3' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/devel/tmp/gcc-4.1.1/objdir/sparc64-sun-solaris2.9/libstdc++-v3' make[1]: *** [all-target-libstdc++-v3] Error 2 make[1]: Leaving directory `/home/devel/tmp/gcc-4.1.1/objdir' make: *** [all] Error 2 try with gcc-4.0.3 and SUN cc 5.8 -- Summary: [4.1/4.2 regression] libstdc++ cannot be build with Solaris threads Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jr at e-integration dot net GCC build triplet: *-*-solaris2.* GCC host triplet: *-*-solaris2.* GCC target triplet: *-*-solaris2.* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28665
[Bug target/27827] [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #54 from whaley at cs dot utsa dot edu 2006-08-09 16:08 --- Dorit, OK, I've posted a new tarfile with a safe kernel code where the loop is not unrolled, so that the vectorizer has a chance. With this kernel, I can make it vectorize code, but only if I throw the -funsafe-math-optimizations flag. This kernel doesn't use a lot of registers, so it should work for both x86-32 and x86-64 archs. I would expect for the vectorized code to beat the x87 in both precisions on the P4E (vector SSE has two and four times the peak of x87 respectively), and beat the x87 code in single on the Ath64 (twice the peak). So far, vectorization is never a win on the P4e, but I can make single win on Ath64. On both platforms, editing the assembly confirms that there are loops in there that use the vector instructions. Once I understand better what's going on, maybe I can improve this . . . Here's some questions I need to figure out: (1) Why do I have to throw the -funsafe-math-optimizations flag to enable this? -- I see where the .vect file warns of it, but it refers to an SSA line, so I'm not sure what's going on. -- ATLAS cannot throw this flag, because it enables non-IEEE fp arithmetic, and ATLAS must maintain IEEE compliance. SSE itself does *not* require ruining IEEE compliance. -- Let me know if there is some way in the code that I can avoid this prob -- If it cannot be avoided, is there a way to make this optimization controlled by a flag that does not mean a loss of IEEE compliance? (2) Is there any pragma or assertion, etc, that I can put in the code to notify the compiler that certain pointers point to 16-byte aligned data? -- Only the output array (C) is possibly misaligned in ATLAS Thanks, Clint -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug target/28247] [4.1/4.2 regression] libstdc++ cannot be build with Solaris threads
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2006-08-09 15:52 --- > Fails with latest gcc-4.1.1/gcc/gthr-solaris.h file during bootstrap. As indicated in the "target milestone" field, this will be fixed in 4.1.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28247
[Bug target/27827] [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #53 from whaley at cs dot utsa dot edu 2006-08-09 15:52 --- Created an attachment (id=12047) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12047&action=view) benchmark wt vectorizable kernel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug c++/28255] [4.1/4.2 regression] ICE with initialization in template
--- Comment #2 from janis at gcc dot gnu dot org 2006-08-09 15:46 --- A regression hunt on powerpc-linux identified this patch: http://gcc.gnu.org/viewcvs?view=rev&rev=102182 r102182 | giovannibajo | 2005-07-20 01:19:59 + (Wed, 20 Jul 2005) -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||giovannibajo at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28255
[Bug tree-optimization/28544] [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1309
-- dberlin at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-07-30 14:44:23 |2006-08-09 14:40:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28544
[Bug tree-optimization/28003] [4.2 Regression] optimizer bug
-- dberlin at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-06-29 19:47:20 |2006-08-09 14:39:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28003
[Bug tree-optimization/28544] [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1309
--- Comment #8 from dberlin at gcc dot gnu dot org 2006-08-09 14:38 --- I can trivially fix this, but the code isn't going to do what you want when i'm done, since it is an aliasing violation :) The assert in question just happens to be good at catching them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28544
[Bug java/28663] New: [4.2 regression] gcj fails to binary-compile eclipse's javac
gcj -O2 -fomit-frame-pointer -fweb -frename-registers -fPIC -fjni -shared -Wl,-O2,--as-needed,--enable-new-dtags,-soname,libecj.so.3 -o libecj.so.3 ecj.jar org/eclipse/jdt/internal/compiler/lookup/Scope.java: In class 'org.eclipse.jdt.internal.compiler.lookup.Scope': org/eclipse/jdt/internal/compiler/lookup/Scope.java: In method 'org.eclipse.jdt.internal.compiler.lookup.Scope.getType(char[])': org/eclipse/jdt/internal/compiler/lookup/Scope.java:2256: error: verification failed at PC=18: incompatible return type org/eclipse/jdt/internal/compiler/lookup/Scope.java: In method 'org.eclipse.jdt.internal.compiler.lookup.Scope.getType(char[][],int)': org/eclipse/jdt/internal/compiler/lookup/Scope.java:2296: error: verification failed at PC=77: incompatible return type org/eclipse/jdt/internal/compiler/ast/QualifiedTypeReference.java: In class 'org.eclipse.jdt.internal.compiler.ast.QualifiedTypeReference': org/eclipse/jdt/internal/compiler/ast/QualifiedTypeReference.java: In method 'org.eclipse.jdt.internal.compiler.ast.QualifiedTypeReference.getTypeBinding(org.eclipse.jdt.internal.compiler.lookup.Scope)': org/eclipse/jdt/internal/compiler/ast/QualifiedTypeReference.java:59: error: verification failed at PC=34: incompatible return type Works as expected in 4.1.1. -- Summary: [4.2 regression] gcj fails to binary-compile eclipse's javac Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bero at arklinux dot org GCC build triplet: i586-pc-linux-gnu GCC host triplet: i586-pc-linux-gnu GCC target triplet: i586-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28663
[Bug target/27827] [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #52 from whaley at cs dot utsa dot edu 2006-08-09 14:33 --- Paolo, >In some sense, this is the peephole I would rather *not* do. But the answer >is yes. :-) Ahh, got it :) >So, do you now agree that the bug would be fixed if the patch that is in GCC >4.2 was backported to GCC 4.1 (so that your users can use that)? Well, much as I might like to deny it, yes I must agree bug is fixed :) I think there might still be more performance to get, and initial timings show that 4 may be slower than 3 on some systems. However, it will also clearly be faster than 3 on some (so far, most) systems, and so far, is competitive everwhere, so not even I can call that a performance bug :) And yes, getting it into the next gcc release would be very helpful for ATLAS. >And do you still see the abysmal x87 single-precision FP performance? No, the problems were the same for both precisions. I haven't retimed all the systems, but here's the numbers I do have for the benchmark: DOUBLESINGLE PEAKgcc3/gccS/gcc4gcc3/gccS/gcc4 ==== Pentium-D : 28002359/2417/20672685/2684/2362 Ath64-X2 : 56003681/4011/21023716/4256/2207 Opteron : 32002590/2517/15072625/2800/1580 P4E : 28001767/1754/14801914/1954/1609 PentiumIII:500239/238/225 407/393/283 As you can see, on the benchmark, the single precision numbers are better than the double now. I cannot get single precision to run at quite the impressive 93% of peak as double when exercising the code generator on the Ath64-X2, but it gets a respectable 85% of peak (at these levels of performance, it takes only very minor differences to drop from 93 to 85, so that's not that unexpected: I am still investigating this). Thanks for all the help, Clint -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug fortran/28600] [4.2 regression] ICE on character pointer assignment
--- Comment #5 from jakub at gcc dot gnu dot org 2006-08-09 14:29 ---
It was caused by the openmp changes, but guess usually the parent routine
at least touches the dummy argument and therefore it would be added to the
right context.
I was testing:
--- trans-decl.c.jj 2006-08-09 15:39:36.0 +0200
+++ trans-decl.c2006-08-09 15:44:35.0 +0200
@@ -884,7 +884,10 @@ gfc_get_symbol_decl (gfc_symbol * sym)
if (TREE_CODE (length) == VAR_DECL
&& DECL_CONTEXT (length) == NULL_TREE)
{
- gfc_add_decl_to_function (length);
+ if (sym->ns->proc_name->backend_decl == current_function_decl)
+ gfc_add_decl_to_function (length);
+ else
+ gfc_add_decl_to_parent_function (length);
gfc_defer_symbol_init (sym);
}
}
before I saw Paul's patch on gcc-patches, guess both versions will DTRT.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28600
[Bug fortran/28600] [4.2 regression] ICE on character pointer assignment
--- Comment #4 from patchapp at dberlin dot org 2006-08-09 14:20 --- Subject: Bug number PR28600 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00266.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28600
[Bug fortran/28630] ICE due to a module function returning a derived type
--- Comment #3 from patchapp at dberlin dot org 2006-08-09 14:20 --- Subject: Bug number PR28630 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00265.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28630
[Bug fortran/28662] New: fpp call of gfortran: -traditional-cpp versus newer macros like #x
See http://gcc.gnu.org/ml/fortran/2006-08/msg00145.html Currently gfortran calls cpp with the option -traditional-cpp. Using this option, newer macros like #define msg(x) print *, #x don't work (the #x causes the argument to be quoted). (See url/email for example.) I couldn't find any standard for fpp. I assume that it is only a Fortran-aware CPP, which is defined in the C99 standard (ISO/IEC 9899:1999, section "6.10.3.2 The # operator"). I would expect that the newer constructs work by default with gfortran, or at least that one can force that mode. The first would simply mean to remove "-traditional-cpp" from the argument list. Other compilers: Sun Studio f95 and Intel Fortran Compiler both support #x by default. g95 and NAGware f95 seem to work as gfortran: msg(test) is converted into print *,#hello -- Summary: fpp call of gfortran: -traditional-cpp versus newer macros like #x Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28662
[Bug fortran/28600] [4.2 regression] ICE on character pointer assignment
-- 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-08-04 12:55:02 |2006-08-09 14:00:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28600
[Bug target/28247] [4.1/4.2 regression] libstdc++ cannot be build with Solaris threads
--- Comment #8 from jr at e-integration dot net 2006-08-09 13:52 --- Created an attachment (id=12046) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12046&action=view) gcc-4.1.1/gcc/gthr-solaris.h weak declaration Fails with latest gcc-4.1.1/gcc/gthr-solaris.h file during bootstrap. CONFIGURE: /gcc-4.1.1/configure sparc64-sun-solaris2.9 \ --prefix=/opt/compiler/GNU/gcc41/gcc-4.1.1 \ --with-gmp --with-mpfr \ --enable-threads=solaris \ --enable-static --enable-shared \ --enable-haifa --with-dwarf2 \ --enable-nls --with-cpu=v9 \ --with-included-gettext \ --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld \ --enable-languages=c,c++,objc,fortran Note: Using CPPFLAGS, CFLAGS, and CXXFLAGS for GMP and MPFR libraries/includes. MAKE BOOTSTRAP: make[4]: Leaving directory `/misc/reloc/root-unified/j/jtaisto/gcc-build/gcc' ./xgcc -B./ -B/opt/OIT/pkg/compiler/GNU/gcc41/gcc-4.1.1/sparc64-sun-solaris2.9/bin/ -isystem /opt/OIT/pkg/compiler/GNU/gcc41/gcc-4.1.1/sparc64-sun-solaris2.9/include -isystem /opt/OIT/pkg/compiler/GNU/gcc41/gcc-4.1.1/sparc64-sun-solaris2.9/sys-include -L/unified/j/jtaisto/gcc-build/gcc/../ld -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I -I/gcc-4.1.1/gcc -I/gcc-4.1.1/gcc/ -I/gcc-4.1.1/gcc/../include -I./../intl -I/gcc-4.1.1/gcc/../libcpp/include -Iyes/include -Iyes/include -fexceptions -c /gcc-4.1.1/gcc/unwind-dw2.c -o libgcc/./unwind-dw2.o In file included from ./gthr-default.h:1, from /gcc-4.1.1/gcc/gthr.h:114, from /gcc-4.1.1/gcc/unwind-dw2.c:42: /gcc-4.1.1/gcc/gthr-solaris.h:74: error: weak declaration of '__gthrw_thr_keycreate' must be public /gcc-4.1.1/gcc/gthr-solaris.h:75: error: weak declaration of '__gthrw_thr_getspecific' must be public /gcc-4.1.1/gcc/gthr-solaris.h:76: error: weak declaration of '__gthrw_thr_setspecific' must be public /gcc-4.1.1/gcc/gthr-solaris.h:77: error: weak declaration of '__gthrw_thr_create' must be public /gcc-4.1.1/gcc/gthr-solaris.h:78: error: weak declaration of '__gthrw_thr_self' must be public /gcc-4.1.1/gcc/gthr-solaris.h:80: error: weak declaration of '__gthrw_mutex_init' must be public /gcc-4.1.1/gcc/gthr-solaris.h:81: error: weak declaration of '__gthrw_mutex_destroy' must be public /gcc-4.1.1/gcc/gthr-solaris.h:82: error: weak declaration of '__gthrw_mutex_lock' must be public /gcc-4.1.1/gcc/gthr-solaris.h:83: error: weak declaration of '__gthrw_mutex_trylock' must be public /gcc-4.1.1/gcc/gthr-solaris.h:84: error: weak declaration of '__gthrw_mutex_unlock' must be public make[3]: *** [libgcc/./unwind-dw2.o] Error 1 make[3]: Leaving directory `/misc/reloc/root-unified/j/jtaisto/gcc-build/gcc' make[2]: *** [stmp-multilib] Error 2 make[2]: Leaving directory `/misc/reloc/root-unified/j/jtaisto/gcc-build/gcc' make[1]: *** [stage1_build] Error 2 make[1]: Leaving directory `/misc/reloc/root-unified/j/jtaisto/gcc-build/gcc' make: *** [bootstrap] Error 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28247
[Bug fortran/28660] Spurious warning: 'ubound.6' is used uninitialized in this function
--- Comment #2 from erik dot edelmann at iki dot fi 2006-08-09 10:54 --- (In reply to comment #1) > Actually this is worse than what is said here, this is wrong code. In a > prerelease of 4.1.0, we allocate r after we allocate x so the size of x is not > know at the time we allocate r. Ah, that explains the cray results I'm getting from my program! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28660
[Bug gcov/profile/28478] gcov is not demangling C++ names
--- Comment #2 from snordin_ng at yahoo dot fr 2006-08-09 10:39 --- Thanks for this astuteness. It's great and works well. Since we use lcov to obtain a suitable output in html format for class and method's coverage, I'll try to modify it using c++filt. I'll inform you about results. -- snordin_ng at yahoo dot fr changed: What|Removed |Added CC||snordin_ng at yahoo dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28478
[Bug rtl-optimization/20586] bootstrap comparision fails with -funroll-loops.
--- Comment #9 from pluto at agmk dot net 2006-08-09 10:36 --- the only "C" bootstrap still shows failures for 4.1.2. Bootstrap comparison failure! ./c-format.o differs ./combine.o differs ./expmed.o differs ./global.o differs ./i386.o differs ./reg-stack.o differs ./regclass.o differs ./reload1.o differs ./sbitmap.o differs ./simplify-rtx.o differs -- pluto at agmk dot net changed: What|Removed |Added Known to fail||4.1.2 Known to work||4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20586
[Bug fortran/28660] Spurious warning: 'ubound.6' is used uninitialized in this function
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-09 10:20 --- Actually this is worse than what is said here, this is wrong code. In a prerelease of 4.1.0, we allocate r after we allocate x so the size of x is not know at the time we allocate r. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |normal Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords|diagnostic |wrong-code Last reconfirmed|-00-00 00:00:00 |2006-08-09 10:20:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28660
[Bug fortran/28660] New: Spurious warning: 'ubound.6' is used uninitialized in this function
When compiling the code below with '-O -Wuninitialized', I get spurious warnings: piekana:~$ cat gforttest.f90 program runoptf90 implicit none real :: x(1) call simulated_annealing (x) contains subroutine simulated_annealing (xmin) real, intent(inout) :: xmin(:) real :: x(size(xmin)) real :: r(size(x)) xmin = r end subroutine simulated_annealing end program runoptf90 piekana:~$ gfortran42 -O -Wuninitialized gforttest.f90 gforttest.f90: In function 'MAIN__': gforttest.f90:6: warning: 'ubound.6' is used uninitialized in this function piekana:~$ gfortran42 --version GNU Fortran 95 (GCC) 4.2.0 20060729 (experimental) -- Summary: Spurious warning: 'ubound.6' is used uninitialized in this function Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: erik dot edelmann at iki dot fi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28660
[Bug middle-end/28651] signed compare incorrectly false for (int)(U+4)<(int)U where U is unsigned INT_MAX (for optimized x86)
--- Comment #8 from patchapp at dberlin dot org 2006-08-09 09:50 --- Subject: Bug number PR28651 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00247.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28651
[Bug rtl-optimization/20586] bootstrap comparision fails with -funroll-loops.
--- Comment #8 from pluto at agmk dot net 2006-08-09 09:45 --- works fine with 4.2.0-20060806 rev. 115974 on x86-64. current 4.1.2 build in progress... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20586
[Bug rtl-optimization/26847] [4.2 Regression] Missed optimization in simplify_plus_minus
--- Comment #2 from bonzini at gnu dot org 2006-08-09 07:42 --- Uhm, fixing this will resurface a wrong-code bug, PR28651, which is more important than this missed optimization. :-( -- bonzini at gnu dot org changed: What|Removed |Added BugsThisDependsOn||28651 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26847
[Bug rtl-optimization/28651] signed compare incorrectly false for (int)(U+4)<(int)U where U is unsigned INT_MAX (for optimized x86)
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-08-09 07:31 --- So, I have a fix as the problem is latent on mainline, too. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-08-08 16:06:27 |2006-08-09 07:31:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28651
