/array_constructor_11.f90
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http
--- Comment #1 from hjl dot tools at gmail dot com 2010-04-28 21:18 ---
It may be caused by revision 158788:
http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00895.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #4 from hjl dot tools at gmail dot com 2010-04-28 22:01 ---
It is caused by revision 158788:
http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00895.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43924
: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43929
--- Comment #15 from hjl dot tools at gmail dot com 2010-04-29 01:20
---
Revision 139756:
http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg01321.html
also contributed to this regression.
[...@gnu-26 rrs]$ ./131573/usr/bin/gcc -O3 pr43884.c
[...@gnu-26 rrs]$ time ./a.out 45
fib(45
--- Comment #16 from hjl dot tools at gmail dot com 2010-04-29 02:20
---
This patch:
diff --git a/gcc/predict.c b/gcc/predict.c
index eb5ddef..a05e796 100644
--- a/gcc/predict.c
+++ b/gcc/predict.c
@@ -120,7 +120,8 @@ maybe_hot_frequency_p (int freq)
if (cfun-function_frequency
--- Comment #3 from hjl dot tools at gmail dot com 2010-04-27 13:07 ---
Ooops. I meant Linux/ia64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43901
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43910
--- Comment #1 from hjl dot tools at gmail dot com 2010-04-27 13:58 ---
Fixed by revision 158769.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #22 from hjl dot tools at gmail dot com 2010-04-27 13:59
---
On Linux/ia32, I got
FAIL: gfortran.dg/coarray_12.f90 -O scan-tree-dump-times original
a.dim.0..ubound = .* nn; 1
FAIL: gfortran.dg/coarray_12.f90 -O scan-tree-dump-times original
a.dim.1..ubound = .* mm; 1
--- Comment #10 from hjl dot tools at gmail dot com 2010-04-26 13:44
---
(In reply to comment #9)
In the leaf_function_p sense it is non-leaf. For the stack alignment it of
course would be possible to change the stack alignment requirements of the
function if it calls itself
--- Comment #13 from hjl dot tools at gmail dot com 2010-04-26 14:47
---
(In reply to comment #12)
Subject: Re: [4.4/4.5/4.6 Regression] Performance
degradation for simple fibonacci numbers calculation due to extra
stack alignment
That is true. For tail call, we
--- Comment #14 from hjl dot tools at gmail dot com 2010-04-26 18:54
---
It is caused by revision 131576:
http://gcc.gnu.org/ml/gcc-cvs/2008-01/msg00337.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43901
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43903
--- Comment #1 from hjl dot tools at gmail dot com 2010-04-26 22:33 ---
It is caused by revision 158732:
http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00839.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #5 from hjl dot tools at gmail dot com 2010-04-25 22:01 ---
(In reply to comment #4)
Btw, with the optimal options -O2 -fwhole-program -fomit-frame-pointer
-mpreferred-stack-boundary=2 GCC 4.3 and 4.4 are slower than 4.1 and 4.5
(14.3s vs. 13.8s). The extra stack
--- Comment #3 from hjl dot tools at gmail dot com 2010-04-24 13:47 ---
It is caused by revision 153978:
http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00196.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2010-04-24 23:23 ---
It is caused by revision 149750:
http://gcc.gnu.org/ml/gcc-cvs/2009-07/msg00631.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43880
--- Comment #2 from hjl dot tools at gmail dot com 2010-04-24 02:42 ---
*** This bug has been marked as a duplicate of 36159 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #8 from hjl dot tools at gmail dot com 2010-04-24 02:42 ---
*** Bug 43874 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2010-04-22 15:38 ---
It is caused by revision 158506:
http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00612.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43842
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla
--- Comment #3 from hjl dot tools at gmail dot com 2010-04-22 18:07 ---
I think revision 158650:
http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00756.html
is the fix for this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43842
: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43830
--- Comment #1 from hjl dot tools at gmail dot com 2010-04-21 13:43 ---
It will always fail on glibc older than 2.12, which hasn't been
released yet.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from hjl dot tools at gmail dot com 2010-04-21 00:04 ---
Do you have a small testcase?
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2010-04-21 00:14 ---
I have Fedora 12 and Fedora 13. Is there a way to reproduce it with only
executable and leave libraries alone?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43825
--- Comment #5 from hjl dot tools at gmail dot com 2010-04-21 00:17 ---
(In reply to comment #4)
(In reply to comment #3)
I have Fedora 12 and Fedora 13. Is there a way to reproduce it with only
executable and leave libraries alone?
I'm not sure what you mean.
Fedora comes
--- Comment #1 from hjl dot tools at gmail dot com 2010-04-19 14:06 ---
Testcase?
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status
--- Comment #8 from hjl dot tools at gmail dot com 2010-04-19 14:44 ---
On Linux/ia32, I got
Executing on host:
/export/gnu/import/svn/gcc-test/bld/gcc/testsuite/g++2/../../g++
-B/export/gnu/import/svn/gcc-test/bld/gcc/testsuite/g++2/../../
/export/gnu/import/svn/gcc-test/src-trunk/gcc
: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43800
--- Comment #5 from hjl dot tools at gmail dot com 2010-04-19 17:24 ---
Gcc never handles MMX correctly. If you mix MMX and x87, gcc
may generate incorrect code due to missing emms.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #5 from hjl dot tools at gmail dot com 2010-04-19 18:03 ---
It is caused by revision 158483:
http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00589.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43799
--- Comment #6 from hjl dot tools at gmail dot com 2010-04-19 19:51 ---
(In reply to comment #4)
Created an attachment (id=20419)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20419action=view) [edit]
Please show the output of
# head kernel/.rtmutex.o.cmd
--
http
--- Comment #10 from hjl dot tools at gmail dot com 2010-04-19 21:07
---
It may be caused revision 158278:
http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00382.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from hjl dot tools at gmail dot com 2010-04-18 15:20 ---
It is caused by revision 158380:
http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00486.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2010-04-17 14:30 ---
It is caused by revision 153958:
http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00176.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43767
--- Comment #1 from hjl dot tools at gmail dot com 2010-04-16 14:37 ---
Revision 158401:
http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00507.html
is the cause.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2010-04-16 15:32 ---
(In reply to comment #2)
What stage is that? stage1 or something later?
It failed at the end of stage 2:
make[4]: *** [decimal128.o] Error 1
make[3]: *** [all-stage2-libdecnumber] Error 2
make[2]: *** [stage2
--- Comment #6 from hjl dot tools at gmail dot com 2010-04-16 18:08 ---
(In reply to comment #5)
Created an attachment (id=20401)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20401action=view) [edit]
gcc46-pr43767.patch
And here is untested fix.
It passed the failed part
--- Comment #3 from hjl dot tools at gmail dot com 2010-04-17 04:00 ---
It is caused by revision 154667:
http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00890.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
: [4.6 regression] New test failures
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot
--- Comment #5 from hjl dot tools at gmail dot com 2010-04-15 14:57 ---
The failure of the testcase in comment #1 is caused
by revision 145440:
http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00060.html
--
hjl dot tools at gmail dot com changed:
What|Removed
--- Comment #4 from hjl dot tools at gmail dot com 2010-04-14 15:51 ---
On Intel Xeon X3350 2.66GHz with 8GB RAM, I got
[...@gnu-1 gcc]$ time ./xgcc -B./ -g -O2 -S
../../src-trunk/gcc/testsuite/gcc.dg/pr43058.c
real0m9.187s
user0m9.042s
sys 0m0.127s
[...@gnu-1 gcc]$ ./xgcc
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla
--- Comment #4 from hjl dot tools at gmail dot com 2010-04-10 13:37 ---
It is caused by revision 117493:
http://gcc.gnu.org/ml/gcc-cvs/2006-10/msg00158.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43555
--- Comment #5 from hjl dot tools at gmail dot com 2010-04-10 13:39 ---
(In reply to comment #4)
It is caused by revision 117493:
http://gcc.gnu.org/ml/gcc-cvs/2006-10/msg00158.html
Maybe C++ frontend needs similar adjustment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
test
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org
--- Comment #1 from hjl dot tools at gmail dot com 2010-04-09 16:25 ---
It is triggered by
* config/i386/i386.md (movtf): Check TARGET_SSE2 instead of
TARGET_64BIT.
in revision 137276:
http://gcc.gnu.org/ml/gcc-cvs/2008-06/msg01037.html
emit_move_multi_word calls
--- Comment #4 from hjl dot tools at gmail dot com 2010-04-09 16:32 ---
It is caused by revision 157849:
http://gcc.gnu.org/ml/gcc-cvs/2010-03/msg00686.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Regression] FAIL: libgomp.c++/loop-10.C
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot
--- Comment #4 from hjl dot tools at gmail dot com 2010-04-07 18:36 ---
It is caused by revision 138953:
http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg00512.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from hjl dot tools at gmail dot com 2010-04-07 22:04 ---
It is caused by revision 148718:
http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg00701.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2010-04-07 05:42 ---
i386.c has
tmp_reg = gen_reg_rtx (Pmode);
emit_insn (gen_rtx_SET (VOIDmode, tmp_reg,
plus_constant (save_area
--- Comment #3 from hjl dot tools at gmail dot com 2010-04-07 05:59 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00229.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Version: 4.5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43618
--- Comment #3 from hjl dot tools at gmail dot com 2010-04-01 13:59 ---
(In reply to comment #1)
Because we only have an optab for LT (reversed UNGE), but
FLOAT_LIB_COMPARE_RETURNS_BOOL is false.
Without -fno-trapping-math we use LT from the start which works.
I suppose
--- Comment #4 from hjl dot tools at gmail dot com 2010-04-01 15:37 ---
It is caused by revision 149031:
http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg01016.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43610
--- Comment #1 from hjl dot tools at gmail dot com 2010-04-02 02:38 ---
It is caused by revision 156865:
http://gcc.gnu.org/ml/gcc-cvs/2010-02/msg00448.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
regression] Failed to boostrap
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
--- Comment #1 from hjl dot tools at gmail dot com 2010-03-31 04:38 ---
It may be caused by revision 157837:
http://gcc.gnu.org/ml/gcc-cvs/2010-03/msg00674.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43587
--- Comment #12 from hjl dot tools at gmail dot com 2010-03-28 14:44
---
(In reply to comment #10)
Created an attachment (id=20228)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20228action=view) [edit]
Broken stdlib.h
Hi,
This patched caused problems for mingw-w64
--- Comment #2 from hjl dot tools at gmail dot com 2010-03-29 02:49 ---
It is caused by revision 147083:
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00057.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Known to fail||4.5.0
Known to work||4.4.3
--- Comment #5 from hjl dot tools at gmail dot com 2010-03-27 14:11 ---
(In reply to comment #4)
No, sseregparm should be perfectly fine with x87 math - it only needs
(obviously) SSE registers available. It's an ABI switch like regparm,
whether math is done using SSE registers
--- Comment #8 from hjl dot tools at gmail dot com 2010-03-27 14:24 ---
(In reply to comment #7)
I very much doubt that the cited revision fixed anything here.
If it is true, that only means that the bug is latent on trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43247
--- Comment #7 from hjl dot tools at gmail dot com 2010-03-27 15:37 ---
(In reply to comment #6)
I don't follow. TARGET_SSEREGPARM does not mean you'll do SSE math.
It merely says that you can expect incoming arguments in SSE registers
instead of on stack. For -mpreferred-stack
--- Comment #10 from hjl dot tools at gmail dot com 2010-03-26 13:08
---
(In reply to comment #9)
Do they have to be executable?
No.
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2010-03-26 13:50 ---
It will be easier to debug if you provide a run-time testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43537
--- Comment #6 from hjl dot tools at gmail dot com 2010-03-26 15:06 ---
(In reply to comment #4)
(In reply to comment #3)
It will be easier to debug if you provide a run-time testcase.
That qvector.ii contains a main() function that executes test1() and test2().
If you want all
--- Comment #10 from hjl dot tools at gmail dot com 2010-03-26 16:39
---
The original testcase was fixed by revision 151360:
http://gcc.gnu.org/ml/gcc-cvs/2009-09/msg00106.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43537
--- Comment #11 from hjl dot tools at gmail dot com 2010-03-26 18:43
---
This regression was introduced by revision 118729:
http://gcc.gnu.org/ml/gcc-cvs/2006-11/msg00380.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43537
--- Comment #5 from hjl dot tools at gmail dot com 2010-03-26 18:54 ---
This is fixed by revision 151360:
http://gcc.gnu.org/ml/gcc-cvs/2009-09/msg00106.html
and was introduced by revision 118729:
http://gcc.gnu.org/ml/gcc-cvs/2006-11/msg00380.html
--
http://gcc.gnu.org/bugzilla
--- Comment #2 from hjl dot tools at gmail dot com 2010-03-26 23:26 ---
We are trying to store DFmode with SFmode alignment since
compress_float_constant converts 1.0DF to 1.0SF. This patch
works around the problem:
--
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index
--- Comment #3 from hjl dot tools at gmail dot com 2010-03-26 23:29 ---
Created an attachment (id=20219)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20219action=view)
A patch to check TARGET_SSE_MATH instead of TARGET_SSE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43546
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: ia64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43520
--- Comment #1 from hjl dot tools at gmail dot com 2010-03-25 16:15 ---
From
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43058#c17
But clearly it is not var-tracking that eats all the memory, instead it is the
scheduler, and it happens also with -g0, and doesn't happen with
-fno
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Known to fail||4.3.4
Known to work||4.4.4 4.5.0
--- Comment #5 from hjl dot tools at gmail dot com 2010-03-26 00:27 ---
It failed to bootstrap on Linux/ia32:
cc1: warnings being treated as errors
../../src-trunk/gcc/cp/pt.c: In function 'get_template_parms_at_level':
../../src-trunk/gcc/cp/pt.c:2851:16: error: comparison between
--- Comment #7 from hjl dot tools at gmail dot com 2010-03-26 00:30 ---
Why
---
Propchange: trunk/gcc/testsuite/objc-obj-c++-shared/Object1-implementation.h
('svn:executable' added)
Propchange: trunk/gcc/testsuite/objc-obj-c++-shared/Object1.h
('svn:executable
: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43512
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43512
--- Comment #7 from hjl dot tools at gmail dot com 2010-03-21 16:20 ---
(In reply to comment #6)
Shouldn't there be a PR about the suboptimal performance from the core2 tuning
(in hopes that original contributors from Intel will revisit these issues)?
Intel didn't contribute -march
--- Comment #5 from hjl dot tools at gmail dot com 2010-03-20 14:34 ---
I saw
_CRTIMP unsigned int __cdecl __MINGW_NOTHROW _rotl(unsigned int, int)
__MINGW_ATTRIB_CONST;
_CRTIMP unsigned int __cdecl __MINGW_NOTHROW _rotr(unsigned int, int)
__MINGW_ATTRIB_CONST;
_CRTIMP unsigned long
--- Comment #6 from hjl dot tools at gmail dot com 2010-03-20 18:01 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00936.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40722
--- Comment #7 from hjl dot tools at gmail dot com 2010-03-20 18:09 ---
An updated patch is at
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00937.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40722
--- Comment #18 from hjl dot tools at gmail dot com 2010-03-18 13:16
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status
--- Comment #5 from hjl dot tools at gmail dot com 2010-03-18 18:13 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #6 from hjl dot tools at gmail dot com 2010-03-17 15:51 ---
It is caused by revision 157093:
http://gcc.gnu.org/ml/gcc-cvs/2010-02/msg00676.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #1 from hjl dot tools at gmail dot com 2010-03-17 20:27 ---
False alarm. I did run out of memory.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #4 from hjl dot tools at gmail dot com 2010-03-16 13:21 ---
A small tectcase;
--
typedef float __v4sf __attribute__ ((__vector_size__ (16)));
typedef int __v4si __attribute__ ((__vector_size__ (16)));
__v4sf my_asin(__v4sf x)
{
static const __v4si g_Mask{ 0x7fff
--- Comment #5 from hjl dot tools at gmail dot com 2010-03-16 13:57 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00669.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #6 from hjl dot tools at gmail dot com 2010-03-16 14:07 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status
--- Comment #3 from hjl dot tools at gmail dot com 2010-03-16 16:27 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00633.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
Summary: Gcc warns label as local variable
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot
--- Comment #3 from hjl dot tools at gmail dot com 2010-03-16 22:37 ---
(In reply to comment #2)
The way I'm fixing it is adding __k8 to the list of sub targets at lines #150
and #303 of compatibility.h. Seems good enough for 4.5.0. Further improvements
fall under libstdc++/34106
801 - 900 of 3333 matches
Mail list logo
