[Bug c/42764] New: Bad exit code in interrupt functions using local vars and calling a function, when compiled without optimization
Problem:
When compiling WITHOUT OPTIMIZATION, the code
generated for INTERRUPT FUNCTIONS using LOCAL VARS
and CALLING A FUNCTION will corrupt the stack.
This bug persists at least since GCC-3.3.4.
How-To-Repeat:
This is the C-code:
extern void function(void);
void __attribute__((interrupt)) VECT_INTBAD(void) {
int x, y, z;
x=1;
y=2;
z=3;
function();
}
Compiled with
v850e-unknown-elf-gcc -mv850e -mdisable-callt -fverbose-asm -nostartfiles
-nodefaultlibs -nostdlib -Wa,-a,-aln=bad_code.ASM
-o bad_code.o -c bad_code.c -save-temps
will generate:
28_VECT_INTBAD:
29 501A add -16, sp
30 0002 63570D00 st.w r10, 12[sp]
31 0006 63F70100 st.w ep, 0[sp]
32 000a 63270500 st.w gp, 4[sp]
33 000e 630F0900 st.w r1, 8[sp]
34 0012 40F6 movhi hi(__ep), r0, ep
35 0016 3EF6 movea lo(__ep), ep, ep
36 001a 4026 movhi hi(__gp), r0, gp
37 001e 2426 movea lo(__gp), gp, gp
38 0022 031E88FF addi -120, sp, sp
39 0026 63FF7500 st.w r31, 116[sp]
40 002a 63177100 st.w r2, 112[sp]
41 002e 63276D00 st.w gp, 108[sp]
42 0032 63376900 st.w r6, 104[sp]
43 0036 633F6500 st.w r7, 100[sp]
44 003a 63476100 st.w r8, 96[sp]
45 003e 634F5D00 st.w r9, 92[sp]
46 0042 635F5900 st.w r11, 88[sp]
47 0046 63675500 st.w r12, 84[sp]
48 004a 636F5100 st.w r13, 80[sp]
49 004e 63774D00 st.w r14, 76[sp]
50 0052 637F4900 st.w r15, 72[sp]
51 0056 63874500 st.w r16, 68[sp]
52 005a 638F4100 st.w r17, 64[sp]
53 005e 63973D00 st.w r18, 60[sp]
54 0062 639F3900 st.w r19, 56[sp]
55 0066 63A73500 st.w r20, 52[sp]
56 006a 63AF3100 st.w r21, 48[sp]
57 006e 63B72D00 st.w r22, 44[sp]
58 0072 63BF2900 st.w r23, 40[sp]
59 0076 63C72500 st.w r24, 36[sp]
60 007a 63CF2100 st.w r25, 32[sp]
61 007e 63D71D00 st.w r26, 28[sp]
62 0082 63DF1900 st.w r27, 24[sp]
63 0086 63E71500 st.w r28, 20[sp]
64 008a 63EF1100 st.w r29, 16[sp]
65 008e 541A add -12,sp #,
66 0090 03E8 mov sp,r29 #,
67 0092 0152 mov 1,r10 #, tmp39
68 0094 7D571100 st.w r10,16[r29]# x, tmp39
69 0098 0252 mov 2,r10 #, tmp40
70 009a 7D571500 st.w r10,20[r29]# y, tmp40
71 009e 0352 mov 3,r10 #, tmp41
72 00a0 7D571900 st.w r10,24[r29]# z, tmp41
73 00a4 2A06 mov hilo(_function),r10 #, tmp42
73
74 00aa 80FF0400 jarl .+4,r31 ; add 4,r31 ; jmp r10 # tmp42
74 44FA6A00
75 00b2 1D18 mov r29,sp #,
76 00b4 23FF7500 ld.w 116[sp], r31
77 00b8 23177100 ld.w 112[sp], r2
78 00bc 23276D00 ld.w 108[sp], gp
79 00c0 23376900 ld.w 104[sp], r6
80 00c4 233F6500 ld.w 100[sp], r7
81 00c8 23476100 ld.w 96[sp], r8
82 00cc 234F5D00 ld.w 92[sp], r9
83 00d0 235F5900 ld.w 88[sp], r11
84 00d4 23675500 ld.w 84[sp], r12
85 00d8 236F5100 ld.w 80[sp], r13
86 00dc 23774D00 ld.w 76[sp], r14
87 00e0 237F4900 ld.w 72[sp], r15
88 00e4 23874500 ld.w 68[sp], r16
89 00e8 238F4100 ld.w 64[sp], r17
90 00ec 23973D00 ld.w 60[sp], r18
91 00f0 239F3900 ld.w 56[sp], r19
92 00f4 23A73500 ld.w 52[sp], r20
93 00f8 23AF3100 ld.w 48[sp], r21
94 00fc 23B72D00 ld.w 44[sp], r22
95 0100 23BF2900 ld.w 40[sp], r23
96 0104 23C72500 ld.w 36[sp], r24
97 0108 23CF2100 ld.w 32[sp], r25
98 010c 23D71D00 ld.w 28[sp], r26
99 0110 23DF1900 ld.w 24[sp], r27
100 0114 23E71500 ld.w 20[sp], r28
101 0118 23EF1100 ld.w 16[sp], r29
102 011c 031E7800 addi 120, sp, sp
103 0120 23F70100 ld.w 0[sp], ep
104 0124 23270500 ld.w 4[sp], gp
105 0128 230F0900 ld.w 8[sp], r1
106 012c 23570D00 ld.w 12[sp], r10
107 0130 031E1000 addi 16, sp, sp
108 0134 E0074001 reti
109
[Bug tree-optimization/33763] [4.3/4.4/4.5 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining
--- Comment #17 from pinskia at gcc dot gnu dot org 2010-01-16 06:52 --- Note on the trunk it fails at -O1 but not -O2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763
[Bug middle-end/42749] [4.5 Regression] -O2 and verify_stmts failed again
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-01-16 06:43 --- This is harder than I thought. CCing the original author of this part of the code. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42749
[Bug middle-end/42749] [4.5 Regression] -O2 and verify_stmts failed again
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-01-16 06:21 --- (In reply to comment #6) > It is caused by revision 146831: Exposed by, not really caused in this case. The bug was there before the extra checking was added. I am looking into fixing tailr. Note we do go from an overflowing being wrapping to be undefined too. So there is more than just fixing types too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42749
[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"
--- Comment #27 from phil at nwl dot cc 2010-01-16 01:08 --- (In reply to comment #26) > Hey, I'm telling you the way we all library maintainers (like me) and users > check the library: they all fetch everything (either mainline or 4_4-branch, > or > whatever) via svn, make, make check. Now you want to do something else, you > want to check the compiler + library you have already installed, but your > obviously missing the testsuite, because you didn't build it yourself. Now, > you > are on your own, because I have no idea how and where to fetch only the > testsuite of the specific GCC you are running on the specific Linux you are > running, and then adjust everything to run it with your already installed > compiler, this is not the normal way we do those tests. > > To repeat, the point was checking that your Linux and your hardware are sane, > because I told you already that we know **for sure** that on current (and no > so > current) machines and Ubuntu, OpenSUSE, Fedora, whatever, that snippet works > perfectly fine and *much* more than it, a whole testsuite. > > So, it's up to you, I'll keep this open: if over the nest month or so you > provide the testresults you get for either your specific GCC, current > 4_4-branch, or current mainline on your OS + hardware, we can hope to make > progress on your issue, otherwise nobody will commit suicide, and the issue > will be simply closed for lack of meaningful feedback from submitter. It's ok man, no offense here. I really didn't want to stomp on any feet. All I'm trying to do is to figure out why I'm having this problem and how to fix it. Abusing this bug tracker for a little conversation was a pleasure to me, getting you upset wasn't my intention. My apologies for that. So I will just do as you say and try to fix my distribution (or bug it's maintainers) instead of getting into your way. Anyway, thanks a lot for your help so far. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libfortran/42763] internal compiler error: in instantiate_virtual_regs_lossage ERROR 1
-- kargl at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42763
[Bug libfortran/42763] internal compiler error: in instantiate_virtual_regs_lossage ERROR 1
--- Comment #3 from sgk at troutmask dot apl dot washington dot edu 2010-01-16 00:22 --- Subject: Re: internal compiler error: in instantiate_virtual_regs_lossage ERROR 1 On Sat, Jan 16, 2010 at 12:04:27AM -, hcolella at gmail dot com wrote: > > --- Comment #2 from hcolella at gmail dot com 2010-01-16 00:04 --- > I was advised to upgrade g77. I did so, to 4.3, > and it did not fix my problem. > What to you mean by 'did not fix my problem'? I can compile your code with 4.3.5, 4.4.3, and 4.5.0. Make sure you have completely removed the 4.0.1 version of the software. You may be picking up the wrong version. What does 'gfortran -v' report? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42763
[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"
--- Comment #26 from paolo dot carlini at oracle dot com 2010-01-16 00:05 --- Hey, I'm telling you the way we all library maintainers (like me) and users check the library: they all fetch everything (either mainline or 4_4-branch, or whatever) via svn, make, make check. Now you want to do something else, you want to check the compiler + library you have already installed, but your obviously missing the testsuite, because you didn't build it yourself. Now, you are on your own, because I have no idea how and where to fetch only the testsuite of the specific GCC you are running on the specific Linux you are running, and then adjust everything to run it with your already installed compiler, this is not the normal way we do those tests. To repeat, the point was checking that your Linux and your hardware are sane, because I told you already that we know **for sure** that on current (and no so current) machines and Ubuntu, OpenSUSE, Fedora, whatever, that snippet works perfectly fine and *much* more than it, a whole testsuite. So, it's up to you, I'll keep this open: if over the nest month or so you provide the testresults you get for either your specific GCC, current 4_4-branch, or current mainline on your OS + hardware, we can hope to make progress on your issue, otherwise nobody will commit suicide, and the issue will be simply closed for lack of meaningful feedback from submitter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libfortran/42763] internal compiler error: in instantiate_virtual_regs_lossage ERROR 1
--- Comment #2 from hcolella at gmail dot com 2010-01-16 00:04 --- I was advised to upgrade g77. I did so, to 4.3, and it did not fix my problem. (In reply to comment #1) > Please update your compiler to at least the latest > 4.2.x release. A better choice would be a vesion > from the 4.4 releases. In fact, you can get pre-compiled > version of gfortran from the gfortran wiki. > > The 4.0.1 version of the compiler has not been > supported for years. Yes, I wrote years. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42763
[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"
--- Comment #25 from phil at nwl dot cc 2010-01-15 23:49 --- (In reply to comment #24) > (In reply to comment #23) > > What we want to do is to run the libstdc++ testsuite with my > > distribution-provided g++, in order to see whether it's generally broken or > > not, right? > > Wrong. You can't use one compiler (older, by the way), with a newer libstdc++. > > > And what I'm criticising here is that I have to compile *anything* of the > > gcc-sources in order to run the testsuite. I see no sense in building any > > binaries at all, since I already have all binaries (executables as well as > > libraries) in order to run the tests?! > > You don't, you *need* a complete new GCC. Ok. So what's the point in doing this, then? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug fortran/42680] [fortran-dev, Regression] ICE in gimplify_expr, at gimplify.c:7176
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2010-01-15 23:20 --- Same test case fails differently on dev then it did on trunk. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42680
[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"
--- Comment #24 from paolo dot carlini at oracle dot com 2010-01-15 23:07 --- (In reply to comment #23) > What we want to do is to run the libstdc++ testsuite with my > distribution-provided g++, in order to see whether it's generally broken or > not, right? Wrong. You can't use one compiler (older, by the way), with a newer libstdc++. > And what I'm criticising here is that I have to compile *anything* of the > gcc-sources in order to run the testsuite. I see no sense in building any > binaries at all, since I already have all binaries (executables as well as > libraries) in order to run the tests?! You don't, you *need* a complete new GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"
--- Comment #23 from phil at nwl dot cc 2010-01-15 22:32 --- (In reply to comment #22) > (In reply to comment #21) > > (In reply to comment #18) > > > Just build everything with default configure options, then go inside the > > > libstdc++-v3 *build* dir and type 'make check'. > > > > Ah, hmm. Well, having to compile everything in order to run the tests using > > an > > external compiler is a bit of a bummer, isn't it? > > Maybe there is a communication problem here: I meant, *the whole GCC*, Yes, it seems so. > normally, with no special options, to keep things simple. If you want, you can > exclude java, which normally takes a while, and fortran, and objective c, the > languages you don't need in other terms: just pass --enable-languages=c++ and > nothing else. What we want to do is to run the libstdc++ testsuite with my distribution-provided g++, in order to see whether it's generally broken or not, right? And what I'm criticising here is that I have to compile *anything* of the gcc-sources in order to run the testsuite. I see no sense in building any binaries at all, since I already have all binaries (executables as well as libraries) in order to run the tests?! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug rtl-optimization/42691] [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG
--- Comment #23 from jingyu at google dot com 2010-01-15 22:25 --- Subject: Re: [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG On Fri, Jan 15, 2010 at 1:59 PM, jakub at gcc dot gnu dot org wrote: > > > --- Comment #21 from jakub at gcc dot gnu dot org 2010-01-15 21:59 > --- > FYI, if you always want to test a NaN, you'd need to use big endian ordering > for some arches, If the floating point format is compatible with IEEE754, on little-endian machine, double float 0x7ff0,,, means an infinite number. on big-endian machine, double float 0x7ff0,,, means a very small number. Then this test does not have problem. >plus there are targets which don't support NaN at all or where > a double isn't as big as 4 shorts. This is troublesome. We need to limit the test case to run on machines where sizeof(double)=4*sizeof(short) only. Any idea how to add conditions to the test case? Thanks for pointing it out! > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > You are the assignee for the bug, or are watching the assignee. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691
[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"
--- Comment #22 from paolo dot carlini at oracle dot com 2010-01-15 22:15 --- (In reply to comment #21) > (In reply to comment #18) > > Just build everything with default configure options, then go inside the > > libstdc++-v3 *build* dir and type 'make check'. > > Ah, hmm. Well, having to compile everything in order to run the tests using an > external compiler is a bit of a bummer, isn't it? Maybe there is a communication problem here: I meant, *the whole GCC*, normally, with no special options, to keep things simple. If you want, you can exclude java, which normally takes a while, and fortran, and objective c, the languages you don't need in other terms: just pass --enable-languages=c++ and nothing else. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug rtl-optimization/42691] [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG
--- Comment #22 from jingyu at gcc dot gnu dot org 2010-01-15 22:11 --- Subject: Bug 42691 Author: jingyu Date: Fri Jan 15 22:11:43 2010 New Revision: 155949 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155949 Log: Backport from mainline(4.5) to fix a regression bug. 2010-01-15 Jing Yu PR rtl-optimization/42691 * combine.c (try_combine): Set changed_i3_dest to 1 when I2 and I3 set a pseudo to a constant and are merged, and adjust comments. 2010-01-15 Jing Yu PR rtl-optimization/42691 * gcc.c-torture/execute/pr42691.c: New. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr42691.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/combine.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691
[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"
--- Comment #21 from phil at nwl dot cc 2010-01-15 22:07 --- (In reply to comment #18) > Just build everything with default configure options, then go inside the > libstdc++-v3 *build* dir and type 'make check'. Ah, hmm. Well, having to compile everything in order to run the tests using an external compiler is a bit of a bummer, isn't it? Compiling will take some time on this X40, so please be patient. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug rtl-optimization/42691] [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG
--- Comment #21 from jakub at gcc dot gnu dot org 2010-01-15 21:59 --- FYI, if you always want to test a NaN, you'd need to use big endian ordering for some arches, plus there are targets which don't support NaN at all or where a double isn't as big as 4 shorts. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691
[Bug rtl-optimization/42691] [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG
--- Comment #20 from jingyu at gcc dot gnu dot org 2010-01-15 21:54 --- Subject: Bug 42691 Author: jingyu Date: Fri Jan 15 21:54:01 2010 New Revision: 155948 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155948 Log: 2010-01-15 Jing Yu PR rtl-optimization/42691 * combine.c (try_combine): Set changed_i3_dest to 1 when I2 and I3 set a pseudo to a constant and are merged, and adjust comments. 2010-01-15 Jing Yu PR rtl-optimization/42691 * gcc.c-torture/execute/pr42691.c: New. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr42691.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691
[Bug rtl-optimization/42691] [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2010-01-15 21:50 --- > I have reverted the whole patch on mainline and 4.4 That was unnecessary. > I will modify the testcase and send the whole patch again. Just send a message to gcc-patches@ and apply the fix to the testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691
[Bug rtl-optimization/42691] [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG
--- Comment #18 from jingyu at google dot com 2010-01-15 21:46 --- Subject: Re: [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG On Fri, Jan 15, 2010 at 1:42 PM, mikpe at it dot uu dot se wrote: > > > --- Comment #17 from mikpe at it dot uu dot se 2010-01-15 21:42 --- > (In reply to comment #16) >> --- testsuite/gcc.c-torture/execute/pr42691.c (revision 155944) >> +++ testsuite/gcc.c-torture/execute/pr42691.c (working copy) >> @@ -26,7 +26,8 @@ >> >> i++; >> } >> - *deletedEntry = 0.0; >> + if (deletedEntry) >> + *deletedEntry = 0.0; >> return 0; >> } > > Thanks, with this fix the test case exits normally with -O0 on both arm and > i686, but abort()s as intended with -Os -mthumb with 4.4 (pre-fix) on arm. > Sorry for the inconvenience. I only tested "-mthumb", which happened to work. I should have proofread the code carefully. I have reverted the whole patch on mainline and 4.4 I will modify the testcase and send the whole patch again. > BTW, gcc-4.3.4 is also broken but gcc-4.2.4 works. Thanks for testing 4.3.4. I don't have a working 4.3.x on hands. I tested gcc-4.2.1, which works. So this is a regression bug. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > You are the assignee for the bug, or are watching the assignee. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691
[Bug rtl-optimization/42691] [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG
--- Comment #17 from mikpe at it dot uu dot se 2010-01-15 21:42 --- (In reply to comment #16) > --- testsuite/gcc.c-torture/execute/pr42691.c (revision 155944) > +++ testsuite/gcc.c-torture/execute/pr42691.c (working copy) > @@ -26,7 +26,8 @@ > > i++; >} > - *deletedEntry = 0.0; > + if (deletedEntry) > +*deletedEntry = 0.0; >return 0; > } Thanks, with this fix the test case exits normally with -O0 on both arm and i686, but abort()s as intended with -Os -mthumb with 4.4 (pre-fix) on arm. BTW, gcc-4.3.4 is also broken but gcc-4.2.4 works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691
[Bug rtl-optimization/42691] [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG
--- Comment #16 from jingyu at google dot com 2010-01-15 21:14 --- Subject: Re: [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG Sorry. The following change would fix it on X86. Index: testsuite/gcc.c-torture/execute/pr42691.c === --- testsuite/gcc.c-torture/execute/pr42691.c (revision 155944) +++ testsuite/gcc.c-torture/execute/pr42691.c (working copy) @@ -26,7 +26,8 @@ i++; } - *deletedEntry = 0.0; + if (deletedEntry) +*deletedEntry = 0.0; return 0; } On Fri, Jan 15, 2010 at 1:11 PM, mikpe at it dot uu dot se wrote: > > > --- Comment #15 from mikpe at it dot uu dot se 2010-01-15 21:11 --- > The test case added with this PR appears to be rather broken. On armv5tel with > gcc-4.3 or 4.4 (without the fix) -Os -mthumb I do get an abort(), which seems > deliberate. However, replacing -Os -mthumb with -O0 -g results in a segfault > because deletedEntry is NULL when "*deletedEntry = 0.0;" is executed. It also > segfaults in the same way on i686/x86_64/powerpc64 even with old non-broken > compiler versions. > > Looking at the code I don't see how it could ever work, that is exit normally > with status 0. The test case would fail on ARM -mthumb -Os due to the bug described in the thread. I will fix the problem immediately. Jing > > > -- > > mikpe at it dot uu dot se changed: > > What |Removed |Added > > CC| |mikpe at it dot uu dot se > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > You are the assignee for the bug, or are watching the assignee. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691
[Bug rtl-optimization/42691] [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG
--- Comment #15 from mikpe at it dot uu dot se 2010-01-15 21:11 --- The test case added with this PR appears to be rather broken. On armv5tel with gcc-4.3 or 4.4 (without the fix) -Os -mthumb I do get an abort(), which seems deliberate. However, replacing -Os -mthumb with -O0 -g results in a segfault because deletedEntry is NULL when "*deletedEntry = 0.0;" is executed. It also segfaults in the same way on i686/x86_64/powerpc64 even with old non-broken compiler versions. Looking at the code I don't see how it could ever work, that is exit normally with status 0. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691
[Bug rtl-optimization/42691] [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG
--- Comment #14 from sezeroz at gmail dot com 2010-01-15 20:59 --- For me, the testcase doesn't abort or exit successfully, it just segfaults (i686, x86_64, gcc-4.3, 4.4). $ gcc44 -g -O2 -Wall -W pr42691.c $ gdb ./a.out GNU gdb Fedora (6.8-24.fc9) [...] Program received signal SIGSEGV, Segmentation fault. add (key=0xbf9eef38, table=0xbf9eef28) at pr42691.c:29 29*deletedEntry = 0.0; -- sezeroz at gmail dot com changed: What|Removed |Added CC||sezeroz at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691
[Bug libfortran/42763] internal compiler error: in instantiate_virtual_regs_lossage ERROR 1
--- Comment #1 from kargl at gcc dot gnu dot org 2010-01-15 20:43 --- Please update your compiler to at least the latest 4.2.x release. A better choice would be a vesion from the 4.4 releases. In fact, you can get pre-compiled version of gfortran from the gfortran wiki. The 4.0.1 version of the compiler has not been supported for years. Yes, I wrote years. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42763
[Bug libfortran/42763] New: internal compiler error: in instantiate_virtual_regs_lossage ERROR 1
internal compiler error: in instantiate_virtual_regs_lossage, at function c:3476 The command line is simply a "return" at the end of a subroutine (line:561). It is followed by an "end" on the next line. c c c ** c pltlib ** c ** c c c the following collection of subroutines is designed c to aid in constructing graphic outputs from fortran c programs. these subroutines are designed to run on c a sun under openwindows and drive a postscript printer. c the user only needs to designate the destination device c in subroutine initpt--all other routines function as c nearly identically as possible on all devices. c c c ccopyright 1991,1992 by h. j. melosh. all rights reserved. c cthis code is provided by the author to designated users for cthe purpose of cooperative research. it may not be distributed cto other users without the express consent of the author. c cunder no circumstances is this code to be used for commercial cpurposes without the author's written consent. c c ***legal notice*** c c this code was written as part of the research of h. j. melosh and his c collaborators. none of these authors make any warranty, express or c implied, or assumes any legal liability or responsibility for the c accuracy, completeness or usefulness of this code or its results, c or represents that its use would not infringe privately owned rights. c c c c* c c the subroutines are self documenting--the user is advised c to study the comments in the fortran listing of each c routine. the routines that are availabe for the user are: c c plotxy--draws a complete x,y plot, either line or scatter c contur--draws a complete x,y,z contour plot c axis--draws a labeled axis c initpt--initializes the graphic device c legend--writes a label or ascii string on the plot c line--draws a continuous line between points c newpen--chooses a pen c number--writes a floating point number on the plot c offset--shifts the coordinate zero and scale c scale--scales an array in rational units. use as input c for axis or arbgrd c symbol--draws one of 16 symbols on the plot c arbgrd--draws a contour plot on an irregular grid: specialized for c finite element codes. c c written by h.j.melosh, july, 1985. modified for the mac ii c october, 1987. plot routines improved january, 1989 c contouring improved march 1992 c c adapted for the sun using pgplot by h. j. melosh, may 1992 c c subroutine plotxy(xl,xu,labelx,labely,xarray,yarray, & npts,irep,isym) c c program to produce an x-y line or scatter plot of arrays (xarray) and c (yarray). the user specifies the coordinates (xl(1),xl(2)) c of the bottom left corner of the plot and coordinates (xu(1), c xu(2)) of the upper right corner. the axes are labeled, c respectively, 'labelx' and 'labely'. (npts) is the number of c points plotted. c c xarray and yarray are not altered by this routine. c c the switch irep has the following effects: c c irep=0: the coordinate axes are scaled to accomodate the full c range of xarray and yarray. the axes are plotted, c then the logical coordinates are shifted and scaled to c accomodate the arrays, which are then plotted. c scales are returned to their default values when the c plot is complete. this is the normal mode for a c single line or scatter plot. c c irep=1: same as irep=0 except that the scales are not returned c to their default values after plotting. this is the c normal mode for the first plot in a sequence of overlaid c plots. c c irep>1: only the arrays are plotted, using a previously set c scale. this mode is used for the second and subsequent c plots in a sequence of overlaid plots. c c irep<0: same as irep>1, except that the scales are returned to c their default values after the plot is complete. used c to terminate a sequence of overlaid plots. c alternatively, the user may make a call to offset c with parameters offset(0.,0.,1.,1.) to perform this c function after the last plot with irep>1. c c the zero axes are drawn as a dashed line if they
[Bug c++/42761] std::bind doesn't work for simple class types
--- Comment #2 from paolo dot carlini at oracle dot com 2010-01-15 20:25 --- Thanks Jason! If we manage to solve this tough problem, then I know how to enable also the volatile / const volatile call operators + other improvements bringing us real close to the WP. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42761
[Bug c++/42761] std::bind doesn't work for simple class types
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Component|libstdc++ |c++ Last reconfirmed|2010-01-15 18:13:58 |2010-01-15 20:15:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42761
[Bug rtl-optimization/42691] [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG
--- Comment #13 from jingyu at gcc dot gnu dot org 2010-01-15 19:09 --- Subject: Bug 42691 Author: jingyu Date: Fri Jan 15 19:08:53 2010 New Revision: 155945 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155945 Log: Backport from mainline(4.5) to fix a regression bug. 2010-01-15 Jing Yu PR rtl-optimization/42691 * combine.c (try_combine): Set changed_i3_dest to 1 when I2 and I3 set a pseudo to a constant and are merged, and adjust comments. 2010-01-15 Jing Yu PR rtl-optimization/42691 * gcc.c-torture/execute/pr42691.c: New. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr42691.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/combine.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691
[Bug c++/42758] [4.5 Regression] ICE on assert() in function with complex(?) template argument
--- Comment #5 from hjl dot tools at gmail dot com 2010-01-15 18:57 --- It is triggered by revision : http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00188.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jason at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-15 18:57:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42758
[Bug rtl-optimization/42691] [4.4/4.5 regression] problematic REG_EQUAL note added to SUBREG
--- Comment #12 from jingyu at gcc dot gnu dot org 2010-01-15 18:47 --- Subject: Bug 42691 Author: jingyu Date: Fri Jan 15 18:47:45 2010 New Revision: 155944 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155944 Log: 2010-01-15 Jing Yu PR rtl-optimization/42691 * combine.c (try_combine): Set changed_i3_dest to 1 when I2 and I3 set a pseudo to a constant and are merged, and adjust comments. 2010-01-15 Jing Yu PR rtl-optimization/42691 * gcc.c-torture/execute/pr42691.c: New. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr42691.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691
[Bug lto/42762] New: ICE in get_resolution() when compiling a C++ program with -flto -fuse-linker-plugin
cat bug.cc
int main(void)
{
try { } catch (int) { }
return 0;
}
g++ -flto -fuse-linker-plugin bug.cc
lto1: internal compiler error: in get_resolution, at lto-streamer-in.c:1519
Please submit a full bug report,
with preprocessed source if appropriate.
GCC 4.5.0 20100114.
--
Summary: ICE in get_resolution() when compiling a C++ program
with -flto -fuse-linker-plugin
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d dot g dot gorbachev at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42762
[Bug libstdc++/42761] std::bind doesn't work for simple class types
--- Comment #1 from jwakely dot gcc at gmail dot com 2010-01-15 18:34 --- OK, I'll revert it all tomorrow if necessary -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42761
[Bug target/42753] _Complex_I is reported as undeclared. Code builds with Sun compiler.
--- Comment #10 from joseph at codesourcery dot com 2010-01-15 18:32 --- Subject: Re: _Complex_I is reported as undeclared. Code builds with Sun compiler. On Fri, 15 Jan 2010, david dot kirkby at onetel dot net wrote: > Is this is trivial fix that could be implemted quickly, or it will require > quite a bit of work, and so I should not expect a solution soon? It could be implemented quickly if someone familiar with fixincludes wishes to fix it. > Is there any workaround you can suggest? Would simply adding > > #define _Complex_I _Complex_I > #define complex _Complex > #define _Imaginary_I_Imaginary_I > #define imaginary _Imaginary > #undef I > #define I _Imaginary_I > > at the top of the source files work? Adding copies of the non-GCC definitions certainly won't work. I suppose you could add #undef of the problem macros followed by #define to values valid for GCC (such as those used by glibc), after including any system headers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753
[Bug fortran/38822] Compile-time simplification of x**(real)
--- Comment #16 from kargl at gcc dot gnu dot org 2010-01-15 18:31 --- Unassign myself as I have no time to work on gfortran. -- kargl at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|kargl at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38822
[Bug target/42753] _Complex_I is reported as undeclared. Code builds with Sun compiler.
--- Comment #9 from david dot kirkby at onetel dot net 2010-01-15 18:25 --- (In reply to comment #8) > Fixincludes is part of the compiler sources, and it is the part that should > work around GCC-incompatible system headers (such as this one) by making > fixed copies when GCC is built and installed. Thus, a failure to fix it > indicates a limitation in fixincludes, and the fix would be to enhance > fixincludes and rebuild GCC. > > It is not part of the C front end, so "c" is not the correct component. Do > not change components back if a maintainer changes them to be more accurate. Is this is trivial fix that could be implemted quickly, or it will require quite a bit of work, and so I should not expect a solution soon? Is there any workaround you can suggest? Would simply adding #define _Complex_I _Complex_I #define complex _Complex #define _Imaginary_I_Imaginary_I #define imaginary _Imaginary #undef I #define I _Imaginary_I at the top of the source files work? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753
[Bug libstdc++/42761] std::bind doesn't work for simple class types
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-15 18:13:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42761
[Bug libstdc++/42761] std::bind doesn't work for simple class types
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Severity|normal |blocker Priority|P3 |P1 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42761
[Bug libstdc++/42761] New: std::bind doesn't work for simple class types
Unfortunately, this very simple example, which we have been discussing for
other reasons, regresses very badly vs tr1. Unfortunately the C++ front-end
doesn't seem ready for a conforming result_of :( Can we prepare a reduced
testcase for Jason?
Maybe he can already tell us whether an error message of the form: "sorry,
unimplemented: unable to determine the declared type of expression
declval()()" points to an issue fixable any time soon...
Otherwise, I'm afraid that for 4.5.0 we have to revert consistently most C++0x
work in .
///
#include
struct X {
typedef int result_type;
int operator()() { return 0; }
int operator()() const { return 1; }
};
const auto b = std::bind(X());
b(); // b is const, so must return 1
--
Summary: std::bind doesn't work for simple class types
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paolo dot carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42761
[Bug middle-end/42760] [4.4 Regression] ICE in convert_move
--- Comment #2 from jakub at gcc dot gnu dot org 2010-01-15 17:01 --- Indeed, that fixes it. Going to bootstrap/regtest it now on several arches, then commit before rolling 4.4.3-rc1. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-15 17:01:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42760
[Bug libgcj/39747] [4.4/4.5 Regression] Installation documentation should suggest building libgmp as PIC for building with libjava
--- Comment #6 from David dot Biesack at sas dot com 2010-01-15 16:45 --- I had this problem on a Linux x86_64 build, manifested with the error /usr/local/lib/libgmp.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42750 ) I'm adding that text here so that if someone else has that problem and searches for it, they can find this bug entry. How does one configure gmp to build correctly so that it can be used by gcc? I can't find any doc in the gmp configure/texinfo that describes how to do that. I ran configure for it and it says -fPIC works in the log, but it does not put -fPIC in the Makefile. I explicitly added it to the CFLAGS in my Makefile CFLAGS = -O2 -pedantic -m64 -mtune=k8 -fPIC and rebuilt it; make check work (in gmp). -- David dot Biesack at sas dot com changed: What|Removed |Added CC||David dot Biesack at sas dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39747
[Bug other/42756] Build fails if gold is used as linker and some libraries reside is /usr/local/lib
--- Comment #3 from aanisimov at inbox dot ru 2010-01-15 16:32 --- (In reply to comment #1) > Try to set LIBRARY_PATH, i.e.: > > export LIBRARY_PATH=/usr/local/lib > This worked much better ;-) -- stage2 finished successfully, but building libstdc++ in stage3 failed with a bunch of /usr/bin/ld: error: unsupported symbol binding Trying to rerun the command to link libstdc++ with -Xlinker --debug=all to see what's going wrong gave no result, because the error message didn't change. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42756
[Bug target/42753] _Complex_I is reported as undeclared. Code builds with Sun compiler.
--- Comment #8 from jsm28 at gcc dot gnu dot org 2010-01-15 16:30 --- Fixincludes is part of the compiler sources, and it is the part that should work around GCC-incompatible system headers (such as this one) by making fixed copies when GCC is built and installed. Thus, a failure to fix it indicates a limitation in fixincludes, and the fix would be to enhance fixincludes and rebuild GCC. It is not part of the C front end, so "c" is not the correct component. Do not change components back if a maintainer changes them to be more accurate. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753
[Bug middle-end/42760] [4.4 Regression] ICE in convert_move
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-15 16:23 --- Trunk has if (COMPLEX_MODE_P (TYPE_MODE (TREE_TYPE (from instead of the 4.4 if (TREE_CODE (TREE_TYPE (from)) == COMPLEX_TYPE) Fixed by 2009-06-17 Steve Ellcey * expr.c (expand_assignment): Change complex type check. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42760
[Bug middle-end/42760] [4.4 Regression] ICE in convert_move
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42760
[Bug lto/42675] lto1 rejects -fdump-core option of gfortran
--- Comment #2 from burnus at gcc dot gnu dot org 2010-01-15 16:08 --- (In reply to comment #1) > Huh. lto1 should probably accept all frontend options but ignore most of > them. > Or lto-wrapper should strip them. I think the crucial part about the option is that it starts with -fdump-*; same result for -fdump-parse-tree while all other options seem to work. Grepping for fdump finds in *opt: common.opt:fdump- common.opt:fdump-final-insns= common.opt:fdump-noaddr common.opt:fdump-unnumbered common.opt:fdump-unnumbered-links fortran/lang.opt:fdump-core fortran/lang.opt:fdump-parse-tree -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42675
[Bug tree-optimization/42717] [4.5 Regression] ice: verify_ssa failed
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-15 16:07 --- Testing sth else. -- 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 Last reconfirmed|2010-01-13 13:16:16 |2010-01-15 16:07:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42717
[Bug middle-end/42749] [4.5 Regression] -O2 and verify_stmts failed agane
--- Comment #6 from hjl dot tools at gmail dot com 2010-01-15 16:03 --- It is caused by revision 146831: http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01473.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42749
[Bug c/42753] _Complex_I is reported as undeclared. Code builds with Sun compiler.
--- Comment #7 from david dot kirkby at onetel dot net 2010-01-15 16:02 --- (In reply to comment #5) > *** Bug 42755 has been marked as a duplicate of this bug. *** > (In reply to comment #4) > This is a fixincludes bug; it needs to fix Sun's complex.h header to > work with GCC. > I've read the fixincludes README, and http://autogen.SourceForge.net/fixinc.html Perhaps I'm thick, but I have great difficulty in understanding what I am supposed to do. Is this a bug in gcc, or just I've not installed gcc fully? The bug has not been marked as CONFIRMED or INVALID, so I'm unsure what you believe it is. If it's due to the fact I've mis-installed gcc, I would appreciate some clearer instructions about how to fix this problem. Those fixincludes instructions make very little sense to me. The same problem exists with the gcc included by Sun at /usr/sfw/bin/gcc (on SPARC) and also the gcc 4.3.4 build by Blastwave (a well known distributor of Solaris software) Does the fixincludes actually modify the Solaris header (in which case one would need root access)? Would including the above bit of code as another header file solve the problem? -- david dot kirkby at onetel dot net changed: What|Removed |Added Component|target |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753
[Bug libfortran/42742] [4.5 Regression] SIGSEGV at libgfortran/io/format.c:111
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2010-01-15 15:58 --- SendingChangeLog Sendingio/format.c Transmitting file data .. Committed revision 155939. This will be back ported to 4.4.4 in a few days. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42742
[Bug middle-end/42760] New: [4.4 Regression] ICE in convert_move
// { dg-do compile }
// { dg-options "-O2" }
template
struct A
{
static T b (T it) { return it; }
};
template
static U
baz (T x, T y, U z)
{
for (long n = y - x; n > 0; --n)
{
*z = *x;
++z;
}
};
template
U
bar (T x, T y, U z)
{
baz (A ::b (x), A ::b (y), A ::b (z));
}
struct C
{
__complex__ float v;
};
template
struct B
{
B (T y[]) { bar (y, y + 1, x); }
operator T *() { return x; }
T x[1];
};
B
foo ()
{
C y[1];
return B (y);
};
ICEs in convert_move on x86_64. Works with 4.3 or 4.5.
--
Summary: [4.4 Regression] ICE in convert_move
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42760
[Bug c/42759] libgcc fails to compile with segmentation fault
--- Comment #1 from onlite at gmail dot com 2010-01-15 15:45 --- Created an attachment (id=19618) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19618&action=view) the preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42759
[Bug c/42759] New: libgcc fails to compile with segmentation fault
In MSYS environment I try to build m68k cross compiler. Both gcc-3.4.5 and gcc-4.4.0 were used The command /opt/gcc-build/./gcc/xgcc -B/opt/gcc-build/./gcc/ -B/usr/local/m68k-elf/bin/ -B/usr/local/m68k-elf/lib/ -isystem /usr/local/m68k-elf/include -isystem /usr/local/m68k-elf/sys-include -g -O2 -mcpu=51qe -Wa,-mno-mac -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../.././gcc -I../../../../gcc_4_4_2_release/libgcc -I../../../../gcc_4_4_2_release/libgcc/. -I../../../../gcc_4_4_2_release/libgcc/../gcc -I../../../../gcc_4_4_2_release/libgcc/../include -DHAVE_CC_TLS -o _popcountdi2.o -MT _popcountdi2.o -MD -MP -MF _popcountdi2.dep -DL_popcountdi2 -c ../../../../gcc_4_4_2_release/libgcc/../gcc/libgcc2.c -save-temps caused ../../../../gcc_4_4_2_release/libgcc/../gcc/libgcc2.c: In function '__popcountdi2': ../../../../gcc_4_4_2_release/libgcc/../gcc/libgcc2.c:809: internal compiler error: Segmentation fault -- Summary: libgcc fails to compile with segmentation fault Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: onlite at gmail dot com GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: m68k-unknown-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42759
[Bug libfortran/42742] [4.5 Regression] SIGSEGV at libgfortran/io/format.c:111
--- Comment #8 from burnus at gcc dot gnu dot org 2010-01-15 15:40 --- Submitted: Patch by Jerry: http://gcc.gnu.org/ml/fortran/2010-01/msg00091.html "It avoids the excessive use of memory that results from the parsed format node tree, probably exceeding available stack or heap." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42742
[Bug driver/42690] Undefined reference errors with -flto -fuse-linker-plugin
--- Comment #12 from espindola at gcc dot gnu dot org 2010-01-15 15:28
---
(In reply to comment #11)
> GCC was configured with --disable-shared option. It seems that the driver does
> not understand that --disable-shared implies static libgcc
>
That is correct. Currently we have
%{static|static-libgcc:-plugin-opt=-pass-through=%(lto_libgcc)} \
%{static:-plugin-opt=-pass-through=-lc} \
That is, --pass-through is only used for libgcc if -static or -static-libgcc is
given. For libgcc we could probably find out if we are using a static one or
not in a more accurate way.
For libc it is harder. The driver doesn't know that libc is static. It just
passes -lc to ld.
It might be possible to change what we test for. I think it would be OK to
always ask the plugin to pass libgcc and libc to the linker a second time *if
they are being used at all*. My understanding is that an unnecessary static
library will be ignored and a shared library will have no effect since it was
already used anyway.
To implement this we should always pass -plugin-opt=-pass-through=%(lto_libgcc)
and -plugin-opt=-pass-through=-lc to the linker unless something like -nostdlib
is used.
What options other than -nostdlib prevent gcc from linking libgcc and libc in
the produced binary?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690
[Bug c++/42758] [4.5 Regression] ICE on assert() in function with complex(?) template argument
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42758
[Bug other/38768] -fschedule-insns documentation is wrong for x86 and some other targets
--- Comment #8 from reza dot yazdani at amd dot com 2010-01-15 15:19 --- We used -O2 -fsched-pressure -fschedule-insns to build the cpu2006 bmks on an amd64-linux machine. Thanks for the list of bugs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38768
[Bug c++/42758] [4.5 Regression] ICE on assert() in function with complex(?) template argument
--- Comment #4 from paolo dot carlini at oracle dot com 2010-01-15 15:18 --- Thanks Michael. It's a serious regression, isn't it? -- paolo dot carlini at oracle dot com changed: What|Removed |Added Summary|ICE on assert() in function |[4.5 Regression] ICE on |with complex(?) template|assert() in function with |argument|complex(?) template argument http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42758
[Bug tree-optimization/39251] FAIL: g++.dg/tree-ssa/new1.C scan-tree-dump-not forwprop1 "= .* \+ -"
--- Comment #10 from mark at codesourcery dot com 2010-01-15 15:05 --- Subject: Re: FAIL: g++.dg/tree-ssa/new1.C scan-tree-dump-not forwprop1 "= .* \+ -" ramana at gcc dot gnu dot org wrote: > So yes it does look ARM specific . Also peeking at results on gcc-testresults > doesn't show this failure on x86. Thanks for looking at that. I will investigate this bug, but it might not be until week after next, as I will be out of the office this coming week. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39251
[Bug c++/42758] ICE on assert() in function with complex(?) template argument
--- Comment #3 from matz at gcc dot gnu dot org 2010-01-15 15:06 --- input_location handling is broken. (gdb) bt #0 0x7704a7c3 in strcmp () from /lib64/libc.so.6 #1 0x011be858 in splay_tree_splay (sp=0x1824110, key=0) at ../../gcc/libiberty/splay-tree.c:148 #2 0x011beed6 in splay_tree_lookup (sp=0x1824110, key=0) at ../../gcc/libiberty/splay-tree.c:389 #3 0x007b162a in get_fileinfo (name=0x0) at ../../gcc/gcc/c-lex.c:114 note: name==0, this comes from: #25 0x00765939 in fname_as_string (pretty_p=1) at ../../gcc/gcc/c-common.c:950 #26 0x004e0b3a in cp_make_fname_decl (loc=1708071, id=0x77e91ec8, type_dep=1) at ../../gcc/gcc/cp/decl.c:3559 #27 0x00765a7a in fname_decl (loc=1708071, rid=67, id=0x77e91ec8) at ../../gcc/gcc/c-common.c:999 Where the block in c-common.c is: 995 location_t saved_location = input_location; 996 input_location = UNKNOWN_LOCATION; 997 998 stmts = push_stmt_list (); 999 decl = (*make_fname_decl) (loc, id, fname_vars[ix].pretty); I.e. input_location is reset (that is okay here), then through the make_fname_decl call the c++ frontend is called back, which tries to construct a decl, implicitely (via cxx_make_type) accessing the fileinfo for input_filename. We want to create the __PRETTY_FUNCTION__ string decl here. I can't say if it's more sensible if the C++ frontend would deal with input_location==UNKNOWN_LOCATION sometimes, or if c-common.c should be changed to not reset it temporarily. But the latter really makes sense here, as the __PRETTY_FUNCTION__ decl is created on demand, i.e. a random place, which it then would get. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42758
[Bug other/42756] Build fails if gold is used as linker and some libraries reside is /usr/local/lib
--- Comment #2 from d dot g dot gorbachev at gmail dot com 2010-01-15 14:57 --- Well, and LD_LIBRARY_PATH=/usr/local/lib , too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42756
[Bug other/42756] Build fails if gold is used as linker and some libraries reside is /usr/local/lib
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2010-01-15 14:45 --- Try to set LIBRARY_PATH, i.e.: export LIBRARY_PATH=/usr/local/lib -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42756
[Bug libstdc++/42624] libstdc++ parallel mode deadlocks in barrier
--- Comment #19 from paolo dot carlini at oracle dot com 2010-01-15 14:35 --- Let's add Jakub in CC, he knows the implementation very well. In case, please keep also in touch privately. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jakub at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42624
[Bug lto/42757] lto1 does not emit common symbols with -fuse-linker-plugin
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-15 14:34 --- I see 2 main.o 2 78 PREVAILING_DEF main 81 RESOLVED_IR i comm.o 1 78 RESOLVED_IR i which is obviously bogus for comm.o. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42757
[Bug libstdc++/42624] libstdc++ parallel mode deadlocks in barrier
--- Comment #18 from singler at kit dot edu 2010-01-15 14:30 --- Created an attachment (id=19617) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19617&action=view) Add printf debug statements. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42624
[Bug libstdc++/42624] libstdc++ parallel mode deadlocks in barrier
--- Comment #17 from singler at kit dot edu 2010-01-15 14:30 --- Created an attachment (id=19616) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19616&action=view) Removes superfluous pragma omp single twice -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42624
[Bug libstdc++/42624] libstdc++ parallel mode deadlocks in barrier
--- Comment #16 from singler at kit dot edu 2010-01-15 14:29 --- First, let's remove superfluous #pragma omp single in two occurences, to make things simpler (see attached patch for trunk). The problem still persists, the program deadlocks. When dropping in some prints (see attached patch), the log ends like this: find going parallel, requesting 2 thread thread 0 of 2 starts thread 0 finished thread 1 of 2 starts thread 1 finished successful join find going parallel, requesting 2 thread thread 0 of 2 starts thread 0 finished Analysis: Thread 1 never starts (or at least does not reach the first printf). In general, for more threads, only thread 0 starts. This obviously leads to the deadlock. So on first sight, I would blame it on the OpenMP implementation. Maybe yet some interference with the pthreads. Any other explanations? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42624
[Bug c++/42740] [4.5 Regression] Many libstdc++ failures
--- Comment #3 from paolo dot carlini at oracle dot com 2010-01-15 14:24 --- Yes, it can, thanks again for the quick turnaround. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42740
[Bug c++/42758] ICE on assert() in function with complex(?) template argument
--- Comment #2 from paolo dot carlini at oracle dot com 2010-01-15 14:06 --- This is just crazy, inside the debugger works fine. Outside -fsyntax-only is enough, -E is not. Richard any idea what the heck is going on? -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42758
[Bug c++/42758] ICE on assert() in function with complex(?) template argument
--- Comment #1 from adl at gnu dot org 2010-01-15 13:40 --- Created an attachment (id=19615) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19615&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42758
[Bug c++/42758] New: ICE on assert() in function with complex(?) template argument
The following code compiles fine with g++-4.4 and causes g++-4.5 to segfault.
Removing the assert() or removing the int_less_than parameter no longer lead
to a segfault.
% g++-4.5 --version
g++-4.5 (Debian 4.5-20091226-1) 4.5.0 20091226 (experimental) [trunk revision
155473]
Copyright (C) 2009 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.
% cat bug.cc
#include
#include
namespace spot
{
struct int_less_than
{
bool operator()(int, int) const { return 0; }
};
int f(const std::set&)
{
assert(0);
return 1;
}
}
% g++-4.4 -c bug.cc# 4.4 runs OK
% g++-4.5 -c bug.cc
g++-4.5: Internal error: Segmentation fault (program cc1plus)
Please submit a full bug report.
See for instructions.
--
Summary: ICE on assert() in function with complex(?) template
argument
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: adl at gnu dot org
GCC build triplet: i686-linux-gnu
GCC host triplet: i686-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42758
[Bug lto/42757] lto1 does not emit common symbols with -fuse-linker-plugin
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-15 13:37 --- Works when linking in comm.o main.o order. I guess the linker resolution handling is bogus. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-15 13:37:53 date|| Summary|lto1 does not emit common |lto1 does not emit common |symbols |symbols with -fuse-linker- ||plugin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42757
[Bug lto/42757] lto1 does not emit common symbols
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2010-01-15 13:34 --- Created an attachment (id=19614) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19614&action=view) Testcase It produces error: undefined reference to 'i' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42757
[Bug lto/42757] New: lto1 does not emit common symbols
GCC 4.5.0 20100114. -- Summary: lto1 does not emit common symbols Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: d dot g dot gorbachev at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42757
[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr
--- Comment #18 from david dot kirkby at onetel dot net 2010-01-15 13:15 --- Subject: Re: gcc fails to build on Solaris x86 - it forgets the locations of libmpfr BlanchardJ at ieee dot org wrote: > --- Comment #17 from BlanchardJ at ieee dot org 2010-01-15 12:37 --- > >> Yes, thank you. That is helpful. How do you produce the $ISALIST? Is that >> simply >> sparcv9 on a modern SPARC and amd64 on an Open Solaris system, or is it a >> list. >> If the latter, how do you every it. >> >> >> drkir...@hawk:~$ isalist >> amd64 pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86 >> >> Do I need >> >> xport LD_OPTIONS='-R/opt/csw/lib/amd64 -R opt/csw/lib/pentium_pro+mmx etc" ? >> I >> doubt it, but I'm not sure what you mean there. >> >> Is it just this, or anything else I need to do? You say "typical blastwave >> build >> would have at a minimum .." but I doubt you would consider gcc a "typical >> blastwave build" If there are further complications, can you let me know >> what >> they are. >> >> Dave >> > > Hi, > > It's just the string '$ISALIST' so it will appear as-is in the final run path. > The runtime linker will take care of expanding it correctly at runtime. So one > just export LD_OPTIONS as-is before building. > > Thank you. That's very helpful. I really hate having to set LD_LIBRARY_PATH - it is particularly an issue if you have multiple compilers. There's alyways the chance it gets set to the wrong compiler by mistake. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481
[Bug fortran/42723] Bootstrapping Fortran with GCC 4.4.2 fails on Solaris 5.10: "f951: internal compiler error: Arithmetic Exception"
--- Comment #6 from burnus at gcc dot gnu dot org 2010-01-15 12:53 --- (In reply to comment #5) > I got GCC bootstrapped now! Instead of building the GMP and MPFR sources > together with GCC I did a build of them in advice. Next I configured the GCC > with the --with-gmp and --with-mpfr options (see below) and could successfully > build GCC. > Not sure why the first approach did fail because the MPFR and GMP code was > indeed nicely build with the GCC compiler... Could it be that then the LD_LIBRARY_PATH was not correctly set and a different GMP/MPFR has been picked up? > For now this issue can be closed/postponed as I have a workaround. > thanks for your help! OK, close as WORKSFORME - if you find something, which should be fixed, feel free to re-open the PR or fill a new one. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42723
[Bug fortran/42723] Bootstrapping Fortran with GCC 4.4.2 fails on Solaris 5.10: "f951: internal compiler error: Arithmetic Exception"
--- Comment #5 from Roger dot Jeurninck at home dot nl 2010-01-15 12:47 --- I got GCC bootstrapped now! Instead of building the GMP and MPFR sources together with GCC I did a build of them in advice. Next I configured the GCC with the --with-gmp and --with-mpfr options (see below) and could successfully build GCC. Not sure why the first approach did fail because the MPFR and GMP code was indeed nicely build with the GCC compiler... Testresults are ok and almost match those of Rainer (http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg01181.html). I will still look into the differences here. For now this issue can be closed/postponed as I have a workaround. thanks for your help! Roger (the configure options I used, note that the LD_LIBRARY_PATH needs to find the libs too) --- --prefix=../install \ --enable-languages=c,fortran,c++ \ --with-gmp-lib=/scratch/rjeurnin/gmp/gmp-4.3.2/install/lib \ --with-gmp-include=/scratch/rjeurnin/gmp/gmp-4.3.2/install/include \ --with-mpfr-lib=/scratch/rjeurnin/mpfr/mpfr-2.4.2/install/lib \ --with-mpfr-include=/scratch/rjeurnin/mpfr/mpfr-2.4.2/install/include \ --verbose -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42723
[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr
--- Comment #17 from BlanchardJ at ieee dot org 2010-01-15 12:37 --- > Yes, thank you. That is helpful. How do you produce the $ISALIST? Is that > simply > sparcv9 on a modern SPARC and amd64 on an Open Solaris system, or is it a > list. > If the latter, how do you every it. > > > drkir...@hawk:~$ isalist > amd64 pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86 > > Do I need > > xport LD_OPTIONS='-R/opt/csw/lib/amd64 -R opt/csw/lib/pentium_pro+mmx etc" ? > I > doubt it, but I'm not sure what you mean there. > > Is it just this, or anything else I need to do? You say "typical blastwave > build > would have at a minimum .." but I doubt you would consider gcc a "typical > blastwave build" If there are further complications, can you let me know what > they are. > > Dave > Hi, It's just the string '$ISALIST' so it will appear as-is in the final run path. The runtime linker will take care of expanding it correctly at runtime. So one just export LD_OPTIONS as-is before building. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481
[Bug middle-end/42739] [4.5 Regression] ICE with computed goto, destructors, and optimization
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-15 11:53 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42739
[Bug middle-end/42739] [4.5 Regression] ICE with computed goto, destructors, and optimization
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-15 11:53 --- Subject: Bug 42739 Author: rguenth Date: Fri Jan 15 11:53:26 2010 New Revision: 155937 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155937 Log: 2010-01-15 Richard Guenther PR middle-end/42739 * tree-cfgcleanup.c (remove_forwarder_block): Move destination labels of computed or non-local gotos to the destination. * tree-cfg.c (gimple_verify_flow_info): Verify that a EH landing pad label is the first label. * g++.dg/torture/pr42739.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr42739.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c trunk/gcc/tree-cfgcleanup.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42739
[Bug target/42753] _Complex_I is reported as undeclared. Code builds with Sun compiler.
--- Comment #6 from jsm28 at gcc dot gnu dot org 2010-01-15 11:52 --- For reference of people without Solaris headers to hand, the code needing fixing by fixincludes is: /* * Compilation environments for Solaris must provide the _Imaginary datatype * and the compiler intrinsics _Complex_I and _Imaginary_I */ #define _Complex_I _Complex_I #define complex _Complex #define _Imaginary_I_Imaginary_I #define imaginary _Imaginary #undef I #define I _Imaginary_I Note there are some TABs there in the original header. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753
[Bug target/42753] _Complex_I is reported as undeclared. Code builds with Sun compiler.
--- Comment #5 from jsm28 at gcc dot gnu dot org 2010-01-15 11:51 --- *** Bug 42755 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753
[Bug c/42755] Using _Complex_I on Open Solaris fails to build an executable
--- Comment #3 from jsm28 at gcc dot gnu dot org 2010-01-15 11:51 --- *** This bug has been marked as a duplicate of 42753 *** -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42755
[Bug target/42753] _Complex_I is reported as undeclared. Code builds with Sun compiler.
--- Comment #4 from jsm28 at gcc dot gnu dot org 2010-01-15 11:49 --- This is a fixincludes bug; it needs to fix Sun's complex.h header to work with GCC. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Component|c |target GCC build triplet|Sun SPARC Enterprise T5240 | |Server running Solaris 10 | |05/2009 | GCC host triplet|Sun SPARC Enterprise T5240 | |Server running Solaris 10 | |05/2009 | GCC target triplet|Sun SPARC Enterprise T5240 |*-*-solaris* |Server running Solaris 10 | |05/2009 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753
[Bug c++/42740] [4.5 Regression] Many libstdc++ failures
--- Comment #2 from dodji at gcc dot gnu dot org 2010-01-15 11:30 --- The culprit commit was reverted so I think this should be fixed. -- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-15 11:30:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42740
[Bug c++/42634] ICE with -g -O2 -std=c++0x in copy_fn_p, at cp/decl.c:9973
--- Comment #9 from dodji at gcc dot gnu dot org 2010-01-15 11:29 --- Re-opening, as the fix was reverted. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42634
[Bug c++/42634] ICE with -g -O2 -std=c++0x in copy_fn_p, at cp/decl.c:9973
--- Comment #8 from dodji at gcc dot gnu dot org 2010-01-15 11:23 --- Subject: Bug 42634 Author: dodji Date: Fri Jan 15 11:23:29 2010 New Revision: 155936 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155936 Log: Revert commit of PR c++/42634, which was commit r155868 Removed: trunk/gcc/testsuite/g++.dg/template/error45.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42634
[Bug other/42756] New: Build fails if gold is used as linker and some libraries reside is /usr/local/lib
I have PPL and CLooG installed in /usr/local/lib. The configure script finds these two libraries and generates makefiles that link with them simply by adding -lppl_c -lppl -lcloog. For example, i686-slackware-linux-gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -o cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o c-parser.o i386-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o \ dummy-checksum.o main.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lcloog -lppl_c -lppl -lgmpxx -L/home/artem/testing/gcc-build/./gmp/.libs -L/home/artem/testing/gcc-build/./mpfr/.libs -lmpc -lmpfr -lgmp -rdynamic -ldl -lz -lelf This works well when GNU ld is used, because it can be taught to look for libraries in /usr/local/bin by editing /etc/ld.so.conf. However, GNU gold doesn't have such an option and requires that all library paths be passed in the command line explicitly (at least a brief look at options.cc shows no other way to specify additional library paths). The program can be partially resolved by saying LDFLAGS=-L/usr/local/lib ../gcc/configure .., which makes stage1 compiler to build successfully. However, building stage2 compiler fails because -L/usr/local/lib does not get added to the command line during compilation of stage2. I used the following options to configure GCC: ../gcc/configure --prefix=/usr/local/gcc-current --libdir=/usr/local/gcc-current/lib --enable-shared --enable-bootstrap --enable-languages=c,c++ --enable-threads=posix --enable-checking=release --with-system-zlib --disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp --enable-gold --enable-lto --verbose --with-arch=i686 --target=i686-slackware-linux --build=i686-slackware-linux --host=i686-slackware-linux -- Summary: Build fails if gold is used as linker and some libraries reside is /usr/local/lib Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aanisimov at inbox dot ru GCC build triplet: i686-slackware-linux GCC host triplet: i686-slackware-linux GCC target triplet: i686-slackware-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42756
[Bug driver/42690] Undefined reference errors with -flto -fuse-linker-plugin
--- Comment #11 from d dot g dot gorbachev at gmail dot com 2010-01-15 11:03 --- GCC was configured with --disable-shared option. It seems that the driver does not understand that --disable-shared implies static libgcc -- d dot g dot gorbachev at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Component|lto |driver Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690
[Bug lto/42690] Undefined reference errors with -flto -fuse-linker-plugin
--- Comment #10 from d dot g dot gorbachev at gmail dot com 2010-01-15 11:02 --- Created an attachment (id=19613) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19613&action=view) 4. Configured with --disable-shared, linking with a static libgcc (with -static). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690
[Bug lto/42690] Undefined reference errors with -flto -fuse-linker-plugin
--- Comment #9 from d dot g dot gorbachev at gmail dot com 2010-01-15 11:02 --- Created an attachment (id=19612) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19612&action=view) 3. Configured with --disable-shared, linking with a static libgcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690
[Bug lto/42690] Undefined reference errors with -flto -fuse-linker-plugin
--- Comment #8 from d dot g dot gorbachev at gmail dot com 2010-01-15 11:02 --- Created an attachment (id=19611) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19611&action=view) 2. Configured w/o --disable-shared, linking with a static libgcc (with -static). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690
[Bug lto/42690] Undefined reference errors with -flto -fuse-linker-plugin
--- Comment #7 from d dot g dot gorbachev at gmail dot com 2010-01-15 11:01 --- Created an attachment (id=19610) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19610&action=view) 1. Configured w/o --disable-shared, linking with a shared libgcc. Output of gcc -v -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690
[Bug middle-end/42749] [4.5 Regression] -O2 and verify_stmts failed agane
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-15 10:42 ---
struct pdf_object { int val; };
int pdf_count_size_object (struct pdf_object * p_obj)
{
return pdf_count_size_object(p_obj) + 2 * sizeof(struct pdf_object);
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-checking, ice-on-valid-
||code
Summary|-O2 and verify_stmts failed |[4.5 Regression] -O2 and
|agane |verify_stmts failed agane
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42749
[Bug c/42755] Using _Complex_I on Open Solaris fails to build an executable
--- Comment #2 from david dot kirkby at onetel dot net 2010-01-15 10:31 --- Created an attachment (id=19609) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19609&action=view) Preprocessed header -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42755
[Bug middle-end/42749] -O2 and verify_stmts failed agane
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-15 10:30 --- Confirmed. Reducing. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-15 10:30:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42749
[Bug c/42755] Using _Complex_I on Open Solaris fails to build an executable
--- Comment #1 from david dot kirkby at onetel dot net 2010-01-15 10:30 --- Created an attachment (id=19608) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19608&action=view) simple_complex.c C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42755
[Bug middle-end/42749] -O2 and verify_stmts failed agane
--- Comment #3 from dcb314 at hotmail dot com 2010-01-15 10:26 --- (In reply to comment #2) > It works for me with 4.5.0 20100114 (experimental) [trunk revision 155925] > on Linux/x86-64. I upgraded to the latest snapshot (20010114), trunk revision 155915 and it still seems broken to me. Either one of the ten revisions fixed it, or somethings gone wrong for me locally. I'll try a raw build of 20010114 and report back. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42749
[Bug c/42755] New: Using _Complex_I on Open Solaris fails to build an executable
I reported this bug against a SPARC system at #42753, but as this is a different version of gcc, on a different operating system with a different processor, I thought it wise to create another ticket. The hardware is a Sun Ultra 27, with a 3.33 GHz Xeon processor. The attached code builds and runs as expected using the Sun Studio 12.1 compiler. drkir...@hawk:~$ /opt/sunstudio12.1/bin/cc -V simple_complex.c cc: Sun C 5.10 SunOS_i386 2009/06/03 acomp: Sun C 5.10 SunOS_i386 2009/06/03 ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.1652 drkir...@hawk:~$ ./a.out CYTHON_CCOMPLEX 1 However, it fails with gcc 4.3.4 drkir...@hawk:~$ /usr/local/gcc-4.3.4-GNU-assembler-Sun-linker/bin/gcc -std=c99 -v -save-temps simple_complex.c Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc-4.3.4/configure --prefix=/usr/local/gcc-4.3.4-GNU-assembler-Sun-linker --with-as=/usr/local/binutils-2.20/bin/as --with-ld=/usr/ccs/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local Thread model: posix gcc version 4.3.4 (GCC) COLLECT_GCC_OPTIONS='-std=c99' '-v' '-save-temps' '-mtune=generic' /usr/local/gcc-4.3.4-GNU-assembler-Sun-linker/libexec/gcc/i386-pc-solaris2.11/4.3.4/cc1 -E -quiet -v simple_complex.c -mtune=generic -std=c99 -fpch-preprocess -o simple_complex.i ignoring nonexistent directory "/usr/local/gcc-4.3.4-GNU-assembler-Sun-linker/lib/gcc/i386-pc-solaris2.11/4.3.4/../../../../i386-pc-solaris2.11/include" #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/gcc-4.3.4-GNU-assembler-Sun-linker/include /usr/local/gcc-4.3.4-GNU-assembler-Sun-linker/lib/gcc/i386-pc-solaris2.11/4.3.4/include /usr/local/gcc-4.3.4-GNU-assembler-Sun-linker/lib/gcc/i386-pc-solaris2.11/4.3.4/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-std=c99' '-v' '-save-temps' '-mtune=generic' /usr/local/gcc-4.3.4-GNU-assembler-Sun-linker/libexec/gcc/i386-pc-solaris2.11/4.3.4/cc1 -fpreprocessed simple_complex.i -quiet -dumpbase simple_complex.c -mtune=generic -auxbase simple_complex -std=c99 -version -o simple_complex.s GNU C (GCC) version 4.3.4 (i386-pc-solaris2.11) compiled by GNU C version 4.3.4, GMP version 4.3.1, MPFR version 2.4.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: aa8da34c6527631409af75a63ef2 simple_complex.c: In function __pyx_t_double_complex_from_parts: simple_complex.c:20: error: _Complex_I undeclared (first use in this function) simple_complex.c:20: error: (Each undeclared identifier is reported only once simple_complex.c:20: error: for each function it appears in.) -- Summary: Using _Complex_I on Open Solaris fails to build an executable Product: gcc Version: 4.3.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: david dot kirkby at onetel dot net GCC build triplet: SunOS hawk 5.11 snv_111b i86pc i386 i86pc GCC host triplet: SunOS hawk 5.11 snv_111b i86pc i386 i86pc GCC target triplet: SunOS hawk 5.11 snv_111b i86pc i386 i86pc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42755
