--- 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 `p
--- 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.gn
--- 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/sh
--- 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.
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")
--- 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.
--- 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
--- 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 i
--- 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
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 could
--- 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.
--
--- 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/bug
--- 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=
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
--- 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
--- 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 Kojim
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 wit
--- 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
--- 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
--- 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
--- 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:
i
--- 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
--- 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
--- 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:
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirme
--- 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 becaus
--- 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
--
--- 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.
--- 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|R
--- 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
--
--- 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
K
--- 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
--- 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
--- 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 cas
--- 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
--- 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
--
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 t
--- 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
---
--- 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 suppor
--- 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
---
--- 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
-
--- 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)
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to
--- 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 g
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
-
--- 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
--- 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
--- 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
---
--- 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
--
--- 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/
--- 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|
--- 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
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
--- 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
--- 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:
ht
61 matches
Mail list logo
