--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-21 14:55 ---
# 1
/Users/eschnett/Cvanilla/configs/einstein-orange-gcc-debug/bindings/Configuration/Thorns/time.h
1 3 4
Hmm, it is including the wrong time.h for some reason.
Could you add -v and provide the output, I am
--- Comment #7 from joel at gcc dot gnu dot org 2005-11-21 14:56 ---
(In reply to comment #6)
Shall we close this as WORKSFORME?
Looks like it.
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from charlet at adacore dot com 2005-11-21 14:59 ---
Subject: Re: [4.1/4.2 Regression] make[7]: rc: Command not found
I'm not sure either. I did notice that the build that had a problem
was using an old version of make (3.79.1). I removed this and now this
system
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-21 15:01 ---
We have in libstdc++:
#include time.h
So this is invalid. -I does:
-I dir
Add the directory dir to the list of directories to be searched
for header files. Directories named by -I are
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-21 15:02 ---
As I said this is invalid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from pluto at agmk dot net 2005-11-21 15:05 ---
gcc-3.3.6 produces better code:
test: movqw, %mm1
psllw $1, %mm1
movq%mm1, w
movqw, %mm1
movq%mm1, dw
ret
.comm dw,8,8
.comm w,8,8
can we
--- Comment #3 from msharov at hotmail dot com 2005-11-21 15:07 ---
By its very nature, demonstrating the problem requires a large example, so I am
unable to provide a sufficiently compact one to post here. You can, however,
download the project I'm having problems with from SourceForge
--- Comment #19 from pinskia at gcc dot gnu dot org 2005-11-21 15:09
---
(In reply to comment #18)
can we classify this as a code size regression?
No because 3.3.x was also wrong in the sense it did not emit an emms.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14552
--- Comment #37 from pedro dot lamarao at mndfck dot org 2005-11-21 15:11
---
Yes, please *heavily* comment.
If this is approved, someone could do the copy on the relevant branches, then
I'd send a patch with better comments and changelog to the gcc-patches list.
--
(972) uname -a
FreeBSD gadoid.ices.cmu.edu 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #0: Mon Feb 23
20:45:55 GMT 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
i386
(973) cat a.c
#include stdlib.h
#include stdio.h
int main(int argc,char *argv[])
{
float n = 40;
int i;
for (i = 0;i
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-21 15:16 ---
This code should have been rejected as it is for 3.4.0 and above.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-21 15:16 ---
Note the error is:
t.c:17: error: conflicting types for foo
t.c:10: error: previous implicit declaration of foo was here
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24971
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-21 15:16
---
(In reply to comment #11)
Could somebody with an Intel 64bit system try to bootstrap this?
I don't have an Intel 64bit machine, but I can do a bootstrap on a x86_64
machine with this patch.
--
(972) uname -a
FreeBSD gadoid.ices.cmu.edu 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #0: Mon Feb 23
20:45:55 GMT 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
i386
(973) cat a.c
#include stdlib.h
#include stdio.h
int main(int argc,char *argv[])
{
float n = 40;
int i;
for (i = 0;i
(972) uname -a
FreeBSD gadoid.ices.cmu.edu 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #0: Mon Feb 23
20:45:55 GMT 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
i386
(973) cat a.c
#include stdlib.h
#include stdio.h
int main(int argc,char *argv[])
{
float n = 40;
int i;
for (i = 0;i
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-21 15:18 ---
*** This bug has been marked as a duplicate of 24971 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-21 15:18 ---
*** Bug 24972 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24971
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-21 15:18 ---
*** This bug has been marked as a duplicate of 24971 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-21 15:18 ---
*** Bug 24973 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24971
--- Comment #4 from rearnsha at gcc dot gnu dot org 2005-11-21 15:19
---
It seems to me that the problem here is that a 'warning' is too strong here,
particularly with -Werror. We really need a diagnostic that is non-fatal to
the compilation, since there's nothing really wrong with
--- Comment #38 from pcarlini at suse dot de 2005-11-21 15:22 ---
(In reply to comment #37)
Yes, please *heavily* comment.
If this is approved, someone could do the copy on the relevant branches, then
I'd send a patch with better comments and changelog to the gcc-patches list.
--- Comment #5 from hansen at cmu dot edu 2005-11-21 15:28 ---
(In reply to comment #2)
Note the error is:
t.c:17: error: conflicting types for foo
t.c:10: error: previous implicit declaration of foo was here
I only get warnings in 3.3.0. Even with warnings, I still do not
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-21 15:29 ---
3.2.3 also gets this wrong the same way.
The callee side says the struct comes on the stack.
The caller side says the struct goes in via %rdi.
Which one is correct?
--
pinskia at gcc dot gnu dot org changed:
--- Comment #3 from machata at post dot cz 2005-11-21 15:31 ---
Created an attachment (id=10311)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10311action=view)
Allow comma only on second and further passes of declarator processing loop.
The patch addresses the problem by eating
--- Comment #5 from msharov at hotmail dot com 2005-11-21 15:34 ---
I would disagree. If the compiler ends up creating a function call where I
expect a simple movl, that _is_ something I want to hear about as a warning. I
have some code that uses inlines in really tight loops and having
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-21 15:35 ---
Here is the rtl which is produced by expanding foo(x):
(insn 15 13 16 (set (reg/f:DI 63)
(symbol_ref:DI (x) var_decl 0x2b15eb00 x)) -1 (nil)
(nil))
(insn 16 15 17 (set (reg:DI 62)
We currently miscompile DLV with -fstrict-aliasing, and the only aliasing
issues
that are visible are inside libstdc++:
/usr/include/c++/4.1.0/bits/basic_string.h:180: warning: dereferencing
type-punned pointer will break strict-aliasing rules
/usr/include/c++/4.1.0/bits/stl_set.h:348: warning:
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-21 15:44 ---
Created an attachment (id=10312)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10312action=view)
patch to enable aliasing warnings for C++
Apply to see the warnings (even during a libstdc++ build).
--
--- Comment #6 from rearnsha at gcc dot gnu dot org 2005-11-21 15:49
---
Subject: Re: -Os should maximize inlining --param
values.
I didn't say the compiler shouldn't say anything, I said it shouldn't be
fatal. Regardless of whether or not you think the limits are too low,
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-21 15:51 ---
(In reply to comment #1)
Created an attachment (id=10312)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10312action=view) [edit]
patch to enable aliasing warnings for C++
Note I think this patch is slightly
--- Comment #14 from pault at gcc dot gnu dot org 2005-11-21 15:53 ---
I have become more than a little bit concerned that this PR is a wild goose
chase.
Applying a similar patch to Erik's, I can persuade some bits of code to do
something. Furthermore, they are even the same things
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-21 15:56 ---
This is a dup of bug 19253 which is fixed in 3.4.5, and 4.0.3. That might be
why you did not find the bug.
*** This bug has been marked as a duplicate of 19253 ***
--
pinskia at gcc dot gnu dot org changed:
--- Comment #17 from pinskia at gcc dot gnu dot org 2005-11-21 15:56
---
*** Bug 24967 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from msharov at hotmail dot com 2005-11-21 16:01 ---
(In reply to comment #6)
This is not something that should cause -Werror to refuse compilation.
Well, according to the manpage, -Werror treats _all_ warnings as fatal, no
matter what they are about. Since -Winline is
--- Comment #5 from jb at gcc dot gnu dot org 2005-11-21 16:01 ---
Just as a general note, the deadline for dwarf3 comments is Dec 1, 2005. So if
anyone with some clue about how to improve support for debugging fortran has
some good suggestions that would require changes in the debug
--- Comment #3 from chris at bubblescope dot net 2005-11-21 16:03 ---
While it does look like there might be an error in this warning code, I also
have a feeling we are doing something bad here. I looked at the examples in
stl_set.h and we are doing reference casting from a
--- Comment #4 from pcarlini at suse dot de 2005-11-21 16:05 ---
Thanks. I'm looking into the issue. The part involving set seems to me much
more
critical and hopefully solvable without breaking the ABI, because we are not
exporting anything from the library involving set/multiset. I
--- Comment #6 from pault at gcc dot gnu dot org 2005-11-21 16:06 ---
Subject: Bug 24223
Author: pault
Date: Mon Nov 21 16:05:58 2005
New Revision: 107310
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107310
Log:
2005-11-21 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #3 from pault at gcc dot gnu dot org 2005-11-21 16:06 ---
Subject: Bug 24705
Author: pault
Date: Mon Nov 21 16:05:58 2005
New Revision: 107310
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107310
Log:
2005-11-21 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-21 16:06 ---
(In reply to comment #7)
I'm pretty sure that if you run a poll of all the C++
programmers, they'll tell you that they expect the former to always be inlined
in an optimized build, while the latter ought to depend
--- Comment #13 from krebbel at gcc dot gnu dot org 2005-11-21 16:07
---
I don't have an Intel 64bit machine, but I can do a bootstrap on a x86_64
machine with this patch.
Ups. That's what I was trying to suggest - an unusual typo isn't it? ;-)
Thanks for taking care of this!
--
--- Comment #1 from rsandifo at gcc dot gnu dot org 2005-11-21 16:09
---
Confirmed. Here's a dejagnu-style testcase:
// PR c++/20416. We correctly constructed the temporary S in foo(),
// but incorrectly destroyed it every time foo() was called.
// { dg-do run }
extern C void abort
--- Comment #5 from pcarlini at suse dot de 2005-11-21 16:09 ---
One more bit of info (meant for Chris too): I think the cast has been added
when
set was changed to have both iterator and const_iterator as const iterator
types.
Since we are not exporting anything, I suppose we can fix
--- Comment #2 from rsandifo at gcc dot gnu dot org 2005-11-21 16:09
---
BTW, this is 12.2/5.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20416
--- Comment #3 from dje at gcc dot gnu dot org 2005-11-21 16:12 ---
Subject: Bug 24953
Author: dje
Date: Mon Nov 21 16:12:32 2005
New Revision: 107311
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107311
Log:
PR target/24953
* config/rs6000/predicates.md
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-11-21 16:19
---
(In reply to comment #13)
Ups. That's what I was trying to suggest - an unusual typo isn't it? ;-)
Thanks for taking care of this!
Actually I was wrong in saying that only complex modes can show up here. It
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-21 16:22
---
(In reply to comment #14)
The testcase to get that construct is:
Compiling with -mpowerpc64 to get the mixed mode. I would not doubt that the
arm failure is a similar issue but not with complex types.
--
--- Comment #9 from msharov at hotmail dot com 2005-11-21 16:25 ---
(In reply to comment #8)
Depends on which C++ developers and if they have really thought about all
their
uses of inline (most have not even though they say they want functions
declared
as inline to be inlined)?
--- Comment #6 from pcarlini at suse dot de 2005-11-21 16:28 ---
Actually, to be 100% safe wrt binary compatibility (addresses, etc.) we can
also overload for _Rb_tree::const_iterator the involved _Rb_tree functions,
I'm preparing a patch.
--
--- Comment #4 from bonzini at gcc dot gnu dot org 2005-11-21 16:38 ---
Subject: Bug 24951
Author: bonzini
Date: Mon Nov 21 16:38:13 2005
New Revision: 107312
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107312
Log:
2005-11-21 Paolo Bonzini [EMAIL PROTECTED]
PR
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-21 16:50
---
Fixed in 4.1.0 and above for now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from bonzini at gcc dot gnu dot org 2005-11-21 17:04 ---
Subject: Bug 24951
Author: bonzini
Date: Mon Nov 21 17:04:11 2005
New Revision: 107313
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107313
Log:
2005-11-21 Paolo Bonzini [EMAIL PROTECTED]
PR
--- Comment #6 from bonzini at gcc dot gnu dot org 2005-11-21 17:05 ---
Andreas, can you confirm it is fixed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24951
This testcase:
int a = 0xe+100;
Produces a diagnostic message that would surprise
most users:
foo.c:1:9: error: invalid suffix +100 on integer constant
I'm not sure what the standard says about ambiguity
between the hex float notation and the regular + operator,
but many users are going to
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-21 17:28 ---
(In reply to comment #0)
but many users are going to think of this behavior as
a parser bug.
This is more of a tokenizer error rather than a parser error.
Anyways 2.95.3 gives:
t.c:1: missing white space after
--- Comment #16 from krebbel at gcc dot gnu dot org 2005-11-21 17:36
---
(In reply to comment #15)
(In reply to comment #14)
The testcase to get that construct is:
Compiling with -mpowerpc64 to get the mixed mode. I would not doubt that the
arm failure is a similar issue but not
--- Comment #7 from pcarlini at suse dot de 2005-11-21 17:55 ---
Created an attachment (id=10314)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10314action=view)
Draft for the set/multiset issue
Richard, can you see if the miscompilation goes away with the attached? In a
sense is
--- Comment #4 from dje at gcc dot gnu dot org 2005-11-21 18:04 ---
Subject: Bug 24953
Author: dje
Date: Mon Nov 21 18:04:14 2005
New Revision: 107314
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107314
Log:
PR target/24953
* config/rs6000/predicates.md
--- Comment #15 from sven dot buijssen at math dot uni-dortmund dot de
2005-11-21 18:06 ---
I cannot tell why, but it seems to me that Paul Thomas' test case is no valid
code:
* Compaq Fortran Compiler X5.4A-1684-46B5P gives:
f90: Warning: line 14: An explicit-shaped array is being
--- Comment #16 from Tobias dot Schlueter at physik dot uni-muenchen dot de
2005-11-21 18:08 ---
Subject: Re: ICE Using Pointer Functions
pgf90 compiles Paul Thomas' example, giving an empty string as output from the
subroutine.
--
Sorry in advance if this is a dup.
Dependent lookup considers static candidate functions, which seems
to be in violation of 14.6.4.2. A dejagnu-style testcase:
// { dg-do run }
extern C void abort (void);
void f(int) {}
static void f(char) { abort(); }
templateclass T void g(T t) { f(t); }
int
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-21 18:20 ---
This is a dup of bug 19092.
*** This bug has been marked as a duplicate of 19092 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-21 18:20 ---
*** Bug 24977 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from joseph at codesourcery dot com 2005-11-21 18:21 ---
Subject: Re: New: simple hexadecimal number parsed as C99 hex
float
On Mon, 21 Nov 2005, bernie at develer dot com wrote:
This testcase:
int a = 0xe+100;
0xe+100 is a single preprocessing number. If the
--- Comment #20 from pluto at agmk dot net 2005-11-21 18:38 ---
(In reply to comment #19)
(In reply to comment #18)
can we classify this as a code size regression?
No because 3.3.x was also wrong in the sense it did not emit an emms.
ok.
gcc 4.1.0/20051113 with x87/mmx mode
--- Comment #3 from bernie at develer dot com 2005-11-21 18:41 ---
(In reply to comment #2)
0xe+100 is a single preprocessing number. If the end of
http://gcc.gnu.org/onlinedocs/gcc/Incompatibilities.html is unclear,
please let us know how we could have improved it so that you
--- Comment #5 from dje at gcc dot gnu dot org 2005-11-21 18:52 ---
Fixed.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from dje at gcc dot gnu dot org 2005-11-21 18:57 ---
Treelang is a sample language. There is no language type defined for it in any
ABI and no reason to create a type. This actually is a good test that the
assert works for undefined languages.
--
I'm the bad boy on the block
So forgive me
--- Comment #2 from gcc at microbizz dot nl 2005-11-21 19:28 ---
Subject: Trampolines fail on i686-apple-darwin
On closer inspection, the problem is that the stack is non-executable.
Adding the following code (borrowed from gcc/config/netbsd.h) to
darwin.h fixes the problem
Adriaan
--- Comment #5 from aj at gcc dot gnu dot org 2005-11-21 19:47 ---
Ok, understood
--
aj at gcc dot gnu dot org changed:
What|Removed |Added
Status|REOPENED
--- Comment #8 from pcarlini at suse dot de 2005-11-21 19:49 ---
Another thing, about the basic_string warning: in order to figure out whether
that cast is really creating problems, you can add
--enable-fully-dynamic-string: with it the problematic code is not used at all.
(as I
Following code is causing the internal compiler error.
$ cat test.f90
real:: a(5,5)
data a/25*1.0/
data a(1,1), a(3,1), a(1,2), a(3,3) /2*1.0, 2*2.0/
data a(2:5,4) /4*1.0/
end
$ gfortran test.f90
t38.f90:0: internal compiler error: in
--- Comment #7 from pault at gcc dot gnu dot org 2005-11-21 20:03 ---
Subject: Bug 24223
Author: pault
Date: Mon Nov 21 20:02:54 2005
New Revision: 107320
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107320
Log:
2005-11-21 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #4 from pault at gcc dot gnu dot org 2005-11-21 20:03 ---
Subject: Bug 24705
Author: pault
Date: Mon Nov 21 20:02:54 2005
New Revision: 107320
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107320
Log:
2005-11-21 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #3 from janis at gcc dot gnu dot org 2005-11-21 20:27 ---
A regression hunt identified the following patch:
http://gcc.gnu.org/viewcvs?view=revrev=106588
2005-11-07 Paolo Bonzini [EMAIL PROTECTED]
PR target/24230
* config/rs6000/rs6000.c
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-21 20:43 ---
I should note that in Apple's GCC for i686-darwin, they warn about this. I
think they should look into fixing the issue here. Anyways confirmed.
--
pinskia at gcc dot gnu dot org changed:
What
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2005-11-21 20:52
---
Subject: Bug 24432
Author: ebotcazou
Date: Mon Nov 21 20:52:25 2005
New Revision: 107321
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107321
Log:
PR libfortran/24432
*
--- Comment #6 from schnetter at aei dot mpg dot de 2005-11-21 20:53
---
Thanks for finding the reason.
The include file was actually called Time.h, but my file system is case
insensitive.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24970
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2005-11-21 20:53
---
Subject: Bug 24432
Author: ebotcazou
Date: Mon Nov 21 20:53:50 2005
New Revision: 107323
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107323
Log:
PR libfortran/24432
*
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-21 21:02 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
I was too lazy to fix this so instead I was filing a bug.
Anyways DECL_MAIN_P is declared twice in cp-tree.h with the same definition. I
don't know or when it happend but it does.
--
Summary: DECL_MAIN_P is declared twice in cp-tree.h
Product: gcc
Version:
--- Comment #5 from mark at gcc dot gnu dot org 2005-11-21 21:11 ---
As requested by Tom I add the following information from the following
mailinglist thread:
http://thread.gmane.org/gmane.comp.java.classpath.patches/5606
The application that uses this functionality is Caliph Emir
GIJ segfaults on
java-puzzlers/5-exceptional-puzzlers/puzzle-45/Workout.java from Bloch
and Gafter's latest book. (This puzzle is due to Jim Hugunin of
Jython and IronPython fame.)
| $ curl -O http://www.javapuzzlers.com/java-puzzlers.zip
| % Total% Received % Xferd Average Speed Time
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-21 21:18 ---
I think this is a dup of bug 1373.
You should try with optimizations turned on.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24980
--- Comment #2 from vadimn at redhat dot com 2005-11-21 21:20 ---
Created an attachment (id=10315)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10315action=view)
BinaryCallTree.java
For my own education, I wrote a variation of Workout.java that prints
out the call tree in the
--- Comment #3 from vadimn at redhat dot com 2005-11-21 21:34 ---
Yeah, this may be a dup.
Bryce did mention that native-compiling this program with -O2 should
turn on the TCO. There are two problems with this theory. Number
one, it still segfaults for me:
| $ gcj -O2 --main=Workout
--- Comment #4 from vadimn at redhat dot com 2005-11-21 21:40 ---
Created an attachment (id=10316)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10316action=view)
call-tree-of-depth-4.png
So, speaking of stress patterns, this is what the call tree looks like
if you run attachment
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-21 21:46 ---
(In reply to comment #3)
Number two, the TCO cannot possibly be applied in this case. (I can't
see how at the moment, but I'm willing to be convinced otherwise.)
Actually TCO cannot because you still need to
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-11-21 21:46
---
*** Bug 24980 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from vadimn at redhat dot com 2005-11-21 21:52 ---
(In reply to comment #5)
It is not that bizarre as what is happening is that the function is
being marked as a pure function so it does nothing useful, so we
remove it.
Except that under Bryce's GCJ, the function
--- Comment #7 from mckinlay at redhat dot com 2005-11-21 22:02 ---
Except that under Bryce's GCJ, the function terminates successfully
even if you throw in System.out.println's into it, thus tainting its
purity.
No, when I add a System.out.println(hi), and compile with a trunk gcj,
--- Comment #6 from jakub at gcc dot gnu dot org 2005-11-21 22:04 ---
Subject: Bug 21647
Author: jakub
Date: Mon Nov 21 22:03:56 2005
New Revision: 107328
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107328
Log:
gcc/fortran/
PR fortran/14943
PR fortran/21647
--- Comment #4 from jakub at gcc dot gnu dot org 2005-11-21 22:04 ---
Subject: Bug 14943
Author: jakub
Date: Mon Nov 21 22:03:56 2005
New Revision: 107328
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107328
Log:
gcc/fortran/
PR fortran/14943
PR fortran/21647
--- Comment #4 from jakub at gcc dot gnu dot org 2005-11-21 22:04 ---
Subject: Bug 24774
Author: jakub
Date: Mon Nov 21 22:03:56 2005
New Revision: 107328
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107328
Log:
gcc/fortran/
PR fortran/14943
PR fortran/21647
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-21 22:27 ---
Confirmed, as a diagnostic issue only. I am going to mark this as a regression
even though I know that the preprocessor was rewritten between 2.95.3 and
3.0.x.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #2 from kargl at gcc dot gnu dot org 2005-11-21 22:29 ---
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01542.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24917
--- Comment #9 from rguenth at gcc dot gnu dot org 2005-11-21 22:35 ---
Doing both fixed DLV! (now trying without that dynamic string thingie)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24975
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-21 22:53 ---
(In reply to comment #2)
I'm ready to do that, but since complex numbers in C are always a pain, I
want to know: are we sure that conj/conjf/conjl are *always* available? I
mean, are they part of the things gcc
101 - 200 of 239 matches
Mail list logo
