--- Comment #3 from dave dot korn dot cygwin at gmail dot com 2009-05-30
15:19 ---
About to test this:
$ svn diff -x -p fortran/trans-decl.c
Index: fortran/trans-decl.c
===
--- fortran/trans-decl.c(revision
--- Comment #4 from dave dot korn dot cygwin at gmail dot com 2009-05-30
15:34 ---
(In reply to comment #3)
> About to test this:
That was wrong. This is what I should have said:
$ svn diff fortran/trans-decl.c
Index: fortran/trans-dec
--- Comment #5 from dave dot korn dot cygwin at gmail dot com 2009-05-30
15:38 ---
The patch in comment 4 works.
dkad...@ubik /tmp/fortran
$ ./hello-fixed.exe
Hello World!
dkad...@ubik /tmp/fortran
$ gdb ./hello-fixed.exe
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C
--- Comment #6 from dave dot korn dot cygwin at gmail dot com 2009-05-30
16:12 ---
Groan.
PASS: gfortran.dg/Wall.f90 (test for excess errors)
spawn [open ...]
Internal Error: insert(): Duplicate key found!
FAIL: gfortran.dg/Wall.f90 execution test
In other words, exactly what Andrew
--- Comment #7 from dave dot korn dot cygwin at gmail dot com 2009-05-30
17:09 ---
http://gcc.gnu.org/ml/fortran/2009-05/msg00452.html
We have two functions that both match MAIN_NAME_P, because they share the same
DECL_NAME. This happens when there is a "PROGRAM main" di
--- Comment #11 from dave dot korn dot cygwin at gmail dot com 2009-06-01
08:05 ---
I checked the fix and it works. Verified.
--
dave dot korn dot cygwin at gmail dot com changed:
What|Removed |Added
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-06-16
11:26 ---
Could you re-run that with --save-temps, and attach the .i, .s, .o and .exe
files to the PR please?
--
dave dot korn dot cygwin at gmail dot com changed:
What|Removed
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-06-16
11:40 ---
Already fixed at r.148523, according to:
http://gcc.gnu.org/ml/gcc/2009-06/msg00339.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40456
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2009-06-17
15:38 ---
Subject: Re: linux-eabi.h:79:36: error: identifier "not" is a special operator
name in C++
> > Could you specify which version of the source tree this was ?
>
> This is trunk, v
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2009-06-21
19:13 ---
Subject: Re: hppa: ICE: in expand_expr_addr_expr_1,
at expr.c:6830
Untested patch attached for comment.
Dave
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2009-06-21
19:13
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2009-06-25
00:32 ---
Subject: Re: FAIL: gcc.dg/builtins-65.c (test for
excess errors)
> Can you put HAVE_C99_RUNTIME around problematic conversions (just copy the
> approach from builtins-18.c) ?
Attache
--- Comment #7 from dave dot korn dot cygwin at gmail dot com 2009-06-25
15:37 ---
Hmm, I'm getting somewhere with this.
By compiling the g++ testsuite "ptrflags.C" case with --save-temps, manually
hacking all the superfluous typeinfo stuff out, and re-assembling an
--- Comment #20 from dave dot korn dot cygwin at gmail dot com 2009-06-29
15:12 ---
I think the best solution to this problem is to enable libstdc++ as a DLL, and
export _S_empty_rep from it. Then every C++ DLL and EXE will link against
libstdc++ and they'll all import the exact
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-01
14:02 ---
Subject: Re: New: [4.5 Regression] Revision 149032
breaks bootstrap
> This occurs because the configure test failed:
Attached preprocessed source for test.
Dave
--- Comment #3 from d
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-01
14:06 ---
Subject: Re: [4.5 Regression] Revision 149032 breaks bootstrap
> Should be fixed already?
I'll retest. It was still presetn in revision 149079.
Dave
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #64 from dave dot korn dot cygwin at gmail dot com 2009-07-04
12:47 ---
(In reply to comment #63)
> GCC still generates a segfaulting executable when used with the testcase in
> the
> report, most likely because my assembler doesn't support the 3-argument .co
--- Comment #66 from dave dot korn dot cygwin at gmail dot com 2009-07-04
13:21 ---
(In reply to comment #65)
> Indeed, i should have expected this, and after rereading the comments here you
> even mentioned this problem already. Sorry for the noise.
>
That's OK. G
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-04
15:46 ---
Subject: Re: [4.5 Regression] Ada build fails
> Could you check whether the following patch fixes it?
It fixes the build error.
Thanks,
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40608
--- Comment #13 from dave dot korn dot cygwin at gmail dot com 2009-07-04
15:48 ---
This should all be resolved by the fixes applied in the past few days to
binutils CVS HEAD.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40455
--- Comment #5 from dave dot korn dot cygwin at gmail dot com 2009-07-04
15:56 ---
(In reply to comment #4)
> (In reply to comment #2)
> > Might be safer to rename to GNAT_FOPEN or something like that? FOPEN is
> > likely
> > to be taken on more than one platform
--- Comment #7 from dave dot korn dot cygwin at gmail dot com 2009-07-04
16:15 ---
You might like to test this again. It was very likely fixed by the these
patches
http://gcc.gnu.org/viewcvs?view=rev&revision=146425
http://gcc.gnu.org/viewcvs?view=rev&revision=146515
I
--- Comment #15 from dave dot korn dot cygwin at gmail dot com 2009-07-04
23:27 ---
(In reply to comment #14)
> I am on cygwin-1.5. will these fixes get pushed to setup? or am I stuck? or
> is
> there a work around?
Hi Jerry,
I can't answer that question. There is
--- Comment #17 from dave dot korn dot cygwin at gmail dot com 2009-07-04
23:55 ---
It is beta, yeah. But it's a damn good beta :) Can't promise you won't
stumble across a new bug or two, but it's reliable enough for fairly heavy-duty
everyday usage.
--
--- Comment #20 from dave dot korn dot cygwin at gmail dot com 2009-07-05
23:47 ---
(In reply to comment #19)
> (In reply to comment #18)
> > As Dave suggests in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40455#c13,
> > this
> > is fixed,
> >
>
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-07
13:35 ---
Subject: Re: [4.4.1 Regression] Ada rts build failure
> Did this work with 4.4.0?
Yes.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40666
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libffi
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dave dot korn dot cygwin at gmail dot com
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40807
--- Comment #13 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-19
17:24 ---
Subject: Re: libcpp breaks bootstrap
> (In reply to comment #8)
> > Also seen on hppa64-hp-hpux11.11.
> >
>
> Does the patch also fix the hpux failure?
Yes.
Dave
--
http:/
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-07-19
17:50 ---
(In reply to comment #0)
> I notice that ffi_call_SYSV has to handle all the return types, but not
> ffi_closure_SYSV nor ffi_closure_raw_SYSV. Does anyone know why that is?
To answer
--- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-20
17:17 ---
Subject: Re: libcpp breaks bootstrap
> Can you commit your fix
>
> http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01109.html
>
> or revert your change that is causing the problem?
config
--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-20
17:51 ---
Subject: Re: libcpp breaks bootstrap
> I posted the fix yesterday. I'm write-after-approval, and I thought I needed
> to wait for someone to OK the patch.
Probably could have been applied
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-26
19:09 ---
Subject: Re: [4.5 Regression] Build failure in libgfortran
> Patch. As I cannot test all the combinations, I would be happy if someone
> could
> test it or read the patch. (I will reread it an
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-26
20:11 ---
Subject: Re: [4.5 Regression] Build failure in
libgfortran
On Sun, 26 Jul 2009, John David Anglin wrote:
> > Patch. As I cannot test all the combinations, I would be happy if someone
>
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-26
21:37 ---
Subject: Re: [4.5 Regression] Build failure in libgfortran
> (In reply to comment #7)
> > (In reply to comment #6)
> > > Can you try whether the following works (place somewhere i
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-29
13:08 ---
Subject: Re: [4.5 Regression] FAIL:
g++.dg/torture/pr34099.C -O1 (internal compiler error) at -O1 and
above
> Can you please try this with -fno-tree-sra? If you have a revis
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-29
16:02 ---
Subject: Re: [4.5 Regression] FAIL:
g++.dg/torture/pr34099.C -O1 (internal compiler error) at -O1 and
above
Attached tree dump.
Dave
--- Comment #6 from dave at hiauly1 dot hia
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-29
18:27 ---
Subject: Re: FAIL: abi_check
> If I'm not wrong, please double check, nothing happened in the library proper
> between those versions, thus it looks like by chance a function is not inlined
&g
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-29
19:31 ---
Subject: Re: FAIL: abi_check
> By "a function", I meant of course _ZNSt5mutexC1Evstd::mutex::mutex(). In the
> meanwhile I checked that indeed that symbol normally is *not* exported at al
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-29
20:13 ---
Subject: Re: FAIL: abi_check
> Try something like this:
Works for me.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40908
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-30
20:47 ---
Subject: Re: FAIL: 26_numerics/headers/cmath/c99_classification_macros_c.cc
> In general, this one must be just xfailed, can pass by chance with PCHs. Can
> you please tweak the dg lines at the beg
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-04
14:27 ---
Subject: Re: ACATS ce3810b segfaults at runtime
> --- Comment #8 from christian dot joensson at gmail dot com 2005-11-04
> 11:24 ---
> Just a ping here... are there any progress on thi
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-13
03:32 ---
Subject: Re: libobjc testsuite failures
> Is this a regression? If this is a regression, was this caused by:
Yes, things were ok on 2005-11-07.
> 2005-11-09 Alexandre Oliva <[EMAIL
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-13
04:29 ---
Subject: Re: libobjc testsuite failures
> --- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-13 04:07
> ---
> Alexandre could you look into this one and PR 24827?
And PR 248
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-14
19:15 ---
Subject: Re: [4.1 regression] gthr-dce.h:77: error: expected expression before
'{' token
> So is pthread_key_delete not declared in HP-UX's DCE headers? Is it actually
> the correct
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-14
19:40 ---
Subject: Re: FAIL: gcc.dg/attr-weakref-1.c
> Does this target actually support weak declarations? It appears to me that it
> only does when the assembler supports .weak, but even then, the linke
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-14
19:51 ---
Subject: Re: [4.1 Regression] libobjc testsuite failures
> worked with the #pragma weaks. Or would it? Anyhow, please confirm how you
> configured the compiler. I'm particularly interes
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-19
02:36 ---
Subject: Re: FAIL: gcc.dg/attr-weakref-1.c
> Does this target actually support weak declarations? It appears to me that it
> only does when the assembler supports .weak, but even then, the linke
--- Comment #13 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-19
02:44 ---
Subject: Re: [4.1 Regression] internal compiler error: verify_flow_info failed
> But the edge is the same now :)
> as:
> Cross jumping from bb 1 to bb 2; 2 common insns
> Deleted labe
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-19
02:51 ---
Subject: Re: [4.1 Regression] libobjc testsuite failures
> --- Comment #8 from mmitchel at gcc dot gnu dot org 2005-11-19 02:13
> ---
> Objective-C is not release-critical.
This is on
--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-19
03:41 ---
Subject: Re: [4.1 Regression] internal compiler error: verify_flow_info failed
> >if (n_branch != 1 && any_condjump_p (BB_END (bb))
> > - && JUMP_LABEL (BB_EN
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-21
03:09 ---
Subject: Re: [3.4 only] FAIL: gcc.dg/sibcall-1.c and FAIL: gcc.dg/sibcall-2.c
> --- Comment #2 from gdr at gcc dot gnu dot org 2005-11-21 02:29 ---
> Is there any hppa maintainer lookin a
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-21
04:55 ---
Subject: Re: [4.1 regression] gthr-dce.h:77: error: expected expression before
'{' token
> Anyhow, it seems to me like we could simply remove or comment out the
> pthread_key_delete
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-21
14:36 ---
Subject: Re: [4.1/4.2 Regression] make[7]: rc: Command not found
> Apparently the libada Makefile is not passing some variables to ada/Makefile
> properly, so this patch might address the problem y
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-23
03:07 ---
Subject: Re: [4.1/4.2 Regression] make[7]: rc: Command not found
> > I'm not sure either. I did notice that the build that had a problem
> > was using an old version of make (3.79.1). I
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-24
22:33 ---
Subject: Re: [4.1 regression] gthr-dce.h:77: error: expected expression before
'{' token
> HP-UX 10 is not a primary platform, but this seems an easy fix; let's fix it
> if
> we c
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-24
23:22 ---
Subject: Re: [4.2 Regression] libgcov.c:652: ICE: in default_secondary_reload,
at targhooks.c:529
> I see that you are having a bad couple of weeks.
Yah. Definitely, slows progress on PA specific st
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-24
23:55 ---
Subject: Re: [4.2 Regression] libgcov.c:652: ICE: in default_secondary_reload,
at targhooks.c:529
> I see that you are having a bad couple of weeks.
Thing were somewhat better before r107468.
D
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-25
21:36 ---
Subject: Re: [4.1/4.2 regression] gthr-dce.h:77: error: expected expression
before '{' token
> Hmm, GTHREAD_USE_WEAK should be zero so that this should not matter at all.
> Did someone f
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-25
21:49 ---
Subject: Re: [4.1/4.2 Regression] libobjc testsuite failures
> Could you attach the preprocessed source (with -g3) for thrd-objc.c from
> libobjc?
Here it is.
Dave
--- Comment #12 from d
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-26
16:57 ---
Subject: Re: [3.4 only] [hppa] 'bus error' at runtime while passing a special
struct to a C++ member function
> Are you working on this? It lools like the bug has been there for a while.
&
--- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-26
20:25 ---
Subject: Re: [4.1/4.2 Regression] libobjc testsuite failures
> > Here it is.
>
> Oops, the file sent had HAVE_GAS_WEAKDEF undef'd, so SUPPORTS_WEAK
> is 0.
With HAVE_GAS_WEAKDE
--- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-26
21:19 ---
Subject: Re: [4.1/4.2 Regression] libobjc testsuite failures
> > > Here it is.
> >
> > Oops, the file sent had HAVE_GAS_WEAKDEF undef'd, so SUPPORTS_WEAK
> > is 0.
>
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-27
17:28 ---
Subject: Re: [4.2 Regression] libgcov.c:652: ICE: in default_secondary_reload,
at targhooks.c:529
> The preprocessed source is where?
Attached.
Dave
--- Comment #6 from dave at hiauly1 dot hia
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-27
17:51 ---
Subject: Re: [4.2 Regression] libgcov.c:652: ICE: in default_secondary_reload,
at targhooks.c:529
This is what I see in gdb:
Assembling functions:
__gcov_merge_single
Breakpoint 3
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-29
22:00 ---
Subject: Re: Failure to build, :1:2: error: missing '(' after
predicate
> On Sun, Nov 27, 2005 at 06:57:05PM -, danglin at gcc dot gnu dot org
> wrote:
> > The "-Aa&qu
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-30
03:32 ---
Subject: Re: FAIL: gfortran.dg/module_equivalence_1.f90
> This is obvious an issue, this is what I get on x86_64-linux-gnu:
> .comm test_equiv.eq.1_,16,16
> .comm test_eq
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-30
03:38 ---
Subject: Re: FAIL: gcc.dg/weak/weak-14.c
> Isn't this just bug 24478?
Yes. However, 24478 didn't have any host/target/build and I didn't
see it.
Dave
--
http://gcc.gnu.org/bugzil
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-30
03:51 ---
Subject: Re: [4.2 Regression] FAIL: gcc.c-torture/execute/conversion.c
compilation
> As explained in bug 24998, I can't test on PA at present but the fix is
> probably similar to that for
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-03
00:14 ---
Subject: Re: FAIL: g++.dg/warn/huge-val1.C (test for excess errors)
> Hmm, limits.h should have been fixincluded but for some reason it was not.
Seems to be in gcc/include. It's possible
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-03
01:10 ---
Subject: Re: FAIL: g++.dg/warn/huge-val1.C (test for excess errors)
> This test is for (or whatever headers define HUGE_VAL
> etc.), not . should indeed be fixincluded,
> but there may be de
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-03
03:19 ---
Subject: Re: [4.1/4.2 regression] gthr-dce.h:77: error: expected expression
before '{' token
> Created an attachment (id=10362)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=1
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-04
20:34 ---
Subject: Re: FAIL: gcc.dg/tree-ssa/20031106-6.c scan-tree-dump-times
temp_struct 0
> gcc-3.3!?? it's getting scary.
Yah, too many gcc versions to maintain... Don't believe the
director
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-04
20:46 ---
Subject: Re: FAIL: gcc.dg/tree-ssa/20031106-6.c scan-tree-dump-times
temp_struct 0
> /home/dave/gnu/gcc-4.0 (!)
>
> can it be you run the mainline testsuite with a 4.0 compiler?
Nope:
[EMAIL
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-04
21:29 ---
Subject: Re: FAIL: gcc.dg/tree-ssa/20031106-6.c scan-tree-dump-times
temp_struct 0
> Can you attach the result of -fdump-tree-sra-all for your system?
Here it is.
Dave
--- Comment #10 from dave
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-06
13:27 ---
Subject: Re: [4.0 regression/hpux] gcc generates incorrect stabs debug output
> By using subspa, the L$etext label is placed back at the beginning of the
> original code section, so it do
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-09
18:31 ---
Subject: Re: [4.1 Regression] hppa64 EH failures
> --- Comment #2 from joseph at codesourcery dot com 2005-12-09 16:58
> ---
> Subject: Re: [4.1 Regression] hppa64 EH failures
>
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-12
15:55 ---
Subject: Re: make[2]: *** [ada/einfo.h] Error 1
> Is this issue still present ?
I last retested a build with Ada enabled about a week ago and the
problem was still present.
> If the issue is wi
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-12
22:50 ---
Subject: Re: make[2]: *** [ada/einfo.h] Error 1
> > > If the issue is with the bootstrap compiler, there's not much we can do.
> >
> > Bootstrap compiler is GCC. This does
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-13
18:48 ---
Subject: Re: [4.2 Regression] libgcc2.c:2033: ICE: tree check: expected tree
that contains 'decl common' structure, have 'name_memory_tag'
Attached .i.
Dave
--- Comment #3 from
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-13
21:25 ---
Subject: Re: [4.2 Regression] libgcc2.c:2033: ICE: tree check: expected tree
that contains 'decl common' structRO
> Please give this a try, tell me if it works
The build gets past the poi
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-14
02:47 ---
Subject: Re: [4.2 Regression] libgcc2.c:2033: ICE: tree check: expected tree
that contains 'decl common' struct
> This is an unrelated bug which was introduced yesterday/today. Can you file
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-18
17:38 ---
Subject: Re: [4.1/4.2 regression] FAIL: gcc.c-torture/execute/20040709-1.c
execution, -Os
> First, it looks from the command lines in the report that the problematic
> compiler is GCC 3.3. B
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-18
18:01 ---
Subject: Re: [4.1/4.2 regression] FAIL: gcc.c-torture/execute/20040709-1.c
execution, -Os
> Unable to reproduce with GCC 4.1 without further feedback. Apparently already
> fixed or made latent
--- Comment #16 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-19
15:44 ---
Subject: Re: [4.1/4.2 regression] FAIL: gcc.c-torture/execute/20040709-1.c
execution, -Os
> Could this be a dup of Bug 23585?
It looks like it could be. Looking at the rtl generated for testB usin
--- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-27
01:41 ---
Subject: Re: [4.1 Regression] (short) ((int)(unsigned short) + (int)) is done
in the wrong type
> --- Comment #14 from danglin at gcc dot gnu dot org 2005-12-27 01:07
> ---
> Running
--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-27
15:00 ---
Subject: Re: [4.1 Regression] (short) ((int)(unsigned short) + (int)) is done
in the wrong type
> Re. comments #14 and #15 -- Dave you really should also say what compiler you
> used, or people wil
--- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-27
17:06 ---
Subject: Re: [4.1 Regression] (short) ((int)(unsigned short) + (int)) is done
in the wrong type
> I am having tough time building the compiler for hppa2.0w-hp-hpux11.11.
> These days gcc won't
--- Comment #20 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-27
19:27 ---
Subject: Re: [4.1 Regression] (short) ((int)(unsigned short) + (int)) is done
in the wrong type
> > I am having tough time building the compiler for hppa2.0w-hp-hpux11.11.
> > These days gc
--- Comment #21 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-27
22:35 ---
Subject: Re: [4.1 Regression] (short) ((int)(unsigned short) + (int)) is done
in the wrong type
> However, I'm getting different tree code with the x86 cross.
I can't reproduce this prob
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-28
00:13 ---
Subject: Re: FAIL: gfortran.dg/cray_pointers_2.f90 at -O2 and above
> Can you attach the dump from -fdump-tree-vars? I suspect that cray_pointers
> are a bit weird on targets like HPPA since we
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-28
00:16 ---
Subject: Re: FAIL: gfortran.dg/cray_pointers_2.f90 at -O2 and above
Here's the dump.
Dave
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-28
00:16 ---
Creat
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-28
00:25 ---
Subject: Re: FAIL: gfortran.dg/cray_pointers_2.f90 at -O2 and above
> Can you attach the dump from -fdump-tree-vars? I suspect that cray_pointers
> are a bit weird on targets like HPPA since we
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2005-12-28
04:18 ---
Subject: Re: FAIL: gfortran.dg/cray_pointers_2.f90 at -O2 and above
> (In reply to comment #6)
> > It I'm reading this correctly, we appear to have the sum of two
> > real4* pointers
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-01
17:11 ---
Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer:
0x00062a00 ***
I've looked at the failure of a85013b.adb.
The problem seems to be that "new" is applying a k
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-01
17:39 ---
Subject: Re: undefined reference to `_gfortran_st_set_nml_var_dim'
> Hmm, there really has not been any change in libgfortran which could have
> caused this.
Agreed. Looking at transfer.o,
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-01
17:44 ---
Subject: Re: undefined reference to `_gfortran_st_set_nml_var_dim'
> Agreed. Looking at transfer.o, we seem to somehow have lost the
> "_gfortran_" prefix:
>
> 3a48 T
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-01
18:54 ---
Subject: Re: undefined reference to `_gfortran_st_set_nml_var_dim'
> > Hmm, there really has not been any change in libgfortran which could have
> > caused this.
>
> Agreed. Lo
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-03
15:03 ---
Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer:
0x00062a00 ***
> The alignment clause takes *bytes*, not *bits*, so you need to use instead:
>
&g
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-03
15:49 ---
Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer:
0x00062a00 ***
> Hmm, so that means that 16 is bigger than Standard'Maximum_Alignment...
Unfortunately, yes. The fun
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-04
02:41 ---
Subject: Re: ACATS cxg1005 fails at runtime on hppa-linux
> May be this one?
Nope.
There seems to be an optimisation issue. I rebuilt the runtime
at -O0. The test passes when compiled at -O0 and
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-06
23:04 ---
Subject: Re: Unable to build gnatmake
> --- Comment #3 from laurent at guerby dot net 2006-01-06 22:18 ---
> Is 4.1 or 4.2 building there now?
I see HP has a new libcl patch:
PHSS
401 - 500 of 1351 matches
Mail list logo
