[Bug fortran/31205] aliased operator assignment produces wrong result
--- Comment #1 from pault at gcc dot gnu dot org 2007-03-17 07:26 --- The aliasing of the arguments to subroutine set results in the initialization of the intent(out) also being applied to the intent(in) argument. I feel a temporary coming on. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-17 07:26:16 date|| Summary|wrong code generated with |aliased operator assignment |gfortran|produces wrong result http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31205
[Bug ada/31174] [4.2 regression] ACATS C380004 fails
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2007-03-17 07:30 --- Probably uncovered by disabling VRP... -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|gcc-4.2-20070307| GCC host triplet|Red Hat 10.0| GCC target triplet|X86 | Last reconfirmed|-00-00 00:00:00 |2007-03-17 07:30:48 date|| Summary|ACATS C380004 Fails |[4.2 regression] ACATS ||C380004 fails http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31174
[Bug ada/31174] [4.2 regression] ACATS C380004 fails
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-03-17 07:30:48 |2007-03-17 07:31:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31174
[Bug ada/31108] [4.2 regression] ACATS C35507M fails
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-03-17 07:33 --- I have to rerun the ACATS tests with more disk space available. After the C3 tests all other failures were due to disk full. OK, please report the results of a complete run. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31108
[Bug fortran/31205] aliased operator assignment produces wrong result
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-17 07:38 --- This is related to PR 14771, most likely the parentheses are being ignored. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31205
[Bug fortran/31237] New: [meta-bug] TRANSFER intrinsic
Just a meta-bug to keep track of problems with TRANSFER. Most of these should go away once we write (and call) gfc_simplify_transfer. -- Summary: [meta-bug] TRANSFER intrinsic Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org BugsThisDependsOn: 18769,30881,31194 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31237
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #17 from ubizjak at gmail dot com 2007-03-17 09:45 --- (In reply to comment #16) As far as I can tell the problem is fixed, at least for Mac OSX 10.3. Thanks Richard for your patience. I have just noticed the following oddity with the code: [karma] bug/cexp_pb% g++-4 -O1 failure_v6.c failure_v6.c: In function 'int main()': failure_v6.c:4: warning: canonical types differ for identical types double __complex__ and double __complex__ complex_type 0x9958c0 type real_type 0x42e238c0 double sizes-gimplified DF This is PR middle-end/30666. Patch for this problem is waiting for review. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug c/31238] New: Too many instructions in C loop
Build the following code with gcc -std=c99 -Wall -Wextra -Werror -Os -S:
void q(const unsigned int);
void f() {for (unsigned int x = 0; x != 10; ++x) q(77);}
The loop becomes:
.L2:
subl$12, %esp
incl%ebx
pushl $77
callq
addl$16, %esp
cmpl$10, %ebx
jne .L2
This is 7 instructions, which is too much. The following equivalent program:
void q(const unsigned int);
void f() {for (unsigned int x = 10; x; --x) q(77);}
becomes:
.L2:
subl$12, %esp
pushl $77
callq
addl$16, %esp
decl%ebx
jne .L2
which is only 6 instructions. Since the programs are equivalent (both just call
q(77) 10 times) and the second version becomes shorter than the first, the
first version is not optimized properly.
The corresponding Ada program with q.ads:
procedure Q(N : in Natural);
and f.adb:
with Q;
procedure F is begin for i in 1 .. 10 loop Q(77); end loop; end F;
built with gnatgcc -Os -Wall -Wextra -Wextra -Werror -S f.adb produces the
following loop:
.L5:
pushl $77
.LCFI3:
call_ada_q
popl%eax
decl%ebx
jns .L5
which is only 5 instructions. I know that situations are often encountered
where C code can not be optimized as much as Ada code, because it would break
some bizarre C feature. I do not know it this is such a situation, or if the C
code could actually become as tight as the Ada code when compiled and
optimized.
But at least the first version of the C code should be optimized to be as tight
as the second version.
(Tested with gcc 4.1.1 (Gentoo 4.1.1-r3) and gnatgcc 3.4.5 (from Gentoo
dev-lang/gnat-3.45).)
--
Summary: Too many instructions in C loop
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sigra at home dot se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31238
[Bug fortran/31209] too much indirection for actual pointer procedure
--- Comment #1 from pault at gcc dot gnu dot org 2007-03-17 10:18 ---
This fixes it and regtests OK - will submit later on
Index: gcc/fortran/trans-expr.c
===
*** gcc/fortran/trans-expr.c(revision 122943)
--- gcc/fortran/trans-expr.c(working copy)
*** gfc_conv_function_call (gfc_se * se, gfc
*** 2078,2083
--- 2078,2084
{
gfc_conv_expr_reference (parmse, e);
if (fsym fsym-attr.pointer
+fsym-attr.flavor != FL_PROCEDURE
e-expr_type != EXPR_NULL)
{
/* Scalar pointer dummy args require an extra level of
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-03-17 10:18:57
date||
Summary|wrong code generated with |too much indirection for
|gfortran|actual pointer procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31209
[Bug fortran/31237] [meta-bug] TRANSFER intrinsic
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||meta-bug Last reconfirmed|-00-00 00:00:00 |2007-03-17 11:22:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31237
[Bug fortran/31234] Thread-safety of random_number should be documented.
-- 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 |2007-03-17 11:22:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31234
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #90 from fxcoudert at gcc dot gnu dot org 2007-03-17 11:24 --- Closing as fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug fortran/31229] kind parameter in function declaration fails to find use-associated parameters
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|i686-pc-linux-gnu | Known to fail||4.1.3 4.2.0 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-03-17 11:25:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31229
[Bug fortran/31184] gfortran option description wrong.
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-17 11:30 --- Subject: Bug 31184 Author: fxcoudert Date: Sat Mar 17 11:30:20 2007 New Revision: 123018 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123018 Log: PR fortran/31184 * invoke.texi: Fix typo. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/invoke.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31184
[Bug c/31239] New: bootstrap fails on 32-bit x86 solaris2.11
building gcc on opensolaris fails. the build attempts to build a 64 bit compiler on a 32 bit system.. gmake GCC_FOR_TARGET=/export/home/error404/Code/gcc-4.1.1/host-i386-pc-solaris2.11/gcc/xgcc -B/export/home/error404/Code/gcc-4.1.1/host-i386-pc-solaris2.11/gcc/ -B/opt/local/i386-pc-solaris2.11/bin/ -B/opt/local/i386-pc-solaris2.11/lib/ -isystem /opt/local/i386-pc-solaris2.11/include -isystem /opt/local/i386-pc-solaris2.11/sys-include \ AR_FOR_TARGET=ar \ AR_CREATE_FOR_TARGET=ar rc \ AR_EXTRACT_FOR_TARGET=ar x \ AR_FLAGS_FOR_TARGET= \ CC=gcc CFLAGS=-march=pentium-m -O3 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute \ BUILD_PREFIX= \ BUILD_PREFIX_1=loser- \ LANGUAGES= \ LIBGCC2_CFLAGS=-O2 -O2 -march=pentium-m -O3 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -m64 \ MULTILIB_CFLAGS= -m64 T=amd64/ amd64/gmon.o amd64/crtbegin.o amd64/crtend.o gmake[4]: Entering directory `/export/home/error404/Code/gcc-4.1.1/host-i386-pc-solaris2.11/gcc' /export/home/error404/Code/gcc-4.1.1/host-i386-pc-solaris2.11/gcc/xgcc -B/export/home/error404/Code/gcc-4.1.1/host-i386-pc-solaris2.11/gcc/ -B/opt/local/i386-pc-solaris2.11/bin/ -B/opt/local/i386-pc-solaris2.11/lib/ -isystem /opt/local/i386-pc-solaris2.11/include -isystem /opt/local/i386-pc-solaris2.11/sys-include -O2 -march=pentium-m -O3 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -Iamd64 -I../.././gcc -I../.././gcc/amd64 -I../.././gcc/../include -I../.././gcc/../libcpp/include -m64 \ -c ../.././gcc/config/i386/gmon-sol2.c -o amd64/gmon.o ../.././gcc/config/i386/gmon-sol2.c:1: error: CPU you selected does not support x86-64 instruction set ../.././gcc/config/i386/gmon-sol2.c:1: error: CPU you selected does not support x86-64 instruction set gmake[4]: *** [amd64/gmon.o] Error 1 gmake[4]: Leaving directory `/export/home/error404/Code/gcc-4.1.1/host-i386-pc-solaris2.11/gcc' gmake[3]: *** [extraamd64] Error 2 gmake[3]: Leaving directory `/export/home/error404/Code/gcc-4.1.1/host-i386-pc-solaris2.11/gcc' gmake[2]: *** [stmp-multilib] Error 2 gmake[2]: Leaving directory `/export/home/error404/Code/gcc-4.1.1/host-i386-pc-solaris2.11/gcc' gmake[1]: *** [all-gcc] Error 2 gmake[1]: Leaving directory `/export/home/error404/Code/gcc-4.1.1' gmake: *** [all] Error 2 -- Summary: bootstrap fails on 32-bit x86 solaris2.11 Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: johnsonnenschein at gmail dot com GCC build triplet: i386-pc-solaris2.11 GCC host triplet: i386-pc-solaris2.11 GCC target triplet: i386-pc-solaris2.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31239
[Bug fortran/31184] gfortran option description wrong.
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-03-17 11:32 --- Subject: Bug 31184 Author: fxcoudert Date: Sat Mar 17 11:31:52 2007 New Revision: 123019 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123019 Log: PR fortran/31184 * invoke.texi: Fix typo. Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/invoke.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31184
[Bug fortran/31184] gfortran option description wrong.
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-03-17 11:33 --- Subject: Bug 31184 Author: fxcoudert Date: Sat Mar 17 11:32:56 2007 New Revision: 123020 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123020 Log: PR fortran/31184 * invoke.texi: Fix typo. Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/invoke.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31184
[Bug fortran/31184] gfortran option description wrong
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-03-17 11:34 --- Fixed on all active branches. Thanks for the report, documentation bug-reports are an important feedback to us! -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Keywords||documentation Resolution||FIXED Summary|gfortran option description |gfortran option description |wrong. |wrong http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31184
[Bug fortran/31189] Support backtracing for non-library errors
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-17 11:36 --- Confirmed. We have to be careful how that interacts with user-installed signal handlers, but it's otherwise a good idea. -- 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 |2007-03-17 11:36:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31189
[Bug fortran/30955] intrinsic: FGET
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Known to fail||4.1.3 4.2.0 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-03-17 11:37:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30955
[Bug fortran/31190] minimum field width list-directed output
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-03-17 11:39 --- Confirmed as an possible enhancement, though I agree there a both pros and cons. (My personal opinion is that I prefer the fixed-width version.) -- 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 |2007-03-17 11:39:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31190
[Bug fortran/31129] No warning on unused parameters
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2007-03-17 11:40:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31129
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #18 from dominiq at lps dot ens dot fr 2007-03-17 12:29 --- Subject: Re: __builtin_cexpi is broken on Darwin This is PR middle-end/30666. Patch for this problem is waiting for review. Thanks for the answer. I did not worried about the warn, but was only in the mode I report what I don't expect. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug fortran/31201] Too large unit number generates wrong code
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-03-17 13:01 --- (In reply to comment #3) The front end is converting the integer8 to integer4 and not checking the range of the number first. Every time a unit number is used, there should be a check to be sure it's in the integer4 range, and otherwise emit an error. Thanks for taking it, Jerry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31201
[Bug testsuite/31240] New: gcc/testsuite/gfortran.dg/pointer_intent_1.f90 failure on OSX
Without option and when compiled with the 20070316 snapshot on OSX 10.3.9 gcc/testsuite/gfortran.dg/pointer_intent_1.f90 yields an executable which segfault, see: http://gcc.gnu.org/ml/fortran/2007-03/msg00345.html but ignore the crash log I have posted. The right one is: ** Host Name: karma.lps.ens.fr Date/Time: 2007-03-17 13:26:25 +0100 OS Version: 10.3.9 (Build 7W98) Report Version: 2 Command: a.out Path:a.out Version: ??? (???) PID: 19276 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x62756700 Thread 0 Crashed: 0 a.out 0x2b8c nonpointer.958 + 0x1c (darwin-crt3.c:-94) 1 a.out 0x28a4 MAIN__ + 0xdc (darwin-crt3.c:-94) 2 a.out 0x2bcc main + 0x30 3 a.out 0x18f0 _start + 0x188 (crt.c:267) 4 dyld0x8fe1a31c _dyld_start + 0x64 PPC Thread State: srr0: 0x2b8c srr1: 0xd030vrsave: 0x cr: 0x4242 xer: 0x lr: 0x28a4 ctr: 0x9c78 r0: 0x0007 r1: 0xbfffefa0 r2: 0x62756700 r3: 0xb010 r4: 0xb008 r5: 0x r6: 0x0001 r7: 0x r8: 0x r9: 0x01e3 r10: 0x0002 r11: 0x001e r12: 0x9c78 r13: 0x r14: 0x r15: 0x r16: 0x r17: 0x r18: 0x r19: 0x r20: 0x r21: 0x r22: 0x r23: 0x r24: 0x r25: 0x r26: 0xb12c r27: 0x0008 r28: 0xb130 r29: 0x01100630 r30: 0xbfffefa0 r31: 0x177c Binary Images Description: 0x1000 - 0x2fff a.out a.out 0x3e000 -0x49fff libgcc_s.1.dylib /sw/lib/gcc4/lib/libgcc_s.1.dylib 0x3f4000 - 0x472fff libgfortran.3.dylib /sw/lib/gcc4/lib/libgfortran.3.dylib 0x7323 - 0x73233fff libmx.A.dylib /usr/lib/libmx.A.dylib 0x8fe0 - 0x8fe4 dyld/usr/lib/dyld 0x9000 - 0x9014 libSystem.B.dylib /usr/lib/libSystem.B.dylib 0x939d - 0x939d4fff libmathCommon.A.dylib /usr/lib/system/libmathCommon.A.dylib In http://gcc.gnu.org/ml/fortran/2007-03/msg00346.html, FX Coudert added: I can confirm that on i686-linux; ... -- Summary: gcc/testsuite/gfortran.dg/pointer_intent_1.f90 failure on OSX Product: gcc Version: 4.3.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 target triplet: powerpc-apple-darwin7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31240
[Bug testsuite/31240] gcc/testsuite/gfortran.dg/pointer_intent_1.f90 failure on OSX
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|powerpc-apple-darwin7 | Keywords||wrong-code Known to fail||4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-03-17 13:15:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31240
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- Comment #20 from dave at hiauly1 dot hia dot nrc dot ca 2007-03-17
13:44 ---
Subject: Re: Bootstrap comparison error at revision 122821
int foo (unsigned int i)
{
int j = 12048173;
if (i 32)
{
j = j i;
if (j 0)
return 0;
}
return 1;
}
correctly have a value range of [0, 12048173] for j_5? (look at 055t.vrp1
dump)
With the third hunk removed, I see
j_5: VARYING
I'll recheck with the third hunk.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug middle-end/31241] New: Post Increment opportunity missed
A simple code that adds a 'value' too all the elements of an array should
generate post increments while loading/storing values from/into the array. The
code looks something like this
for (i = 0; i 10; i++) {
*(intArray++) |= value;
}
However a post increment is not generated at O3 ( that causes the
tree-optimizer to unroll the loop)
Here is the information of the toolchain and the code produced.
$arm-none-eabi-gcc -v -O3 -S enhance.c --save-temps -o-
Using built-in specs.
Target: arm-none-eabi
Configured with:
/mnt/tools/fsf/build/combined-arm-none-eabi-gcc-4.2-branch-2007-03-16/configure
--target=arm-none-eabi
--prefix=/mnt/tools/fsf/install/arm-none-eabi-gcc-4.2-branch-2007-03-16
--enable-languages=c,c++ --disable-nls --with-newlib --disable-gdbtk
--disable-libssp
Thread model: single
gcc version 4.2.0 20070315 (prerelease)
/mnt/tools/fsf/install/arm-none-eabi-gcc-4.2-branch-2007-03-16/libexec/gcc/arm-none-eabi/4.2.0/cc1
-E -quiet -v -D__USES_INITFINI__ enhance.c -O3 -fpch-preprocess -o enhance.i
ignoring nonexistent directory
/mnt/tools/fsf/install/arm-none-eabi-gcc-4.2-branch-2007-03-16/lib/gcc/arm-none-eabi/4.2.0/../../../../arm-none-eabi/sys-include
ignoring nonexistent directory
/mnt/tools/fsf/install/arm-none-eabi-gcc-4.2-branch-2007-03-16/lib/gcc/arm-none-eabi/4.2.0/../../../../arm-none-eabi/include#include
... search starts here:
#include ... search starts here:
/mnt/tools/fsf/install/arm-none-eabi-gcc-4.2-branch-2007-03-16/lib/gcc/arm-none-eabi/4.2.0/include
End of search list.
/mnt/tools/fsf/install/arm-none-eabi-gcc-4.2-branch-2007-03-16/libexec/gcc/arm-none-eabi/4.2.0/cc1
-fpreprocessed enhance.i -quiet -dumpbase enhance.c -auxbase-strip - -O3
-version -o-
GNU C version 4.2.0 20070315 (prerelease) (arm-none-eabi)
compiled by GNU C version 4.0.3 (Ubuntu 4.0.3-1ubuntu5).
GGC heuristics: --param ggc-min-expand=97 --param ggc-min-heapsize=127206
Compiler executable checksum: 31464fade10aeea055a352aa873c9729
.file enhance.c
.text
.align 2
.global ShouldUsePostModify
.type ShouldUsePostModify, %function
ShouldUsePostModify:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldr ip, [r0, #0]
mov r3, r0
orr ip, ip, r1
str ip, [r3], #4
ldr r2, [r0, #4]
orr r2, r2, r1
str r2, [r0, #4]
ldr r0, [r3, #4]
orr r0, r0, r1
str r0, [r3, #4]
add r3, r3, #4
ldr r2, [r3, #4]
orr r2, r2, r1
str r2, [r3, #4]
add r3, r3, #4
ldr r2, [r3, #4]
orr r2, r2, r1
str r2, [r3, #4]
add r3, r3, #4
ldr r2, [r3, #4]
orr r2, r2, r1
str r2, [r3, #4]
add r3, r3, #4
ldr r2, [r3, #4]
orr r2, r2, r1
str r2, [r3, #4]
add r3, r3, #4
ldr r2, [r3, #4]
orr r2, r2, r1
str r2, [r3, #4]
add r3, r3, #4
ldr r2, [r3, #4]
orr r2, r2, r1
str r2, [r3, #4]
add r3, r3, #4
ldr r2, [r3, #4]
orr r2, r2, r1
@ lr needed for prologue
str r2, [r3, #4]
bx lr
.size ShouldUsePostModify, .-ShouldUsePostModify
.ident GCC: (GNU) 4.2.0 20070315 (prerelease)
However this problem vanishes when I use -fno-tree-lrs, this is becuase, then
each copy of intArray created by the unroller gets combined and the load/ store
can be combined with the increment of intArray. However, I dont think that this
( the use of -fno-tree-lrs) is the way to go.
--
Summary: Post Increment opportunity missed
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pranav dot bhandarkar at gmail dot com
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31241
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- Comment #21 from ghazi at gcc dot gnu dot org 2007-03-17 14:12 --- I get similar make compare errors on sparc-sun-solaris2.10. Reverting the bit from comment#15 fixes it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug middle-end/31241] Post Increment opportunity missed
--- Comment #1 from pranav dot bhandarkar at gmail dot com 2007-03-17 14:13 --- Created an attachment (id=13218) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13218action=view) Source that exposes the mentioned deficiency in the compiler -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31241
[Bug target/31242] New: Problem while compiling gcc for bfin-elf
Hello, there seems to be a gcc problem with the target 'bfin-elf': /home/mstein/sim/bfin-elf/build/./gcc/xgcc -B/home/mstein/sim/bfin-elf/build/./gcc/ -nostdinc -B/home/mstein/sim/bfin-elf/build/bfin-elf/newlib/ -isystem /home/mstein/sim/bfin-elf/build/bfin-elf/newlib/targ-include -isystem /n/07/mstein/combined-trunk/newlib/libc/include -B/n/07/mstein/cross-local/bfin-elf-new/bfin-elf/bin/ -B/n/07/mstein/cross-local/bfin-elf-new/bfin-elf/lib/ -isystem /n/07/mstein/cross-local/bfin-elf-new/bfin-elf/include -isystem /n/07/mstein/cross-local/bfin-elf-new/bfin-elf/sys-include -L/home/mstein/sim/bfin-elf/build/./ld -O2 -g -O2 -mid-shared-library -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../.././gcc -I/n/07/mstein/combined-trunk/libgcc -I/n/07/mstein/combined-trunk/libgcc/. -I/n/07/mstein/combined-trunk/libgcc/../gcc -I/n/07/mstein/combined-trunk/libgcc/../include -I/n/07/mstein/combined-trunk/libgcc/../libdecnumber -I../../../libdecnumber -o _div_sf.o -MT _div_sf.o -MD -MP -MF _div_sf.dep -DFINE_GRAINED_LIBRARIES -DL_div_sf -c ../../.././gcc/fp-bit.c ../../.././gcc/fp-bit.c: In function '__divsf3': ../../.././gcc/fp-bit.c:1083: 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. make[4]: *** [_div_sf.o] Error 1 make[4]: Leaving directory `/home/mstein/sim/bfin-elf/build/bfin-elf/mid-shared-library/libgcc' The SVN revision was 123001. -- Summary: Problem while compiling gcc for bfin-elf Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mstein at phenix dot rootshell dot be GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: bfin-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31242
[Bug target/31242] Problem while compiling gcc for bfin-elf
--- Comment #1 from mstein at phenix dot rootshell dot be 2007-03-17 14:20 --- Created an attachment (id=13219) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13219action=view) from SVN revision: 123001 Commandline used to create fp-bit.i: /home/mstein/sim/bfin-elf/build/./gcc/xgcc -B/home/mstein/sim/bfin-elf/build/./gcc/ -nostdinc -B/home/mstein/sim/bfin-elf/build/bfin-elf/newlib/ -isystem /home/mstein/sim/bfin-elf/build/bfin-elf/newlib/targ-include -isystem /n/07/mstein/combined-trunk/newlib/libc/include -B/n/07/mstein/cross-local/bfin-elf-new/bfin-elf/bin/ -B/n/07/mstein/cross-local/bfin-elf-new/bfin-elf/lib/ -isystem /n/07/mstein/cross-local/bfin-elf-new/bfin-elf/include -isystem /n/07/mstein/cross-local/bfin-elf-new/bfin-elf/sys-include -L/home/mstein/sim/bfin-elf/build/./ld -O2 -g -O2 -mid-shared-library -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../.././gcc -I/n/07/mstein/combined-trunk/libgcc -I/n/07/mstein/combined-trunk/libgcc/. -I/n/07/mstein/combined-trunk/libgcc/../gcc -I/n/07/mstein/combined-trunk/libgcc/../include -I/n/07/mstein/combined-trunk/libgcc/../libdecnumber -I../../../libdecnumber -o _div_sf.o -MT _div_sf.o -MD -MP -MF _div_sf.dep -DFINE_GRAINED_LIBRARIES -DL_div_sf -c ../../.././gcc/fp-bit.c -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31242
[Bug tree-optimization/31041] [4.3 Regression] verify_stmts failed: invalid operand to binary operator with -O2 -ftree-vectorize
--- Comment #6 from dorit at gcc dot gnu dot org 2007-03-17 14:43 --- Subject: Bug 31041 Author: dorit Date: Sat Mar 17 14:43:30 2007 New Revision: 123023 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123023 Log: PR tree-optimization/31041 * tree-vect-transform.c (get_initial_def_for_induction): Call force_gimple_operand. Added: trunk/gcc/testsuite/gcc.dg/vect/pr31041.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-transform.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31041
[Bug fortran/31243] New: truncating strings longer than 2**32 characters
The string lengths are truncated to 32-bit
values here, which shouldn't happen.
$ cat substr.f90
program main
character (len=2_8**32_8+4_8) :: ch
ch = ' '
print *,ch(1:2_8**32_8+3_8)
end program main
$ gfortran -fdump-tree-original substr.f90
$ cat substr.f90.003t.original
MAIN__ ()
{
char ch[1:4];
_gfortran_set_std (68, 127, 0);
__builtin_memmove (ch, , 1);
__builtin_memset (ch + 1B, 32, 3);
...
--
Summary: truncating strings longer than 2**32 characters
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31243
[Bug fortran/31244] New: data initialization with more than 2**32 elements
$ cat data.f90 program main integer(kind=1), dimension(4294967296_8) :: i data i /4294967296_8 * 1_1/ print *,i(1) end program main $ gfortran data.f90 data.f90:3.24: data i /4294967296_8 * 1_1/ 1 Error: Integer value too large in expression at (1) This is probably due to the use of gfc_match_int() in top_val_list. -- Summary: data initialization with more than 2**32 elements Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31244
[Bug fortran/31206] wrong code generated with gfortran
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-03-17 15:27 --- I can reproduce the problem, but this is a duplicate of PR 29397. Closing (but thanks anyway!) *** This bug has been marked as a duplicate of 29397 *** -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31206
[Bug fortran/29397] Constant logical expression with parameter array
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-03-17 15:27 --- *** Bug 31206 has been marked as a duplicate of this bug. *** -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29397
[Bug fortran/31207] advance=no and tabs
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-03-17 15:36 --- Confirmed. Reduced test case: $ cat rewind-2.f90 program main write (*,'(A,T1,A)',advance=no) 'XX','ABC' end program main $ gfortran rewind-2.f90 $ ./a.out ABC$ Jerry, I'm putting you on the CC list for this one. I'll see whether I have time for a look. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org, tkoenig at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-17 15:36:58 date|| Summary|wrong code generated with |advance=no and tabs |gfortran| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31207
[Bug fortran/31218] ICE on valid code with gfortran
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-03-17 15:42 --- Confirmed. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||31237 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-17 15:42:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31218
[Bug c/31245] New: SSE2 generation bug with 4.1.2 and -O3
This is my simple test proggie. test1 is always ok, but test2 fails with -O3 (produces output 1 0 0 0 for test2), but -O2 makes it behave. I am on x86_64. -m32 has interesting effects: -O3 -Wall -m32 -msse2 -march=i486 is ok (output 1 0 3 0, as expected) -O3 -Wall -m32 -msse2 -march=i586 is broken (output 0 2 3 4) -O3 -Wall -m32 -msse2 -march=athlon is broken (output 1 0 0 0) Is this the aliasing issues I read about with 4.1 compiler? Is there an easy work-around? In fact I need to pass data as aligned buffer, so I need test2 to behave correctly. :-( Do you need anything else? -- Summary: SSE2 generation bug with 4.1.2 and -O3 Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: prakash at punnoor dot de GCC build triplet: x86_64-pc-linux-gnu GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31245
[Bug fortran/31200] wrong code: procedure call with pointer-returning-function as argument
--- Comment #3 from pault at gcc dot gnu dot org 2007-03-17 15:52 ---
This fixes the bug (and PR31209) and regtests OK. Will package it up as a
submission tomorrow morning.
Index: gcc/fortran/trans-expr.c
===
*** gcc/fortran/trans-expr.c(revision 122943)
--- gcc/fortran/trans-expr.c(working copy)
*** gfc_conv_function_call (gfc_se * se, gfc
*** 2074,2083
--- 2074,2091
/* Argument list functions %VAL, %LOC and %REF are signalled
through arg-name. */
conv_arglist_function (parmse, arg-expr, arg-name);
+ else if ((e-expr_type == EXPR_FUNCTION)
+ e-symtree-n.sym-attr.pointer
+ fsym fsym-attr.target)
+ {
+ gfc_conv_expr (parmse, e);
+ parmse.expr = build_fold_addr_expr (parmse.expr);
+ }
else
{
gfc_conv_expr_reference (parmse, e);
if (fsym fsym-attr.pointer
+fsym-attr.flavor != FL_PROCEDURE
e-expr_type != EXPR_NULL)
{
/* Scalar pointer dummy args require an extra level of
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31200
[Bug c/31245] SSE2 generation bug with 4.1.2 and -O3
--- Comment #1 from prakash at punnoor dot de 2007-03-17 15:52 --- Created an attachment (id=13220) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13220action=view) test2 triggers bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31245
[Bug fortran/31207] advance=no and tabs
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-03-17 15:59 --- I have started looking at this. I believe its a duplicate of 31199. In using advance=no we are failing to retain or use the information about the maximum position reached during preceding writes. *** This bug has been marked as a duplicate of 31199 *** -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31207
[Bug fortran/31199] write with t1 format gives wrong output
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-03-17 15:59 --- *** Bug 31207 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31199
[Bug target/31239] bootstrap fails on 32-bit x86 solaris2.11
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-17 16:34 --- What options are passing to configure? Do you have CFLAGS set? Second i386-solaris is a multilibed target which means it will build the 64bit libraries even on a 32bit machine. If you don't want that, then use --disable-multilib. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31239
[Bug libstdc++/31246] New: Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
Compiling the following with -Wunreachable-code -D_GLIBCXX_DEBUG
--
#include vector
int main()
{
std::vectorint::iterator a;
}
--
produces the warning :
--
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/debug/safe_iterator.h:
In constructor __gnu_debug::_Safe_iterator_Iterator,
_Sequence::_Safe_iterator() [with _Iterator =
__gnu_cxx::__normal_iteratorint*, __gnu_norm::vectorint, std::allocatorint
, _Sequence = __gnu_debug_def::vectorint, std::allocatorint ]:
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/debug/safe_iterator.h:103:
warning: will never be executed
--
I tried g++ 4.1, 4.2 and 4.3. They all produce this annoying warning.
Looking at the code in safe_iterator.h shows nothing obviously wrong.
This might even suggest a bug in -Wunreachable-code, although I categorized
it for now in libstdc++, as I have not been able to isolate a small piece
of code that reproduces the problem.
Some other compilers tend to have the equivalent of -Wunreachable-code
by default. It would be nice if it worked well, and if it was enabled
by -Wall or -Wextra.
--
Summary: Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sylvain dot pion at sophia dot inria dot fr
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31246
[Bug target/31245] SSE2 generation bug with 4.1.2 and -O3
--- Comment #2 from prakash at punnoor dot de 2007-03-17 16:49 --- Created an attachment (id=13221) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13221action=view) test2 triggers bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31245
[Bug target/31245] SSE2 generation bug with 4.1.2 and -O3
--- Comment #3 from prakash at punnoor dot de 2007-03-17 16:51 --- Sorry, I uploaded the wrong test case. In fact changing the unaligned load to aligned load triggers the bug, which the new file represents in a shorter notation, I guess. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31245
[Bug libstdc++/31247] New: std::vector::iterator::value_type is accessible
This is an accepts invalid code report. The following code happens to compile with g++ (all versions), whereas the standard does not guarantee it should (I think). #include vector typedef std::vectorint::iterator Iterator; Iterator::value_type v; Iterator::pointer p; Iterator::iterator_category c; The problem is that developing code with g++, and introducing this kind of code by mistake, pops up errors later when other compilers are used (e.g. those which have pointers for std::vector::iterator). Would it be a good idea to make the access to such types somehow non public? For example by making them protected and making std::iterator_traits a friend? Or maybe only available when _GLIBCXX_DEBUG is not defined ? -- Summary: std::vector::iterator::value_type is accessible Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sylvain dot pion at sophia dot inria dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247
[Bug libstdc++/31246] Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-17 16:58 ---
Lets look at the IR:
;; Function __gnu_debug::_Safe_iterator_Iterator, _Sequence::_Safe_iterator()
[with _Iterator = __gnu_cxx::__normal_iteratorint*, __gnu_norm::vectorint,
std::allocatorint , _Sequence = __gnu_debug_def::vectorint,
std::allocatorint ]
(_ZN11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPiN10__gnu_norm6vectorIiSaIiEN15__gnu_debug_def6vectorIiS6_EEEC4Ev
*INTERNAL* )
;; enabled by -tree-original
{
cleanup_point Unknown tree: expr_stmt
__base_ctor (((struct _Safe_iterator__gnu_cxx::__normal_iteratorint*,
__gnu_norm::vectorint, std::allocatorint ,__gnu_debug_def::vectorint,
std::allocatorint *) this)-D.12082)
;
try
{
cleanup_point Unknown tree: expr_stmt
__comp_ctor (((struct _Safe_iterator__gnu_cxx::__normal_iteratorint*,
__gnu_norm::vectorint, std::allocatorint ,__gnu_debug_def::vectorint,
std::allocatorint *) this)-_M_current)
;
}
catch
{
__base_dtor ((struct _Safe_iterator_base *) this);
}
}
and the constructor for -M_current:
__gnu_debug::_Safe_iterator__gnu_cxx::__normal_iteratorint*,
__gnu_norm::vectorint, std::allocatorint , __gnu_debug_def::vectorint,
std::allocatorint ::~_Safe_iterator() (this, __in_chrg)
{
struct _Safe_iterator_base * this.102;
[/usr/include/c++/4.0.0/debug/safe_iterator.h : 65] {
[/usr/include/c++/4.0.0/debug/safe_iterator.h : 65] try
{
}
finally
{
[/usr/include/c++/4.0.0/debug/safe_iterator.h : 65] this.102 = (struct
_Safe_iterator_base *) this;
[/usr/include/c++/4.0.0/debug/safe_iterator.h : 65] __base_dtor
(this.102);
}
}
[/usr/include/c++/4.0.0/debug/safe_iterator.h : 65] D12095:;
}
So the constructor for that cannot throw so the catch part is removed in both
cases.
The warning is not strange and is correct in that the __base_dtor cannot be
called ever.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31246
[Bug libstdc++/31247] std::vector::iterator::value_type is accessible
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-17 17:00 --- IIRC iterator is an implemention defined type so this is valid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247
[Bug libstdc++/31247] std::vector::iterator::value_type is accessible
--- Comment #2 from chris at bubblescope dot net 2007-03-17 17:19 --- Depending on how you read it, 24.3.1 looks to me like it might require that. It says that iterator_traits is defined to include: typedef typename Iterator::value_type value_type; and that it is specialised for various types of pointers. If we removed std::vectorint::iterator::value_type, we would then have to overload iterator_traits for vector, and I'm not sure we are allowed to. Out of interest, which compilers still have a pointer for std::vector::iterator? -- chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247
[Bug libstdc++/31246] Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
--- Comment #2 from sylvain dot pion at sophia dot inria dot fr 2007-03-17
17:26 ---
Trying further, I noticed that simply default constructing an std::vectorint,
even without the debug mode _GLIBCXX_DEBUG, generates also a bunch (14 !) of
these warnings.
Andrew, I did not follow all the details of your explanation. I don't
understand if there is finally a problem with the libstdc++ code or not.
And if there is, what should be done.
Is this a warning meant to be useful at all, or meant for GCC developers?
How do we get rid of this warning for the simplest C++ code I showed?
Other compilers are able to warn for unreachable code in better conditions.
for example, they warn for int f() { return 1 ; return -1; }, and I
was trying to see if GCC was able to generate the same kind of warnings.
I only found -Wunreachable-code, but so far it proves unusable for C++.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31246
[Bug c/31236] incorrect output on external symbol address cast as integer used in conditional statement
--- Comment #4 from sh-list at ssc-studios dot com 2007-03-17 17:31 ---
so in other words you're saying the solution to this is
if you want it to work with GCC, make your code non-portable
afaik __attribute__ (( weak )) is not part of the standard, its not a
portable solution.
the fact that
#define SOMEVALUE ((int)SomeLinkerScriptDefinedSymbol)
int i = SOMEVALUE;
if(i == 0){
and
if(SOMEVALUE == 0){
give a different result makes gcc act inconsistently on code that should be
equivalent.
what are the real-life speed and size gains of this optimization?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31236
[Bug libstdc++/31247] std::vector::iterator::value_type is accessible
--- Comment #3 from sylvain dot pion at sophia dot inria dot fr 2007-03-17 17:35 --- I'm not sure about the standard requirements. My user question is that I want to develop with GCC as my main compiler, and I want it to catch non-portability bugs as much as possible. @Chris: note that std::iterator_traits would not need to be specialized for std::vector::iterator if it was made a friend of it, so that it would be the only one able to access these types. The compiler I know which still has a pointer for std::vector::iterator is PGCC (the Portland Group Compiler). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247
[Bug libstdc++/31246] Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
--- Comment #3 from chris at bubblescope dot net 2007-03-17 17:46 --- This is a general problem I've come across with templates. You commonly want to try/catch around some operation, but when you have templated on a simple type, like int, then it's easy to find out that no throwing can ever occur, and for this type the try/catch is a waste of time. I'm not sure what the best way of fixing this is. -- chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31246
[Bug c/31236] incorrect output on external symbol address cast as integer used in conditional statement
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-17 17:47 --- Well linker scripts are already non portable and not mentioned in the standard and you are violating the C/C++ standards if the address of a variable is NULL (0) :). Also -O2 with -DUSETEMP gives the same results as without it so it is not inconsistent, even the code is equalivant, the code is not the same when it comes to without optimization :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31236
[Bug libstdc++/31247] std::vector::iterator::value_type is accessible
--- Comment #4 from chris at bubblescope dot net 2007-03-17 17:52 --- The main problem I can see with changing this is that you would have to decide if you were going to remove the same options from the iterators of all other standard containers. To not do so would seem to be inconsistent, but doing so would probably break a huge amount of code. This seems to be part of a larger issue, should these typedefs be defined in any of the standard iterators. Having an offical decision by the standards committee would probably be useful. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247
[Bug c/31166] Integer hex constant does not follow promoting rules
--- Comment #9 from roberto dot gordo at gmail dot com 2007-03-17 17:58 --- I would like to apologize for my faults in gcc bug report 31166, specially to the people who responded, and fully acknowledge my error. I've misunderstood your responses. Now, while reading them again, they appear completely logical to me. I was working during hours with a piece of code on which I've been bitten by lots of c language weirdness. I've discovered and fixed most of them (except the reported one), but after so many consecutive hours of debugging such ugly code my mind was not in a very clear state... and my comments were fairly stupid, I must admit. I'm sorry for that. There is still something remaining that I don't fully understand (the integer/unsigned promotion thing). I'm still wondering about that, but I accept your responses, so I think I'm somewhat not giving the right interpretation at the standard wordings. I will try to find the cause on mailing lists or other places, since the gcc bugzilla may not be the correct place. Thanks for your patience and please accept my apologies for wasting your time. Sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31166
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- Comment #22 from dave at hiauly1 dot hia dot nrc dot ca 2007-03-17
18:03 ---
Subject: Re: Bootstrap comparison error at revision 122821
I'll recheck with the third hunk.
j_5: [0, 12048173] EQUIVALENCES: { } (0 elements)
There isn't any difference in the code generated with and without
the third hunk. Also, stage1 through stage3 with hunk generate the
same code at -O2. As far as I can tell, the code is correct in all
cases.
If the count is actually zero, we can end up doing x 0 (a left shift of
zero). Does hppa handle this correctly? Does it, for
The hardware doesn't support a left shift of zero, so at the moment
the expanders and patterns require that the shift length be greater
than zero.
Sorry, the above statement is wrong. What the hardware doesn't support
is zero length deposits. Deposit instructions are used for shifts.
In the case of an ashift with a CONST_INT shift amount x, the deposit
length is 32 - (INTVAL (x) 31). So, the deposit length is [1, 32].
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug libstdc++/31246] Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
--- Comment #4 from chris at bubblescope dot net 2007-03-17 18:07 ---
Here is a minimal code example:
#include new
int* get_ptr(void* ptr)
{
return new(ptr) int();
}
Which gives (on my computer)
/usr/include/c++/4.0.0/new: In function 'int* get_ptr(void*)':
/usr/include/c++/4.0.0/new:94: warning: will never be executed
But a similar problem exists in much of the templated code, and in general.
The real problem I think here is that the system_header pragma is still broken
for templates. If that was fixed, this warning would go away.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31246
[Bug fortran/30834] ICE with kind=8 exponentiaton
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-03-17 18:45 --- Created an attachment (id=13222) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13222action=view) Proposed patch I think the attached patch would fix this bug. It's a significant rewrite of the arith.c code to: * handle the case of large integer exponents for both complex and real; I do it by not extracting an int from the exponent, but simply handle the mpz_t throughout * rewrite completely the integer**integer case, because it had other problems, such as the following: $ cat c.f90 print *, 0**(-1) end $ gfortran c.f90 c.f90:0: internal compiler error: Floating point exception All testcases reported are fixed. I don't have any more time to work on this now, if one of you want to try the patch on the corner cases you can imagine, I'd appreciate that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30834
[Bug tree-optimization/31248] New: Too much casting for char operands on tree level
Following testcase produces unnecessary moves in short loop:
--cut here--
char table[256];
int test(void) {
char val = 0;
int i;
for (i = 0; i 10; i++)
val += table[i];
return val;
}
--cut here--
gcc -O2:
test:
.LFB2:
movzbl table(%rip), %ecx
movl$1, %edx
.p2align 4,,7
.L2:
(*) movl%ecx, %eax
addbtable(%rdx), %al
addq$1, %rdx
cmpq$10, %rdx
(*) movl%eax, %ecx
jne .L2
movsbl %al,%eax
ret
Those unneccesary moves (*) are generated due to many (spurious?) casts in
optimized tree dump:
test ()
{
long unsigned int ivtmp.31;
char val;
unsigned char D.1985;
bb 2:
val = (char) (unsigned char) MEM[symbol: table];
ivtmp.31 = 1;
L0:;
D.1985 = (unsigned char) val + (unsigned char) MEM[symbol: table, index:
ivtmp.31];
val = (char) D.1985;
ivtmp.31 = ivtmp.31 + 1;
if (ivtmp.31 != 10) goto L0; else goto L2;
L2:;
return (int) val;
--
Summary: Too much casting for char operands on tree level
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31248
[Bug fortran/31120] ICE with integer_exponentiation_1.f90 and -ffast-math
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-03-17 19:58 --- Subject: Bug 31120 Author: fxcoudert Date: Sat Mar 17 19:58:37 2007 New Revision: 123028 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123028 Log: PR fortran/31120 * trans-expr.c (gfc_conv_powi): Make n argument unsigned hwi. (gfc_conv_cst_int_power): Handle integer exponent with care, since it might be too large for us. * gfortran.dg/integer_exponentiation_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/integer_exponentiation_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31120
[Bug fortran/31243] truncating strings longer than 2**32 characters
-- 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 |2007-03-17 20:06:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31243
[Bug target/31239] bootstrap fails on 32-bit x86 solaris2.11
--- Comment #2 from johnsonnenschein at gmail dot com 2007-03-17 20:31 --- yes, you are correct, it was multilib. I tried again with that Perhaps a check of isainfo(1) should be placed in the configure script to ensure the target supports amd64 binaries ? Solaris runs on x86 32-bit or 64-bit -- johnsonnenschein at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31239
[Bug libstdc++/31246] Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
--- Comment #5 from pcarlini at suse dot de 2007-03-17 20:40 --- Note, however, that, as far as I can see, such try/catch are *not* in the library code proper, but *all* synthesized by the C++ front-end. Is it so weird to imagine for the C++ front-end to automatically suppress warning in such case? I think this is a very general issue, which goes even beyond the already general issue about pragma system headers: if the user writes such code and sees such kind of warnings becomes *completely* confused. Gaby, do you have an opinion? -- pcarlini at suse dot de changed: What|Removed |Added CC||gdr at integrable-solutions ||dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31246
[Bug c++/31246] Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
--- Comment #6 from pcarlini at suse dot de 2007-03-17 20:48 --- And I'm recategorizing as C++: either (as I strongly believe) a very general diagnostic issue, or maybe a duplicate of C++/30500: certainly there is nothing we can do on the library side to fix the implementation of placement new itself (per Chris' comment #4. By the way, in that specific case I think we are missing the pragma from the header, because there are no templates involved and should work. But that's not the point). -- pcarlini at suse dot de changed: What|Removed |Added Component|libstdc++ |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31246
[Bug fortran/31203] Character length should never be negative
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-03-17 20:58 --- A two-lines fix for this bug: Index: gcc/fortran/trans-expr.c === --- gcc/fortran/trans-expr.c(revision 123028) +++ gcc/fortran/trans-expr.c(working copy) @@ -227,6 +227,8 @@ gfc_init_se (se, NULL); gfc_conv_expr_type (se, cl-length, gfc_charlen_type_node); + se.expr = fold_build2 (MAX_EXPR, gfc_charlen_type_node, se.expr, +build_int_cst (gfc_charlen_type_node, 0)); gfc_add_block_to_block (pblock, se.pre); tmp = cl-backend_decl; -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-03-16 20:48:08 |2007-03-17 20:58:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31203
[Bug middle-end/31249] New: pseudo-optimzation with sincos/cexpi
With gfortran and g++ the computation of cos(x) and sin(x) is optimized by taking the real and imaginary parts of cexpi(x) (at least it is what I understand). This is working if and only if the computation of cexpi(x) is faster than the sum of the separate computations of cos(x) and sin(x). Now consider the following code: integer, parameter :: n=100 integer :: i real(8) :: pi, ss, sc, t, dt pi = acos(-1.0d0) dt=pi/n sc=0 ss=0 t=0 do i= 1, 100*n sc = sc + cos(t-dt) ss = ss + sin(t) t = t+dt end do print *, sc, ss end the result is (G5 1.8Ghz, OSX 10.3.9): [karma] bug/timing% gfc -O3 sincos.f90 [karma] bug/timing% time a.out -6.324121638644320E-002 -2.934958087315009E-003 13.020u 0.050s 0:13.59 96.1%0+0k 0+2io 0pf+0w It is easy to see that I have fooled the optimizer with the line sc = sc + cos(t-dt) If I replace it by: sc = sc + cos(t) the result is now (over a 50% increase of the CPU time): [karma] bug/timing% gfc -O3 sincos_o.f90 [karma] bug/timing% time a.out -6.324121573032526E-002 -2.934958087315009E-003 21.740u 0.080s 0:22.18 98.3%0+0k 0+2io 0pf+0w to be compared with the result of the code: integer, parameter :: n=100 integer :: i real(8) :: pi, ss, sc, t, dt complex(8) :: z, dz pi = acos(-1.0d0) dt=pi/n dz=cmplx(0.0d0,dt,8) sc=0 ss=0 z=0 do i= 1, 100*n sc = sc + real(exp(z)) ss = ss + aimag(exp(z)) z = z+dz end do print *, sc, ss end is [karma] bug/timing% gfc -O3 cexp.f90 [karma] bug/timing% time a.out -6.324121573032526E-002 -2.934958087315009E-003 20.850u 0.110s 0:21.45 97.7%0+0k 0+2io 0pf+0w Following the comments in PR #30969, 30980, and 31161, I have understood that on OSX cexpi fallback to cexp in perfect agreement with the above timings. So it would probably nice to disable the sincos optimisation on platforms that do not support fast cexpi such as OSX (as presently configured). Note that on Sat, 30 Sep 2006 in http://gcc.gnu.org/ml/fortran/2006-09/msg00454.html I have reported (in vain) a timing regression for the fatigue.f90 polyhedron test case. Is this related to this pseudo-optimization or to another change? -- Summary: pseudo-optimzation with sincos/cexpi Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC target triplet: powerpc-apple-darwin7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249
[Bug fortran/31250] New: Initialization expr as constant character length rejected
$ cat a4.f90 character(len=min(-4,5)) :: s print *, len(s) end $ ./bin/gfortran -static a4.f90 a4.f90:1.31: character(len=min(-4,5)) :: s 1 Error: 's' at (1) must have constant character length in this context I tried with a few intrinsics, like MIN, MODULO, ... None of them work. -- Summary: Initialization expr as constant character length rejected Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid 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=31250
[Bug fortran/31250] Initialization expr as constant character length rejected
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.3.0 4.2.0 Last reconfirmed|-00-00 00:00:00 |2007-03-17 21:28:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31250
[Bug fortran/31251] New: Non-integer character length leads to segfault
$ cat foo.f90 character(len=2.3) :: s print *, len(s) end $ gfortran foo.f90 foo.f90:1.16: character(len=2.3) :: s 1 Error: Expression at (1) must be of INTEGER type foo.f90:1.16: character(len=2.3) :: s 1 Error: Expression at (1) must be of INTEGER type foo.f90:0: internal compiler error: Segmentation fault -- Summary: Non-integer character length leads to segfault Product: gcc Version: 4.3.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=31251
[Bug fortran/31251] Non-integer character length leads to segfault
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.1.3 4.2.0 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-03-17 21:45:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31251
[Bug fortran/31252] New: ICE dans gfc_conv_constant, � fortran/trans-const.c:348
-- Summary: ICE dans gfc_conv_constant, à fortran/trans-const.c:348 Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mikael dot morin at tele2 dot fr GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31252
[Bug fortran/31253] New: ICE in gfc_conv_constant, at fortran/trans-const.c:348
the fortran compiler crashes when trying to compile the following test program : subroutine probleme(p) real(kind=8), dimension(:) :: p integer :: nx = size(p, 1) integer :: nix nix = nx end subroutine The error reported by the compiler is : test.f: In function probleme: test.f:2: erreur interne du compilateur: dans gfc_conv_constant, à fortran/trans-const.c:348 Veuillez soumettre un rapport complet d'anomalies, avec le source pré-traité si nécessaire. Consultez URL:http://gcc.gnu.org/bugs.html pour plus de détail. The compilation command was : gfortran test.f The gfortran -v is : Lecture des spécification à partir de /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/specs Target: x86_64-pc-linux-gnu Configuré avec: /usr/src/gcc-4.1.2/configure --host=x86_64-pc-linux-gnu --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --enable-threads=posix --with-system-zlib --enable-languages=f95 --disable-multilib Modèle de thread: posix version gcc 4.1.2 -- Summary: ICE in gfc_conv_constant, at fortran/trans-const.c:348 Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mikael dot morin at tele2 dot fr GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31253
[Bug fortran/31253] ICE in gfc_conv_constant, at fortran/trans-const.c:348
--- Comment #1 from mikael dot morin at tele2 dot fr 2007-03-17 21:58 --- Created an attachment (id=13223) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13223action=view) the test program that fails -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31253
[Bug fortran/31253] ICE in gfc_conv_constant, at fortran/trans-const.c:348
--- Comment #2 from mikael dot morin at tele2 dot fr 2007-03-17 22:03 --- the attached program (test.f) fails to compile: the compilation command is : gfortran -c test.f the error is : test.f: In function probleme: test.f:2: erreur interne du compilateur: dans gfc_conv_constant, à fortran/trans-const.c:348 Veuillez soumettre un rapport complet d'anomalies, avec le source pré-traité si nécessaire. Consultez URL:http://gcc.gnu.org/bugs.html pour plus de détail. the fortran version is (gfortran -v) : Lecture des spécification à partir de /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/specs Target: x86_64-pc-linux-gnu Configuré avec: /usr/src/gcc-4.1.2/configure --host=x86_64-pc-linux-gnu --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --enable-threads=posix --with-system-zlib --enable-languages=f95 --disable-multilib Modèle de thread: posix version gcc 4.1.2 -- mikael dot morin at tele2 dot fr changed: What|Removed |Added CC||mikael dot morin at tele2 ||dot fr Keywords||ice-on-valid-code Known to fail||4.1.1 4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31253
[Bug fortran/30834] ICE with kind=8 exponentiaton
--- Comment #10 from tkoenig at gcc dot gnu dot org 2007-03-17 22:06 --- Hi FX, I'll look at this. Looking at your patch, I have identified one compile-time hog in complex_pow_ui: $ time gfortran complex.f90 real3m35.506s user3m35.329s sys 0m0.156s $ cat complex.f90 program main print *,(1.0, 0.0)**(2**30) end program main We should use the same algorithm as in the library (in pow.m4). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30834
[Bug fortran/31253] ICE in gfc_conv_constant, at fortran/trans-const.c:348
--- Comment #3 from tkoenig at gcc dot gnu dot org 2007-03-17 22:08 --- Confirmed with 4.3.0. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-17 22:08:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31253
[Bug fortran/31252] ICE dans gfc_conv_constant, � fortran/trans-const.c:348
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-03-17 22:10 --- Empty bug report, closing. *** This bug has been marked as a duplicate of 31253 *** -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31252
[Bug fortran/31253] ICE in gfc_conv_constant, at fortran/trans-const.c:348
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-03-17 22:10 --- *** Bug 31252 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31253
[Bug tree-optimization/29922] [4.3 Regression] [Linux] ICE in insert_into_preds_of_block
--- Comment #24 from dberlin at gcc dot gnu dot org 2007-03-17 23:07 --- Subject: Bug 29922 Author: dberlin Date: Sat Mar 17 23:07:34 2007 New Revision: 123029 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123029 Log: 2007-03-16 Daniel Berlin [EMAIL PROTECTED] Fix PR tree-optimization/29922 * tree-ssa-pre.c (bb_bitmap_sets): Remove RVUSE_* members. (get_representative): Removed. (value_dies_in_block_x): Update for rvuse removal. (valid_in_sets): Update for renaming of vuses_dies_in_block_x. (compute_antic_aux): Handle when PHI nodes appear in non-single-successors. (dump_bitmap_of_names): Removed. (compute_antic_safe): Renamed and removed rvuse calculation. Calculate only antic safe. (insert_into_preds_of_block): Remove assert. (execute_pre): Update for renamed functions. (defer_or_phi_translate_block): New function. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/loadpre12.c trunk/gcc/tree-ssa-pre.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29922
[Bug tree-optimization/29922] [4.3 Regression] [Linux] ICE in insert_into_preds_of_block
--- Comment #25 from tbm at cyrius dot com 2007-03-17 23:16 --- Thanks, Danny! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29922
[Bug tree-optimization/29922] [4.3 Regression] [Linux] ICE in insert_into_preds_of_block
--- Comment #26 from dberlin at gcc dot gnu dot org 2007-03-17 23:18 --- Sorry for the delay. Fixed now. -- dberlin at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29922
[Bug c++/31246] Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
--- Comment #7 from gdr at cs dot tamu dot edu 2007-03-17 23:35 --- Subject: Re: Strange -Wunreachable-code warning with _GLIBCXX_DEBUG pcarlini at suse dot de [EMAIL PROTECTED] writes: | Note, however, that, as far as I can see, such try/catch are *not* in the | library code proper, but *all* synthesized by the C++ front-end. Is it so weird | to imagine for the C++ front-end to automatically suppress warning in such | case? I think this is a very general issue, which goes even beyond the already | general issue about pragma system headers: if the user writes such code and | sees such kind of warnings becomes *completely* confused. Gaby, do you have an | opinion? I agree with you Paolo. The front-end should make sure that its artefacts don't adversily affect diagnostics we emit. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31246
[Bug fortran/30875] Equivalence of derived types with (same) default initializer
--- Comment #2 from brooks at gcc dot gnu dot org 2007-03-17 23:39 --- At the end of 14.6.3.3, Default initialization may be specified for a storage unit that is storage associated provided the objects or subobjects supplying the default initialization are of the same type and type parameters, and supply the same value for the storage unit. It is somewhat unclear to me from that language whether the relevant constraint is that A1 and A2 would have to have the same type and type parameters (which they do not, making the code illegal), or whether A1%I and A2%I would have to have the same type and type parameters (which they do, making the code legal). I tried to get some further opinions about this on comp.lang.fortran, but apparently nobody found my question interesting enough to reply to. :) I've now found that MRC describes this condition as being that the components in question must have the same type and type parameters, which would make this legal, and I suspect that's the final answer we'll get. Thus, I'm confirming the bug; I can certainly reproduce the error message. -- brooks at gcc dot gnu dot org changed: What|Removed |Added CC||brooks at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-03-17 23:39:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30875
[Bug c++/17000] parse error calling member template function of non-lvalue from within template class member
--- Comment #7 from matt at galloway dot me dot uk 2007-03-18 01:06 --- Same problem for me with gcc-4.0.1. Is this going to get fixed or is it correct behaviour and the code needs some sort of codeword to tell the compiler that func2 is a template? -- matt at galloway dot me dot uk changed: What|Removed |Added CC||matt at galloway dot me dot ||uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17000
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- Comment #23 from daney at gcc dot gnu dot org 2007-03-18 01:55 --- Reverting the hunk mentioned in comment #15 also allows mipsel-linux to bootstrap. I bootstrapped R122924 which failed in the stage2 stage3 compare. I then reverted said hunk, and re-bootstrapped successfully. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug fortran/31201] Too large unit number generates wrong code
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-03-18 02:22 --- Heres the real problem: Try compiling this with and without -fno-range-check. integer*8 :: k= 68719476746 integer*8 :: k2 = 2_8**36 + 10 print *, k=,k, k2, int(k2, kind=8), int(k2, kind=4) end With checking: overflow.f:1.34: integer*8 :: k= 68719476746 1 Error: Integer too big for its kind at (1) Without checking: $ gfc -fno-range-check overflow.f $ ./a.out k= 68719476746 68719476746 68719476746 10 So our range checking does not catch the case when too big integer is hidden in some arithmetic and conversion of kinds does not either. I don't think we want integer kind conversion to catch this, its no different then a cast. The programmer needs to be aware of what they are doing. In tha case of the overly large unit number, We do catch non disguised cases. Any opinions on whether we need to really 'fix' this? (I am not taking sides here, the answer too my question has broader implications, ie int intrinsics) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31201
[Bug tree-optimization/31248] Too much casting for char operands on tree level
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-18 05:29 --- You are wrong. The casts are correct as char + char in C is actually defined as (int)(char) + (int) (char) aka promoted to int while doing the addition so what the optimizers do when it sees (char)((int)(char) + (int)(char)), it changes the addition to be (unsigned char)(char) + (unsigned char)(char) so the addition's overflow is defined as being wrapping instead of being undefined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31248
[Bug c++/31246] Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-03-18 05:38 --- I agree with you Paolo. The front-end should make sure that its artefacts don't adversily affect diagnostics we emit. I agree to some extend. The reason why the try/catch is there is because of what the C++ standard says should happen and not really an artafact of what the GCC is doing really. When I first say this bug I was going to say this should not warned about, but when I looked into it a little more, I was thinking the warning is correct except for the fact, there is no way of working around the issue. I think we need to decide what -Wunreachable-code actually means, does it mean if there is a way to fix the code, then warn about unreachable code or does it mean to warn about code which is even hard to work around like in templates and constructors? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31246
[Bug c++/17000] parse error calling member template function of non-lvalue from within template class member
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-03-18 06:12 --- The work around is doing: get_a().template func2 int(); Which tells the compiler for sure func2 is a template. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17000
