--- Comment #2 from jw203198 at hotmail dot com 2005-11-30 02:07 ---
But surely that example isn't evidence of a problem.
Because if somebody codes:
int *p = f();
does it really matter what the signedness of f()'s return value is?
The caller has a pointer which is most definitely
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2005-11-30 02:09
---
Subject: Bug 25109
Author: jvdelisle
Date: Wed Nov 30 02:09:13 2005
New Revision: 107697
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107697
Log:
2005-11-29 Jerry DeLisle <[EMAIL PROTECTED]>
Create this file, x.c:
main(){}
Then pre-process with, "cc -E -g x.c" (the -g is significant).
The output will contain a line such as:
# 1 "/home/me/testdir//"
This seems to be at odds with all other such annotations.
Why is the current directory output? And why the double /?
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-30 02:13 ---
(In reply to comment #2)
> But surely that example isn't evidence of a problem.
yes it is, since it is invalid code, I repeat it is invalid code. How many
more times do I need to repeat that?
Just add a cast to ge
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-30 02:14 ---
The current directory is outputted so that when compiling with -save-temps -g
is no different from -g. The double // is not really a problem at all.
--
pinskia at gcc dot gnu dot org changed:
What
libjava/testsuite/libjava.lang/Array_3.java has failed on powerpc64-linux for
quite a while. See
http://gcc.gnu.org/ml/gcc-testresults/2005-03/msg01215.html. The problem is
that in
static int baz ()
{
int[] x = (int[])null;
int nn = x.length;
return 5;
}
...
try
{
--- Comment #2 from jw203198 at hotmail dot com 2005-11-30 02:18 ---
(In reply to comment #1)
> The current directory is outputted so that when compiling with -save-temps -g
> is no different from -g. The double // is not really a problem at all.
>
That is rather unfortunate.
Because
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-30 02:24 ---
(In reply to comment #2)
> That is rather unfortunate.
> Because if you use the -H option then you will get different output depending
> on whether you use "-g" or not. So while you might be helping the
> "-save-tem
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-30 02:26 ---
Confirmed, also happens on ppc-darwin. (Note this is most likely on other
targets too, there is a bug about x86_64 and this IIRC to get libuwind to pass
its tests).
--
pinskia at gcc dot gnu dot org changed:
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-30 02:29 ---
Hmm, I really want to say this is a bug with respect of -WSystem-headers (or
what ever the spelling for that option is) as -pedantic-errors should not
warn/error for system headers. It might also be a driver issue t
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-30 02:32 ---
This is obvious an issue, this is what I get on x86_64-linux-gnu:
.comm test_equiv.eq.1_,16,16
.comm test_equiv.eq.1_,16,16
.comm test_equiv.eq.1_,16,16
Though one could say that this i
--- Comment #4 from jw203198 at hotmail dot com 2005-11-30 02:52 ---
Don't you think that forcing people to cast pointers is much much more
dangerous than allowing simple equivalence of pointers when they aren't even
being derefenced?
What about this:
struct x *f() { return ptr;}
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2005-11-30 02:53
---
Subject: Bug 25109
Author: jvdelisle
Date: Wed Nov 30 02:53:18 2005
New Revision: 107699
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107699
Log:
2005-11-29 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #4 from jw203198 at hotmail dot com 2005-11-30 02:55 ---
> Can you show where -H will give you the CWD?
Use my original example and add -H.
I *never* had "-save-temps" in my example so I don't understand why you are
corrupting my example so. And I *never* used a -S flag ei
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-30 03:06 ---
(In reply to comment #4)
> > Can you show where -H will give you the CWD?
> Use my original example and add -H.
Your orginal example does not show a difference for -H at all.
pc64:~> gcc -H t.c -g
pc64:~> gcc -H t.c
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-30 03:08 ---
(In reply to comment #4)
> Don't you think that forcing people to cast pointers is much much more
> dangerous than allowing simple equivalence of pointers when they aren't even
> being derefenced?
No. Read my comme
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
|
Kornel wrote:
g++ crashes for a very long function name ;)
Bugs should be filed into bugzilla, rather than mailed to the gcc-bugs
list. We won't track bugs mailed to the list.
I took a quick look. I couldn't reproduce on my system. However, it
occured to me that gcc is probably trying to
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25169
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-30
03:32 ---
Subject: Re: FAIL: gfortran.dg/module_equivalence_1.f90
> This is obvious an issue, this is what I get on x86_64-linux-gnu:
> .comm test_equiv.eq.1_,16,16
> .comm test_equiv.eq.1_,16,16
--- Comment #6 from jw203198 at hotmail dot com 2005-11-30 03:37 ---
> Your orginal example does not show a difference for -H at all.
Does for me:
pc:~/work/stats $ cc -E -H x.c
# 1 "x.c"
# 1 ""
# 1 ""
# 1 "x.c"
main(){}
and:
pc:~/work/stats $ cc -E -H -g
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-30
03:38 ---
Subject: Re: FAIL: gcc.dg/weak/weak-14.c
> Isn't this just bug 24478?
Yes. However, 24478 didn't have any host/target/build and I didn't
see it.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-30 03:42 ---
(In reply to comment #6)
> > Your orginal example does not show a difference for -H at all.
Wait a minute, -E outputs the preprocessed source. -H outputs the files which
are included.
Again this is not a bug.
-
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-30
03:51 ---
Subject: Re: [4.2 Regression] FAIL: gcc.c-torture/execute/conversion.c
compilation
> As explained in bug 24998, I can't test on PA at present but the fix is
> probably similar to that for IA64.
I'm testi
--- Comment #8 from jw203198 at hotmail dot com 2005-11-30 03:52 ---
(In reply to comment #7)
> (In reply to comment #6)
> > > Your orginal example does not show a difference for -H at all.
> Wait a minute, -E outputs the preprocessed source. -H outputs the files which
> are included.
--- Comment #9 from ian at airs dot com 2005-11-30 04:06 ---
This is documented behaviour.
The -g option enables the -fworking-directory option, as described in the
documentation of -fworking-directory. It is the -fworking-directory option
which is printing the directory name.
If you
--- Comment #6 from joseph at codesourcery dot com 2005-11-30 04:14 ---
Subject: Re: [4.2 Regression] FAIL: gcc.c-torture/execute/conversion.c
compilation
On Wed, 30 Nov 2005, dave at hiauly1 dot hia dot nrc dot ca wrote:
> I'm testing a fix for the current reload problems on the PA.
--- Comment #10 from jw203198 at hotmail dot com 2005-11-30 04:16 ---
>
> If you use -E -H -g -fno-working-directory, you will not see the directory
> name.
Thanks, I can use that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25175
gcc.target/powerpc/pr18096-1.c has not been updated for the changing of the
stack overflowing from a warning to an error.
I don't have access to ppc-darwin to test a fix which is why I am filing a bug.
--
Summary: gcc.target/powerpc/pr18096-1.c fails on PPC
Product: gcc
--- Comment #2 from echristo at apple dot com 2005-11-30 06:29 ---
Patch committed.
--
echristo at apple dot com changed:
What|Removed |Added
Status|ASSIGNED
101 - 130 of 130 matches
Mail list logo
