[Bug c++/40013] [4.4/4.5 Regression] ICE when creating a local array with size from the return value of a member function of an object in a nested class in a template class
--- Comment #2 from jakub at gcc dot gnu dot org 2009-05-05 06:37 --- Subject: Bug 40013 Author: jakub Date: Tue May 5 06:37:05 2009 New Revision: 147119 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147119 Log: PR c++/40013 * pt.c (tsubst): If magic NOP_EXPR with side-effects has no type, set it from its operand's type after tsubst_expr. * g++.dg/ext/vla7.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/vla7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40013
[Bug c/40023] New: type mismatch in address expression
Hi, when i compiling Firefox trunk version, got error include .i file. TIA == gcc -o prscanf.o -c -fvisibility=hidden -Wall -pthread -O2 -fPIC -UDEBUG -DMOZILLA_CLIENT=1 -DNDEBUG=1 -DHAVE_VISIBILITY_HIDDEN_ATTRIBUTE=1 -DHAVE_VISIBILITY_PRAGMA=1 -DXP_UNIX=1 -D_GNU_SOURCE=1 -DHAVE_FCNTL_FILE_LOCKING=1 -DLINUX=1 -DHAVE_LCHOWN=1 -DHAVE_STRERROR=1 -D_REENTRANT=1 -DFORCE_PR_LOG -D_PR_PTHREADS -UHAVE_CVAR_BUILT_ON_SEM -D_NSPR_BUILD_ -I/home/use r/d/src/ff-opt/dist/include/nspr -I/home/user/d/src/nsprpub/pr/include -I/home/user/d/src/nsprpub/pr/include/private /home/user/d/src/nsprpub/pr/src/io/prscanf.c /home/user/d/src/nsprpub/pr/src/io/prscanf.c: In function : /home/user/d/src/nsprpub/pr/src/io/prscanf.c:669: error: type mismatch in address expression struct * struct [1] * D.5714 = state-ap; /home/user/d/src/nsprpub/pr/src/io/prscanf.c:669: error: type mismatch in address expression struct * struct [1] * D.5714 = state-ap; /home/user/d/src/nsprpub/pr/src/io/prscanf.c:669: error: type mismatch in address expression struct * struct [1] * D.5714 = state-ap; /home/user/d/src/nsprpub/pr/src/io/prscanf.c:669: error: type mismatch in address expression struct * struct [1] * D.5714 = state-ap; /home/user/d/src/nsprpub/pr/src/io/prscanf.c:669: error: type mismatch in address expression struct * struct [1] * D.5714 = state-ap; /home/user/d/src/nsprpub/pr/src/io/prscanf.c:669: error: type mismatch in address expression struct * struct [1] * D.5714 = state-ap; /home/user/d/src/nsprpub/pr/src/io/prscanf.c:669: error: type mismatch in address expression struct * struct [1] * D.5714 = state-ap; /home/user/d/src/nsprpub/pr/src/io/prscanf.c:669: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. bash-4.0$ cc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr --libexecdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++ --disable-bootstrap --disable-multilib Thread model: posix gcc version 4.5.0 20090504 (experimental) (GCC) -- Summary: type mismatch in address expression Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: happyarch at gmail dot com GCC build triplet: x86_64 GCC host triplet: x86_64 GCC target triplet: x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40023
[Bug c/40023] type mismatch in address expression
--- Comment #1 from happyarch at gmail dot com 2009-05-05 06:40 --- Created an attachment (id=17801) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17801action=view) .i file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40023
[Bug c++/40013] [4.4/4.5 Regression] ICE when creating a local array with size from the return value of a member function of an object in a nested class in a template class
--- Comment #3 from jakub at gcc dot gnu dot org 2009-05-05 06:41 --- Subject: Bug 40013 Author: jakub Date: Tue May 5 06:41:33 2009 New Revision: 147120 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147120 Log: PR c++/40013 * pt.c (tsubst): If magic NOP_EXPR with side-effects has no type, set it from its operand's type after tsubst_expr. * g++.dg/ext/vla7.C: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/ext/vla7.C - copied unchanged from r147119, trunk/gcc/testsuite/g++.dg/ext/vla7.C Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/pt.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40013
[Bug c++/40013] [4.4/4.5 Regression] ICE when creating a local array with size from the return value of a member function of an object in a nested class in a template class
--- Comment #4 from jakub at gcc dot gnu dot org 2009-05-05 06:47 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40013
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #9 from dominiq at lps dot ens dot fr 2009-05-05 07:04 --- Created an attachment (id=17802) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17802action=view) Full summary for the tests with -fwhole-file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #10 from dominiq at lps dot ens dot fr 2009-05-05 07:05 --- After filtering the useless warning with a line regsub -all (^|\n)cc1: warning: command line option .-fwhole-file. is valid for Fortran but not for C $text text gcc/testsuite/lib/prune.expI get: === gfortran Summary === # of expected passes118146 # of unexpected failures144 # of expected failures 78 # of unsupported tests 906 I attached a full summary. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40018] ICE in output_constructor
-- 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 |2009-05-05 08:00:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40018
[Bug fortran/39995] [4.1/4.2 only] Open MP compile fails with internal compiler error
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2009-05-05 08:04 --- (In reply to comment #3) gcc version 4.1.2 20071124 (Red Hat 4.1.2-42) Well, your original bugreport is with gfortran 4.2.4, but anyway: both the 4.1 and 4.2 branches have been closed, so this won't be fixed. Your option is to upgrade (which can be done locally, no need to be superuser). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX Summary|Open MP compile fails with |[4.1/4.2 only] Open MP |internal compiler error |compile fails with internal ||compiler error http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39995
[Bug fortran/40008] F2008: Add NEWUNIT= for OPEN statement
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-05 08:05:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40008
[Bug c/40024] New: trunk/gcc-4.3/gcc: * emutls.c (emutls_destroy): Don' t fall out of the array bound.
gcj-compiled multithreaded programs trigger Segmentation Faults in emutls.c:76
This clearly comes from the deletion of an uninitialized pointer.
I found this patch on toolchain-commit, and it works, but it does not seem to
be committed to gcc subversion tree.
ref:
http://www.mail-archive.com/toolchain-comm...@blackfin.uclinux.org/msg01652.html#trunkgcc43gccemutlsc
Modified: trunk/gcc-4.3/gcc/emutls.c (3180 = 3181)
--- trunk/gcc-4.3/gcc/emutls.c 2009-02-12 18:30:30 UTC (rev 3180)
+++ trunk/gcc-4.3/gcc/emutls.c 2009-02-13 09:45:04 UTC (rev 3181)
@@ -70,7 +70,7 @@
pointer size = arr-size;
pointer i;
- for (i = 0; i size; ++i)
+ for (i = 0; i size - 1; ++i)
{
if (arr-data[i])
free (arr-data[i][-1]);
--
Summary: trunk/gcc-4.3/gcc: * emutls.c (emutls_destroy): Don' t
fall out of the array bound.
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: antoine dot rozenknop at gmail dot com
GCC target triplet: i586-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40024
[Bug fortran/34040] Support for DOUBLE_TYPE_SIZE != 64 targets
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2009-05-05 08:18 --- As far as I can say, the targets with this problem are: avr, bfin, h8300, picochip and sh (for some subtargets of sh). On avr, bfin, h8300 and picochip, we're doomed anyway because there is no double-sized type at all. On sh, we could use long double math calls. I'm making this into an enhancement; it will probably be very painful, because most of the front-end assumes FLOAT_TYPE_SIZE == 32 and DOUBLE_TYPE_SIZE == 64. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Severity|normal |enhancement GCC target triplet|sh-unknown-elf |sh, avr, bfin, h8300, ||picochip Priority|P3 |P5 Last reconfirmed|2007-11-16 23:42:54 |2009-05-05 08:18:07 date|| Summary|relation between kinds and C|Support for DOUBLE_TYPE_SIZE |types (for math builtins) |!= 64 targets |shouldn't be hardcoded | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34040
[Bug ada/40025] New: gnatmake does not honour project files' Library_Version exactly
The change introduced in [1] is most annoying; it means that gnatmake now thinks it knows better than I do what soname my libraries should have. This is wrong. As the maintainer of multiple libraries in Debian over multiple versions and many years, I know better and I insist that gnat honour *exactly* the soname that I specify in project files (and comply with the Law of Least Astonishment in the process). [1] http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01091.html To aggravate the problem, the behavior depends on the platform, which means that a project file will produce libraries with different sonames on different platforms! This makes it very difficult to maintain libraries on multiple platforms and ensure the sonames change whenever we want them to. Also, the documentation in 4.4 does not mention the change in behaviour; the documentation is therefore misleading (hence the severity minor instead of enhancement). I am going to patch Debian's gnat-4.4 to revert to the old behaviour. I am curious to know your rationale behind the change because right now I can see no good reason for it. If this rationale is convincing, perhaps the best would be to make the behaviour controllable from within the project file, i.e. project Lib is package Linker is for Library_Major_Minor_Id_Supported use False; end Linker; end Lib; Please consider this last part a request for enhancement. -- Summary: gnatmake does not honour project files' Library_Version exactly Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic at ludovic-brenta dot org GCC build triplet: pc=linux-gnu GCC host triplet: pc-linux-gnu GCC target triplet: pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40025
[Bug fortran/39576] gcc/fortran/error.c's error.c missing break
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2009-05-05 08:30 --- I can confirm it's missing a break: Index: error.c === --- error.c (revision 147105) +++ error.c (working copy) @@ -533,6 +533,7 @@ case 'u': arg[pos].type = TYPE_UINTEGER; + break; case 'l': c = *format++; -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords|wrong-code |diagnostic, patch Last reconfirmed|2009-04-07 09:23:55 |2009-05-05 08:30:24 date|| Summary|gcc/fortran/error.c's |gcc/fortran/error.c's |error_print - missing |error.c missing break |break ? | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39576
[Bug middle-end/40022] 4.4 regression breaks reply to all in alpine
--- Comment #6 from jakub at gcc dot gnu dot org 2009-05-05 09:02 ---
Reduced testcase:
extern void abort (void);
struct A
{
struct A *a;
};
struct B
{
struct A *b;
};
__attribute__((noinline))
struct A *
foo (struct A *x)
{
asm volatile ( : : g (x) : memory);
return x;
}
__attribute__((noinline))
void
bar (struct B *w, struct A *x, struct A *y, struct A *z)
{
struct A **c;
c = w-b;
*c = foo (x);
while (*c)
c = (*c)-a;
*c = foo (y);
while (*c)
c = (*c)-a;
*c = foo (z);
}
struct B d;
struct A e, f, g;
int
main (void)
{
f.a = g;
bar (d, e, f, 0);
if (d.b == 0
|| d.b-a == 0
|| d.b-a-a == 0
|| d.b-a-a-a != 0)
abort ();
return 0;
}
Looking into it.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-05-05 09:02:11
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022
[Bug fortran/40018] [4.4/4.5 Regression] ICE in output_constructor
--- Comment #2 from burnus at gcc dot gnu dot org 2009-05-05 09:07 --- Mark as regression based on Dominique's comment. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 Summary|ICE in output_constructor |[4.4/4.5 Regression] ICE in ||output_constructor Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40018
[Bug fortran/27452] gfortran support for non-standard sind,cosd and friends intrinsics
--- Comment #12 from ruben at tapir dot caltech dot edu 2009-05-05 09:36 --- (In reply to comment #10) These functions will *not* be implemented, period. And even if they would be implemented, they'd internally just return sin(arg*180/pi) co. The compiler and the runtime library don't actually calculate sin/cos themselves. They rely on libc and often on machine instructions, and they all work in radians too. End of discussion -- move along... I am happy enough with this decision. It is much better to have them consciously not implemented that having them implemented with dubious floating point accuracy. So, I'm moving along. I'm working on an implementation for myself right now, which needs only to satisfy my present accuracy requirements - it does not need to be a quality-grade implementation. I've seen that doing the argument reduction in degrees first does most of the trick for me. Surely much better can be done, especially for the inverse trig functions (which I do not need right now) - if you can afford the runtime cost. I'll look into Kargl's list of suggestions. There is no algorithm that would satisfy all users - those who need more accuracy will be willing to spend more runtime than others. Some programmers find that the usual math libraries are already too accurate for some of their needs, and sometimes hand-code faster (but less accurate) replacements. Good for them! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27452
[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40021
[Bug c/40023] type mismatch in address expression
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-05 09:54 --- Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40023
[Bug fortran/40018] [4.4/4.5 Regression] ICE in output_constructor
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-05 09:58 ---
Confirmed.
#1 0x00befdf6 in output_constructor (exp=0x77fd0cc0, size=80,
align=256) at /space/rguenther/src/svn/trunk/gcc/varasm.c:4716
4716 gcc_assert (pos = total_bytes);
(gdb) p pos
$1 = 4
(gdb) p total_bytes
$2 = 8
(gdb) call debug_generic_expr (exp)
{1, 2, 3, 4, 5, 6, 7, 8, 9, 10}
(gdb) call debug_tree (exp)
constructor 0x77fd0cc0
type array_type 0x75f3c0c0
type integer_type 0x77ee16c0 integer(kind=8) public DI
...
idx integer_cst 0x77eedae0 type integer_type 0x77ee16c0
integer(kind=8) constant 0
val integer_cst 0x77eed090 type integer_type 0x77ee1540
integer(kind=4) constant 1
...
there is a mismatch with the array element type and the actual element
types. Thus confirmed as a frontend issue.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40018
[Bug middle-end/40022] [4.4 Regression] breaks reply to all in alpine
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|4.4 regression breaks reply|[4.4 Regression] breaks |to all in alpine |reply to all in alpine Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022
[Bug middle-end/40022] [4.4/4.5 Regression] Alpine miscompilation
--- Comment #7 from jakub at gcc dot gnu dot org 2009-05-05 10:01 --- Introduced during tuples merge apparently (haven't bisected the tuples branch though). To me this looks like a phiprop bug. In *.alias (trunk, -O2) we have: # BLOCK 3 freq:9100 # PRED: 4 [91.0%] (true,exec) # VUSE .MEMD.2716_19 D.1614_8 = *cD.1606_1; cD.1606_9 = D.1614_8-aD.1593; # SUCC: 4 [100.0%] (fallthru,dfs_back,exec) # BLOCK 4 freq:1 # PRED: 2 [100.0%] (fallthru,exec) 3 [100.0%] (fallthru,dfs_back,exec) # cD.1606_1 = PHI cD.1606_4(2), cD.1606_9(3) # VUSE .MEMD.2716_19 D.1614_7 = *cD.1606_1; if (D.1614_7 != 0B) goto bb 3; else goto bb 5; # SUCC: 3 [91.0%] (true,exec) 5 [9.0%] (false,exec) # BLOCK 5 freq:900 # PRED: 4 [9.0%] (false,exec) # .MEMD.2716_20 = VDEF .MEMD.2716_19 D.1615_11 = fooD.1597 (yD.1602_10(D)); # .MEMD.2716_21 = VDEF .MEMD.2716_20 *cD.1606_1 = D.1615_11; goto bb 7; # SUCC: 7 [100.0%] (fallthru,exec) # BLOCK 6 freq:9100 # PRED: 7 [91.0%] (true,exec) # VUSE .MEMD.2716_21 D.1614_13 = *cD.1606_2; cD.1606_14 = D.1614_13-aD.1593; # SUCC: 7 [100.0%] (fallthru,dfs_back,exec) # BLOCK 7 freq:1 # PRED: 5 [100.0%] (fallthru,exec) 6 [100.0%] (fallthru,dfs_back,exec) # cD.1606_2 = PHI cD.1606_1(5), cD.1606_14(6) # VUSE .MEMD.2716_21 D.1614_12 = *cD.1606_2; if (D.1614_12 != 0B) goto bb 6; else goto bb 8; # SUCC: 6 [91.0%] (true,exec) 8 [9.0%] (false,exec) Note that the D.1614_12 = *cD.1606_2 read depends on the *cD.1606_1 = D.1615_11; store. In phiprop we have though: # BLOCK 3 freq:9100 # PRED: 4 [91.0%] (true,exec) cD.1606_9 = D.1614_8-aD.1593; # VUSE .MEMD.2716_19 D.2745_25 = D.1614_8-aD.1593; # SUCC: 4 [100.0%] (fallthru,dfs_back,exec) # BLOCK 4 freq:1 # PRED: 2 [100.0%] (fallthru,exec) 3 [100.0%] (fallthru,dfs_back,exec) # cD.1606_1 = PHI cD.1606_4(2), cD.1606_9(3) # D.1614_8 = PHI D.2744_24(2), D.2745_25(3) D.1614_7 = D.1614_8; if (D.1614_7 != 0B) goto bb 3; else goto bb 5; # SUCC: 3 [91.0%] (true,exec) 5 [9.0%] (false,exec) # BLOCK 5 freq:900 # PRED: 4 [9.0%] (false,exec) # .MEMD.2716_20 = VDEF .MEMD.2716_19 D.1615_11 = fooD.1597 (yD.1602_10(D)); # .MEMD.2716_21 = VDEF .MEMD.2716_20 *cD.1606_1 = D.1615_11; goto bb 7; # SUCC: 7 [100.0%] (fallthru,exec) # BLOCK 6 freq:9100 # PRED: 7 [91.0%] (true,exec) cD.1606_14 = D.1614_13-aD.1593; # VUSE .MEMD.2716_21 D.2746_26 = D.1614_13-aD.1593; # SUCC: 7 [100.0%] (fallthru,dfs_back,exec) # BLOCK 7 freq:1 # PRED: 5 [100.0%] (fallthru,exec) 6 [100.0%] (fallthru,dfs_back,exec) # cD.1606_2 = PHI cD.1606_1(5), cD.1606_14(6) # D.1614_13 = PHI D.1614_8(5), D.2746_26(6) D.1614_12 = D.1614_13; if (D.1614_12 != 0B) goto bb 6; else goto bb 8; # SUCC: 6 [91.0%] (true,exec) 8 [9.0%] (false,exec) Note that the D.1614_13 PHI now uses D.1614_8, which is correct *c content only if the *cD.1606_1 = D.1615_11; store wasn't performed. This store obviously can change what *c contains. Later passes then find out that D.1614_8 must be 0 to reach BB5 and BB7, so the whole second while loop is removed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.4 Regression] breaks |[4.4/4.5 Regression] Alpine |reply to all in alpine|miscompilation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022
[Bug target/38570] [arm] -mthumb generates sub-optimal prolog/epilog
--- Comment #9 from rearnsha at gcc dot gnu dot org 2009-05-05 10:06 --- (In reply to comment #8) Sorry for my ignorance to gcc. What types of instructions reload will add? Spilling and loading registers? and more? That's pretty much it, but... By reading the the implementation of thumb_far_jump_used_p() I can get the conclusion that if reload thinks there is a far jump, later pass won't change this decision. But if reload thinks there is no far jump, later pass still need to re-check the far jump existence and may change this decision. So if reload occasionally makes a wrong decision later pass should correct it, is it right? Once reload has completed we can't change the decision as to whether or not LR gets saved onto the stack or not. Unfortunately, that doesn't play well with constant pools. We sometimes need to inline these, and that might cause branches to be pushed out of range. Since we don't inline the pools until after reload has completed, that's a major stumbling block. The current code just isn't aware of these issues. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38570
[Bug middle-end/40022] [4.4/4.5 Regression] Alpine miscompilation
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-05-05 10:10 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords||wrong-code Last reconfirmed|2009-05-05 09:02:11 |2009-05-05 10:10:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #11 from dominiq at lps dot ens dot fr 2009-05-05 11:33 --- The summary of the attached file in comment #9 is: FAIL: gfortran.dg/bounds_check_strlen_1.f90 -O0 (test for excess errors) FAIL: gfortran.dg/bounds_temporaries_1.f90 -O (test for excess errors) FAIL: gfortran.dg/contained_3.f90 -O0 execution test FAIL: gfortran.dg/entry_17.f90 -O (test for warnings, line 27) FAIL: gfortran.dg/func_decl_4.f90 -O (test for errors, line 7) FAIL: gfortran.dg/generic_actual_arg.f90 -O (test for excess errors) FAIL: gfortran.dg/global_references_1.f90 -O (test for errors, line 39) FAIL: gfortran.dg/hollerith.f90 -O0 (test for excess errors) FAIL: gfortran.dg/hollerith_legacy.f90 -O (test for warnings, line 24) FAIL: gfortran.dg/import6.f90 -O (test for excess errors) FAIL: gfortran.dg/integer_exponentiation_2.f90 -O0 (test for excess errors) FAIL: gfortran.dg/intrinsic_actual_1.f -O (test for excess errors) FAIL: gfortran.dg/intrinsic_std_1.f90 -O scan-tree-dump original abort : dump file does not exist FAIL: gfortran.dg/pr20865.f90 -O (test for excess errors) FAIL: gfortran.dg/pr37243.f -O0 (test for excess errors) FAIL: gfortran.dg/sizeof.f90 -O0 (test for excess errors) FAIL: gfortran.dg/used_before_typed_4.f90 -O (test for excess errors) FAIL: gfortran.dg/g77/970625-2.f -O (test for excess errors) and with -m64 FAIL: gfortran.dg/loc_1.f90 -O1 (test for excess errors) With the patch in comment #8 of pr40006, the following failures are changed: FAIL: gfortran.dg/hollerith.f90 -O0 (test for excess errors) FAIL: gfortran.dg/hollerith_legacy.f90 -O (test for excess errors) FAIL: gfortran.dg/integer_exponentiation_2.f90 -O0 (test for excess errors) without patch === gfortran Summary for unix//-fwhole-file === # of expected passes28733 # of unexpected failures68 # of expected failures 16 # of unsupported tests 397 with patch === gfortran Summary === # of expected passes28751 # of unexpected failures66 # of expected failures 16 # of unsupported tests 397 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug c++/40007] specialization causes access problem in primary template
--- Comment #1 from jwakely dot gcc at gmail dot com 2009-05-05 11:34 --- Only fails in trunk. I haven't checked, but could it be caused by the fix for PR26693 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40007
[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS
--- Comment #6 from irar at il dot ibm dot com 2009-05-05 12:41 --- Reproduced on x86_64-suse-linux. Seems that, somehow, the vectorized version of loop in line 29 is performed, even though the number of scalar iterations is 1. -- irar at il dot ibm dot com changed: What|Removed |Added CC||irar at il dot ibm dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-05 12:41:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40021
[Bug c/40023] type mismatch in address expression
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-05 12:47 ---
Confirmed.
typedef __builtin_va_list va_list;
typedef struct {
va_list ap;
} ScanfState;
void
GetInt(ScanfState *state, long llval)
{
*__builtin_va_arg(state-ap,long *) = llval;
__builtin_va_end(state-ap);
}
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-05-05 12:47:11
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40023
[Bug c++/26693] [4.3/4.4/4.5 regression] Access checks not performed for types in templates
--- Comment #18 from jwakely dot gcc at gmail dot com 2009-05-05 13:07 --- I think this fix caused Bug 40007 -- jwakely dot gcc at gmail dot com changed: What|Removed |Added CC||jwakely dot gcc at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26693
[Bug c++/40007] specialization causes access problem in primary template
--- Comment #2 from jwakely dot gcc at gmail dot com 2009-05-05 13:08 --- gcc-4.5-20090327 works, gcc-4.5-20090402 doesn't -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40007
[Bug libfortran/39668] Wrongly read namelist with two dimensional array.
--- Comment #5 from toon at moene dot org 2009-05-05 13:33 --- Hmm, I said I'd put it in waiting until I found the definite wording in the Standard about this use of namelist values ... -- toon at moene dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39668
[Bug middle-end/40023] type mismatch in address expression
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-05 14:28 --- Bah. This va_list type stuff is exceptionally bad. The backends expect the bogus address form :/ -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40023
[Bug middle-end/40026] New: [4.5 Regression] ICE during gimplify_init_constructor
The linux kernel build on the gcc.opensuse.org base tester currently fails with ./cc1 -quiet sched.i kernel/sched.c: In function 'build_sched_domains': kernel/sched.c:6325: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Program received signal SIGSEGV, Segmentation fault. 0x007caa09 in is_gimple_mem_rhs_or_call (t=0x0) at /space/rguenther/src/svn/trunk/gcc/gimplify.c:633 633 if (is_gimple_reg_type (TREE_TYPE (t))) (gdb) bt #0 0x007caa09 in is_gimple_mem_rhs_or_call (t=0x0) at /space/rguenther/src/svn/trunk/gcc/gimplify.c:633 #1 0x007f7fb0 in gimplify_expr (expr_p=0x74efb7f8, pre_p=0x7fffb648, post_p=0x7fff8e28, gimple_test_f=0x7ca9ed is_gimple_mem_rhs_or_call, fallback=1) at /space/rguenther/src/svn/trunk/gcc/gimplify.c:7159 #2 0x007e4023 in gimplify_modify_expr (expr_p=0x7fff9718, pre_p=0x7fffb648, post_p=0x7fff8e28, want_value=0 '\0') at /space/rguenther/src/svn/trunk/gcc/gimplify.c:4379 #3 0x007f391d in gimplify_expr (expr_p=0x7fff9718, pre_p=0x7fffb648, post_p=0x7fff8e28, gimple_test_f=0x7bff1c is_gimple_stmt, fallback=0) at /space/rguenther/src/svn/trunk/gcc/gimplify.c:6516 #4 0x007e8724 in gimplify_stmt (stmt_p=0x7fff9718, seq_p=0x7fffb648) at /space/rguenther/src/svn/trunk/gcc/gimplify.c:5162 #5 0x007ca161 in gimplify_and_add (t=0x74efb7c0, seq_p=0x7fffb648) at /space/rguenther/src/svn/trunk/gcc/gimplify.c:390 #6 0x007df18b in gimplify_init_ctor_eval (object=0x74efb240, elts=0x74ef6200, pre_p=0x7fffb648, cleared=1 '\1') at /space/rguenther/src/svn/trunk/gcc/gimplify.c:3490 #7 0x007e0c65 in gimplify_init_constructor (expr_p=0x74ed8f10, pre_p=0x7fffb648, post_p=0x7fffa288, want_value=0 '\0', notify_temp_creation=0 '\0') -- Summary: [4.5 Regression] ICE during gimplify_init_constructor Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40026
[Bug c/40026] [4.5 Regression] ICE during gimplify_init_constructor
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-05 15:12 ---
Reduced testcase, maybe due to the C const expression changes(?)
typedef struct {
unsigned long bits[(((128)+64 -1)/64)];
} cpumask_t;
struct sched_domain {
cpumask_t span;
int flags;
};
void
cpu_to_allnodes_group(struct sched_domain *sd, int sched_smt_power_savings)
{
*sd = (struct sched_domain) {
.span = (cpumask_t) { { [0 ... (((128)+64 -1)/64)-1] = 0UL } },
.flags = (sched_smt_power_savings ? 256 : 0),
};
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|middle-end |c
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40026
[Bug bootstrap/39929] [4.5 Regression] Bootstrapping fails at stage 1 on powerpc-ibm-aix
--- Comment #16 from mmitchel at gcc dot gnu dot org 2009-05-05 15:13 --- Jules, is the ARM GNU/Linux build still broken? David, how about AIX? Thanks, -- Mark -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.5 Regression]|[4.5 Regression] |Bootstrapping fails at stage|Bootstrapping fails at stage |1 on powerpc-apple-darwin9 |1 on powerpc-ibm-aix |and powerpc-ibm-aix | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39929
[Bug bootstrap/40027] New: [4.4/4.5 regression] i686-pc-solaris2.10 bootstrap fails using Sun ld
As first reported here: http://gcc.gnu.org/ml/gcc-help/2009-04/msg00292.html bootstrapping 4.4.0 fails on Solaris 10 x86 if you configure with --build=i686-pc-solaris2.10 /var/tmp/build-gcc/gcc-4.4.0/configure --prefix=/opt/gcc/32-bit/4.4.0 --enable-languages=c --with-gnu-as --with-as=/var/tmp/build-gcc/binutils_2.18/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --with-gmp=/var/tmp/build-gcc/stage --with-mpfr=/var/tmp/build-gcc/stage --with-system-zlib --build=i686-pc-solaris2.10 /var/tmp/build/stage contains gmp-4.2.3 and mpfr-2.3.1 both built with --disable-shared, /var/tmp/build-gcc/binutils_2.18 contains (unsurprisingly) binutils 2.18 As recommended I'm using GNU as and Sun ld, but the build fails with: /bin/bash /var/tmp/build-gcc/gcc-4.4.0/libgcc/../mkinstalldirs . /var/tmp/build-gcc/gcc/./gcc/xgcc -B/var/tmp/build-gcc/gcc/./gcc/ -B/opt/gcc/32-bit/4.4.0/i686-pc-solaris2.10/bin/ -B/opt/gcc/32-bit/4.4.0/i686-pc-solaris2.10/lib/ -isystem /opt/gcc/32-bit/4.4.0/i686-pc-solaris2.10/include -isystem /opt/gcc/32-bit/4.4.0/i686-pc-solaris2.10/sys-include -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -shared -nodefaultlibs -Wl,-h,libgcc_s.so.1 -Wl,-z,text -Wl,-z,defs -Wl,-M,libgcc.map -o ./libgcc_s.so.1.tmp -g -O2 -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixtfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _fixunstfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatditf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o unwind-dw2_s.o unwind-dw2-fde_s.o unwind-sjlj_s.o gthr-gnat_s.o unwind-c_s.o emutls_s.o -lc rm -f ./libgcc_s.so if [ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1 ./libgcc_s.so.1.backup; else true; fi mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 ln -s libgcc_s.so.1 ./libgcc_s.so ld: fatal: symbol `__i686.get_pc_thunk.bx' is multiply-defined: (file /var/tmp/build-gcc/gcc/./gcc/crtbegin.o type=FUNC; file _enable_execute_stack_s.o type=FUNC); ld: fatal: symbol `__i686.get_pc_thunk.bx' is multiply-defined: (file /var/tmp/build-gcc/gcc/./gcc/crtbegin.o type=FUNC; file _absvsi2_s.o type=FUNC); ld: fatal: symbol `__i686.get_pc_thunk.bx' is multiply-defined: (file /var/tmp/build-gcc/gcc/./gcc/crtbegin.o type=FUNC; file _absvdi2_s.o type=FUNC); ld: fatal: symbol `__i686.get_pc_thunk.bx' is multiply-defined: (file /var/tmp/build-gcc/gcc/./gcc/crtbegin.o type=FUNC; file _addvsi3_s.o type=FUNC); ld: fatal: symbol `__i686.get_pc_thunk.bx' is multiply-defined: (file /var/tmp/build-gcc/gcc/./gcc/crtbegin.o type=FUNC; file _addvdi3_s.o type=FUNC); ld: fatal: symbol `__i686.get_pc_thunk.bx' is multiply-defined: (file /var/tmp/build-gcc/gcc/./gcc/crtbegin.o type=FUNC; file _subvsi3_s.o type=FUNC); ld: fatal: symbol `__i686.get_pc_thunk.bx' is multiply-defined: (file /var/tmp/build-gcc/gcc/./gcc/crtbegin.o type=FUNC; file _subvdi3_s.o type=FUNC); ld: fatal: symbol `__i686.get_pc_thunk.bx' is multiply-defined: (file /var/tmp/build-gcc/gcc/./gcc/crtbegin.o type=FUNC; file _mulvsi3_s.o type=FUNC); ld: fatal: symbol `__i686.get_pc_thunk.bx' is multiply-defined: (file /var/tmp/build-gcc/gcc/./gcc/crtbegin.o type=FUNC; file _mulvdi3_s.o type=FUNC); ld: fatal: symbol `__i686.get_pc_thunk.bx' is multiply-defined: (file /var/tmp/build-gcc/gcc/./gcc/crtbegin.o type=FUNC; file _negvsi2_s.o type=FUNC); ld: fatal: symbol `__i686.get_pc_thunk.bx' is multiply-defined: (file /var/tmp/build-gcc/gcc/./gcc/crtbegin.o type=FUNC; file _negvdi2_s.o type=FUNC); ld: fatal: symbol `__i686.get_pc_thunk.bx' is multiply-defined: (file /var/tmp/build-gcc/gcc/./gcc/crtbegin.o type=FUNC; file _popcountsi2_s.o type=FUNC); ld: fatal: symbol `__i686.get_pc_thunk.bx' is multiply-defined: (file /var/tmp/build-gcc/gcc/./gcc/crtbegin.o type=FUNC; file _popcountdi2_s.o type=FUNC); ld: fatal: symbol `__i686.get_pc_thunk.bx' is multiply-defined: (file /var/tmp/build-gcc/gcc/./gcc/crtbegin.o type=FUNC; file _powisf2_s.o type=FUNC); ld: fatal: symbol `__i686.get_pc_thunk.bx' is
[Bug target/38570] [arm] -mthumb generates sub-optimal prolog/epilog
--- Comment #10 from carrot at google dot com 2009-05-05 15:32 --- (In reply to comment #9) (In reply to comment #8) Sorry for my ignorance to gcc. What types of instructions reload will add? Spilling and loading registers? and more? That's pretty much it, but... Before register spilling, it must have used up all physical registers, including callee saved registers. Any saving of callee saved register should already have disabled this optimization. By reading the the implementation of thumb_far_jump_used_p() I can get the conclusion that if reload thinks there is a far jump, later pass won't change this decision. But if reload thinks there is no far jump, later pass still need to re-check the far jump existence and may change this decision. So if reload occasionally makes a wrong decision later pass should correct it, is it right? Once reload has completed we can't change the decision as to whether or not LR gets saved onto the stack or not. Unfortunately, that doesn't play well with constant pools. We sometimes need to inline these, and that might cause branches to be pushed out of range. Since we don't inline the pools until after reload has completed, that's a major stumbling block. The current code just isn't aware of these issues. It looks like a bug in current code and my patch tries to exploit it. We should fix it by checking far jump (or thumb_force_lr_save) in reload pass only and simply get this computed value in later pass. It looks computing the exact limit is very difficult if not impossible. Could we simply use a predefined constant which is much much smaller than the far jump threshold as the limit? For example, use the constant 256 which is only 1/8 of the far jump threshold. I don't expect a larger function can have any chance to satisfy other conditions: leaf function and doesn't use any callee saved registers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38570
[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS
--- Comment #7 from matz at gcc dot gnu dot org 2009-05-05 15:32 --- The problem is the expansion of this code: bb 4: ... D.1650_109 = D.1648_107 | 1; if (D.1650_109 != 0) goto bb 6; else goto bb 5; plus the fact that we need to insert something on edge 4-6. Note how the condition here is always true (should have been cleaned up by some tree optimization, but isn't, and we shouldn't have to rely on this anyway). Now expand comes and wants to generate a jump sequence implementing this if (D.1648_107 | 1) jump true_label. do_jump has code for an IOR expression jump: case TRUTH_ORIF_EXPR: ... do_jump (TREE_OPERAND (exp, 0), NULL_RTX, if_true_label); do_jump (TREE_OPERAND (exp, 1), if_false_label, if_true_label); bb 5 comes after bb 6 so the false edge is fallthrough, hence if_false_label here is NULL. Now we first emit a conditional jump to true_label for the left side: (jump_insn 32 31 0 pr40021.f:28 (set (pc) (if_then_else (ne (reg:CCZ 17 flags) (const_int 0 [0x0])) (label_ref 0) (pc))) -1 (nil)) and then for the right side. As this is a trivially true condition do_jump then decides to emit an unconditional jump plus barrier: (jump_insn 33 32 34 pr40021.f:28 (set (pc) (label_ref 0)) -1 (nil)) (barrier 34 33 0) Note how the first jump is useless now, it conditionally jumps to a label which when not taken will be jumped to anyway unconditionally. This all is fine so far, except that we need to remove fallthrough edges if expand_gimple_cond, if do_jump decided to emit a barrier. Unfortunately this removes one of the two edges, leaving only one. Now emitting on this edge doesn't need splitting anymore, the instruction is inserted at the end of the source block. But that insertion only expects one jump here and inserts before that, leaving the conditional jump before: (jump_insn 32 31 111 5 pr40021.f:28 (set (pc) (if_then_else (ne (reg:CCZ 17 flags) (const_int 0 [0x0])) (label_ref 48) (pc))) -1 (expr_list:REG_BR_PROB (const_int 5000 [0x1388]) (nil))) (insn 13 111 33 6 pr40021.f:20 (set (reg/v:SI 122 [ i ]) (const_int 1 [0x1])) -1 (nil)) (jump_insn 33 13 34 6 pr40021.f:28 (set (pc) (label_ref 48)) -1 (nil)) (barrier 34 33 35) (insn 13 is the inserted one). That's semantically not equivalent, if the conditional jump is taken the assignment i = 1 is left out, although it was supposed to be on exactly that edge. I'm going to fix this in expand_gimple_cond if this situation can happen by cleaning up the generated jump sequence. -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-05-05 12:41:15 |2009-05-05 15:32:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40021
[Bug libgcj/39747] [4.4/4.5 Regression] Installation documentation should suggest building libgmp as PIC
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 Summary|[4.4/4.5 Regression]|[4.4/4.5 Regression] |libjavamath is linking |Installation documentation |against libgmp |should suggest building ||libgmp as PIC http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39747
[Bug rtl-optimization/39871] [4.3/4.4/4.5 regression] Code size increase on ARM due to inferior CSE
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 Summary|[4.3/4.4/4.5 regression] CSE|[4.3/4.4/4.5 regression] |doesn't work|Code size increase on ARM ||due to inferior CSE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39871
[Bug middle-end/39898] [4.5 regression] Revision 146763 caused g++.dg/tree-ssa/ehcleanup-1.C
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39898
[Bug target/40023] [4.5 Regression] type mismatch in address expression
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-05-05 15:44 --- Which back-end expects that form? Only x86-64 or others? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |target Keywords||ice-on-valid-code Summary|type mismatch in address|[4.5 Regression] type |expression |mismatch in address ||expression Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40023
[Bug middle-end/39954] [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c
--- Comment #12 from mmitchel at gcc dot gnu dot org 2009-05-05 15:48 --- Yes, we've been discussing the interaction between attributes and the type system for at least a decade. :-) In type-theoretic terms, the address of a packed int has type pointer-to-packed-int, not pointer-to-int. And the latter can be safely converted to the former, but the former cannot be safely converted to the latter. Michael, unfortunately, if it was your change that introduced this regression, you are responsible for solving the problem. The Right Answer, as you suggest, is to include the packed attribute in the type system, but I suspect that will be a major effort. Unfortunately, I don't know what else to suggest... -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39954
[Bug middle-end/39958] [4.5 Regression] OMP tasking creates invalid gimple
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39958
[Bug tree-optimization/39974] [4.5 regression] Bogus array subscript is below array bounds warning in compiler generated code
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39974
[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug middle-end/39978] [4.5 Regression] SEGV compiling libiberty/regex.c in stage2
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39978
[Bug c++/39987] [4.3/4.4/4.5 Regression] Rejects default argument that is a template via access failure
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39987
[Bug c/40026] [4.5 Regression] ICE during gimplify_init_constructor
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40026
[Bug target/39856] [4.4/4.5 Regression] ICE in subst_stack_regs_pat, at reg-stack.c:1386
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39856
[Bug c++/39862] [4.5 Regression] verify_eh_tree failed with -O2
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39862
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #12 from dominiq at lps dot ens dot fr 2009-05-05 15:57 --- Reduced test for gfortran.dg/contained_3.f90: [ibook-dhum] f90/bug% cat contained_3_red.f90 MODULE ksbin1_aux_mod CONTAINS FUNCTION binden() INTEGER :: binden INTEGER :: setbd binden = 0 ENTRY setbd() setbd = 99 END FUNCTION binden END MODULE ksbin1_aux_mod PROGRAM test integer setbd ! setbd is external, since not use assoc. print *, setbd () if (setbd () .ne. 42 ) call abort () call foo contains subroutine foo USE ksbin1_aux_mod ! module setbd is available print *, setbd () if (setbd () .ne. 99 ) call abort () end subroutine END PROGRAM test INTEGER FUNCTION setbd() setbd=42 END FUNCTION setbd [ibook-dhum] f90/bug% gfc contained_3_red.f90 [ibook-dhum] f90/bug% a.out 42 99 [ibook-dhum] f90/bug% gfc -fwhole-file contained_3_red.f90 [ibook-dhum] f90/bug% a.out 42 42 Abort -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug middle-end/39886] [4.5 Regression] ICE in purge_dead_edges, at cfgrtl.c:2274
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39886
[Bug c/39959] [4.5 Regression] IMA is broken
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39959
[Bug middle-end/39954] [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c
--- Comment #13 from hjl dot tools at gmail dot com 2009-05-05 15:59 --- (In reply to comment #12) Michael, unfortunately, if it was your change that introduced this regression, you are responsible for solving the problem. The Right Answer, as you suggest, is to include the packed attribute in the type system, but I suspect that will be a major effort. Unfortunately, I don't know what else to suggest... We have the aligned attribute in the type system. Can't we implement typedef struct timeval packed __attribute__((packed)); as typedef struct timeval packed __attribute__((aligned(1))); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39954
[Bug tree-optimization/39960] [4.5 Regression] struct-reorg is broken
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39960
[Bug bootstrap/39977] [4.5 Regression] r146817 broke bootstrap on PA
--- Comment #8 from mmitchel at gcc dot gnu dot org 2009-05-05 16:00 --- Steve -- Is there still an issue here? -- Mark -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39977
[Bug bootstrap/39977] [4.5 Regression] r146817 broke bootstrap on PA
--- Comment #9 from sje at cup dot hp dot com 2009-05-05 16:05 --- This bug is fixed, I don't think this bug fixes PR 29209 but I will look into that bug some more and post a comment there. Resolving as fixed. -- sje at cup dot hp dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39977
[Bug bootstrap/39929] [4.5 Regression] Bootstrapping fails at stage 1 on powerpc-ibm-aix
--- Comment #17 from jules at gcc dot gnu dot org 2009-05-05 16:07 --- This still seems to be broken as of r147126 for ARM Linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39929
[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40021
[Bug middle-end/39666] [4.3/4.4/4.5 Regression] spurious warning with ranged-switch statements
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39666
[Bug target/40023] [4.5 Regression] type mismatch in address expression
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-05-05 16:08 --- Subject: Bug 40023 Author: rguenth Date: Tue May 5 16:08:24 2009 New Revision: 147127 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147127 Log: 2009-05-05 Richard Guenther rguent...@suse.de PR middle-end/40023 * builtins.c (gimplify_va_arg_expr): Properly build the address. * gcc.c-torture/compile/pr40023.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr40023.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40023
[Bug middle-end/39927] [4.5 Regression]: build breakage for cris-elf building libstdc++-v3
--- Comment #12 from mmitchel at gcc dot gnu dot org 2009-05-05 16:09 --- HP, is this still a problem? -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39927
[Bug middle-end/40022] [4.4/4.5 Regression] Alpine miscompilation
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-05-05 16:10 --- Subject: Bug 40022 Author: rguenth Date: Tue May 5 16:09:46 2009 New Revision: 147128 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147128 Log: 2009-05-05 Richard Guenther rguent...@suse.de PR tree-optimization/40022 * tree-ssa-phiprop.c (struct phiprop_d): Exchange vop_stmt for the only vuse. (phivn_valid_p): Fix tuplification error, simplify. (phiprop_insert_phi): Add dumps. (propagate_with_phi): Simplify. * gcc.c-torture/execute/pr40022.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr40022.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-phiprop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022
[Bug tree-optimization/39955] [4.5 Regression] struct-layout-1 test failures passing struct containing _Decimal32
--- Comment #14 from mmitchel at gcc dot gnu dot org 2009-05-05 16:10 --- Janis, is this still an issue? -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39955
[Bug middle-end/40023] type mismatch in address expression
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-05-05 16:10 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Component|target |middle-end Keywords|ice-on-valid-code | Resolution||FIXED Summary|[4.5 Regression] type |type mismatch in address |mismatch in address |expression |expression | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40023
[Bug middle-end/40022] [4.4 Regression] Alpine miscompilation
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-05-05 16:10 --- Fixed for trunk. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.5.0 Summary|[4.4/4.5 Regression] Alpine |[4.4 Regression] Alpine |miscompilation |miscompilation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022
[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS
--- Comment #8 from matz at gcc dot gnu dot org 2009-05-05 16:11 --- Created an attachment (id=17803) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17803action=view) fix for the problem I'm regstrapping this patch, it fixes the problem in the testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40021
[Bug middle-end/40022] [4.4 Regression] Alpine miscompilation
--- Comment #11 from mmitchel at gcc dot gnu dot org 2009-05-05 16:11 --- Richard, can this be closed now? -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, mmitchel at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022
[Bug target/30210] [4.5 Regression] Altivec builtins have inaccurate return types
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210
[Bug middle-end/40028] New: RFE - Add GPU acceleration library to gcc
RFE - It would be great if gcc had a couple (ATI / NVidia) of GPU libraries that gcc could use to speed up programs similar to what is done here: http://www.pgroup.com/resources/accel.htm The PGI 8.0 x64+GPU compilers automatically analyze whole program structure and data, split portions of the application between the x64 CPU and GPU as specified by user directives, and define and generate an optimized mapping of loops to automatically use the parallel cores, hardware threading capabilities and SIMD vector capabilities of modern GPUs. In addition to directives and pragmas that specify regions of code or functions to be accelerated, the PGI Fortran and C compilers will support user directives that give the programmer fine-grained control over the mapping of loops, allocation of memory, and optimization for the GPU memory hierarchy. The PGI compilers generate unified x64+GPU object files and executables that manage all movement of data to and from the GPU device while leveraging all existing host-side utilities—linker, librarians, makefiles—and require no changes to the existing standard HPC Linux/x64 programming environment. A demo of a program written in the OpenCL Language is here: http://www.youtube.com/watch?v=r1sN1ELJfNofeature=channel_page The GPGPU Programming Developer Webpage is here: http://gpgpu.org/developer Some applications can be ran hundreds of times faster, see this page at NVidia. http://www.nvidia.com/object/cuda_home.html If we could use run-time-linking to select either the ATI or NVidia (PlayStation?) library at run-time then gcc would remain portable and offer the speedup on any platform that utilized a graphics card with a GPU (not just x86). The middle end could attempt to determine which functions (or groups of code, inlinable, functions, loops, etc.) would be best to offload to the GPU (if a supported one were detected) and then resulting program would run much faster for most people by using the GPU as a coprocessor. Thanks, Rob -- Summary: RFE - Add GPU acceleration library to gcc Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: * GCC host triplet: * GCC target triplet: * http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40028
[Bug middle-end/40028] RFE - Add GPU acceleration library to gcc
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-05 16:25 --- Yes GPU libraries would be nice but this needs a lot of work to begin with. First you have to support the GPUs. This also amounts to doubling the support. If you really want them, since this is open source, start contributing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40028
[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS
--- Comment #9 from hjl dot tools at gmail dot com 2009-05-05 16:28 ---
(In reply to comment #8)
Created an attachment (id=17803)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17803action=view) [edit]
fix for the problem
I'm regstrapping this patch, it fixes the problem in the testcase.
Shouldn't
+ {
+ rtx insn;
+ remove_edge (false_edge);
+ /* Now, we have a single successor block, if we have insns to
+insert on the remaining edge we potentially will insert
+it at the end of this block (if the dest block isn't feasible)
+in order to avoid splitting the edge. This insertion will take
+place in front of the last jump. But we might have emitted
+multiple jumps (conditional and one unconditional) to the
+same destination. Inserting in front of the last one then
+is a problem. See PR 40021. We fix this by deleting all
+jumps except the last unconditional one. */
+ insn = PREV_INSN (get_last_insn ());
+ /* Make sure we have an unconditional jump. Otherwise we're
+confused. */
+ gcc_assert (JUMP_P (insn) !any_condjump_p (insn));
+ for (insn = PREV_INSN (insn); insn != BB_HEAD (bb);)
+ {
+ insn = PREV_INSN (insn);
+ if (JUMP_P (NEXT_INSN (insn)))
+ delete_insn (NEXT_INSN (insn));
+ }
+ }
in a standalone function since it is used twice?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40021
[Bug middle-end/40022] [4.4 Regression] Alpine miscompilation
--- Comment #12 from jakub at gcc dot gnu dot org 2009-05-05 16:53 --- It hasn't been fixed on the 4.4 branch yet, so it can't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022
[Bug debug/40012] [4.5 Regression] Bad debug info for local variables
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-debug Summary|Bad debug info for local|[4.5 Regression] Bad debug |variables |info for local variables Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40012
[Bug tree-optimization/39955] [4.5 Regression] struct-layout-1 test failures passing struct containing _Decimal32
--- Comment #15 from janis at gcc dot gnu dot org 2009-05-05 17:26 --- The struct-layout-1 failures were fixed by the patch from Michael Matz, which Michael Meissner checked in as r147021. The new failures in gcc.target/powerpc still exist and, as far as I know, haven't yet been investigated. The struct-layout-1 failures didn't show up with GCC built as a 64-bit executable because of the bug reported in PR39986, which caused dfp tests to be used as compile-only and skipped using decimal float types in the struct-layout-1 compat tests. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39955
[Bug bootstrap/39977] [4.5 Regression] r146817 broke bootstrap on PA
--- Comment #10 from sje at cup dot hp dot com 2009-05-05 17:52 --- The test case in comment #1 of PR 29209 still happens on ToT with hppa*-*-hpux11.11 so it doesn't look like backporting this fix will fix anything. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39977
[Bug middle-end/40029] New: [4.5 Regression] Big degradation on swim/mgrid on powerpc 32/64 after alias improvement merge (gcc r145494)
CPU2000's swim and mgrid had ~10% slowdown after the merge of the alias improvement branch. GCC was configured with the following: /gcc/HEAD/configure --target=powerpc64-linux --host=powerpc64-linux --build=powerpc64-linux --with-cpu=default32 --enable-threads=posix --enable-shared --enable-__cxa_atexit --with-gmp=/gmp --with-mpfr=mpfr --with-long-double-128 --enable-decimal-float --enable-secure-plt --disable-bootstrap --disable-alsa --prefix=/install/gcc/HEAD build_alias=powerpc64-linux host_alias=powerpc64-linux target_alias=powerpc64-linux --enable-languages=c,c++,fortran --no-create --no-recursion Compile flags used: -m[32|64] -O3 -mcpu=power[4|5|6] -ffast-math -ftree-loop-linear -funroll-loops -fpeel-loops Will provide more details soon. -- Summary: [4.5 Regression] Big degradation on swim/mgrid on powerpc 32/64 after alias improvement merge (gcc r145494) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: luisgpm at linux dot vnet dot ibm dot com GCC build triplet: powerpc*-*-* GCC host triplet: powerpc*-*-* GCC target triplet: powerpc*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40029
[Bug c++/29209] ICE optimizing passing long double to abstract method while in other abstract's impl
--- Comment #12 from sje at cup dot hp dot com 2009-05-05 17:54 --- I retested the test case in comment#1 on a hppa2.0w-hp-hpux11.11 box and it still gives an ICE with 4.4.0 and with ToT (r147128). I don't have a PA linux box so I did not test the example from comment #9 on a linux box. -- sje at cup dot hp dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-05 17:54:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29209
[Bug target/40030] New: vector float * vector float + vector float should produce only vmaddfp
Take:
#define vector __vector
vector float f(vector float a, vector float b, vector float c)
{
return a * b + c;
}
--- CUT ---
Currently for Powerpc (with -O2 -maltivec), we get:
vspltisw 0,-1
vslw 0,0,0
vmaddfp 3,2,3,0
vaddfp 2,3,4
But this should really just produce:
vmaddfp 2,2,3,4
--
Summary: vector float * vector float + vector float should
produce only vmaddfp
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40030
[Bug target/40030] vector float * vector float + vector float should produce only vmaddfp
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-05 18:03 ---
Another testcase but using intrinsics:
#include altivec.h
vector float f(vector float a, vector float b, vector float c)
{
vector float d = (vector float)(-0.0f);
return vec_add (c, vec_madd (a, b, d));
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40030
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #13 from pault at gcc dot gnu dot org 2009-05-05 18:12 --- (In reply to comment #12) ...snip... [ibook-dhum] f90/bug% a.out 42 42 Abort This turns out to be the same bug as that which caused the segfault in gas_dyn.f90. Use associated procedures need to be excluded from the part of the patch in trans-decl.c. Once this is done, the whole polyhedron suite compiles and runs at any level of optimization. The updated patch is regtesting right now. It still needs module procedures to be incorporated but it is nearly there. I have been thinking hard about type cheating - I am likely to allow it for std-f77 and legacy, to warn with other standards and fail with -pedantic. However, I am open to better proposals. I have not checked yet whether type cheating references to a procedure need a double declaration or not (ie. to avoid typing troubles in the back end). Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug target/40031] New: ARM broken with addresses in PHIs with -fPIC
Testcase:
double c;
double d;
double *f(int a)
{
if(a) return c;
return d;
}
--
Summary: ARM broken with addresses in PHIs with -fPIC
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, build
Severity: blocker
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40031
[Bug target/40031] [4.5 Regression] ARM broken with addresses in PHIs with -fPIC
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40031
[Bug bootstrap/39929] [4.5 Regression] Bootstrapping fails at stage 1 on powerpc-ibm-aix
--- Comment #18 from pinskia at gcc dot gnu dot org 2009-05-05 19:15 --- (In reply to comment #16) Jules, is the ARM GNU/Linux build still broken? Yes it is still broken; I filed a seperate bug for that though, see PR 40031. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39929
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #14 from jv244 at cam dot ac dot uk 2009-05-05 19:28 --- (In reply to comment #13) I have been thinking hard about type cheating - I am likely to allow it for std-f77 and legacy, to warn with other standards and fail with -pedantic. this sounds reasonable. Note the other testcases in PR40006 that cheat somewhat beyond the 'type', I think they should be treated on the same footing. Note that type cheating and the like should only be allowed for calls that involve procedures with an implicit interface, it should still be a hard error if there is an explicit interface. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/39998] Procedure Pointer Assignments: Statement Functions Internal Functions
-- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2009-05-05 20:17:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39998
[Bug c/40032] New: [4.5 regression] ICE with incomplete type in struct
The following invalid testcase triggers an ICE on the trunk:
=
struct A
{
enum E : 8;
};
=
bug.c:3: warning: 'anonymous' is narrower than values of its type
'
Segmentation fault
Please submit a full bug report, [etc.]
The C++ frontend is not affected.
The bug appeared between 2009-04-24 and 2009-05-04.
--
Summary: [4.5 regression] ICE with incomplete type in struct
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40032
[Bug c/40032] [4.5 regression] ICE with incomplete type in struct
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40032
[Bug fortran/39996] Double typing of function results not detected
--- Comment #1 from janus at gcc dot gnu dot org 2009-05-05 20:35 --- Extended test case, including six similar cases, of which only the first three are detected (comment #0 corresponds to case 'E'): ! Detected: interface real function A () end function end interface real :: A ! Error: Symbol 'a' at (1) already has basic type of REAL ! Detected: real :: B interface real function B () ! Error: Function 'b' at (1) already has a type of REAL end function end interface ! Detected: interface function C () real :: C end function end interface real :: C ! Error: Symbol 'c' at (1) already has basic type of REAL ! Not Detected: real :: D interface function D () real :: D end function end interface ! Not Detected: interface function E () result (s) real ::s end function end interface real :: E ! Not Detected: real :: F interface function F () result (s) real ::s end function F end interface end -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-05 20:35:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39996
[Bug fortran/39998] Procedure Pointer Assignments: Statement Functions Internal Functions
--- Comment #1 from janus at gcc dot gnu dot org 2009-05-05 20:41 --- Subject: Bug 39998 Author: janus Date: Tue May 5 20:41:00 2009 New Revision: 147133 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147133 Log: 2009-05-05 Janus Weil ja...@gcc.gnu.org PR fortran/39998 * expr.c (gfc_check_pointer_assign): Check for statement functions and internal procedures in procedure pointer assignments. 2009-05-05 Janus Weil ja...@gcc.gnu.org PR fortran/39998 * gfortran.dg/proc_ptr_17.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_17.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39998
[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
--- Comment #12 from pinskia at gcc dot gnu dot org 2009-05-05 20:45 --- (In reply to comment #11) I have a gdb session open, but I'm rather clueless. I have this: but the following fails: (gdb) call debug_tree((*x).generic.type.next_variant) Cannot access memory at address 0x7fff5d302f78 That is because gdb uses the same stack as the program when doing a call so of course that will fail :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
[Bug fortran/39998] Procedure Pointer Assignments: Statement Functions Internal Functions
--- Comment #2 from janus at gcc dot gnu dot org 2009-05-05 20:47 --- Fixed in r147133. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39998
[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
--- Comment #13 from pinskia at gcc dot gnu dot org 2009-05-05 20:47 --- Is there a self contained (one file) source that I could use? Gfortran is known to emit a lot of blocks inside blocks and I wonder if this is the cause. And the GC is only setup to do chaining through the sibling blocks not the subblocks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
[Bug c/40033] New: [4.5 regression] ICE with inavlid statement expression
The following invalid testcase triggers an ICE on trunk:
==
void foo()
{
({ 0,; });
}
==
bug.c: In function 'foo':
bug.c:3: error: expected expression before ';' token
bug.c:3: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in useless_type_conversion_p_1, at tree-ssa.c:900
Please submit a full bug report, [etc.]
--
Summary: [4.5 regression] ICE with inavlid statement expression
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40033
[Bug c++/36740] [c++0x] Compiler accepts invalid syntax in variadic template specialization
--- Comment #3 from reichelt at gcc dot gnu dot org 2009-05-05 21:19 --- *** This bug has been marked as a duplicate of 39639 *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36740
[Bug c++/39639] no diagnostic for ill-formed pack expansion
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39639
[Bug libstdc++/39909] non-TLS version of std::call_once causes terminate
--- Comment #7 from redi at gcc dot gnu dot org 2009-05-05 21:33 --- Subject: Bug 39909 Author: redi Date: Tue May 5 21:32:38 2009 New Revision: 147137 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147137 Log: 2009-05-05 Jonathan Wakely jwakely@gmail.com PR libstdc++/39909 * include/std/mutex (__get_once_functor_lock, __get_once_mutex, __set_once_functor_lock_ptr): Replace global lock object with local locks on global mutex. * src/mutex.cc (__get_once_functor_lock, __get_once_mutex, __set_once_functor_lock_ptr): Likewise, keeping old function to preserve ABI. (__once_proxy): Use pointer to local lock if set, global lock otherwise. * config/abi/pre/gnu.ver: Add new symbols to new ABI version. * testsuite/util/testsuite_abi.cc: Add GLIBCX_3.4.12 version. * testsuite/30_threads/call_once/39909.cc: New. Added: trunk/libstdc++-v3/testsuite/30_threads/call_once/39909.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/abi/pre/gnu.ver trunk/libstdc++-v3/include/std/mutex trunk/libstdc++-v3/src/mutex.cc trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39909
[Bug libstdc++/39909] non-TLS version of std::call_once causes terminate
--- Comment #8 from redi at gcc dot gnu dot org 2009-05-05 21:44 --- Subject: Bug 39909 Author: redi Date: Tue May 5 21:44:27 2009 New Revision: 147138 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147138 Log: 2009-05-05 Jonathan Wakely jwakely@gmail.com PR libstdc++/39909 * include/std/mutex (__get_once_functor_lock, __get_once_mutex, __set_once_functor_lock_ptr): Replace global lock object with local locks on global mutex. * src/mutex.cc (__get_once_functor_lock, __get_once_mutex, __set_once_functor_lock_ptr): Likewise, keeping old function to preserve ABI. (__once_proxy): Use pointer to local lock if set, global lock otherwise. * config/abi/pre/gnu.ver: Add new symbols to new ABI version. * testsuite/util/testsuite_abi.cc: Add GLIBCX_3.4.12 version. * testsuite/30_threads/call_once/39909.cc: New. Added: branches/gcc-4_4-branch/libstdc++-v3/testsuite/30_threads/call_once/39909.cc Modified: branches/gcc-4_4-branch/libstdc++-v3/ChangeLog branches/gcc-4_4-branch/libstdc++-v3/config/abi/pre/gnu.ver branches/gcc-4_4-branch/libstdc++-v3/include/std/mutex branches/gcc-4_4-branch/libstdc++-v3/src/mutex.cc branches/gcc-4_4-branch/libstdc++-v3/testsuite/util/testsuite_abi.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39909
[Bug tree-optimization/39974] [4.5 regression] Bogus array subscript is below array bounds warning in compiler generated code
--- Comment #1 from reichelt at gcc dot gnu dot org 2009-05-05 22:00
---
Here's a reduced version without includes:
===
struct X
{
X(int, const int = 0);
~X();
};
X x[2][3] = { { 0, 0, 0 }, { 0, 0, 0 } };
struct A
{
A(int);
};
struct B
{
A a1, a2, a3, a4, a5, a6;
};
B b[42] =
{
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 },
{ 0, 0, 0, 0, 0, 0 }
};
===
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39974
