[Bug rtl-optimization/7061] Alpha: Access of bytes in struct parameters
--- Comment #4 from rth at gcc dot gnu dot org 2005-11-02 08:06 --- Still present in 4.1. As a guess, we're creating a BLKmode register (because alignof(struct s1) is less than alignof(HImode)), and assign_parm_setup_block forces the data into the stack. It's possible this can be bypassed for some structures, but I havn't given it much thought. -- rth at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-09-07 17:37:09 |2005-11-02 08:06:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7061
[Bug rtl-optimization/7061] Access of bytes in struct parameters
--- Comment #5 from rth at gcc dot gnu dot org 2005-11-02 08:09 --- And there is nothing Alpha specific about this. Any target which passes structures in registers can show it. For instance, ia64: f1: .prologue .body .mmi st2 [r12] = r32 nop 0 mov r14 = r12 ;; .mmi ld1 r15 = [r14], 1 ;; ld1 r8 = [r14] nop 0 ;; .mib nop 0 add r8 = r8, r15 br.ret.sptk.many b0 .endp f1# .align 16 .global f2# .proc f2# f2: .prologue .body .mii nop 0 extr.u r8 = r32, 8, 8 zxt1 r32 = r32 ;; .mib nop 0 add r8 = r8, r32 br.ret.sptk.many b0 -- rth at gcc dot gnu dot org changed: What|Removed |Added GCC host triplet|alphapca56-*-linux-gnu | GCC target triplet|alphapca56-*-linux-gnu | Summary|Alpha: Access of bytes in |Access of bytes in struct |struct parameters |parameters http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7061
[Bug middle-end/24612] [gomp] Bogus is used uninitialized warning
--- Comment #1 from jakub at gcc dot gnu dot org 2005-11-02 08:23 ---
That testcase is IMHO invalid (see
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00099.html
), but
void
foo (void)
{
int i;
#pragma omp parallel sections shared (i)
{
#pragma omp section
{
i = 0;
++i;
}
}
}
which is valid warns too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24612
[Bug c++/24613] [gomp] ICE on unexpected #pragma omp section
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-02 08:57:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24613
[Bug c++/24629] Can't use template argument as friend
--- Comment #2 from giovannibajo at libero dot it 2005-11-02 09:20 --- Template parameters can't be used in friend declarations (nor in any elaborated type specifier construct). -- giovannibajo at libero dot it changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24629
[Bug target/24610] The comment start symbol of arm target
--- Comment #3 from rearnsha at gcc dot gnu dot org 2005-11-02 10:13 --- ../.././gcc/config/arm/lib1funcs.asm:731: Error: no such instruction: `moveq pc,lr' This just shows that you aren't picking up an ARM assembler. Have you installed GAS correctly? and does the compiler know how to find it? If you've not build a cross-compilation toolchain before, it might help to take a look at crosstool (http://kegel.com/crosstool/) -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24610
[Bug libstdc++/23425] vector::clear should be manually inlined
--- Comment #5 from pcarlini at suse dot de 2005-11-02 10:29 --- Fixed for 4.1.0. -- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23425
[Bug libstdc++/23425] vector::clear should be manually inlined
-- pcarlini at suse dot de changed: What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23425
[Bug fortran/24633] New: MODULE attribute conflicts with PROCEDURE attribute
MODULE attribute conflicts with PROCEDURE attribute this error message is not accurate enough. The conflicting attribute should be mentionned. For instance in: module abc contain function abc() The conflicting attributes is the name of the module and the name of the function. this is valid for: GNU Fortran 95 (GCC) 4.1.0 20051015 (experimental) Copyright (C) 2005 Free Software Foundation, Inc. on Linux descartes 2.6.13-1.1526_FC4smp #1 SMP Wed Sep 28 19:28:24 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux -- Summary: MODULE attribute conflicts with PROCEDURE attribute Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anglade at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24633
[Bug libgcj/24616] linking BC-compiled classes: NoClassDefFoundErrors should be deferred
--- Comment #3 from thebohemian at gmx dot net 2005-11-02 11:09 --- Created an attachment (id=10113) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10113action=view) lazy linker test setup This is a newer version of the test for class linking. The change is that the actual tests are not run inside the methods of the LazyLinker class but in separate ones which are then loaded via reflection. By doing so loading the LazyLinker class itself works on all test environments and one can inspect the steps until the test is run more detailed. -- thebohemian at gmx dot net changed: What|Removed |Added Attachment #10103|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616
[Bug c/18624] GCC does not detect local variable set but never used
--- Comment #8 from alexander_herrmann at yahoo dot com dot au 2005-11-02
11:29 ---
I guessed somebody found it before but searching the db I couldn'n find it.
Anyway shouldn't we make it than dependend or blocking Bug
#tree-optimization/21513
As the funktion while C correct will never make it to the compiler using the
-Werror switch together with optimization when this Bug is fixed :)
int problem_funktion(int a)
{
int b;
if (__builtin_expect(((a 0) ((b = 5) != 0)),
1))
{
return(a*b);
}
return(a);
}
--
alexander_herrmann at yahoo dot com dot au changed:
What|Removed |Added
OtherBugsDependingO||21513
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18624
[Bug fortran/22495] Different ideas about .true. and .false.
--- Comment #4 from tobi at gcc dot gnu dot org 2005-11-02 12:37 --- I was curious, and tried below patch, changing .EQV. to .NEQV. in the testcase, and still we don't get the right result, since our logical type is a real logical, in that only the lowest bit is considered. I did some checking, and our output functions seem to agree with the generated code about what values are true and what values are false, i.e. print *,i, lo1 , lo1 .eqv. lo2, lo1 .eqv. .true. if (lo1 .eqv. lo2) PRINT *, 2nd column true if (lo1 .eqv. .true.) PRINT *, 3rd column true would not do fancy stuff. Index: trans-expr.c === --- trans-expr.c(revision 106379) +++ trans-expr.c(working copy) @@ -988,12 +988,17 @@ gfc_conv_expr_op (gfc_se * se, gfc_expr break; case INTRINSIC_NE: -case INTRINSIC_NEQV: code = NE_EXPR; checkstring = 1; lop = 1; break; +case INTRINSIC_NEQV: + code = TRUTH_XOR_EXPR; + checkstring = 1; + lop = 1; + break; + case INTRINSIC_GT: code = GT_EXPR; checkstring = 1; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22495
[Bug c/24634] New: DW_AT_high_pc and DW_AT_low_pc zero in DWARF-2 debug info in object file in 64bit world
We are using a cross compiler for 64 bit Linux on MIPS yosemite. When we compile c sources with command: mips64-linux-gnu-gcc -c -gdwarf-2 -mabi=64 xxx.c then the value of atribute in dwarf2 info : DW_AT_high_pc and DW_AT_low_pc is 0 what is surely wrong for mips64-linux-gnu-gcc -c -gdwarf-2 -mabi=32 there are reasonable values in these attributes -- Summary: DW_AT_high_pc and DW_AT_low_pc zero in DWARF-2 debug info in object file in 64bit world Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mlynarik at decef dot elf dot stuba dot sk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24634
[Bug libfortran/24459] gfortran namelist problem
--- Comment #6 from ed at eh3 dot com 2005-11-02 13:12 --- Hi jvdelisle, I'm not sure if it qualifies as high priority but it is one of the few (only?) gfortran bugs that we've encountered with the MITgcm fluid flow and transport model (http://mitgcm.org). If it helps, I'll be happy to test your fixes, do weekly testing with new versions of gfortran and our model, etc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24459
[Bug fortran/24633] MODULE attribute conflicts with PROCEDURE attribute
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-02 13:15 --- Full testcase: module abc contains function abc() i=1 end function end module There is actually two problems here, the first is the message about the conflicts is not very clear. The second issue is that the error recovery is not really good in that we don't really enter a function scope (sorry I am using C terms, I don't know a better way of describing the issue). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2005-11-02 13:15:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24633
[Bug fortran/24633] MODULE attribute conflicts with PROCEDURE attribute
--- Comment #2 from anglade at gmail dot com 2005-11-02 13:28 --- (In reply to comment #1) Full testcase: module abc contains function abc() i=1 end function end module There is actually two problems here, the first is the message about the conflicts is not very clear. The second issue is that the error recovery is not really good in that we don't really enter a function scope (sorry I am using C terms, I don't know a better way of describing the issue). Sorry for being unclear. 1) The error in the test case is that the function and the module have the same name. 2) The problem with gfortran is not that it does any mistake. It's just that the output error message is not clear enough. 3) sorry for not having put a complete dummy test case. here it is module abc contains function abc(i) integer::i,abc abc=i end function abc end module abc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24633
[Bug c/24635] New: Wrong statement reordering
/*
* Summary:
* Wrong statement reordering
* Description:
* If you run this program, it will produce an output of 1.
* The reason is that the assignment V1=0 which should be
* executed before the call to cl_throw() is moved after
* this call, and hence when cl_throw() invokes longjmp()
* the variable is not assigned a value.
* Operating system:
* Ubuntu 5.10
* Machine:
* Pentium 4
* Compiler: (gcc -v)
* Using built-in specs.
* Target: i486-linux-gnu
* Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-shared
--with-system-zlib --libexecdir=/usr/lib --enable-nls
--without-included-gettext --enable-threads=posix --program-suffix=-4.0
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
--enable-mpfr --disable-werror --enable-checking=release i486-linux-gnu
* Thread model: posix
* gcc version 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)
*/
typedef int __jmp_buf[6];
typedef struct
{
unsigned long int __val[(1024 / (8 * sizeof (unsigned long int)))];
} __sigset_t;
typedef struct __jmp_buf_tag
{
__jmp_buf __jmpbuf;
int __mask_was_saved;
__sigset_t __saved_mask;
} jmp_buf[1];
extern int setjmp (jmp_buf __env) __attribute__ ((__nothrow__));
extern void longjmp (struct __jmp_buf_tag __env[1], int __val)
__attribute__ ((__nothrow__)) __attribute__ ((__noreturn__));
extern int printf (__const char *__restrict __format, ...);
static jmp_buf foo;
extern void cl_throw();
void cl_throw()
{
longjmp(foo, 1);
}
int L1foo(int V0)
{
volatile int V1 = V0;
if (setjmp (foo)) {
goto L9;
}
V1= 0;
cl_throw();
L9:;
return V1;
}
int main ()
{
printf(%d\n, L1foo(1));
return 0;
}
--
Summary: Wrong statement reordering
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: worm at arrakis dot es
GCC host triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24635
[Bug c++/24613] [gomp] ICE on unexpected #pragma omp section
--- Comment #1 from jakub at gcc dot gnu dot org 2005-11-02 13:59 --- Subject: Bug 24613 Author: jakub Date: Wed Nov 2 13:59:00 2005 New Revision: 106383 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106383 Log: PR c++/24613 * c-parser.c (c_parser_pragma): Diagnose PRAGMA_OMP_SECTION outside of PRAGMA_OMP_SECTIONS construct. cp/ * parser.c (cp_parser_pragma): Diagnose PRAGMA_OMP_SECTION outside of PRAGMA_OMP_SECTIONS construct. testsuite/ * gcc.dg/gomp/sections-4.c: New test. * g++.dg/gomp/sections-4.C: New test. Added: branches/gomp-20050608-branch/gcc/testsuite/g++.dg/gomp/sections-4.C branches/gomp-20050608-branch/gcc/testsuite/gcc.dg/gomp/sections-4.c Modified: branches/gomp-20050608-branch/gcc/ChangeLog.gomp branches/gomp-20050608-branch/gcc/c-parser.c branches/gomp-20050608-branch/gcc/cp/ChangeLog.gomp branches/gomp-20050608-branch/gcc/cp/parser.c branches/gomp-20050608-branch/gcc/testsuite/ChangeLog.gomp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24613
[Bug c++/24613] [gomp] ICE on unexpected #pragma omp section
--- Comment #2 from jakub at gcc dot gnu dot org 2005-11-02 14:03 --- Fixed on the branch. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24613
[Bug fortran/24636] New: gfortran: STOP without stop-code too noisy, regression w.r.t. g77
Hi, as it has bothered me for quite some time, I finally decided to report. The program program gfcbug29 stop end when compiled with g77, executes and terminates without any message. *Only* when a stop code is present, as in stop 0 it (the g77 runtime) says so. However, gfortran always makes it write the message, even when no stop code is present: STOP 0 g77 is consistent with all other compilers that I have access to, and also the F2003 draft standard (sec. 8.4) is quite explicit here. Please fix. Cheers, -ha -- Summary: gfortran: STOP without stop-code too noisy, regression w.r.t. g77 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24636
Re: [Bug middle-end/23181] [4.1 Regression] Slowdown of the bresenham line drawing by roughly 20%
--- Comment #13 from law at redhat dot com 2005-10-31 23:36 --- Subject: Re: [4.1 Regression] Slowdown of the bresenham line drawing by roughly 20% On Mon, 2005-10-31 at 23:25 +, hubicka at ucw dot cz wrote: See comment #5. The fact that we ended up with more jumps was just the fact that dom transforms it into more dificult to optimize form And how do you propose to change that without simply removing the reassociation code from our tree optimizers? (and we didn't have code sinking at that moment, there is also mentioned that code sinking would help here). It is not CSE nor reassociation. It is combining of the two increments done interesting way so we can't really undo it later. It is definitely reassociation + simplification (reassociation without simplification is, err, dumb) -- the code was lifted from cse.c and transformed to work on trees in SSA form (and stuck into DOM as we didn't have a better place to put it a couple years ago :(. Hmm, perhaps restricting the reassociation + simplification into case where it kills last use of the intermediate result? I can definitly think of testcases where such heuristic would hurt, but some experimentation with it would be useful... I've looked what the other compilers are doing and except for ICC that manages to get even worse code than we do by completely broken if conversion all seems to get across that correctly... Honza
[Bug middle-end/23181] [4.1 Regression] Slowdown of the bresenham line drawing by roughly 20%
--- Comment #15 from hubicka at ucw dot cz 2005-11-02 14:32 --- Subject: Re: [4.1 Regression] Slowdown of the bresenham line drawing by roughly 20% --- Comment #13 from law at redhat dot com 2005-10-31 23:36 --- Subject: Re: [4.1 Regression] Slowdown of the bresenham line drawing by roughly 20% On Mon, 2005-10-31 at 23:25 +, hubicka at ucw dot cz wrote: See comment #5. The fact that we ended up with more jumps was just the fact that dom transforms it into more dificult to optimize form And how do you propose to change that without simply removing the reassociation code from our tree optimizers? (and we didn't have code sinking at that moment, there is also mentioned that code sinking would help here). It is not CSE nor reassociation. It is combining of the two increments done interesting way so we can't really undo it later. It is definitely reassociation + simplification (reassociation without simplification is, err, dumb) -- the code was lifted from cse.c and transformed to work on trees in SSA form (and stuck into DOM as we didn't have a better place to put it a couple years ago :(. Hmm, perhaps restricting the reassociation + simplification into case where it kills last use of the intermediate result? I can definitly think of testcases where such heuristic would hurt, but some experimentation with it would be useful... I've looked what the other compilers are doing and except for ICC that manages to get even worse code than we do by completely broken if conversion all seems to get across that correctly... Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23181
[Bug c/24635] Wrong statement reordering
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-02 14:51 --- I cannot reproduce this on 4.0.1 or CVS HEAD of 4.0 (20050919), nor on 4.1.0. What optimization options did you use? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Known to work||4.1.0 4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24635
[Bug c/24635] Wrong statement reordering
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-02 14:55 --- I cannot reproduce this with the compiler version you have. GNU C version 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9) (x86_64-linux-gnu) -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.1.0 4.0.1 |4.1.0 4.0.1 4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24635
[Bug middle-end/24635] Wrong statement reordering
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24635
[Bug fortran/24636] gfortran: STOP without stop-code too noisy, regression w.r.t. g77
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-02 14:59 --- Confirmed, this is more of a front-end issue than a library issue. As the front-end emits a call to _gfortran_stop_numeric in both the STOP cases. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|libfortran |fortran Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-02 14:59:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24636
[Bug c++/24628] const-over-non-const identification fails
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-02 15:05 --- And works in 4.0.3 but not in 3.4.5 and 3.4.0. Closing as fixed for 4.0.3 since this was not a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to fail||3.4.0 3.4.5 3.3.6 2.95.3 ||3.2.3 3.0.4 Known to work|4.1.0 |4.1.0 4.0.3 Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24628
[Bug testsuite/24614] gcc.dg/nested-func-4.c (test for excess errors) fails
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-02 15:14 --- 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 |2005-11-02 15:14:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24614
[Bug debug/24634] DW_AT_high_pc and DW_AT_low_pc zero in DWARF-2 debug info in object file in 64bit world
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-02 15:19 --- Are you sure that there are no relocations and that it is zero because of them? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24634
[Bug middle-end/24627] [4.1 Regression] xntp miscompiled
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-02 15:47
---
Here is a further reduced testase:
typedef struct {
union {unsigned Xl_ui;} Ul_i;
union {unsigned Xl_uf;} Ul_f;
} l_fp;
void dolfptoa(short ndec)
{
l_fp work;
work.Ul_f.Xl_uf = 0x535f3d8;
while (ndec 0) {
ndec--;
work.Ul_i.Xl_ui = 0;
work.Ul_i.Xl_ui = 0;
if ((work.Ul_f.Xl_uf) 0x8000)
(work.Ul_i.Xl_ui) |= 0x1;
(work.Ul_f.Xl_uf) = 1;
(work.Ul_i.Xl_ui) = 1;
if ((work.Ul_f.Xl_uf) 0x8000)
(work.Ul_i.Xl_ui) |= 0x1;
(work.Ul_f.Xl_uf) = 1;
(work.Ul_i.Xl_ui) = 1;
if (!(work.Ul_i.Xl_ui 10))
abort ();
}
}
int main()
{
dolfptoa(6);
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24627
[Bug middle-end/24627] [4.1 Regression] xntp miscompiled
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-11-02 15:53
---
The following fails with -O1 -fno-tree-sra.
typedef struct {
struct {unsigned Xl_ui;} Ul_i;
struct {unsigned Xl_uf;} Ul_f;
} l_fp;
void dolfptoa(short ndec)
{
l_fp work;
work.Ul_f.Xl_uf = 0x535f3d8;
while (ndec 0) {
ndec--;
work.Ul_i.Xl_ui = 0;
work.Ul_i.Xl_ui = 0;
if ((work.Ul_f.Xl_uf) 0x8000)
(work.Ul_i.Xl_ui) |= 0x1;
(work.Ul_f.Xl_uf) = 1;
(work.Ul_i.Xl_ui) = 1;
if ((work.Ul_f.Xl_uf) 0x8000)
(work.Ul_i.Xl_ui) |= 0x1;
(work.Ul_f.Xl_uf) = 1;
(work.Ul_i.Xl_ui) = 1;
if (!(work.Ul_i.Xl_ui 10))
abort ();
}
}
int main()
{
dolfptoa(6);
return 0;
}
The -fno-tree-sra is need as otherwise SRA actually does it work and renames
the PHIs correctly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24627
[Bug middle-end/24627] [4.1 Regression] xntp miscompiled
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-02 16:03
---
Here is another more reduced testcase (still at -O1 -fno-tree-sra):
typedef struct {
unsigned a;
} l_fp;
void dolfptoa(short ndec)
{
l_fp work;
unsigned workUl_fXl_uf;
work.a = 0x535f3d8;
while (ndec 0) {
ndec--;
work.a = 0;
work.a = 0;
if (workUl_fXl_uf 0x8000)
work.a |= 0x1;
workUl_fXl_uf = 1;
work.a = 1;
if (workUl_fXl_uf 0x8000)
work.a |= 0x1;
workUl_fXl_uf = 1;
work.a = 1;
if (!(work.a 10))
abort ();
}
}
int main()
{
dolfptoa(6);
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24627
[Bug middle-end/24627] [4.1 Regression] xntp miscompiled
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-11-02 16:12
---
(In reply to comment #12)
Here is another more reduced testcase (still at -O1 -fno-tree-sra):
That testcase is invalid, the one which is valid:
ypedef struct {
unsigned a;
} l_fp;
void dolfptoa(short ndec)
{
l_fp work;
unsigned workUl_fXl_uf;
workUl_fXl_uf = 0x535f3d8;
while (ndec 0) {
ndec--;
work.a = 0;
work.a = 0;
if (workUl_fXl_uf 0x8000)
work.a |= 0x1;
workUl_fXl_uf = 1;
work.a = 1;
if (workUl_fXl_uf 0x8000)
work.a |= 0x1;
workUl_fXl_uf = 1;
work.a = 1;
if (!(work.a 10))
abort ();
}
}
int main()
{
dolfptoa(8);
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24627
[Bug target/24600] [4.1 Regression] unrecognizable instruction
--- Comment #6 from uweigand at gcc dot gnu dot org 2005-11-02 16:22 --- Tested patch in: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00113.html -- uweigand at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |uweigand at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||11/msg00113.html Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2005-11-01 21:53:05 |2005-11-02 16:22:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24600
[Bug libgcj/24637] New: static and non-static declarations of missing type do not pass the verifier
public class Foo {
static MissingClass STATIC_MIA;
}
public class Foo2{
MissingClass NONSTATIC_MIA;
}
Foo and Foo2 should pass the verifier if the bytecode for MissingClass is
absent.
--
Summary: static and non-static declarations of missing type do
not pass the verifier
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: thebohemian at gmx dot net
ReportedBy: thebohemian at gmx dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24637
[Bug libstdc++/23425] vector::clear should be manually inlined
--- Comment #6 from paolo at gcc dot gnu dot org 2005-11-02 16:24 --- Subject: Bug 23425 Author: paolo Date: Wed Nov 2 10:27:54 2005 New Revision: 106379 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106379 Log: 2005-11-02 Thomas Kho [EMAIL PROTECTED] PR libstdc++/23425 * include/bits/stl_vector.h (vector::clear): Open code in terms of _Destroy. 2005-11-02 Paolo Carlini [EMAIL PROTECTED] * include/bits/vector.tcc (vector::_M_fill_assign): Qualify fill_n. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_vector.h trunk/libstdc++-v3/include/bits/vector.tcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23425
[Bug target/24615] [4.1 Regression] internal compiler error: in print_shift_count_operand, at config/s390/s390.c:4025
--- Comment #5 from uweigand at gcc dot gnu dot org 2005-11-02 16:32 --- Confirmed. Looks like a backend problem, I'm working on it. -- uweigand at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |uweigand at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-02 16:32:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24615
[Bug libgcj/24638] New: inconsistent use of Jv_FindClass causing too weak error condition
Jv_FindClass throws a ClassNotFoundException in case the requested class cannot be resolved (regardless of whether the bytecode missing or a further dependency cannot be resolved). This causes problems because in case of serious bytecode errors (eg. the class of a field is missing) where a NoClassDefFoundError should reach the user code. I found code in several places in gcj where the caller of Jv_FindClass expected NULL to be returned. This affects Jv_FindClassFromSignature too because it depends on the former function. Obviously such code will not be executed (unless the Jv_FindClass takes a special codepath where it call Jv_FindClassInCache). - link.cc: around line 1000, look for: if (target_class == NULL) throw new java::lang::NoClassDefFoundError (_Jv_NewStringUTF (sym.class_name-chars())); - verify.cc: around 387, look for data.klass = _Jv_FindClassFromSignature (data.name-chars(), loader); if (data.klass == NULL) throw new java::lang::NoClassDefFoundError(data.name-toString()); I want to hear what the experts have to say about that. My suggestion would be to introduce a special variant of Jv_FindClass which does not throw a ClassNotFoundException (by swallowing it) and then carefully adjusting the code location where the old variant was used. -- Summary: inconsistent use of Jv_FindClass causing too weak error condition Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: thebohemian at gmx dot net ReportedBy: thebohemian at gmx dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24638
[Bug middle-end/24627] [4.1 Regression] xntp miscompiled
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-11-02 16:39
---
This is as far as I can reduce it, -O1:
typedef union {
unsigned a;
} l_fp;
int main(void)
{
l_fp work;
unsigned workUl_fXl_uf = 0x;
int ndec = 10;
do {
ndec--;
work.a = 0;
work.a = 0;
if (workUl_fXl_uf 1)
work.a ++;
workUl_fXl_uf = 1;
work.a ++;
if (workUl_fXl_uf 1)
work.a ++;
work.a ++;
if (work.a 4)
abort ();
}while(ndec 0);
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24627
[Bug middle-end/24627] [4.1 Regression] xntp miscompiled
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-02 17:02 --- A link to the changes (so I can be a little lazy): http://gcc.gnu.org/viewcvs?view=revrev=101841 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24627
[Bug tree-optimization/24365] [4.1 Regression] statement makes a memory store with complex
--- Comment #9 from janis at gcc dot gnu dot org 2005-11-02 17:15 --- A regression hunt on powerpc-linux identified this patch: r100793 | rth | 2005-06-09 07:43:40 + (Thu, 09 Jun 2005) | 38 lines PR tree-opt/20610 -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24365
[Bug target/18900] ppc optimization non removable
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 --- All P1 enhancements not targeted towards 4.1, moving to P5. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18900
[Bug target/23605] memset() Optimization on x86-32 bit
--- Comment #16 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 --- All P1 enhancements not targeted towards 4.1, moving to P5. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23605
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 --- All P1 enhancements not targeted towards 4.1, moving to P5. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug tree-optimization/16797] Opportunity to remove unnecessary load instructions
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 --- All P1 enhancements not targeted towards 4.1, moving to P5. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16797
[Bug tree-optimization/17106] Opportunity to eliminate loads from TOC.
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 --- All P1 enhancements not targeted towards 4.1, moving to P5. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17106
[Bug fortran/18584] --std=f would be nice
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 --- All P1 enhancements not targeted towards 4.1, moving to P5. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18584
[Bug middle-end/16458] PowerPC - redundant compare
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 --- All P1 enhancements not targeted towards 4.1, moving to P5. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16458
[Bug target/17108] Missed opportunity for strength reduction
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 --- All P1 enhancements not targeted towards 4.1, moving to P5. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17108
[Bug target/16798] PowerPC - Opportunity to use recording form instruction.
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 --- All P1 enhancements not targeted towards 4.1, moving to P5. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16798
[Bug java/18585] uniform passing of the classpath parameter
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 --- All P1 enhancements not targeted towards 4.1, moving to P5. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18585
[Bug rtl-optimization/16796] PowerPC - Unnecessary Floating Point Register Copy
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 --- All P1 enhancements not targeted towards 4.1, moving to P5. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16796
[Bug rtl-optimization/16803] PowerPC - invariant code motion could be removed from loop.
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 --- All P1 enhancements not targeted towards 4.1, moving to P5. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16803
[Bug rtl-optimization/16456] PowerPC - redundant subtract involving pointer types
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 --- All P1 enhancements not targeted towards 4.1, moving to P5. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16456
[Bug fortran/23815] Add -byteswapio flag
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 --- All P1 enhancements not targeted towards 4.1, moving to P5. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23815
[Bug target/17593] Over Aggressive Speculative Code Motion
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 --- All P1 enhancements not targeted towards 4.1, moving to P5. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17593
[Bug rtl-optimization/23726] Missed optimizations for divmod
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 --- All P1 enhancements not targeted towards 4.1, moving to P5. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23726
[Bug bootstrap/23101] Make Bootstrap fails on AIX 5.2 ML6
--- Comment #7 from elizabeth dot brosch at thomson dot com 2005-11-02 17:21 --- Subject: RE: Make Bootstrap fails on AIX 5.2 ML6 I agree. I realized that this was unnecessary. Thanks for the reply. --- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-30 17:17 --- Why do you want a compiler which is built in 64bit mode, it will not default to 64bit mode? It will be slower and hug more memory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23101
[Bug middle-end/24462] [4.1 Regression] packed-aligned structures are laid out differently
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-02 17:41 --- Hmm, I would almost want to go on a limb and say this was caused by the patch for PR 21166. Can you try to revert that patch and try the mainline compiler? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24462
[Bug middle-end/24462] [4.1 Regression] packed-aligned structures are laid out differently
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2005-11-02 17:54 --- Hmm, I would almost want to go on a limb and say this was caused by the patch for PR 21166. Can you try to revert that patch and try the mainline compiler? Of course that's it. Thanks for spotting this! -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||nathan at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24462
[Bug fortran/23815] Add -byteswapio flag
--- Comment #9 from rrr6399 at futuretek dot com 2005-11-02 18:17 --- I imagine code from g95 could be leveraged to support this feature couldn't it? This is a really important feature, especially in corporate environments where there is usually mix of big-endian and little-endian machines. (Of course, the current 64 bit record delimitters for unformatted files eliminates any hope of interoperability with other fortran compilers.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23815
[Bug target/24178] [4.0/4.1 regression] generates code that produces unaligned access exceptions
--- Comment #11 from rth at gcc dot gnu dot org 2005-11-02 18:20 --- Subject: Bug 24178 Author: rth Date: Wed Nov 2 18:20:07 2005 New Revision: 106388 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106388 Log: PR target/24178 * config/alpha/alpha.c (get_aligned_mem): Honor alignment given by MEM_ALIGN. Added: trunk/gcc/testsuite/gcc.target/alpha/pr24178.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/alpha/alpha.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24178
[Bug fortran/24636] gfortran: STOP without stop-code too noisy, regression w.r.t. g77
--- Comment #2 from kargl at gcc dot gnu dot org 2005-11-02 18:27 --- This has bugged me also. For a patch, see http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00122.html -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24636
[Bug c++/24569] [4.0/4.1 regression] ICE in add_AT_specification, at dwarf2out.c:4966
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-11-02 18:30 --- Subject: Bug 24569 Author: mmitchel Date: Wed Nov 2 18:30:26 2005 New Revision: 106392 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106392 Log: PR c++/24569 * pt.c (instantiate_decl): Use cp_finish_decl, not finish_static_data_member_decl. PR c++/24569 * g++.dg/debug/static1.C: New test. Added: trunk/gcc/testsuite/g++.dg/debug/static1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24569
[Bug c++/24569] [4.0/4.1 regression] ICE in add_AT_specification, at dwarf2out.c:4966
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-11-02 18:32 --- Subject: Bug 24569 Author: mmitchel Date: Wed Nov 2 18:32:09 2005 New Revision: 106393 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106393 Log: PR c++/24569 * pt.c (instantiate_decl): Use cp_finish_decl, not finish_static_data_member_decl. PR c++/24569 * g++.dg/debug/static1.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/debug/static1.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/pt.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24569
[Bug c++/24569] [4.0/4.1 regression] ICE in add_AT_specification, at dwarf2out.c:4966
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-11-02 18:36 --- Fixed in 4.0.3. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24569
[Bug middle-end/24639] New: [meta-bug] bug to track all uninit variable issues
To get a better feeling for the issues which have been reported, this meta-bug should get the better feeling for them. -- Summary: [meta-bug] bug to track all uninit variable issues Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: diagnostic, meta-bug Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org BugsThisDependsOn: 20644 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug middle-end/24639] [meta-bug] bug to track all uninit variable issues
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||5035, 10138, 16865, 17506, ||19371, 19430, 20968, 21513, ||21548, 21733, 21750, 22197, ||22207, 22456, 23497, 23563, ||23648, 24612 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-02 18:59:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug middle-end/24639] [meta-bug] bug to track all uninit variable issues
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-02 19:00 --- There are at least 19 bugs related to the uninit warnings. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |trivial http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug middle-end/24639] [meta-bug] bug to track all uninit variable issues
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-02 19:01 --- Adding Jeff Law and Diego so they know what the bug numbers are. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org, law at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug fortran/24640] New: ice with invalid label
$ cat test.f90 10: a=10 end $ gfortran test.f90 In file ice.f90:1 20:a=10 1 Warning: Ignoring bad statement label at (1) ice.f90: In function MAIN__: ice.f90:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. $ gfortran -v Using built-in specs. Target: powerpc64-linux Configured with: /home/gccbuild/gcc_trunk_anonsvn/trunk/configure --prefix=/opt/gcc-nightly/trunk-20051101 --build=powerpc64-linux --host=powerpc64-linux --target=powerpc64-linux --with-cpu=default32 --with-as=/opt/gcc-nightly/trunk-20051101/bin/as --with-ld=/opt/gcc-nightly/trunk-20051101/bin/ld --enable-threads=posix --enable-shared --enable-__cxa_atexit --enable-languages=c,c++,f95 --enable-checking --with-mpfr=/opt/gcc-nightly/trunk-20051101 Thread model: posix gcc version 4.1.0 20051101 (experimental) stack trace shows, Program received signal SIGSEGV, Segmentation fault. 0x1006fe18 in gfc_set_decl_location (decl=0x40298700, loc=0x1072fb44) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/trans-decl.c:226 226 DECL_SOURCE_LINE (decl) = loc-lb-linenum; (gdb) bt #0 0x1006fe18 in gfc_set_decl_location (decl=0x40298700, loc=0x1072fb44) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/trans-decl.c:226 #1 0x10071870 in gfc_get_label_decl (lp=0x1072fb30) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/trans-decl.c:256 #2 0x1008a188 in gfc_trans_label_here (code=Variable code is not available. ) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/trans-stmt.c:78 #3 0x1006360c in gfc_trans_code (code=0x1074aa18) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/trans.c:482 #4 0x1007527c in gfc_generate_function_code (ns=0x1074a120) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/trans-decl.c:2594 #5 0x22000482 in ?? () #6 0x10062cd4 in gfc_generate_code (ns=Variable ns is not available. ) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/trans.c:659 #7 0x100432c8 in gfc_parse_file () at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/parse.c:2680 #8 0x100624b4 in gfc_be_parse_file (set_yydebug=Variable set_yydebug is not available. ) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/fortran/f95-lang.c:286 #9 0x10336d6c in toplev_main (argc=Variable argc is not available. ) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/toplev.c:990 #10 0x1008e860 in main (argc=Variable argc is not available. ) at /home/gccbuild/gcc_trunk_anonsvn/trunk/gcc/main.c:35 -- Summary: ice with invalid label Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24640
[Bug middle-end/24639] [meta-bug] bug to track all uninit variable issues
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-02 19:17 --- Some more, this time closed ones. There are many more. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||179, 7258, 10538, 12792, ||13127, 13863, 14204, 16036, ||17518, 18232, 19833, 21005, ||21124 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug target/24621] [4.1 Regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:393
--- Comment #2 from janis at gcc dot gnu dot org 2005-11-02 19:18 --- A regression hunt using a cross compiler identified the following patch: r105306 | rth | 2005-10-12 16:29:35 + (Wed, 12 Oct 2005) | 3 lines PR rtl-opt/23324 * cfgexpand.c (add_alias_set_conflicts): Use objects_must_conflict_p. http://gcc.gnu.org/viewcvs?view=revrev=205306 Only the following options are needed to reproduce the failure with the reduced testcase: -O2. -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24621
[Bug fortran/24641] New: rejecting valid code
$ cat test_cmt.f90 program test_comments real :: a end program test_comments $ This is a valid code (i think) checked against Lahey's syntax checker, getting rejected by gfortran. $ gfortran test_cmt.f90 In file test_cmt.f90:2 real :: 1 Error: Syntax error in data declaration at (1) In file test_cmt.f90:4 a 1 Error: Unclassifiable statement at (1) $ gfortran -v is gcc version 4.1.0 20051101 (experimental) -- Summary: rejecting valid code Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24641
[Bug libgcj/24642] New: Failure to produce random values.
The following code should produce random numbers between 0..2^5-1:
import java.math.BigInteger;
import java.security.SecureRandom;
class RndTest {
public static void main(String[] args) {
SecureRandom rnd = new SecureRandom();
for (int i = 0; i 10; i++)
System.out.print(new BigInteger(5,rnd) + );
}
}
[EMAIL PROTECTED] junit]$ java -version
java version 1.4.2
gij (GNU libgcj) version 4.0.0 20050519 (Red Hat 4.0.0-8)
[EMAIL PROTECTED] src]$ java RndTest
0 31 12 21 21 16 8 24 15 20
[EMAIL PROTECTED] src]$ java RndTest
0 31 12 21 21 16 8 24 15 20
[EMAIL PROTECTED] src]$ java -Djava.security.egd=file:/dev/random RndTest
0 31 12 21 21 16 8 24 15 20
[EMAIL PROTECTED] ~]$ java -version
java version 1.4.2
gij (GNU libgcj) version 4.0.1 20050727 (Red Hat 4.0.1-5)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[EMAIL PROTECTED] ~]$ java RndTest
0 31 12 21 21 16 8 24 15 20
[EMAIL PROTECTED] ~]$ java RndTest
0 31 12 21 21 16 8 24 15 20
In addition the following fails (one would expect an 8):
import java.math.BigInteger;
import java.security.SecureRandom;
public class BigIntTest {
public static void main(String[] args) {
System.out.println(BigInteger.probablePrime(8,new
SecureRandom()).bitLength());
}
}
[EMAIL PROTECTED] junit]$ java -version
java version 1.4.2
gij (GNU libgcj) version 4.0.0 20050519 (Red Hat 4.0.0-8)
[EMAIL PROTECTED] ~]$ java BigIntTest
2
[EMAIL PROTECTED] ~]$ java BigIntTest
2
See also: http://forums.java.sun.com/thread.jspa?messageID=3960085
--
Summary: Failure to produce random values.
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: smythe70 at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24642
[Bug middle-end/24627] [4.1 Regression] xntp miscompiled
--- Comment #16 from dnovillo at gcc dot gnu dot org 2005-11-02 19:40 --- testing patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24627
[Bug classpath/24642] Failure to produce random values.
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-02 19:43 --- This is related to PR 24481. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||24481 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24642
[Bug middle-end/20644] bogus uninitialized warning on unused variable
--- Comment #4 from h dot b dot furuseth at usit dot uio dot no 2005-11-02 19:52 --- I think I'd appreciate that warning when writing portable code: The warning can be useful if the 1 is replaced with a macro which may or may not expand to 1, or an enum defined in an #ifdef, or an implementation-dependent expression like ((char)-1 0). But of course, it depends on how many false positives the warning tends to give for normal programs. Maybe there could be a warning option to turn on and off some warnings that do not apply with the particular #defines and constants being used. (And also turn on/off -Wunreachable for this case.) -- h dot b dot furuseth at usit dot uio dot no changed: What|Removed |Added CC||h dot b dot furuseth at usit ||dot uio dot no http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20644
[Bug c++/20021] warning behavior depends on textual format of literal constant
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-02 20:01 --- This does not warn for me on the mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20021
[Bug target/24620] [4.1 Regression] internal compiler error: in find_reloads, at reload.c:3730
--- Comment #2 from uweigand at gcc dot gnu dot org 2005-11-02 20:27 --- Clearly a backend bug. Working on it ... -- uweigand at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |uweigand at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-02 20:27:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24620
[Bug fortran/24643] New: Unclassifiable statement on character substring concatenation
gfortran issues an Unclassifiable statement error when trying to compile a statement with concatenation of substrings of character variables. -- Summary: Unclassifiable statement on character substring concatenation Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot indiv dot nluug dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24643
[Bug fortran/24643] Unclassifiable statement on character substring concatenation
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2005-11-02 20:36 --- Created an attachment (id=10114) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10114action=view) Test case for this bug Test case added. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24643
[Bug fortran/24643] Unclassifiable statement on character substring concatenation
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-02 20:39 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2005-11-02 20:39:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24643
[Bug c/24644] New: gcc-4.1 compiled ppc64 kernels do not boot
I do not have a reduced testcase, nor do I know what the real cuplprit is. kernel compiled with gcc-4_0-branch boot ok, but gcc-mainline fails to boot. Linux kernel 2.6.14, arch/ppc64/defconfig, do not boot on POWER5. They hang early in SMP init because a spinlock was unlocked twice. Enabling CONFIG_DEBUG_SPINLOCK and adding a few extra printk will show this: Linux version 2.6.14 ([EMAIL PROTECTED]) (gcc version 4.1.0 20051102 (experimental)) #61 SMP Wed Nov 2 19:47:05 UTC 2005 Memory: 495732k/524288k available (5004k kernel code, 27528k reserved, 1340k data, 2394k bss, 380k init) 374.78 BogoMIPS (lpj=749568) Mount-cache hash table entries: 256 softlockup thread 0 started up. Processor 1 found. Brought up 2 CPUs BUG: spinlock already unlocked on CPU#1, migration/1/5 c0 .schedule+0x3fc/0x870c1 .kthread+0xf0/0x170 lock: c000142a6100, .magic: dead4ead, .owner: swapper/1,c04dbc0c,c007b9c0 .owner_cpu: -1 Call Trace: [c0e33c30] [c021d2ec] .spin_bug+0xcc/0x150 (unreliable) [c0e33cc0] [c021d444] ._raw_spin_unlock+0xd4/0xe0 [c0e33d50] [c04ddfa4] ._spin_unlock_irq+0xa4/0xe0 [c0e33de0] [c04dbc0c] .schedule+0x3fc/0x870 [c0e33ee0] [c007b9c0] .kthread+0xf0/0x170 [c0e33f90] [c0010948] .kernel_thread+0x4c/0x68 kernel BUG in spin_bug at /home/olaf/kernel/olh/gcc41/linux-2.6.14-olh/lib/spinlock_debug.c:34! cpu 0x1: Vector: 700 (Program Check) at [c0e339b0] pc: c021d2f0: .spin_bug+0xd0/0x150 lr: c021d2ec: .spin_bug+0xcc/0x150 sp: c0e33c30 msr: 80021032 current = 0xcffd2040 paca= 0xc0619000 pid = 5, comm = migration/1 kernel BUG in spin_bug at /home/olaf/kernel/olh/gcc41/linux-2.6.14-olh/lib/spinlock_debug.c:34! enter ? for help 1:mon In this case, spinlock at c000142a6100 is used correctly in a schedule_tail() and schedule() call. Later, schedule() starts to use a spinlock at ..142ae100, then suddenly calls the unlock with ...142a6100. I currently do not know if the code in kernel/schedule.c is miscompiled, or if the breakage is somewhere else. If I replace the schedule.o with a gcc40 compiled version, things get further, but die later during kernel init due to wrong pointer dereferencing. Perhaps the object files generated with gcc-4_0-branch and gcc-mainline are somewhat incompatible. 7_spin_lock_irq(85) swapper(1):c0,j4294892318 l 13ff8f28 7_spin_unlock_irq(292) swapper(1):c0,j4294892318 l 13ff8f28 7_spin_lock_irq(85) swapper(1):c0,j4294892318 l 13ff8e90 7_spin_unlock_irq(292) swapper(1):c0,j4294892318 l 13ff8e90 7_spin_lock_irq(85) swapper(1):c0,j4294892318 l 00e17be8 7_spin_unlock_irq(292) swapper(1):c0,j4294892318 l 00e17be8 7_spin_lock_irq(85) swapper(1):c0,j4294892318 l 142a6100 7schedule_tail(1552) swapper(6):c0,j4294892318 c000142a6100 7_spin_unlock_irq(292) swapper(6):c0,j4294892318 l 142a6100 7_spin_lock_irq(85) swapper(6):c0,j4294892318 l 00e2c8d0 7_spin_unlock_irq(292) swapper(6):c0,j4294892318 l 00e2c8d0 7_spin_lock_irq(85) swapper(6):c0,j4294892318 l 142a6100 7schedule(3019) swapper(1):c0,j4294892318 c000142a6100 7_spin_unlock_irq(292) swapper(1):c0,j4294892318 l 142a6100 7_spin_lock_irq(85) swapper(1):c0,j4294892318 l 00e17be8 7_spin_unlock_irq(292) swapper(1):c0,j4294892318 l 00e17be8 7_spin_lock_irq(85) swapper(1):c0,j4294892318 l 00e17bf8 7_spin_unlock_irq(292) swapper(1):c0,j4294892318 l 00e17bf8 7_spin_lock_irq(85) swapper(1):c0,j4294892318 l 142a6100 7schedule_tail(1552) swapper(7):c0,j4294892318 c000142a6100 7_spin_unlock_irq(292) swapper(7):c0,j4294892318 l 142a6100 7_spin_lock_irq(85) swapper(7):c0,j4294892318 l 00e2f9e0 7_spin_unlock_irq(292) swapper(7):c0,j4294892318 l 00e2f9e0 7_spin_lock_irq(85) swapper(7):c0,j4294892318 l 142a6100 7schedule(3019) swapper(1):c0,j4294892318 c000142a6100 7_spin_unlock_irq(292) swapper(1):c0,j4294892318 l 142a6100 7_spin_lock_irq(85) swapper(1):c0,j4294892318 l 00e17bf8 7_spin_unlock_irq(292) swapper(1):c0,j4294892318 l 00e17bf8 4Processor 1 found. 7_spin_lock_irq(85) swapper(0):c1,j4294892318 l 142ae100 6Brought up 2 CPUs 7schedule(3019) swapper(1):c0,j4294892318 c000142a6100 7_spin_unlock_irq(292) migration/1(5):c1,j4294892318 l 142a6100 4BUG: spinlock already unlocked on CPU#1, migration/1/5 4c0 .schedule+0x3fc/0x870c1 .kthread+0xf0/0x170 lock: c000142a6100, .magic: dead4ead, .owner: swapper/1,c04dbc0c,c007b9c0 .owner_cpu: -1 4Call Trace: 4[c0e33c30] [c021d2ec] .spin_bug+0xcc/0x150 (unreliable) 4[c0e33cc0] [c021d444] ._raw_spin_unlock+0xd4/0xe0 4[c0e33d50] [c04ddfa4] ._spin_unlock_irq+0xa4/0xe0 4[c0e33de0] [c04dbc0c] .schedule+0x3fc/0x870 4[c0e33ee0] [c007b9c0] .kthread+0xf0/0x170 4[c0e33f90] [c0010948] .kernel_thread+0x4c/0x68 2kernel BUG in spin_bug at /home/olaf/kernel/olh/gcc41/linux-2.6.14-olh/lib/spinlock_debug.c:34! 1:mon
[Bug middle-end/24644] [4.1 Regression] gcc-4.1 compiled ppc64 kernels do not boot
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|c |middle-end Keywords||wrong-code Summary|gcc-4.1 compiled ppc64 |[4.1 Regression] gcc-4.1 |kernels do not boot |compiled ppc64 kernels do ||not boot Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24644
[Bug fortran/24643] Unclassifiable statement on character substring concatenation
--- Comment #3 from tobi at gcc dot gnu dot org 2005-11-02 20:42 --- [EMAIL PROTECTED]:~/src/gcc ../gcc/build/gcc/f951 -quiet -fsyntax-only Warning: Reading file 'stdin' as free form. PROGRAM TABLES IMPLICIT CHARACTER*8(Y) YBTABLE=Ylocal(1:2) END [EMAIL PROTECTED]:~/src/gcc ../gcc/build/gcc/f951 -quiet -fsyntax-only Warning: Reading file 'stdin' as free form. PROGRAM TABLES IMPLICIT CHARACTER*8(Y) WRITE(YLOCAL,'(I2.2)') ILOCAL YBTABLE=Ylocal(1:2) END In file :4 YBTABLE=Ylocal(1:2) 1 Error: Unclassifiable statement at (1) [EMAIL PROTECTED]:~/src/gcc ../gcc/build/gcc/f951 -quiet -fsyntax-only Warning: Reading file 'stdin' as free form. PROGRAM TABLES IMPLICIT CHARACTER*8(Y) ybtable='b' YBTABLE=Ylocal(1:2) END [EMAIL PROTECTED]:~/src/gcc ../gcc/build/gcc/f951 -quiet -fsyntax-only Warning: Reading file 'stdin' as free form. PROGRAM TABLES IMPLICIT CHARACTER*8(Y) WRITE(YLOCAL,'(I2.2)') ILOCAL ybtable='b' YBTABLE=Ylocal(1:2) END In file :5 YBTABLE=Ylocal(1:2) 1 Error: Unclassifiable statement at (1) [EMAIL PROTECTED]:~/src/gcc ../gcc/build/gcc/f951 -quiet -fsyntax-only Warning: Reading file 'stdin' as free form. PROGRAM TABLES IMPLICIT CHARACTER*8(Y) WRITE(YLOCAL,'(I2.2)') ILOCAL ybtable='b' YBTABLE=Ylocal END [EMAIL PROTECTED]:~/src/gcc -- 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=24643
[Bug libstdc++/24645] New: Commonize arithmetic inserters/extractors bodies
Especially now, after fixing a couple of correctness issues, it's obvious that all the arithmetic inserters/extractors share a common body which should be commonized to templatized _M_insert/_M_extract, in complete analogy with _M_insert_int/_M_extract_int, for example, in the num_put/num_get facets. -- Summary: Commonize arithmetic inserters/extractors bodies 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=24645
[Bug middle-end/24644] [4.1 Regression] gcc-4.1 compiled ppc64 kernels do not boot
--- Comment #1 from olh at suse dot de 2005-11-02 20:49 --- Created an attachment (id=10115) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10115action=view) PR24644.tar.bz2 buildscripts, preprocessed files, kernel .config and debug patches, bootlog. building with -O1 does not fix it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24644
[Bug fortran/18157] ice-on-valid code, pointer to user-defined type, fold-struct.c
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-11-02 21:01 --- Subject: Bug 18157 Author: pinskia Date: Wed Nov 2 21:01:54 2005 New Revision: 106396 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106396 Log: 2005-11-02 Andrew Pinski [EMAIL PROTECTED] PR fortran/18157 * gfortran.fortran-torture/compile/defined_type_1.f90: New test. * gfortran.fortran-torture/compile/defined_type_2.f90: New test. * gfortran.fortran-torture/compile/defined_type_3.f90: New test. 2005-11-02 Andrew Pinski [EMAIL PROTECTED] PR fortran/18157 * trans-array.c (gfc_conv_resolve_dependencies): Use the correct type for the temporary array. * trans-expr.c (gfc_trans_assignment): Pass lss instead of lss_section to gfc_conv_resolve_dependencies to get the correct type. Added: trunk/gcc/testsuite/gfortran.fortran-torture/compile/defined_type_1.f90 trunk/gcc/testsuite/gfortran.fortran-torture/compile/defined_type_2.f90 trunk/gcc/testsuite/gfortran.fortran-torture/compile/defined_type_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18157
[Bug c++/17964] [4.0/4.1 Regression] cpp error messages contain wrong line in C++
--- Comment #10 from mrs at apple dot com 2005-11-02 21:04 --- Radar 3843157 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17964
[Bug libfortran/24584] Segfault when reading empty string in namelist file
-- 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=24584
[Bug fortran/18157] ice-on-valid code, pointer to user-defined type, fold-struct.c
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-11-02 21:12 --- Subject: Bug 18157 Author: pinskia Date: Wed Nov 2 21:12:27 2005 New Revision: 106397 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106397 Log: 2005-11-02 Andrew Pinski [EMAIL PROTECTED] PR fortran/18157 * gfortran.fortran-torture/compile/defined_type_1.f90: New test. * gfortran.fortran-torture/compile/defined_type_2.f90: New test. * gfortran.fortran-torture/compile/defined_type_3.f90: New test. 2005-11-02 Andrew Pinski [EMAIL PROTECTED] PR fortran/18157 * trans-array.c (gfc_conv_resolve_dependencies): Use the correct type for the temporary array. * trans-expr.c (gfc_trans_assignment): Pass lss instead of lss_section to gfc_conv_resolve_dependencies to get the correct type. Added: branches/gcc-4_0-branch/gcc/testsuite/gfortran.fortran-torture/compile/defined_type_1.f90 - copied unchanged from r106396, trunk/gcc/testsuite/gfortran.fortran-torture/compile/defined_type_1.f90 branches/gcc-4_0-branch/gcc/testsuite/gfortran.fortran-torture/compile/defined_type_2.f90 - copied unchanged from r106396, trunk/gcc/testsuite/gfortran.fortran-torture/compile/defined_type_2.f90 branches/gcc-4_0-branch/gcc/testsuite/gfortran.fortran-torture/compile/defined_type_3.f90 - copied unchanged from r106396, trunk/gcc/testsuite/gfortran.fortran-torture/compile/defined_type_3.f90 Modified: branches/gcc-4_0-branch/gcc/fortran/ChangeLog branches/gcc-4_0-branch/gcc/fortran/trans-array.c branches/gcc-4_0-branch/gcc/fortran/trans-expr.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18157
[Bug fortran/18157] ice-on-valid code, pointer to user-defined type, fold-struct.c
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-02 21:12 --- Fixed in 4.0.3 and above, thanks for your report. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18157
[Bug fortran/24643] Unclassifiable statement on implicitly typed character substring
--- Comment #4 from tkoenig at gcc dot gnu dot org 2005-11-02 21:13 --- g77 groks this: $ cat grg.f PROGRAM TABLES IMPLICIT CHARACTER*8(Y) WRITE(YLOCAL,'(I2.2)') ILOCAL YBTABLE=Ylocal(1:2) END $ g77 grg.f $ -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||19292 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24643
[Bug fortran/15502] [meta-bug] bugs needed for SPEC CPU 2K and 2K5/6 and 95
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-02 21:13 --- Note there are still some more 2k5/6 SPEC blocking bugs which just had not been filed yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15502
[Bug fortran/23538] gfortran hangs on old cray fortran 66 program
--- Comment #7 from tkoenig at gcc dot gnu dot org 2005-11-02 21:17 --- g77 gets confused by the errors, then bails out: $ g77 d2ds.f $ g77 d2ds.f 21 | tail 2 Argument #4 of `maxval' is one type at (2) but is some other type at (1) [info -f g77 M GLOBALS] d2ds.f:831: warning: call maxval (0,0,sig,eps,ijk,valmax,locval,slab) 1 d2ds.f:1159: (continued): call maxval (1,0,sig,eps,ijk,valmax,locval,slab) 2 Argument #5 of `maxval' is one type at (2) but is some other type at (1) [info -f g77 M GLOBALS] d2ds.f:795: confused by earlier errors, bailing out -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||19292 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23538
[Bug fortran/23815] Add -byteswapio flag
--- Comment #10 from tkoenig at gcc dot gnu dot org 2005-11-02 21:20 --- (In reply to comment #9) I imagine code from g95 could be leveraged to support this feature couldn't it? Rather not. The libraries have diverged pretty much so it is probably easier to write this from scratch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23815
[Bug fortran/20867] statement function args not given implicit type early enough
--- Comment #1 from tkoenig at gcc dot gnu dot org 2005-11-02 21:24 --- $ cat foo.f REAL :: st1 st1(I)=I**2 ! I implicitly typed to integer REAL :: I END $ g77 foo.f foo.f: In program `MAIN__': foo.f:2: st1(I)=I**2 ! I implicitly typed to integer 1 foo.f:3: (continued): REAL :: I 2 Invalid declaration of or reference to symbol `i' at (2) [initially seen at (1)] -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||19292 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20867
[Bug fortran/24640] ice with invalid label
--- Comment #1 from tkoenig at gcc dot gnu dot org 2005-11-02 21:28 --- This is only in free-form: $ cat tst.f 10: a=10 end $ gfortran tst.f In file tst.f:1 10: a=10 1 Error: Non-numeric character in statement label at (1) Confirmed. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-02 21:28:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24640
[Bug c++/19253] [3.4/4.0/4.1 regression] bad error message / ICE for invalid template parameter
--- Comment #12 from mmitchel at gcc dot gnu dot org 2005-11-02 21:34 --- Subject: Bug 19253 Author: mmitchel Date: Wed Nov 2 21:34:51 2005 New Revision: 106398 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106398 Log: PR c++/19253 * parser.c (cp_parser_postfix_expression): Use cp_parser_elaborated_type_specifier to handle typename-types in functional casts. (cp_parser_enclosed_argument_list): Skip ahead to the end of the template argument list if the closing is not found. PR c++/19253 * g++.dg/parse/typename8.C: Compile with -w -fpermissive. * g++.dg/parse/typename9.C: New test. * g++/dg/parse/typename10.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/parse/typename10.C trunk/gcc/testsuite/g++.dg/parse/typename9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/parse/typename8.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19253
