--- Comment #31 from bergner at vnet dot ibm dot com 2006-12-05 04:41
---
...and here's the patch I mentioned in the previous comment:
Index: reload1.c
===
--- reload1.c (revision 119497)
+++ reload1.c (working copy)
@
--- Comment #30 from bergner at vnet dot ibm dot com 2006-12-05 04:22
---
Ok, the problem from comment #28 was due to a latent bug in
reload1.c:eliminate_regs_in_insn(). The bug is that eliminate_regs_in_insn()
calls single_set() on the passed in insn. This has been fine before, but no
--- Comment #11 from bergner at vnet dot ibm dot com 2006-12-05 02:06
---
The testcase pr26943-2.c fails intermittently for me using unpatched mainline.
Is anyone else seeing that? I'm building on powerpc64-linux with -m32. If I
run it a few times, it mainly passes, but every once in
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-12-05 00:51
---
Subject: Bug 30005
Author: jvdelisle
Date: Tue Dec 5 00:51:26 2006
New Revision: 119530
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119530
Log:
2006-12-04 Jerry DeLisle <[EMAIL PROTECTED]>
On 12/4/06, Shaun Jackman <[EMAIL PROTECTED]> wrote:
In the code snippet below, the function mul_8_8 compiles to use
exactly one `mul' instruction on the AVR. The function mul_16_8 calls
mul_8_8 twice. If mul_8_8 is a static inline function and inlined in
...
For comparison, a hand-coded 16x8 m
--- Comment #2 from ron3763 at msn dot com 2006-12-04 23:55 ---
(In reply to comment #1)
> This is a "bug" in glibc. The mainline changed the way it handles inline to
> be
> the C99 way.
>
> Also see:
> http://sourceware.org/ml/libc-hacker/2006-11/msg1.html
>
Ok, I read his patc
--- Comment #1 from pault at gcc dot gnu dot org 2006-12-04 23:31 ---
Created an attachment (id=12745)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12745&action=view)
A fix for this PR
Regtests on Cygwin_NT/amd64
--
pault at gcc dot gnu dot org changed:
What|R
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-12-04 23:21
---
Fixed in 4.1.2.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Assigned
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-12-04 23:21
---
Subject: Bug 29632
Author: mmitchel
Date: Mon Dec 4 23:21:03 2006
New Revision: 119517
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119517
Log:
PR c++/29632
* call.c (add_builtin_candida
--- Comment #3 from michael dot meissner at amd dot com 2006-12-04 23:21
---
I've done some analysis on the test case. The current GCC 4.2 and mainline
branches no longer generate the initial push of %r8, but instead do a subq
$8,%rsp. I believe in the compiler you used it did the pus
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-12-04 23:21
---
Fixed in 4.1.2.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-12-04 23:20
---
Subject: Bug 29733
Author: mmitchel
Date: Mon Dec 4 23:19:56 2006
New Revision: 119516
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119516
Log:
PR c++/29733
* pt.c (tsubst_decl): Disallo
In the code snippet below, the function mul_8_8 compiles to use
exactly one `mul' instruction on the AVR. The function mul_16_8 calls
mul_8_8 twice. If mul_8_8 is a static inline function and inlined in
mul_16_8, each call generates three `mul' instructions! Why does
inlining mul_8_8 cause each 8x
--- Comment #28 from dave at hiauly1 dot hia dot nrc dot ca 2006-12-04
22:52 ---
Subject: Re: [4.1/4.2/4.3 regression] Unsatisfied symbol "fmodl" in
libgfortran shared library
> I suspect the determination of kind types is at least partially broken
> since both 32 and 64-bit PA target
--- Comment #32 from pinskia at gcc dot gnu dot org 2006-12-04 22:51
---
*** Bug 30069 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-04 22:51 ---
This is not really a bug but a questionable one in the C++ standard.
anyways this is a dup of bug 57.
*** This bug has been marked as a duplicate of 57 ***
--
pinskia at gcc dot gnu dot org changed:
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirm
--- Comment #1 from ppluzhnikov at charter dot net 2006-12-04 22:46 ---
It turns out that I've already seen this bug in MSVC-6.0,
and found a workaround.
This parses fine (note extra parenthesis) with gcc-3.4.0 and above:
struct Foo {
void foo23(const vector< char, allocator< char
--- Comment #3 from pault at gcc dot gnu dot org 2006-12-04 22:44 ---
Created an attachment (id=12744)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12744&action=view)
A fix for this PR
This is most of the way there, using the idea in #2; except that, for reasons I
do not understa
The test case below declares 3 global functions with exactly the
same signature, and another 3 member functions with the same signature.
The last of these is incorrectly rejected.
$ cat junk.cc
#include
using namespace std;
void foo11(const vector & = vector());
void foo12(const vector< char,
--- Comment #27 from ebotcazou at gcc dot gnu dot org 2006-12-04 22:18
---
> Hopefully, that is a "generic you" because I haven't decided
> anything. In fact, I requested that pault or fx backout the
> offending patch. See
>
> http://gcc.gnu.org/ml/fortran/2006-11/msg00523.html
Than
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-12-04 22:16
---
Fixed in 4.2.0, 4.3.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-12-04 22:15
---
Subject: Bug 29733
Author: mmitchel
Date: Mon Dec 4 22:15:24 2006
New Revision: 119513
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119513
Log:
PR c++/29733
* pt.c (tsubst_decl): Disallo
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-12-04 22:14
---
Subject: Bug 29632
Author: mmitchel
Date: Mon Dec 4 22:14:42 2006
New Revision: 119512
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119512
Log:
PR c++/29632
* call.c (add_builtin_candida
--- Comment #26 from sgk at troutmask dot apl dot washington dot edu
2006-12-04 21:37 ---
Subject: Re: [4.1/4.2/4.3 regression] Unsatisfied symbol "fmodl" in
libgfortran shared library
On Mon, Dec 04, 2006 at 08:54:40PM -, ebotcazou at gcc dot gnu dot org
wrote:
> > When rth fixed
--- Comment #3 from dfranke at gcc dot gnu dot org 2006-12-04 21:35 ---
Subject: Bug 29949
Author: dfranke
Date: Mon Dec 4 21:35:19 2006
New Revision: 119511
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119511
Log:
PR libgomp/29949
* env.c (omp_set_num_threads
--- Comment #31 from dave at hiauly1 dot hia dot nrc dot ca 2006-12-04
21:26 ---
Subject: Re: [4.3 Regression] build/genconditions
../../gcc/gcc/config/pa/pa.md > tmp-condmd.c: /bin/sh: 13354 Memory
fault(coredump)
> I will test on a cross if it fixes the failure on hppa. It seemed n
--- Comment #25 from burnus at gcc dot gnu dot org 2006-12-04 21:15 ---
> OK, I'll put this in the pipeline for clean-up and submission.
Thanks. At least the generic interface patch should be completely ok; for the
other one, I'll try to dream up something which is not correctly covered
--- Comment #25 from dave at hiauly1 dot hia dot nrc dot ca 2006-12-04
21:13 ---
Subject: Re: [4.1/4.2/4.3 regression] Unsatisfied symbol "fmodl" in
libgfortran shared library
> > When rth fixed gfortran's determination of kind types,
> > gfortran suddenly grew real(10) or real(16) on
--- Comment #6 from pcarlini at suse dot de 2006-12-04 21:12 ---
Finally fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW
Examples taken from the Fortran 2003 standard, Section C.11.2.
They are not recognized as invalid.
* * *
INTERFACE BAD8 ! this interface is invalid !
! despite the fact that it is unambiguous !
SUBROUTINE S8A(X,Y,Z)
REAL,OPTIONAL :: X
INTEGER :: Y
REAL :: Z
END SUBROUTINE S8A
--- Comment #5 from paolo at gcc dot gnu dot org 2006-12-04 21:12 ---
Subject: Bug 29989
Author: paolo
Date: Mon Dec 4 21:11:52 2006
New Revision: 119510
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119510
Log:
2006-12-04 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
The following code fragment fails on gcc i386 3.4.5-2, but works on 4.0.
Compilation terminates normally when field x is removed from structure
declaration S.
The fragment is simple enough, but I could not find an open bug description for
it.
struct S
{
char x;
unsigned char v[2];
};
st
--- Comment #24 from pault at gcc dot gnu dot org 2006-12-04 20:55 ---
OK, I'll put this in the pipeline for clean-up and submission.
Paul
> However, one gets neither a warning nor an error for the following test case,
> which can be found in the Fortran 2003 standard, Section C.11.2:
--- Comment #24 from ebotcazou at gcc dot gnu dot org 2006-12-04 20:54
---
> Yes, "always". Ping pbrook or stevenb. c99_function.c was
> included to provide missing c99 routines on platforms that
> needed them. 4.1.1 worked because people were careful with
> adding missing functions.
--- Comment #2 from pault at gcc dot gnu dot org 2006-12-04 20:47 ---
(In reply to comment #1)
> I thought I would have time to do something about this bug, but I will not;
> not
> in the next few weeks/months. I therefore unassign it from me. My appologies
> to those who expected to
--- Comment #6 from burnus at gcc dot gnu dot org 2006-12-04 20:03 ---
Subject: Bug 29962
Author: burnus
Date: Mon Dec 4 20:02:43 2006
New Revision: 119505
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119505
Log:
fortran/
2006-12-04 Tobias Burnus <[EMAIL PROTECTED]>
--- Comment #7 from pault at gcc dot gnu dot org 2006-12-04 19:30 ---
Subject: Bug 29821
Author: pault
Date: Mon Dec 4 19:30:33 2006
New Revision: 119504
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119504
Log:
2006-12-04 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #1 from mrs at apple dot com 2006-12-04 19:27 ---
radr://4405938
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30066
A user would like an option to mark all inline functions (foo in this case):
extern void bar();
inline void foo() { bar(); }
void doit() { foo(); }
as hidden, kinda like what -fvisibility-inlines-hidden does for inline methods.
I gather this is so that runtime binding is limited to make startup
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-12-04 19:14 ---
Created an attachment (id=12742)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12742&action=view)
tentative patch
This patch implements this optimization, although it could be improved to
consider more possibl
Sometimes constants could be replaced by smaller, cheaper constants by
making use of scaled indices.
--
Summary: Could use indexed addressing to reduce const costs
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|00
--- Comment #8 from paulthomas2 at wanadoo dot fr 2006-12-04 18:38 ---
Subject: Re: [4.1 and 4.2 only] Dimension of a function
result as host association does not work
Tobias,
> t you saw the submission email (autoattached to this PR and thus also
> in your mailbox).
>
As I said ye
--- Comment #19 from pinskia at gcc dot gnu dot org 2006-12-04 18:32
---
Subject: Bug 14329
Author: pinskia
Date: Mon Dec 4 18:31:40 2006
New Revision: 119501
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119501
Log:
2006-12-04 Richard Henderson <[EMAIL PROTECTED]>
--- Comment #4 from pcarlini at suse dot de 2006-12-04 18:23 ---
Damn ;)
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|RESOLVED
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-12-04 18:08
---
Subject: Bug 29733
Author: mmitchel
Date: Mon Dec 4 18:08:11 2006
New Revision: 119500
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119500
Log:
PR c++/29733
* pt.c (tsubst_decl): Disallo
--- Comment #7 from burnus at gcc dot gnu dot org 2006-12-04 18:05 ---
> Thank you! I had a bit of a surprise when I tried, a few minutes ago, to
> apply the patch... I thought that I was going even madder than usual, when it
> came back with the information that there was an unrevers
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-12-04 18:00
---
Subject: Bug 29632
Author: mmitchel
Date: Mon Dec 4 18:00:32 2006
New Revision: 119499
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119499
Log:
PR c++/29632
* call.c (add_builtin_candida
--- Comment #6 from pault at gcc dot gnu dot org 2006-12-04 17:53 ---
(In reply to comment #5)
> Subject: Bug 29916
Tobias,
Thank you! I had a bit of a surprise when I tried, a few minutes ago, to apply
the patch... I thought that I was going even madder than usual, when it came
back
--- Comment #23 from sgk at troutmask dot apl dot washington dot edu
2006-12-04 17:40 ---
Subject: Re: [4.1/4.2/4.3 regression] Unsatisfied symbol "fmodl" in
libgfortran shared library
On Mon, Dec 04, 2006 at 05:06:37PM -, ebotcazou at gcc dot gnu dot org
wrote:
>
>
> --- Co
--- Comment #22 from ebotcazou at gcc dot gnu dot org 2006-12-04 17:06
---
> AFAIK, libgfortran has also assumed a C99 compiler/library is
> available (even though gcc isn't C99 compliant). You'd need to
> ping pbrook or stevenb about the details.
s/also/always? In either case, that
On 12/4/06, Andrew Haley <[EMAIL PROTECTED]> wrote:
Thanks. This is caused because
seda.sandStorm.internal.AggTPSThreadManager$governorThread is in the
file
seda/sandStorm/internal/ATTIC/AggTPSThreadManager$governorThread.class
(In other words, it's not where gcj expects to find it.)
This is a
--- Comment #21 from sgk at troutmask dot apl dot washington dot edu
2006-12-04 16:46 ---
Subject: Re: [4.1/4.2/4.3 regression] Unsatisfied symbol "fmodl" in
libgfortran shared library
On Mon, Dec 04, 2006 at 09:22:10AM -, ebotcazou at gcc dot gnu dot org
wrote:
> Note that I'm co
--- Comment #20 from sgk at troutmask dot apl dot washington dot edu
2006-12-04 16:44 ---
Subject: Re: [4.1/4.2/4.3 regression] Unsatisfied symbol "fmodl" in
libgfortran shared library
On Mon, Dec 04, 2006 at 09:09:51AM -, pault at gcc dot gnu dot org wrote:
>
> (In reply to comm
--- Comment #1 from ssoe at kirktelecom dot com 2006-12-04 16:42 ---
Created an attachment (id=12741)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12741&action=view)
Testcase
Reduced version of shell/cmdedit.c from busybox-1.2.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
$ m68k-linux-gcc -v -m5307 -msep-data -O1 -c gcc-m68k-ice.c
Using built-in specs.
Target: m68k-linux
Configured with: ../gcc-4.3-20061202/configure --prefix=/home/ssoe/tmp/m68k
--target m68k-linux --disable-shared --disable-threads --enable-languages=c
--with-headers=/home/ssoe/tmp/m68k/m68k-linux/
--- Comment #3 from bangerth at dealii dot org 2006-12-04 16:11 ---
Confirmed. While there may not be much that can be done at the place
where the current error is reported, the warning is definitely a valid
request.
W.
--
bangerth at dealii dot org changed:
What|Rem
--- Comment #15 from marc dot glisse at normalesup dot org 2006-12-04
15:54 ---
*** Bug 30062 has been marked as a duplicate of this bug. ***
--
marc dot glisse at normalesup dot org changed:
What|Removed |Added
---
--- Comment #1 from marc dot glisse at normalesup dot org 2006-12-04 15:54
---
*** This bug has been marked as a duplicate of 2316 ***
--
marc dot glisse at normalesup dot org changed:
What|Removed |Added
--- Comment #22 from pbrook at gcc dot gnu dot org 2006-12-04 15:10 ---
I disagree. All code that requires new gas would previously ICE.
Any code that currently compiles with 4.1 should be unaffected.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-12-04 14:51 ---
(In reply to comment #1)
> I think this is really a dup of bug 12990.
>
Sort of, but not quite. 12990 does no cover the exception handling aspects,
but it claims that the problem persists target-independently for
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-12-04 14:37 ---
Created an attachment (id=12740)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12740&action=view)
preprocessed source
The sub-command that fails using --save-temps -v is:
/home/amylaar/bld/2006-11-27/sh-elf/.
--- Comment #4 from amylaar at gcc dot gnu dot org 2006-12-04 14:27 ---
The bug is not fixed; the gcc.c patch has not been reviewed.
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
People are probably more likely to fix their code if they're told how -- it
would be useful to have
void new_function() { }
void __attribute__((deprecated("use new_function instead")) old_function() { }
int main(int argc, char **argv) {
old_function();
}
resulting in
test.cpp: 6: warning
Shaun Jackman writes:
> $ gcj -c /usr/share/java/seda.jar
> seda/sandStorm/internal/AggTPSThreadManager.java: In class
> 'seda.sandStorm.internal.AggTPSThreadManager$governorThread':
> seda/sandStorm/internal/AggTPSThreadManager.java: In method
> 'seda.sandStorm.internal.AggTPSThreadManager$go
Hello,
I noticed that if I give g++ the prototypes for bsearch as listed in the 2003
standard, it errors out saying that the 2 declarations conflict:
extern "C" void *bsearch(const void *key, const void *base, size_t nmemb,
size_t size, int (*compar)(const void *, const void *));
extern "C++" voi
--- Comment #21 from rearnsha at gcc dot gnu dot org 2006-12-04 11:26
---
We can't apply this patch to the 4.1 branch if it would mean users had to use
CVS versions of binutils.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
--- Comment #5 from burnus at gcc dot gnu dot org 2006-12-04 11:16 ---
Subject: Bug 29916
Author: burnus
Date: Mon Dec 4 11:16:12 2006
New Revision: 119489
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119489
Log:
fortran/
2006-12-04 Paul Thomas <[EMAIL PROTECTED]>
PR f
--- Comment #4 from jakub at gcc dot gnu dot org 2006-12-04 10:36 ---
Fixed in SVN.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGN
--- Comment #6 from jakub at gcc dot gnu dot org 2006-12-04 10:36 ---
Fixed in SVN.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGN
--- Comment #3 from jakub at gcc dot gnu dot org 2006-12-04 10:30 ---
Subject: Bug 29947
Author: jakub
Date: Mon Dec 4 10:30:11 2006
New Revision: 119486
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119486
Log:
PR libgomp/29947
* omp-low.c (expand_omp_for_stat
--- Comment #2 from jakub at gcc dot gnu dot org 2006-12-04 10:26 ---
Subject: Bug 29947
Author: jakub
Date: Mon Dec 4 10:26:00 2006
New Revision: 119485
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119485
Log:
PR libgomp/29947
* omp-low.c (expand_omp_for_stat
--- Comment #5 from jakub at gcc dot gnu dot org 2006-12-04 10:23 ---
Subject: Bug 29965
Author: jakub
Date: Mon Dec 4 10:23:06 2006
New Revision: 119484
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119484
Log:
PR middle-end/29965
* omp-low.c (determine_parall
--- Comment #4 from jakub at gcc dot gnu dot org 2006-12-04 10:21 ---
Subject: Bug 29965
Author: jakub
Date: Mon Dec 4 10:20:51 2006
New Revision: 119483
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119483
Log:
PR middle-end/29965
* omp-low.c (determine_parall
--- Comment #3 from pault at gcc dot gnu dot org 2006-12-04 09:44 ---
Since I posted a fix, I guess that I should accept the bug!
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #29 from irar at il dot ibm dot com 2006-12-04 09:24 ---
I reproduced the wrong printings on x86. It seems to be a problem in strided
access vectorization after all - no stores are generated. I am looking into
this.
Thanks,
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2006-12-04 09:22
---
> I am curious as to why the test in the original patch, for the presence of the
> builtin, does not work. In principle, it should furnish the old tree-ssa
> version of MOD. Would it not be an idea to apply the
--- Comment #18 from pault at gcc dot gnu dot org 2006-12-04 09:09 ---
(In reply to comment #17)
> Created an attachment (id=12735)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12735&action=view) [edit]
> Compilable version of previous patch.
FX and Eric,
Thanks for plugging the
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-04 08:15 ---
*** Bug 30046 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-04 08:15 ---
*** This bug has been marked as a duplicate of 29733 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from s__nakayama at infoseek dot jp 2006-12-04 08:11 ---
I seem this is same as Bug 29733.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30046
82 matches
Mail list logo
