On Sun, 2005-05-08 at 22:54 -0700, Zack Weinberg wrote:
Ralf Corsepius [EMAIL PROTECTED] writes:
On Sun, 2005-05-08 at 21:34 -0700, Zack Weinberg wrote:
Ralf Corsepius [EMAIL PROTECTED] writes:
FWIW: IMO, NO_IMPLICIT_EXTERN_C actually is an OS/libc feature (Your
system headers are
On 5/8/05, Steven Bosscher [EMAIL PROTECTED] wrote:
Hi,
Hello,
I have looked at the GCSE CPROP passes with CSE path following
disabled (-O1 -fgcse --param max-cse-path-length=1). The input
code are the cc1-i files from 20040726 (with checking enabled).
While that discussion flies way above
On Mon, 9 May 2005, Ralf Corsepius wrote:
FWIW: IMO, NO_IMPLICIT_EXTERN_C actually is an OS/libc feature (Your
system headers are c++ aware), therefore it is hardly possible or
useful to ever use #define NO_IMPLICIT_EXTERN_C on generic targets
(*-elf, *-coff etc.).
You could apply that
Original Message
From: Ralf Corsepius
Sent: 09 May 2005 09:27
On Sun, 2005-05-08 at 22:54 -0700, Zack Weinberg wrote:
Ralf Corsepius [EMAIL PROTECTED] writes:
On Sun, 2005-05-08 at 21:34 -0700, Zack Weinberg wrote:
Ralf Corsepius [EMAIL PROTECTED] writes:
FWIW: IMO,
On Sat, 2005-05-07 at 13:58, Andi Kleen wrote:
Tom Tromey [EMAIL PROTECTED] writes:
Splitting up libgcj.so probably makes sense even for the Linux distro
case (the one I am most concerned with at the moment), just so that
apps that don't use AWT or Swing don't really pay for it. The
On Sat, 2005-05-07 at 04:14, Richard Henderson wrote:
On Fri, May 06, 2005 at 01:59:06PM -0700, Steve Ellcey wrote:
I was wondering if anyone could tell me how to write an (empty)
instruction pattern that does a truncate/extend conversion on a register
'in place'.
All the conversions I
Hello,
after setting up the latest snapshot, i was caught off guard as all my
numbers were off (and usually it's better than a swiss clock).
So, i've double checked, stripped some cruft from compiler command
line and pitted various snapshots (20050410, 20050424, 20050501) vs
20050508 in my app.
It appears that GCSE considers read only memory as call clobbered, which
is not the case in CSE. I have took the test for read-only memory from CSE
and add it to GCSE where we compute the transparency. Here is a patch that
does so. This patch makes gcse eliminate redundant loads after stores
On Monday 09 May 2005 03:55, Matt Kraai wrote:
On Sun, May 08, 2005 at 07:31:38PM -0700, Matt Kraai wrote:
On Mon, May 09, 2005 at 03:03:23AM +0100, Paul Brook wrote:
On Monday 09 May 2005 02:26, Matt Kraai wrote:
Howdy,
The rules for c-objc-common.o, loop-unroll.o, and
Hi,
I am porting gcc (version 4.0) to a CPU supporting conditional jumps, which does
not have a CC register. I have combined the comparision and jump operation in
the definition of cbranchsi4 as show at the end of this message.
This works fine on gcc 3.4, however on gcc 4.0 it creates an error
James E Wilson wrote:
William S Fulton wrote:
test.cxx:15: warning: non-local variable unnamed::anonymous enum
unnamed::Instance uses anonymous type
Just grepping the sources for the warning, I find this comment
/* [basic.link]: A name with no linkage (notably, the name of a class
On Mon, 2005-05-09 at 17:45 +0300, Mostafa Hagog wrote:
It appears that GCSE considers read only memory as call clobbered, which
is not the case in CSE. I have took the test for read-only memory from CSE
and add it to GCSE where we compute the transparency. Here is a patch that
does so.
It appears that GCSE considers read only memory as call clobbered, which
is not the case in CSE. I have took the test for read-only memory from CSE
and add it to GCSE where we compute the transparency.
My wild guess is that this was not possible when MEM_READONLY_P was
RTX_UNCHANGING_P, and now
Hi,
As far as I can understand, it's not possible to build gcc 4.0.0 and
gcc 3.4.* using GNU binutils with current release 2.15 of GNU
binutils. One has to use the CVS sources or at least one file.
FYI binutils-2.16 has just been released. You might want to try that.
I have installed
References: 427E8378.1010309 at brenda-arkle dot demon dot co dot
uk873bsxbclc.fsf at codesourcery dot com20050508225133.GA2890 at
dementia dot proulx dot com87r7gh9tmq.fsf at codesourcery dot com
Apologies if this has lost its References field - it shouldn't have
done, but off-hand I can't
On Mon, May 09, 2005 at 12:40:48PM +0100, Richard Earnshaw wrote:
The best way is to have a post-reload splitter that splits the insn
into nothing at all.
Is that really valid? I would have thought it would break the data flow.
Obviously you only split to nothing when the registers match.
On Mon, 2005-05-09 at 17:11, Richard Henderson wrote:
On Mon, May 09, 2005 at 12:40:48PM +0100, Richard Earnshaw wrote:
The best way is to have a post-reload splitter that splits the insn
into nothing at all.
Is that really valid? I would have thought it would break the data flow.
On Mon, May 09, 2005 at 05:45:24PM +0300, Mostafa Hagog wrote:
EXECUTE_IF_SET_IN_BITMAP (blocks_with_calls, 0, bb_index, bi)
{
! if (! MEM_READONLY_P (x))
Looks like you should push this check here:
case MEM:
if (!MEM_READONLY_P (x))
On Mon, May 09, 2005 at 05:26:10PM +0100, Richard Earnshaw wrote:
So do we fully recreate *all* the flow information before a scheduling
pass?
Yes.
r~
i686-pc-linux-gnu
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.0/configure --prefix=/opt/gcc-4.0.0
Thread model: posix
gcc version 4.0.0
Red Hat Enterprise Linux ES release 4 (Nahant)
Linux snoopdog 2.6.9-5.0.3.EL #1 Mon Feb 14 09:52:18 EST 2005 i686 i686 i386
Bernard Leak wrote:
[in reply to why by default an MTA should be installed
in order to be able to send reports in the usual way]
Special system restrictions may make it
impracticable to install the expected tools, but this is really
a red herring.
Hmm...
Installing an MTA, whatever its size may
Georg Bauhaus [EMAIL PROTECTED] writes:
Installing an MTA, whatever its size may be, has the potential
of introducing more work, more open ports, more firewall building,
more following the associated securitiy advisories absent a firewall
or not absent a firewall, more ...
Not at all. All
Bernard Leak [EMAIL PROTECTED] writes:
My system has developed, for hysterical reasons, as a minimal
installation of GNU/Linux on a P4. Minimal really was minimal - no
networking, no X... Everything else has been added on demand. I
managed to get my networking running with no problems
Zack Weinberg wrote:
All modern MTAs can be configured, quite easily, in a
'dumb client' mode where they accept mail only from the local host --
Well, easily is arguable if you aren't a Unix sysadmin, and
depending on the MTA...
There are even programs, such as sSMTP
which, not a month ago had
Zack Weinberg wrote:
The gcc test result script (via Mail) expects the /usr/sbin/sendmail
interface, but not Allman's implementation. You can install whatever
mail transport agent you prefer.
Again, not having an MTA installed indicates a monumental error in the
packaging or installation of
Matthew Woodcraft [EMAIL PROTECTED] writes:
There is at least one serious distribution which has considered having no
/usr/sbin/sendmail (or mailx) in a default installation:
http://lists.ubuntu.com/archives/ubuntu-devel/2005-February/004207.html
What a horrible idea. It's not just about
Mainline bootstrapped fine on 6 May 05. It is broken today with
./xgcc -B./ -B/usr/home/sgk/work/41/amd64-unknown-freebsd6.0/bin/ -isystem
/usr/home/sgk/work/41/amd64-unknown-freebsd6.0/include -isystem
/usr/home/sgk/work/41/amd64-unknown-freebsd6.0/sys-include
Georg Bauhaus [EMAIL PROTECTED] writes:
Good Thing, and improving. However, be sure to add a procedure
to your network monitoring setup to inform you of risky bugs in network
related software. And this is where work starts to be caused by
the assumption that e.g. a GCC shell script can send
Is anybody collecting information on performance regressions in 4.0.0 (vs.
3.4.3)? I've got some results on POVRAY and BYTEmark, and BYTEmark saw some
performance regression, particularly with profiled optimization
(-fprofile-{generate,use}):
Steve Kargl wrote:
Mainline bootstrapped fine on 6 May 05. It is broken today with
./xgcc -B./ -B/usr/home/sgk/work/41/amd64-unknown-freebsd6.0/bin/ -isystem
/usr/home/sgk/work/41/amd64-unknown-freebsd6.0/include -isystem
/usr/home/sgk/work/41/amd64-unknown-freebsd6.0/sys-include
Jason Bucata [EMAIL PROTECTED] wrote:
Is anybody collecting information on performance regressions in 4.0.0
(vs.
3.4.3)? I've got some results on POVRAY and BYTEmark, and BYTEmark
saw some performance regression, particularly with profiled
optimization (-fprofile-{generate,use}):
Kazu Hirata wrote:
Hi,
I have two questions about the C++ front end.
Consider a C++ program
static const int array[] = { 0, 0, 0, 1, 1, 1, 2, 2, 2 };
int
foo (int a)
{
return array[7];
}
I am trying to fold array[7] into 2. It turns out that if T is an
ARRAY_REF,
TREE_READONLY (TREE_OPERAND
Mark Mitchell writes:
Kazu Hirata wrote:
...
static const int array[] = { 0, 0, 0, 1, 1, 1, 2, 2, 2 };
int
foo (int a)
{
return array[7];
}
I am trying to fold array[7] into 2. It turns out that if T is an
ARRAY_REF,
TREE_READONLY (TREE_OPERAND (T, 0))
is 0. Why? This
Paul Schlie wrote:
- ??? no such thing, you can't dynamically initialize a static const,
as then it's not a static const, but rather simply a global const
(as a static const object is logically equivalent to a named/addressable
literal, yes?)
No, it's not.
static const int i = f();
--
Mark
On Mon, May 09, 2005 at 05:03:23PM -0700, Mark Mitchell wrote:
Steve Kargl wrote:
I suspect the problem arose with this commit
2005-05-08 Julian Brown [EMAIL PROTECTED]
H.J. Lu [EMAIL PROTECTED]
Paul Brook [EMAIL PROTECTED]
Probably; so, if you submit
Steve Kargl wrote:
On Mon, May 09, 2005 at 05:03:23PM -0700, Mark Mitchell wrote:
Steve Kargl wrote:
I suspect the problem arose with this commit
2005-05-08 Julian Brown [EMAIL PROTECTED]
H.J. Lu [EMAIL PROTECTED]
Paul Brook [EMAIL PROTECTED]
Probably; so, if you submit
From: Mark Mitchell [EMAIL PROTECTED]
Paul Schlie wrote:
- ??? no such thing, you can't dynamically initialize a static const,
as then it's not a static const, but rather simply a global const
(as a static const object is logically equivalent to a named/addressable
literal, yes?)
From: Paul Schlie [EMAIL PROTECTED]
From: Mark Mitchell [EMAIL PROTECTED]
Paul Schlie wrote:
- ??? no such thing, you can't dynamically initialize a static const,
as then it's not a static const, but rather simply a global const
(as a static const object is logically equivalent to a
Hi Mark,
That's a bug, or, rather, a place where the C++ front-end is failing
to give full information to the optimizer. It should be
TREE_READONLY. There are some tricky bits, in that if we're doing a
dynamic initialization, we presently cannot mark it TREE_READONLY,
but this is a static
The SPASS theorem prover (see below) is miscompiled at -O2 by:
gcc version 3.4.3
gcc version 3.4.4 20050314 (prerelease) (Debian 3.4.3-13)
gcc version 4.0.0 (release)
gcc version 4.1.0 20050509 (experimental)
it is compiled correctly by:
gcc version 3.3.6 (Debian 1:3.3.6-3)
gcc version 3.3.5
--- Additional Comments From duraid at octopus dot com dot au 2005-05-09
06:44 ---
oops, my mistake. this bug appears on x86 too, at least:
gcc version 3.4.4 20050314 (prerelease) (Debian 3.4.3-13)
fails (at -O2), but:
gcc version 3.3.6 (Debian 1:3.3.6-3)
works. Perhaps this is a bug
--- Additional Comments From tsandnes at norway dot atmel dot com
2005-05-09 07:01 ---
Subject: Re: Overflowed address in dwarf debug line information
bjoern dot m dot haase at web dot de wrote:
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-05-06 14:12
--- Additional Comments From trauscher at loytec dot com 2005-05-09 07:04
---
The problem is that -march=xxx -mtune=yyy doesn't work.
The arm_override_option function scans the options
in the order -mtune, -march, -mcpu. So when -mtune is
given, 'arm_tune' first set by -mtune and then
--- Additional Comments From giovannibajo at libero dot it 2005-05-09
07:07 ---
Zack, this is a regression of part of your c-decl stuff. Can you possibly give
it a look? It breaks builds of glibc on primary platforms.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16676
--- Additional Comments From benh at kernel dot crashing dot org
2005-05-09 07:11 ---
Ben Elliston just produced a patch for it that I tested. It fixed building of
glibc on debian powerpc with -g1 (used by debian rules for nptl).
The patch is on it's way to the patch list (which didn't
--- Additional Comments From giovannibajo at libero dot it 2005-05-09
07:25 ---
I analyzed this PR again. The problem seems not related to attribute strong
itself, but rather the way v3 namespaces work. Basically, without debug
support, the failing code looks like:
Consider the following short program:
#include algorithm
void Tst1(short* __restrict__ SrcP, short* __restrict__ MinP, int Len)
{
for (int x=0; xLen; x++)
MinP[x] = SrcP[x] ? MinP[x];
}
void Tst2(short* __restrict__ SrcP, short* __restrict__ MinP, int Len)
{
for (int x=0; xLen;
--- Additional Comments From micis at gmx dot de 2005-05-09 08:24 ---
I cannot reproduce this bug any longer. Maybe the fix for pr20122 also helps
here.
Michael Cieslinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19716
I don't quite know how to characterize this one, so i'll let it up to those in
the know to fix the summary/description.
Primo, AFAIK, gcc has always struggled to get this right but 4.1 is setting a
new record; so i'll qualify that as a regression vs 3.3/3.4.
Secundo, i haven't found any related
--- Additional Comments From tbptbp at gmail dot com 2005-05-09 08:46
---
I'm going to ping this bugreport because there's still some very bad interaction
with gcse in current gcc.
Just compile the 'packet_intersection.cpp' testcase with ie g++-4.1-4120050501
for ia32 to convince
--- Additional Comments From tbptbp at gmail dot com 2005-05-09 08:50
---
I forgot to say that using ternary operators or if/else while changing the
codegen slightly doesn't make much difference.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21463
--- Additional Comments From pcarlini at suse dot de 2005-05-09 09:04
---
- Fully qualify all references to std names from code within namespace
_GLIBCXX_STD (which expands to __gnu_norm in debug mode). This is hard
because
it's impossible to fully check it, and it's pervasive.
--- Additional Comments From pcarlini at suse dot de 2005-05-09 09:16
---
I found something in the archive:
http://gcc.gnu.org/ml/libstdc++/2002-12/msg9.html
That's why we didn't qualify less co... In mainline (vs v7-branch), where we
still don't have anything special for those
input:
== a.c =
#include stdio.h
#include inttypes.h
int main() {
uint64_t pos = 1;
pos = 1;
if (pos 1 || pos 0xULL) {
printf(fail\n);
return 1;
}
printf(ok\n);
return 0;
}
= end of a.c =
command lines:
$ gcc a.c
$
--
What|Removed |Added
OtherBugsDependingO||21418
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21442
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-05-09
10:03 ---
The problem is that, while looking for AbstractInterruptibleChannel (a
superclass of SelectableChannel), we do not look into the imports of
SelectableChannel.
*** This bug has been marked as a duplicate of
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-05-09
10:03 ---
*** Bug 21442 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--
Bug 21418 depends on bug 21442, which changed state.
Bug 21442 Summary: problem with imports and multifile builds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21442
What|Old Value |New Value
Consider the following short function:
void Tst1(float* __restrict__ SrcP, float* __restrict__ DstP, int Len)
{
for (int x=0; xLen; x++)
{
DstP[x] = SrcP[x] * SrcP[x];
}
}
If this function is compiled with:
g++41 -O -S TstPow.cpp
--- Additional Comments From vaclav dot ovsik at i dot cz 2005-05-09 10:47
---
Subject: Re: thread lib posix = runtime gij segfaults on Debian G/L Woody
On Fri, May 06, 2005 at 01:45:49PM -, pinskia at gcc dot gnu dot org wrote:
This sounds like recursive mutexes are not working
The following function is not vectorised while there is a sqrt vector function
available.
#include math.h
void Tst1(float* __restrict__ SrcP, float* __restrict__ DstP, int Len)
{
for (int x=0; xLen; x++)
DstP[x] = sqrt(SrcP[x]);
}
Compiled with
g++41 -O -ffast-math -S
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-09
11:15 ---
Reduced testcase is following. The root of the problem is that when we declare
strings of different length in the same character(len=*) declaration, all
strings are truncated to the length of the first
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-05-09
11:18 ---
Ah! I understand now. Sorry, your initial report wasn't clear. Yes, I agree
this is incorrect.
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-09
11:27 ---
Subject: Bug 19155
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-09 11:21:02
Modified files:
libgfortran/io : unix.c
libgfortran:
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org |org
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-05-09 11:30 ---
Could you please post backtrace of segfault? with both gcc-4.0 and gcc-3.4 if it
is different.
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-09
11:31 ---
Subject: Bug 19155
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-09 11:27:06
Modified files:
gcc/testsuite :
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-09
11:37 ---
I don't close this one since NIST test FM110 is not fixed with this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19155
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-09
11:53 ---
Subject: Bug 21427
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-05-09 11:48:12
Modified files:
gcc/cp :
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-09
11:56 ---
Subject: Bug 21427
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-09 11:52:45
Modified files:
gcc/testsuite : ChangeLog
Added files:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
12:01 ---
Does -fno-strict-aliasing fix the problem?
Also is there any warnings from -Wstrict-aliasing?
If so this might not be a bug in gcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21461
--- Additional Comments From tobi at gcc dot gnu dot org 2005-05-09 12:05
---
Are you going to review that patch, Paul? I don't think anybody else is
qualified.
--
What|Removed |Added
--- Additional Comments From tobi at gcc dot gnu dot org 2005-05-09 12:06
---
I don't think so. Several people have used it, and noone complained about weird
things happening.
--
What|Removed |Added
--- Additional Comments From giovannibajo at libero dot it 2005-05-09
12:18 ---
There are others unqualified names as default template parmaters, for
instance allocator. A good testcase would be something like:
--
struct less;
struct allocator;
struct
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
12:20 ---
Closing as works for me.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From duraid at octopus dot com dot au 2005-05-09
12:20 ---
(In reply to comment #3)
Does -fno-strict-aliasing fix the problem?
Yes, oops.
Also is there any warnings from -Wstrict-aliasing?
No.
If so this might not be a bug in gcc.
Indeed. Sorry!
--
--- Additional Comments From nathan at gcc dot gnu dot org 2005-05-09
12:21 ---
2005-05-08 Nathan Sidwell [EMAIL PROTECTED]
PR c++/21427
Backport 2005-03-01 Nathan Sidwell [EMAIL PROTECTED]
* class.c (update_vtable_entry_for_fn): Don't crash on invalid
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
12:21 ---
Confirmed.
--
What|Removed |Added
Severity|normal
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
12:21 ---
Confirmed.
--
What|Removed |Added
Severity|normal |minor
--- Additional Comments From duraid at octopus dot com dot au 2005-05-09
12:24 ---
Actually, I shouldn't have closed this so hastily. The code _is_ pretty dirty
but I'm not sure GCC is really doing something legal at -O2.
--
What|Removed |Added
--- Additional Comments From pcarlini at suse dot de 2005-05-09 12:29
---
I see, thanks. Indeed, I don't remember having paid attention to default
template
arguments. Let's wait a bit for Gaby's opinion on the whole issue, and, in case,
let's quickly fix those problems.
--
The following code makes g++ 3.4.4 and g++ 3.3.6 (Debian) crash on my system.
Adding the missing default argument for arg1 fixes the crash
templatetypename F
void test(F function, bool arg0 = false, bool arg1)
{
}
int main()
{
test(main);
}
Detailed G++ versions:
g++-3.3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
12:53 ---
Confirmed and not a regression.
Here is the backtrace:
#0 convert_default_arg (type=0xb7bf9804, arg=0x0, fn=0xb7c8c948, parmnum=2)
at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/cp/call.c:4513
#1
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-09
13:00 ---
Looking into it for AdaCore.
--
What|Removed |Added
AssignedTo|unassigned at gcc
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-05-09 13:23 ---
yes, please do not close this bug as i can reproduce it even with
-fno-strict-aliasing, but it seems it breaks at least in four files
(dfgparser.c, list.c, sharing.c, subst.c) so it could take
--- Additional Comments From tobi at gcc dot gnu dot org 2005-05-09 13:40
---
What is wrong is this from the .t02.original dump:
create (temp_ptr, _temp_ptr)
{
char[1:15] * new_item;
{
void * * ptr.0;
ptr.0 = (void * *) new_item;
_gfortran_allocate (ptr.0, 15, 0);
}
--- Additional Comments From duraid at octopus dot com dot au 2005-05-09
13:41 ---
Building on ia64 with the 3.4.4 compiler mentioned above, I get:
#0 red_ReduceInput (Search=0x600ac338, ClauseList=0x60112e18)
at clause.h:525
#1 0x4010dd90 in
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-09
13:41 ---
Subject: Bug 19285
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-09 13:32:30
Modified files:
libjava:
--- Additional Comments From rth at gcc dot gnu dot org 2005-05-09 13:44
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From rth at gcc dot gnu dot org 2005-05-09 13:46
---
Powerpc fixed; ia64 still broken.
--
What|Removed |Added
Summary|[PowerPC] ICE
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-09
13:48 ---
Subject: Bug 19285
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-09 13:34:33
Modified files:
libjava/java/lang:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-09
13:54 ---
Subject: Bug 21285
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-09 13:39:35
Modified files:
libffi :
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-09
13:55 ---
Subject: Bug 21285
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-05-09 13:40:16
Modified files:
libffi :
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-05-09
13:58 ---
This is a call clobbering bug.
We don't pass the address of c to the call, we pass the address of some
substructure.
As a result, we don't think foo can touch c.b, when it can beause of the upcast.
Whee.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-09
14:00 ---
Subject: Bug 19285
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-09 13:50:01
Modified files:
gcc/java :
--- Additional Comments From giovannibajo at libero dot it 2005-05-09
14:03 ---
The real bug is this accepts-invalid:
templatetypename F
void test(F function, bool arg0 = false, bool arg1)
{}
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-05-09
14:04 ---
This is, of course, a regression from 3.4.x
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-09
14:20 ---
Subject: Bug 21397
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-09 14:15:51
Modified files:
gcc: ChangeLog
gcc/config/arm :
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
14:22 ---
*** This bug has been marked as a duplicate of 16829 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
14:22 ---
*** Bug 21467 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
1 - 100 of 218 matches
Mail list logo
