--- 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
--- 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 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 #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=12735action=view) [edit]
Compilable version of previous patch.
FX and Eric,
Thanks for plugging the
--- 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 #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
--
--- 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 #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=gccview=revrev=119483
Log:
PR middle-end/29965
* omp-low.c
--- 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=gccview=revrev=119484
Log:
PR middle-end/29965
* omp-low.c
--- 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=gccview=revrev=119485
Log:
PR libgomp/29947
* omp-low.c
--- 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=gccview=revrev=119486
Log:
PR libgomp/29947
* omp-low.c
--- 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
--- 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
--- 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=gccview=revrev=119489
Log:
fortran/
2006-12-04 Paul Thomas [EMAIL PROTECTED]
PR
--- 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
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++ void
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
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:
--- 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
--- 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=12740action=view)
preprocessed source
The sub-command that fails using --save-temps -v is:
--- 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 #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 #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 #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 #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
$ 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
--- 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=12741action=view)
Testcase
Reduced version of shell/cmdedit.c from busybox-1.2.2.
--
--- 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 comment
--- 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
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 #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's
--- 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:
---
--- 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 #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=gccview=revrev=119499
Log:
PR c++/29632
* call.c
--- 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 unreversed
--- 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=gccview=revrev=119500
Log:
PR c++/29733
* pt.c (tsubst_decl): Disallow
--- Comment #4 from pcarlini at suse dot de 2006-12-04 18:23 ---
Damn windows.h ;)
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|RESOLVED
--- 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=gccview=revrev=119501
Log:
2006-12-04 Richard Henderson [EMAIL PROTECTED]
--- 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
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
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:
--- 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=12742action=view)
tentative patch
This patch implements this optimization, although it could be improved to
consider more possible
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 mrs at apple dot com 2006-12-04 19:27 ---
radr://4405938
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30066
--- 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=gccview=revrev=119504
Log:
2006-12-04 Paul Thomas [EMAIL PROTECTED]
PR
--- 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=gccview=revrev=119505
Log:
fortran/
2006-12-04 Tobias Burnus [EMAIL PROTECTED]
--- 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 be
--- 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. For
--- 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:
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];
};
--- 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=gccview=revrev=119510
Log:
2006-12-04 Paolo Carlini [EMAIL PROTECTED]
PR
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 #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
--- 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 many
--- 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 #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
--- 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=gccview=revrev=119511
Log:
PR libgomp/29949
* env.c
--- 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 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=gccview=revrev=119512
Log:
PR c++/29632
* call.c
--- 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=gccview=revrev=119513
Log:
PR c++/29733
* pt.c (tsubst_decl): Disallow
--- 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 #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
Thanks for
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 vector
using namespace std;
void foo11(const vectorchar = vectorchar());
void foo12(const
--- 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=12744action=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
--- 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
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- 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:
--- 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 #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 targets
--- 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=gccview=revrev=119516
Log:
PR c++/29733
* pt.c (tsubst_decl): Disallow
--- 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
--- 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
--- 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=gccview=revrev=119517
Log:
PR c++/29632
* call.c
--- 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
--- 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=12745action=view)
A fix for this PR
Regtests on Cygwin_NT/amd64
--
pault at gcc dot gnu dot org changed:
What
--- 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 patch, so
--- 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=gccview=revrev=119530
Log:
2006-12-04 Jerry DeLisle [EMAIL PROTECTED]
PR
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
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
--- 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 #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
--- 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)
82 matches
Mail list logo
