The submission deadline is extended until the 22nd of November, 2009.
Apologies if you receive multiple copies of this call.
CALL FOR PAPERS
2nd Workshop on
Well, the configure process should result in the variable LIBOBJS
in the generated libiberty Makefile to be set to list of objects
containing implementations of replacement system routines.
So if you do not have HAVE_STRCASECMP in config.h, you should
have been getting strcasecmp.o in LIBOBJS
* Paul Edwards wrote on Sat, Nov 14, 2009 at 09:51:39AM CET:
Well, the configure process should result in the variable LIBOBJS
in the generated libiberty Makefile to be set to list of objects
containing implementations of replacement system routines.
So if you do not have HAVE_STRCASECMP in
LIBOBJS includes a strcasecmp.s$U.s
That suffix is certainly strange-looking though. I checked in
config.log and I can see that it automatically detected that
my object code has a .s extension, which is basically
correct given that I forced the -S option.
Why do you pass -S in the compiler
Hi all,
Just a small update, that after some discussions with Joern we think that based
on our
time constraints and the current state of GCC, instead of trying to push full
ICI into GCC
we start from the opposite approach:
We take all our plugins (support pass selection and reordering from
Jan Hubicka wrote:
-fno-ipa-cp should work around your problem for time being.
Indeed it did. Some figures:
hlprog (the main forecast program):
link time optimization time: 3:20 minutes
top memory usage:920 Mbyte
Inliner report:
Inlined 764 calls, eliminated 226 functions,
On Sun, Nov 8, 2009 at 19:10, Larry Evans cppljev...@suddenlink.net wrote:
Does someone know of a way to view this in a graphical way,
somewhat like what xvcg does for its cfg's?
When I've needed to visualize a CFG, I just used a very simplistic
script to paw through the dump file to produce
2009/11/14 Toon Moene t...@moene.org:
Jan Hubicka wrote:
-fno-ipa-cp should work around your problem for time being.
Indeed it did. Some figures:
hlprog (the main forecast program):
link time optimization time: 3:20 minutes
top memory usage: 920 Mbyte
Inliner report:
On Sat, Nov 14, 2009 at 8:51 PM, Richard Guenther
richard.guent...@gmail.com wrote:
Note that some optimizers (for example value-numbering) contain cut-offs
so that they are turned off for large functions as otherwise compile-time
issues appear as algorithms are non-linear in the size of the
Richard Guenther wrote:
2009/11/14 Toon Moene t...@moene.org:
However, my endeavour is to boldly go where no inliner has gone before, and
implement -falways-inline-functions-only-called-once, along the following
lines:
...
(Sugg. b. Rich. G.), because inlining functions that are only
On Sat, Nov 14, 2009 at 2:13 PM, Steven Bosscher stevenb@gmail.com wrote:
On Sat, Nov 14, 2009 at 8:51 PM, Richard Guenther
richard.guent...@gmail.com wrote:
Note that some optimizers (for example value-numbering) contain cut-offs
so that they are turned off for large functions as
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-11-14 08:58 ---
Probably related with the move to internal preprocessing, see also PR36380.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jakub at gcc dot gnu dot org 2009-11-14 10:59 ---
When only D.3 lists them and D.2 doesn't is IMHO a clear sign that they belong
into omp_lib.f90 only and not into omp_lib.h.
These two parameters are never mentioned in the standard except for D.3/D.4
AFAIK, and D.3
--- Comment #1 from zsojka at seznam dot cz 2009-11-14 12:50 ---
Created an attachment (id=19016)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19016action=view)
even shorter testcase
This testcase is invalid C++, gcc gives diagnostics and crashes with the same
error message
--
example code:
#include iostream
using namespace std;
struct test {
test () {
cout test::test() endl;
}
~test() {
cout test::~test() endl;
}
};
struct a {
const test x;
a () : x(test()){
cout
On Linux/ia32, revision 154177 gave:
FAIL: gcc.c-torture/compile/930117-1.c -O1 (internal compiler error)
FAIL: gcc.c-torture/compile/930117-1.c -O1 (test for excess errors)
FAIL: gcc.c-torture/compile/930117-1.c -O2 (internal compiler error)
FAIL: gcc.c-torture/compile/930117-1.c -O2
--- Comment #1 from mikpe at it dot uu dot se 2009-11-14 16:09 ---
Presumably fixed for 4.5 by revision 154178.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42044
--- Comment #5 from mikpe at it dot uu dot se 2009-11-14 16:32 ---
This wrong-code bug also occurs with 4.3.4 on i686-linux, but not with 4.2.4 or
4.1.2, making it a regression. The patch for 4.4 applies cleanly to 4.3 and
fixes the bug there with no new regressions (I tested i686,
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|jakub at gcc dot gnu dot org|unassigned at gcc dot gnu
|
--- Comment #2 from nickpelling at nanodome dot com 2009-11-14 16:45
---
Created an attachment (id=19017)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19017action=view)
Test C file for which gcc -O3 should (but currently doesn't) use r14
--
--- Comment #3 from nickpelling at nanodome dot com 2009-11-14 16:48
---
Created an attachment (id=19018)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19018action=view)
This is the assembler file generated by gcc 4.4.1 for the C test file
Note the presence of [sp, #0] in the
--- Comment #4 from nickpelling at nanodome dot com 2009-11-14 16:50
---
Actually, I am targeting ARM (not Thumb1).
I don't currently have easy access to 4.2.1 and 4.3.2, but I am assured that
the former does indeed use r14 and the latter does indeed not use r14.
--
--- Comment #3 from reichelt at gcc dot gnu dot org 2009-11-14 17:07
---
The code compiles without ICE on trunk since at least 2009-09-17.
So lets close it as fixed.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rearnsha at gcc dot gnu dot org 2009-11-14 18:17
---
Subject: Bug 42031
Author: rearnsha
Date: Sat Nov 14 18:17:21 2009
New Revision: 154182
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154182
Log:
PR target/42031
* arm.md (adddi_sesidi_di):
--- Comment #3 from rearnsha at gcc dot gnu dot org 2009-11-14 18:25
---
Fixed with posted patch
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
The following was reported by John McFarland:
PROGRAM prog
TYPE object
PROCEDURE(), POINTER, NOPASS :: f
END TYPE object
TYPE container
TYPE (object), POINTER :: o(:)
END TYPE container
TYPE (container) :: c
TYPE (object) :: o1, o2
PROCEDURE(), POINTER :: f = NULL()
o1%f = f
! This
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2009-11-14 18:35
---
Does anyone recognize this in resolve.c
/* If we have more than one element left in the repeat count,
and we have more than one element left in the target variable,
then create a range
--- Comment #2 from hjl dot tools at gmail dot com 2009-11-14 18:37 ---
(In reply to comment #1)
Presumably fixed for 4.5 by revision 154178.
Yes, revision 154178 fixed it on trunk.
--
hjl dot tools at gmail dot com changed:
What|Removed
--- Comment #3 from ubizjak at gmail dot com 2009-11-14 18:57 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #11 from reichelt at gcc dot gnu dot org 2009-11-14 19:24
---
The problems with -O -fipa-pta seem to be fixed since GCC 4.4.0.
I checked all duplicates from comment #4 - #7.
--
reichelt at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from kargl at gcc dot gnu dot org 2009-11-14 19:30 ---
(In reply to comment #7)
Does anyone recognize this in resolve.c
/* If we have more than one element left in the repeat count,
and we have more than one element left in the target variable,
--- Comment #9 from kargl at gcc dot gnu dot org 2009-11-14 19:32 ---
which traces to
REMOVE:kargl[207] svn log -r 86443 resolve.c |more
r86443 | rth | 2004-08-23 14:53:14 -0700 (Mon, 23 Aug 2004) | 11 lines
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-14 19:39 ---
Caused by recent changes
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.3.4
Known to work||4.2.4 4.4.3
--- Comment #6 from andreast at gcc dot gnu dot org 2009-11-14 20:57
---
I tried on another core2duo (x86_64-apple-darwin9), same issue. W/o
extra_gij_ldflags=-Wl,-allow_stack_execute for ecjx_LINK I fail with the same
entry in Library/Logs/CrashReporter:
--- Comment #5 from reichelt at gcc dot gnu dot org 2009-11-14 21:21
---
Confirmed.
Reduced testcase (crashes with -O2 -fwhole-program -fipa-struct-reorg):
=
templateint struct A
{
char c;
void foo(int);
void bar(int i) {
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2009-11-14 21:24
---
Interesting, the following patch allows the test case in comment #4 to compile.
Index: data.c
===
--- data.c (revision 154170)
+++ data.c
Sent from my iPhone
On Nov 14, 2009, at 2:35 PM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-11-14
22:35 ---
I guess the easiest is to avoid the special formats and simply use %ld
and long
--- Comment #3 from pinskia at gmail dot com 2009-11-14 22:44 ---
Subject: Re: lto-elf.c fails to compile on IRIX 6.5
Sent from my iPhone
On Nov 14, 2009, at 2:35 PM, rguenth at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #2 from rguenth at gcc dot
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-11-14 22:35 ---
I guess the easiest is to avoid the special formats and simply use %ld
and long unconditionally.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41996
--- Comment #4 from d dot g dot gorbachev at gmail dot com 2009-11-14
23:35 ---
GCC 4.5.0 20091112 -- works.
--
d dot g dot gorbachev at gmail dot com changed:
What|Removed |Added
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2009-11-15
01:57 ---
Yes, I have...
[MacPro:darwin_objdir/x86_64-apple-darwin10.2.0/libjava] howarth% grep
extra_gij_ldflags *
Makefile:extra_gij_ldflags = -Wl,-allow_stack_execute
I have been testing on a late 2008 MacPro
strne r2, [r3, #0]
streq r2, [r3, #0]
bx lr
.L5:
.align 2
.L4:
.word var
.size foo, .-foo
.comm var,4,4
.ident GCC: (GNU) 4.5.0 20091114 (experimental)
This should be:
cmp r0, #0
ldr r3, .L4
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-15 04:08 ---
Here is an example which also happens on x86 so this is not target specific:
int var;
int g(int);
int foo(int enable, int t, int tt)
{
if (enable)
var |= 1;
else
var = ~1;
return
--- Comment #3 from hutchinsonandy at gcc dot gnu dot org 2009-11-15 04:10
---
Subject: Bug 21078
Author: hutchinsonandy
Date: Sun Nov 15 04:10:20 2009
New Revision: 154188
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154188
Log:
PR target/21078, 21080
* config/avr/avr.c
I failed to build gcc with configuration follows:
../gcc/configure --target=sh-elf --host=i386-pc-mingw32
--build=i686-apple-darwin10 --enable-languages=c --with-gmp=/opt/MinGW
--with-mpfr=/opt/MinGW
I think genmodes should be built on build environment, but there seems it was
built with
--- Comment #1 from monaka at monami-software dot com 2009-11-15 05:54
---
Created an attachment (id=19019)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19019action=view)
build log.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42047
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-11-15 06:00 ---
Oh I see why this works for me, I install gmp/mpfr in the sysroot and I had
used the sysroot so I don't need to supply --with-gmp/--with-mpfr.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42047
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-15 06:03 ---
Looks like we need a new variable for build includes (that is BUILD_INCLUDES
which does not include GMPINC, PPLINC, DECNUMINC, LIBELFINC, or CLOOGINC).
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #4 from monaka at monami-software dot com 2009-11-15 07:12
---
Looks like we need a new variable for build includes
I think, too. I've built successful with my patch. (I don't send my patch
because it is half-finished.)
--
50 matches
Mail list logo
