[Bug middle-end/41924] graphite miscompiles aermod
--- Comment #3 from grosser at gcc dot gnu dot org 2009-11-21 08:32 --- Li, Is this bug solved with a newer cloog version? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41924
[Bug middle-end/42130] New: [graphite-branch] dealII fails
Compilation with only graphite-identity fails: -O3 -fno-loop-interchange -fno-loop-block -fno-loop-strip-mine -- Running 447.dealII train base amd64-m64-gcc43-nn default /home/grosser/spec/bin/specinvoke -d /home/grosser/spec/benchspec/CPU2006/447.dealII/run/run_base_train_amd64-m64-gcc43-nn.0007 -e speccmds.err -o speccmds.stdout -f speccmds.cmd -C 447.dealII: copy 0 non-zero return code (exit code=0, signal=11) -- without graphite identity it works: -O3 -fno-graphite-identity -fno-loop-interchange -fno-loop-block -fno-loop-strip-mine -fno-graphite -- Summary: [graphite-branch] dealII fails Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: grosser at gcc dot gnu dot org ReportedBy: grosser at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42130
[Bug middle-end/42130] [graphite-branch] dealII fails
--- Comment #1 from grosser at gcc dot gnu dot org 2009-11-21 08:50 --- Created an attachment (id=19071) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19071action=view) Small C++ testcase showing the same behavior -O2 -fno-tree-ch are required options Fails on execution Submitted by: Alexander Monakov -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42130
[Bug c/42126] gcc optimizes line away/optimizes to an endless loop
--- Comment #5 from codemasterhs at yahoo dot de 2009-11-21 09:02 --- (In reply to comment #4) The pointer is not declared volatile. static struct smpMsg_t * volatile freeList; would be a volatile pointer. Ok, this worked. So where has to be the volatile keyword, so that everything works? I mean I thought volatile TYPE (like int, char and so on) foo is right, isn´t it? Or does this only not work for pointers? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42126
[Bug middle-end/41924] graphite miscompiles aermod
--- Comment #4 from spop at gcc dot gnu dot org 2009-11-21 09:04 --- Yes, this should be fixed now in the Graphite branch, and it will be fixed in trunk after the merge that I am preparing. Sebastian -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41924
[Bug middle-end/41924] graphite miscompiles aermod
--- Comment #5 from spop at gcc dot gnu dot org 2009-11-21 09:09 --- My automatic testers are still failing one of the aermod tests, see for example pb05.sum from: http://groups.google.com/group/gcc-graphite-test/browse_thread/thread/4afb9c19aa8a10c7 -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41924
[Bug inline-asm/40124] Inline asm should support limited control flow
--- Comment #13 from pinskia at gcc dot gnu dot org 2009-11-21 09:12 --- Reopening to ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40124
[Bug inline-asm/40124] Inline asm should support limited control flow
--- Comment #14 from pinskia at gcc dot gnu dot org 2009-11-21 09:13
---
Mark this as fixed for 4.5:
http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Extended%20asm%20with%20gotoAs
of GCC version 4.5, asm goto may be used to have the assembly jump to one or
more C labels. In this form, a fifth section after the clobber list contains a
list of all C labels to which the assembly may jump. Each label operand is
implicitly self-named. The asm is also assumed to fall through to the next
statement.
This form of asm is restricted to not have outputs. This is due to a internal
restriction in the compiler that control transfer instructions cannot have
outputs. This restriction on asm goto may be lifted in some future version of
the compiler. In the mean time, asm goto may include a memory clobber, and so
leave outputs in memory.
int frob(int x)
{
int y;
asm goto (frob %%r5, %1; jc %l[error]; mov (%2), %%r5
: : r(x), r(y) : r5, memory : error);
return y;
error:
return -1;
}
In this (inefficient) example, the frob instruction sets the carry bit to
indicate an error. The jc instruction detects this and branches to the error
label. Finally, the output of the frob instruction (%r5) is stored into the
memory for variable y, which is later read by the return statement.
void doit(void)
{
int i = 0;
asm goto (mfsr %%r1, 123; jmp %%r1;
.pushsection doit_table;
.long %l0, %l1, %l2, %l3;
.popsection
: : : r1 : label1, label2, label3, label4);
__builtin_unreachable ();
label1:
f1();
return;
label2:
f2();
return;
label3:
i = 1;
label4:
f3(i);
}
In this (also inefficient) example, the mfsr instruction reads an address from
some out-of-band machine register, and the following jmp instruction branches
to that address. The address read by the mfsr instruction is assumed to have
been previously set via some application-specific mechanism to be one of the
four values stored in the doit_table section. Finally, the asm is followed by a
call to __builtin_unreachable to indicate that the asm does not in fact fall
through.
#define TRACE1(NUM) \
do { \
asm goto (0: nop; \
.pushsection trace_table; \
.long 0b, %l0; \
.popsection \
: : : : trace#NUM); \
if (0) { trace#NUM: trace(); } \
} while (0)
#define TRACE TRACE1(__COUNTER__)
In this example (which in fact inspired the asm goto feature) we want on rare
occasions to call the trace function; on other occasions we'd like to keep the
overhead to the absolute minimum. The normal code path consists of a single nop
instruction. However, we record the address of this nop together with the
address of a label that calls the trace function. This allows the nop
instruction to be patched at runtime to be an unconditional branch to the
stored label. It is assumed that an optimizing compiler will move the labeled
block out of line, to optimize the fall through path from the asm.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||FIXED
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40124
[Bug inline-asm/41294] =rm constraints give overlapping memory addresses
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-11-21 09:15 --- *** This bug has been marked as a duplicate of 37195 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41294
[Bug inline-asm/37195] different variables get the same overlapping memory address in inline assembly
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-11-21 09:15 --- *** Bug 41294 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37195
[Bug target/42100] soft float flags missings from libgcc.a (and others) if no --with-float given at configure time
--- Comment #2 from rearnsha at gcc dot gnu dot org 2009-11-21 10:56 --- This is a known problem, but I'm not going to fix it. The difficulty is that it will break object compatibility for a large number of users upgrading from older versions of the compiler (the attributes will conflict) forcing them to recompile everything (and in some cases that's not possible). The attribute system used in the arm-elf configuration is very primitive and not extensible, so it was entirely reworked as part of the ARM ABI standardization effort. Finally the arm-elf configuration is heading rapidly towards obsolescence so I would strongly recommend all developers moving towards the arm-eabi port. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42100
[Bug rtl-optimization/42116] ice on valid code (unrecognizable insn)
--- Comment #5 from ltuikov at yahoo dot com 2009-11-21 11:25 --- Also observed with gcc 4.4.2. -- ltuikov at yahoo dot com changed: What|Removed |Added Version|4.2.1 |4.4.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42116
[Bug rtl-optimization/42116] ice on valid code (unrecognizable insn)
--- Comment #6 from ltuikov at yahoo dot com 2009-11-21 11:31 --- Compiling gcc 4.4.2 cross compiler for ARC gives ICE, unrecognizable insn: [lu...@localhost libgcc]$/home/luben/ware/gcc-4.4.2-arc-build/./gcc/xgcc -v -sav e-temps -B/home/luben/ware/gcc-4.4.2-arc-build/./gcc/ -B/opt/arc-tools/arc-elf32/bin/ -B/opt/arc-tools/arc-elf32/lib/ -isystem /opt/arc-tools/arc-elf32/include -isystem /opt/arc-tools/arc-elf32/sys-include -g -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I../../../gcc-4.4.2/libgcc -I../../../gcc-4.4.2/libgcc/. -I../../../gcc-4.4.2/libgcc/../gcc -I../../../gcc-4.4.2/libgcc/../include -o _ffsdi2.o -MT _ffsdi2.o -MD -MP -MF _ffsdi2.dep -DL_ffsdi2 -c ../../../gcc-4.4.2/libgcc/../gcc/libgcc2.c Reading specs from /home/luben/ware/gcc-4.4.2-arc-build/./gcc/specs Target: arc-elf32 Configured with: ../gcc-4.4.2/configure --prefix=/opt/arc-tools --target=arc-elf32 --program-prefix=arc- --with-build-time-tools=/opt/arc-tools/bin --enable-multilib --disable-tls --enable-languages=c,c++ --disable-nls --with-headers --with-newlib --with-libs='/opt/arc-tools/lib /opt/arc-tools/lib64' Thread model: single gcc version 4.4.2 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-B/home/luben/ware/gcc-4.4.2-arc-build/./gcc/' '-B/opt/arc-tools/arc-elf32/bin/' '-B/opt/arc-tools/arc-elf32/lib/' '-isystem' '/opt/arc-tools/arc-elf32/include' '-isystem' '/opt/arc-tools/arc-elf32/sys-include' '-g' '-O2' '-O2' '-g' '-O2' '-DIN_GCC' '-DCROSS_DIRECTORY_STRUCTURE' '-W' '-Wall' '-Wwrite-strings' '-Wstrict-prototypes' '-Wmissing-prototypes' '-Wcast-qual' '-Wold-style-definition' '-isystem' './include' '-g' '-DIN_LIBGCC2' '-D__GCC_FLOAT_NOT_NEEDED' '-I.' '-I.' '-I../.././gcc' '-I../../../gcc-4.4.2/libgcc' '-I../../../gcc-4.4.2/libgcc/.' '-I../../../gcc-4.4.2/libgcc/../gcc' '-I../../../gcc-4.4.2/libgcc/../include' '-o' '_ffsdi2.o' '-MT' '_ffsdi2.o' '-MD' '-MP' '-MF' '_ffsdi2.dep' '-DL_ffsdi2' '-c' /home/luben/ware/gcc-4.4.2-arc-build/./gcc/cc1 -E -quiet -v -I. -I. -I../.././gcc -I../../../gcc-4.4.2/libgcc -I../../../gcc-4.4.2/libgcc/. -I../../../gcc-4.4.2/libgcc/../gcc -I../../../gcc-4.4.2/libgcc/../include -iprefix /home/luben/ware/gcc-4.4.2-arc-build/gcc/../lib/gcc/arc-elf32/4.4.2/ -isystem /home/luben/ware/gcc-4.4.2-arc-build/./gcc/include -isystem /home/luben/ware/gcc-4.4.2-arc-build/./gcc/include-fixed -MD _ffsdi2.d -MF _ffsdi2.dep -MP -MT _ffsdi2.o -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DL_ffsdi2 -isystem /opt/arc-tools/arc-elf32/include -isystem /opt/arc-tools/arc-elf32/sys-include -isystem ./include ../../../gcc-4.4.2/libgcc/../gcc/libgcc2.c -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -g -g -g -fworking-directory -O2 -O2 -O2 -fpch-preprocess -o libgcc2.i ignoring nonexistent directory /opt/arc-tools/arc-elf32/include ignoring nonexistent directory ./include ignoring nonexistent directory /home/luben/ware/gcc-4.4.2-arc-build/gcc/../lib/gcc/arc-elf32/4.4.2/include ignoring nonexistent directory /home/luben/ware/gcc-4.4.2-arc-build/gcc/../lib/gcc/arc-elf32/4.4.2/include-fixed ignoring nonexistent directory /home/luben/ware/gcc-4.4.2-arc-build/gcc/../lib/gcc/arc-elf32/4.4.2/../../../../arc-elf32/sys-include ignoring nonexistent directory /home/luben/ware/gcc-4.4.2-arc-build/gcc/../lib/gcc/arc-elf32/4.4.2/../../../../arc-elf32/include ignoring nonexistent directory /home/luben/ware/gcc-4.4.2-arc-build/gcc/../lib/gcc/../../lib/gcc/arc-elf32/4.4.2/include ignoring nonexistent directory /home/luben/ware/gcc-4.4.2-arc-build/gcc/../lib/gcc/../../lib/gcc/arc-elf32/4.4.2/include-fixed ignoring nonexistent directory /home/luben/ware/gcc-4.4.2-arc-build/gcc/../lib/gcc/../../lib/gcc/arc-elf32/4.4.2/../../../../arc-elf32/sys-include ignoring nonexistent directory /home/luben/ware/gcc-4.4.2-arc-build/gcc/../lib/gcc/../../lib/gcc/arc-elf32/4.4.2/../../../../arc-elf32/include ignoring duplicate directory . ignoring duplicate directory ../../../gcc-4.4.2/libgcc/. #include ... search starts here: #include ... search starts here: . ../.././gcc ../../../gcc-4.4.2/libgcc ../../../gcc-4.4.2/libgcc/../gcc ../../../gcc-4.4.2/libgcc/../include /home/luben/ware/gcc-4.4.2-arc-build/./gcc/include /home/luben/ware/gcc-4.4.2-arc-build/./gcc/include-fixed /opt/arc-tools/arc-elf32/sys-include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-B/home/luben/ware/gcc-4.4.2-arc-build/./gcc/' '-B/opt/arc-tools/arc-elf32/bin/' '-B/opt/arc-tools/arc-elf32/lib/' '-isystem' '/opt/arc-tools/arc-elf32/include' '-isystem' '/opt/arc-tools/arc-elf32/sys-include' '-g' '-O2' '-O2' '-g' '-O2' '-DIN_GCC' '-DCROSS_DIRECTORY_STRUCTURE' '-W' '-Wall' '-Wwrite-strings' '-Wstrict-prototypes' '-Wmissing-prototypes' '-Wcast-qual' '-Wold-style-definition'
[Bug rtl-optimization/42116] ice on valid code (unrecognizable insn)
--- Comment #7 from ltuikov at yahoo dot com 2009-11-21 11:34 --- Created an attachment (id=19072) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19072action=view) Preprocessed source code ICE compiling a cross compiler for ARC with gcc 4.4.2. -- ltuikov at yahoo dot com changed: What|Removed |Added Attachment #19065|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42116
[Bug rtl-optimization/42116] ice on valid code (unrecognizable insn)
--- Comment #8 from ltuikov at yahoo dot com 2009-11-21 11:35 --- Created an attachment (id=19073) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19073action=view) Assembly output ICE compiling a cross compiler for ARC with gcc 4.4.2. -- ltuikov at yahoo dot com changed: What|Removed |Added Attachment #19066|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42116
[Bug target/40959] build fails - No rule to make target `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o', needed by `T_TARGET'. Stop.
--- Comment #12 from mexas at bristol dot ac dot uk 2009-11-21 11:47 --- I see.. So what is the way forward? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40959
[Bug rtl-optimization/42116] ice on valid code (unrecognizable insn)
--- Comment #9 from ltuikov at yahoo dot com 2009-11-21 12:01 --- The ICE is generated when cross-compiling libgcc2.c at line 547. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42116
[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression
--- Comment #15 from toon at moene dot org 2009-11-21 12:11 --- I don't see that the standard suggests the specific code the Frontend generates. In fact it should be valid to increment the DO variable by m3 and express the exit test in terms of the DO variable as well. The Standard doesn't prescribe the code the Frontend generates - however, to be sure one follows the Standard, it's most easy to simply implement the steps given. To illustrate this with a simple example: DO I = M1, M2, M3 B(I) = A(I) ENDDO would be most easily, and atraightforwardly, implemented as follows: IF (M3 0 .AND. M1 M2) GOTO 200 ! Loop executed zero times IF (M3 0 .AND. M1 M2) GOTO 200 ! Ditto ITEMP = (M2 - M1 + M3) / M3 ! Temporary loop count I = M1 100 CONTINUE B(I) = A(I) ITEMP = ITEMP - 1 ! Adjust internal loop counter I = I + M3 ! Adjust DO loop variable IF (ITEMP 0) GOTO 100 200 CONTINUE That there are two induction variables in this loop is inconsequential - one of them should be eliminated by induction variable elimination (at least, that was the case with g77 and the RTL loop optimization pass). If you think that the Frontend does something different / in addition to the above, feel free to open a separate PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression
--- Comment #16 from rguenther at suse dot de 2009-11-21 12:19 --- Subject: Re: [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression On Sat, 21 Nov 2009, toon at moene dot org wrote: --- Comment #15 from toon at moene dot org 2009-11-21 12:11 --- I don't see that the standard suggests the specific code the Frontend generates. In fact it should be valid to increment the DO variable by m3 and express the exit test in terms of the DO variable as well. The Standard doesn't prescribe the code the Frontend generates - however, to be sure one follows the Standard, it's most easy to simply implement the steps given. To illustrate this with a simple example: DO I = M1, M2, M3 B(I) = A(I) ENDDO would be most easily, and atraightforwardly, implemented as follows: IF (M3 0 .AND. M1 M2) GOTO 200 ! Loop executed zero times IF (M3 0 .AND. M1 M2) GOTO 200 ! Ditto ITEMP = (M2 - M1 + M3) / M3 ! Temporary loop count I = M1 100 CONTINUE B(I) = A(I) ITEMP = ITEMP - 1 ! Adjust internal loop counter I = I + M3 ! Adjust DO loop variable IF (ITEMP 0) GOTO 100 200 CONTINUE That there are two induction variables in this loop is inconsequential - one of them should be eliminated by induction variable elimination (at least, that was the case with g77 and the RTL loop optimization pass). Sure, but the frontend generates if (M3 0) ITEMP = (M2 - M1) / M3 else ITEMP = (M1 - M2) / -M3 I = M1 100 CONTINUE B(I) = A(I) I = I + M3 if (ITEMP == 0) GOTO 200 ITEMP = ITEMP - 1 GOTO 100 200 CONTINUE The conditional setting of ITEMP is what confuses GCC. Also I don't see the test for zero-time executing loops (but maybe I omitted it from my pasting in comment #12). Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug c/39985] Type qualifiers not actually ignored on function return type
--- Comment #1 from gcc at magfr dot user dot lysator dot liu dot se 2009-11-21 12:24 --- Created an attachment (id=19074) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19074action=view) Test case - g++ -Wignored-qualifiers test.C gives confusing results In C++ it becomes even worse since the types are used more. As it stands right now it becomes ridiculous: $ g++ -Wignored-qualifiers test.C test.C:12: warning: type qualifiers ignored on function return type test.C:12: error: conflicting return type specified for virtual const int D1::F() test.C:5: error: overriding virtual int B1::F() test.C:20: warning: type qualifiers ignored on function return type test.C:27: error: conflicting return type specified for virtual int D2::F() test.C:20: error: overriding virtual const int B2::F() Are the type qualifiers ignored or are they not? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39985
[Bug middle-end/42127] Verify_flow_info: Wrong frequency of block. Profiled bootstrap failed.
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2009-11-21 13:40 --- This maybe related to r154291 (tree-optimize.c (execute_fixup_cfg): Rescale frequencies.) Counts are not rescaled for entry block and exit block. Then in counts_to_freqs(), their frequencies become very large. Then overflow into a negative number in EDGE_FREQUENCY() in find_many_sub_basic_blocks(). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42127
[Bug fortran/42131] New: Weird translation of DO loops
Split out from PR42108.
The loop is not unrolled because the frontend presents us with very funny
obfuscated code:
do k=i,nnd,n
temp=temp+(x(k)-x(k+jmini))**2
end do
gets translated to
{
character(kind=4) countm1.6;
integer(kind=4) D.1551;
integer(kind=4) D.1550;
integer(kind=4) D.1549;
D.1549 = i;
D.1550 = *nnd;
D.1551 = *n;
k = D.1549;
if (D.1551 0)
{
if (D.1550 D.1549) goto L.6;, countm1.6 = (character(kind=4)) (D.1550 -
D.1549) / (character(kind=4)) D.1551;;
}
else
{
if (D.1550 D.1549) goto L.6;, countm1.6 = (character(kind=4)) (D.1549 -
D.1550) / (character(kind=4)) -D.1551;;
}
while (1)
{
{
real(kind=8) D.1556;
real(kind=8) D.1555;
D.1555 = (((*x)[(integer(kind=8)) k + -1] - (*x)[(integer(kind=8)) (k
+ jmini) + -1]));
D.1556 = D.1555 * D.1555;
temp = temp + D.1556;
}
L.5:;
k = k + D.1551;
if (countm1.6 == 0) goto L.6;
countm1.6 = countm1.6 + 4294967295;
}
L.6:;
}
The funny conditional initialization of countm1.6 makes the analysis of
the number of iterations of this loop impossible (not to mention the
conversions to character(kind=4)).
Toon suggests:
The Standard doesn't prescribe the code the Frontend generates - however, to be
sure one follows the Standard, it's most easy to simply implement the steps
given.
To illustrate this with a simple example:
DO I = M1, M2, M3
B(I) = A(I)
ENDDO
would be most easily, and atraightforwardly, implemented as follows:
IF (M3 0 .AND. M1 M2) GOTO 200 ! Loop executed zero times
IF (M3 0 .AND. M1 M2) GOTO 200 ! Ditto
ITEMP = (M2 - M1 + M3) / M3 ! Temporary loop count
I = M1
100 CONTINUE
B(I) = A(I)
ITEMP = ITEMP - 1 ! Adjust internal loop counter
I = I + M3 ! Adjust DO loop variable
IF (ITEMP 0) GOTO 100
200 CONTINUE
That there are two induction variables in this loop is inconsequential - one of
them should be eliminated by induction variable elimination (at least, that was
the case with g77 and the RTL loop optimization pass).
which I would agree with. I btw cannot see the difference between
if (D.1551 0)
{
if (D.1550 D.1549) goto L.6;, countm1.6 = (character(kind=4)) (D.1550 -
D.1549) / (character(kind=4)) D.1551;;
}
else
{
if (D.1550 D.1549) goto L.6;, countm1.6 = (character(kind=4)) (D.1549 -
D.1550) / (character(kind=4)) -D.1551;;
}
and
if ((D.1551 0 D.1550 D.1549) || (D.1551 0 D.1550 D.1549))
goto L.6;
countm1.6 = (character(kind=4)) (D.1550 - D.1549) / (character(kind=4)) D.1551;
where the unconditional initialization of countm1.6 is the important difference
(I'm sure the zero-trip-count check can be done more efficiently).
--
Summary: Weird translation of DO loops
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression
--- Comment #17 from rguenth at gcc dot gnu dot org 2009-11-21 13:58 --- I have filed PR42131 for the DO loop translation issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug middle-end/42103] [4.4 regression] packed 64-bit field reports as violation of strict aliasing rules
--- Comment #4 from tlesher at digium dot com 2009-11-21 14:05 --- (In reply to comment #3) (In reply to comment #2) I've also confirmed that using the 'may_alias' attribute in the 64-bit version suppresses the warning, although I think this qualifies as a workaround, not a fix to the problem. I'm also not sure how our project leaders would consider such a workaround, given that the intent behind extra warnings is to make the code better. It is not a work around, it fixes the aliasing issue in your code. Let us suppose that you are correct, that there is an aliasing issue in my code. Why would code that differs only by length of type generate an aliasing warning on 64-bit but remain silent on 32-bit? Does not that point to a similar aliasing problem in the 32-bit case? Why does gcc not generate a warning in that case? Or if gcc is correct in not generating a warning for 32-bit, why is it correct to generate that warning for 64-bit? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42103
[Bug c++/42132] New: [C++0x] SFINAE failure with cv-qualifiers
Consider a simplified form of std::bind that just wraps a functor and calls it,
preserving the cv-qualifiers on the wrapper:
#include utility
using std::declval;
templatetypename Sig
struct result_of;
templatetypename Fn, typename... ArgTypes
struct result_ofFn(ArgTypes...)
{
typedef decltype( declvalFn()( declvalArgTypes()... ) ) type;
};
templatetypename Fn
struct Binder
{
Fn functor;
typename result_ofFn()::type
call()
{
return functor();
}
typename result_ofconst Fn()::type
call() const
{
return functor();
}
typename result_ofvolatile Fn()::type
call() volatile
{
return functor();
}
typename result_ofconst volatile Fn()::type
call() const volatile
{
return functor();
}
};
struct F
{
int operator()() { return 0; }
};
int main()
{
BinderF b = { };
b.call();
}
This gives:
bind.cc: In instantiation of 'result_ofconst F()':
bind.cc:26:3: instantiated from 'BinderF'
bind.cc:52:13: instantiated from here
bind.cc:11:65: error: passing 'const F' as 'this' argument of 'int
F::operator()()' discards qualifiers
bind.cc:11:65: error: passing 'const F' as 'this' argument of 'int
F::operator()()' discards qualifiers
bind.cc: In instantiation of 'result_ofvolatile F()':
bind.cc:32:3: instantiated from 'BinderF'
bind.cc:52:13: instantiated from here
bind.cc:11:65: error: passing 'volatile F' as 'this' argument of 'int
F::operator()()' discards qualifiers
bind.cc:11:65: error: passing 'volatile F' as 'this' argument of 'int
F::operator()()' discards qualifiers
bind.cc: In instantiation of 'result_ofconst volatile F()':
bind.cc:38:3: instantiated from 'BinderF'
bind.cc:52:13: instantiated from here
bind.cc:11:65: error: passing 'const volatile F' as 'this' argument of 'int
F::operator()()' discards qualifiers
bind.cc:11:65: error: passing 'const volatile F' as 'this' argument of 'int
F::operator()()' discards qualifiers
using:
Using built-in specs.
COLLECT_GCC=/home/jwakely/gcc/4.x/bin/g++
COLLECT_LTO_WRAPPER=/home/jwakely/gcc/4.x/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../src/gcc/configure --prefix=/n/14/jwakely/gcc/4.x
--with-mpfr=/opt/cfarm/mpfr-2.4.1 --with-gmp=/opt/cfarm/gmp-4.2.4
--enable-libstdcxx-time=rt --enable-languages=c,c++ --disable-bootstrap :
(reconfigured) ../src/gcc/configure --prefix=/n/14/jwakely/gcc/4.x
--with-mpfr=/opt/cfarm/mpfr-2.4.1 --with-gmp=/opt/cfarm/gmp-4.2.4
--enable-libstdcxx-time=rt --enable-languages=c,c++ --disable-bootstrap
Thread model: posix
gcc version 4.5.0 20091121 (experimental) (GCC)
The problem is that overload resolution for b.call() causes result_ofcv-qual
Fn::type to be instantiated, which gives an error when cv-qual does not
match the cv-quals of Fn::operator()
Shouldn't SFINAE cause those invalid instantiations to be ignored, silently
removing the invalid overloads from the overload set, leaving just the one I'm
trying to call?
This is blocking my attempts to make std::bind conform to the C++0x WP,
particularly forwarding cv-quals. If g++ is right, what extra hoops do I need
to jump through to make the code above work?
I get the same result if I use decltype directly, rather than via result_of,
which is why I think this is a sfinae bug, not a problem with using result_of
here:
#include utility
using std::declval;
templatetypename Fn
struct Binder
{
Fn functor;
decltype( declvalFn()() )
call()
{
return functor();
}
decltype( declvalconst Fn()() )
call() const
{
return functor();
}
decltype( declvalvolatile Fn()() )
call() volatile
{
return functor();
}
decltype( declvalconst volatile Fn()() )
call() const volatile
{
return functor();
}
};
struct F
{
int operator()() { return 0; }
};
int main()
{
BinderF b = { };
b.call();
}
bind.cc: In instantiation of 'BinderF':
bind.cc:43:13: instantiated from here
bind.cc:17:3: error: passing 'const F' as 'this' argument of 'int
F::operator()()' discards qualifiers
bind.cc: In instantiation of 'BinderF':
bind.cc:43:13: instantiated from here
bind.cc:23:3: error: passing 'volatile F' as 'this' argument of 'int
F::operator()()' discards qualifiers
bind.cc: In instantiation of 'BinderF':
bind.cc:43:13: instantiated from here
bind.cc:29:3: error: passing 'const volatile F' as 'this' argument of 'int
F::operator()()' discards qualifiers
N.B. tr1::bind can handle this because tr1::result_of doesn't preserve
cv-quals, which means it gives the wrong result when operator() is overloaded
for different cv qualifiers.
--
Summary: [C++0x] SFINAE failure with cv-qualifiers
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: redi at gcc dot gnu dot org
OtherBugsDependingO 35569
nThis:
http://gcc.gnu.org
[Bug c/36470] sizeof UTF-32 is 2 on AVR
--- Comment #4 from hutchinsonandy at gcc dot gnu dot org 2009-11-21 15:06 --- Test and now passes for avr and m32 targets. gcc.dg/utf32-1.c gcc.dg/utf32-2.c gcc.dg/utf32-3.c I will remove XFAIL in cleanup patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36470
[Bug target/42113] [4.3/4.4/4.5 Regression] Internal Compiler error with -O3, breaking commit known
--- Comment #7 from mattst88 at gmail dot com 2009-11-21 16:15 --- I can confirm that the attached patch fixes the issue. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
[Bug c++/42133] New: undiagnosed uninitialized variable
#include stdio.h
int main(int argc, char *argv[])
{
int click;
click++;
printf(click is %d \n,click);
return 0;
}
compile and execute:
test $: g++ -o gccbug gccbug.cpp
test $: ./gccbug
click is 1
In this case click is set to zero. When I found this bug in
a more complex program click had been set to -1 initially.
--
Summary: undiagnosed uninitialized variable
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kornelix at yahoo dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42133
[Bug c++/42133] undiagnosed uninitialized variable
--- Comment #1 from kornelix at yahoo dot de 2009-11-21 16:21 --- Sorry, -Wall will indeed trigger a diagnostic. Please erase this report. Mike -- kornelix at yahoo dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42133
[Bug fortran/42131] Weird translation of DO loops
--- Comment #1 from kargl at gcc dot gnu dot org 2009-11-21 16:26 --- (In reply to comment #0) To illustrate this with a simple example: DO I = M1, M2, M3 B(I) = A(I) ENDDO would be most easily, and atraightforwardly, implemented as follows: IF (M3 0 .AND. M1 M2) GOTO 200 ! Loop executed zero times IF (M3 0 .AND. M1 M2) GOTO 200 ! Ditto First, I just woke up 10 minutes ago and still have 1/2 of cup of coffee, but the logic above looks wrong. do i = 1, 2, 1 print *, i end do should produce 1 2 Here, we have m1 = 1, m2 = 2, m3 = 1 IF (M3 0 .AND. M1 M2) GOTO 200 ! Loop executed zero times -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug c++/41727] inner template specialization on non-type arg template causes ICE
--- Comment #2 from cppljevans at suddenlink dot net 2009-11-21 16:46
---
Created an attachment (id=19075)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19075action=view)
zip archive with test case and Makefile and compile output
The recently attached .zip file contains:
M Filemode Length Date Time File
- -- --- -
-rw-r--r-- 1621 21-Nov-2009 09:40:04 bug.value_wrap.cpp
-rw-r--r-- 1061 21-Nov-2009 09:57:30 bug.value_wrap.report
-rw-r--r-- 1215 21-Nov-2009 09:53:30 Makefile
- -- --- -
3897 3 files
The .cpp File is the source file which was compiled with the Makefile
to produce the .report file. The .report shows the compilation of the
.cpp with every possible combination of {defined,undefined} properties
for Macros in {OUTER_ARG0_SPECIALIZED,INNER_ARG1_NON_TYPE}. All
compiles with -DOUTER_ARG0_SPECIALIZED succeed. Both compiles with
-UOUTER_ARG0_SPECIALIZED fail; however, the one with
-DINNER_ARG1_NON_TYPE produces the ICE.
I suspect the problem is related to the attempt to substitute an outer
template argument into the slot for an inner template parameter as
noted in the following post to the gcc.devel newsgroup:
http://article.gmane.org/gmane.comp.gcc.devel/110111/match=pt+c+most_specialized_class
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41727
[Bug middle-end/42103] [4.4 regression] packed 64-bit field reports as violation of strict aliasing rules
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-11-21 17:29 ---
static inline void put_unaligned_uint64(void *p, uint64_t datum)
{
struct { uint64_t d; } __attribute__((packed)) *pp = p;
pp-d = datum;
}
int iax_ie_append_versioned_uint64(struct iax_ie_data *ied, unsigned char ie,
unsigned char version, uint64_t value)
{
struct _local {
unsigned char version;
uint64_t value;
} __attribute__((packed)) newval = { version, };
put_unaligned_uint64(newval.value, htonll(value));
return iax_ie_append_raw(ied, ie, newval, (int) sizeof(newval));
}
This code accesses an object of type uint64_t via a pointer to a
struct containing an uint64_t which is an alias violation.
I don't see put_unaligned_uint32 being used, and only in the context
of the use of put_unaligned_uint64 it is appearant to the compiler
that you violate C aliasing rules.
You probably instead want to use sth like
typedef uint64_t __attribute__((aligned(1))) unaligned_uint64_t;
static inline void put_unaligned_uint64(void *p, uint64_t datum)
{
unaligned_uint64_t *pp = p;
*pp = datum;
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42103
[Bug fortran/42131] Weird translation of DO loops
--- Comment #2 from toon at moene dot org 2009-11-21 17:33 --- Sorry, Steve - my mistake. The original message should have been: To illustrate this with a simple example: DO I = M1, M2, M3 B(I) = A(I) ENDDO would be most easily, and straightforwardly, implemented as follows: IF (M3 0 .AND. M1 M2) GOTO 200 ! Loop executed zero times IF (M3 0 .AND. M1 M2) GOTO 200 ! Ditto ITEMP = (M2 - M1 + M3) / M3 ! Temporary loop counter I = M1 100 CONTINUE B(I) = A(I) ITEMP = ITEMP - 1 ! Adjust internal loop counter I = I + M3 ! Adjust DO loop variable IF (ITEMP = 0) GOTO 100 200 CONTINUE I hope this makes clear what's weird about the way the Fortran Frontend does it now. The example code follows the Standard as close as possible (it only doesn't check that m3 isn't zero, which isn't allowed), except that I follow Note 8.7 instead of the reasoning in the sequence of steps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug middle-end/42127] Verify_flow_info: Wrong frequency of block. Profiled bootstrap failed.
--- Comment #2 from b3timmons at speedymail dot org 2009-11-21 17:37 --- (In reply to comment #0) GCC 4.5.0 20091119 (r154346) ../../gcc-4.5/gcc/gengtype-parse.c: In function âarray_and_function_declarators_optâ: ../../gcc-4.5/gcc/gengtype-parse.c:508:1: error: verify_flow_info: Wrong frequency of block 13 -184951 ../../gcc-4.5/gcc/gengtype-parse.c:508:1: internal compiler error: verify_flow_info failed Also happens on x86_64-unknown-linux-gnu under r154408: ../../gcc/gcc/c-parser.c: In function c_parser_next_token_is: ../../gcc/gcc/c-parser.c:336:1: error: verify_flow_info: Wrong frequency of block 7 -199641 -- b3timmons at speedymail dot org changed: What|Removed |Added CC||b3timmons at speedymail dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42127
[Bug fortran/42131] Weird translation of DO loops
--- Comment #3 from tkoenig at gcc dot gnu dot org 2009-11-21 18:31 --- (In reply to comment #2) Sorry, Steve - my mistake. The original message should have been: To illustrate this with a simple example: DO I = M1, M2, M3 B(I) = A(I) ENDDO would be most easily, and straightforwardly, implemented as follows: IF (M3 0 .AND. M1 M2) GOTO 200 ! Loop executed zero times IF (M3 0 .AND. M1 M2) GOTO 200 ! Ditto ITEMP = (M2 - M1 + M3) / M3 ! Temporary loop counter I = M1 100 CONTINUE B(I) = A(I) ITEMP = ITEMP - 1 ! Adjust internal loop counter I = I + M3 ! Adjust DO loop variable IF (ITEMP = 0) GOTO 100 200 CONTINUE As written, this executes the assignment one time too many. The last but one line should read: IF (ITEMP 0) GOTO 100 What we generate has the test at the bottom of the loop, whereas 8.1.6.4.2 puts the test of the iteration count first. What we could generate, IMHO, is read (*,*) m1, m2, m3 ITEMP = (M2 - M1 + M3) / M3 ! Temporary loop counter print *,'itemp=',itemp I = M1 100 CONTINUE IF (ITEMP = 0) GOTO 200 print *,i I = I + M3 ! Adjust DO loop variable ITEMP = ITEMP - 1 ! Adjust internal loop counter GOTO 100 200 CONTINUE print *,final : i = , i end Does this have any drawbacks? Would the middle end recognize this for vectorization and loop unrolling? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug middle-end/42127] Verify_flow_info: Wrong frequency of block. Profiled bootstrap failed.
--- Comment #3 from hubicka at ucw dot cz 2009-11-21 18:54 --- Subject: Re: Verify_flow_info: Wrong frequency of block. Profiled bootstrap failed. --- Comment #2 from b3timmons at speedymail dot org 2009-11-21 17:37 --- (In reply to comment #0) GCC 4.5.0 20091119 (r154346) ../../gcc-4.5/gcc/gengtype-parse.c: In function âarray_and_function_declarators_optâ: ../../gcc-4.5/gcc/gengtype-parse.c:508:1: error: verify_flow_info: Wrong frequency of block 13 -184951 ../../gcc-4.5/gcc/gengtype-parse.c:508:1: internal compiler error: verify_flow_info failed Also happens on x86_64-unknown-linux-gnu under r154408: ../../gcc/gcc/c-parser.c: In function c_parser_next_token_is: ../../gcc/gcc/c-parser.c:336:1: error: verify_flow_info: Wrong frequency of block 7 -199641 Looks like overflow in frequency scaling. I will look into this. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42127
[Bug tree-optimization/42078] [4.5 Regression] ICE in gimple_assign_set_rhs_code
-- aoliva at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42078
[Bug tree-optimization/42078] [4.5 Regression] ICE in gimple_assign_set_rhs_code
--- Comment #9 from aoliva at gcc dot gnu dot org 2009-11-21 19:12 --- Fixed -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42078
[Bug c++/27402] error on SFINAE
--- Comment #2 from paolo dot carlini at oracle dot com 2009-11-21 19:16 --- This works with 4.4.x and current mainline. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Known to fail||4.1.0 4.3.3 Known to work||4.4.0 4.5.0 Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27402
[Bug fortran/42131] Weird translation of DO loops
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-11-21 19:24 ---
The middle-end prefers do { } while () loop style so it knows the loop is
always executed. It even tries to transform other loop forms into this by
copying the loop header. So if the FE already can cheaply produce this
it would be prefered.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug fortran/38530] ICE with the example for c_funloc
--- Comment #4 from dominiq at lps dot ens dot fr 2009-11-21 20:46 --- This PR and PR42119 are fixed by the patch in comment #1 of PR42119 without regression. It also fixes the test in comment #7 pf PR34199. As far as I can understand the comment /* ??? This should be considered a front-end bug. We should not be generating ADDR_EXPR of something that isn't an LVALUE. The only exception here is STRING_CST. */ there is something wrong in gfortran. Is the patch in comment #2 a step in the right direction? As a side note, it would be nice to have the companion C code to have an executable test in the manual. -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38530
[Bug testsuite/42135] New: FAIL: libgomp.graphite/force-parallel-2.c execution test
Since revision 150792, the test libgomp.graphite/force-parallel-2.c (introduced
in revision 150755) fails on *-apple-darwin9. AFAICT the array x[1][1]
is allocated in stack and is too big for the 64Mb hard limit on darwin. One
solution could be to replace 1 with 4000. Also the following patch works.
--- /opt/gcc/_gcc_clean/libgomp/testsuite/libgomp.graphite/graphite.exp
2009-08-14 19:16:39.0 +0200
+++ /opt/gcc/gcc-4.5-work/libgomp/testsuite/libgomp.graphite/graphite.exp
2009-11-20 16:32:46.0 +0100
@@ -33,10 +33,24 @@ if ![check_effective_target_fgraphite] {
}
# Flags for force-parallel-*.c testcases.
-set PARALLEL_CFLAGS -ansi -pedantic-errors -O2 \
--ftree-parallelize-loops=4 -floop-parallelize-all \
--fdump-tree-parloops-details -fdump-tree-optimized \
--fno-loop-strip-mine -fdump-tree-graphite-all
+if { ![istarget *-*-darwin*] } {
+set PARALLEL_CFLAGS -ansi -pedantic-errors -O2 \
+-ftree-parallelize-loops=4 -floop-parallelize-all \
+-fdump-tree-parloops-details -fdump-tree-optimized \
+-fno-loop-strip-mine -fdump-tree-graphite-all
+ } elseif { ![is-effective-target lp64] } {
+set PARALLEL_CFLAGS -ansi -pedantic-errors -O2 \
+-ftree-parallelize-loops=4 -floop-parallelize-all \
+-fdump-tree-parloops-details -fdump-tree-optimized \
+-fno-loop-strip-mine -fdump-tree-graphite-all \
+-Wl,-stack_size,0x2000,-stack_addr,0xa000
+ } else {
+set PARALLEL_CFLAGS -ansi -pedantic-errors -O2 \
+-ftree-parallelize-loops=4 -floop-parallelize-all \
+-fdump-tree-parloops-details -fdump-tree-optimized \
+-fno-loop-strip-mine -fdump-tree-graphite-all \
+-Wl,-stack_size,0x2000
+ }
# Initialize `dg'.
dg-init
What is the best solution? or is there a better one?
--
Summary: FAIL: libgomp.graphite/force-parallel-2.c execution test
Product: gcc
Version: 4.5.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: *-apple-darwin9
GCC host triplet: *-apple-darwin9
GCC target triplet: *-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42135
[Bug c++/42132] [C++0x] SFINAE failure with cv-qualifiers
--- Comment #1 from paolo dot carlini at oracle dot com 2009-11-21 21:11 --- No excuses, just use --permissive! ;) Seriously, it would be nice if Jason could confirm this is glitch in the extended SFINAE implementation, which, in case, could be relatively easy to fix, I suspect... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||paolo dot carlini at oracle ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42132
[Bug fortran/42131] Weird translation of DO loops
--- Comment #5 from toon at moene dot org 2009-11-21 21:40 ---
The middle-end prefers do { } while () loop style so it knows the loop is
always executed.
And the Fortran Standard describes the loops being built (by compilers) just
so:
1. First you determine what is m1, m2, m3
2. Then you initialize the do loop counter with m1
3. Then you determine the loop count (m2 - m1 + m3) / m3
4. If the loop count is zero or negative, you skip the loop
5. Otherwise, you traverse the loop body at least once.
Or, to return to our example (and fix the mistake Thomas Koenig noted):
DO I = M1, M2, M3
B(I) = A(I)
ENDDO
turns into
ITEMP = (M2 - M1 + M3) / M3 ! The iteration count
IF (ITEMP = 0) GOTO 200 ! Past this point, the loop is executed
I = M1 ! at least once.
100 CONTINUE
B(I) = A(I)
ITEMP = ITEMP - 1
I = I + M3
IF (ITEMP 0) GOTO 100
200 CONTINUE
therewith following the (normative) text of the Standard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug c++/42132] [C++0x] SFINAE failure with cv-qualifiers
--- Comment #2 from jason at gcc dot gnu dot org 2009-11-21 21:41 --- Shouldn't SFINAE cause those invalid instantiations to be ignored, silently removing the invalid overloads from the overload set, leaving just the one I'm trying to call? No, SFINAE only applies to function signatures; if considering a signature triggers an invalid instantiation, that makes the program ill-formed. I think the version without result_of ought to work, however. -- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-21 21:41:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42132
[Bug c++/42132] [C++0x] SFINAE failure with cv-qualifiers
--- Comment #3 from jason at gcc dot gnu dot org 2009-11-21 21:51 --- 14.9.2/8: Only invalid types and expressions in the immediate context of the function type and its template parameter types can result in a deduction failure. [ Note: The evaluation of the substituted types and expressions can result in side effects such as the instantiation of class template specializations and/or function template specializations, the generation of implicitly-defined functions, etc. Such side effects are not in the immediate context and can result in the program being ill-formed. end note ] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42132
[Bug tree-optimization/39960] [4.5 Regression] struct-reorg is broken
--- Comment #7 from hjl dot tools at gmail dot com 2009-11-21 22:08 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39960
[Bug c++/42132] [C++0x] SFINAE failure with cv-qualifiers
--- Comment #4 from jason at gcc dot gnu dot org 2009-11-21 22:08 ---
Actually, the decltype variant isn't a SFINAE issue either; SFINAE only applies
to function templates because it's part of deduction. For a simpler example:
template class T
struct A
{
void f (T::type);
};
Aint a;
This is ill-formed, we don't discard f from Aint.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42132
[Bug fortran/41807] [4.5/4.4 Regression] data statement with nested type constructors
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2009-11-21 22:15
---
Here is a tentative patch. I removed the offending code and ran the testsuite
to see what would happen. The only failure was the test case associated with
patch that caused the regression. This failure was an ICE on and assert. So i
thought, why not just replace that assert with the error message, and it
appears to work. It even sort of make sense, its not very intrusive, and it
passes regression testing on x86-64.
Any opinions? Shall we just uuse this?
Index: trans-const.c
===
--- trans-const.c (revision 154411)
+++ trans-const.c (working copy)
@@ -340,7 +340,7 @@ void
gfc_conv_constant (gfc_se * se, gfc_expr * expr)
{
/* We may be receiving an expression for C_NULL_PTR or C_NULL_FUNPTR. If
- so, they expr_type will not yet be an EXPR_CONSTANT. We need to make
+ so, the expr_type will not yet be an EXPR_CONSTANT. We need to make
it so here. */
if (expr-ts.type == BT_DERIVED expr-ts.u.derived
expr-ts.u.derived-attr.is_iso_c)
@@ -353,7 +353,11 @@ gfc_conv_constant (gfc_se * se, gfc_expr * expr)
}
}
- gcc_assert (expr-expr_type == EXPR_CONSTANT);
+ if (expr-expr_type != EXPR_CONSTANT)
+{
+ gfc_error (non-constant DATA value at %L, expr-where);
+ return;
+}
if (se-ss != NULL)
{
Index: resolve.c
===
--- resolve.c (revision 154411)
+++ resolve.c (working copy)
@@ -11083,9 +11083,6 @@ next_data_value (void)
{
while (mpz_cmp_ui (values.left, 0) == 0)
{
- if (!gfc_is_constant_expr (values.vnode-expr))
- gfc_error (non-constant DATA value at %L,
- values.vnode-expr-where);
if (values.vnode-next == NULL)
return FAILURE;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41807
[Bug c/42136] New: Inconsistent strict-aliasing warning with cast from char[]
Source:
typedef union u { unsigned i; unsigned short s[2]; unsigned char c[4]; } u;
char c[4] __attribute__((aligned));
short s[2] __attribute__((aligned));
int f1()
{
return ((union u*)s)-i;
}
int f2()
{
return ((union u*)c)-i;
}
Using gcc 4.5:
gcc -O3 -fstrict-aliasing -Wall -S wstrict_aliasing_char.c
wstrict_aliasing_char.c: In function 'f2':
wstrict_aliasing_char.c:13:17: warning: dereferencing type-punned pointer will
break strict-aliasing rules
I would expect either both or neither of the functions to warn, since pointer
casting to unions is given in the manual as something that violates
strict-aliasing, although gcc doesn't seem to actually take advantage of this.
Instead, it looks like the warning is hardcoded to apply to a cast from char
(c-common.c:1746 in r1554411):
alias_set_type set1 =
get_alias_set (TREE_TYPE (TREE_OPERAND (expr, 0)));
alias_set_type set2 = get_alias_set (TREE_TYPE (type));
if (set1 != set2 set2 != 0
(set1 == 0 || !alias_sets_conflict_p (set1, set2)))
{
warning (OPT_Wstrict_aliasing, dereferencing type-punned
pointer will break strict-aliasing rules);
return true;
}
This came up during some x264 work, but it's taken care of now with some
__attribute__((may_alias)).
--
Summary: Inconsistent strict-aliasing warning with cast from
char[]
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: astrange at ithinksw dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42136
[Bug c/42136] Inconsistent strict-aliasing warning with cast from char[]
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-21 22:56 --- !alias_sets_conflict_p (set1, set2) should really be alias_set_subset_of with all the added false positives from the very imprecise frontend code that this would cause. Thus, the cast from short[] also should warn. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2009-11-21 22:56:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42136
[Bug middle-end/42025] [4.5 Regression] ICE verify_stmts failed (non-trivial conversion at assignment)
--- Comment #7 from jamborm at gcc dot gnu dot org 2009-11-21 22:57 --- Subject: Bug 42025 Author: jamborm Date: Sat Nov 21 22:56:36 2009 New Revision: 154413 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154413 Log: 2009-11-21 Martin Jambor mjam...@suse.cz PR middle-end/42025 * tree-sra.c (access_precludes_ipa_sra_p): New function. (splice_param_accesses): Check all accesses by calling access_precludes_ipa_sra_p. (sra_ipa_modify_expr): Rename argument erite to dont_convert and do not convert types if it is true. (sra_ipa_modify_assign): Convert types in case of mismatch. * testsuite/gcc.c-torture/compile/pr42025-1.c: New test. * testsuite/gcc.c-torture/compile/pr42025-2.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr42025-1.c trunk/gcc/testsuite/gcc.c-torture/compile/pr42025-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42025
[Bug c++/42132] [C++0x] SFINAE failure with cv-qualifiers
--- Comment #5 from paolo dot carlini at oracle dot com 2009-11-21 23:05 --- Thanks for the analysis, Jason. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42132
[Bug fortran/42131] Weird translation of DO loops
--- Comment #6 from tkoenig at gcc dot gnu dot org 2009-11-21 23:07 ---
Created an attachment (id=19076)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19076action=view)
proposed patch
This patch generates
D.1336 = m1;
D.1337 = m2;
D.1338 = m3;
i = D.1336;
if (D.1338 0)
{
if (D.1337 D.1336) goto L.2;
}
else
{
if (D.1337 D.1336) goto L.2;
}
countm1.1 = (character(kind=4)) (D.1337 - D.1336) / (character(kind=4))
D.1338;
while (1)
{
{
Is this better, or did I overlook anything?
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug fortran/42131] Weird translation of DO loops
--- Comment #7 from rguenther at suse dot de 2009-11-21 23:23 ---
Subject: Re: Weird translation of DO loops
On Sat, 21 Nov 2009, tkoenig at gcc dot gnu dot org wrote:
--- Comment #6 from tkoenig at gcc dot gnu dot org 2009-11-21 23:07
---
Created an attachment (id=19076)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19076action=view)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19076action=view)
proposed patch
This patch generates
D.1336 = m1;
D.1337 = m2;
D.1338 = m3;
i = D.1336;
if (D.1338 0)
{
if (D.1337 D.1336) goto L.2;
}
else
{
if (D.1337 D.1336) goto L.2;
}
countm1.1 = (character(kind=4)) (D.1337 - D.1336) / (character(kind=4))
D.1338;
while (1)
{
{
Is this better, or did I overlook anything?
That's better.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug fortran/42131] Weird translation of DO loops
--- Comment #8 from tkoenig at gcc dot gnu dot org 2009-11-21 23:42 --- Subject: Re: Weird translation of DO loops On Sat, 2009-11-21 at 23:23 +, rguenther at suse dot de wrote: That's better. Not yet correct, though, this causes regressions for program main character*9 line line = ' 10 1 -3' read (unit=line,fmt='(3I3)') m1, m2, m3 print *,m1,m2,m3 do i=m1, m2, m3 print *,i end do end program main I'll have to look some more. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug middle-end/42025] [4.5 Regression] ICE verify_stmts failed (non-trivial conversion at assignment)
--- Comment #8 from jamborm at gcc dot gnu dot org 2009-11-21 23:43 --- Fixed. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42025
[Bug c++/42137] New: error: expected constructor, destructor, or type conversion before �{� token
error: expected constructor, destructor, or type conversion before { token
when compiling attached file from ppl sources with gcc 4.5.0 rev 154407
--
Summary: error: expected constructor, destructor, or type
conversion before { token
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: denis dot onischenko at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42137
[Bug c++/42137] error: expected constructor, destructor, or type conversion before �{� token
--- Comment #1 from denis dot onischenko at gmail dot com 2009-11-21 23:45 --- Created an attachment (id=19077) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19077action=view) preprocessed c++ source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42137
[Bug c++/42137] error: expected constructor, destructor, or type conversion before �{� token
--- Comment #2 from denis dot onischenko at gmail dot com 2009-11-21 23:45 --- Created an attachment (id=19078) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19078action=view) compiler output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42137
[Bug debug/42138] New: ICE on h8300 target
h8300-elf-gcc -mint32 -mh -O2 -fomit-frame-pointer -g test.c
test.c: In function 'sys_pwrite64':
test.c:19: internal compiler error: in
compute_frame_pointer_to_fb_displacement, at dwarf2out.c:12228
test.c
struct foo {
int foo;
};
struct foo *fget_light(int fd);
long sys_pwrite64(unsigned int fd, const char *buf,
int count, int pos)
{
struct foo *file;
int ret = -9;
int fput_needed;
file = fget_light(fd);
if (file-foo 16)
ret = vfs_write(file, buf, count, pos);
return ret;
}
--
Summary: ICE on h8300 target
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ysato at users dot sourceforge dot jp
GCC host triplet: x86_64-linux-gnu
GCC target triplet: h8300-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42138
[Bug fortran/41807] [4.5/4.4 Regression] data statement with nested type constructors
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2009-11-22 02:05 --- Subject: Bug 41807 Author: jvdelisle Date: Sun Nov 22 02:05:12 2009 New Revision: 154419 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154419 Log: 2009-11-21 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/41807 * gfortran.dg/data_value_1.f90: Update test. * gfortran.dg/array_constructor_32.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/array_constructor_32.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/data_value_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41807
[Bug c++/42139] New: Compiling firefox trunk with 4.5 fails with 'out of memory allocating 4072 bytes after a total of xxx bytes'
### Here's the output of compilation together with -v and -save-temps: [eh...@germany src]$ /home/ehren/gcc-4.5/dist/bin/g++ -o jsxml.o -c -I./../../dist/system_wrappers_js -include /home/ehren/mozilla-central/js/src/config/gcc_hidden.h -DOSTYPE=\Linux2.6.27.21-170.2.56.fc10\ -DOSARCH=Linux -DEXPORT_JS_API -I/home/ehren/mozilla-central/js/src -I. -I./../../dist/include -I./../../dist/include/nsprpub -I/home/ehren/mozilla-central/objdir-ff-release/dist/include/nspr -I/home/ehren/mozilla-central/js/src -fPIC -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Wno-long-long -pedantic -fno-strict-aliasing -pthread -pipe -DNDEBUG -DTRIMMED -O3 -fstrict-aliasing-DMOZILLA_CLIENT -include ./js-confdefs.h -Wp,-MD,.deps/jsxml.pp /home/ehren/mozilla-central/js/src/jsxml.cpp -v -save-temps g++: warning: -pipe ignored because -save-temps specified Using built-in specs. COLLECT_GCC=/home/ehren/gcc-4.5/dist/bin/g++ COLLECT_LTO_WRAPPER=/home/ehren/gcc-4.5/dist/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../srcdir/configure --without-libstdcxx --enable-checking --disable-bootstrap CFLAGS='-g3 -O0' --enable-languages=c,c++ --enable-__cxa_atexit --prefix=/home/ehren/gcc-4.5/dist/ Thread model: posix gcc version 4.5.0 20091122 (experimental) (GCC) COLLECT_GCC_OPTIONS='-o' 'jsxml.o' '-c' '-I./../../dist/system_wrappers_js' '-include' '/home/ehren/mozilla-central/js/src/config/gcc_hidden.h' '-DOSTYPE=Linux2.6.27.21-170.2.56.fc10' '-DOSARCH=Linux' '-DEXPORT_JS_API' '-I/home/ehren/mozilla-central/js/src' '-I.' '-I./../../dist/include' '-I./../../dist/include/nsprpub' '-I/home/ehren/mozilla-central/objdir-ff-release/dist/include/nspr' '-I/home/ehren/mozilla-central/js/src' '-fPIC' '-fno-rtti' '-fno-exceptions' '-Wall' '-Wpointer-arith' '-Woverloaded-virtual' '-Wsynth' '-Wno-ctor-dtor-privacy' '-Wno-non-virtual-dtor' '-Wcast-align' '-Wno-invalid-offsetof' '-Wno-variadic-macros' '-Wno-long-long' '-pedantic' '-pthread' '-pipe' '-DNDEBUG' '-DTRIMMED' '-O3' '-fstrict-aliasing' '-DMOZILLA_CLIENT' '-include' './js-confdefs.h' '-v' '-save-temps' '-shared-libgcc' '-mtune=generic' /home/ehren/gcc-4.5/dist/libexec/gcc/i686-pc-linux-gnu/4.5.0/cc1plus -E -quiet -v -I./../../dist/system_wrappers_js -I/home/ehren/mozilla-central/js/src -I. -I./../../dist/include -I./../../dist/include/nsprpub -I/home/ehren/mozilla-central/objdir-ff-release/dist/include/nspr -I/home/ehren/mozilla-central/js/src -D_GNU_SOURCE -D_REENTRANT -DOSTYPE=Linux2.6.27.21-170.2.56.fc10 -DOSARCH=Linux -DEXPORT_JS_API -DNDEBUG -DTRIMMED -DMOZILLA_CLIENT -include /home/ehren/mozilla-central/js/src/config/gcc_hidden.h -include ./js-confdefs.h -MD .deps/jsxml.pp /home/ehren/mozilla-central/js/src/jsxml.cpp -mtune=generic -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Wno-long-long -pedantic -fPIC -fno-rtti -fno-exceptions -fstrict-aliasing -O3 -fpch-preprocess -o jsxml.ii ignoring nonexistent directory /home/ehren/gcc-4.5/dist/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../i686-pc-linux-gnu/include ignoring nonexistent directory ./../../dist/include/nsprpub ignoring duplicate directory /home/ehren/mozilla-central/js/src #include ... search starts here: #include ... search starts here: ./../../dist/system_wrappers_js /home/ehren/mozilla-central/js/src . ./../../dist/include /home/ehren/mozilla-central/objdir-ff-release/dist/include/nspr /home/ehren/gcc-4.5/dist/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0 /home/ehren/gcc-4.5/dist/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/i686-pc-linux-gnu /home/ehren/gcc-4.5/dist/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/backward /usr/local/include /home/ehren/gcc-4.5/dist/include /home/ehren/gcc-4.5/dist/lib/gcc/i686-pc-linux-gnu/4.5.0/include /home/ehren/gcc-4.5/dist/lib/gcc/i686-pc-linux-gnu/4.5.0/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-o' 'jsxml.o' '-c' '-I./../../dist/system_wrappers_js' '-include' '/home/ehren/mozilla-central/js/src/config/gcc_hidden.h' '-DOSTYPE=Linux2.6.27.21-170.2.56.fc10' '-DOSARCH=Linux' '-DEXPORT_JS_API' '-I/home/ehren/mozilla-central/js/src' '-I.' '-I./../../dist/include' '-I./../../dist/include/nsprpub' '-I/home/ehren/mozilla-central/objdir-ff-release/dist/include/nspr' '-I/home/ehren/mozilla-central/js/src' '-fPIC' '-fno-rtti' '-fno-exceptions' '-Wall' '-Wpointer-arith' '-Woverloaded-virtual' '-Wsynth' '-Wno-ctor-dtor-privacy' '-Wno-non-virtual-dtor' '-Wcast-align' '-Wno-invalid-offsetof' '-Wno-variadic-macros' '-Wno-long-long' '-pedantic' '-pthread' '-pipe' '-DNDEBUG' '-DTRIMMED' '-O3' '-fstrict-aliasing' '-DMOZILLA_CLIENT' '-include' './js-confdefs.h' '-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
[Bug fortran/41807] [4.5/4.4 Regression] data statement with nested type constructors
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2009-11-22 02:06 --- Subject: Bug 41807 Author: jvdelisle Date: Sun Nov 22 02:06:26 2009 New Revision: 154420 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154420 Log: 2009-11-21 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/41807 * trans-const.c (gfc_conv_const): Fix typo in comment. Replace assert with error message if not constant. * resolve.c (next_data_value): Delete check for constant. Modified: trunk/gcc/fortran/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41807
[Bug fortran/41807] [4.5/4.4 Regression] data statement with nested type constructors
--- Comment #21 from jvdelisle at gcc dot gnu dot org 2009-11-22 02:10 --- Fixed on trunk. Note I inadvertently left off the PR number in the commit. It was: SendingChangeLog Sendingresolve.c Sendingtrans-const.c Transmitting file data ... Committed revision 154418. I will backport this to 4.4 in a day. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41807
[Bug c++/42139] Compiling firefox trunk with 4.5 fails with 'out of memory allocating 4072 bytes after a total of xxx bytes'
--- Comment #1 from ehren dot m at gmail dot com 2009-11-22 02:10 --- Created an attachment (id=19079) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19079action=view) jsxml.ii -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42139
[Bug ada/42140] New: GNAT appears to misbehave with limited tagged types and possibly finalization
I'm working on a small project to create an abstraction over directories and archives. I've managed to write some code that seems simple enough (using tagged limited types) and even though the code appears to be valid, it seems to either trigger bugs in the runtime (causing crashes on execution) or fails to compile: Both Debian GCC 4.3, GNAT GPL 2009 and FreeBSD GCC 4.4 fail with the following: pfseudo-archiver-directory.adb:24:41: wrong type for return_subtype_indication pfseudo-archiver-directory.adb:46:35: wrong type for return_subtype_indication GCC SVN (r154285) fails to build with a strange error: arc_dir_003.adb:25:32: _master conflicts with declaration at line 21 The output of -gnatG shows this error to be apparently incorrect: error := false; B_1 : declare _master : constant integer := system__soft_links__current_master.all; A6bM : integer renames _master; type A6b is access all pfseudo__archiver__Tarchive_tC; R7b : A6b := pfseudo__archiver__directory. The code is available here: http://git.coreland.ath.cx/gitweb.cgi?p=pfseudo/.git;a=summary $ git clone http://git.coreland.ath.cx/pfseudo/.git Configure and build with: $ echo 'gcc' conf-adacomp $ echo 'gnatbind' conf-adabind $ echo 'gnatlink' conf-adalink $ make $ make tests Here's another case from a prototype that causes a crash on GCC 4.4 but, ironically, gives every impression of compiling and running on earlier versions (4.3, GPL 2009): with Ada.Streams.Stream_IO; with Ada.Finalization; package Archiver is type Archiver_t is tagged limited private; type Archive_t is tagged limited private; function Open_Archive (Archiver : in Archiver_t; Path : in String) return Archive_t'Class; function Stream (Archive : in Archive_t) return Ada.Streams.Stream_IO.Stream_Access; private package Stream_IO renames Ada.Streams.Stream_IO; type Archiver_t is tagged limited null record; type Archive_t is new Ada.Finalization.Limited_Controlled with record Name : access String; File : Stream_IO.File_Type; end record; end Archiver; package body Archiver is function Open_Archive (Archiver : in Archiver_t; Path : in String) return Archive_t'Class is pragma Unreferenced (Archiver); begin -- This line causes a segmentation fault. return A : Archive_t'Class := Archive_t'(Ada.Finalization.Limited_Controlled with others = ) do A.Name := new String'(Path); Stream_IO.Open (Name = A.Name.all, File = A.File, Mode = Stream_IO.In_File); end return; end Open_Archive; function Stream (Archive : in Archive_t) return Ada.Streams.Stream_IO.Stream_Access is begin return Stream_IO.Stream (Archive.File); end Stream; end Archiver; with Ada.Text_IO; with Ada.Streams.Stream_IO; with Archiver; procedure Main is A : Archiver.Archiver_t; S : constant Ada.Streams.Stream_IO.Stream_Access := Archiver.Stream (Archiver.Open_Archive (A, file.zip)); X : Integer; begin X := Integer'Input (S); Ada.Text_IO.Put_Line (Integer'Image (X)); end Main; -- Summary: GNAT appears to misbehave with limited tagged types and possibly finalization Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at coreland dot ath dot cx GCC host triplet: x86_64-portbld-freebsd7.2, i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42140
[Bug ada/42140] GNAT appears to misbehave with limited tagged types and possibly finalization
--- Comment #1 from gcc at coreland dot ath dot cx 2009-11-22 05:27 --- By causes a crash above, I meant that the generated code crashes at the highlighted line. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42140
