--- Comment #9 from jblomqvi at cc dot hut dot fi 2005-10-11 06:11 ---
Updated patch here: http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00572.html
--
jblomqvi at cc dot hut dot fi changed:
What|Removed |Added
--- Comment #17 from cvs-commit at gcc dot gnu dot org 2005-10-11 06:19
---
Subject: Bug 13583
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-11 06:19:13
Modified files:
libstdc++-v3 : ChangeLog configure configure.ac
--- Comment #6 from cvs-commit at gcc dot gnu dot org 2005-10-11 06:20
---
Subject: Bug 24302
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]2005-10-11 06:19:56
Modified files:
gcc: toplev.c
gcc/cp : ChangeLog
--- Comment #7 from cvs-commit at gcc dot gnu dot org 2005-10-11 06:20
---
Subject: Bug 24302
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]2005-10-11 06:20:35
Modified files:
gcc: toplev.c
--- Comment #9 from wilson at specifix dot com 2005-10-11 06:20 ---
Or maybe I will look at it later tonight.
The problem seems to be that we have no code that will make a jump insn
dependent on the previous jump insn when we are scheduling a region that
contains multiple basic blocks.
--- Comment #8 from cvs-commit at gcc dot gnu dot org 2005-10-11 06:22
---
Subject: Bug 24302
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]2005-10-11 06:22:09
Modified files:
gcc: ChangeLog
Log
--- Comment #18 from cvs-commit at gcc dot gnu dot org 2005-10-11 06:22
---
Subject: Bug 13583
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-10-11 06:22:08
Modified files:
libstdc++-v3 : ChangeLog
--- Comment #5 from cvs-commit at gcc dot gnu dot org 2005-10-11 06:25
---
Subject: Bug 24277
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]2005-10-11 06:25:50
Modified files:
gcc/cp : pt.c ChangeLog
--- Comment #6 from cvs-commit at gcc dot gnu dot org 2005-10-11 06:26
---
Subject: Bug 24277
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]2005-10-11 06:26:04
Modified files:
gcc/cp : pt.c
gcc/testsuite : ChangeLog
Added
--- Comment #10 from wilson at specifix dot com 2005-10-11 06:26 ---
Created an attachment (id=9960)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9960action=view)
trivial hack to make the reduced testcase work
Actually, come to think of it, other targets don't use schedule_ebbs
--- Comment #19 from ian at airs dot com 2005-10-11 06:28 ---
Fixed on mainline and 4.0 branch. Will not fix on 3.4.
--
ian at airs dot com changed:
What|Removed |Added
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-10-11 06:28
---
Fixed in 4.0.3.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-10-11 06:30
---
Fixed in 4.0.3.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from phython at gcc dot gnu dot org 2005-10-11 06:36
---
Created an attachment (id=9961)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9961action=view)
vrp workaround
There seems to be a combination of front-end and middle-end bugs that cause
this. The attached
--- Comment #10 from phython at gcc dot gnu dot org 2005-10-11 06:41
---
Created an attachment (id=9962)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9962action=view)
treat nonmember static functions like inline functions
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17256
--- Comment #4 from uros at kss-loka dot si 2005-10-11 06:41 ---
From _.c.10.gcse1:
STORE_MOTION delete insn in BB 0:
(insn 17 15 47 0 (parallel [
(set (mem/s:SI (reg/v/f:SI 59 [ s ]) [3
variable.buf+0 S4 A32])
(ashift:SI
--- Comment #11 from phython at gcc dot gnu dot org 2005-10-11 06:42
---
Created an attachment (id=9963)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9963action=view)
testcase
This patch also changes the error in:
static void f();
void g() { f(); }
into a warning.
--
--- Comment #3 from mmitchel at gcc dot gnu dot org 2005-10-11 06:49
---
The semantics of #pragma interface are not entirely well-specified in this
case. However, the documentation does suggest that you use an explicit
subdirectory when you have multiple headers with the same name in
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #2 from belyshev at depni dot sinp dot msu dot ru 2005-10-11
07:30 ---
*** This bug has been marked as a duplicate of 20003 ***
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed |Added
--- Comment #4 from belyshev at depni dot sinp dot msu dot ru 2005-10-11
07:30 ---
*** Bug 23069 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20003
--- Comment #29 from dannysmith at users dot sourceforge dot net
2005-10-11 08:01 ---
Updated patch here.
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00565.html
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21766
--- Comment #5 from uros at kss-loka dot si 2005-10-11 08:55 ---
(In reply to comment #4)
gcse-sm blindly converted valid insn pattern into unrecognized insn pattern.
The problem is in gcse.c, function replace_store_insn(), line 6294:
6293 mem = smexpr-pattern;
6294 insn =
--- Comment #3 from mick at nag dot co dot uk 2005-10-11 09:26 ---
Thanks - the problem is now fixed in 64-bit compilations. However, if I compile
try.f and sub.c with the -m32 flag, I still get memory allocated on 8-byte
boundaries rather than 16-byte. As Andrew said, this is down to
--- Comment #4 from pcarlini at suse dot de 2005-10-11 09:55 ---
The problem is confirmed, should be fixable.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2005-10-11 10:42
---
Really interesting: it's a combination of TARGET_PTRMEMFUNC_VBIT_LOCATION,
inlining, efficient stack slot allocation and delay slot scheduling!
SPARC doesn't define TARGET_PTRMEMFUNC_VBIT_LOCATION so the
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2005-10-11 10:54
---
The only approach to fixing this I can think of is to modify the selection
logic of TARGET_PTRMEMFUNC_VBIT_LOCATION: if the target has strict alignment
and delay slots, the macro should be set to
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-11 11:19 ---
This is really a glibc bug and needs to be fixed. The C standard says that
malloc allocates that the right alignment so this is a glibc bug.
--
pinskia at gcc dot gnu dot org changed:
What
Hi,
compiling linux-2.6.13.4 (vanilla) on my PC (linux-2.6.13.1, gcc-3.3.6,
glibc-2.3.5).
Problem (make):
...
LD drivers/scsi/qla2xxx/built-in.o
CC drivers/serial/serial_core.o
*** glibc detected *** double free or corruption (!prev): 0x084dd188 ***
drivers/serial/serial_core.c: In
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-11 11:25 ---
*** This bug has been marked as a duplicate of 16676 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from pinskia at gcc dot gnu dot org 2005-10-11 11:25
---
*** Bug 24304 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-11 11:26 ---
Can you attach the preprocessed source?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from bonzini at gcc dot gnu dot org 2005-10-11 11:38
---
This is as small as I could make it. Any other attempt to hoist something
causes it not to fail anymore (at -maltivec -O2). Interesting, given that GCSE
*does* the hoisting...
It's a reload problem.
typedef
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-10-11 11:48 ---
This is now fixed by preventing to build with the HP's as.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
va_arg seems to mess up the va_list when variadic variables have size 0, but
when have large alignment requirements. When the alignment is small, this
seems to work by chance.
$ gcc foo.c -o foo ./foo
3 0
#include stdarg.h
#include stdio.h
typedef int __attribute__ ((vector_size (16))) foo_t;
--- Comment #2 from dvilleneuve at kronos dot com 2005-10-11 12:28 ---
Indeed, in gcc-4.0.1, the previous code chunk does not elicit a warning.
However, a slightly modified version still gets a warning (tested
on RHEL-4, with gcc version 4.0.1 20050727 (Red Hat 4.0.1-4.EL4.2)).
c-code
--- Comment #2 from mconstant at hancocklumber dot com 2005-10-11 12:33
---
I actually solved the problem. I had to just reinstall the kernel-headers and
kernel-modules off of the slackware discs again and it works now. The files
that were giving errors were corrupted somehow. I tried
--- Comment #3 from tobi at gcc dot gnu dot org 2005-10-11 13:25 ---
(In reply to comment #2)
In case anybody wants to work on this, I have an old unfinished patch lying
around that adds builtins and RTL codes for byteswap operation. This allows
to use platform specific tricks that
/space/rguenther/obj/gcc-libgfortran/gcc/f951
/space/rguenther/src/gcc-libgfortran/gcc/testsuite/gfortran.fortran-torture/execute/character_select_1.f90
-quiet -dumpbase character_select_1.f90 -mtune=pentiumpro -auxbase
character_select_1 -O0 -w -version -fprofile-generate -o character_select_1.s
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-11 13:28 ---
Closing as invalid for now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
=i686-pc-linux-gnu --enable-__cxa_atexit
--enable-languages=c++,objc,java,f95 --prefix=/home/gates/pinskia/linux
--enable-threads=posix --enable-shared
Thread model: posix
gcc version 4.1.0 20051011 (experimental)
/home/gates/pinskia/linux/libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1 -quiet -v
t.c -quiet
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
--- Comment #7 from giovannibajo at libero dot it 2005-10-11 13:43 ---
Yes, I think the problem is in delay slot scheduling too. COND_EXPR means that
either branch must not be evaluated because it could be illegal; if you hoist a
mem from a branch into the delay slot of the condition,
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-11 13:44 ---
Confirmed, here is a C testcase:
struct a
{
void *l;
char *k;
};
void *f(struct a*, int len, char*);
void fgg(void)
{
void * gotovar;
struct a jmp[] = {{L1, }, {L2, EEE}, {L3, T}};
gotovar = f(jmp, 3,
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2005-10-11 13:51
---
Yes, I think the problem is in delay slot scheduling too. COND_EXPR means that
either branch must not be evaluated because it could be illegal; if you hoist
a
mem from a branch into the delay slot of the
On Oct 11, 2005, at 9:51 AM, ebotcazou at gcc dot gnu dot org wrote:
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2005-10-11
13:51 ---
Yes, I think the problem is in delay slot scheduling too. COND_EXPR
means that
either branch must not be evaluated because it could be
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-10-11 13:55 ---
Subject: Re: [4.0 regression] mem_fun* code fine with -O1, bus error with -O2
On Oct 11, 2005, at 9:51 AM, ebotcazou at gcc dot gnu dot org wrote:
--- Comment #8 from ebotcazou at gcc dot gnu dot org
../../obj34/gcc/cc1plus -w -quiet -o /dev/null pr24278.min1.ii
Killed
Program received signal SIGINT, Interrupt.
0x006cd5c7 in classify_argument (mode=QImode, type=0x2a95a058f0,
classes=0x7fbfffe050, bit_offset=0) at i386.c:2054
2054 if (TREE_CODE (field) == FIELD_DECL)
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-10-11 13:58 ---
Created an attachment (id=9964)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9964action=view)
testcase
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24308
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2005-10-11 13:59
---
may_trap_p is the correct thing as it should detect this instruction as
trapping:
/* Memory ref can trap unless it's a static var or a stack slot. */
case MEM:
if (MEM_NOTRAP_P (x))
--- Comment #2 from bje at gcc dot gnu dot org 2005-10-11 14:02 ---
gcc version 4.1.0 20051010 (experimental)
I managed to work out that you need to add -msse to trigger the bug.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22509
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-10-11 14:06
---
I am changing the target milestone back to 4.1 as this is most likely fortran
specific, just nobody has found a C/C++ testcase for this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22509
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-10-11 14:07
---
(In reply to comment #10)
I am changing the target milestone back to 4.1 as this is most likely fortran
specific, just nobody has found a C/C++ testcase for this bug.
I mean this is most likely ___NOT___
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-11 14:09 ---
Confirmed, a regression from 3.3.3.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-11 14:10 ---
Works for me with 3.4.0, 4.0.0, and 4.1.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The example (attached below), when compiled by following gcc
---
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../../gcc-CVS-20051011/gcc-CVS-20051011/configure
--host=i686-pc-linux-gnu --prefix=/usr/local/opt/gcc-4.1
--exec-prefix=/usr/local/opt/gcc
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-11 14:11 ---
(In reply to comment #2)
Works for me with 3.4.0, 4.0.0, and 4.1.0.
Except that was 32bit.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from drab at kepler dot fjfi dot cvut dot cz 2005-10-11
14:11 ---
Created an attachment (id=9965)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9965action=view)
Triggers the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24309
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #11 from mark at codesourcery dot com 2005-10-11 14:22 ---
Subject: Re: [4.0 regression] mem_fun* code fine
with -O1, bus error with -O2
ebotcazou at gcc dot gnu dot org wrote:
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2005-10-11 13:59
---
--- Comment #4 from dberlin at gcc dot gnu dot org 2005-10-11 14:25 ---
Subject: Bug 4
Author: dberlin
Date: Tue Oct 11 14:15:11 2005
New Revision: 83801
URL: http://gcc.gnu.org/viewcvs?root=gccrepoview=revrev=83801
Log:
Fixing bug 4
Modified:
--- Comment #17 from h dot m dot brand at xs4all dot nl 2005-10-11 14:37
---
Subject: Re: gcc-4.x fails to build on AIX 5.2.0.0-ML04
On 6 Oct 2005 17:24:10 -, dje at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
Now that all seems to be in more or less working order, and
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2005-10-11 14:41
---
This certainly is a bug in the back-end, not a bug in the default
location of the v-bit. You shouldn't need to break the C++ ABI on SPARC
to fix this bug.
Right, I was confused, I thought __pfn was
--- Comment #4 from rguenth at gcc dot gnu dot org 2005-10-11 14:41 ---
It looks like only checking-enabled 3.4.5 allocates memory until it get's
killed
by the kernel. A checking-disabled 3.4.5 build just endlessly loops (in the
same place).
--
--- Comment #5 from rguenth at gcc dot gnu dot org 2005-10-11 14:45 ---
Also fails with 3.3.3 (SuSE Linux) - which is really hammer-branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24308
--- Comment #13 from mark at codesourcery dot com 2005-10-11 14:47 ---
Subject: Re: [4.0 regression] mem_fun* code fine
with -O1, bus error with -O2
ebotcazou at gcc dot gnu dot org wrote:
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2005-10-11 14:41
---
This
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-11 14:48 ---
Confirmed, reduced testcase:
float weight[10];
void lsp_weight_quant(float *x, char *cdbk)
{
int i,j;
float dist;
int best_id=0;
for (i=0;i16;i++)
{
for (j=0;j10;j++)
--- Comment #18 from h dot m dot brand at xs4all dot nl 2005-10-11 14:52
---
Subject: Re: gcc-4.x fails to build on AIX 5.2.0.0-ML04
On 11 Oct 2005 14:37:31 -, h dot m dot brand at xs4all dot nl
[EMAIL PROTECTED] wrote:
Ignore the AIX 4.3 question: I've raised the limits to
--- Comment #6 from rguenth at gcc dot gnu dot org 2005-10-11 14:55 ---
Oh, and make it hang-on-valid by adding a closing brace at EOF. Also fails
with
unpatched FSF 3.3.6, so not a regression. So WONTFIX probably, unless latent
somehow.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #3 from drab at kepler dot fjfi dot cvut dot cz 2005-10-11
14:56 ---
(In reply to comment #2)
--
but this is just a latent bug as the above also ICEs in 4.0.0.
Related to PR 23820.
No! Both the reduced and my original testcase work for me on 4.0.x.
At least on this
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-11 14:58 ---
(In reply to comment #3)
No! Both the reduced and my original testcase work for me on 4.0.x.
At least on this one:
That is with checking disabled so ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24309
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-10-11 15:03 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from cvs-commit at gcc dot gnu dot org 2005-10-11 15:11
---
Subject: Bug 23946
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-11 15:11:02
Modified files:
gcc: ChangeLog tree-ssa-ccp.c
--- Comment #5 from drab at kepler dot fjfi dot cvut dot cz 2005-10-11
15:24 ---
(In reply to comment #4)
That is with checking disabled so ...
Yes. That's right.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24309
--- Comment #6 from dberlin at gcc dot gnu dot org 2005-10-11 15:27 ---
Subject: Re: [4.1 Regression] ICE with -O3
-ftree-loop-linear
On Tue, 2005-10-11 at 15:24 +, drab at kepler dot fjfi dot cvut dot
cz wrote:
--- Comment #5 from drab at kepler dot fjfi dot cvut
Due to a design-mistake in the cxx_printable_name print ring buffer, we print
out freed strings at ipa-inline.c:cgraph_decide_inlining_of_small_functions
fprintf (dump_file,
\nConsidering %s with %i insns to be inlined into %s\n
Estimated growth
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-10-11 15:38 ---
Patch was posted. Problem is latent since at least old-gcc.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-10-11 15:40 ---
Created an attachment (id=9966)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9966action=view)
testcase (unincluded)
Testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24310
--- Comment #11 from bonzini at gcc dot gnu dot org 2005-10-11 15:41
---
Created an attachment (id=9967)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9967action=view)
reduced testcase
reduced testcase, but with uninitialized variables. top of tree:
2005-09-29 Paolo Bonzini
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-10-11 15:42 ---
The patch causes diffs like the following in the ipa-inline-dump:
-Considering int GuardLayersDim::lower(int) const [with int Dim = 2] with 0
in
sns to be inlined into int UniformGridPartitionDim::partition(const
--- Comment #6 from janis at gcc dot gnu dot org 2005-10-11 16:22 ---
I forgot to add the PR information to the ChangeLog entry at first, but this
is fixed in 3.4.5 by http://gcc.gnu.org/ml/gcc-cvs/2005-10/msg00274.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18583
From the Meissner example Window (Ising model), this line
print '( , I6, 64 A1)', L**3, Merge (+, -, Ising(: 4, : 4, : 4) == 1)
causes
meissner10.f90: In function MAIN__:
meissner10.f90:18: internal compiler error: in gfc_conv_expr_descriptor, at
fortran/trans-array.c:3815
The ICE is due to
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2005-10-11 16:24
---
Ah. I think that would best be fixed in the front-end, then. If the
class doesn't have a virtual pointer, then there's no need to generate
the conditional expression; avoiding that will not only fix this
--
bonzini at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gcc dot gnu dot
|dot org
--- Comment #6 from bonzini at gcc dot gnu dot org 2005-10-11 16:30 ---
Can somebody with a failing system remove all @'s from the toplevel Makefile
and send me the log that results?
That is,
sed -i 's/^\t@/\t' Makefile
make whatever-you-were-invoking
Paolo
--
--- Comment #3 from janis at gcc dot gnu dot org 2005-10-11 16:32 ---
This is from Steve Ellcey's change on 2005-10-07, which I approved. I'll
take a look.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from cvs-commit at gcc dot gnu dot org 2005-10-11 16:38
---
Subject: Bug 21369
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]2005-10-11 16:38:00
Modified files:
gcc/cp : parser.c
--- Comment #6 from cvs-commit at gcc dot gnu dot org 2005-10-11 16:38
---
Subject: Bug 21369
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]2005-10-11 16:38:52
Modified files:
gcc/cp : parser.c ChangeLog
gcc/testsuite :
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-10-11 16:41
---
Fixed in 4.0.3.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-11 16:45 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #18 from mmitchel at gcc dot gnu dot org 2005-10-11 16:49
---
The optimization question in Comment #11 was answered incorrectly.
The C++ standard in fact requires that Y be initialized before the constructor
is run; see [basic.start.init].
--
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janis at gcc dot gnu dot org
|dot org
--- Comment #19 from sabre at nondot dot org 2005-10-11 16:58 ---
To clarify: you are saying that the response in comment #12 is wrong?
-Chris
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
--- Comment #20 from mark at codesourcery dot com 2005-10-11 17:00 ---
Subject: Re: [4.0/4.1 Regression] C++ front-end does not inline
the static const double
sabre at nondot dot org wrote:
--- Comment #19 from sabre at nondot dot org 2005-10-11 16:58 ---
To clarify: you
--- Comment #21 from sabre at nondot dot org 2005-10-11 17:03 ---
required optimization doesn't make sense to me. To put it more clearly, do
you agree that this:
In particular, I think the C++ standard specifies that memory is zero
initialized and then ctors (within a translation
--- Comment #4 from cvs-commit at gcc dot gnu dot org 2005-10-11 17:04
---
Subject: Bug 24281
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-11 17:04:45
Modified files:
gcc/testsuite : ChangeLog
--- Comment #22 from mark at codesourcery dot com 2005-10-11 17:05 ---
Subject: Re: [4.0/4.1 Regression] C++ front-end does not inline
the static const double
sabre at nondot dot org wrote:
--- Comment #21 from sabre at nondot dot org 2005-10-11 17:03 ---
required
1 - 100 of 227 matches
Mail list logo
