--- Comment #9 from bonzini at gcc dot gnu dot org 2005-10-07 07:19 ---
I'm looking at it.
--
bonzini at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from bonzini at gcc dot gnu dot org 2005-10-07 07:21 ---
Created an attachment (id=9916)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9916&action=view)
another patch
Similar to the previous patch, but also prints && correctly for ADDR_EXPR of a
LABEL_DECL.
--
b
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2005-10-07 07:30
---
Thomas, perhaps we could divide and conquer. We could manually eliminate each
of the 204 optimzations one at a time until the breakage disappears. Maybe we
develop a script to locate those, bubblestrap, test, re
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
Hi!
As discussed on the mailing list (
http://gcc.gnu.org/ml/java/2005-10/msg00025.html ), there is a segmentation
fault problem using org.w3c.dom.* packages.
Verified on debian SID (me, gcj version 4.0.2) and on FC3 (David Daney, CVS
head) using the small test program what was wirtten to demonst
--- Comment #1 from khiraly123 at gmx dot net 2005-10-07 08:36 ---
Created an attachment (id=9917)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9917&action=view)
Testcase, java source file
Exactly the same file, what is available on:
http://khiraly.4242.hu/tmp/saxsux/SaxSux.java
--- Comment #2 from khiraly123 at gmx dot net 2005-10-07 08:37 ---
Created an attachment (id=9918)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9918&action=view)
XML file, what the java program use
Exactly the same file, what is available on:
http://khiraly.4242.hu/tmp/saxsux/con
--- Comment #10 from rguenth at gcc dot gnu dot org 2005-10-07 09:05
---
Honza, I'm stuck with rth's comment that there may be still sharing bugs even
after making fold_indirect_ref_1 fold the offending statement. And as you
noted,
calling copy_body_r on the folded or unfolded tree cau
--- Comment #48 from cvs-commit at gcc dot gnu dot org 2005-10-07 10:54
---
Subject: Bug 15855
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-10-07 10:54:10
Modified files:
gcc/cp : ChangeLog decl2
--- Comment #2 from jkj at sco dot com 2005-10-07 10:57 ---
(In reply to comment #1)
> Because bar is not static to the TU, we can override it in a different one
> which causes use not to
> optimizate it out, try adding static infront of bar, baz, and larger.
>
> So this is a testcase
// gcc 3.4.5 and 4.0.2 produce warning output
#define STATIC
// no warning
#define STATIC static
STATIC int foo(void)
{
int i = 47;
i++;
}
int bar(void)
{
if (foo()) return 1;
return 0;
}
--
Summary: Missing "warning: control reaches end of non-void
fun
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-07 11:12 ---
Fixed in 4.1.0 by change a lot of the middle-end so the patch will not be
backported, so closing as fixed. There is most likely a dup of this bug
somewhere.
--
pinskia at gcc dot gnu dot org changed:
when declaring an empty struct like
struct {};
there should be a parse error when compiling with -std=c99, since there seem to
be no grammar rule in the c-standard[1] which allows the empty curled braces in
a struct declaration.
visual studio 2003 and the edg parser report this as a parse error.
[
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-07 11:16 ---
Using -std=c99 -pedantic-errors:
earth:~>gcc t.c -std=c99 -pedantic-errors
t.c:1: error: struct has no members
t.c:1: error: unnamed struct/union that defines no instances
earth:~>~/ia32_linux_gcc3_4/bin/gcc t.c -std
--- Comment #49 from rguenth at gcc dot gnu dot org 2005-10-07 11:17
---
So trying to get some updated comparison I noticed that the testcase fails to
compile with 3.3.x and compared to 3.4.x we have improved a lot wrt -O2
compile-time:
3.4: 1m32s, peak at 230MB
4.1:48s, peak at
when declaring an empty struct like
struct {};
there should be a parse error when compiling with -std=c99, since there seem to
be no grammar rule in the c-standard[1] which allows the empty curled braces in
a struct declaration.
visual studio 2003 and the edg parser report this as a parse error.
[
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-07 11:28 ---
*** Bug 24254 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24253
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-07 11:28 ---
*** This bug has been marked as a duplicate of 24253 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
Instead of passing the pointer to the variable itself a pointer to a temporary
holding the address of the variable is used.
$ cat wait.c
typedef union
{
union wait *__uptr;
int *__iptr;
} __WAIT_STATUS __attribute__ ((__transparent_union__));
union wait
{
int w_status;
};
int wait (__WAIT_ST
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-07 11:45 ---
Hmm, unions are passed by reference in powerpc-linux, unless that is also an
ABI regression too.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-07 12:06 ---
Confirmed, this is a ABI regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from ptsekov at gmx dot net 2005-10-07 12:13 ---
Both the simple testcase and the program I am working on work fine with your
patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196
--- Comment #6 from rguenth at gcc dot gnu dot org 2005-10-07 12:45 ---
In fold_binary (fold-const.c:7122) we fold
op0 == (x, op1)
to
(x, op0 == op1)
but in creation of the new EQ_EXPR we use trees which have NOPs
stripped, so we end up with a pointer and an integer type for the
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-07 13:05 ---
Debugging this, it looks a middle-end bug, in that we get the wrong type.
The type which we get now:
Breakpoint 5, function_arg (cum=0xb020, mode=SImode, type=0x1c97900,
named=1) at ../../gcc/config/rs6000/rs600
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-07 13:08 ---
Caused by:
2005-09-24 Richard Henderson <[EMAIL PROTECTED]>
...
* gimplify.c (create_tmp_from_val): Likewise.
Confirmed caused by that patch by reverting it.
--
pinskia at gcc dot gnu dot org
--- Comment #10 from stewart at neuron dot com 2005-10-07 13:49 ---
(In reply to comment #9)
> Yes, I'm sure. I know what's going on here.
>
This is the only bug I was able to find regarding AttachCurrentThread. I'm
working on getting FUSE-J (Java bindings for FUSE userspace filesyste
--- Comment #9 from segalemb at usp dot br 2005-10-07 13:57 ---
(In reply to comment #8)
I tried this simple test case:
module param
double precision mutdefc(8,5,7)
data mutdefc(1,1,1) /0.d0/
* mutdefc(1,1,2) /0.d0/
end module param
and the c
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-07 14:00 ---
The one liner which fixes the problem (I am bootstrapping right now):
Index: tree-ssa-ccp.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-ssa-ccp.c,v
retrieving r
--- Comment #34 from steven at gcc dot gnu dot org 2005-10-07 14:09 ---
This is basically unfixable without serious hacking that is not appropriate for
GCC 3.4, so Gaby, with your permission, I'd like to close this one as
WONTFIX...
--
steven at gcc dot gnu dot org changed:
--- Comment #4 from czimman at bloomberg dot com 2005-10-07 14:53 ---
Created an attachment (id=9927)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9927&action=view)
mmcsd.s
What happens is that a bogus label (.L622) gets created, and is treated as an
unresolved symbol at link tim
/tmp/gcc41/libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1 -quiet -v icefoo.c -dumpbase
icefoo.c -auxbase icefoo -O -version -fgcse -fgcse-sm -o icefoo.s
GNU C version 4.1.0 20051007 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.1.0 20051007 (experimental).
GGC heuristics
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-07 15:21 ---
Confirmed, 4.0.0 worked.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
It would often be convenient to see what libgcj is doing with
shared libraries -- which get loaded, which don't, and why.
We should add a gij flag like '-Xverbose:libraries' to do this.
--
Summary: add flag to track shared library activity
Product: gcc
Version: 4
--- Comment #5 from rearnsha at gcc dot gnu dot org 2005-10-07 15:51
---
Yes we need the preprocessed source code. Unless I can run the compiler under
a debugger there's no chance of working out what's going wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23980
--- Comment #6 from czimman at bloomberg dot com 2005-10-07 15:54 ---
Created an attachment (id=9928)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9928&action=view)
mmcsd.i
This is the pre-processed output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23980
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last reconf
GCC 4.0.0 / 4.0.2 seems to ignore the stdcall (and also fastcall)
attributes when used at static member template functions.
The generated code for the function is incorrect.
Also when taking the address of that function, the type is a pointer to
a "normal" function and not a pointer to a stdcall
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|c++ |target
http:
When running gfortran on a 64-bit AMD Athlon64 Linux machine, the
Fortran ALLOCATE statement does not align pointers on 16-byte boundaries.
This means that allocated memory cannot be passed to assembly language
routines that rely on 16-byte alignment (e.g. assembly language using
SSE instructions l
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-07 16:55 ---
Confirmed, a C++ bug with templates and attributes. a regression from 3.4.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-07 17:05 ---
Fixed by:
2005-10-01 Jakub Jelinek <[EMAIL PROTECTED]>
* runtime/memory.c (malloc_t): Remove.
(GFC_MALLOC_MAGIC, HEADER_SIZE, DATA_POINTER, DATA_HEADER): Remove.
(mem_root, runtime_cleanup,
--- Comment #14 from pcarlini at suse dot de 2005-10-07 17:05 ---
(In reply to comment #13)
> Both the simple testcase and the program I am working on work fine with your
> patch.
Thanks. Actually, I have to think a bit more about the idea. I'm not sure that
there are binary compatibili
--- Comment #7 from rearnsha at gcc dot gnu dot org 2005-10-07 17:10
---
The problem here is that we have a complex compare-and-jump insn with side
effects, so the insn can't be simply removed. cfgrtl is getting confused and
is generating code that references a deleted label.
--
re
--- Comment #2 from kargl at gcc dot gnu dot org 2005-10-07 17:25 ---
On amd64-*-freebsd with Jakub's patch, I get
troutmask:sgk[206] gfc41 -static -o z try.f sub.c
troutmask:sgk[207] ./z
Address of x = 0x00554000
x is aligned on a 16-byte boundary
--
http://gcc.gnu.org/b
--- Comment #2 from janis187 at us dot ibm dot com 2005-10-07 17:26 ---
A regression hunt identified this large patch from Zack Weinberg and
Matt Austern:
http://gcc.gnu.org/ml/gcc-cvs/2004-09/msg00920.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24215
--- Comment #7 from cvs-commit at gcc dot gnu dot org 2005-10-07 18:12
---
Subject: Bug 24227
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-07 18:12:11
Modified files:
gcc: ChangeLog fold-const.c
gcc/testsuite
--- Comment #8 from rguenth at gcc dot gnu dot org 2005-10-07 18:14 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
/tmp/gcc41/libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1 -quiet -v test.c -dumpbase
test.c -msse2 -auxbase-strip test.o -O -version -ftree-vectorize -o test.o
GNU C version 4.1.0 20051007 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.1.0 20051007 (experimental).
GGC heuristics
FAIL: gcc.dg/torture/builtin-convert-1.c -O1 (test for excess errors)
FAIL: gcc.dg/torture/builtin-convert-1.c -O2 (test for excess errors)
FAIL: gcc.dg/torture/builtin-convert-1.c -O3 -fomit-frame-pointer (test for
excess errors)
FAIL: gcc.dg/torture/builtin-convert-1.c -O3 -g (test for ex
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-07 19:15 ---
Hmm, nothing has touched builtin-convert-1.c.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-07 19:18 ---
Looks like the testcase is wrong in that it does not test C99 for ceill and
floorl.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-07 19:27 ---
Confirmed, this was always broken in that we got wrong code in 4.0.0 but now we
get an ICE which means this is a regression and a progression.
Adding -W -Wall for 4.0, you get a warning:
t.c: In function test:
t.c
--- Comment #9 from cvs-commit at gcc dot gnu dot org 2005-10-07 19:27
---
Subject: Bug 24193
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-07 19:27:37
Modified files:
gcc: ChangeLog
gcc/config/ia64: ia64.md
--- Comment #6 from janis187 at us dot ibm dot com 2005-10-07 19:36 ---
A regression hunt on powerpc-linux using the testcase from comment #4
identified this patch from [EMAIL PROTECTED]:
http://gcc.gnu.org/ml/gcc-cvs/2005-08/msg00101.html
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #4 from janis187 at us dot ibm dot com 2005-10-07 19:45 ---
The most recent break on mainline was by this patch from jakub:
http://gcc.gnu.org/ml/gcc-cvs/2005-08/msg00974.html
The same patch was applied to the 4.0 branch, causing the failure in 4.0.2.
That patch from Jak
/tmp/gcc41/libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1 -quiet -v test.c -dumpbase
test.c -mtune=pentiumpro -auxbase-strip test.o -O -version
-fmove-loop-invariants -fgcse -o test.o
GNU C version 4.1.0 20051007 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.1.0 20051007
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-07 19:50 ---
(In reply to comment #4)
> Before that, the failure on mainline started sometime between 2003-07-16 and
> 2003-09-15. I can identify the patch if it would be useful to anyone.
Hmm, can you because in PR 15167, Neil
--- Comment #10 from wilson at gcc dot gnu dot org 2005-10-07 19:57 ---
Mine. IA-64.
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|una
--- Comment #11 from wilson at gcc dot gnu dot org 2005-10-07 19:58 ---
Fixed on mainline.
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-07 19:58 ---
Confirmed, a regression from 4.0.0.
I think this is a target bug as you had:
(set (mem:DF (plus:SI (reg/f:SI 7 sp)
(const_int 8 [0x8])) [0 S8 A32])
(const_double:DF -858993460 [0x]
2
--- Comment #35 from gdr at integrable-solutions dot net 2005-10-07 20:00
---
Subject: Re: [3.4 regression] pessimization of "goto *"
"steven at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| This is basically unfixable without serious hacking that is not
| appropriate for GCC 3.
--- Comment #6 from cvs-commit at gcc dot gnu dot org 2005-10-07 20:02
---
Subject: Bug 16339
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-07 20:02:28
Modified files:
libgfortran: ChangeLog
libgfortran/io : io.h unix.c
--- Comment #7 from cvs-commit at gcc dot gnu dot org 2005-10-07 20:02
---
Subject: Bug 23363
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-07 20:02:28
Modified files:
libgfortran: ChangeLog
libgfortran/io : io.h unix.c
--- Comment #36 from steven at gcc dot gnu dot org 2005-10-07 20:06 ---
Not really fixable for 3.4.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from tkoenig at gcc dot gnu dot org 2005-10-07 20:12 ---
> It should be noted that the patch assumes that the padding for real(10) is 10
> bytes data + 2 bytes padding. This works on i686-Linux, might not work on
> other
> targets (big endian?).
Itanium has padding to 1
--- Comment #5 from janis187 at us dot ibm dot com 2005-10-07 20:27 ---
I bumped into this PR by accident and happen to have looked into this recently.
__uint128_t is supported on a ppc64 system with a powerpc64-linux compiler
using "-m32 -mpowerpc64".
--
http://gcc.gnu.org/bugzilla
--- Comment #8 from rth at gcc dot gnu dot org 2005-10-07 21:03 ---
Steven's complaining about the solution...
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from rth at gcc dot gnu dot org 2005-10-07 21:04 ---
... so it's his. Revert the patch and do what you like.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-10-07 21:05
---
Steven is not the only one who is complaining about it.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #11 from steven at gcc dot gnu dot org 2005-10-07 21:11 ---
I think I have every right to complain after what happened to
e.g. the CD-DCE patch, thank you very much. FY.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #12 from steven at gcc dot gnu dot org 2005-10-07 21:12 ---
Oh, and for the record, if you don't care about compile time, fine, but SAY SO
and say it in public so people know that even the top gcc hacker doesn't give
shit about compile time, and so that I can stop wasting my
--- Comment #14 from steven at gcc dot gnu dot org 2005-10-07 21:21 ---
I don't have time to work on these (new job), so unassigning.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2005-10-07 21:21 ---
I don't have time to work on these (new job), so unassigning.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from steven at gcc dot gnu dot org 2005-10-07 21:21 ---
I don't have time to work on these (new job), so unassigning.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from steven at gcc dot gnu dot org 2005-10-07 21:21 ---
I don't have time to work on these (new job), so unassigning.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from steven at gcc dot gnu dot org 2005-10-07 21:21 ---
I don't have time to work on these (new job), so unassigning.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from steven at gcc dot gnu dot org 2005-10-07 21:21 ---
I don't have time to work on these (new job), so unassigning.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from steven at gcc dot gnu dot org 2005-10-07 21:21 ---
I don't have time to work on these (new job), so unassigning.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
-
gmp=/home/xxx/compiler/gmp
--with-mpfr=/home/xxx/compiler/gmp
Thread model: posix
gcc version 4.1.0 20051007 (experimental)
--
Summary: ICE when writing to array of strings that is an elements
of a user defined type
Product: gcc
Version: 4.1.0
--- Comment #4 from steven at gcc dot gnu dot org 2005-10-07 21:32 ---
The patch has almost no effect except for -Os. For SPEC binaries the
effect of the patch is not exactly shocking on AMD64 at least: No effect
at all on compile time, no effect on performance, and almost no effect
on
--- Comment #5 from steven at gcc dot gnu dot org 2005-10-07 21:33 ---
This is somehow a bug in sched-ebb, but I can't figure out where...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from yosef at phys dot utb dot edu 2005-10-07 21:36 ---
This bug also seems to cause a segfault when
writing to a standard array of strings.
program main
implicit none
type ice
character(len=80) :: mess(10)
end type ice
character(len=80) :: smess(10)
type(
--- Comment #9 from steven at gcc dot gnu dot org 2005-10-07 21:55 ---
I guess something like this should work if Andrew was right in comment #6.
Obviously this doesn't fix the the test case from comment #1 because we
don't go through this code if a user codes an "attribute regparm".
I
--- Comment #13 from steven at gcc dot gnu dot org 2005-10-07 21:57 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
The Dwarf2 information for Altvec vectors gave _unknown_ as a base type for the
vector instead of, in this case, 'short'.
Using the depricated 'attribute' scheme works, but the 'new' __vector does not,
so it could be considered a regression.
This works correctly in 4.0.0
Here is an exmple of th
--- Comment #10 from steven at gcc dot gnu dot org 2005-10-07 21:58 ---
I have no time to work on this. Note that there is no test case anymore
either, so it's hard to tell whether a fix is doing the right thing.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from janis at gcc dot gnu dot org 2005-10-07 22:12 ---
I'm testing the backport of a fix for this.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
-
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |debug
Keywords||wrong-debug
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-07 22:39 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-07 22:44 ---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00407.html
Sometimes I wonder why a simple one line patch takes this long to create and
why only a few developers (and a maybe 1-3 maintainers) are looking
--- Comment #2 from janis at gcc dot gnu dot org 2005-10-07 23:01 ---
A regression hunt identified this patch from [EMAIL PROTECTED]:
http://gcc.gnu.org/ml/gcc-cvs/2005-07/msg01082.html
--
janis at gcc dot gnu dot org changed:
What|Removed |Adde
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-07 23:03 ---
Hmm, maybe this is not a target bug after all but a latent bug in gcse store
motion.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24257
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|3.4.5 |3.4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24267
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-07 23:34 ---
Can you do timings with today's compiler?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23363
--- Comment #2 from janis at gcc dot gnu dot org 2005-10-07 23:50 ---
For all of the 3.4.x and 4.0.x compilers I tried, plus the 3.4 branch,
4.0 branch, and mainline, I get the warning "stdcall attribute directive
ignored" and there is no change in the generated code. This is for
powe
--- Comment #2 from cvs-commit at gcc dot gnu dot org 2005-10-07 23:57
---
Subject: Bug 23644
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-07 23:57:36
Modified files:
gcc: ChangeLog
gcc/doc: invoke.tex
--- Comment #3 from janis at gcc dot gnu dot org 2005-10-08 00:00 ---
Had I read the documentation for stdcall I'd know it's not used for powerpc.
I'm starting a reghunt using an i686-linux cross compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24260
--- Comment #2 from janis at gcc dot gnu dot org 2005-10-08 00:03 ---
A regression hunt using an i686-linux cross compiler identified this patch
from [EMAIL PROTECTED]:
http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg00015.html
--
janis at gcc dot gnu dot org changed:
What
--- Comment #3 from cvs-commit at gcc dot gnu dot org 2005-10-08 00:13
---
Subject: Bug 23644
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-10-08 00:13:07
Modified files:
gcc: ChangeLog
1 - 100 of 124 matches
Mail list logo
