The GCC Mission Statement says nothing about conforming to international standards!?
I just read the GCC Mission Statement and I see nothing there about conforming to international standards for programming languages. Why does the GCC Mission Statement not include conforming to internationally accepted standards? Its very counterproductive not to use standards. -John Burak
Re: Failure to build libjava on 512MB machine
On Fri, 2 Feb 2007, Paolo Bonzini wrote:
I'd be curious to know the effect of removing the complexity field of
struct tree_exp. It should be possible to bootstrap C/C++/Java/Fortran
with a two line patch removing the field from tree.h, and the only
reference to it in tree.c (via the macro TREE_COMPLEXITY).
You mean, like the patch below?
Doesn't work:
trunk/gcc/cp/pt.c: In function 'tsubst_expr':
trunk/gcc/cp/pt.c:8924: error: 'struct tree_exp' has no member named
'complexity'
Gerald
Index: tree.c
===
--- tree.c (revision 121482)
+++ tree.c (working copy)
@@ -2931,7 +2931,6 @@
#else
SET_EXPR_LOCUS (t, NULL);
#endif
- TREE_COMPLEXITY (t) = 0;
TREE_OPERAND (t, 0) = node;
TREE_BLOCK (t) = NULL_TREE;
if (node !TYPE_P (node))
Index: tree.h
===
--- tree.h (revision 121482)
+++ tree.h (working copy)
@@ -1498,7 +1498,6 @@
/* In ordinary expression nodes. */
#define TREE_OPERAND(NODE, I) TREE_OPERAND_CHECK (NODE, I)
-#define TREE_COMPLEXITY(NODE) (EXPR_CHECK (NODE)-exp.complexity)
/* In gimple statements. */
#define GIMPLE_STMT_OPERAND(NODE, I) GIMPLE_STMT_OPERAND_CHECK (NODE, I)
@@ -1724,7 +1723,6 @@
{
struct tree_common common;
source_locus locus;
- int complexity;
tree block;
tree GTY ((special (tree_exp),
desc (TREE_CODE ((tree) %0
Re: The GCC Mission Statement says nothing about conforming to international standards!?
icrashedtheinternet wrote: I just read the GCC Mission Statement and I see nothing there about conforming to international standards for programming languages. Why does the GCC Mission Statement not include conforming to internationally accepted standards? Its very counterproductive not to use standards. Of course not including it in the mission statement does not mean that it is not a requirement, so the last sentence is a bit of a non-sequitur. To me, implementing C means implementing the standard, and I think that this is the general approach of gcc, so it is not entirely clear it should be explicit in the mission statement. Ultimately the more important goal is to implement a widely useable compiler, to the extent that includes following the standard, that's what will happen. -John Burak
Some hints on solving this problem?
Hi, I am working on gcc 4.1.1 and Itanium2 architecture. I want to use gcc to emit some code before each ld and st instruction (I know that using dynamic binary translator like PIN may be more suitable for this task, but I am on the way of studying gcc and want to use it to achieve this goal). But after several days of study, I find that the back-end of gcc too complex... :-( So, what is the best level in back-end to accomplish this task? I would appreciate any help I can get on this problem! thx!
Re: About Gcc tree tutorials
Also, I referred to some tutorials and articles in the net about writing gcc front-end. And here are they: 1. http://en.wikibooks.org/wiki/GNU_C_Compiler_Internals/Print_version 2. http://www.faqs.org/docs/Linux-HOWTO/GCC-Frontend-HOWTO.html (old) 3. http://www.linuxjournal.com/article/7884 (overview) 4. http://www.eskimo.com/~johnnyb/computers/toy/cobol_14.html A bit out of date, but may be useful: http://svn.gna.org/viewcvs/gsc/branches/hello-world/ Best Regards, Rafael
Re: Failure to build libjava on 512MB machine
Tom Tromey wrote: Marco == Marco Trudel [EMAIL PROTECTED] writes: Marco If it takes about 30 to 40min to build this html/parser.o and Marco gnu-xml.o needs about 1 or 2 minutes but is - last time I took a look Marco - a lot bigger than the html parser, shouldn't then be investigated Marco why this html parser is such a hard thing? It is just a really big file. I think there's more than that. Way bigger files need way less time to compile... If it still takes too much memory to compile, I suppose I, or someone (hint, hint), will look at how to shrink it. Makefile has been updated to split the compilation, right? I just compiled a rev 121540 and still, htmp/parser[FOOBAR].o takes way over 30min. A good example is also to compile ecj.jar. It can need from 1min to way over 30min, depending on the gcj. I'll try some test compilations and send statistics as soon as my machine is free for some extra work. This might be a x86, 32bit, static gcj or whatever problem only. But optimization seems to be involved... Marco
[LWOW] INWESTYCYJNE INTERESY W UKRAINIE : 24 - 26 lutego 2007 r., Lwow, Ukraina gcc@gcc.gnu.org
Serdecznie zapraszamy na
Międzynarodową Polsko - Ukraińską konferencję na temat
Polska - Ukraina: sami budujemy przyszłość
XX Międzynarodowa konferencja
INWESTYCYJNE INTERESY W UKRAINIE
Aktualne informacje.Ostateczne wydarzenia z Ukrainy.Informacje
handlowo-gospodarcze.
Przepisy prawne, exportowo-importowe. W co warto inwestować na Ukrainie?
Jak nabyć nieruchomoć na firmę?
Rozwój inwestycji w Ukrainie- teraniejszość i perspektywy
24-26 lutego 2007 r., Lwów, Ukraina
http://www.seminar.pl.ua/lvov.html
Osoba odpowiedzialna: Wiktoria Swięcicka {Tel. OO 38 (O67) 5=O=6=O=1=1=O }
E-mail:[EMAIL PROTECTED]
Faks: OO 38 (044) 4=5=5=9=9=9=9
Usun: mailto:[EMAIL PROTECTED]:gcc@gcc.gnu.org
GCC 4.0.4 Released
I'm pleased to announce that GCC-4.0.4 has been released on January 31, 2007. This release is a minor release, containing bug fixes for regressions relative to earlier releases. It is the final release from the 4.0.x series, and the gcc-4_0-branch is now closed. GCC 4.0.4 is provided for those who require a high degree of binary compatibility with previous 4.0.x releases. For most users, the GCC team recommends that version 4.1.1 or later be used instead. This release is available for download from the FTP servers listed here http://www.gnu.org/order/ftp.html We would like to thank the impressive number people who contributed to this release. -- Dr. Gabriel Dos Reis ([EMAIL PROTECTED]), Assistant Professor http://www.cs.tamu.edu/people/faculty/gdr Texas AM University -- Department of Computer Science 301, Bright Building -- College Station, TX 77843-3112
Re: The GCC Mission Statement says nothing about conforming to international standards!?
On Sat, Feb 03, 2007 at 01:42:06AM -0700, icrashedtheinternet wrote: I just read the GCC Mission Statement and I see nothing there about conforming to international standards for programming languages. Why does the GCC Mission Statement not include conforming to internationally accepted standards? Its very counterproductive not to use standards. You incorrectly assume that the mission statement is an exhaustive list of every GCC priority. It isn't. Many GCC contributors are active members of the appropriate standards committees, and GCC tries to conform to appropriate standards and to document known areas of non-compliance. Standards conformance is a goal, but it is not the #1 goal. For example (to risk reviving a recent debate), it appears that almost every large C program in existence assumes, deliberately or accidentally, that int overflow wraps around in a two's complement manner, but a compiler that rigorously enforced conformance to internationally accepted standards could happily break all of that code (e.g. by trapping on every overflow). The result is that GCC explicitly rejects something that you might have been taught in compiler class, that the standard is a contract between the compiler developer and the users and that the compiler can do anything it wants with any code that does not rigorously meet what is defined in the standard. Standard-conforming code should work, but the issue of what to do with technically incorrect, but commonly occurring code is something that we'll continue to struggle with. In some cases, serving the users might require going beyond the standard, in other cases, the cost in lost opportunities for optimization might be too high.
Re: Some hints on solving this problem?
1) Modify the final() in final.c to emit some code before ld and st before outputting the assembly. 2) Modify the MD file. Find the template which generate ld or st, and add some code before ld and st. On 2/3/07, 吴曦 [EMAIL PROTECTED] wrote: Hi, I am working on gcc 4.1.1 and Itanium2 architecture. I want to use gcc to emit some code before each ld and st instruction (I know that using dynamic binary translator like PIN may be more suitable for this task, but I am on the way of studying gcc and want to use it to achieve this goal). But after several days of study, I find that the back-end of gcc too complex... :-( So, what is the best level in back-end to accomplish this task? I would appreciate any help I can get on this problem! thx! -- Paul Yuan www.yingbo.com
Re: About Gcc tree tutorials
Ferad Zyulkyarov wrote: Also, I referred to some tutorials and articles in the net about writing gcc front-end. And here are they: 1. http://en.wikibooks.org/wiki/GNU_C_Compiler_Internals/Print_version 2. http://www.faqs.org/docs/Linux-HOWTO/GCC-Frontend-HOWTO.html (old) 3. http://www.linuxjournal.com/article/7884 (overview) 4. http://www.eskimo.com/~johnnyb/computers/toy/cobol_14.html I would be thankful if you share any doc resources that you have. The treelang front-end that's included with GCC is itself primarily a tutorial/example on writing a GCC front end. The treelang documentation does a fairly good job of describing how the internals work, I think. - Brooks
[Bug java/21695] ICE when building gnu-xml.lo in libjava directory
--- Comment #4 from brian at dessent dot net 2007-02-03 09:08 --- I never found out what was causing this but it hasn't happened in quite some time so this can be closed out as INVALID. -- brian at dessent dot net changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21695
[Bug c++/29209] ICE optimizing passing long double to abstract method while in other abstract's impl
--- Comment #5 from tbm at cyrius dot com 2007-02-03 09:45 --- I don't see this with Linux on HPPA hardware. Steve Ellcey, can you try on HPUX please? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29209
[Bug middle-end/28116] [4.1 Regression] ICE when building konverter with gcc-4.1 with -O3 [RSO]
--- Comment #19 from tbm at cyrius dot com 2007-02-03 09:47 --- (In reply to comment #18) Fixed. Richi, do you think you can check whether PR28358 is really a duplicate of this bug (as Andrew thinks) and should be closed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28116
[Bug ada/25117] GNAT Bug Box, GCC error, verify_ssa failed
--- Comment #7 from tbm at cyrius dot com 2007-02-03 09:51 --- (In reply to comment #6) Created an attachment (id=10360) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10360action=view) [edit] source file set for the 4.2 Bug Box To reproduce, Can you still reproduce this problem? I cannot with 4.2.0 20070131. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25117
[Bug ada/30686] New: [4.2 Regression] ada: ICE in expand_expr_addr_expr_1, at expr.c:6563
I get the following with 4.2.0 20070131: [EMAIL PROTECTED]:~/libtexttools$ /usr/lib/gcc-snapshot/bin/gcc -c windows.adb +===GNAT BUG DETECTED==+ | 4.2.0 20070131 (prerelease) (ia64-unknown-linux-gnu) GCC error: | | in expand_expr_addr_expr_1, at expr.c:6563 | | Error detected at windows.adb:265:5 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. windows.adb windows.ads common.ads gen_list.ads os.ads userio.ads strings.ads controls.ads english.ads windows.adb:273:14: warning: x may be referenced before it has a value windows.adb:273:17: warning: y may be referenced before it has a value windows.adb:1879:16: warning: OldX may be referenced before it has a value windows.adb:1879:22: warning: OldY may be referenced before it has a value windows.adb:2555:19: warning: Relative may be referenced before it has a value windows.adb:2574:19: warning: Tempint may be referenced before it has a value windows.adb:2666:03: warning: OK is never assigned a value windows.adb:2667:03: warning: text is never assigned a value compilation abandoned -- Summary: [4.2 Regression] ada: ICE in expand_expr_addr_expr_1, at expr.c:6563 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30686
[Bug ada/30686] [4.2 Regression] ada: ICE in expand_expr_addr_expr_1, at expr.c:6563
--- Comment #1 from tbm at cyrius dot com 2007-02-03 10:04 --- Created an attachment (id=13000) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13000action=view) ada testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30686
[Bug ada/30686] ada: ICE in expand_expr_addr_expr_1, at expr.c:6563
--- Comment #2 from tbm at cyrius dot com 2007-02-03 10:05 --- Also happens with 4.1: +===GNAT BUG DETECTED==+ | 4.1.2 20061115 (prerelease) (Debian 4.1.1-22) (ia64-unknown-linux-gnu) GCC error:| | in expand_expr_addr_expr_1, at expr.c:6393 | | Error detected at windows.adb:265:5 | -- tbm at cyrius dot com changed: What|Removed |Added Keywords||ice-on-valid-code Summary|[4.2 Regression] ada: ICE in|ada: ICE in |expand_expr_addr_expr_1, at |expand_expr_addr_expr_1, at |expr.c:6563 |expr.c:6563 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30686
[Bug target/30687] New: undocumented attributes on ia64
The ia64 backend has various undocumented machine attributes. Unfortunately
they are used in code.
{ syscall_linkage, 0, 0, false, true, true, NULL },
{ model, 1, 1, true, false, false, ia64_handle_model_attribute },
{ version_id, 1, 1, true, false, false,
ia64_handle_version_id_attribute },
Would be good to document them.
--
Summary: undocumented attributes on ia64
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ak at muc dot de
GCC target triplet: ia64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30687
[Bug ada/30686] ada: ICE in expand_expr_addr_expr_1, at expr.c:6563
--- Comment #3 from tbm at cyrius dot com 2007-02-03 10:11 --- I also see this with 4.2.0 20060721. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30686
[Bug fortran/30683] [4.2 only] internal compiler error: Segmentation fault
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Keywords||ice-on-valid-code, patch Known to fail||4.2.0 4.1.2 Known to work||4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-02-03 10:33:57 date|| Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30683
[Bug fortran/29899] [Segfault] Fortran entry point caught from C function
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-02-03 10:43 --- I've tried a few times to look into it, but the .tar.bz2 code on your server is just too large, and the example you posted here doesn't compile. Could you try the following: * upgrade to gfortran-4.2 or later (you can download gfortran-4.3 binaries from http://gcc.gnu.org/wiki/GFortranBinaries) and see if your bug is fixed * reduce your testcase to something we can investigate Merci ! -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29899
[Bug rtl-optimization/30688] New: Branch registers loaded too late on ia64
During Linux kernel development we ran into a few situations that showed that indirect calls (through a function pointer) are significant slower on IA64 than on other platforms. Various ugly workarounds have been added to work around that. Some investigation shows the code gcc generates for indirect calls on ia64 isn't very good. The IA64 optimization manuals recommend to load branch registers as early as possible before a indirect jump, so that the CPU can start fetching the code stream at the target. Otherwise there is a longer stall. I ran some statistics over a 2.6.19 linux kernel with a recent 4.3 snapshot by grepping for indirect calls and in near all cases i looked at the branch register was loaded in the bundle directly preceding the bundle that contains the jump. Earlier versions (4.1 and 4.0) also weren't any better. From looking at code in many cases it would have been possible to load the branch register earlier since there was no conditional state. This is a enhancement request to change the scheduler to be more aggressive at moving branch register loads earlier before jumps on ia64. -- Summary: Branch registers loaded too late on ia64 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ak at muc dot de GCC target triplet: ia64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30688
[Bug rtl-optimization/30688] Branch registers loaded too late on ia64
--- Comment #1 from ak at muc dot de 2007-02-03 11:22 ---
Here's a simple test case:
void f(int k, int (*fptr)(int i))
{
int i;
/* Do something useless */
for (i = 0; i 5; i++)
k *= 10;
fptr(k);
}
compiled with 4.3.0 20070203 gives
...
;;
.mmi
nop 0
mov r1 = r36
mov b0 = r34
.mib
nop 0
mov ar.pfs = r35
br.ret.sptk.many b0
Note b0 is only loaded directly in front of the branch, even though it could
have been loaded much earlier in front of the loop.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30688
[Bug fortran/30689] New: equivalence modifies common block
I hope this is a new bug (I am not good at searching through bugzilla). I am also not sure if this is according to standards, but as I undertand equivalence is a harmless statement. It shouldn't change the lenght of the common block. I am using gfortran -fdefault-integer-8 to compile gaussian-03 program on x86_64 machine. Everything works fine including GOMP stuff. Only the command to reserve memory in the beginning doesn't work. One can use environment variable, but it is annoying to tell every student, how to do it, so I decided to fix also this and stumbled on the following problem: program lstint Implicit Integer(A-Z) REAL FP DOUBLE PRECISION DP COMMON/QPSTAT/LASTYP,STATUS,CHRCTR,DIGIT,Intger,FP,dp,LENSTR lenstr=15 write(*,*)'QPtranenter:lenstr=',lenstr Call QPutIt End Subroutine QPutIt Implicit Integer(A-Z) integer fpl,dpl(2) integer LASTYP,STATUS,CHRCTR,DIGIT,Intger,LENSTR Real FP Double Precision DP Common/QPStat/LASTYP,STATUS,CHRCTR,DIGIT,Intger,FP,DP,LENSTR Equivalence (DPL,DP),(FPL,FP) write(*,*)'QPutItstart:lenstr=',lenstr return end gfortran -fdefault-integer-8 -o x x.f ./x lenstr=15 lenstr=0 Apparently the address of lenstr gets shifted in the subroutine because of the equivalence statement. Is this the right behavior? -- Summary: equivalence modifies common block Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: milan at cmm dot ki dot si http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30689
[Bug fortran/30683] [4.2 only] internal compiler error: Segmentation fault
--- Comment #5 from sfilippone at uniroma2 dot it 2007-02-03 12:05 --- (In reply to comment #2) I'm testing a patch for this at the moment. The problem is you have renamed SIZE to an interface. That is, this is leading to the segfault: interface size module procedure get_fld_size end interface While the standard may permit this construct, it may be prudent to not rename standard intrinsic procedures. Agreed. I take it you mean it IS standard conforming, right? Just to make sure. In any case, an ice is an ice -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30683
[Bug libfortran/30690] New: Clean up m4 files
Right now, the files from the m4 directory don't follow a sane nor uniform quoting style. What they do is also undocumented. This section of the code needs to be documented better, and also needs some cleanup. Alternatively, a rewrite would be in order. -- Summary: Clean up m4 files 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30690
[Bug fortran/30660] Allocatable components of a derived type require the SAVE attribute.
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch, rejects-valid Known to fail||4.3.0 4.2.0 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30660
[Bug libfortran/30690] Clean up m4 files
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-03 12:51:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30690
[Bug libfortran/30007] libgfortran doesn't build for sh-elf
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30007
[Bug c/30691] New: i386 and x86-64 build options m32 and m64
Under Intel 386 and AMD x86-64 Options are listed several different parameters one can give to -march, such as i386,i486,pentium,prescott,etc. For AMD64 users the special options -m32 and -m64 specify whether to build for 32 or 64 bit environments. Aren't both these options redundant? If you're building on an amd64 then the default target architecture ought to be 64-bit, and if you specify -march=i386 then presumably you want 32-bit code... -- Summary: i386 and x86-64 build options m32 and m64 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: beethoven3322 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30691
[Bug c++/28358] ICE on valide template code using -O1 or -O2, but *not* with -O0 or -O3
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-02-03 13:13 --- I cannot reproduce this with either current 4.1 branch head nor g++ (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28358
[Bug fortran/30660] Allocatable components of a derived type require the SAVE attribute.
--- Comment #4 from pault at gcc dot gnu dot org 2007-02-03 13:38 --- Subject: Bug 30660 Author: pault Date: Sat Feb 3 13:38:42 2007 New Revision: 121541 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121541 Log: 2007-02-03 Paul Thomas [EMAIL PROTECTED] PR fortran/30514 * array.c (match_array_element_spec): If the length of an array is negative, adjust the upper limit to make it zero length. PR fortran/30660 * resolve.c (pure_function, resolve_function): Initialize name to null to clear up build warnings. (resolve_fl_variable): Look at components explicitly to check for default initializer, rather than using gfc_default_initializer. 2007-02-03 Paul Thomas [EMAIL PROTECTED] PR fortran/30514 * gfortran.dg/zero_sized_2.f90: New test. PR fortran/30660 * gfortran.dg/alloc_comp_basics_4.f90: New test. PR fortran/29820 * gfortran.dg/actual_array_interface_1.f90: Copy source to empty file. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_basics_4.f90 trunk/gcc/testsuite/gfortran.dg/zero_sized_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/actual_array_interface_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30660
[Bug fortran/29820] ICE in fold_convert, at fold-const.c:2146
--- Comment #13 from pault at gcc dot gnu dot org 2007-02-03 13:38 --- Subject: Bug 29820 Author: pault Date: Sat Feb 3 13:38:42 2007 New Revision: 121541 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121541 Log: 2007-02-03 Paul Thomas [EMAIL PROTECTED] PR fortran/30514 * array.c (match_array_element_spec): If the length of an array is negative, adjust the upper limit to make it zero length. PR fortran/30660 * resolve.c (pure_function, resolve_function): Initialize name to null to clear up build warnings. (resolve_fl_variable): Look at components explicitly to check for default initializer, rather than using gfc_default_initializer. 2007-02-03 Paul Thomas [EMAIL PROTECTED] PR fortran/30514 * gfortran.dg/zero_sized_2.f90: New test. PR fortran/30660 * gfortran.dg/alloc_comp_basics_4.f90: New test. PR fortran/29820 * gfortran.dg/actual_array_interface_1.f90: Copy source to empty file. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_basics_4.f90 trunk/gcc/testsuite/gfortran.dg/zero_sized_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/actual_array_interface_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29820
[Bug fortran/30514] zero-sized array wrongly rejected: integer :: i(1:-1)
--- Comment #5 from pault at gcc dot gnu dot org 2007-02-03 13:38 --- Subject: Bug 30514 Author: pault Date: Sat Feb 3 13:38:42 2007 New Revision: 121541 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121541 Log: 2007-02-03 Paul Thomas [EMAIL PROTECTED] PR fortran/30514 * array.c (match_array_element_spec): If the length of an array is negative, adjust the upper limit to make it zero length. PR fortran/30660 * resolve.c (pure_function, resolve_function): Initialize name to null to clear up build warnings. (resolve_fl_variable): Look at components explicitly to check for default initializer, rather than using gfc_default_initializer. 2007-02-03 Paul Thomas [EMAIL PROTECTED] PR fortran/30514 * gfortran.dg/zero_sized_2.f90: New test. PR fortran/30660 * gfortran.dg/alloc_comp_basics_4.f90: New test. PR fortran/29820 * gfortran.dg/actual_array_interface_1.f90: Copy source to empty file. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_basics_4.f90 trunk/gcc/testsuite/gfortran.dg/zero_sized_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/actual_array_interface_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30514
[Bug c++/29209] ICE optimizing passing long double to abstract method while in other abstract's impl
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-03 14:47 --- Subject: Re: ICE optimizing passing long double to abstract method while in other abstract's impl --- Comment #5 from tbm at cyrius dot com 2007-02-03 09:45 --- I don't see this with Linux on HPPA hardware. Steve Ellcey, can you try on HPUX please? The treatment of long doubles on HPUX and Linux is different. Long doubles are 128-bit IEEE format on HPUX. They are 64-bit IEEE format on Linux (i.e., same as double). Arguments larger than 64 bits are passed by indirect reference. Thus, the 128-bit format is always passed by reference. Smaller arguments are passed by value. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29209
[Bug c/30692] New: GCC automatically fails to preprocess files with the hpp file extension
I want to use gcc's -E option to just have the preprocessor run on one of my header files, to see if some macros expand correctly. GCC will do this happily if the file's extension is .h, but not if it is .hpp. You can see this trivially by typing in at the console: $ touch blah.hpp $ gcc -E blah.hpp gcc: blah.hpp: linker input file unused because linking not done I think this is because gcc uses the file extension to determine that you probably want to compile C++ and so tries to link the libstdc++. But if you use -E you don't want to link anything! You're just trying to use the preprocessor to see if your macros are working. Renaming the file to have a .h extension fixes the problem. Using g++ instead of gcc gives the same error. I'm using gcc on Ubuntu Edgy, here's the --version line: gcc (GCC) 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- Summary: GCC automatically fails to preprocess files with the hpp file extension Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: k04jg02 at kzoo dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30692
[Bug c++/9278] Illegal use of typedef to void
--- Comment #24 from tbm at cyrius dot com 2007-02-03 15:06 ---
Is the following supposed to fail given that Joseph said that it's valid C code
(but not valid in C++) and the header contains extern C:
(sid)976:[EMAIL PROTECTED]: ~/src] cat t.h
#if defined(__cplusplus)
extern C {
#endif
typedef void ALCvoid;
void test(ALCvoid);
#if defined(__cplusplus)
}
#endif
(sid)977:[EMAIL PROTECTED]: ~/src] cat t.c
#include t.h
(sid)978:[EMAIL PROTECTED]: ~/src] /usr/lib/gcc-snapshot/bin/g++ -c t.c
In file included from t.c:1:
t.h:5: error: 'anonymous' has incomplete type
t.h:5: error: invalid use of 'ALCvoid'
--
tbm at cyrius dot com changed:
What|Removed |Added
CC||tbm at cyrius dot com, jsm28
||at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9278
[Bug c++/9278] Illegal use of typedef to void
--- Comment #25 from joseph at codesourcery dot com 2007-02-03 15:13 --- Subject: Re: Illegal use of typedef to void On Sat, 3 Feb 2007, tbm at cyrius dot com wrote: Is the following supposed to fail given that Joseph said that it's valid C code (but not valid in C++) and the header contains extern C: extern C does not change the language rules, only linkage. The contents must still be valid C++ and are interpreted according to C++ rules for those cases where the same code is valid C and C++ but has different semantics in the two languages. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9278
[Bug c/30692] GCC automatically fails to preprocess files with the hpp file extension
--- Comment #1 from schwab at suse dot de 2007-02-03 15:15 --- .hpp is not a recognized extension. If you want the file to be treated as a C++ header precede it with `-xc++-header'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30692
[Bug c++/29209] ICE optimizing passing long double to abstract method while in other abstract's impl
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-03 15:16 --- Subject: Re: ICE optimizing passing long double to abstract method while in other abstract's impl --- Comment #5 from tbm at cyrius dot com 2007-02-03 09:45 --- I don't see this with Linux on HPPA hardware. Steve Ellcey, can you try on HPUX please? I can no longer duplicate this using 4.1.1 (I recently rebuilt it with an updated version of gmp/mpfr). Trunk also doesn't ICE. However, I see ICEs with 4.0.0, 4.0.1, 4.0.2, 4.0.3, 4.0.4 and 4.1.0 in make_decl_rtl: -bash-2.05b$ /opt/gnu/gcc/gcc-4.1.0/bin/g++ -c -O3 pr29209-1.cc pr29209-1.cc: In member function 'void DataOutputStream_impl::_ZTv0_n12_N21DataOutputStream_impl16write_longdoubleEe(long double)': pr29209-1.cc:21: internal compiler error: in make_decl_rtl, at varasm.c:890 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29209
[Bug tree-optimization/30375] [4.3 Regression] tree-ssa-dse incorrectly removes struct initialization
--- Comment #7 from steven at gcc dot gnu dot org 2007-02-03 15:28 --- Is this now being looked into by Diego or Aldy? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30375
[Bug tree-optimization/30375] [4.3 Regression] tree-ssa-dse incorrectly removes struct initialization
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-03 15:28:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30375
[Bug target/18631] [4.0 Regression] missing error messages passing vectors with -mno-altivec -mabi=altivec
--- Comment #8 from gdr at gcc dot gnu dot org 2007-02-03 15:31 --- won't fix in GCC-4.0.4 -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18631
[Bug target/22537] [4.0 Regression] unable to find a register to spill in class CREG
--- Comment #2 from gdr at gcc dot gnu dot org 2007-02-03 15:32 --- Fixed in GCC-4.1.1 and higher. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22537
[Bug rtl-optimization/22563] [4.0 Regression] performance regression for gcc newer than 2.95
--- Comment #17 from gdr at gcc dot gnu dot org 2007-02-03 15:32 --- Fixed in GCC-4.1.1 and higher. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22563
[Bug middle-end/23090] [4.0 Regression] gcc.c-torture/execute/20050713-1.c -Os fails
--- Comment #9 from gdr at gcc dot gnu dot org 2007-02-03 15:33 --- Fixed in GCC-4.1.0 and higher. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23090
[Bug c/23144] [4.0/4.1/4.2/4.3 Regression] invalid parameter forward declarations not diagnosed
--- Comment #5 from gdr at gcc dot gnu dot org 2007-02-03 15:34 --- won't fix in GCC-4.0.x. Adjusting milestone -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23144
[Bug debug/23205] [4.0 Regression] [C++/unit-at-a-time] stabs debug info omitted for global const variables
--- Comment #10 from gdr at gcc dot gnu dot org 2007-02-03 15:35 --- Fixed in GCC-4.1.0 and higher. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23205
[Bug c/23228] [4.0 Regression] Silly unused variable warning after redeclaration of a local variable
--- Comment #6 from gdr at gcc dot gnu dot org 2007-02-03 15:35 --- Fixed in GCC-4.1.0 and higher. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23228
[Bug middle-end/23290] [4.0 Regression] Layout changed for structure with single complex field
--- Comment #5 from gdr at gcc dot gnu dot org 2007-02-03 15:36 --- Fixed in GCC-4.1.1 and higher. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23290
[Bug rtl-optimization/23490] [4.0 Regression] Long compile time for array initializer with inlined constructor
--- Comment #14 from gdr at gcc dot gnu dot org 2007-02-03 15:37 --- Fixed in GCC-4.1.0 and higher -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23490
[Bug tree-optimization/23563] [4.0 Regression] False warning for uninitialized variable
--- Comment #4 from gdr at gcc dot gnu dot org 2007-02-03 15:37 --- Fixed in GCC-4.1.0 and higher -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23563
[Bug c++/23708] [4.0 Regression] Non-inline function incorrectly treated as inline when using precompiled headers
--- Comment #6 from gdr at gcc dot gnu dot org 2007-02-03 15:38 --- Fixed in GCC-4.1.0 and higher. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23708
[Bug target/23728] [4.0 regression] [m68k] ICE (Segmentation fault) building python
--- Comment #3 from gdr at gcc dot gnu dot org 2007-02-03 15:38 --- Fixed in 4.1.0 and higher. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23728
[Bug middle-end/23848] [4.0/4.1/4.2/4.3 Regression] stack deallocation can be more efficient
--- Comment #2 from gdr at gcc dot gnu dot org 2007-02-03 15:42 --- won't fix in GCC-4.0.4. Adjusting milestone. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23848
[Bug target/23963] [4.0 Regression] MMX intrinsics cause ICE in trunc_int_for_mode
--- Comment #5 from gdr at gcc dot gnu dot org 2007-02-03 15:43 --- Fixed in GCC-4.1.2 and higher. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23963
[Bug middle-end/24004] [4.0 Regression] bogus 'may be uninit warnings' for loops
--- Comment #4 from gdr at gcc dot gnu dot org 2007-02-03 15:44 --- Fixed in GCC-4.1.1 and higher. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24004
[Bug middle-end/24020] [4.0 regression] Excessive (x20) recusive inlining for 4.0 with -O3 and poor stack usage even without inlining
--- Comment #5 from gdr at gcc dot gnu dot org 2007-02-03 15:44 --- Fixed in GCC-4.1.1 and higher. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24020
[Bug preprocessor/24024] [4.0/4.1/4.2/4.3 Regression] gcc -E -C processes \ incorrectly inside C comments
--- Comment #6 from gdr at gcc dot gnu dot org 2007-02-03 15:45 --- Won't fix in GCC-4.0.4. Adjusting milestone. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24024
[Bug middle-end/24306] [4.0 Regression] va_arg gets confused when skipping over certain zero-sized types with -msse
--- Comment #11 from gdr at gcc dot gnu dot org 2007-02-03 15:46 --- Fixed in GCC-4.1.0 and higher. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24306
[Bug rtl-optimization/24361] [4.0 regression] Optimizations -fcse-follow-jumps -fforce-mem break code
--- Comment #3 from gdr at gcc dot gnu dot org 2007-02-03 15:46 --- Fixed in GCC-4.1.1 and higher. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24361
[Bug rtl-optimization/24497] [4.0 Regression] internal compiler error: in apply_opt_in_copies, at loop-unroll.c:2122
--- Comment #9 from gdr at gcc dot gnu dot org 2007-02-03 15:47 --- Fixed in GCC-4.1.0 and higher. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24497
[Bug c++/24522] [4.0 Regression] htonl in optimized template function generates compiler warning
--- Comment #7 from gdr at gcc dot gnu dot org 2007-02-03 15:48 --- Fixed in GCC-4.1.0 and higher -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24522
[Bug middle-end/24570] [4.0 Regression] unit-at-a-time: debug info not emitted for unused global variables
--- Comment #6 from gdr at gcc dot gnu dot org 2007-02-03 15:49 --- Fixed in GCC-4.1.0 and higher, -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24570
[Bug tree-optimization/30375] [4.3 Regression] tree-ssa-dse incorrectly removes struct initialization
--- Comment #8 from dnovillo at gcc dot gnu dot org 2007-02-03 15:49 --- (In reply to comment #7) Is this now being looked into by Diego or Aldy? It wasn't. It is now. -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-02-03 15:28:16 |2007-02-03 15:49:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30375
[Bug target/24586] [4.0 regression] ICE in g++.dg/opt/mmx2.C
--- Comment #1 from gdr at gcc dot gnu dot org 2007-02-03 15:50 --- Won't fix in GCC-4.0.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24586
[Bug ada/24880] [4.0/4.1/4.2/4.3 regression] Conversion of user-defined integer type with Size fixed causes crashes
--- Comment #3 from gdr at gcc dot gnu dot org 2007-02-03 15:51 --- Won't fix in GCC-4.0.4. Adjusting milestone. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24880
[Bug c++/24907] [4.0 Regression] int x, ; accepted
--- Comment #7 from gdr at gcc dot gnu dot org 2007-02-03 16:02 --- Fixed in GCC-4.1.0. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24907
[Bug tree-optimization/24931] [4.0 Regression] uninitialized structure member after assignment
--- Comment #6 from gdr at gcc dot gnu dot org 2007-02-03 16:02 --- Fixed in GCC-4.1.0 -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24931
[Bug preprocessor/24976] [4.0/4.1/4.2/4.3 Regression] simple hexadecimal number and plus/minus and no space
--- Comment #6 from gdr at gcc dot gnu dot org 2007-02-03 16:03 --- Won't fix in GCC-4.0.x. Adjusting milestone. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24976
[Bug target/25042] [4.0 Regression] __float128 ICE on x86
--- Comment #8 from gdr at gcc dot gnu dot org 2007-02-03 16:03 --- Fixed in GCC-4.1.0. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25042
[Bug target/25043] [4.0 Regression] [m68k] ICE in instantiate_virtual_regs_lossage
--- Comment #3 from gdr at gcc dot gnu dot org 2007-02-03 16:04 --- Fixed in GCC-4.1.0 -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25043
[Bug target/25203] [4.0] enable checking failure in g++.dg/opt/mmx2.C
--- Comment #4 from gdr at gcc dot gnu dot org 2007-02-03 16:05 --- Fixed in GCC0-4.1.0 -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25203
[Bug driver/25208] [4.0/4.1/4.2/4.3 Regression] two outputs and -MMD
--- Comment #10 from gdr at gcc dot gnu dot org 2007-02-03 16:05 --- Won't fix in GCC-4.0.x. Adjusting milestone. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25208
[Bug target/25218] [4.0 Regression] ICE : in compensate_edge, at reg-stack.c:2795
--- Comment #10 from gdr at gcc dot gnu dot org 2007-02-03 16:06 --- Fixed in GCC-4.1.1. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25218
[Bug c/25314] [4.0/4.1/4.2/4.3 Regression] Unreachable code at beginning of switch statement is not reported anymore
--- Comment #8 from gdr at gcc dot gnu dot org 2007-02-03 16:06 --- Won't fix in GCC-4.0.x. Adjusting milestone. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25314
[Bug c++/25342] [4.0 Regression] internal compiler error: in lookup_member, at cp/search.c:1209
--- Comment #12 from gdr at gcc dot gnu dot org 2007-02-03 16:06 --- Fixed in GCC-4.1.0. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25342
[Bug target/25343] [4.0/4.1/4.2/4.3 regression] [m68k] testsuite failures
--- Comment #3 from gdr at gcc dot gnu dot org 2007-02-03 16:07 --- Won't fix in GCC-4.0.x. Adjusting milestone. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25343
[Bug c++/25357] [4.0 Regression] ICE in typeid
--- Comment #10 from gdr at gcc dot gnu dot org 2007-02-03 16:08 --- Fixed in GCC-4.1.0 ad higher. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25357
[Bug target/25448] [4.0/4.1/4.2/4.3 Regression] Unfounded warnings from the AVR backend
--- Comment #3 from gdr at gcc dot gnu dot org 2007-02-03 16:09 --- Won't fix in GCC-4.0.x. Adjusting milestone. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25448
[Bug debug/25468] [4.0 Regression] -g makes g++ loop forever
--- Comment #13 from gdr at gcc dot gnu dot org 2007-02-03 16:09 --- Fixed in GCC-4.1.2 and higher. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25468
[Bug gcov-profile/25551] [4.0 Regression] gcov incorrect count for lone return in block
--- Comment #4 from gdr at gcc dot gnu dot org 2007-02-03 16:10 --- Fixed in GCC-4.1.0 and higher. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25551
[Bug preprocessor/25717] [4.0 Regression] -dD does not list all defined macros (in particular, __STDC__)
--- Comment #10 from gdr at gcc dot gnu dot org 2007-02-03 16:10 --- Fixed in GCC-4.1.0 and higher. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25717
[Bug fortran/30689] equivalence modifies common block
--- Comment #1 from pault at gcc dot gnu dot org 2007-02-03 16:11 --- Apparently the address of lenstr gets shifted in the subroutine because of the equivalence statement. Is this the right behavior? This is what happens with my amd84: $ /irun/bin/gfortran --version GNU Fortran 95 (GCC) 4.3.0 20070202 (experimental) Copyright (C) 2006 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING [EMAIL PROTECTED] /home/fortran $ /irun/bin/gfortran -fdefault-integer-8 pr30689.f90 pr30689.f90:5.20: COMMON/QPSTAT/LASTYP,STATUS,CHRCTR,DIGIT,Intger,FP,dp,LENSTR 1 Warning: Padding of 4 bytes required before 'dp' in COMMON 'qpstat' at (1) pr30689.f90:16.20: Common/QPStat/LASTYP,STATUS,CHRCTR,DIGIT,Intger,FP,DP,LENSTR 1 Warning: Padding of 12 bytes required before 'dp' in COMMON 'qpstat' at (1) pr30689.f90:16.20: Common/QPStat/LASTYP,STATUS,CHRCTR,DIGIT,Intger,FP,DP,LENSTR 1 Warning: Named COMMON block 'qpstat' at (1) shall be of the same size Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30689
[Bug c/25805] [4.0 Regression] Incorrect handling of zero-initialized flexible arrays
--- Comment #6 from gdr at gcc dot gnu dot org 2007-02-03 16:11 --- Fixed in GCC-4.1.0 and higher -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25805
[Bug c++/25973] [4.0/4.1/4.2/4.3 Regression] Wrong warning: control reaches end of non-void function
--- Comment #5 from gdr at gcc dot gnu dot org 2007-02-03 16:14 --- Won't fix in GCC-4.0.x. Adjustine milestone. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25973
[Bug c/25993] [4.0 Regression] -std= produces incorrect preprocessor output for .S
--- Comment #8 from gdr at gcc dot gnu dot org 2007-02-03 16:14 --- Fixed in GCC-4.1.2 and higher. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25993
[Bug middle-end/26034] [4.0 Regression] gcc uses way too much stack space for this code
--- Comment #2 from gdr at gcc dot gnu dot org 2007-02-03 16:15 --- Won't fix in GCC-4.0.x. Closing. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26034
[Bug target/26098] [4.0 Regression] ICE in multiplication of 16-byte longlong vector on x86_64
--- Comment #4 from gdr at gcc dot gnu dot org 2007-02-03 16:15 --- Fixed in GCC-4.1.0. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26098
[Bug ada/26111] [4.0 Regression] Ada ICE in expand_assignment, at expr.c:3824
--- Comment #6 from gdr at gcc dot gnu dot org 2007-02-03 16:16 --- Won't fix in GCC-4.0.x. Closing. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26111
[Bug c++/26295] [4.0 Regression] Invalid namespace pointer seg fault
--- Comment #10 from gdr at gcc dot gnu dot org 2007-02-03 16:16 --- Fixed in GCC-4.1.1. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26295
[Bug fortran/30694] New: minval/maxval with +/-Inf
This is strange: $ cat minval.f90 program main integer :: i data i /z'7f80'/ real :: a(1) a(1) = transfer(i,a(1)) ! a(1) contains +Inf print *,a(1), minval(a) if (a(1) minval(a)) print *,Strange... end program main $ gfortran minval.f90 $ ./a.out +Infinity 3.4028235E+38 Strange... Ifort gets this right: $ ifort minval.f90 $ ./a.out Infinity Infinity We should really be initializing our starting values to +/-Inf, both in the library and the front end. Related, of course, to PR 30512. -- Summary: minval/maxval with +/-Inf Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org BugsThisDependsOn: 30512 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694
[Bug debug/26330] [4.0 regression] gcc generates code that does not allow retrieval of struct arguments with debugger
--- Comment #4 from gdr at gcc dot gnu dot org 2007-02-03 16:17 --- Won't fix in GCC-4.0.x. Closing. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26330
[Bug c++/26365] [4.0 Regression] ICE in finish_class_member_access_expr, at cp/typeck.c
--- Comment #12 from gdr at gcc dot gnu dot org 2007-02-03 16:19 --- Fixed in GCC-4.1.1 -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26365
[Bug c++/26496] [4.0 Regression] Pointer to member function
--- Comment #11 from gdr at gcc dot gnu dot org 2007-02-03 16:19 --- Fixed in GCC-4.1.2 -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26496
[Bug c++/26559] [4.0 Regression] ICE with __builtin_constant_p in template argument
--- Comment #8 from gdr at gcc dot gnu dot org 2007-02-03 16:19 --- Fixed in GCC-4.1.2 -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26559
[Bug fortran/29786] [4.1/4.2/4.3 Regression] rejects equivalence
--- Comment #7 from pault at gcc dot gnu dot org 2007-02-03 16:20 --- Brooks, It wasn't fair to deposit this one on you so I have taken it back. Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|brooks at gcc dot gnu dot |pault at gcc dot gnu dot org |org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29786
[Bug rtl-optimization/15023] -frename-registers is slow
--- Comment #13 from steven at gcc dot gnu dot org 2007-02-03 16:20 --- Haven't seen any reports of wrong-code coming out of register renaming in a while. Register renaming is enabled if loop unrolling / peeling is enabled. So the test coverage of this pass is much better than it used to be. I think that the wrong-code issue for this bug is fixed. -- steven at gcc dot gnu dot org changed: What|Removed |Added Keywords|ice-on-valid-code | Summary|-frename-registers is buggy |-frename-registers is slow |and slow| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15023
[Bug target/26560] [4.0/4.1 regression] mips: unable to find a register to spill in class 'FP_REGS'
--- Comment #5 from gdr at gcc dot gnu dot org 2007-02-03 16:20 --- Fixed in GCC-4.2.0 -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.0.4 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26560
