--- Comment #5 from pault at gcc dot gnu dot org 2008-11-30 08:04 ---
This is fixed for trunk and 4.3.
I have prepared a testcase that will be committed tonight.
Thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed
--- Comment #17 from andreast at gcc dot gnu dot org 2008-11-30 08:22
---
http://gcc.gnu.org/ml/gcc-testresults/2008-11/msg02671.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38314
--- Comment #6 from pault at gcc dot gnu dot org 2008-11-30 08:50 ---
Subject: Bug 35824
Author: pault
Date: Sun Nov 30 08:48:51 2008
New Revision: 142292
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142292
Log:
2008-11-30 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2008-11-30 09:04
---
Visible on SPARC 64-bit. IMHO this is serious and should be fixed for 4.4.0.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2008-11-30 09:21
---
A little better with the current 4.4.0 compiler:
t.c:3: warning: cast from pointer to integer of different size
t.c:3: error: initializer element is not constant
but not as good as with the Sun compiler.
--
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P3
Summary|Vectorizer failures (max, |vectorizer
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-11-30 09:27
---
Works for me on Solaris 10 as well.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2008-11-30 09:30
---
*** This bug has been marked as a duplicate of 37344 ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2008-11-30 09:30
---
*** Bug 37279 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37344
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2008-11-30 09:33
---
Presumably spurious.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2008-11-30 09:37
---
Visible on SPARC 64-bit.
And IA-64, s390x, x86_64-darwin, etc. So almost all 64-bit platforms.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- 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
--- 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
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
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
--- 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
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
--- 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.
--
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=
--- 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
--- 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
--- 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 #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
--- 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 #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
--- 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 #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
--- 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
--- 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 #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);
bb 5:
# prephitmp.14_14 = PHI current_automata_list_3(D)(3), pretmp.13_12(4)
D.1235_4 = prephitmp.14_14;
D.1239_5 = (int *) D.1235_4;
with
--- 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 #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
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
CC|ebotcazou at gcc dot gnu dot|
|org |
--- 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
--- 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
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
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,
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, Pak2
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
--- 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
--- 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
:
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'Class, =
--- 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
--- 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 #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 #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
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
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
--- 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
--- 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 predictors
--- 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 #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:
--- 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=gccview=revrev=142293
Log:
PR middle-end/38283
* varasm.c
--- 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 #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
--- 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=gccview=revrev=142294
Log:
2008-11-30 H.J. Lu [EMAIL PROTECTED]
PR
For g++.dg/opt/pmf1.C we generate
struct Container t;
...
bb 3:
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 #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
--- 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=16793action=view)
patch v1
Attached is a minimal patch, which makes the simple case work where a separate
result variable is used,
--- 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 #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=16794action=view)
patch re-enabling the warning
So we have a new blocker here... attaching the otherwise working patch.
--
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 iostream
using namespace
--- 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=gccview=revrev=142295
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=gccview=revrev=142296
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=gccview=revrev=142297
Log:
PR target/38287
* config/sparc/sparc.md
--- 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=gccview=revrev=142298
Log:
PR target/38287
* config/sparc/sparc.md
--- 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
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 #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,
--- 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 #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 #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
--- 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
--- 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 #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=gccview=revrev=142299
Log:
2008-11-30 Daniel Kraft [EMAIL PROTECTED]
PR
--- 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.
--
--- 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
--- 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.
--
--- 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
--- 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.
--
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 #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
--- 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 #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
--- 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 ;)
--- 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.
--- 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 #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 #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=16795action=view)
patch v2
This updated patch passes the testsuite without regressions and adds some
additional checks.
--
--- 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
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38072
--
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
Summary|[4.3 regression] Inlined|[4.2/4.3 Regression] Inlined
|con/de-structor
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Priority|P3 |P2
Last
--- 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
--- 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
--- 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
--- 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.
--
--- 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
1 - 100 of 111 matches
Mail list logo
