: 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=45361
--- Comment #7 from hjl dot tools at gmail dot com 2010-08-20 16:54 ---
Created an attachment (id=21531)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21531&action=view)
A patch
I talked to icc people. They think the return value should be
zero-extended to reflex what h
ion 163403 Failed to bootstrap
Product: gcc
Version: 4.5.3
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.gn
--- Comment #1 from hjl dot tools at gmail dot com 2010-08-20 13:52 ---
We are running out of stack in recursive call:
Program received signal SIGSEGV, Segmentation fault.
0x41bf3c90 in if_then_else_cond (x=0x23ef08d0,
ptrue=0x6ef88070, pfalse
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=45355
--- 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
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45350
--- 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
--
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 #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
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
--
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
--- 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
--- 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=21518&action=view) [edit]
> gcc46-pr45336.patch
>
> If you are complaining about
--- 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 #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
.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=45325
Component: testsuite
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
--- 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
--- 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 #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 #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
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- 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
--- 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
--- 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=21499&action=view)
A different patch
We added the 2rd alternative to "*add_1" for Atom
so that we always us
--- 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=21497&action=view) [edit]
> A patch which should produce more add insns
>
> In
--- 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&#x
--- 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 #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 #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 #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 #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 #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 #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=21490&action=view)
The preprocessed source
It should be compiled with
-march=i486 -ftls-model=initial-exec -mtune=i586 -O
--- 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 #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&q
--- 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 #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 #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 #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
--
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
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
--- 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(%
--- 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 #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 #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) at
--- 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
--- 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
--- 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 #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 #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 #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:
--- 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
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=45266
--- 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 #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 #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 #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 t
--- 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 #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 #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=21442&action=view)
A patch
This patch seems to work for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45234
--- 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
--- 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 #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 #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 #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
--- 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 #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 #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 #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 0xbf800000.
--
hjl dot tools at gmail
--- 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-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
--- 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 #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 #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 #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
: 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
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45188
char_1.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://gcc.gnu.org/bugzilla/show_bug.cgi?id=45183
--- 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 =
--- 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 #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
: 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=45182
--- 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
--- 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
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 #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
--- 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 #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
--- 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-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 do
--- 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 libgf
--- 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 #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 #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
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 03:49 ---
It is 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 01:06 ---
It is 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
201 - 300 of 3390 matches
Mail list logo
