[Bug c/34737] missed optimization, foo(p); p++ is better then foo(p++)
--- Comment #1 from wvangulik at xs4all dot nl 2008-01-11 08:17 --- Created an attachment (id=14920) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14920action=view) Test case showing the three cases Compile using -fno-line. For the AVR I used: avr-gcc -Wall -Os -fno-inline -mmcu=avr5 --save-temps main.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34737
[Bug c/34737] New: missed optimization, foo(p); p++ is better then foo(p++)
Consider the following:
char *x;
volatile int y;
void foo(char *p)
{
y += *p;
}
void main(void)
{
char *p1 = x;
foo(p1++);
foo(p1++);
foo(p1++);
foo(p1++);
foo(p1++);
foo(p1++);
foo(p1++);
foo(p1++);
foo(p1++);
foo(p1++);
}
For the AVR target this will generate ugly code. Having a double saved variable
etc.
/* prologue: frame size=0 */
push r14
push r15
push r16
push r17
/* prologue end (size=4) */
lds r24,x
lds r25,(x)+1
movw r16,r24
subi r16,lo8(-(1))
sbci r17,hi8(-(1))
call foo
movw r14,r16
sec
adc r14,__zero_reg__
adc r15,__zero_reg__
movw r24,r16
call foo
movw r16,r14
subi r16,lo8(-(1))
sbci r17,hi8(-(1))
movw r24,r14
call foo
etc..
The results gets much better when writing it like foo(p); p++;
/* prologue: frame size=0 */
push r16
push r17
/* prologue end (size=2) */
movw r16,r24
call foo
subi r16,lo8(-(1))
sbci r17,hi8(-(1))
movw r24,r16
call foo
subi r16,lo8(-(1))
sbci r17,hi8(-(1))
And the results get near optimal when using larger increments then the target
can add immediately ( 64). The compiler then adds the cumulative offset. Which
would be the most optimal case if also done for lower increments.
movw r16,r24
call foo
movw r24,r16
subi r24,lo8(-(65))
sbci r25,hi8(-(65))
call foo
movw r24,r16
subi r24,lo8(-(130))
sbci r25,hi8(-(130))
This worst behaviour is shown for 4.1.2, 4.2.2, 4.3.0
Better results (still non-optimal) are with 3.4.6 and 3.3.6.
But 4.0.4 is producing the most optimal code for the original foo(p++)
Ugly code is also being seen for arm/thumb and pdp-11.
But good code for arm/arm
So it's a multi-target problem, not just the avr!
--
Summary: missed optimization, foo(p); p++ is better then foo(p++)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wvangulik at xs4all dot nl
GCC target triplet: multiple-none-none
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34737
[Bug fortran/34722] [4.3 Regression] ICE: left-over @iostat variable polutes namespace
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-01-11 08:52 --- I am investigating. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-01-09 15:57:57 |2008-01-11 08:52:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34722
[Bug c++/34738] New: gcc fails to compile a file in the trolltech qt 4.3.0 source tree. Internal compiler error or cc1plus: out of memory allocating
Hallo, This happens when compiling file src/script/qscriptcontext_p.cpp in trolltech's qt 4.3.0 sources. gcc -c -mpowerpc -mminimal-toc -O2 -Wall -W -D_THREAD_SAFE -DQT_SHARED -DQT_BUILD_SCRIPT_LIB -DQLALR_NO_QSCRIPTGRAMMAR_DEBUG_INFO -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQ_SCRIPT_DIRECT_CODE -DQT_NO_DEBUG -DQT_CORE_LIB -I../../mkspecs/aix-g++ -I. -I../../include/QtCore -I../../include/QtCore -I../../include -I../../include/QtScript -I. -I. -o qscriptcontext_p.o qscriptcontext_p.cpp qscriptcontext_p.cpp: In member function 'void QScriptContextPrivate::execute(QScript::Code*)': qscriptcontext_p.cpp:2097: internal compiler error: Illegal instruction Using the -save-temps options causes cc1plus: out of memory allocating, which also occurred with gcc 4.2.2 which caused me to try 4.2.1: [EMAIL PROTECTED] gcc -save-temps -c -mpowerpc -mminimal-toc -O2 -Wall -W -D_THREAD_SAFE -DQT_SHARED -DQT_BUILD_SCRIPT_LIB -DQLALR_NO_QSCRIPTGRAMMAR_DEBUG_INFO -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQ_SCRIPT_DIRECT_CODE -DQT_NO_DEBUG -DQT_CORE_LIB -I../../mkspecs/aix-g++ -I. -I../../include/QtCore -I../../include/QtCore -I../../include -I../../include/QtScript -I. -I. -o qscriptcontext_p.o qscriptcontext_p.cpp cc1plus: out of memory allocating 24969464 bytes after a total of 247429368 bytes [EMAIL PROTECTED] gcc -v Using built-in specs. Target: powerpc-ibm-aix5.2.0.0 Configured with: ../gcc-4.2.1/configure --enable-version-specific-runtime-libs --enable-static --enable-shared --enable-threads --with-as=/usr/bin/as --without-gnu-ld --with-ld=/usr/bin/ld --prefix=/opt/gcc-4.2.1 --disable-nls --with-pic --disable-symvers --enable-symvers=no --enable-languages=c,c++,objc Thread model: aix gcc version 4.2.1 Where can I post the preprocessed source? It's somewhat big. thomas -- Summary: gcc fails to compile a file in the trolltech qt 4.3.0 source tree. Internal compiler error or cc1plus: out of memory allocating Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: T dot Mittelstaedt at cadenas dot de GCC build triplet: powerpc-ibm-aix5.2.0. GCC host triplet: powerpc-ibm-aix5.2.0. GCC target triplet: powerpc-ibm-aix5.2.0. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34738
[Bug target/34529] [4.1/4.2/4.3 Regression] Wrong code with altivec stores and offsets
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2008-01-11 08:57 --- Recategorizing as per Ulrich's analysis. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Component|rtl-optimization|target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34529
[Bug c++/34738] gcc fails to compile a file in the trolltech qt 4.3.0 source tree. Internal compiler error or cc1plus: out of memory allocating
--- Comment #1 from T dot Mittelstaedt at cadenas dot de 2008-01-11 08:58 --- Created an attachment (id=14921) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14921action=view) gzipped preprocessed source (was too big otherwise) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34738
[Bug c++/34738] gcc fails to compile a file in the trolltech qt 4.3.0 source tree. Internal compiler error or cc1plus: out of memory allocating
--- Comment #2 from T dot Mittelstaedt at cadenas dot de 2008-01-11 08:59 --- Created an attachment (id=14922) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14922action=view) assembly source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34738
[Bug target/34641] [4.3 Regression] ICE in reload_cse_simplify_operands, at postreload.c:395
--- Comment #8 from krebbel at gcc dot gnu dot org 2008-01-11 09:03 --- Fixed with: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00460.html -- krebbel at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34641
[Bug middle-end/28779] internal compiler error: in cgraph_estimate_size_after_inlining, at ipa-inline.c:106
--- Comment #9 from steven at gcc dot gnu dot org 2008-01-11 09:12 --- Honza, is this bug fixed by your commit of comment #8? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28779
[Bug middle-end/31529] [4.3 Regression] ICE in cgraph_expand_function with IMA
--- Comment #10 from steven at gcc dot gnu dot org 2008-01-11 09:14 --- Actually, I don't know if --combine is really that obscure. People seem to use it with some success, see e.g. http://lwn.net/Articles/197097/. Also, others seem to think IMA is importan enough to upgrade bugs to P1, see http://gcc.gnu.org/ml/gcc-bugs/2008-01/msg00995.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31529
[Bug c/34735] C99 6.7.4/3 is not diagnose
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-11 09:28 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-11 09:28:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34735
[Bug tree-optimization/34737] Inefficient gimplification of post-modified function arguments, TER doesn't do its work
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-11 09:42 ---
Confirmed.
void foo(char *p);
void test1(char * p)
{
foo(p++);
foo(p++);
foo(p++);
foo(p++);
}
void test2(char * p)
{
foo(p); p++;
foo(p); p++;
foo(p); p++;
foo(p); p++;
}
The problem is with the first variant we have two registers life over each
function call, while with the second variant only one. This can be seen
from the optimized tree-dump already:
test1 (p)
{
bb 2:
p_3 = p_1(D) + 1;
foo (p_1(D));
p_5 = p_3 + 1;
foo (p_3);
p_7 = p_5 + 1;
foo (p_5);
foo (p_7) [tail call];
return;
}
test2 (p)
{
bb 2:
foo (p_1(D));
p_2 = p_1(D) + 1;
foo (p_2);
p_3 = p_2 + 1;
foo (p_3);
p_4 = p_3 + 1;
foo (p_4) [tail call];
return;
}
and is initially caused by gimplification which produces
p.0 = p;
p = p + 1;
foo (p.0);
from
foo (p++ );
no further pass undos this transformation.
With GCC 4.0 TER produced
foo (p);
foo (p + 1B);
foo (p + 2B);
...
where we can generate good code from. From 4.1 on this is no longer done.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
Component|c |tree-optimization
Ever Confirmed|0 |1
GCC target triplet|multiple-none-none |
Keywords||missed-optimization
Last reconfirmed|-00-00 00:00:00 |2008-01-11 09:42:38
date||
Summary|missed optimization, foo(p);|Inefficient gimplification
|p++ is better then foo(p++) |of post-modified function
||arguments, TER doesn't do
||its work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34737
[Bug fortran/34556] Rejects valid with bogus error message: parameter initalization
--- Comment #3 from pault at gcc dot gnu dot org 2008-01-11 10:13 --- I have had a brief attempt to resolve this one and have driven my head against a brick wall! Starting with this development of the original testcase: ! Rejects-valid. Fails with gfortran 4.1, 4.2 and 4.3 ! For 4.3 the error message is: ! !(/ linem, nplam /) ) ! 1 !Error: Invalid character in name at (1) ! ! Found using the Fortran Company Fortran 90 Test Suite (Lite), ! Version 1.4 module splitprms integer, parameter :: nplam = 3 ! # of plans to expand TABs integer, parameter :: linem = 3 ! max. line length integer, parameter :: ncntm = 39 ! max. # cont. lines integer, parameter, dimension (linem*nplam) :: check1 = [ max ([(i, i= 1,linem), (10*i, i= 1,linem)], [(6, i= 1, 2*linem) ]), [(i, i= 1,linem)]] integer, parameter, dimension (linem, nplam) :: check2 = reshape (check1, [linem, nplam ]) integer, parameter, dimension (2) :: check3 = [linem, nplam ] ! This is OK! integer, parameter, dimension (linem, nplam) :: check4 = reshape ([ max ([(i, i= 1,linem), (10*i, i= 1,linem)], [(6, i= 1, 2*linem) ]), [(i, i= 1,linem)]], check3 ) ! This is not integer, parameter, dimension (linem, nplam) :: nxttab = reshape ([ max ([(i, i= 1,linem), (10*i, i= 1,linem)], [(6, i= 1, 2*linem) ]), [(i, i= 1,linem)]], [linem, nplam ]) ! This is the original integer, parameter, dimension (linem, nplam) :: nxttab2 = reshape ( (/max ((/(6+3*((i-6+3)/3), i= 1,linem), (6+2*((i-6+2)/2), i= 1,linem)/), (/(6, i= 1, 2*linem)/)), (/(i, i= 1,linem)/)/), (/ linem, nplam /) ) end module splitprms Resolution of the 'reshape' function is being derailed for some reason by the shape expression in gfc_simplify_reshape. However, simplifying this does not do the job but adding a gfc_simplify_expr in gfc_get_array_element fixes this problem but breaks everything else! *sigh* Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34556
[Bug libstdc++/34733] numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale
--- Comment #10 from pcarlini at suse dot de 2008-01-11 10:18 --- (In reply to comment #9) I don't agree that localeconv()-grouping is garbage just because thousands_sep is NUL. I'm not aware of anything in C or POSIX that says that. We are working on this assumption. You agreed to it, at the beginning of this thread. You agreed that, in C, a NUL as thousand separator in the localedata means no grouping in C. The grouping must be not looked at, in that case (this point is exactly what has been clarified to me, time ago, by glibc people) And that makes perfect sense, because C strings cannot have a \0 in the middle. In C, there is no meaningful way to group with \0. In the case of bg_BG, the grouping is clearly correct. What's questionable in this case is the value of thousands_sep. But that's probably just a bug in the Bulgarian locale definition. That is another, glibc, issue, probably. Bugs aside, there may be a perfectly valid locale (a user-defined one) in which there is no thsousands_sep (i.e., it's NUL) but where grouping is non-empty. It's trivial to create one as an exercise. The C++ library numpunct should be able to represent such a locale without change. Nobody disagrees with that! Maybe that was not clear in the previous messages. Of course the user can do that, in C++, and the rationale is that basic_string can have \0 in the middle. That seems obvious to me. No problem in v3, AFAIK, but any issue here it's just a bug that will be fixed ASAP. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733
[Bug middle-end/34739] Need full backport of 28796
--- Comment #3 from steven at gcc dot gnu dot org 2008-01-11 11:24 --- So where is the a testcase that you found? And why, pray tell, assign the bug to Richi instead of just trying to backport it yourself? ;-) -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34739
[Bug middle-end/34739] New: Need full backport of 28796
Found a testcase that ice's the ppc-darwin backend at -O3 -ffast-math that is
fixed by the full backport of the patches in 28796. In particular, this part:
Author: rguenth
Date: Tue Oct 24 09:15:07 2006
New Revision: 118001
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118001
Log:
2006-10-24 Richard Guenther [EMAIL PROTECTED]
PR middle-end/28796
* builtins.c (fold_builtin_classify): Use HONOR_INFINITIES
and HONOR_NANS instead of MODE_HAS_INFINITIES and MODE_HAS_NANS
for deciding optimizations in consistency with fold-const.c
(fold_builtin_unordered_cmp): Likewise.
* gcc.dg/pr28796-1.c: New testcase.
* gcc.dg/pr28796-1.c: Likewise.
Added:
trunk/gcc/testsuite/gcc.dg/pr28796-1.c
trunk/gcc/testsuite/gcc.dg/pr28796-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog
Testcase:
#include math.h
int test2(double x, double y) {
return islessgreater(x, y);
}
--
Summary: Need full backport of 28796
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: rguenth at gcc dot gnu dot org
ReportedBy: echristo at apple dot com
GCC build triplet: powerpc-darwin9
GCC host triplet: powerpc-darwin9
GCC target triplet: powerpc-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34739
[Bug c++/34738] gcc fails to compile a file in the trolltech qt 4.3.0 source tree. Internal compiler error or cc1plus: out of memory allocating
--- Comment #4 from T dot Mittelstaedt at cadenas dot de 2008-01-11 09:54 --- Sorry forgot to add contents of an earlier mail which I sent to gcc-help and gcc-bugs mailing lists, that version 4.1.1 which I downloaded from ftp.hvcc.edu (pware) and an earlier 4.1 version, which we built and which had other problems, do compile this file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34738
[Bug rtl-optimization/15482] can't find a register in class `GENERAL_REGS' while reloading `asm'
--- Comment #4 from dominiq at lps dot ens dot fr 2008-01-11 09:35 --- I see the same problem at any level of optimization I have tried on i686-apple-darwin9 for the test case gcc.target/i386/asm-3.c: [ibook-dhum] f90/bug% /opt/gcc/gcc4.3w/bin/gcc -O0 /opt/gcc/_gcc_clean/gcc/testsuite/gcc.target/i386/asm-3.c /opt/gcc/_gcc_clean/gcc/testsuite/gcc.target/i386/asm-3.c: In function 'main': /opt/gcc/_gcc_clean/gcc/testsuite/gcc.target/i386/asm-3.c:19: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' /opt/gcc/_gcc_clean/gcc/testsuite/gcc.target/i386/asm-3.c:19: error: 'asm' operand has impossible constraints The failure was present for rev. 130218 (see http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg00861.html). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15482
[Bug c++/34738] gcc fails to compile a file in the trolltech qt 4.3.0 source tree. Internal compiler error or cc1plus: out of memory allocating
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-11 09:50 --- You have not enough memory. 250MB is not unreasonable to compile this file. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34738
[Bug middle-end/34739] Need full backport of 28796
--- Comment #1 from steven at gcc dot gnu dot org 2008-01-11 11:09 --- Not a regression, so won't be fixed in 4.2. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34739
[Bug c++/34738] gcc fails to compile a file in the trolltech qt 4.3.0 source tree. Internal compiler error or cc1plus: out of memory allocating
--- Comment #5 from steven at gcc dot gnu dot org 2008-01-11 11:18 --- We should at least understand where all the memory is going. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-11 11:18:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34738
[Bug middle-end/34739] Need full backport of 28796
--- Comment #2 from echristo at apple dot com 2008-01-11 11:19 --- Doesn't ice under 4.0 so it is a regression. -- echristo at apple dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34739
[Bug middle-end/34739] Need full backport of 28796
--- Comment #4 from echristo at apple dot com 2008-01-11 11:26 --- It's in the bug and I have assignment issues currently and he asked me to? -- echristo at apple dot com changed: What|Removed |Added Last reconfirmed|-00-00 00:00:00 |2008-01-11 11:26:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34739
[Bug middle-end/34739] Need full backport of 28796
--- Comment #7 from echristo at apple dot com 2008-01-11 11:48 --- Created an attachment (id=14923) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14923action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34739
[Bug tree-optimization/34737] Scheduling of post-modified function arguments is not good
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-11 11:33 --- No what happened with 4.0 is rather DOM would prop x+1 for each x. Really this comes down to scheduling of instructions and moving them closer to their usage. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.0.4 | Summary|Inefficient gimplification |Scheduling of post-modified |of post-modified function |function arguments is not |arguments, TER doesn't do |good |its work| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34737
[Bug middle-end/34739] Need full backport of 28796
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-01-11 11:38 --- Preprocessed source? The testcase listed here is not going to show the issue on most targets anyways. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34739
[Bug middle-end/34732] Optimization flag trigger unexpected crash
--- Comment #6 from ijeukens at yahoo dot com dot br 2008-01-11 11:43 --- Not a bug (wrong variable type (int instead of size_t) triggered strange behavior. -- ijeukens at yahoo dot com dot br changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34732
[Bug middle-end/34739] Need full backport of 28796
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-01-11 11:48 --- (In reply to comment #4) It's in the bug and I have assignment issues currently and he asked me to? You mean Apple has issues, not you technically and legally IIRC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34739
[Bug c++/34738] gcc fails to compile a file in the trolltech qt 4.3.0 source tree. Internal compiler error or cc1plus: out of memory allocating
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-11 13:09 --- Created an attachment (id=14924) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14924action=view) uninclude -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34738
[Bug c++/34738] gcc fails to compile a file in the trolltech qt 4.3.0 source tree. Internal compiler error or cc1plus: out of memory allocating
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-11 13:09 --- The preprocessed testcase is useless, nobody has ppc-aix5 available. Please strip system includes with 'uninclude'. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34738
[Bug middle-end/30905] [4.3 Regression] Fails to cross-jump
--- Comment #10 from zadeck at naturalbridge dot com 2008-01-11 13:15 --- stevens patch bootstrapped and regression tested on x86-86, ppc-32 and ia-64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30905
[Bug c++/34738] gcc fails to compile a file in the trolltech qt 4.3.0 source tree. Internal compiler error or cc1plus: out of memory allocating
--- Comment #10 from T dot Mittelstaedt at cadenas dot de 2008-01-11 14:10 --- A colleague just told me, that aix only gives an application 256 MB memory except if you set a certain environment variable (don't know yet) or specify something like -Wl,-bmaxdata:0x8000 to the linker. Where could I set this for configure so that it propagates down. Then I can test if it works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34738
[Bug middle-end/30905] [4.3 Regression] Fails to cross-jump
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-01-11 14:56 --- Subject: Bug 30905 Author: rguenth Date: Fri Jan 11 14:55:34 2008 New Revision: 131468 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131468 Log: 2008-01-11 Steven Bosscher [EMAIL PROTECTED] PR rtl-optimization/30905 * cfgcleanup.c: Include dce.h (crossjumps_occured): New global variable. (try_crossjump_bb): Exit loop after finding a fallthru edge. If something changed, set crossjumps_occured to true. (try_optimize_cfg): Clear crossjumps_occured at the beginning. Don't add/remove fake edges to exit here... (cleanup_cfg): ...but do it here, when crossjumping. Run a fast DCE when successful crossjumps occured in the latest iteration of try_optimize_cfg. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgcleanup.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30905
[Bug c++/34738] gcc fails to compile a file in the trolltech qt 4.3.0 source tree. Internal compiler error or cc1plus: out of memory allocating
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-01-11 14:51 --- 4.0: 448376 kB 4.1: 424788 kB 4.2: 512644 kB 4.3: 249496 kB I don't have a 64bit 3.4 compiler and 3.3 doesn't grasp the C++ used. Nothing obvious from the 4.3 numbers, the CU looks simply large: parser: 1.19 ( 6%) usr 0.47 (34%) sys 1.59 ( 8%) wall 75754 kB (39%) ggc integration : 0.18 ( 1%) usr 0.03 ( 2%) sys 0.19 ( 1%) wall 16649 kB ( 9%) ggc expand: 1.01 ( 5%) usr 0.02 ( 1%) sys 1.10 ( 6%) wall 10792 kB ( 6%) ggc PRE : 1.52 ( 8%) usr 0.02 ( 1%) sys 1.51 ( 8%) wall 536 kB ( 0%) ggc TOTAL : 18.47 1.3819.87 192736 kB I'll declare it fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Keywords||memory-hog Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34738
[Bug middle-end/34743] New: Testcase gcc.dg/tree-ssa/20070302-1.c is broken
The test stopped testing what it's supposed to test. The call to function baz() should not be inlined. This patch to the test exposes the failure. The operand scanner is adding non-clobbered symbols to the call site. Details at http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00477.html -- Summary: Testcase gcc.dg/tree-ssa/20070302-1.c is broken Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: middle-end AssignedTo: dnovillo at gcc dot gnu dot org ReportedBy: dnovillo at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34743
[Bug fortran/34742] New: Document the kind of integer passed for string lengths
As requested on the mailing list: Document the kind of integer passed for string lengths http://gcc.gnu.org/ml/fortran/2008-01/msg00134.html | The character length variables you mention are always (for gfortran) | 32-bit integer signed variables, so if you need to address them in | gfortran, you can use either integer(kind=4) or, in C99, int32_t | (found in header inttypes.h). -- Summary: Document the kind of integer passed for string lengths Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: documentation Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34742
[Bug middle-end/32135] [4.3 Regression] bogus array-ref fold triggering array overflow warning
--- Comment #4 from hubicka at gcc dot gnu dot org 2008-01-11 15:25 ---
I am testing the attached patch. It disables the transformation and produce:
in_cols.0 = (char *) in_cols;
D.1180 = in_cols.0 + 500;
perhaps more canonical way would be
in_cols.0 = in_cols + 500;
d.1180 = (char *)in_cost.0
or for nonzero offset in the second index
in_cols.0 = in_cols + 500;
d.1180 = in_cost.0[nonzero_offset];
But it would need maybe_fold... to produce non-gimple or we would need to do
the transform in gimplifier itself.
Honza
Index: tree-ssa-ccp.c
===
--- tree-ssa-ccp.c (revision 131461)
+++ tree-ssa-ccp.c (working copy)
@@ -1588,6 +1588,7 @@ maybe_fold_offset_to_array_ref (tree bas
{
tree min_idx, idx, idx_type, elt_offset = integer_zero_node;
tree array_type, elt_type, elt_size;
+ tree domain_type;
/* If BASE is an ARRAY_REF, we can pick up another offset (this time
measured in units of the size of elements type) from that ARRAY_REF).
@@ -1659,9 +1660,10 @@ maybe_fold_offset_to_array_ref (tree bas
low bound, if any, convert the index into that type, and add the
low bound. */
min_idx = build_int_cst (idx_type, 0);
- if (TYPE_DOMAIN (array_type))
+ domain_type = TYPE_DOMAIN (TREE_TYPE (base));
+ if (domain_type)
{
- idx_type = TYPE_DOMAIN (array_type);
+ idx_type = domain_type;
if (TYPE_MIN_VALUE (idx_type))
min_idx = TYPE_MIN_VALUE (idx_type);
else
@@ -1681,6 +1683,24 @@ maybe_fold_offset_to_array_ref (tree bas
/* Make sure to possibly truncate late after offsetting. */
idx = fold_convert (idx_type, idx);
+ /* We don't want to construct access past array bounds. For example
+ char *(c[4]);
+
+ c[3][2]; should not be simplified into (*c)[14] or tree-vrp will give
false
+ warning. */
+ if (domain_type TYPE_MAX_VALUE (domain_type)
+ TREE_CODE (TYPE_MAX_VALUE (domain_type)) == INTEGER_CST)
+{
+ tree up_bound = TYPE_MAX_VALUE (domain_type);
+
+ if (tree_int_cst_lt (up_bound, idx)
+ /* Accesses after the end of arrays of size 0 (gcc
+extension) and 1 are likely intentional (struct
+hack). */
+ || compare_tree_int (up_bound, 1) 0)
+ return NULL_TREE;
+}
+
return build4 (ARRAY_REF, elt_type, base, idx, NULL_TREE, NULL_TREE);
}
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2008-01-11 14:12:54 |2008-01-11 15:25:44
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32135
[Bug c++/34052] [4.3 regression] Trouble with variadic templates as template-template parameter
--- Comment #5 from dgregor at gcc dot gnu dot org 2008-01-11 15:24 --- Amusingly enough (since this is the second time this has happened today), this problem occurs both with and without variadic templates. The following code is ill-formed according to C++98, but GCC accepts it: templatetemplatetypename T = int, typename U class C struct X; I'm working on a fix for both issues. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34052
[Bug fortran/34741] New: Bounds-check of array-pointer == [ constructor ]
The following out-of-bounds problem (in the if clause) is not detected:
character, pointer :: ptr(:)
allocate(ptr(9))
ptr = transfer('Sample#0'//achar(0),ptr) ! Causes ICE
if (any (ptr .ne. ['S','a','m','p','l','e','#','0'])) call abort
end
NAG f95 finds:
Rank 1 of array operand has extent 9 instead of 8
--
Summary: Bounds-check of array-pointer == [ constructor ]
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34741
[Bug middle-end/34743] Testcase gcc.dg/tree-ssa/20070302-1.c is broken
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-11 15:57 ---
It's doing the correct thing. We have
p_1, name memory tag: NMT.14, is dereferenced, points-to vars: { SFT.3 SFT.7 }
(SFT.3 is x.x, SFT.7 is z.x)
Now, NMT.14 is marked call clobbered:
NMT.14, UID D.1582, struct A, is addressable, score: 40, direct reads: 2,
direct writes: 1, indirect reads: 0, indirect writes: 2, call clobbered (passed
to call), may aliases: { SFT.3 SFT.7 }
because one of its pointed-to vars is call clobbered (SFT.7, aka z, which is
passed to the call). Here:
static void
compute_tag_properties (void)
{
...
EXECUTE_IF_SET_IN_BITMAP (ma, 0, i, bi)
{
entry = referenced_var (i);
/* Call clobbered entries cause the tag to be marked
call clobbered. */
if (!tagcc is_call_clobbered (entry))
{
mark_call_clobbered (tag, var_ann (entry)-escape_mask);
tagcc = true;
changed = true;
}
I don't know if we can disable this if var_ann (entry)-escape_mask ==
ESCAPE_TO_CALL.
I don't know if we need to propagate tags from NMT aliases to the NMT
this way at all - after all we add all subvars of an escaped var to
call clobbered vars already.
So, confirmed - there's a missing optimization.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||alias, missed-optimization
Last reconfirmed|-00-00 00:00:00 |2008-01-11 15:57:57
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34743
[Bug middle-end/30905] [4.3 Regression] Fails to cross-jump
--- Comment #14 from steven at gcc dot gnu dot org 2008-01-11 15:09 --- Whee, thanks Kenny and Richi!!! Zapp... -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30905
[Bug middle-end/31529] [4.3 Regression] ICE in cgraph_expand_function with IMA
--- Comment #11 from hubicka at gcc dot gnu dot org 2008-01-11 15:39 --- The problem here is really how we handle extern inline functions redefining non-extern inline functions. What forntend does is to handle all extern inline or extern functions of same name in all units as single functions. It always rewrite in place the declaration by last body seen. Within single unit we allow transition from extern inline with definition to non-extern inline deinition by resetting the node and disabling inline. This is already ugly and gets worse with IMA: here we transit from non-extern inline to inline killing the non-extern inline body before cgraph has chance to output it. This is simply wrong, since we must output it. If someone gets C frontend to handle extern inline functions by assigning them separate DECLs different in each source unit (ideally as static inline would get) and different from DECL of non-extern inline. I can add simple cgraph API to associate extern inline variant with the offline body for purposes of inlining. Then we can behave sanely: use extern inline body when inlining and non-extern inline body when outputting the offline function. Current scheme where all extern inline functions are disabled from inlining in IMA or where we ICE as now is simply nonsense. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31529
[Bug c++/33964] [4.3 Regression] internal compiler error: in dependent_type_p, at cp/pt.c:15319 (vararg templates)
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-01-11 14:11 ---
This code is ill-formed, and should be rejected because Args cannot be
deduced from typename Args::is_applied. Interestingly enough, this problem
actually has nothing to do with variadic templates: take away the parameter
pack and we still accept this ill-formed code:
templatetypename T
struct ugh {};
templatetypename T struct ughtypename T::is_applied { };
The problem is that, when we're marking template parameters in
process_partial_specialization via for_each_template_parm, we mark *all*
template parameters, not just those that are in deduced contexts. I'm working
on a fix now...
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Keywords|ice-on-invalid-code |accepts-invalid
Last reconfirmed|2007-11-19 04:44:27 |2008-01-11 14:11:27
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33964
[Bug fortran/34740] New: -fbounds-check with TRANSFER misses out of bounds in array assignment
For the following program, I expect an out-of-bounds error; NAG f95 shows at
run time:
Rank 1 of array operand has extent 7 instead of 8
character, pointer :: ptr(:)
allocate(ptr(8))
ptr = transfer('Sample'//achar(0),ptr)
end
--
Summary: -fbounds-check with TRANSFER misses out of bounds in
array assignment
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34740
[Bug middle-end/30905] [4.3 Regression] Fails to cross-jump
--- Comment #12 from stevenb dot gcc at gmail dot com 2008-01-11 13:48 --- Subject: Re: [4.3 Regression] Fails to cross-jump Richi, could you commit it for me? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30905
[Bug c++/34691] [4.1/4.2/4.3 Regression] Default argument checking not performed after overload resolution with C linkage
--- Comment #3 from jakub at gcc dot gnu dot org 2008-01-11 14:01 ---
What about:
namespace A {
extern C int g (double);
}
namespace B {
extern C int g (int);
}
using namespace A;
using namespace B;
void f ()
{
g (1.0);
}
I don't believe this is valid, as extern C means there is just one g, yet it
is accepted.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34691
[Bug tree-optimization/33826] [4.1/4.2/4.3 Regression] GCC generates wrong code for infinitely recursive functions
--- Comment #19 from zadeck at naturalbridge dot com 2008-01-11 13:09 --- Subject: Re: [4.1/4.2/4.3 Regression] GCC generates wrong code for infinitely recursive functions ghazi at gcc dot gnu dot org wrote: --- Comment #18 from ghazi at gcc dot gnu dot org 2008-01-11 03:57 --- Thanks Kenny, patch posted here: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00445.html ok to commit. kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33826
[Bug libstdc++/34626] Header constructors_destructor_fn_imps.hpp not found on AIX 5.3/IBM PPC
--- Comment #9 from T dot Mittelstaedt at cadenas dot de 2008-01-11 12:55 --- (In reply to comment #7) I have just tried to compile after detarring with GNU tar 1.19, and it compiled succesfully! Therefore the problem was a depackaging bug in an older version of tar. I'll contact Gregoire Avot to compare our configs, but this might be a common issue. You might want to add this fact in the http://gcc.gnu.org/install/specific.html#x-ibm-aix section, as GNU tar 1.13 was widely distributed by IBM in AIX. Ran into this thing too. Should really be in http://gcc.gnu.org/install/specific.html#x-ibm-aix section. Just checked the page -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34626
[Bug middle-end/30905] [4.3 Regression] Fails to cross-jump
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-01-11 13:41 --- The patch is ok. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30905
[Bug middle-end/28779] internal compiler error: in cgraph_estimate_size_after_inlining, at ipa-inline.c:106
--- Comment #10 from aldot at gcc dot gnu dot org 2008-01-11 13:30 ---
Still fails for me on trunk (revision 131461):
gcc-4.3-HEAD -Os --combine -c -o pr28779.o pr28779a.c pr28779b.c
pr28779b.c: In function 'e1000_write_reg_io':
pr28779b.c:12: internal compiler error: in cgraph_estimate_size_after_inlining,
at ipa-inline.c:188
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
$ cat pr28779a.c
/* PR middle-end/28779 */
/* { dg-do compile } */
/* { dg-options --combine -Os } */
/* { dg-additional-sources pr28779b.c } */
struct e1000_hw { };
void e1000_io_write(struct e1000_hw *hw, unsigned long port, unsigned int
value);
void e1000_write_reg_io(struct e1000_hw *hw, unsigned int offset)
{ unsigned long io_addr; e1000_io_write(hw, io_addr, offset); }
int e1000_reset_hw(struct e1000_hw *hw) { e1000_write_reg_io((hw), 0x0); }
$ cat pr28779b.c
/* Additional file for PR middle-end/28779 */
struct pci_device_id { };
struct pci_dev { };
struct pci_driver
{ int (*probe) (struct pci_dev *dev, const struct pci_device_id *id); };
struct e1000_hw { };
int e1000_probe(struct pci_dev *pdev, const struct pci_device_id *ent);
struct pci_driver e1000_driver = { .probe = e1000_probe };
int e1000_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
{ struct e1000_hw *adapter; e1000_reset_hw(adapter); }
void e1000_io_write(struct e1000_hw *hw, unsigned long port, unsigned int
value)
{ }
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
CC||aldot at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28779
[Bug libstdc++/34733] numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale
--- Comment #12 from sebor at roguewave dot com 2008-01-11 15:59 --- (In reply to comment #11) [...] So while I agree that NUL thousands_sep means no grouping to stdio and to iostreams in C++, I should clarify that in C++ it means that only if the NUL comes from libc (e.g., via localeconv), but not from a user-defined numpunct facet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733
[Bug middle-end/34743] Testcase gcc.dg/tree-ssa/20070302-1.c is broken
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-11 16:39 --- We even mark all pointed-to vars of value-escaping pointers as call-clobbered. So I believe NMTs itself need never be call-clobbered. But there's also hints that we cover bugs somewhere: FIXME: This is not quite right. They should only be clobbered if value_escapes_p is true, regardless of whether they point to global memory or not. So removing this code and fixing all the bugs would be nice. It is the cause of a bunch of clobbering. */ Also it is not at all clear to me what MTAG_GLOBAL is all about (and its appearant relation to call clobbered state). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34743
[Bug libstdc++/34733] numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale
--- Comment #11 from sebor at roguewave dot com 2008-01-11 15:56 --- I think the disconnect might be in how each of us is looking at the LC_NUMERIC data. To me, it's just a bunch of values that are independent of one another. You, OTOH, seem to view it more as a set of rules described by the data (if thousands_sep == NUL then grouping doesn't matter). The reason why I don't look at it that way is because I think the rules for the interpretation of the data are separate from the data: in C they are in sprintf and C++ in num_put. So while I agree that NUL thousands_sep means no grouping to stdio and to iostreams in C++, it's just one possible interpretation of the data for the specific purposes of the two libraries. There are other possible and equally valid interpretations/rules that can be drawn from it (e.g., in third party code). Finally, I'm not suggesting or even hoping that anything be done about this in libstdc++ ASAP, or necessarily at any point. I mostly just wanted to make a record of the issue (whether you consider it valid or not) and get your perspective on it, that's all :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733
[Bug middle-end/28779] internal compiler error: in cgraph_estimate_size_after_inlining, at ipa-inline.c:106
--- Comment #12 from aldot at gcc dot gnu dot org 2008-01-11 15:21 --- Honza, the IPA pass reordering also caused PR31529, perhaps they are related? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28779
[Bug c++/34738] gcc fails to compile a file in the trolltech qt 4.3.0 source tree. Internal compiler error or cc1plus: out of memory allocating
--- Comment #8 from T dot Mittelstaedt at cadenas dot de 2008-01-11 13:19 --- Created an attachment (id=14925) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14925action=view) preprocessed source stripped of system includes via uninclude -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34738
[Bug middle-end/34739] [4.2 Regression] Need full backport of 28796
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |ASSIGNED Ever Confirmed|0 |1 Known to work||4.0.3 4.3.0 Last reconfirmed|2008-01-11 11:26:22 |2008-01-11 12:15:31 date|| Summary|Need full backport of 28796 |[4.2 Regression] Need full ||backport of 28796 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34739
[Bug fortran/34537] ICE or wrong code for TRANSFER of constant string to character
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-11 14:21 --- Paul's patch (approved): http://gcc.gnu.org/ml/fortran/2008-01/msg00131.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34537
[Bug libstdc++/34730] Legal program doesn't compile with -D_GLIBCXX_DEBUG
--- Comment #5 from bkoz at gcc dot gnu dot org 2008-01-11 18:05 --- Paolo, as a quick aside, you might find it useful to look at the concept GCC library sources for stuff like this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34730
[Bug tree-optimization/34683] SSA rewriting in the loop unroller causes quadratic behavior
--- Comment #47 from rguenth at gcc dot gnu dot org 2008-01-11 13:29 --- Most of the PRE/FRE memory is spent in copied VOPs VECs. Unfortunately we cannot move them to heap memory easily as the get shared in the PRE tables... I tried to be explicit in managing the memory, but it gets really hard (which is probably the reason we stick it in GC memory in the first place). So we could use two variants of all routines, one using GC allocated VECs and one using heap allocated VECs and use the GC allocated one only for the final SCC iteration and the PRE tables. Smells like a task for C++ templates or a really ugly hack in C. Obviously this is not going to happen for 4.3 :/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug middle-end/32135] [4.3 Regression] bogus array-ref fold triggering array overflow warning
-- hubicka at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-05-29 09:21:36 |2008-01-11 14:12:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32135
[Bug middle-end/28779] internal compiler error: in cgraph_estimate_size_after_inlining, at ipa-inline.c:106
--- Comment #11 from hubicka at ucw dot cz 2008-01-11 14:04 --- Subject: Re: internal compiler error: in cgraph_estimate_size_after_inlining, at ipa-inline.c:106 The bug re-appeared due to yet another reorganization of IPA pass queue. The issues with function changing their types are quite ugly, I am looking into that now. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28779
[Bug fortran/34722] [4.3 Regression] ICE: left-over @iostat variable polutes namespace
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-01-11 21:16 --- Subject: Bug 34722 Author: jvdelisle Date: Fri Jan 11 21:15:41 2008 New Revision: 131475 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131475 Log: 2008-01-11 Jerry DeLisle [EMAIL PROTECTED] PR fortran/34722 * trans-io.c (create_dummy_iostat): Commit the symbol. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-io.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34722
[Bug fortran/34722] [4.3 Regression] ICE: left-over @iostat variable polutes namespace
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2008-01-11 21:18 --- Subject: Bug 34722 Author: jvdelisle Date: Fri Jan 11 21:18:10 2008 New Revision: 131476 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131476 Log: 2008-01-11 Jerry DeLisle [EMAIL PROTECTED] PR fortran/34722 * gfortran.dg//inquire_12.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/inquire_12.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34722
[Bug fortran/34722] [4.3 Regression] ICE: left-over @iostat variable polutes namespace
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2008-01-11 21:20 --- Fixed on trunk. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34722
[Bug inline-asm/33932] miscalculation of asm labels with -g3
--- Comment #6 from mmitchel at gcc dot gnu dot org 2008-01-11 21:23 --- I do think this is a bug. It's certainly not going to meet user expectations. I think this is another case of a GCC extension that could have been better-designed. If we were starting from scratch, I think saying that an asm defaults to the text section, unless it has an explicit section attribute, would be a good thing. But, I don't think we can change this now; there is definitely code out there that depends on switching sections and then emitting an asm. But, we could make sure that we always pop back from the debug section to whatever the preceding section was after emitting debug information. That seems reasonable to me, as I don't think people are trying to implicitly put stuff into the debug section. (If they want to do that, they explicitly use a .section directive.) That would fix this case and probably avoid the problem in general. We could also add the ability to use __attribute__((section)) with an asm, like so: __attribute__((section (.text))) asm (...); with the semantics that we would enter that section, emit the asm, and then pop back to whatever section we had before. That would give users a natural way to specify what section an asm goes into, without having to put .section directives in the asm itself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33932
[Bug target/34637] ICE in rws_insn_set, at config/ia64/ia64.c:5335
--- Comment #3 from wilson at gcc dot gnu dot org 2008-01-11 21:23 --- The ia64 code to insert stop bits has a built-in assumption that if we see a register set twice in the same instruction, then we goofed, and must ICE. The testcase has an extended asm with 3 outputs and 4 inputs. None of the outputs are used after the asm. The register allocator decided to assign two of the outputs to the same hard register which is OK if they are never used. But they are used inside the asm, so this won't work. If I mark the outputs as early clobber, i.e. change : =r (compare_value) , =r (exchange_value) , =r (sum) to : =r (compare_value) , =r (exchange_value) , =r (sum) Then there is no ICE, and I also get correct code. So we need to fix the asm at a minimum. It doesn't appear to be from gcc code. We might also need to fix the ia64 backend to allow the same reg to be written twice by the same insn, since it can occur as this testcase shows. Though this testcase is broken, there might be some valid way that this can occur. Maybe just allowing this for asms is OK. Or maybe just emitting a friendlier error message here is OK. That was for mainline. I checked the gcc-4.1 branch, and this is the same problem, except that all 3 outputs got assigned to the same hard register. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-11 21:23:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34637
[Bug fortran/32489] Endless loop when compiling
--- Comment #4 from pault at gcc dot gnu dot org 2008-01-11 19:12 --- (In reply to comment #3) Breaking up the expression for h1, thusly: hh = (/(exp(-2*pi*(0,1)*mod(k*L,N)/N)*h2(L),L=0,N-1)/) h1 = (/(sum(hh),k=0,N-1)/) cures the problem. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32489
[Bug libfortran/34670] bounds checking for array intrinsics
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-01-11 20:21 --- Subject: Bug 34670 Author: tkoenig Date: Fri Jan 11 20:21:05 2008 New Revision: 131473 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131473 Log: 2008-01-11 Thomas Koenig [EMAIL PROTECTED] PR libfortran/34670 * m4/iparm.m4 (upcase): New macro (copied from the m4 manual). (u_name): New macro for the upper case name of the intrinsic. * m4/iforeach.m4 (name`'rtype_qual`_'atype_code): Add bounds checking and rank check, depending on compile_options.bounds_check. (`m'name`'rtype_qual`_'atype_code): Likewise. (`s'name`'rtype_qual`_'atype_code): Likewise. * m4/ifunction.m4 (name`'rtype_qual`_'atype_code): Add bounds checking and rank check, depending on compile_options.bounds_check. (`m'name`'rtype_qual`_'atype_code): Likewise. (`s'name`'rtype_qual`_'atype_code): Likewise. * generated/all_l16.c: Regenerated. * generated/all_l4.c: Regenerated. * generated/all_l8.c: Regenerated. * generated/any_l16.c: Regenerated. * generated/any_l4.c: Regenerated. * generated/any_l8.c: Regenerated. * generated/count_16_l16.c: Regenerated. * generated/count_16_l4.c: Regenerated. * generated/count_16_l8.c: Regenerated. * generated/count_4_l16.c: Regenerated. * generated/count_4_l4.c: Regenerated. * generated/count_4_l8.c: Regenerated. * generated/count_8_l16.c: Regenerated. * generated/count_8_l4.c: Regenerated. * generated/count_8_l8.c: Regenerated. * generated/maxloc0_16_i1.c: Regenerated. * generated/maxloc0_16_i16.c: Regenerated. * generated/maxloc0_16_i2.c: Regenerated. * generated/maxloc0_16_i4.c: Regenerated. * generated/maxloc0_16_i8.c: Regenerated. * generated/maxloc0_16_r10.c: Regenerated. * generated/maxloc0_16_r16.c: Regenerated. * generated/maxloc0_16_r4.c: Regenerated. * generated/maxloc0_16_r8.c: Regenerated. * generated/maxloc0_4_i1.c: Regenerated. * generated/maxloc0_4_i16.c: Regenerated. * generated/maxloc0_4_i2.c: Regenerated. * generated/maxloc0_4_i4.c: Regenerated. * generated/maxloc0_4_i8.c: Regenerated. * generated/maxloc0_4_r10.c: Regenerated. * generated/maxloc0_4_r16.c: Regenerated. * generated/maxloc0_4_r4.c: Regenerated. * generated/maxloc0_4_r8.c: Regenerated. * generated/maxloc0_8_i1.c: Regenerated. * generated/maxloc0_8_i16.c: Regenerated. * generated/maxloc0_8_i2.c: Regenerated. * generated/maxloc0_8_i4.c: Regenerated. * generated/maxloc0_8_i8.c: Regenerated. * generated/maxloc0_8_r10.c: Regenerated. * generated/maxloc0_8_r16.c: Regenerated. * generated/maxloc0_8_r4.c: Regenerated. * generated/maxloc0_8_r8.c: Regenerated. * generated/maxloc1_16_i1.c: Regenerated. * generated/maxloc1_16_i16.c: Regenerated. * generated/maxloc1_16_i2.c: Regenerated. * generated/maxloc1_16_i4.c: Regenerated. * generated/maxloc1_16_i8.c: Regenerated. * generated/maxloc1_16_r10.c: Regenerated. * generated/maxloc1_16_r16.c: Regenerated. * generated/maxloc1_16_r4.c: Regenerated. * generated/maxloc1_16_r8.c: Regenerated. * generated/maxloc1_4_i1.c: Regenerated. * generated/maxloc1_4_i16.c: Regenerated. * generated/maxloc1_4_i2.c: Regenerated. * generated/maxloc1_4_i4.c: Regenerated. * generated/maxloc1_4_i8.c: Regenerated. * generated/maxloc1_4_r10.c: Regenerated. * generated/maxloc1_4_r16.c: Regenerated. * generated/maxloc1_4_r4.c: Regenerated. * generated/maxloc1_4_r8.c: Regenerated. * generated/maxloc1_8_i1.c: Regenerated. * generated/maxloc1_8_i16.c: Regenerated. * generated/maxloc1_8_i2.c: Regenerated. * generated/maxloc1_8_i4.c: Regenerated. * generated/maxloc1_8_i8.c: Regenerated. * generated/maxloc1_8_r10.c: Regenerated. * generated/maxloc1_8_r16.c: Regenerated. * generated/maxloc1_8_r4.c: Regenerated. * generated/maxloc1_8_r8.c: Regenerated. * generated/maxval_i1.c: Regenerated. * generated/maxval_i16.c: Regenerated. * generated/maxval_i2.c: Regenerated. * generated/maxval_i4.c: Regenerated. * generated/maxval_i8.c: Regenerated. * generated/maxval_r10.c: Regenerated. * generated/maxval_r16.c: Regenerated. * generated/maxval_r4.c: Regenerated. * generated/maxval_r8.c: Regenerated. * generated/minloc0_16_i1.c: Regenerated. * generated/minloc0_16_i16.c: Regenerated. * generated/minloc0_16_i2.c: Regenerated. * generated/minloc0_16_i4.c: Regenerated. *
[Bug fortran/33037] TRANSFER should warn on mismatched sizes
--- Comment #9 from burnus at gcc dot gnu dot org 2008-01-11 14:02 ---
For the following ill-defined program, also a warning should be printed. It
comes from PR 34537 and had before an ICE. NAG f95 prints Intrinsic TRANSFER
has partly undefined result.
program main
implicit none
character(len=8), target :: t
character(len=8), pointer :: p
p = t
call test(p)
print *, t
contains
subroutine test(a)
character(len=8),pointer :: a
a = transfer('Sample',a)
end subroutine test
end program main
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33037
[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel
--- Comment #29 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-11 21:29 --- Subject: Re: [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel Eric, More precisely the QTY is changed after the reg has been entered with a hash. This is expected, but the reg must be removed from the table. The problem here is that the reg is a pseudo and has been entered twice, for SImode and DImode, but is only removed once. Tentative fix to be attached. I believe that you have solved the problem. I did a quick cross build on hppa-unknown-linux-gnu with your change on the trunk and it fixed the endless loop. I'm now doing a regular bootstrap and check. Thanks, Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944
[Bug target/26015] [4.1/4.2/4.3 Regression] ICE during bootstrap for vax architecture
--- Comment #10 from wilson at gcc dot gnu dot org 2008-01-11 21:42 --- Subject: Bug 26015 Author: wilson Date: Fri Jan 11 21:42:03 2008 New Revision: 131477 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131477 Log: PR target/26015 * config/vax/elf.h (FRAME_POINTER_CFA_OFFSET): Define. Modified: trunk/gcc/ChangeLog trunk/gcc/config/vax/elf.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26015
[Bug target/26015] [4.1/4.2/4.3 Regression] ICE during bootstrap for vax architecture
--- Comment #12 from wilson at gcc dot gnu dot org 2008-01-11 21:52 --- Fixed on mainline. -- wilson at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26015
[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel
--- Comment #27 from ebotcazou at gcc dot gnu dot org 2008-01-11 18:09 --- Obviously, the problem is that the hash of reg 66 is changed after a hash table element is created for it in the bucket for the original hash. I have no idea yet whether this is expected, or if not, what is going wrong. More precisely the QTY is changed after the reg has been entered with a hash. This is expected, but the reg must be removed from the table. The problem here is that the reg is a pseudo and has been entered twice, for SImode and DImode, but is only removed once. Tentative fix to be attached. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944
[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel
--- Comment #28 from ebotcazou at gcc dot gnu dot org 2008-01-11 18:09 --- Created an attachment (id=14927) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14927action=view) Lightly tested fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944
[Bug middle-end/31309] [4.1/4.2/4.3 regression] reads/writes past end of structure
--- Comment #20 from ebotcazou at gcc dot gnu dot org 2008-01-11 19:45 --- Subject: Bug 31309 Author: ebotcazou Date: Fri Jan 11 19:44:40 2008 New Revision: 131472 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131472 Log: PR middle-end/31309 * expr.c (copy_blkmode_from_reg): Use a mode suited to the size when copying to memory. Added: trunk/gcc/testsuite/gcc.dg/struct-ret-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31309
[Bug middle-end/31309] [4.1/4.2 regression] reads/writes past end of structure
--- Comment #21 from ebotcazou at gcc dot gnu dot org 2008-01-11 19:47 --- Fixed on the mainline. I'm not sure we want to put this on the other branches. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|ebotcazou at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||01/msg00437.html Status|ASSIGNED|NEW Known to fail|4.0.4 4.1.2 4.2.0 4.3.0 |4.0.4 4.1.2 4.2.0 Summary|[4.1/4.2/4.3 regression]|[4.1/4.2 regression] |reads/writes past end of|reads/writes past end of |structure |structure Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31309
[Bug fortran/34537] ICE or wrong code for TRANSFER of constant string to character
--- Comment #4 from pault at gcc dot gnu dot org 2008-01-11 18:26 --- Subject: Bug 34537 Author: pault Date: Fri Jan 11 18:25:29 2008 New Revision: 131470 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131470 Log: 2008-01-11 Paul Thomas [EMAIL PROTECTED] PR fortran/34537 * simplify.c (gfc_simplify_transfer): Return NULL if the size of the element is unavailable and only assign character length to the result, if 'mold' is constant. 2008-01-11 Paul Thomas [EMAIL PROTECTED] PR fortran/34537 * gfortran.dg/transfer_simplify_8.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/transfer_simplify_8.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34537
[Bug fortran/34537] ICE or wrong code for TRANSFER of constant string to character
--- Comment #5 from pault at gcc dot gnu dot org 2008-01-11 18:27 --- Fixed on trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34537
[Bug target/26015] [4.1/4.2/4.3 Regression] ICE during bootstrap for vax architecture
--- Comment #11 from wilson at gcc dot gnu dot org 2008-01-11 21:50 --- Mine, as I wrote a patch for it. -- wilson at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26015
[Bug c++/34691] [4.1/4.2/4.3 Regression] Default argument checking not performed after overload resolution with C linkage
--- Comment #2 from jakub at gcc dot gnu dot org 2008-01-11 13:25 ---
Related:
void foo (int i, int j = 6);
void foo (int i = 4, int j);
int bar (void)
{
foo ();
}
is accepted (correctly), but:
extern C {
void foo (int i, int j = 6);
void foo (int i = 4, int j);
}
int bar (void)
{
foo ();
}
is rejected. How does the C linkage matter here?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34691
[Bug c++/34738] gcc fails to compile a file in the trolltech qt 4.3.0 source tree. Internal compiler error or cc1plus: out of memory allocating
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-01-11 13:57 --- Created an attachment (id=14926) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14926action=view) testcase Adjusted to also build with 4.3. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Attachment #14921|0 |1 is obsolete|| Attachment #14925|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34738
[Bug inline-asm/33932] miscalculation of asm labels with -g3
--- Comment #5 from stsp at users dot sourceforge dot net 2008-01-11 20:14 --- Actually I don't believe it is not a bug. The properly functional code cannot be miscompiled that easily only because of the different -g option. Adding Mark to CC for the final judgement on this. :) -- stsp at users dot sourceforge dot net changed: What|Removed |Added CC||stsp at users dot ||sourceforge dot net, ||mmitchel at gcc dot gnu dot ||org Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33932
[Bug middle-end/34744] New: Memory leaks in compiler with empty program
Memory leak with empty Fortran programs: latest trunk Given: program gamsanal end $ valgrind --leak-check=full f951 pr34722.f90 ==20839== 1,408 bytes in 20 blocks are definitely lost in loss record 2 of 6 ==20839==at 0x4A059F6: malloc (vg_replace_malloc.c:149) ==20839==by 0xB1B567: xmalloc (xmalloc.c:147) ==20839==by 0x51E842: df_install_refs (df-scan.c:2425) ==20839==by 0x51EADA: df_refs_add_to_chains (df-scan.c:2551) ==20839==by 0x52029F: df_record_exit_block_uses (df-scan.c:3808) ==20839==by 0x5218D0: df_scan_blocks (df-scan.c:597) ==20839==by 0x51499D: rest_of_handle_df_initialize (df-core.c:742) ==20839==by 0x65C925: execute_one_pass (passes.c:1118) ==20839==by 0x65CAEB: execute_pass_list (passes.c:1171) ==20839==by 0x65CAFD: execute_pass_list (passes.c:1172) ==20839==by 0x735345: tree_rest_of_compilation (tree-optimize.c:404) ==20839==by 0x8E55E1: cgraph_expand_function (cgraphunit.c:1152) ==20839== ==20839== LEAK SUMMARY: ==20839==definitely lost: 1,408 bytes in 20 blocks. ==20839== possibly lost: 64 bytes in 2 blocks. ==20839==still reachable: 297,659 bytes in 951 blocks. ==20839== suppressed: 0 bytes in 0 blocks. ==20839== Reachable blocks (those to which a pointer was found) are not shown. ==20839== To see them, rerun with: --leak-check=full --show-reachable=yes -- Summary: Memory leaks in compiler with empty program Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jvdelisle at gcc dot gnu dot org GCC host triplet: x86-64-linux-gni http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34744
[Bug libfortran/34745] New: collect array bounds checking
Jerry DeLisle noted in http://gcc.gnu.org/ml/fortran/2008-01/msg00142.html that it might be good to collect the bounds-checking code for intrinsics into a single function. -- Summary: collect array bounds checking Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org BugsThisDependsOn: 34670 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34745
[Bug libfortran/34746] New: [4.3 Regression] wrong formats in libgfortran's runtime_error
Fallout from the patch for PR 34670: http://gcc.gnu.org/ml/fortran/2008-01/msg00146.html -- Summary: [4.3 Regression] wrong formats in libgfortran's runtime_error Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: tkoenig at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34746
[Bug tree-optimization/23821] [4.0/4.1/4.2/4.3 Regression] DOM and VRP creating harder to optimize code
-- spop at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-08-27 21:48:05 |2008-01-11 22:27:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
[Bug inline-asm/33932] miscalculation of asm labels with -g3
--- Comment #7 from stsp at users dot sourceforge dot net 2008-01-11 22:02 --- Thank you for the prompt reply! I also think simply changing to the previous section is the good fix because the main problem, as I see it, is that the -g3 currently has the different behaveour than the other -gX options. The fact that asm() doesn't automatically change to .text is, as you say, not really a bug. But the erratic behaveour of -g3 certainly is. I guess the problem is that currently it is not officially documented what section is used by default, so the one may say any random section is OK. But IMHO it would be much better to have a particular section be a default, and have it documented. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33932
[Bug rtl-optimization/34628] [4.2/4.3 Regression] problems with inlining on ARM
--- Comment #12 from tbm at cyrius dot com 2008-01-11 22:01 --- (In reply to comment #11) Created an attachment (id=14907) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14907action=view) [edit] Lightly tested fix. I'll give it a whirl on IA-64 but it would be nice to test it on ARM too. I'm away from my machine for another week. Paul, do you think you could bootstrap and regtest the patch on ARM? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34628
[Bug fortran/32489] Endless loop when compiling
--- Comment #5 from pault at gcc dot gnu dot org 2008-01-11 22:01 ---
(In reply to comment #4)
Will 2.5s do you on amd64/Cygwin_nt?
Index: gcc/fortran/array.c
===
*** gcc/fortran/array.c (revision 131469)
--- gcc/fortran/array.c (working copy)
*** gfc_expand_constructor (gfc_expr *e)
*** 1401,1406
--- 1401,1409
gfc_expr *f;
try rc;
+ if (!gfc_is_constant_expr (e))
+ return SUCCESS;
+
f = gfc_get_array_element (e, GFC_MAX_AC_EXPAND);
if (f != NULL)
{
...yet to be regtested but rather obvious.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32489
[Bug fortran/32489] Endless loop when compiling
--- Comment #6 from dominiq at lps dot ens dot fr 2008-01-11 23:21 --- With the patch there is a regression for the following tests: [ibook-dhum] f90/bug% gfc /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/array_initializer_1.f90 /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/array_initializer_1.f90:13.30: real, parameter :: r(6) = (/(x(i:i +1, i), i = 1,3)/) 1 Error: Invalid character in name at (1) /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/array_initializer_1.f90:14.31: real, parameter :: s(12) = (/((x(i, i:j-1:-1), i = 3,4), j = 2,3)/) 1 Error: Invalid character in name at (1) and [ibook-dhum] f90/bug% gfc /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/char_result_5.f90 /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/char_result_5.f90:93: internal compiler error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32489
[Bug target/34412] ICE in extract_insn, at recog.c:1990
--- Comment #4 from hutchinsonandy at aim dot com 2008-01-11 23:32 --- Created an attachment (id=14928) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14928action=view) Fix expander patch Prior analysis is correct. Typo resulted in QI addition to HI mode frame pointer, when Tiny series target was selected (256 byte stack). The addition was intended to just change LSB as MSB is always fixed. Patch corrects prolog expander typo so that 8 bit (QI) increment is made to 8 bit representation of frame pointer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34412
[Bug target/34412] ICE in extract_insn, at recog.c:1990
--- Comment #5 from hutchinsonandy at aim dot com 2008-01-11 23:40 --- An instant work around for Tiny Targets is to optimise at higher level (-Os) This will most likely remove need for frame pointer and skirt around the bug. Though it will still happen if there are more auto variables than registers free. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34412
[Bug tree-optimization/23821] [4.0/4.1/4.2/4.3 Regression] DOM and VRP creating harder to optimize code
--- Comment #14 from sebpop at gmail dot com 2008-01-12 00:11 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] DOM and VRP creating harder to optimize code Patch: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00518.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
[Bug ada/33788] [4.3 regression] GNAT bug box in expand_expr_addr_expr_1, at expr.c:6862
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2008-01-12 00:24 --- Investigating. -- 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-12-14 10:44:21 |2008-01-12 00:24:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33788
[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel
--- Comment #31 from ebotcazou at gcc dot gnu dot org 2008-01-12 00:30 --- After playing with dbgcounts to see what happens, I indeed found the same as what Eric notes in comment #27. The proposed fix makes perfect sense. Thanks. Assigning to self. -- 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|2008-01-09 19:09:59 |2008-01-12 00:30:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944
[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel
--- Comment #30 from steven at gcc dot gnu dot org 2008-01-12 00:25 --- After playing with dbgcounts to see what happens, I indeed found the same as what Eric notes in comment #27. The proposed fix makes perfect sense. I won't be fixing this, I think Eric has already proposed the correct fix. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944
[Bug c++/34747] New: __attribute__((aligned(x)))+__alignof != correct behaviour
__attribute__((aligned(x))) is not derivable and etc. Here is the tests which
discovering the bugs:
///
#include stdio.h
#ifdef __GNUC__
#define DECLARE_ALIGN(x) __attribute__((aligned(x)))
#elif defined(_MSC_VER)
#define DECLARE_ALIGN(x) __declspec(align(x))
#endif
struct DECLARE_ALIGN(1) A1 {
};
struct DECLARE_ALIGN(16) A16 {
};
struct DECLARE_ALIGN(32) A32 {
};
#pragma pack(push,1)
struct DECLARE_ALIGN(16) A16P1 { //Alignment still should be 16
};
struct DECLARE_ALIGN(32) A32P1 { //Alignment still should be 32
};
#pragma pack(pop)
struct DECLARE_ALIGN(16) A1632_1 : A32 {}; //Overall alignment still should be
32
struct DECLARE_ALIGN(16) A1632_2 { A32 a32; }; //Overall alignment still should
be 32
int failures = 0;
///
#pragma pack(push,1)
struct test1_t {
A1 a1;
};
#pragma pack(pop)
void test1() {
if(__alignof(test1_t) != 1) { printf(FAILED: test1\n); failures++; }
}
#pragma pack(push,1)
struct test2_t
: A1 {
};
#pragma pack(pop)
void test2() {
if(__alignof(test2_t) != 1) { printf(FAILED: test2\n); failures++; }
}
#pragma pack(push,1)
struct test3_t {
int i;
A1 a1;
};
#pragma pack(pop)
void test3() {
if(__alignof(test3_t) != 1) { printf(FAILED: test3\n); failures++; }
}
#pragma pack(push,1)
struct test4_t
: A1 {
int i;
};
#pragma pack(pop)
void test4() {
if(__alignof(test4_t) != 1) { printf(FAILED: test4\n); failures++; }
}
///
#pragma pack(push,1)
struct test5_t {
A16P1 a16p1;
};
#pragma pack(pop)
void test5() {
if(__alignof(test5_t) != 16) { printf(FAILED: test5\n); failures++; }
}
#pragma pack(push,1)
struct test6_t
: A16P1 {
};
#pragma pack(pop)
void test6() {
if(__alignof(test6_t) != 16) { printf(FAILED: test6\n); failures++; }
}
#pragma pack(push,1)
struct test7_t {
int i;
A16P1 a16p1;
};
#pragma pack(pop)
void test7() {
if(__alignof(test7_t) != 16) { printf(FAILED: test7\n); failures++; }
}
#pragma pack(push,1)
struct test8_t
: A16P1 {
int i;
};
#pragma pack(pop)
void test8() {
if(__alignof(test8_t) != 16) { printf(FAILED: test8\n); failures++; }
}
///
struct test10_t {
int i;
A16 a16;
};
void test10() {
if(__alignof(test10_t) != 16) { printf(FAILED: test10\n); failures++; }
}
struct test11_t {
int i;
A16 a16;
A32 a32;
};
void test11() {
if(__alignof(test11_t) != 32) { printf(FAILED: test11\n); failures++; }
}
struct test12_t : A16 {
int i;
};
void test12() {
if(__alignof(test12_t) != 16) { printf(FAILED: test12\n); failures++; }
}
struct test13_t : A16,A32 {
char i;
};
void test13() {
if(__alignof(test13_t) != 32) { printf(FAILED: test13\n); failures++; }
}
struct test14_t : A16,A32 {
char c;
int i;
};
void test14() {
if(__alignof(test14_t) != 32) { printf(FAILED: test14\n); failures++; }
}
struct test15_t {
int i;
A16P1 a16p1;
};
void test15() {
if(__alignof(test15_t) != 16) { printf(FAILED: test15\n); failures++; }
}
struct test16_t {
int i;
A16P1 a16p1;
A32P1 a32p1;
};
void test16() {
if(__alignof(test16_t) != 32) { printf(FAILED: test16\n); failures++; }
}
struct test17_t : A16P1 {
int i;
};
void test17() {
if(__alignof(test17_t) != 16) { printf(FAILED: test17\n); failures++; }
}
struct test18_t : A16P1,A32P1 {
int i;
};
void test18() {
if(__alignof(test18_t) != 32) { printf(FAILED: test18\n); failures++; }
}
struct test19_t : A16P1,A32P1 {
char c;
int i;
};
void test19() {
if(__alignof(test19_t) != 32) { printf(FAILED: test19\n); failures++; }
}
#pragma pack(push,1)
struct test20_t {
int i;
A16 a16;
};
void test20() {
if(__alignof(test20_t) != 16) { printf(FAILED: test20\n); failures++; }
}
struct test21_t {
int i;
A16 a16;
A32 a32;
};
void test21() {
if(__alignof(test21_t) != 32) { printf(FAILED: test21\n); failures++; }
}
struct test22_t : A16 {
int i;
};
void test22() {
if(__alignof(test22_t) != 16) { printf(FAILED: test22\n); failures++; }
}
struct test23_t : A16,A32 {
int i;
};
void test23() {
if(__alignof(test23_t) != 32) { printf(FAILED: test23\n); failures++; }
}
struct test24_t : A16,A32 {
char c;
int i;
};
void test24() {
if(__alignof(test24_t) != 32) { printf(FAILED: test24\n); failures++; }
}
struct test25_t {
int i;
A16P1 a16p1;
};
void test25() {
if(__alignof(test25_t) != 16) { printf(FAILED: test25\n); failures++; }
}
struct test26_t {
int i;
A16P1 a16p1;
A32P1 a32p1;
};
void test26() {
if(__alignof(test26_t) != 32) { printf(FAILED: test26\n); failures++; }
}
struct test27_t : A16P1 {
int i;
};
void test27() {
if(__alignof(test27_t) != 16) { printf(FAILED: test27\n); failures++; }
}
struct test28_t : A16P1,A32P1 {
int i;
};
void test28() {
if(__alignof(test28_t) != 32) { printf(FAILED: test28\n);
[Bug c++/34747] __attribute__((aligned(x)))+__alignof != correct behaviour
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-12 03:27 --- I think this is really just PR 10179 which was fixed for 4.3.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34747
[Bug tree-optimization/34683] SSA rewriting in the loop unroller causes quadratic behavior
--- Comment #48 from rakdver at gcc dot gnu dot org 2008-01-12 03:59 --- (In reply to comment #47) Most of the PRE/FRE memory is spent in copied VOPs VECs. Unfortunately we cannot move them to heap memory easily as the get shared in the PRE tables... I tried to be explicit in managing the memory, but it gets really hard (which is probably the reason we stick it in GC memory in the first place). in fact, it copies the VOPS list of each store statement 50 times on average (once for PRE and once for FRE, i.e., about 100x total). Cannot sccvn be throttled down somehow so that it does not spend so much memory this way? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
