[Bug c/38167] Inline accessor to stdin is breaks on -O2 optimization
--- Comment #2 from jakub at gcc dot gnu dot org 2008-11-17 08:46 --- Works just fine here, with both 4.3 and 4.4, -O2 and -O0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38167
[Bug middle-end/38140] [4.4 Regression] ice for C code with -O2
--- Comment #4 from jakub at gcc dot gnu dot org 2008-11-17 08:48 --- Created an attachment (id=16708) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16708action=view) gcc44-pr38140.patch Patch I'm ATM bootstrapping/regtesting. tree-ssa-forwprop.c was creating invalid GIMPLE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38140
[Bug target/38130] [4.4 regression]__builtin_alloca (vs IRA?) testsuite failures on mingw32
--- Comment #2 from jakub at gcc dot gnu dot org 2008-11-17 09:21 ---
Web pass changes:
(insn 14 13 16 2 920929-1.c:5 (parallel [
(set (reg:SI 70)
(unspec_volatile:SI [
(reg:SI 70)
] 1))
(set (reg/f:SI 7 sp)
(minus:SI (reg/f:SI 7 sp)
(reg:SI 70)))
(clobber (reg:CC 17 flags))
]) 672 {allocate_stack_worker_32} (nil))
into:
(insn 14 13 16 2 920929-1.c:5 (parallel [
(set (reg:SI 80)
(unspec_volatile:SI [
(reg:SI 70)
] 1))
(set (reg/f:SI 7 sp)
(minus:SI (reg/f:SI 7 sp)
(reg:SI 70)))
(clobber (reg:CC 17 flags))
]) 672 {allocate_stack_worker_32} (nil))
Is this correct (given that the pattern uses match_dup)? Also, is there a
reason why the allocate_stack_worker_{32,64} patterns use match_dup for between
the output register and input register? I'd say using
(match_operand:SI 0 register_operand =a) for the output reg and
(match_operand:SI 1 register_operand a) for the input reg (match_dup 1)ed
into the sp adjustment would give the RA more freedom.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38130
[Bug target/38130] [4.4 regression]__builtin_alloca (vs IRA?) testsuite failures on mingw32
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38130
[Bug target/38134] [4.4 Regression] speed regression with inline-asm sse code
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38134
[Bug middle-end/38140] [4.4 Regression] ice for C code with -O2
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38140
[Bug middle-end/37908] atomic NAND op generate wrong code; __sync_nand_and_fetch, __sync_fetch_and_nand
--- Comment #11 from uros at gcc dot gnu dot org 2008-11-17 11:20 --- Subject: Bug 37908 Author: uros Date: Mon Nov 17 11:19:06 2008 New Revision: 141942 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141942 Log: PR middle-end/37908 * optabs.c (expand_sync_operation): Properly handle NAND case by calculating ~(t1 val) instead of (~t1 val). * builtins.c (expand_builtin_sync_operation): Warn for changed semantics in NAND builtins. * c.opt (Wsync-nand): New warning option. Describe -Wsync-nand. * doc/invoke.texi (Warning options): Add Wsync-nand. * doc/extend.texi (Atomic Builtins) [__sync_fetch_and_nand]: Correct __sync_fetch_and_nand builtin operation in the example. Add a note about changed semantics in GCC 4.4. [__sync_nand_and_fetch]: Correct __sync_nand_and_fetch builtin operation in the example. Add a note about changed semantics in GCC 4.4. testsuite/ChangeLog: PR middle-end/37908 * gcc.dg/pr37908.c: New test. * gcc.dg/ia64-sync-1.c: Correct __sync_fetch_and_nand and __sync_nand_and_fetch results. Add dg-message to look for the warning about changed semantics of NAND builtin. (init_si, init_di): Change init value for __sync_fetch_and_nand to -1. (test_si, test_di): Change expected result of __sync_nand_and_fetch to ~7. * gcc.dg/ia64-sync-2.c: Correct __sync_fetch_and_nand and __sync_nand_and_fetch results. Add dg-message to look for the warning about changed semantics of NAND builtin. (init_noret_si, init_noret_di): Change init value for __sync_fetch_and_nand to -1. (init_noret_si, init_noret_di): Change expected result of __sync_nand_and_fetch to ~7. * gcc.dg/sync-2.c: Correct __sync_fetch_and_nand and __sync_nand_and_fetch results. Add dg-message to look for the warning about changed semantics of NAND builtin. (init_qi, init_qi): Change init value for __sync_fetch_and_nand to -1. (init_hi, init_hi): Change expected result of __sync_nand_and_fetch to ~7. * gcc.dg/sync-3.c: Copy from sync-2.c instead of including the c source file. * gcc.c-torture/compile/sync-1.c: Add dg-message to look for the warning about changed semantics of NAND builtin. * gcc.c-torture/compile/sync-2.c: Ditto. * gcc.c-torture/compile/sync-3.c: Ditto. Added: trunk/gcc/testsuite/gcc.dg/pr37908.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/c.opt trunk/gcc/doc/extend.texi trunk/gcc/doc/invoke.texi trunk/gcc/optabs.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/compile/sync-1.c trunk/gcc/testsuite/gcc.c-torture/compile/sync-2.c trunk/gcc/testsuite/gcc.c-torture/compile/sync-3.c trunk/gcc/testsuite/gcc.dg/ia64-sync-1.c trunk/gcc/testsuite/gcc.dg/ia64-sync-2.c trunk/gcc/testsuite/gcc.dg/sync-2.c trunk/gcc/testsuite/gcc.dg/sync-3.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37908
[Bug c/31887] bad warning converting qualified void* to qualified array pointer
--- Comment #4 from bugs at 59A2 dot org 2008-11-17 12:24 ---
There is no way to qualify an array type, but this sort of conversion is very
useful. For instance, the optimizer produces better code for
void foo(const double a[], int m, int n) {
const double (*b)[n] = (const double(*)[n])a;
/* use b[i][j] in inner loops */
}
than when `a[i*n+j]' is used (without manually hoisting arithmetic out of inner
loops). With -Wcast-qual, a warning is given since the qualifier does not
apply to the array type, only the elements. Note that this example is very
similar to the example given in
http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf page 87
(physical page 94). Clearly the cast above should be possible, although there
is no way to express it in a way that is compatible with C99 paragraph 6.7.3.8.
I propose that -Wcast-qual promote qualifiers on array elements to the array
itself when determining whether a cast discards qualifiers. That is, not warn
for casts like the one above.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31887
[Bug target/37033] [4.4 Regression] Revision 138733 breaks -g vs -g0 for PCH
--- Comment #9 from ubizjak at gmail dot com 2008-11-17 12:27 --- We can add -fno-dwarf2-cfi-asm to gcc.dg/pch/valid-1b.hs to suppress definition of __GCC_HAVE_DWARF2_CFI_ASM in -g case. Patch at http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00807.html -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||11/msg00807.html Status|UNCONFIRMED |NEW Component|debug |target Ever Confirmed|0 |1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2008-11-17 12:27:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37033
[Bug tree-optimization/38168] New: failure in gamess benchmark when -ftree-parallelize-loops=4 is enabled
specperl /Develop/SPEC2006/bin/specpp -DSPEC_CPU_NO_HOLLERITH -DSPEC_CPU -DNDEBUG chgpen.F -o chgpen.fppized.f /Develop/Bins/bin//gfortran -c -o chgpen.fppized.o -O3 -mcpu=power6 -mtune=power6 -ftree-parallelize-loops=4 chgpen.fppized.f chgpen.fppized.f: In function 'stepit': chgpen.fppized.f:1726: error: basic block 425 should be marked irreducible chgpen.fppized.f:1726: error: edge from 425 to 418 should be marked irreducible chgpen.fppized.f:1726: error: basic block 418 should be marked irreducible chgpen.fppized.f:1726: error: edge from 418 to 68 should be marked irreducible chgpen.fppized.f:1726: confused by earlier errors, bailing out -- Summary: failure in gamess benchmark when -ftree-parallelize- loops=4 is enabled Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: razya at il dot ibm dot com GCC build triplet: powerpc64-suse-linux GCC host triplet: powerpc64-suse-linux GCC target triplet: powerpc64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38168
[Bug tree-optimization/38169] New: Wrong string constant optimizing
I have found a bug in string constant optimizing in gcc-4.4 trunk. It occurs with -O3 or -O2 -profile-generate (tested on x86_64 and ia64). For C the problem is fixed since rev. 141606, but not for C++. Tested rev. 141852. g++ is okay with non-static function (set -DNO_STATIC): $ ./g++-4.4-141852 -std=c++0x -DNO_STATIC -O3 testutf3.c -o testutf3 ./testutf3 Test OK g++ -O2 is also okay with static functions: $ ./g++-4.4-141852 -std=c++0x -O2 testutf3.c -o testutf3 ./testutf3 Test OK g++ is not okay with static functions using -O3 or -O2 -fprofile-generate: $ ./g++-4.4-141852 -std=c++0x -O3 testutf3.c -o testutf3 ./testutf3 Verify ws failed. Expected: Hello World L Got: 95ad96f8 2a 0 19566cdd0 2ab388 7f9566ca88 2a4003ec 0b408 Verify Us failed. Expected: Hello World U Got: 95579ab0 2a9555d724 2a95579ab0 2a 1 2a 0 0 1 2a 1 Verify ws failed. Expected: HelloWorld s L Got: 95ad96f8 2a 0 19566cdd0 2ab388 7f9566ca88 2a4003ec 0b408 7f Verify Us failed. Expected: HelloWorld s U Got: 95579ab0 2a9555d724 2a95579ab0 2a 1 2a 0 0 1 2a 1 0 Verify ws failed. Expected: HelloWorld L s Got: 95ad96f8 2a 0 19566cdd0 2ab388 7f9566ca88 2a4003ec 0b408 7f Verify Us failed. Expected: HelloWorld U s Got: 95579ab0 2a9555d724 2a95579ab0 2a 1 2a 0 0 1 2a 1 0 Test FAILED. 6 failures occured Aborted Exit 134 (SIGABRT) $ g++-4.4-141852 -std=c++0x -O2 -fprofile-generate testutf3.c -o testutf3 ./testutf3 Verify ws failed. Expected: Hello World L Got: 604340 09ccb80b1 0403779 040352c 0 b 0402117 09566cdd0 Verify us failed. Expected: Hello World u Got: ca88 9566 2a 0 750 40 0 0 4000 60 0 0 f2e0 Verify Us failed. Expected: Hello World U Got: 604340 095560ef2 2a604328 0 0 0 0 0 0 0402630 Verify ws failed. Expected: HelloWorld s L Got: 604340 09ccb80b1 0403779 040352c 0 b 0402117 09566cdd0 2a Verify us failed. Expected: HelloWorld s u Got: ca88 9566 2a 0 750 40 0 0 4000 60 0 0 f2e0 bfff Verify Us failed. Expected: HelloWorld s U Got: 604340 095560ef2 2a604328 0 0 0 0 0 0 0402630 0 Verify ws failed. Expected: HelloWorld L s Got: 604340 09ccb80b1 0403779 040352c 0 b 0402117 09566cdd0 2a Verify us failed. Expected: HelloWorld u s Got: ca88 9566 2a 0 750 40 0 0 4000 60 0 0 f2e0 bfff Verify Us failed. Expected: HelloWorld U s Got: 604340 095560ef2 2a604328 0 0 0 0 0 0 0402630 0 Verify us failed. Expected: Hello World Got: 6548 6c6c 206f 6f57 6c72 64 0 0 1 0 2a Verify us failed. Expected: Hello World Got: ca88 9566 2a 0 750 40 0 0 4000 60 0 0 Test FAILED. 11 failures occured Aborted Exit 134 (SIGABRT) gcc is okay since trunk rev. 141606 with and non-static functions (set -DNO_STATIC): $ gcc-4.4-141852 -std=gnu99 -DNO_STATIC -O3 testutf3.c -o testutf3 ./testutf3 Test OK $ gcc-4.4-141852 -std=gnu99 -O3 testutf3.c -o testutf3 ./testutf3 Test OK gcc old rev. 141605 was not okay: $ gcc-4.4-141605 -std=gnu99 -O3 testutf3.c -o testutf3 ./testutf3 Verify ws failed. Expected: Hello World L Got:0 0 0 0 05f363878 0 19566cdd0 2ab388 7f9566ca88 Verify Us failed. Expected: Hello World U Got:0 0177ff8e 09556bba0 2a9555d724 2a9556bba0 2a 143545520 0 [...] Test FAILED. 9 failures occured Aborted Exit 134 (SIGABRT) $ gcc-4.4-141605 -std=gnu99 -O2 -fprofile-generate testutf3.c -o testutf3 ./testutf3 Verify ws failed. Expected: Hello World L Got:0 0 0 0402700 09569dea1 2a604300 09ccb80b1 0403849 Verify us failed. Expected: Hello World u Got: ca88 9566 2a 0 6c8 40 0 0 4000 60 0 0 f2e0 [...] Test FAILED. 13 failures occured Aborted Exit 134 (SIGABRT) -- Summary: Wrong string constant optimizing Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: holger dot hopp at sap dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38169
[Bug tree-optimization/38169] Wrong string constant optimizing
--- Comment #1 from holger dot hopp at sap dot com 2008-11-17 13:09 --- Created an attachment (id=16709) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16709action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38169
[Bug tree-optimization/38170] New: diff failure in cactusADM benchmark when -ftree-parallelize-loops=4 is enabled
In benchADM.out.cmp (result of specdiff): 0115: 10 |0.100 | 0.99987677 | 1.5877 | -0.4683 | 0.4683 | 10 |0.100 | 1. | 1. | 0. | 0. | ^ 0116: 20 |0.200 | 0.99952526 | 1.00022181 | -0.00019306 | 0.00019306 | 20 |0.200 | 1. | 1. | 0. | 0. | ^ 0117: 30 |0.300 | 0.99900319 | 1.00046081 | -0.00043291 | 0.00043291 | 30 |0.300 | 1. | 1. | 0. | 0. | ^ 0118: 40 |0.400 | 0.99829310 | 1.00079573 | -0.00076711 | 0.00076711 | 40 |0.400 | 1. | 1. | 0. | 0. | ^ 0119: 50 |0.500 | 0.99736195 | 1.00124644 | -0.00119544 | 0.00119544 | 50 |0.500 | 1. | 1. | 0. | 0. | ^ 0120: 60 |0.600 | 0.99621475 | 1.00179950 | -0.00171307 | 0.00171307 | 60 |0.600 | 1. | 1. | 0. | 0. | ^ 0121: 70 |0.700 | 0.99486839 | 1.00243861 | -0.00231496 | 0.00231496 | 70 |0.700 | 1. | 1. | 0. | 0. | ^ 0122: 80 |0.800 | 0.99332902 | 1.00316352 | -0.00299734 | 0.00299734 | 80 |0.800 | 1. | 1. | 0. | 0. | ^ 0123: 90 |0.900 | 0.99159883 | 1.00397717 | -0.00375618 | 0.00375618 | 90 |0.900 | 1. | 1. | 0. | 0. | ^ 0124:100 |1.000 | 0.98968199 | 1.00487686 | -0.00458712 | 0.00458712 | 100 |1.000 | 1. | 1. | 0. | 0. | -- Summary: diff failure in cactusADM benchmark when -ftree- parallelize-loops=4 is enabled Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: razya at il dot ibm dot com GCC build triplet: powerpc64-suse-linux GCC host triplet: powerpc64-suse-linux GCC target triplet: powerpc64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38170
[Bug c/38167] Inline accessor to stdin is breaks on -O2 optimization
--- Comment #3 from aleksi dot nurmi at helsinki dot fi 2008-11-17 14:06 --- Works for me on 4.1.3 20080308 (prerelease) (Ubuntu 4.1.2-21ubuntu1) and (Ubuntu 20081013-0ubuntu2) 4.3.3 20081014 (prerelease), too. But not in 4.2.4 (Ubuntu 4.2.4-1ubuntu3). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38167
[Bug target/38118] gcc emits non-TLS data as TLS on Solaris 11/SPARC
--- Comment #2 from ro at techfak dot uni-bielefeld dot de 2008-11-17 14:25 --- Subject: Re: gcc emits non-TLS data as TLS on Solaris 11/SPARC I'm not completely sure this is a bug in Sun as. If you consider the assembler code for my testcase produced by gcc: .global tsd .section.tbss,#alloc,#write,#tls .align 4 .type tsd, #tls_object .size tsd, 4 tsd: .skip 4 .common non_tsd,4,4 versus what Studio 12 cc produces: .section.bss,#alloc,#write .common non_tsd,4,4 .section.tbss,#alloc,#write,#tls .common tsd,4,4 you see that gcc lacks the section switching between non_tsd and tsd. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38118
[Bug rtl-optimization/37397] IRA performance impact on SPEC CPU 2K/2006
--- Comment #4 from hjl dot tools at gmail dot com 2008-11-17 14:31 --- Revision 141860 caused 30% slowdown on 454.calculix in SPEC CPU 2006 with -O2 -ffast-math on Linux/Intel64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37397
[Bug libfortran/32784] [win32] Using 'CONOUT$', 'CONIN$', or 'CONERR$' as assigned file generates Fortran runtime error: Bad file descriptor
--- Comment #28 from steve dot chapel at a2pg dot com 2008-11-17 15:01 --- I'm changing the summary of this bug report to better indicate the problem that the patch fixes. Could we get the patch into gfortran 4.5? There is discussion on the NONMEM users mailing list about how to get NONMEM to work with gfortran on Windows, and users are waiting for a resolution to this issue. Thanks. -- steve dot chapel at a2pg dot com changed: What|Removed |Added Summary|[win32] Using 'con' or |[win32] Using 'CONOUT$', |'CONOUT$' as assigned file |'CONIN$', or 'CONERR$' as |generates Fortran runtime |assigned file generates |error: File 'con' does not |Fortran runtime error: Bad |exist |file descriptor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32784
[Bug c/38167] Accessor to stdin is breaks on -O2 optimization
--- Comment #4 from aleksi dot nurmi at helsinki dot fi 2008-11-17 15:11
---
I found an even shorter way to make it segfault, with no inline functions at
all. It's an -O2 problem, then.
#include stdio.h
struct iostream {
FILE *f;
};
static struct iostream our_stdin = { 0 };
void read_char(struct iostream* ios)
{
if (ios-f == 0)
if (ios == our_stdin)
ios-f = stdin;
fgetc(ios-f);
}
int main()
{
read_char(our_stdin);
return 0;
}
--
aleksi dot nurmi at helsinki dot fi changed:
What|Removed |Added
Summary|Inline accessor to stdin is |Accessor to stdin is breaks
|breaks on -O2 optimization |on -O2 optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38167
[Bug c/38167] Accessor to stdin breaks on -O2 optimization
--- Comment #5 from aleksi dot nurmi at helsinki dot fi 2008-11-17 15:53 --- GDB output showing that libc (debug) received a null pointer: Program received signal SIGSEGV, Segmentation fault. _IO_getc (fp=0x0) at getc.c:40 40_IO_acquire_lock (fp); (gdb) print fp $1 = (FILE *) 0x0 (gdb) up #1 0x0040051e in main () at fault.c:20 20 read_char(our_stdin); (gdb) print our_stdin.f $2 = (FILE *) 0x7f75cc0c96a0 (gdb) print stdin $3 = (struct _IO_FILE *) 0x7f75cc0c96a0 -- aleksi dot nurmi at helsinki dot fi changed: What|Removed |Added Summary|Accessor to stdin is breaks |Accessor to stdin breaks on |on -O2 optimization |-O2 optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38167
[Bug preprocessor/38161] [4.4 regression] #elif non-const expression #defined in this #if breaks
--- Comment #1 from tromey at gcc dot gnu dot org 2008-11-17 17:29 --- According to my reading of the standard, this code is in fact incorrect. This is basically the same as #36320. I'm beginning to wonder, though, whether this change was overly eager on my part and should be made -pedantic only, or something like that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38161
[Bug target/38134] [4.4 Regression] speed regression with inline-asm sse code
--- Comment #6 from ubizjak at gmail dot com 2008-11-17 18:11 --- I think that addps .LC10(%rip), %xmm0 mulps %xmm1, %xmm0 addps .LC11(%rip), %xmm0 mulps %xmm1, %xmm0 addps .LC12(%rip), %xmm0 mulps %xmm1, %xmm0 addps .LC13(%rip), %xmm0 mulps %xmm1, %xmm0 addps .LC14(%rip), %xmm0 mulps %xmm1, %xmm0 is the bottleneck. Perhaps we should split impilicit memory operands out of the insn by some generic peephole (if the register is available) and schedule loads appropriately. OTOH, loop optimizer should detect invariant loads and move them out of the loop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38134
[Bug target/38134] [4.4 Regression] speed regression with inline-asm sse code
--- Comment #7 from tim at klingt dot org 2008-11-17 18:19 --- Created an attachment (id=16710) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16710action=view) compressed preprocessed source, gcc-4.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38134
[Bug tree-optimization/38169] Wrong string constant optimizing
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-11-17 18:20 --- Maybe related to PR38051 - I cannot reproduce the problem after that rev. Can you double-check? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38169
[Bug target/38134] [4.4 Regression] speed regression with inline-asm sse code
--- Comment #8 from tim at klingt dot org 2008-11-17 18:30 --- Created an attachment (id=16711) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16711action=view) 16684: compressed preprocessed source, gcc-4.3 -- tim at klingt dot org changed: What|Removed |Added Attachment #16684|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38134
[Bug ada/20974] ACATS c250002: gnatchop cannot create file with special character
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2008-11-17 18:34 --- Does this still occur with more recent versions? -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20974
[Bug ada/20974] ACATS c250002: gnatchop cannot create file with special character
--- Comment #5 from laurent at guerby dot net 2008-11-17 18:41 --- According to: http://gcc.gnu.org/ml/gcc-testresults/2008-11/msg01399.html i686-apple-darwin9 is clean ACATS-wise, so I think we can assume this is fixed for current Apple hardware/software. -- laurent at guerby dot net changed: What|Removed |Added CC||laurent at guerby dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20974
[Bug middle-end/37565] __optimize__ attribute doesn't work correctly
--- Comment #7 from sje at cup dot hp dot com 2008-11-17 18:41 --- This also causes the failure of gcc.dg/pr37106-1.c on ia64-*-* targets. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565
[Bug ada/20974] ACATS c250002: gnatchop cannot create file with special character
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2008-11-17 18:45 --- i686-apple-darwin9 is clean ACATS-wise, so I think we can assume this is fixed for current Apple hardware/software. OK, closing. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20974
[Bug target/38134] [4.4 Regression] speed regression with inline-asm sse code
--- Comment #9 from tim at klingt dot org 2008-11-17 18:49 --- i have updated the test program and attached preprocessed sources of gcc 4.3 and 4.4 the loop prefix contains 4.4 (9 invariant loads, one store of a generated constant to the stack): pxor%xmm5, %xmm5 xorl%eax, %eax movdqa %xmm5, %xmm0 xorl%edx, %edx pcmpeqd %xmm5, %xmm0 movaps .LC2(%rip), %xmm14 psrld $31, %xmm0 movdqa .LC3(%rip), %xmm13 pslld $31, %xmm0 movaps .LC4(%rip), %xmm12 movaps .LC5(%rip), %xmm11 movaps .LC6(%rip), %xmm10 movaps .LC7(%rip), %xmm9 movaps .LC8(%rip), %xmm8 movaps .LC9(%rip), %xmm7 movaps .LC16(%rip), %xmm6 movdqa %xmm0, -24(%rsp) 4.3 (8 invariant loads, store one generated constant in register): pxor%xmm6, %xmm6 xorl%edx, %edx movdqa %xmm6, %xmm0 xorl%eax, %eax pcmpeqd %xmm6, %xmm0 movaps .LC9(%rip), %xmm15 psrld $31, %xmm0 movaps .LC10(%rip), %xmm14 pslld $31, %xmm0 movaps .LC11(%rip), %xmm13 movaps .LC12(%rip), %xmm12 movaps .LC13(%rip), %xmm11 movdqa .LC14(%rip), %xmm10 movaps .LC15(%rip), %xmm9 movaps .LC16(%rip), %xmm8 movdqa %xmm0, %xmm7 body: 4.3 (7 loads from memory, 2 loads are used in the next instruction, others are used later): .L48: movaps in(%rax), %xmm2 movaps .LC2(%rip), %xmm0 movdqa %xmm2, %xmm5 movdqa .LC3(%rip), %xmm4 pand%xmm7, %xmm5 movaps .LC4(%rip), %xmm1 addl$4, %edx #APP # 324 benchmarks/../source/dsp/../../libs/libsimdmath/lib/sincosf4.h 1 xorps %xmm5, %xmm2 # 0 2 #NO_APP mulps %xmm2, %xmm0 movaps %xmm2, %xmm3 #APP # 327 benchmarks/../source/dsp/../../libs/libsimdmath/lib/sincosf4.h 1 cvttps2dq %xmm0, %xmm0 # 0 2 #NO_APP pand%xmm0, %xmm4 paddd %xmm0, %xmm4 #APP # 330 benchmarks/../source/dsp/../../libs/libsimdmath/lib/sincosf4.h 1 cvtdq2ps %xmm4, %xmm0 # 0 2 #NO_APP pand%xmm10, %xmm4 mulps %xmm0, %xmm1 psrld $1, %xmm4 subps %xmm1, %xmm3 movaps .LC5(%rip), %xmm1 mulps %xmm0, %xmm1 mulps .LC6(%rip), %xmm0 subps %xmm1, %xmm3 subps %xmm0, %xmm3 movaps .LC7(%rip), %xmm0 movaps %xmm3, %xmm1 cmpltps %xmm2, %xmm0 mulps %xmm3, %xmm1 movaps %xmm0, %xmm2 movaps .LC8(%rip), %xmm0 mulps %xmm1, %xmm0 addps %xmm15, %xmm0 mulps %xmm1, %xmm0 addps %xmm14, %xmm0 mulps %xmm1, %xmm0 addps %xmm13, %xmm0 mulps %xmm1, %xmm0 addps %xmm12, %xmm0 mulps %xmm1, %xmm0 addps %xmm11, %xmm0 mulps %xmm1, %xmm0 mulps %xmm3, %xmm0 addps %xmm3, %xmm0 #APP # 341 benchmarks/../source/dsp/../../libs/libsimdmath/lib/sincosf4.h 1 andps %xmm2, %xmm0 # 0 2 # 342 benchmarks/../source/dsp/../../libs/libsimdmath/lib/sincosf4.h 1 andnps %xmm3, %xmm2 # 0 2 #NO_APP movaps %xmm8, %xmm3 #APP # 343 benchmarks/../source/dsp/../../libs/libsimdmath/lib/sincosf4.h 1 orps %xmm2, %xmm0 # 0 2 #NO_APP movdqa %xmm6, %xmm2 movaps %xmm0, %xmm1 psubd %xmm4, %xmm2 addps %xmm9, %xmm1 divps %xmm1, %xmm3 movaps %xmm3, %xmm1 #APP # 145 benchmarks/../source/dsp/../../libs/libsimdmath/lib/simdconst.h 1 andps %xmm2, %xmm1 # 0 2 # 146 benchmarks/../source/dsp/../../libs/libsimdmath/lib/simdconst.h 1 andnps %xmm0, %xmm2 # 0 2 # 147 benchmarks/../source/dsp/../../libs/libsimdmath/lib/simdconst.h 1 orps %xmm2, %xmm1 # 0 2 # 348 benchmarks/../source/dsp/../../libs/libsimdmath/lib/sincosf4.h 1 xorps %xmm5, %xmm1 # 0 2 #NO_APP movaps %xmm1, out(%rax) addq$16, %rax cmpl%edi, %edx jne .L48 4.4 (6 loads from memory, 5 loads are used as memory argument to opcodes): .L54: movaps in(%rax), %xmm2 movdqa -24(%rsp), %xmm3 addl$4, %edx pand%xmm2, %xmm3 #APP # 324 benchmarks/../source/dsp/../../libs/libsimdmath/lib/sincosf4.h 1 xorps %xmm3, %xmm2 # 0 2 #NO_APP movaps %xmm2, %xmm4 movaps %xmm2, %xmm15 mulps %xmm14, %xmm4 #APP # 327 benchmarks/../source/dsp/../../libs/libsimdmath/lib/sincosf4.h 1 cvttps2dq %xmm4, %xmm4 # 0 2 #NO_APP movdqa %xmm4, %xmm0 pand%xmm13, %xmm0 paddd %xmm0, %xmm4 #APP # 330 benchmarks/../source/dsp/../../libs/libsimdmath/lib/sincosf4.h 1 cvtdq2ps %xmm4, %xmm0 # 0 2 #NO_APP pand.LC14(%rip), %xmm4 movaps %xmm0, %xmm1 psrld $1, %xmm4 mulps %xmm12, %xmm1 subps %xmm1, %xmm15
[Bug ada/27243] [4.2 regression] ACATS c37215h fails
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2008-11-17 18:49 --- No plan to fix the failure at this point. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27243
[Bug ada/38131] [4.4 regression] ACATS cc70a01 and cxa4016 segv on exception
--- Comment #1 from laurent at guerby dot net 2008-11-17 19:17 ---
Reduced testcase from cxa4016 at rev 141913:
$ gnatmake -f -g t1
gcc -c -g t1.adb
gnatbind -x t1.ali
gnatlink t1.ali -g
$ ./t1
Erreur de segmentation
$ gdb ./t1
(gdb) r
Starting program: /home/guerby/tmp/t1
Program received signal SIGSEGV, Segmentation fault.
uw_update_context_1 (context=0xff8e8fc8, fs=0xff8e8c60) at
../../../trunk/libgcc/../gcc/unwind-dw2.c:177
177 return * (_Unwind_Ptr *) ptr;
Current language: auto; currently c
(gdb) bt
#0 uw_update_context_1 (context=0xff8e8fc8, fs=0xff8e8c60) at
../../../trunk/libgcc/../gcc/unwind-dw2.c:177
#1 0x00026310 in uw_update_context (context=0xff8e8fc8, fs=0xff8e8c60) at
../../../trunk/libgcc/../gcc/unwind-dw2.c:1388
#2 0x00027378 in _Unwind_RaiseException (exc=0x48010) at
../../../trunk/libgcc/../gcc/unwind.inc:127
#3 0x00020450 in ada.exceptions.exception_propagation.propagate_exception
(e=0x4276c, from_signal_handler=false) at a-exexpr.adb:589
#4 0x000211c0 in __gnat_raise_nodefer_with_msg (e=0x4276c) at
a-except.adb:829
#5 0x0002125c in __gnat_raise_exception (e=0x4276c, message={P_ARRAY =
0xff8e8b80, P_BOUNDS = 0x29778}) at a-except.adb:868
#6 0x0001352c in ada.strings.wide_fixed.replace_slice (source={P_ARRAY =
0xff8e9774, P_BOUNDS = 0xff8e96e0}, low=12, high=10, by={P_ARRAY = 0x292f0,
P_BOUNDS = 0xff8e96d8}) at a-stwifi.adb:447
#7 0x000142d8 in ada.strings.wide_fixed.replace_slice (source={P_ARRAY =
0xff8e9774, P_BOUNDS = 0x292e8}, low=12, high=10, by={P_ARRAY = 0x292f0,
P_BOUNDS = 0x29300}, drop=ada__strings__error,
justify=ada__strings__left, pad=32 ' ') at a-stwifi.adb:480
#8 0x00011648 in t1 () at t1.adb:5
(gdb) info local
orig_context = {reg = {0x0 repeats 14 times, 0xff8e8b7c, 0xff8e954c, 0x0,
0x4, 0x8, 0xc, 0x10, 0x14, 0x18, 0x1c, 0x20, 0x24, 0x28, 0x2c, 0x30, 0x34,
0x38, 0x3c, 0x0 repeats 71 times}, cfa = 0x0,
ra = 0x1352c, lsda = 0x315cf, bases = {tbase = 0x0, dbase = 0x0, func =
0x1330c}, flags = 1073741824, version = 0, args_size = 0, by_value = '\0'
repeats 102 times}
cfa = value optimized out
tmp_sp = {ptr = 0, word = 0}
(gdb) quit
The program is running. Exit anyway? (y or n) y
$ cat t1.adb
with Ada.Strings.Wide_Fixed;
procedure T1 is
Result_String : Wide_String(1..10) := (others = Ada.Strings.Wide_Space);
begin
Ada.Strings.Wide_Fixed.Replace_Slice(Result_String,
Result_String'Last + 2, -- should raise exception
Result_String'Last,
xxx);
end T1;
Note: If a-stwifi.adb is recompiled at -O0 or -O1 the test pass (both reduced
and full), at -O2 it fails so the issue is likely a miscompilation of
a-stwifi.adb
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38131
[Bug ada/37543] Assembler error during compilation
--- Comment #5 from sam at gcc dot gnu dot org 2008-11-17 19:40 --- Please open a separate bug if you still experience build problems. This one (problem with generated assembler when compiling Ada code) should be closed as it has been resolved by yourself. -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37543
[Bug testsuite/38099] tmpdir-gcc.dg-struct-layout-1/t027 c_compat_x_tst.o-c_compat_y_tst.o execute failure
--- Comment #24 from janis at gcc dot gnu dot org 2008-11-17 19:41 --- Subject: Bug 38099 Author: janis Date: Mon Nov 17 19:39:54 2008 New Revision: 141948 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141948 Log: 2008-11-14 Jack Howarth [EMAIL PROTECTED] PR testsuite/38099 * gcc.dg/compat/struct-layout-1_generate.c: Also use -no-mmx on i?86/x86_64 darwin. * g++.dg/compat/struct-layout-1_generate.c: Same. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/compat/struct-layout-1_generate.c trunk/gcc/testsuite/gcc.dg/compat/struct-layout-1_generate.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38099
[Bug fortran/34955] transfer_assumed_size_1.f90: Valgrind error: invalid read of size 3
--- Comment #18 from mikael at gcc dot gnu dot org 2008-11-17 19:43 ---
The problem is in ByteToString.
The assignment of the transfer result is changed to a memmove.
The memmove is controlled by the size of both the lhs and the rhs.
The size of the rhs (actually the charlen=3 in this case) is not the same as
that of the actual data, as the charlen was copied from string's typespec in
transfer.
Thus, we are copying 3 bytes, instead of 2.
I think the code is still a valid program and a wrong-code, as while the
standard allow to have a result (partially) undefined/processor-dependent, it
doesn't allow to read unallocated memory.
module TransferBug
type ByteType
integer(kind=1) :: singleByte
end type
type(ByteType) :: BytesPrototype(2)
contains
function StringToBytes(v) result (bytes)
character(len=2) :: v
type (ByteType) :: bytes(2)!size(transfer(v, BytesPrototype)))
bytes = transfer('Hi', BytesPrototype)
end function
subroutine BytesToString(bytes, string)
type (ByteType) :: bytes(2)
character(len=*) :: string
string = transfer(bytes, string)
end subroutine
end module
program main
use TransferBug
character(len=3) :: str
type(ByteType) :: i(1)
call BytesToString( StringToBytes('Hi'), str )
end program
Valgrind doesn't complain on this testcase, but I strongly suspect that the bug
is still there. Using the commented array size forces the creation of
temporaries, and then valgrind catches the error.
Now, how to fix this?
We could unconditionally create a temporary in transfer, so that we have both
the original data size and the target data size at the time of the memmove.
That would probably mean a lot of regressions, and not only speed ones.
We could keep track of the original data size.
I must admit I'm not satisfied with this one either.
What else?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34955
[Bug ada/16095] Illegal program not detected, X'Access of wrong type
--- Comment #2 from sam at gcc dot gnu dot org 2008-11-17 19:56 --- From what I understand: - access T1 is an access_definition and thus a general access type (RM 3.10(12/2)) - Y'Access is of the type of its context, which should be a general access type (RM 3.10.2(24/1)) - An equality operator exists for anonymous access types and is visible because it is defined in Standard (RM 4.5.2(7.2/2)) Note that the current GCC gives no error even on the line you marked with error detected. Do you agree that this bug can be closed? -- sam at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-06-14 04:48:37 |2008-11-17 19:56:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16095
[Bug ada/16212] Bug box in Gigi, code=316, on legal Ada 83 program
--- Comment #3 from sam at gcc dot gnu dot org 2008-11-17 19:59 --- Lowering priority: opened more than 4 years ago, concerns Ada 83, pathological case. +===GNAT BUG DETECTED==+ | 4.4.0 20081021 (experimental) (x86_64-unknown-linux-gnu) GCC error: | | in Case_Statement_to_gnu, at ada/gcc-interface/trans.c:1626 | | Error detected at test_251265.adb:4:9| -- sam at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P5 Last reconfirmed|2006-03-19 06:01:59 |2008-11-17 19:59:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16212
[Bug ada/23187] MAXPATHLEN usage in gcc/ada/*.c
--- Comment #10 from sam at gcc dot gnu dot org 2008-11-17 20:13 --- Lowering priority, 3 years without feedback despite a new request 7 months ago. -- sam at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23187
[Bug preprocessor/38161] [4.4 regression] #elif non-const expression #defined in this #if breaks
--- Comment #2 from h dot b dot furuseth at usit dot uio dot no 2008-11-17 20:15 --- Subject: Re: [4.4 regression] #elif non-const expression #defined in this #if breaks Yes, I should have read the #36320 text more carefully. I merely noticed that its empty #elif cannot expand to anything correct, while my example can (and does in the real-life case which produced it). I thought C99 6.10p7 was what saved it: The preprocessing tokens within a preprocessing directive are not subject to macro expansion unless otherwise stated. but maybe not. 6.10.1p3 doesn't say anything about some #elif branches not being evaluated:-( Hopefully that's just overly standard-lawerly though. Maybe comp.std.c would have been a better place to ask. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38161
[Bug ada/23390] abstract function in private part not overloading previous function is not allowed
--- Comment #1 from sam at gcc dot gnu dot org 2008-11-17 20:15 --- This is fixed in GCC 4.4.0 and gives the expected error. GNAT 4.4.0 20081116 (experimental) Copyright 1992-2008, Free Software Foundation, Inc. Compiling: three.adb (source file time stamp: 2008-11-17 20:14:51) ==Error messages for source file: one.ads 11. function Func (X : in Type_T) return Type_T is abstract; | abstract subprograms must be visible (RM 3.9.3(10)) -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23390
[Bug testsuite/34575] gcc.target/powerpc/parity-1.c and popcount-1.c scan-assembler popcntb on darwin9
--- Comment #4 from janis at gcc dot gnu dot org 2008-11-17 20:19 --- Fixed by Jack's patch. -- janis at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34575
[Bug testsuite/38008] gcc/testsuite/gcc.c-torture/execute/builtins/lib/sprintf.c unportable
--- Comment #3 from janis at gcc dot gnu dot org 2008-11-17 20:20 --- Fixed by Jack's patch. -- janis at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38008
[Bug testsuite/38098] gcc.dg/cpp/subframework1.c -fno-show-column fails on darwin9
--- Comment #2 from janis at gcc dot gnu dot org 2008-11-17 20:21 --- Fixed by Jack's patch. -- janis at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38098
[Bug testsuite/38099] tmpdir-gcc.dg-struct-layout-1/t027 c_compat_x_tst.o-c_compat_y_tst.o execute failure
--- Comment #25 from janis at gcc dot gnu dot org 2008-11-17 20:23 --- Fixed by Jack's patch. -- janis at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38099
[Bug ada/25844] [4.2/4.3/4.4 regression] ICE on overloaded renames
--- Comment #5 from sam at gcc dot gnu dot org 2008-11-17 20:28 --- % gcc -c x-toolkit.adb +===GNAT BUG DETECTED==+ | 4.4.0 20081116 (experimental) (x86_64-unknown-linux-gnu) Assert_Failure atree.adb:886| | Error detected at x-toolkit.ads:1369:7 | | -- sam at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.0.2 |4.0.2 4.4.0 Last reconfirmed|2006-01-18 18:49:05 |2008-11-17 20:28:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25844
[Bug tree-optimization/38169] Wrong string constant optimizing
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-11-17 20:34 --- Patch for 4.3: http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00830.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38169
[Bug tree-optimization/38169] Wrong string constant optimizing
-- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-17 20:34:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38169
[Bug middle-end/38140] [4.4 Regression] ice for C code with -O2
--- Comment #5 from jakub at gcc dot gnu dot org 2008-11-17 21:00 --- Subject: Bug 38140 Author: jakub Date: Mon Nov 17 20:58:52 2008 New Revision: 141949 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141949 Log: PR middle-end/38140 * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): If propagating x = a into *x = b, add a cast if not useless type conversion or don't optimize if another stmt would be needed. * gcc.dg/pr38140.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr38140.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-forwprop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38140
[Bug middle-end/38140] [4.4 Regression] ice for C code with -O2
--- Comment #6 from jakub at gcc dot gnu dot org 2008-11-17 21:00 --- Fixed. -- 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=38140
[Bug ada/30094] bogus use of CROSS_COMPILE in adaint.c
--- Comment #2 from sam at gcc dot gnu dot org 2008-11-17 21:13 --- This check is still present in the sources, albeit now using CROSS_DIRECTORY_STRUCTURE. -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-17 21:13:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30094
[Bug ada/30614] compiler puts the blame on in parameter mode, not pointer to constant, for assignment to component
--- Comment #2 from sam at gcc dot gnu dot org 2008-11-17 21:16 --- The proposed fix has been withheld by Robert Dewar who was not entirely satisfied by the proposed solution and proposed to send an alternate fix. Unassigning and lowering priority (the only issue is the error message quality). -- sam at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|sam at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30614
[Bug target/37362] [4.4 Regression] Bootstrap broken on mipsisa64r2-linux-gcc
--- Comment #4 from g0dsowncountry at yahoo dot com 2008-11-17 21:39 --- Using top-of-stack GCC and Binutils from Nov 17, issue still present; Applied the below patch and re-tried, no change in behavior. Fails the same way... FYI, This is what I'm using to configure GCC: - ../gcc-svn-111708/configure --prefix= --host=i686-host_pc-linux-gnu --target=mipsisa64r2-linux --build=i686-host_pc-linux-gnu --disable-nls --with-newlib --disable-shared --disable-threads --with-gnu-as --with-gnu-ld --disable-soft-float --enable-symvers=gnu --enable-__cxa_atexit --disable-libmudflap --disable-libssp --disable-libffi --disable-libgomp --with-local-prefix= --with-sysroot= --enable-multilib --enable-languages=c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37362
[Bug target/38130] [4.4 regression]__builtin_alloca (vs IRA?) testsuite failures on mingw32
--- Comment #3 from jakub at gcc dot gnu dot org 2008-11-17 22:12 --- Created an attachment (id=16712) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16712action=view) gcc44-pr38130.patch This patch fixes the testcase from quick look at generated assembly. Could anybody please bootstrap/regtest it on mingw? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38130
[Bug fortran/36463] [4.4 regression] gfc_get_default_type(): Bad symbol
--- Comment #15 from mikael at gcc dot gnu dot org 2008-11-17 22:19 ---
(In reply to comment #14)
I've just discovered I was paraphrasing Janus here:
http://gcc.gnu.org/ml/fortran/2008-10/msg00219.html
The error for comment #13 was introduced the patch in comment #10.
Knowing that, I tried this:
Index: expr.c
===
--- expr.c (révision 141942)
+++ expr.c (copie de travail)
@@ -3514,7 +3514,7 @@ replace_symbol (gfc_expr *expr, gfc_symbol *sym, i
expr-symtree-n.sym-ns == sym-ts.interface-formal_ns)
{
gfc_symtree *stree;
- gfc_get_sym_tree (expr-symtree-name, sym-formal_ns, stree);
+ gfc_get_sym_tree (expr-symtree-n.sym-name, sym-formal_ns, stree);
stree-n.sym-attr = expr-symtree-n.sym-attr;
expr-symtree = stree;
}
I don't know if it is solving the right problem, but at least the testcase in
comment #13 compiles with it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36463
[Bug middle-end/38157] -fconserve-stack enabled by default
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-11-17 22:23 --- Hmm: Common Var(flag_conserve_stack,0) Optimization It should be: Common Var(flag_conserve_stack) Init(0) Optimization Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-17 22:23:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38157
[Bug middle-end/38157] -fconserve-stack enabled by default
--- Comment #2 from hubicka at gcc dot gnu dot org 2008-11-17 22:27 --- Mine. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-11-17 22:23:14 |2008-11-17 22:27:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38157
[Bug target/38130] [4.4 regression]__builtin_alloca (vs IRA?) testsuite failures on mingw32
--- Comment #4 from jakub at gcc dot gnu dot org 2008-11-17 22:28 --- Created an attachment (id=16713) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16713action=view) gcc44-pr38130.patch I've talked about this with Honza on IRC: honza I would just use 0 constraint. At least in old times with regmove, regmove was able to discover that it should use same pseudo for input and output. If you use pair of =a and a only reload sees this fact honza so patch is OK with that change. This is an updated patch which uses 0 instead of a constraint for operand 1. So, can anyone please test it? Thanks. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Attachment #16712|0 |1 is obsolete|| AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38130
[Bug fortran/38138] [4.4 Regression] Revision 141890 caused gfortran.dg/proc_decl_18.f90
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38138
[Bug ada/16095] Illegal program not detected, X'Access of wrong type
--- Comment #3 from ludovic at ludovic-brenta dot org 2008-11-17 22:32
---
The bug was open at a time when the default mode of GCC was Ada 95; gcc -gnat95
still shows the error messages for line 11 if it is uncommented.
I think the bug is legitimate in Ada 95 mode (and probably in Ada 83 mode,
too). The example violates 3.10.2(28) because the accessibility level of Y is
deeper than that of the anonymous access type of X.
Looking at the new rules for Ada 2005, I see that 3.10.2(28) has not changed.
The AARM even says: 28.b/2 {AI95-00230-01} If A is an anonymous
access-to-object type of an access parameter access type, then the view can
never have a deeper accessibility level than A. In the present case, A is the
anonymous type of X and the view is Y, which does have a deeper accessibility
level than A.
Maybe I've missed an implicit type conversion rule, new to Ada 2005, that
permits converting Y'Access to the anonymous access type of X, thereby making
the program legal in -gnat05 mode. But in -gnat95 mode, I'm pretty confident
the program is illegal. The error messages for line 11 could be improved quite
a lot, though.
Anyway, I can't think of a situation where X = Y'Access (short of address
representation clauses or pragma Import/Export, where all bets are off anyway),
so I believe that even if the program is legal in Ada 2005, perhaps the
compiler should warn that = will always return False.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16095
[Bug target/38120] missing space in x86 assembly code for some mov instructions
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|trivial |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38120
[Bug ada/38131] [4.4 regression] ACATS cc70a01 and cxa4016 segv on exception
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38131
[Bug boehm-gc/38162] [4.4 Regression] FAIL: gctest
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|libgcj |boehm-gc GCC target triplet||x86_64-unknown-linux-gnu Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38162
[Bug fortran/36463] [4.4 regression] gfc_get_default_type(): Bad symbol
--- Comment #16 from janus at gcc dot gnu dot org 2008-11-17 22:56 --- I don't know if it is solving the right problem, but at least the testcase in comment #13 compiles with it. This indeed fixes it. Nice job. Obviously I was looking for the solution in the wrong places. Btw it also makes comment #12 compile, while the resulting executable produces a segfault. But I guess this is due to the weird things which this program does(?). Thanks for finding this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36463
[Bug testsuite/37326] [4.4 Regression] gcc.dg/tree-ssa/ssa-store-ccp-3.c scan-tree-dump-times optimized conststaticvariable 1
--- Comment #2 from sje at cup dot hp dot com 2008-11-17 22:58 --- hppa64 is setting __PIC__ because it sets flag_pic and generates PIC code by default but it sets flag_pic to 2 in override_options after we have already checked its value in decode_options and used its value to set flag_shlib. The optimization in this test is determined by flag_shlib. We need to either set flag_shlib in override_options when we set flag_pic (making hppa64 a true PIC platform) or not set flag_pic for PA64 even though it is generating PIC code or xfail the test. IA64 HP-UX does not set flag_pic even though the code is PIC, that is why it does not fail. Setting flag_shlib could make some code slower by preventing inlining so as to allow functions to be overridden which you have to do if the code is in a shared library. David, do you have a prefered fix? -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-17 22:58:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37326
[Bug ada/38131] [4.4 regression] ACATS cc70a01 and cxa4016 segv on exception
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38131
[Bug target/37362] [4.4 Regression] Bootstrap broken on mipsisa64r2-linux-gcc
--- Comment #5 from ubizjak at gmail dot com 2008-11-18 00:11 --- (In reply to comment #4) Using top-of-stack GCC and Binutils from Nov 17, issue still present; Applied the below patch and re-tried, no change in behavior. Fails the same way... This one is tested with a cross and works for me: Index: mips.md === --- mips.md (revision 141951) +++ mips.md (working copy) @@ -4537,7 +4537,7 @@ rtx low = mips_subword (operands[0], 0); rtx high = mips_subword (operands[0], 1); emit_insn (gen_store_wordmode (low, operands[1], const0_rtx)); - if (ISA_HAS_MXHC1) + if (register_operand (high, HALFMODEmode) ISA_HAS_MXHC1) emit_insn (gen_mfhc1mode (high, operands[1])); else emit_insn (gen_store_wordmode (high, operands[1], const1_rtx)); -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-18 00:11:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37362
[Bug testsuite/37326] [4.4 Regression] gcc.dg/tree-ssa/ssa-store-ccp-3.c scan-tree-dump-times optimized conststaticvariable 1
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2008-11-18 00:55 --- Subject: Re: [4.4 Regression] gcc.dg/tree-ssa/ssa-store-ccp-3.c scan-tree-dump-times optimized conststaticvariable 1 David, do you have a prefered fix? For 4.4, I don't think we can not remove the code which sets flag_pic. The code in config/pa would all have to be updated to add checks for TARGET_64BIT where flag_pic is used. There might be other side effects. I'm somewhat concerned about not setting flag_shlib in override options. However, I think flag_shlib will get set if -fpic/-fPIC is specified on the command line. Possibly a note should be added to the documentation. Would adding a dg-options statement for hppa64-*-* fix the test? Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37326
[Bug libffi/38129] FAIL: libffi.special/unwindtest.cc -shared-libgcc -lstdc++ execution test
--- Comment #1 from danglin at gcc dot gnu dot org 2008-11-18 01:22 --- This is an assembler EH bug. *** This bug has been marked as a duplicate of 37610 *** -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38129
[Bug target/37610] [4.4 Regression] FAIL: g++.dg/eh/pr29166.C execution test
--- Comment #1 from danglin at gcc dot gnu dot org 2008-11-18 01:22 --- *** Bug 38129 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37610
[Bug target/37362] [4.4 Regression] Bootstrap broken on mipsisa64r2-linux-gcc
--- Comment #6 from g0dsowncountry at yahoo dot com 2008-11-18 01:31
---
With the patch in Comment #5, the test case passes; but the GCC Build fails
with the following error message while creating
mipsisa64r2-linux/64/libgcc/_powitf2.o
../../../../gcc-svn-111708/libgcc/../gcc/libgcc2.c: In function '__powitf2':
../../../../gcc-svn-111708/libgcc/../gcc/libgcc2.c:1743: error: insn does not
satisfy its constraints:
(insn 209 208 202 8 ../../../../gcc-svn-111708/libgcc/../gcc/libgcc2.c:1742
(set (reg:TF 44 $f12)
(unspec:TF [
(mem/u/c/i:DI (lo_sum:DI (reg/f:DI 4 $4 [218])
(symbol_ref/u:DI (*.LC0) [flags 0x2])) [2 S8 A128])
(reg:TF 44 $f12)
] 32)) 336 {mthc1tf} (expr_list:REG_EQUAL (const_double:TF 1.0e+0
[0x0.8p+1])
(nil)))
../../../../gcc-svn-111708/libgcc/../gcc/libgcc2.c:1743: internal compiler
error: in copyprop_hardreg_forward_1, at regrename.c:1595
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37362
[Bug bootstrap/38010] gcc/config.gcc needs adjustment for darwin10
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2008-11-18 02:03 --- Fixed with the checkin of... r141803 | janis | 2008-11-12 16:33:34 -0500 (Wed, 12 Nov 2008) | 5 lines 2008-11-12 Jack Howarth [EMAIL PROTECTED] PR bootstrap/38010 * gcc/config.gcc: Use darwin9.h on darwin10 as well. -- howarth at nitro dot med dot uc dot edu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38010
[Bug target/37610] [4.4 Regression] FAIL: g++.dg/eh/pr29166.C execution test
--- Comment #2 from danglin at gcc dot gnu dot org 2008-11-18 02:31 ---
The hppa gas target currently defines DWARF2_LINE_MIN_INSN_LENGTH to 4 in
tc-hppa.h. I can fix this failure by changing DWARF2_LINE_MIN_INSN_LENGTH
to 1. However, the failure appears to be caused by an inconsistency in
the handling of DW_CFA_advance_loc1, DW_CFA_advance_loc2 and
DW_CFA_advance_loc4
in dw2gencfi.c and unwind-dw2.c.
In dw2gencfi.c, we have:
addressT delta = S_GET_VALUE (to) - S_GET_VALUE (from);
addressT scaled = delta / DWARF2_LINE_MIN_INSN_LENGTH;
if (scaled = 0x3F)
out_one (DW_CFA_advance_loc + scaled);
else if (delta = 0xFF)
{
out_one (DW_CFA_advance_loc1);
out_one (delta);
}
else if (delta = 0x)
{
out_one (DW_CFA_advance_loc2);
out_two (delta);
}
else
{
out_one (DW_CFA_advance_loc4);
out_four (delta);
}
In unwind-dw2.c, we have:
case DW_CFA_advance_loc1:
fs-pc += read_1u (insn_ptr) * fs-code_align;
insn_ptr += 1;
break;
case DW_CFA_advance_loc2:
fs-pc += read_2u (insn_ptr) * fs-code_align;
insn_ptr += 2;
break;
case DW_CFA_advance_loc4:
fs-pc += read_4u (insn_ptr) * fs-code_align;
insn_ptr += 4;
break;
The code in binutils/dwarf.c also scales the file values by the code
alignment factor. So two against one says the dw2gencfi.c code is wrong.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
CC||rth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37610
[Bug libfortran/32784] [win32] Using 'CONOUT$', 'CONIN$', or 'CONERR$' as assigned file generates Fortran runtime error: Bad file descriptor
--- Comment #29 from jvdelisle at gcc dot gnu dot org 2008-11-18 03:02 --- Steve, I will try but we also still have the issue of 38122 as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32784
[Bug target/34587] gcc.dg/initpri1.c fails on powerpc-apple-darwin
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2008-11-18 04:05 --- This test case appears to only fail for the default -fPIC on darwin. If compiled with -fno-PIC, the test case passes on i686-apple-darwin9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34587
[Bug target/34587] gcc.dg/initpri1.c fails on powerpc-apple-darwin
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2008-11-18 04:08 --- Created an attachment (id=16714) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16714action=view) assembly file for gcc.dg/initpri1.c at -m32 on i686-apple-darwin9 created with... /sw/src/fink.build/gcc44-4.3.999-20081117/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc44-4.3.999-20081117/darwin_objdir/gcc/ /sw/src/fink.build/gcc44-4.3.999-20081117/gcc-4.4-20081117/gcc/testsuite/gcc.dg/initpri1.c -ansi -pedantic-errors -lm -m32 --save-temps -o ./initpri1.exe -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34587
[Bug target/34587] gcc.dg/initpri1.c fails on powerpc-apple-darwin
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2008-11-18 04:09 --- Created an attachment (id=16715) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16715action=view) assembly file for gcc.dg/initpri1.c at -m32 with -fno-PIC on i686-apple-darwin9 created with... /sw/src/fink.build/gcc44-4.3.999-20081117/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc44-4.3.999-20081117/darwin_objdir/gcc/ /sw/src/fink.build/gcc44-4.3.999-20081117/gcc-4.4-20081117/gcc/testsuite/gcc.dg/initpri1.c -ansi -pedantic-errors -lm -m32 -fno-PIC --save-temps -o ./initpri1.exe -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34587
[Bug target/34587] gcc.dg/initpri1.c fails on powerpc-apple-darwin
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2008-11-18 04:19 --- Can confirm the same behavior with gcc 4.3.2 on powerpc-apple-darwin9. With... gcc-4 -ansi -pedantic-errors -lm -m32 initpri1.c the testcase aborts. With... gcc-4 -ansi -pedantic-errors -lm -m32 -fno-PIC initpri1.c it executes fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34587
[Bug target/38130] [4.4 regression]__builtin_alloca (vs IRA?) testsuite failures on mingw32
--- Comment #5 from dannysmith at users dot sourceforge dot net 2008-11-18 05:55 --- (In reply to comment #4) Created an attachment (id=16713) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16713action=view) [edit] gcc44-pr38130.patch I've talked about this with Honza on IRC: honza I would just use 0 constraint. At least in old times with regmove, regmove was able to discover that it should use same pseudo for input and output. If you use pair of =a and a only reload sees this fact honza so patch is OK with that change. This is an updated patch which uses 0 instead of a constraint for operand 1. So, can anyone please test it? Thanks. This patch bootstraps on mingw32 (c,c++,gfortran) successfully, libstcd++ now compiles and the two testcases reported as failing now pass. A full regtest is in progress and so far looks good. Thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38130
[Bug bootstrap/37915] bootstrap broken for cygwin
--- Comment #3 from dannysmith at users dot sourceforge dot net 2008-11-18 06:26 --- Hello Murali, Does the patch for PR 38130 fix the build of libstdc++ on cygwin? http://gcc.gnu.org/bugzilla/attachment.cgi?id=16713action=view Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added CC||dannysmith at users dot ||sourceforge dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37915
[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf
--- Comment #9 from tehila at il dot ibm dot com 2008-11-18 07:35 --- This testcase is indeed very slow on SPU, with -O2 and above. I don't see any slowness for -O1. If I turn off the insns scheduler (with -fno-schedule-insns) it is much faster: X4 faster for 1,000 args (ARG3), much more for 10,000 args (ARG4). It seems that the scheduler generates excessive register pressure, by hoisting loads and sinking stores. Maybe the decision-maker of the scheduler (which insn to move) should be improved. -- tehila at il dot ibm dot com changed: What|Removed |Added CC||uweigand at de dot ibm dot ||com, bergner at vnet dot ibm ||dot com, abel at ispras dot ||ru, tehila at il dot ibm dot ||com, zaks at il dot ibm dot ||com, meissner at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
