This is something I've had on my disk for a few months; committed and
also activated on gcc.gnu.org.
In case anyone wonders, the reason why some snapshot was created earlier
during the day was due to me debugging something at one point. :-)
Gerald
2007-01-05 Gerald Pfeifer [EMAIL PROTECTED]
On Thu, Jan 04, 2007 at 03:31:46PM -0800, H. J. Lu wrote:
Here is one implementation of ELF sharable section proposal:
http://groups-beta.google.com/group/generic-abi/browse_thread/thread/bca08f6560f61b0d
Several people have expressed interests. I post it here for comments.
I used OS
On Fri, Jan 05, 2007 at 08:53:07AM +, Christoph Hellwig wrote:
On Thu, Jan 04, 2007 at 03:31:46PM -0800, H. J. Lu wrote:
Here is one implementation of ELF sharable section proposal:
http://groups-beta.google.com/group/generic-abi/browse_thread/thread/bca08f6560f61b0d
Several
Are 4.0 snapshots still necessary? I suspect they should be
discontinued.
David
On Fri, Jan 05, 2007 at 08:19:39AM +0100, Eric Botcazou wrote:
Not much. I'm convinced it would be feasible, but definitely not easy,
so I wanted to see how much interest there was - seems like some, but
not a lot.
Would this comprise retrofitting the support into the 4.2 branch?
I have
This is from the gcc-help mailing list. It's mentioned there for ARM,
but it's just as bad for x86-64.
It appears that memory references to arrays aren't being hoisted out
of loops: in this test case, gcc 3.4 doesn't touch memory at all in
the loop, but 4.3pre (and 4.2, etc) does.
Here's the
Not much. I'm convinced it would be feasible, but definitely not easy,
so I wanted to see how much interest there was - seems like some, but
not a lot.
Would this comprise retrofitting the support into the 4.2 branch?
I don't think it's needed in the 4.2 branch since you can get the
On Fri, Jan 05, 2007 at 09:23:56AM -0500, Richard Kenner wrote:
Not much. I'm convinced it would be feasible, but definitely not easy,
so I wanted to see how much interest there was - seems like some, but
not a lot.
Would this comprise retrofitting the support into the 4.2 branch?
Please does anyone know the answer to the following questions?
1. The operating system (OS) schedules tasks, but gnat allow us to set
schedule policies such as Round Robin, then how does gnat tell the OS to
start doing Round Robin scheduling?
2. If someone wants to write a new
Andrew Haley [EMAIL PROTECTED] writes:
It appears that memory references to arrays aren't being hoisted out
of loops: in this test case, gcc 3.4 doesn't touch memory at all in
the loop, but 4.3pre (and 4.2, etc) does.
Here's the test case:
void foo(int *a)
{ int i;
for (i
David Edelsohn [EMAIL PROTECTED] writes:
Are 4.0 snapshots still necessary? I suspect they should be
discontinued.
4.0 still seems to be regarded as an active branch.
I don't mind closing it, myself. Does anybody think we should have a
4.0.4 release?
Ian
Daniel Jacobowitz wrote on 12/30/06 02:08:
Once upon a time, the --disable-bootstrap configure option wasn't
necessary. make built gcc, and make bootstrap bootstrapped it.
Is this behavior useful? Should we have it back again?
That'd be great. I miss the old behaviour.
On 05 Jan 2007 07:18:47 -0800, Ian Lance Taylor [EMAIL PROTECTED] wrote:
At the tree level, the problem is that the assignment to a[0] is seen
as aliasing a[1]. This causes the use of a[1] to look like a USE of
an SMT, and the assignment to a[0] to look like a DEF of the same
SMT. So in
On 1/5/07, Andrew Haley [EMAIL PROTECTED] wrote:
This is from the gcc-help mailing list. It's mentioned there for ARM,
but it's just as bad for x86-64.
It appears that memory references to arrays aren't being hoisted out
of loops: in this test case, gcc 3.4 doesn't touch memory at all in
the
Steven Bosscher writes:
Steven What does the code look like if you compile with -O2 -fgcse-sm?
Yep. Mark and I recently discussed whether gcse-sm should be
enabled by default at some optimization level. We're hiding performance
from GCC users.
David
Steven Bosscher writes:
On 1/5/07, Andrew Haley [EMAIL PROTECTED] wrote:
This is from the gcc-help mailing list. It's mentioned there for ARM,
but it's just as bad for x86-64.
It appears that memory references to arrays aren't being hoisted out
of loops: in this test case, gcc
On 1/5/07, David Edelsohn [EMAIL PROTECTED] wrote:
Steven Bosscher writes:
Steven What does the code look like if you compile with -O2 -fgcse-sm?
Yep. Mark and I recently discussed whether gcse-sm should be
enabled by default at some optimization level. We're hiding performance
, (%ecx)
but now I get (gcc version 4.3.0 20070105 (experimental)) (rev 120486
(this would be interesting in the output of gcc -v, is there a way to
put the revision there?))
call__sync_bool_compare_and_swap_4
Now, reading the manual suggests that if I use the wrong architecture I
should
I have no intention of touching the build system for the release
branch, in any case.
So, assuming we go back to the old behaviour, 4.2.x would be the only series
for which 'make' performs a complete bootstrap? Seems a little odd. I think
we need a clear cut here: either automatic bootstrap
On Fri, Jan 05, 2007 at 06:00:53PM +0100, Eric Botcazou wrote:
So, assuming we go back to the old behaviour, 4.2.x would be the only series
for which 'make' performs a complete bootstrap? Seems a little odd. I think
we need a clear cut here: either automatic bootstrap is a good feature and
)
lock
cmpxchgl%edx, (%ecx)
but now I get (gcc version 4.3.0 20070105 (experimental)) (rev 120486
(this would be interesting in the output of gcc -v, is there a way to
put the revision there?))
call__sync_bool_compare_and_swap_4
Now, reading the manual
On Fri, Jan 05, 2007 at 05:05:41PM +, Andrew Haley wrote:
But it can't unless you use an architecture that has cmpxchgl.
cmpxchgl is a 486 instruction; if you compile for 386, we have to
generate the call because there is no such instruction.
And the older compiler was a Debian packaged
Hi all!
I don't know exactly if I've understood all your previous explanation (excepted
the load store motion part), but we pointed out 2 different problems:
Pb n°1: depending on the optimization level -03, a[0] and a[1] are being loaded
and stored on each loop iteration
Pb n°2: depending on
Please don't top-post. It's very confusing.
Mick CORNUT writes:
I don't know exactly if I've understood all your previous
explanation (excepted the load store motion part), but we pointed
out 2 different problems:
Pb n°1: depending on the optimization level -03, a[0] and a[1] are
On Fri, Jan 05, 2007 at 07:26:27AM -0800, Ian Lance Taylor wrote:
David Edelsohn [EMAIL PROTECTED] writes:
Are 4.0 snapshots still necessary? I suspect they should be
discontinued.
4.0 still seems to be regarded as an active branch.
I don't mind closing it, myself. Does anybody
On 1/5/07, Joe Buck [EMAIL PROTECTED] wrote:
On Fri, Jan 05, 2007 at 07:26:27AM -0800, Ian Lance Taylor wrote:
David Edelsohn [EMAIL PROTECTED] writes:
Are 4.0 snapshots still necessary? I suspect they should be
discontinued.
4.0 still seems to be regarded as an active branch.
I
I'd like to see it closed, too, all Linux/BSD vendors I know of are either
still using 3.x or have switched to 4.1 already.
Yes, 4.1.x seems to have been selected by various vendors as the codebase for
their first GCC4-based release.
--
Eric Botcazou
Are 4.0 snapshots still necessary? I suspect they should be
discontinued.
4.0 still seems to be regarded as an active branch.
I don't mind closing it, myself. Does anybody think we should have a
4.0.4 release?
I'd like to see it closed. We have some bugs that are
On 1/5/07, David Fang [EMAIL PROTECTED] wrote:
Are 4.0 snapshots still necessary? I suspect they should be
discontinued.
4.0 still seems to be regarded as an active branch.
I don't mind closing it, myself. Does anybody think we should have a
4.0.4 release?
I'd
On Fri, Jan 05, 2007 at 02:23:36PM -0500, David Fang wrote:
User chiming in: before retiring 4.0, one would be more easily convinced
to make a transition to 4.1+ if the regressions from 4.0 to 4.1 numbered
fewer. In the database, I see only 79 (P3+) regressions in 4.1 that are
not in 4.0
[ omitting gcc-patches ]
On Fri, 5 Jan 2007, Joe Buck wrote:
I'd like to see it closed. We have some bugs that are only open
because they are targeted for 4.0.4 (fixed on all branches but 4_0).
If there is consensus, I'll be happy to take the appropriate steps,
which include:
1. Updating
[ omitting gcc-patches ]
On Fri, 5 Jan 2007, Joe Buck wrote:
I'd like to see it closed. We have some bugs that are only open
because they are targeted for 4.0.4 (fixed on all branches but 4_0).
If there is consensus, I'll be happy to take the appropriate steps,
which include:
1.
Joe Buck [EMAIL PROTECTED] writes:
| On Fri, Jan 05, 2007 at 07:26:27AM -0800, Ian Lance Taylor wrote:
| David Edelsohn [EMAIL PROTECTED] writes:
|
| Are 4.0 snapshots still necessary? I suspect they should be
| discontinued.
|
| 4.0 still seems to be regarded as an active branch.
|
On Fri, Jan 05, 2007 at 03:02:00PM -0500, Andrew Pinski wrote:
[ omitting gcc-patches ]
On Fri, 5 Jan 2007, Joe Buck wrote:
I'd like to see it closed. We have some bugs that are only open
because they are targeted for 4.0.4 (fixed on all branches but 4_0).
If there is
Joe Buck [EMAIL PROTECTED] writes:
| On Fri, Jan 05, 2007 at 07:26:27AM -0800, Ian Lance Taylor wrote:
| David Edelsohn [EMAIL PROTECTED] writes:
|
| Are 4.0 snapshots still necessary? I suspect they should be
| discontinued.
|
| 4.0 still seems to be regarded as an
On fre, 2007-01-05 at 17:05 +, Andrew Haley wrote:
Magnus Fromreide writes:
But it can't unless you use an architecture that has cmpxchgl.
cmpxchgl is a 486 instruction; if you compile for 386, we have to
generate the call because there is no such instruction.
Sigh - I failed to tell
Joe Buck [EMAIL PROTECTED] writes:
| On Fri, Jan 05, 2007 at 03:02:00PM -0500, Andrew Pinski wrote:
|
| [ omitting gcc-patches ]
|
| On Fri, 5 Jan 2007, Joe Buck wrote:
|I'd like to see it closed. We have some bugs that are only open
|because they are targeted for 4.0.4 (fixed
On Fri, Jan 05, 2007 at 09:27:35PM +0100, Magnus Fromreide wrote:
On fre, 2007-01-05 at 17:05 +, Andrew Haley wrote:
Magnus Fromreide writes:
But it can't unless you use an architecture that has cmpxchgl.
cmpxchgl is a 486 instruction; if you compile for 386, we have to
generate
On fre, 2007-01-05 at 12:53 -0800, H. J. Lu wrote:
On Fri, Jan 05, 2007 at 09:27:35PM +0100, Magnus Fromreide wrote:
On fre, 2007-01-05 at 17:05 +, Andrew Haley wrote:
Magnus Fromreide writes:
But it can't unless you use an architecture that has cmpxchgl.
cmpxchgl is a 486
On 05 Jan 2007 07:18:47 -0800, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Andrew Haley [EMAIL PROTECTED] writes:
It appears that memory references to arrays aren't being hoisted out
of loops: in this test case, gcc 3.4 doesn't touch memory at all in
the loop, but 4.3pre (and 4.2, etc) does.
Snapshot gcc-4.3-20070105 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070105/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Tom == Tom Tromey [EMAIL PROTECTED] writes:
Tom We're planning to merge the 'gcj-eclipse' branch back to the
Tom trunk this week.
We discovered a couple libjava test suite failures in the merged tree.
I'm holding off committing this merge until Andrew investigates them a
bit more.
Meanwhile
Chris,
I see you have not received any response to this yet, so let me give
it a try.
On Sat, 28 Oct 2006, Chris Pickett wrote:
1. Create a default section, at the top, and put all options enabled by
default there.
This sounds like an interesting proposal. Gaby, Joseph, what do you
think?
--- Comment #4 from burnus at gcc dot gnu dot org 2007-01-05 09:08 ---
Subject: Bug 29624
Author: burnus
Date: Fri Jan 5 09:08:37 2007
New Revision: 120472
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120472
Log:
fortran/
2007-01-05 Tobias Burnus [EMAIL PROTECTED]
--- Comment #5 from burnus at gcc dot gnu dot org 2007-01-05 09:20 ---
Fixed in 4.3.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from pault at gcc dot gnu dot org 2007-01-05 09:30 ---
(In reply to comment #1)
What GCC is doing is calling _gfortran_internal_pack/_gfortran_internal_unpack
in a different order than most other compilers.
It should not call _gfortran_internal_unpack at all for the
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-01-05 10:06
---
I guess we could try to provide a graceful degradation for such systems... The
use of dup() can probably be avoided if dup() isn't available, without too much
degradation in the library features. access() can
--- Comment #1 from rearnsha at gcc dot gnu dot org 2007-01-05 10:10
---
A better patch, suggested by Nicolas Pitre is:
@ Result is x + 0.0 = x or 0.0 + y = y.
- teq r4, #0
+ orrsip, r4, xl
moveq xh, yh
moveq xl, yl
RETLDM r4, r5
which performs the
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-01-05 10:10
---
Confirmed as it has been reported by other people as well. I don't understand
enough of this name aliasing to understand the reason for this bug. Can you
confirm that the following is enough to trigger the bug?
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-01-05 11:35 ---
Subject: Bug 29241
Author: rguenth
Date: Fri Jan 5 11:35:01 2007
New Revision: 120475
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120475
Log:
2007-01-05 Richrad Guenther [EMAIL PROTECTED]
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-01-05 11:36 ---
Fixed for 4.1.2.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-01-05 11:43
---
Mine. I'm testing the inliner fix.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
Summary: [4.1 RegressionICE in build_enumerator, at
cp/decl.c:10111
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-01-05 12:31 ---
I see
=== g++ tests ===
Running target unix
FAIL: g++.dg/parse/enum3.C (test for errors, line 3)
FAIL: g++.dg/parse/enum3.C (test for excess errors)
FAIL: g++.old-deja/g++.bugs/900405_01.C (test
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-01-05 12:40 ---
Reverting
Author: jakub
Date: Wed Jan 3 08:13:50 2007
New Revision: 120392
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120392
Log:
PR c++/29535
Backported from mainline
2006-10-17
--- Comment #2 from vk3ty at bigpond dot com 2007-01-05 12:57 ---
(In reply to comment #1)
../../../unxfbsdi.pro/misc/dict_zh.cxx
g++-ooo: Internal error: Killed: 9 (program cc1plus)
This usually means GCC is running out of memory.
Can you do two things for us?
First can you
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-01-05 13:01
---
Reconfirmed. The problem still exists.
#1 0x0844d296 in copy_to_mode_reg (mode=SImode, x=0xb7c8b1a0)
at /home/richard/src/gcc-4_1-branch/gcc/explow.c:577
577 gcc_assert (GET_MODE (x) == mode ||
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-01-05 13:06
---
But of course at least after SRA we miss a NOP_EXPR on the initialization:
intD.2 SR.40D.1798;
short intD.12 SR.39D.1797;
short intD.12 test$typeD.1796;
short intD.12 D.1745;
short intD.12 D.1744;
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-01-05 13:17
---
=== g++ tests ===
Running target unix
FAIL: g++.dg/parse/enum3.C (test for errors, line 3)
FAIL: g++.dg/parse/enum3.C (test for excess errors)
FAIL: g++.old-deja/g++.bugs/900405_01.C
--- Comment #4 from jakub at gcc dot gnu dot org 2007-01-05 13:44 ---
Sorry, I have mistakenly bootstrapped this with the default checking
(i.e. --enable-checking=release).
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-01-05 13:45
---
And we get that because for the COMPONENT_REF
D.1741.typeD.1734
we have
component_ref 0xb7c3d168
type integer_type 0xb7c401cc short int HI
size integer_cst 0xb7c2e300 constant invariant 16
--- Comment #19 from rguenth at gcc dot gnu dot org 2007-01-05 13:46
---
So the proposed patch (for all branches) is:
Index: tree.c
===
*** tree.c (revision 120477)
--- tree.c (working copy)
***
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-01-05 13:47
---
Sorry, I have mistakenly bootstrapped this with the default checking
(i.e. --enable-checking=release).
Richard's log is actually --enable-checking=release. With tree checking
=== g++ tests
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-01-05 13:53
---
Subject: Bug 28116
Author: rguenth
Date: Fri Jan 5 13:53:45 2007
New Revision: 120480
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120480
Log:
2007-01-05 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-01-05 13:57
---
Subject: Bug 28116
Author: rguenth
Date: Fri Jan 5 13:56:54 2007
New Revision: 120481
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120481
Log:
2007-01-05 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-01-05 13:59
---
Various cygwin testresults posted to the gcc-testresults mailing-list show no
failure of these tests. Closing accordingly.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-01-05 14:00
---
Subject: Bug 28116
Author: rguenth
Date: Fri Jan 5 14:00:46 2007
New Revision: 120482
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120482
Log:
2007-01-05 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-01-05 14:02
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-01-05 14:03
---
(In reply to comment #11)
A draft patch was posted (quite a while ago) by FX:
http://gcc.gnu.org/ml/fortran/2006-11/msg00634.html
I'd add that it's easy to separate the coredump part of the patch (handling of
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-01-05 14:06
---
This bug has been open for more that one year without any update, without
general agreement on wether we have a bug or a testcase exhibiting incorrect or
suboptimal behaviour.
Closing.
--
fxcoudert at gcc
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-01-05 14:12
---
ping: Would you have either an example where this limit is encountered?
Wouldn't 4.3 be ideal for that work?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21881
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-01-05 14:15
---
Is this still a bug, with the new patches for optimizing calls to memcpy?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jakub at gcc dot gnu dot org 2007-01-05 14:18 ---
http://gcc.gnu.org/viewcvs?view=revrevision=115086
Hope it is enough to put in just the 4 lines...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30382
--- Comment #20 from rguenth at gcc dot gnu dot org 2007-01-05 14:30
---
Mine (patch posted).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pault at gcc dot gnu dot org 2007-01-05 14:45 ---
Subject: Bug 27996
Author: pault
Date: Fri Jan 5 14:45:20 2007
New Revision: 120485
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120485
Log:
2007-01-05 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #9 from pault at gcc dot gnu dot org 2007-01-05 14:45 ---
Subject: Bug 23232
Author: pault
Date: Fri Jan 5 14:45:20 2007
New Revision: 120485
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120485
Log:
2007-01-05 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #4 from pault at gcc dot gnu dot org 2007-01-05 14:45 ---
Subject: Bug 27998
Author: pault
Date: Fri Jan 5 14:45:20 2007
New Revision: 120485
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120485
Log:
2007-01-05 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #7 from jakub at gcc dot gnu dot org 2007-01-05 14:56 ---
Created an attachment (id=12859)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12859action=view)
gcc41-pr30382.patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30382
I just tried to compile package libhugetlbfs-1.0.1-200612221420
with the GNU C compiler version 4.2 snapshot 20061230
The compiler said
/usr/include/bits/string3.h: In function 'jumpfunc':
/usr/include/bits/string3.h:51: internal compiler error: in ix86_expand_movmem,
at config/i386/i386.c:13608
--- Comment #1 from dcb314 at hotmail dot com 2007-01-05 15:31 ---
Created an attachment (id=12860)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12860action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30383
--- Comment #2 from jakub at gcc dot gnu dot org 2007-01-05 15:49 ---
Subject: Bug 30360
Author: jakub
Date: Fri Jan 5 15:49:05 2007
New Revision: 120486
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120486
Log:
PR c/30360
* libgcc2.c (__divdc3): Compare c and d
--- Comment #3 from jakub at gcc dot gnu dot org 2007-01-05 15:50 ---
Subject: Bug 30360
Author: jakub
Date: Fri Jan 5 15:50:25 2007
New Revision: 120487
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120487
Log:
PR c/30360
* libgcc2.c (__divdc3): Compare c and d
--- Comment #4 from jakub at gcc dot gnu dot org 2007-01-05 15:53 ---
Subject: Bug 30360
Author: jakub
Date: Fri Jan 5 15:53:31 2007
New Revision: 120488
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120488
Log:
PR c/30360
* libgcc2.c (__divdc3): Compare c and d
--- Comment #7 from jakub at gcc dot gnu dot org 2007-01-05 15:55 ---
Subject: Bug 25993
Author: jakub
Date: Fri Jan 5 15:55:45 2007
New Revision: 120489
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120489
Log:
Backported from mainline
2006-09-17 Steven
--- Comment #5 from jakub at gcc dot gnu dot org 2007-01-05 16:16 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-01-05 16:30 ---
It seems to be IVOPTs rewriting introduces the trees. Testcase:
extern void op( int, int);
void foo(int f0, int f1, int e0, int e1)
{
for (int i1 = f1; i1 = e1; ++i1)
for (int i0 = f0; i0 = e0; ++i0)
on i386-darwin. The command-line generating this error is:
/tmp/gfortran-20070105/ibin/./prev-gcc/xgcc
-B/tmp/gfortran-20070105/ibin/./prev-gcc/
-B/usr/local/gfortran/i386-apple-darwin8.8.1/bin/ -c -DHAVE_CONFIG_H -O2 -g
-fomit-frame-pointer -I. -I../../gcc/libiberty/../include -W -Wall -pedantic
--- Comment #2 from hartmann at physik dot uni-kl dot de 2007-01-05 16:42
---
ok.
the trick with the include which provides additional 7 chars confused me. but
the issue remains: I'm not able to produce an position independent gcc for
mingw without hacking cppdefaults.c. The reason for
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-01-05 16:51 ---
(In reply to comment #4)
I guess we could try to provide a graceful degradation for such systems... The
use of dup() can probably be avoided if dup() isn't available, without too
much
degradation in the library
--- Comment #8 from jakub at gcc dot gnu dot org 2007-01-05 16:53 ---
Subject: Bug 30382
Author: jakub
Date: Fri Jan 5 16:53:27 2007
New Revision: 120490
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120490
Log:
PR c++/30382
Backported from mainline:
--- Comment #9 from jakub at gcc dot gnu dot org 2007-01-05 16:54 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-05 17:08 ---
Mine for now as I am going to apply the testcase:
static void g(int t)
{
int a;
while (a f())
;
}
void h(int t)
{
g(t);
}
-
Which was fixed by:
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00359.html
--- Comment #3 from rask at sygehus dot dk 2007-01-05 17:29 ---
Created an attachment (id=12861)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12861action=view)
patch in testing to fix typo
The option -specs=ldblspecs is added by gcc/config/rs6000/t-ppccomm when
compiling libgcc2
--- Comment #15 from mmitchel at gcc dot gnu dot org 2007-01-05 17:39
---
Eric asked me to weigh in here. My only concern about a backport is Comment
#9, which suggests that the patch didn't work. I'm assuming that since we're
all talking about backporting it, that comment was
--- Comment #4 from joseph at codesourcery dot com 2007-01-05 17:52 ---
Subject: Re: Build failure in libgcc2 powitf2 with ICE in
gen_reg_rtx
On Fri, 5 Jan 2007, rask at sygehus dot dk wrote:
The option -specs=ldblspecs is added by gcc/config/rs6000/t-ppccomm when
compiling
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2007-01-05 18:10
---
Eric asked me to weigh in here. My only concern about a backport is Comment
#9, which suggests that the patch didn't work. I'm assuming that since we're
all talking about backporting it, that comment was
--- Comment #17 from mark at codesourcery dot com 2007-01-05 18:13 ---
Subject: Re: [4.0/4.1 regression] internal consistency
failure
ebotcazou at gcc dot gnu dot org wrote:
Thanks Mark. It seems that a whole new class of internal consistency failures
due to the mishandling of
--- Comment #3 from stuart at apple dot com 2007-01-05 18:27 ---
Created an attachment (id=12862)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12862action=view)
vectorized assembly output from ICC v9.1
Generated from the indefinite loop variant of the testcase on OS X 10.4.7,
--- Comment #4 from stuart at apple dot com 2007-01-05 18:30 ---
I ran the testcase through ICC, and it unrolled the loops without vectorizing
them. However, making the loops indefinite gets us the desired, vectorized
result. Here is the modified, indefinite loop version of the
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2007-01-05 18:33
---
Do you mean positive cascading effects, in that bugs go away, or
negative, in that new bugs show up?
Positive cascading effects if the set of patch is backported to the branch.
Do you think that backporting
1 - 100 of 156 matches
Mail list logo
