) 4.5.0 20091005 (experimental)
The expression x*(1.0 + x) above is optmized into x + x * x using the fmacd
instruction, which multiplies and accumlates. The following is part combine
pass dump, note how instruction 13 is modified.:
---
;; Function f (f)
starting the processing of deferred insns
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-10-05 08:32 ---
Fixed. The ICE is really fixed. The new thing is sth else and thus for a new
PR please.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #29 from paolo dot carlini at oracle dot com 2009-10-05 09:08
---
Hi David. This delay is strange indeed, normally the first step doesn't take so
much time. I suggest sending a reminder to assignments@
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41351
--- Comment #1 from dougkwan at gcc dot gnu dot org 2009-10-05 09:09
---
Subject: Bug 41574
Author: dougkwan
Date: Mon Oct 5 09:08:46 2009
New Revision: 152443
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152443
Log:
2009-10-05 Doug Kwan dougk...@google.com
PR
--- Comment #10 from burnus at gcc dot gnu dot org 2009-10-05 09:19 ---
Subject: Bug 41479
Author: burnus
Date: Mon Oct 5 09:19:13 2009
New Revision: 152444
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152444
Log:
2009-10-05 Tobias Burnus bur...@net-b.de
PR
--- Comment #11 from burnus at gcc dot gnu dot org 2009-10-05 09:20 ---
Subject: Bug 41479
Author: burnus
Date: Mon Oct 5 09:19:52 2009
New Revision: 152445
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152445
Log:
2009-10-05 Tobias Burnus bur...@net-b.de
PR
--- Comment #12 from burnus at gcc dot gnu dot org 2009-10-05 09:20 ---
FIXED on the trunk (4.5) and on the 4.3 and 4.4 branches.
Thanks for the report!
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from ramana at gcc dot gnu dot org 2009-10-05 09:28 ---
(In reply to comment #10)
(In reply to comment #9)
(In reply to comment #8)
Are you testing the correct compiler ?
Yes.
After building my 4.4 tree (though a
cross compiler ) I see the code
--- Comment #2 from ramana at gcc dot gnu dot org 2009-10-05 09:32 ---
Fixed.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2009-10-05 09:48 ---
The ChangeLog entry is wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41574
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-10-05 09:49 ---
There is one common problem with handling of target options - we do not
properly adjust the flag_var.
But - I cannot reproduce the original problem. Care to attach a testcase?
I always get linker complaints like
--- Comment #1 from jakub at gcc dot gnu dot org 2009-10-05 09:52 ---
Created an attachment (id=18706)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18706action=view)
gcc45-pr41558.patch
Patch I'm going to bootstrap/regtest.
BTW, gdb 7.0.50.20091005-cvs doesn't work with the
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-10-05 09:53 ---
Not yet fixed. We still have
if (CODE_CONTAINS_STRUCT (code, TS_OPTIMIZATION))
{
/* FIXME lto. Not handled yet. */
gcc_unreachable ();
}
if (CODE_CONTAINS_STRUCT (code,
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2009-10-05 10:00
---
The ChangeLog entry is wrong.
And folks from Google shouldn't feel entitled to break a freeze imposed by
other folks from Google even if, yes, it is annoyingly long. :-)
--
ebotcazou at gcc dot gnu dot org
The following C++ code:
class Klass
{
public:
private:
static void f(const char* a, int b) {}
};
int main (void)
{
char* x;
Klass::f (x);
}
Incorrectly produces the follow error message in
--- Comment #1 from redi at gcc dot gnu dot org 2009-10-05 10:28 ---
Access checking happens after overload resolution.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41575
--- Comment #1 from redi at gcc dot gnu dot org 2009-10-05 10:34 ---
The code should not compile, swapping of rvalues is no longer supported in the
C++0x draft.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41568
t1.f90
--
subroutine foo
common /bar/ a, b
integer(4) :: a ,b
a = 1
b = 2
end
t2.f90
--
program test
common /bar/ c, d
integer(4) :: c, d
call foo
if (c/=1 .or. d/=2) call abort
end program test
./gfortran -B. -B ../x86_64-unknown-linux-gnu/libgfortran/.libs -o t t1.f90
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-05 10:55 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from redi at gcc dot gnu dot org 2009-10-05 11:30 ---
*** Bug 41333 has been marked as a duplicate of this bug. ***
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from redi at gcc dot gnu dot org 2009-10-05 11:30 ---
(In reply to comment #8)
I have got the issue. The problem is not sed but rather the pattern being
searched from ld --version
My ld --version returns
GNU ld (GNU Binutils)2.18
Where the pattern looked by the
I have narrowed down a problem in my application to the testcase which I will
soon attach.
The testcase should output:
Out r8: 0x82ce3350
Out cr: 0x8
Version of GCC: 4.3.4.
Command line which generates broken output: gcc -O2 compiler_issue.c
Command line which generates ok output: gcc -O2
--- Comment #1 from magnus dot christensson at acm dot org 2009-10-05
11:31 ---
Created an attachment (id=18707)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18707action=view)
-save-temps output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41577
--- Comment #2 from magnus dot christensson at acm dot org 2009-10-05
11:32 ---
Created an attachment (id=18708)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18708action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41577
--- Comment #3 from magnus dot christensson at acm dot org 2009-10-05
11:34 ---
I suspect that the problem is that an optimization path does not properly
distinguish between signed and unsigned comparisons. You get the same behavior
if you remove the int32 int_res = res; line and let
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-10-05 11:59 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-10-05 11:59 ---
A workaround is to provide -fno-tree-vrp.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41577
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-10-05 12:02 ---
Actually the testcase is invalid.
uint32 res = ((uint16)(cpu-gprs[12] 16) * (uint16)(cpu-gprs[16]
16));
performs a signed multiplication which invokes undefined behavior if it
overflows. Thus the
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-10-05 12:03 ---
A fix is to write
uint32 res = ((uint32)(uint16)(cpu-gprs[12] 16)
* (uint32)(uint16)(cpu-gprs[16] 16));
instead to force the multiplication in an unsigned type.
--
AMD Athlon64 4800+ (dual core, 1MB L2 cache each, SSE, SSE2, SSE3), 4GB DDR400
with
[LTO] gfortran -march=native -ffast-math -funroll-loops -flto -O3
[noLTO] gfortran -march=opteron -ffast-math -funroll-loops -ftree-loop-linear
-ftree-vectorize -msse3
When running the Polyhedron Benchmark
--- Comment #8 from magnus dot christensson at acm dot org 2009-10-05
12:36 ---
(In reply to comment #7)
A fix is to write
uint32 res = ((uint32)(uint16)(cpu-gprs[12] 16)
* (uint32)(uint16)(cpu-gprs[16] 16));
instead to force the multiplication in an unsigned
See review comment http://gcc.gnu.org/ml/fortran/2009-09/msg00298.html
For two longer test cases, see
http://gcc.gnu.org/ml/fortran/2009-09/msg00295.html
Currently, SELECT TYPE(type) uses:
+ /* Special case: If we're in a SELECT TYPE block,
+ replace the selector variable by a temporary.
--- Comment #2 from burnus at gcc dot gnu dot org 2009-10-05 12:40 ---
See also review comments http://gcc.gnu.org/ml/fortran/2009-09/msg00298.html
and http://gcc.gnu.org/ml/fortran/2009-09/msg00296.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41539
For SAME_TYPE_AS and EXTENDS_TYPE_OF one should add a compile-time
simplification to simplify.c
Cf. also review comments at http://gcc.gnu.org/ml/fortran/2009-09/msg00298.html
--
Summary: [OOP] SAME_TYPE_AS and EXTENDS_TYPE_OF - add compile-
time simplifcation
--- Comment #6 from ro at techfak dot uni-bielefeld dot de 2009-10-05
12:51 ---
Subject: Re: plugin-api.h unconditionally includes stdint.h
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-10-04 20:27
---
Rainer, I think the checks are in place to properly set
Currently, the size needed for allocation is not taken into account with CLASS.
The example below should print
42 -4.0
but prints
512 0.000
Expected:
a) The warning
Warning: Dynamic size allocation at (1) not supported yet, using size of
declared type
is turned into an error as
type, abstract :: t
end type t
class(t), allocatable :: a
allocate(a)
is wrong. For the allocate one has to use either
allocate(derived-type :: a)
or
allocate(a, source=some_type_or_class)
One needs to reject this at compile time.
* * *
Another interesting issue is:
type, abstract
--- Comment #1 from burnus at gcc dot gnu dot org 2009-10-05 12:53 ---
See also PR 41582.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
The following program is valid but it fails to compile due to the way the
indices in vtable are implemented.
Cf. http://gcc.gnu.org/ml/fortran/2009-09/msg00298.html
= File: bb.f90 =
module m
type t
end type t
end module m
= File: cc.f90 =
module m2
use m
type,
--- Comment #2 from ro at techfak dot uni-bielefeld dot de 2009-10-05
12:56 ---
Subject: Re: lto-elf.c fails to compile on Solaris
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-03 22:12
---
Waiting for someone with access to that host to investigate.
I've
empty.c
---
/* This page intentionally left blank. */
./xgcc -B. -o t empty.c -shared -fwhopr
lto1: internal compiler error: vector VEC(cgraph_node_ptr,base) index domain
error, in csi_node at cgraph.h:614
Please submit a full bug report,
with preprocessed source if appropriate.
See
--- Comment #4 from T-Bone at parisc-linux dot org 2009-10-05 13:03 ---
Here's additional input for this bug, focusing on the ffmpeg commit which first
triggered this error (r18553):
$ gcc-4.4 -v
Using built-in specs.
Target: ia64-linux-gnu
Configured with: ../src/configure -v
--- Comment #5 from T-Bone at parisc-linux dot org 2009-10-05 13:05 ---
Created an attachment (id=18709)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18709action=view)
preprocessed msmpeg4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41567
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-10-05 13:09 ---
with 64bit int the multiplication will never overflow, so it would work there
as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41577
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-05 13:10 ---
Try enabling -fwhole-program together with -flto.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41578
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-10-05 13:13 ---
That's weird. So is this a libelf bug after all or can we somehow workaround
it
in gcc?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40702
--- Comment #15 from domob at gcc dot gnu dot org 2009-10-05 13:15 ---
Subject: Bug 41403
Author: domob
Date: Mon Oct 5 13:15:35 2009
New Revision: 152448
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152448
Log:
2009-10-05 Daniel Kraft d...@domob.eu
PR fortran/41403
--- Comment #30 from rguenth at gcc dot gnu dot org 2009-10-05 13:18
---
Subject: Bug 23821
Author: rguenth
Date: Mon Oct 5 13:18:09 2009
New Revision: 152449
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152449
Log:
2009-10-05 Richard Guenther rguent...@suse.de
PR
--- Comment #31 from rguenth at gcc dot gnu dot org 2009-10-05 13:19
---
Fixed for 4.5.0, not going to fix it for the branches.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from domob at gcc dot gnu dot org 2009-10-05 13:19 ---
Fixed on trunk. I won't backport, as this is no real regression.
I still volunteer to rework the assigned/computed goto implementation (and have
some ideas for that) in case we deem it worth the effort, but as both
--- Comment #6 from laurent at guerby dot net 2009-10-05 13:19 ---
Andrew, did you reproduce it? If not what's missing/would help?
--
laurent at guerby dot net changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2009-10-05 13:22
---
Great, then patch + testcase is going in mainline. I have to ask submitter his
exact name for the ChangeLog, though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41530
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-10-05 13:22 ---
On IRC, Jakub told me to remove the value_expr flag after
gimplification and to introduce a new dummy var decl with the flag set
for the purpose of debugging. My first attempt is the following
patch. It did
type t
integer :: i
class(t), allocatable :: foo
end type t
In Fortran 2003 this is invalid to have CLASS(T) in the same TYPE as the one
being defined. I think Fortran 2008 allows this, but as currently, deallocating
also does not work, I would simply reject it.
C438 (R440) If the POINTER
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|4.1.2 4.3.1 4.4.2 4.5.0 |4.1.2 4.3.1 4.4.2
Known to work|3.3.3
(Cf. also PR 41585)
type t0
end type t0
type t
integer :: i
class(t0), allocatable :: foo
end type t
type(t) :: m
allocate(t0 :: m%foo)
m%i = 5
end
leaks memory:
D.1375 = (void * restrict) __builtin_malloc (1);
m.foo.$data = (struct t0 *) D.1375;
m.foo.$vindex = 1;
m.i = 5;
}
--- Comment #1 from burnus at gcc dot gnu dot org 2009-10-05 13:27 ---
See also PR 41586.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41585
type t0
integer :: j = 42
end type t0
type t
integer :: i
class(t0), allocatable :: foo(3)
end type t
Is invalid. the foo(3) shall be foo(:) as foo is allocatable.
--
Summary: [OOP] ICE with ALLOCATABLE CLASS components
Product: gcc
Version: 4.5.0
LTO bugs are not regressions, thus this is a meta-bug where we can queue issues
that have been brought up during the final review that need to be addressed
before the 4.5.0 release.
--
Summary: LTO bugs to be addressed before the merge
Product: gcc
Version:
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||41526, 41528, 41529, 41550,
|
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41588
--- Comment #1 from andi-gcc at firstfloor dot org 2009-10-05 14:04 ---
Created an attachment (id=18710)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18710action=view)
tlto1.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41589
Using built-in specs.
COLLECT_GCC=gcc45
COLLECT_LTO_WRAPPER=/pkg/gcc-4.5-091004/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/pkg/gcc-4.5-091004
--enable-checking=release --enable-languages=c,c++
--- Comment #2 from andi-gcc at firstfloor dot org 2009-10-05 14:04 ---
Created an attachment (id=18711)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18711action=view)
tlto2.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41589
--- Comment #3 from andi-gcc at firstfloor dot org 2009-10-05 14:04 ---
Created an attachment (id=18712)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18712action=view)
Makefile.lto
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41589
--- Comment #4 from ro at techfak dot uni-bielefeld dot de 2009-10-05
14:05 ---
Subject: Re: lto-elf.c fails to compile on Solaris
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-10-05 13:13
---
That's weird. So is this a libelf bug after all or can we somehow
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-10-05 14:06
---
Subject: Bug 41487
Author: rguenth
Date: Mon Oct 5 14:05:54 2009
New Revision: 152450
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152450
Log:
2009-10-05 Richard Guenther rguent...@suse.de
PR
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-10-05 14:06 ---
Subject: Bug 41552
Author: rguenth
Date: Mon Oct 5 14:05:54 2009
New Revision: 152450
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152450
Log:
2009-10-05 Richard Guenther rguent...@suse.de
PR
When investigating PR lto/40702, I noticed that no definition of __STDC__ is
emitted at all in the output of gcc -g3 -save-temps, making it very hard to
understand why conditional pieces of code are used.
$ cat head.h
#define HEAD 1
$ cat stdc0.c
#include head.h
#define STDC0
$ gcc -I. -g3
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-10-05 14:16 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-10-05 14:17
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-10-05 14:20 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
for mismatched user-alignment.
* gcc.dg/lto/20091005-1_0.c: New testcase.
* gcc.dg/lto/20091005-1_1.c: Likewise.
Added:
trunk/gcc/testsuite/gcc.dg/lto/20091005-1_0.c
trunk/gcc/testsuite/gcc.dg/lto/20091005-1_1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-symtab.c
trunk
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-10-05 14:28 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-10-05 14:30 ---
Subject: Bug 41281
Author: rguenth
Date: Mon Oct 5 14:30:10 2009
New Revision: 152453
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152453
Log:
2009-10-05 Richard Guenther rguent...@suse.de
PR
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-10-05 14:31 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
e.g. when -fwhole-program should be specified, at compile or at line time
and that it applies to the object files
I figured it out using the source and #gcc, but it would be better in
the texinfo file.
--
Summary: documentation should document interaction of -flto and -
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-05 14:37 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from redi at gcc dot gnu dot org 2009-10-05 14:58 ---
14.3.1 [temp.arg.type] paragraph 2 in the current C++ standard says:
A type without linkage (3.5) shall not be used as a template argument for a
template type parameter.
This is changing for C++0x, based on the
--- Comment #3 from dmitry at lsi dot upc dot edu 2009-10-05 14:42 ---
(In reply to comment #1)
This is not a bug, local classes cannot be template arguments.
What does prevent them to be?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31951
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-10-05 15:14 ---
Namelookup is done before access control IIRC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41575
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-10-05 15:16 ---
I think this optimization is up to the linker as the variables are marked as
hidden and not marked as local to the Translational unit.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41589
--- Comment #1 from burnus at gcc dot gnu dot org 2009-10-05 15:17 ---
Does not need to be a component or derived type, any scalar leaks:
integer , allocatable :: a
allocate(a)
a = 42
end
MAIN__ ()
{
integer(kind=4) * a;
{
void * restrict D.1366;
D.1366 = (void *
Hi,
It looks like the following file from one of the gcc mirrors:
ftp://gd.tuwien.ac.at/gnu/gcc/releases/gcc-4.4.1/gcc-4.4.1.tar.bz2
has two .hpp files misnamed as .hp which causes the build to fail, namely:
hash_load_check_resize_trigger_imp.hp
constructors_destructor_fn_imps.hp
--
--- Comment #1 from paolo dot carlini at oracle dot com 2009-10-05 15:42
---
The files are definitely named correctly in SVN.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from andi-gcc at firstfloor dot org 2009-10-05 15:42 ---
I use binutils 2.19 (from opensuse 11.1).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41589
--- Comment #5 from dougkwan at google dot com 2009-10-05 15:44 ---
Subject: Re: Distribute floating point
expressions causes bad code.
I am aware of the fact the stage one has ended but this is a bug fix,
not an experimental new feature. Did I break a code freeze? If so, I
--- Comment #6 from dougkwan at google dot com 2009-10-05 15:48 ---
Subject: Re: Distribute floating point
expressions causes bad code.
Just saw Diego's e-mail about the me breaking the freeze. Sorry I
should have checked that before checking thing in. It was just my
bad.
--- Comment #2 from dirk dot herrmann-privat at gmx dot de 2009-10-05
16:48 ---
Hi,
thanks for considering my report.
The relevant sections seem to be (these were pointed out to me on comp.lang.ada
by Adam Beneschan):
4.9(38) : For a real static expression that is not part of a
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-10-05 17:07 ---
(In reply to comment #6)
I use binutils 2.19 (from opensuse 11.1).
What I meant was that -ffunction-sections -fdata-sections and then
-Wl,--gc-sections to remove the unused variables/functions.
--
--- Comment #2 from davine at poczta dot onet dot pl 2009-10-05 17:20
---
Still I hope the mirrored file gets fixed. Thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41592
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-10-05 17:23 ---
The problem usually stems from using the wrong tar to untar it.
GNU tar is usually the best tar to use for the gcc sources.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41592
--- Comment #4 from davine at poczta dot onet dot pl 2009-10-05 17:31
---
Could you elaborate? Did you mean a wrong tar for creating a tarball? I'm
ceratinly using gnu tar here and have never had any such problems.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41592
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-10-05 17:46 ---
Fixed on the trunk.
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-10-05 17:46 ---
Subject: Bug 40992
Author: pinskia
Date: Mon Oct 5 17:46:35 2009
New Revision: 152458
URL:
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-10-05 17:46 ---
Fixed on the trunk.
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-10-05 17:46 ---
Subject: Bug 40992
Author: pinskia
Date: Mon Oct 5 17:46:35 2009
New Revision: 152458
URL:
--- Comment #4 from jbytheway at gmail dot com 2009-10-05 17:48 ---
I've added my name to my account details. You should see it up there somewhere
^^.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41530
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-10-05 17:48
---
Subject: Bug 41511
Author: ebotcazou
Date: Mon Oct 5 17:48:09 2009
New Revision: 152459
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152459
Log:
PR rtl-optimization/41511
* combine.c
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-10-05 17:48 ---
Doubt it is the same as 40992 as this does not use inline-asm that much.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2009-10-05 17:50 ---
Draft patch at http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00300.html,
has room for improvements.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41591
--- Comment #5 from paolo at gcc dot gnu dot org 2009-10-05 17:56 ---
Subject: Bug 41530
Author: paolo
Date: Mon Oct 5 17:56:02 2009
New Revision: 152461
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152461
Log:
2009-10-05 John Bytheway jbythe...@gmail.com
PR
1 - 100 of 156 matches
Mail list logo
