[Bug target/24610] The comment start symbol of arm target
--- Comment #1 from rearnsha at gcc dot gnu dot org 2005-11-01 09:37 --- Subject: Re: New: The comment start symbol of arm target On Tue, 2005-11-01 at 07:31, hanzac at gmail dot com wrote: > It's true that the arm comment start symbol is '@', but GCC will generate some > assembler code end with a '@' and a comment without a separator so it can't be > parsed by gas. No, it shouldn't. '@' is the comment symbol in GAS for ARM. Any other use of '@' by gcc in ARM code is a bug. So the question is where is this coming from. I don't have a wince build, so can you post an assembly code fragment that demonstrates this problem? > @@ -294,7 +294,7 @@ > #endif > > #ifndef ASM_COMMENT_START > -#define ASM_COMMENT_START "@" > +#define ASM_COMMENT_START ";@" > #endif This is incorrect. ';' is a statement separator, not a comment separator. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24610
[Bug middle-end/24514] ICE on bootstrap
--- Comment #3 from r dot emrich at de dot tecosim dot com 2005-11-01 09:46 --- Created an attachment (id=10097) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10097&action=view) assembler output I compiled c-parser.c with the exact same commandline as in the bootstrap, except the added -S -dap switch. Output as attachment. Additionally I tried to change the -O2 switch to -O1, wich failed too. Compilation without optimization switch succeeds. If helpfull in any way, I may provide the output of these compilations too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
[Bug target/23378] [4.1 Regression] code quality regression for complicated loop
--- Comment #7 from martin at mpa-garching dot mpg dot de 2005-11-01 10:22 --- The regression is unfortunately still there :( Reducing the testcase is really hard, and I have some indications that the problem vanishes if there is less work to do in the critical loop. If you have any suggestion how to proceed, they would be greatly appreciated ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23378
[Bug tree-optimization/21513] [4.0/4.1 Regression] __builtin_expect getting in the way of uninitialized warnings
--- Comment #4 from alexander_herrmann at yahoo dot com dot au 2005-11-01
10:46 ---
Subject: Re: [4.0/4.1 Regression] __builtin_expect getting in the way of
uninitialized warnings
Never is a long time. It may become release relevant
as soon as somebody extends the
-Wunused-value the way other today compiler handle it
like warning me about a value wich is assigned to a
local variable without beeing used.
Sp please consider the workaround code fragment:
int problem_funktion(int a)
{
int b = 0; // WORKAROUND
if (__builtin_expect(((a > 0) && ((b = 5) != 0)),
1))
{
return(a*b);
}
return(a);
}
Compiled with gcc -Wall -O it produces the no wrong
Warning. As a Value is assigned to b.
I did this quite often as a workaround
http://www.aiengine.org/doc/index.html . But if
somebody whithin the time of never does spend the time
to extend the -Wunused-value the way it works in other
up2date compilers gcc will complain based on the
data-flow analyses that b is assigned the value of 0
which is never used. Imo this can become reality
before never comes which would prevent these code in
any case to be compiled. Doesn't have to P2 but
something higher than P5 would be appriciated so that
somebody may take the time to look into it bevor never
is here.
Send instant messages to your online friends http://uk.messenger.yahoo.com
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21513
[Bug c/24611] New: -Wunused-value Extension
As a enhancement to the -Wunused-value which may allready detected by the
data-flow analysis.
int problem_funktion(int a)
{
int b = 0; // This should cause a warning as the value 0 is never used
if (__builtin_expect(((a > 0) && ((b = 5) != 0)), 1))
{
return(a*b);
}
return(a);
}
Compiling with -Wunused-value imo it should give me a warning about assigning a
unused value to b.
--
Summary: -Wunused-value Extension
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexander_herrmann at yahoo dot com dot au
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24611
[Bug middle-end/24514] ICE on bootstrap
--- Comment #4 from r dot emrich at de dot tecosim dot com 2005-11-01 11:02 --- Also fails on at least tree-data-ref.c and tree-cfg.c with xgcc: Internal error: Trace/BPT/RangeErr/DivZero/Ovflow trap (program cc1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
[Bug middle-end/24612] New: [gomp] Bogus "is used uninitialized" warning
Compiling the following code with "-fopenmp -O -Wall" yields a bogus warning
(happens with C and C++):
==
void foo()
{
int i;
#pragma omp threadprivate(i)
#pragma omp parallel sections
{
#pragma omp section
{
i = 0;
++i;
}
}
}
==
bug.c: In function 'foo':
bug.c:11: warning: 'i' is used uninitialized in this function
--
Summary: [gomp] Bogus "is used uninitialized" warning
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic, openmp
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24612
[Bug libstdc++/24595] std::tr1::get_deleter not declared
--- Comment #2 from pcarlini at suse dot de 2005-11-01 11:14 --- Fixed for 4.0.3. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24595
[Bug fortran/21565] namelist in block data is illegal
--- Comment #3 from pault at gcc dot gnu dot org 2005-11-01 12:15 --- Subject: Bug 21565 Author: pault Date: Tue Nov 1 12:15:07 2005 New Revision: 106326 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106326 Log: 2005-11-01 Paul Thomas <[EMAIL PROTECTED]> PR fortran/21565 * symbol.c (check_conflict): An object cannot be in a namelist and in block data. PR fortran/18737 * resolve.c (resolve_symbol): Set the error flag to gfc_set_default_type, in the case of an external symbol, so that an error message is emitted if IMPLICIT NONE is set. PR fortran/14994 * gfortran.h (gfc_generic_isym_id): Add GFC_ISYM_SECNDS to enum. * check.c (gfc_check_secnds): New function. * intrinsic.c (add_functions): Add call to secnds. * iresolve.c (gfc_resolve_secnds): New function. * trans-intrinsic (gfc_conv_intrinsic_function): Add call to secnds via case GFC_ISYM_SECNDS. * intrinsic.texi: Add documentation for secnds. 2005-11-01 Paul Thomas <[EMAIL PROTECTED]> PR fortran/14994 * libgfortran/intrinsics/date_and_time.c: Add interface to the functions date_and_time for the intrinsic function secnds. 2005-11-01 Paul Thomas <[EMAIL PROTECTED]> PR fortran/21565 gfortran.dg/namelist_blockdata.f90: New test. PR fortran/18737 gfortran.dg/external_implicit_none.f90: New test. PR fortran/14994 * gfortran.dg/secnds.f: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/external_implicit_none.f90 branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/namelist_blockdata.f branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/secnds.f Modified: branches/gcc-4_0-branch/gcc/fortran/ChangeLog branches/gcc-4_0-branch/gcc/fortran/check.c branches/gcc-4_0-branch/gcc/fortran/gfortran.h branches/gcc-4_0-branch/gcc/fortran/intrinsic.c branches/gcc-4_0-branch/gcc/fortran/intrinsic.h branches/gcc-4_0-branch/gcc/fortran/intrinsic.texi branches/gcc-4_0-branch/gcc/fortran/iresolve.c branches/gcc-4_0-branch/gcc/fortran/resolve.c branches/gcc-4_0-branch/gcc/fortran/symbol.c branches/gcc-4_0-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/libgfortran/ChangeLog branches/gcc-4_0-branch/libgfortran/intrinsics/date_and_time.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21565
[Bug fortran/14994] Secnds Intrinsic not support (or any VMS intrinsics)
--- Comment #6 from pault at gcc dot gnu dot org 2005-11-01 12:15 --- Subject: Bug 14994 Author: pault Date: Tue Nov 1 12:15:07 2005 New Revision: 106326 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106326 Log: 2005-11-01 Paul Thomas <[EMAIL PROTECTED]> PR fortran/21565 * symbol.c (check_conflict): An object cannot be in a namelist and in block data. PR fortran/18737 * resolve.c (resolve_symbol): Set the error flag to gfc_set_default_type, in the case of an external symbol, so that an error message is emitted if IMPLICIT NONE is set. PR fortran/14994 * gfortran.h (gfc_generic_isym_id): Add GFC_ISYM_SECNDS to enum. * check.c (gfc_check_secnds): New function. * intrinsic.c (add_functions): Add call to secnds. * iresolve.c (gfc_resolve_secnds): New function. * trans-intrinsic (gfc_conv_intrinsic_function): Add call to secnds via case GFC_ISYM_SECNDS. * intrinsic.texi: Add documentation for secnds. 2005-11-01 Paul Thomas <[EMAIL PROTECTED]> PR fortran/14994 * libgfortran/intrinsics/date_and_time.c: Add interface to the functions date_and_time for the intrinsic function secnds. 2005-11-01 Paul Thomas <[EMAIL PROTECTED]> PR fortran/21565 gfortran.dg/namelist_blockdata.f90: New test. PR fortran/18737 gfortran.dg/external_implicit_none.f90: New test. PR fortran/14994 * gfortran.dg/secnds.f: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/external_implicit_none.f90 branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/namelist_blockdata.f branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/secnds.f Modified: branches/gcc-4_0-branch/gcc/fortran/ChangeLog branches/gcc-4_0-branch/gcc/fortran/check.c branches/gcc-4_0-branch/gcc/fortran/gfortran.h branches/gcc-4_0-branch/gcc/fortran/intrinsic.c branches/gcc-4_0-branch/gcc/fortran/intrinsic.h branches/gcc-4_0-branch/gcc/fortran/intrinsic.texi branches/gcc-4_0-branch/gcc/fortran/iresolve.c branches/gcc-4_0-branch/gcc/fortran/resolve.c branches/gcc-4_0-branch/gcc/fortran/symbol.c branches/gcc-4_0-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/libgfortran/ChangeLog branches/gcc-4_0-branch/libgfortran/intrinsics/date_and_time.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14994
[Bug fortran/18737] ICE on invalid use of external keyword
--- Comment #7 from pault at gcc dot gnu dot org 2005-11-01 12:15 --- Subject: Bug 18737 Author: pault Date: Tue Nov 1 12:15:07 2005 New Revision: 106326 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106326 Log: 2005-11-01 Paul Thomas <[EMAIL PROTECTED]> PR fortran/21565 * symbol.c (check_conflict): An object cannot be in a namelist and in block data. PR fortran/18737 * resolve.c (resolve_symbol): Set the error flag to gfc_set_default_type, in the case of an external symbol, so that an error message is emitted if IMPLICIT NONE is set. PR fortran/14994 * gfortran.h (gfc_generic_isym_id): Add GFC_ISYM_SECNDS to enum. * check.c (gfc_check_secnds): New function. * intrinsic.c (add_functions): Add call to secnds. * iresolve.c (gfc_resolve_secnds): New function. * trans-intrinsic (gfc_conv_intrinsic_function): Add call to secnds via case GFC_ISYM_SECNDS. * intrinsic.texi: Add documentation for secnds. 2005-11-01 Paul Thomas <[EMAIL PROTECTED]> PR fortran/14994 * libgfortran/intrinsics/date_and_time.c: Add interface to the functions date_and_time for the intrinsic function secnds. 2005-11-01 Paul Thomas <[EMAIL PROTECTED]> PR fortran/21565 gfortran.dg/namelist_blockdata.f90: New test. PR fortran/18737 gfortran.dg/external_implicit_none.f90: New test. PR fortran/14994 * gfortran.dg/secnds.f: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/external_implicit_none.f90 branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/namelist_blockdata.f branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/secnds.f Modified: branches/gcc-4_0-branch/gcc/fortran/ChangeLog branches/gcc-4_0-branch/gcc/fortran/check.c branches/gcc-4_0-branch/gcc/fortran/gfortran.h branches/gcc-4_0-branch/gcc/fortran/intrinsic.c branches/gcc-4_0-branch/gcc/fortran/intrinsic.h branches/gcc-4_0-branch/gcc/fortran/intrinsic.texi branches/gcc-4_0-branch/gcc/fortran/iresolve.c branches/gcc-4_0-branch/gcc/fortran/resolve.c branches/gcc-4_0-branch/gcc/fortran/symbol.c branches/gcc-4_0-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/libgfortran/ChangeLog branches/gcc-4_0-branch/libgfortran/intrinsics/date_and_time.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18737
[Bug fortran/18737] ICE on invalid use of external keyword
--- Comment #8 from tobi at gcc dot gnu dot org 2005-11-01 12:58 --- Fixed by Paul's patch. -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org, ||pault at gcc dot gnu dot org Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18737
[Bug target/24600] [4.1 Regression] unrecognizable instruction
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-11-01 13:01 --- Created an attachment (id=10098) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10098&action=view) reduced testcase testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24600
[Bug target/24600] [4.1 Regression] unrecognizable instruction
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-11-01 13:01 --- Critical, as this happens in a lot of packages. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24600
[Bug fortran/14994] Secnds Intrinsic not support (or any VMS intrinsics)
--- Comment #7 from pault at gcc dot gnu dot org 2005-11-01 13:03 --- Fixed on mainline and 4.0 -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14994
[Bug fortran/21565] namelist in block data is illegal
--- Comment #4 from pault at gcc dot gnu dot org 2005-11-01 13:04 --- Fixed on mainline and 4.0 -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21565
[Bug rtl-optimization/22509] [4.1 regression] elemental.f90 testsuite failure (-fweb)
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22509
[Bug rtl-optimization/22509] [4.1 regression] elemental.f90 testsuite failure (-fweb)
--- Comment #15 from rakdver at gcc dot gnu dot org 2005-11-01 14:08
---
C testcase (needs to be compiled with -O1 -funroll-loops and complete unrolling
on trees must be disabled)
int e_fn (int *p, int *q)
{
return *p - *q;
}
int main (void)
{
int a[8];
int b[8];
int A[8];
unsigned i, j;
int C = 1, tmp;
int *p;
for (i = 2; i < 6; i++)
{
a[2 * i - 4] = 2;
a[2 * i - 3] = 2;
}
for (i = 2; i < 6; i++)
{
b[2 * i - 4] = 0;
b[2 * i - 3] = 0;
}
b[1] = e_fn (&a[0], &C);
b[3] = e_fn (&a[2], &C);
b[5] = e_fn (&a[4], &C);
b[7] = e_fn (&a[6], &C);
for (i = 1, j = 6; i < 5; i++, j -= 2)
{
p = A;
tmp = b[2*i-2] + 1;
A[2*i - 2] = e_fn(&a[j], &tmp);
tmp = b[2*i-1] + 1;
A[2*i - 1] = e_fn(&a[j+1], &tmp);
}
for (i = 1; i < 5; i++)
{
a[2*i-2] = p[2*i -2];
a[2*i-1] = p[2*i -1]; for (i = 0; i < 8; i++)
}
printf (" %d",a[i]);
printf ("\n");
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22509
[Bug rtl-optimization/22509] [4.1 regression] elemental.f90 testsuite failure (-fweb)
--- Comment #16 from rakdver at gcc dot gnu dot org 2005-11-01 14:15
---
Smaller testcase:
int e_fn (int *p, int *q)
{
return *p - *q;
}
int main (void)
{
int a[8] = {2,2,2,2,2,2,2,2};
int b[8] = {0,1,0,1,0,1,0,1};
int A[8];
unsigned i, j;
int tmp;
int *p = A;
for (i = 1, j = 6; i < 5; i++, j -= 2)
{
tmp = b[2*i-2] + 1;
A[2*i - 2] = e_fn(&a[j], &tmp);
tmp = b[2*i-1] + 1;
A[2*i - 1] = e_fn(&a[j+1], &tmp);
}
for (i = 1; i < 4; i++)
a[2*i-1] = p[2*i -1];
printf ("%d\n",p[7]);
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22509
[Bug c/24611] -Wunused-value Extension
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-01 14:22 --- *** This bug has been marked as a duplicate of 18624 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24611
[Bug c/18624] GCC does not detect local variable set but never used
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-01 14:22 --- *** Bug 24611 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||alexander_herrmann at yahoo ||dot com dot au http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18624
[Bug target/24600] [4.1 Regression] unrecognizable instruction
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24600
[Bug rtl-optimization/22509] [4.1 regression] elemental.f90 testsuite failure (-fweb)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P5 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22509
[Bug c++/24613] New: [gomp] ICE on unexpected #pragma omp section
When the C++ parser encounters a "#pragma omp section" without enclosing "#pragma omp sections" it crashes, like on the following one-liner: == #pragma omp section == bug1.cc:1: internal compiler error: in cp_parser_pragma, at cp/parser.c:18791 Please submit a full bug report, [etc.] The same happens inside functions. The C frontend is ot affected. -- Summary: [gomp] ICE on unexpected #pragma omp section Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ice-on-invalid-code, openmp Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24613
[Bug tree-optimization/24609] Same value duplicated in two different registers
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-01 14:54 ---
Actually it is "int*" and "int" and that mainly comes down to how we repesent
(int*)[d];
If we change the code (we should be able to do this in the IR also, Daniel
Berlin had a patch which did it):
extern int abs (int __x);
extern int bar (short*, short, int);
struct s
{
short int* top;
short int* left;
short int* diag;
};
typedef int aar[];
typedef aar *aptr;
typedef char par[];
typedef par *pptr;
int
foo (int *a, struct s* p, short int pv[6][16])
{
int s = 0;
int b;
aptr a1;
a1 = (aptr)(a);
pptr p1= (pptr)(p);
for (b = 0; b < 6; ++b)
{
int d;
short int ps;
if (abs (p->left[0] - p->diag[0])
< abs (p->diag[0] - p->top[0]))
d = 1;
else
d = 2;
(*a1)[b] = d;
ps = (*p1)[d - 1];
s += bar (pv[b], ps, a[b]);
}
return s;
}
--
We get:
.L12:
movl$1, %eax
xorl%edx, %edx
.
jl .L12
movl$2, %eax
movl$1, %edx
jmp .L5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24609
[Bug middle-end/24585] [3.4/4.0/4.1 Regression] spurious section conflict error while building linux kernel
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-01 14:55 --- So this is invalid after all. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24585
[Bug target/23303] [4.1 Regression] 4.1 generates sall + addl instead of leal
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-01 14:57 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00011.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||11/msg00011.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23303
[Bug rtl-optimization/24034] [4.1 regression] Regrename: Inconsistency Failure
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||10/msg00803.html Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2005-11-01 15:12:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24034
[Bug target/23303] [4.1 Regression] 4.1 generates sall + addl instead of leal
--- Comment #7 from dann at godzilla dot ics dot uci dot edu 2005-11-01 15:15 --- (In reply to comment #5) > Hmm, > I am still not sure if it matters too much, but since there are actually > dupes of this problem, I think we can simply add peep2 fixing this > particular common case. > > I am testing attached patch. Could you please try to measure the code size impact of this patch? (like the examples in PR23153: xterm, PR8361 or kernel) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23303
[Bug libgcj/21326] seg fault in _Jv_Linker
--- Comment #6 from tromey at gcc dot gnu dot org 2005-11-01 15:17 --- Fixed. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21326
[Bug testsuite/24614] New: gcc.dg/nested-func-4.c (test for excess errors) fails
FAIL: gcc.dg/nested-func-4.c (test for excess errors) (a new test) appeared on mainline on hppa2.0w-hp-hpux11.11 between 20051026 and 20051027. Excess errors: Warning: consider linking with `-static' as system libraries with profiling support are only provided in archive format Some other profiling tests link with -static on hppa*-*-hpux*, probably this one should as well. -- Summary: gcc.dg/nested-func-4.c (test for excess errors) fails Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org GCC target triplet: hppa*-*-hpux* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24614
[Bug c++/24605] [4.0/4.1 Regression] internal compiler error: Segmentation fault while compiling c++ file
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.1.0 |4.1.0 4.0.3 Summary|[4.1 Regression] internal |[4.0/4.1 Regression] |compiler error: Segmentation|internal compiler error: |fault while compiling c++ |Segmentation fault while |file|compiling c++ file Target Milestone|4.1.0 |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24605
[Bug target/24615] New: internal compiler error: in print_shift_count_operand, at config/s390/s390.c:4025
We ICE during building nss of the mozilla suite. -- Summary: internal compiler error: in print_shift_count_operand, at config/s390/s390.c:4025 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: critical Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org GCC target triplet: s390-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24615
[Bug target/24615] internal compiler error: in print_shift_count_operand, at config/s390/s390.c:4025
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-01 15:47 --- Created an attachment (id=10099) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10099&action=view) reduced testcase testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24615
[Bug target/24615] [4.1 Regression] internal compiler error: in print_shift_count_operand, at config/s390/s390.c:4025
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-11-01 15:56 --- Regression from 4.0, btw. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|internal compiler error: in |[4.1 Regression] internal |print_shift_count_operand, |compiler error: in |at config/s390/s390.c:4025 |print_shift_count_operand, ||at config/s390/s390.c:4025 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24615
[Bug tree-optimization/24609] Same value duplicated in two different registers
--- Comment #3 from ian at airs dot com 2005-11-01 16:09 --- You've managed to change the code so that we still have two registers, but now they have different values. I agree that there are probably going to be times when it is good to have two different registers. But when they always have the same value, as they do in my original test case, shouldn't something clean that up? If so, what? And do you still get two registers in your test case if you change (*p1)[d - 1] to (*p1)[d]? And if you do get two registers, do they have the same value or not? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24609
[Bug tree-optimization/24609] Same value duplicated in two different registers
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-01 16:17 --- If we change (*p1)[d-1] to (*p1)[d], we get: .L2: movl 8(%edi), %eax movswl (%eax),%edx movl 4(%edi), %eax movswl (%eax),%eax subl %edx, %eax movl %eax, %ecx sarl $31, %ecx xorl %ecx, %eax subl %ecx, %eax movl (%edi), %ecx movswl (%ecx),%ecx subl %ecx, %edx movl %edx, %ecx sarl $31, %ecx xorl %ecx, %edx subl %ecx, %edx cmpl %edx, %eax movl 8(%ebp), %edx setge %al movzbl %al, %eax incl %eax movl %eax, -4(%edx,%esi,4) incl %esi movl %eax, 8(%esp) movsbl (%edi,%eax),%eax movl %ebx, (%esp) addl $32, %ebx movl %eax, 4(%esp) call bar addl %eax, -16(%ebp) cmpl $7, %esi jne .L2 For the loop, which seems like very good as there are no branches, only setge %al movzbl %al, %eax incl %eax -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24609
[Bug libgcj/24616] New: linking BC-compiled classes: NoClassDefFoundErrors should be deferred
In various situations where the BC-compiled classes are linked and a NoClassDefFoundError is thrown, this error condition should be deferred to the time when the actual erroneous code location is executed. The situation always involves that a class cannot be resolved (because the bytecode is not available). That means: - invoking a static method of a missing class - accessing a static member of a missing class - creating an array from a missing class - creating a multi array from a missing class - accessing a valid static member whose type is missing - accessing a valid non-static field whose type is missing - invoking a non-static method of a missing class (true?) There may be more cases. I have to investigate that. -- Summary: linking BC-compiled classes: NoClassDefFoundErrors should be deferred Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: thebohemian at gmx dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616
[Bug libgcj/24616] linking BC-compiled classes: NoClassDefFoundErrors should be deferred
-- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-01 16:22:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616
[Bug libstdc++/24617] New: vector vs __erase_at_end
This is to track this nice suggestion from Howard: http://gcc.gnu.org/ml/libstdc++/2005-11/msg1.html -- Summary: vector vs __erase_at_end Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24617
[Bug middle-end/22275] [3.4/4.0/4.1 Regression] bitfield layout change (regression?)
--- Comment #11 from janis at gcc dot gnu dot org 2005-11-01 16:42 --- A regression hunt identified the following patch: r65207 | jason | 2003-04-03 18:23:04 + (Thu, 03 Apr 2003) | 17 lines * stor-layout.c (do_type_align): New fn, split out from... (layout_decl): ...here. Do all alignment calculations for FIELD_DECLs here. (update_alignment_for_field): Not here. (start_record_layout, debug_rli): Remove unpadded_align. * tree.h (struct record_layout_info_s): Remove unpadded_align. * c-decl.c (finish_enum): Don't set DECL_SIZE, DECL_ALIGN or DECL_MODE on the CONST_DECLs. (finish_struct): Don't mess with DECL_ALIGN. * cp/class.c (build_vtable): Set DECL_ALIGN here. (get_vtable_decl): Not here. (layout_vtable_decl): Or here. (create_vtable_ptr): Or here. (layout_class_type): Or here. (check_bitfield_decl): Don't mess with field alignment. * ada/misc.c (gnat_adjust_rli): #if 0. -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug middle-end/22275] [3.4/4.0/4.1 Regression] bitfield layout change (regression?)
--- Comment #12 from steven at gcc dot gnu dot org 2005-11-01 16:44 --- The mail to gcc-patches for the patch identified in comment #11 is http://gcc.gnu.org/ml/gcc-patches/2003-04/msg00209.html. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||steven at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug middle-end/22275] [3.4/4.0/4.1 Regression] bitfield layout change (regression?)
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-11-01 16:57 --- Related to PR 10145 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug middle-end/24514] ICE on bootstrap
--- Comment #5 from echristo at apple dot com 2005-11-01 17:27 --- The patch to 23585 is likely the cause. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
[Bug middle-end/24514] ICE on bootstrap
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-01 17:33 --- Maybe a testcase in: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00028.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
[Bug middle-end/24514] [4.0/4.1 Regression] ICE on bootstrap
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build, ice-on-valid-code Priority|P2 |P3 Summary|ICE on bootstrap|[4.0/4.1 Regression] ICE on ||bootstrap Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
[Bug middle-end/24514] [4.0/4.1 Regression] ICE on bootstrap
--- Comment #7 from echristo at apple dot com 2005-11-01 17:43 --- Changing to P1 since it's a regression that likely affects all mips (including primary platform mips-elf). -- echristo at apple dot com changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
[Bug middle-end/24514] [4.0/4.1 Regression] ICE on bootstrap
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-01 17:44 --- (In reply to comment #7) > Changing to P1 since it's a regression that likely affects all mips (including > primary platform mips-elf). I don't know if it is allowed for someone to change the priority (except to P3 so that Mark can relook at the bug). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
[Bug libmudflap/24619] New: mudflap instrumentation of dlopen is incorrect
[forwarded from http://bugs.debian.org/336511]
bug submitter writes:
If mudflap is used to instrument a program using dlopen, and the program
(assuming it is compiled with -rdynamic) loads itself by passing NULL for the
path to dlopen, the program will crash unconditionally; that is, regardless of
the options passed to mudflap, so long as instrumentation is enabled.
This is because (at least with GNU/Linux) it is valid to pass a NULL pointer as
the path argument to dlopen, and the instrumentation code unconditionally uses
strlen on that pointer, without checking first if it is NULL.
I have included the following patch, which may help fix the problem. I have
not
tested it, but it should work. As always, it is "as is", with no warranty of
any kind. The patch is against svn HEAD (r104588).
- --- mf-hooks2.c.orig 2005-10-30 20:35:44.0 +
+++ mf-hooks2.c 2005-10-30 20:37:38.0 +
@@ -1679,8 +1679,10 @@ WRAPPER2(void *, dlopen, const char *pat
void *p;
size_t n;
TRACE ("%s\n", __PRETTY_FUNCTION__);
- - n = strlen (path);
- - MF_VALIDATE_EXTENT (path, CLAMPADD(n, 1), __MF_CHECK_READ, "dlopen path");
+ if (NULL != path) {
+n = strlen (path);
+MF_VALIDATE_EXTENT (path, CLAMPADD(n, 1), __MF_CHECK_READ, "dlopen path");
+ }
p = dlopen (path, flags);
if (NULL != p) {
#ifdef MF_REGISTER_dlopen
--
Summary: mudflap instrumentation of dlopen is incorrect
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libmudflap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24619
[Bug libmudflap/24619] mudflap instrumentation of dlopen is incorrect
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-01 17:48 --- I think this is a GNU extension or one which came in from elf. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24619
[Bug target/24620] New: [4.1 Regression] internal compiler error: in find_reloads, at reload.c:3730
/usr/lib64/gcc/s390x-suse-linux/4.1.0/cc1plus -fpreprocessed alpha_mask3.ii
-quiet -dumpbase alpha_mask3.cpp -m64 -mzarch -march=z900 -auxbase-strip
alpha_mask3.o -O2 -Wall -version -fmessage-length=0 -o alpha_mask3.s
alpha_mask3.cpp: In member function 'unsigned int the_application::render()':
alpha_mask3.cpp:489: error: unable to generate reloads for:
(insn 3221 3217 3224 335 (set (zero_extract:DI (subreg:DI
(reg:SI 12 %r12 [orig:672 D.16347 ] [672]) 0)
(const_int 16 [0x10])
(const_int
48 [0x30]))
(const_int 32794 [0x801a])) 101 {*insvdi_reg_imm} (insn_list:REG_DEP_TRUE 3217
(nil))
(nil))
alpha_mask3.cpp:489: internal compiler error: in
find_reloads, at reload.c:3730
--
Summary: [4.1 Regression] internal compiler error: in
find_reloads, at reload.c:3730
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: critical
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
GCC target triplet: s390x-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24620
[Bug target/24620] [4.1 Regression] internal compiler error: in find_reloads, at reload.c:3730
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-01 18:00 --- Created an attachment (id=10100) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10100&action=view) reduced testcase testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24620
[Bug middle-end/24514] [4.0/4.1 Regression] ICE on bootstrap
--- Comment #9 from echristo at apple dot com 2005-11-01 18:06 --- Bringing down to P3 and letting Mark set the priority. -- echristo at apple dot com changed: What|Removed |Added CC||mark at codesourcery dot com Priority|P1 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
[Bug tree-optimization/24609] Same value duplicated in two different registers
--- Comment #5 from ian at airs dot com 2005-11-01 18:06 --- That means that you did get only one register, and that therefore the block was simple enough for RTL if-conversion to operate. So I'd still like to understand why we get two identical registers in the original test case, which is clearly bad. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24609
[Bug middle-end/24514] [4.0/4.1 Regression] ICE on bootstrap
--- Comment #10 from mmitchel at gcc dot gnu dot org 2005-11-01 18:13 --- I'm going to make this a P2. IRIX isn't a primary platform anymore. Thanks, Eric. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
[Bug middle-end/24514] [4.0/4.1 Regression] ICE on bootstrap
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-11-01 18:18 --- Oh, this effects mips-elf also which is a primary target. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|mips-sgi-irix6.5| GCC host triplet|mips-sgi-irix6.5| GCC target triplet|mips-sgi-irix6.5|mips-sgi-irix6.5, mips-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
[Bug middle-end/24514] [4.0/4.1 Regression] ICE on bootstrap
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-01 18:27 --- It is failing in: 285 return offset % GET_MODE_SIZE (mode) != 0; mode is BLKmode which has a mode size of 0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
[Bug tree-optimization/18501] [4.1 Regression] Missing 'used unintialized' warning
--- Comment #9 from dnovillo at gcc dot gnu dot org 2005-11-01 18:29 --- Jeff has a much better approach to solving this. http://gcc.gnu.org/ml/gcc/2005-11/msg00032.html -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added CC||law at gcc dot gnu dot org AssignedTo|dnovillo at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
[Bug middle-end/24514] [4.0/4.1 Regression] ICE on bootstrap
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-11-01 18:30 --- The RTL which is failing: (set (reg:DI 2 $2 [197]) (unspec:DI [ (mem/s/c:BLK (plus:DI (reg/f:DI 29 $sp) (const_int 8 [0x8])) [0+4 S8 A32]) (mem/s/c:QI (plus:DI (reg/f:DI 29 $sp) (const_int 8 [0x8])) [0+4 S1 A32]) ] 18)) I don't even know what this instruction does but it is a MIPS specific issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-01 18:30:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
[Bug tree-optimization/24609] Same value duplicated in two different registers
--- Comment #6 from ian at airs dot com 2005-11-01 18:46 --- Created an attachment (id=10101) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10101&action=view) .s file from gcc 3.4 -S -O2 I've attached the assembler code generated by gcc 3.4 with -S -O2. This code is much better than that generated by 4.1. It does not duplicate the register, and RTL if-conversion is able to eliminate the branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24609
[Bug tree-optimization/24609] [4.1 regression] Same value duplicated in two different registers
--- Comment #7 from ian at airs dot com 2005-11-01 18:47 --- Because the 4.1 code is worse than the 3.4 code, I believe that this is a 4.1 regression, and I am marking it as such. Please correct me if I made a mistake. -- ian at airs dot com changed: What|Removed |Added Summary|Same value duplicated in two|[4.1 regression] Same value |different registers |duplicated in two different ||registers http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24609
[Bug target/24621] New: [4.1 Regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:393
We ICE compiling unrar
/usr/lib64/gcc/s390x-suse-linux/4.1.0/cc1plus -fpreprocessed recvol.ii -quiet
-dumpbase recvol.cpp -m64 -mzarch -march=z900 -auxbase recvol -O2 -Wall -Wall
-version -fmessage-length=0 -fmessage-length=0 -o recvol.s
recvol.cpp: In member function 'bool RecVolumes::Restore(RAROptions*, const
char*, const wchar*, bool)':
recvol.cpp:135: warning: comparison between signed
and unsigned integer expressionsrecvol.cpp:377: error: insn does not
satisfy its constraints: (insn 3128 506 3129 61
(set (reg:DI 5 %r5)
(const_int 134036 [0x20b94])) 47 {*movdi_64} (nil)
(nil))
recvol.cpp:377: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:393
--
Summary: [4.1 Regression] internal compiler error: in
reload_cse_simplify_operands, at postreload.c:393
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
GCC target triplet: s390x-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24621
[Bug target/24621] [4.1 Regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:393
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-01 18:49 --- Created an attachment (id=10102) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10102&action=view) reduced testcase testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24621
[Bug tree-optimization/18501] [4.1 Regression] Missing 'used unintialized' warning
--- Comment #10 from law at redhat dot com 2005-11-01 18:50 --- Subject: Re: [4.1 Regression] Missing 'used unintialized' warning On Tue, 2005-11-01 at 18:29 +, dnovillo at gcc dot gnu dot org wrote: > > --- Comment #9 from dnovillo at gcc dot gnu dot org 2005-11-01 18:29 > --- > > Jeff has a much better approach to solving this. > http://gcc.gnu.org/ml/gcc/2005-11/msg00032.html I'd rather you not assign it to me just yet -- while I think my approach is better, I don't think we have a consensus that it's what we're going to do yet :-) jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
[Bug tree-optimization/18501] [4.1 Regression] Missing 'used unintialized' warning
--- Comment #11 from dnovillo at redhat dot com 2005-11-01 18:56 --- Subject: Re: [4.1 Regression] Missing 'used unintialized' warning On Tuesday 01 November 2005 13:50, law at redhat dot com wrote: > I'd rather you not assign it to me just yet -- while I think my approach > is better, I don't think we have a consensus that it's what we're going > to do yet :-) > Don't worry, I haven't assigned it :) I just added a pointer to the thread and added you to the CC list. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
[Bug fortran/24534] [4.0/4.1 Regression] PUBLIC derived types with private components
--- Comment #5 from tobi at gcc dot gnu dot org 2005-11-01 19:22 --- CCing pault, as he introduced that error. Looks like you've been to strict, Paul -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org, ||pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24534
[Bug fortran/24524] Fortran dependency checking should reverse loops
-- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-01 19:24:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24524
[Bug libgcj/24616] linking BC-compiled classes: NoClassDefFoundErrors should be deferred
--- Comment #1 from thebohemian at gmx dot net 2005-11-01 19:32 --- Created an attachment (id=10103) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10103&action=view) A test for the linking mechanism This is a slightly bigger test for the linking mechanism. Unpack the tar.bz2, put gcj4 in your path and run make. How does it work: - there is a single source file which contains 4 classes. After the compilation to bytecode the file test/linker/TestClass.class is removed. - a jar is created from the remaining classes - a shared object is compiled from the jar - a gcjdb file is created - the classes in the jar are registered in the db file If everything is fine then run the shell script: bc-run.sh You will see that gij fails to load and execute the main class. On Sun (can be invoked by nf-run.sh if 'java' runs the proprietary VM) java the test will succeed. The test contains some expected failures as well as situations where no error happens although variables of the missing class test.linker.TestClass are involved. As a bonus there is a setup for gij in interpreted mode. This is for another PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616
[Bug libgcj/24616] linking BC-compiled classes: NoClassDefFoundErrors should be deferred
--- Comment #2 from thebohemian at gmx dot net 2005-11-01 19:38 --- More hints for the test: running the start script as: ??-run.sh nothing should succeed on every vm in every variant since the critical code locations are not touched in any way. However this only succeed for gij in interpreted mode when my patch for PR #17021 is applied. -- thebohemian at gmx dot net changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |thebohemian at gmx dot net |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-11-01 16:22:23 |2005-11-01 19:38:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616
[Bug fortran/24398] invalid module file gives weird error
-- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-01 19:50:33 date|| Summary|gfortran tries to parse a |invalid module file gives |comment in a module |weird error http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24398
[Bug middle-end/24462] [4.1 Regression] packed-aligned structures are laid out differently
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-01 19:51 --- Maybe I am missing something, somewhere, what does the missing DECL_PACKED do? Do you have a simple compile time testcase which fails with 4.1.0 but passes with 4.0? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24462
[Bug fortran/24404] Poor Error Description, bad error order
--- Comment #2 from tobi at gcc dot gnu dot org 2005-11-01 19:53 --- The ordering of errors is hard to tackle, the bad error description is easily fixed on the other hand. -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-01 19:53:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24404
[Bug c++/17964] [4.0/4.1 Regression] cpp error messages contain wrong line in C++
--- Comment #9 from jsm28 at gcc dot gnu dot org 2005-11-01 20:03 --- Working on a fix. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jsm28 at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-10-13 20:57:39 |2005-11-01 20:03:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17964
[Bug fortran/24404] Poor Error Description, bad error order
--- Comment #3 from tobi at gcc dot gnu dot org 2005-11-01 20:05 --- Subject: Bug 24404 Author: tobi Date: Tue Nov 1 20:05:54 2005 New Revision: 106346 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106346 Log: PR fortran/24404 * resolve.c (resolve_symbol): Output symbol names in more error messages, clarify error message. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24404
[Bug fortran/24404] Poor Error Description, bad error order
--- Comment #4 from tobi at gcc dot gnu dot org 2005-11-01 20:14 --- It remains the ordering of the error messages which in this case is hard to tackle, I'm tempted to say WONTFIX. -- tobi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|tobi at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24404
[Bug fortran/24404] Poor Error Description, bad error order
-- tobi at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24404
[Bug fortran/24404] Poor Error Description, bad error order
-- tobi at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24404
[Bug fortran/24406] EQUIVALENCE broken in 32-bit code with optimization -O2
--- Comment #6 from tobi at gcc dot gnu dot org 2005-11-01 20:20 --- (In reply to comment #3) > The code is illegal, and therefore gfortran can do anything > it wants (including start WW III). > > (1) rteps is never defined, so it can't be reference in the IF > statement. > > (2) Even if rteps was defined prior to the assignments of irt(1) and > irt(2), rteps would become undefined via 14.7.6(1) of the standard. > > (3) The use of BOZ literal constants here is nonstandard although > gfortran may permit its use in this manner (I haven't checked). Using equivalences this way is a common extension, and we actually use this in a number of testcases ourselves, so if we decided to start WWIII in this case, we probably wouldn't live much longer than our testsuite runs take. -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24406
[Bug c++/19756] -Wparentheses doesn't warn on ambiguous if in C++
--- Comment #6 from dank at kegel dot com 2005-11-01 20:22 --- Is this a duplicate of bug 19564 ? -- dank at kegel dot com changed: What|Removed |Added CC||dank at kegel dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19756
[Bug fortran/24357] whither ratfor?
--- Comment #2 from tobi at gcc dot gnu dot org 2005-11-01 20:25 --- I'd say, if someone wants to implement the necessary specs, he's free to do so, but for the time being, we can remove the support from invoke.texi, and gcc.c. -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-10-14 02:53:16 |2005-11-01 20:25:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24357
[Bug java/20495] [4.0/4.1 Regression] building gcj hangs on gcj-dbtool
--- Comment #2 from aph at gcc dot gnu dot org 2005-11-01 20:41 --- THis looks like a hang in the unwinder the very first time any exception is thrown -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20495
[Bug target/24623] New: [4.1 Regression] internal compiler error: in propagate_one_insn, at flow.c:1702
We ICE in compiling libxquery: /usr/lib64/gcc/s390x-suse-linux/4.1.0/cc1plus -fpreprocessed XQFLWOR.ii -quiet -dumpbase XQFLWOR.cpp -m64 -mzarch -march=z900 -auxbase-strip /usr/src/packages/BUILD/xquery-1.1.0/build_unix/.libs/XQFLWOR.o -O2 -Wall -version -fmessage-length=0 -fPIC -o XQFLWOR.s XQFLWOR.cpp: In copy constructor 'SortableItem::SortableItem(const SortableItem&)':XQFLWOR.cpp:78: error: Attempt to delete prologue/epilogue insn: (insn 163 162 164 3 (parallel [(set (reg:DI 6 %r6) (mem:DI (plus:DI (reg/f:DI 15 %r15) (const_int 48 [0x30])) [23 S8 A64])) (set (reg:DI 7 %r7) (mem:DI (plus:DI (reg/f:DI 15 %r15) (const_int 56 [0x38])) [23 S8 A64])) (set (reg:DI 8 %r8) (mem:DI (plus:DI (reg/f:DI 15 %r15) (const_int 64 [0x40])) [23 S8 A64])) (set (reg:DI 9 %r9) (mem:DI (plus:DI (reg/f:DI 15 %r15) (const_int 72 [0x48])) [23 S8 A64])) ]) -1 (nil) (nil)) XQFLWOR.cpp:78: internal compiler error: in propagate_one_insn, at flow.c:1702 Please submit a full bug report, with preprocessed source if appropriate. -- Summary: [4.1 Regression] internal compiler error: in propagate_one_insn, at flow.c:1702 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org GCC target triplet: s390x-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24623
[Bug target/24623] [4.1 Regression] internal compiler error: in propagate_one_insn, at flow.c:1702
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-01 20:57 --- Created an attachment (id=10104) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10104&action=view) reduced testcase testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24623
[Bug fortran/24008] gfortran too permissive about ENTRY syntax
-- tobi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-09-22 23:58:09 |2005-11-01 21:00:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24008
[Bug target/24230] [4.1 Regression] ICE in extract_insn with altivec
--- Comment #24 from bonzini at gcc dot gnu dot org 2005-11-01 21:05 --- Aldy, I have a patch for this that only needs more testing. If you want, and if you do not have any better idea than what I said in comment #17, I can take this. -- bonzini at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24230
[Bug target/24230] [4.1 Regression] ICE in extract_insn with altivec
--- Comment #25 from aldyh at gcc dot gnu dot org 2005-11-01 21:16 --- Bonzini: Perhaps both approaches would be even better. We definitely should handle the transformed vector, because theoretically it's still easy to generate. And adding the extra check you mention would be icing on the cake :). -- aldyh at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24230
[Bug fortran/23420] ICE on invalid print statement
--- Comment #9 from tobi at gcc dot gnu dot org 2005-11-01 21:18 --- Ugh, I completely forgot about this one. I'll try to look into this later this week. -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23420
[Bug libfortran/23363] gfortran 30 x slower that g77 on random I/O
--- Comment #10 from tobi at gcc dot gnu dot org 2005-11-01 21:21 --- Fixed if I read Janne's measurements correctly, please reopen if I'm wrong. -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23363
[Bug libfortran/21820] Really, really, horrible IO performance
--- Comment #14 from tobi at gcc dot gnu dot org 2005-11-01 21:22 --- (In reply to comment #13) > The patch from #12 has been committed to mainline. So should this bug be closed? -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21820
[Bug target/24230] [4.1 Regression] ICE in extract_insn with altivec
--- Comment #26 from bonzini at gcc dot gnu dot org 2005-11-01 21:23 --- Okay, taking this. If you ever want to make SPE constants more optimized, be careful about this bug though! ;-) -- bonzini at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|aldyh at gcc dot gnu dot org|bonzini at gcc dot gnu dot ||org Status|NEW |ASSIGNED Last reconfirmed|2005-10-31 20:10:22 |2005-11-01 21:23:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24230
[Bug fortran/23460] [3.4 Regression] g77 unable to locate fortran INCLUDE files when preprocessed
--- Comment #3 from tobi at gcc dot gnu dot org 2005-11-01 21:24 --- This is really the same as PR 20811: we don't take the (original) location of the source file into account. *** This bug has been marked as a duplicate of 20811 *** -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23460
[Bug fortran/20811] gfortran include problem (regression from g77)
--- Comment #3 from tobi at gcc dot gnu dot org 2005-11-01 21:24 --- *** Bug 23460 has been marked as a duplicate of this bug. *** -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||douglas dot vechinski at ||dynetics dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20811
[Bug fortran/22495] Different ideas about .true. and .false.
--- Comment #2 from tobi at gcc dot gnu dot org 2005-11-01 21:30 --- I'd say we don't care. Results with other compilers: pgf90: 0 F F F 1 T F F 2 F F F 3 T F F 4 F F F ifort: 0 F F F 1 T T T 2 F F F 3 T T T 4 F F F Admittedly, there's something to be said about ifort's results :-) -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22495
[Bug fortran/22495] Different ideas about .true. and .false.
--- Comment #3 from tobi at gcc dot gnu dot org 2005-11-01 21:36 --- Actually, the .NEQV. case would be easily fixed, as there's a TRUTH_XOR_EXPR in the middleend. On the other hand .EQV. would require adding some special case logic to gfc_conv_expr_op (admittedly, not difficult logic). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22495
[Bug fortran/24245] -fdump-parse-tree gives ICE for CONTAINED functions
--- Comment #5 from eedelman at gcc dot gnu dot org 2005-11-01 21:40 --- Subject: Bug 24245 Author: eedelman Date: Tue Nov 1 21:40:06 2005 New Revision: 106353 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106353 Log: fortran/ 2005-11-01 Erik Edelmann <[EMAIL PROTECTED]> PR 24245 * trans.c (gfc_generate_code): Move code to create a main program symbol from here ... * parse.c (main_program_symbol): ... to this new function, setting the locus from gfc_current_locus instead of ns->code->loc. (gfc_parse_file): Call main_program_symbol for main programs. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/parse.c trunk/gcc/fortran/trans.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24245
[Bug target/24624] New: [4.1 Regression] internal compiler error: in reload, at reload1.c:1071
We ICE compiling the linux kernel. /usr/lib64/gcc/s390x-suse-linux/4.1.0/cc1 -fpreprocessed inetpeer.i -quiet -dumpbase inetpeer.c -m64 -mbackchain -msoft-float -march=z900 -mpacked-stack -mstack-size=8192 -mstack-guard=256 -mwarn-dynamicstack -mwarn-framesize=256 -mzarch -auxbase-strip net/ipv4/.tmp_inetpeer.o -O2 -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -Werror-implicit-function-declaration -Wno-sign-compare -Wdeclaration-after-statement -Wno-pointer-sign -version -fno-strict-aliasing -fno-common -ffreestanding -fomit-frame-pointer -finline-limit=1 -fno-strength-reduce -o inetpeer.s net/ipv4/inetpeer.c: In function 'peer_check_expire': net/ipv4/inetpeer.c:461: internal compiler error: in reload, at reload1.c:1071 Please submit a full bug report, with preprocessed source if appropriate. See http://www.suse.de/feedback> for instructions. -- Summary: [4.1 Regression] internal compiler error: in reload, at reload1.c:1071 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: critical Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org GCC target triplet: s390x-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24624
[Bug target/24624] [4.1 Regression] internal compiler error: in reload, at reload1.c:1071
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-01 21:48 --- Created an attachment (id=10105) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10105&action=view) reduced testcase testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24624
[Bug fortran/24245] -fdump-parse-tree gives ICE for CONTAINED functions
--- Comment #6 from eedelman at gcc dot gnu dot org 2005-11-01 21:50 --- Subject: Bug 24245 Author: eedelman Date: Tue Nov 1 21:50:26 2005 New Revision: 106355 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106355 Log: fortran/ 2005-11-01 Erik Edelmann <[EMAIL PROTECTED]> PR fortran/24245 * trans.c (gfc_generate_code): Move code to create a main program symbol from here ... * parse.c (main_program_symbol): ... to this new function, setting the locus from gfc_current_locus instead of ns->code->loc. (gfc_parse_file): Call main_program_symbol for main programs. Modified: branches/gcc-4_0-branch/gcc/fortran/ChangeLog branches/gcc-4_0-branch/gcc/fortran/parse.c branches/gcc-4_0-branch/gcc/fortran/trans.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24245
[Bug fortran/24245] -fdump-parse-tree gives ICE for CONTAINED functions
--- Comment #7 from eedelman at gcc dot gnu dot org 2005-11-01 21:51 --- With this bug fixed on both mainline and 4.0, I declare this PR fixed -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24245
[Bug target/24600] [4.1 Regression] unrecognizable instruction
--- Comment #4 from uweigand at gcc dot gnu dot org 2005-11-01 21:53 --- This is a bug in the old loop optimizer introduced by: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00690.html The problem with this patch is that it assumes gen_move_insn where the source is a PLUS representing an address always returns a valid instruction. This is not the case at least on s390. -- uweigand at gcc dot gnu dot org changed: What|Removed |Added CC||uweigand at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-01 21:53:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24600
