[Bug pending/27971] New: eliminate shift in array[(x2)3]
array[(x2)3] can be arranged to avoid the right shift.
consider:
% cat shift-and-fold.c
unsigned array[4];
unsigned foo(unsigned long x)
{
return array[(x2)3ul];
}
% /home/odo/gcc/bin/gcc -g -O3 -Wall -c -o shift-and-fold.o shift-and-fold.c
% objdump -dr shift-and-fold.o
shift-and-fold.o: file format elf64-x86-64
Disassembly of section .text:
foo:
0: 48 c1 ef 02 shr$0x2,%rdi
4: 83 e7 03and$0x3,%edi
7: 8b 04 bd 00 00 00 00mov0x0(,%rdi,4),%eax
a: R_X86_64_32S array
e: c3 retq
could be:
and $0xc,%edi
mov 0(%rdi),%eax
gcc does the right thing when the left shift isn't part of an address...
thanks
-dean
% /home/odo/gcc/bin/gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../gcc/configure --prefix=/home/odo/gcc
--host=x86_64-linux-gnu --disable-multilib --enable-languages=c,c++
--disable-bootstrap
Thread model: posix
gcc version 4.2.0 20060603 (experimental)
--
Summary: eliminate shift in array[(x2)3]
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: pending
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dean at arctic dot org
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27971
[Bug target/27971] eliminate shift in array[(x2)3]
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-09 06:18 ---
This works correctly on powerpc. The rtl we get on x86_64 is:
(insn 10 7 11 2 (parallel [
(set (reg:DI 61)
(lshiftrt:DI (reg/v:DI 59 [ x ])
(const_int 2 [0x2])))
(clobber (reg:CC 17 flags))
]) 456 {*lshrdi3_1_rex64} (insn_list:REG_DEP_TRUE 6 (nil))
(expr_list:REG_DEAD (reg/v:DI 59 [ x ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 11 10 13 2 (parallel [
(set (reg:DI 62)
(and:DI (reg:DI 61)
(const_int 3 [0x3])))
(clobber (reg:CC 17 flags))
]) 297 {*anddi_1_rex64} (insn_list:REG_DEP_TRUE 10 (nil))
(expr_list:REG_DEAD (reg:DI 61)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 13 11 17 2 (set (reg:SI 64)
(mem/s:SI (plus:DI (mult:DI (reg:DI 62)
(const_int 4 [0x4]))
(symbol_ref:DI (array) var_decl 0x2af4bbb0 array)) [3
array S4 A32])) 40 {*movsi_1} (insn_list:REG_DEP_TRUE 11 (nil))
(expr_list:REG_DEAD (reg:DI 62)
(nil)))
so I wonder if the something is not being reduced correctly.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|pending |target
Ever Confirmed|0 |1
GCC host triplet|x86_64-linux-gnu|
Last reconfirmed|-00-00 00:00:00 |2006-06-09 06:18:37
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27971
[Bug target/27971] eliminate shift in array[(x2)3]
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-09 06:20 ---
Here is the RTL we get on PPC:
(insn 6 9 7 2 (set (reg/v:SI 120 [ x ])
(reg:SI 3 r3 [ x ])) 327 {*movsi_internal1} (nil)
(expr_list:REG_DEAD (reg:SI 3 r3 [ x ])
(expr_list:REG_EQUIV (mem/c/i:SI (plus:SI (reg/f:SI 67 ap)
(const_int 24 [0x18])) [4 x+0 S4 A32])
(nil
...
(insn 13 12 14 2 (set (reg:SI 124)
(lshiftrt:SI (reg/v:SI 120 [ x ])
(const_int 2 [0x2]))) 195 {lshrsi3_no_power}
(insn_list:REG_DEP_TRUE 6 (nil))
(expr_list:REG_DEAD (reg/v:SI 120 [ x ])
(nil)))
(insn 14 13 15 2 (parallel [
(set (reg:SI 125)
(and:SI (reg:SI 124)
(const_int 3 [0x3])))
(clobber (scratch:CC))
]) 146 {andsi3} (insn_list:REG_DEP_TRUE 13 (nil))
(expr_list:REG_DEAD (reg:SI 124)
(expr_list:REG_UNUSED (scratch:CC)
(nil
(insn 15 14 17 2 (set (reg:SI 126)
(ashift:SI (reg:SI 125)
(const_int 2 [0x2]))) 189 {ashlsi3_no_power}
(insn_list:REG_DEP_TRUE 14 (nil))
(expr_list:REG_DEAD (reg:SI 125)
(nil)))
Which gets reduced to:
(insn 15 14 17 2 (parallel [
(set (reg:SI 126)
(and:SI (reg:SI 3 r3 [ x ])
(const_int 12 [0xc])))
(clobber (scratch:CC))
]) 146 {andsi3} (nil)
(expr_list:REG_UNUSED (scratch:CC)
(expr_list:REG_DEAD (reg:SI 3 r3 [ x ])
(nil
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27971
[Bug fortran/27786] [4.1 only] Bad interaction between Cray pointer, assumed-size array and bounds checking
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-06-09 06:43 --- I'm reopening the PR because the bug is not fixed yet on the 4.1 branch. The current policy is to allow a week before comitting your patch to 4.1 (after bootstrap regtesting), and then close the bugzilla PR. (in case you need info on how to use svn to backport a patch, you can read http://gcc.gnu.org/wiki/SvnMerge) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Keywords||patch Known to fail||4.1.2 Known to work||4.2.0 Resolution|FIXED | Summary|Bad interaction between Cray|[4.1 only] Bad interaction |pointer, assumed-size array |between Cray pointer, |and bounds checking |assumed-size array and ||bounds checking http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27786
[Bug fortran/27965] gfortran gives Array bound mismatch for valid program
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-06-09 06:53 --- My patch at http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00364.html fixes this problem (I noted it during while designing the patch, but didn't fill a PR because I knew it would be fixed soon :) Thanks Tobias for your help testing -fbounds-check, I hope in the next few weeks we can make it feature-full and bug-free :) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||27766 nThis|| AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||06/msg00364.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2006-06-09 06:53:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27965
[Bug ada/27937] [4.2 Regression] Ada bootstrap failure on Solaris 10/x86
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 Version|unknown |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27937
[Bug middle-end/27896] inefficient lowering for return
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-09 07:25 --- 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-06-09 07:25:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27896
[Bug c/27899] Compile warning with --combine and global register variables.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-09 07:31 --- --combine is not tested that well. In fact for this case, the decls should be combined into one and not warned about but it looks like GCC combines these two variables. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27899
[Bug fortran/27897] ICE on common block with the same name as the program.
-- 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=27897
[Bug middle-end/27889] [4.1/4.2 Regression] ICE on complex assignment in nested function
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-06-09 07:37 --- (In reply to comment #10) implicit COMPLEX (a-z) Does that actually declare the variables in MAIN or just say after the first use, they are declared in that function as complex? (this should be noted as a seperate bug if it really should declared the variables in the program instead of the function). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27889
[Bug target/27922] final link failed: Nonrepresentable section on output
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27922
[Bug ada/27936] [4.2 Regression] gnatbind fails to link on Tru64 UNIX
-- 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=27936
[Bug ada/27944] [4.2 Regression] s-taprop.adb:66:06: warning: redundant with clause in body
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build Summary|s-taprop.adb:66:06: warning:|[4.2 Regression] s- |redundant with clause in|taprop.adb:66:06: warning: |body|redundant with clause in ||body Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27944
[Bug middle-end/27945] [4.0/4.1/4.2 Regression] Packed struct of variable length has wrong size
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-06-09 07:45 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed|0 |1 Known to fail||3.4.0 4.0.0 4.1.0 4.2.0 Known to work||3.3.3 Last reconfirmed|-00-00 00:00:00 |2006-06-09 07:45:54 date|| Summary|Packed struct of variable |[4.0/4.1/4.2 Regression] |length has wrong size |Packed struct of variable ||length has wrong size Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27945
[Bug bootstrap/27963] [4.2 Regression] libjava fails to build if it isn't built by default
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27963
[Bug fortran/27958] [4.1 only] assignments to and from zero-sized string selections not handled
-- 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=27958
[Bug debug/27970] error while compiling ClanLib-0.8
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-09 07:49 --- Can you also attach the preprocessed source? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27970
[Bug bootstrap/27963] [4.2 Regression] libjava fails to build if it isn't built by default
-- ayers at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ayers at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-09 07:57:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27963
[Bug bootstrap/27963] [4.2 Regression] libjava fails to build if it isn't built by default
--- Comment #6 from ayers at gcc dot gnu dot org 2006-06-09 08:01 --- Patch posted at: http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00410.html and waiting for approval. -- ayers at gcc dot gnu dot org changed: What|Removed |Added CC|d dot ayers at inode dot at | Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27963
[Bug target/27212] vec_cmplt followed by a vec_all_ge, gives two vcmpgtuh instructions
--- Comment #5 from bonzini at gnu dot org 2006-06-09 08:15 --- I'll give it a shot. If combine could, well, combine the two instructions, it would be quite easy to make a patch, and it would remove some most hackish aspects of the Altivec implemention. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27212
[Bug middle-end/27889] [4.1/4.2 Regression] ICE on complex assignment in nested function
--- Comment #12 from paul dot richard dot thomas at cea dot fr 2006-06-09 08:50 --- (In reply to comment #11) (In reply to comment #10) implicit COMPLEX (a-z) Does that actually declare the variables in MAIN or just say after the first use, they are declared in that function as complex? (this should be noted as a seperate bug if it really should declared the variables in the program instead of the function). They are declared in MAIN and the type information should be host associated to the variables in the function. According to the gfortran parse tree, this is happening correctly: $ /irun/bin/gfortran -fdump-parse-tree pr27889.f90 Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4) procedure name = MAIN__ symtree: t Ambig 0 symbol t (COMPLEX 4)(VARIABLE UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC ) symtree: foo Ambig 0 symbol foo (UNKNOWN 0)(PROCEDURE UNKNOWN-INTENT UNKNOWN-ACCESS INTERNAL- PROC SUBROUTINE) symtree: MAIN__ Ambig 0 symbol MAIN__ (UNKNOWN 0)(PROCEDURE UNKNOWN-INTENT PUBLIC UNKNOWN-PROC S UBROUTINE) symtree: s Ambig 0 symbol s (COMPLEX 4)(VARIABLE UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC ) CALL foo () CONTAINS Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4) procedure name = foo symtree: foo Ambig 0 from namespace MAIN__ ASSIGN MAIN__:t (+ MAIN__:s MAIN__:s) pr27889.f90: In function 'foo': pr27889.f90:2: error: invalid operand to binary operator D.907 pr27889.f90:2: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. This is rather like that parameter bug, isn't it, Andrew? ie. type information is not getting correctly broadcast to enclosed procedure blocks. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27889
[Bug target/27959] [4.1 regression] s390x miscompilation due to clobbering literal pool base reg
--- Comment #2 from jakub at gcc dot gnu dot org 2006-06-09 08:56 --- Works just fine in GCC 3.4.x (in that case with -O2 -mtune=z990 which fails in 4.1.x as well) and works on the trunk too (but it is unclear whether that's just because reload chooses different registers by accident or if the problem has been really fixed). -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|s390x miscompilation due to |[4.1 regression] s390x |clobbering literal pool base|miscompilation due to |reg |clobbering literal pool base ||reg http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27959
[Bug ada/27936] [4.2 Regression] gnatbind fails to link on Tru64 UNIX
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-06-09 09:06 --- I ran into it some time ago too. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-09 09:06:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27936
[Bug ada/27937] [4.2 Regression] Ada bootstrap failure on Solaris 10/x86
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-06-09 09:08 --- Confirmed, this happens when the compiler is configured for SJLJ exceptions. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-09 09:08:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27937
[Bug bootstrap/26998] bootstrap failure building libdecnumber, ICE in compare_values, tree-vrp.c:432
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-06-09 09:34 --- This no longer blocks 27116 because I was able to fix that differently. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO|27116 | nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26998
[Bug c++/27129] [4.1/4.2 Regression] ICE in get_expr_operands
--- Comment #7 from jakub at gcc dot gnu dot org 2006-06-09 09:42 --- This has been fixed by the PR20103 changes. *** This bug has been marked as a duplicate of 20103 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27129
[Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer
--- Comment #55 from jakub at gcc dot gnu dot org 2006-06-09 09:42 --- *** Bug 27129 has been marked as a duplicate of this bug. *** -- jakub 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=20103
[Bug target/27082] segfault with virtual class and visibility (hidden)
--- Comment #13 from tbm at cyrius dot com 2006-06-09 09:57 --- This segfault also shows up when compiling thunderbird-1.5.0.2 with gcc 4.2 on Alpha. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27082
[Bug testsuite/27707] g++.dg/tree-ssa/ivopts-1.C fails
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-06-09 10:24 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27707
[Bug tree-optimization/27039] [4.1 Regression] Unable to determine # of iterations for a simple loop
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rguenth at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27039
[Bug middle-end/26630] [4.0 Regression] Incorrect result when subtracting, casting to short and back to int, adding and multiplying
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rguenth at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26630
[Bug c++/27975] New: warning for comparison of different enum types impossible to control/is undocumented
gcc/cp/call.c build_now_op, emits a warning for comparison of different enum types. It seems to be neither controlled by any warning option nor documented. I don't want to fix all thoose warnings (a large amount in our code) right now, and at the same time turn on -Werror and fix other warnings. This is impossible right now. -- Summary: warning for comparison of different enum types impossible to control/is undocumented Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: patrik dot hagglund at bredband dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27975
[Bug target/27959] [4.1 regression] s390x miscompilation due to clobbering literal pool base reg
--- Comment #3 from krebbel at gcc dot gnu dot org 2006-06-09 11:41 ---
On s390 we use a trick to make the literal pool base register
available on demand. It is defined as eliminable register
which can be eliminated to itself with offset 0. When a reload round
finds a r13 (literal pool base) it asks the back end whether it can
be eliminated and the back end says no. So reload throws any pseudos
out of r13 and marks it as bad_spill_regs_global hence it won't be
used as a reload register.
In your example there is no literal pool reference when entering reload.
So the initial elimination step marks r13 as eliminable and therefore free
to be used in reloads and it actually is used in a reload. In the second
round reload forces a constant into the literal pool what creates a
literal pool reference. When update_eliminables is called r13 is marked
as cant_eliminate and the respective bit in bad_spill_regs_global is set.
So far so good.
Unfortunately reload seems to think that registers which were once good to
be used in reloads will be good for future reloads as well - thats my
impression at least. The bitmap used_spill_regs is not reset between the
reload rounds. used_spill_regs is used in finish_spills to recalculate the
spill_regs array which then contains r13 since it was used as reload reg in the
first round.
The following patch deletes all registers which are recognized by
update_eliminables as eliminable_previous but cant_eliminate now from the
used_spill_regs bitmap and fixes your testcase.
Since reload is always a bit dodgy and tends to be unpredictable I would be
interested in Ulrichs opinion about the patch. He knows much better whats
going on in reload. So Ulrich do think this makes sense?
Index: gcc/reload1.c
===
*** gcc/reload1.c.orig 2006-06-09 13:12:39.0 +0200
--- gcc/reload1.c 2006-06-09 13:14:54.0 +0200
*** reload (rtx first, int global)
*** 987,992
--- 987,994
HARD_REG_SET to_spill;
CLEAR_HARD_REG_SET (to_spill);
update_eliminables (to_spill);
+ AND_COMPL_HARD_REG_SET(used_spill_regs, to_spill);
+
for (i = 0; i FIRST_PSEUDO_REGISTER; i++)
if (TEST_HARD_REG_BIT (to_spill, i))
{
--
krebbel 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-06-09 11:41:57
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27959
[Bug bootstrap/26998] bootstrap failure building libdecnumber, ICE in compare_values, tree-vrp.c:432
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-06-09 12:39 --- Subject: Bug 26998 Author: rguenth Date: Fri Jun 9 12:39:11 2006 New Revision: 114507 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114507 Log: 2006-06-09 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/26998 * tree-vrp.c (extract_range_from_unary_expr): For NEGATE_EXPR of signed types, only TYPE_MIN_VALUE is special, but for both, minimum and maximum value. Likewise VR_ANTI_RANGE is special in this case, as is -fwrapv. * gcc.dg/torture/pr26998.c: New testcase. * gcc.dg/tree-ssa/vrp29.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr26998.c trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp29.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26998
[Bug bootstrap/26998] bootstrap failure building libdecnumber, ICE in compare_values, tree-vrp.c:432
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-06-09 12:39 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26998
[Bug middle-end/27116] [4.2 Regression] Incorrect integer division (wrong sign).
--- Comment #21 from patchapp at dberlin dot org 2006-06-09 12:55 --- Subject: Bug number PR27116 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-06/msg00457.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27116
[Bug bootstrap/27963] [4.2 Regression] libjava fails to build if it isn't built by default
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-06-09 13:14 --- WAITING is used to get feed back from the reporter. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2006-06-09 07:57:39 |2006-06-09 13:14:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27963
[Bug c++/27977] New: ICE when declaring recursive member in std namespace (illegal code)
The following code makes the compiler to consume infinite stack memory during
compilation. Obviously the code is invalid.
struct a {
a() {}
a std::b;
};
This problem does occur with any gcc 4.0.2 or later, not with gcc 3.3.5 or
older. I have not checked versions in between.
std can be replaced with any other namespace known to the compiler to reproduce
the problem.
--
Summary: ICE when declaring recursive member in std namespace
(illegal code)
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rschiele at uni-mannheim dot de
GCC build triplet: *-*-linux
GCC host triplet: *-*-linux
GCC target triplet: *-*-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27977
[Bug fortran/16206] rejects valid array initialization expression
--- Comment #5 from paul dot richard dot thomas at cea dot fr 2006-06-09 15:19 --- Created an attachment (id=11647) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11647action=view) An experimental fix for the PR This was to have been the second of the two approaches, described above. It works, in that it fixes the bug but its limitations become obvious, very quickly; try some arithmetic with an arrya_section, for example. However, all is not lost! You will note the heavy use of gmp to do the arithmetic - that was in preparation for a tactical retreat to approach (i). I have done all the tests to understand what happens in expr.c and am confident that I will have a proper fix in about 1 week. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16206
[Bug ada/27937] [4.2 Regression] Ada bootstrap failure on Solaris 10/x86
--- Comment #2 from ro at techfak dot uni-bielefeld dot de 2006-06-09 15:36 --- Subject: Re: [4.2 Regression] Ada bootstrap failure on Solaris 10/x86 ebotcazou at gcc dot gnu dot org writes: Confirmed, this happens when the compiler is configured for SJLJ exceptions. But this seems not to be the case here: % grep -i except gcc/auto-host.h /* Define 0/1 to force the choice for exception handling model. */ /* #undef CONFIG_SJLJ_EXCEPTIONS */ Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27937
[Bug c/27978] New: static inline functions code not generated if -fPIC is used
I'm attaching the code which demonstates the bug. If to compile the attached code with: cc -fPIC -S testlib.c you can see, that symbol foo is referenced, but no code with foo is generated (even label foo is missing in assembler code) (Workaround is to compile with -O flag, with -O code for foo is correctly generated) # cc -v Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/gcc-4.1.1/work/gcc-4.1.1/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.1 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.1/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.1/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --disable-multilib --disable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++,objc --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.1.1 (Gentoo 4.1.1) -- Summary: static inline functions code not generated if -fPIC is used Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ykar at list dot ru GCC build triplet: x86_64-pc-linux-gnu GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27978
[Bug c/27978] static inline functions code not generated if -fPIC is used
--- Comment #1 from ykar at list dot ru 2006-06-09 16:08 --- Created an attachment (id=11648) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11648action=view) test case to demonstrate the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27978
[Bug c++/27979] New: conversion check confused by enum bitfields
I think the following invalid conversion error, which is believe is wrong.
When I remove the bitfield, the program compile fine. In any case, the error
message isn't really optimal. :)
(sid)4502:[EMAIL PROTECTED]: ~/src] cat test.cpp
class Ast
{
enum AstKind { };
const AstKind kind : 8;
void foo(AstKind k) { }
void bar(void) { foo(kind); }
};
[with gcc 4.2 20060508]
(sid)4503:[EMAIL PROTECTED]: ~/src] /usr/lib/gcc-snapshot/bin/g++ -c test.cpp
test.cpp: In member function 'void Ast::bar()':
test.cpp:6: error: invalid conversion from 'unsigned char' to 'Ast::AstKind'
test.cpp:6: error: initializing argument 1 of 'void Ast::foo(Ast::AstKind)'
zsh: exit 1 /usr/lib/gcc-snapshot/bin/g++ -c test.cpp
[with gcc 4.2 20060530]
(sid)4504:[EMAIL PROTECTED]: ~/src] /usr/lib/gcc-snapshot/bin/g++ -c test.cpp
test.cpp: In member function 'void Ast::bar()':
test.cpp:6: error: invalid conversion from 'Ast::AstKind' to 'Ast::AstKind'
test.cpp:6: error: initializing argument 1 of 'void Ast::foo(Ast::AstKind)'
zsh: exit 1 /usr/lib/gcc-snapshot/bin/g++ -c test.cpp
(sid)4505:[EMAIL PROTECTED]: ~/src]
--
Summary: conversion check confused by enum bitfields
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27979
[Bug target/27758] [4.1 regression] -O0 -fpic link failure
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-06-09 16:52 --- *** Bug 27978 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||ykar at list dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27758
[Bug target/27978] static inline functions code not generated if -fPIC is used
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-09 16:52 --- This is already fixed in 4.1.2 and the mainline. *** This bug has been marked as a duplicate of 27758 *** -- 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=27978
[Bug c++/27979] 4.2 Regression] conversion check confused by enum bitfields
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-09 16:56 --- Confirmed, 4.1.0 accepted this code. -- 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 Keywords||rejects-valid Known to fail||4.2.0 Known to work||4.1.0 Last reconfirmed|-00-00 00:00:00 |2006-06-09 16:56:28 date|| Summary|conversion check confused by|4.2 Regression] conversion |enum bitfields |check confused by enum ||bitfields Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27979
[Bug libgcj/27730] Thread.getId() needs implemented
--- Comment #1 from tromey at gcc dot gnu dot org 2006-06-09 17:09 --- Teting a patch. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-05-22 20:26:32 |2006-06-09 17:09:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27730
[Bug bootstrap/20737] Build fails in target-libiberty
--- Comment #15 from jbwaters at gmail dot com 2006-06-09 17:29 --- As an FYI: I was able to build 4.0.3 just fine. 4.1.0 and 4.1.1 both fail as per this ticket. So whatever changed to break building on NetBSD happened between 4.0.3 and 4.1.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20737
[Bug fortran/27980] New: Wrong allocation for zero-sized function result
From a posting to comp.lang.fortran: program xint_func implicit none integer, parameter :: n=3,ii(n)=(/2,0,-1/) integer:: i character(len=80) :: line do i=1,n write (line,'(10I5)'), int_func(ii(i)) end do contains function int_func(n) result(ivec) integer, intent(in) :: n integer :: ivec(n) integer :: i if (n 0) then forall (i=1:n) ivec(i) = i end if end function int_func end program xint_func $ gfortran foo.f90 $ ./a.out Fortran runtime error: Attempt to allocate a negative amount of memory. $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../../gcc/trunk/configure --prefix=/home/ig25 --enable-languages=c,fortran Thread model: posix gcc version 4.2.0 20060525 (experimental) I'm looking into this. -- Summary: Wrong allocation for zero-sized function result Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27980
[Bug c++/27979] 4.2 Regression] conversion check confused by enum bitfields
--- Comment #2 from tbm at cyrius dot com 2006-06-09 17:47 ---
The following, related example, fails with gcc 4.2 20060508 but works with
20060530. It would be great if whoever works on this PR could check what
change was responsible to get this working, and if it was just an accidental
change, whether the following test case should be added to the test suite:
enum EBorderStyle {
BNATIVE, BNONE, BHIDDEN
};
class BorderValue
{
public:
EBorderStyle style : 8;
};
class bar
{
BorderValue *border;
EBorderStyle foo() { return border ? border-style : BHIDDEN; }
};
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27979
[Bug c++/27979] 4.2 Regression] conversion check confused by enum bitfields
--- Comment #3 from tbm at cyrius dot com 2006-06-09 18:03 --- It wasn't accidentally fixed. It was fixed by Mark Mitchell for PR c++/27506, which contain the same test case as my 2nd example. In any case, the first test case wasn't fixed by the fix for PR 27506. -- tbm at cyrius dot com changed: What|Removed |Added CC||mark at codesourcery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27979
[Bug c++/27826] [4.0/4.1 Regression] ICE in copy_to_mode_reg
--- Comment #12 from janis at gcc dot gnu dot org 2006-06-09 18:10 --- The reduced testcase from comment #7 doesn't fail with my i686 cross compilers on powerpc-linux, so I did a regression hunt using the testcase from comment #4. It identified this patch as the fix on mainline: http://gcc.gnu.org/viewcvs?view=revrev=113199 r113199 | mmitchel | 2006-04-23 18:04:33 + (Sun, 23 Apr 2006) This is indeed Mark's bitfield patch, Andrew guessed correctly. I've got another regression hunt running to find the break; it's currently between revisions 83668 and 83876 in late May 2004; there are broken builds in there so it might take awhile to keep the hunt progressing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27826
[Bug fortran/27980] Wrong allocation for zero-sized function result
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-09 18:18:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27980
[Bug libstdc++/27878] GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0 worked.
--- Comment #10 from martinol at nrlssc dot navy dot mil 2006-06-09 18:30 --- gcc-4.1-20060331 snapshots compiles successfully. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27878
[Bug c++/27826] [4.0/4.1 Regression] ICE in copy_to_mode_reg
--- Comment #13 from janis at gcc dot gnu dot org 2006-06-09 18:44 --- The test starts failing on mainline with this patch: http://gcc.gnu.org/viewcvs?view=revrev=83858 r83858 | rth | 2004-06-29 16:25:28 + (Tue, 29 Jun 2004) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27826
[Bug fortran/27981] New: Strange error message for illegal integer constant
The programme program longint real x if (.true.) x = 12345678901 end program longint contains an integer constant that does not fit into 32 bits. The compiler gives the following error message: $ ~/gcc/bin/gfortran -Wall -c longint.f90 In file longint.f90:3 if (.true.) x = 12345678901 1 Error: Unclassifiable statement in IF-clause at (1) This is with the compiler version $ ~/gcc/bin/gfortran --version GNU Fortran 95 (GCC) 4.2.0 20060527 (experimental) The error message should instead be Illegal integer constant, or integer constant too large for default integer kind integer*32, or something similar. -- Summary: Strange error message for illegal integer constant Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schnetter at aei dot mpg dot de GCC build triplet: i386-apple-darwin8.6.1 GCC host triplet: i386-apple-darwin8.6.1 GCC target triplet: i386-apple-darwin8.6.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27981
[Bug fortran/16206] rejects valid array initialization expression
--- Comment #6 from pault at gcc dot gnu dot org 2006-06-09 19:40 --- I seem to be on the way to fixing this, so I had beter assign it to myself! 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16206
[Bug libstdc++/27878] GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0 worked.
--- Comment #11 from pcarlini at suse dot de 2006-06-09 19:42 --- For comparison, please provide the config.log of that snapshot. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27878
[Bug c++/27748] [4.2 Regression] rejects _Pragma with macros
--- Comment #4 from jakub at gcc dot gnu dot org 2006-06-09 21:13 --- Subject: Bug 27748 Author: jakub Date: Fri Jun 9 21:13:25 2006 New Revision: 114519 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114519 Log: PR preprocessor/27746 * directives.c (do_pragma): Handle pragma with valid namespace and invalid name coming from macro expansion. * directives.c (destringize_and_run): Initialize next field in context. PR c/27747 PR c++/27748 * directives.c (destringize_and_run): Set NO_EXPAND on the tokens. * macro.c (_cpp_backup_tokens): Fix comment typo. testsuite/ PR c/27747 * gcc.dg/cpp/_Pragma6.c: New test. PR c++/27748 * g++.dg/cpp/_Pragma1.C: New test. PR preprocessor/27746 * gcc.dg/gomp/macro-3.c: New test. * gcc.dg/gomp/macro-4.c: New test. * g++.dg/gomp/macro-3.C: New test. * g++.dg/gomp/macro-4.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp/_Pragma1.C trunk/gcc/testsuite/g++.dg/gomp/macro-3.C trunk/gcc/testsuite/g++.dg/gomp/macro-4.C trunk/gcc/testsuite/gcc.dg/cpp/_Pragma6.c trunk/gcc/testsuite/gcc.dg/gomp/macro-3.c trunk/gcc/testsuite/gcc.dg/gomp/macro-4.c Modified: trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/directives.c trunk/libcpp/macro.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27748
[Bug preprocessor/27746] ICE on openmp code when using _Pragma from macro
--- Comment #13 from jakub at gcc dot gnu dot org 2006-06-09 21:13 --- Subject: Bug 27746 Author: jakub Date: Fri Jun 9 21:13:25 2006 New Revision: 114519 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114519 Log: PR preprocessor/27746 * directives.c (do_pragma): Handle pragma with valid namespace and invalid name coming from macro expansion. * directives.c (destringize_and_run): Initialize next field in context. PR c/27747 PR c++/27748 * directives.c (destringize_and_run): Set NO_EXPAND on the tokens. * macro.c (_cpp_backup_tokens): Fix comment typo. testsuite/ PR c/27747 * gcc.dg/cpp/_Pragma6.c: New test. PR c++/27748 * g++.dg/cpp/_Pragma1.C: New test. PR preprocessor/27746 * gcc.dg/gomp/macro-3.c: New test. * gcc.dg/gomp/macro-4.c: New test. * g++.dg/gomp/macro-3.C: New test. * g++.dg/gomp/macro-4.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp/_Pragma1.C trunk/gcc/testsuite/g++.dg/gomp/macro-3.C trunk/gcc/testsuite/g++.dg/gomp/macro-4.C trunk/gcc/testsuite/gcc.dg/cpp/_Pragma6.c trunk/gcc/testsuite/gcc.dg/gomp/macro-3.c trunk/gcc/testsuite/gcc.dg/gomp/macro-4.c Modified: trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/directives.c trunk/libcpp/macro.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27746
[Bug c/27747] [4.2 Regression] ice _Pragma and macros
--- Comment #4 from jakub at gcc dot gnu dot org 2006-06-09 21:13 --- Subject: Bug 27747 Author: jakub Date: Fri Jun 9 21:13:25 2006 New Revision: 114519 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114519 Log: PR preprocessor/27746 * directives.c (do_pragma): Handle pragma with valid namespace and invalid name coming from macro expansion. * directives.c (destringize_and_run): Initialize next field in context. PR c/27747 PR c++/27748 * directives.c (destringize_and_run): Set NO_EXPAND on the tokens. * macro.c (_cpp_backup_tokens): Fix comment typo. testsuite/ PR c/27747 * gcc.dg/cpp/_Pragma6.c: New test. PR c++/27748 * g++.dg/cpp/_Pragma1.C: New test. PR preprocessor/27746 * gcc.dg/gomp/macro-3.c: New test. * gcc.dg/gomp/macro-4.c: New test. * g++.dg/gomp/macro-3.C: New test. * g++.dg/gomp/macro-4.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp/_Pragma1.C trunk/gcc/testsuite/g++.dg/gomp/macro-3.C trunk/gcc/testsuite/g++.dg/gomp/macro-4.C trunk/gcc/testsuite/gcc.dg/cpp/_Pragma6.c trunk/gcc/testsuite/gcc.dg/gomp/macro-3.c trunk/gcc/testsuite/gcc.dg/gomp/macro-4.c Modified: trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/directives.c trunk/libcpp/macro.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27747
[Bug fortran/27916] Problem with allocatable arrays inside OpenMP do loop
--- Comment #2 from jakub at gcc dot gnu dot org 2006-06-09 21:18 --- Subject: Bug 27916 Author: jakub Date: Fri Jun 9 21:18:42 2006 New Revision: 114520 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114520 Log: PR fortran/27916 * trans-openmp.c (gfc_omp_clause_default_ctor): New function. * trans.h (gfc_omp_clause_default_ctor): New prototype. * f95-lang.c (LANG_HOOKS_OMP_CLAUSE_DEFAULT_CTOR): Define. * testsuite/libgomp.fortran/pr27916-1.f90: New test. * testsuite/libgomp.fortran/pr27916-2.f90: New test. Added: trunk/libgomp/testsuite/libgomp.fortran/pr27916-1.f90 trunk/libgomp/testsuite/libgomp.fortran/pr27916-2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/f95-lang.c trunk/gcc/fortran/trans-openmp.c trunk/gcc/fortran/trans.h trunk/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27916
[Bug fortran/27916] Problem with allocatable arrays inside OpenMP do loop
--- Comment #3 from jakub at gcc dot gnu dot org 2006-06-09 21:25 --- Should be fixed in SVN. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27916
[Bug preprocessor/27746] ICE on openmp code when using _Pragma from macro
--- Comment #14 from jakub at gcc dot gnu dot org 2006-06-09 21:26 --- Should be fixed in SVN. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27746
[Bug c/27747] [4.2 Regression] ice _Pragma and macros
--- Comment #5 from jakub at gcc dot gnu dot org 2006-06-09 21:26 --- Should be fixed in SVN. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27747
[Bug c++/27748] [4.2 Regression] rejects _Pragma with macros
--- Comment #5 from jakub at gcc dot gnu dot org 2006-06-09 21:27 --- Should be fixed in SVN. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27748
[Bug libgcj/27730] Thread.getId() needs implemented
--- Comment #2 from tromey at gcc dot gnu dot org 2006-06-09 21:36 --- Fixed. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27730
[Bug libgcj/27730] Thread.getId() needs implemented
--- Comment #3 from tromey at gcc dot gnu dot org 2006-06-09 21:37 --- Subject: Bug 27730 Author: tromey Date: Fri Jun 9 21:37:32 2006 New Revision: 114524 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114524 Log: PR libgcj/27730: * java/lang/Thread.java (threadId): New field. (nextThreadId): New static field. (Thread): Initialize new field. (getId): New method. Modified: trunk/libjava/ChangeLog trunk/libjava/java/lang/Thread.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27730
[Bug java/27982] New: Make gcj inline methods in java.nio.Buffer
There are some optimization ideas in this e-mail thread (especially in the leaves or the thread). http://gcc.gnu.org/ml/java/2006-06/msg00030.html Basically, Buffers have no accessable constructors, so the compiler knows that there can be no user classes derived from Buffer. Buffers can be treated much like final classes and all Buffer methods could be inlined. Many of the get and put methods could be inlined as if they were fancy array accesses. -- Summary: Make gcj inline methods in java.nio.Buffer Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: daney at gcc dot gnu dot org GCC build triplet: *-*-* GCC host triplet: *-*-* GCC target triplet: *-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27982
[Bug target/26347] hidden weak extern functions fail regardless of existence on alpha/linux
--- Comment #8 from vapier at gentoo dot org 2006-06-09 22:01 --- unless i did something wrong, it's still broken with gcc-4.1.1 ... except now i get an ICE: [EMAIL PROTECTED] 0 ~ $ alpha-unknown-linux-gnu-gcc -c alpha-hidden-weak.c alpha-hidden-weak.c: In function '_start': alpha-hidden-weak.c:8: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. [EMAIL PROTECTED] 0 ~ $ alpha-unknown-linux-gnu-gcc --version alpha-unknown-linux-gnu-gcc (GCC) 4.1.1 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- vapier at gentoo dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26347
[Bug fortran/24558] ENTRY doesn't work in module procedures
--- Comment #6 from pault at gcc dot gnu dot org 2006-06-09 22:16 --- Subject: Bug 24558 Author: pault Date: Fri Jun 9 22:16:08 2006 New Revision: 114526 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114526 Log: 2006-06-10 Paul Thomas [EMAIL PROTECTED] PR fortran/24558 PR fortran/20877 PR fortran/25047 * decl.c (get_proc_name): Add new argument to flag that a module function entry is being treated. If true, correct error condition, add symtree to module namespace and add a module procedure. (gfc_match_function_decl, gfc_match_entry, gfc_match_subroutine): Use the new argument in calls to get_proc_name. * resolve.c (resolve_entries): ENTRY symbol reference to to master entry namespace if a module function. * trans-decl.c (gfc_create_module_variable): Return if the symbol is an entry. * trans-exp.c (gfc_conv_variable): Check that parent_decl is not NULL. 2006-06-10 Paul Thomas [EMAIL PROTECTED] PR fortran/24558 * gfortran.dg/entry_6.f90: New test. PR fortran/20877 PR fortran/25047 * gfortran.dg/entry_7.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/entry_6.f90 trunk/gcc/testsuite/gfortran.dg/entry_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24558
[Bug fortran/25047] insert_bbt(): Duplicate key found!
--- Comment #3 from pault at gcc dot gnu dot org 2006-06-09 22:16 --- Subject: Bug 25047 Author: pault Date: Fri Jun 9 22:16:08 2006 New Revision: 114526 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114526 Log: 2006-06-10 Paul Thomas [EMAIL PROTECTED] PR fortran/24558 PR fortran/20877 PR fortran/25047 * decl.c (get_proc_name): Add new argument to flag that a module function entry is being treated. If true, correct error condition, add symtree to module namespace and add a module procedure. (gfc_match_function_decl, gfc_match_entry, gfc_match_subroutine): Use the new argument in calls to get_proc_name. * resolve.c (resolve_entries): ENTRY symbol reference to to master entry namespace if a module function. * trans-decl.c (gfc_create_module_variable): Return if the symbol is an entry. * trans-exp.c (gfc_conv_variable): Check that parent_decl is not NULL. 2006-06-10 Paul Thomas [EMAIL PROTECTED] PR fortran/24558 * gfortran.dg/entry_6.f90: New test. PR fortran/20877 PR fortran/25047 * gfortran.dg/entry_7.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/entry_6.f90 trunk/gcc/testsuite/gfortran.dg/entry_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25047
[Bug fortran/20877] result may not be entry
--- Comment #3 from pault at gcc dot gnu dot org 2006-06-09 22:16 --- Subject: Bug 20877 Author: pault Date: Fri Jun 9 22:16:08 2006 New Revision: 114526 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114526 Log: 2006-06-10 Paul Thomas [EMAIL PROTECTED] PR fortran/24558 PR fortran/20877 PR fortran/25047 * decl.c (get_proc_name): Add new argument to flag that a module function entry is being treated. If true, correct error condition, add symtree to module namespace and add a module procedure. (gfc_match_function_decl, gfc_match_entry, gfc_match_subroutine): Use the new argument in calls to get_proc_name. * resolve.c (resolve_entries): ENTRY symbol reference to to master entry namespace if a module function. * trans-decl.c (gfc_create_module_variable): Return if the symbol is an entry. * trans-exp.c (gfc_conv_variable): Check that parent_decl is not NULL. 2006-06-10 Paul Thomas [EMAIL PROTECTED] PR fortran/24558 * gfortran.dg/entry_6.f90: New test. PR fortran/20877 PR fortran/25047 * gfortran.dg/entry_7.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/entry_6.f90 trunk/gcc/testsuite/gfortran.dg/entry_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20877
[Bug libgcj/27983] New: FAIL: md5test output - gij test
byte compile: /mnt/gnu/gcc/objdir/gcc/gcj -B/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux 11.11/libjava/ -B/mnt/gnu/gcc/objdir/gcc/ --encoding=UTF-8 -C -I/mnt/gnu/gcc/obj dir/hppa2.0w-hp-hpux11.11/libjava/testsuite/../libgcj-4.2.0.jar -g /mnt/gnu/gcc/ gcc/libjava/testsuite/libjava.lang/md5test.java -d /mnt/gnu/gcc/objdir/hppa2.0w- hp-hpux11.11/libjava/testsuite 2@ stdout PASS: md5test byte compilation md5test md5test set_ld_library_path_env_vars: ld_library_path=.:/mnt/gnu/gcc/objdir/hppa2.0w-hp- hpux11.11/./libjava/.libs Setting LD_LIBRARY_PATH to .:/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libjava /.libs:.:/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libjava/.libs:.:/mnt/gnu/gc c/objdir/hppa2.0w-hp-hpux11.11/./libjava/.libs /usr/lib/dld.sl: Filename passed is Null. /usr/lib/dld.sl: No such file or directory 0CC175B9C0F1B6A831C399E269772661 0CC175B9C0F1B6A831C399E269772661 900150983CD24FB0D6963F7D28E17F72 900150983CD24FB0D6963F7D28E17F72 F96B697D7CB7938D525A2F31AAF161D0 F96B697D7CB7938D525A2F31AAF161D0 C3FCD3D76192E4007DFB496CCA67E13B C3FCD3D76192E4007DFB496CCA67E13B D174AB98D277D9F5A5611C2C9F419D9F D174AB98D277D9F5A5611C2C9F419D9F 57EDF4A22BE3C955AC49DA2E2107B67A 57EDF4A22BE3C955AC49DA2E2107B67A PASS: md5test execution - gij test FAIL: md5test output - gij test -- Summary: FAIL: md5test output - gij test Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27983
[Bug debug/27851] Hour-long segfault with -O1 -g on gcc.dg/parm-impl-decl-1.c
--- Comment #3 from wilson at gcc dot gnu dot org 2006-06-10 01:19 ---
This is a C front end bug. The C front end is creating a circular symbol
table, where the function h is defined both in the external scope and inside
itself. The dwarf2out.c code then goes into an infinite recursion trying to
tree walk the circular symbol table.
The syntax error is not needed to reproduce the problem. You just need two
functions with implicit function declarations in their parameter list. For
instance:
foo (int (*p)[sizeof(j())])
{
}
h (int (*p)[sizeof(i())])
{
}
The C front end problem can be reproduced with only one function, but you need
two to trigger the dwarf2out.c failure.
You also don't need a checking enabled build to reproduce this.
The dwarf code works in the presence of a single circular reference in the
symbol table because there is code in gen_subprogram_die that catches the case
where we try to define a function twice. This doesn't work when we have two
circular references. Now the function h is defined in 3 places, externally,
inside itself, and inside foo. The one inside foo is turned into a
declaration, and now the short circuit code in gen_subprogram_die doesn't work,
and we get the infinite recursion.
The problem occurs in get_parm_info and store_parm_decls_newstyle in c-decl.c.
The first function tears apart the binding scope for parameters. When it sees
a function, it puts it on the others list. Then store_parm_decls_newstyle
reinserts it in the proper place in the proper scope with nested=0 regardless
of what the original value of nested was. This appears to be the bug.
When the function i, for instance, was inserted into binding scopes, it was put
in two of them. It was put in the external scope with nested=0, and it was put
in the param scope with nested=1. If this info was preserved by get_parm_info
and store_parm_decls_newstyle, then the bug would not occur.
The circular refernence is created in pop_scope. When popping the scope for
the function h, i is inserted into the BLOCK_VARS for the function body because
nested is 0. When popping the external scope, i is inserted into the
BLOCK_VARS for the external scope, because nested is 0. Now we have the same
decl in two places in the symbol table. When we handle the function h for the
external scope, it is chained to i, and now since i is also declared inside the
function h, the function h is also declared inside itself. When we add foo, h
is now also declared inside foo, and foo inside h.
I don't see an easy way to fix this without adding aanother datastructure. We
could change the others field to be a structure containing a tree and the
nested info, and then store_parm_decls_newstyle can get the nested value
correct when it reinserts the tree into the symbol table.
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
CC||wilson at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-06-10 01:19:03
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27851
[Bug c++/27975] warning for comparison of different enum types impossible to control/is undocumented
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-10 02:21 --- Why is this that bad of a warning, really it could prove useful to make sure that you don't end up with always true comparisons because enums are not the same as their under lieing type in C++. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27975
[Bug c++/27977] ICE when declaring recursive member in std namespace (illegal code)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-10 02:47 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|*-*-linux | GCC host triplet|*-*-linux | GCC target triplet|*-*-linux | Keywords||error-recovery, ice-on- ||invalid-code Known to fail||4.0.0 4.2.0 4.1.0 Known to work||3.4.0 Last reconfirmed|-00-00 00:00:00 |2006-06-10 02:47:29 date|| Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27977
[Bug rtl-optimization/27761] combine miscompiles
--- Comment #5 from wilson at gcc dot gnu dot org 2006-06-10 02:49 --- If a combination is successful, we will delete i1 and i2, so it doesn't matter if they changed accidentally. If a combination fails, then we go through undobuf and revert all changes, so it doesn't matter if i1 or i2 changed accidentally. They will be restored to their original values when we are done. The only case where it matters is if added_sets_2 or added_sets_1 is true. In this case, we will re-add the patterns from i1 and/or i2 after the combination. So in this case, we need to make sure we still have the original patterns. We already make a copy of the i2 pattern for this purpose. i2pat is a copy, and is only used if added_sets_2 is true. So we just need to do the same for i1pat. I agree the comment before the i2pat is a bit confusing. It looks like the copy was originally added to fix an obscure problem, but it also happens to fix this one too. It looks like there is an unnecessary gen_rtx_SET call, as i2pat will only be used if added_sets_2 is true. So the code setting i2pat should be moved inside the added_sets_2 if statement. The new i1pat code should work the same way. The actual modification of the if_then_else rtl happens inside force_to_mode, as called from simplify_and_const_int. See the uses of SUBST in the if_then_else case in force_to_mode. This problem could be fixed if we generated new rtl here instead of using SUBST, but I don't think that is helpful, as there are other places that also call SUBST. It is safer to make the i1pat copy. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-10 02:49:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27761
[Bug fortran/27981] Strange error message for illegal integer constant
--- Comment #1 from kargl at gcc dot gnu dot org 2006-06-10 05:03 --- Erik, Thanks for the report. This is yet another example of gfortran's error handling code getting confused. If you remove the if (.true.) then you get the error message you want. If the if statement, the error is buffered then gfortran tries a different path to resolve the if clause. gfortran eventually gives up, but the original error is lost. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27981
