[Bug tree-optimization/23817] New: ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:398
// test case, compile with -O3
int foo1 (void);
void foo2 (int);
static int foo9 (int k)
{
return ((k == 0x00) || (k == 0x10) || (k == 0x14));
}
static int foo8 (int *p)
{
return *p;
}
void foo6 (int *p)
{
int a, b, c, d, e = 0;
foo8 (p);
b = 0;
do
{
b++;
a = foo1();
}
while (b < 3 && (!foo9 (a)));
repeat:
d = 3;
do
{
c = foo1 ();
if (c)
foo1 ();
d--;
}
while (c && d);
if (c && !e)
{
foo2 (c);
return;
}
if (!e)
{
e = 1;
goto repeat;
}
}
// compiler output:
sd.i: In function 'foo6':
sd.i:15: internal compiler error: in check_loop_closed_ssa_use, at
tree-ssa-loop-manip.c:398
--
Summary: ICE in check_loop_closed_ssa_use, at tree-ssa-loop-
manip.c:398
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: belyshev at depni dot sinp dot msu dot ru
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23817
[Bug c/10719] invalid code generated (x86, "int $5") with __builtin_va_arg(va, char);
--- Additional Comments From appfault at hotmail dot com 2005-09-11 08:04 --- Invalid? So whenever behavior is undefined by the C standard, would it be ok to delete the user's harddrive as well? This is ridiculous - fix the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10719
[Bug tree-optimization/23818] New: ICE in dominated_by_p, at dominance.c:827
// testcase, compile with -O1 -fno-tree-dominator-opts :
void foo (int p[100], int k, ...)
{
int j, *q;
__builtin_va_list ap;
__builtin_va_start (ap, k);
q = __builtin_va_arg (ap, int *);
for (j = 0; j < 100; j++)
p [j] = q [j];
__builtin_va_end(ap);
}
// compiler output:
capifunc.i: In function 'foo':
capifunc.i:2: internal compiler error: in dominated_by_p, at dominance.c:827
--
Summary: ICE in dominated_by_p, at dominance.c:827
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: belyshev at depni dot sinp dot msu dot ru
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23818
[Bug tree-optimization/23820] New: ICE in lambda_loopnest_to_gcc_loopnest, at lambda-code.c:1982
// test case, compile with -O1 -ftree-loop-linear
int t [2][4];
void foo (void)
{
int i, j, k, v;
float e;
for (;;)
{
v = 0;
for (j = 0; j < 2; j ++)
{
for (k = 2; k < 4; k ++)
{
e = 0.0;
for (i = 0; i < 4; i ++)
e += t [j][i];
if (e)
v = j;
}
}
t [v][0] = 0;
}
}
// compiler output:
1.i: In function 'foo':
1.i:4: internal compiler error: in lambda_loopnest_to_gcc_loopnest, at
lambda-code.c:1982
--
Summary: ICE in lambda_loopnest_to_gcc_loopnest, at lambda-
code.c:1982
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: belyshev at depni dot sinp dot msu dot ru
CC: dberlin at gcc dot gnu dot org,gcc-bugs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23820
[Bug libstdc++/23781] Implicit conversion from NULL to list::iterator
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-11 09:48 --- Subject: Bug 23781 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-11 09:48:41 Modified files: libstdc++-v3 : ChangeLog libstdc++-v3/include/ext: slist libstdc++-v3/include/tr1: hashtable array libstdc++-v3/include/bits: list.tcc stl_list.h stl_tree.h libstdc++-v3/testsuite/23_containers/map/operators: 1_neg.cc libstdc++-v3/testsuite/23_containers/set/operators: 1_neg.cc Added files: libstdc++-v3/testsuite/ext/slist: 23781.cc libstdc++-v3/testsuite/tr1/6_containers/unordered: 23781.cc libstdc++-v3/testsuite/23_containers/list: 23781.cc libstdc++-v3/testsuite/23_containers/map: 23781.cc libstdc++-v3/testsuite/23_containers/multimap: 23781.cc libstdc++-v3/testsuite/23_containers/multiset: 23781.cc libstdc++-v3/testsuite/23_containers/set: 23781.cc Log message: 2005-09-11 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/23781 * include/bits/stl_list.h (_List_iterator<>:: _List_iterator(_List_node_base*), _List_const_iterator<>:: _List_const_iterator(const _List_node_base*)): Make explicit. (list<>::begin(), list<>::end(), list<>::pop_back()): Adjust consistently. * include/bits/list.tcc (list<>::insert, list<>::erase): Adjust consistently. * include/bits/stl_tree.h (_Rb_tree_iterator<>:: _Rb_tree_iterator(_Link_type), _Rb_tree_const_iterator<>:: _Rb_tree_const_iterator(_Link_type)): Make explicit. (_Rb_tree<>::begin(), _Rb_tree<>::end()): Adjust consistently. * include/ext/slist (_Slist_iterator<>::_Slist_iterator(_Node*)): Make explicit. (slist<>::erase(iterator), slist<>::erase(iterator, iterator)): Adjust consistently. * include/tr1/hashtable (hashtable_iterator<>:: hashtable_iterator(hash_node<>**)): Make explicit. * testsuite/23_containers/list/23781.cc: New. * testsuite/23_containers/map/23781.cc: Likewise. * testsuite/23_containers/multimap/23781.cc: Likewise. * testsuite/23_containers/multiset/23781.cc: Likewise. * testsuite/23_containers/set/23781.cc: Likewise. * testsuite/ext/slist/23781.cc: Likewise. * testsuite/tr1/6_containers/unordered/23781.cc: Likewise. * testsuite/23_containers/map/operators/1_neg.cc: Adjust dg-error line numbers. * testsuite/23_containers/set/operators/1_neg.cc: Likewise. * include/tr1/array (array<>::begin(), array<>::end()): Adjust stylistically for consistency with the other containers. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&r1=1.3094&r2=1.3095 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/ext/slist.diff?cvsroot=gcc&r1=1.27&r2=1.28 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/tr1/hashtable.diff?cvsroot=gcc&r1=1.8&r2=1.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/tr1/array.diff?cvsroot=gcc&r1=1.7&r2=1.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/ext/slist/23781.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/tr1/6_containers/unordered/23781.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/list.tcc.diff?cvsroot=gcc&r1=1.21&r2=1.22 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/stl_list.h.diff?cvsroot=gcc&r1=1.51&r2=1.52 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/stl_tree.h.diff?cvsroot=gcc&r1=1.47&r2=1.48 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/23_containers/list/23781.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/23_containers/map/23781.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/23_containers/map/operators/1_neg.cc.diff?cvsroot=gcc&r1=1.7&r2=1.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/23_containers/multimap/23781.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/23_containers/multiset/23781.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/23_containers/set/23781.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/23_containers/set/operators/1_neg.cc.diff?cvsroot=gcc&r1=1.7&r2=1.8 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23781
[Bug libstdc++/23781] Implicit conversion from NULL to list::iterator
--- Additional Comments From pcarlini at suse dot de 2005-09-11 09:52 --- Fixed for 4.1. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23781
[Bug tree-optimization/23817] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:398
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-09-11 10:39 ---
// another testcase, compile with -O3
int b;
void foo1 (int);
void foo (void)
{
int i, j, k, l;
short v;
for (i = 0; i < 10; i ++)
{
for (l = 0; l < 10; l++)
{
asm volatile ("\n" : "=a" (v));
j = v;
if (j)
{
k = 1;
goto out;
}
}
if (b)
foo1 (j);
k = 0;
out:
if (!k)
return;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23817
[Bug tree-optimization/23821] New: Dom creating harder to optimize code
Dom transforms the following testcase:
static int a[199];
int
main ()
{
int i, x;
for (i = 0; i < 199; i++)
{
x = a[i];
if (x != i)
abort ();
}
return 0;
}
to
int
main ()
{
int i;
for (i = 0; i < 199; i = x + 1)
{
x = a[i];
if (x != i)
abort ();
}
return 0;
}
Now we are not able to determine that i is an induction variable.
--
Summary: Dom creating harder to optimize code
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rakdver at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
[Bug libfortran/21820] Really, really, horrible IO performance
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-09-11 11:10 --- The patch from #12 has been committed to mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21820
[Bug libfortran/23363] gfortran 30 x slower that g77 on random I/O
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-09-11 11:15 --- The patch from #5 has been committed to mainline, so now we lose to g77 only by a factor of 30 and not 500 in case the file exists. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23363
[Bug fortran/23814] unformatted files from gfortran are incompatible with g77 unformatted files and solaris f95 unformatted files
--- Additional Comments From jblomqvi at cc dot hut dot fi 2005-09-11 12:09 --- Bud Davis is back and working on the pluggable record markers patch. Expect it to be completed and committed within a few weeks. There is no simple solution that is right for all situations. Gfortran uses 64-bit record markers by default since we want compatibility between LP32 and LP64 bit platforms (which incidentally g77 doesn't provide), and we want to support records bigger than 2 GB. There has been some discussion about a byteswapio patch, but nothing has been done. Patches are welcome, of course. And, I would hardly classify the bug as "critical". If you want portable binary io you're probably better off using a library such as netcdf anyway. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23814
[Bug fortran/23814] unformatted files from gfortran are incompatible with g77 unformatted files and solaris f95 unformatted files
--- Additional Comments From rrr6399 at futuretek dot com 2005-09-11 13:24 --- I believe it really is critical since myself and many others who may use gfortran need to interoperate with data generated by legacy codes on the same system that were compiled with g77 or on other systems (Sun, SGI) compiled with their native f77 or f90/f95 compilers. Some of the codes are proprietary, many are from other third parties, it isn't really feasible to force them to use another binary file library. Plus, I've been working with unformatted FORTRAN files for 15 years and this is the first time I've had this type of issue with the structure of an unformatted file. So given the current situtation, I'll have to write a format convertor for unformatted data from any gfortran code to the "standard" g77 format in order to interoperate. I would've thought that the FORTRAN spec would've covered this kind of thing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23814
[Bug c++/23823] New: Is this right?
struct foo {
template
voidf();
template
voidg();
};
template<>
voidfoo::f() {}
template<>
voidfoo::f() {}
template
voidfoo::g() {}
template
voidfoo::g() {}
gets you:
~/ootbc/members/src$ g++ foo.cc
foo.cc:13: error: partial specialization `g' of function template
foo.cc:13: error: got 1 template parameters for `void foo::g()'
foo.cc:13: error: but 2 required
foo.cc:15: error: partial specialization `g' of function template
foo.cc:15: error: redefinition of `void foo::g()'
foo.cc:13: error: `void foo::g()' previously declared here
foo.cc:15: error: got 1 template parameters for `void foo::g()'
foo.cc:15: error: but 2 required
The error message is hosed, because there are in fact two parameters. Not sure
whether the code is valid or not (but it should be :-)
--
Summary: Is this right?
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23823
[Bug libfortran/20179] cannot mix C and Fortran I/O
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-11 13:35 --- Subject: Bug 20179 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-11 13:34:57 Modified files: libgfortran: ChangeLog libgfortran/io : io.h transfer.c unix.c Log message: PR libfortran/20179 * io/unix.c (is_preconnected): Add function to test if a stream corresponds to a preconnected unit. * io/io.h: Add prototype for is_preconnected. * io/transfer.c (data_transfer_init): Do not truncate preconnected units. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.301&r2=1.302 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/io.h.diff?cvsroot=gcc&r1=1.29&r2=1.30 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/transfer.c.diff?cvsroot=gcc&r1=1.57&r2=1.58 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/unix.c.diff?cvsroot=gcc&r1=1.38&r2=1.39 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20179
[Bug target/23809] Misleading documentation for -mmmx/msse/...
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11 14:18 --- Target bug and not related to the C front-end at all. -- What|Removed |Added Component|c |target Keywords||documentation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23809
[Bug rtl-optimization/23812] swapping DImode halves produces poor x86 register allocation
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11 14:22 --- This is the normal subreg problem with the current RA. There are a couple other bugs about this already opened. -- What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization, ra http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23812
[Bug rtl-optimization/23813] redundant register assignments not eliminated
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11 14:24 --- This is the same issue as PR 23812. GCC's RA likes to keep double sized variables in registers next to one another. This is the normal subreg problem with the current RA. There are a couple other bugs about this already opened. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23813
[Bug fortran/23814] unformatted files from gfortran are incompatible with g77 unformatted files and solaris f95 unformatted files
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11 14:27 --- More than that this is a dup of bug 19303. unformatted was never supposed to be used with different versions of the compiler, or across different targets. It is just like using write in C. *** This bug has been marked as a duplicate of 19303 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23814
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11 14:27 --- *** Bug 23814 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||rrr6399 at futuretek dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug target/23816] ICE in extract_insn, at recog.c:2084
-- What|Removed |Added Component|tree-optimization |target Keywords||ssemmx http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23816
[Bug target/23816] ICE in extract_insn, at recog.c:2084
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11 14:30 --- This is a target bug as the tree optimizers get it right: MEM[base: vect_p.55, index: D.1801] = VEC_COND_EXPR < vect_var_.40 > vect_var_.47 , vect_var_.40 , vect_var_.47 > ; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23816
[Bug tree-optimization/23817] [4.1 Regression] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:398
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11 14:31 --- Confirmed a regression. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-11 14:31:58 date|| Summary|ICE in |[4.1 Regression] ICE in |check_loop_closed_ssa_use, |check_loop_closed_ssa_use, |at tree-ssa-loop-manip.c:398|at tree-ssa-loop-manip.c:398 Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23817
[Bug libstdc++/23767] std::vector iterator implementation wrong
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-11 14:32:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug c/10719] invalid code generated (x86, "int $5") with __builtin_va_arg(va, char);
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11 14:34 --- (In reply to comment #12) > Invalid? So whenever behavior is undefined by the C standard, would it be ok > to delete the user's harddrive as well? This is ridiculous - fix the bug. It is undefined which means anything can happen. The comment about delete the user's harddrive is mainly a joke about the C standard says about this. There is no bug here except in your code as the variable is passed as an int and not as a char. To fix your code, replace char with int and it works just fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10719
[Bug tree-optimization/23818] ICE in dominated_by_p, at dominance.c:827
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11 14:36 --- Note this is only reproducible on x86_64 because of the way var_args are implemented. -- What|Removed |Added GCC target triplet||x86_64-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23818
[Bug tree-optimization/23818] [4.1 Regression] ICE in dominated_by_p, at dominance.c:827
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11 14:38 --- Confirmed, it is ICE while doing std args which is also new for 4.1.0. -- What|Removed |Added CC||jakub at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-11 14:38:58 date|| Summary|ICE in dominated_by_p, at |[4.1 Regression] ICE in |dominance.c:827 |dominated_by_p, at ||dominance.c:827 Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23818
[Bug tree-optimization/23820] ICE in lambda_loopnest_to_gcc_loopnest, at lambda-code.c:1982
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11 14:42 --- Confirmed but not a regression. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail||4.0.0 4.1.0 Last reconfirmed|-00-00 00:00:00 |2005-09-11 14:42:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23820
[Bug c++/23823] Is this right?
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11 14:46 --- (In reply to comment #0) > foo.cc:13: error: partial specialization `g' of function template > foo.cc:13: error: got 1 template parameters for `void foo::g()' > foo.cc:13: error: but 2 required No, there are only one: template -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23823
[Bug target/23816] [4.1 Regression] ICE in extract_insn, at recog.c:2084
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11 15:10 --- Confirmed, a 4.1 regression. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-11 15:10:41 date|| Summary|ICE in extract_insn, at |[4.1 Regression] ICE in |recog.c:2084|extract_insn, at ||recog.c:2084 Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23816
[Bug tree-optimization/23821] [4.0/4.1 Regression] Dom creating harder to optimize code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11 15:16 --- Confirmed a regression. The mainline and 4.0.0 on PPC gives: L3: addi r9,r9,1 bdz L10 L2: slwi r0,r9,2 lwzx r2,r11,r0 cmpw cr7,r2,r9 beq+ cr7,L3 While 3.3 gives: L7: lwz r3,0(r9) addi r9,r9,4 cmpw cr0,r3,r2 beq+ cr0,L4 bl L_abort$stub L4: addi r2,r2,1 cmpwi cr1,r2,198 ble+ cr1,L7 -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2005-09-11 15:16:17 date|| Summary|Dom creating harder to |[4.0/4.1 Regression] Dom |optimize code |creating harder to optimize ||code Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
[Bug tree-optimization/23821] [4.0/4.1 Regression] DOM and VRP creating harder to optimize code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11 15:19 --- It is not just DOM on the mainline, it is also VRP -- What|Removed |Added Summary|[4.0/4.1 Regression] Dom|[4.0/4.1 Regression] DOM and |creating harder to optimize |VRP creating harder to |code|optimize code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
[Bug tree-optimization/23817] [4.1 Regression] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:398
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11 15:23 --- This is after complete unrolling. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23817
[Bug tree-optimization/23817] [4.1 Regression] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:398
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-09-11
15:35 ---
Smaller testcase:
int b;
void foo1 (int);
void foo (void)
{
int i, j, k, l;
short v;
for (i = 0; i < 10; i ++)
{
for (l = 0; l < 10; l++)
{
asm volatile ("\n" : "=a" (v));
j = v;
if (j)
goto out;
}
if (b)
foo1 (j);
return;
out: ;
}
}
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23817
Re: [Bug middle-end/23125] [4.0/4.1 Regression] OpenBSD's zic.c causes g++ but not gcc to segfault
On Sep 10, 2005, at 4:34 PM, geoffk at geoffk dot org wrote: You should be able to tell if the user set the name because it will start with a '*'. Except currently, we do: else if (C_DECL_REGISTER (decl)) change_decl_assembler_name (decl, get_identifier (asmspec)); else set_user_assembler_name (decl, asmspec); -- Pinski
[Bug middle-end/23125] [4.0/4.1 Regression] OpenBSD's zic.c causes g++ but not gcc to segfault
--- Additional Comments From pinskia at physics dot uc dot edu 2005-09-11 15:40 --- Subject: Re: [4.0/4.1 Regression] OpenBSD's zic.c causes g++ but not gcc to segfault On Sep 10, 2005, at 4:34 PM, geoffk at geoffk dot org wrote: > You should be able to tell if the user set the name because it will > start with a '*'. Except currently, we do: else if (C_DECL_REGISTER (decl)) change_decl_assembler_name (decl, get_identifier (asmspec)); else set_user_assembler_name (decl, asmspec); -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23125
[Bug c++/23823] Is this right?
--- Additional Comments From igodard at pacbell dot net 2005-09-11 15:44
---
Nah, tried:
struct foo {
template
voidf();
template
voidg();
};
template<>
voidfoo::f() {}
template<>
voidfoo::f() {}
template
voidfoo::g() {}
template
voidfoo::g() {}
which gets me:
~/ootbc/members/src$ g++ foo.cc
foo.cc:13: error: partial specialization `g' of function template
foo.cc:15: error: partial specialization `g' of function template
foo.cc:15: error: redefinition of `void foo::g()'
foo.cc:13: error: `void foo::g()' previously declared here
~/ootbc/members/src$ fg
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23823
[Bug c++/23730] [4.0/4.1 Regression] ICE instead of reporting a call to a non-existent member function
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-09-11
15:55 ---
Even shorter testcase:
===
struct A;
void foo(A& a)
{
a();
}
===
--
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Keywords||monitored
Summary|[4.0/4.1 Regression] ICE|[4.0/4.1 Regression] ICE
|instead of reporting a call |instead of reporting a call
|to a non existant member|to a non-existent member
|function|function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23730
[Bug c++/23797] [3.4/4.0/4.1 Regression] ICE on typename outside template
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-09-11
15:58 ---
Even shorter testcase:
struct A { typedef int X; };
int i = typename A::X();
--
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Keywords||monitored
Summary|[3.4/4.0/4.1 Regression] ICE|[3.4/4.0/4.1 Regression] ICE
|(on invalid)|on typename outside template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23797
Re: c++/8431: compile short program to get internal compilation error
You wrote:
:Synopsis: compile short program to get internal compilation error
:
:State-Changed-From-To: open->feedback
:State-Changed-By: paolo
:State-Changed-When: Sat Nov 2 17:23:38 2002
:State-Changed-Why:
:Unfortunately the files didn't reach us. Could you possibly
:send them again?
:Thanks, Paolo.
:
:http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8431
I'm not sure your mechanism is lynx-friendly, so I'll include them
here as plain text. Sorry for the inconvenience.
I get an internal compilation error when using
gcc version 2.95.3 20010315 (release)
to compile this code, whether or not I use -Wall or -save-temps. I use no
other switches, no includes, just a straight compile.
=== code begins immediately after this line
#define X(a) if(a);
int main(void) { long long little_doggie;
/*
* It makes no difference whether the offending expressions are surrounded by
* () or (()). I used (()) because of your suggestion to check the
* compilation against -Wall.
*/
X((little_doggie=0x01030507090B0D0FLL)) /* internal error */
/* X((little_doggie=0x01030507090B0D0FL)) internal error */
/* X((little_doggie=0x01030507090B0D0F)) internal error */
/* X((little_doggie=0x0103050709))internal error */
/* X((little_doggie=0x01030507)) compiles ok*/
return 0; }
=== code ends immediately before this line
The output I get is this:
/tmp/e1.cxx: In function `int main()':
/tmp/e1.cxx:11: Internal compiler error in `do_jump', at expr.c:10976
Please submit a full bug report.
See http://www.gnu.org/software/gcc/bugs.html> for instructions.
The output from the -v switch is this:
Reading specs from /usr/lib/gcc-lib/i386-slackware-linux/2.95.3/specs
gcc version 2.95.3 20010315 (release)
/usr/lib/gcc-lib/i386-slackware-linux/2.95.3/specs contains this:
===content begins immediately after this line
*asm:
%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*}
*asm_final:
%|
*cpp:
%(cpp_cpu) %{fPIC:-D__PIC__ -D__pic__} %{fpic:-D__PIC__ -D__pic__}
%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}
*cc1:
%(cc1_cpu) %{profile:-p}
*cc1plus:
*endfile:
%{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s
*link:
-m elf_i386 %{shared:-shared} %{!shared: %{!ibcs: %{!static:
%{rdynamic:-export-dynamic} %{!dynamic-linker:-dynamic-linker
/lib/ld-linux.so.2}} %{static:-static}}}
*lib:
%{shared: -lc}%{!shared: %{mieee-fp:-lieee} %{pthread:-lpthread}
%{profile:-lc_p} %{!profile: -lc}}
*libgcc:
-lgcc
*startfile:
%{!shared: %{pg:gcrt1.o%s} %{!pg:%{p:gcrt1.o%s}
%{!p:%{profile:gcrt1.o%s} %{!profile:crt1.o%s
crti.o%s %{!shared:crtbegin.o%s} %{shared:crtbeginS.o%s}
*switches_need_spaces:
*signed_char:
%{funsigned-char:-D__CHAR_UNSIGNED__}
*predefines:
-D__ELF__ -Dunix -D__i386__ -Dlinux -Asystem(posix)
*cross_compile:
0
*version:
2.95.3
*multilib:
. ;
*multilib_defaults:
*multilib_extra:
*multilib_matches:
*linker:
collect2
*cpp_486:
%{!ansi:-Di486} -D__i486 -D__i486__
*cpp_586:
%{!ansi:-Di586 -Dpentium} -D__i586 -D__i586__ -D__pentium -D__pentium__
*cpp_k6:
%{!ansi:-Di586 -Dk6}-D__i586 -D__i586__ -D__k6 -D__k6__
*cpp_686:
%{!ansi:-Di686 -Dpentiumpro}-D__i686 -D__i686__ -D__pentiumpro
-D__pentiumpro__
*cpp_cpu_default:
*cpp_cpu:
-Acpu(i386) -Amachine(i386) %{!ansi:-Di386} -D__i386 -D__i386__
%{mcpu=i486:%(cpp_486)} %{m486:%(cpp_486)} %{mpentium:%(cpp_586)}
%{mcpu=pentium:%(cpp_586)} %{mpentiumpro:%(cpp_686)}
%{mcpu=pentiumpro:%(cpp_686)} %{mcpu=k6:%(cpp_k6)}
%{!mcpu*:%{!m486:%{!mpentium*:%(cpp_cpu_default)}}}
*cc1_cpu:
%{!mcpu*: %{m386:-mcpu=i386 -march=i386} %{m486:-mcpu=i486 -march=i486}
%{mpentium:-mcpu=pentium} %{mpentiumpro:-mcpu=pentiumpro}}
*link_command:
%{!fsyntax-only: %{!c:%{!M:%{!MM:%{!E:%{!S:%(linker) %l %X %{o*} %{A} %{d}
%{e*} %{m} %{N} %{n}%{r} %{s} %{t} %{u*} %{x} %{z} %{Z}
%{!A:%{!nostdlib:%{!nostartfiles:%S}}}
%{static:} %{L*} %D %o %{!nostdlib:%{!nodefaultlibs:%G %L %G}}
%{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*}
}}
===content ends immediately before this line
Hope this helps!
[Bug c/23824] New: Using mipsel to compile BigEndian -O2 does not work
extern void * memcpy(void *, void *, int );
int test(char *from, char *to)
{
memcpy(from,to,8);
}
Compilation:
mipsel-linux-gnu-gcc -O2 -EB -o test.o -c test.c
Gives output:
:
0: 88a20003lwl v0,3(a1)
4: 88a30007lwl v1,7(a1)
8: 98a2lwr v0,0(a1)
c: 98a30004lwr v1,4(a1)
10: a8820003swl v0,3(a0)
14: b882swr v0,0(a0)
18: a8830007swl v1,7(a0)
1c: 03e8jr ra
20: b8830004swr v1,4(a0)
And trying it with:
mips-sgi-irix5-gcc -O2 -EB -o test.o -c test.c
:
0: 88a2lwl v0,0(a1)
4: 88a30004lwl v1,4(a1)
8: 98a20003lwr v0,3(a1)
c: 98a30007lwr v1,7(a1)
10: a882swl v0,0(a0)
14: b8820003swr v0,3(a0)
18: a8830004swl v1,4(a0)
1c: 03e8jr ra
20: b8830007swr v1,7(a0)
The second way is the correct one (at least the hardware likes it more).
--
Summary: Using mipsel to compile BigEndian -O2 does not work
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ondrap at penguin dot cz
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: gcc-4.0.1/configure --host=i686-pc-linux-gnu --
target=mipsel-lin
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: mipsel-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23824
[Bug target/23824] Using mipsel to compile BigEndian -O2 does not work
-- What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23824
[Bug fortran/16861] segfault with doubly used module
--- Additional Comments From pault at gcc dot gnu dot org 2005-09-11 16:28
---
(In reply to comment #22)
A thoroughly reduced testcase is:
module foo
INTEGER :: i
end module foo
module bar
contains
subroutine sub(j)
use foo
integer, dimension(i) :: j !change dimension to explicit clears bug
end subroutine sub
end module bar
module foobar
use foo !or eliminate this to clear bug
use bar
end module foobar
The ICE occurs whilst writing foobar because the symtree for the arrayspec for j
has no symbol for i, as said in the discussion in the PR. This has the effect
of causing the ICE here:
static void
mio_symtree_ref (gfc_symtree ** stp)
{
pointer_info *p;
fixup_t *f;
if (iomode == IO_OUTPUT)
{
mio_symbol_ref (&(*stp)->n.sym); http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16861
[Bug libfortran/19872] [4.0 only] closed and re-opened file not overwriten
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-11 18:40 --- Patch was never committed to 4.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19872
[Bug libfortran/19872] [4.0 only] closed and re-opened file not overwriten
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-11 18:55 --- Subject: Bug 19872 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-09-11 18:55:16 Modified files: gcc/testsuite : ChangeLog libgfortran: ChangeLog libgfortran/io : io.h transfer.c unix.c Added files: gcc/testsuite/gfortran.dg: overwrite_1.f Log message: PR libfortran/19872 * gfortran.dg/overwrite_1.f: New test. PR libfortran/19872 PR libfortran/20179 * io/unix.c (is_preconnected): Add function to test if a stream corresponds to a preconnected unit. * io/io.h: Add prototype for is_preconnected. * io/transfer.c (data_transfer_init): Truncate overwritten files on first write, but not preconnected units. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.397&r2=1.5084.2.398 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/overwrite_1.f.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.163.2.90&r2=1.163.2.91 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/io.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.16.10.7&r2=1.16.10.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/transfer.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.32.2.16&r2=1.32.2.17 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/unix.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.21.10.14&r2=1.21.10.15 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19872
[Bug libfortran/20179] cannot mix C and Fortran I/O
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-11 18:55 --- Subject: Bug 20179 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-09-11 18:55:16 Modified files: gcc/testsuite : ChangeLog libgfortran: ChangeLog libgfortran/io : io.h transfer.c unix.c Added files: gcc/testsuite/gfortran.dg: overwrite_1.f Log message: PR libfortran/19872 * gfortran.dg/overwrite_1.f: New test. PR libfortran/19872 PR libfortran/20179 * io/unix.c (is_preconnected): Add function to test if a stream corresponds to a preconnected unit. * io/io.h: Add prototype for is_preconnected. * io/transfer.c (data_transfer_init): Truncate overwritten files on first write, but not preconnected units. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.397&r2=1.5084.2.398 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/overwrite_1.f.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.163.2.90&r2=1.163.2.91 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/io.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.16.10.7&r2=1.16.10.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/transfer.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.32.2.16&r2=1.32.2.17 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/unix.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.21.10.14&r2=1.21.10.15 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20179
[Bug libfortran/19872] [4.0 only] closed and re-opened file not overwriten
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-11 19:39 --- Subject: Bug 19872 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-11 19:39:35 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: overwrite_1.f Log message: PR libfortran/19872 * gfortran.dg/overwrite_1.f: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6045&r2=1.6046 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/overwrite_1.f.diff?cvsroot=gcc&r1=1.1&r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19872
[Bug fortran/23814] unformatted files from gfortran are incompatible with g77 unformatted files and solaris f95 unformatted files
--- Additional Comments From rrr6399 at futuretek dot com 2005-09-11 20:47 --- Well, just to warn you, you're going to have a lot of steamed engineers on your hands when they discover that they either have to recompile all of their FORTRAN codes on every platform with gfortran, write all of their data (50 - 1000MB binaries and larger) as ASCII, or convert their files to the traditional g77 format to interoperate with the rest of their processes. What will actually happen is that users will get burnt once and then they'll drop gfortran like a hot potato and put in a request to purchase a commercial compiler from Intel or PGI. Another reason that this feature is so painful is that engineers tend to pipeline their unformatted files from one process to the next. There can literally be 10 or more programs in a process that will read from or write to a given unformatted file. Any program in the process that was compiled with gfortran will break the process and probably in such a subtle way that it'll take each user hours to figure out what went wrong. (I spent four hours on it yesterday discovering what the problem was in my process and that's with knowing how to read the output from "od".) Furthermore, when one writes binary in C, you get exactly what your variables are sized to in your code. If the platform is a 32 bit machine and is IEEE compliant, you pretty much know that a short is 16bit, an int is 32 bit, a long is 32 bit and a long long is 64 bit. Typically, many times developers even define macros or new types that guarantee that the variables are the same lengths independent of 32 bit or 64 bit architectures. There are also compiler switches many times that govern the length of the various primitive types. So if portability of the data is important to you, the resulting binary file is interoperable except for big-Endian versus little-Endian issues...(that can be worked with a flag at the top or always writing in one endianess.) With C binary files, of course, you don't have to worry about the the silly record markers either that muck up the works. I think the goal of allowing record lengths > 2GB is a good long time target, but having been in the field for many years, I imagine that the current use cases for record lengths > 2GBs are very very few compared to those involving interoperability with other compilers and platforms. The few users requiring >2GB record lengths can easily modify their write statement to output multiple records as well rather than one large one. Hopefully, once there is a compiler switch in place, everybody will be happy. :-) p.s. It is too bad the FORTRAN spec (even the 2003) threw in the towel on interoperable binary files. It forces everybody to deal with these issues in different ways using various third party libaries or ad hoc cobbled-together solutions. As shown by the CORBA standard and others, the specification of interoperable binary files is completely doable. I imagine the FORTRAN vendors will continue to ensure that their binary file format can be completely specified by the user just to meet the needs of their customers even though the spec doesn't force them to. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23814
[Bug c/23439] [4.1 regression] "f(){for" crashes the C frontend
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||09/msg00680.html Status|NEW |ASSIGNED Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23439
[Bug c++/23440] [4.0/4.1 regression] "void f(){for" crashes the C++ frontend
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||09/msg00680.html Status|NEW |ASSIGNED Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23440
[Bug fortran/21647] INQUIRE errors when using -fdefault-integer-8
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-11
21:27 ---
This is a front-end bug. We generate wrong code for all the ioparm members that
are passed by reference (the pointers are cast, instead of creating
temporaries). All cases handled by set_parameter_ref (in trans-io.c) are handled
incorrectly when given a kind different that the GFC_INTEGER_4. Exhaustive list
(hopefully) is: iostat, exist, opened, number, named, recl, nextrec, size and
iolength. Two examples:
$ cat a.f90
logical*8 ex
inquire (file="foo",exist=ex)
end
$ gfortran -fdump-tree-original a.f90
$ cat a.f90.t02.original
MAIN__ ()
{
logical8 ex;
_gfortran_filename = "a.f90";
_gfortran_line = 2;
_gfortran_ioparm.file = "foo";
_gfortran_ioparm.file_len = 3;
_gfortran_ioparm.exist = (int4 *) &ex;
_gfortran_st_inquire ();
}
$ cat b.f90
integer*8 i
write(*,"()",iostat=i)
end
$ gfortran -fdump-tree-original b.f90
$ cat b.f90.t02.original
MAIN__ ()
{
int8 i;
_gfortran_filename = "b.f90";
_gfortran_line = 2;
_gfortran_ioparm.unit = 6;
_gfortran_ioparm.format = "()";
_gfortran_ioparm.format_len = 2;
_gfortran_ioparm.iostat = (int4 *) &i;
_gfortran_st_write ();
_gfortran_st_write_done ();
}
My guess is that in both cases, we should create a temporary before the call,
set the ioparm member to that temporary, make the library call and then get the
value from the temporary back to the real variable. Unfortunately, I have no
idea how to do that (i'm not much of a front-end guy).
--
What|Removed |Added
Component|libfortran |fortran
Keywords||wrong-code
Last reconfirmed|2005-05-19 16:51:29 |2005-09-11 21:27:46
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21647
[Bug c++/2316] g++ fails to overload on language linkage
--- Additional Comments From sebor at roguewave dot com 2005-09-11 21:34 --- In reply to comment #6: The vanilla EDG eccp 3.5 compiles the test case w/o an error: $ eccp -v t.cpp && ./a.out; echo $? Edison Design Group C/C++ Front End, version 3.5 (Nov 9 2004 20:00:33) Copyright 1988-2004 Edison Design Group, Inc. 0 Intel C++ 9.0 (based on eccp 3.4.1) does reject the code, but that's most likely for compatibility with gcc. I wouldn't rely on its behavior to determine whether gcc is or isn't correct. (Note that HP aCC 6.0 which is also based on EDG eccp accepts the code as expected.) In reply to comment #4: I don't think DR 4 is related since it's about internal linkage. The test case is well-formed according to 7.5.1, p1, "Two function types with different language linkages are distinct types even if they are otherwise identical." I.e., the first foo() can only take the address of an extern "C" function as an argument (and not extern "C++") while the second foo() only an extern "C++" function (and not extern "C"). Thus, each foo() is a distinct overload. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
[Bug libfortran/19872] [4.0 only] closed and re-opened file not overwriten
-- What|Removed |Added Target Milestone|4.0.1 |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19872
[Bug fortran/18315] wrong result for lbound with single argument
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-11 21:51 --- Are you sure about that, Thomas? Most compilers I have access to (Intel, g95, g77, Sun, Lahey) says something similar to "The left and right hand sides of this array syntax assignment must be conformable arrays." or "Array assignment at (1) has different sizes". I think this code is not standard-conforming. -- What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18315
[Bug fortran/20971] gfortran - internal compiler error on bad program -fdefault-integer-8
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-11 22:01 --- Aren't these fixed? Trying to compile these testcases with an up-to-date compiler, I don't get ICEs... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20971
[Bug fortran/23814] unformatted files from gfortran are incompatible with g77 unformatted files and solaris f95 unformatted files
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-11 22:05 --- (In reply to comment #5) > > Furthermore, when one writes binary in C, you get exactly what your variables > are sized to in your code. If the platform is a 32 bit machine and is IEEE > compliant, What happens when one or the other of these conditions isn't met? > I imagine the FORTRAN vendors The correct spelling of the name of the language is Fortran. Your comments #3 and #5 are nice little rants. Actual code to fix the problem speaks volumes over your rants. In particular, you've been told that Bud Davis is working on the problem. If there was an easy solution to the problem, Bud (or one the others working on gfortran) would have fixed it long ago. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23814
[Bug java/21418] Order of source files matters when compiling
--- Additional Comments From mark at gcc dot gnu dot org 2005-09-11 22:29
---
And I tracked our problems with The javax.swing.Box inner class AccessibleBox
extends AccessibleAWTContainer in GNU Classpath to a similar order problem.
Take the following source files:
p/AClass.java
::
package p;
public class AClass
{
protected abstract class InnerA
{
protected InnerA()
{
}
}
}
::
q/BClass.java
::
package q;
import p.*;
public class BClass extends AClass
{
protected class InnerB extends AClass.InnerA
{
}
}
::
q/CClass.java
::
package q;
import p.AClass;
public class CClass extends BClass
{
protected class InnerC extends AClass.InnerA
{
}
}
When compiled as follows all goes well:
$ gcj -C p/AClass.java q/BClass.java q/CClass.java
But when we change the order to:
$ gcj -C p/AClass.java q/CClass.java q/BClass.java
q/CClass.java:5: error: Nested class p.AClass$InnerA is protected; cannot be
accessed from here.
protected class InnerC extends AClass.InnerA
^
1 error
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21418
[Bug c++/23825] New: [4.0/4.1 Regression] Extra C++ failures
Starting from http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00497.html there are extra C++ failures: FAIL: g++.dg/other/error8.C (test for errors, line 8) FAIL: g++.dg/other/error8.C (test for errors, line 9) FAIL: g++.dg/other/error8.C duplicate error messages (test for bogus messages, line 8) FAIL: g++.dg/other/error8.C duplicate error messages (test for bogus messages, line 9) FAIL: g++.dg/template/union1.C (test for excess errors) WARNING: g++.dg/template/union1.C compilation failed to produce executable They aren't fixed as in http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00544.html -- Summary: [4.0/4.1 Regression] Extra C++ failures Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23825
[Bug c++/23825] [4.0/4.1 Regression] Extra C++ failures
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11 23:02 --- See http://gcc.gnu.org/ml/gcc-regression/2005-09/msg00022.html -- What|Removed |Added Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23825
[Bug rtl-optimization/23098] [4.1 Regression] store of 0.0 to float
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-11 23:22 --- Subject: Bug 23098 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-11 23:22:11 Modified files: gcc: ChangeLog gcc/config/rs6000: predicates.md rs6000.md rs6000.c altivec.md Log message: PR rtl-optimization/23098 * config/rs6000/predicates.md (easy_fp_constant): SFmode constant 0.0f is easy. * config/rs6000/rs6000.md (movdf splitter): Use const_double_operand predicate for TARGET_POWERPC64. * config/rs6000/rs6000.c (rs6000_legitimize_reload_address): Expand SYMBOL_REF method to ABI_V4. * config/rs6000/altivec.md (build_vector_mask_for_load): Use replace_equiv_address. * config/rs6000/rs6000.c (rs6000_emit_eh_reg_restore): Mark MEM as rs6000_sr_alias_set and MEM_NOTRAP. (rs6000_aix_emit_builtin_unwind_init): Use gen_frame_mem(). Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9933&r2=2.9934 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/predicates.md.diff?cvsroot=gcc&r1=1.25&r2=1.26 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.md.diff?cvsroot=gcc&r1=1.406&r2=1.407 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.c.diff?cvsroot=gcc&r1=1.866&r2=1.867 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/altivec.md.diff?cvsroot=gcc&r1=1.44&r2=1.45 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23098
[Bug fortran/23814] unformatted files from gfortran are incompatible with g77 unformatted files and solaris f95 unformatted files
--- Additional Comments From rrr6399 at futuretek dot com 2005-09-11 23:22 --- I'm not sure why I'm getting so much pushback on this silly thing. I realize that disagreeing with the assumptions made during the design may be regarded by some as "rants", but what I was attempting to do (perhaps poorly) is illustrate why simple decisions that might seem fairly benign can have huge efficiency impacts on a large population of users. There has been a pattern of these decisions made over the years that have wasted thousands (if not millions) of hours of people's precious time. (Big Endian vs. Little Endian, \ versus /, CR vs CR/LF vs LF, 8 byte vs 4 byte markers, etc.) If you read some of the previous comments, you'll see that some don't think it's an issue. It really is a problem that should take high priority. I know Bud is going to apply a variation of the patch he wrote a few months ago soon and I'm happy about that. I hope there isn't any pushback from the rest of the developers. I think the default should actually be 4 byte markers, but that's just my humble opinion. BTW, I think both spellings of FORTRAN (FORmula TRANslation) are correct actually: http://www.ibiblio.org/pub/languages/fortran/ch1-1.html http://www.engin.umd.umich.edu/CIS/course.des/cis400/fortran/fortran.html (Not that it really matters in the big scheme of things.) I'll also post a small C program to convert to the g77 format soon as a temporary fix until the patch is in place. (I'm completely hammered with work right now, but I'll try to contribute more in the future. I've already sent in some code snippets on the little endian/big endian issue.) Also, if I wanted to be condescended to I'd go talk to my wife. :-) I hope that we can all keep this professional in the future and respect people's time (development, trouble shooting and bug reporting) that they put into this to help make a better product for everybody. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23814
[Bug c++/23826] New: invalid use of constructor as a template
The following code compiled in g++ 3.3.4, but does not compile in the latest
4.0.x
Seems like a regression testing oversight.
template
class db_reference {
private:
T r;
public:
ID_TYPE &id;
db_reference(ID_TYPE req_id=0);
T &get();
std::string print(int full_subtables=0, int show_ids=1, int no_refs=0)
const;
std::string print_xml(int full_subtables=1, int show_ids=0, int no_refs=1,
const char *tag=0) const;
void parse_xml(std::string &buf, const char *tag);
void parse(const std::string &buf);
void parse(const SQL_ROW &buf);
operator T() const;
T *operator ->();
const T *operator ->() const;
db_reference &operator =(T &t);
db_reference &operator =(const db_reference &t);
};
template
db_reference::db_reference(ID_TYPE req_id) : id(*(ID_TYPE
*)(&(r.id))) {
id=req_id;
}
The error is
error: invalid use of constructor as a template
note: use db_reference::db_reference instead of db_reference::db_reference to name the constructor in a qualified name
--
Summary: invalid use of constructor as a template
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: harold at alum dot mit dot edu
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: 4.0.x
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23826
[Bug java/21418] Order of source files matters when compiling
--- Additional Comments From cvs-commit at developer dot classpath dot org 2005-09-11 23:36 --- Subject: Bug 21418 CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Mark Wielaard <[EMAIL PROTECTED]> 05/09/11 23:15:58 Modified files: . : ChangeLog lib: gen-classlist.sh.in Log message: * lib/gen-classlist.sh.in: Use sort -r to work around bug #21418. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.4725&tr2=1.4726&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/lib/gen-classlist.sh.in.diff?tr1=1.30&tr2=1.31&r1=text&r2=text -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21418
[Bug c++/23823] Is this right?
--- Additional Comments From bangerth at dealii dot org 2005-09-11 23:38 --- The code is illegal (you can only partially specialize class templates, not function templates). I think the error message is clear: you only give one template parameter (and try, illegally, to fix the other), instead of having two template parameters as required (note the function has two parameters, but in your attempt of a partial specialization, you only leave one as a template while fixing the other to a particular value). W. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23823
[Bug c++/23826] invalid use of constructor as a template
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-11 23:39 --- (In reply to comment #0) > The following code compiled in g++ 3.3.4, but does not compile in the latest > 4.0.x > Seems like a regression testing oversight. Nope, see below. > The error is > error: invalid use of constructor as a template > note: use db_reference::db_reference instead of > db_reference ID_TYPE>::db_reference to name the constructor in a qualified > name The error even says how to fix your code. In fact the note part was added so people don't confuse what the error message meant. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23826
[Bug c++/23826] invalid use of constructor as a template
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-11 23:46 --- For the reporter: what the compiler is telling you is that your code is not valid ISO C++. What it is not telling you is that G++ 3.3.4 did not really actually know what is valid C++ and what is not. In GCC 3.4 and later there is a new C++ parser that is ISO C++ conforming. Sadly for you, this means that while older G++ versions accepted your invalid C++, newer G++ releases do not, and you have to fix your code to make it work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23826
[Bug preprocessor/23827] New: standard C++ should not have hex float preprocessing tokens
Standard C++ does not include hexadecimal floating point numbers. The
preprocessor correctly pedwarns for C++ if such a preprocessing token is
converted to a token, but it incorrectly allows p+ and p- in preprocessing
tokens in standard C++ mode in the first place. The problem is probably the
table
static const struct lang_flags lang_defaults[] =
{ /* c99 c++ xnum std // digr */
/* CXX98 */ { 0, 1, 1, 1, 1, 1 },
in libcpp/init.c: xnum should be 0 not 1. The valid C++ testcases this affects
(compile with -std=c++98 -pedantic-errors, should execute OK, instead aborts)
are along the lines of gcc.dg/c90-hexfloat-2.c:
#define f (
#define l )
#define str(x) #x
#define xstr(x) str(x)
/* C90 and C++: "0x1p+( 0x1p+)"; C99: "0x1p+f 0x1p+l" */
const char *s = xstr(0x1p+f 0x1p+l);
extern "C" void abort (void);
extern "C" int strcmp (const char *, const char *);
int
main (void)
{
if (strcmp (s, "0x1p+( 0x1p+)"))
abort ();
else
return 0; /* Correct C90 and C++ behavior. */
}
--
Summary: standard C++ should not have hex float preprocessing
tokens
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23827
[Bug preprocessor/23827] standard C++ should not have hex float preprocessing tokens
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-12 00:32 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||accepts-invalid Known to fail||2.95.3 3.0.4 3.2.2 3.2.3 ||3.3.1 4.0.0 3.4.0 Last reconfirmed|-00-00 00:00:00 |2005-09-12 00:32:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23827
[Bug fortran/23814] unformatted files from gfortran are incompatible with g77 unformatted files and solaris f95 unformatted files
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-12 00:35 --- (In reply to comment #7) > > I realize that disagreeing with the assumptions made during the design may be > regarded by some as "rants", but what I was attempting to do (perhaps poorly) > is > illustrate why simple decisions that might seem fairly benign can have huge > efficiency impacts on a large population of users. Why do you think that this was a "simple decision" in the initial design? The world is moving to 64-bit CPUs, and a 32-bit record marker effects performance (think about alignment issues). Bud has thought about this problem for several months, produced a plausible patch, and then Real Life got into his way. A fix to this problem takes time. There is no simple solution. > If you read some of the previous comments, you'll see that some don't think > it's > an issue. It really is a problem that should take high priority. This isn't pushback but reality. There are only a handful of volunteers hacking on the code. What is a high priority to you may not be very high on some hacker's lists. To me, fixing the known bugs in modules is much higher priority than changing a functioning portion of the compiler. > I know Bud is going to apply a variation of the patch he wrote a > few months ago soon and I'm happy about that. I hope there isn't > any pushback from the rest of the developers. I doubt that there will be pushback. Yes, we will review the code and make suggestions. But, most of the developers will welcome Bud's effort. > I think the default should actually be 4 byte markers, but that's > just my humble opinion. I only use opteron base systems where a 64-bit marker is preferred. > > BTW, I think both spellings of FORTRAN (FORmula TRANslation) > are correct actually: http://www.ibiblio.org/pub/languages/fortran/ch1-1.html > http://www.engin.umd.umich.edu/CIS/course.des/cis400/fortran/fortran.html > (Not that it really matters in the big scheme of things.) Read the Standard. It very carefully uses "FORTRAN 77" to identify specific references to ISO 1539:1980. Indeed, the passage in 1.6 says "Each Fortran International Standard since ISO 1539:1980 (informally referred to as FORTRAN 77)". Note, "ORTRAN" actually appears in small caps. Everywhere else the Standard carefully uses Fortran. > I'll also post a small C program to convert to the g77 format soon as a > temporary fix until the patch is in place. Thanks. > (I'm completely hammered with > work right now, but I'll try to contribute more in the future. I've already > sent in some code snippets on the little endian/big endian issue.) So, you can appreciate the demands on the developers. :-) I would love to devote several hours a week to gfortran, but time is occupied by Real Life. > I hope that we can all keep this professional in the future and > respect people's time (development, trouble shooting and bug reporting) > that they put into this to help make a better product for > everybody. Sorry if my comment appeared to be too strong, but your Comment #3 and #5 appeared to be "preaching to the choir". We know there's a problem. Bud is working on it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23814
[Bug c++/23823] Is this right?
--- Additional Comments From igodard at pacbell dot net 2005-09-12 01:14
---
Well, you may think it's clear but I am am counter-example :-) Perhaps
"template parameter" (in the message) is a formal term in the language syntax
specification (who but acompiler maven would know that?), but I expected that
"template parameter" refered to the template parameters, not the template
argument specifications. That is, I thought (in the example) that it referred to
"T, true" in "voidfoo::g() {}", rather than to "template".
That is, you know what the message means only if you already know what it means,
which is by definition a bad diagnostic.
--
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23823
[Bug rtl-optimization/11261] Weak code generated for JPEG compression
-- What|Removed |Added Status|WAITING |NEW Last reconfirmed|2003-11-22 20:18:21 |2005-09-12 01:18:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11261
[Bug c++/18803] [3.4.5 regression] rejects access to operator() in template
--- Additional Comments From bangerth at dealii dot org 2005-09-12 01:18 --- Folks, I find that this bug is now present on the 3.4.x branch. I don't know for how long, but believe that it broke somewhere between 5 and 15 days ago. It would be good if we could fix this before 3.4.5 finally comes out. Note that both 4.0.x and mainline seem to be unaffected, so it may be one of the patches that were backported that caused this... W. -- What|Removed |Added CC||gdr at gcc dot gnu dot org, ||nathan at gcc dot gnu dot ||org, reichelt at gcc dot gnu ||dot org Status|RESOLVED|REOPENED Resolution|FIXED | Summary|[4.0 regression] rejects|[3.4.5 regression] rejects |access to operator() in |access to operator() in |template|template http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18803
[Bug c++/18803] [3.4 regression] rejects access to operator() in template
-- What|Removed |Added Known to fail||3.4.5 Known to work||3.4.4 Summary|[3.4.5 regression] rejects |[3.4 regression] rejects |access to operator() in |access to operator() in |template|template Target Milestone|4.0.0 |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18803
[Bug rtl-optimization/23828] New: local calling convention not used when using -fwhole-program --combine
When compiling the files in the attachment for PR22574 using the command line: gcc -fwhole-program --combine -march=i686 -O2 button.i charproc.i charsets.i cursor.i data.i doublechr.i fontutils.i input.i main.i menu.i misc.i print.i ptydata.i screen.i scrollbar.i tabs.i util.i xstrings.i VTPrsTbl.i -S the function ClearLeft looks like: ClearLeft.221553: pushl %ebp movl%esp, %ebp subl$8, %esp movl3748(%eax), %ecx movl3752(%eax), %edx movl$0, (%esp); <- 0 is passed on the stack incl%ecx movl%ecx, 4(%esp) callClearInLine.221545 leave ret When compiling just the file util.i that contains ClearLeft using -march=i686 -O2 the assembly is: ClearLeft: pushl %ebp movl%esp, %ebp subl$8, %esp movl3748(%eax), %ecx movl3752(%eax), %edx incl%ecx movl%ecx, (%esp) xorl%ecx, %ecx ; 0 is passed in a register callClearInLine leave ret When using -fwhole-program --combine the parameter "0" to the ClearInLine function is passed on the stack instead of being passed in a register. Is there a reason for that? Shouldn't it be more better to pass it in a register? -- Summary: local calling convention not used when using -fwhole- program --combine Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dann at godzilla dot ics dot uci dot edu CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: i686-pc-linux-gnus http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23828
[Bug middle-end/23828] local calling convention not used when using -fwhole-program --combine
-- What|Removed |Added Component|rtl-optimization|middle-end Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23828
[Bug java/23829] New: FreeBSD 5 support for libjava
FreeBSD 5 has -lpthread but not activated. -- Summary: FreeBSD 5 support for libjava Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: chat95 at mac dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org GCC build triplet: i386-unknown-freebsd5.4 GCC host triplet: i386-unknown-freebsd5.4 GCC target triplet: i386-unknown-freebsd5.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23829
[Bug java/23829] FreeBSD 5 support for libjava
--- Additional Comments From chat95 at mac dot com 2005-09-12 01:54 --- Created an attachment (id=9708) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9708&action=view) FreeBSD >=5.3 has -lpthread -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23829
[Bug c++/23823] Is this right?
--- Additional Comments From bangerth at dealii dot org 2005-09-12 01:55
---
Well, but then tell me what you expect for the case you have:
template
voidfoo::g() {}
How many template parameters do you give? I count one (in the
'template <...>' angle brackets). And how many are expected (the
language says it would be 2)?. Propose a better wording for the
message, rather than just complaining about the existing text.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23823
[Bug libgcj/23829] FreeBSD 5 support for libjava
-- What|Removed |Added Component|java|libgcj http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23829
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Additional Comments From rrr6399 at futuretek dot com 2005-09-12 02:20 --- FYI: Here's what Intel did for to address the record sizes larger than 2 GB: http://www.intel.com/software/products/compilers/flin/docs/main_for/mergedProjects/bldaps_for/format_of_record_types_.htm The nice thing about this approach is that the files are compatible with files generated by f77/g77 and other vendors' f90/f95 compilers. The tradeoff is that it makes the i/o logic a little more complicated. I believe that PGI (Portland Group) compiler generates f77 compliant unformatted files as well. I haven't found their approach yet for dealing with >2GB record sizes, but the docs are at http://www.pgroup.com/resources/docs.htm I'm going to check Cray, SGI and Sun as well to see what format they output. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug c++/23823] Is this right?
--- Additional Comments From igodard at pacbell dot net 2005-09-12 03:17 --- In the case you give I count one template argument specificatiob, and two template parameters. As for a better message, how about: "A template definition must have same number of formal template specifications (within "template<...>") as the definition; the actual arguments (within "name<...>") may differ." Ivan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23823
[Bug c/23830] New: inline optimization possibility - reorder compilation step
subj: For functions specified inline, decision to inline them should be based on
inlined code size instead of un-inlined function length.
Here is a simple snippet of a larger complex.
inline int changePrecision(int x, int x_prec, int y_prec) {
if (y_prec>x_prec) return (x<<(y_prec-x_prec));
else
if (y_prec>(x_prec-y_prec));
else
return k;
}
which is intended to be called with constants x_prec & y_prec.
This code though assigned inline (it would be 0 or 1 cycles) is
first created into a function, observed to be long enough, and not inlined.
--
Summary: inline optimization possibility - reorder compilation
step
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Atif dot Hussain at gmail dot com
CC: Atif dot Hussain at gmail dot com,gcc-bugs at gcc dot
gnu dot org
GCC host triplet: frontend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23830
[Bug libstdc++/22309] mt allocator doesn't pthread_key_delete it's keys
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-12 04:49 --- Subject: Bug 22309 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-12 04:49:11 Modified files: libstdc++-v3 : ChangeLog libstdc++-v3/config: linker-map.gnu libstdc++-v3/include/ext: mt_allocator.h libstdc++-v3/src: mt_allocator.cc libstdc++-v3/testsuite/lib: dg-options.exp libstdc++.exp Added files: libstdc++-v3/testsuite: testsuite_shared.cc libstdc++-v3/testsuite/ext/mt_allocator: 22309_thread.cc Log message: 2005-09-11 Benjamin Kosnik <[EMAIL PROTECTED]> PR libstdc++/19265 PR libstdc++/22309 * include/ext/mt_allocator.h (__gnu_cxx::__create_handler): Remove. (__pool::_M_destroy_thread_key): Compatibility only. (__pool::_M_initialize(__destroy): Same. (__pool::_M_initialize): New. (__pool::_M_initialize_once): Nothing fancy. (__pool::_M_once): Remove. (__common_pool): New. (__common_pool_base): New. (__per_type_pool): New. (__per_type_pool_base): New. * src/mt_allocator.cc: Same. * config/linker-map.gnu (__pool::_M_initialize()): Add. 2005-09-11 Jakub Jelinek <[EMAIL PROTECTED]> PR libstdc++/19265 PR libstdc++/22309 * src/mt_allocator.cc (__gnu_internal::freelist_mutex): Make static. (__gnu_internal::__freelist): New type. (__gnu_internal::freelist): New variable. (__gnu_internal::_M_destroy_thread_key): New function. (__gnu_cxx::__pool::_M_destroy): Don't delete _M_thread_freelist_initial. (__gnu_cxx::__pool::_M_initialize): Make argument nameless. Don't use _M_thread_freelist and _M_thread_freelist_initial __pool fields, instead use __gnu_internal::freelist fields, call gthread_key_create just once. Use __gnu_internal::_M_destroy_thread_key as key destructor. (__gnu_cxx::__pool::_M_get_thread_id): Store size_t id rather than _Thread_record* in the thread specific value. Don't use _M_thread_freelist __pool field, instead use __gnu_internal::freelist fields. (__gnu_cxx::__pool::_M_destroy_thread_key): Do nothing. 2005-09-11 Benjamin Kosnik <[EMAIL PROTECTED]> Jakub Jelinek <[EMAIL PROTECTED]> PR libstdc++/19265 PR libstdc++/22309 * testsuite/testsuite_shared.cc: New. * testsuite/lib/dg-options.exp (dg-require-sharedlib): New. * testsuite/lib/libstdc++.exp (libstdc++_init): Look for shared library, and set v3-sharedlib based on this. (check_v3_target_sharedlib): New. (proc v3-build_support): Build shared objects. * testsuite/ext/mt_allocator/22309_thread.cc: New, use above. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&r1=1.3095&r2=1.3096 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/config/linker-map.gnu.diff?cvsroot=gcc&r1=1.84&r2=1.85 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/ext/mt_allocator.h.diff?cvsroot=gcc&r1=1.47&r2=1.48 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/src/mt_allocator.cc.diff?cvsroot=gcc&r1=1.12&r2=1.13 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/testsuite_shared.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/ext/mt_allocator/22309_thread.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/lib/dg-options.exp.diff?cvsroot=gcc&r1=1.4&r2=1.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/lib/libstdc++.exp.diff?cvsroot=gcc&r1=1.45&r2=1.46 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22309
[Bug libstdc++/19265] problem with _S_destroy_thread_key when using dynamic libraries
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-12 04:49 --- Subject: Bug 19265 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-12 04:49:11 Modified files: libstdc++-v3 : ChangeLog libstdc++-v3/config: linker-map.gnu libstdc++-v3/include/ext: mt_allocator.h libstdc++-v3/src: mt_allocator.cc libstdc++-v3/testsuite/lib: dg-options.exp libstdc++.exp Added files: libstdc++-v3/testsuite: testsuite_shared.cc libstdc++-v3/testsuite/ext/mt_allocator: 22309_thread.cc Log message: 2005-09-11 Benjamin Kosnik <[EMAIL PROTECTED]> PR libstdc++/19265 PR libstdc++/22309 * include/ext/mt_allocator.h (__gnu_cxx::__create_handler): Remove. (__pool::_M_destroy_thread_key): Compatibility only. (__pool::_M_initialize(__destroy): Same. (__pool::_M_initialize): New. (__pool::_M_initialize_once): Nothing fancy. (__pool::_M_once): Remove. (__common_pool): New. (__common_pool_base): New. (__per_type_pool): New. (__per_type_pool_base): New. * src/mt_allocator.cc: Same. * config/linker-map.gnu (__pool::_M_initialize()): Add. 2005-09-11 Jakub Jelinek <[EMAIL PROTECTED]> PR libstdc++/19265 PR libstdc++/22309 * src/mt_allocator.cc (__gnu_internal::freelist_mutex): Make static. (__gnu_internal::__freelist): New type. (__gnu_internal::freelist): New variable. (__gnu_internal::_M_destroy_thread_key): New function. (__gnu_cxx::__pool::_M_destroy): Don't delete _M_thread_freelist_initial. (__gnu_cxx::__pool::_M_initialize): Make argument nameless. Don't use _M_thread_freelist and _M_thread_freelist_initial __pool fields, instead use __gnu_internal::freelist fields, call gthread_key_create just once. Use __gnu_internal::_M_destroy_thread_key as key destructor. (__gnu_cxx::__pool::_M_get_thread_id): Store size_t id rather than _Thread_record* in the thread specific value. Don't use _M_thread_freelist __pool field, instead use __gnu_internal::freelist fields. (__gnu_cxx::__pool::_M_destroy_thread_key): Do nothing. 2005-09-11 Benjamin Kosnik <[EMAIL PROTECTED]> Jakub Jelinek <[EMAIL PROTECTED]> PR libstdc++/19265 PR libstdc++/22309 * testsuite/testsuite_shared.cc: New. * testsuite/lib/dg-options.exp (dg-require-sharedlib): New. * testsuite/lib/libstdc++.exp (libstdc++_init): Look for shared library, and set v3-sharedlib based on this. (check_v3_target_sharedlib): New. (proc v3-build_support): Build shared objects. * testsuite/ext/mt_allocator/22309_thread.cc: New, use above. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&r1=1.3095&r2=1.3096 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/config/linker-map.gnu.diff?cvsroot=gcc&r1=1.84&r2=1.85 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/ext/mt_allocator.h.diff?cvsroot=gcc&r1=1.47&r2=1.48 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/src/mt_allocator.cc.diff?cvsroot=gcc&r1=1.12&r2=1.13 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/testsuite_shared.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/ext/mt_allocator/22309_thread.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/lib/dg-options.exp.diff?cvsroot=gcc&r1=1.4&r2=1.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/lib/libstdc++.exp.diff?cvsroot=gcc&r1=1.45&r2=1.46 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19265
[Bug middle-end/23830] inline optimization possibility - reorder compilation step
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23830
[Bug middle-end/23830] inline optimization possibility - reorder compilation step
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-12 05:01 --- For 4.1 we do have IPA based constant propagation which basically implements what you want. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23830
[Bug fortran/23379] compiler segfault with internal write
--- Additional Comments From jvdelisle at verizon dot net 2005-09-12 05:39 --- I have confirmed that the test case given is resolved by the patch discusssed in comment #3. The patch is in review. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23379
[Bug middle-end/19419] Overlapping memcpy with discriminated types
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-09-12 06:14 --- Investigating. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-07-15 21:34:21 |2005-09-12 06:14:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19419
[Bug c/10719] invalid code generated (x86, "int $5") with __builtin_va_arg(va, char);
--- Additional Comments From appfault at hotmail dot com 2005-09-12 06:17 --- I agree that gcc apparently complies with the standard as currently implemented. So this zilla is not a defect, but an enhancement request. Why not reopen this to add a -Wundefined-behavior, so that at least bugs like that could be caught up front when using -Werror? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10719
