--- Comment #3 from hjl dot tools at gmail dot com 2010-08-21 04:10 ---
(In reply to comment #2)
How are they are not commutative with respect of the NaNs? Is it only when
both are operands are NaNs, it causes an issue?
If I read your testcase correctly, x87 and SSE both don't
--- Comment #4 from hjl dot tools at gmail dot com 2010-08-21 04:14 ---
(In reply to comment #2)
How are they are not commutative with respect of the NaNs? Is it only when
both are operands are NaNs, it causes an issue?
Yes, only when both operands and NaNs with SSE FP
--- Comment #3 from hjl dot tools at gmail dot com 2010-08-21 05:13 ---
On Linux/Intel64, I got
time /usr/gcc-4.5/bin/gcc -m32 -O2 pr45364.i -g -c /tmp
/usr/gcc-4.5/bin/gcc -m32 -O2 pr45364.i -g -c 110.63s user 0.17s system 99%
cpu 1:50.87 total
[...@gnu-6 tmp]$ /usr/gcc-4.5/bin
--- Comment #5 from hjl dot tools at gmail dot com 2010-08-21 05:21 ---
*** This bug has been marked as a duplicate of 45336 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #11 from hjl dot tools at gmail dot com 2010-08-21 05:21
---
*** Bug 41323 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-08-19 13:31 ---
Please hold off any changes. I am talking to icc people
about this. I hope to come up with a solution soon.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2010-08-19 13:34 ---
(In reply to comment #1)
Created an attachment (id=21518)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21518action=view) [edit]
gcc46-pr45336.patch
If you are complaining about the 2 gradual sign
--- Comment #3 from hjl dot tools at gmail dot com 2010-08-19 14:20 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|NEW
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45324
Product: gcc
Version: 4.5.3
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://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #1 from hjl dot tools at gmail dot com 2010-08-19 18:20 ---
It is caused by revision 163293
http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00504.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.5.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45344
--- Comment #4 from hjl dot tools at gmail dot com 2010-08-19 19:38 ---
It is caused by revision 162918:
http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00129.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45350
--- Comment #1 from hjl dot tools at gmail dot com 2010-08-19 22:52 ---
It may be caused by revision 163383:
http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00595.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
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=45324
: 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=45325
--- Comment #13 from hjl dot tools at gmail dot com 2010-08-18 23:08
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status
--- Comment #25 from hjl dot tools at gmail dot com 2010-08-17 14:47
---
(In reply to comment #24)
I think that's beginning to look reasonable. So the problem was that without
alternative 2, such an add would match alternative 3 instead and be split?
Yes.
--
http
--- Comment #5 from hjl dot tools at gmail dot com 2010-08-17 17:41 ---
It 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 |Added
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #18 from hjl dot tools at gmail dot com 2010-08-18 03:29
---
If you believe it is a gcc bug, please provide a small run-time
testcase which can be linked with any /usr/lib64/libc.a compiled
from glibc 2.12.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286
--- Comment #2 from hjl dot tools at gmail dot com 2010-08-18 03:31 ---
It is caused by revision 144044:
http://gcc.gnu.org/ml/gcc-cvs/2009-02/msg00210.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2010-08-18 03:36 ---
It is caused by revision 161655:
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg6.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #20 from hjl dot tools at gmail dot com 2010-08-18 03:59
---
(In reply to comment #19)
as we stated, you wont hit the bug with vanilla gcc + vanilla glibc. we also
arent absolutely stating this is a gcc bug. our dissection of the problem
lead us from cryptsetup
--- Comment #8 from hjl dot tools at gmail dot com 2010-08-16 13:19 ---
Created an attachment (id=21490)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21490action=view)
The preprocessed source
It should be compiled with
-march=i486 -ftls-model=initial-exec -mtune=i586 -O2 -fPIC
--- Comment #2 from hjl dot tools at gmail dot com 2010-08-16 14:48 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status
--- Comment #3 from hjl dot tools at gmail dot com 2010-08-16 14:52 ---
*** This bug has been marked as a duplicate of 41323 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from hjl dot tools at gmail dot com 2010-08-16 14:52 ---
*** Bug 45294 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41323
--- Comment #2 from hjl dot tools at gmail dot com 2010-08-16 14:54 ---
Apparently, it isn't a problem for icc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41323
--- Comment #3 from hjl dot tools at gmail dot com 2010-08-16 15:47 ---
Since we implement _mm_XXX intrinsics with __builtin_ia32_XXX,
we can make the prototype of __builtin_ia32_XXX to match the hardware.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41323
--- Comment #4 from hjl dot tools at gmail dot com 2010-08-16 17:25 ---
Apparently, icc treats those intrinsics as returning unsigned int.
I will investigate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41323
--- Comment #20 from hjl dot tools at gmail dot com 2010-08-17 00:10
---
(In reply to comment #18)
I'm seeing some strange situations where this code is unnecessarily producing
lea insns even when not tuning for Atom.
This code looks very strange. I don't understand why we aren't
--- Comment #21 from hjl dot tools at gmail dot com 2010-08-17 00:11
---
(In reply to comment #19)
Created an attachment (id=21497)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21497action=view) [edit]
A patch which should produce more add insns
In other words, don't we
--- Comment #23 from hjl dot tools at gmail dot com 2010-08-17 03:46
---
Created an attachment (id=21499)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21499action=view)
A different patch
We added the 2rd alternative to *addmode_1 for Atom
so that we always use add instead lea
--- Comment #7 from hjl dot tools at gmail dot com 2010-08-15 20:36 ---
It works for me:
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /export/home/hjl/bugs/gcc/pr45286/foo
Breakpoint 1, sigvtalarm (foo=0
--- Comment #9 from hjl dot tools at gmail dot com 2010-08-15 20:45 ---
You have to show me exact CFLAGS used to compile sigaction.c.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286
--- Comment #11 from hjl dot tools at gmail dot com 2010-08-15 21:15
---
It works for me with -fPIC -fPIE using gcc 4.4.4 on
Fedora 13. I got
movq__restore...@gotpcrel(%rip), %rax
movq%rax, 56(%rsp)
in assembly output. It is correct. Please make sure that
you
--- Comment #13 from hjl dot tools at gmail dot com 2010-08-15 21:36
---
(In reply to comment #12)
(In reply to comment #11)
It works for me with -fPIC -fPIE using gcc 4.4.4 on
Fedora 13. I got
movq__restore...@gotpcrel(%rip), %rax
movq%rax, 56(%rsp
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=45292
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Known to fail||4.5.3 4.6.0
Known to work||4.4.4
--- Comment #1 from hjl dot tools at gmail dot com 2010-08-16 01:13 ---
It is caused by revision 145825:
http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00448.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2010-08-16 01:18 ---
libgomp is miscompiled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45292
--- Comment #3 from hjl dot tools at gmail dot com 2010-08-16 02:29 ---
task.o is miscompiled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45292
--- Comment #4 from hjl dot tools at gmail dot com 2010-08-16 02:52 ---
gomp_barrier_handle_tasks is miscompiled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45292
--- Comment #5 from hjl dot tools at gmail dot com 2010-08-16 05:04 ---
Disable
+(define_expand cmpcc
+ [(set (reg:CC FLAGS_REG)
+(compare:CC (match_operand 0 flags_reg_operand )
+(match_operand 1 general_operand )))]
+
+{
+ ix86_compare_op0 = operands[0
--- Comment #6 from hjl dot tools at gmail dot com 2010-08-16 05:18 ---
-mtune=i586 miscompiled gomp_barrier_handle_tasks which
has a loop and calls:
static inline void gomp_mutex_lock (gomp_mutex_t *mutex)
{
if (!__sync_bool_compare_and_swap (mutex, 0, 1))
gomp_mutex_lock_slow
--- Comment #9 from hjl dot tools at gmail dot com 2010-08-14 22:23 ---
assert is too strong as shown in the testcase.
This patch works for me:
--
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index b925122..863c9bf 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config
--- Comment #3 from hjl dot tools at gmail dot com 2010-08-15 02:25 ---
(In reply to comment #0)
http://bugs.gentoo.org/show_bug.cgi?id=283470
kact.sa_restorer = restore_rt; get miss compile with -fPIE
with -fPIC the code get
48 8d 05 2e ff ff fflea-0xd2(%rip),%rax # 10
--- Comment #5 from hjl dot tools at gmail dot com 2010-08-15 05:40 ---
Please help me reproduce it with a run-time testcase. I can build
libc.a.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286
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=45266
--- Comment #2 from hjl dot tools at gmail dot com 2010-08-12 15:48 ---
(In reply to comment #1)
The pattern doesn't match even though I see two memcpy calls!?
I am using
# make RUNTESTFLAGS=--target_board 'unix{-m32,}' check
2 failures are 1 for 64bit and 1 for 32bit.
--
hjl
--- Comment #4 from hjl dot tools at gmail dot com 2010-08-12 16:44 ---
I was wrong. Linux/ia32 has the same regression:
FAIL: gfortran.dg/array_memcpy_3.f90 -O scan-tree-dump-times original
memcpy|(ref-all.*ref-all) 2
--
hjl dot tools at gmail dot com changed:
What
--- Comment #1 from hjl dot tools at gmail dot com 2010-08-12 19:09 ---
It is fixed by revision 158732:
http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00839.html
on trunk.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2010-08-12 20:16 ---
It was triggered by revision 151511:
http://gcc.gnu.org/ml/gcc-cvs/2009-09/msg00257.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45267
--- Comment #10 from hjl dot tools at gmail dot com 2010-08-11 19:12
---
(In reply to comment #9)
Apparently some KVM versions claim to be GenuineIntel family 6 model 6 with
lm,
but not ssse3, see
https://bugzilla.redhat.com/show_bug.cgi?id=620562
Perhaps the has_longmode - core2
--- Comment #11 from hjl dot tools at gmail dot com 2010-08-11 20:31
---
Maybe we can improve the unknown processor support:
1. For 32bit, use i686 + -mSSEx.
2. For 64bit, use x86_64 + -mSSEx.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44046
--- Comment #2 from hjl dot tools at gmail dot com 2010-08-11 23:58 ---
It was caused by revision 153878:
http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00094.html
and disappeared with revision 159514:
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00566.html
I am not if it really fixed the bug
--- Comment #2 from hjl dot tools at gmail dot com 2010-08-12 03:14 ---
It failed for me with gcc 4.2 and 4.3.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #15 from hjl dot tools at gmail dot com 2010-08-10 13:36
---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00734.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #5 from hjl dot tools at gmail dot com 2010-08-09 15:51 ---
(In reply to comment #4)
H.J, this was introduced by your commit:
...
By backing out lines marked as ***, compilation succeeds.
Can you take a look at the assembly output to see if
the stack is realigned
--- Comment #7 from hjl dot tools at gmail dot com 2010-08-09 16:19 ---
__builtin_alloca (var) is handled properly. __builtin_alloca (const int)
is a special case. I am looking into it now.
--
hjl dot tools at gmail dot com changed:
What|Removed
--- Comment #8 from hjl dot tools at gmail dot com 2010-08-09 16:28 ---
/* Adjust the stack pointer by minus ADJUST (an rtx for a number of bytes).
This pushes when ADJUST is positive. ADJUST need not be constant. */
void
anti_adjust_stack (rtx adjust)
{
rtx temp;
if (adjust
--- Comment #9 from hjl dot tools at gmail dot com 2010-08-09 16:38 ---
Does this patch:
--
diff --git a/gcc/calls.c b/gcc/calls.c
index cd0d9c5..cbb0944 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -2846,7 +2846,8 @@ expand_call (tree exp, rtx target, int ignore)
/* Stack
--- Comment #11 from hjl dot tools at gmail dot com 2010-08-09 17:01
---
(In reply to comment #9)
Does this patch:
--
diff --git a/gcc/calls.c b/gcc/calls.c
index cd0d9c5..cbb0944 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -2846,7 +2846,8 @@ expand_call (tree exp, rtx
--- Comment #12 from hjl dot tools at gmail dot com 2010-08-09 17:24
---
Created an attachment (id=21442)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21442action=view)
A patch
This patch seems to work for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45234
--- Comment #1 from hjl dot tools at gmail dot com 2010-08-10 04:29 ---
*** This bug has been marked as a duplicate of 45182 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #6 from hjl dot tools at gmail dot com 2010-08-10 04:29 ---
*** Bug 45242 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2010-08-07 18:46 ---
It is caused by revision 162842:
http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00053.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45219
--- Comment #4 from hjl dot tools at gmail dot com 2010-08-06 21:02 ---
I opened:
http://www.sourceware.org/bugzilla/show_bug.cgi?id=11893
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #5 from hjl dot tools at gmail dot com 2010-08-06 21:51 ---
The bug is in gcc. pushq $imm32S only takes 32bit signed extended
immediate. You can't push 0xbf80. Instead, you push -1082130432
or 0xbf80.
--
hjl dot tools at gmail dot com changed
--- Comment #6 from hjl dot tools at gmail dot com 2010-08-06 22:10 ---
This patch:
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 204211a..3dfbede 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -12921,7 +12921,7 @@ ix86_print_operand (FILE
--- Comment #7 from hjl dot tools at gmail dot com 2010-08-06 22:39 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00528.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from hjl dot tools at gmail dot com 2010-08-05 14:04 ---
It is caused by revision 162888:
http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00099.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45189
--- Comment #3 from hjl dot tools at gmail dot com 2010-08-05 16:38 ---
-fpic is broken. On Fedora 13, I got:
[...@gnu-15 gcc]$ ./xgcc -B./
/net/gnu-6/export/gnu/import/git/gcc/gcc/testsuite/g++.dg/torture/stackalign/eh-thiscall-1.C
-mstackrealign -mpreferred-stack-boundary=5 -O -c
--- Comment #6 from hjl dot tools at gmail dot com 2010-08-05 16:44 ---
Unlike integer modes, middle-end only knows memory when moving with
subreg on vector mode.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #7 from hjl dot tools at gmail dot com 2010-08-05 16:58 ---
Can we add direct support for moving with (subreg:DI (reg:TI)) and
(subreg:TI (reg:OI))?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45198
--- Comment #5 from hjl dot tools at gmail dot com 2010-08-05 22:42 ---
It 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 |Added
-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=45182
--- Comment #1 from hjl dot tools at gmail dot com 2010-08-04 14:49 ---
[...@gnu-35 delta]$ cat testcase-min.i
typedef struct TypHeader {
struct TypHeader * * ptr;
} * TypHandle;
void PlainRange ( hdList ) TypHandle hdList;
{
long lenList;
long low;
long inc
--- Comment #3 from hjl dot tools at gmail dot com 2010-08-04 15:36 ---
It is caused by revision 162849:
http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00060.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45182
--- Comment #4 from hjl dot tools at gmail dot com 2010-08-04 15:57 ---
This testcase doesn't have any warnings:
---
typedef struct TypHeader {
struct TypHeader ** ptr;
} *TypHandle;
void PlainRange (TypHandle hdList, long lenList, long low, long inc)
{
long i;
for (i = 1; i
: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
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=45183
: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45188
: debug
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=45189
--- Comment #13 from hjl dot tools at gmail dot com 2010-08-03 14:24
---
gfortran.dg/maxlocval_3.f90 is due to assembler warning:
/tmp/cc9gn3uW.s:3475: Warning: Use of 'movl' may violate WAW dependency 'GR%, %
in 1 - 127' (impliedf), specific resource number is 24^M
/tmp/cc9gn3uW.s
--- Comment #18 from hjl dot tools at gmail dot com 2010-08-04 00:28
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status
regression] New Fortran failuires
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
--- Comment #5 from hjl dot tools at gmail dot com 2010-07-30 14:48 ---
In fact, revision 162688 gave:
FAIL: c-c++-common/uninit-17.c (test for warnings, line 12)
FAIL: c-c++-common/uninit-17.c (test for warnings, line 14)
FAIL: c-c++-common/uninit-17.c (test for excess errors)
FAIL
--- Comment #6 from hjl dot tools at gmail dot com 2010-07-30 18:54 ---
Fixed by revision 162720.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
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=45131
--- Comment #1 from hjl dot tools at gmail dot com 2010-07-29 14:12 ---
It may be caused by revision 162653:
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg01007.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2010-07-29 14:16 ---
It happened between revision 162661 and revision 162667.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2010-07-29 14:19 ---
It is caused by revision 162667:
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg01021.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #5 from hjl dot tools at gmail dot com 2010-07-29 15:47 ---
(In reply to comment #4)
HJ, as it works on most systems, can you do some debugging?
Trunk was broken since yesterday and was fixed a while ago.
a) Does the system has HAVE_TTYNAME defined for libgfortran
--- Comment #4 from hjl dot tools at gmail dot com 2010-07-29 22:30 ---
It isn't fixed. Revision 162688 gave
FAIL: c-c++-common/uninit-17.c (test for warnings, line 14)
FAIL: c-c++-common/uninit-17.c -Wc++-compat (test for warnings, line 14)
--
hjl dot tools at gmail dot com
--- Comment #2 from hjl dot tools at gmail dot com 2010-07-30 00:32 ---
It is caused by revision 161655:
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg6.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #4 from hjl dot tools at gmail dot com 2010-07-30 04:11 ---
I was wrong. It never worked.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45136
Version: 4.6.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=45119
--- Comment #1 from hjl dot tools at gmail dot com 2010-07-29 00:55 ---
Revision 162649 is OK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45119
201 - 300 of 3333 matches
Mail list logo
