[Bug middle-end/25636] cc1 and cc1plus --help core
--- Comment #2 from freddyz77 at tin dot it 2006-01-06 09:14 ---
Well, I don't know why but looking more deeply I still don't understand
$ gdb /opt/gcc42/libexec/gcc/i686-pc-linux-gnu/4.2.0/cc1
GNU gdb Red Hat Linux (6.3.0.0-1.84rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".
(gdb) r --help
Starting program: /opt/gcc42/libexec/gcc/i686-pc-linux-gnu/4.2.0/cc1 --help
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xb9f000
The following options are language-independent:
Program received signal SIGSEGV, Segmentation fault.
0x083580bd in print_filtered_help (flag=536870912) at ../.././gcc/opts.c:1301
1301 memset (printed, 0, cl_options_count);
(gdb) list
1296 if (flag == CL_COMMON || flag == CL_TARGET)
1297{
1298 filter = flag;
1299 if (!printed)
1300printed = xmalloc (cl_options_count);
1301 memset (printed, 0, cl_options_count);
1302}
1303 else
1304{
1305 /* Don't print COMMON options twice. */
(gdb) info registers
eax0x9aeb988162445704
ecx0x9aeb980162445696
edx0x0 0
ebx0x24e590
esp0xbfbaa5b0 0xbfbaa5b0
ebp0xbfbab9a0 0xbfbab9a0
esi0x0 0
edi0x2041 541065217
eip0x83580bd0x83580bd
eflags 0x10246 66118
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
(gdb) disas 0x83580bd
Dump of assembler code for function print_filtered_help:
0x08357f40 : push %ebp
0x08357f41 : push %edi
0x08357f42 : push %esi
0x08357f43 : push %ebx
...
0x083580aa : je 0x83581a5
0x083580b0 : mov0x85a641c,%ebx
0x083580b6 : mov0x85f5940,%eax
0x083580bb : xor%edx,%edx
0x083580bd : mov%ebx,0x85a641c
0x083580c3 : mov%ebx,0x8(%esp)
0x083580c7 : mov%edx,0x4(%esp)
0x083580cb : mov%eax,(%esp)
0x083580ce : call 0x8049afc
0x083580d3 : test %ebx,%ebx
0x083580d5 : je 0x8358081
0x083580d7 : mov0x10(%esp),%edx
0x083580db : mov%edx,0x14(%esp)
0x083580df : xor%esi,%esi
0x083580e1 : xor%ebx,%ebx
0x083580e3 : jmp0x83580f1
0x083580e5 : inc%esi
0x083580e6 : add$0x1c,%ebx
0x083580e9 : cmp0x85a641c,%esi
0x083580ef : je 0x8358081
0x083580f1 : mov0x85a642c(%ebx),%edx
0x083580f7 : mov0x14(%esp),%eax
...
0x0835814e : call 0x804955c
---Type to continue, or q to quit---q
Quit
(gdb) x/4b 0x85a641c
0x85a641c : 0x4e0x020x000x00
(gdb)
The program stop at memset so why this
mov%ebx,0x85a641c
should happen??? I cannot find any assigment to this variable however assembly
write into this variable...
freddy77
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636
[Bug target/25661] Wrong long double to float conversion
--- Comment #6 from amodra at bigpond dot net dot au 2006-01-06 09:31 --- In answer to comment #1, using just the upper double of the TFmode long double *is* rounding to double. As David says in #5, the upper double is the value of the long double rounded to double.. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25661
[Bug c++/25689] New: missed diagnostic about assignment used as truth value.
[ foo.cpp ]
struct Var {
operator int() const;
Var& operator = (int);
bool operator == (int);
};
bool operator == (int, Var&);
void foo(Var var)
{
if (var = 0); // if (var.operator=(0))
}
[ foo.cpp.t03.gimple ]
void foo(Var) (var)
{
bool retval.0;
struct Var & D.1768;
int D.1769;
D.1768 = operator= (&var, 0);
D.1769 = operator 1 (D.1768);
retval.0 = D.1769 != 0;
}
--
Summary: missed diagnostic about assignment used as truth value.
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC build triplet: i686-pld-linux
GCC host triplet: i686-pld-linux
GCC target triplet: i686-pld-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25689
[Bug c/25690] New: error: unrecognizable insn - failed to assign &a[1] if a is a struct
Source (test.c):
struct type {
char dummy;
} a[2];
void test( void ) {
struct type* b = &a[1];
}
compiler call:
mcore-gcc test.c -c
output:
test.c: In function 'test':
test.c:7: error: unrecognizable insn:
(insn 8 6 9 3 (set (reg:SI 25)
(const:SI (plus:SI (symbol_ref:SI ("a") )
(const_int 1 [0x1] -1 (nil)
(nil))
test.c:7: internal compiler error: in extract_insn, at recog.c:2084
--
Summary: error: unrecognizable insn - failed to assign &a[1] if a
is a struct
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: olaf at bonorden dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: mcore-be-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25690
[Bug c/25690] error: unrecognizable insn - failed to assign &a[1] if a is a struct
--- Comment #1 from olaf at bonorden dot de 2006-01-06 09:56 --- Don't know the exact version of gcc, i do a svn checkout yesterday. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25690
Bug
Hi,
I am not sure is this a bug or not !.
Here is my code, very simple
///
#include
int main ()
{
floata;
floatb;
int i;
a = 10.97;
b = 0.0;
for (i=0; i < 30; i++) {
b = b + a;
}
printf ("a = %f , b = %f", a, b);
return (0);
}
//
And the output :
a = 10.97 , b = 329.16
Why b is not just 329.1 ?
My gcc is gcc-3.4.4.
I tried both on DOS / DJGPP and Cygwin/WinXP
Any Idea or Solution ?
Regards
CC Vural
[Bug c++/25689] missed diagnostic about assignment used as truth value.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-06 12:32 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2006-01-06 12:32:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25689
[Bug c/25688] Unable to install GCC
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-06 12:34 --- This is current installation problem of your current GCC and binutils. Sounds like you don't have GNU binutils installed. This is not a GCC bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25688
[Bug fortran/25691] New: ICE on generic procedure
Segmentation fault when calling a generic procedure like call bilin_interpolate(x,y,ixp,iyp,wt_00,wt_01,wt_10,wt_11) for a interface like: interface bilin_interpolate module procedure bilin_interp_array module procedure bilin_interp_elem end interface with: subroutine bilin_interp_array(xp,yp,ixp,iyp) elemental subroutine bilin_interp_elem(xp,yp,ixp,iyp,wt_00,wt_01,wt_10,wt_11) the attached files should be compiled i.e. gfortran -c Function_ml.f90 gfortran -c Interpol_factors.f90 gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.0.2/configure --prefix=/disk1/local/gcc402 Thread model: posix gcc version 4.0.2 -- Summary: ICE on generic procedure Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Heiko dot Klein at gmx dot net GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25691
[Bug fortran/25691] ICE on generic procedure
--- Comment #1 from Heiko dot Klein at gmx dot net 2006-01-06 13:01 --- Created an attachment (id=10586) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10586&action=view) interface and implementation -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25691
[Bug fortran/25691] ICE on generic procedure
--- Comment #2 from Heiko dot Klein at gmx dot net 2006-01-06 13:02 --- Created an attachment (id=10587) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10587&action=view) usage of generic procedure calling of the (currently commented) procedure directly compiles without problems -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25691
[Bug libstdc++/25524] libstdc++ headers should go in multilib directories
--- Comment #6 from joseph at codesourcery dot com 2006-01-06 13:27 --- Subject: Re: libstdc++ headers should go in multilib directories On Fri, 6 Jan 2006, pcarlini at suse dot de wrote: > > Working on a fix. > > Many thanks. I was wondering whether you are aware of another (long standing) > multilib bug, libstdc++/20451, maybe fixable at the same time with a minor > additional effort?!? Thanks again. The bugs seem entirely independent. My proposed approach for the present bug can now be seen on csl-3_4_3-linux-branch, the mainline version will follow later. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25524
[Bug debug/24824] [4.1/4.2 Regression] ICE: in build_abbrev_table, at dwarf2out.c:6427 with -feliminate-dwarf2-dups
--- Comment #10 from nathan at gcc dot gnu dot org 2006-01-06 13:39 --- Created an attachment (id=10588) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10588&action=view) simplest test case This appears to be tickling a latent bug in the dwarf code. Before my patch I discover that the structure's dwarf information appears to be a child of comp_unit, whereas afterwards it's a child of a namespace. the latter seems correct to me -- I am investigating. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24824
[Bug fortran/22146] ICE when calling ELEMENTAL subroutines
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-06 13:40 --- *** Bug 25691 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||Heiko dot Klein at gmx dot ||net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22146
[Bug fortran/25691] ICE on generic procedure
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-06 13:40 --- This reduces to the testcase in PR 22146. *** This bug has been marked as a duplicate of 22146 *** -- 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=25691
[Bug fortran/25669] LBOUND (array), as actual arg,causes fatal error.
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-06 13:56 --- Confirmed (for now, unless you feel this is an exact dup of bug 18003). -- 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 |2006-01-06 13:56:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25669
[Bug java/25664] internal bug in compiler when assigning value to a static final field of java code
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-06 14:01 --- Can you attach the full code as I cannot reproduce this with the code you put into the comment as it just spits out errors. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25664
[Bug libgcj/25655] Implement signal chaining
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-06 14:01 --- I said 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 |2006-01-06 14:01:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25655
[Bug tree-optimization/25621] Missed optimization when unrolling the loop (splitting up the sum) (only with -ffast-math)
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-06 14:07 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-06 14:07:04 date|| Summary|Missed optimisation |Missed optimization when ||unrolling the loop ||(splitting up the sum) (only ||with -ffast-math) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25621
[Bug tree-optimization/25620] Missed optimization with power (only with -ffast-math)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-06 14:07 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-06 14:07:43 date|| Summary|Missed optimisation with|Missed optimization with |power |power (only with -ffast- ||math) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25620
[Bug rtl-optimization/25600] unsigned>>31?-1:0 should be optimized to int>>31
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-06 14:08 --- 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 |2006-01-06 14:08:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25600
[Bug c/25683] Error while running `make`
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25683
[Bug c/25692] New: Strange results with cast when using -O2 flag or not under Linux ppc64
Hello,
Here is a small sample to repeat the case:
#include
main()
{
double d1, *pd1;
char *c = (char*)&d1;
pd1 = &d1;
((int*)pd1)[0] = -1;
((int*)pd1)[1] = -1;
fprintf(stderr,">> d1 = %lf\n", d1);
fprintf(stderr,">> int: %d %d\n", ((int*)pd1)[0], ((int*)pd1)[1]);
fprintf(stderr,">> c1 = %02x\n", c[0]);
fprintf(stderr,">> c2 = %02x\n", c[1]);
fprintf(stderr,">> c3 = %02x\n", c[2]);
fprintf(stderr,">> c4 = %02x\n", c[3]);
fprintf(stderr,">> c5 = %02x\n", c[4]);
fprintf(stderr,">> c6 = %02x\n", c[5]);
fprintf(stderr,">> c7 = %02x\n", c[6]);
fprintf(stderr,">> c8 = %02x\n", c[7]);
}
When I compile with `gcc -m64 -o b64 b64.c`, the output is correct:
>> d1 = nan
>> int: -1 -1
>> c1 = ff
>> c2 = ff
>> c3 = ff
>> c4 = ff
>> c5 = ff
>> c6 = ff
>> c7 = ff
>> c8 = ff
But when I use the optimise flag, `gcc -O2 -m64 -o b64 b64.c`, and run again
the sample, there is a problem with the results. See bellow:
>> d1 = 0.00
>> int: -1 -1
>> c1 = ff
>> c2 = ff
>> c3 = ff
>> c4 = ff
>> c5 = ff
>> c6 = ff
>> c7 = ff
>> c8 = ff
Gcc release:
Using built-in specs.
Target: ppc64-redhat-linux
Configured with: ../gcc-4.0.0/configure --prefix=/home/comp/gcctest4.0.0
--enable-shared --enable-threads=posix --disable-checking --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --host=ppc64-redhat-linux
--build=ppc64-redhat-linux --target=ppc64-redhat-linux --with-cpu=default32
--enable-languages=c,c++
Thread model: posix
gcc version 4.0.0
Environment:
Linux 2.6.9-11.EL #1 SMP Fri May 20 18:18:48 EDT 2005 ppc64 ppc64 ppc64
GNU/Linux
Best regards.
--
Summary: Strange results with cast when using -O2 flag or not
under Linux ppc64
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fm at 4js dot com
GCC build triplet: powerpc64-linux RedHat 4.0
GCC host triplet: powerpc64-ibm
GCC target triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25692
[Bug c/25692] Strange results with cast when using -O2 flag or not under Linux ppc64
--- Comment #1 from fm at 4js dot com 2006-01-06 14:19 --- Created an attachment (id=10589) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10589&action=view) Small sample to illustrate the problem How to repeat sample -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25692
[Bug c/25692] Strange results with cast when using -O2 flag or not under Linux ppc64
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-06 14:20 --- You are violating C aliasing rules as you acess d1 via an int. *** This bug has been marked as a duplicate of 21920 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Summary|Strange results with cast |Strange results with cast |when using -O2 flag or not |when using -O2 flag or not |under Linux ppc64 |under Linux ppc64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25692
[Bug c/21920] alias violating
--- Comment #81 from pinskia at gcc dot gnu dot org 2006-01-06 14:20 --- *** Bug 25692 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||fm at 4js dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug c/25692] Strange results with cast when using -O2 flag or not under Linux ppc64
--- Comment #3 from fm at 4js dot com 2006-01-06 14:46 --- Maybe... But I made some tests under Linux X86 and some AIX 64 bits. This code works as expected everywhere... So, I wonder why gcc behaviour is différent under this Linux PPC64 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25692
[Bug libfortran/21468] vectorizing libfortran
--- Comment #9 from jb at gcc dot gnu dot org 2006-01-06 14:47 --- Reopening since many of the intrinsics could still vectorize better. -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21468
[Bug c/25692] Strange results with cast when using -O2 flag or not under Linux ppc64
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-06 14:53 --- (In reply to comment #3) > Maybe... > > But I made some tests under Linux X86 and some AIX 64 bits. This code works as > expected everywhere... > So, I wonder why gcc behaviour is différent under this Linux PPC64 ? Because PPC 64 schedules code more aggressively. Anyways the code is undefined so anything can happen. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25692
[Bug fortran/25693] New: Missleading line number for 'unused variable' warnings
The line number given in warning messages for unused variables in a procedure with an internal procedure, is that of the first line of the internal procedure, instead of the host procedure. I find this a bit confusing: erik:~$ cat -n swap.f90 1 subroutine sort() 2 real :: a 3 4 contains 5 6 subroutine swap() 7 end subroutine swap 8 9 end subroutine sort erik:~$ gfortran -Wall -c swap.f90 swap.f90: In function 'sort': swap.f90:6: warning: unused variable 'a' (The optimal thing would of course be to give the line where the variable was declared, but since a variable can have several declarations (e.g. one for type and a separate one for dimension), this is not allways possible.) -- Summary: Missleading line number for 'unused variable' warnings Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: diagnostic Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: eedelman at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25693
[Bug tree-optimization/25528] missed LIM on the tree level (complex types)
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-06 15:00 --- Subject: Bug 25528 Author: pinskia Date: Fri Jan 6 15:00:50 2006 New Revision: 109419 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109419 Log: 2006-01-06 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/25528 * tree-ssa-alias.c (find_used_portions): Handle REALPART_EXPR and IMAGPART_EXPR. * tree-flow-inline.h (var_can_have_subvars): Handle complex types on non gimple variables. Also add checks at the top for decls and mtags. * tree-ssa-structalias.c (push_fields_onto_fieldstack): Handle complex types. * tree-ssa-operands.c (parse_ssa_operands): Handle REALPART_EXPR and IMAGPART_EXPR for creating MUST_DEFs. (get_expr_operands): Handle SSA_NAME, STRUCT_FIELD_TAG, TYPE_MEMORY_TAG, and NAME_MEMORY_TAG separately from the DECLs. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-flow-inline.h trunk/gcc/tree-ssa-alias.c trunk/gcc/tree-ssa-operands.c trunk/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25528
[Bug tree-optimization/25528] missed LIM on the tree level (complex types)
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-06 15:01 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25528
[Bug fortran/25693] Missleading line number for 'unused variable' warnings
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-06 15:01 --- IIRC the issue is using warning instead of gfc_warning. There is another bug like this filed for arguments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25693
[Bug fortran/21918] Warnings about unused variables should point to the declaration
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-06 15:02 --- *** Bug 25693 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||eedelman at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21918
[Bug fortran/25693] Missleading line number for 'unused variable' warnings
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-06 15:02 --- Actually the bug is for both, This is a dup of bug 21918. *** This bug has been marked as a duplicate of 21918 *** -- 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=25693
[Bug libstdc++/25524] libstdc++ headers should go in multilib directories
--- Comment #7 from pcarlini at suse dot de 2006-01-06 15:12 --- (In reply to comment #6) > The bugs seem entirely independent. Ok, too bad ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25524
[Bug target/25690] error: unrecognizable insn - failed to assign &a[1] if a is a struct
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25690
[Bug other/25694] New: selective non-bootstrap build broken
Building a non-bootstrap native gcc with selected target libraries doesn't work anymore. on an i686-pc-linux-gnu host in a directory parallel to a unified symlink tree in ../srcw , I configured with: ../srcw/configure --with-arch=i686 and then started make with: make all-gcc all-target-libstdc++-v3 all-target-libobjc make built libiberty, then proceeded configuring gcc, but failed with: Using ggc-page for garbage collection. checking whether to enable maintainer-specific portions of Makefiles... no Links are now set up to build a native compiler for i686-pc-linux-gnu. updating cache ./config.cache configure: creating ./config.status config.status: creating Makefile config.status: creating gccbug config.status: creating mklibgcc config.status: creating libada-mk config.status: creating auto-host.h config.status: executing default commands cat: stage_last: No such file or directory make: invalid option -- a Usage: make [options] [target] ... Options: -b, -m Ignored for compatibility. -C DIRECTORY, --directory=DIRECTORY Change to DIRECTORY before doing anything. -d Print lots of debugging information. --debug[=FLAGS] Print various types of debugging information. -e, --environment-overrides Environment variables override makefiles. -f FILE, --file=FILE, --makefile=FILE Read FILE as a makefile. -h, --help Print this message and exit. -i, --ignore-errors Ignore errors from commands. -I DIRECTORY, --include-dir=DIRECTORY Search DIRECTORY for included makefiles. -j [N], --jobs[=N] Allow N jobs at once; infinite jobs with no arg. -k, --keep-goingKeep going when some targets can't be made. -l [N], --load-average[=N], --max-load[=N] Don't start multiple jobs unless load is below N. -n, --just-print, --dry-run, --recon Don't actually run any commands; just print them. -o FILE, --old-file=FILE, --assume-old=FILE Consider FILE to be very old and don't remake it. -p, --print-data-base Print make's internal database. -q, --question Run no commands; exit status says if up to date. -r, --no-builtin-rules Disable the built-in implicit rules. -R, --no-builtin-variables Disable the built-in variable settings. -s, --silent, --quiet Don't echo commands. -S, --no-keep-going, --stop Turns off -k. -t, --touch Touch targets instead of remaking them. -v, --version Print the version number of make and exit. -w, --print-directory Print the current directory. --no-print-directoryTurn off -w, even if it was turned on implicitly. -W FILE, --what-if=FILE, --new-file=FILE, --assume-new=FILE Consider FILE to be infinitely new. --warn-undefined-variables Warn when an undefined variable is referenced. Report bugs to . make: *** [configure-build-libiberty] Error 2 -- Summary: selective non-bootstrap build broken Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25694
[Bug other/25694] selective non-bootstrap build broken
--- Comment #1 from drow at gcc dot gnu dot org 2006-01-06 16:35 --- Subject: Re: New: selective non-bootstrap build broken On Fri, Jan 06, 2006 at 04:27:16PM -, amylaar at gcc dot gnu dot org wrote: > Building a non-bootstrap native gcc with selected target libraries > doesn't work anymore. > > on an i686-pc-linux-gnu host in a directory parallel to a unified symlink tree > in ../srcw , I configured with: > > ../srcw/configure --with-arch=i686 > > and then started make with: > > make all-gcc all-target-libstdc++-v3 all-target-libobjc For now try this plus --disable-bootstrap. This is trying to build stage 1. Obviously we need to reconsider the --enable/--disable switch since it's generating so many complaints. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25694
[Bug bootstrap/25695] New: [4.2 Regression] bootstrap no longer does a comparision
We no longer (after toplevel bootstrap) do a comparision between stage2 and stage3. -- Summary: [4.2 Regression] bootstrap no longer does a comparision Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25695
[Bug bootstrap/25695] [4.2 Regression] bootstrap no longer does a comparision
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-06 16:39 --- Oh, I should say we invoke make compare in the gcc directory but that does nothing since it has no idea it was invoked using toplevel bootstrap. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25695
[Bug fortran/25691] ICE on generic procedure
--- Comment #4 from Heiko dot Klein at gmx dot net 2006-01-06 17:07 --- I doubt that it has anything to do with PR 22146. PR 22146 is about elemental, and I get the same ICE when removing the elemental keyword. I don't get the ICE when calling the elemental subroutine directly. (See commented line in Interpol_factors.f90) Heiko (In reply to comment #3) > This reduces to the testcase in PR 22146. > > *** This bug has been marked as a duplicate of 22146 *** > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25691
[Bug other/25694] selective non-bootstrap build broken
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-01-06 17:27 --- The toplevel makefile has a target 'all' which allegedly does a native non-bootstrap build. However, that still does a multi-stage build, thus building everything that is intended to be debugged with a compiler that isn't trusted to generate correct code, and will most of the time emit debug information that the (presumably stable) system gdb won't understand. A true one-stage buld is essential for reliable debugging. And for reasonable turn-around times during bug fixing, it is also important that you can cd to the gcc directory and re-build cc1 using 'make cc1', and this will only rebuild files where the sources are changed, or the .o files have been removed by hand (I often do that in order to remove optimization for a module under investigation). I don't mind adding --disable-bootstrap to my configure lines; however, the toplevel bootstrap documentation in the wiki seems to imply that this option has been removed or is intended for removal before the 4.2 release. I would consider the removal of this option without another way to get the functionality a showstopper. There is also the issue that the target 'all-gcc' exists in Makefiles generated without --disable-bootstrap, but it doesn't work, and this failure is only apparent after a considerable time building and configuring sources has passed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25694
[Bug libfortran/25697] New: libfortran - Segmentation fault/ Bad Address on unformatted read
On the Macintosh this program gives a "Segmentation fault" on Linux it gives "Fortran runtime error: Bad address" dranta:~/tests/gfortran-D] dir% gfortran -o write19 write19.f [dranta:~/tests/gfortran-D] dir% write19 Segmentation fault [dranta:~/tests/gfortran-D] dir% cat write19.f integer data(500) do i = 1,500 data(i)=-1 enddo open(unit=11,status='scratch',form='unformatted') read(11,end=1000 )data 1000 continue backspace 11 write(11)data read(11,end=1001 )data 1001 continue backspace 11 backspace 11 write(11)data rewind 11 backspace 11 read(11,end=1002 )data 1002 continue read(11,end=1003 )data 1003 continue close(11) end dranta:~/tests/gfortran-D] dir% gfortran --v Using built-in specs. Target: powerpc-apple-darwin8.3.0 Configured with: ../gcc/configure --prefix=/Users/dir/gfortran --enable-languages=c,f95 Thread model: posix gcc version 4.2.0 20060106 (experimental) [dranta:~/tests/gfortran-D] dir% -- Summary: libfortran - Segmentation fault/ Bad Address on unformatted read Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lanl dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25697
[Bug java/25664] [3.4/4.0/4.1/4.2 Regression] internal bug in compiler when assigning value to a static final field of java code
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-06 18:49 ---
Reduced testcase:
class bugfinal {
static final int a=0;
void method() {
a++;
}
}
This code is invalid.
Anyways confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Keywords||ice-on-invalid-code
Known to fail||3.4.4 3.4.5 4.0.0 4.1.0
||4.2.0 3.3.3 3.2.3
Known to work||3.0.4
Last reconfirmed|-00-00 00:00:00 |2006-01-06 18:49:41
date||
Summary|internal bug in compiler|[3.4/4.0/4.1/4.2 Regression]
|when assigning value to a |internal bug in compiler
|static final field of java |when assigning value to a
|code|static final field of java
||code
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25664
[Bug target/25662] [4.0/4.1 Regression] Unrecognizable insn with -O on PPC
--- Comment #3 from ian at airs dot com 2006-01-06 19:05 --- I think this is a bug in simplify_expand_binop (adding Richard Sandiford to the CC since he introduced that function). Currently when simplify_expand_binop is given two constants, it calls simplify_gen_binary. When the operation does not simplify, that will wind up returning RTL which may not satisfy the instruction predicates. I think it should call simplify_binary_operation instead. If that fails, it should call expand_binop as usual. I will attach a sample, untested, patch. -- ian at airs dot com changed: What|Removed |Added CC||richard at codesourcery dot ||com, ian at airs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25662
[Bug target/25662] [4.0/4.1 Regression] Unrecognizable insn with -O on PPC
--- Comment #4 from ian at airs dot com 2006-01-06 19:06 --- Created an attachment (id=10590) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10590&action=view) Sample untested patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25662
[Bug java/25676] Use of MIN_EXPR/MAX_EXPR is wrong for java
-- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-06 19:17:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25676
[Bug other/25698] New: installation fails
I have a SuSe-9.1Pro with gcc-3.3.3 installed. I downloaded/extracted a copy of
gcc-4.0.2.tar.bz2 on my HD. Then, I created an empty directory under the
gcc-4.0.2 directory tree and name it objdir. After entering the objdir
directory, I configured gcc for a compilation as follows:
+
../configure --prefix=/usr --enable-threads=posix
--with-gxx-include-dir=='${prefix}/include/g++' --enable-bootstrap ; make
bootstrap > & /usr/tmp/world
+
Then, I executed "make bootstrap" and successfully compiled the gcc-4.0.2. When
I tried to install (make DESTDIR=/usr/tmp/gcc-4.0.2-1-root install) the
compiled gcc to a temporarily directory for RPM packaging purposes, I got the
following error messages:
+
/bin/sh ../mkinstalldirs /usr/tmp/gcc-4.0.2-1-root/usr
/usr/tmp/gcc-4.0.2-1-root/usr
make[1]: Entering directory `/usr/src/packages/BUILD/gcc-4.0.2/objdir/fastjar'
make[1]: *** No rule to make target `../zlib/libz.a', needed by `fastjar'.
Stop.
make[1]: Leaving directory `/usr/src/packages/BUILD/gcc-4.0.2/objdir/fastjar'
make: *** [install-fastjar] Error 2
+
The installation process seems to expect all built libraries under their
respective source directories.
--
Summary: installation fails
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mazilo at msn dot com
GCC build triplet: i586-suse-linux
GCC host triplet: i586-suse-linux
GCC target triplet: i586-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25698
[Bug target/23731] [4.1/4.2 regression] [hppa] 475 test failures in libjava
--- Comment #5 from tromey at gcc dot gnu dot org 2006-01-06 19:34 --- What is the status of this? It looks like Bug 24348 might be fixed. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23731
[Bug java/24441] [4.1/4.2 regression] ICE's when building the ecj compiler 3.1.1
--- Comment #8 from tromey at gcc dot gnu dot org 2006-01-06 19:39 --- The fix was checked in a while ago. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24441
[Bug fortran/25101] [4.1] Zero stride allowed in FORALL:s
--- Comment #6 from kargl at gcc dot gnu dot org 2006-01-06 20:04 --- Subject: Bug 25101 Author: kargl Date: Fri Jan 6 20:04:15 2006 New Revision: 109425 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109425 Log: 2006-01-06 Steven G. Kargl <[EMAIL PROTECTED]> PR fortran/25101 * resolve.c (resolve_forall_iterators): Check for scalar variables; Check stride is nonzero. PR fortran/24640 * parse.c (next_free): Check for whitespace after the label. * match.c (gfc_match_small_literal_int): Initialize cnt variable. PR fortran/25101 * gfortran.dg/forall_2.f90: New test. PR fortran/24640 * gfortran.dg/label_2.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/forall_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/label_2.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/match.c branches/gcc-4_1-branch/gcc/fortran/parse.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25101
[Bug fortran/24640] [4.1] ice with invalid label
--- Comment #7 from kargl at gcc dot gnu dot org 2006-01-06 20:04 --- Subject: Bug 24640 Author: kargl Date: Fri Jan 6 20:04:15 2006 New Revision: 109425 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109425 Log: 2006-01-06 Steven G. Kargl <[EMAIL PROTECTED]> PR fortran/25101 * resolve.c (resolve_forall_iterators): Check for scalar variables; Check stride is nonzero. PR fortran/24640 * parse.c (next_free): Check for whitespace after the label. * match.c (gfc_match_small_literal_int): Initialize cnt variable. PR fortran/25101 * gfortran.dg/forall_2.f90: New test. PR fortran/24640 * gfortran.dg/label_2.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/forall_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/label_2.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/match.c branches/gcc-4_1-branch/gcc/fortran/parse.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24640
[Bug fortran/24640] [4.1] ice with invalid label
--- Comment #8 from kargl at gcc dot gnu dot org 2006-01-06 20:06 --- Fixed on 4.1, too. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24640
[Bug fortran/25101] [4.1] Zero stride allowed in FORALL:s
--- Comment #7 from kargl at gcc dot gnu dot org 2006-01-06 20:07 --- Fixed on 4.1, too. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25101
[Bug libfortran/25697] libfortran - Segmentation fault/ Bad Address on unformatted read
--- Comment #1 from dir at lanl dot gov 2006-01-06 20:11 --- Here is a shorter one that also crashes on the Macintosh - [dranta:~/tests/gfortran-D] dir% gfortran -o write20 write20.f [dranta:~/tests/gfortran-D] dir% write20 Segmentation fault [dranta:~/tests/gfortran-D] dir% cat write20.f integer data(500) do i = 1,500 data(i)=-1 enddo open(unit=11,status='scratch',form='unformatted') write(11)data read(11,end=1000 )data 1000 continue backspace 11 backspace 11 write(11)data rewind 11 read(11,end=1001 )data 1001 continue read(11,end=1002 )data 1002 continue close(11) end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25697
[Bug libgcj/23499] [4.1/4.2 regression] libgcj/classpath create empty directory $PREFIX/share/classpath/api/
--- Comment #9 from tromey at gcc dot gnu dot org 2006-01-06 20:12 --- Subject: Bug 23499 Author: tromey Date: Fri Jan 6 20:12:22 2006 New Revision: 109426 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109426 Log: PR libgcj/23499: * lib/Makefile.in: Rebuilt. * lib/Makefile.am (glibj_DATA): Commented out. Modified: trunk/libjava/classpath/ChangeLog.gcj trunk/libjava/classpath/lib/Makefile.am trunk/libjava/classpath/lib/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23499
[Bug target/25662] [4.0/4.1 Regression] Unrecognizable insn with -O on PPC
--- Comment #5 from dje at gcc dot gnu dot org 2006-01-06 20:18 --- The patched compiler does build and does fix the testcase. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-06 20:18:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25662
[Bug tree-optimization/18527] cannot determine number of iterations for loops with <=
--- Comment #9 from rakdver at gcc dot gnu dot org 2006-01-06 20:23 --- Subject: Bug 18527 Author: rakdver Date: Fri Jan 6 20:22:56 2006 New Revision: 109427 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109427 Log: PR tree-optimization/18527 * tree-ssa-loop-niter.c (number_of_iterations_cond, number_of_iterations_special, number_of_iterations_exit): Move base and step of an iv to a single structure. Add no_overflow flag, and use it in # of iterations analysis. * tree-scalar-evolution.c (analyze_scalar_evolution_in_loop): Add folded_casts argument. (simple_iv): Pass base and step in a structure. Set no_overflow flag. (scev_const_prop): Add argument to analyze_scalar_evolution_in_loop. Evaluate expensiveness of computing # of iterations instead of the final expression. * tree-scalar-evolution.h (affine_iv): New structure. (simple_iv): Declaration changed. * tree-chrec.c (chrec_apply): Handle chrecs containing symbols. * tree-ssa-loop-ivopts.c (determine_biv_step, find_givs_in_stmt_scev, find_givs_in_stmt): Changed due to simple_iv change. * gcc.dg/tree-ssa/loop-15.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-15.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-chrec.c trunk/gcc/tree-scalar-evolution.c trunk/gcc/tree-scalar-evolution.h trunk/gcc/tree-ssa-loop-ivopts.c trunk/gcc/tree-ssa-loop-niter.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18527
[Bug libgcj/23499] [4.1/4.2 regression] libgcj/classpath create empty directory $PREFIX/share/classpath/api/
--- Comment #10 from tromey at gcc dot gnu dot org 2006-01-06 20:26 --- Subject: Bug 23499 Author: tromey Date: Fri Jan 6 20:26:52 2006 New Revision: 109428 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109428 Log: PR libgcj/23499: * lib/Makefile.in: Rebuilt. * lib/Makefile.am (glibj_DATA): Commented out. Modified: branches/gcc-4_1-branch/libjava/classpath/ChangeLog.gcj branches/gcc-4_1-branch/libjava/classpath/lib/Makefile.am branches/gcc-4_1-branch/libjava/classpath/lib/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23499
[Bug target/24348] [4.1/4.2 regression] bootstrap failure building libgcc
--- Comment #6 from debian-gcc at lists dot debian dot org 2006-01-06 20:27 --- (In reply to comment #5) > Is this fixed? yes, according to http://lists.debian.org/debian-gcc/2005/12/msg00220.html Matthias -- debian-gcc at lists dot debian dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24348
[Bug target/23731] [4.1/4.2 regression] [hppa] 475 test failures in libjava
--- Comment #6 from debian-gcc at lists dot debian dot org 2006-01-06 20:28 --- (In reply to comment #5) > What is the status of this? > It looks like Bug 24348 might be fixed. correct, the patch for 24348 is checked in. Matthias -- debian-gcc at lists dot debian dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23731
[Bug libgcj/23499] [4.1/4.2 regression] libgcj/classpath create empty directory $PREFIX/share/classpath/api/
--- Comment #11 from tromey at gcc dot gnu dot org 2006-01-06 20:30 --- Fix checked in. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23499
[Bug target/25662] [4.0/4.1 Regression] Unrecognizable insn with -O on PPC
--- Comment #6 from halcy0n at gentoo dot org 2006-01-06 20:54 --- I can confirm it fixes it on my box as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25662
[Bug java/25700] New: gcj manual missing option index
The gcj manual does not have an option index. Also many concepts and functions are not indexed at all. -- Summary: gcj manual missing option index Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25700
[Bug c++/25701] New: gcc.texi missing @direntry for g++
If you go to the top-level info node, you will see that there is no direct menu entry for the "g++" command. I think we should have one, which means adding an @direntry for it. (See gcc/java/gcj.texi for an example of per-command @direntry use) More generally I think we should have an @direntry for each program we install in $bindir. I haven't looked to see what other ones might be missing. -- Summary: gcc.texi missing @direntry for g++ Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25701
[Bug c/25702] New: feature request: generate a warning for sizeof on a pointer
One common mistake in C is to do sizeof(x) where x is a pointer and
what was really wanted was sizeof(*x). Similar to requiring
parentheses around assignments in conditionals, I'd like an optional
warning to be added when sizeof is done on a variable that is a
pointer. For example, in the code below, the first sizeof would
give a warning. To prevent this warning, sizeof(char *) can be
used instead.
void fu (void)
{
char *x;
printf(" x %d\n", sizeof(x));
printf("char * %d\n", sizeof(char *));
printf("char * %d\n", sizeof("hello world"));
}
I've done a proof of concept for gcc 3.3 as below. I haven't done
extensive testing and I didn't make the warning optional.
*** c-parse.y 2005/12/05 22:19:42 1.1
--- c-parse.y 2005/12/05 22:54:43
***
*** 494,502
--- 494,506
if (TREE_CODE ($2) == COMPONENT_REF
&& DECL_C_BIT_FIELD (TREE_OPERAND ($2, 1)))
error ("`sizeof' applied to a bit-field");
+ warning("`sizeof' reference #1");
+ if (TREE_CODE (TREE_TYPE ($2)) == POINTER_TYPE)
+ warning("`sizeof' applied to a pointer variable");
$$ = c_sizeof (TREE_TYPE ($2)); }
| sizeof '(' typename ')' %prec HYPERUNARY
{ skip_evaluation--;
+ warning("`sizeof' reference #2");
$$ = c_sizeof (groktypename ($3)); }
| alignof unary_expr %prec UNARY
{ skip_evaluation--;
--
Summary: feature request: generate a warning for sizeof on a
pointer
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: meklund at cisco dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25702
[Bug ada/25703] New: ACATS FAIL cxa4024 Ada.Strings.Maps on x86-linux
Last time it passed (before PR24994): LAST_UPDATED: Sun Dec 11 12:10:30 UTC 2005 (revision 108381M) Now that Ada bootstraps again, it fails: ,.,. CXA4024 ACATS 2.5 06-01-06 22:31:19 CXA4024 Check that the function "-", To_Ranges, To_Domain, and To_Range are available in the package Ada.Strings.Maps, and that they produce correct results. * CXA4024 Incorrect structure or components in Character_Ranges constant. CXA4024 FAILED . Note: it passes on x86_64. -- Summary: ACATS FAIL cxa4024 Ada.Strings.Maps on x86-linux Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25703
[Bug c/25702] feature request: generate a warning for sizeof on a pointer
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-06 22:12 --- Actually people use sizeof(x) all the time to mean the correct thing, for an example: memcpy(&x, y, sizeof(x)); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25702
[Bug ada/24290] [4.1/4.2 Regression] ACATS ICE c64104c
--- Comment #1 from laurent at guerby dot net 2006-01-06 22:15 --- Now passing on both 4.1 and 4.2 as of LAST_UPDATED: Fri Jan 6 18:54:39 UTC 2006 (revision 109421) (it has been working for a while) -- laurent at guerby dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24290
[Bug ada/24356] Unable to build gnatmake
--- Comment #3 from laurent at guerby dot net 2006-01-06 22:18 --- Is 4.1 or 4.2 building there now? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24356
[Bug ada/24468] link failure for several acats tests
--- Comment #5 from laurent at guerby dot net 2006-01-06 22:19 --- Is 4.1 or 4.2 working there? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24468
[Bug c/25702] feature request: generate a warning for sizeof on a pointer
--- Comment #2 from meklund at cisco dot com 2006-01-06 22:24 ---
Subject: Re: feature request: generate a warning for sizeof on a pointer
On Fri, Jan 06, 2006 at 10:12:55PM -, pinskia at gcc dot gnu dot org wrote:
> Actually people use sizeof(x) all the time to mean the correct thing, for an
> example: memcpy(&x, y, sizeof(x));
True, and that is why I'd like to make it an optional warning. People
would be up in arms if it weren't optional. But, for people that want
to avoid this easily missed problem, they could live with
memcpy(&x, y, sizeof(xtype *))
I have seen one instance where people would consider it annoying:
char *m[] = { "this", "is", "bothersome", "to", "some" };
int m_items = sizeof(m) / sizeof(*m);
but once again, the avoidance of having unexpectedly short lengths
would override the annoyance for many.
How about I apply my patch and do a large build like BSD "make world"
and come back with a listing of how prevalent the above is?
--mark
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25702
[Bug ada/24356] Unable to build gnatmake
--- Comment #4 from bugzilla-gcc at thewrittenword dot com 2006-01-06 22:32 --- (In reply to comment #3) > Is 4.1 or 4.2 building there now? Dunno. Will try and find some time to build 4.1 soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24356
[Bug ada/24356] Unable to build gnatmake
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-06 23:04 --- Subject: Re: Unable to build gnatmake > --- Comment #3 from laurent at guerby dot net 2006-01-06 22:18 --- > Is 4.1 or 4.2 building there now? I see HP has a new libcl patch: PHSS_33903 - s700_800 11.23 LIBCL patch HP-UX series 700 11.X patch digest,HP-UX series 800 11.X patch digest HP-UX,UNIX 2005/12/22 s700_800 11.23 LIBCL patch Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24356
[Bug ada/24356] Unable to build gnatmake
--- Comment #6 from bugzilla-gcc at thewrittenword dot com 2006-01-06 23:18 --- (In reply to comment #5) > I see HP has a new libcl patch: > > PHSS_33903 - s700_800 11.23 LIBCL patch > > HP-UX series 700 11.X patch digest,HP-UX series 800 11.X patch digest > HP-UX,UNIX 2005/12/22 s700_800 11.23 LIBCL patch The list of changes relative to our current version PHSS_33405: JAGaf80041: Applications built with -Wl,-a,archive -z i result in a run time core dump JAGaf77560: f90 application aborting when trying to write shared common data to stdout So, I don't expect the new patch to resolve this problem on 4.0.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24356
[Bug fortran/25705] New: fortran goto from inner IF to outer ELSE (more complex than PR17708)
* Reduced FORTRAN program form HFS.f in package atsp * A General Program for Computing Magnetic Dipole and * Electric Quadrupole Hyperfine Constants * * C O P Y R I G H T -- 1994 * * P. Jonsson and C.G. Wahlstrom, Department of Physics, * Lund Institute of Technology, * P.O. Box 118,S-221 00 Lund * Sweden * C. Froese Fischer, Department of Computer Science * Vanderbilt University, * Nashville, TN 37235 * USA * * Computer Physics Communication, Vol. 74, 399--414 (1993) subroutine qq ! (reduced by rmg from above) * DIMENSION STATEMENTS PARAMETER (KFL1=60,KFL2=12) DIMENSION J2STO(KFL2,3),J3STO(KFL2,3),NBAR(KFL2), : JBAR(KFL2,3),JPBAR(KFL2,3) * COMMON BLOCKS LOGICAL FAIL,FREE COMMON/TENSOR/VVSHELL(50),IIHSH,NNOVLP(50),IIRHO(50),IISIG(50), 1 MMU(50),MMUP(50),NNU(50),NNUP(50) COMMON/COUPLE/NJ1S,NJ23S,J1(KFL1),J2(KFL2,3),J3(KFL2,3),FREE(KFL1) COMMON/INFORM/IREADC,IWRITE,IOUT,IREADJ,IREADW,ISCW,IREAD,ISC(4) COMMON/KRON/IDEL(10,10) COMMON/MEDEFN/IHSH,NJ(10),LJ(10),NOSH1(10),NOSH2(10),J1QN1(19,3) 1,J1QN2(19,3),IJFUL(10) COMMON/DEBUG/IBUG1,IBUG2,IBUG3,NBUG6,NBUG7,IFULL COMMON/TERMS/NROWS,ITAB(24),JTAB(24),NTAB(333) COMMON/CONSTS/ZERO,TENTH,HALF,ONE,TWO,THREE,FOUR,SEVEN,ELEVEN,EPS COMMON/OVRLAP/MU,NU,MUP,NUP,NONORT,NOVLPS,IROWMU,IROWNU,ICOLMU, 1 ICOLNU,NORTH,IORDER,NCALLS,LMU,LNU,LMUP,LNUP,JMU,JNU,JMUP,JNUP COMMON/OVRINT/IOVEL(2),IOVER(2),IOVEP(2) COMMON/MACHOR/IMATCH(2) COMMON/FACT/GAM(100) COMMON/EMS/IEM(4),JI,JF,IFL * INTERACTING SUBSHELL ON R.H.S. FOUND. THE ONE ON L.H.S. MUST * BE EITHER MU OR NU * 506 IF(IX.EQ.0.AND.IY.EQ.1) THEN IF(IBACK3.EQ.0) THEN IRHO=MU IF(MU.NE.NU) IBACK3=1 MGO=MATCH(IONE,IZERO,IZERO,IZERO) IF(MGO.EQ.0) THEN IRHO=0 RETURN ELSEIF(MGO.EQ.1) THEN IF(IBACK3.EQ.1) THEN MU=MUSTO NU=NUSTO MUP=MUPSTO NUP=NUPSTO NOVLPS=NOVSTO LMU=LMUSTO LNU=LNUSTO LMUP=LMUPST LNUP=LNUPST GO TO 105 ! rmg questionable goto ELSE IRHO=0 RETURN ENDIF ELSE GO TO 108 ENDIF ELSE 105 IRHO=NU RML=ZERO RML2=ZERO IBACK3=0 MGO=MATCH(IZERO,IONE,IZERO,IZERO) IF(MGO.EQ.2) GO TO 108 IRHO=0 RETURN ENDIF 108 MEMR=IRHO ENDIF END gcc-.3.4.5 SPECS Reading specs from /usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.5/specs Configured with: /var/tmp/portage/gcc-3.4.5/work/gcc-3.4.5/configure --prefix=/usr --bindir=/usr/powerpc-unknown-linux-gnu/gcc-bin/3.4.5 --includedir=/usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.5/include --datadir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/3.4.5 --mandir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/3.4.5/man --infodir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/3.4.5/info --with-gxx-include-dir=/usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.5/include/g++-v3 --host=powerpc-unknown-linux-gnu --build=powerpc-unknown-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --disable-multilib --disable-libmudflap --disable-libgcj --enable-languages=c,c++,objc,f77 --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 3.4.5 Output from: gcc-3.4.5 -S on ppc computer (G4) .file "q.f" .section".text" .align 2 .globl qq_ .type qq_, @function qq_: stwu 1,-736(1) mflr 0 stw 31,732(1) stw 0,740(1) mr 31,1 nop .L2: lwz 0,644(31) cmpwi 7,0,0 bne 7,.L1 lwz 0,648(31) cmpwi 7,0,1 bne 7,.L1 lwz 0,652(31) cmpwi 7,0,0 bne 7,.L4 lis 9,[EMAIL PROTECTED] lwz 0,[EMAIL PROTECTED](9) stw 0,656(31) lis 9,[EMAIL PROTECTED] lis 11,[EMAIL PROTECTED] lwz 9,[EMAIL PROTECTED](9) lwz 0,[EMAIL PROTECTED](11) cmpw 7,9,0 beq 7,.L5 li 0,1 stw 0,652(31) .L5: addi 0,31,664 addi 9,31,668 addi 11,31,668 addi 10,31,668 mr 3,0 mr 4,9 mr 5,11 mr 6,10 crxor 6,6,6 bl match_ mr 0,
[Bug rtl-optimization/25677] [4.2 regression] testsuite failure:gcc.c-torture/execute/960802-1.c -O1 and -O2
--- Comment #6 from hp at gcc dot gnu dot org 2006-01-07 00:02 --- I built and checked cross from i686-pc-linux-gnu to cris-axis-linux-gnu with this patch, and built CSiBE-2.1.1 at -O0, -O1, -O2 (note 1) and -O3 compile-time tests and -Os compile-time and size tests, with just the two expected differences in the generated code (using the previously posted unrandomization and asm-wrapper patches). Thanks! (note 1: fails to compile -O2: invalid assembly code is generated for linux-2.4.23-pre3-testplatform/net/ipv4/tcp_input.c at -O2 with and without the patch due to a different bug) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25677
[Bug ada/24356] Unable to build gnatmake
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-07 00:10 --- Subject: Re: Unable to build gnatmake > --- Comment #3 from laurent at guerby dot net 2006-01-06 22:18 --- > Is 4.1 or 4.2 building there now? Albert, it looks like replacing "/usr/lib/libcl.a" with "-lcl /usr/lib/libcl.a" might work. The shared form seems to provide U_prep_frame_rec_for_unwind and the archive version seems to provide U_IS_STUB_OR_CALLX and U_is_shared_pc. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24356
[Bug fortran/25705] fortran goto from inner IF to outer ELSE (more complex than PR17708)
--- Comment #1 from malitzke at metronets dot com 2006-01-07 00:12 --- I know that this has no easy solution. However, just stating that this is an (implicitly) inadmissable case of going from one block to another is not satisfactory. Please PLEASE!!! do not make this into another case for specifications lawyers. What the using community needs are not arguments but continued use of working programs. Rewrites are OK when there are clear advantages in efficiency or less susceptibility to fraudulent use of existing code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25705
[Bug fortran/25705] fortran goto from inner IF to outer ELSE (more complex than PR17708)
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-07 00:16 --- IFC gives a warning: fortcom: Warning: t.f, line 70: A jump into a block from outside the block may have occurred. [105] GO TO 105 ! rmg questionable goto ^ Oh, this is a dup of bug 18540. This is really questionable Fortran code. *** This bug has been marked as a duplicate of 18540 *** *** This bug has been marked as a duplicate of 18540 *** -- 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=25705
[Bug fortran/18540] Jumping into blocks gives error rather than warning
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-07 00:16 --- *** Bug 25705 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||malitzke at metronets dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18540
[Bug tree-optimization/23455] tree load PRE is not working properly
--- Comment #11 from steven at gcc dot gnu dot org 2006-01-07 00:25 --- The thread starting at http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00373.html addresses my question in comment #10. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23455
[Bug libfortran/25697] libfortran - Segmentation fault/ Bad Address on unformatted read
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-01-07 00:59 --- Confirmed -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-07 00:59:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25697
[Bug target/25706] New: [4.2 regression]: invalid asm: "mov"
Last known to work with: "Thu Dec 8 10:28:12 UTC 2005 (revision 108225M)". Known to fail with: "Thu Jan 5 03:26:35 UTC 2006 (revision 109371M)". For the test-case in the attachment named bug.i, this line is emitted: mov.w [$r12=$r10+8],$r9 That's an invalid asm; it should have been movs.w or movu.w. The error is in the CRIS port; setting state when the %x asm operand output modifier is seen, and clearing it with %e, except there are other %x that aren't followed by %e. -- Summary: [4.2 regression]: invalid asm: "mov" Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org GCC target triplet: cris-axis-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25706
[Bug target/25706] [4.2 regression]: invalid asm: "mov"
--- Comment #1 from hp at gcc dot gnu dot org 2006-01-07 01:30 --- Created an attachment (id=10591) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10591&action=view) test-case Compile with ./cc1 -fpreprocessed -march=v10 -quiet -O2 -w -fno-strict-aliasing -fno-common -fomit-frame-pointer -fno-strength-reduce -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25706
[Bug target/25706] [4.2 regression]: invalid asm: "mov"
-- hp at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hp at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-07 01:30:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25706
[Bug fortran/25047] insert_bbt(): Duplicate key found!
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-07 04:21 --- The Duplicated Key problem is actually PR 24558. After fixing that one we would still have a problem with the return type being a character. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||24558 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25047
[Bug fortran/25707] New: support for Fortran 2003 USE statements, INTRINSIC and NONINTRINSIC
http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=/com.ibm.xlf101a.doc/xlflr/use.htm statements like as valid: use INTRINSIC, ISO_FORTRAN_ENV end -- Summary: support for Fortran 2003 USE statements, INTRINSIC and NONINTRINSIC Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org OtherBugsDependingO 20585,22547 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25707
[Bug fortran/25708] New: Module loading is not good at all
doing something like: function f() use modulef end function function g() use modulef end function function h() use modulef end function function i() use modulef end function - Causes us to load in the module 4 times which is just wrong. -- Summary: Module loading is not good at all Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: compile-time-hog Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708
[Bug fortran/25708] Module loading is not good at all
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-07 05:10 --- Looking at the profile for PR 21130 makes me think fixing this bug will also fix that one. Oh. it is just as bad if we have module modulef declared in the same file as we have to save it and then reload it which is just a waste of time. To Paul: Also fixing up the derived types after the fact is just wrong that was PR 25391. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||paul dot richard dot thomas ||at cea dot fr OtherBugsDependingO||21130, 25391 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708
[Bug fortran/25709] New: BIND (Fortran 2003) is not supported at all
For more information see http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=/com.ibm.xlf101a.doc/xlflr/bindc-attr.htm (Note I am starting to like XLF's manual). -- Summary: BIND (Fortran 2003) is not supported at all Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org OtherBugsDependingO 20585 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25709
[Bug fortran/25710] New: accepts "call" to function
Testcase: function f() REAL :: f f = 1.0 end function call f end - This is very much related to PR 23308. The problem here is the main issue why we create two decls for f in the following program: function f() REAL :: f f = 1.0 end function g = f() end -- Summary: accepts "call" to function Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org BugsThisDependsOn: 23308 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25710
[Bug fortran/23308] named common block confused as procedure - runtime segfault
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-07 05:31 --- Note I think fixing PR 25710 and the mentioned problem of not keeping symbols correctly will fix this bug. I have been trying to fix this but it is hard. Also note we have the same problem with "call" to functions. Also I have been thinking ICC is not a good compiler to test with for diagnostic issues. Actually this is only horrible Fortran 95 according to Lahey's fortran compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23308
[Bug fortran/25048] dummy argument with POINTER attribute
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-07 05:34 --- This looks like another case for PR 14771. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||14771 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25048
[Bug fortran/25034] allows passing of contained subprograms as actual argument
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-07 05:37 --- Isn't this just a dup of bug 20861? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25034
[Bug fortran/19654] compilation crashes when variable is too large instead of showing error
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-07 05:43 --- (In reply to comment #2) > It seems that, above a given size, gfortran declares the array as non-static: Does not matter, the front-end is supposed to error out when the array's size has overflowed. The DECL_SIZE_UNIT is See the overflow. There were a couple of bugs about the C, C++ and Ada front-ends that were like this bug (I cannot find them currently). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19654
[Bug fortran/22571] Reject derived types for dummy arguments declared in the subroutine unless they are SEQUENCE
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-07 05:47 --- *** Bug 25686 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22571
[Bug fortran/25686] Accepts invalid Fortran 95 (different argument types)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-07 05:47 --- *** This bug has been marked as a duplicate of 22571 *** -- 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=25686
[Bug fortran/25709] BIND (Fortran 2003) is not supported at all
--- Comment #1 from kargl at gcc dot gnu dot org 2006-01-07 06:05 --- Please, do not use non-standard documents! You can get a copy of the Final Committee Draft of the Fortran 2003 standard from the J3 web site (or you can ask me to send you a copy). Vendors tend to interpret the standard in a manner that suits their needs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25709
