[Bug rtl-optimization/26587] [4.1 Regression] strict aliasing incorrectly pre-loads an array element with loops
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-03-07 10:02 ---
Reduced testcase:
extern int printf(const char *format, ...);
typedef unsigned int BF_word;
typedef BF_word BF_key[16 + 2];
static struct {
BF_key P;
} BF_current;
int main(void)
{
BF_word L, R;
BF_word tmp1, tmp2, tmp3, tmp4, *ptr;
L = R = 0;
ptr = BF_current.P;
do {
int i;
ptr += 2;
L ^= BF_current.P[0];
for (i = 0; i < 16; i += 2) {
tmp1 = L & 0xFF;
tmp3 += tmp1;
L ^= tmp3;;
}
*(ptr - 2) = L;
} while (ptr < &BF_current.P[16 + 2]);
printf("%08x %08x\n", L, R);
return 0;
}
-O2 -fno-strict-aliasing:
0001e6d4
-O2:
0001c100
-fno-ivopts does not fix it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26587
[Bug rtl-optimization/26587] [4.1 Regression] strict aliasing incorrectly pre-loads an array element with loops
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-03-07 10:12 ---
Umm, that has uninitialized vars. The following is ok wrt -Wall -Werror:
extern int printf(const char *, ...);
typedef unsigned int BF_word;
typedef BF_word BF_key[16 + 2];
static struct {
BF_key P;
} BF_current;
int main(void)
{
BF_word L;
BF_word tmp4, *ptr;
BF_word i;
for (i = 0; i < 16 + 2; i++)
BF_current.P[i] = i * 0x98765432;
L = 0;
ptr = BF_current.P;
do {
ptr += 2;
L ^= BF_current.P[0];
tmp4 = L >> 24;
L = tmp4 ^ BF_current.P[16 + 1];
*(ptr - 2) = L;
} while (ptr < &BF_current.P[16 + 2]);
printf("%08x\n", L);
return 0;
}
and prints 1fdb9752 vs. 1fdb974d.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26587
[Bug c/26591] New: Spurious parse error message with register struct .
Derived from gdb/testsuite/gdb.base/store.c :
struct s_3 { short s[3]; } z_3, s_3;
struct s_3
add_struct_3 (struct s_3 s)
{
int i;
for (i = 0; i < sizeof (s) / sizeof (s.s[0]); i++)
{
s.s[i] = s.s[i] + s.s[i];
}
return s;
}
struct s_3
wack_struct_3 (void)
{
int i; register struct s_3 u = z_3;
for (i = 0; i < sizeof (s_3) / sizeof (s_3.s[0]); i++) { s_3.s[i] = i + 1; }
u = add_struct_3 (u);
return u;
}
Compiling this with arm-none-eabi-gcc gives :
try.c: In function 'wack_struct_3':
try.c:41: error: address of register variable 'u' requested
3.4.5 and 4.0 seem to compile this ok. Its possibly related to the fix for
#18160 .
--
Summary: Spurious parse error message with register struct .
Product: gcc
Version: 4.1.0
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 build triplet: i686-linux-gnu
GCC host triplet: i686-linux-gnu
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26591
[Bug tree-optimization/26587] [4.1 Regression] strict aliasing incorrectly pre-loads an array element with loops
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-03-07 10:39 --- With -fno-ivopts -fno-tree-vrp tree-optimizers produce the same for both 4.1.0 and 4.2.0 until tree loop-invariant-motion, which does the wrong transformation because of bogus alias information: :; # TMT.6_23 = PHI ; # ptr_3 = PHI <&BF_current.P[0](3), ptr_9(5)>; # L_2 = PHI <0(3), L_14(5)>; :; ptr_9 = ptr_3 + 8B; # VUSE ; D.1297_10 = BF_current.P[0]; L_11 = L_2 ^ D.1297_10; tmp4_12 = L_11 >> 24; # VUSE ; D.1298_13 = BF_current.P[17]; L_14 = tmp4_12 ^ D.1298_13; D.1299_15 = ptr_9 - 8B; # TMT.6_25 = V_MAY_DEF ; *D.1299_15 = L_14; if (ptr_9 < &BF_current.P[18]) goto ; else goto ; the store to *D.1299_15 kills BF_current_21, which we don't notice. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org Component|rtl-optimization|tree-optimization Keywords||alias http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26587
[Bug tree-optimization/26587] [4.1/4.2 Regression] strict aliasing incorrectly pre-loads an array element with loops
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-03-07 10:41 --- The problem is latent on the mainline with -fno-tree-salias. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.1.0 |4.1.0 4.2.0 Known to work|4.2.0 4.0.3 |4.0.3 Summary|[4.1 Regression] strict |[4.1/4.2 Regression] strict |aliasing incorrectly pre- |aliasing incorrectly pre- |loads an array element with |loads an array element with |loops |loops http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26587
[Bug tree-optimization/26587] [4.1/4.2 Regression] strict aliasing incorrectly pre-loads an array element with loops
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-03-07 10:43 --- With -O2 -fno-ivopts -fno-tree-vrp -fno-tree-salias -fno-strict-aliasing we correctly get :; # BF_current_23 = PHI ; # ptr_3 = PHI <&BF_current.P[0](5), ptr_9(7)>; # L_2 = PHI <0(5), L_14(7)>; :; ptr_9 = ptr_3 + 8B; # VUSE ; D.1541_10 = BF_current.P[0]; L_11 = L_2 ^ D.1541_10; tmp4_12 = L_11 >> 24; # VUSE ; D.1542_13 = BF_current.P[17]; L_14 = tmp4_12 ^ D.1542_13; D.1543_15 = ptr_9 - 8B; # BF_current_24 = V_MAY_DEF ; *D.1543_15 = L_14; if (ptr_9 < &BF_current.P[18]) goto ; else goto ; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26587
[Bug c/26591] Spurious parse error message with register struct .
--- Comment #1 from ramana dot radhakrishnan at codito dot com 2006-03-07 10:49 --- Occurs with arm-none-eabi-gcc 4.1.0 -branch with yesterday's update. -- ramana dot radhakrishnan at codito dot com changed: What|Removed |Added Summary|Spurious parse error message|Spurious parse error message |with register struct . |with register struct . http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26591
[Bug tree-optimization/26587] [4.1/4.2 Regression] strict aliasing incorrectly pre-loads an array element with loops
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-03-07 11:02 ---
Pointed-to sets for pointers in main
ptr_8, points-to vars: { BF_current }
ptr_3, points-to vars: { BF_current }
ptr_9, points-to vars: { BF_current }
D.1543_15, is dereferenced, points-to anything
D.1544_16, points-to vars: { BF_current }
is wrong because of:
handle_ptr_arith (struct constraint_expr lhs, tree expr)
{
tree op0, op1;
struct constraint_expr base, offset;
if (TREE_CODE (expr) != PLUS_EXPR)
return false;
and
(gdb) call debug_tree(expr)
unit size
align 32 symtab 0 alias set -1 precision 32 min max
pointer_to_this >
sizes-gimplified unsigned SI size unit size
align 32 symtab 0 alias set -1>
arg 0
visited var def_stmt
version 9
ptr-info 0x4021f740>
arg 1 constant
invariant 8>>
I have a fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26587
[Bug c++/26592] New: g++ ICE in cp_expr_size expanding template with inline assembly
ICE in this version of G++, my previous Debian version worked.
Compiling a method of a class that subclasses a template that
contains inline assembly code (used for atomic instructions),
see complete code snippet below. Command line "g++ -c foo.c"
yields error message:
g++_bug.cxx: In member function void LatchC::latch(int) volatile:
g++_bug.cxx:34: internal compiler error: in cp_expr_size, at
cp/cp-objcp-common.c:101
template
class AtomicM
{
public:
AtomicM(T i = T()) : val(i) { }
AtomicM(const AtomicM& from) : val(from.val) { }
AtomicM& operator=(const AtomicM& from)
{ exchange(from.val); return *this; }
inline T exchangeCmp(T e, T comparand) volatile
{
register int eax asm("eax") = comparand;
__asm__ __volatile__(
"lock; cmpxchg %2,%0"
: "+m" (val)
, "+a" (eax)
: "q" (e)
: "cc"
);
return (T)eax;
}
protected:
volatile T val;
};
class LatchC
: private AtomicM
{
public:
inline void latch(int i) volatile
{
while (exchangeCmp(i, 0) != 0)
yield(1);
}
void enter();
private:
static void yield(int ms);
};
void
LatchC::enter()
{
latch(1);
}
--
Summary: g++ ICE in cp_expr_size expanding template with inline
assembly
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cjh at managesoft dot com
GCC build triplet: i486-pc-linux-gnu
GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26592
[Bug tree-optimization/26587] [4.1/4.2 Regression] strict aliasing incorrectly pre-loads an array element with loops
--- Comment #10 from patchapp at dberlin dot org 2006-03-07 12:20 --- Subject: Bug number PR tree-optimization/26587 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00357.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26587
[Bug c++/26592] g++ ICE in cp_expr_size expanding template with inline assembly
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-03-07 12:26 --- I already entered your previous report into the database, but forgot to notify you, sorry. *** This bug has been marked as a duplicate of 26577 *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26592
[Bug c++/26577] [4.0/4.1/4.2 regression] ICE in cp_expr_size with volatile and call to static
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-03-07 12:26 --- *** Bug 26592 has been marked as a duplicate of this bug. *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||cjh at managesoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26577
[Bug c/26591] Spurious parse error message with register struct .
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-07 12:28 --- *** This bug has been marked as a duplicate of 26004 *** -- 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=26591
[Bug c/26004] [4.1/4.2 Regression] gcc errors on valid code [SVO]
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-03-07 12:28 --- *** Bug 26591 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||ramana dot radhakrishnan at ||codito dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26004
[Bug libgcj/26593] New: libgcjawt should be built even if the gtk peers aren't
Currently, libgcjawt (used, among other things, by OpenOffice.org) is built only if the gtk peers are used. Looks like the classpath guys have already fixed it to work with other peers, but the Makefiles need updating. -- Summary: libgcjawt should be built even if the gtk peers aren't Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bero at arklinux dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26593
[Bug libgcj/26593] libgcjawt should be built even if the gtk peers aren't
--- Comment #1 from bero at arklinux dot org 2006-03-07 13:06 --- Created an attachment (id=10980) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10980&action=view) Build libgcjawt when using Qt peers Attaching patch, currently tested only in a "It compiles, therefore it works(R)" fashion. [(R) indicates a registered trademark of Microsoft's QA department] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26593
[Bug libgcj/26593] libgcjawt should be built even if the gtk peers aren't
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-07 13:35 --- Hmm, shouldn't libgcjawt built even without the peers selected as someone might have their own peers to install after GCJ was install? (this is directed towards the reporter) -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26593
[Bug tree-optimization/26587] [4.1/4.2 Regression] strict aliasing incorrectly pre-loads an array element with loops
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-03-07 14:26 --- Patches posted. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-03-07 02:08:20 |2006-03-07 14:26:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26587
[Bug libfortran/26595] New: gfortran - jump to error label not working correctly after reading EOF
The second read should jump to the label with out comment. [dranta:~/tests/gfortran-D] dir% gfortran -o write29 write29.f [dranta:~/tests/gfortran-D] dir% write29 At line 7 of file write29.f Fortran runtime error: End of file [dranta:~/tests/gfortran-D] dir% cat write29.f program test dimension idata(1011) open(unit=11,form='unformatted') read(11,end=1000 )idata call abort() 1000 continue read(11,err=1001 )idata call abort() 1001 continue close(11,status='delete') stop end -- Summary: gfortran - jump to error label not working correctly after reading EOF Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lanl dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26595
[Bug c++/26596] New: ICE for precompiling c++ header
When precompiling stdc++.h during a bootstrap (make boostrap), the c++ compiler crashes with an ICE. Here is the relevant part of the log: ... make[2]: Entering directory `/home/arend/tmp/build-gcc/i686-pc-cygwin/libstdc++-v3/include' sed -e '/^#/s/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_][ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*\)/_GLIBCXX_\1/g' \ -e 's/_GLIBCXX_SUPPORTS_WEAK/__GXX_WEAK__/g' \ -e 's,^#include "\(.*\)",#include ,g' \ < /home/arend/tmp/gcc-3.4.6/libstdc++-v3/../gcc/gthr.h > i686-pc-cygwin/bits/gthr.h sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \ -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' \ < /home/arend/tmp/gcc-3.4.6/libstdc++-v3/../gcc/gthr-single.h > i686-pc-cygwin/bits/gthr-single.h sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \ -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' \ -e 's/SUPPORTS_WEAK/__GXX_WEAK__/g' \ -e 's/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*USE_WEAK\)/_GLIBCXX_\1/g' \ < /home/arend/tmp/gcc-3.4.6/libstdc++-v3/../gcc/gthr-posix.h > i686-pc-cygwin/bits/gthr-posix.h sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \ -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' \ -e 's/SUPPORTS_WEAK/__GXX_WEAK__/g' \ -e 's/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*USE_WEAK\)/_GLIBCXX_\1/g' \ -e 's,^#include "\(.*\)",#include ,g' \ < /home/arend/tmp/gcc-3.4.6/libstdc++-v3/../gcc/gthr-posix.h > i686-pc-cygwin/bits/gthr-default.h touch ./i686-pc-cygwin/bits/stdc++.h; \ if [ ! -d "./i686-pc-cygwin/bits/stdc++.h.gch" ]; then \ mkdir -p ./i686-pc-cygwin/bits/stdc++.h.gch; \ fi; \ /home/arend/tmp/build-gcc/gcc/xgcc -shared-libgcc -B/home/arend/tmp/build-gcc/gcc/ -nostdinc++ -L/home/arend/tmp/build-gcc/i686-pc-cygwin/libstdc++-v3/src -L/home/arend/tmp/build-gcc/i686-pc-cygwin/libstdc++-v3/src/.libs -B/home/arend/opt/install/gcc-3.4.6/i686-pc-cygwin/bin/ -B/home/arend/opt/install/gcc-3.4.6/i686-pc-cygwin/lib/ -isystem /home/arend/opt/install/gcc-3.4.6/i686-pc-cygwin/include -isystem /home/arend/opt/install/gcc-3.4.6/i686-pc-cygwin/sys-include -Winvalid-pch -Wno-deprecated -x c++-header -g -Os -I/home/arend/tmp/build-gcc/i686-pc-cygwin/libstdc++-v3/include/i686-pc-cygwin -I/home/arend/tmp/build-gcc/i686-pc-cygwin/libstdc++-v3/include -I/home/arend/tmp/gcc-3.4.6/libstdc++-v3/libsupc++ /home/arend/tmp/gcc-3.4.6/libstdc++-v3/include/stdc++.h -O0 -g -o ./i686-pc-cygwin/bits/stdc++.h.gch/O0g; \ /home/arend/tmp/build-gcc/gcc/xgcc -shared-libgcc -B/home/arend/tmp/build-gcc/gcc/ -nostdinc++ -L/home/arend/tmp/build-gcc/i686-pc-cygwin/libstdc++-v3/src -L/home/arend/tmp/build-gcc/i686-pc-cygwin/libstdc++-v3/src/.libs -B/home/arend/opt/install/gcc-3.4.6/i686-pc-cygwin/bin/ -B/home/arend/opt/install/gcc-3.4.6/i686-pc-cygwin/lib/ -isystem /home/arend/opt/install/gcc-3.4.6/i686-pc-cygwin/include -isystem /home/arend/opt/install/gcc-3.4.6/i686-pc-cygwin/sys-include -Winvalid-pch -Wno-deprecated -x c++-header -g -Os -I/home/arend/tmp/build-gcc/i686-pc-cygwin/libstdc++-v3/include/i686-pc-cygwin -I/home/arend/tmp/build-gcc/i686-pc-cygwin/libstdc++-v3/include -I/home/arend/tmp/gcc-3.4.6/libstdc++-v3/libsupc++ /home/arend/tmp/gcc-3.4.6/libstdc++-v3/include/stdc++.h -O2 -g -o ./i686-pc-cygwin/bits/stdc++.h.gch/O2g; /home/arend/tmp/gcc-3.4.6/libstdc++-v3/include/stdc++.h:82: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. /home/arend/tmp/gcc-3.4.6/libstdc++-v3/include/stdc++.h:82: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[2]: *** [i686-pc-cygwin/bits/stdc++.h] Error 1 make[2]: Leaving directory `/home/arend/tmp/build-gcc/i686-pc-cygwin/libstdc++-v3/include' ... The compiler was configured using ../gcc-3.4.6/configure --prefix=/home/arend/opt/install/gcc-3.4.6 --disable-shared --enable-static --enable-threads --enable-target-optspace --enable-languages=ada,c,c++,f77,java,objc --enable-libgcj --enable-nls --enable-version-specific-runtime-libs --with-x --enable-java-awt=xlib --disable-libgcj-debug --disable-win32-registry --enable-sjlj-exceptions on i686-pc-cygwin (cygwin version 1.5.19(0.150/4/2)). Regards, Thomas -- Summary: ICE for precompiling c++ header Product: gcc Version: 3.4.6 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Arend at web dot de GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26596
[Bug java/22377] BC compilation fails to detect abstract instantiation
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-07 15:16 --- Now I think the idea in comment #3 is incorrect. I looked at implementing it today, and I realized that it will also cause a super() constructor call to throw an exception. The idea in comment #1 may still work. I'd prefer something more direct however. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22377
[Bug libfortran/26564] ../.././libgfortran/mk-kinds-h.sh: Unknown type
--- Comment #15 from diskman at kc dot rr dot com 2006-03-07 15:31 --- The closest would be the "AlphaServer DS20", mine is the EV56 [PCA56] and the DS20 is the EV6 [the very next generation]. I did manage to get GCC-4.1.0 Fortran to build, I simple 'reworked' GMP/MPFR... I built GMP with the following: CC=gcc-3.2.3 CXX=g++-3.2.3 CPP=cpp-3.2.3 \ CFLAGS="-O2 -mieee -finline -fomit-frame-pointer -mtune=ev56 -w -pipe" \ CXXFLAGS="-O2 -mieee -finline -fomit-frame-pointer -mtune=ev56 -w -pipe" \ ./configure \ --build=alpha-alpha-linux \ --prefix=/usr \ --sysconfdir=/etc \ --infodir=/usr/info \ --mandir=/usr/man \ --disable-cxx \ --disable-nails \ --disable-mpfr MPFR: CC="ccache gcc-3.2.3" CXX="ccache g++-3.2.3" CPP="ccache cpp-3.2.3" \ CFLAGS="-O2 -fno-strict-aliasing -fomit-frame-pointer -mtune=ev56 -w -pipe" \ CXXFLAGS="-O2 -fomit-frame-pointer -mtune=ev56 -w -pipe" \ ./configure \ --build=alpha-alpha-linux \ --prefix=/usr \ --sysconfdir=/etc \ --infodir=/usr/info \ --mandir=/usr/man \ --enable-shared \ --enable-mpfr Now Fortran is working as it should. Right now, at the moment, its compiling the GCJ portion of the build -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26564
[Bug libfortran/26564] ../.././libgfortran/mk-kinds-h.sh: Unknown type
--- Comment #16 from diskman at kc dot rr dot com 2006-03-07 15:38 --- Oh one other thing, I just wanted to thank everyone for pointing me in the right direction and taking the time to help me out... To everyone, thank you! -- diskman at kc dot rr dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26564
[Bug libfortran/26564] ../.././libgfortran/mk-kinds-h.sh: Unknown type
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2006-03-07 15:42 --- (In reply to comment #15) > I did manage to get GCC-4.1.0 Fortran to build, I simple 'reworked' > GMP/MPFR... OK. I'm closing this PR since it's not a bug in gfortran, but a mis-compilation in GMP/MPFR. > I built GMP with the following: > > CC=gcc-3.2.3 CXX=g++-3.2.3 CPP=cpp-3.2.3 \ > CFLAGS="-O2 -mieee -finline -fomit-frame-pointer -mtune=ev56 -w -pipe" \ > CXXFLAGS="-O2 -mieee -finline -fomit-frame-pointer -mtune=ev56 -w -pipe" \ > ./configure \ > --build=alpha-alpha-linux \ > --prefix=/usr \ > --sysconfdir=/etc \ > --infodir=/usr/info \ > --mandir=/usr/man \ > --disable-cxx \ > --disable-nails \ > --disable-mpfr > > MPFR: > > CC="ccache gcc-3.2.3" CXX="ccache g++-3.2.3" CPP="ccache cpp-3.2.3" \ > CFLAGS="-O2 -fno-strict-aliasing -fomit-frame-pointer -mtune=ev56 -w -pipe" \ > CXXFLAGS="-O2 -fomit-frame-pointer -mtune=ev56 -w -pipe" \ > ./configure \ > --build=alpha-alpha-linux \ > --prefix=/usr \ > --sysconfdir=/etc \ > --infodir=/usr/info \ > --mandir=/usr/man \ > --enable-shared \ > --enable-mpfr Please note that GMP/MFPR are well known for miscompiling. The GMP webpage is full of warnings that builds with non-default options (and exotic or recent compilers) are very risky. As gfortran uses GMP/MPFR only at compile time (it's not used in the generated code) and for very few tasks, I'd advise not to look for performance but for safety. CFLAGS="-O2 -mieee -finline -fomit-frame-pointer -mtune=ev56 -w -pipe" seems very risky to me, given my bad experiences with GMP. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Resolution|FIXED |INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26564
[Bug c++/26596] ICE for precompiling c++ header
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-07 15:50 --- *** This bug has been marked as a duplicate of 11341 *** -- 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=26596
[Bug pch/11341] [cygwin] [pch] ICE in ggc_pop_context, at ggc-page.c:1441 while compiling libstc++3
--- Comment #35 from pinskia at gcc dot gnu dot org 2006-03-07 15:50 --- *** Bug 26596 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||Thomas dot Arend at web dot ||de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11341
[Bug libfortran/26595] gfortran - jump to error label not working correctly after reading EOF
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-07 15:52 --- Hmm, I almost want to say this is a dup of bug 26509. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||26509 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26595
[Bug c++/10852] Old for-scoping rules improperly used?
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-03-07 15:54
---
Here's an example where the code is invalid, but is accepted because
of the for-scope-warning machinery:
==
namespace N
{
int i;
}
int i;
void foo()
{
for (int i=0; i<10; ++i) ;
using namespace N;
i;
}
==
The problem is that we track old and new scoping rules simultaneously
to be able to issue warnings. This doesn't work properly in corner
cases like in this PR.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||accepts-invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10852
[Bug libgcj/26506] Native build of Azureus 2.4.0.0 throws ArrayIndexOutOfBounds running under gcj 4.1.0
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-07 16:14 --- It would be helpful to have a stack trace for the exception. Or, Anthony, if you know more about the problem, could you update this PR? -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-07 16:14:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26506
[Bug libgcj/26495] problems with gcj-dbtool
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-07 16:16 --- Does this stop the build? I think this error can safely be ignored. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-07 16:16:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26495
[Bug tree-optimization/26587] [4.1/4.2 Regression] strict aliasing incorrectly pre-loads an array element with loops
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-03-07 16:23 --- Subject: Bug 26587 Author: rguenth Date: Tue Mar 7 16:23:38 2006 New Revision: 111808 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111808 Log: 2006-03-07 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/26587 * tree-ssa-structalias.c (handle_ptr_arith): Handle MINUS_EXPR. * gcc.dg/torture/pr26587.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr26587.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26587
[Bug tree-optimization/26587] [4.1/4.2 Regression] strict aliasing incorrectly pre-loads an array element with loops
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-03-07 16:26 --- Subject: Bug 26587 Author: rguenth Date: Tue Mar 7 16:26:14 2006 New Revision: 111809 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111809 Log: 2006-03-07 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/26587 * tree-ssa-structalias.c (handle_ptr_arith): Handle MINUS_EXPR. * gcc.dg/torture/pr26587.c: New testcase. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/torture/pr26587.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26587
[Bug fortran/26509] incorrect behaviour of error-handler for internal read
--- Comment #8 from dir at lanl dot gov 2006-03-07 16:30 --- Here are the ABSOFT and IBM xlf results - [dranta:~/tests/gfortran-D] dir% f90 -o write30 write30.f [dranta:~/tests/gfortran-D] dir% write30 read error occurred [dranta:~/tests/gfortran-D] dir% xlf90 -o write30 write30.f ** dummy === End of Compilation 1 === 1501-510 Compilation successful for file write30.f. [dranta:~/tests/gfortran-D] dir% write30 1525-002 The I/O statement on the internal file cannot be completed because the end of the internal file was reached. The program will stop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509
[Bug libgcj/26522] [4.1/4.2 Regression] gcc-4.1.0-RC{1,2} install headers into a top-level (root) /include
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-07 16:37 --- I'm testing a patch. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-07 16:37:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26522
[Bug tree-optimization/26587] [4.1/4.2 Regression] strict aliasing incorrectly pre-loads an array element with loops
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-03-07 16:49 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26587
[Bug libgcj/26351] Native Momory Leak in ResourceBundle
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-07 16:58 --- 3.4.x is closed, we won't be putting any bug fixes on that branch. (I think the next 3.4.x release will be the last one ever.) This bug does seem to appear on the 4.0 branch. I think I'll check in your patch, it seems to be ok. This bug doesn't appear in the 4.1 series or later. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-07 16:58:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26351
[Bug libgcj/26351] Native Momory Leak in ResourceBundle
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-07 17:07 --- Subject: Bug 26351 Author: tromey Date: Tue Mar 7 17:07:37 2006 New Revision: 111814 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111814 Log: 2006-03-07 fexx <[EMAIL PROTECTED]> PR libgcj/26351: * gnu/gcj/runtime/natStackTrace.cc (fillInStackTrace): Free 'addrs' if it is set. Modified: branches/gcc-4_0-branch/libjava/ChangeLog branches/gcc-4_0-branch/libjava/gnu/gcj/runtime/natStackTrace.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26351
[Bug libgcj/26351] Native Momory Leak in ResourceBundle
--- Comment #6 from tromey at gcc dot gnu dot org 2006-03-07 17:08 --- Fix checked in. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26351
[Bug c/26589] Optimizer hangs on conditional expression
--- Comment #2 from pmcilroy at gmail dot com 2006-03-07 17:14 --- Subject: Re: Optimizer hangs on conditional expression OK, thanks very much. I will let them know. - Peter On Mar 6, 2006, at 8:43 PM, pinskia at gcc dot gnu dot org wrote: > > > --- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-07 > 04:43 --- > This works in 3.3.2 with the FSF GCC. Please report this bug to Apple > first > since it is their modified version of gcc. > > > -- > > 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=26589 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26589
[Bug libgcj/26073] [4.2 regression] libjava fails to compile
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-07 18:16 --- I think this was just fixed by David Daney: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111815 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26073
[Bug libgcj/26073] [4.2 regression] libjava fails to compile
--- Comment #6 from daney at gcc dot gnu dot org 2006-03-07 18:29 --- Should be fixed by the patch I just committed. -- daney at gcc dot gnu dot org changed: What|Removed |Added CC||daney at gcc dot gnu dot org Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26073
[Bug ada/18819] [4.2 Regression] ACATS cdd2a02 fail at runtime
--- Comment #32 from ebotcazou at gcc dot gnu dot org 2006-03-07 18:33 --- Created an attachment (id=10984) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10984&action=view) Reduced testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18819
[Bug libgcj/26522] [4.1/4.2 Regression] gcc-4.1.0-RC{1,2} install headers into a top-level (root) /include
--- Comment #3 from patchapp at dberlin dot org 2006-03-07 18:45 --- Subject: Bug number PR libgcj/26522 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00374.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26522
[Bug libgcj/26103] Wrong exception thrown
--- Comment #3 from tromey at gcc dot gnu dot org 2006-03-07 18:52 --- Testing a patch. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-02-05 14:44:32 |2006-03-07 18:52:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26103
[Bug c++/26597] New: static const class member, ?:, undefined reference
Consider the following code:
=== bug.cpp ===
struct Test {
static const int number=5;
int test(const int n);
};
int Test::test(const int n)
{
int max = number > n ? number : n;
return max;
}
int main()
{
Test t;
t.test(6);
return 0;
}
I get the following linker error:
/tmp/ccWCtyqx.o(.text+0x18): In function `Test::test(int)':
: undefined reference to `Test::number'
collect2: ld returned 1 exit status
I have tested g++ 3.3.5, 4.0.2, and 4.1.0. With g++ 4.* and -O2 the error
disappears. Also if one replaces the ? : by an if statement, the error
disappears. Of course, an additional "extern const int Test::number;" also
solves the problem.
Environment: i386-linux (Debian GNU/Linux)
Releases: 3.3.5, 4.0.2, 4.1.0
How-To-Repeat: g++ -o bug bug.cpp
Best regards,
Elmar
--
Summary: static const class member, ?:, undefined reference
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: teufl at weyl dot math dot tugraz dot at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26597
[Bug middle-end/26238] [4.2 Regression] passes.texi does not document the openMP lowering pass
--- Comment #3 from aldyh at gcc dot gnu dot org 2006-03-07 19:20 --- Subject: Bug 26238 Author: aldyh Date: Tue Mar 7 19:20:32 2006 New Revision: 111818 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111818 Log: PR gomp/26238 * doc/passes.texi (Tree-SSA passes): Document omp lowering and expansion. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/passes.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26238
[Bug c++/26597] static const class member, ?:, undefined reference
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-07 19:47 --- Here is the relevant section of the standard (TC1, section 9.4.2, paragraph 4): If a 'static' data member is of 'const' integral or 'const' enumeral type, its declaration in the class definition can specify a 'constant-initializer' which shall be an integral constant expression (5.19). In that case, the member can appear in integral constant expressions. The member shall still be defined in a namespace scope if it is used in the program and the namespace scope definition shall not contain an 'initializer'. *** This bug has been marked as a duplicate of 23370 *** -- 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=26597
[Bug c++/23370] No error at -O1 for static const class member passed by reference
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-07 19:47 --- *** Bug 26597 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||teufl at weyl dot math dot ||tugraz dot at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23370
[Bug c/26004] [4.1 Regression] gcc errors on valid code [SVO]
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-03-07 19:52 --- This is fixed on the mainline how I don't know. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.1.0 4.2.0 |4.1.0 Known to work|4.0.2 |4.0.2 4.2.0 Summary|[4.1/4.2 Regression] gcc|[4.1 Regression] gcc errors |errors on valid code [SVO] |on valid code [SVO] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26004
[Bug c/26004] [4.1 Regression] gcc errors on valid code [SVO]
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-03-07 19:55 --- Janis could you figure out which patch fixed this on the mainline if it was ever broken on the mainline. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26004
[Bug fortran/25786] [meta-bug] assumed length/sized problems
--- Comment #1 from pault at gcc dot gnu dot org 2006-03-07 20:19 --- It seems that we have temporarily, at least, exhausted the supply of this genre of bug! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25786
[Bug fortran/18428] No preprocessing option -cpp for gfortran
--- Comment #7 from tom dot browder at fwb dot srs dot com 2006-03-07 20:37 --- (In reply to comment #6) > While I completely agree with you, I don't see a way to do that with the > current framework. On the other hand, when (or if) we switch to cpplib, it How does the current framework now handle the difference between source files t.f (not preprocessed) and t.F (preprocessed). Couldn't command line arg '-cpp' set a flag to change the handling of any source file to the same as t.F? (I know it's probably not that easy in reality.) -- tom dot browder at fwb dot srs dot com changed: What|Removed |Added CC||tom dot browder at fwb dot ||srs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18428
[Bug rtl-optimization/24814] unrolling doesn't put loop notes in right place
--- Comment #5 from amylaar at gcc dot gnu dot org 2006-03-07 20:52 --- (In reply to comment #4) > Actually there is nothing that uses LOOP_NOTEs other than the old RTL loop > optimizer. At least, nothing that _should_ use it. Wanna know about loops? > Find natural loops instead of depending on the notes. So you are saying I should put natural loop detection into the SH backend so that it can decide if it should save all target registers? Note that the branch probability estimation machinery does not set estimated execution counts, so the execution counts are unusable without profile data. > But the point is moot, the old RTL loop optimizer is no more. It had its weaknesses, but at least it was well-tuned for a wide range of target architectures and operated generally well together with the rest of the compiler. What we have now is a collection of passes that often work at cross-purposes. E.g. web, loop strength reduction/unrolling and auto-increment generation are completely out of sync. -- amylaar at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24814
[Bug c/26004] [4.1/4.2 Regression] gcc errors on valid code [SVO]
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-03-07 21:02 --- The reduced testcase in this bug is fixed but the full testcase in the gdb testsuite. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.1.0 |4.1.0 4.2.0 Known to work|4.0.2 4.2.0 |4.0.2 Summary|[4.1 Regression] gcc errors |[4.1/4.2 Regression] gcc |on valid code [SVO] |errors on valid code [SVO] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26004
[Bug c/26004] [4.1/4.2 Regression] gcc errors on valid code [SVO]
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-03-07 21:06
---
New reduced testcase:
struct s_3 { short s[3]; } z_3, s_3;
struct s_3 add_struct_3 (struct s_3 s){}
wack_struct_3 (void)
{
int i; register struct s_3 u = z_3;
u = add_struct_3 (u);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26004
[Bug c/26598] New: Unable to build a mc68332 target
The tm.h and m668k-none.c TRAGET_CPU_DEFAULT seem to be strange. Looks like the #if TARGET_CPU_DEFAULT == xxx will never match. -- Summary: Unable to build a mc68332 target Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ggallant571 at comcast dot net GCC target triplet: m68k-linux-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26598
[Bug libgcj/26103] Wrong exception thrown
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-07 21:34 --- Subject: Bug 26103 Author: tromey Date: Tue Mar 7 21:34:46 2006 New Revision: 111819 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111819 Log: PR libgcj/26103: * java/lang/ClassLoader.java (loadClass): Don't throw StringIndexOutOfBoundsException if name is empty. * java/lang/natClassLoader.cc (loadClassFromSig): Throw exception if class not found. Modified: branches/gcc-4_1-branch/libjava/ChangeLog branches/gcc-4_1-branch/libjava/java/lang/ClassLoader.java branches/gcc-4_1-branch/libjava/java/lang/natClassLoader.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26103
[Bug libgcj/26103] Wrong exception thrown
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-07 21:39 --- Subject: Bug 26103 Author: tromey Date: Tue Mar 7 21:39:44 2006 New Revision: 111820 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111820 Log: PR libgcj/26103: * java/lang/ClassLoader.java (loadClass): Don't throw StringIndexOutOfBoundsException if name is empty. * java/lang/natClassLoader.cc (loadClassFromSig): Throw exception if class not found. Modified: trunk/libjava/ChangeLog trunk/libjava/java/lang/ClassLoader.java trunk/libjava/java/lang/natClassLoader.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26103
[Bug libgcj/26103] Wrong exception thrown
--- Comment #6 from tromey at gcc dot gnu dot org 2006-03-07 21:41 --- Fix checked in. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26103
[Bug rtl-optimization/24814] unrolling doesn't put loop notes in right place
--- Comment #6 from dberlin at gcc dot gnu dot org 2006-03-07 21:50 --- (In reply to comment #5) > (In reply to comment #4) > > Actually there is nothing that uses LOOP_NOTEs other than the old RTL loop > > optimizer. At least, nothing that _should_ use it. Wanna know about > > loops? > > Find natural loops instead of depending on the notes. > > So you are saying I should put natural loop detection into the SH backend so > that it can decide if it should save all target registers? > Yes, if you need to detect loops, call the routine to detect natural loops. This is the way of the future. LOOP_NOTES are not. I agree that this bug should be marked WONTFIX. > It had its weaknesses, but at least it was well-tuned for a wide range of > target architectures and operated generally well together with the rest of the > compiler. What we have now is a collection of passes that often work at > cross-purposes. E.g. web, loop strength reduction/unrolling and > auto-increment generation are completely out of sync. Completely irrelevant to this bug. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24814
[Bug tree-optimization/26600] New: internal compiler error: in push_reload, at reload.c:1303
void fdct_int32()
{
int tmp4, tmp5, tmp7;
int z1, z2, z3, z4, z5;
int *dataptr;
int i;
for (i = 0; i < 8; i++) {
tmp7 = dataptr[0];
z3 = tmp4;
z4 = tmp5 + tmp7;
z5 = (z3 + z4) * ((int) 9633);
z3 += z5;
dataptr[56] = tmp4 + z1 + z3;
dataptr[40] = tmp5 + z2 + z4;
dataptr++;
}
}
When compiling the above file with the following command line arguments:
gcc -c -O -march=pentium4 -ftree-vectorize foo.c
I get the following error:
foo.c: In function 'fdct_int32':
foo.c:22: internal compiler error: in push_reload, at reload.c:1303
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
I discovered this while trying to compile the xvid sources using silly CFLAGS
by accident. The above file is a somewhat reduced testcase.
--
Summary: internal compiler error: in push_reload, at
reload.c:1303
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ma1flfs at bath dot ac dot uk
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=26600
[Bug fortran/26064] 4.1 regression introduced with patch for bug 18197
--- Comment #13 from hjl at gcc dot gnu dot org 2006-03-07 22:29 --- Subject: Bug 26064 Author: hjl Date: Tue Mar 7 22:29:32 2006 New Revision: 111821 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111821 Log: 2006-03-07 H.J. Lu <[EMAIL PROTECTED]> PR fortran/26041 PR fortran/26064 Backport from mainline * resolve.c (resolve_types): New function. (resolve_codes): Likewise. (gfc_resolve): Use them. Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/resolve.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26064
[Bug fortran/26041] [4.1]: FORTRAN compiler won't compile the valid code
--- Comment #11 from hjl at gcc dot gnu dot org 2006-03-07 22:29 --- Subject: Bug 26041 Author: hjl Date: Tue Mar 7 22:29:32 2006 New Revision: 111821 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111821 Log: 2006-03-07 H.J. Lu <[EMAIL PROTECTED]> PR fortran/26041 PR fortran/26064 Backport from mainline * resolve.c (resolve_types): New function. (resolve_codes): Likewise. (gfc_resolve): Use them. Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/resolve.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26041
[Bug fortran/26064] 4.1 regression introduced with patch for bug 18197
--- Comment #14 from hjl at gcc dot gnu dot org 2006-03-07 22:31 --- Subject: Bug 26064 Author: hjl Date: Tue Mar 7 22:30:58 2006 New Revision: 111822 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111822 Log: 2006-03-07 H.J. Lu <[EMAIL PROTECTED]> PR fortran/26041 PR fortran/26064 Backport from mainline * gfortran.dg/sibling_dummy_procedure_1.f90: New file. * gfortran.dg/sibling_dummy_procedure_2.f90: Likewise. * gfortran.dg/sibling_dummy_procedure_3.f90: Likewise. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/sibling_dummy_procedure_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/sibling_dummy_procedure_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/sibling_dummy_procedure_3.f90 Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26064
[Bug fortran/26041] [4.1]: FORTRAN compiler won't compile the valid code
--- Comment #12 from hjl at gcc dot gnu dot org 2006-03-07 22:31 --- Subject: Bug 26041 Author: hjl Date: Tue Mar 7 22:30:58 2006 New Revision: 111822 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111822 Log: 2006-03-07 H.J. Lu <[EMAIL PROTECTED]> PR fortran/26041 PR fortran/26064 Backport from mainline * gfortran.dg/sibling_dummy_procedure_1.f90: New file. * gfortran.dg/sibling_dummy_procedure_2.f90: Likewise. * gfortran.dg/sibling_dummy_procedure_3.f90: Likewise. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/sibling_dummy_procedure_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/sibling_dummy_procedure_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/sibling_dummy_procedure_3.f90 Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26041
[Bug fortran/26041] [4.1]: FORTRAN compiler won't compile the valid code
--- Comment #13 from hjl at lucon dot org 2006-03-07 22:32 --- Fixed. -- hjl at lucon dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26041
[Bug target/26445] SSE byte-by-byte load instruction fails to compile
--- Comment #6 from gchernis11 at msn dot com 2006-03-07 22:33 --- (In reply to comment #5) > Reducing. What does it mean? How do i change status to active? -- gchernis11 at msn dot com changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26445
[Bug fortran/20935] failed assertion for maxloc(n, mask=.true.)
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-03-07 22:33 --- Created an attachment (id=10987) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10987&action=view) partial patch This is a partial proof-of-concept patch that only deals with minloc. The test should be fairly straightforward, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20935
[Bug fortran/26041] [4.1]: FORTRAN compiler won't compile the valid code
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26041
[Bug other/26601] New: --whole-program --combine with gcc4.1 fails to link cpu2000 benchmarks
Hi, Following is the list of benchmarks failed to compile/link using --fwhole-program --combine option with GCC, $/opt/gcc-nightly/4.1-20060228/bin/gcc -v Using built-in specs. Target: powerpc64-linux Configured with: /home/gccbuild/gcc_4.1_anonsvn/4.1/configure --prefix=/opt/gcc-nightly/4.1-20060228 --build=powerpc64-linux --host=powerpc64-linux --target=powerpc64-linux --with-cpu=default32 --with-as=/opt/gcc-nightly/4.1-20060228/bin/as --with-ld=/opt/gcc-nightly/4.1-20060228/bin/ld --enable-threads=posix --enable-shared --enable-__cxa_atexit --enable-languages=c,c++,f95,java,objc --enable-checking --with-mpfr=/opt/gcc-nightly/4.1-20060228 Thread model: posix gcc version 4.1.0 Integer: 164.gzip, 175.vpr, 176.gcc, 181.mcf, 186.crafty, 197.parser, 252.eon, 253.perlbmk, 254.gap, 255.vortex, 256.bzip2, 300.twolf Floating point: 168.wupwise, 171.swim, 172.mgrid, 173.applu, 177.mesa, 178.galgel, 187.facerec, 188.ammp, 189.lucas, 191.fma3d, 200.sixtrack 301.apsi Onlys benchmark succeeded are 179.art and 183.equake. The other compiler options used are "-m32 -O3 -mcpu=power4" All the integer benchmarks failed with indefined reference errors. All the fortran benchmarks failed with following error, /opt/gcc-nightly/4.1-20060228/lib/gcc/powerpc64-linux/4.1.0/../../../../lib/libgfortranbegin.a(fmain.o): In function `main': /home/gccbuild/gcc_4.1_anonsvn/4.1/libgfortran/fmain.c:18: undefined reference to `MAIN__' collect2: ld returned 1 exit status -- Summary: --whole-program --combine with gcc4.1 fails to link cpu2000 benchmarks Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttamp at us dot ibm dot com GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26601
[Bug libgcj/23288] java.lang.Class's #getPackage() returns null
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-07 22:41 --- I believe this was fixed a while back. The test cases work for me with 4.1. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23288
[Bug rtl-optimization/24814] unrolling doesn't put loop notes in right place
--- Comment #7 from amylaar at gcc dot gnu dot org 2006-03-07 22:42 --- (In reply to comment #6) > Yes, if you need to detect loops, call the routine to detect natural loops. > This is the way of the future. > LOOP_NOTES are not. Is flow_loops_find and the data that it initailizes a stable interface, and can it be safely called from prologue/epilogue generation? I see no mention of this function in the files in doc/ ; the loop notes are documented there, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24814
[Bug libgcj/24183] xmlj code not properly built
--- Comment #1 from tromey at gcc dot gnu dot org 2006-03-07 22:44 --- Testing a patch. I think this bug report is a bit wrong, in that we don't actually need to link the JNI library into libgcj. loadLibrary seems appropriate here, particularly given that this code is seldom used. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-07 22:44:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24183
[Bug libgcj/25593] Socket problems
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-07 22:49 --- I tried this test case with my 4.1 build and it seemed to work fine. opsy. gij HServer & [1] 21044 opsy. gij HClient READ: 224 READ: 12 opsy. java.net.SocketException: Socket Closed at HServer$1.run (HServer.java:29) Does this look right to you? -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25593
[Bug java/12089] m68k-coff-gcj segmentation fault on array initilisation
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-07 23:00 --- Defining these types seems ok to me. It would be nice if there were front end documentation explaining that front ends are required to, though. FWIW Alexandre Oliva has a patch to bug 8620 the "other way" -- by changing gcc, not gcj. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12089
[Bug target/26588] gfortran -fopenmp passes unrecognised -pthread
--- Comment #2 from billingd at gcc dot gnu dot org 2006-03-07 23:51 --- Subject: Bug 26588 Author: billingd Date: Tue Mar 7 23:51:34 2006 New Revision: 111824 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111824 Log: 2006-03-08 David Billinghurst <[EMAIL PROTECTED]> PR target/26588 * config/i386/cygwin.h (GOMP_SELF_SPECS): Define. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/cygwin.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26588
[Bug target/26588] gfortran -fopenmp passes unrecognised -pthread
--- Comment #3 from billingd at gcc dot gnu dot org 2006-03-07 23:55 --- Fixed by patch. -- billingd at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26588
[Bug other/22313] [4.2 Regression] profiledbootstrap is broken on the mainline
--- Comment #32 from pinskia at gcc dot gnu dot org 2006-03-08 00:01 --- And now profiledbootstrap is broken a different way on the mainline so I am not fixing this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
[Bug rtl-optimization/25569] [4.2 Regression] FAIL: gfortran.dg/g77/20010610.f -O3 -fomit-frame-pointer -funroll-loops
--- Comment #5 from janis at gcc dot gnu dot org 2006-03-08 00:07 --- A regression hunt on powerpc64-linux using the C test case from comment #4 identified this patch: http://gcc.gnu.org/viewcvs?view=rev&rev=110705 r110705 | law | 2006-02-07 18:31:27 + (Tue, 07 Feb 2006) That date doesn't match up with when the Fortran test started failing so I ran another regression hunt using it, which identified this patch: http://gcc.gnu.org/viewcvs?view=rev&rev=108425 r108425 | law | 2005-12-12 19:59:16 + (Mon, 12 Dec 2005) -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||law at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25569
[Bug middle-end/26238] [4.2 Regression] passes.texi does not document the openMP lowering pass
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-08 00:11 --- Fixed. Thanks Aldy for this documention. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26238
[Bug target/23706] [4.1 Regression] ICE in rtl_verify_flow_info_1
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.0 |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23706
[Bug libgcj/26495] problems with gcj-dbtool
-- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26495
[Bug libgcj/24834] PersistentByteMap close() method is not catching Exception
--- Comment #3 from tromey at gcc dot gnu dot org 2006-03-08 00:37 --- I looked and as far as I can see, this bug is fixed in 4.1. PersistentByteMap.close now throws IOException. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24834
[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64
--- Comment #10 from wilson at gcc dot gnu dot org 2006-03-08 00:46 --- I missed the denorm angle obviously. And the answer to the question about what is different between native and interpreted execution would of course be libffi, which took me far longer to remember than it should have. Anyways, looking at libffi, the issue appears to be the stf_spill function in the src/ia64/ffi.c file. This function spills an FP value to the stack, taking as argument a _float80 value, which is effectively a long double. So when we pass the denorm double to stf_spill, it gets normalized to a long double, and this normalization appears to be causing all of the trouble. This long double value then gets passed to dtoa in fdlibm which expects a double argument. dtoa then fails. I didn't debug dtoa to see why it fails, but it seems clear if we pass it an argument of the wrong type, we are asking for trouble. On IA-64, FP values are always stored in FP regs as a long double value rounded to the appropriate type, so the normalization will have no effect except on denorm values I think. This means only single-denorm and double-denorm arguments values are broken, which is something that would be easy to miss without a testcase. Stepping through ffi_call in gdb at the point whjere stf_spill is called, I see the incoming value is f6 4.9406564584124654417656879286822137e-324(raw 0xfc010800) which has the minimum double exponent (fc01) and a denorm fraction (0...800). After the conversion to _float80, we have f6 4.9406564584124654417656879286822137e-324(raw 0xfbcd8000) This now has an exponent invalid for double (fbcd) and a normal fraction (800...0). If I rewrite stf_spill to be a macro instead of a function, to avoid the argument type conversion, then the testcase works for both gcj and gij. ldf_spill appears to have the same problem, and is in need of the same solution. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64
--- Comment #11 from wilson at gcc dot gnu dot org 2006-03-08 00:51 --- Created an attachment (id=10989) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10989&action=view) unfinished untested patch to fix stf_spill bug in ia64 libffi port This is unfinished. It needs to be a bit cleaner, and also ldf_spill appears to need the same fix. This is untested, except for the testcase. It does make the testcase work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug libgcj/23495] java.lang.String.equals is suboptimal
--- Comment #10 from tromey at gcc dot gnu dot org 2006-03-08 00:54 --- Actually, Robin, could you send your current patch for this? It seems like we should simply put it in. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23495
[Bug fortran/26509] incorrect behaviour of error-handler for internal read
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2006-03-08 01:13 --- I think the votes are starting to come in on this one. I am going to get an opinion from com.lang.fortran and then proceed. I do not thing the standards disallow the desired behavior. Gfortran does the minimum now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509
[Bug libfortran/26595] gfortran - jump to error label not working correctly after reading EOF
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-03-08 01:16 --- Yes it is. See my comments there. I am working this issue. *** This bug has been marked as a duplicate of 26509 *** -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26595
[Bug fortran/26509] incorrect behaviour of error-handler for internal read
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2006-03-08 01:16 --- *** Bug 26595 has been marked as a duplicate of this bug. *** -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added CC||dir at lanl dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509
[Bug c/26004] [4.1/4.2 Regression] gcc errors on valid code [SVO]
--- Comment #17 from janis at gcc dot gnu dot org 2006-03-08 01:34 --- A regression hunt on powerpc-linux using the testcase from comment #16 identified this patch: http://gcc.gnu.org/viewcvs?view=rev&rev=101269 r101269 | jason | 2005-06-23 14:44:21 + (Thu, 23 Jun 2005) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26004
[Bug target/26600] internal compiler error: in push_reload, at reload.c:1303
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-08 03:06 --- Hmm, this works in "4.1.1 20060304" on x86_64 with -m32. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26600
[Bug c++/26512] g++ doesn't recognize user-defined operator<<(ostream, const pair
--- Comment #10 from bangerth at dealii dot org 2006-03-08 04:43 --- (In reply to comment #4) > I looked at your link and at issue 197. I don't see how this applies to my bug > report, especially in connection with _user defined_ types. What I don't > understand is, why does g++ handle builtin types different than user defined > types. e.g: > > operator<<(ostream, const pair &) > vs. > operator<<(ostream, const pair &) Because user defined types are associated with a namespace (in which the compiler can then lookup functions, if one of its arguments is from that namespace), whereas builtin types have no associated namespace. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26512
[Bug c++/26512] g++ doesn't recognize user-defined operator<<(ostream, const pair
--- Comment #11 from bangerth at dealii dot org 2006-03-08 04:49 ---
This is indeed invalid under the present rules:
---
typedef std::map M;
namespace std {
extern std::ostream &operator <<(std::ostream &f, const M::value_type &p);
};
void f()
{
M m;
std::copy(m.begin(), m.end(),
std::ostream_iterator(std::cout));
}
---
When inside std::copy, the compiler needs to lookup an operator<< for
its arguments. It does so in the present namespace (i.e. std::) as well
as the namespaces of all arguments. The arguments are std::ofstream and
std::pair (and possibly the template arguments of two classes, though
I'm not sure about that). All these arguments are from namespace std::
or are builtin types that have no associated namespace. Lookup therefore
has to fail.
The solution is to put your own definition of operator<< into namespace
std:: -- not pretty, but a solution that we have discussed several times
here in this database...
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC||bangerth at dealii dot org
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26512
[Bug c++/26448] unnecessary namespace-alias ambiguity
--- Comment #1 from bangerth at dealii dot org 2006-03-08 04:52 --- My understanding is that this code is in fact invalid (and icc agrees with me). You may consider this part of the standard gratuitously unfriendly, but remember that namespace aliases form a directed graph and proving that two paths in the graph lead to the same node is not necessarily a cheap task. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26448
[Bug c++/26352] ICE
--- Comment #5 from bangerth at dealii dot org 2006-03-08 04:55 --- I see you used precompiled headers. Does the same ICE happen if you don't do that? W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26352
[Bug libgcj/25593] Socket problems
--- Comment #3 from r_ovidius at eml dot cc 2006-03-08 04:56 --- Yes, I just compiled 4.1 on linux and the testcase works there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25593
[Bug c++/26278] candidates list contains duplicates
--- Comment #3 from bangerth at dealii dot org 2006-03-08 04:57 --- Can you try to come up with a reasonably sized example code? Thanks W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26278
[Bug c++/25992] conditional expression and strings literal
--- Comment #5 from bangerth at dealii dot org 2006-03-08 05:02 ---
Confirmed. These two lines should behave the same, but don't:
--
extern bool flag;
int main()
{
char* p;
p = (true ? "a" : "lalala" );
p = (flag ? "a" : "lalala" );
}
--
g/x> /home/bangerth/bin/gcc-4.2*/bin/c++ -c x.cc -Wwrite-strings
x.cc: In function ‘int main()’:
x.cc:5: warning: deprecated conversion from string constant to
‘char*’'
x.cc:6: error: invalid conversion from ‘const char*’ to
‘char*’
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||diagnostic
Last reconfirmed|-00-00 00:00:00 |2006-03-08 05:02:36
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25992
[Bug c++/25863] Allowed knowledge of private structure.
--- Comment #1 from bangerth at dealii dot org 2006-03-08 05:04 --- This is how it is supposed to be. Note that access control (i.e. whether you can or cannot use a name) is not implemented by "hiding" the name. The name of private members is always available, you may simply not access it (unless you're a friend or member). W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25863
[Bug c++/25814] Request for warning for parser ambiguity of function declarations and variable declarations with initializations
--- Comment #4 from bangerth at dealii dot org 2006-03-08 05:07 --- I think we can confirm the problem. I doubt anyone will come around to actually taking this on anytime soon, though... W. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-08 05:07:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25814
