[Bug libgcj/27352] SecurityManager.checkPermission() called unnecessarily
--- Comment #3 from csm at gnu dot org 2006-05-01 06:41 --- It looks like methods internal to Class need to bypass the security manager when getting the class loader, or should be doing that lookup in a `doPriviliged' block, right? Does Classpath itself suffer from this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27352
[Bug bootstrap/27367] New: [4.2 Regression] gstdint.h in libdecnumber is not cleaned up with make distclean
Just filing a bug report based on what I see with a make distclean in the toplevel directory. -- Summary: [4.2 Regression] gstdint.h in libdecnumber is not cleaned up with make distclean Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27367
[Bug bootstrap/3415] make distclean (in gcc subdirectory) does not clean up all the way
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-01 06:25 --- I see the following files still present on the mainline with a cross compilers: ./gcc: total 488 -rw-r--r--1 pinskia pinskia1143 Mar 27 00:17 libada-mk drwxr-xr-x3 pinskia pinskia 102 Mar 27 00:17 ada drwxr-xr-x2 pinskia pinskia 68 Mar 27 00:17 treelang drwxr-xr-x2 pinskia pinskia 68 Mar 27 00:17 objcp drwxr-xr-x2 pinskia pinskia 68 Mar 27 00:17 fortran -rw-r--r--1 pinskia pinskia 130512 Mar 27 00:20 gengtype-lex.c -rw-r--r--1 pinskia pinskia 509 Mar 27 00:20 gengtype-yacc.h -rw-r--r--1 pinskia pinskia 37854 Mar 27 00:20 gengtype-yacc.c -rwxr-xr-x1 pinskia pinskia 21 Mar 27 00:20 collect-ld -rwxr-xr-x1 pinskia pinskia 21 Mar 27 00:20 as -rwxr-xr-x1 pinskia pinskia 21 Mar 27 00:20 nm -rw-r--r--1 pinskia pinskia 62 Mar 27 00:20 gcc-vers.texi -rw-r--r--1 pinskia pinskia 38947 Mar 27 00:20 fp-bit.c -rw-r--r--1 pinskia pinskia2879 Mar 27 00:22 insn-conditions.md drwxr-xr-x 26 pinskia pinskia 884 Mar 27 00:45 doc -rw-r--r--1 pinskia pinskia 403 Mar 27 00:46 insn-automata.c -rw-r--r--1 pinskia pinskia 171 Mar 27 00:54 gcov-iov.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3415
[Bug bootstrap/25470] [4.2 Regression] fixincludes/ subdirectory not cleaned by "make distclean"
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-01 06:24 --- 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-05-01 06:24:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25470
[Bug tree-optimization/23744] VRP does not merge discontinuous ranges of PHIs
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-01 06:19 --- PR 25643 shows why this is even more important than just the testcase below. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23744
[Bug tree-optimization/25643] VRP does not remove -fbounds-check for Fortran
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-01 06:18 ---
Grrr:
Visiting PHI node: i_3 = PHI ;
Argument #0 (4 -> 12 executable)
i_17
Value: [1, 1] EQUIVALENCES: { } (0 elements)
Argument #1 (13 -> 12 executable)
i_13
Value: [2, +INF] EQUIVALENCES: { } (0 elements)
so we have [1,1] UNION [2, +INF] and we just get ~[0,0] bogus
and it also means this is PR 23744.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||23744
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25643
[Bug target/27234] no way to stop gcc from mucking with the incoming argument stack
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-05-01 05:58
---
(In reply to comment #12)
> Can somebody please add a small standalone test case showing the problem here?
One is:
int g(int a, int b);
int f(int a, int b)
{
g(a, b);
return g(a, b);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27234
[Bug ada/27366] New: ada build fails as cygwin does not have clearenv
cygwin does not have the clearenv function, so ada compliation dies in ada/env.c. Testing a patch to use unsetenv path. -- Summary: ada build fails as cygwin does not have clearenv Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: billingd at gcc dot gnu dot org ReportedBy: billingd at gcc dot gnu dot org GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27366
[Bug target/27158] [4.1/4.2 regression] ICE in extract_insn with -maltivec
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-05-01 05:50
---
Hmm, maybe really this is just the RA playing tricks in that it should be able
to move
(insn 22 16 48 3 (set (reg:V4SI 126)
(vec_duplicate:V4SI (const_int 1 [0x1]))) 755 {altivec_vspltisw} (nil)
(expr_list:REG_EQUIV (const_vector:V4SI [
(const_int 1 [0x1])
(const_int 1 [0x1])
(const_int 1 [0x1])
(const_int 1 [0x1])
])
(nil)))
Back into the loop after the asm.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27158
[Bug target/27158] [4.1/4.2 regression] ICE in extract_insn with -maltivec
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-05-01 05:45 --- The problem here is that we don't recongize the constant is resepentable with vspltisw. Hmm. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27158
[Bug target/27234] no way to stop gcc from mucking with the incoming argument stack
--- Comment #12 from ian at airs dot com 2006-05-01 04:51 --- Can somebody please add a small standalone test case showing the problem here? Thanks. -- ian at airs dot com changed: What|Removed |Added CC||ian at airs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27234
[Bug translation/26987] German translation of gcc 4.1
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-01 03:46 --- (In reply to comment #5) > It's not that we need special casing for a certain language: The TP robot is > generally broken (doesn't respond to translator's requests). I reported it > there several times, to no avail. I think we only officially take stuff from the TP robot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26987
[Bug c++/26904] A template named the same as its member confuses lookup through inheritance
--- Comment #3 from dave at boost-consulting dot com 2006-05-01 02:43 --- I'm afraid I don't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26904
[Bug c++/27094] [4.0 Regression] tree check: expected tree_list, have omp_return in build_call
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|mark at codesourcery dot com|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27094
[Bug c++/26904] A template named the same as its member confuses lookup through inheritance
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-01 02:28 --- Do you have a shorter testcase? It is hard to figure out if this is valid code (though it does look like it is). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26904
[Bug c++/26534] [4.1] bitfield wrong optimize
--- Comment #10 from mmitchel at gcc dot gnu dot org 2006-05-01 02:18 --- Fixed in 4.1.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26534
[Bug c++/26534] [4.1] bitfield wrong optimize
--- Comment #9 from mmitchel at gcc dot gnu dot org 2006-05-01 02:18 --- Subject: Bug 26534 Author: mmitchel Date: Mon May 1 02:18:14 2006 New Revision: 113407 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113407 Log: PR c++/26534 * cp-tree.h (adjust_bitfield_initializer): Declare. * typeck.c (build_modify_expr): Use it. * typeck2.c (adjust_bitfield_initializer): Define. (process_init_constructor_record): Use it. PR c++/26534 * g++.dg/opt/bitfield1.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/opt/bitfield1.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/cp-tree.h branches/gcc-4_1-branch/gcc/cp/typeck.c branches/gcc-4_1-branch/gcc/cp/typeck2.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26534
[Bug fortran/26815] requires both arguments to ATAN2 to be of same type
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-01 01:51 --- (In reply to comment #2) > Does anyone oppose closing this report? No objections in one month so I am assuming it is ok to close this as invalid. -- 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=26815
[Bug c++/27094] [4.0 Regression] tree check: expected tree_list, have omp_return in build_call
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.1 |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27094
[Bug c++/27094] [4.0 Regression] tree check: expected tree_list, have omp_return in build_call
--- Comment #9 from mmitchel at gcc dot gnu dot org 2006-04-30 23:29 --- Fixed in 4.1.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 Regression]|[4.0 Regression] tree check: |tree check: expected|expected tree_list, have |tree_list, have omp_return |omp_return in build_call |in build_call | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27094
[Bug c++/27094] [4.0/4.1/4.2 Regression] tree check: expected tree_list, have omp_return in build_call
--- Comment #8 from mmitchel at gcc dot gnu dot org 2006-04-30 23:25 --- Subject: Bug 27094 Author: mmitchel Date: Sun Apr 30 23:25:44 2006 New Revision: 113400 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113400 Log: PR c++/27094 * pt.c (tsubst_default_argument): Increment function_depth around call to tsubst_expr. * parser.c (cp_parser_parameter_declaration): Likewise. PR c++/27094 * g++.dg/template/defarg8.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/defarg8.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/parser.c branches/gcc-4_1-branch/gcc/cp/pt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27094
[Bug c++/27094] [4.0/4.1/4.2 Regression] tree check: expected tree_list, have omp_return in build_call
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-04-30 23:21 --- Subject: Bug 27094 Author: mmitchel Date: Sun Apr 30 23:21:38 2006 New Revision: 113399 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113399 Log: PR c++/27094 * pt.c (tsubst_default_argument): Increment function_depth around call to tsubst_expr. * parser.c (cp_parser_parameter_declaration): Likewise. * decl2.c (mark_used): Tidy. PR c++/27094 * g++.dg/template/defarg8.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/defarg8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27094
[Bug libstdc++/6257] [DR 456] C-library symbols enter global namespace
--- Comment #25 from pinskia at gcc dot gnu dot org 2006-04-30 23:06 --- Suspending based on the Defect report being still open. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |SUSPENDED Summary|C-library symbols enter |[DR 456] C-library symbols |global namespace|enter global namespace http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257
[Bug libstdc++/6257] C-library symbols enter global namespace
--- Comment #24 from gdr at integrable-solutions dot net 2006-04-30 23:05 --- Subject: Re: C-library symbols enter global namespace "marc dot glisse at normalesup dot org" <[EMAIL PROTECTED]> writes: | (In reply to comment #20) | > the | > very same source code would not be be portable across those targets. I don't | > think we would like that. Besides, more generally, I'm not at all sure that | > all the users would actually *like* the new behavior. | | I meant proposing it as a choice, with a flag like -fclean-global-namespace That is a non-starter. PR better suspended. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257
Re: [Bug libstdc++/6257] C-library symbols enter global namespace
"marc dot glisse at normalesup dot org" <[EMAIL PROTECTED]> writes: | (In reply to comment #20) | > the | > very same source code would not be be portable across those targets. I don't | > think we would like that. Besides, more generally, I'm not at all sure that | > all the users would actually *like* the new behavior. | | I meant proposing it as a choice, with a flag like -fclean-global-namespace That is a non-starter. PR better suspended. -- Gaby
[Bug libgcj/27330] natSystemProperties.cc:213: error: 'getpwuid_r' was not declared in this scope
--- Comment #4 from andreast at gcc dot gnu dot org 2006-04-30 21:09 --- This one works too, found by Dave. --- configure.ac(revision 113252) +++ configure.ac(working copy) @@ -805,7 +805,7 @@ THREADLDFLAGS=-pthread THREADSPEC=-lpthread ;; - alpha*-dec-osf*) + alpha*-dec-osf* | hppa*-hp-hpux*) THREADCXXFLAGS=-pthread # boehm-gc needs some functions from librt, so link that too. THREADLIBS='-lpthread -lrt' We will submit once the libjava port is done on this arch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27330
[Bug fortran/27304] gfortran: Warn/abort when format in write does not fit passed arguments
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2006-04-30 21:02 --- Fixed on 4.1 and 4.2 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27304
[Bug fortran/27304] gfortran: Warn/abort when format in write does not fit passed arguments
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2006-04-30 21:02 --- Subject: Bug 27304 Author: jvdelisle Date: Sun Apr 30 21:02:10 2006 New Revision: 113398 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113398 Log: 2006-04-30 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/27304 * gfortran.dg/fmt_exhaust.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/fmt_exhaust.f90 Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27304
[Bug fortran/27304] gfortran: Warn/abort when format in write does not fit passed arguments
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2006-04-30 20:59 --- Subject: Bug 27304 Author: jvdelisle Date: Sun Apr 30 20:59:08 2006 New Revision: 113397 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113397 Log: 2006-04-30 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/27304 * io/transfer.c (formatted_transfer_scalar): Generate error if data descriptors are exhausted. * io/format.c (next_format0): Fix comment. Modified: branches/gcc-4_1-branch/libgfortran/ChangeLog branches/gcc-4_1-branch/libgfortran/io/format.c branches/gcc-4_1-branch/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27304
[Bug libfortran/27360] Memory leaks when reading logicals
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2006-04-30 19:55 --- Fixed on 4.1 and 4.2 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27360
[Bug libfortran/27360] Memory leaks when reading logicals
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-04-30 19:53 --- Subject: Bug 27360 Author: jvdelisle Date: Sun Apr 30 19:53:41 2006 New Revision: 113396 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113396 Log: 2006-04-30 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/27360 * io/list_read.c (read_logical): Free line_buffer and free saved. Modified: branches/gcc-4_1-branch/libgfortran/ChangeLog branches/gcc-4_1-branch/libgfortran/io/list_read.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27360
[Bug rtl-optimization/17104] Non-optimal code generation for bitfield initialization
--- Comment #9 from roger at eyesopen dot com 2006-04-30 19:52 --- *** Bug 13335 has been marked as a duplicate of this bug. *** -- roger at eyesopen dot com changed: What|Removed |Added CC||dje at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17104
[Bug rtl-optimization/13335] cse of sub-expressions of zero_extend/sign_extend expressions
--- Comment #9 from roger at eyesopen dot com 2006-04-30 19:52 --- This bug is a duplicate of PR17104 which was fixed by Nathan Sidwell in November 2004. If you read comment #4, you'll notice that the failure of CSE to handle the rs6000's rs6000_emit_move's zero_extends is identical. *** This bug has been marked as a duplicate of 17104 *** -- roger at eyesopen dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13335
[Bug tree-optimization/27364] [4.1/4.2 Regression] VRP miscompiles some unsigned math
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-04-30 19:44 --- The problem here is that 3321928 * 1294 wraps to 3607536 but VRP does not see it because 3607536 > 3321928. Oh how I hate wrapping. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27364
[Bug tree-optimization/27365] add a way to mark that a path cannot be taken, something like __builtin_unreachable()
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-30 19:34 --- Actually gcc_unreachable is to make sure that the compiler is constaint. Really marking a path as unreachable is the same thing as using __builtin_expect. -- 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=27365
[Bug tree-optimization/15911] VRP/DOM does not like TRUTH_AND_EXPR
--- Comment #28 from dann at godzilla dot ics dot uci dot edu 2006-04-30 19:25 --- Just a note, fixing the problem in this PR would fix the only remaining failure for cprop in Brigg's compiler benchmarks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15911
[Bug tree-optimization/27365] New: add a way to mark that a path cannot be taken, something like __builtin_unreachable()
It would be nice to have some form of a builtin that shows that a portion of the code is not reachable, and it generates no code in the binary. gcc_unreachable() is used now in the gcc sources for this, but it will generate assembly code that calls abort(). Another way to accomplish the same thing could be with attributes Can attributes be used for function calls? I beleive right now they can't. If they could, then something like this could work: myfunc(foo,bar,baz) __attribute__((noreturn)); Some functions are known not to return only in certain situations, so they cannot be declared as being "noreturn". An example where this would be useful is the Fsignal function in emacs. -- Summary: add a way to mark that a path cannot be taken, something like __builtin_unreachable() Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dann at godzilla dot ics dot uci dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27365
[Bug tree-optimization/27364] [4.1/4.2 Regression] VRP miscompiles some unsigned math
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27364
[Bug tree-optimization/27364] [4.1/4.2 Regression] VRP miscompiles some unsigned math
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-04-30 18:22 --- (In reply to comment #10) > Here is the reduced testcase: And guess what that testcase also fails in 4.1.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org Summary|[4.2 Regression] Gcc 4.2|[4.1/4.2 Regression] VRP |miscompiles binutils|miscompiles some unsigned ||math http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27364
[Bug tree-optimization/27364] [4.2 Regression] Gcc 4.2 miscompiles binutils
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-04-30 18:21
---
Here is the reduced testcase:
int f(unsigned number_of_digits_to_use)
{
if (number_of_digits_to_use >1294)
return 0;
return (number_of_digits_to_use * 3321928 / 100 + 1) /16;
}
int main(void)
{
if (f(11) != 2)
__builtin_abort ();
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27364
[Bug tree-optimization/27364] [4.2 Regression] Gcc 4.2 miscompiles binutils
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-04-30 18:17 ---
VRP is doing it:
D.2691_73 = number_of_digits_to_use_32 * 3321928;
D.2692_74 = D.2691_73 / 100;
more_than_enough_bits_for_digits_75 = D.2692_74 + 1;
D.2693_76 = more_than_enough_bits_for_digits_75 / 16;
more_than_enough_littlenums_for_digits_77 = D.2693_76 + 2;
size_of_digits_in_littlenums_78 = more_than_enough_littlenums_for_digits_77;
size_of_digits_in_chars_79 = more_than_enough_littlenums_for_digits_77 * 2;
Into:
D.2691_73 = number_of_digits_to_use_32 * 3321928;
D.2692_74 = D.2691_73 / 100;
more_than_enough_bits_for_digits_75 = D.2692_74 + 1;
D.2693_76 = more_than_enough_bits_for_digits_75 >> 4;
more_than_enough_littlenums_for_digits_77 = 2;
size_of_digits_in_littlenums_78 = 2;
size_of_digits_in_chars_79 = 4;
number_of_digits_to_use_32: [0, 1294] EQUIVALENCES: { } (0 elements)
Note this should not be turned into new until someone reduces it to a smaller
testcase.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|other |tree-optimization
GCC build triplet|x86_64-unknown-linux-gnu|
GCC host triplet|x86_64-unknown-linux-gnu|
GCC target triplet|x86_64-unknown-linux-gnu|
Keywords||wrong-code
Summary|Gcc 4.2 miscompiles binutils|[4.2 Regression] Gcc 4.2
||miscompiles binutils
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27364
[Bug other/27364] Gcc 4.2 miscompiles binutils
-- hjl at lucon dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|2006-04-30 18:11:21 |2006-04-30 18:11:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27364
[Bug libfortran/27360] Memory leaks when reading logicals
--- Comment #5 from eedelman at gcc dot gnu dot org 2006-04-30 18:05 --- (In reply to comment #4) > Subject: Bug number PR27360 > > 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-04/msg01152.html > Works for me. Thanks for the quick fix! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27360
[Bug c++/27094] [4.0/4.1/4.2 Regression] tree check: expected tree_list, have omp_return in build_call
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27094
[Bug c++/26757] [4.1/4.2 regression] C++ front-end producing two DECLs with the same UID
--- Comment #18 from mmitchel at gcc dot gnu dot org 2006-04-30 17:56 --- Andrew -- Thanks for investigating this, and for attempting to tolerate this bit of weirdness from the front end. -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26757
[Bug other/27364] Gcc 4.2 miscompiles binutils
--- Comment #8 from hjl at lucon dot org 2006-04-30 17:55 --- Created an attachment (id=11350) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11350&action=view) A testcase [EMAIL PROTECTED] gas]$ /export/build/gnu/gcc-last/build-x86_64-linux/./prev-gcc/xgcc -B/export/build/gnu/gcc-last/build-x86_64-linux/./prev-gcc/ -O2 foo.c [EMAIL PROTECTED] gas]$ ./a.out Aborted -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27364
[Bug c++/24561] no static definition at -O0
--- Comment #10 from mark at codesourcery dot com 2006-04-30 16:50 --- Subject: Re: no static definition at -O0 hubicka at gcc dot gnu dot org wrote: > I don't quite see reason for outputting unneeded static functions even at -O0 > that it mostly just slows down the compilation process, but I am testing patch > that makes cgraph believe that every function passed to it should be output > unless it is extern inline and will post it for consideration once testing > converge. The reason for emitting all static functions at -O0 is that, historically, most compilers have done that. People tend to call these functions from the debugger. Of course, in GCC, we have attributes to say that a function should be kept, even though it's static, but some other compilers don't, so people tend to rely on the fact that these functions are emitted when optimization is disabled. We could document that GCC no longer keeps static functions at -O0. As you say, dropping these functions should improve compile times, although we don't really know by how much. My guess would be that there aren't very many unnecessary static functions. Please do be careful that your patch doesn't cause cgraph to emit all COMDAT functions. COMDAT functions (or weak/linkonce) functions should not be emitted at -O0, if they are not needed, because there tend to be *tons* of them; that would probably impact compile-time a lot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24561
[Bug c++/27339] [4.1/4.2 Regression] out-of-class definition of value template parameter with private type
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-30 16:29 --- Confirmed. Janis, could you do a regression hunt on this bug? Thanks. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-30 16:29:22 date|| Summary|[4.1/4.2 Regression]out-of- |[4.1/4.2 Regression] out-of- |class definition of value |class definition of value |template parameter with |template parameter with |private type|private type http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27339
[Bug target/27333] internal compiler error: Segmentation fault
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-30 16:25 --- This works for me and many other people. You have to be doing something different (and since you did not follow directions of supplying the configure options it is hard to tell). Also you did not see if it passes again after running it again which is going to be a sign of bad memory/hardware. Anyways this works for many other people so closing as invalid. -- 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=27333
[Bug other/27364] Gcc 4.2 miscompiles binutils
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-30 15:57 --- Note I think Jeff's patch just exposed a bug. Now since we don't have a testcase this is going to put into WAITING until we have one. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27364
[Bug other/27364] Gcc 4.2 miscompiles binutils
--- Comment #6 from hjl at lucon dot org 2006-04-30 15:33 --- Hi Jeff, It looks like your patch http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01386.html causes gcc 4.2 miscompiles binutils on Linux/x86 and Linux/x86-64. -- hjl at lucon dot org changed: What|Removed |Added CC||law at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27364
[Bug debug/26881] [4.1/4.2 Regression] internal compiler error in dwarf2out_finish
--- Comment #8 from hubicka at gcc dot gnu dot org 2006-04-30 14:30 --- Jakub, adding a worklist and passing all variables to dwarf2out as last it quite easy to do. However could you enlighten me a bit why the particular order is needed? Honza -- hubicka at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26881
[Bug other/27364] Gcc 4.2 miscompiles binutils
--- Comment #5 from hjl at lucon dot org 2006-04-30 14:25 --- Andrew, I tried my best to find a testcase. The best I can do so far is to put a testcase in binutils so that when you build binutils with gcc 4.2 on Linux/x86 and Linux/x86-64, you will get an "make check" failure in gas. I don't think anyone should have serious problems to get binutils from CVS. If you don't think I should open this bug, just let me know. I will close it and open a new one when I find a small testcase. BTW, there was a typo in my email, it is when number_of_digits_to_use == 11, gcc 4.2 gets 4 for (number_of_digits_to_use * 3321928 / 100 + 1) when -O2 is used. From assembler code, it always gets 4 no matter what number_of_digits_to_use is. -- hjl at lucon dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27364
[Bug rtl-optimization/17234] if-conversion bug on x86
--- Comment #6 from hubicka at gcc dot gnu dot org 2006-04-30 14:24 --- Sorry, I've must missed the two pings and noticed the problem only now while housekeeping. There is no easy way to peek cfglayout about what decisions it will do in future, so there is no easy way to decide whether to duplicate or not. I am not sure if this is important enought, but if we really care, we might consider if-conversion to do the duplication itself for really small blocks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17234
[Bug c++/24561] no static definition at -O0
--- Comment #9 from hubicka at gcc dot gnu dot org 2006-04-30 13:56 --- Concerning the comments, unit-at-a-time is not optimization, it is just way overall compilation is driven. I don't quite see reason for outputting unneeded static functions even at -O0 that it mostly just slows down the compilation process, but I am testing patch that makes cgraph believe that every function passed to it should be output unless it is extern inline and will post it for consideration once testing converge. Honza -- hubicka at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24561
[Bug middle-end/25962] Pointer (null) check after the use in cgraph.c
--- Comment #4 from hubicka at gcc dot gnu dot org 2006-04-30 13:48 --- testing patch. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25962
[Bug middle-end/17876] Attribute "noinline" should be fully moved into cgraph
--- Comment #2 from hubicka at gcc dot gnu dot org 2006-04-30 13:45 --- Good point, I think I can do that easilly once mainline reopens. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17876
[Bug middle-end/24729] function calls created by builtins do not make use of inline definitions
--- Comment #7 from hubicka at gcc dot gnu dot org 2006-04-30 13:35 --- I should probably also note that IPA branch will get it right in the testcase (and the other PR) via early inlining, but it sadly won't get it right in any consistent manner... Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24729
[Bug middle-end/24729] function calls created by builtins do not make use of inline definitions
--- Comment #6 from hubicka at gcc dot gnu dot org 2006-04-30 13:33 --- This is probably won't fix as well. The problem is that calls to builtins in general can be produced arbitrarily late in the compilation process (before RTL expansion). We might try to do limited inliner pass specializing to extern inlines late in compilation but at the moment this is undoable because at that moment we are in SSA and having extern inlines released from memory. On IPA branch we can get further but with all the aliasing datastructures built plus the fact that extern inline builtins might in general have totally inexpected behaviour, I think it is rather dangerous to implement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24729
[Bug middle-end/25776] [4.2 Regression] ICE in cgraph after error at -O1 and above
--- Comment #9 from hubicka at gcc dot gnu dot org 2006-04-30 13:27 --- Both patches (comment #7 and comment #8) are OK assuming they pass testing (that is rather obvious). Thanks, Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25776
[Bug c++/27278] [4.0/4.1/4.2 regression] ICE with invalid operator declaration
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-04-30 10:47 --- Fixed on mainline, 4.1 branch, and 4.0 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27278
[Bug c++/27278] [4.0/4.1/4.2 regression] ICE with invalid operator declaration
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-04-30 10:40 --- Subject: Bug 27278 Author: reichelt Date: Sun Apr 30 10:40:18 2006 New Revision: 113391 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113391 Log: PR c++/27278 * decl.c (grok_op_properties): Skip operators with invalid args when checking for class-type or enum-type args. * g++.dg/parse/operator7.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/parse/operator7.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/decl.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27278
[Bug c++/27278] [4.0/4.1/4.2 regression] ICE with invalid operator declaration
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-04-30 10:37 --- Subject: Bug 27278 Author: reichelt Date: Sun Apr 30 10:37:24 2006 New Revision: 113390 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113390 Log: PR c++/27278 * decl.c (grok_op_properties): Skip operators with invalid args when checking for class-type or enum-type args. * g++.dg/parse/operator7.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/operator7.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/decl.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27278
[Bug c++/27278] [4.0/4.1/4.2 regression] ICE with invalid operator declaration
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-04-30 10:34 --- Subject: Bug 27278 Author: reichelt Date: Sun Apr 30 10:34:05 2006 New Revision: 113389 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113389 Log: PR c++/27278 * decl.c (grok_op_properties): Skip operators with invalid args when checking for class-type or enum-type args. * g++.dg/parse/operator7.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/operator7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27278
[Bug other/27364] Gcc 4.2 miscompiles binutils
--- Comment #4 from dirtyepic dot sk at gmail dot com 2006-04-30 09:59 --- Here is the testcase: dirtyepic ~ $ cat pr27364.S .tfloat 1.442695040888963407359924681002 dirtyepic ~ $ gcc pr27364.S pr27364.S: Assembler messages: pr27364.S:1: Fatal error: failed sanity check This is from sysdeps/x86_64/fpu/s_expm1l.S:40 in glibc. It produces the error when we attempt to compile glibc with a binutils-2.16.91.0.* or 2.16.92 built with GCC trunk. x86_64-pc-linux-gnu-gcc ../sysdeps/x86_64/fpu/s_expm1l.S -c -D__NO_MATH_INLINES -D__LIBC_INTERNAL_MATH_INLINES -I../include -I/var/tmp/portage/glibc-2.4-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/math -I/var/tmp/portage/glibc-2.4-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl -I../sysdeps/x86_64/elf -I../nptl/sysdeps/unix/sysv/linux/x86_64 -I../sysdeps/unix/sysv/linux/x86_64 -I../sysdeps/unix/sysv/linux/wordsize-64 -I../ports/sysdeps/unix/sysv/linux -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../ports/sysdeps/unix/sysv -I../nptl/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../sysdeps/unix/x86_64 -I../ports/sysdeps/unix -I../nptl/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/x86_64/fpu -I../nptl/sysdeps/x86_64 -I../sysdeps/x86_64 -I../sysdeps/wordsize-64 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../ports -I../nptl -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.0-pre20060421/include -isystem /usr/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DNOT_IN_libc=1 -DIS_IN_libm=1-DASSEMBLER -Wa,--noexecstack -Wa,--noexecstack -o /var/tmp/portage/glibc-2.4-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/s_expm1l.o -MD -MP -MF /var/tmp/portage/glibc-2.4-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/s_expm1l.o.dt -MT /var/tmp/portage/glibc-2.4-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/s_expm1l.o ../sysdeps/x86_64/fpu/s_expm1l.S: Assembler messages: ../sysdeps/x86_64/fpu/s_expm1l.S:40: Fatal error: failed sanity check Glibc is 2.4, configured with: configure --disable-nls --disable-stackguard-randomization --enable-old-ssp-compat --enable-omitfp --with-tls --with-__thread --enable-add-ons=ports,nptl,c_stubs,libidn --enable-kernel=2.6.11 --without-selinux --without-cvs --enable-bind-now --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --disable-profile --without-gd --with-headers=/usr/include --prefix=/usr --libdir=/usr/lib64 --mandir=/usr/share/man --infodir=/usr/share/info --libexecdir=/usr/lib64/misc/glibc Binutils is 2.16.92, configured with: configure --prefix=/usr --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --datadir=/usr/share/binutils-data/x86_64-pc-linux-gnu/2.16.92 --infodir=/usr/share/binutils-data/x86_64-pc-linux-gnu/2.16.92/info --mandir=/usr/share/binutils-data/x86_64-pc-linux-gnu/2.16.92/man --bindir=/usr/x86_64-pc-linux-gnu/binutils-bin/2.16.92 --libdir=/usr/lib64/binutils/x86_64-pc-linux-gnu/2.16.92 --libexecdir=/usr/lib64/binutils/x86_64-pc-linux-gnu/2.16.92 --includedir=/usr/lib64/binutils/x86_64-pc-linux-gnu/2.16.92/include --enable-64-bit-bfd --enable-shared --disable-werror --disable-nls --build=x86_64-pc-linux-gnu and GCC is 20060428 svn: Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/gcc-4.2.0_pre20060428/work/gcc-4.2.0-20060428/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.2.0-pre20060428 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.0-pre20060428/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.2.0-pre20060428 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.2.0-pre20060428/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.2.0-pre20060428/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.0-pre20060428/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-nls --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --disable-multilib --disable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.2.0-pre20060428 (experimental) We're not the first to hit it. See: http://thread.gmane.org/gmane.comp.gnu.binutils/26989/ What other information will help? -- dirtyepic dot sk at gmail dot com changed: What|Removed |Added CC|
[Bug target/27363] ARM gcc 4.1 optimization bug
--- Comment #4 from yfw dot debian at gmail dot com 2006-04-30 09:09 --- I tried the gcc 4.1.1 snapshot 20060421. The bug still there. The assembly code producted with -Os option is the same as gcc 4.1.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27363
[Bug c/27273] [4.2 regression] tree check fail for legal code when convert returns a constant from an expression that was not constant
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-30 08:04 --- This patch works for me (I have not fully test it yet though): Index: c-common.c === --- c-common.c (revision 113388) +++ c-common.c (working copy) @@ -1080,7 +1080,8 @@ convert_and_check (tree type, tree expr) /* Do not diagnose overflow in a constant expression merely because a conversion overflowed. */ - TREE_CONSTANT_OVERFLOW (t) = TREE_CONSTANT_OVERFLOW (expr); + if (TREE_CODE (expr) == INTEGER_CST) + TREE_CONSTANT_OVERFLOW (t) = TREE_CONSTANT_OVERFLOW (expr); /* No warning for converting 0x8000 to int. */ if (!(TYPE_UNSIGNED (type) < TYPE_UNSIGNED (TREE_TYPE (expr)) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27273
[Bug other/27156] SIGSEGV in operator delete() / wrong-code?
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-30 08:02 --- The testcase works for me as I don't have the STLport installed (and what is in this bug is not enough to reproduce the bug). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27156
[Bug c++/27141] [4.0/4.1/4.2 Regression] Unexpected requirement for usual deallocation function
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-30 07:57 --- I am thinking this is the ABI getting in the way of the C++ standard. In that the secondary ~D() is getting in the way. The reason I say that is because it worked with the old ABI in 2.95.3. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Known to fail||3.0.4 4.0.0 4.1.0 3.4.0 ||3.3.3 Known to work||2.95.3 Last reconfirmed|-00-00 00:00:00 |2006-04-30 07:57:28 date|| Summary|Unexpected requirement for |[4.0/4.1/4.2 Regression] |usual deallocation function |Unexpected requirement for ||usual deallocation function Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27141
[Bug c/27120] Should warn about uninitialized use of variable array element
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-30 07:47 --- (In reply to comment #0) [first testcase using nonconstant index] > > does not warn about the use of uninitialized array buffer. While > [second testcase using constant index] > > does. Likewise for C++. In the second example, SRA works on the array, scalarizes the array which allows for the current initialization warning to happen. Now maybe we should do the uninitialization warning in the front-end. -- 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-04-30 07:47:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27120
[Bug middle-end/27002] ICE with -fipa-pta when calling a function
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-30 07:44 --- Confirmed, but since the Fortran compiler has some issues with creating DECLs refering to the same function, it might become hard to fix this without a front-end fix. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-30 07:44:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27002
[Bug c/26732] Accepts invalid code at different optimization levels.
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-30 07:39 --- 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-04-30 07:39:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26732
[Bug bootstrap/26718] Bootstrap 4.1.0 fails on Apple Power G5
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-30 07:37 --- Well this works for me and others with the normal cctools so closing as invalid. -- 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=26718
[Bug other/27364] Gcc 4.2 miscompiles binutils
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-30 07:35 --- http://gcc.gnu.org/ml/gcc/2006-04/msg00577.html I don't even see how you can get 37 in general in this case. I can see 34 but not 37. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27364
[Bug middle-end/27321] Compare against constant infinity fails with IBM long double format
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-30 07:33 --- Actually I am wrong in saying it worked. I usually forget to test the return value as I assume people use abort to signal a failure. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|powerpc-apple-darwin8 |powerpc*-*-* Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2006-04-30 07:33:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27321
[Bug other/27364] Gcc 4.2 miscompiles binutils
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-30 07:25 --- You are wrong. When number_of_digits_to_use is 1, we get: 3321928 / 100 Which is equal to 3 And then add 1. Try again please. -- 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=27364
[Bug other/27364] Gcc 4.2 miscompiles binutils
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-30 07:14 --- Testcase? You know this is the nth bug you have filed without a testcase and every time someone gets upset because you don't follow directions. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|Gcc 4.2 miscompiles binutils|Gcc 4.2 miscompiles binutils |on Linux/x86 and Linux/x86- | |64 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27364
[Bug other/27364] New: Gcc 4.2 miscompiles binutils
Gcc 4.2 miscompiles binutils on Linux/x86 and Linux/x86-64. When gcc 4.2 is used, "make check" in binutils from CVS will have one failure in gas. The problem is more_than_enough_bits_for_digits = (number_of_digits_to_use * 3321928 / 100 + 1); around line 347 in gas/atof-generic.c is computed as 4 when -O2 is used. -- Summary: Gcc 4.2 miscompiles binutils Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27364
