[Bug fortran/33554] [4.3 regression] Seg.fault: Default initialization of derived type uses uninitialized values
--- Comment #5 from anlauf at gmx dot de 2007-09-26 07:10 --- (In reply to comment #4) I found backups of other gfortran versions: Working: GNU Fortran (GCC) 4.3.0 20070420 (experimental) Failing: GNU Fortran (GCC) 4.3.0 20070805 (experimental) So it's a regression. -- anlauf at gmx dot de changed: What|Removed |Added Summary|Seg.fault: Default |[4.3 regression] Seg.fault: |initialization of derived |Default initialization of |type uses uninitialized |derived type uses |values |uninitialized values http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33554
[Bug fortran/33554] [4.3 regression] Seg.fault: Default initialization of derived type uses uninitialized values
--- Comment #6 from dominiq at lps dot ens dot fr 2007-09-26 07:45 --- > Failing: > GNU Fortran (GCC) 4.3.0 20070805 (experimental) Did you try a more recent version? I don't see the problem with Target: powerpc-apple-darwin8 gcc version 4.3.0 20070925 (experimental) (GCC) -> revision 128768 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33554
[Bug fortran/33554] [4.3 regression] Seg.fault: Default initialization of derived type uses uninitialized values
--- Comment #7 from burnus at gcc dot gnu dot org 2007-09-26 07:53 --- > I found backups of other gfortran versions: More tests: Works: 2007-07-23-r126835 Fails: 2007-07-25-r126902 This probably caused by: http://gcc.gnu.org/ml/gcc-cvs/2007-07/msg00745.html r126885 | pault | 2007-07-24 21:15:27 +0200 (Di, 24 Jul 2007) | 36 lines 2007-07-24 Paul Thomas <[EMAIL PROTECTED]> PR 31205 PR 32842 * trans-expr.c (gfc_conv_function_call): Remove the default initialization of intent(out) derived types. [...] > > GNU Fortran (GCC) 4.3.0 20070805 (experimental) > Did you try a more recent version? Yes, it is crashing with today's version and yesterday's -ftree-dump-original looks wrong; the problem with memory-access bugs is that it is quite random whether it is detected or not - even valgrind does not always detect it. (It does here, which is no surprise as the program crashes with a segmentation fault.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33554
[Bug fortran/33554] [4.3 regression] Seg.fault: Default initialization of derived type uses uninitialized values
--- Comment #8 from dominiq at lps dot ens dot fr 2007-09-26 08:10 --- Now I get a bus error, but I have to use: gfc -m64 -g pr33554.f90 -O0 with gfc -m64 -g pr33554.f90 -fbounds-check -O0 the bus error disappear. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33554
[Bug target/31985] Wide operations (i.e. adddi3) are split too late
--- Comment #2 from ubizjak at gmail dot com 2007-09-26 08:53 --- The testcase from comment #1 is fixed: test_c: subl$16, %esp movl24(%esp), %eax mull20(%esp) movl%eax, 8(%esp) movl%edx, 12(%esp) addl$16, %esp ret test_asm: subl$16, %esp movl20(%esp), %eax #APP mull 24(%esp) #NO_APP movl%eax, 8(%esp) movl%edx, 12(%esp) addl$16, %esp ret and the testcase from the description is much better: test_c: pushl %ebx subl$16, %esp movl36(%esp), %eax movl28(%esp), %ecx movl24(%esp), %ebx movl32(%esp), %edx (*) addl%ecx, %eax movl%eax, 8(%esp) (*) adcl%ebx, %edx movl%edx, 12(%esp) addl$16, %esp popl%ebx ret Still, addl and adcl could use memory input operand, removing two movs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31985
[Bug middle-end/33559] GCC manual documents Wstack-protector option but not fstack-protector/fno-stack-protector
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-26 08:59 ---
They are included as far as I can tell:
@item -fstack-protector
Emit extra code to check for buffer overflows, such as stack smashing
attacks. This is done by adding a guard variable to functions with
vulnerable objects. This includes functions that call alloca, and
functions with buffers larger than 8 bytes. The guards are initialized
when a function is entered and then checked when the function exits.
If a guard check fails, an error message is printed and the program exits.
@item -fstack-protector-all
Like @option{-fstack-protector} except that all functions are protected.
They are documented
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Optimize-Options.html#Optimize-Options
Though I see they are not part of the option index.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33559
[Bug tree-optimization/30375] [4.3 Regression] tree-ssa-dse incorrectly removes struct initialization
--- Comment #29 from belyshev at depni dot sinp dot msu dot ru 2007-09-26
09:31 ---
Another testcase:
/* { dg-do run } */
/* { dg-options "-O1 --param max-aliased-vops=0" } */
struct T
{
int a, b;
} t;
__attribute__((noinline)) struct T *f (struct T *p)
{
struct T *q = __builtin_malloc (sizeof (struct T));
*q = *p;
return q;
}
int main (void)
{
struct T *p;
t.a = 1;
t.b = 2;
p = f (&t);
t.a = 3;
if (p->a != 1)
__builtin_abort ();
return 0;
}
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed |Added
CC||belyshev at depni dot sinp
||dot msu dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30375
[Bug tree-optimization/33560] New: [4.3 regression] wrong code with dse and alias partitioning
Reduced from 197.parser which failed with -O1:
/* { dg-do run } */
/* { dg-options "-O1 --param max-aliased-vops=0" } */
struct T
{
int a, b;
} t;
__attribute__((noinline)) struct T *f (struct T *p)
{
struct T *q = __builtin_malloc (sizeof (struct T));
*q = *p;
return q;
}
int main (void)
{
struct T *p;
t.a = 1;
t.b = 2;
p = f (&t);
t.a = 3;
if (p->a != 1)
__builtin_abort ();
return 0;
}
--
Summary: [4.3 regression] wrong code with dse and alias
partitioning
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: belyshev at depni dot sinp dot msu dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33560
[Bug tree-optimization/30375] [4.3 Regression] tree-ssa-dse incorrectly removes struct initialization
--- Comment #30 from belyshev at depni dot sinp dot msu dot ru 2007-09-26 09:46 --- (In reply to comment #29) > Another testcase: Ignore this one, I filed it as a separate report, see bug 33560 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30375
[Bug tree-optimization/33560] [4.3 regression] wrong code with dse and alias partitioning
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-26 09:57 --- Confirmed. I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||30375 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-26 09:57:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33560
[Bug tree-optimization/33560] [4.3 regression] wrong code with dse and alias partitioning
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-26 09:58 --- get_use_of_stmt_lhs happily skips over calls. -- 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|2007-09-26 09:57:56 |2007-09-26 09:58:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33560
[Bug fortran/33561] New: Wrong code for single precision math functions on x86_64-pc-mingw32
I have had a bug report from people who tested my gfortran binaries for
mingw-w64 that the float variants of math functions aren't working properly.
The proper report that was sent to me has this example:
C:\gfortran\test\single_bug>type table.f90
program table
real x
integer i
write(*,*) ' x sin(x)cos(x) tan(x)'
do i = 0, 10
x = i
write(*,*) x, sin(x), cos(x), tan(x)
end do
end program table
C:\gfortran\test\single_bug>c:\gfortran\win64\bin\x86_64-pc-mingw32-gfortran
table.f90 -o table
C:\gfortran\test\single_bug>table
x sin(x)cos(x) tan(x)
0.00 0.00 0.00 0.00
1.00 1.00 1.00 1.00
2.00 2. 2. 2.
3.00 3. 3. 3.
4.00 4. 4. 4.
5.00 5. 5. 5.
6.00 6. 6. 6.
7.00 7. 7. 7.
8.00 8. 8. 8.
9.00 9. 9. 9.
10.010.10.10.
Indeed, there is a difference between a C function that calls sinf():
#include
float foo(float *x) { return sinf(*x); }
which is compiled into:
_foo:
LFB47:
pushq %rbp
LCFI0:
movq%rsp, %rbp
LCFI1:
subq$32, %rsp
LCFI2:
movq%rcx, 16(%rbp)
movq16(%rbp), %rax
movss (%rax), %xmm0
call_sinf
leave
ret
and the equivalent Fortran function:
real function foo(x)
real x
foo = sin(x)
end function foo
that is compiled into:
_foo_:
LFB2:
pushq %rbp
LCFI0:
movq%rsp, %rbp
LCFI1:
subq$64, %rsp
LCFI2:
movq%rcx, 16(%rbp)
movq16(%rbp), %rax
movss (%rax), %xmm0
call_sinf
movss %xmm0, -4(%rbp)
movl-4(%rbp), %eax
movl%eax, -20(%rbp)
movss -20(%rbp), %xmm0
leave
ret
(Notice the extra lines between the call to _sinf and the leave.)
--
Summary: Wrong code for single precision math functions on
x86_64-pc-mingw32
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
GCC build triplet: i386-pc-mingw32
GCC host triplet: i386-pc-mingw32
GCC target triplet: x86_64-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33561
[Bug fortran/33561] Wrong code for single precision math functions on x86_64-pc-mingw32
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-26 11:45:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33561
[Bug tree-optimization/30375] [4.3 Regression] tree-ssa-dse incorrectly removes struct initialization
--- Comment #31 from rguenth at gcc dot gnu dot org 2007-09-26 11:55 --- Subject: Bug 30375 Author: rguenth Date: Wed Sep 26 11:55:17 2007 New Revision: 128810 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128810 Log: 2007-09-26 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/30375 PR tree-optimization/33560 * tree-ssa-dse.c (get_use_of_stmt_lhs): Give up on uses with calls. Revert 2006-05-22 Aldy Hernandez <[EMAIL PROTECTED]> * tree-ssa-dse.c (aggregate_vardecl_d): New. (dse_global_data): Add aggregate_vardecl field. (dse_possible_dead_store_p): New. Add prev_defvar variable. Allow immediate uses and previous immediate uses to differ if they are setting different parts of the whole. (get_aggregate_vardecl): New. (dse_record_partial_aggregate_store): New. (dse_whole_aggregate_clobbered_p): New. (dse_partial_kill_p): New. Call dse_maybe_record_aggregate_store(). When checking whether a STMT and its USE_STMT refer to the same memory address, check also for partial kills that clobber the whole. Move some variable definitions to the block where they are used. (aggregate_vardecl_hash): New. (aggregate_vardecl_eq): New. (aggregate_vardecl_free): New. (aggregate_whole_store_p): New. (tree_ssa_dse): Initialize and free aggregate_vardecl. Mark which aggregate stores we care about. * gcc.dg/tree-ssa/complex-4.c: XFAIL. * gcc.dg/tree-ssa/complex-5.c: Likewise. * gcc.dg/tree-ssa/ssa-dse-9.c: Likewise. * gcc.dg/torture/pr30375.c: New testcase. * gcc.dg/torture/pr33560.c: New testcase. * gcc.dg/tree-ssa/pr30375.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr30375.c trunk/gcc/testsuite/gcc.dg/torture/pr33560.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr30375.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/complex-4.c trunk/gcc/testsuite/gcc.dg/tree-ssa/complex-5.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-9.c trunk/gcc/tree-ssa-dse.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30375
[Bug tree-optimization/33560] [4.3 regression] wrong code with dse and alias partitioning
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-26 11:55 --- Subject: Bug 33560 Author: rguenth Date: Wed Sep 26 11:55:17 2007 New Revision: 128810 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128810 Log: 2007-09-26 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/30375 PR tree-optimization/33560 * tree-ssa-dse.c (get_use_of_stmt_lhs): Give up on uses with calls. Revert 2006-05-22 Aldy Hernandez <[EMAIL PROTECTED]> * tree-ssa-dse.c (aggregate_vardecl_d): New. (dse_global_data): Add aggregate_vardecl field. (dse_possible_dead_store_p): New. Add prev_defvar variable. Allow immediate uses and previous immediate uses to differ if they are setting different parts of the whole. (get_aggregate_vardecl): New. (dse_record_partial_aggregate_store): New. (dse_whole_aggregate_clobbered_p): New. (dse_partial_kill_p): New. Call dse_maybe_record_aggregate_store(). When checking whether a STMT and its USE_STMT refer to the same memory address, check also for partial kills that clobber the whole. Move some variable definitions to the block where they are used. (aggregate_vardecl_hash): New. (aggregate_vardecl_eq): New. (aggregate_vardecl_free): New. (aggregate_whole_store_p): New. (tree_ssa_dse): Initialize and free aggregate_vardecl. Mark which aggregate stores we care about. * gcc.dg/tree-ssa/complex-4.c: XFAIL. * gcc.dg/tree-ssa/complex-5.c: Likewise. * gcc.dg/tree-ssa/ssa-dse-9.c: Likewise. * gcc.dg/torture/pr30375.c: New testcase. * gcc.dg/torture/pr33560.c: New testcase. * gcc.dg/tree-ssa/pr30375.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr30375.c trunk/gcc/testsuite/gcc.dg/torture/pr33560.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr30375.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/complex-4.c trunk/gcc/testsuite/gcc.dg/tree-ssa/complex-5.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-9.c trunk/gcc/tree-ssa-dse.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33560
[Bug tree-optimization/33562] New: aggregate DSE disabled
Author: rguenth Date: Wed Sep 26 11:55:17 2007 New Revision: 128810 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128810 Log: 2007-09-26 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/30375 PR tree-optimization/33560 ... * gcc.dg/tree-ssa/complex-4.c: XFAIL. * gcc.dg/tree-ssa/complex-5.c: Likewise. * gcc.dg/tree-ssa/ssa-dse-9.c: Likewise. -- Summary: aggregate DSE disabled Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization, xfail Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org BugsThisDependsOn: 30375 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33562
[Bug tree-optimization/33560] [4.3 regression] wrong code with dse and alias partitioning
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-09-26 11:56 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33560
[Bug tree-optimization/30375] [4.3 Regression] tree-ssa-dse incorrectly removes struct initialization
--- Comment #32 from rguenth at gcc dot gnu dot org 2007-09-26 11:56 --- 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=30375
[Bug tree-optimization/33383] [4.3 Regression] Revision 128092 miscompiles 400.perlbench
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-09-26 11:57 --- This should now be fixed. Waiting for next results from the spec-tester to verify. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33383
[Bug c/16602] Spurious warnings about pointer to array -> const pointer to array conversion
--- Comment #5 from jozef dot behran at krs dot sk 2007-09-26 11:58 ---
Section 5.6.2.1, paragraph 2 says "E1[E2] is equivalent to *((E1)+(E2))". This
means if we have "typedef int THostAddr[8]" then the declaration "THostAddr
*Host" declares Host to be a pointer to 8-item arrays of integers, so the
"const" in "const THostAddr *Host" must be applied to the whole array type
called "THostAddr" and not just the member type of the array type "THostAddr".
Also section 6.7.7, paragraph 3 says "typedef" introduces a synonym to a type
specified by the specifier. Therefore the element type of the "THostAddr[10]"
type is "THostAddr" and not "int" (the element type of "THostAddr"). This
meaning is hidden in the words "a typedef declarator does not introduce a new
type, only a synonym for the type specified" (this implies "a typedef
declarator introduces a synonym for the type specified").
Just to make my point clear: these two array variables don't have the same
element type:
typedef int THostAddr[8];
THostAddr HostList1[10];
int HostList2[80];
The element type of HostList1 is an 8-item array of ints, while the element
type of HostList2 is plain int (so you can write "HostList1[x][y]" but not
"HostList2[x][y]"). If you don't believe me, try this little program:
--- snip ---
#include
typedef int THostAddr[8];
THostAddr HostList1[10];
int HostList2[80];
int main(void)
{
printf("%d %d\n",sizeof(HostList1[0]),sizeof(HostList2[0]));
printf(
"%d %d\n",
(int *)(HostList1+1)-(int *)HostList1,
(int *)(HostList2+1)-(int *)HostList2
);
return(0);
}
--- snip ---
It will say "32 4" on my x86 GNU/Linux box (or maybe some other number on
different platforms but the first number will always be 8-times bigger than the
second one). So when the *SIZES* of the element types of the two variables
don't match, they clearly cannot have the same element type.
The conclusion is that you are wrong with the argument in bug 33076. You cannot
say the objects that trigger the spurious warnings have "int" as their element
type, cause they don't have. Their element type is an array of ints. And then
the "const" qualifier must be applied to the whole of this "array of ints" in
these examples according to the standard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16602
[Bug fortran/33561] Wrong code for single precision math functions on x86_64-pc-mingw32
--- Comment #1 from ubizjak at gmail dot com 2007-09-26 12:00 --- (In reply to comment #0) > (Notice the extra lines between the call to _sinf and the leave.) -O2 will remove these lines (as well as the lines above _sinf): BTW: Could you check if _sinf returns values in %xmm0 reg? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33561
[Bug fortran/33561] Wrong code for single precision math functions on x86_64-pc-mingw32
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-26 12:03 --- There is nothing wrong with the extra asm instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33561
[Bug tree-optimization/33562] aggregate DSE disabled
-- belyshev at depni dot sinp dot msu dot ru changed: What|Removed |Added CC||belyshev at depni dot sinp ||dot msu dot ru Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-26 12:03:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33562
[Bug c/33076] Warning when passing a pointer to a const array to a function that expects a pointer to a non-cast one
--- Comment #6 from jozef dot behran at krs dot sk 2007-09-26 12:06 --- > Neither C nor C++ have qualified array types, only arrays of qualified > element types, but C++ has different rules from C regarding conversions > involving qualifiers, which allow some conversions (involving arrays or > pointers to pointers) not allowed in C. Could you give me reference in the C standard where this is stated ? The section 6.7.3, paragraph 8, says nothing about C/C++ not having qualified array types, it only says that a qualifier applied to an array type holds for the element type of the array type (these two are not the same things, see bug 16602 for more discussion about the topic). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33076
[Bug c/16602] Spurious warnings about pointer to array -> const pointer to array conversion
--- Comment #6 from jsm28 at gcc dot gnu dot org 2007-09-26 12:09 --- When you apply const to "array of int", the resulting type is "array of const int" not "const array of int"; that's how type qualifiers and arrays interact in C, there is no such thing as a qualified array type. "array of const int" is not a const-qualified type in C. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16602
[Bug c/33076] Warning when passing a pointer to a const array to a function that expects a pointer to a non-cast one
--- Comment #7 from jozef dot behran at krs dot sk 2007-09-26 12:18 --- > Neither C nor C++ have qualified array types, only arrays of qualified > element types, but C++ has different rules from C regarding conversions > involving qualifiers, which allow some conversions (involving arrays or > pointers to pointers) not allowed in C. And another point: Whether C/C++ have or don't have qualified array types, still the difference between the "const caca *" and "caca *" types is a "const" qualifier being applied to some part of the "caca *" base type. Therefore the types must be compatible when the automatic type conversion involved only adds "const" qualifiers to the type. Therefore the warnings are not legitimate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33076
[Bug c/25309] [4.0/4.1/4.2/4.3 Regression] ICE on initialization of a huge array
--- Comment #15 from jsm28 at gcc dot gnu dot org 2007-09-26 12:32 --- Subject: Bug 25309 Author: jsm28 Date: Wed Sep 26 12:32:27 2007 New Revision: 128811 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128811 Log: PR c/25309 * c-common.c (complete_array_type): Diagnose too-large arrays and set type to error_mark_node. testsuite: * gcc.dg/large-size-array-2.c: Expect diagnostic for too-large array. * gcc.dg/large-size-array-4.c: New. Copy of large-size-array-2.c without -O2. Added: trunk/gcc/testsuite/gcc.dg/large-size-array-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/large-size-array-2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25309
[Bug c/16602] Spurious warnings about pointer to array -> const pointer to array conversion
--- Comment #7 from jozef dot behran at krs dot sk 2007-09-26 12:33 --- Hm, I must apologize for argumenting about wrong point of this issue. Now I can see why other sometimes say "think before you type" :) The problem here is not whether applying const to "array of int" makes "const array of int" or "array of const int". The problem here is why gcc does not apply that "const" automatically and rather complains about incompatible pointer types. I am reopening the bug cause I still don't have a clue why "pointer to array of ints" typed expression is assignment incompatible with a "pointer to array of const ints" typed lvalue. Especially when "pointer to int" typed expression IS assignment compatible with "pointer to const int" typed lvalue. This is what is this bug all about. -- jozef dot behran at krs dot sk changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16602
[Bug c/33076] Warning when passing a pointer to a const array to a function that expects a pointer to a non-cast one
--- Comment #8 from joseph at codesourcery dot com 2007-09-26 12:38 --- Subject: Re: Warning when passing a pointer to a const array to a function that expects a pointer to a non-cast one On Wed, 26 Sep 2007, jozef dot behran at krs dot sk wrote: > Could you give me reference in the C standard where this is stated ? The > section 6.7.3, paragraph 8, says nothing about C/C++ not having qualified > array > types, it only says that a qualifier applied to an array type holds for the > element type of the array type (these two are not the same things, see bug > 16602 for more discussion about the topic). That which you quote means there is no way to put a qualifier on the array type because any attempt to do so puts it on the element type instead. That there are no qualified array types is simply the logical conclusion from there being no C syntax to write one. Note "not the array type" in that paragraph. The question of whether abstractly one might imagine a qualified array type in C despite the lack of syntax to describe one, and how such a type (notwithstanding the lack of syntax to describe it) would behave if it were to exist, is not an interesting one in the absence of implementation extensions to define such a type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33076
[Bug tree-optimization/33563] New: [4.3 Regression] DSE removes non-dead store
For gcc.dg/torture
/* { dg-do run } */
/* { dg-options "--param max-aliased-vops=0" } */
struct T
{
int a, b;
} t, q;
int main (void)
{
struct T *p;
t.a = 1;
t.b = 2;
q = t;
t.a = 3;
if (q.a != 1)
__builtin_abort ();
return 0;
}
the logic behind tree-ssa-dse.c:get_use_of_stmt_lhs is wrong.
--
Summary: [4.3 Regression] DSE removes non-dead store
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33563
[Bug c/33076] Warning when passing a pointer to a const array to a function that expects a pointer to a non-cast one
--- Comment #9 from joseph at codesourcery dot com 2007-09-26 12:42 --- Subject: Re: Warning when passing a pointer to a const array to a function that expects a pointer to a non-cast one On Wed, 26 Sep 2007, jozef dot behran at krs dot sk wrote: > And another point: Whether C/C++ have or don't have qualified array types, > still the difference between the "const caca *" and "caca *" types is a > "const" > qualifier being applied to some part of the "caca *" base type. Therefore the > types must be compatible when the automatic type conversion involved only adds > "const" qualifiers to the type. Therefore the warnings are not legitimate. Read the C FAQ. You can't pass a "char **" where a "const char **" is expected either in C. That's how the language works. http://c-faq.com/ansi/constmismatch.html C++ allows certain cases C doesn't that can be shown to be safe, as noted in that FAQ. A proposal to make C use the C++ rules was rejected in the course of C99 development. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33076
[Bug fortran/33561] Wrong code for single precision math functions on x86_64-pc-mingw32
--- Comment #3 from ktietz at gcc dot gnu dot org 2007-09-26 12:52 --- This doesn't seems to be an error in gcc. The w64 crt currently does not implement some math functions proper. May somebody can assist to port the assemble coded function for this target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33561
[Bug tree-optimization/33563] [4.3 Regression] DSE removes non-dead store
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-26 13:26 --- I have a patch. -- 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 |2007-09-26 13:26:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33563
[Bug c/33564] New: A static inline function as a parameter of another static inline function is not inlined.
This is a duplicate of bug 1601, which I can't reopen.
This bug is still present on 4.1.2-13 (RedHat, 20070626) and 3.4.6-3 (RedHat
20060404). Looking at the produced assembly, f2 and fun are both produced; the
assembly should only produce fun and inline both f1 and f2. I havn't tested it
on 4.2.1 yet, but I'm reopening it because it was reported as fixed years ago.
I'm compiling the test given below with:
gcc -c -O3 --save-temps inline_test.c
How-To-Repeat (from bug 1601):
static inline int
f1( int (*f)(int y), int q )
{
return( (*f)( q ) );
}
static inline int
f2( int z )
{
return( z ^ 32 );
}
int fun( int x )
{
return( f1( &f2, x ) );
}
--
Summary: A static inline function as a parameter of another
static inline function is not inlined.
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michaelferguson at acm dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33564
[Bug target/33168] [4.3 Regression] GCC Boot failure, building libstc++
--- Comment #11 from amodra at bigpond dot net dot au 2007-09-26 14:27 --- We first choose a section here, when decl readonly_flag is false: #0 get_section (name=0x4cca824 ".data._ZSt15system_category", flags=512, decl=0x4e44000) at /src/gcc-current/gcc/varasm.c:527 #1 0x1067bd70 in get_block_for_decl (decl=0x4e44000) at /src/gcc-current/gcc/varasm.c:1196 #2 0x1067c588 in make_decl_rtl (decl=0x4e44000) at /src/gcc-current/gcc/varasm.c:1395 #3 0x1067d3d8 in notice_global_symbol (decl=0x4e44000) at /src/gcc-current/gcc/varasm.c:1558 #4 0x106dd04c in varpool_mark_needed_node (node=0x4f12500) at /src/gcc-current/gcc/varpool.c:192 #5 0x106dda78 in varpool_finalize_decl (decl=0x4e44000) at /src/gcc-current/gcc/varpool.c:297 #6 0x10403fac in rest_of_decl_compilation (decl=0x4e44000, top_level=1, at_end=0) at /src/gcc-current/gcc/passes.c:192 #7 0x1002c624 in make_rtl_for_nonlocal_decl (decl=0x4e44000, init=0x0, asmspec=0x10b4f398 "") at /src/gcc-current/gcc/cp/decl.c:5136 #8 0x1003e1ec in cp_finish_decl (decl=0x4e44000, init=0x0, init_const_expr_p=0 '\0', asmspec_tree=, flags=8) at /src/gcc-current/gcc/cp/decl.c:5511 Note flags=512 is SECTION_WRITE in get_section call. We set readonly near the end of cp_finish_decl. This change in the readonly flag is the cause of later trouble when assemble_variable is called, as targetm.section_type_flags (called from get_named_section, from get_variable_section, from assemble_variable) now returns 0. get_section is then called with flags=0, triggering the error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33168
[Bug other/33543] make html does not generate gccinstall documentation properly
--- Comment #1 from manu at gcc dot gnu dot org 2007-09-26 14:30 --- This is a known problem. There is a patch here: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01735.html -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-26 14:30:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33543
[Bug fortran/33561] Wrong code for single precision math functions on x86_64-pc-mingw32
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-09-26 14:47 --- Sorry for the wrong report, and thanks. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33561
[Bug c/33564] A static inline function as a parameter of another static inline function is not inlined.
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-26 14:49 --- Fixed in 4.3.0. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |RESOLVED Keywords||missed-optimization Known to fail||4.2.2 Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33564
[Bug tree-optimization/33563] [4.3 Regression] DSE removes non-dead store
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-26 15:32 --- Subject: Bug 33563 Author: rguenth Date: Wed Sep 26 15:31:50 2007 New Revision: 128815 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128815 Log: 2007-09-26 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/33563 * tree-ssa-dse.c (get_use_of_stmt_lhs): Rename to ... (get_kill_of_stmt_lhs): ... this. Re-structure. Handle aggregate stores. (dse_optimize_stmt): Call get_kill_of_stmt_lhs instead of get_use_of_stmt_lhs. * gcc.dg/torture/pr33563.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr33563.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-dse.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33563
[Bug tree-optimization/33563] [4.3 Regression] DSE removes non-dead store
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-26 15:32 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33563
[Bug fortran/33544] Spurious warning in TRANSFER intrinsic in Sept 24 snapshot of gfortran
--- Comment #8 from michael dot a dot richmond at nasa dot gov 2007-09-26
15:36 ---
An analogous message appears when I compile the program listed below with the
flag "-fdefault-real-8":
qq.f90:3.15:
rft = TRANSFER('abcd', 0.0)
1
Warning: Intrinsic TRANSFER at (1) has partly undefined result: source size 4 <
result size 8
PROGRAM printd
REAL :: rft
rft = TRANSFER('abcd', 0.0)
END PROGRAM printd
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33544
[Bug c/16602] Spurious warnings about pointer to array -> const pointer to array conversion
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-09-26 16:40 --- Again this is invalid. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16602
[Bug tree-optimization/33565] New: [4.3 regression] spurious warning: assuming signed overflow does not occur when assuming that (X + c) >= X is always true
with -O2 -Wall:
void f (int m, int n)
{
int j;
for (j = m; j < m + 10 && j < n; j ++)
do_something (j);
}
t.c:2: warning: assuming signed overflow does not occur when assuming that (X +
c) >= X is always true
(also note useless line number)
--
Summary: [4.3 regression] spurious warning: assuming signed
overflow does not occur when assuming that (X + c) >= X
is always true
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: belyshev at depni dot sinp dot msu dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33565
[Bug target/33479] SyncTest Intermittent failing on MIPS
--- Comment #5 from daney at gcc dot gnu dot org 2007-09-26 16:45 --- Subject: Bug 33479 Author: daney Date: Wed Sep 26 16:45:39 2007 New Revision: 128821 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128821 Log: 2007-09-26 David Daney <[EMAIL PROTECTED]> PR target/33479 * config/mips/mips.md (sync_compare_and_swap, sync_old_add, sync_new_add, sync_old_, sync_new_, sync_old_nand, sync_new_nand, sync_lock_test_and_set): Fix '&' constraint modifiers. Update length attributes. (sync_add, sync_sub, sync_old_sub, sync_new_sub, sync_, sync_nand): Update length attributes. * config/mips/mips.h (MIPS_COMPARE_AND_SWAP, MIPS_SYNC_OP, MIPS_SYNC_OLD_OP, MIPS_SYNC_NEW_OP, MIPS_SYNC_NAND, MIPS_SYNC_OLD_NAND, MIPS_SYNC_NEW_NAND, MIPS_SYNC_EXCHANGE): Add post-loop sync. Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/mips.h trunk/gcc/config/mips/mips.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33479
[Bug fortran/33432] g77 extension: Support for the .XOR. operator
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-09-26 17:17 --- (In reply to comment #0) > The only problem is that this patch rejects (with -std=gnu/legacy) a > user-implemented .XOR., which is valid Fortran 90/95/2003. I suggest we make it conditional on a -fxor-operator, disabled by default (and maybe enabled with -std=legacy?). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33432
[Bug libstdc++/33489] parallel v3: sort assumes that the type of the objects to be sorted have a default constructor
--- Comment #3 from bkoz at gcc dot gnu dot org 2007-09-26 17:27 --- OK. Now there are tests for all of algorithms for defaultconstructable. As per 20.1, this is not required for template arguments unless the standard explicitly notes it. http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01921.html >From this, we can see that the following parallel algorithms have issues with this: merge nth_element partial_sort random_shuffle set_difference set_intersection set_symmetric_difference set_union sort stable_sort partial_sum -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33489
[Bug tree-optimization/33383] [4.3 Regression] Revision 128092 miscompiles 400.perlbench
--- Comment #8 from hjl at lucon dot org 2007-09-26 17:39 --- Revision 128810: http://gcc.gnu.org/ml/gcc-cvs/2007-09/msg00806.html doesn't fix 400.perlbench on Linux/x86-64. I am testing revision 128815: http://gcc.gnu.org/ml/gcc-cvs/2007-09/msg00812.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33383
[Bug tree-optimization/33565] [4.3 regression] spurious warning: assuming signed overflow does not occur when assuming that (X + c) >= X is always true
--- Comment #1 from ian at airs dot com 2007-09-26 17:54 --- Created an attachment (id=14253) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14253&action=view) Patch I'm testing this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33565
[Bug fortran/33566] New: fortran : wrong rank of derived type parameters array components
gfortran seems to miscalculate the rank when trying to get a component of an array member of a derived type parameter. I think that the following program explains better than my cryptic explanations : program test_vec implicit none integer :: i real:: x type vec3 real, dimension(3) :: coords end type vec3 type(vec3),parameter :: v1 = vec3((/ 1.0, 2.0, 3.0 /)) type(vec3) :: v2 v2 = vec3((/ 1.0, 2.0, 3.0 /)) x = v1%coords(1) ! works do i=1,3 x = v1%coords(i) ! fails x = v2%coords(i) ! works end do end program test_vec Here is the error returned ... $ gfortran -c test.f test.f:27.9: x = v1%coords(i) ! fails 1 Error: Incompatible ranks 0 and 1 in assignment at (1) ... and the version of gfortran used : $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-svn/gcc/configure --enable-languages=fortran : (reconfigured) ../gcc-svn/gcc/configure --enable-languages=fortran : (reconfigured) ../gcc-svn/gcc/configure --enable-languages=fortran Thread model: posix gcc version 4.3.0 20070926 (experimental) (GCC) -- Summary: fortran : wrong rank of derived type parameters array components Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mikael dot morin at tele2 dot fr GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33566
[Bug c++/31446] [4.2/4.3 regression] ICE with invalid template parameter
--- Comment #5 from pcarlini at suse dot de 2007-09-26 18:24 --- Seems due to a trivial thinko in the changes for 27668, 27962, etc.. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31446
[Bug c/33396] add --enable-intermodule
--- Comment #4 from aldot at gcc dot gnu dot org 2007-09-26 18:43 --- For the fortran frontend, It seems that i have this patch (must be relatively old; undetermined status, ATM). Index: gcc/fortran/Make-lang.in === --- gcc/fortran/Make-lang.in(revision 128688) +++ gcc/fortran/Make-lang.in(working copy) @@ -67,6 +67,8 @@ F95_OBJS = $(F95_PARSER_OBJS) \ fortran/trans-intrinsic.o fortran/trans-io.o fortran/trans-openmp.o \ fortran/trans-stmt.o fortran/trans-types.o +F95_OBJS-onestep = f951_frontend.o + #^L # Define the names for selecting gfortran in LANGUAGES. fortran: f951$(exeext) @@ -90,11 +92,15 @@ gfortran-cross$(exeext): gfortran$(exeex -rm -f gfortran-cross$(exeext) cp gfortran$(exeext) gfortran-cross$(exeext) +f951_frontend.o: $(F95_OBJS:.o=.c) +$(CC) $(ALL_CFLAGS) $(LDFLAGS) -c $(filter %.c,$^) -o $@ -combine + # The compiler itself is called f951. -f951$(exeext): $(F95_OBJS) \ +# Make-lang.in is not generated via configure, so we cannot use @onestep@ +f951$(exeext): $(F95_OBJS$(onestep)) \ $(BACKEND) $(LIBDEPS) attribs.o $(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ \ - $(F95_OBJS) $(BACKEND) $(LIBS) attribs.o + $(F95_OBJS$(onestep)) $(BACKEND) $(LIBS) attribs.o gt-fortran-trans.h: s-gtype; @true #^L -- aldot at gcc dot gnu dot org changed: What|Removed |Added Component|bootstrap |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33396
[Bug bootstrap/33396] add --enable-intermodule
--- Comment #5 from aldot at gcc dot gnu dot org 2007-09-26 18:53 --- (In reply to comment #4) > For the fortran frontend, It seems that i have this patch (must be relatively > old; undetermined status, ATM). Scratch that. Testing a working version that i will attach when it passes the check. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33396
[Bug tree-optimization/33562] [4.3 Regression] aggregate DSE disabled
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-26 19:04 --- * gcc.dg/tree-ssa/complex-4.c: XFAIL. is a regression then because the testcase was added back in 2006-02-18 (by me). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Summary|aggregate DSE disabled |[4.3 Regression] aggregate ||DSE disabled Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33562
[Bug tree-optimization/33565] [4.3 regression] spurious warning: assuming signed overflow does not occur when assuming that (X + c) >= X is always true
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-26 19:04 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-26 19:04:56 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33565
[Bug libstdc++/33485] parallel v3: do not use __builtin_alloca, use VLA
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-09-26 19:06 --- Hmm, __extension__ is lost with templates, see PR 21385. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||21385 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33485
[Bug middle-end/33500] [4.3 regression] ICE in copy_to_mode_reg with logical(kind=1) expression
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33500
[Bug c++/33501] [4.1/4.2/4.3 regression] Copy constructor assumed to exist for undefined class
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33501
[Bug c++/33506] [4.2/4.3 Regression] TYPE_RAISES_EXCEPTIONS dumped with attributes
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33506
[Bug target/33545] [4.3 regression] Bootstrap failure/broken exceptions on alpha/Tru64
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33545
[Bug c++/33516] [4.1/4.2/4.3 Regression] Rejects typedef qualified name-lookup
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2/4.3 Regression]|[4.1/4.2/4.3 Regression] |Rejects typedef qualified |Rejects typedef qualified |name-lookup |name-lookup Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33516
[Bug debug/33537] [4.1/4.2/4.3 regression] C++ arguments passed by invisible reference have wrong type
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2/4.3 regression]|[4.1/4.2/4.3 regression] C++ |C++ arguments passed by |arguments passed by |invisible reference have|invisible reference have |wrong type |wrong type Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33537
[Bug fortran/33554] [4.3 regression] Seg.fault: Default initialization of derived type uses uninitialized values
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33554
[Bug rtl-optimization/33410] [4.2/4.3 regression] ICE in iv_analyze_expr, at loop-iv.c:934
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33410
[Bug target/30919] [4.1 regression] unable to find a register to spill in class 'CREG'
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30919
[Bug bootstrap/25672] [4.1/4.2 regression] cross build's libgcc picks up CFLAGS
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25672
[Bug ada/31108] [4.2 regression] ACATS C35507M fails
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31108
[Bug ada/31108] [4.2 regression] ACATS C35507M fails
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.3 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31108
[Bug tree-optimization/31632] [4.1 regression] ICE in compare_values
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-09-26 19:11 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31632
[Bug target/30663] [4.1/4.2 regression] m68k-uclinux-20060615 compiler fault
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30663
[Bug tree-optimization/32139] [4.1 Regression] ICE in mark_operand_necessary
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32139
[Bug ada/32452] [4.2 Regression] Incorrect type debugging information for variables in other compilation units
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1 Regression]|[4.2 Regression] Incorrect |Incorrect type debugging|type debugging information |information for variables in|for variables in other |other compilation units |compilation units Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32452
[Bug fortran/33566] fortran : wrong rank of derived type parameters array components
-- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org OtherBugsDependingO||32834 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|i686-pc-linux-gnu | Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2007-09-26 19:12:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33566
[Bug tree-optimization/32891] [4.2 Regression] PRE goes crazy on YQPkgTechnicalDetailsView.cpp
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32891
[Bug ada/31174] [4.2 regression] ACATS C380004 fails
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31174
[Bug target/33008] [4.1/4.2 regression] code pessimization after -fforce-mem removal.
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33008
[Bug libgomp/33131] [4.2 regression] libgomp/env.c:60: warning: implicit declaration of function 'strncasecmp'
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33131
[Bug tree-optimization/32901] [4.1/4.2/4.3 regression] bitfield constants with multiple bitfields take up space in .data
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1 regression] bitfield |[4.1/4.2/4.3 regression] |constants with multiple |bitfield constants with |bitfields take up space in |multiple bitfields take up |.data |space in .data Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32901
[Bug target/33391] [4.3 regression] gfortran.dg/do_3.F90 fails at -O2
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33391
[Bug c++/32470] [4.2/4.3 regression] fvisibility=hidden without effect in some cases
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2 regression]|[4.2/4.3 regression] |fvisibility=hidden without |fvisibility=hidden without |effect in some cases|effect in some cases Target Milestone|--- |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32470
[Bug tree-optimization/33434] [4.3 Regression] -fipa-cp miscompilation
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33434
[Bug rtl-optimization/33410] [4.2/4.3 regression] ICE in iv_analyze_expr, at loop-iv.c:934
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.3.0 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33410
[Bug libfortran/33421] [4.3 Regression] Weird quotation of namelist output of character arrays
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33421
[Bug libstdc++/33489] parallel v3: sort assumes that the type of the objects to be sorted have a default constructor
--- Comment #4 from bangerth at dealii dot org 2007-09-26 19:41 --- (In reply to comment #3) > OK. Now there are tests for all of algorithms for defaultconstructable. As per > 20.1, this is not required for template arguments unless the standard > explicitly notes it. Yay, thanks for tackling this area! W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33489
[Bug tree-optimization/33383] [4.3 Regression] Revision 128092 miscompiles 400.perlbench
--- Comment #9 from hjl at lucon dot org 2007-09-26 19:57 --- (In reply to comment #8) > Revision 128810: > > http://gcc.gnu.org/ml/gcc-cvs/2007-09/msg00806.html > > doesn't fix 400.perlbench on Linux/x86-64. I am testing revision 128815: > > http://gcc.gnu.org/ml/gcc-cvs/2007-09/msg00812.html Revision 128815 doesn't fix the problem. perlbench executable still ran out of memory on Linux/x86-64 with -O2 -ffast-math. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33383
[Bug libstdc++/33485] parallel v3: do not use __builtin_alloca, use VLA
--- Comment #6 from bkoz at gcc dot gnu dot org 2007-09-26 20:43 --- the real question for me is why #pragma GCC system header doesn't work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33485
[Bug bootstrap/33511] make fails with no rule to make target 'all' in directory gcc
--- Comment #13 from gmills at library dot berkeley dot edu 2007-09-26 21:02 --- I just wanted to add that I finally got gcc to compile with c, c++, objc and objc++ front ends. The key apparently was to upgrade to the latest gnu tar. The previous version was 1.13 (as far as I can tell). Anyway, thank you for all the help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33511
[Bug bootstrap/25672] [4.1/4.2 regression] cross build's libgcc picks up CFLAGS
--- Comment #18 from rask at gcc dot gnu dot org 2007-09-26 21:06 --- I ran into this with 4.3 a few weeks ago. -- rask at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.1.2 4.2.0 |4.1.2 4.2.0 4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25672
[Bug rtl-optimization/33552] [4.3 Regression] wrong code for multiple output asm, wrong df?
--- Comment #14 from jakub at gcc dot gnu dot org 2007-09-26 21:19 ---
This isn't related to commutative constraints, can be reproduced with:
void
mul_basecase (unsigned long *wp, unsigned long *up, long un,
unsigned long *vp, long vn)
{
long j;
unsigned long prod_low, prod_high;
unsigned long cy_dig;
unsigned long v_limb;
v_limb = vp[0];
cy_dig = 0;
for (j = un; j > 0; j--)
{
unsigned long u_limb, w_limb;
u_limb = *up++;
__asm__ ("mulq %3"
: "=a" (prod_low), "=d" (prod_high)
: "0" (u_limb), "rm" (v_limb));
__asm__ ("addq %5,%q1\n\tadcq %3,%q0"
: "=r" (cy_dig), "=&r" (w_limb)
: "0" (prod_high), "rme" (0), "1" (prod_low), "rme" (cy_dig));
*wp++ = w_limb;
}
}
The problem is that match_asm_constraints_1 doesn't do any checking whether
the change it wants to do is actually valid.
Particularly it must and does not check whether the output (whose value it will
kill in the new insn prepended before the asm) isn't among inputs of the asm.
Also, I wonder whether it shouldn't limit any changes to REGs, ATM it will
happily copy around MEMs etc., which IMHO is highly undesirable.
When the output is present among inputs (except for the one with matching
constraint), we have either a choice to create a new pseudo or just don't do
anything.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33552
[Bug rtl-optimization/33552] [4.3 Regression] wrong code for multiple output asm, wrong df?
--- Comment #15 from jakub at gcc dot gnu dot org 2007-09-26 21:24 --- The restriction at least not to allow MEM_Ps was posted in: http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01329.html but never applied to the trunk. But I believe it should instead check just for REG_P, instead of !MEM_P. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33552
[Bug target/33532] bogus escape
--- Comment #8 from wilson at tuliptree dot org 2007-09-26 22:11 ---
Subject: Re: bogus escape
On Tue, 2007-09-25 at 17:36 +, kai-gcc-bugs at khms dot westfalen
dot de wrote:
> Furthermore, this is most definitely undocumented (and I'd guess
> unintentional)
> behaviour. The docs seem to be pretty clear: the contents of a brace block is
> a
> piece of C, period.
It is unintentional. The original syntax was friendly to lisp parsers,
and we had only quoted-strings in define_insns, as lisp parsers can't
parse C code. Later we added braced-strings in define_insns as a
simplification, which is no longer lisp friendly. When this was done,
there was no change to the handling of escapes. Internal to gcc, this
is still handled as if it is a string, it just doesn't start and end
with quote characters anymore.
The treatment of escapes is simple. \" always simplifies to ",
regardless of whether you are inside or outside a string. This is
because, originally, we were always inside a string here, and the
current code still behaves that way, even when using a braced-string.
> Really, I think calling this an enhancment request is wrong: it is plainly a
> bug. Not necessarily a severe bug, and one can certainly argue why it's there
> and what would be the correct solution, but I am firmly convinced that the
> status quo is NOT correct.
Except that the current behaviour causes no problems at any point in a
gcc build. You can only see a problem because you have an external
program looking at md files. This doesn't necessarily make it a gcc
bug. It could be fixed just as easily in your program by changing how
you handle quoted characters.
I can create an artifical example that shows a gcc bug though. If I add
this to the end of the ia64.md file:
(define_insn "artificial"
[(unspec [(const_int 0)] )]
""
{
return ".section .artificial,\"r\",@progbits";
}
[(set_attr "itanium_class" "ignore")
(set_attr "predicable" "no")])
and then try to build it, I get an error building insn-output.o
../../gcc/gcc/config/ia64/ia64.md:6430: error: expected â;â before ârâ
This is because gcc translated this line to
return ".section .artificial,"r",@progbits";
which is not valid C. I can make this work by doubling the \
characters, but that is awkward. We could declare this to be a real gcc
bug, file a PR for it, and then make this one depend on the new bug.
When this new bug gets fixed, this current bug will be exposed as a gcc
build failure, and will have to be fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33532
[Bug libfortran/30780] FPE in CPU_TIME (and possibly others) with -ffpe-trap=underflow
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-09-26 22:27 --- Subject: Bug 30780 Author: fxcoudert Date: Wed Sep 26 22:27:16 2007 New Revision: 128825 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128825 Log: PR fortran/30780 * invoke.texi: Add note to -ffpe-trap option. Fix typos. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/invoke.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30780
[Bug libfortran/30780] FPE in CPU_TIME (and possibly others) with -ffpe-trap=underflow
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-09-26 22:28 --- Documentation added. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30780
[Bug bootstrap/33567] New: Bootstrapping not working in b128824
Reason: prev-gcc/xgcc not able to build executables.
configure: ./gcc-mainline-dp/configure --enable-libssp
--prefix=/opt/gcc-mainline-dp --enable-docdir --enable-htmldir
--enable-languages="c"
After stage1, i tried compiling xgcc and a C file I wrote:
#include
int main(){
;
return 0;
}
and the error popped up in ld unable to recognize paranthesis:
[EMAIL PROTECTED]:~/WS/act/gcc-build/intl$ ../prev-gcc/xgcc -B ../prev-gcc/ -g
-fomit-frame-pointer a.c -v 2>&1 | tee a.txt
Reading specs from ../prev-gcc/specs
Target: i686-pc-linux-gnu
Configured with: ../gcc-mainline-dp/configure --enable-libdetect
--enable-libssp --prefix=/opt/gcc-mainline-dp --enable-docdir --enable-htmldir
--enable-languages=c
Thread model: posix
gcc version 4.3.0 20070926 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-B' '../prev-gcc/' '-g' '-fomit-frame-pointer' '-v'
'-mtune=generic'
../prev-gcc/cc1 -quiet -v -iprefix
/home/karthik/WS/act/gcc-build/prev-gcc/../lib/gcc/i686-pc-linux-gnu/4.3.0/
-isystem ../prev-gcc/include -isystem ../prev-gcc/include-fixed a.c -quiet
-dumpbase a.c -mtune=generic -auxbase a -g -version -fomit-frame-pointer -o
/tmp/ccTprhqx.s
ignoring nonexistent directory
"/home/karthik/WS/act/gcc-build/prev-gcc/../lib/gcc/i686-pc-linux-gnu/4.3.0/include"
ignoring nonexistent directory
"/home/karthik/WS/act/gcc-build/prev-gcc/../lib/gcc/i686-pc-linux-gnu/4.3.0/include-fixed"
ignoring nonexistent directory
"/home/karthik/WS/act/gcc-build/prev-gcc/../lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../i686-pc-linux-gnu/include"
ignoring nonexistent directory
"/home/karthik/WS/act/gcc-build/prev-gcc/../lib/gcc/../../include"
ignoring nonexistent directory
"/home/karthik/WS/act/gcc-build/prev-gcc/../lib/gcc/../../lib/gcc/i686-pc-linux-gnu/4.3.0/include"
ignoring nonexistent directory
"/home/karthik/WS/act/gcc-build/prev-gcc/../lib/gcc/../../lib/gcc/i686-pc-linux-gnu/4.3.0/include-fixed"
ignoring nonexistent directory
"/home/karthik/WS/act/gcc-build/prev-gcc/../lib/gcc/../../lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
../prev-gcc/include
../prev-gcc/include-fixed
/usr/local/include
/usr/include
End of search list.
GNU C (GCC) version 4.3.0 20070926 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.1.2, GMP version 4.2.1, MPFR version
2.2.1-p1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 09807fb8f916e5613f7e842be08c469b
COLLECT_GCC_OPTIONS='-B' '../prev-gcc/' '-g' '-fomit-frame-pointer' '-v'
'-mtune=generic'
../prev-gcc/as -V -Qy -o /tmp/ccOX8s9Y.o /tmp/ccTprhqx.s
GNU assembler version 2.17.50.0.17 (i486-slackware-linux) using BFD version
(Linux/GNU Binutils) 2.17.50.0.17.20070615
COMPILER_PATH=../prev-gcc/
LIBRARY_PATH=../prev-gcc/:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-B' '../prev-gcc/' '-g' '-fomit-frame-pointer' '-v'
'-mtune=generic'
../prev-gcc/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker
/lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o ../prev-gcc/crtbegin.o
-L../prev-gcc /tmp/ccOX8s9Y.o (--eh-frame-hdr -m elf_i386 -dynamic-linker
/lib/ld-linux.so.2 ink_detect) -lgcc --as-needed -lgcc_s --no-as-needed -lc
-lgcc --as-needed -lgcc_s --no-as-needed ../prev-gcc/crtend.o /usr/lib/crtn.o
/usr/lib/gcc/i486-slackware-linux/4.1.2/../../../../i486-slackware-linux/bin/ld:
(--eh-frame-hdr: No such file: No such file or directory
collect2: ld returned 1 exit status
P.S.: I asked the guys in #slackware regarding the binutils and they told me it
wasn't wonky. I'm not sure if the paranthesising is specific to binutils-2.18.
--
Summary: Bootstrapping not working in b128824
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: karthikkumar at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33567
[Bug fortran/31154] IMPORT fails for " FUNCTION (...)" kind of procedures
--- Comment #6 from patchapp at dberlin dot org 2007-09-27 00:11 --- Subject: Bug number PR31154 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01901.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31154
[Bug fortran/33400] Formatted read fails if line ends without line break
--- Comment #3 from patchapp at dberlin dot org 2007-09-27 00:11 --- Subject: Bug number PR33400 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01925.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33400
[Bug middle-end/32395] false positive warning about use of uninitialized variable.
--- Comment #11 from manu at gcc dot gnu dot org 2007-09-27 00:58 --- (In reply to comment #10) > Manuel, ping, do you working on it? > i've posted preprocessed 32-bit testaces for you over month ago ;) > btw. PR32368 exposes this bug. > Sorry, I am probably doing something wrong but I cannot get it to compile. Weird. [EMAIL PROTECTED]:~$ 128590/build/gcc/cc1plus src/multi_index_test.ii -O1 -Wall -Wfatal-errors In file included from /usr/include/c++/4.2.1/bits/stl_algobase.h:73, from /usr/include/c++/4.2.1/algorithm:66, from /usr/include/boost/multi_index_container.hpp:20, from multi_index_test.cpp:2: /usr/include/c++/4.2.1/bits/cpp_type_traits.h: At global scope: /usr/include/c++/4.2.1/bits/cpp_type_traits.h:346: error: expected identifier before â__is_podâ and [EMAIL PROTECTED]:~/$ g++ -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4) [EMAIL PROTECTED]:~/$ g++ -Wall -O1 -c multi_index_test.ii -Wfatal-errors /usr/include/c++/4.2.1/x86_64-pld-linux/32/bits/c++config.h:149: error: expected `=' before â__attribute__â compilation terminated due to -Wfatal-errors. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32395
[Bug middle-end/32395] false positive warning about use of uninitialized variable.
--- Comment #12 from bangerth at dealii dot org 2007-09-27 04:06 --- (In reply to comment #11) > /usr/include/c++/4.2.1/bits/cpp_type_traits.h:346: error: expected identifier > before ‘__is_pod’ __is_pod is only implemented on mainline, not 4.2.1. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32395
[Bug rtl-optimization/33552] [4.3 Regression] wrong code for multiple output asm, wrong df?
--- Comment #16 from bonzini at gnu dot org 2007-09-27 06:28 --- I will implement something along the lines that Jakub discussed. In the meanwhile, could anybody figure a self-contained execution testcase based on comment #14? Thanks! -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-09-25 18:57:01 |2007-09-27 06:28:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33552
