[Bug middle-end/24716] [4.1 Regression] Wrong code generated when optimising
--- Comment #7 from bonzini at gcc dot gnu dot org 2005-11-09 08:20 ---
Reduced testcase
/* { dg-do run } */
/* { dg-options -O -fdump-tree-dom3 } */
int Link[] = { -1 };
int W[] = { 2 };
extern void abort (void);
int f (int k, int p)
{
int pdest, j, D1361;
j = 0;
pdest = 0;
for (;;) {
if (pdest 2)
do
j--, pdest++;
while (j 2);
if (j == 1)
break;
while (pdest p)
if (j == p)
pdest++;
do
{
D1361 = W[k];
do
if (D1361 != 0)
pdest = 1, W[k] = D1361 = 0;
while (p 1);
} while (k 0);
do
{
p = 0;
k = Link[k];
while (p j)
if (k != -1)
pdest++, p++;
}
while (k != -1);
j = 1;
}
/* The correct return value should be pdest (1 in the call from main).
DOM3 is mistaken and propagates a 0 here. */
return pdest;
}
int main ()
{
if (!f (0, 2))
abort ();
return 0;
}
/* { dg-final { scan-tree-dump-times return 0 1 dom3 } } */
/* { dg-final { cleanup-tree-dump dom3 } } */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
[Bug middle-end/24716] [4.1 Regression] Wrong code generated when optimising
-- bonzini at gcc dot gnu dot org changed: What|Removed |Added CC||bonzini at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-09 08:20:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
[Bug tree-optimization/24716] [4.1 Regression] Wrong code generated when optimising
--- Comment #8 from bonzini at gcc dot gnu dot org 2005-11-09 08:22 --- dom3 is at fault -- bonzini at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
[Bug fortran/24755] New: internal compiler error with statement function
internal compiler error subroutine nhatgrid() implicit none integer :: lambda real(kind=8) :: arg,sigma real(kind=8) :: dshpfunc dshpfunc(arg)=-lambda/sigma*(arg/sigma)**(lambda-1)*exp(-(arg/sigma)**lambda) end subroutine nhatgrid -- Summary: internal compiler error with statement function Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tdeutsch at cea dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24755
[Bug libfortran/24342] [4.1 regression] testsuite failure:gfortran.fortran-torture/execute/in-pack.f90 exe
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2005-11-09 10:08 --- (In reply to comment #5) Don't worry, I do. :-) It comes from the linker, trigged by the source code for fedisableexcept, using machinery that's set up by to warn for functions that shouldn't be used, like in this case, where it's not (can't be) implemented as the warning says. OK, I see. I was only stating that glibc specifies that the feenableexcept/fedisableexcept should be available, even if they actually can't do anything (and in that case, calling them with argument 0 is fine). That's why I wasn't expecting this issue, and still think the warning not conforming to the documented behaviour. You seem to think they are defined? They're not, except for a single: #define FE_ALL_EXCEPT 0 No, that's what I was thinking should happen. That is OK (and the fpu-glibc.h code should indeed work fine, that is do nothing). if (FE_ALL_EXCEPT != 0) fedisableexcept (FE_ALL_EXCEPT); OK, I guess if it removes that warning it's OK. It shouldn't break anything. I'll do it when I have some time. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-11-07 23:24:28 |2005-11-09 10:08:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24342
[Bug libfortran/24719] [4.1 Regression] Nonadvancing read does not read more than 1 line
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2005-11-09 10:12 --- (In reply to comment #3) I believe I have a fix for this one that works with the previous patch to pr24489. I am testing along with work on pr24699 to make sure we have no conflicts or regressions. pr24719, pr24699, pr24700, and pr24489 all relate to io/transfer.c. I'm out of town right now and can't look properly into things, but I'm a bit scared that we're actually shuffling bugs around by the recent patches to the IO library rather than actually fixing them. I'll try to help as soon as I come back home (in about a week). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24719
[Bug libfortran/24342] [4.1 regression] testsuite failure:gfortran.fortran-torture/execute/in-pack.f90 exe
--- Comment #7 from hp at bitrange dot com 2005-11-09 10:24 --- Subject: Re: [4.1 regression] testsuite failure:gfortran.fortran-torture/execute/in-pack.f90 exe On Wed, 9 Nov 2005, fxcoudert at gcc dot gnu dot org wrote: --- Comment #6 from fxcoudert at gcc dot gnu dot org 2005-11-09 10:08 --- OK, I see. I was only stating that glibc specifies that the feenableexcept/fedisableexcept should be available, even if they actually can't do anything (and in that case, calling them with argument 0 is fine). That's why I wasn't expecting this issue, and still think the warning not conforming to the documented behaviour. Yes, that's a valid point. OK, I guess if it removes that warning it's OK. It shouldn't break anything. I'll do it when I have some time. Thanks in advance! brgds, H-P -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24342
[Bug c/24753] FreeBSD make buildworld failure
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-09 11:07 --- First, a hardware failure is possible - usually just re-trying may fix the problem or make it show up somehow different / somewhere else, if this is the case. Second, your gcc 3.4.2 is outdated, please update to a more recent version, like 3.4.4. Also be sure to include preprocessed source with the bugreport, the information you gave sofar is useless to us. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24753
[Bug fortran/22607] Elemental character functions don't work
--- Comment #4 from eedelman at gcc dot gnu dot org 2005-11-09 11:28 --- Subject: Bug 22607 Author: eedelman Date: Wed Nov 9 11:27:56 2005 New Revision: 106683 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106683 Log: fortran/ 2005-11-09 Erik Edelmann [EMAIL PROTECTED] PR fortran/22607 * trans-decl.c(build_function_decl): Don't set DECL_IS_PURE (fndecl) = 1 for return-by-reference functions. testsuite/ 2005-11-09 Erik Edelmann [EMAIL PROTECTED] PR fortran/22607 * gfortran-dg/pure_byref_1.f90: New. * gfortran-dg/pure_byref_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/pure_byref_1.f90 trunk/gcc/testsuite/gfortran.dg/pure_byref_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22607
[Bug tree-optimization/24716] [4.1 Regression] Wrong code generated when optimising
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||law at gcc dot gnu dot org Severity|normal |critical GCC build triplet|powerpc-apple-darwin8.2.0 | GCC host triplet|powerpc-apple-darwin8.2.0 | GCC target triplet|powerpc-apple-darwin8.2.0 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
[Bug fortran/24755] internal compiler error with statement function
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24755
[Bug fortran/24755] [4.0/4.1 Regression] internal compiler error with statement function
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-09 11:44 --- Confirmed, backtrace: #0 0x080727d3 in recursive_stmt_fcn (e=0x9fec3b8, sym=0x9fec218) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/fortran/match.c:2727 #1 0x080727b5 in recursive_stmt_fcn (e=0x9fec540, sym=0x9fec218) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/fortran/match.c:2744 #2 0x080727b5 in recursive_stmt_fcn (e=0x9fec818, sym=0x9fec218) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/fortran/match.c:2744 #3 0x080727b5 in recursive_stmt_fcn (e=0x9fecb70, sym=0x9fec218) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/fortran/match.c:2744 #4 0x080727b5 in recursive_stmt_fcn (e=0x9fecbc8, sym=0x9fec218) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/fortran/match.c:2744 #5 0x08074349 in gfc_match_st_function () at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/fortran/match.c:2819 #6 0x0807c2ba in match_word (str=value optimized out, subr=0x8074270 gfc_match_st_function, old_locus=0xbfdffc08) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/fortran/parse.c:65 #7 0x0807c3ac in decode_statement () at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/fortran/parse.c:132 #8 0x0807cda5 in next_statement () at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/fortran/parse.c:356 # -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.1.0 4.0.3 Known to work||4.0.1 Last reconfirmed|-00-00 00:00:00 |2005-11-09 11:44:05 date|| Summary|internal compiler error with|[4.0/4.1 Regression] |statement function |internal compiler error with ||statement function http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24755
[Bug target/24624] [4.1 Regression] internal compiler error: in reload, at reload1.c:1071
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-09 12:01 --- Fixed by: http://gcc.gnu.org/ml/gcc-cvs/2005-11/msg00389.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24624
[Bug target/24623] [4.1 Regression] internal compiler error: in propagate_one_insn, at flow.c:1702
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-09 12:01 --- Fixed by: http://gcc.gnu.org/ml/gcc-cvs/2005-11/msg00388.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24623
[Bug target/24624] [4.1 Regression] internal compiler error: in reload, at reload1.c:1071
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-09 12:02 ---
Note your testcase will fail on every target except for s390:
/* { dg-do compile } */
/* { dg-options -O1 -mpacked-stack } */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24624
[Bug middle-end/22127] [3.4/4.0/4.1 Regression] register window not preserved after getcontext call
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2005-11-09 12:08 --- *** Bug 21957 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22127
[Bug middle-end/21957] IA-64 register stack is not preserved after getcontext call
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2005-11-09 12:08 --- *** This bug has been marked as a duplicate of 22127 *** -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21957
[Bug target/24624] [4.1 Regression] internal compiler error: in reload, at reload1.c:1071
--- Comment #9 from krebbel at gcc dot gnu dot org 2005-11-09 12:18 --- Ups sorry. I've fixed that now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24624
[Bug rtl-optimization/24034] [4.1 regression] Regrename: Inconsistency Failure
-- krebbel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |krebbel at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24034
[Bug rtl-optimization/24034] [4.1 regression] Regrename: Inconsistency Failure
--- Comment #2 from krebbel at gcc dot gnu dot org 2005-11-09 12:24 --- Patch committed: http://gcc.gnu.org/ml/gcc-cvs/2005-11/msg00387.html -- krebbel at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24034
[Bug c/24644] [4.1 Regression] gcc-4.1 compiled ppc64 kernels do not boot
--- Comment #24 from pinskia at gcc dot gnu dot org 2005-11-09 12:34 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24644
[Bug c/24644] [4.1 Regression] gcc-4.1 compiled ppc64 kernels do not boot
--- Comment #24 from pinskia at gcc dot gnu dot org 2005-11-09 12:34 --- Fixed. --- Comment #25 from pinskia at gcc dot gnu dot org 2005-11-09 12:34 --- Subject: Bug 24644 Author: pinskia Date: Wed Nov 9 12:33:59 2005 New Revision: 106693 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106693 Log: 2005-11-09 Andrew Pinski [EMAIL PROTECTED] PR c/24644 * dwarf2-out.c (add_name_and_src_coords_attributes): Don't add a linkage name for a variable if it a register variable. * c-decl.c (grokdeclarator): Global register variables should be set as PUBLIC. Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c trunk/gcc/dwarf2out.c -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24644
[Bug tree-optimization/24716] [4.1 Regression] Wrong code generated when optimising
--- Comment #9 from rguenth at gcc dot gnu dot org 2005-11-09 13:14 --- It's IVCANONs fault, pr24716.c.t76.ivcanon: ... # pdest_23 = PHI 0(1); L24:; return pdest_23; } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
[Bug fortran/24755] [4.0/4.1 Regression] internal compiler error with statement function
--- Comment #2 from pault at gcc dot gnu dot org 2005-11-09 13:17 --- Since recursive_stmt_fcn is involved, this looks like my doing! I'll take a look tomorrow morning. Paul T -- pault at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24755
[Bug tree-optimization/24716] [4.1 Regression] Wrong code generated when optimising
--- Comment #10 from rguenth at gcc dot gnu dot org 2005-11-09 13:31 --- Or more definitely, store copyprop. # BLOCK 1 freq:122 # PRED: 0 [100.0%] (fallthru,exec) 31 [100.0%] (fallthru,exec) # jD.1285_18 = PHI 0(0), 1(31); # pD.1281_7 = PHI pD.1281_25(0), pD.1281_48(31); # kD.1280_5 = PHI kD.1280_26(0), kD.1280_30(31); # WD.1277_1 = PHI WD.1277_27(0), WD.1277_57(31); L0:; if (0) goto L43; else goto L3; # SUCC: 2 [50.0%] (true,exec) 6 [50.0%] (false,exec) ... # BLOCK 6 freq:122 # PRED: 1 [50.0%] (false,exec) 5 [100.0%] (fallthru,exec) # jD.1285_20 = PHI jD.1285_18(1), jD.1285_17(5); # pdestD.1284_11 = PHI 0(1), 1(5); L3:; if (jD.1285_20 == 1) goto L24; else goto L26; # SUCC: 33 [10.0%] (loop_exit,true,exec) 7 [90.0%] (false,exec) ... # BLOCK 33 freq:12 # PRED: 6 [10.0%] (loop_exit,true,exec) # pdestD.1284_23 = PHI pdestD.1284_11(6); L24:; return pdestD.1284_23; cfg_cleanup will propagate through the PHIs. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
[Bug tree-optimization/24716] [4.1 Regression] Wrong code generated when optimising
--- Comment #11 from rguenth at gcc dot gnu dot org 2005-11-09 13:59 --- Doh, I have a fix. What a stupid error in analyze_evolution_in_loop. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-11-09 08:20:55 |2005-11-09 13:59:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
[Bug tree-optimization/24716] [4.1 Regression] Wrong code generated when optimising
--- Comment #12 from rguenth at gcc dot gnu dot org 2005-11-09 14:01 --- Created an attachment (id=10185) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10185action=view) patch this is what I'm going to test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
[Bug target/24661] unable to find a register to spill in class NO_REGS on ia64
--- Comment #9 from matz at suse dot de 2005-11-09 14:49 ---
A shorter testcase (which at least breaks on SuSEs 3.3-hammer compiler) is:
---
typedef union value {
long double d;
} Value;
double ld2d(Value v) {
return v.d;
}
---
The problem seems to be that the register containing the union is TImode,
which gets converted to TFmode via subreg, which in turn is truncated to
DFmode via float_truncate, which somehow confuses gcc.
--
matz at suse dot de changed:
What|Removed |Added
CC||matz at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24661
[Bug c/24756] New: pointer arithmetic on ia32 uses signed divide
By using a signed divide for pointer arithmetic an incorerct value can be obtained given sufficient distance between two pointers. I have tested this on gcc 3.4 (RedHat EL4 update 1) and the same behaviour persists. # gcc -v -save-temps -Wall -o test ./test.c Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 2731 (Red Hat Linux 7.2 2.96-118.7.2) /usr/lib/gcc-lib/i386-redhat-linux/2.96/cpp0 -lang-c -v -D__GNUC__=2 -D__GNUC_MINOR__=96 -D__GNUC_PATCHLEVEL__=0 -D__ELF__ -Dunix -Dlinux -D__ELF__ -D__unix__ -D__linux__ -D__unix -D__linux -Asystem(posix) -D__NO_INLINE__ -Wall -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -D__tune_i386__ ./test.c test.i GNU CPP version 2.96 2731 (Red Hat Linux 7.2 2.96-118.7.2) (cpplib) (i386 Linux/ELF) ignoring nonexistent directory /usr/i386-redhat-linux/include #include ... search starts here: #include ... search starts here: /usr/local/include /usr/lib/gcc-lib/i386-redhat-linux/2.96/include /usr/include End of search list. /usr/lib/gcc-lib/i386-redhat-linux/2.96/cc1 test.i -quiet -dumpbase test.c -Wall -version -o test.s GNU C version 2.96 2731 (Red Hat Linux 7.2 2.96-118.7.2) (i386-redhat-linux) compiled by GNU C version 2.96 2731 (Red Hat Linux 7.2 2.96-118.7.2). ./test.c:1: warning: initialization makes pointer from integer without a cast ./test.c:2: warning: initialization makes pointer from integer without a cast ./test.c:5: warning: return type defaults to `int' ./test.c: In function `main': ./test.c:6: warning: implicit declaration of function `printf' ./test.c:6: warning: unsigned int format, pointer arg (arg 2) ./test.c:6: warning: unsigned int format, pointer arg (arg 3) ./test.c:9: warning: unsigned int format, long unsigned int arg (arg 3) ./test.c:11: warning: control reaches end of non-void function as -V -Qy -o test.o test.s GNU assembler version 2.11.90.0.8 (i386-redhat-linux) using BFD version 2.11.90.0.8 /usr/lib/gcc-lib/i386-redhat-linux/2.96/collect2 -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o test /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crti.o /usr/lib/gcc-lib/i386-redhat-linux/2.96/crtbegin.o -L/usr/lib/gcc-lib/i386-redhat-linux/2.96 -L/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../.. test.o -lgcc -lc -lgcc /usr/lib/gcc-lib/i386-redhat-linux/2.96/crtend.o /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crtn.o # ./test a = 0xcceb b = 0x2410 pointer ( a - b ) 0xea36c000 non-pointer ( ( ((unsigned long)a) - ((unsigned long)b) ) / 4) 0x2a36c000 Assembler: .file test.c .version01.01 gcc2_compiled.: .globl number .data .align 4 .typenumber,@object .sizenumber,4 number: .long -857014272 .globl mem_map .align 4 .typemem_map,@object .sizemem_map,4 mem_map: .long 605028352 .section.rodata .LC0: .string a = %#x b = %#x\n .align 32 .LC1: .string pointer\t\t( a - b )\t\t\t\t\t\t%#x\nnon-pointer\t( ( ((unsigned long)a) - ((unsigned long)b) ) / 4)\t%#x\n .text .align 4 .globl main .typemain,@function main: pushl %ebp movl%esp, %ebp subl$8, %esp subl$4, %esp pushl mem_map pushl number pushl $.LC0 callprintf addl$16, %esp subl$4, %esp movlmem_map, %edx movlnumber, %eax subl%edx, %eax shrl$2, %eax UNSIGNED (manual) pushl %eax movlmem_map, %edx movlnumber, %eax subl%edx, %eax movl%eax, %eax sarl$2, %eax SIGNED (pointer) pushl %eax pushl $.LC1 callprintf addl$16, %esp leave ret .Lfe1: .sizemain,.Lfe1-main .ident GCC: (GNU) 2.96 2731 (Red Hat Linux 7.2 2.96-118.7.2) -- Summary: pointer arithmetic on ia32 uses signed divide Product: gcc Version: 2.96 (redhat) Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: j3p0uk at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24756
[Bug c/24756] pointer arithmetic on ia32 uses signed divide
--- Comment #1 from j3p0uk at hotmail dot com 2005-11-09 14:51 --- Created an attachment (id=10186) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10186action=view) Test source (.i) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24756
[Bug tree-optimization/24716] [4.1 Regression] Wrong code generated when optimising
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-11-09 15:07 --- (In reply to comment #10) Or more definitely, store copyprop. s/store/scev/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
[Bug bootstrap/24710] gfortran - fails to build on Mac OSX -10.4.3
--- Comment #18 from dir at lanl dot gov 2005-11-09 15:13 --- That was it - my system had two versions of strip. Thanks, Dale The final library build has some warning messages, but they do not seem to hurt anything - ranlib -c .libs/libgfortranbegin.a creating libgfortranbegin.la (cd .libs rm -f libgfortranbegin.la ln -s ../libgfortranbegin.la libgfortranbegin.la) /Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/xgcc -B/Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/ -B/Users/dir/gfortran/powerpc-apple-darwin8.3.0/bin/ -B/Users/dir/gfortran/powerpc-apple-darwin8.3.0/lib/ -isystem /Users/dir/gfortran/powerpc-apple-darwin8.3.0/include -isystem /Users/dir/gfortran/powerpc-apple-darwin8.3.0/sys-include -m64 -dynamiclib -flat_namespace -undefined suppress -o .libs/libgfortran.0.0.0.dylib .libs/compile_options.o .libs/environ.o .libs/error.o .libs/fpu.o .libs/main.o .libs/memory.o .libs/pause.o .libs/stop.o .libs/string.o .libs/select.o .libs/all_l4.o .libs/all_l8.o .libs/all_l16.o .libs/any_l4.o .libs/any_l8.o .libs/any_l16.o .libs/count_4_l4.o .libs/count_8_l4.o .libs/count_16_l4.o .libs/count_4_l8.o .libs/count_8_l8.o .libs/count_16_l8.o .libs/count_4_l16.o .libs/count_8_l16.o .libs/count_16_l16.o .libs/maxloc0_4_i4.o .libs/maxloc0_8_i4.o .libs/maxloc0_16_i4.o .libs/maxloc0_4_i8.o .libs/maxloc0_8_i8.o .libs/maxloc0_16_i8.o .libs/maxloc0_4_i16.o .libs/maxloc0_8_i16.o .libs/maxloc0_16_i16.o .libs/maxloc0_4_r4.o .libs/maxloc0_8_r4.o .libs/maxloc0_16_r4.o .libs/maxloc0_4_r8.o .libs/maxloc0_8_r8.o .libs/maxloc0_16_r8.o .libs/maxloc0_4_r10.o .libs/maxloc0_8_r10.o .libs/maxloc0_16_r10.o .libs/maxloc0_4_r16.o .libs/maxloc0_8_r16.o .libs/maxloc0_16_r16.o .libs/maxloc1_4_i4.o .libs/maxloc1_8_i4.o .libs/maxloc1_16_i4.o .libs/maxloc1_4_i8.o .libs/maxloc1_8_i8.o .libs/maxloc1_16_i8.o .libs/maxloc1_4_i16.o .libs/maxloc1_8_i16.o .libs/maxloc1_16_i16.o .libs/maxloc1_4_r4.o .libs/maxloc1_8_r4.o .libs/maxloc1_16_r4.o .libs/maxloc1_4_r8.o .libs/maxloc1_8_r8.o .libs/maxloc1_16_r8.o .libs/maxloc1_4_r10.o .libs/maxloc1_8_r10.o .libs/maxloc1_16_r10.o .libs/maxloc1_4_r16.o .libs/maxloc1_8_r16.o .libs/maxloc1_16_r16.o .libs/maxval_i4.o .libs/maxval_i8.o .libs/maxval_i16.o .libs/maxval_r4.o .libs/maxval_r8.o .libs/maxval_r10.o .libs/maxval_r16.o .libs/minloc0_4_i4.o .libs/minloc0_8_i4.o .libs/minloc0_16_i4.o .libs/minloc0_4_i8.o .libs/minloc0_8_i8.o .libs/minloc0_16_i8.o .libs/minloc0_4_i16.o .libs/minloc0_8_i16.o .libs/minloc0_16_i16.o .libs/minloc0_4_r4.o .libs/minloc0_8_r4.o .libs/minloc0_16_r4.o .libs/minloc0_4_r8.o .libs/minloc0_8_r8.o .libs/minloc0_16_r8.o .libs/minloc0_4_r10.o .libs/minloc0_8_r10.o .libs/minloc0_16_r10.o .libs/minloc0_4_r16.o .libs/minloc0_8_r16.o .libs/minloc0_16_r16.o .libs/minloc1_4_i4.o .libs/minloc1_8_i4.o .libs/minloc1_16_i4.o .libs/minloc1_4_i8.o .libs/minloc1_8_i8.o .libs/minloc1_16_i8.o .libs/minloc1_4_i16.o .libs/minloc1_8_i16.o .libs/minloc1_16_i16.o .libs/minloc1_4_r4.o .libs/minloc1_8_r4.o .libs/minloc1_16_r4.o .libs/minloc1_4_r8.o .libs/minloc1_8_r8.o .libs/minloc1_16_r8.o .libs/minloc1_4_r10.o .libs/minloc1_8_r10.o .libs/minloc1_16_r10.o .libs/minloc1_4_r16.o .libs/minloc1_8_r16.o .libs/minloc1_16_r16.o .libs/minval_i4.o .libs/minval_i8.o .libs/minval_i16.o .libs/minval_r4.o .libs/minval_r8.o .libs/minval_r10.o .libs/minval_r16.o .libs/product_i4.o .libs/product_i8.o .libs/product_i16.o .libs/product_r4.o .libs/product_r8.o .libs/product_r10.o .libs/product_r16.o .libs/product_c4.o .libs/product_c8.o .libs/product_c10.o .libs/product_c16.o .libs/sum_i4.o .libs/sum_i8.o .libs/sum_i16.o .libs/sum_r4.o .libs/sum_r8.o .libs/sum_r10.o .libs/sum_r16.o .libs/sum_c4.o .libs/sum_c8.o .libs/sum_c10.o .libs/sum_c16.o .libs/dotprod_i4.o .libs/dotprod_i8.o .libs/dotprod_i16.o .libs/dotprod_r4.o .libs/dotprod_r8.o .libs/dotprod_r10.o .libs/dotprod_r16.o .libs/dotprod_l4.o .libs/dotprod_l8.o .libs/dotprod_l16.o .libs/dotprod_c4.o .libs/dotprod_c8.o .libs/dotprod_c10.o .libs/dotprod_c16.o .libs/matmul_i4.o .libs/matmul_i8.o .libs/matmul_i16.o .libs/matmul_r4.o .libs/matmul_r8.o .libs/matmul_r10.o .libs/matmul_r16.o .libs/matmul_c4.o .libs/matmul_c8.o .libs/matmul_c10.o .libs/matmul_c16.o .libs/matmul_l4.o .libs/matmul_l8.o .libs/matmul_l16.o .libs/transpose_i4.o .libs/transpose_i8.o .libs/transpose_i16.o .libs/transpose_c4.o .libs/transpose_c8.o .libs/transpose_c10.o .libs/transpose_c16.o .libs/shape_i4.o .libs/shape_i8.o .libs/shape_i16.o .libs/eoshift1_4.o .libs/eoshift1_8.o .libs/eoshift1_16.o .libs/eoshift3_4.o .libs/eoshift3_8.o .libs/eoshift3_16.o .libs/cshift1_4.o .libs/cshift1_8.o .libs/cshift1_16.o .libs/reshape_i4.o .libs/reshape_i8.o .libs/reshape_i16.o .libs/reshape_c4.o .libs/reshape_c8.o .libs/reshape_c10.o .libs/reshape_c16.o .libs/in_pack_i4.o .libs/in_pack_i8.o .libs/in_pack_i16.o .libs/in_pack_c4.o .libs/in_pack_c8.o .libs/in_pack_c10.o .libs/in_pack_c16.o .libs/in_unpack_i4.o .libs/in_unpack_i8.o .libs/in_unpack_i16.o .libs/in_unpack_c4.o
[Bug bootstrap/24710] gfortran - fails to build on Mac OSX -10.4.3
--- Comment #19 from pinskia at gcc dot gnu dot org 2005-11-09 15:17 --- (In reply to comment #18) That was it - my system had two versions of strip. Where was the second one comming from? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
[Bug libgcj/24616] linking BC-compiled classes: NoClassDefFoundErrors should be deferred
--- Comment #16 from thebohemian at gmx dot net 2005-11-09 15:18 --- Created an attachment (id=10187) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10187action=view) preliminary patch - just for review This is another preview of the patch. The patch begins to more and more depend on my verifier fixes (you can see that in the prims.cc diff). I hope I will be able to send that in soon. If you are using the provided test setup then with this patch you will be able run: invokeMethod (this one is probably not correct, as it call a constructor which is AFAIK a static method after all) invokeStaticMethod accessStaticFieldOfMissingType accessFieldOfMissingType in BC-compiled classes mode and it behaves like the JDK. The fixes for the field access may look a bit untidy. Well I apologize. The linker is big machine for me and do not have a complete oversight about it. I had to carefully adjust it at several places. If you have suggestions how to make it more elegant please tell me so. There is more to come and I expect the changes to get bigger. At this state I fixed 3 (or 4) of the mentioned problems in the PR and I would like to make the patch pretty and send it in. After that I will continue working on the remaining issues. Objections? -- thebohemian at gmx dot net changed: What|Removed |Added Attachment #10161|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616
[Bug c/24756] pointer arithmetic on ia32 uses signed divide
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-09 15:19 --- Why do you think this is a bug. The difference between a[3]-a[4] better be -1. (where a is an array). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24756
[Bug libgcj/24616] linking BC-compiled classes: NoClassDefFoundErrors should be deferred
--- Comment #17 from thebohemian at gmx dot net 2005-11-09 15:22 --- Created an attachment (id=10188) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10188action=view) lazy linker test setup This is a small update to the test setup. BC-compilation is now done with debugging symbols and there is a .gdbinit file which I use quiete often. -- thebohemian at gmx dot net changed: What|Removed |Added Attachment #10113|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616
[Bug target/24661] unable to find a register to spill in class NO_REGS on ia64
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-09 15:23 --- Hmm, do we have an ABI change in 4.1: We get in 4.1.0: ld2d: .prologue .body fnorm.d f8 = f8 br.ret.sptk.many b0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24661
[Bug rtl-optimization/24319] [3.4/4.0/4.1 regression] amd64 register spill error with -fschedule-insns
--- Comment #6 from uros at kss-loka dot si 2005-11-09 15:27 ---
The problem is caused by the combination of (1) x86_64 parameter passing
convention, (2) x86 instructions that _require_ parameters in specific
registers and (3) sched1 scheduling pass.
ad 1)
x86_64 passes function parameters in registers in the order, defined in
x86_64_int_parameter_registers[] array.
5 /*RDI*/, 4 /*RSI*/, 1 /*RDX*/, 2 /*RCX*/,
FIRST_REX_INT_REG /*R8 */, FIRST_REX_INT_REG + 1 /*R9 */
Additionally, RAX is used as a hidden argument register.
In original example, call sequence to memory_to_string is constructed as:
(insn 17 15 18 0 (set (reg:DI 4 si)
(reg:DI 61)) 81 {*movdi_1_rex64} (insn_list:REG_DEP_TRUE 15 (nil))
(expr_list:REG_DEAD (reg:DI 61)
(nil)))
(insn 18 17 19 0 (set (reg:DI 5 di [ c_string ])
(reg/v/f:DI 60 [ c_string ])) 81 {*movdi_1_rex64} (nil)
(expr_list:REG_DEAD (reg/v/f:DI 60 [ c_string ])
(nil)))
(call_insn 19 18 20 0 (set (reg:DI 0 ax)
(call (mem:QI (symbol_ref:DI (memory_to_string) [flags 0x3]
function_decl 0x4044f080 memory_to_string) [0 S1 A8])
(const_int 0 [0x0]))) 732 {*call_value_0_rex64}
(insn_list:REG_DEP_TRUE 17 (insn_list:REG_DEP_TRUE 18 (nil)))
(expr_list:REG_DEAD (reg:DI 4 si)
(expr_list:REG_DEAD (reg:DI 5 di [ c_string ])
(expr_list:REG_EH_REGION (const_int 0 [0x0])
(nil
(expr_list:REG_DEP_TRUE (use (reg:DI 5 di [ c_string ]))
(expr_list:REG_DEP_TRUE (use (reg:DI 4 si))
(nil
ad 2)
Please note, that this sequence can be found just after *strlenqi_rex_1
mega-pattern. This pattern requires parameters to be put in excactly defined
registers:
(define_insn *strlenqi_rex_1
[(set (match_operand:DI 0 register_operand =c)
(unspec:DI [(mem:BLK (match_operand:DI 5 register_operand 1))
(match_operand:QI 2 register_operand a)
(match_operand:DI 3 immediate_operand i)
(match_operand:DI 4 register_operand 0)] UNSPEC_SCAS))
(use (reg:SI DIRFLAG_REG))
(clobber (match_operand:DI 1 register_operand =D))
(clobber (reg:CC FLAGS_REG))]
However, at the time of sched1 pass (before reload) hard registers are not
known yet. We have following RTL pattern just above memory_to_string call
sequence (reg_notes are not shown for clarity):
(insn 13 12 14 0 (parallel [
(set (reg:DI 63)
(unspec:DI [
(mem:BLK (reg/f:DI 65 [ c_string ]) [0 A8])
(reg:QI 67)
(const_int 1 [0x1])
(reg:DI 66)
] 20))
(use (reg:SI 19 dirflag))
(clobber (reg/f:DI 65 [ c_string ]))
(clobber (reg:CC 17 flags))
]) 511 {*strlenqi_rex_1}
ad 3)
Sched1 pass is free to move (insn 17) and (insn 18) before (insn 13) as it
doesn't recognize register allocating conflicts between these instructions.
Following that move, reload has no registers to spill and ICEs.
The testcase from comment #3 ICEs with:
error: unable to find a register to spill in class âAREGâ
Here, the same problem could be observed. As foo is missing a prototype,
hidden RAX register gets allocated in addition to RDI:
(insn 20 18 21 0 (set (reg:DI 5 di)
(reg:DI 61)) 81 {*movdi_1_rex64} (insn_list:REG_DEP_TRUE 18 (nil))
(expr_list:REG_DEAD (reg:DI 61)
(nil)))
(insn 21 20 22 0 (set (reg:QI 0 ax)
(const_int 0 [0x0])) 55 {*movqi_1} (nil)
(nil))
(call_insn 22 21 23 0 (set (reg:SI 0 ax)
(call (mem:QI (symbol_ref:DI (foo) [flags 0x41] function_decl
0x402cbd80 foo) [0 S1 A8])
(const_int 0 [0x0]))) 732 {*call_value_0_rex64}
(insn_list:REG_DEP_TRUE 20 (insn_list:REG_DEP_TRUE 21 (nil)))
(expr_list:REG_DEAD (reg:DI 5 di)
(nil))
(expr_list:REG_DEP_TRUE (use (reg:QI 0 ax))
(expr_list:REG_DEP_TRUE (use (reg:DI 5 di))
(nil
This AX register is then moved before strlenqi_rex_1 pattern and this blocks
the AX register. (BTW: If prototype of foo is added, this particular testcase
compiles OK.)
One possible fix to this problem would be not to schedule instructions that
have assigned hard registers (move insns in above case). Considering the number
of x86 instructions, that require fixed registers I would suggest bugmasters to
raise the priority of this bug.
The x86 backend should not have these problems, but using -mregparm=X I think
it could also be tricked to this sort of ICEs.
(BTW: I have added Jim Wilson to CC of this bug as he is current maintaine of
insn scheduling pass code. Perhaps he has some ideas on how to solve this
problem.)
--
uros at kss-loka dot si changed:
What|Removed |Added
CC||wilson at gcc dot gnu dot
|
[Bug libgcj/24616] linking BC-compiled classes: NoClassDefFoundErrors should be deferred
--- Comment #18 from aph at gcc dot gnu dot org 2005-11-09 15:28 --- It's probably not the best idea to solve everything in this bug in a single patch. Better make several patches, for the different issues. Also, if there are some verifier changes needed, let's get those committed first. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616
[Bug bootstrap/24710] gfortran - fails to build on Mac OSX -10.4.3
--- Comment #20 from dir at lanl dot gov 2005-11-09 15:29 --- It was in /usr/local/bin along with a 100 or so other programs - I suppose that one of them installed it . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
[Bug bootstrap/24710] gfortran - fails to build on Mac OSX -10.4.3
--- Comment #21 from pinskia at gcc dot gnu dot org 2005-11-09 15:30 --- Closing as works for me then. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
[Bug target/24661] unable to find a register to spill in class NO_REGS on ia64
--- Comment #11 from matz at suse dot de 2005-11-09 15:32 --- You mean ABI change, because the input register seems to be f8, instead of in0 (as would be need for this union)? I'm not sure, but it looks fishy at least. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24661
[Bug c/24756] pointer arithmetic on ia32 uses signed divide
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-11-09 15:53 --- Note that obtaining the difference of pointers that don't point to the same object is invoking undefined behavior, too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24756
[Bug target/24661] unable to find a register to spill in class NO_REGS on ia64
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-09 15:57 --- (In reply to comment #11) You mean ABI change, because the input register seems to be f8, instead of in0 (as would be need for this union)? I'm not sure, but it looks fishy at least. Actually it is not an ABI change as the 3.4's RTL looks like: (insn 3 2 4 (set (reg/v:TI 340 [ v ]) (reg:TI 136 f8 [ v ])) -1 (nil) (nil)) so it comes in as f8. Note 4.0.3 20051105 fails the same way as your 4.0.3 does So closing as fixed as this is not a regression. Note gcc 4.1 produces the RTL as: (insn 6 11 7 0 (set (reg:XF 340) (reg:XF 136 f8 [ v ])) -1 (nil) (nil)) Which is in the correct mode right away. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to fail|3.3.2 3.3.6 3.4.4 4.0.2 |3.3.2 3.3.6 3.4.4 4.0.2 ||4.0.3 Known to work||4.1.0 Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24661
[Bug bootstrap/19289] ice during gcc4-20050102 profiledboostrap.
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-09 16:26 --- This works for me. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19289
[Bug debug/22313] [4.1 Regression] gcc HEAD as of 2005/07/05 fails to profiledbootstrap
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-09 16:29 --- (In reply to comment #11) This is reproducable on gcc mainline on amd64: This works for me with GNU assembler 2.16.91 20051027 with the GCC mainline on i686-linux-gnu And with GNU assembler 2.16 with the GCC mainline on x86_64-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
[Bug target/24475] gcc.dg/tls/pr24428.c execution test and gcc.dg/tls/pr24428-2.c execution test fail on IA32
--- Comment #1 from jakub at gcc dot gnu dot org 2005-11-09 16:31 --- Works just fine here. What glibc are you using? pr24428.c and pr24428-2.c are the only dg-do run tls tests, so perhaps your libc doesn't support TLS at all? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24475
[Bug other/24757] New: __sync_fetch_and_add on ia64
Since end of May, quite a few libstdc++-v3 testcases, stressing atomicity.h are failing on multi-processor ia64 machines. See, for instance, in: http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00411.html FAIL: 22_locale/locale/cons/12658_thread-1.cc execution test FAIL: 22_locale/locale/cons/12658_thread-2.cc execution test Those tests *never* fail in 4_0-branch, which doesn't use the builtins, and never did in mainline before the below of mine (and a simultaneous one to the compiler, which emptied ia64intrin.h) 2005-05-25 Paolo Carlini [EMAIL PROTECTED] * config/cpu/ia64/atomicity.h: Do not include ia64intrin.h. My analysis is that __sync_fetch_and_add is somehow misbehaving on ia64. I will try to investigate further the actual assembly, but I don't make promises, sorry. -- Summary: __sync_fetch_and_add on ia64 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24757
[Bug c++/21123] [4.0 regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101
--- Comment #27 from jason at gcc dot gnu dot org 2005-11-09 16:58 --- Subject: Bug 21123 Author: jason Date: Wed Nov 9 16:58:52 2005 New Revision: 106698 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106698 Log: PR c++/21123 * method.c (use_thunk): Use build_cplus_new instead of force_target_expr. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/inherit/thunk4.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/method.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21123
[Bug c++/24758] New: Non ambiguous typedefs
Here's the test case:
---
typedef unsigned short ushort;
namespace X
{
typedef unsigned short ushort;
}
using namespace X;
int main()
{
ushort us = 0;
}
---
prompt g++ main.cpp
main.cpp: In function 'int main()':
main.cpp:12: error: 'ushort' was not declared in this scope
main.cpp:12: error: expected `;' before 'us'
I'm expecting a clean compile (and it does compile cleanly with CW and Comeau).
The deal is that the typedef ushort is defined in two different places, to the
same type, and then brought in conflict via a using declaration. But since
the two typedefs refer to the same type, I expect that the compiler will see
that there is no conflict, and proceed without error or warning (reference
C++03 7.1.3p2).
Had the two typedefs referred to different types, I expect the compiler to
complain about an ambiguity, for example:
typedef unsigned short ushort;
namespace X
{
typedef short ushort;
}
using namespace X;
int main()
{
ushort us = 0;
}
error: ambiguous access to name found 'ushort' and 'X::ushort'
This bug is important as client code commonly includes system headers which
create a lot of common typedefs in the global namespace. If the user also
(unknowingly) creates the same typedefs, and if there is no conflict, there
should be no error. If there is a conflict, the error message should be a lot
more helpful than it currently is.
--
Summary: Non ambiguous typedefs
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hhinnant at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24758
[Bug other/24757] __sync_fetch_and_add on ia64
--- Comment #1 from pcarlini at suse dot de 2005-11-09 17:00 --- (In reply to comment #0) Those tests *never* fail in 4_0-branch, which doesn't use the builtins, and never did in mainline before the below of mine (and a simultaneous one to the compiler, which emptied ia64intrin.h) Whereas it *is* true that those tests never fail in 4_0-branch, the second part is not strictly true: sometimes, in mainline the tests failed also before that date. I would say, much less consistently. This is all I know, for now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24757
[Bug c++/24758] Non ambiguous typedefs
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-09 17:03 --- This is a dup of bug 23594. *** This bug has been marked as a duplicate of 23594 *** -- 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=24758
[Bug c++/23594] namespace typedef and global typedef name the same type, using kills global
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-09 17:03 --- *** Bug 24758 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||hhinnant at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23594
[Bug c++/21123] [4.0 regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101
--- Comment #28 from pinskia at gcc dot gnu dot org 2005-11-09 17:04 --- Fixed in 4.0.3. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21123
[Bug c++/22172] [3.4 Regression] Internal compiler error, seg fault.
--- Comment #16 from reichelt at gcc dot gnu dot org 2005-11-09 17:12 --- Backport for the 3.4 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||11/msg00643.html Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22172
[Bug c++/23594] namespace typedef and global typedef name the same type, using kills global
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-09 17:25 --- Related to PR 9726. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||9726 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23594
[Bug c/24756] pointer arithmetic on ia32 uses signed divide
--- Comment #4 from j3p0uk at hotmail dot com 2005-11-09 17:25 --- The test case was a simple test case where I tried to show the mathematical behaviour in as simple a way as possible. The reason I thought that this may be a bug is because the behaviour on a 64-bit system is different as no sign extension would occur during the divide operation, hence the two values would be the same (0x2a36c000) - and I've run the test program on an ia64 to prove this. Given this fact the pointer arithmetic in this case is giving an answer that is wrong (0xea36c000), and the reason for this can clearly be shown to be sign-extension occurring when possibly it should not. 0xcceb - 0x2410 1010 1000 1101 1011 ^ Highest order bit set 0x2a36c000 0010 1010 0011 0110 1100 ^^ 0xea36c000 1110 1010 0011 0110 1100 ^^ I admit that I hadn't thought about the case of a larger - smaller pointer, so would agree that the fix isn't as simple as I thought, but that doesn't change the fact that the current answer given is incorrect for the test program I was using. If you think the test program should be altered in any way to more correctly determine the behaviour but need a large memory system to run it on then I'll be more than happy to run it for you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24756
[Bug c/24756] pointer arithmetic on ia32 uses signed divide
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-09 17:30 --- This is invalid because otherwise you get the incorrect answer for a[3]-a[4]: a = 0x8049668 b = 0x804966c pointer ( a - b ) 0x non-pointer ( ( ((unsigned long)a) - ((unsigned long)b) ) / 4) 0x3fff -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24756
[Bug other/24757] __sync_fetch_and_add on ia64
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-09 17:35 --- Hmm you said in: http://gcc.gnu.org/ml/libstdc++/2005-11/msg00149.html That was really a glibc bug. And actually 4.0 and before uses the builtins for ia64, this is where the builtins came from in the first place. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24757
[Bug fortran/24759] New: Unclear error message
The code subroutine a (emask) implicit none real, intent(in) :: emask(:,:,:) logical :: left(3), right(3) integer :: i,j,k i=1; j=1; k=1 left=.false. right=.false. if (.not.right(3)) left(1) = abs(emask(i,j,k+1)-1)0.01) end subroutine a contains an error in the if statement. The last closing parenthesis in this line must not be there. When compiled with gfortran, the error message is $ ~/gcc/bin/gfortran --version GNU Fortran 95 (GCC) 4.1.0 20051030 (experimental) $ ~/gcc/bin/gfortran -c unclassifyable.f90 In file unclassifyable.f90:9 if (.not.right(3)) left(1) = abs(emask(i,j,k+1)-1)0.01) 1 Error: Unclassifiable statement in IF-clause at (1) This may be technically correct, but I wonder whether it would be possible to count parentheses and detect the mismatch. I'm aware of the fact that classifying statements in Fortran requires e.g. looking for equal signs and commas that are not enclosed in parentheses, so that mismatching parantheses can throw the classifier off. But the classifier probably already contains parentheses matching code, and reporting the mismatch would lead to a better error message. -- Summary: Unclear error message Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schnetter at aei dot mpg dot de GCC build triplet: powerpc-apple-darwin8.3.0 GCC host triplet: powerpc-apple-darwin8.3.0 GCC target triplet: powerpc-apple-darwin8.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24759
[Bug fortran/24759] Unclear error message for a syntax error
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-09 17:39 --- I notice that we give an unclassifiable error almost any time there is a syntax error. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2005-11-09 17:39:53 date|| Summary|Unclear error message |Unclear error message for a ||syntax error http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24759
[Bug other/24757] __sync_fetch_and_add on ia64
--- Comment #3 from pcarlini at suse dot de 2005-11-09 17:45 --- (In reply to comment #2) Hmm you said in: http://gcc.gnu.org/ml/libstdc++/2005-11/msg00149.html That was really a glibc bug. Exactly *was*. Ehi, do you think I'm stupid? Of course in the meanwhile I have checked that the problem is present in machines equipped with glibc2.3.5 and is not, on the same machines, for 4_0-branch. And actually 4.0 and before uses the builtins for ia64, this is where the builtins came from in the first place. Exactly. But, given the glibc bug above, masking the gcc behavior well into 2005 for some of our machines, at least, isn't possible that when we switched to builtins everywhere something got broken? Alternately, the ia64 builtins themselves can be defective, but that seems much less likely to me, because we are talking about a very consistent behavior for relatively simple usages of one single mutex and one single atomic counter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24757
[Bug libgcj/15430] Cannot interrupt blocking I/O calls with close()
--- Comment #5 from daney at gcc dot gnu dot org 2005-11-09 17:46 --- Created an attachment (id=10189) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10189action=view) Program that demonstrates how shutdown can solve the problem. Compile socktest.c thusly: gcc -g -o soctest soctest.c -lpthread Then run it and from a different window telnet localhost 4455 Do not type anything in the telnet window. When the socket is shutdown the read returns with a value of zero. I guess we should shutdown as well as close in the socket code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15430
[Bug libstdc++/24347] Document boost_shared_ptr vs concurrency
--- Comment #1 from redi at gcc dot gnu dot org 2005-11-09 17:51 --- We need to doc much more than that ... we don't have any docs saying which TR1 components are supported or how to make use of them, do we? I had some changes on my hard drive adding docs to the docs/html/ext pages, but now that TR1 is officially sanctioned it might deserve a new docs/html/tr1 dir. Assign this to me if you want. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24347
[Bug other/24757] __sync_fetch_and_add on ia64
--- Comment #4 from pcarlini at suse dot de 2005-11-09 17:51 --- (In reply to comment #3) .Alternately, the ia64 builtins themselves can be defective, but that seems much less likely to me, because we are talking about a very consistent behavior for relatively simple usages of one single mutex and one single atomic counter. And this is also inconsistent with 4_0-branch, where we have no problems, never during the last 6 months, at least. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24757
[Bug libstdc++/24347] Document boost_shared_ptr vs concurrency
--- Comment #2 from pcarlini at suse dot de 2005-11-09 17:52 --- Your are welcome! -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |redi at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-09 17:52:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24347
[Bug tree-optimization/24716] [4.1 Regression] Wrong code generated when optimising
--- Comment #14 from rguenth at gcc dot gnu dot org 2005-11-09 18:01 --- Subject: Bug 24716 Author: rguenth Date: Wed Nov 9 18:00:59 2005 New Revision: 106700 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106700 Log: 2005-11-09 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/24716 * tree-scalar-evolution.c (analyze_evolution_in_loop): Use t_bool to track results from follow_ssa_edge. * gcc.c-torture/execute/pr24716.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr24716.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-scalar-evolution.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
[Bug tree-optimization/24716] [4.1 Regression] Wrong code generated when optimising
--- Comment #15 from rguenth at gcc dot gnu dot org 2005-11-09 18:02 --- 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=24716
[Bug target/24475] gcc.dg/tls/pr24428.c execution test and gcc.dg/tls/pr24428-2.c execution test fail on IA32
--- Comment #2 from joseph at codesourcery dot com 2005-11-09 18:09 --- Subject: Re: gcc.dg/tls/pr24428.c execution test and gcc.dg/tls/pr24428-2.c execution test fail on IA32 On Wed, 9 Nov 2005, jakub at gcc dot gnu dot org wrote: Works just fine here. What glibc are you using? pr24428.c and pr24428-2.c are the only dg-do run tls tests, so perhaps your libc doesn't support TLS at all? The tests changed from failing to working on my (CodeSourcery Automatic Testing System) nightly builds when I switched them from running on an i686-pc-linux-gnu system to running on an x86_64 system (with more recent libc), bootstrapping with an i686-pc-linux-gnu cross-compiler and configuring with --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=i686-pc-linux-gnu; that is, the same compiler version failed under the pure 32-bit environment but passed when building as 32-bit under a 64-bit kernel (with more recent libc), and this was the only change in test results between the two environments apart from gcc.misc-tests/linkage.c which tries to link with programs built with cc. Both environments have some form of glibc 2.3.2; it's quite possible the older one doesn't support TLS. If the state of libc doesn't support TLS can reliably be detected then perhaps the test should be marked UNSUPPORTED in that case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24475
[Bug bootstrap/24695] [csl-arm-branch] Bootstrap failure with current csl-arm-branch
--- Comment #2 from bero at arklinux dot org 2005-11-09 18:13 --- It definitely wasn't added in binutils csl-arm-branch... Is gcc csl-arm-branch supposed to be used with binutils head now? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24695
[Bug libgcj/15430] Cannot interrupt blocking I/O calls with close()
--- Comment #6 from aph at gcc dot gnu dot org 2005-11-09 18:22 --- Two things: Does this work for fds that aren't associated with sockets? It doesn't quite avoid the need for locking, since we still need to make sure that we only close an fd once. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15430
[Bug target/23231] cross compiling fails for mips-sgi-irix6.5
--- Comment #5 from pfl at iis dot fhg dot de 2005-11-09 18:35 --- Ok, I switched to MacOSX. There I have a /usr/gnu/build/gcc-4.0.2 diectory with the original sources. Then I do a ../gcc-4.0.2/configure --cache-file=../mips-gcc-4.0.2.configure.cache --prefix=/usr/gnu --bindir=/usr/gnu/bin --sbindir=/usr/gnu/sbin --libdir=/usr/gnu/lib32 --disable-nls --disable-multilib --disable-intl --enable-languages=c,c++ --target=mips-sgi-irix6.5 --program-prefix=mips-sgi-irix6.5- --with-libs=/usr/gnu/mips-sgi-irix6.5/lib --with-gnu-ld --with-ld=/usr/gnu/bin/mips-sgi-irix6.5-ld --with-gnu-as --with-as=/usr/gnu/bin/mips-sgi-irix6.5-as in the directory: /usr/gnu/build/mips-gcc-4.0.2-compile As preparation I did a: CFLAGS=-O1 CXXFLAGS=-O1 ./configure --cache-file=../binutils_configure.cache --prefix=/usr/gnu --bindir=/usr/gnu/bin --sbindir=/usr/gnu/sbin --libdir=/usr/gnu/lib32 --program-prefix=mips-sgi-irix6.5- --target=mips-sgi-irix6.5 make make install on the binutils-2.16.1 in: /usr/gnu/build/mips-binutils-2.16.1. Furthermore, I copied the original libs from the SGI box (IRIX 6.5.25) to: /usr/gnu/mips-sgi-irix6.5/lib and the headers to: /usr/gnu/mips-sgi-irix6.5/sys-include This it the contens of those directorys: pwd /usr/gnu/mips-sgi-irix6.5/lib ls -l total 14536 -rw-r--r--1 pfeil pfeil 30 Sep 11 23:13 COPIED drwxr-xr-x 32 pfeil pfeil 1088 Sep 29 23:28 ldscripts -r-xr-xr-x1 pfeil pfeil 3322796 Sep 30 00:17 libc.so -r-xr-xr-x1 pfeil pfeil 3322796 Sep 11 23:30 libc.so.1 -r--r--r--1 pfeil pfeil 128088 Sep 11 23:30 libdisk.so -r--r--r--1 pfeil pfeil67600 Sep 11 23:30 libpam.so -r--r--r--1 pfeil pfeil25224 Sep 11 23:30 libpam_misc.so -rwxr-xr-x1 pfeil pfeil 555440 Sep 11 23:30 rld pwd /usr/gnu/mips-sgi-irix6.5/sys-include ls ABIinfo.h ieeefp.hresolv.h FlexLexer.h internalrld_interface.h MediaViewer inttypes.h rpc Mrm invent.hrpcsvc Sgm isam.h rsvp SpeedShop iso646.hsac.h Vk kmem.h sat.h X11 ksyssched.h Xm langinfo.h scncomment.h a.out.h lastlog.h scnhdr.h abi_mutex.h ldfcn.h search.h aio.h libXlate.h semaphore.h alloca.hlibdwarf.h setjmp.h aouthdr.h libelf.hsex.h ar.hliberrno.h sgi_nl.h archives.h libexc.hsgidefs.h arcslibftn.hsgidlfcn.h arpalibgen.hsgtty.h asm.h libw.h shadow.h assert.hlimits.hshlib.h auxv.h linenum.h sigfpe.h bstring.h locale.hsiginfo.h cap_net.h locale_attr.h signal.h capability.hmakesnmp cblas.h malloc.hsock_extern.h ckpt.h math.h ssdi.h clearance.h math62.hstamp.h clibdefs.h mdbm.h standards.h cmplrs mediad.hstd.h compact_reloc.h memory.hstdarg.h core.out.h mls.h stddef.h cpio.h mntent.hstdio.h cr1.h mon.h stdlib.h craymonetary.h storclass.h crypt.h mpc.h string.h cs.hmpool.h strings.h ctype.h mqueue.hstropts.h curses.hmsym.h stsupport.h db.hmutex.h sum.h dbm.h namefs svr4_math.h deflt.h nan.h sym.h devmgmt.h nanothread.hsym64.h di_aux.hndbm.h sym_aux.h di_group.h net symconst.h di_passwd.h netconfig.h syms.h dial.h netdb.h sys dirent.hnetdir.hsys.s disassembler.h netinet sysexits.h dlfcn.h netman syslog.h dslib.h netns tar.h dwarf.h nl_types.h task.h elf.h nlist.h tcpd.h elf_abi.h ns_api.hterm.h elf_delta.h ns_daemon.h termio.h elf_mips.h obj.h termios.h elfaccess.h obj_ext.h
[Bug libstdc++/23591] exceptions in plugins in threads cause segmentation violation by leaving bad exit handler for the pthread
--- Comment #5 from bkoz at gcc dot gnu dot org 2005-11-09 18:36 --- Created an attachment (id=10190) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10190action=view) tentative patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23591
[Bug fortran/24655] ICE with statement function
--- Comment #2 from tobi at gcc dot gnu dot org 2005-11-09 18:40 --- *** This bug has been marked as a duplicate of 24755 *** -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24655
[Bug fortran/24755] [4.0/4.1 Regression] internal compiler error with statement function
--- Comment #3 from tobi at gcc dot gnu dot org 2005-11-09 18:40 --- *** Bug 24655 has been marked as a duplicate of this bug. *** -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||pavarini at pv dot infn dot ||it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24755
[Bug fortran/24646] accepting invalid label
-- tobi at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24646
[Bug rtl-optimization/24760] New: -d option changes generated code
When compiling some files, the -da option or - AFAICT - any of its constituent options changes the generated code. When using -da, the -quiet option can also have an effect on the generated code, although this is harder to demonstrate. -- Summary: -d option changes generated code Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24760
[Bug rtl-optimization/24760] -d option changes generated code
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-09 18:52 --- Most (if not all) of these issues are usually a pass depending on addresses being the same. I think David E. has a bug filed about one of these issues already. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24760
[Bug rtl-optimization/24760] -d option changes generated code
--- Comment #2 from amylaar at gcc dot gnu dot org 2005-11-09 18:59 --- Created an attachment (id=10191) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10191action=view) test case Mainline version 106440 configured for i686-pc-linux-gnu --with-arch=i686: ../../i686/gcc/cc1 -fpreprocessed cse.i -quiet -g -O2 -o t.s-i0 produces different output than ../../i686/gcc/cc1 -fpreprocessed cse.i -quiet -g -O2 -o t.s-i1 -da or ../../i686/gcc/cc1 -fpreprocessed cse.i -quiet -g -O2 -o t.s-ik -dk Mainline version 106440 configured for sh-elf: /mnt/scratch/nightly/2005-11-03/sh-elf/gcc/cc1 -fpreprocessed cse.i -quiet -m4 -g -O2 -o t.s-0 produces different code than: /mnt/scratch/nightly/2005-11-03/sh-elf/gcc/cc1 -fpreprocessed cse.i -quiet -m4 -g -O2 -o t.s-1 -da -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24760
[Bug rtl-optimization/24760] -d option changes generated code
--- Comment #3 from amylaar at gcc dot gnu dot org 2005-11-09 19:08 --- Created an attachment (id=10192) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10192action=view) test case This is a shorter test case, but only debug information changes were observed for this test case. configured for i686-pc-linux-gnu or for sh-elf, compare the output of: ./cc1 -fpreprocessed -g -O2 l0.c -o l0.s-0 with: ./cc1 -fpreprocessed -g -O2 l0.c -o l0.s-1 -da -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24760
[Bug libgcj/15430] Cannot interrupt blocking I/O calls with close()
--- Comment #7 from daney at gcc dot gnu dot org 2005-11-09 19:24 --- Here is the first version of my patch: http://gcc.gnu.org/ml/java-patches/2005-q4/msg00176.html -- daney at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15430
[Bug other/24757] __sync_fetch_and_add on ia64
--- Comment #5 from pcarlini at suse dot de 2005-11-09 19:30 --- Some additional details from testresults: the bulk of the builtin atomics changes went in around mid of April, the ia64 specific bits, on April, 14. All the results that Andreas sent at the beginning of the month (for instance april, 7, 8, 9) are fine. Then, at the end of the month (for instance, april, 22, 23, 24) the results are not clean anymore. Lately, never less than 2 failures, often 4, in threading tests. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24757
[Bug rtl-optimization/24760] -d option changes generated code
--- Comment #4 from amylaar at gcc dot gnu dot org 2005-11-09 19:35 --- I have observed the -quiet influence only with a proprietary testcase so far (EEMBC aiifft01/bmark.c for sh-elf -m4 -ml -g -O3 -version -fomit-frame-pointer -funroll-loops --param max-inline-insns-single=5). Compiling with -da -quiet generally makes this code smaller than compiling with -quiet only, but with a probability of about 1/5th -da -quiet produces larger code. -da without -quiet generally produces code that is larger than any of the above scenarios, but sometimes it produces identical code to -quiet (without -da). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24760
[Bug inline-asm/24761] New: Missing register load before inline asm in templated function causes SIGSEGV
I have a templated function which uses inline assembler (with MMX instructions). Inline assembler is passed pointer to array element. When this function is instantiated for the first time, code before inline assembler is generated correctly. When it is instantiated for the second time, one of registers used in inline assembler is not loaded from stack and causes segfault when it is dereferenced in inline assembler. I will attach test case. g++-4.0 -v: Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.0.2 (Debian 4.0.2-2) -- Summary: Missing register load before inline asm in templated function causes SIGSEGV Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: inline-asm AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: krzysiek-gcc dot gnu dot org at lichota dot net GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24761
[Bug inline-asm/24761] Missing register load before inline asm in templated function causes SIGSEGV
--- Comment #1 from krzysiek-gcc dot gnu dot org at lichota dot net 2005-11-09 19:46 --- Created an attachment (id=10193) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10193action=view) Testcase for the bug This is the testcase. Compile with: g++-4.0 -save-temps -fPIC -ggdb3 -Wno-non-virtual-dtor -O0 -pthread -fkeep-inline-functions testcase10.cpp When both calls to bar() are instantiated, the segfault occurs. When only one is instantiated (the other is commented out), it works correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24761
[Bug libstdc++/24595] std::tr1::get_deleter not declared
--- Comment #3 from redi at gcc dot gnu dot org 2005-11-09 19:49 --- Created an attachment (id=10194) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10194action=view) alternative fix This bug was my fault - sorry for the dumb mistake, and not catching it. We could leave _M_get_deleter private by declaring get_deleter before the friend declaration, something like this untested patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24595
[Bug inline-asm/24761] Missing register load before inline asm in templated function causes SIGSEGV
--- Comment #2 from krzysiek-gcc dot gnu dot org at lichota dot net 2005-11-09 19:49 --- Created an attachment (id=10195) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10195action=view) Assembler code generated from testcase This is code generated from testcase. In first instantiation eax register is loaded before inline asm starts: .loc 1 25 0 movl-16(%ebp), %eax addl-20(%ebp), %eax sall$2, %eax addl8(%ebp), %eax movl%eax, -8(%ebp) .loc 1 41 0 movl-16(%ebp), %eax addl-24(%ebp), %eax sall$2, %eax movl%eax, %edx addl-12(%ebp), %edx movl-8(%ebp), %eax #APP movq (%edx), %mm0 ; In the second instantiation, eax is not loaded: .loc 1 25 0 movl-16(%ebp), %eax addl-20(%ebp), %eax sall$2, %eax addl8(%ebp), %eax movl%eax, -8(%ebp) .loc 1 41 0 movl-16(%ebp), %eax addl-24(%ebp), %eax sall$2, %eax movl%eax, %edx addl-12(%ebp), %edx #APP movq (%edx), %mm0 ; Then in line: pxor (%eax), %mm0 ; eax is dereferenced and segfault occurs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24761
[Bug inline-asm/24761] Missing register load before inline asm in templated function causes SIGSEGV
--- Comment #3 from krzysiek-gcc dot gnu dot org at lichota dot net 2005-11-09 20:00 --- Created an attachment (id=10196) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10196action=view) Correct code generated by g++ 3.4.2 This is the correct code generated by g++ 3.4.2. It loads eax before inline asm starts in both instantiations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24761
[Bug rtl-optimization/24762] New: [killloop-branch] code motion of non-invariant expressions with hard registers.
The killloop-branch produces wrong code for the following test due to a bug in
loop-invariant.c or code related to it.
extern C void abort(void);
class runtime_error {};
void test01(int iters)
{
for (int i = 0; i iters; ++i)
{
try {
throw runtime_error();
abort();
} catch (runtime_error) { }
}
}
int main(int argc, char* argv[])
{
test01(1);
return 0;
}
The problem is that the following expression is moved out of the loop:
(insn 64 63 54 3 (set (reg:DI 350)
(reg:DI 16 r16)) 5 {*movdi_internal} (nil)
(nil))
See the attached dumps. So far I can only reproduce the bug on IA-64.
Obviously, exceptions are involved somehow. On ia64, there are also over 300
libjava failures that disappear when loop-invariant.c is disabled.
--
Summary: [killloop-branch] code motion of non-invariant
expressions with hard registers.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
GCC target triplet: ia64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24762
[Bug rtl-optimization/24762] [killloop-branch] code motion of non-invariant expressions with hard registers.
--- Comment #1 from steven at gcc dot gnu dot org 2005-11-09 20:12 --- Created an attachment (id=10197) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10197action=view) loop2_init dump -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24762
[Bug rtl-optimization/24762] [killloop-branch] code motion of non-invariant expressions with hard registers.
--- Comment #2 from steven at gcc dot gnu dot org 2005-11-09 20:12 --- Created an attachment (id=10198) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10198action=view) loop2_invariant dump -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24762
[Bug other/4372] #pragma weak pthread* inclusion causes applications to crash without a linker error when one forgets to link with -lpthread
--- Comment #9 from aoliva at gcc dot gnu dot org 2005-11-09 20:13 --- Subject: Bug 4372 Author: aoliva Date: Wed Nov 9 20:13:41 2005 New Revision: 106703 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106703 Log: PR other/4372 * tree.h (IDENTIFIER_TRANSPARENT_ALIAS): New. (TREE_DEPRECATED): Adjust comment. Check for a DECL. * c-common.c (handle_weakref_attribute): New. (c_common_attribute_table): Add weakref. * configure.ac (HAVE_GAS_WEAKREF): Check for weakref support in the assembler. * configure, config.in: Rebuilt. * defaults.h (ASM_OUTPUT_WEAKREF): Define if HAVE_GAS_WEAKREF. * doc/extend.texi: Document weakref attribute. * varasm.c (ultimate_transparent_alias_target): New (assemble_name): Use it. (weak_finish_1): Split out of... (weak_finish): ... and deal with weakrefs in... (weakref_targets): ... new list. (globalize_decl): Clean up weakref_targets. (do_assemble_alias): Handle weakrefs. (finish_aliases_1): Do not reject weakrefs to external symbols. (assemble_alias): Handle weakrefs. Added: trunk/gcc/testsuite/gcc.dg/attr-weakref-1.c trunk/gcc/testsuite/gcc.dg/attr-weakref-1a.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/config.in trunk/gcc/configure trunk/gcc/configure.ac trunk/gcc/defaults.h trunk/gcc/doc/extend.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.old-deja/g++.abi/vtable2.C trunk/gcc/tree.h trunk/gcc/varasm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4372
[Bug c++/24761] [4.0/4.1 Regression] Missing register load before inline asm in templated function causes SIGSEGV
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-09 20:24 ---
Simplified example:
template int
int f(int i)
{
asm(%0 %1 : +r(i) );
return i;
}
int main(void)
{
f0(0)+ f1(0);
}
-
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
Status|UNCONFIRMED |NEW
Component|inline-asm |c++
Ever Confirmed|0 |1
Keywords||wrong-code
Known to fail||2.95.3 4.0.0 4.1.0
Known to work||3.4.0 3.3.3 3.2.3 3.0.4
Last reconfirmed|-00-00 00:00:00 |2005-11-09 20:24:19
date||
Summary|Missing register load before|[4.0/4.1 Regression] Missing
|inline asm in templated |register load before inline
|function causes SIGSEGV |asm in templated function
||causes SIGSEGV
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24761
[Bug c++/24138] [4.1 regression] ICE with the code in PR 20407
--- Comment #5 from aldyh at gcc dot gnu dot org 2005-11-09 20:25 --- I'll take a look at this. -- aldyh at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aldyh at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24138
[Bug c++/24761] [4.0/4.1 Regression] templates and inline-asm and +
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-09 20:28 --- For the first time template is instantiated, we get: __asm__(%0 %1 :=r i:0 i); The second time, we get: __asm__(%0 %1 :=r i:); Somehow we brought back a bug from 2.95.3 (weird isn't it). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24761
[Bug rtl-optimization/24760] -d option changes generated code
--- Comment #5 from amylaar at gcc dot gnu dot org 2005-11-09 20:56 ---
(In reply to comment #4)
-da without -quiet generally produces code that is larger than any of the
above
scenarios, but sometimes it produces identical code to -quiet (without -da).
I have now captured four different sets of debugging dumps (with different
code generated) for -da, and the first dump where they differ in things other
than mere pointers is 21.loop2_unroll . Allocation of registers that
appear new in this dump appears to be different.
I think these statements are to blame:
87487rakdver /* Allocate the basic variables (i0). */
89197 hagog if (opt_info-insns_to_split)
89197 hagog htab_traverse (opt_info-insns_to_split,
allocate_basic_va
89197 hagog if (opt_info-insns_with_var_to_expand)
89197 hagog {
89197 hagog htab_traverse (opt_info-insns_with_var_to_expand,
89197 hagog insert_var_expansion_initialization,
89197 hagog opt_info-loop_preheader);
89197 hagog htab_traverse (opt_info-insns_with_var_to_expand,
89197 hagog combine_var_copies_in_loop_exit,
89197 hagog opt_info-loop_exit);
89197 hagog }
Unless you want to sort the insns that are found during a hash table traversal,
you have to fix the hash functions to be address-independent.
I think ve_info_hash and si_info_hash should use the uid of the insn rather
than its address.
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
CC||rakdver at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24760
[Bug other/4372] #pragma weak pthread* inclusion causes applications to crash without a linker error when one forgets to link with -lpthread
--- Comment #10 from aoliva at gcc dot gnu dot org 2005-11-09 20:57 --- Subject: Bug 4372 Author: aoliva Date: Wed Nov 9 20:57:30 2005 New Revision: 106704 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106704 Log: gcc/ChangeLog: PR other/4372 * gthr-dce.h, gthr-posix.h, gthr-posix95.h, gthr-solaris.h, gthr-tpf.h: Define __gthrw. For all identifiers that might be weak, introduce weakrefs or non-weak aliases with __gthrw, and prefix all uses with __ghtrw. libobjc/ChangeLog: PR other/4372 * thr-objc.c (_XOPEN_SOURCE): Define. Modified: trunk/gcc/ChangeLog trunk/gcc/gthr-dce.h trunk/gcc/gthr-posix.h trunk/gcc/gthr-posix95.h trunk/gcc/gthr-solaris.h trunk/gcc/gthr-tpf.h trunk/libobjc/ChangeLog trunk/libobjc/thr-objc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4372
[Bug other/4372] #pragma weak pthread* inclusion causes applications to crash without a linker error when one forgets to link with -lpthread
--- Comment #11 from aoliva at gcc dot gnu dot org 2005-11-09 20:58 --- Fixed -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4372
[Bug rtl-optimization/24319] [3.4/4.0/4.1 regression] amd64 register spill error with -fschedule-insns
--- Comment #7 from wilson at tuliptree dot org 2005-11-09 21:07 --- Subject: Re: [3.4/4.0/4.1 regression] amd64 register spill error with -fschedule-insns On Wed, 2005-11-09 at 07:27, uros at kss-loka dot si wrote: (BTW: I have added Jim Wilson to CC of this bug as he is current maintaine of insn scheduling pass code. Perhaps he has some ideas on how to solve this problem.) Vlad's name really should be first in the list, as he is the only one of the 4 listed people that is actively working on the scheduler. This problem only shows up when the -fschedule-insns option is used. The x86 port deliberately disables this by default for good reasons. One possible solution is to add hooks to the x86 backend that emit an error when a user specifies the -fschedule-insns option, since it isn't expected to work, and if it did work, it would more likely than not result in worse code. I think this is the best short term option. Another possible solution is to modify the strlenqi_rex_1 pattern to use explicit hard registers instead of constraints that specify one register. There is little point in trying to register allocate a pattern when there is only one possible register that can be used here. Using a hard register would expose the dependencies to the scheduler, preventing the scheduler from performing bad optimizations. The downside here is that use of hard registers may confuse some optimization passes, or expose limitations in some optimization passes, resulting in some performance loss. Also, you will have to find and fix all existing patterns which have this problem. Doing this will be error prone, and may cause additional problems, and/or may result in an incomplete fix if some patterns are missed. I doubt that this is worth the effort. As for a scheduler fix, we could perhaps test SMALL_REGISTER_CLASSES, and if defined, then make all insns that use a hard register into a scheduling barrier (e.g. a call to flush_pending_lists). Most all targets that define SMALL_REGISTER_CLASSES already disables the first scheduling pass, so this probably won't break anything. This should be verified. This is going to severely limit the optimizations that sched1 can perform, which may make it pointless, but at least then the -fschedule-insns option should work for x86. Since it was changes to SCHED_GROUP handling that exposed this problem, perhaps the SCHED_GROUP handling code can be conditional on SMALL_REGISTER_CLASSES. For instance, maybe we can put the insns loading parameters into registers into the SCHED_GROUP for SMALL_REGISTER_CLASSES targets. This would prevent moving such insns during sched1. This would mean adding code like the existing in_post_call_group_p stuff, except for insns before a call instead of insns after a call. I think this is the best long term solution. As for a register allocator fix, we could extend the RA to be able to spill and reload hard registers, but the resulting code in this case would be so bad that I see no point in even trying. Since end users will gain little benefit from being able to run the sched1 pass on x86 code, I don't think this is a serious problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24319
[Bug rtl-optimization/24762] [killloop-branch] code motion of non-invariant expressions with hard registers.
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-09 21:08 --- This is not an ia64 specific issue as far as I can see, on x86_64, we get: (note 64 61 62 2 [bb 2] NOTE_INSN_BASIC_BLOCK) (insn 62 64 63 2 (set (reg:DI 63) (reg:DI 0 ax)) -1 (nil) (nil)) (insn 63 62 53 2 (set (reg:DI 65) (reg:DI 1 dx)) -1 (nil) (nil)) so those could also be moved above the loop also (if you change the cost). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24762
