[Bug c/39130] [libdl] (Now and then) dynamic loading/un-loading of shared libraries not happening
--- Comment #4 from ykalidas at gmail dot com 2009-02-08 06:47 --- PROBLEM - when i change the libkali.so.1 and libkali.so in ./shared/ to point to either of the libraries lib1.so.1.0 or lib2.so.1.0, the program run only one of the codes to which it pointed earlier. Example #ln -sf `pwd`/lib1.so.1.0 shared/libkali.so; ln -sf `pwd`/lib1.so.1.0 shared/libkali.so.1 #./progdl would STILL INVOKE fun() in lib2.so.1.0 EVEN IF THE FILE IS REMOVED. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39130
[Bug c/39130] [libdl] (Now and then) dynamic loading/un-loading of shared libraries not happening
--- Comment #3 from ykalidas at gmail dot com 2009-02-08 06:30 --- Created an attachment (id=17273) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17273&action=view) program invoking shared lib's function. Program that loads the function in the shared library. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39130
[Bug c/39130] [libdl] (Now and then) dynamic loading/un-loading of shared libraries not happening
--- Comment #2 from ykalidas at gmail dot com 2009-02-08 06:29 --- Created an attachment (id=17272) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17272&action=view) Plug-in function void fun(); would be made available through a shared object. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39130
[Bug c/39130] [libdl] (Now and then) dynamic loading/un-loading of shared libraries not happening
--- Comment #1 from ykalidas at gmail dot com 2009-02-08 06:29 --- Created an attachment (id=17271) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17271&action=view) Plug-in function void fun(); is a function that would be made available through a shared object. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39130
[Bug c/39130] New: [libdl] (Now and then) dynamic loading/un-loading of shared libraries not happening
Freshly compiled code calls and excutes a function in a non-existent library.
Details below :
#gcc -v
gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11)
How to reproduce the problem :
#Directories required "./shared"
#source code head'ed below
==> 1.c <==
#include
void fun() {
printf("1\n");
}
==> 2.c <==
#include
void fun() {
printf("2\n");
}
#include
#include
int main(int argc, char **argv)
{
void *lib_handle;
void (*fn)();
char *error;
while(1) {
lib_handle = dlopen("./shared/libkali.so", RTLD_LAZY);
if (!lib_handle)
{
fprintf(stderr, "%s\n", dlerror());
exit(1);
}
fn = dlsym(lib_handle, "fun");
if ((error = dlerror()) != NULL)
{
fprintf(stderr, "%s\n", error);
exit(1);
}
(*fn)();
dlclose(lib_handle);
}//while
return 0;
}
#gcc -Wall -fPIC -c 1.c
#gcc -Wall -fPIC -c 2.c
#gcc -shared -Wl,-soname,lib1.so.1 -o lib1.so.1.0 1.o
#gcc -shared -Wl,-soname,lib2.so.1 -o lib2.so.1.0 2.o
#gcc -rdynamic -o progdl progdl.c -ldl
#Following shared library will be changed to test plug-in (lib1.so.1.0 or
lib2.so.1.0)
#ln -sf `pwd`/lib1.so.1.0 shared/libkali.so; ln -sf `pwd`/lib1.so.1.0
shared/libkali.so.1
#ln -sf `pwd`/lib2.so.1.0 shared/libkali.so; ln -sf `pwd`/lib2.so.1.0
shared/libkali.so.1
--
Summary: [libdl] (Now and then) dynamic loading/un-loading of
shared libraries not happening
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ykalidas at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39130
[Bug target/9703] [arm] Accessing data through constant pool more times could be solved in less instructions
--- Comment #11 from ramana dot r at gmail dot com 2009-02-08 05:23 ---
(In reply to comment #10)
> This might have been implemented for 4.4 already. Section anchors now have
> been enabled for ARM.
>
4.4 seems to enable this with section anchors turned on. This is the code
generated.
Here is the code generated for the function reported.
ldr r3, .L3
mov r0, #11
mov r2, #12
stmia r3, {r0, r2}@ phole stm
bx lr
I suspect this can now be closed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9703
[Bug target/9663] [arm] gcc-20030127 misses an optimization opportunity
--- Comment #8 from ramana dot r at gmail dot com 2009-02-08 05:17 --- (In reply to comment #7) > Note you have to do with -fno-inline now on the mainline as the function is > inlined at -O2. > It looks as though this is fixed in 4.3 and mainline today. I checked with 4.1 and saw that the problem existed in 4.1 Looking at the assembly generated for the function, I no longer see a cmp and mov as reported in the bug report. I see similar code generated in 4.1 but no longer in 4.3 or 4.4. I see subs generated for 4.3 and 4.4 in the loop kernel as of version r143940 for 4.3 and 144002 for mainline. Here is the snippet of code from 4.1, 4.3 and 4.4 as given below. 4.1 .L8: ldr r3, .L12 umull r1, r2, r3, ip mov r2, r2, lsr #3 mov r3, r2, asl #1 mov r1, r2, asl #3 add r3, r3, r1 rsb r3, r3, ip add r3, r3, #48 cmp r2, #0 Insns from original bug report. mov ip, r2 strbr3, [r0, #-1]! bne .L8 4.3 .L5: umull r2, r3, r5, ip mov r3, r3, lsr #3 mov r2, r3, asl #1 mov r1, r3, asl #3 add r2, r2, r1 rsb r2, r2, ip add r2, r2, #48 subsip, r3, #0 strbr2, [r0, #-1]! bne .L5 4.4 .L5: umull r1, r2, r4, ip mov r2, r2, lsr #3 add r1, r2, r2, asl #2 sub ip, ip, r1, asl #1 add r1, ip, #48 subsip, r2, #0 strbr1, [r0, #-1]! bne .L5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9663
[Bug rtl-optimization/39081] missed optimization: un-needed copy of structure.
--- Comment #3 from linasvepstas at gmail dot com 2009-02-08 04:57 --- Thanks, You are quite right, I offer my apologies for wasting your time. I meant to have the signature of other() be other(TV&) not other(TV*) -- but -- I was hurriedly explaining this to someone else, and said "oh its like a pointer" and must have typed what I was saying. Haste makes waste. Again, my apologies. FWIW, when the signature is correct, then indeed the compiler gets it right. -- linasvepstas at gmail dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39081
[Bug c/39128] GPC polygon clipping library fails with -O2
--- Comment #4 from merkert at comcast dot net 2009-02-08 02:48 --- I just found out that it compiles at -O2 if I also specify -ffloat-store. So, I'm thinking it might be related to that old bug (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323), which would not entirely be a surprise. It's always an issue for any non-trivial piece of math code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39128
[Bug tree-optimization/39129] New: The meaning of 'BB' in "too many BBs in loop"
Compile something with -ftree-vectorizer-verbose, and you'll probably get: "note: not vectorized: too many BBs in loop." The meaning of 'BB' in this context is most certainly not universally known, so instead of a mysterious two-letter acronym the warning should talk about basic blocks. (I couldn't even find out the meaning of 'BB' by using Google, then I ended up asking on IRC.) -- Summary: The meaning of 'BB' in "too many BBs in loop" Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lanurmi at iki dot fi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39129
[Bug c/39128] GPC polygon clipping library fails with -O2
--- Comment #3 from merkert at comcast dot net 2009-02-08 02:19 --- Created an attachment (id=17270) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17270&action=view) Full source code Full source code, including main.i and gpc code and the polygon that causes the core dump. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39128
[Bug c/39128] GPC polygon clipping library fails with -O2
--- Comment #2 from merkert at comcast dot net 2009-02-08 02:18 --- Created an attachment (id=17269) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17269&action=view) The data file that causes the core dump run like this: gzip -dc polygon.gz | ./clip -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39128
[Bug c/39128] GPC polygon clipping library fails with -O2
--- Comment #1 from merkert at comcast dot net 2009-02-08 02:17 --- Created an attachment (id=17268) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17268&action=view) Preprocessed source Compile like this: gcc -O2 main.i -o clip -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39128
[Bug c/39128] New: GPC polygon clipping library fails with -O2
When compiling the popular GPC polygon clipping library (http://www.cs.man.ac.uk/~toby/alan/software/) with -O2 or -O3 and then processing a special polygon, it fails with a sigsegv on linux. The program works fine without optimization and with -O. I get the same results with compilers 4.3.2 and 4.3.3, but not with 4.0.2 (at -O3). I've run valgrind on the code and it comes back clean and even works!! I've attached a the preprocessed source (which is large) from the gcc-4.4. This is how it's compile and run: gcc -O2 -o clip main.i gzip -dc polygon.gz | ./clip I've attached also the full source code. I'll try to contact the author as well, perhaps there's a problem with the code when using optimization. -- Summary: GPC polygon clipping library fails with -O2 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: merkert at comcast dot net GCC build triplet: gcc (GCC) 4.4.0 20090130 (experimental) GCC host triplet: Linux linux 2.6.11.4-21.17-smp #1 SMP Fri Apr 6 08:42:34 UTC 200 GCC target triplet: gcc (GCC) 4.4.0 20090130 (experimental) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39128
[Bug target/38991] [4.3/4.4 Regression] SH: ICE in extract_insn at recog.c:1990
--- Comment #5 from kkojima at gcc dot gnu dot org 2009-02-08 00:55 --- Fixed. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38991
[Bug target/38991] [4.3/4.4 Regression] SH: ICE in extract_insn at recog.c:1990
--- Comment #4 from kkojima at gcc dot gnu dot org 2009-02-08 00:53 --- Subject: Bug 38991 Author: kkojima Date: Sun Feb 8 00:53:30 2009 New Revision: 144013 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144013 Log: Backport from mainline: 2009-02-05 Kaz Kojima PR target/38991 * config/sh/predicates.md (general_movsrc_operand): Don't check the subreg of system registers here. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/sh/predicates.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38991
[Bug middle-end/39127] New: Invalid GIMPLE with OpenMP
For libgomp.c/icv-1.c I see
main.omp_fn.0 (struct .omp_data_s.0 * .omp_data_i)
...
:
err.4_4 = err;
err ={v} err.4_4 | 8;
goto ;
:
err.2_2 = err;
err ={v} err.2_2 | 1;
goto ;
in icv-1.c.023t.ssa. err ={v} err.2_2 | 1; is invalid gimple.
--
Summary: Invalid GIMPLE with OpenMP
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-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=39127
[Bug middle-end/39124] [4.4 Regression]: -fno-exceptions leads to a ICE
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-02-07 23:26 --- Created an attachment (id=17267) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17267&action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39124
[Bug middle-end/22456] [4.2/4.3/4.4 regression] missing "is used uninitialized" warning
--- Comment #20 from manu at gcc dot gnu dot org 2009-02-07 21:33 --- (In reply to comment #19) > (In reply to comment #18) > > There were couple of bugs with real C code where warnings are actually > > useful - > > Yes please. reopen what those that you feel are still valid and add me to the > CC list. > I have reviewed all of them already and reclassified. If you have more doubts, please read http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings and then ask. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22456
[Bug tree-optimization/18501] [4.2/4.3/4.4 Regression] Missing 'used uninitialized' warning (CCP)
--- Comment #25 from manu at gcc dot gnu dot org 2009-02-07 21:29 --- *** Bug 30856 has been marked as a duplicate of this bug. *** -- manu at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||30856 nThis|| CC||christoph dot mallon at gmx ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
[Bug middle-end/30856] missing uninitialized variable warning (CCP)
--- Comment #12 from manu at gcc dot gnu dot org 2009-02-07 21:29 ---
This is a duplicate of 18501. CCP assumes y is always 23.
Reordering passes just changes the set of false negatives/positives. For
example, if you move the warning before CCP, then you get a warning for this
case:
int f(int x)
{
int y;
int x = 42;
if (x == 42) y = 23;
return y;
}
A more complete analysis is here:
http://gcc.gnu.org/ml/gcc/2005-11/msg00028.html
And some random ideas are here:
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings#problem_ccp
How other compilers get this right? I don't know, but ideas and patches are
welcome.
*** This bug has been marked as a duplicate of 18501 ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||18501
Status|REOPENED|RESOLVED
Resolution||DUPLICATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30856
[Bug middle-end/30856] missing uninitialized variable warning (CCP)
--- Comment #11 from manu at gcc dot gnu dot org 2009-02-07 21:21 --- This wasn't a duplicate of bug 22456 -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|RESOLVED|REOPENED Resolution|DUPLICATE | Summary|[4.1/4.2/4.3 Regression]|missing uninitialized |Missing "warning: '$FOO' may|variable warning (CCP) |be used uninitialized in| |this function" in trivial | |case| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30856
[Bug tree-optimization/18501] [4.2/4.3/4.4 Regression] Missing 'used uninitialized' warning (CCP)
--- Comment #24 from manu at gcc dot gnu dot org 2009-02-07 21:15 --- *** Bug 30575 has been marked as a duplicate of this bug. *** -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||muntyan at tamu dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
[Bug middle-end/30575] Missing warning about unitialized variable (CCP)
--- Comment #5 from manu at gcc dot gnu dot org 2009-02-07 21:15 --- This is an EXACT duplicate of bug 18501. CCP just assumes that foo is 8 always and just removes foo completely. *** This bug has been marked as a duplicate of 18501 *** -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Summary|Missing warning about |Missing warning about |unitialized variable|unitialized variable (CCP) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30575
[Bug c/30542] missing uninitialized variable warning (CCP)
-- manu 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-02-07 21:12:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30542
[Bug c/30542] missing uninitialized variable warning (CCP)
--- Comment #5 from manu at gcc dot gnu dot org 2009-02-07 21:11 --- This is clearly CCP. Probably a duplicate of 18501, better double check if 18501 is ever fixed. The reason why uncommenting the block of code brings back the warning is that CCP cannot assume that foo is just 50 because it could also be 52, so it doesn't remove foo and then the late pass kicks in and detects a default definition in the PHI node. I bet the warning given is "may be used". -- manu at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||18501 Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | Summary|gcc 4.1.1 missing |missing uninitialized |uninitialized variable |variable warning (CCP) |warnings| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30542
[Bug c++/31246] -Wunreachable-code warnings for compiler-generated code
--- Comment #28 from manu at gcc dot gnu dot org 2009-02-07 21:07 --- There is a patch here: http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00972.html -- manu at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||10/msg00972.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31246
[Bug middle-end/22456] [4.2/4.3/4.4 regression] missing "is used uninitialized" warning
--- Comment #19 from manu at gcc dot gnu dot org 2009-02-07 20:58 --- (In reply to comment #18) > There were couple of bugs with real C code where warnings are actually useful > - Yes please. reopen what those that you feel are still valid and add me to the CC list. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22456
[Bug libfortran/39083] stage 3 libgfortran build fails
--- Comment #7 from tony_eckert at umsl dot edu 2009-02-07 20:58 --- Thanks to Mikael Morin for spotting that. Updating from gmp-4.1.4 to gmp-4.2.4 and adding the latest mpfr fixed the problem. Thanks to all who replied. -- tony_eckert at umsl dot edu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39083
[Bug c++/28152] Diagnostic about wrong use _Complex prints __complex__
--- Comment #8 from manu at gcc dot gnu dot org 2009-02-07 20:54 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00874.html -- manu at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||10/msg00874.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28152
[Bug middle-end/20982] alignment attribute ignired for vector pointers types
--- Comment #3 from manu at gcc dot gnu dot org 2009-02-07 20:46 --- This is a missing diagnostic. -- manu at gcc dot gnu dot org changed: What|Removed |Added Keywords||diagnostic Last reconfirmed|2007-11-16 19:32:54 |2009-02-07 20:46:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20982
[Bug middle-end/30575] Missing warning about unitialized variable
--- Comment #4 from muntyan at tamu dot edu 2009-02-07 20:38 --- Hm, it might be a dup of #18501, but a mere mortal like me can't decide if it's so. Sorry for the spam if that's the case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30575
[Bug middle-end/30575] Missing warning about unitialized variable
--- Comment #3 from muntyan at tamu dot edu 2009-02-07 20:35 --- See the comments #17 and #18 in bug #22456. This is not a dup. -- muntyan at tamu dot edu changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30575
[Bug middle-end/22456] [4.2/4.3/4.4 regression] missing "is used uninitialized" warning
--- Comment #18 from muntyan at tamu dot edu 2009-02-07 20:35 --- There were couple of bugs with real C code where warnings are actually useful - see comment #2, and they were closed as a dup of this one. This one may or may not be important, but the warning did go for good, in valid cases (that is, in invalid but real program code). I would open a new entry as you say, but I don't think it makes sense - I already have opened one (closed as a dup), and I wasn't alone in that. I'll reopen #30575 because I can't reopen this one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22456
[Bug c++/14875] When using 'or' keyword, the error message speaks of a '||' token
--- Comment #12 from manu at gcc dot gnu dot org 2009-02-07 20:29 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00971.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14875
[Bug c++/13358] long long and C++ do not mix well
--- Comment #21 from manu at gcc dot gnu dot org 2009-02-07 20:23 --- There is a patch here: http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00970.html -- manu at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||10/msg00970.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13358
[Bug c++/39126] New: Missing "move" constructor call (C++0x rvalue references)
struct Foo {
Foo(Foo && from) { }
Foo() { }
~Foo() { }
/*private:
Foo(const Foo & from) { }*/
};
Foo CreateFoo(bool b) {
Foo f;
if (b) return Foo();
return f;
}
int main () {
Foo f(CreateFoo(false));
}
The problem might also be a spurious destructor call. The symptom is that the
constructor without parameters is called once, the move constructor never and
the destructor twice. With the traditional copy constructor included, the
programme works as intended, with one additional move constructor call, but no
copy constructor calls. Without the "if (b) return Foo();" line the programme
also works.
I've tested with these builds and -std=gnu++0x:
g++-4.3 (Debian 4.3.2-1.1) 4.3.2
g++ (Debian 20090129-1) 4.4.0 20090129 (experimental) [trunk revision 143770]
--
Summary: Missing "move" constructor call (C++0x rvalue
references)
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gbrammer at gmx dot de
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39126
[Bug c++/21146] unable to resolve visible symbol
--- Comment #5 from manu at gcc dot gnu dot org 2009-02-07 20:18 --- This still fails in GCC 4.4 icc accepts the code in strict mode, so I guess this is rejects-valid. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Known to fail||4.4.0 Last reconfirmed|-00-00 00:00:00 |2009-02-07 20:18:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21146
[Bug debug/39073] [4.4 Regression] unable to debug CP2K (no local symbols)
--- Comment #12 from burnus at gcc dot gnu dot org 2009-02-07 20:12 --- Workaround patch for GDB by Jan: http://sourceware.org/ml/gdb-patches/2009-02/msg00177.html "GDB currently ignores DW_TAG_module and so the DIEs get completely lost. This patch is not the real Fortran module support - it only merges the namespaces as flat - but it fixes the "regression" of gfortran-4.4." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39073
[Bug c/39084] [4.3/4.4 regression] ice on struct redefinition
--- Comment #4 from hjl dot tools at gmail dot com 2009-02-07 19:18 --- I think it is caused by revision 129491: http://gcc.gnu.org/ml/gcc-cvs/2007-10/msg00596.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||rguenther at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39084
[Bug middle-end/39124] [4.4 Regression]: -fno-exceptions leads to a ICE
--- Comment #3 from hjl dot tools at gmail dot com 2009-02-07 18:55 --- This is caused by revision 139756: http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg01321.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jh at suse dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39124
[Bug fortran/38913] Fortran does not set TYPE_CANONICAL properly
--- Comment #7 from rguenther at suse dot de 2009-02-07 18:49 --- Subject: Re: Fortran does not set TYPE_CANONICAL properly On Sat, 7 Feb 2009, jv244 at cam dot ac dot uk wrote: > --- Comment #6 from jv244 at cam dot ac dot uk 2009-02-07 15:32 --- > (In reply to comment #5) > > I guess that since Richard says that it's a problem, we had better confirm > > it:-) > > Do we need a bugzilla field 'confirmatio ad verecundiam' ;-) Haha ;) OTOH I am no longer convinced it is a real problem, but I also only have some F77 skills, so no testcases with whatever Fortran calls "structs" from me ;) Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38913
[Bug middle-end/39124] [4.4 Regression]: -fno-exceptions leads to a ICE
-- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.4.0 Known to work||4.3.2 Last reconfirmed|-00-00 00:00:00 |2009-02-07 18:37:49 date|| Summary|-fno-exceptions leads to a |[4.4 Regression]: -fno- |ICE |exceptions leads to a ICE Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39124
[Bug c++/30680] Spurious "might be used uninitialized" warning in STL use.
--- Comment #4 from manu at gcc dot gnu dot org 2009-02-07 16:30 --- Two years without testcase. I cannot reproduce. Probably a duplicate. Marked as INVALID. Please, reopen if you have a reproducible testcase obtained following http://gcc.gnu.org/bugs.html#report -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30680
[Bug middle-end/20968] spurious "may be used uninitialized" warning (conditional PHIs)
--- Comment #6 from manu at gcc dot gnu dot org 2009-02-07 16:27 --- This is just another case that would require conditional PHIs. I am not marking it as a duplicate of bug 36550, because this case is harder than then typical: if(q) p=1; something() if(q) use(p); Therefore, it may be possible to fix bug 36550 and still not fix this. -- manu at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||36550 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-07 16:27:01 date|| Summary|Spurious "may be used |spurious "may be used |uninitialized" warning |uninitialized" warning ||(conditional PHIs) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20968
[Bug target/38824] [4.4 Regression] performance regression of sse code from 4.2/4.3
--- Comment #14 from rob1weld at aol dot com 2009-02-07 16:18 --- (In reply to comment #8) > Created an attachment (id=17173) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17173&action=view) [edit] > An extracted test case for this bug. > > Hi tim, I extracted this test case from your website. But I can't exactly > ... FWIW. Platform i386-pc-solaris2.11 on an AMD Athlon X2 4200+: # /usr/bin/g++ -v Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/specs Configured with: /builds2/sfwnv-gate/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++,f77,objc --enable-shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-20050802) # /opt/csw/gcc3/bin/g++ -v Reading specs from /opt/csw/gcc3/lib/gcc/i386-pc-solaris2.8/3.4.5/specs Configured with: ../sources/gcc-3.4.5/configure --prefix=/opt/csw/gcc3 --with-local-prefix=/opt/csw --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix --enable-shared --enable-multilib --enable-nls --with-included-gettext --with-libiconv-prefix=/opt/csw --with-x --enable-java-awt=xlib --enable-languages=all Thread model: posix gcc version 3.4.5 # /opt/csw/gcc4/bin/g++ -v Reading specs from /opt/csw/gcc4/lib/gcc/i386-pc-solaris2.8/4.0.2/specs Target: i386-pc-solaris2.8 Configured with: ../sources/gcc-4.0.2/configure --prefix=/opt/csw/gcc4 --with-local-prefix=/opt/csw --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix --enable-shared --enable-multilib --enable-nls --with-included-gettext --with-libiconv-prefix=/opt/csw --with-x --enable-java-awt=xlib --with-system-zlib --enable-languages=c,c++,f95,java,objc,ada Thread model: posix gcc version 4.0.2 # g++ -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc_trunk/configure --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared --disable-static --enable-multilib --enable-decimal-float --with-long-double-128 --with-included-gettext --enable-stage1-checking --enable-checking=release --with-tune=k8 --with-cpu=k8 --with-arch=k8 --with-gnu-as --with-as=/usr/local/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld Thread model: posix gcc version 4.4.0 20090206 (experimental) [trunk revision 143992] (GCC) - # time ./3.4.3.out real0m5.554s user0m4.144s sys 0m0.146s # time ./3.4.5.out real0m5.669s user0m4.089s sys 0m0.141s # time ./4.0.2.out real0m5.266s user0m4.023s sys 0m0.132s # time ./4.4.0.out real0m5.060s user0m3.799s sys 0m0.124s - It seems gcc 3.4.3 (csl-sol210-3_4-20050802) is faster than gcc 3.4.5 and the current Trunk is ~10% faster (with all the years of progress) Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38824
[Bug middle-end/22197] inconsistent uninitialized warning for structs (SRA, DCE)
--- Comment #5 from manu at gcc dot gnu dot org 2009-02-07 16:18 --- This is an interaction between SRA deciding to create separate variables for testval and unusedval because of the copy and DCE deciding whether to remove all references to unusedval because of the call. The copy is an use, but if the result is not used, then DCE removes it and the warning goes away. If you pass something to a function, that is an use. In particular, the BLOCK is not conditional and there is no PHI node: so the uninitialized value "is used". GCC does not warn for forget(testvar) because SRA is not applied there and hence GCC does not know whether elements of testvar are uninitialized. Ideally, we should warn in all cases or in none. I would rather warn in all cases as we do for simple variables. If testvar is completely uninitialized and passed to a function, we should definitely get a warning. Anyway, this will be hard to get right because we would need to look within structures. This is more an enhancement request. -- manu 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-02-07 16:18:20 date|| Summary|invalid "is" used |inconsistent uninitialized |uninitialized, should be|warning for structs (SRA, |"may be"|DCE) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22197
[Bug testsuite/37960] FAIL: gcc.dg/pr11492.c (test for bogus messages, line 8)
--- Comment #9 from manu at gcc dot gnu dot org 2009-02-07 15:40 --- Is this fixed? I think the solution was clear. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37960
[Bug middle-end/22456] [4.2/4.3/4.4 regression] missing "is used uninitialized" warning
--- Comment #17 from manu at gcc dot gnu dot org 2009-02-07 15:35 ---
Without optimization we build the following:
foo ()
{
intD.0 iD.1591;
# BLOCK 2
# PRED: ENTRY (fallthru)
[pr22456.c : 4] goto ;
# SUCC: 4 (fallthru)
# BLOCK 3
# PRED: 4 (true)
[pr22456.c : 4] iD.1591_3 = iD.1591_1 + 1;
# SUCC: 4 (fallthru)
# BLOCK 4
# PRED: 2 (fallthru) 3 (fallthru)
# iD.1591_1 = PHI
[pr22456.c : 4] if (iD.1591_1 != 0)
goto ;
else
goto ;
# SUCC: 3 (true) 5 (false)
# BLOCK 5
# PRED: 4 (false)
[pr22456.c : 5] return;
# SUCC: EXIT
}
Because of the way the loop is represented, we generate a PHI node for the
condition instead of a direct use. Since we do not warn about PHI nodes without
optimization, then there is no warning.
With optimization the loop is completely removed since it doesn't do anything.
Hence, there is no warning. I wasn't able to construct a testcase where the
loop does anything useful (or the value of "i" is used after the loop) and we
do not warn.
This doesn't have anything to do with CCP and it is not a duplicate of bug
18501.
Closed as INVALID. If anyone comes up with a testcase for this where the loop
is not empty, open a new PR and add me to the CC.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn|18501 |
Status|NEW |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22456
[Bug fortran/38913] Fortran does not set TYPE_CANONICAL properly
--- Comment #6 from jv244 at cam dot ac dot uk 2009-02-07 15:32 --- (In reply to comment #5) > I guess that since Richard says that it's a problem, we had better confirm > it:-) Do we need a bugzilla field 'confirmatio ad verecundiam' ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38913
[Bug middle-end/36550] Wrong "may be used uninitialized" warning (conditional PHIs)
--- Comment #6 from manu at gcc dot gnu dot org 2009-02-07 15:05 --- *** Bug 27289 has been marked as a duplicate of this bug. *** -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||fnf at specifix dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36550
[Bug middle-end/27289] Gcc produces spurious -Wuninitialized warning compiling gdb
--- Comment #7 from manu at gcc dot gnu dot org 2009-02-07 15:05 --- This needs conditional PHIs (or smarter propagation) so a duplicate of bug 36550 *** This bug has been marked as a duplicate of 36550 *** -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27289
[Bug web/34120] bugs/reghunt.html should be updated to mention svn
--- Comment #2 from manu at gcc dot gnu dot org 2009-02-07 14:53 --- This was FIXED by me a while ago. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34120
[Bug libstdc++/34015] warning in backward_warning.h is illegible
--- Comment #9 from manu at gcc dot gnu dot org 2009-02-07 14:44 --- Closing. Nobody cares enough to fix this in any other way and GCC 4.3.0 is out already. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34015
[Bug middle-end/28216] [4.2/4.3/4.4 regression] mangled warning message
--- Comment #6 from manu at gcc dot gnu dot org 2009-02-07 14:39 --- No testcase, no answer for months, possibly fixed. I am closing this, we have far enough real bugs open. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28216
[Bug tree-optimization/39120] [4.2/4.3/4.4 Regression] Missed escape constraints for call results
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-07 12:31 --- Subject: Bug 39120 Author: rguenth Date: Sat Feb 7 12:31:34 2009 New Revision: 144003 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144003 Log: 2009-02-07 Richard Guenther PR tree-optimization/39120 * tree-ssa-structalias.c (handle_rhs_call): Fill out return constraints. (handle_lhs_call): Process return constraints. Add escape constraints if necessary. (handle_const_call): Fill out return constraints. Make nested case more precise. Avoid consttmp if possible. (handle_pure_call): Fill out return constraints. Avoid callused if possible. (find_func_aliases): Simplify call handling. Manually build nonlocal constraints for asm outputs. * tree-ssa-alias.c (ref_maybe_used_by_call_p_1): Add shortcut for const calls. Properly use is_call_clobbered for non-const, non-pure calls. * gcc.c-torture/execute/pr39120.c: New testcase. Added: branches/alias-improvements/gcc/testsuite/gcc.c-torture/execute/pr39120.c Modified: branches/alias-improvements/gcc/ChangeLog.alias branches/alias-improvements/gcc/tree-ssa-alias.c branches/alias-improvements/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39120
[Bug middle-end/39124] -fno-exceptions leads to a ICE
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-07 12:18 --- Reducing. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Summary| -fno-exceptions leads to a |-fno-exceptions leads to a |ICE |ICE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39124
[Bug c++/39060] [4.4 regression] ICE with lots of invalid member functions
--- Comment #1 from paolo dot carlini at oracle dot com 2009-02-07 11:35 --- Today I can't reproduce it. Do you? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39060
[Bug web/39125] New: trunk revision 143992 - Too many Testsuite FAILs = email > 400K = bounce
I hope "Web" is the correct 'Component' as it is not the "Testsuite" that is at fault but the mail-handler that needs some tweaking. On the Platform i386-pc-solaris2.11 (and possibly others) there are so many "test for excess errors" FAILs that the email created by "contrib/test_summary" is over 40 bytes (a little over 430k). This causes a bounce reply message which _might_ mean that tests with the most failures (and require fixing quicker) will not be included in: http://gcc.gnu.org/ml/gcc-testresults/2009-02/ Here is the email: Date: Fri, 6 Feb 2009 5:15 am Hi. This is the qmail-send program at sourceware.org. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. : ezmlm-reject: fatal: Sorry, I don't accept messages larger than 40 bytes (#5.2.3) --- Enclosed are the original headers of the message. Attached Message ... You actually need to make the email quite a bit less than 400k. I tried ~390k and it was rejected too (and the "Attached Message" headers were empty!). I ended up having to delete MANY results to get the email down to a size of ~380k so it would be accepted. Here is a Testsuite result (many libstdc++ FAILs deleted): http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00709.html Rob -- Summary: trunk revision 143992 - Too many Testsuite FAILs = email > 400K = bounce Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: web AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39125
[Bug c++/28501] ICE with __real__ and implicit type conversion
--- Comment #4 from paolo dot carlini at oracle dot com 2009-02-07 11:11 --- Mark, can I have your opinion about this issue? I'm still thinking we could rather easily accept the code... Thanks in advance. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||mark at codesourcery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28501
[Bug bootstrap/39111] gcc 4.4.0 20090204 - Configury from GNU linker to Operating System's Linker broke (reverse works OK)
--- Comment #4 from rob1weld at aol dot com 2009-02-07 11:04 --- (In reply to comment #3) > Despite all the problems Ada passes _all_ of it's Testsuite: > http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00620.html > My Testsuite Submission bounced, please view these results instead: http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00707.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39111
