[Bug tree-optimization/26304] [4.2 Regression] 25_algorithms/prev_permutation/1.cc on powerpc{64,}-linux and powerpc-darwin
--- Comment #25 from pinskia at gcc dot gnu dot org 2006-05-16 06:11 --- This was fixed by the patch for PR 27603. *** This bug has been marked as a duplicate of 27603 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26304
[Bug tree-optimization/27603] [4.1 Regression] wrong code, apparently due to bad VRP (-O2)
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-05-16 06:11 --- *** Bug 26304 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27603
[Bug tree-optimization/27603] [4.1 Regression] wrong code, apparently due to bad VRP (-O2)
--- Comment #16 from rguenth at gcc dot gnu dot org 2006-05-16 08:01 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27603
[Bug tree-optimization/27603] [4.1 Regression] wrong code, apparently due to bad VRP (-O2)
--- Comment #17 from rguenth at gcc dot gnu dot org 2006-05-16 08:02 --- Subject: Bug 27603 Author: rguenth Date: Tue May 16 08:01:43 2006 New Revision: 113820 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113820 Log: 2006-05-16 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/27603 * tree-ssa-loop-niter.c (infer_loop_bounds_from_undefined): Do computation in original type, do division only for nonzero steps. * gcc.dg/torture/pr27603.c: New testcase. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/torture/pr27603.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-loop-niter.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27603
[Bug target/27593] bad code generation
--- Comment #8 from philipp at marek dot priv dot at 2006-05-16 08:20 --- If I remove the -funroll-loops, will it cause better code generation? I.e. only save two registers at function start, and use just these two registers? Can I achieve such an optimization without doing assembly myself? Thank you for your help! Regards, Phil -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27593
[Bug c/27273] [4.2 regression] tree check fail for legal code when convert returns a constant from an expression that was not constant
--- Comment #10 from mueller at gcc dot gnu dot org 2006-05-16 08:37 --- ok, rerunning regtest -- mueller at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |mueller at gcc dot gnu dot |org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27273
[Bug target/27621] [SH] generated pic code is not right
--- Comment #4 from saito at densan dot co dot jp 2006-05-16 09:13 --- I can not look the problem of the testcase using gcc-4.1.0. I will try to use gcc-4.1.0 on shlinux instead of gcc-3.4.6. Thanks for your support. -- saito at densan dot co dot jp changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27621
[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-16 09:28 --- Confirmed. Works with -m64, though the docs say The 64-bit environment sets int to 32 bits and long and pointer to 64 bits, and generates code for PowerPC64, as for -mpowerpc64. for the -m64 option. -- rguenth 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-05-16 09:28:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27619
[Bug driver/27622] New: gcc hang when compiling with -pipe
Mike Frysinger reported this bug for 4.1 Blackfin gcc. See http://blackfin.uclinux.org/tracker/index.php?func=detailaid=1287group_id=18atid=145. $ gcc -o some/non/existent/dir/voodoo.o -c voodoo.i -pipe Assembler messages: FATAL: can't create some/non/existent/dir/voodoo.o: No such file or directory sits here forever I can reproduce it on native i686 GCC 4.1 branch and 4.2 HEAD. My initial thought is the driver make cc1 write to the pipe and as read from it. as exits because it cannot open the output file. Then cc1 should get SIGPIPE and exit. But it seems it does not get the signal. The gcc 4.0.3 coming with Ubuntu Dapper does not has this issue. The as version is GNU assembler 2.16.91 20060118 Debian GNU/Linux. -- Summary: gcc hang when compiling with -pipe Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jzhang918 at gmail dot com GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27622
[Bug c/27499] ICE with unsigned iteration variable and -fopenmp
--- Comment #2 from jakub at gcc dot gnu dot org 2006-05-16 10:12 --- Subject: Bug 27499 Author: jakub Date: Tue May 16 10:12:39 2006 New Revision: 113822 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113822 Log: PR c/27499 * gimplify.c (gimplify_omp_for): Remove assertion that iteration var is signed. * gcc.dg/gomp/pr27499.c: New test. * g++.dg/gomp/pr27499.C: New test. Added: trunk/gcc/testsuite/g++.dg/gomp/pr27499.C trunk/gcc/testsuite/gcc.dg/gomp/pr27499.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27499
[Bug middle-end/27573] ICE with -fopenmp -fprofile-generate
--- Comment #1 from jakub at gcc dot gnu dot org 2006-05-16 10:16 --- Subject: Bug 27573 Author: jakub Date: Tue May 16 10:16:36 2006 New Revision: 113823 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113823 Log: PR middle-end/27573 * omp-low.c (expand_omp_parallel): Don't assert .OMP_DATA_I = .OMP_DATA_O is the first statement in the block, instead search for it. * gcc.dg/gomp/pr27573.c: New test. * gfortran.dg/gomp/pr27573.f90: New test. Added: trunk/gcc/testsuite/gcc.dg/gomp/pr27573.c trunk/gcc/testsuite/gfortran.dg/gomp/pr27573.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27573
[Bug middle-end/27573] ICE with -fopenmp -fprofile-generate
--- Comment #2 from jakub at gcc dot gnu dot org 2006-05-16 10:17 --- Fixed in SVN. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27573
[Bug c/27499] ICE with unsigned iteration variable and -fopenmp
--- Comment #3 from jakub at gcc dot gnu dot org 2006-05-16 10:18 --- Fixed in SVN. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27499
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
--- Comment #1 from jakub at gcc dot gnu dot org 2006-05-16 10:20 --- Guess the message should be sorry rather than error. Without glibc and binutils support for .tinit_array/.tfini_array this really isn't fixable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557
[Bug rtl-optimization/27623] New: invalid loop transformation.
-- Summary: invalid loop transformation. Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ramana dot radhakrishnan at codito dot com GCC build triplet: i686-pc-linux GCC host triplet: i686-pc-linux GCC target triplet: powerpc-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27623
[Bug rtl-optimization/27625] New: invalid loop transformation.
Number of loop iterations is calculated wrongly in the following bit of code.
extern char __dp0 ;
extern const long __reloc_table ;
extern const int __reloc_num ;
void
foo (void)
{
register char *dp = 0;
int cpu;
const long *reloc_ptr;
unsigned int num_relocs = 0;
dp = __dp0;
for (reloc_ptr = __reloc_table, num_relocs = (unsigned
int)__reloc_num;num_relocs; reloc_ptr++,num_relocs--)
*(long *)(dp + *reloc_ptr) += (long)dp;
}
Code generated for :
./xgcc -B`pwd` -S -O3 -mregnames ~/tmp/fails.i
is
foo:
lis %r9,[EMAIL PROTECTED]
lis %r11,[EMAIL PROTECTED]
la %r8,[EMAIL PROTECTED](%r9)
lis %r9,[EMAIL PROTECTED]
la %r9,[EMAIL PROTECTED](%r9)
la %r11,[EMAIL PROTECTED](%r11)
mtctr %r9
mr %r10,%r8
.L4:
lwz %r9,0(%r11)
addi %r11,%r11,4
lwzx %r0,%r9,%r10
add %r0,%r0,%r8
stwx %r0,%r9,%r10
bdnz .L4
blr
This bug seems to appear after the ivopts backport. .08.jump has a check for
the loop counter to be 0 which 09.cse removes as trivially dead. I would expect
there to be a check for the loop counter to be zero before the body of the
loop.
--
Summary: invalid loop transformation.
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ramana dot radhakrishnan at codito dot com
GCC build triplet: i686-pc-linux
GCC host triplet: i686-pc-linux
GCC target triplet: powerpc-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27625
[Bug rtl-optimization/27623] invalid loop transformation.
--- Comment #1 from ramana dot radhakrishnan at codito dot com 2006-05-16 10:45 --- Clicked too early. Can be marked invalid. -- ramana dot radhakrishnan at codito dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Summary|invalid loop transformation.|invalid loop transformation. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27623
[Bug driver/27622] gcc hang when compiling with -pipe
--- Comment #1 from jzhang918 at gmail dot com 2006-05-16 11:06 --- Created an attachment (id=11475) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11475action=view) The test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27622
[Bug c/27627] New: __builtin_nanf() doesn't return a _quiet_ nan on parisc
hppa-unknown-linux-gnu
configured with: ../src/configure -v
--enable-languages=c,c++,java,fortran,objc,obj-c++,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
+--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk
+--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre --enable-mpfr
--enable-checking=release hppa-linux-gnu
Hi all,
Trying to debug glibc test-float failures on linux parisc, it appears that a
place where one pb occures was during:
__real__ res = (float) M_PI_2 - __real__ y; //(1)
of '__cacosf (__complex__ float x);'
where __real__ y == nan;
The glibc test was failing because resulting of computation (1) is a
_signaling_ nan: the fpsr v bit (i.e. Invalid operation) is set.
Afaik this occures because __real__ y is itself a _signaling_ nan?
And this came from imho casinf() computation hunk:
[snip]
else if (__isinff (__real__ x) || __isinff (__imag__ x))
{
__real__ res = __nanf ();
__imag__ res = __copysignf (HUGE_VALF, __imag__ x);
}
[snip]
It seems so that __nanf (), precompiled as __builtin_nanf(), return a
signaling nan.
I will attach a precompile file of this simple test case:
#ifndef _GNU_SOURCE
# define _GNU_SOURCE
#endif
#include math.h
#include float.h
#include limits.h
#include errno.h
#include stdlib.h
#include stdio.h
#include string.h
static float
L_nanf (const char *tagp)
{
if (tagp[0] != '\0')
{
char buf[6 + strlen (tagp)];
sprintf (buf, NAN(%s), tagp);
return strtof (buf, NULL);
}
printf (tagp[0] == '\\0'\n);
return NAN;
}
int
main (int argc, char **argv)
{
union { unsigned long long l; unsigned int sw[2]; } s;
float res, tst;
res = L_nanf ();
//printf (res: 0x%x\n, (int)res);
tst = 4.0 - res;
__asm__(#BannerIn);
/* Get the current status word. */
__asm__ (\n\t
fstd %%fr0,0(%1)
: =m (s.l)
: r (s.l)
);
printf (s.sw[0]: 0x%x.\n, s.sw[0]);
printf (s.sw[0] 27: 0x%x.\n, (s.sw[0] 27));
__asm__(#BannerOut);
return (int)tst;
}
reporting well:
tagp[0] == '\0'
s.sw[0]: 0x8000.
s.sw[0] 27: 0x10.
Tx,
Joel
PS: compile options for test case:
gcc-4.1: warning: -pipe ignored because -save-temps specified
Using built-in specs.
Target: hppa-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,fortran,objc,obj-c++,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib --without-i
ncluded-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1
--enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre --enable-mpfr
--enable-checking=release hppa-linux-gnu
Thread model: posix
gcc version 4.1.1 20060511 (prerelease) (Debian 4.1.0-4)
/usr/lib/gcc/hppa-linux-gnu/4.1.1/cc1 -E -quiet -nostdinc -v -I../include -I.
-I/CAD/parisc-linux/Dpkg/dpkg-work/glibc-2.3.6/build-tree/hppa-libc/math -I..
-I../libio -I/CAD/parisc-l
inux/Dpkg/dpkg-work/glibc-2.3.6/build-tree/hppa-libc -I../sysdeps/hppa/elf
-I../libidn/sysdeps/unix -I../linuxthreads/sysdeps/unix/sysv/linux/hppa
-I../linuxthreads/sysdeps/unix/sysv/
linux -I../linuxthreads/sysdeps/pthread -I../sysdeps/pthread
-I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix
-I../linuxthreads/sysdeps/hppa -I../sysdeps/unix/sysv/l
inux/hppa -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu
-I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet
-I../sysdeps/unix/sysv -I../sysdeps/unix -I../sysdeps/po
six -I../sysdeps/hppa/hppa1.1 -I../sysdeps/wordsize-32
-I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/hppa/fpu
-I../sysdeps/hppa -I../sysdeps/ieee754 -I../sysdep
s/generic/elf -I../sysdeps/generic -MD
/CAD/parisc-linux/Dpkg/dpkg-work/glibc-2.3.6/build-tree/hppa-libc/math/Nan.d
-MF /CAD/parisc-linux/Dpkg/dpkg-work/glibc-2.3.6/build-tree/hppa-li
bc/math/Nan.o.dt -MP -MT
/CAD/parisc-linux/Dpkg/dpkg-work/glibc-2.3.6/build-tree/hppa-libc/math/Nan.o
-MQ
/CAD/parisc-linux/Dpkg/dpkg-work/glibc-2.3.6/build-tree/hppa-libc/math/Nan.o
-D__NO_MATH_INLINES -D__LIBC_INTERNAL_MATH_INLINES -DNO_LONG_DOUBLE
-D_Mlong_double_=double -D_LIBC_REENTRANT -DNOT_IN_libc=1 -isystem
/usr/lib/gcc/hppa-linux-gnu/4.1.1/include -isyst
em /CAD/parisc-linux/Dpkg/dpkg-work/glibc-2.3.6/debian/include -include
../include/libc-symbols.h Nan.c -std=gnu99 -Wall -Winline -Wstrict-prototypes
-Wwrite-strings -Wno-uninitialize
d -fstrict-aliasing -fno-inline -ffloat-store -fno-builtin -fworking-directory
-O2 -fpch-preprocess -o Nan.i
#include ... search starts here:
#include ... search starts here:
../include
.
/CAD/parisc-linux/Dpkg/dpkg-work/glibc-2.3.6/build-tree/hppa-libc/math
..
../libio
/CAD/parisc-linux/Dpkg/dpkg-work/glibc-2.3.6/build-tree/hppa-libc
../sysdeps/hppa/elf
../libidn/sysdeps/unix
../linuxthreads/sysdeps/unix/sysv/linux/hppa
../linuxthreads/sysdeps/unix/sysv/linux
[Bug c/27627] __builtin_nanf() doesn't return a _quiet_ nan on parisc
--- Comment #1 from soete dot joel at tiscali dot be 2006-05-16 11:51 --- Created an attachment (id=11476) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11476action=view) precompile nan test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27627
[Bug c/27628] New: Incorrect memory access type used used in accessing bitfields
When specifying a bitfield type, the compiler should generate assembly language
instructions that honor that type.
For example, with the following structure,
typedef struct {
unsigned long bitfA: 8;
unsigned long bitfB: 8;
unsigned long bitfC: 8;
unsigned long bitfD: 8;
} MYSTRUCT;
the compiler should only attempt to access the bitfields using 32 bit accesses
(on the ARM, this would be using LDR STR instructions). What I actually get
is that the compiler will try to access these bitfields using LDRB STRB
(8-bit accesses). On some targets, only one type of access is allowed to
certain memory areas, so an error results.
Using built-in specs.
Target: arm-elf
Configured with: ../gcc-4.1.0/configure --target=arm-elf
--prefix=/g/gnuarm-4.1.0 --enable-interwork --enable-multilib --with-float=soft
--with-newlib --with-he
aders=../newlib-1.14.0/newlib/libc/include --enable-languages=c,c++
Thread model: single
gcc version 4.1.0
--
Summary: Incorrect memory access type used used in accessing
bitfields
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ryan at embedded-iq dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27628
[Bug rtl-optimization/27625] invalid loop transformation.
--- Comment #1 from ramana dot radhakrishnan at codito dot com 2006-05-16 12:11 --- Richi on IRC suggested that a weak attribute for reloc_num would fix this . The assumption being made is that the address of reloc_num can never be 0 , which ofcourse is not the case for a weak symbol . -- ramana dot radhakrishnan at codito dot com changed: What|Removed |Added Summary|invalid loop transformation.|invalid loop transformation. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27625
[Bug c/27628] Incorrect memory access type used used in accessing bitfields
--- Comment #1 from falk at debian dot org 2006-05-16 12:40 --- There is no guarantee that this happens, and it would suppress many useful optimizations. However, if you mark the fields as volatile, the ARM ABI guarantees that the access will be in the specified width (and after PR 23623 has been fixed, gcc should follow this). -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27628
[Bug middle-end/26528] [4.2 regression] gcc miscompiles FFTW 3.1
--- Comment #14 from martin at mpa-garching dot mpg dot de 2006-05-16 12:49 --- Even with PR 26304 fixed, the testsuite still crashes with a segfault in the same place. I'm using FFTW 3.1.1 now, but the testing procedure is the same. Again, the problem disappears with -fno-ivopts. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26528
[Bug c++/27129] [4.1/4.2 Regression] ICE in get_expr_operands
--- Comment #4 from jakub at gcc dot gnu dot org 2006-05-16 13:15 --- Testing a patch. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-04-12 11:17:02 |2006-05-16 13:15:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27129
[Bug c++/27491] [4.1/4.2 regression] ICE on variable initialization
--- Comment #3 from jakub at gcc dot gnu dot org 2006-05-16 13:33 --- Testing a patch. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-05-08 15:19:12 |2006-05-16 13:33:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27491
[Bug target/26885] [4.1/4.2 regression] -m64 -m32 no longer creates 32-bit object
--- Comment #9 from hjl at gcc dot gnu dot org 2006-05-16 14:27 --- Subject: Bug 26885 Author: hjl Date: Tue May 16 14:27:18 2006 New Revision: 113824 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113824 Log: gcc/ 2006-05-16 H.J. Lu [EMAIL PROTECTED] PR driver/26885 * Makefile.in (GCC_OBJS): New. (OBJS-common): Add opts-common.o. (xgcc$(exeext)): Replace gcc.o with $(GCC_OBJS). (cpp$(exeext)): Likewise. (gcc.o): Also depend on opts.h. (opts-common.o): New. * common.opt (gcoff): Add Negative(gdwarf-2). (gdwarf-2): Add Negative(gstabs). (gstabs): Add Negative(gstabs+). (gstabs+): Add Negative(gvms). (gvms): Add Negative(gxcoff). (gxcoff): Add Negative(gxcoff+). (gxcoff+): Add Negative(gcoff). * config/i386/i386.opt (m32): Add Negative(m64). (m64): Add Negative(m32). * doc/options.texi: Document the Negative option. * gcc.c: Include opts.h. (main): Call prune_options after expandargv. * optc-gen.awk: Generate common declarations for all flag variables in options.c. Output the neg_index field. * opts.c (find_opt): Moved to ... * opts-common.c: Here. New file. * opts.h (cl_option): Add a neg_index field. (find_opt): New. (prune_options): Likewise. gcc/cp/ 2006-05-16 H.J. Lu [EMAIL PROTECTED] PR driver/26885 * Make-lang.in (GXX_OBJS): Replace gcc.o with $(GCC_OBJS). gcc/fortran/ 2006-05-16 H.J. Lu [EMAIL PROTECTED] PR driver/26885 * Make-lang.in (GFORTRAN_D_OBJS): Replace gcc.o with $(GCC_OBJS). gcc/java/ 2006-05-16 H.J. Lu [EMAIL PROTECTED] PR driver/26885 * Make-lang.in ($(GCJ)$(exeext)): Replace gcc.o with $(GCC_OBJS). gcc/treelang/ 2006-05-16 H.J. Lu [EMAIL PROTECTED] PR driver/26885 * Make-lang.in (gtreelang$(exeext)): Replace gcc.o with $(GCC_OBJS). Added: trunk/gcc/opts-common.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/common.opt trunk/gcc/config/i386/i386.opt trunk/gcc/cp/ChangeLog trunk/gcc/cp/Make-lang.in trunk/gcc/doc/options.texi trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/Make-lang.in trunk/gcc/gcc.c trunk/gcc/java/ChangeLog trunk/gcc/java/Make-lang.in trunk/gcc/optc-gen.awk trunk/gcc/opts.c trunk/gcc/opts.h trunk/gcc/treelang/ChangeLog trunk/gcc/treelang/Make-lang.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26885
[Bug c++/27339] [4.1 Regression] out-of-class definition of value template parameter with private type
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-05-16 14:55 --- Fixed in 4.1.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27339
[Bug c++/27339] [4.1 Regression] out-of-class definition of value template parameter with private type
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-05-16 14:55 --- Subject: Bug 27339 Author: mmitchel Date: Tue May 16 14:54:55 2006 New Revision: 113825 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113825 Log: PR c++/27339 * cp-tree.h (perform_access_checks): New function. * semantics.c (perform_access_checks): New function. (perform_deferred_access_checks): Use it. * parser.c (cp_parser_simple_declaration): Adjust call to cp_parser_init_declarator. (cp_parser_type_parameter): Do not defer checks in default arguments. (cp_parser_explicit_specialization): Adjust call to cp_parser_single_declaration. (cp_parser_init_declarator): Perform template-parameter access checks. (cp_parser_parameter_declaration): Do not defer checks for template parameter default arguments. (cp_parser_template_declaration_after_export): Gather access checks for template parameters, and pass them to cp_parser_single_declaration. (cp_parser_template_parameter_access_checks): New function. (cp_parser_single_declaration): Add checks parameter. PR c++/27339 * g++.dg/parser/access8.C: Adjust error marker. * g++.dg/template/access17.C: New test. * g++.dg/template/access18.C: Likewise. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/access17.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/access18.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/cp-tree.h branches/gcc-4_1-branch/gcc/cp/parser.c branches/gcc-4_1-branch/gcc/cp/semantics.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/access8.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27339
[Bug c++/26757] [4.1/4.2 regression] C++ front-end producing two DECLs with the same UID
--- Comment #20 from mmitchel at gcc dot gnu dot org 2006-05-16 14:57 --- Andrew -- Is there any news on this patch? Is there anyone else available to review/test Andrew's patch? Thanks, -- Mark -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added CC||amacleod at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26757
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
--- Comment #2 from Georg dot Baum at post dot rwth-aachen dot de 2006-05-16 15:04 --- Yes, I think that would be good. Then you know that you are not doing something wrong but that it is a tool chain limitation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557
[Bug c++/26757] [4.1/4.2 regression] C++ front-end producing two DECLs with the same UID
--- Comment #21 from amacleod at redhat dot com 2006-05-16 15:16 --- Actually, no, no new news :-). I had forgotten about this one. I'll run it again today and check it in if no problems show up. You want it against 4.1 and mainline? or do you want to try it against mainline for a few days first? Risk is minor, but always present. :-P Andrew -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26757
[Bug tree-optimization/22303] CCP does not handle STRING_CSTs
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-05-16 15:34 --- Subject: Bug 22303 Author: rguenth Date: Tue May 16 15:34:12 2006 New Revision: 113826 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113826 Log: 2006-05-16 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/22303 * tree-ssa-ccp.c (fold_const_aggregate_ref): Handle reads from STRING_CSTs. (evaluate_stmt): Fall back to fold_const_aggregate_ref, if ccp_fold did not simplify the statement. * gcc.dg/tree-ssa/ssa-ccp-13.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ccp-13.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22303
[Bug tree-optimization/22303] CCP does not handle STRING_CSTs
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-05-16 15:34 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22303
[Bug c/27628] Incorrect memory access type used used in accessing bitfields
--- Comment #2 from ryan at embedded-iq dot com 2006-05-16 15:54 --- Subject: RE: Incorrect memory access type used used in accessing bitfields Hi Falk, Thanks for your reply. Any idea with what release PR 23623 will be fixed? 4.3.0? Regards, Ryan -Original Message- From: falk at debian dot org [mailto:[EMAIL PROTECTED] Sent: 16 May 2006 02:40 PM To: [EMAIL PROTECTED] Subject: [Bug c/27628] Incorrect memory access type used used in accessing bitfields --- Comment #1 from falk at debian dot org 2006-05-16 12:40 --- There is no guarantee that this happens, and it would suppress many useful optimizations. However, if you mark the fields as volatile, the ARM ABI guarantees that the access will be in the specified width (and after PR 23623 has been fixed, gcc should follow this). -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27628 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27628
[Bug c/27627] __builtin_nanf() doesn't return a _quiet_ nan on parisc
--- Comment #2 from soete dot joel at tiscali dot be 2006-05-16 15:58 --- Created an attachment (id=11477) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11477action=view) a very simpler test case afaik don't need precompile (just rebuild) (e.g. gcc -o nan2 Nan2.c; ./nan2) -- soete dot joel at tiscali dot be changed: What|Removed |Added Attachment #11476|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27627
[Bug target/26885] [4.1/4.2 regression] -m64 -m32 no longer creates 32-bit object
--- Comment #10 from hjl at lucon dot org 2006-05-16 16:32 --- Hi Mark, I realized that I had an updated patch http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00090.html to address a concern from http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00050.html Can I update gcc/doc/invoke.texi? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26885
[Bug target/26885] [4.1/4.2 regression] -m64 -m32 no longer creates 32-bit object
--- Comment #11 from mark at codesourcery dot com 2006-05-16 16:51 --- Subject: Re: [4.1/4.2 regression] -m64 -m32 no longer creates 32-bit object hjl at lucon dot org wrote: --- Comment #10 from hjl at lucon dot org 2006-05-16 16:32 --- Hi Mark, I realized that I had an updated patch http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00090.html to address a concern from http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00050.html Can I update gcc/doc/invoke.texi? OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26885
[Bug middle-end/27415] Iteration var in firstprivate or reduction clauses not reported
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-16 16:52:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27415
[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-16 17:03 --- This might turn out to be a kernel issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27619
[Bug target/26885] [4.1/4.2 regression] -m64 -m32 no longer creates 32-bit object
--- Comment #12 from hjl at gcc dot gnu dot org 2006-05-16 17:06 --- Subject: Bug 26885 Author: hjl Date: Tue May 16 17:06:05 2006 New Revision: 113828 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113828 Log: gcc/ 2006-05-16 H.J. Lu [EMAIL PROTECTED] PR driver/26885 * Makefile.in (GCC_OBJS): New. (OBJS-common): Add opts-common.o. (xgcc$(exeext)): Replace gcc.o with $(GCC_OBJS). (cpp$(exeext)): Likewise. (gcc.o): Also depend on opts.h. (opts-common.o): New. * common.opt (gcoff): Add Negative(gdwarf-2). (gdwarf-2): Add Negative(gstabs). (gstabs): Add Negative(gstabs+). (gstabs+): Add Negative(gvms). (gvms): Add Negative(gxcoff). (gxcoff): Add Negative(gxcoff+). (gxcoff+): Add Negative(gcoff). * config/i386/i386.opt (m32): Add Negative(m64). (m64): Add Negative(m32). * doc/options.texi: Document the Negative option. * gcc.c: Include opts.h. (main): Call prune_options after expandargv. * optc-gen.awk: Generate common declarations for all flag variables in options.c. Output the neg_index field. * opts.c (find_opt): Moved to ... * opts-common.c: Here. New file. * opts.h (cl_option): Add a neg_index field. (find_opt): New. (prune_options): Likewise. gcc/cp/ 2006-05-16 H.J. Lu [EMAIL PROTECTED] PR driver/26885 * Make-lang.in (GXX_OBJS): Replace gcc.o with $(GCC_OBJS). gcc/fortran/ 2006-05-16 H.J. Lu [EMAIL PROTECTED] PR driver/26885 * Make-lang.in (GFORTRAN_D_OBJS): Replace gcc.o with $(GCC_OBJS). gcc/java/ 2006-05-16 H.J. Lu [EMAIL PROTECTED] PR driver/26885 * Make-lang.in ($(GCJ)$(exeext)): Replace gcc.o with $(GCC_OBJS). gcc/treelang/ 2006-05-16 H.J. Lu [EMAIL PROTECTED] PR driver/26885 * Make-lang.in (gtreelang$(exeext)): Replace gcc.o with $(GCC_OBJS). Added: branches/gcc-4_1-branch/gcc/opts-common.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/Makefile.in branches/gcc-4_1-branch/gcc/common.opt branches/gcc-4_1-branch/gcc/config/i386/i386.opt branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/Make-lang.in branches/gcc-4_1-branch/gcc/doc/options.texi branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/Make-lang.in branches/gcc-4_1-branch/gcc/gcc.c branches/gcc-4_1-branch/gcc/java/ChangeLog branches/gcc-4_1-branch/gcc/java/Make-lang.in branches/gcc-4_1-branch/gcc/optc-gen.awk branches/gcc-4_1-branch/gcc/opts.c branches/gcc-4_1-branch/gcc/opts.h branches/gcc-4_1-branch/gcc/treelang/ChangeLog branches/gcc-4_1-branch/gcc/treelang/Make-lang.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26885
[Bug rtl-optimization/27625] invalid loop transformation.
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-16 17:07 --- This is all undefined code: for (reloc_ptr = __reloc_table, num_relocs = (unsigned int)__reloc_num;num_relocs; reloc_ptr++,num_relocs--) *(long *)(dp + *reloc_ptr) += (long)dp; reloc_ptr can only extend one place out to be valid. -- 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=27625
[Bug middle-end/23623] volatile keyword changes bitfield access size from 32bit to 8bit
-- 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=23623
[Bug c/27628] Incorrect memory access type used used in accessing bitfields
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-16 17:15 --- (In reply to comment #2) Subject: RE: Incorrect memory access type used used in accessing bitfields Hi Falk, Thanks for your reply. Any idea with what release PR 23623 will be fixed? 4.2.0, the person who closed did not set the target milestone. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27628
[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-05-16 17:16 --- -m64 asm: .L.main: mflr %r0 std %r0,16(%r1) stdu %r1,-128(%r1) ld %r9,[EMAIL PROTECTED](%r2) lwa %r0,0(%r9) sradi %r9,%r0,53 rldicl %r11,%r0,0,53 addi %r9,%r9,1 addi %r11,%r11,2047 cmpldi %cr7,%r9,2 or %r11,%r11,%r0 rldicr %r11,%r11,0,52 bge %cr7,.L3 mr %r11,%r0 .L3: std %r11,112(%r1) lfd %f0,112(%r1) fcfid %f0,%f0 frsp %f13,%f0 ld %r9,[EMAIL PROTECTED](%r2) lfs %f0,0(%r9) fdivs %f13,%f13,%f0 lfs %f0,[EMAIL PROTECTED](%r2) fcmpu %cr7,%f13,%f0 beq %cr7,.L2 bl abort nop .L2: li %r3,0 addi %r1,%r1,128 ld %r0,16(%r1) mtlr %r0 blr .long 0 .byte 0,0,0,1,128,0,0,0 .size main,.-.L.main .globl i .section.data .align 2 .type i, @object .size i, 4 i: .long 274 .globl f .align 2 .type f, @object .size f, 4 f: .long 1065353216 -mpowerpc64: main: stwu %r1,-16(%r1) mflr %r0 stw %r0,20(%r1) lis %r9,[EMAIL PROTECTED] lwa %r0,[EMAIL PROTECTED](%r9) sradi %r9,%r0,53 rldicl %r11,%r0,0,53 addi %r9,%r9,1 addi %r11,%r11,2047 cmpldi %cr7,%r9,2 or %r11,%r11,%r0 rldicr %r11,%r11,0,52 bge %cr7,.L3 mr %r11,%r0 .L3: std %r11,8(%r1) lfd %f0,8(%r1) fcfid %f0,%f0 frsp %f13,%f0 lis %r9,[EMAIL PROTECTED] lfs %f0,[EMAIL PROTECTED](%r9) fdivs %f13,%f13,%f0 lis %r9,[EMAIL PROTECTED] lfs %f0,[EMAIL PROTECTED](%r9) fcmpu %cr7,%f13,%f0 beq %cr7,.L2 bl abort .L2: li %r3,0 lwz %r0,20(%r1) mtlr %r0 addi %r1,%r1,16 blr .size main,.-main .globl i .section.sdata,aw,@progbits .align 2 .type i, @object .size i, 4 i: .long 274 .globl f .align 2 .type f, @object .size f, 4 f: .long 1065353216 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27619
[Bug target/27627] __builtin_nanf() doesn't return a _quiet_ nan on parisc
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-16 17:17 --- Why do you think this is a GCC bug? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27627
[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1
--- Comment #4 from olh at suse dot de 2006-05-16 17:24 --- Created an attachment (id=11478) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11478action=view) pr27619.s.diff gcc -Wall -o pr27619 -O2 -g --save-temps pr27619.c -m64 vs. gcc -Wall -o pr27619 -O2 -g --save-temps pr27619.c -mpowerpc64 does -mpowerpc64 default to 32bit by any chance? see stdu vs. stwu in fn prologue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27619
[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-16 17:27 --- (In reply to comment #4) does -mpowerpc64 default to 32bit by any chance? see stdu vs. stwu in fn prologue. Well I bet you have 32bit as the default. Anyways -mpowerpc64 is the 64bit register in 32bit mode. And the asm is not different except for differences in loading. I am wondering if there is context switch happening somewhere which is messing up the registers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27619
[Bug c/27629] New: SIGSEGV in printstack() on Solaris 9
C and C++ programs compiled with gcc 4.1 die with a SIGSEGV in Solaris 9
printstack(). The same programs run successfully when compiled with 4.0.2 and
prior. If this is due to a Solaris bug it would be great if gcc could work
around it.
$ cat t.c gcc -g t.c ./a.out || gdb -q a.out
int printstack (int);
int main ()
{
printstack (1);
}
Segmentation Fault (core dumped)
(gdb) run
Starting program: /tmp/a.out
Program received signal SIGSEGV, Segmentation fault.
0xff2d6f24 in display_stack_info () from /usr/lib/libc.so.1
(gdb) where
#0 0xff2d6f24 in display_stack_info () from /usr/lib/libc.so.1
#1 0xff2d6a84 in walkcontext () from /usr/lib/libc.so.1
#2 0xff2d6fb4 in printstack () from /usr/lib/libc.so.1
#3 0x000105b4 in main () at t.c:5
--
Summary: SIGSEGV in printstack() on Solaris 9
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: sparc-sun-solaris2.9
GCC host triplet: sparc-sun-solaris2.9
GCC target triplet: sparc-sun-solaris2.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27629
[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-05-16 17:28 --- Yes it does: [EMAIL PROTECTED]:/tmp gcc -o t -O -mpowerpc64 t.c -mregnames [EMAIL PROTECTED]:/tmp file t t: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), for GNU/Linux 2.6.4, not stripped with -mpowerpc64 -m64 it works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27619
[Bug target/26885] [4.1/4.2 regression] -m64 -m32 no longer creates 32-bit object
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-05-16 17:29 --- Grrr, this broke bootstrap every where. Did you test this at all? -fno-common added done by defualt to prevent cases like this. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26885
[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1
--- Comment #7 from olh at suse dot de 2006-05-16 17:30 --- yes, mpowerpc64 creates 32bit apps. -m64 (gdb) info float f0 274 (raw 0x40712000) f1 0(raw 0x) f2 0(raw 0x) f3 0(raw 0x) f4 0(raw 0x) f5 0(raw 0x) f6 0(raw 0x) f7 0(raw 0x) f8 0(raw 0x) f9 0(raw 0x) f100(raw 0x) f110(raw 0x) f120(raw 0x) f13274 (raw 0x40712000) f140(raw 0x) f150(raw 0x) f160(raw 0x) f170(raw 0x) f180(raw 0x) f190(raw 0x) f200(raw 0x) f210(raw 0x) f220(raw 0x) f230(raw 0x) f240(raw 0x) f250(raw 0x) f260(raw 0x) f270(raw 0x) f280(raw 0x) f290(raw 0x) f300(raw 0x) f310(raw 0x) fpscr 0x2000 8192 mpowerpc64 (gdb) info float f0 274 (raw 0x40712000) f1 0(raw 0x) f2 0(raw 0x) f3 0(raw 0x) f4 0(raw 0x) f5 0(raw 0x) f6 0(raw 0x) f7 0(raw 0x) f8 0(raw 0x) f9 0(raw 0x) f100(raw 0x) f110(raw 0x) f120(raw 0x) f131177886392320(raw 0x427123f8) f140(raw 0x) f150(raw 0x) f160(raw 0x) f170(raw 0x) f180(raw 0x) f190(raw 0x) f200(raw 0x) f210(raw 0x) f220(raw 0x) f230(raw 0x) f240(raw 0x) f250(raw 0x) f260(raw 0x) f270(raw 0x) f280(raw 0x) f290(raw 0x) f300(raw 0x) f310(raw 0x) fpscr 0x4000 16384 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27619
[Bug target/27629] SIGSEGV in printstack() on Solaris 9
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-16 17:31 --- (In reply to comment #0) If this is due to a Solaris bug it would be great if gcc could work around it. And this attitute is wrong. Did you file this with Sun yet? If not, you should say the same thing, if this is a GCC, Solaris should work around it. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27629
[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-05-16 17:34 --- The only thing I think we can do is warn that -mpowerpc64 might not work with Linux as the linux kernel does not save and restore the full register while doing a context switch (it is one reason why -mcpu=G5 -m32 does not turn on -mpowerpc64 on Linux). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27619
[Bug target/27629] SIGSEGV in printstack() on Solaris 9
--- Comment #2 from sebor at roguewave dot com 2006-05-16 17:35 --- I'm not sure what you find wrong with my attitude but yes, I did send Sun a note about it pointing them to this problem report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27629
[Bug target/26885] [4.1/4.2 regression] -m64 -m32 no longer creates 32-bit object
--- Comment #14 from hjl at lucon dot org 2006-05-16 17:37 --- I didn't see -fno-common in my build logs on Linux/x86, Linux/x86-64 and Linux/ia64. I am using: ../configure \ \ --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld \ \ --enable-shared \ --enable-threads=posix \ --enable-haifa \ --enable-checking=assert \ --prefix=/usr/gcc-4.2 \ --with-local-prefix=/usr/local to configure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26885
[Bug target/26885] [4.1/4.2 regression] -m64 -m32 no longer creates 32-bit object
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-05-16 17:39 --- (In reply to comment #14) --enable-checking=assert \ There is your issue. Why are you disabling all checking except for assert on the mainline for testing? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26885
[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1
--- Comment #9 from janis at gcc dot gnu dot org 2006-05-16 17:55 --- Good grief, if it might not work with Linux then it shouldn't be available for GNU/Linux targets. -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27619
[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1
--- Comment #10 from janis at gcc dot gnu dot org 2006-05-16 18:26 --- By the way, I found this by running SPEC CPU2000, FreePOOMA, FTensor, and Blitz++ with several sets of options plus either -m32, -m64, or -m32 -mpowerpc64 and this was the only failure I saw. This failure happens consistently. It seems as if a kernel issue would affect additional tests. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27619
[Bug tree-optimization/26678] [4.1/4.2 Regression] GNAT BUG DETECTED when compiling AWS.
--- Comment #16 from rguenth at gcc dot gnu dot org 2006-05-16 19:14 --- I'm not working on the Ada problem. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rguenth 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=26678
[Bug c++/26757] [4.1/4.2 regression] C++ front-end producing two DECLs with the same UID
--- Comment #22 from amacleod at redhat dot com 2006-05-16 20:48 --- Bootstraps on the 4.1 branch on i686-pc-linux-gnu and produces no new testsuite failures. It also allows the original testcase to compile. The mainline version is now running. Since it seems to be blocking other cases and there is some interest, I'm going to check it into 4.1, and then mainline later. If any issues pop up, we'll deal with them then. Andrew -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26757
[Bug c++/26757] [4.1/4.2 regression] C++ front-end producing two DECLs with the same UID
--- Comment #23 from amacleod at redhat dot com 2006-05-16 20:51 --- Subject: Bug 26757 Author: amacleod Date: Tue May 16 20:51:14 2006 New Revision: 113829 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113829 Log: Remove redundant hash table lookup when finding referenced vars. 2006-05-16 Andrew MacLeod [EMAIL PROTECTED] PR c++/26757 * tree-dfa.c (struct walk_state): Remove. (add_referenced_var): Change Parameters. (find_referenced_vars): Done use a walk_state. (find_vars_r): Unused parameter and change parms to add_referenced_var. (referenced_var_insert): Assert same UID has not been inserted. (add_referenced_var): Check if var exists via referenced_var table. (get_virtual_var): Call add_referenced_var with new parameter. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/tree-dfa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26757
[Bug middle-end/27536] [4.2 Regression] -fsection-anchors breaks Ada
--- Comment #10 from schwab at suse dot de 2006-05-16 20:56 --- Testresults here http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg00858.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27536
[Bug target/27082] segfault with virtual class and visibility (hidden)
--- Comment #4 from tbm at cyrius dot com 2006-05-16 21:11 --- Hmm, that's interesting. When I call g++ from a Makefile I get a unrecognizable insn error but calling it directly leads to the segfault. I've no idea if this unrecognizable insn error is helpful in any way but I thought I'd mention it here. Anyway, I can confirm this segfault on Alpha with gcc 4.0/4.1/4.2. (sid)[EMAIL PROTECTED]:~$ make x g++ -c test.c test.c: In constructor 'Virtual::Virtual()': test.c:1: error: unrecognizable insn: (insn 9 4 10 0 (set (reg/f:DI 70) (nil)) -1 (nil) (expr_list:REG_EQUAL (symbol_ref/i:DI (_ZTV7Virtual) [flags 0x2] var_decl 0x2316840 _ZTV7Virtual) (nil))) test.c:1: internal compiler error: in extract_insn, at recog.c:2084 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-4.1/README.Bugs. Preprocessed source stored into /tmp/cccHCxpV.out file, please attach this to your bugreport. make: *** [x] Error 1 (sid)[EMAIL PROTECTED]:~$ g++ -c test.c test.c: In constructor 'Virtual::Virtual()': test.c:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-4.1/README.Bugs. Preprocessed source stored into /tmp/ccrSaFP6.out file, please attach this to your bugreport. (sid)[EMAIL PROTECTED]:~$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27082
Re: [Bug target/27082] segfault with virtual class and visibility (hidden)
--- Comment #4 from tbm at cyrius dot com 2006-05-16 21:11 --- Hmm, that's interesting. When I call g++ from a Makefile I get a unrecognizable insn error but calling it directly leads to the segfault. I've no idea if this unrecognizable insn error is helpful in any way but I thought I'd mention it here. Anyway, I can confirm this segfault on Alpha with gcc 4.0/4.1/4.2. That means there is some memory curption going on. -- Pinski
[Bug target/27082] segfault with virtual class and visibility (hidden)
--- Comment #5 from pinskia at physics dot uc dot edu 2006-05-16 21:13 --- Subject: Re: segfault with virtual class and visibility (hidden) --- Comment #4 from tbm at cyrius dot com 2006-05-16 21:11 --- Hmm, that's interesting. When I call g++ from a Makefile I get a unrecognizable insn error but calling it directly leads to the segfault. I've no idea if this unrecognizable insn error is helpful in any way but I thought I'd mention it here. Anyway, I can confirm this segfault on Alpha with gcc 4.0/4.1/4.2. That means there is some memory curption going on. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27082
[Bug target/27082] segfault with virtual class and visibility (hidden)
--- Comment #6 from tbm at cyrius dot com 2006-05-16 21:22 --- (In reply to comment #2) Looking at the backtrace, this looks like a target specific issue. Yeah, cannot reproduce it on arm, i386, ia64, hppa, mips, powerpc. Can we add some Alpha GCC folks to the CC list of this bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27082
[Bug target/26885] [4.1/4.2 regression] -m64 -m32 no longer creates 32-bit object
--- Comment #16 from bernds_cb1 at t-online dot de 2006-05-16 21:30 --- I saw the fallout of this on the mailing list, but was the patch ever sent to gcc-patches before it was committed? -- bernds_cb1 at t-online dot de changed: What|Removed |Added CC||bernds_cb1 at t-online dot ||de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26885
[Bug target/26885] [4.1/4.2 regression] -m64 -m32 no longer creates 32-bit object
--- Comment #17 from mmitchel at gcc dot gnu dot org 2006-05-16 21:46 --- Yes, the patch was posted; see Comment #8. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26885
[Bug fortran/27633] New: Fortran accesses char array as integer
I got unaligned access on ia64 for
gcc/testsuite/gfortran.dg/transfer_array_intrinsic_2.f90
For
96subroutine test3 (ch1, ch2, ch3, clen)
97 integer clen
98 character(8) :: ch1(:)
99 character(*) :: ch2(2)
100 character(clen) :: ch3(2)
101 character(8) :: cntrl(2) = (/lmnoPQRS,LMNOpqrs/)
102 integer(8) :: ic(2)
103 ic = transfer (cntrl, ic)
Gfortran generates code like
(insn 1785 1391 2163 80
/net/gnu-13/export/gnu/src/gcc-4.1/gcc/gcc/testsuite/gfortran.dg/transfer_array_intrinsic_2.f90:103
(set (reg/f:DI 14 r14 [orig:406 D.2542 ] [406])
(plus:DI (high:DI (symbol_ref:DI (cntrl.1064) [flags 0x2] var_decl
0x2361da20 cntrl))
(reg:DI 1 r1))) 76 {*load_symptr_high} (nil)
(nil))
...
(insn 1786 2163 2164 80
/net/gnu-13/export/gnu/src/gcc-4.1/gcc/gcc/testsuite/gfortran.dg/transfer_array_intrinsic_2.f90:103
(set (reg/f:DI 14 r14 [orig:406 D.2542 ] [406])
(lo_sum:DI (reg/f:DI 14 r14 [orig:406 D.2542 ] [406])
(symbol_ref:DI (cntrl.1064) [flags 0x2] var_decl
0x2361da20 cntrl))) 77 {*load_symptr_low} (nil)
(nil))
...
(insn 1395 2164 2165 80
/net/gnu-13/export/gnu/src/gcc-4.1/gcc/gcc/testsuite/gfortran.dg/transfer_array_intrinsic_2.f90:103
(set (reg:DI 15 r15 [1139])
(mem/s/j:DI (post_inc:DI (reg/f:DI 14 r14 [orig:406 D.2542 ] [406])) [0
S8 A64])) 5 {*movdi_internal} (insn_list:REG_DEP_TRUE 1392 (nil))
(expr_list:REG_INC (reg/f:DI 14 r14 [orig:406 D.2542 ] [406])
(nil)))
So cntrl is read as 64bit integer.
--
Summary: Fortran accesses char array as integer
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27633
[Bug fortran/27634] New: formatted reading/writing: real format without dot
real val
character str*6
open(1,FILE=tmp.dat)
read(1,'(a6,f4)') str,val
print*,str,val
end
gfortran tells me as follows:
read(1,'(a6,f4)') str,val
1
Warning: Period required in format string at (1)
# ./a.out
At line 4 of file read_gfc_test.f
Fortran runtime error: Period required in format
(a6,f4)
^
At compile time, gfortran issues only a warning, although it aborts
unconditionally at runtime, which comes as a bad surprise.
Either gfortran should abort at compile time, or it should support
this syntax (f4 as an equivalent of f4.0).
Same issue also for writing.
Support would be probably easy (not regtested, but works for me):
At Line 726 of libgfortran/io/format.c:
if (t != FMT_PERIOD)
{
/* We treat missing decimal descriptor as 0 !! */
fmt-saved_token = t;
tail-u.real.d = 0;
break;
}
This is a regression vs. g77.
--
Summary: formatted reading/writing: real format without dot
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manfred99 at gmx dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27634
[Bug fortran/27633] Fortran accesses char array as integer with transfer
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-16 22:19 --- I already mentioned before it should be using VIEW_CONVERT_EXPR instead of an address and a NOP_EXPR but nobody listened to me in the orginal bug report. Note this effects both strict alignment targets and aliasing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2006-05-16 22:19:40 date|| Summary|Fortran accesses char array |Fortran accesses char array |as integer |as integer with transfer http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27633
[Bug c++/27635] New: failure of template class with with inherited templated classes
Member variables of parent class are not found under template constructions where the template type is passed to the parent class. -- Summary: failure of template class with with inherited templated classes Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: johnbrown at pentum dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27635
[Bug c++/27635] failure of template class with with inherited templated classes
--- Comment #1 from johnbrown at pentum dot com 2006-05-16 22:38 --- Created an attachment (id=11479) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11479action=view) Test case gcc -v : gcc version 4.0.2 20051125 (Red Hat 4.0.2-8) uname Linux plinux 2.6.11-1.1369_FC4 #1 Thu Jun 2 22:55:56 EDT 2005 i686 athlon i386 GNU/Linux Compile: gcc junk.cpp Produces: junk.cpp:43: error: f was not declared in this scope -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27635
[Bug c++/27635] failure of template class with with inherited templated classes
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-16 22:39 --- Please read: http://gcc.gnu.org/gcc-3.4/changes.html This is not a bug. -- Pinski -- 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=27635
[Bug c++/27635] failure of template class with with inherited templated classes
--- Comment #3 from johnbrown at pentum dot com 2006-05-16 22:40 --- Created an attachment (id=11480) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11480action=view) -save-temp file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27635
[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1
--- Comment #11 from janis at gcc dot gnu dot org 2006-05-16 22:42 --- As mentioned above, the Linux kernel does not provide context switching support needed for -m32 -mpowerpc64. I'm looking into disabling it for powerpc64-linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27619
[Bug c++/27635] failure of template class with with inherited templated classes
--- Comment #4 from johnbrown at pentum dot com 2006-05-16 22:52 --- (In reply to comment #2) Please read: http://gcc.gnu.org/gcc-3.4/changes.html This is not a bug. -- Pinski (In reply to comment #2) Thanks, you are correct. Please read: http://gcc.gnu.org/gcc-3.4/changes.html This is not a bug. -- Pinski -- johnbrown at pentum dot com changed: What|Removed |Added Severity|normal |major http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27635
[Bug target/27636] New: Bad thunk alias to stdcall method
Compiling the following program:
#define STDCALL __attribute__((stdcall))
struct B1 {
int x;
virtual int STDCALL bar(int x) = 0;
};
struct B2 {
int x;
virtual int STDCALL foo(int x) = 0;
};
struct D: B1, B2 {
int a;
int STDCALL bar(int n);
int STDCALL foo(int n);
};
int STDCALL
D::bar(int n) {
return a + n;
}
int STDCALL
D::foo(int n) {
return a + n;
}
with gcc -x c++ gccbug5.c on MinGW results in the following error message:
gccbug5.c:26: error: 'int *LTHUNK0(int)' aliased to undefined symbol
'_ZN1D3fooEi'
--
Summary: Bad thunk alias to stdcall method
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rridge at csclub dot uwaterloo dot ca
GCC build triplet: i386-pc-mingw32
GCC host triplet: i386-pc-mingw32
GCC target triplet: i386-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27636
[Bug target/27636] Bad thunk alias to stdcall method
--- Comment #1 from rridge at csclub dot uwaterloo dot ca 2006-05-16 23:38 --- LTHUNK0 should be aliased to [EMAIL PROTECTED]. The bug goes away if D::bar(int) is not defined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27636
[Bug target/27636] Bad thunk alias to stdcall method
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-16 23:54 --- This looks related to Bug 27067. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||27067 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27636
[Bug target/27636] Bad thunk alias to stdcall method
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-16 23:55 --- Does the patch there fix this issue also? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27636
[Bug fortran/27634] formatted reading/writing: real format without dot
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-05-17 00:16 --- I will investigate this a bit. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-17 00:16:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27634
[Bug libfortran/27575] gfortran - does not generate error when trying to read too much data
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-05-17 00:37 --- Subject: Bug 27575 Author: jvdelisle Date: Wed May 17 00:36:53 2006 New Revision: 113837 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113837 Log: 2006-05-16 Jerry DeLisle [EMAIL PROTECTED] PR libgfortran/27575 * io/transfer.c (read_block): Add check for end file condition. (read_block_direct): Add check for end file condition. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27575
[Bug libfortran/27575] gfortran - does not generate error when trying to read too much data
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-05-17 00:41 --- Subject: Bug 27575 Author: jvdelisle Date: Wed May 17 00:40:23 2006 New Revision: 113838 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113838 Log: 2006-05-16 Jerry DeLisle [EMAIL PROTECTED] PR libgfortran/27575 * gfortran.dg/read_eof_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/read_eof_4.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27575
[Bug target/27627] __builtin_nanf() doesn't return a _quiet_ nan on parisc
--- Comment #4 from danglin at gcc dot gnu dot org 2006-05-17 00:49 --- This isn't a target bug as far as I can tell. The value generated by __builtin_nanf() as shown by Nan2.c is 0x7fc0. The same value is printed on x86. This is a signaling NaN. Positive quiet NaNs range between 0x7f81 and 0x7fbf. We have the following code for at -02: .LC0: .word 2143289344 .text .align 4 .globl main .type main, @function main: .PROC .CALLINFO FRAME=0,CALLS,SAVE_RP .ENTRY stw %r2,-20(%r30) ldil LR'.LC0,%r28 ldil LR'.LC1,%r26 ldw RR'.LC0(%r28),%r25 ldo RR'.LC1(%r26),%r26 ldw -20(%r30),%r2 bl printf,%r0 nop nop .EXIT 2143289344 is 0x7fc0 hex. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27627
[Bug awt/20630] GTK 2.8 peer Image and Graphics API reorganization
--- Comment #6 from sven at physto dot se 2006-05-17 00:56 --- I should update my previous comment: DataBuffers created by the user, i.e. the DataBuffer implementations in the public API do wrap true java arrays. However, when creating a BufferedImage on the JDK the corresponding DataBuffer is not one of the public implementations. And that most likely wraps a native bitmap. This seems like a good idea, and it's what I'm currently advocating. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20630
[Bug target/26600] [4.1/4.2 Regression] internal compiler error: in push_reload, at reload.c:1303
--- Comment #11 from sayle at gcc dot gnu dot org 2006-05-17 01:12 --- Subject: Bug 26600 Author: sayle Date: Wed May 17 01:11:59 2006 New Revision: 113839 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113839 Log: PR target/26600 * config/i386/i386.c (legitimate_constant_p) CONST_DOUBLE: TImode integer constants other than zero are only legitimate on TARGET_64BIT. CONST_VECTOR Only zero vectors are legitimate. (ix86_cannot_force_const_mem): Integral and vector constants can always be put in the constant pool. * gcc.target/i386/pr26600.c: New test case. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.target/i386/pr26600.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/i386/i386.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26600
[Bug target/27636] Bad thunk alias to stdcall method
--- Comment #4 from wszafran at users dot sourceforge dot net 2006-05-17 01:15 --- (In reply to comment #2) This looks related to Bug 27067. Not only related but pretty much the same thing. And Ross' example program compiles cleanly using the latest 4.1.1 (20060512) snapshot with Danny's patch for 27067 applied. I don't have the 4.2.0 available but I imagine the same patch can be used to mend it as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27636
[Bug tree-optimization/27373] [4.2 Regression] ICE: add_virtual_operand with pointers to arrays
--- Comment #8 from dberlin at gcc dot gnu dot org 2006-05-17 01:16 --- Subject: Bug 27373 Author: dberlin Date: Wed May 17 01:16:08 2006 New Revision: 113840 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113840 Log: 2006-05-16 Daniel Berlin [EMAIL PROTECTED] Fix PR tree-optimization/27373 * tree-ssa-forwprop.c: (forward_propagate_addr_expr_1): Add argument. (forward_propagate_addr_expr): Update call. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr27373.c Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-forwprop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27373
[Bug target/27636] Bad thunk alias to stdcall method
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-17 02:36 --- *** This bug has been marked as a duplicate of 27067 *** -- 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=27636
[Bug target/27067] Compile errors with multiple inheritance where the stdcall attribute is applied to virtual functions.
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-17 02:36 --- *** Bug 27636 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rridge at csclub dot ||uwaterloo dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27067
[Bug other/27513] Add RatFor support
--- Comment #4 from rchapman at acm dot org 2006-05-17 03:44 --- (In reply to comment #3) I don't mind putting it back in, Jim described what needs to be done in PR24357. I don't have a ratfor processor to test with, so I'd prefer if someone else wrote (i.e. copied from gcc 4.0) and tested the necessary specs. I too would love to see Ratfor support reinstated. I really appreciate the expertise and efforts of the developers and maintainers and am sure that they always have a long list of things to do. Unfortunately, I do not have the 'smarts' to write and test the necessary specs. I have been maintaining a branch of 'PD Ratfor in C' derived from 'Ratfor in C' (as posted by Ozan Yigit [oz] June 19, 1985, in 'net.sources' on Usenet with subsequent modifications by Ken Yap and W. Bauske) and have used it extensively with GCC versions prior to 4.x on a variety of platforms. I would be glad to provide this 'ratfor' packaged as a GNU Build System distribution tarball to anyone who can write and test the specs. The tarball contains a conventional 'configure', 'make', 'make install' distribution (including man page, info document, and two simple ratfor test programs) that has been validated for linux (RedHat Fedora) and MingW. Thanks for your time and attention. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27513
