[Bug middle-end/26717] [4.2 Regression] gfortran: ICE at tree-complex.c:133 with -O -ffast-math in LAPACK,
--- Comment #5 from anlauf at gmx dot de 2006-03-17 08:06 --- (In reply to comment #4) > I will, however, suggest that you reconsider using --fast-math with gfortran. > One of my codes works correctly without --fast-math, but it > will generate NaN's with it. I have not tracked down the problem, A fairly well-known case is complex division, where -ffast-math assumes a reduced range of the variables so that no overflow can occur. See the gcc option -fno-cx-limited-range for more details. Here's an example where -fno-cx-limited-range does not counter the effect of -ffast-math and produces an NaN: % cat gfc_complex_div.f90 program gfc_complex_div implicit none complex, parameter :: a = 1.e-30 * (1.0, 1.0) print *, cx_div (a, a) contains function cx_div (a, b) complex :: cx_div, a, b cx_div = a / b end function cx_div end program gfc_complex_div % gfc gfc_complex_div.f90 -O && ./a.out ( 1.00, 0.00) % gfc gfc_complex_div.f90 -O -ffast-math && ./a.out ( NaN, NaN) % gfc gfc_complex_div.f90 -O -ffast-math -fno-cx-limited-range && ./a.out ( NaN, NaN) I think this used to work (with g77?), but it appears not to work any longer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26717
[Bug bootstrap/26718] Bootstrap 4.1.0 fails on Apple Power G5
--- Comment #4 from aszodi at imp dot univie dot ac dot at 2006-03-17 08:53 --- Andrew: I could build gcc 4.0.2 on my private iBook (OS X 10.4.4 = Darwin V8.4.0), but not gcc 4.1.0 -- so the problem is most probably not G5-specific. Fang: I used the nm that came with the system (/usr/bin/nm). I would assume that autoconf checks for the appropriate tools. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26718
[Bug libfortran/26712] gfortran on mac intel runtime floating point exception when printing
--- Comment #5 from ccb at dl dot ac dot uk 2006-03-17 10:13 --- How do I put this. The apple fenv.h supplied functions "work" by only setting bits in mxcsr (not cw), and then only setting bits 1-6. Problem is that the actual working bits are in 7-12 (as in fpu-387.h). So my little test.f runs with the default mask (all bits on). I get the failure when using gfortran as the mxcsr bits are all set off (same test.f as above, default compilation) 0x37f is cw 0 is cw_sse Floating point exception defalt cw_sse is 0x1f80 . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26712
[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access
--- Comment #19 from rguenth at gcc dot gnu dot org 2006-03-17 10:33 --- *sigh*, seems like I opened a can of worms. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
[Bug rtl-optimization/26725] New: ICE in check_reg_live, at haifa-sched.c:4645 with -O2 at IPF
GCC 4.2 revision 112135 failed to compile SPEC cpu2000/197.parser.
Here is the minimal reproducer:
struct Exp_struct {
char type;
unsigned char cost;
};
extern void foo();
void print_expression(struct Exp_struct * n)
{
int i;
if (n->type == 2)
{
for (i=0; icost; i++) foo();
foo();
} else {
for (i=0; icost; i++) foo();
if (n->cost == 0) foo();
}
}
$ gcc-42 -c -O2 par.c
par.c: In function 'print_expression':
par.c:17: internal compiler error: in check_reg_live, at haifa-sched.c:4645
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: ICE in check_reg_live, at haifa-sched.c:4645 with -O2 at
IPF
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: grigory_zagorodnev at linux dot intel dot com
GCC build triplet: ia64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26725
[Bug tree-optimization/26726] New: -fivopts producing out of bounds array refs
=== Cut ===
struct
QValueList
{
QValueList()
{
sh = new int;
}
QValueList& operator+= ( QValueList&);
int* sh;
};
void
queryIconsByContext()
{
QValueList iconlist[8];
QValueList iconlistResult;
for (int i=0; i<8; i++)
iconlistResult+=iconlist[i];
}
=== Cut ===
g++ -O2
produces this SSA form after ivopts branch:
...
ivtmp.38_37 = ivtmp.38_1 + 4B;
if (ivtmp.38_37 != &iconlist[9]) goto ; else goto ;
...
taking address of the 10th iconlist element is out of bounds access.
--
Summary: -fivopts producing out of bounds array refs
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mueller at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26726
[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access
--- Comment #20 from rguenth at gcc dot gnu dot org 2006-03-17 11:03 --- For the testcase in comment #6 we fall into the #ifdef CONSTANT_ALIGNMENT else if (CONSTANT_CLASS_P (exp)) align = CONSTANT_ALIGNMENT (exp, align); #endif path and conclude the alignment is 128. I have yet another patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
[Bug bootstrap/26715] bootstrap comparison failure
--- Comment #2 from chris dot pitchford at newsint dot co dot uk 2006-03-17 11:18 --- Currently the only C compiler on the box is GCC 3.4.2 which was downloaded from Sunfreeware.com Is this the bootstrap compiler? To be honest this project is the first time I've tried to compile GCC, I've always previously used sunfreeware's or my distro was bundled with GCC! Am I right in thinking the compilation process is.. use system CC to make an interim GCC, then use that to compile the full GCC? -- chris dot pitchford at newsint dot co dot uk changed: What|Removed |Added CC||chris dot pitchford at ||newsint dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26715
[Bug libfortran/26712] gfortran on mac intel runtime floating point exception when printing
--- Comment #6 from ccb at dl dot ac dot uk 2006-03-17 11:30 --- Created an attachment (id=11062) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11062&action=view) fpu-387.h based fpe control for mactel The changes are to the SSE elements. It sets a mask as for the local floating point registers. This seems to work for the fortran code I deal with. -- ccb at dl dot ac dot uk changed: What|Removed |Added Attachment #11058|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26712
[Bug bootstrap/26715] bootstrap comparison failure
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-03-17 11:33 --- > Currently the only C compiler on the box is GCC 3.4.2 which was downloaded > from Sunfreeware.com Is this the bootstrap compiler? The bootstrap compiler is the compiler that compiles GCC during stage #1 of the 3-stage bootstrap. During stage #2 and stage, #3 GCC compiles itself. > Am I right in thinking the compilation process is.. use system CC to make an > interim GCC, then use that to compile the full GCC? Do you have another C compiler than GCC 3.4.2 installed on the box? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26715
[Bug tree-optimization/26726] -fivopts producing out of bounds array refs
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-17 11:39 ---
Reduced testcase:
struct QValueList {
QValueList() { sh = new int; }
void foo();
int* sh;
};
void queryIconsByContext()
{
QValueList iconlist[8];
iconlist[7].foo();
}
ivopts generates
:
ivtmp.35_3 = &iconlist[1];
# ivtmp.35_12 = PHI ;
:;
D.2027_8 = operator new (4);
D.2028_9 = (int *) D.2027_8;
D.2072_4 = (int * *) &iconlist[0];
D.2073_7 = (int * *) ivtmp.35_12;
D.2074_21 = D.2072_4 + D.2073_7;
D.2075_22 = -&iconlist;
D.2076_23 = (int * *) D.2075_22;
MEM[base: D.2074_21, index: D.2076_23, offset: -4B] = D.2028_9;
ivtmp.35_17 = ivtmp.35_12 + 4B;
if (ivtmp.35_17 != &iconlist[9]) goto ; else goto ;
:;
goto ();
both using -&iconlist (!?) as index and and -4 as offset for TMR looks weird
here. Referencing &iconlist[9] is sort of wrong-code.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rakdver at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||wrong-code
Last reconfirmed|-00-00 00:00:00 |2006-03-17 11:39:44
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26726
[Bug tree-optimization/26726] -fivopts producing out of bounds array refs
--- Comment #2 from mueller at gcc dot gnu dot org 2006-03-17 12:40 --- one possible workaround would be to lower the ARRAY_REF's to indirect mem refs, which I don't track -- mueller at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26726
[Bug tree-optimization/26726] -fivopts producing out of bounds array refs
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-17 12:55 --- For your warning patch another option is to simply only warn in either the first or the second VRP pass, not in the third which is the only one run after loop optimizations. Also you could ignore ADDR_EXPR (ARRAY_REF (...)) as these are not reading/writing to the memory. Instead for D.1234_2 = &a[i]; *D.1234_2 = j; warn at the point of the INDIRECT_REF and lookup the DEF for D.1234_2 to check if it is defined as &ARRAY_REF (...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26726
[Bug tree-optimization/26726] -fivopts producing out of bounds array refs
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-03-17 13:00 --- Now I noticed IVOPTs generates a TMR with base == &iconlist[1] + ivtmp, offset -&iconlist[0] and offset -4B (ivtmp being &iconlist[0] initially). Which boils down to using simply *ivtmp instead of a TMR. Funny. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26726
[Bug tree-optimization/26726] -fivopts producing out of bounds array refs
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-03-17 13:17 ---
Simpler testcase:
struct Foo {
Foo() : s(1) {}
int s;
};
void foo(Foo&);
void bar(void)
{
Foo x[4];
foo(x[0]);
}
:
ivtmp.34 = &x[1];
:;
D.1822 = (int *) &x[0];
D.1825 = -&x;
MEM[base: D.1822 + (int *) ivtmp.34, index: (int *) D.1825, offset: -4B] = 1;
ivtmp.34 = ivtmp.34 + 4B;
if (ivtmp.34 != &x[5]) goto ; else goto ;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26726
Re: [Bug tree-optimization/26726] -fivopts producing out of bounds array refs
On Fri, 2006-03-17 at 12:40 +, mueller at gcc dot gnu dot org wrote: > > --- Comment #2 from mueller at gcc dot gnu dot org 2006-03-17 12:40 > --- > one possible workaround would be to lower the ARRAY_REF's to indirect mem > refs, > which I don't track > > Uh, no. We are in fact, trying to do the exact opposite in the future (keep things array ref as long as possible)
[Bug tree-optimization/26726] -fivopts producing out of bounds array refs
--- Comment #6 from dberlin at gcc dot gnu dot org 2006-03-17 13:31 --- Subject: Re: -fivopts producing out of bounds array refs On Fri, 2006-03-17 at 12:40 +, mueller at gcc dot gnu dot org wrote: > > --- Comment #2 from mueller at gcc dot gnu dot org 2006-03-17 12:40 > --- > one possible workaround would be to lower the ARRAY_REF's to indirect mem > refs, > which I don't track > > Uh, no. We are in fact, trying to do the exact opposite in the future (keep things array ref as long as possible) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26726
[Bug middle-end/21898] Segmentation fault on testsuite case gcc.dg/20020425-1.c
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-03-17 14:29 --- I see the same on ia64 for trunk. Program received signal SIGSEGV, Segmentation fault. 0x402ed101 in gimplify_cond_expr (expr_p=0x2070aca8, pre_p=0x607ffe8dc798, fallback=fb_none) at gimplify.c:2425 2425 TREE_OPERAND (expr, 0) = gimple_boolify (TREE_OPERAND (expr, 0)); (gdb) bt #0 0x402ed101 in gimplify_cond_expr (expr_p=0x2070aca8, pre_p=0x607ffe8dc798, fallback=fb_none) at gimplify.c:2425 #1 0x40319bd0 in gimplify_expr (expr_p=0x2070aca8, pre_p=0x607ffe8dc798, post_p=0x607ffe8dc7a0, [EMAIL PROTECTED]: 0x402c11e0 , fallback=fb_none) at gimplify.c:5251 #2 0x40306660 in gimplify_stmt (stmt_p=0x2070aca8) at gimplify.c:4144 #3 0x403066d0 in gimplify_to_stmt_list (stmt_p=0x2070aca8) at gimplify.c:4152 #4 0x402ee330 in gimplify_cond_expr (expr_p=0x2070acf8, pre_p=0x607ffe8dd218, fallback=fb_none) at gimplify.c:2456 #5 0x40319bd0 in gimplify_expr (expr_p=0x2070acf8, pre_p=0x607ffe8dd218, post_p=0x607ffe8dd220, [EMAIL PROTECTED]: 0x402c11e0 , fallback=fb_none) at gimplify.c:5251 #6 0x40306660 in gimplify_stmt (stmt_p=0x2070acf8) at gimplify.c:4144 #7 0x403066d0 in gimplify_to_stmt_list (stmt_p=0x2070acf8) at gimplify.c:4152 #8 0x402ee330 in gimplify_cond_expr (expr_p=0x2070ad48, pre_p=0x607ffe8ddc98, fallback=fb_none) at gimplify.c:2456 the frontend passes us: Breakpoint 3, gimplify_cond_expr (expr_p=0x207cfe70, pre_p=0x607fff1fe018, fallback=fb_none) at gimplify.c:2365 2365 tree expr = *expr_p; (gdb) n 2369 type = TREE_TYPE (expr); (gdb) call debug_tree(expr) > arg 0 constant invariant 0> arg 1 head (nil) tail (nil) stmts > arg 2 arg 0 arg 1 head (nil) tail (nil) stmts > arg 2 arg 0 arg 1 etc. recursive gimplification will of course break at some point here. I remember Zdenek rewriting gimplification to a non-recursive thingie... any news here? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Known to fail||4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-03-17 14:29:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21898
[Bug middle-end/21898] Segmentation fault on testsuite case gcc.dg/20020425-1.c
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-03-17 14:32 --- Forgot to mention - the ia64 build I was seeing this with was built with -g -fno-inline and checking enabled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21898
[Bug rtl-optimization/26725] [4.2 Regression] ICE in check_reg_live, at haifa-sched.c:4645 with -O2 on ia64
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet||ia64-unknown-linux-gnu Keywords||ice-on-valid-code Summary|ICE in check_reg_live, at |[4.2 Regression] ICE in |haifa-sched.c:4645 with -O2 |check_reg_live, at haifa- |at IPF |sched.c:4645 with -O2 on ||ia64 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26725
[Bug rtl-optimization/26727] New: [4.2 Regression] gcc.target/powerpc/doloop-1.c fails
I was looking through my testsuite results and noticed this fails.
We deinitely don't get a do loop at all:
L7:
addic. r0,r0,-1
add r4,r4,r2
addi r2,r2,1
bne- cr0,L7
L5:
..
blr
L6:
add r5,r5,r2
addi r2,r2,1
bdz L5
add r5,r5,r2
addi r2,r2,1
bdz L5
b L6
Really this testcase could be optimized even further to just:
if (count > 10)
pcb += count;
else if (count > 0)
pca += count;
But that is a different issue (and would cause this testcase to fail again
because then the testcase is not testing what it should be testing).
Anyways what we get in final_cleanup is:
:
if (count > 10) goto ; else goto ;
:;
if (count > 0) goto ; else goto ;
:;
i.39 = 1;
:;
pcb = (char *) i.39 + pcb;
i.39 = i.39 + 1;
if (i.39 != count) goto ; else goto ;
:;
i = 0;
:;
pca = (char *) i + pca;
i = i + 1;
if (i != count) goto ; else goto ;
Which obviously confuses the IV lookup on the rtl level.
Anyways here the testcase:
/* { dg-do compile { target powerpc*-*-* } } */
/* { dg-options "-O2" } */
void foo (int count, char* pca, char* pcb) {
int i;
if (count > 10)
for (i = 0; i < count; ++i)
pcb += i;
else
for (i = 0; i < count; ++i)
pca += i;
*pca = *pcb;
}
/* { dg-final { scan-assembler "bdnz" } } */
--
Summary: [4.2 Regression] gcc.target/powerpc/doloop-1.c fails
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc-darwin7.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26727
[Bug rtl-optimization/26727] [4.2 Regression] gcc.target/powerpc/doloop-1.c fails
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26727
[Bug middle-end/26724] __builtin_constant_p fails to recognise function with constant return
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-17 15:20 --- Confirmed, the problem is: /* If this expression has side effects, show we don't know it to be a constant. Likewise if it's a pointer or aggregate type since in those case we only want literals, since those are only optimized when generating RTL, not later. And finally, if we are compiling an initializer, not code, we need to return a definite result now; there's not going to be any more optimization done. */ if (TREE_SIDE_EFFECTS (arglist) || AGGREGATE_TYPE_P (TREE_TYPE (arglist)) || POINTER_TYPE_P (TREE_TYPE (arglist)) || cfun == 0) return integer_zero_node; I don't know much about anything else but a work around is using a variable to store the results (yes this is stupid and it should not dependent on that). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|tree-optimization |middle-end Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-17 15:20:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26724
Error with stl
Hello,
I've got a problem compiling the following source
[EMAIL PROTECTED]:~/tmp/xxx> g++ -Wall -O2 b.cpp
b.cpp: In member function ‘void bCls::DumpItems()’:
b.cpp:15: error: expected `;' before ‘aIter’
When I compile this code with borland's bcc it compiles without complaining.
So I think it might be an error in g++ or it's because I just start
programming in C++.
Hope You can help me, sicerely
Michael Tomuschat
Here is the code:
# File b.cpp
#include
using std::vector;
template struct aCls {
T val;
aCls( T v) { val = v; }
};
template class bCls {
public:
bCls( void) {}
vector > bLst;
void AddItem( T v) { bLst.insert( bLst.end(), v); }
void DumpItems( void) {
vector >::iterator aIter; // tut nicht
}
};
int main( void) {
bCls B;
for( int i = 0; i < 10; i++) B.AddItem( i);
return -1;
}
I'm using gcc:
[EMAIL PROTECTED]:~/tmp/xxx> g++ --version
g++ (GCC) 4.0.2 20050901 (prerelease) (SUSE Linux)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--
Dipl. Ing. Michael Tomuschat
Ing.-Büro Tomuschat Tel. : 07071-943866
Steinbößstr. 23 Fax : 07071-943867 (wenn Büro besetzt ist)
72074 Tübingen E-mail: [EMAIL PROTECTED]
[Bug java/26720] Can't find method 'access$1(I)'
-- rmathew 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-03-17 15:28:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26720
Re: Error with stl
On Mar 17, 2006, at 10:33 AM, Michael Tomuschat wrote: vector >::iterator aIter; // tut nicht You forgot the typename keyword. It should be: typename vector >::iterator aIter; -- Pinski
[Bug fortran/26728] New: On AMD Athlon 64 not possible to call C routine with variable no. of arguments from Fortran
Since gcc release 4 it is not possible anymore to call from Fortran a C routine
defined for a variable no. of arguments using the ellips notation.
It used to work on all previous gcc 3 releases,
and it still works on 32-bit machines, like e.g. Intel Pentium with
SUSE Linux 10.0 (gcc 4.0.2)
$ uname -a
Linux pc012038 2.6.13-15-default #1 Tue Sep 13 14:56:15 UTC 2005 x86_64 x86_64
x86_64 GNU/Linux
$ cat for_ellips.f
PROGRAM FELLIS
WRITE(*,2100)
CALL SSN(99123)
WRITE(*,1100)
STOP 0
1100 FORMAT('F: returning from SSN(n1)')
2100 FORMAT('F: calling SSN(99123)')
END
$ cat ftoc_ellips.c
#include
#include
#define SSN ssn_
int SSN(int *noargs, ...)
{
va_list Cargs;
printf("C: here in SSN...\n");
va_start(Cargs,noargs);
return 0;
}
$ /usr/local/gnu/bin/gfortran -c for_ellips.f
$ /usr/local/gnu/bin/gcc -c ftoc_ellips.c
$ /usr/local/gnu/bin/gfortran for_ellips.o ftoc_ellips.o -o ./ftoc_ellips.exe
$ ./ftoc_ellips.exe
F: calling SSN(99123)
Illegal instruction
$ /usr/local/gnu/bin/gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-threads=posix --prefix=/usr/local/gnu
--with-local-prefix=/usr/local/gnu --infodir=/usr/local/gnu/share/info
--mandir=/usr/local/gnu/share/man --libdir=/usr/local/gnu/lib64
--libexecdir=/usr/local/gnu/lib64 --enable-languages=c,c++,objc,fortran
--disable-checking --with-gxx-include-dir=/usr/local/gnu/include/c++/4.0.2
--disable-libjava-multilib --with-slibdir=/usr/local/gnu/lib64
--with-system-zlib --enable-shared --enable-__cxa_atexit
--without-system-libunwind
Thread model: posix
gcc version 4.1.0
The same happens with gcc 4.0.2:
$ gfortran -c for_ellips.f
$ gcc -c ftoc_ellips.c
$ gfortran for_ellips.o ftoc_ellips.o -o ./ftoc_ellips.exe
$ ./ftoc_ellips.exe
F: calling SSN(99123)
Segmentation fault
$ gcc -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,f95,java,ada --disable-checking
--with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-java-awt=gtk
--disable-libjava-multilib --with-slibdir=/lib64 --with-system-zlib
--enable-shared --enable-__cxa_atexit --without-system-libunwind
--host=x86_64-suse-linux
Thread model: posix
gcc version 4.0.2 20050901 (prerelease) (SUSE Linux)
--
Summary: On AMD Athlon 64 not possible to call C routine with
variable no. of arguments from Fortran
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kbanse at eso dot org
GCC build triplet: x86_64-suse-linux
GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26728
[Bug fortran/26728] On AMD Athlon 64 not possible to call C routine with variable no. of arguments from Fortran
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-17 15:41 --- This is not valid code at all. The fortran code assumes it is passing to a non varargs function which is correct. You should develop a different solution to this issue. -- 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=26728
[Bug tree-optimization/26629] tree load PRE does not work on array references
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-17 16:11 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01110.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||03/msg01110.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26629
[Bug c++/26729] New: bogus 'comparison is always 0' message
trivial function using POD constructors says "comparison is always 0".
If I remove any of the UInt16 constructors, the warning goes away.
This doesn't seem to happen in gcc-4.1.0
typedef unsigned short UInt16;
UInt16 pipe;
UInt16 cmp ()
{
UInt16 answer;
answer =
UInt16((pipe & UInt16(0x8800u))) == UInt16(0x8000u)
& ((pipe & 0x4000)!= 0)
? (pipe & 0x2000u)!= 0
&(((pipe & 0x400u)!= 0))
?(((pipe & 0x1001u)
^ 0x1000u))) != 0)))
:(pipe & 0x1001u) == 0x1001u
// Next line is reported as always false
:UInt16((pipe & 0x3700u)) == UInt16(0x3000u);
return answer;
}
--
Summary: bogus 'comparison is always 0' message
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: apl at alum dot mit dot edu
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=26729
[Bug c++/26729] bogus 'comparison is always 0' message
--- Comment #1 from apl at alum dot mit dot edu 2006-03-17 16:48 --- Created an attachment (id=11063) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11063&action=view) g++ -Wall -Werror -Wextra -O2 ... (almost) trivial test case... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26729
[Bug c/26730] New: Pointer assignment used together with ++ leads to an update of the wrong structure
This is not the same as bug 11751 as the variable used with ++ is not reused.
Here the simple code:
sadd.i:
# 1 "sadd.c"
# 1 ""
# 1 ""
# 1 "sadd.c"
typedef struct A A;
struct A {
int no;
A *sub;
};
void main()
{ A sub={0, ((void*)0)};
A root={0, &sub};
A *pos=&root;
pos=&pos->sub[pos->no++];
printf("%d %d %p %p %p\n", root.no, sub.no, &root, &sub, pos);
}
Here the compiler call:
<~/test> 82>/usr/local/gcc-4.1.0/bin/gcc -v -save-temps sadd.c
Using built-in specs.
Target: i586-suse-linux
Configured with: ../gcc-4.1.0/configure --prefix=/usr/local/gcc-4.1.0
--enable-java-awt=gtk --with-cpu=pentium4 --enable-threads=posix
--enable-languages=c,c++,java --disable-checking --host=i586-suse-linux
--disable-libjava-multilib --without-system-libunwind --with-sy
stem-zlib
Thread model: posix
gcc version 4.1.0
/usr/local/gcc-4.1.0/libexec/gcc/i586-suse-linux/4.1.0/cc1 -E -quiet -v sadd.c
-mtune=pentium4 -fpch-preprocess -o sadd.i
ignoring nonexistent directory
"/usr/local/gcc-4.1.0/lib/gcc/i586-suse-linux/4.1.0/../../../../i586-suse-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/local/gcc-4.1.0/include
/usr/local/gcc-4.1.0/lib/gcc/i586-suse-linux/4.1.0/include
/usr/include
End of search list.
/usr/local/gcc-4.1.0/libexec/gcc/i586-suse-linux/4.1.0/cc1 -fpreprocessed
sadd.i -quiet -dumpbase sadd.c -mtune=pentium4 -auxbase sadd
-version -o sadd.s
GNU C version 4.1.0 (i586-suse-linux)
compiled by GNU C version 4.1.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 9c3116972ab61a6d962b78330fe593eb
sadd.c: In function main:
sadd.c:15: warning: incompatible implicit declaration of built-in function
printf
sadd.c:10: warning: return type of main is not int
as -V -Qy -o sadd.o sadd.s
GNU assembler version 2.16.91.0.2 (i586-suse-linux) using BFD version
2.16.91.0.2 20050720 (SuSE Linux)
/usr/local/gcc-4.1.0/libexec/gcc/i586-suse-linux/4.1.0/collect2 --eh-frame-hdr
-m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib
/crt1.o /usr/lib/crti.o
/usr/local/gcc-4.1.0/lib/gcc/i586-suse-linux/4.1.0/crtbegin.o
-L/usr/local/gcc-4.1.0/lib/gcc/i586-suse-linux/4.
1.0 -L/usr/local/gcc-4.1.0/lib/gcc/i586-suse-linux/4.1.0/../../.. sadd.o -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed
-lgcc_s --no-as-needed
/usr/local/gcc-4.1.0/lib/gcc/i586-suse-linux/4.1.0/crtend.o /usr/lib/crtn.o
Here the command execution.
<~/test> 85>sadd
0 1 0xbf995550 0xbf995558 0xbf995558
The problem is that the updated pos pointer is used to perform the ++ on the
field "no" while the assignment should be actually the last statement. Also
pos->no was needed and fetched before to actually calculate the new pos.
The problem is present even with -O0 on the gcc-4.0.2 (from SuSe 10.0) and
gcc-4.1.0 (see above)
The compilers gcc-3.4.6, gcc-3.3.1 don't have that problem on the same platform
and on Tru64 5.1. Also the Tru64 5.1 standard C compiler does not have the
problem.
<~/test> >gcc -o sadd sadd.c
sadd.c: In function `main':
sadd.c:10: warning: return type of `main' is not `int'
<~/test> >sadd
1 0 11fffbfe0 11fffbfd0 11fffbfd0
<~/test> >gcc -v
Reading specs from
/usr/local/gcc-3.3.1/lib/gcc-lib/alphaev68-dec-osf5.1/3.3.1/specs
Configured with: ../gcc-3.3.1/configure --prefix=/usr/local/gcc-3.3.1
--disable-shared
Thread model: single
gcc version 3.3.1
<~/test> >cc -o sadd sadd.c
<~/test> >sadd
1 0 11fffbfd8 11fffbfe8 11fffbfe8
<~/test> >cc -V
Compaq C V6.4-216 (dtk) on Compaq Tru64 UNIX V5.1A (Rev. 1885)
Compiler Driver V6.4-013 (dtk) cc Driver
<~/test> >
--
Summary: Pointer assignment used together with ++ leads to an
update of the wrong structure
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: SimonX200 at hotmail 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=26730
RE: too few template-parameter-lists with nested template
I have worked around the problem. The HashTable methods now have __GCC__ code
that detects when the object has not had its constructor called, and
Performs the same initialization on-demand.
>From the lack of responses indicating otherwise, I suppose I will assume this
>is a bug in G++. Should that go into bugzilla?
Dr. Michael J. Gourlay
University of Central Florida / FIEA
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Gourlay
Sent: Thursday, March 16, 2006 4:33 PM
To: gcc-bugs@gcc.gnu.org
Subject: too few template-parameter-lists with nested template
I've seen other posts asking a similar question, but the solution continues to
evade me.
I have a line of code that compiles and runs as designed with MSVC but not
under g++ 3.4.2 (mingw-special):
HashTable::FactoryEntry>
Factory::sFactoryTable ;
The following lines do compile (but see caveat below):
template class
HashTable::FactoryEntry>
Factory::sFactoryTable ;
...or...
template <> class HashTable::FactoryEntry>
Factory::sFactoryTable ;
The resulting code, however, seems not to have called the constructor on
sFactoryTable by the time it gets used, which is well after "main" starts -
i.e. this is not a problem with order of execution of static constructors.
Here is some context for the code above:
template class HashTable
{
...
protected:
LinkedList * mLists ;
...
} ;
template class Factory : public HashEntry
{
...
protected:
struct FactoryEntry : public HashEntry
{ // struct to associate a factory with a hash table key.
Factory * mFactory ;
} ;
static HashTable sFactoryTable ; // singleton list of
concrete factories associated with this abstract factory
} ;
I searched http://gcc.gnu.org/ and found several simpler variations where
people complained about initialization of static templated class members, the
solution to which was to prefix the class name with "template <>", but I found
no mention of a situation like that above, which involves nested templated
classes.
I apologize if this reflects my ignorance rather than a bug in the GNU C
compiler, and would appreciate having somebody explain how to make this work.
Thanks.
Michael J. Gourlay
[Bug c/26730] Pointer assignment used together with ++ leads to an update of the wrong structure
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-17 16:59 --- pos=&pos->sub[pos->no++]; This is undefined. You assign pos and use it without a sequence point. *** This bug has been marked as a duplicate of 11751 *** -- 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=26730
[Bug c/11751] wrong evaluation order of an expression
--- Comment #64 from pinskia at gcc dot gnu dot org 2006-03-17 16:59 --- *** Bug 26730 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||SimonX200 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11751
[Bug c++/26729] [3.3/3.4 Regression] bogus 'comparison is always 0' message
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-17 17:00 --- Fixed in 4.0.0, 3.4.6 was the last release of 3.4.x. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||diagnostic Resolution||FIXED Summary|bogus 'comparison is always |[3.3/3.4 Regression] bogus |0' message |'comparison is always 0' ||message Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26729
[Bug c++/26729] [3.3/3.4 Regression] bogus 'comparison is always 0' message
--- Comment #3 from apl at alum dot mit dot edu 2006-03-17 17:04 --- Any clue as to the specific patch? We build with -Wall -Wextra -Werror, and won't be able to upgrade to gcc-4.x for at least another couple of months. -- apl at alum dot mit dot edu changed: What|Removed |Added Known to fail||3.4.3 Known to work||4.1.0 4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26729
[Bug c++/26729] [3.3/3.4 Regression] bogus 'comparison is always 0' message
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-17 17:07 --- Who knows, 3.4.x is dead, I would not doubt it was the merge of the tree-ssa branch into the mainline which fixed this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail|3.4.3 |3.4.3 3.3.3 Known to work|4.1.0 4.0.0 |4.1.0 4.0.0 3.2.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26729
[Bug tree-optimization/26731] New: Jump threading gets in the way of loops
Jump threading causes bad interactions with loops:
int f(int t, int a, int x)
{
int n, g;
if (t)
n = a;
else
n = 4;
for (g=0; ghttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=26731
[Bug tree-optimization/26731] Jump threading gets in the way of loops
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-17 17:32 --- I almost think this is also the cause for PR 26727. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||26727 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26731
[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access
--- Comment #21 from rguenth at gcc dot gnu dot org 2006-03-17 17:38 --- Subject: Bug 26721 Author: rguenth Date: Fri Mar 17 17:38:51 2006 New Revision: 112177 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112177 Log: 2006-03-17 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/26721 * builtins.c (get_pointer_alignment): For component style references adjust alignment to the component type alignment. Make sure to adjust alignment for component access of constants. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
[Bug target/26721] [4.2 Regression]: Gcc generates unaligned access
--- Comment #22 from rguenth at gcc dot gnu dot org 2006-03-17 17:39 --- This should be fixed now. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
[Bug rtl-optimization/26727] [4.2 Regression] gcc.target/powerpc/doloop-1.c fails
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-17 17:52 --- It also fails on AIX. http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg01132.html This worked in rev 112118 but failed in 112135. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|powerpc-darwin7.9.0 |powerpc-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26727
[Bug java/26720] Can't find method 'access$1(I)'
--- Comment #1 from tromey at gcc dot gnu dot org 2006-03-17 18:01 --- The bug here is that the code that handles assignments requiring an accessor method does not understand that a constant might be subject to a narrowing constant conversion. Hence it does not (e.g.) convert '0' to '(byte) 0', and thus the accessor method is not found. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26720
[Bug fortran/26716] [4.1,4.2 regression] gfortran: incorrect choice of overloaded function
--- Comment #3 from pault at gcc dot gnu dot org 2006-03-17 18:02 ---
I have a patch that fixes this and regtests OK; I will get it ready for
submission tomorrow.
Index: gcc/fortran/interface.c
===
*** gcc/fortran/interface.c (revision 112139)
--- gcc/fortran/interface.c (working copy)
*** compare_actual_formal (gfc_actual_arglis
*** 1178,1183
--- 1178,1184
gfc_actual_arglist **new, *a, *actual, temp;
gfc_formal_arglist *f;
int i, n, na;
+ bool rank_check;
actual = *ap;
*** compare_actual_formal (gfc_actual_arglis
*** 1260,1270
return 0;
}
if (!compare_parameter
! (f->sym, a->expr,
! ranks_must_agree && f->sym->as
!&& f->sym->as->type == AS_ASSUMED_SHAPE,
! is_elemental))
{
if (where)
gfc_error ("Type/rank mismatch in argument '%s' at %L",
--- 1261,1274
return 0;
}
+ rank_check = where != NULL
+&& !is_elemental
+&& f->sym->as
+&& (f->sym->as->type == AS_ASSUMED_SHAPE
+ || f->sym->as->type == AS_DEFERRED);
+
if (!compare_parameter
! (f->sym, a->expr, ranks_must_agree || rank_check, is_elemental))
{
if (where)
gfc_error ("Type/rank mismatch in argument '%s' at %L",
*** check_intents (gfc_formal_arglist * f, g
*** 1595,1603
void
gfc_procedure_use (gfc_symbol * sym, gfc_actual_arglist ** ap, locus * where)
{
- int ranks_must_agree;
- ranks_must_agree = !sym->attr.elemental && (sym->attr.contained
- || sym->attr.if_source == IFSRC_IFBODY);
/* Warn about calls with an implicit interface. */
if (gfc_option.warn_implicit_interface
--- 1599,1604
*** gfc_procedure_use (gfc_symbol * sym, gfc
*** 1606,1612
sym->name, where);
if (sym->attr.if_source == IFSRC_UNKNOWN
! || !compare_actual_formal (ap, sym->formal, ranks_must_agree,
sym->attr.elemental, where))
return;
--- 1607,1613
sym->name, where);
if (sym->attr.if_source == IFSRC_UNKNOWN
! || !compare_actual_formal (ap, sym->formal, 0,
sym->attr.elemental, where))
return;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26716
[Bug java/26720] Can't find method 'access$1(I)'
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-17 18:06 --- One potential fix is to call try_builtin_assignconv in nested_field_access_fix or the like. I haven't tried this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26720
[Bug libstdc++/26513] make_exports.pl hardcoded to build nm
--- Comment #3 from bkoz at gcc dot gnu dot org 2006-03-17 18:29 --- Solution is to make make_exports.pl.in with NM_FOR_TARGET substition for current uses of 'nm' This is done with other scripts. This is low-priority, but this is enough of a hint so that you should be able to try and fix it. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26513
[Bug libstdc++/26497] libstdc++-v3: configure: test: -lt: unary operator expected
--- Comment #7 from bkoz at gcc dot gnu dot org 2006-03-17 18:31 --- linking tests are native only, because finding all the support objects needed for all the various platforms (crt.o, etc.) is hard. At least, this is the traditional objection. fixing glibcxx_gnu_ld_version still seems possible, see earlier comment. Suggest you try this approach... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26497
[Bug libstdc++/25608] g++ miscompiles gcjx
--- Comment #18 from bkoz at gcc dot gnu dot org 2006-03-17 18:33 --- is this still an active issue, or was it indicative of some temporary or transient thing in the gcc sources? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25608
[Bug c/26732] New: Rejects valid code at different optimization levels.
#include
int
bar(baz)
struct { int foo; } baz;
{
return baz.foo;
}
int main (void)
{
struct { int foo; } baz;
baz.foo = 0xdeadbeef;
if (bar(baz) != 0xdeadbeef)
abort();
}
Compiling at O2 results in no error.
compiling at O3 results in the following error :
fail.c:35: error: incompatible type for argument 1 of 'bar'
This is a regression from 3.4.x .Have not checked this for mainline yet.
--
Summary: Rejects valid code at different optimization levels.
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ramana dot radhakrishnan at codito dot com
GCC host triplet: i686-linux-gnu
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26732
[Bug c/26732] Accepts invalid code at different optimization levels.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-17 18:43 --- This is invalid code, well undefined at best. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26732
[Bug c/26732] Accepts invalid code at different optimization levels.
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-17 18:45 --- Related to PR 22249. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26732
[Bug c/26732] Accepts invalid code at different optimization levels.
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-17 18:47 --- This is all: http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00772.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26732
[Bug libstdc++/25409] STL mt_allocator crash in global construcutor
--- Comment #5 from bkoz at gcc dot gnu dot org 2006-03-17 19:04 --- Created an attachment (id=11064) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11064&action=view) example of how to do testcase Explicitly use __mt_alloc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25409
[Bug libstdc++/25409] STL mt_allocator crash in global construcutor
--- Comment #6 from bkoz at gcc dot gnu dot org 2006-03-17 19:10 --- I'm closing this. I cannot reproduce it. In addition, the submitted testcase is not sufficient: it has a complicated directory structure, makefiles, etc etc. Also, does not demonstrate the so-called bug... Please read: http://gcc.gnu.org/bugs.html For the record, using -pthread is mandatory for pthread code. In fact, on mainline this is now more obvious due to the weakref patches. I am sympathetic to the problems with the gcc manual, which seem to indicate that -pthread is a arch-specific flag. I suggest you file a new bug report about this specific issue. best, benjamin -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25409
[Bug libstdc++/26733] New: move semantics vs. debug mode
-- Summary: move semantics vs. debug mode Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bkoz at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26733
[Bug libstdc++/26733] move semantics vs. debug mode
--- Comment #1 from bkoz at gcc dot gnu dot org 2006-03-17 19:15 --- On libstdcxx_so_7-branch, there is preliminary support for move semantics. These patches have some issues: 1) _GLIBCXX_STD_MOVE not listed in any ChangeLog entry... 2) new fails in debug mode. First pointed out here: http://gcc.gnu.org/ml/libstdc++/2006-03/msg00034.html >From that: While testing this, I noticed some issues with the current _GLIBCXX_STD_MOVE related code in debug mode, regardless of symbol versioning strategy. (Is this vestigial from when debug mode was not nested?) For the time being, I am going to punt on this, as I have a couple other patches to go. I attach the current fails for both, which are the same. Since this stuff is not on mainline, I am not quite sure it's been tested in debug mode, and I forgot to make debug mode baselines before I started with this stuff. So, I'll return to this issue shortly. FAIL: 20_util/utility/pair/moveable.cc execution test FAIL: 21_strings/basic_string/element_access/char/empty.cc execution test FAIL: 21_strings/basic_string/element_access/wchar_t/empty.cc execution test FAIL: 23_containers/deque/moveable.cc execution test FAIL: 23_containers/deque/resize/moveable.cc execution test FAIL: 23_containers/list/moveable.cc execution test FAIL: 23_containers/map/moveable.cc execution test FAIL: 23_containers/multimap/moveable.cc execution test FAIL: 23_containers/multiset/moveable.cc execution test FAIL: 23_containers/set/moveable.cc execution test FAIL: 23_containers/vector/moveable.cc execution test FAIL: 23_containers/vector/resize/moveable.cc execution test It turns out that these fails were pre-existing. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26733
[Bug libstdc++/26733] move semantics vs. debug mode
--- Comment #2 from bkoz at gcc dot gnu dot org 2006-03-17 19:16 --- Created an attachment (id=11065) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11065&action=view) patch to test debug mode This runs the testsuite with -D_GLIBCXX_DEBUG. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26733
[Bug libstdc++/26733] move semantics vs. debug mode
--- Comment #3 from pcarlini at suse dot de 2006-03-17 19:48 --- (In reply to comment #1) > On libstdcxx_so_7-branch, there is preliminary support for move semantics. > > These patches have some issues: > > 1) _GLIBCXX_STD_MOVE not listed in any ChangeLog entry... > 2) new fails in debug mode. Benjamin, I suspect the issues are related. Definitely, _GLIBCXX_STD_MOVE predates the latest version of debug mode: I had to quickly hack it on the occasion of the 2005-12-23 merge, to avoid fails together with the first version of the nested debug mode. I think it should be simply updated consistently with the current version. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26733
[Bug c/26732] Accepts invalid code at different optimization levels.
--- Comment #4 from joseph at codesourcery dot com 2006-03-17 19:48 --- Subject: Re: Accepts invalid code at different optimization levels. Bug 16876 is a related case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26732
[Bug tree-optimization/26731] Jump threading gets in the way of loops
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-03-17 20:02 --- Confirmed. Though SCEV should be taught to handle this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-17 20:02:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26731
[Bug target/26734] New: GCC cannot bootstrap on IA64 HP-UX
The compiler builds but when it tries to build libgcc I get a bunch of ICEs.
Here is a small test case that will not compile with -O2 on ia64-hp-hpux11.23
with the ToT compiler:
extern int c;
long long __negti2 () { return (-c); }
I believe the problem is due to the IA64 speculation changes that Maxim checked
in.
--
Summary: GCC cannot bootstrap on IA64 HP-UX
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sje at cup dot hp dot com
GCC host triplet: ia64-hp-hpux11.23
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26734
[Bug target/26734] [4.2 Regression] GCC cannot bootstrap on IA64 HP-UX
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |blocker GCC host triplet|ia64-hp-hpux11.23 | GCC target triplet||ia64-hp-hpux11.23 Keywords||build Summary|GCC cannot bootstrap on IA64|[4.2 Regression] GCC cannot |HP-UX |bootstrap on IA64 HP-UX Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26734
[Bug libfortran/26735] New: -fconvert=swap and implied open
$ cat conv-implied-open.f90 program main implicit none integer (kind=8) :: i1, i2, i3 write (10) 1_8 close (10) open (10,status="old", form="unformatted", access="direct", recl=8) read (10,rec=1) i1 read (10,rec=2) i2 read (10,rec=3) i3 print '(3Z16,1X)',i1,i2,i3 end program main $ gfortran conv-implied-open.f90 $ ./a.out 8 1 8 $ gfortran -fconvert=swap conv-implied-open.f90 $ ./a.out 800 100 800 The second call is incorrect. The lack of an open statement means that the information about the byte-swapping isn't picked up. This is not really all that serious, because I suspect most people will give their files descriptive names if they want to move them across architectures. -- Summary: -fconvert=swap and implied open Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26735
[Bug fortran/20618] Variable format expressions not supported
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-03-17 21:12 --- Following the discussion on comp.lang.fortran on this subject, I'm tempted to mark this WONTFIX. This feature can cause a lot of headaches to implement and is of questionable semantics. Any objections? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20618
[Bug target/26734] [4.2 Regression] GCC cannot bootstrap on IA64 HP-UX
--- Comment #1 from mkuvyrkov at gcc dot gnu dot org 2006-03-17 21:16
---
(In reply to comment #0)
> The compiler builds but when it tries to build libgcc I get a bunch of ICEs.
> Here is a small test case that will not compile with -O2 on ia64-hp-hpux11.23
> with the ToT compiler:
>
> extern int c;
> long long __negti2 () { return (-c); }
>
> I believe the problem is due to the IA64 speculation changes that Maxim
> checked
> in.
Unfortunately, I don't have access to HP-UX and the bug doesn't appear on
ia64-linux, so can you please provide some more information for the failure
like backtrace.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26734
Re: [Bug target/26734] [4.2 Regression] GCC cannot bootstrap on IA64 HP-UX
On Mar 17, 2006, at 4:16 PM, mkuvyrkov at gcc dot gnu dot org wrote: Unfortunately, I don't have access to HP-UX and the bug doesn't appear on ia64-linux, so can you please provide some more information for the failure like backtrace. A cross compile will most likely reproduce it. -- Pinski
[Bug target/26734] [4.2 Regression] GCC cannot bootstrap on IA64 HP-UX
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-17 21:19 --- Subject: Re: [4.2 Regression] GCC cannot bootstrap on IA64 HP-UX On Mar 17, 2006, at 4:16 PM, mkuvyrkov at gcc dot gnu dot org wrote: > > Unfortunately, I don't have access to HP-UX and the bug doesn't appear > on > ia64-linux, so can you please provide some more information for the > failure > like backtrace. A cross compile will most likely reproduce it. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26734
[Bug target/26734] [4.2 Regression] GCC cannot bootstrap on IA64 HP-UX
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-17 21:20 --- hmm, I get: options.c:3863: error: `MASK_ILP32' undeclared here (not in a function) or was there a fix for this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26734
[Bug target/26734] [4.2 Regression] GCC cannot bootstrap on IA64 HP-UX
--- Comment #4 from sje at cup dot hp dot com 2006-03-17 21:25 --- I already fixed the problem in comment 3 with an 'obvious' checkin to config/ia64/ia64.opts. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26734
[Bug target/26734] [4.2 Regression] GCC cannot bootstrap on IA64 HP-UX
--- Comment #5 from sje at cup dot hp dot com 2006-03-17 21:47 --- The debugger shows: (gdb) p debug_rtx(*unused_listp) (deps_list 34 (nil) 0 [0x0]) (gdb) p debug_rtx(prev_link) (UnKnown Unknown) When I print unused_insn_list I get a long RTL that I couldn't capture. Here is a backtrace: #0 internal_error (gmsgid=0x40f8228 "in %s, at %s:%d") at /proj/opensrc/nightly/src/trunk/gcc/diagnostic.c:586 #1 0x49c5b10:0 in fancy_abort ( file=0x41141e0 "/proj/opensrc/nightly/src/trunk/gcc/lists.c", line=60, function=0x41141d0 "free_list") at /proj/opensrc/nightly/src/trunk/gcc/diagnostic.c:642 #2 0x4effe00:0 in free_list (listp=0x401673c4, unused_listp=0x400525f0) at /proj/opensrc/nightly/src/trunk/gcc/lists.c:57 #3 0x4f00b20:0 in free_DEPS_LIST_list (listp=0x401673c4) at /proj/opensrc/nightly/src/trunk/gcc/lists.c:207 #4 0x56bceb0:0 in schedule_insn (insn=0x6f4b76c0) at /proj/opensrc/nightly/src/trunk/gcc/haifa-sched.c:1173 #5 0x56c7bd0:0 in schedule_block (target_bb=0x70c8, rgn_n_insns1=7) at /proj/opensrc/nightly/src/trunk/gcc/haifa-sched.c:2515 #6 0x581c4d0:0 in schedule_ebb (head=0x6f4b7a80, tail=0x6f4b7ae0) at /proj/opensrc/nightly/src/trunk/gcc/sched-ebb.c:512 #7 0x581d1f0:0 in schedule_ebbs () at /proj/opensrc/nightly/src/trunk/gcc/sched-ebb.c:613 #8 0x53caa40:0 in ia64_reorg () at /proj/opensrc/nightly/src/trunk/gcc/config/ia64/ia64.c:8498 #9 0x5804e20:0 in rest_of_handle_machine_reorg () at /proj/opensrc/nightly/src/trunk/gcc/reorg.c:3816 #10 0x529e450:0 in execute_one_pass (pass=0x4003151c) at /proj/opensrc/nightly/src/trunk/gcc/passes.c:860 #11 0x529ea10:0 in execute_pass_list (pass=0x4003151c) at /proj/opensrc/nightly/src/trunk/gcc/passes.c:907 #12 0x529eab0:0 in execute_pass_list (pass=0x4003075c) at /proj/opensrc/nightly/src/trunk/gcc/passes.c:908 #13 0x529eab0:0 in execute_pass_list (pass=0x40030728) at /proj/opensrc/nightly/src/trunk/gcc/passes.c:908 #14 0x44a9960:0 in tree_rest_of_compilation (fndecl=0x6f4ae100) at /proj/opensrc/nightly/src/trunk/gcc/tree-optimize.c:418 #15 0x4216580:0 in c_expand_body (fndecl=0x6f4ae100) at /proj/opensrc/nightly/src/trunk/gcc/c-decl.c:6689 #16 0x540da00:0 in cgraph_expand_function (node=0x6f3f1480) at /proj/opensrc/nightly/src/trunk/gcc/cgraphunit.c:1102 #17 0x540e2b0:0 in cgraph_expand_all_functions () at /proj/opensrc/nightly/src/trunk/gcc/cgraphunit.c:1167 #18 0x54109f0:0 in cgraph_optimize () at /proj/opensrc/nightly/src/trunk/gcc/cgraphunit.c:1435 #19 0x4222d80:0 in c_write_global_declarations () at /proj/opensrc/nightly/src/trunk/gcc/c-decl.c:7804 #20 0x51651a0:0 in compile_file () at /proj/opensrc/nightly/src/trunk/gcc/toplev.c:1012 #21 0x516af30:0 in do_compile () at /proj/opensrc/nightly/src/trunk/gcc/toplev.c:1970 #22 0x516b0e0:0 in toplev_main (argc=3, argv=0x7778) at /proj/opensrc/nightly/src/trunk/gcc/toplev.c:2002 #23 0x43f2280:0 in main (argc=3, argv=0x7778) at /proj/opensrc/nightly/src/trunk/gcc/main.c:35 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26734
[Bug target/26734] [4.2 Regression] GCC cannot bootstrap on IA64 HP-UX
--- Comment #6 from sje at cup dot hp dot com 2006-03-17 22:34 --- I applied the patch that Maxim created for PR 26725 but it did not seem to help this problem. I verified the problem happened on ia64-hp-hpux11.23 in LP64 mode as well as ILP32 mode so that makes it more surprising that it doesn't happen on IA64 Linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26734
Re: [Bug libstdc++/25608] g++ miscompiles gcjx
"bkoz at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | is this still an active issue, or was it indicative of some temporary or | transient thing in the gcc sources? Now, I get a "segmentation fault" -- instead of dead lock. gcjx is compiled with mainline GCC/g++. I was trying to compile classptah. Adding generated files in builddir '..'. /home/gdr/bin/gcjx -encoding UTF-8 -classpath .: -d . @classes make[1]: *** [compile-classes] Segmentation fault make[1]: Leaving directory `/home/gdr/build/classpath/lib' -- Gaby
[Bug libstdc++/25608] g++ miscompiles gcjx
--- Comment #19 from gdr at integrable-solutions dot net 2006-03-17 23:37 --- Subject: Re: g++ miscompiles gcjx "bkoz at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | is this still an active issue, or was it indicative of some temporary or | transient thing in the gcc sources? Now, I get a "segmentation fault" -- instead of dead lock. gcjx is compiled with mainline GCC/g++. I was trying to compile classptah. Adding generated files in builddir '..'. /home/gdr/bin/gcjx -encoding UTF-8 -classpath .: -d . @classes make[1]: *** [compile-classes] Segmentation fault make[1]: Leaving directory `/home/gdr/build/classpath/lib' -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25608
[Bug target/26734] [4.2 Regression] GCC cannot bootstrap on IA64 HP-UX
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-03-17 23:39 --- t.c: In function '__negti2': t.c:4: internal compiler error: in add_forw_dep, at sched-deps.c:1644 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. (deps_list 1815750704 (nil) 131064191212584960 [0x1d1a230]) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26734
[Bug target/26734] [4.2 Regression] GCC cannot bootstrap on IA64 HP-UX
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-03-17 23:57 --- Confirmed, with a cross compiler. here is the backtrace: #1 0x0083e49c in add_forw_dep (to=0x1d1a230, link=0x1db9100) at ../../gcc/sched-deps.c:1644 #2 0x0083e8f4 in compute_forward_dependences (head=0x1d1a640, tail=0x1db7958) at ../../gcc/sched-deps.c:1700 #3 0x008418d4 in schedule_ebb (head=0x1d1a640, tail=0x1db7958) at ../../gcc/sched-ebb.c:459 #4 0x00841f30 in schedule_ebbs () at ../../gcc/sched-ebb.c:613 #5 0x006afbcc in ia64_reorg () at ../../gcc/config/ia64/ia64.c:8498 #6 0x008399b0 in rest_of_handle_machine_reorg () at ../../gcc/reorg.c:3816 #7 0x006415c0 in execute_one_pass (pass=0x953dcc) at ../../gcc/passes.c:860 #8 0x006417c4 in execute_pass_list (pass=0x953dcc) at ../../gcc/passes.c:907 #9 0x006417ec in execute_pass_list (pass=0x952a80) at ../../gcc/passes.c:908 #10 0x006417ec in execute_pass_list (pass=0x952a4c) at ../../gcc/passes.c:908 #11 0x0011d924 in tree_rest_of_compilation (fndecl=0x1db4000) at ../../gcc/tree-optimize.c:418 #12 0x000289dc in c_expand_body (fndecl=0x1db4000) at ../../gcc/c-decl.c:6689 #13 0x006c8e0c in cgraph_expand_function (node=0x1db5000) at ../../gcc/cgraphunit.c:1102 #14 0x006c9180 in cgraph_expand_all_functions () at ../../gcc/cgraphunit.c:1167 #15 0x006c9fb8 in cgraph_optimize () at ../../gcc/cgraphunit.c:1435 #16 0x0002c8f8 in c_write_global_declarations () at ../../gcc/c-decl.c:7804 #17 0x005c7fbc in compile_file () at ../../gcc/toplev.c:1012 #18 0x005ca6cc in do_compile () at ../../gcc/toplev.c:1970 #19 0x005ca768 in toplev_main (argc=3, argv=0xbd28) at ../../gcc/toplev.c:2002 #20 0x000db710 in main (argc=3, argv=0xbd28) at ../../gcc/main.c:35 So this is definitely a target issue. -- 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-03-17 23:57:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26734
[Bug fortran/26509] incorrect behaviour of error-handler for direct access write
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2006-03-18 01:56 --- Subject: Bug 26509 Author: jvdelisle Date: Sat Mar 18 01:56:07 2006 New Revision: 112198 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112198 Log: 2006-03-17 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/26509 * libgfortran.h: Add ERROR_DIRECT_EOR. * runtime/error.c (translate_error): Add translation for new error. * io/transfer.c (write_buf): Add check for EOR when mode is direct access. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/error.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509
[Bug fortran/26509] incorrect behaviour of error-handler for direct access write
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2006-03-18 01:59 --- Subject: Bug 26509 Author: jvdelisle Date: Sat Mar 18 01:59:50 2006 New Revision: 112199 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112199 Log: 2006-03-17 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/26509 gfortran.dg/write_direct_eor.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/write_direct_eor.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509
[Bug c++/26739] New: [4.2 regression] ICE in g++.old-deja/g++.pt/friend36.C
The testcase g++.old-deja/g++.pt/friend36.C ICEs on mainline: friend36.C: In instantiation of 'S': friend36.C:12: instantiated from here friend36.C:9: error: redefinition of 'template void f(T)' friend36.C:4: error: 'template void f(T)' previously declared here friend36.C:9: internal compiler error: tree check: expected var_decl or function_decl or type_decl or template_decl, have error_mark in tsubst_friend_function, at cp/pt.c:5286 Please submit a full bug report, [etc.] -- Summary: [4.2 regression] ICE in g++.old-deja/g++.pt/friend36.C Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code, error-recovery Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26739
[Bug c++/26740] New: [4.2 regression] ICE taking the address of a bound member function
The following testcases cause ICEs on mainline: g++.old-deja/g++.bugs/900213_03.C g++.old-deja/g++.other/pmf2.C g++.old-deja/g++.other/pmf7.C They all crash at the same position: pmf2.C: In function 'void f()': pmf2.C:17: error: ISO C++ forbids taking the address of a bound member function to form a pointer to member function. Say '&S::f' pmf2.C:17: internal compiler error: in build_offset_ref, at cp/init.c:1353 Please submit a full bug report, [etc.] -- Summary: [4.2 regression] ICE taking the address of a bound member function Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code, error-recovery Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26740
[Bug c++/26739] [4.2 regression] ICE in g++.old-deja/g++.pt/friend36.C
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26739
[Bug c++/26740] [4.2 regression] ICE taking the address of a bound member function
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26740
[Bug c++/26740] [4.2 regression] ICE taking the address of a bound member function
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-18 03:08 ---
Grrr. Well confirmed. The reason why this does show up in the testresults is
because of the follow:
fmp = &ptr->function_member; // { dg-error "" }
pmf = & pf->f; // { dg-error "" } not a valid pmf expression
&a.f; // { dg-error "" } overloaded
Meaning dg-error should really take an argument instead of just a null string.
--
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-03-18 03:08:59
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26740
[Bug c++/26740] [4.2 regression] ICE taking the address of a bound member function
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-18 03:09 --- So who ever fixes this bug, please also fix the testsuite so the testsuite will show the ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26740
[Bug c++/26739] [4.2 regression] ICE in g++.old-deja/g++.pt/friend36.C
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-18 03:11 ---
Confirmed.
friend void f(T) {} // { dg-error "" } redeclaration
Grrr oh well.
--
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-03-18 03:11:09
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26739
[Bug fortran/26741] New: Elemental functions not permitted in initialization expressions
In testing gfortran's capacity to deal with iso_varying_string, it was found
that the error "Specification function 'len_' at (1) must be PURE" was produced
- see testcase below. This is obviously incorrect because elemental functions
are pure.
The patch and the testcase appear below.
Paul Thomas
! { dg-do compile }
! Tests the fix for elemental functions not being allowed in
! specification expressions in pure procedures.
!
! Testcase from iso_varying_string by Rich Townsend <[EMAIL PROTECTED]>
! The allocatable component has been changed to a pointer for this testcase.
!
module iso_varying_string
type varying_string
private
character(LEN=1), dimension(:), pointer :: chars
end type varying_string
interface len
module procedure len_
end interface len
contains
pure function char_auto (string) result (char_string)
type(varying_string), intent(in) :: string
character(LEN=len(string)) :: char_string ! Error was here
end function char_auto
elemental function len_ (string) result (length)
type(varying_string), intent(in) :: string
integer :: length
end function len_
end module iso_varying_string
Index: gcc/fortran/expr.c
===
*** gcc/fortran/expr.c (revision 112139)
--- gcc/fortran/expr.c (working copy)
*** external_spec_function (gfc_expr * e)
*** 1636,1642
return FAILURE;
}
! if (!f->attr.pure)
{
gfc_error ("Specification function '%s' at %L must be PURE", f->name,
&e->where);
--- 1636,1642
return FAILURE;
}
! if (!f->attr.pure && !f->attr.elemental)
{
gfc_error ("Specification function '%s' at %L must be PURE", f->name,
&e->where);
--
Summary: Elemental functions not permitted in initialization
expressions
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: pault at gcc dot gnu dot org
ReportedBy: pault at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26741
[Bug other/21866] profiledbootstrap on gcc4 - release fails
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-18 06:05 --- Since this worked for me and this is only report of this failure, something must be up with the source you used. Closing as works for me. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21866
[Bug other/25178] installation of gfortran failed after deveral trys
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-18 06:07 --- We do not support the binaries. Please use the fortran mailing list for these binaries. [EMAIL PROTECTED] is the place you should be reporting problems. Note these binaries work for a lot of people. -- 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=25178
[Bug bootstrap/21698] creating first stage compiler
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-18 06:20 --- crosstools and the crossgcc list is the best place to ask questions like this really. Second sysroot can be changed at runtime now. So this is not a bug and closing as such. -- 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=21698
[Bug target/21737] long double incorrect result
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-18 06:22 --- As I mentioned 4.0.0 works for me so closing as fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21737
[Bug gcov/profile/21388] gcov-io.h compilation warning
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-18 06:25 --- Since this does not show up in 4.0.0 closing as won't fix as 3.4.6 was the last release. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21388
[Bug libgomp/26308] [4.2 Regression] libgomp bootstrap failure on Tru64 UNIX V4.0F
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-18 06:30 --- Was this fixed? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build Summary|libgomp bootstrap failure on|[4.2 Regression] libgomp |Tru64 UNIX V4.0F|bootstrap failure on Tru64 ||UNIX V4.0F Target Milestone|--- |4.2.0 Version|unknown |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26308
[Bug other/25178] installation of gfortran failed after deveral trys
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-03-18 06:31 --- I know for sure the binaries do not work on Win98. This was reported before. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25178
[Bug libgomp/26308] [4.2 Regression] libgomp bootstrap failure on Tru64 UNIX V4.0F
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-18 06:33 --- PR 26161 might had fixed this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||26161 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26308
[Bug rtl-optimization/17228] ICE when compiling the CGAL branch of fgsd ( i486 Linux g++ 3.3.4 debian )
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-18 06:34 --- (In reply to comment #4) > I can reproduce it with 3.3.4 (Debian 1:3.3.4-9) on alpha-linux. Seems to be > some kind of memory corruption, trying to reduce the test case fails. Any news on that reduction? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||falk at debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17228
[Bug fortran/26741] Elemental functions not permitted in initialization expressions
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-18 06:36 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-18 06:36:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26741
[Bug rtl-optimization/26727] [4.2 Regression] gcc.target/powerpc/doloop-1.c fails
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-18 06:38 --- Confirm based on http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg01186.html If PR 26731 gets fixed, this testcase needs to be changed (or removed) as it will cause the testcase to always fail. -- 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-03-18 06:38:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26727
[Bug fortran/26716] [4.1/4.2 regression] gfortran: incorrect choice of overloaded function
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Summary|[4.1,4.2 regression]|[4.1/4.2 regression] |gfortran: incorrect choice |gfortran: incorrect choice |of overloaded function |of overloaded function Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26716
[Bug c/26742] New: force code block in default clause of switch statement
Without a code block around my "default" clause of my switch statement the
compiler can't parse the following instructions.
I'm including the text of a file which, when compiled, will run without a bug
(you will need to delete some of the local dependencies and references to
global variables). If you remove the curly braces around the switch statement's
default clause you'll find the compiler can't parse the file. The next
declaration after the default clause introduction ("default:") is "char
*myArgv[64];" and the compiler will tell you there's an error: syntax error
before "char" on that line.
(I messed with this for about 30 minutes before I figured out that it was a
curly brace thing.)
System/package info:
gcc --version: gcc (GCC) 3.3.5 (Debian 1:3.3.5-8ubuntu2.1)
here's the code:
/***
Author: William P. Henry Jr.
Name: mysh.c
Class: CS 360
Assignment: lab2
Purpose: Simulate the UNIX command prompt and command processing.
For purpose of understanding how Unix sh works by using
fork() and exec(...), also string operations.
***/
#include
#include
#include
#include
#include
#include
//contains static global variable for operations
//including a string table for commands
#include "commandGlobals.h"
#include "commandProcessing.h"
#define DIRECTORY_LOCAL
#include "directoryGlobals.h"
#define PATH_LOCAL
#include "pathGlobals.h"
#include "pathProcessing.h"
//initialize array of recognized commands (global from
//the commandGlobals.h file change the size there if you
//make any additions or removals here */
const char *cmd[] = {"mkdir", "rmdir", "ls","cd", "pwd", "creat", "rm",
"quit", "help", "?", "menu", "reload", "echo", "exit", 0};
enum commandEnums {MKDIR = 0, RMDIR, LS, CD, PWD, CREAT, RM, QUIT, HELP,
QUESTION, MENU, RELOAD, ECHO, EXIT };
int main( int argc, char **argv, char **env )
{
printf("\n*BEGIN MYSH.C MAIN\n");
initEnvironInfo(env);
printf("Home string is: %s\n", homeBuf);
printf("Path variables (in pathPointers[0-n]) are: \n");
int m = 0;
while( 0 != pathPointers[m] )
{
printf("\t%s\n", pathPointers[m++]);
}//end while more path variables, print variables
printf("PWD is: %s\n", getenv("PWD"));
int ID = 0;
char *fullInputString = malloc(256*(sizeof(char)));
char *command = malloc(256*(sizeof(char)));
char *arguments = malloc(256*(sizeof(char)));
char localBuf[256];
//used in child process
char *fullCmd = malloc(256*(sizeof(char)));
int pid = 0;
int retval = 0;
int status = 0;
while(1)
{
printf("wphix $: ");
fgets(inputLine, 256, stdin);
//copy the full input string for use passing into
//other functions, overwrite the final '\n'
//leftover from user hitting "enter"
// fullInputString[0] = '\0';
strcpy(fullInputString, inputLine);
fullInputString[strlen(fullInputString)-1] = '\0';
inputLine[strlen(inputLine)-1] = '\0';
command = strtok(inputLine, " ");
//copy all arguments after the initial command
arguments = strtok( 0, "\n");
//returns values as enumerated above
ID = findCmd(command);
switch(ID)
{
case(CD):
//printf("found %s at index %d\n", cmd[ID],
ID);
if( 0 == arguments )
{
//printf("no argument given for cd\n");
chdir(homeBuf);
localBuf[0]='\0';
if( 0 == getcwd(localBuf, 256) )
{
printf("getcwd(localBuf, 256)
failed\n");
}//end if
else
{
printf("PWD is: %s\n",
localBuf);
}//end else (so getcwd worked)
}//end if no arguments are passed
else if( 0 == chdir( arguments ) )
{
//printf("was given %s to change to\n",
arguments);
localBuf[0]='\0';
if( 0 == getcwd(localBuf, 256) )
