--- Comment #3 from ayers at gcc dot gnu dot org 2009-03-15 07:38 ---
Confirmed that this is fixed in 4.3 and the trunk.
--
ayers at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rob1weld at aol dot com 2009-03-15 07:57 ---
(In reply to comment #2)
From ka...@gcc.gnu.org
4.2.1 is history and is completely and utterly unsupported.
OK.
Directory ftp://ftp.gnu.org/gnu/gcc/ says the date is 07/20/07 so it is barely
over one year old. ...
--- Comment #3 from doko at ubuntu dot com 2009-03-15 09:47 ---
looks so, didn't find the ICE message before submitting. the patch in 39175
applied on the branch fixes this problem, no regressions in the testsuite.
*** This bug has been marked as a duplicate of 39175 ***
--
doko
--- Comment #6 from doko at ubuntu dot com 2009-03-15 09:47 ---
*** Bug 39461 has been marked as a duplicate of this bug. ***
--
doko at ubuntu dot com changed:
What|Removed |Added
typedef int myint __attribute__((may_alias));
int foo(void *p)
{
myint *q = (int *)p;
return *q;
}
gcc -S t.c -Wall -O2
t.c: In function foo:
t.c:5: warning: pointer targets in initialization differ in signedness
--
Summary: [4.2/4.3/4.4 Regression] Attribute may_alias causes
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-03-15 11:55
---
Huh. Weird. I can reproduce this with
typedef int myint __attribute__((may_alias));
int foo(void *p)
{
myint *q = (int *)p;
return *q;
}
happens since 4.0. But only for the C frontend. - PR39464.
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-15 11:55 ---
Fails since GCC 4.0. Only happens with the C FE.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-03-15 12:08 ---
This is because convert_for_assignment does not know about the pointer target
difference due to the may_alias attribute. Note that I think a warning is
appropriate here, just the one emitted is confusing.
--- Comment #14 from aesok at gcc dot gnu dot org 2009-03-15 13:09 ---
Subject: Bug 34299
Author: aesok
Date: Sun Mar 15 13:09:44 2009
New Revision: 144870
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144870
Log:
PR target/34299
* config/avr/avr.c
--- Comment #15 from aesok at gcc dot gnu dot org 2009-03-15 13:14 ---
Fixed.
--
aesok at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
When building a program that uses an objc library as a DLL, libobjc
can't find its classes. When the program and the library are statically
linked, it works.
My libobjc itself is linked as a static library.
Environment:
System: Linux asgard.webkeks.org 2.6.28.5 #1
--- Comment #21 from hjl dot tools at gmail dot com 2009-03-15 17:37
---
(In reply to comment #19)
I did find that the ICE doesn't occur with the following change to
libcpp/expr.c:
Index: expr.c
===
--- expr.c
--- Comment #22 from dave at hiauly1 dot hia dot nrc dot ca 2009-03-15
18:07 ---
Subject: Re: [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c
Since revision 144529:
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg0.html
is the cause and it is inline related, I
--- Comment #23 from hjl dot tools at gmail dot com 2009-03-15 18:47
---
(In reply to comment #22)
Subject: Re: [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c
Since revision 144529:
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg0.html
is the cause and it
--- Comment #24 from rguenth at gcc dot gnu dot org 2009-03-15 19:51
---
Well, that change cannot possibly cause a miscompilation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-03-15 20:08 ---
This bug was reasoned by duplicate existance of function __chkstk.
For targets mingw/cygwin this symbol allocates and probes stack (see
/gcc/config/i386/cygwin.asm). The VC variant export the same symbol name in
--- Comment #7 from ktietz at gcc dot gnu dot org 2009-03-15 20:13 ---
The following patch solves this problem and prevents the name collision for 32
and 64 bits win32 systems.
ChangeLog
* config/i386/i386.md (allocate_stack_worker_32): Use
___gnu_chkstk.
The shared library libgfortran.so.3 in 4.3.x has the
__iso_c_binding_c_f_procpoin...@gfortran_1.0 symbol exported. This symbol is
missing in 4.4.0 20090315.
--
Summary: [4.4 regression]
__iso_c_binding_c_f_procpoin...@gfortran_1.0 missing
--- Comment #1 from spojenie at o2 dot pl 2009-03-15 21:04 ---
Created an attachment (id=17466)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17466action=view)
The .ii file generated from hairy templates that seem to cause the problem
--
--- Comment #1 from hjl dot tools at gmail dot com 2009-03-15 21:12 ---
*** This bug has been marked as a duplicate of 38871 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #13 from hjl dot tools at gmail dot com 2009-03-15 21:12
---
*** Bug 39467 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Sent from my iPhone
On Mar 15, 2009, at 2:02 PM, doko at ubuntu dot com gcc-bugzi...@gcc.gnu.org
wrote:
The shared library libgfortran.so.3 in 4.3.x has the
__iso_c_binding_c_f_procpoin...@gfortran_1.0 symbol exported. This
symbol is
missing in 4.4.0 20090315.
I think this symbol
:
The shared library libgfortran.so.3 in 4.3.x has the
__iso_c_binding_c_f_procpoin...@gfortran_1.0 symbol exported. This
symbol is
missing in 4.4.0 20090315.
I think this symbol was never used (from the fortran front-end) so
removing is ok. Also I think there is a duplicated bug about
As reported at the thread in http://gcc.gnu.org/ml/gcc/2009-03/msg00369.html
Using 4.4.0 gcc, I compiled a function and found it a tad long. The
command line is:
gcc -Os -mcpu=arm7tdmi-s -S func.c
although the output is pretty much the same with -O2 or -O3 as well (only
a few instructions
--- Comment #1 from ramana dot r at gmail dot com 2009-03-15 22:20 ---
I took a look at this for some time on Friday and I found that the
conditional constant propagation pass has pushed down the value
(tree-ssa-ccp.c). This is done by the CCP pass up in the optimization
pipeline
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-03-15 22:25 ---
Trying to deal with this on the tree level will certainly be the wrong thing.
A
target dependent pass should instead try to re-materialize code to generate
constants from existing ones.
--
rguenth at gcc dot
On ARM target when the compiler can deduce that the result of a calculation is
a constant, it always substitutes the calculation with the constant, even if
loading the constant is more expensive (both in code size and execution time)
than the actual calculation.
I attach a file that contains two
--- Comment #1 from zoltan at bendor dot com dot au 2009-03-15 22:51
---
Created an attachment (id=17467)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17467action=view)
Demonstrates the constant loading cost problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39469
The files ../melt-branch/gcc/compiler-probe.c and ../melt-branch/gcc/basilys.c
both use the GNU extensions lrand48_r() and srand48_r() and are not portable.
srand48_r(3) - Linux man page
http://linux.die.net/man/3/srand48_r
or
The GNU C Library
--- Comment #4 from zoltan at bendor dot com dot au 2009-03-15 23:21
---
Subject: Re: Constant propagation in a number
of tree passes does not take into account machine costs.
I have also filed a bug report, 39469, with a much simpler and clearer
test code. Maybe the two should be
--- Comment #3 from steven at gcc dot gnu dot org 2009-03-15 23:35 ---
Is there a test case for this PR?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from steven at gcc dot gnu dot org 2009-03-15 23:43 ---
*** Bug 39468 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from steven at gcc dot gnu dot org 2009-03-15 23:43 ---
*** This bug has been marked as a duplicate of 39469 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2009-03-15 23:45 ---
Related to Bug PR20211, too. It's all the same problem, basically: Undoing
constant propagation and discovering how to re-create constant values using
cheap arithmetic on live values in registers...
--
--- Comment #8 from dannysmith at users dot sourceforge dot net 2009-03-16
02:13 ---
(In reply to comment #7)
The following patch solves this problem and prevents the name collision for 32
and 64 bits win32 systems.
ChangeLog
* config/i386/i386.md
36 matches
Mail list logo
