[Bug middle-end/35676] internal compiler error: in expand_mult, at expmed.c:3225
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-24 08:56 --- This works for me on the trunk with -march=i486 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35676
[Bug rtl-optimization/35675] gcc hangs with -frtl-abstract-sequences -O[23s]
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-03-24 08:59 --- This is most likely a dup of bug 33009. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35675
[Bug target/31558] ICE with __builtin_vec_splat
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-24 09:30 --- I am testing this patch on powerpc-darwin right now and should be able to submit it tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31558
[Bug objc/29197] [4.0/4.1/4.2/4.3/4.4 Regression] ICE after error with array type with undefined variable
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-09-24 03:03:53 |2008-03-24 09:11:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29197
[Bug middle-end/34212] spurious warning: value computed is not used
--- Comment #12 from pinskia at gcc dot gnu dot org 2008-03-24 09:09 --- My patch does not work as we now don't warn for +f(); which is wrong. I am no longer going to work on 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=34212
[Bug objc/29197] [4.0/4.1/4.2/4.3/4.4 Regression] ICE after error with array type with undefined variable
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-03-24 09:01 --- (In reply to comment #5) I am no longer working on this. I am about to post a patch for this, I found the patch on my machine after all this time :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29197
[Bug testsuite/35677] New: Intermitent failure FAIL: libgomp.fortran/crayptr2.f90
For the record, I see an intermitent failure (3 out of 44 tests) of libgomp.fortran/crayptr2.f90 on i686-apple-darwin9: rev. 132129: FAIL: libgomp.fortran/crayptr2.f90 -O2 execution test rev. 133270: FAIL: libgomp.fortran/crayptr2.f90 -O3 -fomit-frame-pointer -funroll-loops execution test rev. 133469: FAIL: libgomp.fortran/crayptr2.f90 -O0 execution test The first case occured with -m64 and the two others with -m32 (default). -- Summary: Intermitent failure FAIL: libgomp.fortran/crayptr2.f90 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35677
[Bug rtl-optimization/35675] gcc hangs with -frtl-abstract-sequences -O[23s]
--- Comment #5 from eric dot weddington at atmel dot com 2008-03-24 14:46 --- The patch in bug #33009 does indeed fix the problem that I'm seeing. Closing bug as duplicate of #33009. *** This bug has been marked as a duplicate of 33009 *** -- eric dot weddington at atmel dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35675
[Bug rtl-optimization/33009] -frtl-abstract-sequences causes an infinite loop
--- Comment #17 from eric dot weddington at atmel dot com 2008-03-24 14:46 --- *** Bug 35675 has been marked as a duplicate of this bug. *** -- eric dot weddington at atmel dot com changed: What|Removed |Added CC||eric dot weddington at atmel ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33009
[Bug c/22371] C front-end produces mis-match types in MODIFY_EXPR
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-03-24 15:09 --- Subject: Bug 22371 Author: rguenth Date: Mon Mar 24 15:08:52 2008 New Revision: 133479 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133479 Log: 2008-03-24 Richard Guenther [EMAIL PROTECTED] PR c/22371 * gimplify.c (gimplify_modify_expr): For frontend type-correct pointer assignments change conversions according to middle-end rules. (gimplify_modify_expr_rhs): Deal with NULL TARGET_EXPR_INITIAL. * configure.ac: Include type checking in yes. * configure: Regenerate. Modified: trunk/gcc/ChangeLog trunk/gcc/configure trunk/gcc/configure.ac trunk/gcc/gimplify.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22371
[Bug c/22371] C front-end produces mis-match types in MODIFY_EXPR
--- Comment #14 from rguenth at gcc dot gnu dot org 2008-03-24 15:10 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22371
[Bug c/22371] C front-end produces mis-match types in MODIFY_EXPR
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-03-24 15:10 --- Really. -- 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=22371
[Bug middle-end/35674] openMP parallel for pragma with SIMD type as reduction variable crashes gcc
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-24 16:08 --- Ok, on i686-linux-gnu, I can reproduce this failure. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|gcc version 4.2.1 (SUSE | |Linux) ../configure -- | |enable-threads=pos | GCC host triplet|i586-suse-linux | Last reconfirmed|-00-00 00:00:00 |2008-03-24 16:08:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35674
[Bug c++/35678] New: partial template specialization ICE in dependent_type_p, at cp/pt.c:15539
Consider:
templatetypename T, T struct A;
templatetypename struct B;
templatetemplatetypename T, T class U struct BUchar, 'h' {};
BAchar,'h' x;
// internal compiler error: in dependent_type_p, at cp/pt.c:15539
Comeau 4.3.9 and GCC 4.1.2 accept the code.
--
Summary: partial template specialization ICE in dependent_type_p,
at cp/pt.c:15539
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35678
[Bug regression/35671] [POSSIBLY NOT A BUG] GCC 4.3.0 vs. 4.2.3 observations
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-24 16:10 --- Does the code size difference goes away when you compare w/o -ftree-vectorize ? It might be the case we are no vectorizing more which means we have peeled more loops and such. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35671
[Bug c++/35678] [4.3/4.4 Regression] partial template specialization ICE in dependent_type_p, at cp/pt.c:15539
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-24 16:14 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.3.0 Known to work||4.2.0 Last reconfirmed|-00-00 00:00:00 |2008-03-24 16:14:23 date|| Summary|partial template|[4.3/4.4 Regression] partial |specialization ICE in |template specialization ICE |dependent_type_p, at|in dependent_type_p, at |cp/pt.c:15539 |cp/pt.c:15539 Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35678
[Bug rtl-optimization/35388] [4.2 Regression] error compiling dealII SPEC CPU 2006 benchmark
--- Comment #3 from falk at debian dot org 2008-03-24 16:23 --- I can't reproduce this on Alpha Linux with Debian 4.2.3-2. On that system, long double is 16 bytes. What's the length on your system? Also, can you try 4.3? -- falk at debian dot org changed: What|Removed |Added CC||falk at debian dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35388
[Bug tree-optimization/35653] [4.3/4.4 Regression]: gcc-4.3 -O3/-ftree-vectorize regression: incorrect code generation
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-03-24 16:34 --- I think the code is violating alignment requirements of the C/C++ standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35653
[Bug target/35659] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64
--- Comment #2 from kmccarty at debian dot org 2008-03-24 16:47 --- (In reply to comment #1) Does it work with gcc 4.2? Yes, it does, at least with this version: (sid)[EMAIL PROTECTED]:~$ gfortran-4.2 -v Using built-in specs. Target: ia64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --disable-libmudflap --disable-libssp --with-system-libunwind --enable-checking=release --build=ia64-linux-gnu --host=ia64-linux-gnu --target=ia64-linux-gnu Thread model: posix gcc version 4.2.3 (Debian 4.2.3-2) The test case works in all cases with gfortran 4.2, regardless of whether I use libkernlib.a and libkerngent.a compiled with gfortran 4.2 or 4.3. (But please let me know if you need copies of these libraries built with gfortran 4.2 anyway.) I also just noticed, surprisingly, that with gfortran 4.3, if I compile the test program with -O3 or with -O3 -funroll-loops, the test succeeds. So oddly enough it is ONLY with -O2 (without -funroll-loops) that the test fails. (Again, this behavior is independent of which gfortran version I use to build libkernlib.a and libkerngent.a.) Please also let me know if you need the intermediate .f and .o files built with gfortran-4.3 -O3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35659
[Bug tree-optimization/35653] [4.3/4.4 Regression]: gcc-4.3 -O3/-ftree-vectorize regression: incorrect code generation
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-03-24 16:48
---
I tend to agree with Andrew here. If you go through a packed union the failure
vanishes:
union U {
unsigned u;
}__attribute__((packed));
int main()
{
char buf[256];
char *dest;
int i;
dest = buf[2];
for (i = 0; i 32; i++)
{
((union U *)dest)-u = 0;
dest += 4;
}
return buf[2];
}
So, IMHO this bug is invalid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35653
[Bug tree-optimization/35653] [4.3/4.4 Regression]: gcc-4.3 -O3/-ftree-vectorize regression: incorrect code generation
--- Comment #13 from edwintorok at gmail dot com 2008-03-24 17:00 ---
(In reply to comment #11)
I think the code is violating alignment requirements of the C/C++ standard.
First a real bug here is that -Wstrict-aliasing doesn't warn of this situation.
Do you agree?
Unaligned accesses is undefined in general, I agree.
But on x86 it has always been possible to do unaligned accesses, and it is
possible even with vector instructions (movdqu). Of course these are slower
than aligned accesses, but there should be some way to express them in C [*]
The most natural way to do that is to typecast, and this has worked, knowing
that x86 doesn't have instructions that can SIGBUS/SIGSEGV on unaligned
accesses (not true anymore with vector instructions), or knowing that compilers
won't generate vectorized code for unaligned accesses (true until gcc-4.3
AFAIK).
If you decide to handle unaligned accesses as undefined even for x86, the Linux
kernel developers should be notified:
The kernel has a macro, that is defined as such on x86:
#define get_unaligned(ptr) (*(ptr))
And defined using these generically for non-x86 architectures
struct __una_u32 { __u32 x __attribute__((packed)); };
static inline __u32 __uldl(const __u32 *addr)
{
const struct __una_u32 *ptr = (const struct __una_u32 *) addr;
return ptr-x;
}
[*]: this can be used to express unaligned accesses safely
And it is being used in a loop:
http://lxr.linux.no/linux/net/bluetooth/bnep/core.c#L153
BTW, the original code for this bugreport does unaligned accesses only on
little-endian architectures, and this has worked on all compilers until now:
#if WORDS_BIGENDIAN == 0
..
#define cli_readint32(buff) (*(const int32_t *)(buff))
...
#else
...
static inline int32_t cli_readint32(const char *buff)
{
int32_t ret;
ret = buff[0] 0xff;
ret |= (buff[1] 0xff) 8;
ret |= (buff[2] 0xff) 16;
ret |= (buff[3] 0xff) 24;
return ret;
}
...
#endif
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35653
[Bug driver/35532] Native GCC no longer searches $prefix/lib for startfiles when run from $objdir
--- Comment #10 from carlos at codesourcery dot com 2008-03-24 17:25
---
Greg,
I've gone through your DIY instructions. Very well done. Using the sysroot
infrastructure is definitely the way forward for you. Looking at your existing
DIY instructions you probably want to:
1. Create a Construct sysroot step before the first stage gcc (3.5), this
will include creating $sysroot/usr/include.
2. Install the kernel headers (3.6) as part of the Construct sysroot step, or
as the next step.
You might want to verify that this is still needed:
~~~
echo
/* Remove /usr/include from end of include search path. */
#undef STANDARD_INCLUDE_DIR
#define STANDARD_INCLUDE_DIR 0 gcc/config/${DL_HEADER}
~~~
in step (3.10).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532
[Bug target/35659] [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-03-24 17:32 --- Possibly a scheduling issue. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.2.3 Summary|Miscompiled code with -O2 |[4.3/4.4 Regression] |(but not with -O2 -funroll- |Miscompiled code with -O2 |loops) on ia64 |(but not with -O2 -funroll- ||loops) on ia64 Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35659
[Bug fortran/35395] Invalid-accepted - public entity with private type should be diagnosed
--- Comment #4 from w6ws at earthlink dot net 2008-03-24 17:47 --- Subject: Re: Invalid-accepted - public entity with private type should be diagnosed pault at gcc dot gnu dot org wrote: This is permitted in F2003 so you have to apply the F95 standard to extract the message out of gfortran: OK, I have researched this further, and concur with your response. In fact, MRC 95/2003 discusses this in section 18.14. (I finally bought a copy last week...) So you may close the PR. However it would also be nice if at least the following web pages were updated to show that the feature is now supported: http://gcc.gnu.org/wiki/GFortran#news http://gcc.gnu.org/wiki/Fortran2003 http://gcc.gnu.org/wiki/Fortran2003Status Thank you, Walter -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35395
[Bug libstdc++/35679] New: Cannot build cross compiler for i686-pc-linux-gnu: configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES
/configure --disable-nls --disable-c-mbchar --disable-shared --prefix=/emc/ucode/Linux-2x-i686/gcc3x/v4.3.0-2.18-2008-03-15 --target=i686-emc-elf --enable-languages=c++ --disable-multilib --with-gnu-as --with-gnu-ld --with-gmp=/home/blah/gmp --with-mpfr=/home/blah/mpfr --with-newlib --with-headers=/home/blah/core-toolchain/newlib-1.16.0/newlib/libc/include checking dynamic linker characteristics... no checking how to hardcode library paths into programs... immediate checking for shl_load... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[2]: *** [configure-target-libstdc++-v3] Error 1 -- Summary: Cannot build cross compiler for i686-pc-linux-gnu: configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yakov at emc dot com GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35679
[Bug fortran/34955] transfer_assumed_size_1.f90: Valgrind error: invalid read of size 3
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2008-03-24 18:43
---
OK, I now can reproduce it. Here's a reduced testcase:
module TransferBug
type ByteType
integer(kind=1) :: singleByte
end type
type(ByteType) :: BytesPrototype(1)
contains
function StringToBytes(v) result (bytes)
character(len=2) :: v
type (ByteType) :: bytes(size(transfer(v, BytesPrototype)))
bytes = transfer('Hi', BytesPrototype)
end function
subroutine BytesToString(bytes, string)
type (ByteType) :: bytes(2)
character(len=*) :: string
string = transfer(bytes, string)
end subroutine
end module
program main
use TransferBug
character(len=3) :: str
call BytesToString( StringToBytes('Hi'), str )
end program
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-03-24 18:43:13
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34955
[Bug fortran/35680] New: [4.3/4.4 regression] ICE on invalid transfer in variable declaration
program main print *, foo() contains function foo() integer foo(size(transfer(x, [1]))) real x end function end program gives: a.f90:2: internal compiler error: Segmentation fault gfortran 4.1.2 20070626 (Red Hat 4.1.2-14) says: In file a.f90:5 integer foo(size(transfer(x, [1]))) 1 Error: Variable 'x' cannot appear in the expression at (1) -- Summary: [4.3/4.4 regression] ICE on invalid transfer in variable declaration Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680
[Bug middle-end/32396] [4.1/4.2 Regression] gcc uses 0 as altivec load/store index
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-24 19:02 --- This was indeed fixed by PR 34529: .L3: stvx 0,0,9 stvx 0,9,0 addi 9,9,32 bdnz .L3 -- Pinski -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.3.0 4.4.0 Summary|[4.1/4.2/4.3/4.4 Regression]|[4.1/4.2 Regression] gcc |gcc uses 0 as altivec |uses 0 as altivec load/store |load/store index|index http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32396
[Bug fortran/33295] ICE in fold_const.c (fold_convert) when reordering USE statements
--- Comment #7 from pault at gcc dot gnu dot org 2008-03-24 19:12 --- Subject: Bug 33295 Author: pault Date: Mon Mar 24 19:11:24 2008 New Revision: 133488 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133488 Log: 2008-03-24 Paul Thomas [EMAIL PROTECTED] PR fortran/34813 * resolve.c (resolve_structure_cons): It is an error to assign NULL to anything other than a pointer or allocatable component. PR fortran/33295 * resolve.c (resolve_symbol): If the symbol is a derived type, resolve the derived type. If the symbol is a derived type function, ensure that the derived type is visible in the same namespace as the function. 2008-03-24 Paul Thomas [EMAIL PROTECTED] PR fortran/34813 * gfortran.dg/null_3.f90 : New test PR fortran/33295 * gfortran.dg/module_function_type_1.f90 : New test Added: trunk/gcc/testsuite/gfortran.dg/module_function_type_1.f90 trunk/gcc/testsuite/gfortran.dg/null_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33295
[Bug fortran/34813] ICE on incorrect nested type constructor (fold-const.c (fold_convert):2629)
--- Comment #4 from pault at gcc dot gnu dot org 2008-03-24 19:12 --- Subject: Bug 34813 Author: pault Date: Mon Mar 24 19:11:24 2008 New Revision: 133488 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133488 Log: 2008-03-24 Paul Thomas [EMAIL PROTECTED] PR fortran/34813 * resolve.c (resolve_structure_cons): It is an error to assign NULL to anything other than a pointer or allocatable component. PR fortran/33295 * resolve.c (resolve_symbol): If the symbol is a derived type, resolve the derived type. If the symbol is a derived type function, ensure that the derived type is visible in the same namespace as the function. 2008-03-24 Paul Thomas [EMAIL PROTECTED] PR fortran/34813 * gfortran.dg/null_3.f90 : New test PR fortran/33295 * gfortran.dg/module_function_type_1.f90 : New test Added: trunk/gcc/testsuite/gfortran.dg/module_function_type_1.f90 trunk/gcc/testsuite/gfortran.dg/null_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34813
[Bug tree-optimization/35653] [4.3/4.4 Regression]: gcc-4.3 -O3/-ftree-vectorize regression: incorrect code generation
--- Comment #14 from victork at gcc dot gnu dot org 2008-03-24 19:14
---
I tend to agree with Andrew here. If you go through a packed union the
failure
vanishes:
So, IMHO this bug is invalid.
The fact that failure vanishes is not a good argument here. The failure
vanishes simply because vectorized failed to vectorize dest-u statement.
Here is an modified example
struct U
{
unsigned u;
};
int main()
{
struct U buf[256];
struct U *dest;
int i;
dest = buf;
for (i = 0; i 32; i++)
{
dest-u = 0;
dest += 1;
}
return buf[2].u;
}
And it is not vectorized without any good reason.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35653
[Bug fortran/35681] New: wrong result for vector subscripted array expression in MVBITS
The following program prints out the wrong results when an array with vector valued subscript is used in an expression as the FROM argument and also used as the TO argument. The array case gives different results from a similar scalar DO loop. If a different array is used in the FROM argument, the array results are the same as the scalar results. I'd guess that you aren't recognizing (ILA1(NFV3)) as an expression and copying it to a temp before invoking MVBITS. Dick Hendrickson program YA0017 ! gcc version 4.4.0 20080312 (experimental) [trunk revision 133139] (GCC) INTEGER ILA1(10) INTEGER ILA2(10) INTEGER ICA3(10), nfv3(10) ILA1 = (/1,2,3,4,5,6,7,8,9,10/) ILA2 = (/1,2,3,4,5,6,7,8,9,10/) ica3 = (/1,2,3,4,5,6,7,8,9,10/) nfv3 = (/9,9,6,2,4,9,2,9,6,10/) DO J1 = 1,10 CALL MVBITS(Ila1(NFV3(J1)),2,4,ILA2(J1), 3) ENDDO CALL MVBITS ((ILA1(NFV3)), 2, 4, ILA1, 3) !fails print *, 'first test' DO J1 = 1,10 IF (ILA1(J1) .NE. ILA2(J1)) $ print *, 'j1 = ', j1, ' vvs = ', nfv3(j1), $ ' scalar =', ila2(j1), ' vector = ', ila1(j1) ENDDO ILA1 = (/1,2,3,4,5,6,7,8,9,10/) ILA2 = (/1,2,3,4,5,6,7,8,9,10/) ica3 = (/1,2,3,4,5,6,7,8,9,10/) nfv3 = (/9,9,6,2,4,9,2,9,6,10/) DO J1 = 1,10 CALL MVBITS(Ica3(NFV3(J1)),2,4,ILA2(J1), 3) ENDDO CALL MVBITS ((Ica3(NFV3)), 2, 4, ILA1, 3) !works print *, 'second test' DO J1 = 1,10 IF (ILA1(J1) .NE. ILA2(J1)) $ print *, 'j1 = ', j1, ' vvs = ', nfv3(j1), $ ' scalar =', ila2(j1), ' vector = ', ila1(j1) ENDDO END --- results C:\g_experiments\gfortrangfortran ya0017.f C:\g_experiments\gfortrana first test j1 =4 vvs =2 scalar = 4 vector = 36 j1 =5 vvs =4 scalar = 13 vector = 77 j1 =7 vvs =2 scalar = 7 vector = 39 j1 =9 vvs =6 scalar = 9 vector = 41 second test -- Summary: wrong result for vector subscripted array expression in MVBITS Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dick dot hendrickson at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug libstdc++/35679] Cannot build cross compiler for i686-pc-linux-gnu: configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES
--- Comment #1 from brian at dessent dot net 2008-03-24 19:54 --- Subject: Re: New: Cannot build cross compiler for i686-pc-linux-gnu: configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES yakov at emc dot com wrote: --target=i686-emc-elf --enable-languages=c++ --disable-multilib --with-gnu-as Your title for this bug is misleading as it seems you're building a cross for a newlib bare metal target, not i686-pc-linux-gnu. That's just the host, and is irrelevant to the issue. There is currently a known problem with the libstdc++ configury and bare metal newlib targets. You can fix it either by providing BSP files (crt*.o, linker script, etc) for your board so that test programs can be linked, or you can disable the AC_LIBTOOL_DLOPEN check in libstc++-v3/configure.ac for newlib targets, as in http://gcc.gnu.org/ml/gcc/2007-11/msg00790.html. For a summary of the history of this issue: http://gcc.gnu.org/ml/gcc/2008-03/msg00515.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35679
[Bug fortran/27997] Fortran 2003: Support type-spec for array constructor
--- Comment #5 from d at domob dot eu 2008-03-24 20:01 --- Created an attachment (id=15370) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15370action=view) Partly fixed patch This patch fixes the problem described above with respect to correct detection of seen_ts and adds some tests (hope this is ok); the string conversion problem is still failing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27997
[Bug fortran/35682] New: assignment to run-time zero-sized complex section stores a value
When I try the following test program, a value is stored into the first element of the complex array, even though the array section is zero sized. It fails with variables for the section subscripts and works if I use explicit constants for the subscripts. Dick Hendrickson -- C:\g_experiments\gfortrangfortran ha0020.f C:\g_experiments\gfortrana first test 1 (-1., 0.000) second test -- program try_ha0020 call ha0020(1,10,-1,2,-3) end program SUBROUTINE HA0020(nf1,nf10,mf1,nf2,mf3) COMPLEX XCA(20), xda(20) do I = 1,20 xca(i) = i xda(i) = -i enddo XCA(NF1:NF10:MF1) = XDA(NF1:NF2:MF3)!fails print *, 'first test' DO J1 = 1,20 if (xca(j1) .ne. j1) print *, j1, xca(j1) enddo do I = 1,20 xca(i) = i xda(i) = -i enddo xca( 1: 10: -1) = xda( 1: 2: -3)!works print *, 'second test' DO J1 = 1,20 if (xca(j1) .ne. j1) print *, j1, xca(j1) enddo END SUBROUTINE -- Summary: assignment to run-time zero-sized complex section stores a value Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dick dot hendrickson at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35682
[Bug libstdc++/35679] Cannot build cross compiler for i686-pc-linux-gnu: configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES
--- Comment #2 from yakov at emc dot com 2008-03-24 20:29 --- Subject: Re: Cannot build cross compiler for i686-pc-linux-gnu: configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES Brian, first, thank you very much for such a quick response. Actually, this target is i[3456789]86-*-elf) /*gcc-4.3.0/configure */ sincerely, yakov brian at dessent dot net wrote: --- Comment #1 from brian at dessent dot net 2008-03-24 19:54 --- Subject: Re: New: Cannot build cross compiler for i686-pc-linux-gnu: configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES yakov at emc dot com wrote: --target=i686-emc-elf --enable-languages=c++ --disable-multilib --with-gnu-as Your title for this bug is misleading as it seems you're building a cross for a newlib bare metal target, not i686-pc-linux-gnu. That's just the host, and is irrelevant to the issue. There is currently a known problem with the libstdc++ configury and bare metal newlib targets. You can fix it either by providing BSP files (crt*.o, linker script, etc) for your board so that test programs can be linked, or you can disable the AC_LIBTOOL_DLOPEN check in libstc++-v3/configure.ac for newlib targets, as in http://gcc.gnu.org/ml/gcc/2007-11/msg00790.html. For a summary of the history of this issue: http://gcc.gnu.org/ml/gcc/2008-03/msg00515.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35679
[Bug fortran/35682] assignment to run-time zero-sized complex section stores a value
--- Comment #1 from dick dot hendrickson at gmail dot com 2008-03-24 20:35 --- Some similar assignment statements that work correctly ZCA(NF1:NF10:MF1) = ZDA(NF1:NF10:MF1) XCA(NF10:NF5:NF2) = XDA(NF4:NF9:MF2) where the NF* variables have the value * and the MF* variables have the value -*. NF3 = 3, MF2 = -2 Dick Hendrickson -- dick dot hendrickson at gmail dot com changed: What|Removed |Added CC||dick dot hendrickson at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35682
[Bug fortran/35685] New: UBOUND incorrect for run-time zero-sized section
The following program gives the wrong value for the UBOUND function on a zero sized array. It looks correct for constant section subscripts, but incorrect for run-time expressions. The related functions, LBOUND, SHAPE, and SIZE are correct. Dick Hendrickson C:\g_experiments\gfortrangfortran ja0045.f C:\g_experiments\gfortrana UBOUND ZDA1= 0 -5 -1 --- program try_ja0045 call ja0045(3,-3,7,1,6) end program SUBROUTINE JA0045(nf3,mf3,nf7,nf1,nf6) INTEGER IDA(3) real ZDA1(3:10,4:10,5:10) IDA = UBOUND(ZDA1(3:2, NF3:MF3, NF7+NF1:NF6)) if ( any(ida .ne. (/0,0,0/)) ) print *, 'UBOUND ZDA1=',ida IDA = LBOUND(ZDA1(3:2, NF3:MF3, NF7+NF1:NF6)) if ( any(ida .ne. (/1,1,1/)) ) print *, 'LBOUND =',ida IDA = SHAPE(ZDA1(3:2, NF3:MF3, NF7+NF1:NF6)) if ( any(ida .ne. (/0,0,0/)) ) print *, 'SHAPE =',ida J = SIZE(ZDA1(3:2, NF3:MF3, NF7+NF1:NF6)) if ( j .ne. 0 ) print *, 'SIZE =',j END SUBROUTINE -- Summary: UBOUND incorrect for run-time zero-sized section Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dick dot hendrickson at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35685
[Bug fortran/33295] ICE in fold_const.c (fold_convert) when reordering USE statements
--- Comment #8 from pault at gcc dot gnu dot org 2008-03-24 21:11 --- Subject: Bug 33295 Author: pault Date: Mon Mar 24 21:10:36 2008 New Revision: 133490 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133490 Log: 2008-03-24 Paul Thomas [EMAIL PROTECTED] PR fortran/34813 * resolve.c (resolve_structure_cons): It is an error to assign NULL to anything other than a pointer or allocatable component. PR fortran/33295 * resolve.c (resolve_symbol): If the symbol is a derived type, resolve the derived type. If the symbol is a derived type function, ensure that the derived type is visible in the same namespace as the function. 2008-03-24 Paul Thomas [EMAIL PROTECTED] PR fortran/34813 * gfortran.dg/null_3.f90 : New test PR fortran/33295 * gfortran.dg/module_function_type_1.f90 : New test Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/module_function_type_1.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/null_3.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/resolve.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33295
[Bug fortran/34813] ICE on incorrect nested type constructor (fold-const.c (fold_convert):2629)
--- Comment #5 from pault at gcc dot gnu dot org 2008-03-24 21:11 --- Subject: Bug 34813 Author: pault Date: Mon Mar 24 21:10:36 2008 New Revision: 133490 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133490 Log: 2008-03-24 Paul Thomas [EMAIL PROTECTED] PR fortran/34813 * resolve.c (resolve_structure_cons): It is an error to assign NULL to anything other than a pointer or allocatable component. PR fortran/33295 * resolve.c (resolve_symbol): If the symbol is a derived type, resolve the derived type. If the symbol is a derived type function, ensure that the derived type is visible in the same namespace as the function. 2008-03-24 Paul Thomas [EMAIL PROTECTED] PR fortran/34813 * gfortran.dg/null_3.f90 : New test PR fortran/33295 * gfortran.dg/module_function_type_1.f90 : New test Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/module_function_type_1.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/null_3.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/resolve.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34813
[Bug c++/35686] New: Incorrect value returned by function that uses a std::vector
Very simple function returns value of vector-item instead of the correct value.
Code compiles without any problem. Running it returns incorrect value.
Tried it with Intel and Microsoft compilers, both return the correct value.
Code (since I do not see a method to attach anything here...):
#include iostream
#include vector
std::vectorint next;
long numOfNodes = 5;
int addNode(void)
{
next.push_back(-1);
return numOfNodes;
}
int main ( int argc, char *argv[] )
{
next = std::vectorint ();
next.push_back(-1);
next[0] = addNode();
std::cout Returned value: next[0] std::endl;
std::cout Real Value: (numOfNodes) std::endl;
return 0;
}
--
Summary: Incorrect value returned by function that uses a
std::vector
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lmdv_gnu at mandata dot nl
GCC build triplet: ../configure --enable-threads=posix --prefix=/usr --
with-local-
GCC host triplet: gcc version 4.2.1 (SUSE Linux)
GCC target triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35686
[Bug c++/35686] Incorrect value returned by function that uses a std::vector
--- Comment #1 from lmdv_gnu at mandata dot nl 2008-03-24 21:14 --- Created an attachment (id=15371) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15371action=view) preprocessed file of the program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35686
[Bug c++/35686] Incorrect value returned by function that uses a std::vector
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-24 21:16 --- next[0] = addNode(); This will invoke undefined behavior as the order of execution of the lhs and rhs of the assignment expression is unspecified. So a compiler can invoke either next[0] first or addNode() first. Both are valid. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED GCC build triplet| ../configure --enable- |../configure --enable- |threads=posix --prefix=/usr |threads=posix --prefix=/usr |--with-local- |--with-local- Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35686
[Bug c++/35546] [4.3/4.4 Regression] __attribute__(format...) broken for members of template classes?
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-24 21:28 --- CCing Jason as he was the one who did the attribute delaying patches for 4.3.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35546
[Bug c++/35686] Incorrect value returned by function that uses a std::vector
--- Comment #3 from lmdv_gnu at mandata dot nl 2008-03-24 21:29 --- Does this mean that it is correct that no assigment takes place? Even though the returned value is an integer that has nothing to do with the vector? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35686
[Bug c++/35686] Incorrect value returned by function that uses a std::vector
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-03-24 21:34 --- It means that the vector is probably re-allocated and the value stored into dead memory. Using valgrind should uncover that fact. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35686
[Bug c++/35686] Incorrect value returned by function that uses a std::vector
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-03-24 21:35 --- (In reply to comment #3) Does this mean that it is correct that no assigment takes place? So what is happening is that next[0] returns a reference and that reference goes invalid when next.push_back(-1) gets called. So the assignment happens, just to the wrong place :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35686
[Bug c++/35686] Incorrect value returned by function that uses a std::vector
--- Comment #6 from lmdv_gnu at mandata dot nl 2008-03-24 21:38 --- ok, I understand. Thanks for your help! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35686
[Bug fortran/35685] UBOUND incorrect for run-time zero-sized section
-- burnus 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 |2008-03-24 22:11:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35685
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
-- burnus 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 |2008-03-24 22:13:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug regression/35671] [POSSIBLY NOT A BUG] GCC 4.3.0 vs. 4.2.3 observations
--- Comment #2 from t dot artem at mailcity dot com 2008-03-24 22:24 --- I'll check this out very soon - at least on Wine sources. Recompiling KDE isn't a task I'm very found of. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35671
[Bug ada/35687] New: [4.4 Regression] gnatmake: /test/gnu/gcc/gcc-svn/gcc/ada/gnatchop.adb compilation error
make[3]: Entering directory `/test/gnu/gcc/objdir/gcc/ada/tools' ../../gnatmake -c -I../rts -I. -I/test/gnu/gcc/gcc/gcc/ada gnatchop --GCC=../.. /xgcc -B../../ -g -O2 -mdisable-indexing -gnatpg -gnata ../../xgcc -c -I./ -I../rts -I. -I/test/gnu/gcc/gcc/gcc/ada -B../../ -g -O2 -mdi sable-indexing -gnatpg -gnata -I- /test/gnu/gcc/gcc-svn/gcc/ada/gnatchop.adb gnatmake: /test/gnu/gcc/gcc-svn/gcc/ada/gnatchop.adb compilation error make[3]: *** [../../gnatchop] Error 4 make[3]: Leaving directory `/test/gnu/gcc/objdir/gcc/ada/tools' make[2]: *** [gnattools-native] Error 2 make[2]: Leaving directory `/test/gnu/gcc/objdir/gnattools' make[1]: *** [all-gnattools] Error 2 -bash-3.2$ ./xgcc -B./ -v Reading specs from ./specs Target: hppa2.0w-hp-hpux11.11 Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu/bin/as --enable-shared --disable-nls --with-local-prefix=/opt/gnu --prefix=/opt/gnu/gcc/gcc-4.4.0 --enable-debug=no --enable-threads=posix --with-mpfr=/opt/gnu/gcc/gcc-4.4.0 --with-gmp=/opt/gnu/gcc/gcc-4.4.0 --disable-libmudflap --enable-languages=c,c++,objc,obj-c++,fortran,java,ada Thread model: posix gcc version 4.4.0 20080323 (experimental) [trunk revision 133462] (GCC) -- Summary: [4.4 Regression] gnatmake: /test/gnu/gcc/gcc- svn/gcc/ada/gnatchop.adb compilation error Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35687
[Bug regression/35671] [POSSIBLY NOT A BUG] GCC 4.3.0 vs. 4.2.3 observations
--- Comment #3 from t dot artem at mailcity dot com 2008-03-24 23:01 --- counting all .so and .a files in lib/wine directory: Without -ftree-vectorize: GCC 4.2.3: 46,884,566 bytes in 305 files GCC 4.3.0: 47,375,178 bytes in 305 files With -ftree-vectorize: GCC 4.2.3: 46,889,486 bytes in 305 files GCC 4.3.0: 47,397,130 bytes in 305 files It's not like too much to care about. I have to test using different sources. The truth is that Windows archivers work slower in Wine compiled using GCC 4.3. That was the real grief. -- t dot artem at mailcity dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35671
[Bug rtl-optimization/26222] [4.2 Regression] build failuring in libjava
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-03-24 23:06 --- Subject: Bug 26222 Author: pinskia Date: Mon Mar 24 23:05:31 2008 New Revision: 133493 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133493 Log: 2008-03-24 Andrew Pinski [EMAIL PROTECTED] PR middle-end/26222 * gcc.dg/torture/pr26222.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr26222.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26222
[Bug ada/35687] [4.4 Regression] gnatmake: /test/gnu/gcc/gcc-svn/gcc/ada/gnatchop.adb compilation error
--- Comment #1 from danglin at gcc dot gnu dot org 2008-03-24 23:18 --- Error also occurs on linux. -- danglin at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|hppa2.0w-hp-hpux11.11 |hppa*-*-* (32-bit) GCC host triplet|hppa2.0w-hp-hpux11.11 |hppa*-*-* (32-bit) GCC target triplet|hppa2.0w-hp-hpux11.11 |hppa*-*-* (32-bit) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35687
[Bug c++/35688] New: template visibility botch
/* { dg-require-visibility } */
/* { dg-options -fvisibility=hidden } */
/* { dg-final { scan-hidden __ZN1s6vectorI1AEC1Ev } } */
/* { dg-final { scan-hidden __ZN1s3fooI1AEEvT_ } } */
/* Radar 5813435 */
namespace s __attribute__((visibility(default))) {
template class T
class vector {
public:
vector() { }
};
template class T
void foo(T t) {
}
}
class A {
public:
A() { }
};
s::vectorA v;
int main() {
A a;
s::foo(a);
}
should pass (if I got the spelling for the symbols correct wrt leading _).
radr://5813435
--
Summary: template visibility botch
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35688
[Bug target/35657] TDmode isn't aligned at 128bit when passing to a function
--- Comment #3 from hjl dot tools at gmail dot com 2008-03-25 00:42 ---
This patch will align DFP to its natural boundary.
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c (revision 1917)
+++ gcc/config/i386/i386.c (working copy)
@@ -4609,7 +4609,8 @@ ix86_function_arg_boundary (enum machine
align = GET_MODE_ALIGNMENT (mode);
if (align PARM_BOUNDARY)
align = PARM_BOUNDARY;
- if (!TARGET_64BIT)
+ /* Decimal floating point is aligned to its natural boundary. */
+ if (!TARGET_64BIT !VALID_DFP_MODE_P (mode))
{
/* i386 ABI defines all arguments to be 4 byte aligned. We have to
make an exception for SSE modes since these require 128bit
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35657
[Bug c++/35689] New: ostream no longer usable with java exceptions
The pdftk package fails to compile under gcc 4.3.1 from the gcc 4.3 branch due the error... /sw/lib/gcc4.3/bin/g++ pdftk.cc -I../java_libs -O3 -DPATH_DELIM=0x2f -DASK_ABOUT_WARNINGS=false -fdollars-in-identifiers -DPDFTK_VER=\1.41\ -c /sw/lib/gcc4.3/lib/gcc/i686-apple-darwin9/4.3.1/../../../../include/c++/4.3.1/bits/ostream_insert.h: In function 'std::basic_ostream_CharT, _Traits std::__ostream_insert(std::basic_ostream_CharT, _Traits, const _CharT*, std::streamsize) [with _CharT = char, _Traits = std::char_traitschar]': /sw/lib/gcc4.3/lib/gcc/i686-apple-darwin9/4.3.1/../../../../include/c++/4.3.1/ostream:517: instantiated from 'std::basic_ostreamchar, _Traits std::operator(std::basic_ostreamchar, _Traits, const char*) [with _Traits = std::char_traitschar]' pdftk.cc:114: instantiated from here /sw/lib/gcc4.3/lib/gcc/i686-apple-darwin9/4.3.1/../../../../include/c++/4.3.1/bits/ostream_insert.h:107: error: mixing C++ and Java catches in a single translation unit This error occurs for any cerr or cout in pdftk.cc. -- Summary: ostream no longer usable with java exceptions Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35689
[Bug c++/35689] ostream no longer usable with java exceptions
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-03-25 00:57 --- This regression doesn't exist in gcc 4.2.3 on i686-apple-darwin9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35689
[Bug libstdc++/35689] ostream no longer usable with java exceptions
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-25 01:03 --- I don't think this is a GCC bug at all. libstdc++ can use exceptions freely really since it is C++ code. Since there is no way to combine C++ and Java exceptions in one TU, we reject the code. Now there is exception usage in ostream, yes this is new for 4.3.0 but does not mean it is a bug in GCC. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35689
[Bug libstdc++/35689] ostream no longer usable with java exceptions
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2008-03-25 01:05 --- Created an attachment (id=15372) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15372action=view) compressed preprocessed source file for pdftk.cc File generated with... /sw/lib/gcc4.3/bin/g++ pdftk.cc -I../java_libs -O3 -E -o pdftk.i -DPATH_DELIM=0x2f -DASK_ABOUT_WARNINGS=false -fdollars-in-identifiers -DPDFTK_VER=\1.41\ -c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35689
[Bug libstdc++/35689] ostream no longer usable with java exceptions
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-03-25 01:08 --- Basically it is wrong that pdftk is using C++ I/O here really but instead java I/O. Anyways this is the correct error. -- 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=35689
[Bug libstdc++/35689] ostream no longer usable with java exceptions
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2008-03-25 01:12 --- So it is meaningless now to attempt to set #pragma GCC java_exceptions in c++ code? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35689
[Bug libstdc++/35689] ostream no longer usable with java exceptions
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-03-25 01:15 --- (In reply to comment #5) So it is meaningless now to attempt to set #pragma GCC java_exceptions in c++ code? This is C++ code but it is CNI code also so setting that is ok. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35689
[Bug fortran/34828] ICE: GNU MP: Cannot reallocate memory for gfortran.dg/parameter_array_init_3.f90
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2008-03-25 02:53 --- Un-assigning myself. I can see valgrind errors but have been unable to isolate the problem. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jvdelisle 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=34828
[Bug tree-optimization/26069] [4.0/4.1/4.2/4.3 Regression] Runtime endian-ness check is no longer optimized out.
--- Comment #22 from pinskia at gcc dot gnu dot org 2008-03-25 03:42 --- All of these testcases work correctly now on the trunk (except for an extra store for the one in comment #11 but that is PR 30271). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.4.0 Summary|[4.0/4.1/4.2/4.3/4.4|[4.0/4.1/4.2/4.3 Regression] |Regression] Runtime endian- |Runtime endian-ness check is |ness check is no longer |no longer optimized out. |optimized out. | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26069
[Bug bootstrap/35451] stage2 bootstrap xgcc infinite loop
--- Comment #1 from oblivian at users dot sourceforge dot net 2008-03-25 04:05 --- I've started over using the 4.3.0 release source files instead of svn and still have the same problem. After more checking I've narrowed this down to stage 2 ld-new, collect2 and the xgcc from stage 1. The do_spec_1 routine shows argbuf getting loaded with the path to ./prev-gcc/xgcc instead of a -L./prev-gcc/ linker directory. This causes collect2 or the executor (I'm still not clear on the run path) to run xgcc again which loads with the wrong argbuf again and calls collect2 again and so on until it eats all memory obviously. If I copy the ld-new from prev-ld to the stage2 ld directory the stage2 compiler will run and inserts -L./prev-gcc ok. I'm still trying to track down if this is a binutils ld problem or if binutils is broken by 4.3.0. I know first indication is that ld and therefore binutils is broken, but as I said before the exact same setup with 4.2.3 works fine. Also, I've now tried the compile setup I stated before, except on a gcc 4.2.3, binutils 2.18 and glibc 2.7 system as the host. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35451
[Bug tree-optimization/35429] [4.1/4.2/4.3/4.4 regression] ICE with complex arithmetic
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-25 04:23 --- 2005-12-22 Richard Guenther [EMAIL PROTECTED] * tree.c (tree_fold_gcd): Use build_int_cst where appropriate. * tree-ssa-loop-ivcanon.c (create_canonical_iv): Likewise. * varasm.c (array_size_for_constructor): Likewise. * fold-const.c (size_diffop, invert_truthvalue, optimize_bit_field_compare, make_range, build_range_check, fold_cond_expr_with_comparison, fold_truthop, fold_single_bit_test_into_sign_test, fold_binary): Likewise. Caused it though using BIT_IOR_EXPR on a complex type does not make sense does it? Anyways adding INTEGRAL_TYPE_P makes it work. Also I think there are some missed optimization due to a full equality check of the types rather than a weaker one, I will file them as seperate bugs. Mine, I am testing the obvious patch which adds the check for INTEGRAL_TYPE_P. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-03-15 01:27:39 |2008-03-25 04:23:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35429
[Bug middle-end/35691] New: Missed (a == 0) (b == 0) into (a|(typeof(a)(b)) == 0 when the types don't match
While looking into PR 35429, I noticed this small missed optimization.
If we have:
typedef unsigned int1;
int foo(int z0, int1 z1)
{
return z0 != 0 || z1 != 0;
}
int foo1(int z0, int1 z1)
{
return z0 == 0 z1 == 0;
}
--- CUT ---
Both of those should optimize as int is the same size as unsigned and we are
comparing against 0. The same thing should happen with int and long on a ILP32
target.
--
Summary: Missed (a == 0) (b == 0) into (a|(typeof(a)(b)) == 0
when the types don't match
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35691
[Bug tree-optimization/35429] [4.1/4.2/4.3/4.4 regression] ICE with complex arithmetic
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-25 04:34 ---
Here is the patch which I am testing:
Index: fold-const.c
===
--- fold-const.c(revision 133503)
+++ fold-const.c(working copy)
@@ -5357,7 +5357,8 @@ fold_truthop (enum tree_code code, tree
if (code == TRUTH_OR_EXPR
lcode == NE_EXPR integer_zerop (lr_arg)
rcode == NE_EXPR integer_zerop (rr_arg)
- TREE_TYPE (ll_arg) == TREE_TYPE (rl_arg))
+ TREE_TYPE (ll_arg) == TREE_TYPE (rl_arg)
+ INTEGRAL_TYPE_P (TREE_TYPE (ll_arg)))
return build2 (NE_EXPR, truth_type,
build2 (BIT_IOR_EXPR, TREE_TYPE (ll_arg),
ll_arg, rl_arg),
@@ -5367,7 +5368,8 @@ fold_truthop (enum tree_code code, tree
if (code == TRUTH_AND_EXPR
lcode == EQ_EXPR integer_zerop (lr_arg)
rcode == EQ_EXPR integer_zerop (rr_arg)
- TREE_TYPE (ll_arg) == TREE_TYPE (rl_arg))
+ TREE_TYPE (ll_arg) == TREE_TYPE (rl_arg)
+ INTEGRAL_TYPE_P (TREE_TYPE (ll_arg)))
return build2 (EQ_EXPR, truth_type,
build2 (BIT_IOR_EXPR, TREE_TYPE (ll_arg),
ll_arg, rl_arg),
Index: testsuite/gcc.c-torture/compile/complex-5.c
===
--- testsuite/gcc.c-torture/compile/complex-5.c (revision 0)
+++ testsuite/gcc.c-torture/compile/complex-5.c (revision 0)
@@ -0,0 +1,9 @@
+int foo(__complex__ int z0, __complex__ int z1)
+{
+ return z0 != 0 || z1 != 0;
+}
+
+int foo1(__complex__ int z0, __complex__ int z1)
+{
+ return z0 == 0 z1 == 0;
+}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35429
[Bug fortran/33295] ICE in fold_const.c (fold_convert) when reordering USE statements
--- Comment #9 from pault at gcc dot gnu dot org 2008-03-25 05:34 --- Fixed on trumk and 4.3. Thanks for the report. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33295
[Bug fortran/34813] ICE on incorrect nested type constructor (fold-const.c (fold_convert):2629)
--- Comment #6 from pault at gcc dot gnu dot org 2008-03-25 05:34 --- Fixed on trumk and 4.3. Thanks for the report. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34813
[Bug fortran/32179] Ensure that ss-string_length is always set [TODO item]
--- Comment #3 from pault at gcc dot gnu dot org 2008-03-25 05:42 --- Not only did the TODO disappear but the problem SEEMs to have done so too. The last attempt at a fix was pretty all embracing and has ensured that the scalarizer is always getting a string expression to work with. That said, I just know that another such bug is going to appear:) I am going to tempt fate... Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32179
