--- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-04-07 10:08
---
also try to compile by gcc comman ... the famous hello word program..
$ gcc -c -Wall -D_GNU_SOURCE abhi.c -o abhi.o
$ gcc -c abhi.o abhi.c
gcc: abhi.o: linker input file unused because linking not done
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-04-07 13:29
---
There should not be any difference as i directed cc to gcc
Your bug. The Makefile expects Sun CC since it uses Sun CC options. So you
need to use Sun CC.
--
ebotcazou at gcc dot gnu dot org changed
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2009-04-07 13:38
---
Thanks a lot , Is there any workaround for this problem,Becouse SunCC compiler
is paid.
You need to read the documentation of the software you're trying to build and
see whether GCC is supported; if so, follow
--- Comment #21 from ebotcazou at gcc dot gnu dot org 2009-04-07 05:13
---
It looks like this would affect: hpux-ia64, lynxos-ppc, lynxos-x86,
vxworks-arm, vxworks-m68k, vxworks-mips, vxworks-sparcv9 and vxworks-x86
with the default ./configure _AND_ every other Target _IF_
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2009-04-05 17:55
---
Using the BSD Ports I was able to build Ada, up until revision 145338 .
While I do not use Ada it would be unfortunate to lose this Language.
This language is not supported in the FSF tree on OpenBSD, i.e
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2009-04-05 18:26
---
As for the backend issue, may be it will show up on i386-unknown-freebsd too
(a
primary platform), and there's a gcc/ada/system-freebsd-x86.ads in the FSF
tree.
Most probably not, you need FE SJLJ
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2009-04-05 21:43
---
Is there a supported platform currently using FE SJLJ?
Windows.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2009-04-04 17:44
---
The Ada compiler hasn't been ported to OpenBSD yet.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-04-04 19:48
---
Too late. :-)
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2009-04-01 20:46
---
Subject: Bug 39588
Author: ebotcazou
Date: Wed Apr 1 20:46:30 2009
New Revision: 145430
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145430
Log:
PR rtl-optimization/39588
* combine.c
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-04-01 20:47
---
Subject: Bug 39588
Author: ebotcazou
Date: Wed Apr 1 20:47:37 2009
New Revision: 145431
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145431
Log:
PR rtl-optimization/39588
* combine.c
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2009-04-01 20:48
---
Subject: Bug 39588
Author: ebotcazou
Date: Wed Apr 1 20:48:33 2009
New Revision: 145432
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145432
Log:
PR rtl-optimization/39588
* combine.c
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2009-04-01 20:51
---
Thanks for the reduced testcase.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot
|dot org
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2009-03-23 11:25
---
Did behavior change if you remove the aligned (2) attribute from d?
No, it didn't change without the attribute, it was and still is (10, 12).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39514
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2009-03-23 11:47
---
I'd like to see this message, which is on by default, for the change
introduced in r132614. I haven't figured out how to determine if the offset
for a field has changed, just the alignment. I'll attach my
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2009-03-18 16:56
---
OK. I decided to look at this in more detail in the simulator. The failing
instruction is:
2001358: d0 07 bf fc ld [ %fp + -4 ], %o0
and when I run with a breakpoint there, a dump
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2009-03-18 18:54
---
Subject: Bug 35180
Author: ebotcazou
Date: Wed Mar 18 18:54:31 2009
New Revision: 144942
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144942
Log:
PR target/35180
* config/sparc/sparc.md
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2009-03-18 22:24
---
Please post the failure message when you report failures.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2009-03-17 21:22
---
* cp/method.c (use_thunk): Change is_thunk from crtl to cfun.
in ChangeLog is incorrect. It should be
* method.c (use_thunk): Change is_thunk from crtl to cfun.
in cp/ChangeLog.
--
ebotcazou at gcc dot
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-03-13 09:35
---
Works fine now, thanks for the quick turn around!
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
: failure of SSE2 tests
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ebotcazou at gcc
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2009-03-12 18:43
---
How can I reproduce it?
-mtune=i586 presumably.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39445
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2009-03-11 09:06
---
See http://gcc.gnu.org/ml/gcc-patches/2008-12/msg01134.html
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2009-03-11 10:25
---
I thought that the now what as with your patch. So it looks indeed like quite
similar to what I see. I'll try to see why it doesn't solve my case.
Reverting to the old canonicalization at the tree level
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2009-03-08 09:02
---
The branch is (virtually) closed.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-03-08 09:04
---
http://gcc.gnu.org/ml/gcc-cvs/2009-02/msg00594.html
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2009-03-08 09:09
---
No feedback in 3 months.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2009-03-08 09:11
---
No feedback 3 years.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2009-03-08 09:12
---
No feedback in 3 months.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-03-08 09:18
---
The stack must be executable because of trampolines.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2009-03-08 09:21
---
Patches must be submitted on gcc-patches@
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-03-08 09:38
---
A workaround is to remove -gnatE.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2009-03-08 09:46
---
What happened to the patch?
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Summary|gcc Ada does not handle |fixed point
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Summary|gcc Ada doesn't handle |address
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2009-03-08 09:54
---
The testcase compiles with -gnat95.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2009-03-08 10:03
---
*** This bug has been marked as a duplicate of 39221 ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2009-03-08 10:03
---
*** Bug 25819 has been marked as a duplicate of this bug. ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-03-05 13:06
---
Currently sizeof(f1) == sizeof(int) rather than 4*sizeof(int), i.e.
sizeof the object is determined by the type only, not the actual object
size taking into account its initializer.
That's C. 6.5.3.4 (2
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2009-03-05 13:31
---
No, the case is an extension to C. 6.5.3.4 was obviously written without this
case in mind.
Not at all, see 6.7.2.1 (16):
16 As a special case, the last element of a structure with more than one named
member
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2009-03-02 18:42
---
I'm seeing it on an ACATS test as well (with local compiler modifications).
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2009-03-01 08:07
---
There is a bug in the gcc compiler for the C code that changes the behavior of
a simple program with -O2 optimizations, but not with -O1 or -O0.
-O2 enables -fstrict-aliasing so the code must be written in ISO
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2009-03-01 10:53
---
Subject: Bug 39264
Author: ebotcazou
Date: Sun Mar 1 10:53:17 2009
New Revision: 144514
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144514
Log:
PR ada/39264
* gcc-interface/decl.c
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2009-03-01 10:56
---
The test should pass everywhere now.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2009-02-28 11:38
---
Is there a 64-bit GDB around on the machine?
ebotca...@gcc40:~$ gdb pack3
GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2009-02-26 08:16
---
fstack-check is known to be broken on x86 GNU/Linux, see PR 13757.
Yes, the current implementation is non-functional on x86{-64}/Linux.
*** This bug has been marked as a duplicate of 13757
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2009-02-26 08:16
---
*** Bug 39306 has been marked as a duplicate of this bug. ***
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #25 from ebotcazou at gcc dot gnu dot org 2009-02-26 08:26
---
Also, you can have the same problem with this kind of code without threads.
Imagine, for example, if the 'shared_variable' may be in read-only memory and
'can_write' indicates this case.
Then it must
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-02-23 14:43
---
Visible on s390x as well:
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02251.html
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2009-02-23 14:43
---
Investigating.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2009-02-18 09:51
---
Please make sure the warning is issued only for appropriate languages (it is
not
needed in Ada for example and the wording doesn't make sense). TIA.
--
ebotcazou at gcc dot gnu dot org changed
--- Comment #26 from ebotcazou at gcc dot gnu dot org 2009-02-18 22:11
---
Fixed. The C++ static/extern issue has been added as PR 39236.
You have installed a lot more things than what's described in the ChangeLog.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2009-02-17 18:56
---
TREE_STATIC DECL_EXTERNAL doesn't make sense for a VAR_DECL as per tree.h:
/* In a VAR_DECL, nonzero means allocate static storage.
#define TREE_STATIC(NODE) ((NODE)-base.static_flag)
* In a VAR_DECL
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2009-02-14 17:16
---
The problem is that targetm.binds_local_p returns true for
var_decl 0xb7866000 k
type integer_type 0xb785edd0 unsigned int readonly unsigned SI
size integer_cst 0xb778b4a4 constant 32
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-02-12 11:40
---
Even for code with lots of computed gotos, the CFG should not be fully
connected. We factorize computed gotos to avoid exactly that. At least we
used
to. Maybe the factorizing is broken, or it is undone
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2009-02-09 11:09
---
Subject: Bug 38981
Author: ebotcazou
Date: Mon Feb 9 11:09:25 2009
New Revision: 144032
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144032
Log:
PR middle-end/38981
* tree-ssa
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2009-02-09 11:11
---
Thanks for reporting the problem.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2009-02-08 10:09
---
Confirmed on Solaris 8, but neither on Solaris 9 nor on Solaris 10.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2009-02-08 10:11
---
Btw, the default extension for preprocessed sources is .i, just pass
-save-temps
to the compiler to get the file.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2009-02-08 10:26
---
This is a bug in the qsort implementation on Solaris 8:
Breakpoint 1, sort_coalesce_list (cl=0x1ce4b80)
at /nile.build/botcazou/gcc-head/src/gcc/tree-ssa-coalesce.c:434
434 qsort (cl-sorted, num
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2009-02-08 10:58
---
This is a bug in the qsort implementation on Solaris 8:
Browsing the Sun database shows several related tickets, but most have been
closed as not a defect on the ground that the comparator function fails
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2009-02-08 12:33
---
Recategorizing.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-02-08 13:01
---
Reproducible with every compiler I tried...
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2009-02-08 13:01
---
Investigating.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Summary|Unaligned memory access with|unaligned
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2009-02-08 17:59
---
Still present on SPARC 32-bit on the mainline:
FAIL: gcc.c-torture/execute/pr38819.c execution, -O2
FAIL: gcc.c-torture/execute/pr38819.c execution, -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-01-29 14:37
---
RTEMS has fixed size task stacks. This test is blowing a stack that is ~100K
large. How large does it need to be? Is is a bug to use this much stack?
It's a QOI issue, the stack usage is already capped (see
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2009-01-25 18:02
---
Do we have a testcase for a primary platform that is affected by this bug?
FWIW I haven't seen this failure mode on the SPARC yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38740
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-01-10 22:06
---
I don't know how I can test this file alone without regtesting all gcc (I
tried: make -k check-gcc RUNTESTFLAGS=dg.exp=graphite/block-3.c without
success).
Try make -k check-gcc RUNTESTFLAGS=graphite.exp
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-01-07 10:11
---
Fallout of the change made for PR middle-end/23294 in GCC 4.2.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2009-01-06 12:57
---
Bootstrapping GNAT with a more recent GNAT is not supported.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2009-01-06 13:24
---
I've seen that on the SPARC too. Does Richard's patch in
http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00506.html
help? If so, it is approved for mainline and 4.3 branch.
--
ebotcazou at gcc dot gnu dot
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2009-01-06 13:27
---
Please fill in the known to work field if you can.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from ebotcazou at gcc dot gnu dot org 2009-01-07 06:34
---
Most interesting libcalls for x86 -m32 probably are the DImode ones, and if
subreg lowering does this for all arguments, we would have to update the
REG_REP notes in the CALL_INSN, or do a lot of DSE-like
: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ebotcazou at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38591
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2008-12-21 16:07
---
What are the differences?
This is explained in the message.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38591
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2008-12-21 17:12
---
auto-host.h must exist when those files were compiled. I guess
it was generated more than once.
My understanding is that it is re-generated at each stage:
auto-host.h: cstamp-h ; @true
cstamp-h: config.in
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2008-12-20 22:33
---
Subject: Bug 37610
Author: ebotcazou
Date: Sat Dec 20 22:32:30 2008
New Revision: 142850
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142850
Log:
PR target/37610
* configure.ac
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38495
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-12-17 17:19
---
Created an attachment (id=16917)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16917action=view)
Reduced testcase
To be gnatchop-ed and compiled at -O2 -gnatp -mtune=i686.
--
http://gcc.gnu.org
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2008-12-17 17:35
---
Vlad, I'd again need your help for this one, it's apparently a stack slot
sharing problem. Ada testcase and instructions have been filed.
The problematic excerpt of assembly is:
movl%esi, -28(%ebp
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2008-12-17 17:15
---
a-strfix.adb is miscompiled at -O2 -gnatp on i686 (not i586).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38495
--- Comment #33 from ebotcazou at gcc dot gnu dot org 2008-12-11 12:44
---
Eric, you would add a blurb about that in the platform-specific installation
notes (comment #25). Did that happen?
No, it didn't, IIRC I wasn't sure of my analysis at all.
What do you, as a SPARC port
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2008-12-11 12:45
---
See PR 10353.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2008-12-11 23:03
---
I guess for !ACCUMULATE_OUTGOING_ARGS DCE of calls having stack arguments
generally shouldn't be an issue (unless they pop the stack themselves, don't
remember if it is easily determinable in generic way
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2008-12-11 23:18
---
http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg01144.html
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #88 from ebotcazou at gcc dot gnu dot org 2008-12-10 08:48
---
Subject: Bug 37170
Author: ebotcazou
Date: Wed Dec 10 08:46:40 2008
New Revision: 142640
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142640
Log:
PR target/37170
PR target/38448
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2008-12-10 08:48
---
Subject: Bug 38448
Author: ebotcazou
Date: Wed Dec 10 08:46:40 2008
New Revision: 142640
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142640
Log:
PR target/37170
PR target/38448
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2008-12-09 10:58
---
a current snapshot from the branch, exluding r142149 works for me. I'll try to
reduce the applied patches until the builds succeeds again with r142149, but
again, this may take a while.
The only possibility
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2008-12-09 16:35
---
sorry for not noticing earlier; indeded, this is a patch by CodeSourcery to
enable to build libobjc.
see http://lists.debian.org/debian-gcc/2008/04/msg00240.html
Thanks. The definition of EH_USES looks
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-12-09 18:32
---
Now on to this one. :-) Is 20081115 the date of the first failure? 08 was
fine?
There are test results for IA-64/Linux (suse-linux and unknown-linux) both
4.3.3
and 4.4.0 posted on the gcc-testresults
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2008-12-08 23:01
---
a current snapshot from the branch, exluding r142149 works for me. I'll try to
reduce the applied patches until the builds succeeds again with r142149, but
again, this may take a while.
So are the dates
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2008-12-08 23:11
---
Your sparc patch referenced in comment #1 fixes this powerpc64-linux failure.
Are you planning to push for it to be accepted for 4.4?
Already done yesterday: http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00418
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2008-12-06 08:11
---
r142149 | ebotcazou | 2008-11-24 09:36:43 +0100 (Mon, 24 Nov 2008) | 4 lines
* df-scan.c (df_get_call_refs): For unconditional noreturn calls
add EH_USES regs as artificial uses
501 - 600 of 2613 matches
Mail list logo
