make[4]: Entering directory
`/home/gzp/src/gcc-4.3/obj/i686-pc-linux-gnu/libmudflap'
if /bin/sh ./libtool --tag=CC --mode=compile
/home/gzp/src/gcc-4.3/obj/./gcc/xgcc -B/home/gzp/src/gcc-4.3/obj/./g
then mv -f ".deps/mf-runtime.Tpo" ".deps/mf-runtime.Plo"; else rm -f
".deps/mf-runtime.Tpo";
--- Comment #1 from bonzini at gnu dot org 2008-12-01 07:31 ---
Why a ref-all pointer? Why not put the cast after the dereference instead?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38334
--- Comment #7 from domob at gcc dot gnu dot org 2008-12-01 07:27 ---
Closing, for runtime-recursion checking I accepted PR 32626.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2008-12-01 07:26
---
> My experiance with this bug is that it segfaults at a place away from where
> the
> actual bug is. This one has been very very elusive.
See PR 37469 for a simple method to exhibit the problem.
--
http://
--- Comment #1 from domob at gcc dot gnu dot org 2008-12-01 07:25 ---
Taking this on, as addition to PR 37779 about compile-time recursion checking.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--
The compiler aborts wile building the GNUstep base library.
The problem was originally in an objective-c file, but I isolated it to a small
fragment of C code which causes the same failure.
Compiler version is:
Target: i686-pc-linux-gnu
Configured with: ../configure --with-mpfr=/usr/local --enabl
--- Comment #3 from adam dot c dot scott at gmail dot com 2008-12-01 06:47
---
With my version of g++ I didn't get your example warning about subscript. This
would be great.
In response to your objection... If any line of code modified the index of a
for loop then why use a for loop?
--- Comment #3 from burnus at gcc dot gnu dot org 2008-12-01 06:44 ---
> read( 50, *, pos = 1 )
> is valid only if the unit has been connected for STREAM access.
Well, (a) I don't see how this can be tested at compile time and (b) I thought
that
open(50,access='stream')
is doing so.
--- Comment #2 from adam dot c dot scott at gmail dot com 2008-12-01 06:30
---
(In reply to comment #0)
> Add warning about modifying an index in a for loop.
>
> Without this warning the kind of errors introduced in code are likely to be
> very difficult to debug (core dump).
>
> Exa
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-12-01 03:55
---
read( 50, *, pos = 1 )
is valid only if the unit has been connected for STREAM access. F2003
"9.5.1.10POS= specifier in a data transfer statement
The POS= specifier specifies the file position in file stora
gcc4x/vtrunk-2.19-2008-11-29_ntv/bin/gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /home/yakov/svn-gnu-gcc/gcc-trunk/configure
--enable-languages=c,c++ --disable-nls --disable-c-mbchar --disable-shared
--with-gmp=/emc/ucode/Linux-2x-i686/gmp-4.2.2
--with-mpfr=/emc/ucode/Li
--- Comment #8 from Joey dot ye at intel dot com 2008-12-01 02:18 ---
Yes. It fixes 416/481 on 32 bits and 481 on 64 bits.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38280
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-12-01 02:11
---
Try this:
gdb --args f951 parameter_array_init_3.f90
r
bt
My experiance with this bug is that it segfaults at a place away from where the
actual bug is. This one has been very very elusive.
--
http://gcc
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-01 00:17 ---
I had the same thing for the PS3 compiler, it turned out due to C++ style
comments in the system headers. This was causing libcpp to abort.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-01 00:14 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-01 00:10 ---
Hmm, shouldn't the unwinder using pthreads mutex's already?
What is the output of "gcc -v" is the thread model set to single?
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Priority|P3 |P2
Last reconf
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.3 regression] Inlined|[4.2/4.3 Regression] Inlined
|con/de-structor break
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37861
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38072
--- Comment #11 from sgunderson at bigfoot dot com 2008-11-30 22:48 ---
Subject: Re: Massive performance regression
for jpeg_idct_islow
On Sun, Nov 30, 2008 at 09:29:29PM -, rguenth at gcc dot gnu dot org wrote:
> so it uses -mtune=i486 - this optimizes the multiplication f
--- Comment #3 from janus at gcc dot gnu dot org 2008-11-30 22:00 ---
Created an attachment (id=16795)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16795&action=view)
patch v2
This updated patch passes the testsuite without regressions and adds some
additional checks.
--
htt
--- Comment #29 from steven at gcc dot gnu dot org 2008-11-30 21:32 ---
The insns 8 in comment #0 show the regmove transformation that matters here:
With regmove disabled::
(insn:HI 8 7 14 2 ../../include/mmintrin.h:300 (set (reg:V2SI 61)
(plus:V2SI (reg:V2SI 63 [ x ])
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-11-30 21:29
---
"
/usr/lib/gcc-snapshot/libexec/gcc/i486-linux-gnu/4.4.0/cc1 -quiet -v -I.
-D_REENTRANT -DPIC ./jidctint.c -quiet -dumpbase jidctint.c -mtune=i486
-auxbase-strip .libs/jidctint.o -g -g -O2 -Wall -version -fPIC -o
/
--- Comment #9 from sgunderson at bigfoot dot com 2008-11-30 21:22 ---
Subject: Re: Massive performance regression
for jpeg_idct_islow
On Sun, Nov 30, 2008 at 09:19:08PM -, sgunderson at bigfoot dot com wrote:
> -mtune=generic still produces these long series of leas.
Sorr
--- Comment #8 from sgunderson at bigfoot dot com 2008-11-30 21:19 ---
Subject: Re: Massive performance regression
for jpeg_idct_islow
On Sun, Nov 30, 2008 at 09:04:07PM -, rguenth at gcc dot gnu dot org wrote:
> Append -v to the command-line you use for compiling ;) Serio
--- Comment #28 from steven at gcc dot gnu dot org 2008-11-30 21:18 ---
You're not explaining what regmove does. What transformation do these
alternatives with "*" enable regmove to do?
I'm not saying that a separate pass is not an option. Perhaps a regmove-like
pass is necessary. In f
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-11-30 21:17 ---
Btw,
ERRMSG.12 = stat.11 != 0 ? (void) __builtin_memcpy ((void *) &err, (void *)
ERRMSG.12, 30) : (void) 0;
doesn't make sense. You assign void to ERRMSG.12 which is not void.
--
rguenth at gcc dot gnu dot org
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-30 21:15 ---
The failure is that fold_builtin_memory_op forgets to properly make the
return value available if 'ignore' is passed as true. This confuses
COND_EXPR gimplification. The fix may be non-trivial.
--
rguenth at gc
See http://gcc.gnu.org/ml/fortran/2008-11/msg00398.html for details.
With some gfortran allocatation patch, the middle end generates invalid GIMPLE
at any optimization level (but -O0). The difference between two
-fdump-tree-original (-O0 and with optimization) looks as follows:
ERRMSG.12 = &
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-11-30 21:04 ---
Append -v to the command-line you use for compiling ;) Seriously, if using
-mtune=generic works then this is a Debian packaging issue of their
gcc-snapshot compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #27 from hjl dot tools at gmail dot com 2008-11-30 20:52
---
(In reply to comment #26)
> Resurrecting regmove is not an option. Time is better spent on figuring out
> what regmove does, that makes a difference, and see if IRA can be taught to do
> the same.
>
x86 has
(def
--- Comment #26 from steven at gcc dot gnu dot org 2008-11-30 20:45 ---
Resurrecting regmove is not an option. Time is better spent on figuring out
what regmove does, that makes a difference, and see if IRA can be taught to do
the same.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #6 from sgunderson at bigfoot dot com 2008-11-30 20:40 ---
Subject: Re: Massive performance regression
for jpeg_idct_islow
On Sun, Nov 30, 2008 at 08:37:31PM -, rguenth at gcc dot gnu dot org wrote:
> --- Comment #5 from rguenth at gcc dot gnu dot org 2008-
--- Comment #6 from domob at gcc dot gnu dot org 2008-11-30 20:40 ---
This second commit detects cases like the one mentioned by Tobias in comment #2
on trunk/4.4 I'm going to work on a optional runtime-recursion checking
feature now as last part for this PR.
--
http://gcc.gnu.org/
--- Comment #5 from domob at gcc dot gnu dot org 2008-11-30 20:37 ---
Subject: Bug 37779
Author: domob
Date: Sun Nov 30 20:36:10 2008
New Revision: 142299
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142299
Log:
2008-11-30 Daniel Kraft <[EMAIL PROTECTED]>
PR fortran
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-11-30 20:37 ---
What is the gcc output if you append -v?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38328
--- Comment #4 from sgunderson at bigfoot dot com 2008-11-30 20:32 ---
Subject: Re: Massive performance regression
for jpeg_idct_islow
On Sun, Nov 30, 2008 at 04:23:31PM -, rguenth at gcc dot gnu dot org wrote:
> Which tuning are you using? Try enabling -mtune=generic (pos
--- Comment #6 from pault at gcc dot gnu dot org 2008-11-30 19:53 ---
Index: libgfortran/generated/reshape_r4.c
===
--- libgfortran/generated/reshape_r4.c (revision 142291)
+++ libgfortran/generated/reshape_r4.c (working c
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-30 19:50 ---
You mean like
g++ -S -O2 t.C -Wall
t.C: In function int main(int, char**):
t.C:12: warning: array subscript is above array bounds
? Seriously, there is too many code around modifying the induction variable
in a
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-11-30 19:38 ---
Yeah, that definitely complicates matters.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35560
--- Comment #4 from pinskia at gmail dot com 2008-11-30 19:29 ---
Subject: Re: Missing CSE/PRE for memory operations involved in virtual call.
I think this bug is invalid since the type can change via a placement
new which will change the vtable.
Sent from my iPhone
On Nov 30, 2008
I think this bug is invalid since the type can change via a placement
new which will change the vtable.
Sent from my iPhone
On Nov 30, 2008, at 4:09 AM, "rguenth at gcc dot gnu dot org" <[EMAIL PROTECTED]
> wrote:
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-11-30
12:09
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2008-11-30 19:27
---
Thanks for the reduced testcase.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2008-11-30 19:24
---
Subject: Bug 38287
Author: ebotcazou
Date: Sun Nov 30 19:23:38 2008
New Revision: 142298
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142298
Log:
PR target/38287
* config/sparc/sparc.md
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2008-11-30 19:23
---
Subject: Bug 38287
Author: ebotcazou
Date: Sun Nov 30 19:22:40 2008
New Revision: 142297
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142297
Log:
PR target/38287
* config/sparc/sparc.md
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2008-11-30 19:22
---
Subject: Bug 38287
Author: ebotcazou
Date: Sun Nov 30 19:21:10 2008
New Revision: 142296
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142296
Log:
PR target/38287
* config/sparc/sparc.md
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-11-30 19:20
---
Subject: Bug 38287
Author: ebotcazou
Date: Sun Nov 30 19:19:06 2008
New Revision: 142295
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142295
Log:
PR target/38287
* config/sparc/sparc.md
Add warning about modifying an index in a for loop.
Without this warning the kind of errors introduced in code are likely to be
very difficult to debug (core dump).
Example code to reproduce below. Current commandline used to compile: -ansi
-pedantic -Wall -O.
#include
using namespace std;
in
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-11-30 18:50 ---
Created an attachment (id=16794)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16794&action=view)
patch re-enabling the warning
So we have a new blocker here... attaching the otherwise working patch.
--
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-11-30 17:55 ---
The testcase in this PR works since GCC 4.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27432
--- Comment #2 from janus at gcc dot gnu dot org 2008-11-30 17:50 ---
Created an attachment (id=16793)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16793&action=view)
patch v1
Attached is a minimal patch, which makes the simple case work where a separate
result variable is used,
--- Comment #7 from janus at gcc dot gnu dot org 2008-11-30 17:42 ---
Regarding the validity see also
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/5d2154a34072eb72/d9d7f1edde9aaa5b
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37254
For g++.dg/opt/pmf1.C we generate
struct Container t;
...
:
D.1857_10 = (int (*__vtbl_ptr_type) (void) * *) &t;
D.1858_11 = *D.1857_10;
a strict-aliasing warning is created if SRA is enabled and PR36509 is fixed.
The frontend should probably use a ref-all pointer for the access.
--
--- Comment #9 from hjl at gcc dot gnu dot org 2008-11-30 16:49 ---
Subject: Bug 38272
Author: hjl
Date: Sun Nov 30 16:48:00 2008
New Revision: 142294
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142294
Log:
2008-11-30 H.J. Lu <[EMAIL PROTECTED]>
PR rtl-optimization
--- Comment #8 from danglin at gcc dot gnu dot org 2008-11-30 16:42 ---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-11-30 16:39 ---
Not on all targets though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306
--- Comment #7 from danglin at gcc dot gnu dot org 2008-11-30 16:37 ---
Subject: Bug 38283
Author: danglin
Date: Sun Nov 30 16:35:59 2008
New Revision: 142293
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142293
Log:
PR middle-end/38283
* varasm.c (emutls_finish
--- Comment #5 from jv244 at cam dot ac dot uk 2008-11-30 16:26 ---
(In reply to comment #4)
> 4.3:
> -O3 -march=native -funroll-loops -ffast-math ==> 4.376
> -O3 -march=native -funroll-loops -ffast-math -fschedule-insns ==> 3.372
strangely:
http://gcc.gnu.org/online
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-11-30 16:23 ---
Which tuning are you using? Try enabling -mtune=generic (possibly by default).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38328
--- Comment #4 from jv244 at cam dot ac dot uk 2008-11-30 16:17 ---
(In reply to comment #2)
> Due to the high density of branches in the code this is easily a code layout
> and/or padding issue. Different architectures have different constraints on
> their decoders and branch predictor
--- Comment #10 from Woebbeking at web dot de 2008-11-30 15:46 ---
And if you've many overloads of a virtual function and override only one you
also get a warning. And in some projects this happens very often :-(
So I also support this suggestion!
--
Woebbeking at web dot de changed
package pak1 is
type T1 is abstract tagged null record;
procedure p1(X : T1) is abstract;
pragma Import (Ada, p1);--ERROR: can't complete an abstract subprogram
end pak1;
B.1(22) says that an Import pragma must be the completion of a
declaration, and 6.1(20) says that a completion is
with Text_io; use Text_io;
procedure test1 is
type Root (K : boolean) is tagged null record;
type Root_Access is access Root'Class;
type Child is new Root (K => True) with null record;
Var : Root_Access;
begin
begin
Var := new Child'(K => False);
put_line("FAILED " & B
--- Comment #14 from joseph at codesourcery dot com 2008-11-30 15:37
---
Subject: Re: O2 causes invalid code
On Sun, 30 Nov 2008, rguenth at gcc dot gnu dot org wrote:
> Note that the C standard forbids type-punning through a union.
> Basically it says that you may only read from a
--- Comment #7 from Woebbeking at web dot de 2008-11-30 15:36 ---
Any progress on this?
This warning could be really useful if only 1) would be handled. In its current
state I can't use it as I get too many "false" positives :-(
--
Woebbeking at web dot de changed:
What
--- Comment #2 from ludovic at ludovic-brenta dot org 2008-11-30 15:16
---
*** Bug 38331 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16094
--- Comment #1 from ludovic at ludovic-brenta dot org 2008-11-30 15:16
---
*** This bug has been marked as a duplicate of 16094 ***
--
ludovic at ludovic-brenta dot org changed:
What|Removed |Added
---
generic
type Item (<>) is private;
with function "=" (L, R : Item) return Boolean is <>;
package pak1 is
end pak1;
with pak1;
package pak2 is
type T is tagged null record;
package new_pak1a is new pak1 (Item => T'Class);--OK by AI05-71
package new_pak1b is new pak1 (Item => T'C
--- Comment #2 from sgunderson at bigfoot dot com 2008-11-30 15:06 ---
OK, I looked at the source. The issue here seems to be that 4.4 likes to
compile this:
z3 = ((z3) * (- ((INT32) 16069)));
into this:
10 0.0403 : 805cc87: lea(%ecx,%ecx,4),%ebx
: 80
--- Comment #1 from hjl dot tools at gmail dot com 2008-11-30 15:00 ---
Can you try -fno-ira to see if it fixes the problem?
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
generic
type T1 is tagged private;
package pak1 is
type T2 is new T1 with
record
i,j: integer;
end record;
x1: T2 := T2'(2,3);-- ERROR:
x2: T2 := T2'(T1 with 2,3);-- OK
end pak1;
The declaration of x1 is illegal because t
package pak1 is
end pak1;
package pak1.pak2 is
x1: integer;
end pak1.pak2;
private with pak1.pak2;
generic
package pak1.pak3 is
x2 : integer := pak1.pak2.x1; -- ERROR: "pak2" is not visible
x3 : integer := pak2.x1;-- ERROR: "pak2" is not visible
end pak1.pak3;
In Pak1.Pak3, Pa
First of all, I'm using Debian's gcc-snapshot package:
gcc version 4.4.0 20081117 (experimental) [trunk revision 141948] (Debian
20081117-1)
Let me know if I should try to rebuild with another GCC version.
I tested my image scaler (http://bzr.sesse.net/qscale/) and libjpeg with 4.4
vs. 4.3, a
with Ada.Streams;
package pak1 is
type T3 is abstract new Ada.Streams.Root_Stream_Type with null record;
type T3_access is access T3;
end pak1;
with pak1;
procedure test is
type T1 is tagged null record;
type T2 is new T1 with null record;
x1: pak1.T3_access;
x2: T2;
begin
T
--- Comment #10 from pault at gcc dot gnu dot org 2008-11-30 13:13 ---
(In reply to comment #9)
> I might as well take it too:-)
Since I cannot reproduce the bug, even at -m32, I am unassigning myself.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from janus at gcc dot gnu dot org 2008-11-30 12:28 ---
I'm not sure the codes in comment #1 and #3 are actually valid, or if gfortran
is right to reject them. See also PR33162 comment #9, where Jerry concludes
that a similar thing should be rejected (this is proc_decl_8.f9
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
CC|ebotcazou at gcc dot gnu dot|
|org |
Assigned
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-11-30 12:09 ---
Note that we also do not CSE OBJ_TYPE_REF trees which seem to be valid gimple
in place of the call in GIMPLE_CALLs so they do not get a separate
value-number.
(not that we would do anything useful with them if they w
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-11-30 12:06
---
Works fine with GCC 4.2.x and later.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-11-30 12:01 ---
PRE now does the correct thing:
pretmp.13_12 = *entry_ptr_1(D);
:
# prephitmp.14_14 = PHI
D.1235_4 = prephitmp.14_14;
D.1239_5 = (int *) D.1235_4;
with pretmp and the prephitmp being (void *) pointers.
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-11-30 11:56 ---
Well, the middle-end thinks that *ap is clobbered by the calls to foo/bar
(which it obviously is). The middle-end has no idea that the _vptr member
of *ap is special and not clobbered (is it?). We do not have a sui
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-11-30 11:48 ---
Oh, maybe try -fno-tree-reassoc as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306
--- Comment #3 from ubizjak at gmail dot com 2008-11-30 11:43 ---
(In reply to comment #2)
> and what about 32-bits?
The quote from i386.c:
/* ??? This is a lie. We do have moves between mmx/general, and for
mmx/sse2. But by saying we need secondary memory we discourage the
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-11-30 11:43
---
Note that the C standard forbids type-punning through a union. Basically it
says
that you may only read from a union member if you have previously written to
it.
It also says that all other bits apart from the one
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-11-30 11:38 ---
Due to the high density of branches in the code this is easily a code layout
and/or padding issue. Different architectures have different constraints on
their decoders and branch predictors related to branch density
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-11-30 11:33 ---
Also the compiler is able to do this optimization.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38302
--- Comment #19 from rguenther at suse dot de 2008-11-30 11:19 ---
Subject: Re: [4.4 Regression] unaligned stack in main
due to tail call optimization
On Sat, 29 Nov 2008, hjl dot tools at gmail dot com wrote:
> --- Comment #18 from hjl dot tools at gmail dot com 2008-11-29 21:1
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2008-11-30 10:52
---
Do you have local changes? This works fine on SuSE:
http://gcc.gnu.org/ml/gcc-testresults/2008-11/msg02676.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38326
seen with 4.3 branch 20081115 20081122
/home/packages/gcc/gcj-4.3-4.3.2/build/ia64-linux-gnu/libjava$
/home/packages/gcc/gcj-4.3-4.3.2/build/gcc/gcj
-B/home/packages/gcc/gcj-4.3-4.3.2/build/ia64-linux-gnu/libjava/
-B/home/packages/gcc/gcj-4.3-4.3.2/build/gcc/ -funwind-tables -fclasspath=
-fbootcla
--- Comment #2 from bechir dot zalila at gmail dot com 2008-11-30 10:27
---
(In reply to comment #1)
> 0.1 is not exactly representable in a binary float format.
>
Sure, but in former versions of GNAT-GCC (4.2.X), the expected value
(1.0E-01) was displayed.
--
bech
--- Comment #2 from pluto at agmk dot net 2008-11-30 10:23 ---
(In reply to comment #1)
> You need -mtune=core to generate "movd %xmm0, %rax". Gcc 4.4 works.
is movd faster only on core2 architecture?
and what about 32-bits?
$ /opt/gcc44/bin/gcc movd.c -O2 -S -march=core2 -m32
foo:
--- Comment #1 from schwab at suse dot de 2008-11-30 10:10 ---
0.1 is not exactly representable in a binary float format.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38325
The test case below shows a bug in the Long_Long_Float'Image function on
FreeBSD 7:
File test_float.adb;
with Ada.Text_IO; use Ada.Text_IO;
procedure Test_Float is
L : Long_Long_Float := 1.000;
LL : Long_Long_Float := 10.000;
begin
Put_Line (Long_Long_Float'Im
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2008-11-30 09:54
---
What's the status of this patch exactly?
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
---
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot
|dot org
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2008-11-30 09:45
---
Known to work.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2008-11-30 09:43
---
Not reproducible.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 111 matches
Mail list logo
