On 12/5/07, Jan Beulich [EMAIL PROTECTED] wrote:
Andrew Pinski [EMAIL PROTECTED] 25.11.07 19:45
On 11/25/07, Luca [EMAIL PROTECTED] wrote:
7.1. Add __attribute__((pointer_size(XXX))) and #pragma pointer_size
to allow 64-bit pointers in 32-bit mode and viceversa
This is already there,
Hi,
My libc is configured to omit any FP support (UCLIBC_HAS_FLOATS is not set)
but the recent libbid updates seems to unconditionally pull in floatingpoint
accessor functions thus breaking bootstrap. My notes on this read:
8
Follows:
Precedes:
do not pull in allegedly
On 11/25/07 3:43 PM, Mark Mitchell wrote:
My suggestion (not as a GCC SC member or GCC RM, but just as a fellow
GCC developer with an interest in improving the compiler in the same way
that you're trying to do) is that you stop writing code and start
writing a paper about what you're trying to
Wednesday 05 December 2007 21:08:41 Daniel Berlin yazmıştı:
So I tried a full history conversion using git-svn of the gcc
repository (IE every trunk revision from 1-HEAD as of yesterday)
The git-svn import was done using repacks every 1000 revisions.
After it finished, I used git-gc
On 12/5/07, Daniel Berlin [EMAIL PROTECTED] wrote:
I already have two way sync with hg.
Maybe someday when git is more usable than hg to a normal developer,
or it at least is significantly smaller than hg, i'll look at it
again.
Sorry, what is hg?
On Dec 5, 2007 11:08 AM, Daniel Berlin [EMAIL PROTECTED] wrote:
So I tried a full history conversion using git-svn of the gcc
repository (IE every trunk revision from 1-HEAD as of yesterday)
The git-svn import was done using repacks every 1000 revisions.
After it finished, I used git-gc
On 12/5/07, NightStrike [EMAIL PROTECTED] wrote:
On 12/5/07, Daniel Berlin [EMAIL PROTECTED] wrote:
I already have two way sync with hg.
Maybe someday when git is more usable than hg to a normal developer,
or it at least is significantly smaller than hg, i'll look at it
again.
Sorry,
Daniel == Daniel Berlin [EMAIL PROTECTED] writes:
Daniel So I tried a full history conversion using git-svn of the gcc
Daniel repository (IE every trunk revision from 1-HEAD as of
Daniel yesterday) The git-svn import was done using repacks every
Daniel 1000 revisions. After it finished, I used
For the record:
[EMAIL PROTECTED]:/compilerstuff/gitgcc/gccrepo$ git --version
git version 1.5.3.7
(I downloaded it yesterday when i started the import)
On 12/5/07, Daniel Berlin [EMAIL PROTECTED] wrote:
So I tried a full history conversion using git-svn of the gcc
repository (IE every trunk
Tony,
To configure common-logging to use JDK logger. Create a file named
commons-loggin.properties with the following:
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Jdk14Logger
In a webapp this would go into WEB-INF/classes directory.
I'm not sure where to put it for the
On 12/5/07, Ollie Wild [EMAIL PROTECTED] wrote:
On Dec 5, 2007 11:08 AM, Daniel Berlin [EMAIL PROTECTED] wrote:
So I tried a full history conversion using git-svn of the gcc
repository (IE every trunk revision from 1-HEAD as of yesterday)
The git-svn import was done using repacks every 1000
On GCC we use -gnato on tests known to need it
(/gcc/testsuite/ada/acats/overflow.lst) since we want to test
flags the typical GCC/Ada user does use and not what official validation
requires (which is -gnato -gnatE IIRC).
But you're running a test that's *part* of the official validation and
On 05 December 2007 21:04, Daniel Berlin wrote:
Patch manager will be dying for a week or two while i change hosting.
of course, if nobody is still using it, i can just kill it permanently.
Well I haven't submitted any patches just lately, but I always use it when I
do, I think it's very
On Wed, Dec 05, 2007 at 04:32:00PM -0500, NightStrike wrote:
On 12/5/07, Daniel Berlin [EMAIL PROTECTED] wrote:
Patch manager will be dying for a week or two while i change hosting.
of course, if nobody is still using it, i can just kill it permanently.
grep -F -e patchapp gcc-bugs@
Snapshot gcc-4.2-20071205 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20071205/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 2007-11-27 18:29, Michael Eager wrote:
Joseph S. Myers wrote:
On Tue, 27 Nov 2007, Michael Eager wrote:
I think that there is a pervasive understanding that SImode is
single precision integer, 32-bits long.
Only among contributors not considering non-8-bit bytes. SImode
is 4
Boris Boesler [EMAIL PROTECTED] writes:
I assume that GCC internals assume that memory can be byte (8 bits)
addressed - for historical reasons.
No. gcc internals assume that memory can be addressed in units of
size BITS_PER_UNIT. The default for BITS_PER_UNIT is 8. I have
written
On 12/5/07, Daniel Berlin [EMAIL PROTECTED] wrote:
Patch manager will be dying for a week or two while i change hosting.
of course, if nobody is still using it, i can just kill it permanently.
What is the patch manager?
On 12/5/07, Daniel Berlin [EMAIL PROTECTED] wrote:
So I tried a full history conversion using git-svn of the gcc
repository (IE every trunk revision from 1-HEAD as of yesterday)
The git-svn import was done using repacks every 1000 revisions.
After it finished, I used git-gc --aggressive
On 12/5/07, Samuel Tardieu [EMAIL PROTECTED] wrote:
Daniel == Daniel Berlin [EMAIL PROTECTED] writes:
Daniel So I tried a full history conversion using git-svn of the gcc
Daniel repository (IE every trunk revision from 1-HEAD as of
Daniel yesterday) The git-svn import was done using repacks
On Tue, 2007-12-04 at 09:18 -0700, Tom Tromey wrote:
First, continuing to have good quality messages. Right now at the
very least you get a (semi-) accurate record of what was touched.
I've seen plenty of ChangeLog-less projects out there than end up with
commits like fixed a bug, or even
Harvey Harrison [EMAIL PROTECTED] writes:
On Wed, 2007-12-05 at 21:23 +0100, Samuel Tardieu wrote:
Daniel == Daniel Berlin [EMAIL PROTECTED] writes:
Daniel So I tried a full history conversion using git-svn of the gcc
Daniel repository (IE every trunk revision from 1-HEAD as of
Daniel
On Dec 5, 2007 6:15 PM, Ben Elliston [EMAIL PROTECTED] wrote:
On Tue, 2007-12-04 at 09:18 -0700, Tom Tromey wrote:
First, continuing to have good quality messages. Right now at the
very least you get a (semi-) accurate record of what was touched.
I've seen plenty of ChangeLog-less
On Thu, 2007-12-06 at 00:34 +0100, Andreas Schwab wrote:
Harvey Harrison [EMAIL PROTECTED] writes:
On Wed, 2007-12-05 at 21:23 +0100, Samuel Tardieu wrote:
Daniel == Daniel Berlin [EMAIL PROTECTED] writes:
Daniel So I tried a full history conversion using git-svn of the gcc
Daniel
On Wed, Mar 01, 2006 at 06:20:53PM +, Steven Newbury wrote:
OK, thank-you. I'll target arm-iwmmxt-linux-gnueabi with --with-cpu= etc
and
--disable-multilib. The vendor string is for my build scripts and also will
help differentiate the toolchain, is that valid?
Yep.
--
Daniel
On Wed, Dec 05, 2007 at 09:05:33AM -0500, Diego Novillo wrote:
In my simplistic view of this problem, I've always had the idea that -O0
-g means full debugging bliss, -O1 -g means tolerable debugging
(symbols shouldn't disappear, for instance, though they do now) and -O2
-g means you can
At revision 130629 regtesting on Intel Darwin9 gives a dozen
The process has forked and you cannot use this CoreFoundation functionality
safely. You MUST exec().
Break on
__THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__()
to debug.
then stop to
On Wed, 2007-12-05 at 21:23 +0100, Samuel Tardieu wrote:
Daniel == Daniel Berlin [EMAIL PROTECTED] writes:
Daniel So I tried a full history conversion using git-svn of the gcc
Daniel repository (IE every trunk revision from 1-HEAD as of
Daniel yesterday) The git-svn import was done using
So I tried a full history conversion using git-svn of the gcc
repository (IE every trunk revision from 1-HEAD as of yesterday)
The git-svn import was done using repacks every 1000 revisions.
After it finished, I used git-gc --aggressive --prune. Two hours
later, it finished.
The final size after
On 12/5/07, Daniel Berlin [EMAIL PROTECTED] wrote:
As I said, maybe i'll look at git in another year or so.
But i'm certainly going to ignore all the git is so great, we should
move gcc to it people until it works better, while i am much more
inclined to believe the hg is so great, we should
On Wed, 2007-12-05 at 18:35 -0500, Daniel Berlin wrote:
svn propedit --revision rev number svn:log
OK, well, it used to be a bit trickier in CVS .. :-)
Ben
Patch manager will be dying for a week or two while i change hosting.
of course, if nobody is still using it, i can just kill it permanently.
Ben Elliston wrote:
Something else that hasn't been raised is that ChangeLogs can be
revised. We often see people making mistakes with their ChangeLog
entries, but since the ChangeLog is versioned, they can revise it. If
you screw up a commit message, it's much harder to fix it (and a purist
On Dec 5, 2007 1:40 PM, Daniel Berlin [EMAIL PROTECTED] wrote:
Out of curiosity, how much of that is the .git/svn directory? This is
where git-svn-specific data is stored. It is *very* inefficient, at
least for the 1.5.2.5 version I'm using.
I was only counting the space in .the packs
Andrew Pinski [EMAIL PROTECTED] 25.11.07 19:45
On 11/25/07, Luca [EMAIL PROTECTED] wrote:
7.1. Add __attribute__((pointer_size(XXX))) and #pragma pointer_size
to allow 64-bit pointers in 32-bit mode and viceversa
This is already there, try using __attribute__((mode(DI) )).
Hmm, unless this
Thanks for the quick response!
I'm sure it seems I like to make hard wok for myself! It gets worse,
I'm porting Gentoo Linux to iWMMXt with pure EABI kernel and
userspace. I'm not concerned about being able to run old binaries.
So is using abi=iwmmxt really not what I want? A
Hi Bernhard,
Please open a gcc bug and assign it to me.
Thanks.
H.J.
---
On Wed, Dec 05, 2007 at 03:02:32PM +0100, Bernhard Fischer wrote:
Hi,
My libc is configured to omit any FP support (UCLIBC_HAS_FLOATS is not set)
but the recent libbid updates seems to unconditionally pull in
From: Daniel Berlin [EMAIL PROTECTED]
Date: Wed, 5 Dec 2007 14:08:41 -0500
So I tried a full history conversion using git-svn of the gcc
repository (IE every trunk revision from 1-HEAD as of yesterday)
The git-svn import was done using repacks every 1000 revisions.
After it finished, I used
On 12/5/07, David Miller [EMAIL PROTECTED] wrote:
From: Daniel Berlin [EMAIL PROTECTED]
Date: Wed, 5 Dec 2007 14:08:41 -0500
So I tried a full history conversion using git-svn of the gcc
repository (IE every trunk revision from 1-HEAD as of yesterday)
The git-svn import was done using
From: Daniel Berlin [EMAIL PROTECTED]
Date: Wed, 5 Dec 2007 21:41:19 -0500
It is true I gave up quickly, but this is mainly because i don't like
to fight with my tools.
I am quite fine with a distributed workflow, I now use 8 or so gcc
branches in mercurial (auto synced from svn) and merge a
On 12/5/07, David Miller [EMAIL PROTECTED] wrote:
From: Daniel Berlin [EMAIL PROTECTED]
Date: Wed, 5 Dec 2007 21:41:19 -0500
It is true I gave up quickly, but this is mainly because i don't like
to fight with my tools.
I am quite fine with a distributed workflow, I now use 8 or so gcc
Michael Meissner wrote:
One of the things that I've been interested in is adding support to GCC to
compile individual functions with specific target options. I first presented a
draft at the Google mini-summit, and then another draft at the GCC developer
summit last July.
...
The proposal is
From: Daniel Berlin [EMAIL PROTECTED]
Date: Wed, 5 Dec 2007 22:47:01 -0500
The size is clearly not just svn data, it's in the git pack itself.
And other users have shown much smaller metadata from a GIT import,
and yes those are including all of the repository history and branches
not just the
I fought with this a few months ago when I did my own clone of gcc svn.
My bad for only discussing this on #git at the time. Should have put
this to the list as well.
If anyone recalls my report was something along the lines of
git gc --aggressive explodes pack size.
git repack -a -d
On Wed, 2007-12-05 at 20:20 -0800, David Miller wrote:
From: Daniel Berlin [EMAIL PROTECTED]
Date: Wed, 5 Dec 2007 22:47:01 -0500
The size is clearly not just svn data, it's in the git pack itself.
And other users have shown much smaller metadata from a GIT import,
and yes those are
On 12/5/07, David Miller [EMAIL PROTECTED] wrote:
From: Daniel Berlin [EMAIL PROTECTED]
Date: Wed, 5 Dec 2007 22:47:01 -0500
The size is clearly not just svn data, it's in the git pack itself.
And other users have shown much smaller metadata from a GIT import,
and yes those are including
From: Daniel Berlin [EMAIL PROTECTED]
Date: Wed, 5 Dec 2007 23:32:52 -0500
On 12/5/07, David Miller [EMAIL PROTECTED] wrote:
From: Daniel Berlin [EMAIL PROTECTED]
Date: Wed, 5 Dec 2007 22:47:01 -0500
The size is clearly not just svn data, it's in the git pack itself.
And other users
On Wed, 5 Dec 2007, Harvey Harrison wrote:
If anyone recalls my report was something along the lines of
git gc --aggressive explodes pack size.
Yes, --aggressive is generally a bad idea. I think we should remove it or
at least fix it. It doesn't do what the name implies, because it
On Wed, 2007-12-05 at 20:54 -0800, Linus Torvalds wrote:
On Wed, 5 Dec 2007, Harvey Harrison wrote:
If anyone recalls my report was something along the lines of
git gc --aggressive explodes pack size.
[ By default, for example, git svn clone/fetch seems to create those
horrible
On 12/5/07, David Miller [EMAIL PROTECTED] wrote:
From: Daniel Berlin [EMAIL PROTECTED]
Date: Wed, 5 Dec 2007 23:32:52 -0500
On 12/5/07, David Miller [EMAIL PROTECTED] wrote:
From: Daniel Berlin [EMAIL PROTECTED]
Date: Wed, 5 Dec 2007 22:47:01 -0500
The size is clearly not just
On Thu, 2007-12-06 at 00:11 -0500, Daniel Berlin wrote:
On 12/5/07, David Miller [EMAIL PROTECTED] wrote:
From: Daniel Berlin [EMAIL PROTECTED]
Date: Wed, 5 Dec 2007 23:32:52 -0500
On 12/5/07, David Miller [EMAIL PROTECTED] wrote:
From: Daniel Berlin [EMAIL PROTECTED]
Date: Wed,
While you won't get the git svn metadata if you clone the infradead
repo, it can be recreated on the fly by git svn if you want to start
commiting directly to gcc svn.
I will give this a try :)
On Thu, 6 Dec 2007, Daniel Berlin wrote:
Actually, it turns out that git-gc --aggressive does this dumb thing
to pack files sometimes regardless of whether you converted from an
SVN repo or not.
Absolutely. git --aggressive is mostly dumb. It's really only useful for
the case of I know I
On 12/6/07, Daniel Berlin [EMAIL PROTECTED] wrote:
While you won't get the git svn metadata if you clone the infradead
repo, it can be recreated on the fly by git svn if you want to start
commiting directly to gcc svn.
I will give this a try :)
Back when I was working on the Mozilla
On Thu, Dec 06, 2007 at 01:47:54AM -0500, Jon Smirl wrote:
The key to converting repositories of this size is RAM. 4GB minimum,
more would be better. git-repack is not multi-threaded. There were a
few attempts at making it multi-threaded but none were too successful.
If I remember right, with
git repack -a -d --depth=250 --window=250
Since I have the whole gcc repo locally I'll give this a shot overnight
just to see what can be done at the extreme end or things.
Harvey
--- Comment #3 from sam at gcc dot gnu dot org 2007-12-05 09:27 ---
This is fixed in SVN trunk
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from sam at gcc dot gnu dot org 2007-12-05 09:25 ---
Subject: Bug 21489
Author: sam
Date: Wed Dec 5 09:25:38 2007
New Revision: 130617
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130617
Log:
gcc/ada/
PR ada/21489
* exp_ch9.adb
package pak1 is
type T1 is interface;
function F1(X: T1) return Integer is abstract;
type T2 is tagged null record;
function F2(X: T2) return Integer;
end pak1;
limited with pak1;
package pak2 is
x1: access pak1.T1'Class;
x2: access pak1.T2'Class;
N1: Integer := x1.F1;
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2007-12-05 10:12
---
We could probably get away with a kludge for -ffloat-store and optimization,
but currently the flag comes into play only very late (in TER) and I think
it's better to keep this.
So I think the approach to
--- Comment #1 from sam at gcc dot gnu dot org 2007-12-05 09:40 ---
GNAT 4.3.0 20071204 (experimental)
Copyright 1992-2007, Free Software Foundation, Inc.
Compiling: pak2.ads (source file time stamp: 2007-12-05 09:33:51)
6. N1: Integer := x1.F1; -- line 5
--- Comment #2 from jakub at gcc dot gnu dot org 2007-12-05 10:45 ---
Subject: Bug 34271
Author: jakub
Date: Wed Dec 5 10:45:21 2007
New Revision: 130619
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130619
Log:
PR c++/34271
* semantics.c (finish_decltype_type):
--- Comment #3 from jakub at gcc dot gnu dot org 2007-12-05 11:15 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
Overview Description:
A very simple TEST.F code using D1MACH.F from SLATEC (to initialize machine
constants) compiles correctly using GFORTRAN, but the produced executable gives
nonsense results.
Steps to Reproduce:
1. Save the following program TEST.F and the routine D1MACH.F
**
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21489
package test1 is
package pak2 is
x1: integer;
end pak2;
type T1 is interface;
type T2 is interface;
procedure p1(x2: T1; x3: integer := pak2.x1) is abstract;
type T3 is new T2 and T1 with null record;
procedure p1(x2: T3; x3: integer := pak2.x1); -- line 13
end
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15804
--- Comment #1 from sam at gcc dot gnu dot org 2007-12-05 12:13 ---
This has already been fixed in trunk.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from sam at gcc dot gnu dot org 2007-12-05 12:22 ---
Already fixed in trunk.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
package Pak1 is
pragma Elaborate_Body;
type T1 is abstract tagged null record;
function F1 (X1: T1) return access Integer is abstract;
end Pak1;
package body Pak1 is
procedure P2 (X2: T1) is
I : Integer;
begin
I := F1(T1'Class(X2)).all; -- line 6
end P2;
end
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32792
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22559
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17318
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-12-05 10:44
---
(In reply to comment #11)
Andrew, IIRC you extended DECL_COMPLEX_GIMPLE_REG_P to DECL_GIMPLE_REG_P, can
vectors be affected by the same issue?
No because vector types are not effected by -ffloat-store and there
--- Comment #143 from jv244 at cam dot ac dot uk 2007-12-05 10:12 ---
CP2K fails again to compile
all.f90:51639.23:
TYPE(cp_error_type), INTENT(inout) :: error
1
Error: Derived type 'cp_error_type' at (1) is being used before it is defined
--
jv244
--- Comment #5 from burnus at gcc dot gnu dot org 2007-12-05 13:42 ---
Subject: Bug 34333
Author: burnus
Date: Wed Dec 5 13:42:32 2007
New Revision: 130623
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130623
Log:
2007-12-05 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #1 from rask at gcc dot gnu dot org 2007-12-05 13:50 ---
*** This bug has been marked as a duplicate of 33777 ***
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from ubizjak at gmail dot com 2007-12-05 13:54 ---
(In reply to comment #8)
Instead, -fPIC should unconditionally decrease the available regparm by 1.
Yes, this seems to be the best solution in the short term.
I'm testing following patch:
Index: i386.c
--- Comment #2 from sam at gcc dot gnu dot org 2007-12-05 12:35 ---
This is already fixed in SVN trunk.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ludovic at ludovic-brenta dot org 2007-12-05 12:28
---
*** Bug 34348 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34347
package pak1 is
pragma elaborate_body;
type T1 is abstract tagged null record;
function f1 (x1: T1) return access integer is abstract;
end pak1;
package body pak1 is
procedure p2 (x2: T1) is
i: integer;
begin
i := f1(T1'class(x2)).all; -- line 6
end p2;
end pak1;
--- Comment #8 from sam at gcc dot gnu dot org 2007-12-05 14:35 ---
Fixed in SVN trunk, thanks for the patch.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rask at gcc dot gnu dot org 2007-12-05 13:50 ---
*** Bug 34349 has been marked as a duplicate of this bug. ***
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from ubizjak at gmail dot com 2007-12-05 16:03 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL|
--- Comment #10 from uros at gcc dot gnu dot org 2007-12-05 16:01 ---
Subject: Bug 34312
Author: uros
Date: Wed Dec 5 16:01:22 2007
New Revision: 130625
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130625
Log:
PR target/34312
* config/i386/i386.c
--- Comment #6 from pault at gcc dot gnu dot org 2007-12-05 15:18 ---
(In reply to comment #5)
*** Bug 34339 has been marked as a duplicate of this bug. ***
OK Thanks all - I'm onto it.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from sam at gcc dot gnu dot org 2007-12-05 14:35 ---
Subject: Bug 34284
Author: sam
Date: Wed Dec 5 14:34:48 2007
New Revision: 130624
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130624
Log:
2007-12-05 Bechir Zalila [EMAIL PROTECTED]
gnattools/
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2007-12-05 17:42
---
2) pa_secondary_reload() requests a secondary scratch register reload for
essentially everything when CLASS is FP_REGS. However, reload is treating
this reload as optional, resulting in spill failures and
--- Comment #5 from janis at gcc dot gnu dot org 2007-12-05 19:02 ---
I was going to do a regression hunt on this, but discovered that it doesn't
fail with current cross compilers for sparc-linux and i686-linux. With
powerpc-linux it fails for 20071120 and passes for 20071130.
--
--- Comment #26 from sam at gcc dot gnu dot org 2007-12-05 18:57 ---
Eric,
what is the status for this PR? Is there some work to do on your patch? Or is
the issue moot?
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from raksit at google dot com 2007-12-05 19:27 ---
For the rtl emitted on x86 processors, the combiner is almost able to optimize
the shift away. It combines and simplifies the 3 instructions down to:
Failed to match this instruction:
(set (reg:SI 64)
(mem/s:SI
--- Comment #16 from dave at hiauly1 dot hia dot nrc dot ca 2007-12-05
19:01 ---
Subject: Re: [4.2/4.3 Regression] ICE in reload_cse_simplify_operands, at
postreload.c:392
You should request a secondary reload when you need one, like on the SPARC.
Currently the only return value of
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-12-05 19:11 ---
extern void free (void *__ptr);
struct shparam
{
char **p;
int foo;
};
static struct shparam shellparam;
inline void freeparam (volatile struct shparam *param, char **ap)
{
free ((void *) (*ap));
free ((void
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-12-05 19:10 ---
The bug is at least masked by
2007-11-21 Richard Guenther [EMAIL PROTECTED]
PR tree-optimization/34148
* tree-ssa-structalias.c (create_variable_info_for): Do not use
field-sensitive PTA
--- Comment #1 from patchapp at dberlin dot org 2007-12-05 18:07 ---
Subject: Bug number PR34342
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00202.html
--
--- Comment #2 from rask at gcc dot gnu dot org 2007-12-05 17:00 ---
And the configure arguments:
--target bfin-unknown-elf --enable-checking=yes,rtl --with-newlib --enable-sim
--disable-gdb --disable-nls --disable-libffi --disable-target-libffi
--disable-boehm-gc
Revision 130561 fails to build libstdc++:
gcc/xgcc -Bgcc/ -S -o /dev/null -O2 -msep-data /tmp/complex_io.cc
/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/msep-data/libstdc++-v3/include/complex:
In function 'std::basic_ostream_CharT, _Traits
std::operator(std::basic_ostream_CharT, _Traits,
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-12-05 19:21 ---
The SMT.39 (for char *) has aliases shellparam, SFT.31 and SFT.32 where
shellparam is the parent var of SFT.31 and SFT.32 -- this is the bug.
I will investigate why this happens.
--
--- Comment #17 from jakub at gcc dot gnu dot org 2007-12-05 19:56 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|REOPENED
--- Comment #27 from ebotcazou at gcc dot gnu dot org 2007-12-05 19:02
---
what is the status for this PR? Is there some work to do on your patch?
Commit it after approval. :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20548
1 - 100 of 148 matches
Mail list logo
