[Bug objc/22474] Objc produces mis-match (non compatible) types in EQ_EXPR
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22474
[Bug bootstrap/37013] gcc-4.2.1 build breaks in fortran when using --with-mpfr=
--- 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. ... Support for "old" versions of gcc is a _requirement_ to build some of the Branches: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38626#c4 Some Branches use code from a year ago; with all the updates made to the particular section of gcc that the Branch Group is working on. The entirety of the Branch is _not_ necessarily synced to the Trunk. Since "Bootstrapping GNAT with a more recent GNAT is not supported" you are _required_ to use a version of gcc that is old enough to compile the file "gcc/ada/ali.adb" without causing the obscure error message: "ali.adb:1825:41: (style) bad casing of "NUL" declared in Standard". It would be great if the main ./configure checked if the "host Gnat" being used to Bootstrap the "built Gnat" is a usable version so we did not get a compilation error much later in the build. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37013
[Bug target/39461] ICE in output_460, at config/rs6000/rs6000.md:11495
--- 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 at ubuntu dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39461
[Bug target/39175] ICE while compiling qt-4.5.0-rc1
--- 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 CC||doko at ubuntu dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39175
[Bug c/39464] New: [4.2/4.3/4.4 Regression] Attribute may_alias causes invalid warning
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
invalid warning
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
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=39464
[Bug middle-end/39460] strange aliasing warnings compiling pymol under gcc 4.4
--- 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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39460
[Bug c/39464] [4.2/4.3/4.4 Regression] Attribute may_alias causes invalid warning
--- 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 Known to fail||4.0.4 Known to work||3.4.6 Target Milestone|--- |4.2.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39464
[Bug c/39464] [4.2/4.3/4.4 Regression] Attribute may_alias causes invalid warning
--- 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.
Something like
/* If this is a difference in target attributes, do war. */
else if (!attribute_list_equal (TYPE_ATTRIBUTES (ttl),
TYPE_ATTRIBUTES (ttr)))
WARN_FOR_ASSIGNMENT (input_location, 0,
G_("pointer targets in passing argument "
"%d of %qE have different attributes"),
G_("pointer targets in assignment "
"have different attributes"),
G_("pointer targets in initialization "
"have different attributes"),
G_("pointer targets in return have "
"different attributes"));
/* If this is not a case of ignoring a mismatch in signedness,
no warning. */
would be an improvement.
./cc1 -quiet -Wall t.i
t.i: In function 'foo':
t.i:5: warning: pointer targets in initialization have different attributes
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-03-15 12:08:59
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39464
[Bug target/34299] [avr] ICE on function attribute syntax for main()
--- 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=gcc&view=rev&rev=144870 Log: PR target/34299 * config/avr/avr.c (avr_handle_fndecl_attribute): Move code for generate a warning if the function name does not begin with "__vector" and the function has either the 'signal' or 'interrupt' attribute, from here to ... (avr_declare_function_name): ...here. New function. * config/avr/avr.h (ASM_DECLARE_FUNCTION_NAME): Redefine. * config/avr/avr-protos.h (avr_declare_function_name): Declare. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-protos.h trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34299
[Bug target/34299] [avr] ICE on function attribute syntax for main()
--- 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|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34299
[Bug libobjc/39465] New: libobjc does not find classes of DLLs
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 SMP Sat Feb 14 14:16:10 CET 2009
i686 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz GenuineIntel GNU/Linux
host: mingw32
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../gcc-4.3.0-20080502/configure -v --prefix=/usr
--libexecdir=/usr/lib --program-prefix=mingw32- --target=mingw32
--with-headers=/usr/mingw32/include --without-x --disable-nls
--disable-win32-registry --disable-shared --disable-java-awt
--disable-libgcj-debug --with-gcc --with-gnu-ld --with-gnu-as --enable-threads
--enable-languages=c,c++,objc --enable-libgcj --enable-java-gc=boehm
--enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug
How-To-Repeat:
asgard:/tmp$ cat foo.h
#import
@interface MyObj: Object
- (void)foo;
@end
asgard:/tmp$ cat foo.m
#import
#import "foo.h"
@implementation MyObj
- (void)foo
{
puts("foo!");
}
@end
asgard:/tmp$ cat test.m
#import "foo.h"
int main()
{
MyObj *x = [MyObj new];
[x foo];
return 0;
}
asgard:/tmp$ mingw32-gcc -shared -Wl,--out-implib,libfoo.dll.a foo.m -o
libfoo.dll -lobjc
asgard:/tmp$ mingw32-gcc -L. test.m -lfoo -lobjc
Info: resolving ___objc_class_name_MyObj by linking to
__impobjc_class_name_MyObj (auto-import)
/usr/lib/gcc/mingw32/4.3.0/../../../../mingw32/bin/ld: warning:
auto-importing has been activated without --enable-auto-import specified on the
command line.
This should work unless it involves constant data structures
referencing symbols from auto-imported DLLs.
asgard:/tmp$ wine a.exe
objc runtime: cannot find class MyObj
--- Comment #1 from js-gcc at webkeks dot org 2009-03-15 15:34 ---
Fix:
I guess some change to libobjc is needed so it can find classes inside
DLLs.
--
Summary: libobjc does not find classes of DLLs
Product: gcc
Version: 3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libobjc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: js-gcc at webkeks dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: mingw32
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
[Bug debug/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c
--- 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 (revision 144529) > +++ expr.c (working copy) > @@ -39,7 +39,7 @@ > /* Some simple utility routines on double integers. */ > #define num_zerop(num) ((num.low | num.high) == 0) > #define num_eq(num1, num2) (num1.low == num2.low && num1.high == num2.high) > -static bool num_positive (cpp_num, size_t); > +static bool num_positive (cpp_num, size_t) __attribute__((noinline)); > static bool num_greater_eq (cpp_num, cpp_num, size_t); > static cpp_num num_trim (cpp_num, size_t); > static cpp_num num_part_mul (cpp_num_part, cpp_num_part); > Since revision 144529: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg0.html is the cause and it is inline related, I suggest you use revision 144529 as base and revert the tree-inline.c change to see if it fixes libcpp/expr.c. -- hjl dot tools at gmail dot com changed: What|Removed |Added Summary|[4.4 Regression] ICE at |[4.4 Regression] Revision |dwarf2out.c:10353 in|144529 miscompiled |loc_descriptor_from_tree_1 |libcpp/expr.c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355
[Bug debug/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/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 suggest you use revision > 144529 as base and revert the tree-inline.c change to see if it fixes > libcpp/expr.c. I'll give it a try. I was hoping to to pin down what's being miscompiled but it is proving difficult. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355
[Bug debug/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c
--- 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 is inline related, I suggest you use revision > > 144529 as base and revert the tree-inline.c change to see if it fixes > > libcpp/expr.c. > > I'll give it a try. I was hoping to to pin down what's being miscompiled > but it is proving difficult. > If the tree-inline.c change is the cause, I would check each call to can_be_nonlocal to find out which one caused this regression. -- hjl dot tools at gmail dot com changed: What|Removed |Added BugsThisDependsOn||39345 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355
[Bug debug/39355] [4.4 Regression] Revision 144529 miscompiled libcpp/expr.c
--- 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
[Bug driver/39356] assembler isn't called
--- 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 kernel32, ntdll, and ntoskernl. But the MS variant just probes the stack and does not allocates stack space. I temporary removed the exports from our .def files in mingw-w64 and this solves the issue so far. The bad side of this fix is, that libraries generated by VC can't be linked proper, if they reference the ms __chkstk variant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356
[Bug driver/39356] assembler isn't called
--- 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. (allocate_stack_worker_64): Likewise. * config/i386/cygwin.asm (__alloca): Renamed to __gnu_alloca. (___chkstk): Renamed to ___gnu_chkstk. Index: gcc/gcc/config/i386/cygwin.asm === --- gcc.orig/gcc/config/i386/cygwin.asm +++ gcc/gcc/config/i386/cygwin.asm @@ -40,11 +40,11 @@ increments is necessary to ensure that the guard pages used by the OS virtual memory manger are allocated in correct sequence. */ - .global ___chkstk - .global __alloca #ifndef _WIN64 -___chkstk: -__alloca: + .global ___gnu_chkstk + .global ___gnu_alloca +___gnu_chkstk: +__gnu_alloca: pushl %ecx/* save temp */ leal8(%esp), %ecx /* point past return addr */ cmpl$0x1000, %eax /* > 4k ?*/ @@ -72,9 +72,11 @@ Ldone: pushl %eax ret #else + .global ___gnu_chkstk + .global __gnu_alloca /* __alloca is a normal function call, which uses %rcx as the argument. And stack space for the argument is saved. */ -__alloca: +__gnu_alloca: movq%rcx, %rax addq$0x7, %rax andq$0xfff8, %rax @@ -107,7 +109,7 @@ Ldone_alloca: /* ___chkstk is a *special* function call, which uses %rax as the argument. We avoid clobbering the 4 integer argument registers, %rcx, %rdx, %r8 and %r9, which leaves us with %rax, %r10, and %r11 to use. */ -___chkstk: +___gnu_chkstk: addq$0x7, %rax /* Make sure stack is on alignment of 8. */ andq$0xfff8, %rax popq%r11/* pop return address */ Index: gcc/gcc/config/i386/i386.md === --- gcc.orig/gcc/config/i386/i386.md +++ gcc/gcc/config/i386/i386.md @@ -20297,7 +20297,7 @@ (set (reg:SI SP_REG) (minus:SI (reg:SI SP_REG) (match_dup 1))) (clobber (reg:CC FLAGS_REG))] "!TARGET_64BIT && TARGET_STACK_PROBE" - "call\t___chkstk" + "call\t___gnu_chkstk" [(set_attr "type" "multi") (set_attr "length" "5")]) @@ -20310,7 +20310,7 @@ (clobber (reg:DI R11_REG)) (clobber (reg:CC FLAGS_REG))] "TARGET_64BIT && TARGET_STACK_PROBE" - "call\t___chkstk" + "call\t___gnu_chkstk" [(set_attr "type" "multi") (set_attr "length" "5")]) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356
[Bug libfortran/39467] New: [4.4 regression] __iso_c_binding_c_f_procpoin...@gfortran_1.0 missing in libgfortran
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 in libgfortran Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doko at ubuntu dot com GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39467
[Bug c++/39466] frepo relinking causes error - object in .o but not in .rpo or vice versa
--- 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=17466&action=view) The .ii file generated from hairy templates that seem to cause the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39466
[Bug libfortran/39467] [4.4 regression] __iso_c_binding_c_f_procpoin...@gfortran_1.0 missing in libgfortran
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39467
[Bug libfortran/38871] [4.4 Regression] libgfortran.so.3 dropped __iso_c_binding_c_f_procpointer@@GFORTRAN_1.0
--- 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 CC||doko at ubuntu dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38871
Re: [Bug libfortran/39467] New: [4.4 regression] __iso_c_binding_c_f_procpoin...@gfortran_1.0 missing in libgfortran
Sent from my iPhone On Mar 15, 2009, at 2:02 PM, "doko at ubuntu dot com" > 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 was never used (from the fortran front-end) so removing is ok. Also I think there is a duplicated bug about this already. -- Summary: [4.4 regression] __iso_c_binding_c_f_procpoin...@gfortran_1.0 missing in libgfortran Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doko at ubuntu dot com GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39467
[Bug libfortran/39467] [4.4 regression] __iso_c_binding_c_f_procpoin...@gfortran_1.0 missing in libgfortran
--- Comment #2 from pinskia at gmail dot com 2009-03-15 21:15 --- Subject: Re: New: [4.4 regression] __iso_c_binding_c_f_procpoin...@gfortran_1.0 missing in libgfortran Sent from my iPhone On Mar 15, 2009, at 2:02 PM, "doko at ubuntu dot com" 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 was never used (from the fortran front-end) so removing is ok. Also I think there is a duplicated bug about this already. > > > > -- > Summary: [4.4 regression] >__iso_c_binding_c_f_procpoin...@gfortran_1.0 > missing in >libgfortran > Product: gcc > Version: 4.4.0 >Status: UNCONFIRMED > Severity: major > Priority: P3 > Component: libfortran >AssignedTo: unassigned at gcc dot gnu dot org >ReportedBy: doko at ubuntu dot com > GCC target triplet: i486-linux-gnu > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39467 > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39467
[Bug tree-optimization/39468] New: Constant propagation in a number of tree passes does not take into account machine costs.
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 longer).
The function is basically an unrolled 32 bit unsigned division by 1E9:
unsigned int divby1e9( unsigned int num, unsigned int *quotient )
{
unsigned int dig;
unsigned int tmp;
tmp = 10u;
dig = 0;
if ( num >= tmp ) {
tmp <<= 2;
if ( num >= tmp ) {
num -= tmp;
dig = 4;
}
else {
tmp >>= 1;
if ( num >= tmp ) {
num -= tmp;
dig = 2;
}
tmp >>= 1;
if ( num >= tmp ) {
num -= tmp;
dig++;
}
}
}
*quotinet = dig;
return num;
}
The compiler generated the following code:
divby1e9:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldr r3, .L10
cmp r0, r3
movls r3, #0
bls .L3
ldr r2, .L10+4
cmp r0, r2
addhi r0, r0, #293601280
addhi r0, r0, #1359872
addhi r0, r0, #6144
movhi r3, #4
bhi .L3
.L4:
ldr r2, .L10+8
cmp r0, r2
movls r3, #0
bls .L6
add r0, r0, #-2013265920
add r0, r0, #13238272
add r0, r0, #27648
cmp r0, r3
movls r3, #2
bls .L3
mov r3, #2
.L6:
add r0, r0, #-1006632960
add r0, r0, #6619136
add r0, r0, #13824
add r3, r3, #1
.L3:
str r3, [r1, #0]
bx lr
.L11:
.align 2
.L10:
.word 9
.word -294967297
.word 19
Note that it is sub-optimal on two counts.
First, each loading of a constant takes 3 instructions and 3 clocks.
Storing the constant and fetching it using an ldr also takes 3 clocks but
only two 32-bit words and identical constants need to be stored only once.
The speed increase is only true on the ARM7TDMI-S, which has no caches, so
that's just a minor issue, but the memory saving is true no matter what
ARM core you have (note that -Os was specified).
Second, and this is the real problem, if the compiler did not want to be
overly clever and compiled the code as it was written, then instead of
loading the constants 4 times, at the cost of 3 instuctions each, it could
have loaded it only once and then generated the next constants at the cost
of a single-word, single clock shift. The code would have been rather
shorter *and* faster, plus some of the jumps could have been eliminated.
Practically each C statement line (except the braces) corresponds to one
assembly instruction, so without being clever, just translating what's
written, it could be done in 20 words instead of 30.
--
Summary: Constant propagation in a number of tree passes does not
take into account machine costs.
Product: gcc
Version: lto
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ramana dot r at gmail dot com
GCC build triplet: i686-unknown-linux-gnu
GCC host triplet: i686-unknown-linux-gnu
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39468
[Bug tree-optimization/39468] Constant propagation in a number of tree passes does not take into account machine costs.
--- 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 because in general constant propagation is a good idea . In any case there are a bunch of tree optimizers that identify these and generally bring in constants into expressions as generally a good idea. One might argue that constant propagation in general is a good thing but the problem appears to be that the moment one has an architecture where costs of loading immediate's is higher than the cost of simple arithmetic operations the final code generated might not be the most efficient. With some more experimentation in the last hour or so I found that for this particular case, I can get the following code divby1e9: @ Function supports interworking. @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. ldr r3, .L7 cmp r0, r3 mov r2, #0 bcc .L2 mov r3, r3, asl #2 cmp r0, r3 rsbcs r0, r3, r0 addcs r2, r2, #4 bcs .L2 mov r3, r3, lsr #1 cmp r0, r3 rsbcs r0, r3, r0 mov r3, r3, lsr #1 movcs r2, #2 cmp r0, r3 rsbcs r0, r3, r0 addcs r2, r2, #1 .L2: str r2, [r1, #0] bx lr .L8: .align 2 .L7: .word 10 .size divby1e9, .-divby1e9 .ident "GCC: (GNU) 4.4.0 20090313 (experimental) [trunk revision 143499]" but with the following command line options. ./xgcc -B`pwd` -S -Os newpr.c -fno-tree-ccp -fno-tree-fre -fno-tree-vrp -fno-tree-dominator-opts -fno-gcse I'm not sure about the best way to fix this but I've filed this for the moment as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39468 cheers Ramana -- ramana dot r at gmail dot com changed: What|Removed |Added Summary|Constant propagation in a |Constant propagation in a |number of tree passes does |number of tree passes does |not take into account |not take into account |machine costs. |machine costs. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39468
[Bug tree-optimization/39468] Constant propagation in a number of tree passes does not take into account machine costs.
--- 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 gnu dot org changed: What|Removed |Added Keywords||missed-optimization Version|lto |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39468
[Bug c/39469] New: Calculated values replaced with constants even if he constants cost more than the calculations
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 short C functions. They do exactly the same, but foo() processes a constant while bar() processes its argument. Compiling the code with -Os, -O2 or -O3 results in code where processing the argument is much shorter and faster than processing the constant. In particular, processing the variable argument generates code (the same assembly is generated for -Os and -O3) that is 7 words long and executes in 14 clocks. Using -Os, the function processing a constant generates a 10 word, 25 clock assembly while -O2 or -O3 creates a 17 words, 24 clock code. That is, when a constant is given instead of a variable parameter, the generated code is 40% longer and 79% slower for -Os and 143% longer and 71% slower with -O3. Adding the load of the constant to the beginning of the variable argument version of the code would cost 1 word, 1 clock if the peephole optimiser was clever enough and 2 words, 3 clocks in the worst case. Nowhere near the 3 words, 11 clocks (-Os) or 10 words, 10 clocks (-O2,-O3) cost the compiler generated. The command line used was: arm-aebi-gcc-4.4.0 -S -O[s23] constant.c -- Summary: Calculated values replaced with constants even if he constants cost more than the calculations Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zoltan at bendor dot com dot au GCC host triplet: i386-elf-linux GCC target triplet: arm-eabi-unknown http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39469
[Bug c/39469] Calculated values replaced with constants even if he constants cost more than the calculations
--- 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=17467&action=view) Demonstrates the constant loading cost problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39469
[Bug bootstrap/39470] New: [melt] - lrand48_r() and srand48_r() are GNU extensions and are not portable
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 http://www.delorie.com/gnu/docs/glibc/libc_398.html or drand48_r(3) - phpMan http://phpunixman.sourceforge.net/index.php/man/drand48_r/3 "CONFORMING TO These functions are GNU extensions and are not portable." In the mean time I will hunt down an implementation from somewhere and drop it in so as to not affect the build. Thanks, Rob # gmake ... gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wno-error -DHAVE_CONFIG_H -I. -I. -I../../melt-branch/gcc -I../../melt-branch/gcc/. -I../../melt-branch/gcc/../include -I./../intl -I../../melt-branch/gcc/../libcpp/include -I/usr/local/include -I/usr/local/include -I../../melt-branch/gcc/../libdecnumber -I../../melt-branch/gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/local/include -I/include -DCLOOG_PPL_BACKEND -I/usr/local/include ../../melt-branch/gcc/compiler-probe.c -o compiler-probe.o ../../melt-branch/gcc/compiler-probe.c: In function del_proberequest: ../../melt-branch/gcc/compiler-probe.c:241: warning: initialization discards qualifiers from pointer target type ../../melt-branch/gcc/compiler-probe.c:243: warning: cast discards qualifiers from pointer target type ../../melt-branch/gcc/compiler-probe.c: In function hash_filename: ../../melt-branch/gcc/compiler-probe.c:255: warning: cast discards qualifiers from pointer target type ../../melt-branch/gcc/compiler-probe.c: In function eq_filename: ../../melt-branch/gcc/compiler-probe.c:262: warning: cast discards qualifiers from pointer target type ../../melt-branch/gcc/compiler-probe.c:263: warning: cast discards qualifiers from pointer target type ../../melt-branch/gcc/compiler-probe.c: In function hash_info_tree: ../../melt-branch/gcc/compiler-probe.c:305: warning: cast from pointer to integer of different size ../../melt-branch/gcc/compiler-probe.c:308: warning: cast from pointer to integer of different size ../../melt-branch/gcc/compiler-probe.c:309: warning: cast from pointer to integer of different size ../../melt-branch/gcc/compiler-probe.c:311: warning: cast from pointer to integer of different size ../../melt-branch/gcc/compiler-probe.c:312: warning: cast from pointer to integer of different size ../../melt-branch/gcc/compiler-probe.c:318: warning: cast from pointer to integer of different size ../../melt-branch/gcc/compiler-probe.c: In function eq_info_tree: ../../melt-branch/gcc/compiler-probe.c:329: warning: cast from pointer to integer of different size ../../melt-branch/gcc/compiler-probe.c:330: warning: cast from pointer to integer of different size ../../melt-branch/gcc/compiler-probe.c:339: warning: cast from pointer to integer of different size ../../melt-branch/gcc/compiler-probe.c:343: warning: cast from pointer to integer of different size ../../melt-branch/gcc/compiler-probe.c: At top level: ../../melt-branch/gcc/compiler-probe.c:352: warning: no previous prototype for comprobe_unique_index_of_tree ../../melt-branch/gcc/compiler-probe.c: In function comprobe_unique_index_of_tree: ../../melt-branch/gcc/compiler-probe.c:361: warning: cast from pointer to integer of different size ../../melt-branch/gcc/compiler-probe.c: At top level: ../../melt-branch/gcc/compiler-probe.c:391: warning: no previous prototype for comprobe_tree_of_unique_index ../../melt-branch/gcc/compiler-probe.c: In function hash_info_bb: ../../melt-branch/gcc/compiler-probe.c:410: warning: cast from pointer to integer of different size ../../melt-branch/gcc/compiler-probe.c:413: warning: cast from pointer to integer of different size ../../melt-branch/gcc/compiler-probe.c:414: warning: cast from pointer to integer of different size ../../melt-branch/gcc/compiler-probe.c:416: warning: cast from pointer to integer of different size ../../melt-branch/gcc/compiler-probe.c:417: warning: cast from pointer to integer of different size ../../melt-branch/gcc/compiler-probe.c:423: warning: cast from pointer to integer of different size ../../melt-branch/gcc/compiler-probe.c: In function eq_info_bb: ../../melt-branch/gcc/compiler-probe.c:434: warning: cast from pointer to integer of different size ../../melt-branch/gcc/compiler-probe.c:435: warning: cast from pointer to integer of different size ../../melt-branch/gcc/compiler-probe.c:444: warning: cast from pointer to integer of different size ../../melt-branch/gcc/compiler-probe.c:448: warning: cast from pointer to integer of different size ../../melt-branch/gcc/compiler-probe.c: In function hash_info_gimple: ../../melt-branch/gcc/compiler-probe.c:463: warning: cast from pointer to integer of d
[Bug tree-optimization/39468] Constant propagation in a number of tree passes does not take into account machine costs.
--- Comment #3 from ramana dot r at gmail dot com 2009-03-15 22:59 --- (In reply to comment #2) > 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. > I suspect it would be a cost based thing with costs from the target especially for such targets. It might also help in cases involving symbol references similar to the one in the patch proposed here. http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00158.html This is still a CSE pass but this might help in a global context as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39468
[Bug target/38110] gcc.dg/pr30286.c fails on i686-apple-darwin9
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-03-15 23:05 --- Fixed in current gcc trunk on i686-apple-darwin9 and i686-apple-darwin10. -- howarth at nitro dot med dot uc dot edu changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38110
[Bug bootstrap/39470] [melt] - lrand48_r() and srand48_r() are GNU extensions and are not portable
--- Comment #1 from rob1weld at aol dot com 2009-03-15 23:18 ---
Workaround:
Define this at top of one file and export it in the other:
struct drand48_data
{
unsigned short int __x[3]; /* Current state. */
unsigned short int __old_x[3]; /* Old state. */
unsigned short int __c; /* Additive const. in congruential formula. */
unsigned short int __init; /* Flag for initializing. */
unsigned long long int __a; /* Factor in congruential formula. */
};
Use these versions of __drand48_iterate(), nrand48_r(), lrand48_r() and
srand48_r() at the top of one of the files (with exports in the other):
http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/uclinux-h8/uClibc/libc/stdlib/drand48-iter.c?revision=1.1.1.2&view=markup
http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/uclinux-h8/uClibc/libc/stdlib/nrand48_r.c?view=markup&revision=1.1.1.1
http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/uclinux-h8/uClibc/libc/stdlib/lrand48_r.c?view=markup&revision=1.1.1.1
http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/uclinux-h8/uClibc/libc/stdlib/srand48_r.c?view=markup&revision=1.1.1.1
The build continues ...
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39470
[Bug tree-optimization/39468] Constant propagation in a number of tree passes does not take into account machine costs.
--- 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 merged into the same bug? Zoltan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39468
[Bug rtl-optimization/29858] regmove has been silently disabled
--- Comment #6 from steven at gcc dot gnu dot org 2009-03-15 23:32 --- Discover_flag_regs has disappeared for GCC 4.4. WONTFIX for earlier releases. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29858
[Bug rtl-optimization/30065] Could use indexed addressing to reduce const costs
--- 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 Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30065
[Bug c/39469] Calculated values replaced with constants even if the constants cost more than the calculations
-- steven 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-03-15 23:43:09 date|| Summary|Calculated values replaced |Calculated values replaced |with constants even if he |with constants even if the |constants cost more than the|constants cost more than the |calculations|calculations http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39469
[Bug c/39469] Calculated values replaced with constants even if the constants cost more than the calculations
--- 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 CC||ramana dot r at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39469
[Bug tree-optimization/39468] Constant propagation in a number of tree passes does not take into account machine costs.
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39468
[Bug c/39469] Calculated values replaced with constants even if the constants cost more than the calculations
--- 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... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39469
[Bug driver/39356] assembler isn't called
--- 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 (allocate_stack_worker_32): Use > ___gnu_chkstk. > (allocate_stack_worker_64): Likewise. > * config/i386/cygwin.asm (__alloca): Renamed to __gnu_alloca. > (___chkstk): Renamed to ___gnu_chkstk. > No. This breaks backward compatibility. Static libraries and objects built with current and older versions of gcc will not be able to resolve references to __alloca or ___chkstk.Why not add labels with the new names as aliases rather than replace. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356
