--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-03
22:49 ---
Subject: Re: FAIL: gfortran.dg/gamma_5.f90
> > Now, the hard part. The gfortran.dg/gamma_5.f90 test fails at n = 16.
>
> This works on my i686-pc-linux-gnu system, and also fails when I u
--- Comment #16 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-03
20:47 ---
Subject: Re: FAIL: gfortran.dg/gamma_5.f90
> This works on my i686-pc-linux-gnu system, and also fails when I use
> -ffloat-store. Seems like we have a roundoff problem with normal ieee
&g
--- Comment #13 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-03
19:37 ---
Subject: Re: FAIL: gfortran.dg/gamma_5.f90
> This implements the fallback functions, but naturally
> doesn't do anything on my linux system (which has all tgamma*
> and lgamma* function
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-02
23:45 ---
Subject: Re: FAIL: gfortran.dg/gamma_5.f90
> Can anybody test this? John?
I'm on it.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33698
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-01
23:29 ---
Subject: Re: New: FAIL:
gcc.dg/tree-ssa/pr33723.c scan-tree-dump-times t.f.f1 = 1 4
Tree dump attached.
Dave
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-01
23:29
--- Comment #13 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-01
19:45 ---
Subject: Re: INIT_PRIORITY is broken
> I don't think that's actually a bug -- except maybe its a
> misoptimization. The compiler's just inlining the calls to c1 from the
> _GLO
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-30
17:47 ---
Subject: Re: INIT_PRIORITY is broken
> Would you please try this patch?
I'll give it a try when I get home tonight.
Thanks,
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33579
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-29
00:35 ---
Subject: Re: INIT_PRIORITY is broken
> I believe you're correct that my changes broke the handling of
> prioritized constructors in the case where we use collect2. I didn't
> real
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-28
22:47 ---
Subject: Re: "error: array type has incomplete element type" in system header
> > In particular, the following DR was referenced as proof the above is
> > "not valid C":
--- Comment #52 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-27
00:29 ---
Subject: Re: wrong types in character array/scalar binop
Fixed on PA.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
--- Comment #49 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-25
23:17 ---
Subject: Re: wrong types in character array/scalar binop
> Yes, I found this after my last mail. I need to review this. The define
> is definitely not needed on linux.
The HP assembler allows d
--- Comment #48 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-25
20:57 ---
Subject: Re: wrong types in character array/scalar binop
> ./pa/pa.h:#define ASM_PN_FORMAT "%s___%lu"
> ./v850/v850.h:#define ASM_PN_FORMAT "%s___%lu"
>
> It looks li
--- Comment #44 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-25
18:03 ---
Subject: Re: wrong types in character array/scalar binop
> ASM_FORMAT_PRIVATE_NAME (tmp_name, prefix ? prefix : "T",
I'm still don't understand how we get underscores.
--- Comment #41 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-25
15:41 ---
Subject: Re: wrong types in character array/scalar binop
> While on x86_64-gnu-linux the dump has:
> int8 S.5;
> the variable on hppa-unknown-linux-gnu is:
> int4 S___5;
I wonder why t
--- Comment #38 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-25
02:39 ---
Subject: Re: wrong types in character array/scalar binop
Tree dump attached.
Dave
--- Comment #39 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-25
02:39 ---
Created an attachment (id
--- Comment #25 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-23
20:11 ---
Subject: Re: Bad reference to build directory in libstdc++.la
> What is the status of this bug? Will the proposed patches be implemented?
> (Note: http://gcc.gnu.org/bugzilla/page.cgi?id=field
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-22
01:30 ---
Subject: Re: gcc.c-torture/execute/longlong.c
execution at -O3
Things appear to go wrong in the greg pass:
(insn 73 133 70 4
/home/dave/gnu/gcc-4.3/gcc/gcc/testsuite/gcc.c-torture/execute
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-20
20:53 ---
Subject: Re: New:
gcc.c-torture/execute/longlong.c execution at -O3
Comparing 4.2 to 4.3, the significant difference in main appears to be:
4.2)
ldw 140(%r20),%r19 ;, tmp115
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-19
22:16 ---
Subject: Re: [4.2 Regression] ICE in delete_output_reload, at reload1.c:7926
> #1 0x00601eac in delete_output_reload (insn=0x2b78f71e4140, j=1,
> last_reload_reg=21)
> at gcc-4.2/gc
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-18
23:55 ---
Subject: Re: New: collect2 doesn't strip .sl version
On Sun, 14 Oct 2007, danglin at gcc dot gnu dot org wrote:
> After recently updating libgmp, I find that shared libraries that
> were lin
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-15
13:28 ---
Subject: Re: FAIL: 21_strings/headers/cwchar/macros.cc (test for excess
errors)
> --- Comment #5 from pcarlini at suse dot de 2007-10-15 09:35 ---
> Fixed.
I don't believe the chang
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-15
13:20 ---
Subject: Re: FAIL: 21_strings/headers/cwchar/macros.cc (test for excess
errors)
> --- Comment #1 from pcarlini at suse dot de 2007-10-15 09:12 ---
> What does it mean "These are define
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-14
21:44 ---
Subject: Re: FAIL: 17_intro/headers/c++1998/all.cc (test for excess errors)
> Are you willing to prepare and test on your target a patch along those lines?
> Specifically, I would suggest followi
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-11
01:26 ---
Subject: Re: FAIL: 17_intro/headers/all_pedantic_errors.cc (test for excess
errors)
> Looking at the testresults, it appears to have been introduced between
> 128587 and 128594 in September. Th
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-10
21:39 ---
Subject: Re: 1938 unexpected fails in libjava testsuite
> I don't think this code is used on HP/UX? If it were, it might be good to
> test
> there.
HP/UX doesn't appear to have, pth
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-10
17:04 ---
Subject: Re: 1938 unexpected fails in libjava testsuite
The attached patch fixes the problem.
Dave
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-10
17:04 ---
Created an
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-09
02:39 ---
Subject: Re: FAIL: gfortran.dg/gamma_5.f90
> --- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-10-09 02:18
> ---
> I was just looking at a DOC search and for HP-UX 11i
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-09
02:11 ---
Subject: Re: FAIL: gfortran.dg/gamma_5.f90
>/* Functions built into gcc itself. */
> +#ifndef tgamma
> +#define tgamma gamma
> +#endif
> +
> #include "mathbuiltins.def"
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-09
01:45 ---
Subject: Re: FAIL: gfortran.dg/gamma_5.f90
> --- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-10-09 01:32
> ---
> Just before the #include in trans-intrinsic.c we could d
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-08
23:01 ---
Subject: Re: FAIL: 17_intro/headers/all_pedantic_errors.cc (test for excess
errors)
> I only tested in Linux.
This was not introduced by your change. The problem is the use of
an C99 extension (l
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-08
20:10 ---
Subject: Re: FAIL: 17_intro/headers/all_pedantic_errors.cc (test for excess
errors)
> That's strange. I am looking at it. I ran the libstdc++ testsuite
> before and did not see this proble
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-08
19:32 ---
Subject: Re: FAIL: 17_intro/headers/all_pedantic_errors.cc (test for excess
errors)
> --- Comment #1 from pcarlini at suse dot de 2007-10-08 18:57 ---
> So the problem is new, right? Has it
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-05
19:02 ---
Subject: Re: bootstrap with ada failed
> --- Comment #8 from aoliva at gcc dot gnu dot org 2007-10-05 18:17
> ---
> Actually, Dave tells me in one of the "Ignored" entries th
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-05
03:52 ---
Subject: Re: bootstrap with ada failed
Ignore.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33634
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-05
03:48 ---
Subject: Re: bootstrap with ada failed
Ignore.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33634
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-03
21:23 ---
Subject: Re: bootstrap with ada failed
> --- Comment #2 from ebotcazou at gcc dot gnu dot org 2007-10-03 06:08
> ---
> Try to revert the big SRA patch.
128907 is ok. 128908 is brok
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-01
17:29 ---
Subject: Re: FAIL: gfortran.dg/nint_2.f90 -O0 execution test
> Does hpux10 have round()? And does it have ceil()? (I assume that the last
> answer is yes, because it's ANSI C, but hpux could
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-01
16:33 ---
Subject: Re: FAIL: gfortran.dg/nint_2.f90 -O0 execution test
> It should print "0 1 1". If it prints "1 1 1", then your system libm has a
> bug.
It prints "0 1 1&qu
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-01
15:23 ---
Subject: Re: FAIL: gfortran.dg/integer_exponentiation_4.f90 -O (internal
compiler error)
> You might also want to build GMP and MPFR with internal checking enabled
> (--enable-assert, I think). D
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2007-09-30
22:31 ---
Subject: Re: FAIL: gfortran.dg/gamma_1.f90
> The patch below should provide fallback functions (build in maintainer mode or
> use autoreconf in libgfortran), does it work?
I'll give this a
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2007-09-30
21:51 ---
Subject: Re: FAIL: abi_check
> --- Comment #3 from bkoz at gcc dot gnu dot org 2007-09-18 21:54 ---
> These all appear to be fails from missing C99 math functionality: tanl, etc.
>
&g
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2007-09-29
16:47 ---
Subject: Re: FAIL: gfortran.dg/gamma_1.f90
> Subject: Re: FAIL: gfortran.dg/gamma_1.f90
>
> > libgfortran in general assumes that a full C99 runtime is available.
It was the fortran f
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-09-29
16:15 ---
Subject: Re: FAIL: gfortran.dg/gamma_1.f90
> libgfortran in general assumes that a full C99 runtime is available.
lgamma and lgamma_r are available, so it should be possible to fudge
a f version. T
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2007-09-28
01:41 ---
Subject: Re: New: INIT_PRIORITY is broken
On Fri, Sep 28, 2007 at 01:35:04AM -, danglin at gcc dot gnu dot org wrote:
> FAIL: gcc.dg/initpri1.c execution test
I've attached the assembler ou
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-09-21
23:35 ---
Subject: Re: [4.3 regression] FAIL: gcc.c-torture/execute/990404-1.c execution
at -O3
Seems to have disappeared between 128564 and 128587.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33280
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2007-09-21
00:41 ---
Subject: Re: New: FAIL: gcc.c-torture/execute/990404-1.c execution at -O3
> This fail was first observed in 4.3.0 20070901 revision 128010. It was not
> present in revision 127946.
This was intr
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2007-09-20
02:24 ---
Subject: Re: fallback scalbn doesn't handle denormals correctly
> For some reason, I had completely forgotten about ldexp(). But as it is C89,
> it
> should be available, and as all GCC sup
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2007-09-18
22:24 ---
Subject: Re: FAIL: abi_check
> So, maybe something with libmath config, config for C99 functions?
Think so, I see asinf isn't found, yet it's there. I'm going
to remove "-j
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2007-09-11
22:58 ---
Subject: Re: FAIL: gcc.dg/tree-ssa/loadpre11.c scan-tree-dump-times
Eliminated: 1 1
This was instroduced between 128314 (ok) and 128343 (fail).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33402
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2007-09-11
22:45 ---
Subject: Re: New: FAIL: gcc.dg/tree-ssa/loadpre11.c scan-tree-dump-times
Eliminated: 1 1
Tree dump attached.
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-09-11
22:45
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2007-09-10
21:30 ---
Subject: Re: gcc.c:6236: error: passing argument 1 of 'xputenv' discards
qualifiers from pointer target type
> What is the status here?
> I tested the patch below on hppa64-hp-hpux11.11, i
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2007-09-09
20:26 ---
Subject: Re: New: gcc: libgomp.spec: No such file or directory
> gcc: libgomp.spec: No such file or directory
It appears libgomp didn't get installed although it builds and
there are no fail
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2007-09-09
19:27 ---
Subject: Re: [4.3 Regression] g++.old-deja/g++.eh/ia64-1.C ICEs at -O1 on
spu-elf
> Please try after r128284. See also story about this test-case for cris-elf at
> <http://gcc.gnu.org/ml/gcc-pat
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2007-09-07
22:05 ---
Subject: Re: Segmentation fault bootstrapping on HP-UX 11.11
> As mentioned before, I'm able to bootstrap with HP's compiler, so if this
> information doesn't help you I'll jus
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2007-09-07
01:50 ---
Subject: Re: gcc.c:6236: error: passing argument 1 of 'xputenv' discards
qualifiers from pointer target type
> > > Another option would be to constify xputenv and use CONST_CAST on
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2007-09-05
15:08 ---
Subject: Re: gcc.c:6236: error: passing argument 1 of 'xputenv' discards
qualifiers from pointer target type
> --- Comment #2 from ghazi at gcc dot gnu dot org 2007-09-05 06:17 ---
&
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2007-08-31
01:53 ---
Subject: Re: [4.3 Regression] /usr/ccs/bin/ld: Duplicate symbol "global
destructors keyed to _ZNSt3tr112_GLOBAL__N_16i
> Was this fixed?
No, there are still duplicate symbol failures as rep
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2007-08-30
01:43 ---
Subject: Re: [4.3 Regression] libgcc2.c:1890: internal compiler error: in
local_cprop_pass, at gcse.c:3236
> Any news on this bug?
I have been building with Steven's change for the past couple
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2007-08-25
22:24 ---
Subject: Re: New: FAIL: gcc.dg/builtins-20.c (test for excess errors)
test3l and test3f fail. Attached .s file.
Dave
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-08-25
22:24
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-08-22
23:39 ---
Subject: Re: FAIL: gcc.dg/pr32912-[12].c (test for excess errors)
> The warning comes from:
> typedef int __m128i __attribute__ ((__vector_size__ (16)));
> __m128i a, b, c, d, e, f;
Right. Wo
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2007-08-19
01:11 ---
Subject: Re: ICE in emit_move_insn and expand_call with -fdefault-integer-8
> Jeff, Dave, as you can see in the above comments, I proposed this patch based
> on a previous similar patch to powerpc,
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2007-08-11
13:05 ---
Subject: Re: FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution
> write_float uses isfinite (n) and isnan (n) to determine if "Infinite" or
> "NaN"
> is e
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2007-08-10
04:42 ---
Subject: Re: FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution
> write_float uses isfinite (n) and isnan (n) to determine if "Infinite" or
> "NaN"
> is e
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2007-08-10
00:41 ---
Subject: Re: FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution
> Still can't reproduce this on hppa2.0w-hp-hpux11.31. I'm starting to think
> that
> printf might be brok
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2007-08-09
23:30 ---
Subject: Re: FAIL: gfortran.dg/integer_exponentiation_2.f90 at -O1 and above
> Any results? I cannot reproduce this on hppa2.0w-hp-hpux11.31 (neither the
> original bug nor your testcase that
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2007-08-09
18:41 ---
Subject: Re: New: Unsatisfied symbol "lroundl" in file libgfortran.sl
> The symbol is from misc_specifics.o.
It looks like lroundl there is an implementation using roundl. There
is an impl
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2007-08-09
17:57 ---
Subject: Re: New: Unsatisfied symbol "lroundl" in file libgfortran.sl
The symbol is from misc_specifics.o.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33038
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2007-08-08
18:11 ---
Subject: Re: Segmentation fault bootstrapping on HP-UX 11.11
> --- Comment #2 from pda at freeshell dot org 2007-08-08 17:10 ---
> I tried configuring for HP ld as you suggested, but that
--- Comment #21 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-31
15:30 ---
Subject: Re: FAIL: 23_containers/bitset/cons/16020.cc execution test
> --- Comment #20 from hjl at lucon dot org 2007-07-30 20:41 ---
> Is this related to PR32921? Can you try the pa
--- Comment #18 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-25
23:34 ---
Subject: Re: FAIL: 23_containers/bitset/cons/16020.cc execution test
> > So the aliasing set of bitset<5> is 88 and the store for
> > b.D.57473.D.57333._M_w
> > is done in alias
--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-25
22:07 ---
Subject: Re: FAIL: 23_containers/bitset/cons/16020.cc execution test
> So the aliasing set of bitset<5> is 88 and the store for
> b.D.57473.D.57333._M_w
> is done in aliasing set 10.
--- Comment #13 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-25
21:53 ---
Subject: Re: FAIL: 23_containers/bitset/cons/16020.cc execution test
> Can you attach the dump of -fdump-rtl-expand-details ?
Attached.
Dave
--- Comment #14 from dave at hiauly1 dot hia dot
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-25
21:31 ---
Subject: Re: FAIL: 23_containers/bitset/cons/16020.cc execution test
The appears to be a problem with the sched passes. If I compile with
-fno-schedule-insns and -fno-schedule-insns2, the test doesn&#
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-24
19:30 ---
Subject: Re: FAIL: 23_containers/bitset/cons/16020.cc execution test
> 0x00010318 and 0x0001031c are totally bogus. Changing this
> to a middle-end bug.
Here is preprocessed source.
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-24
16:25 ---
Subject: Re: Exception handling not thread-safe on AIX5.x and HP-UX
> It doesn't seem to fail using g++ 4.2. Fix or fluke?
There were some changes to config/pa/hpux-unwind.h in 2006 that
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-24
15:40 ---
Subject: Re: FAIL: 23_containers/bitset/cons/16020.cc execution test
> I think there is no reason to categorize as libstdc++: almost nothing changed
> in the library in that timespan (and defi
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-21
23:54 ---
Subject: Re: FAIL: g++.dg/opt/pr24665.C
> > Looking at gcc-testresults for i686-pc-linux-gnu, revision 126573 works
> > while
> > 126587 fails.
>
> 126595 introduced a bootst
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-21
23:28 ---
Subject: Re: FAIL: g++.dg/opt/pr24665.C
> Looking at gcc-testresults for i686-pc-linux-gnu, revision 126573 works while
> 126587 fails.
126595 introduced a bootstrap failure on hppa64-hp-hpux11.
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-19
23:49 ---
Subject: Re: New: Bootstrap comparison error -- VUSES info changed
For reference, I attached the difference in omega.o between stage
2 and 3.
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-17
01:06 ---
Subject: Re: jc1: out of memory allocating 4072 bytes after a total of
805021000 bytes
> Hi guys, can you check whether the 32723 fix that was just checked in
> fixes this?
Still same problem wi
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-16
16:16 ---
Subject: Re: jc1: out of memory allocating 4072 bytes after a total of
805021000 bytes
> Hi guys, can you check whether the 32723 fix that was just checked in
> fixes this?
Doesn't seem to be
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-15
00:27 ---
Subject: Re: [4.3 Regression] __builtin_eh_return broken by dataflow merge
I'm testing making the MEM volatile.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32769
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-14
20:00 ---
Subject: Re: New: __builtin_eh_return broken by dataflow merge
Attached is preprocessed source for unwind-dw2.c on hppa-unknown-linux-gnu.
Dave
--- Comment #2 from dave at hiauly1 dot hia dot nrc
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-12
19:21 ---
Subject: Re: jc1: out of memory allocating 4072 bytes after a total of
805021000 bytes
> I have a few upcoming patches that should seriously reduce memory usage of
> points-to.
Sounds good.
--- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-10
00:04 ---
Subject: Re: [4.3 Regression] checking for suffix of object files...
configure: error: cannot compute suffix of f obje
> The problem that i have is it the argument pointer does not have a fixed
>
--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-09
22:01 ---
Subject: Re: [4.3 Regression] checking for suffix of object files...
configure: error: cannot compute suffix of f obje
> --- Comment #16 from bonzini at gnu dot org 2007-07-09 21
--- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-08
05:12 ---
Subject: Re: [4.3 Regression] checking for suffix of object files...
configure: error: cannot compute suffix of f objeRO
> There is nothing magical about the entry block defs except that they are
&g
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-08
02:29 ---
Subject: Re: [4.3 Regression] checking for suffix of object files...
configure: error: cannot compute suffix of f objeRO
> Why can't you put something in the prologue that sets the reg an
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-07
23:30 ---
Subject: Re: [4.3 Regression] checking for suffix of object files...
configure: error: cannot compute suffix of f obje
> suggest a way that we could accommodate this?
Prior to reload being completed
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-07
22:02 ---
Subject: Re: [4.3 Regression] checking for suffix of object files...
configure: error: cannot compute suffix of f objeRO
The REG_DEAD problem is a red herring. The notes are recomputed
after the sched1
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-07
15:55 ---
Subject: Re: New: FAIL: abi_check
> I've seen this with 4.2.1 and 4.3.0.
Attached is the output log (probably somewhat out of order).
Dave
--- Comment #2 from dave at hiauly1 dot hia dot
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-02
20:09 ---
Subject: Re: [4.3 Regression] ICE: in vn_binary_op_insert, at
tree-ssa-sccvn.c:852
> I cannot reproduce with a cross to hppa-linux.
> Is this still happening with the latest patches as of this m
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-02
20:07 ---
Subject: Re: [4.3 Regression] checking for suffix of object files...
configure: error: cannot compute suffix of f objeRO
> Can you send me, the dump produced by -fdump-rtl-expand with the trunk
--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-26
17:46 ---
Subject: Re: [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
> The offending gcc.dg/cleanup-[8|9|10|11].c tests now pass as do almost all C++
> and libstdc++ tests.
Unfortunately, we
--- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-23
18:40 ---
Subject: Re: [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
> Thanks for the patch. I just started a mipsel-linux bootstrap.
Same here for hppa-linux.
Dave
--
http://gcc.gnu.
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-23
01:57 ---
Subject: Re: [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
The same failures occur on hppa-unknown-linux-gnu.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32437
--- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-21
02:56 ---
Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
> Created an attachment (id=13738)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13738&action=view)
> --> (ht
--- Comment #16 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-19
20:39 ---
Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
> "make" may change stack limit.
You are right. Make bumps the soft limit to unlimited when the hard
limit is unl
--- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-19
19:56 ---
Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
> > We need to know that the return pointer (r2) is not used and that
> > the function is a leaf function (i.e., that
--- Comment #13 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-15
20:05 ---
Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
> > We need to know that the return pointer (r2) is not used and that
> > the function is a leaf function (i.e., that
401 - 500 of 1012 matches
Mail list logo
