--- Comment #7 from jakub at gcc dot gnu dot org 2009-04-06 08:13 ---
Closing then.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONF
--- Comment #3 from janus at gcc dot gnu dot org 2009-04-06 08:33 ---
Subject: Bug 39414
Author: janus
Date: Mon Apr 6 08:33:31 2009
New Revision: 145583
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145583
Log:
2009-04-06 Janus Weil
PR fortran/39414
* decl.c
--- Comment #4 from janus at gcc dot gnu dot org 2009-04-06 08:36 ---
Committed as r145583. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rainer at emrich-ebersheim dot de 2009-04-06 08:53
---
This is a regression because it used to work for gcc-4.4.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39610
...
/bin/sh ../libtool --tag CXX --mode=compile
/home/ayers/gcc/trunk/build/./gcc/xgcc -shared-libgcc
-B/home/ayers/gcc/trunk/build/./gcc -nostdinc++
-L/home/ayers/gcc/trunk/build/i686-pc-linux-gnu/libstdc++-v3/src
-L/home/ayers/gcc/trunk/build/i686-pc-linux-gnu/libstdc++-v3/src/.libs
-B/usr/local/
--- Comment #1 from dodji at gcc dot gnu dot org 2009-04-06 08:50 ---
Confirmed on gcc trunk.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #1 from ayers at gcc dot gnu dot org 2009-04-06 09:04 ---
Possibly related: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39610
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39659
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-06 09:11 ---
*** Bug 39649 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #14 from paolo dot carlini at oracle dot com 2009-04-06 09:34
---
Thanks Hans-Peter. If you can analyze a bit more the stdint.h issues it would
be great. In particular, I would like to know if on such targets stdint.h is
available at C++ library configure time, the configure
--- Comment #4 from ayers at gcc dot gnu dot org 2009-04-06 10:06 ---
The patch fixes the build... a new bootstrap is in progress.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39659
--- Comment #6 from pault at gcc dot gnu dot org 2009-04-06 11:07 ---
Fixed on trunk and 4.4
Thanks for the report
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from ayers at gcc dot gnu dot org 2009-04-06 11:07 ---
Bootstrap completed successfully, thanks for the fast patch!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39659
--- Comment #6 from pault at gcc dot gnu dot org 2009-04-06 11:07 ---
Fixed on trunk and 4.4
Thanks for the report
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
Latest svn version (and for the past few weeks) stops in compilation with
../../gcc4svnsource/gcc/config/i386/host-mingw32.c: In function
'mingw32_gt_pch_use_address':
../../gcc4svnsource/gcc/config/i386/host-mingw32.c:140: error: ISO C90 forbids
mixed declarations and code
Mingw. Using a recent
--- Comment #18 from pault at gcc dot gnu dot org 2009-04-06 10:52 ---
Fixed on trunk. I am prepared to backport but the mood appears to be against
it.
Thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pault at gcc dot gnu dot org 2009-04-06 10:54 ---
Fixed on trunk. I am prepared to backport but the mood appears to be against
it.
Thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org
--- Comment #5 from pault at gcc dot gnu dot org 2009-04-06 10:54 ---
Fixed on trunk. I am prepared to backport but the mood appears to be against
it.
Thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-04-06 11:14 ---
For cris-axis-elf we do not fold
one_1 = 1.0e+0;
oneL_2 = 1.0e+0;
__builtin_sincos (1.0e+0, &s, &c);
to a constant because __builtin_sincos did not get transformed to
__builtin_cexpi.
We fold it later via th
--- Comment #2 from dodji at gcc dot gnu dot org 2009-04-06 10:28 ---
Created an attachment (id=17593)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17593&action=view)
candidate fix
I am regtesting this fix atm.
With it, I get the following error output from g++ trunk from today:
--- Comment #9 from pault at gcc dot gnu dot org 2009-04-06 10:52 ---
Fixed on trunk. I am prepared to backport but the mood appears to be against
it.
Thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from pault at gcc dot gnu dot org 2009-04-06 10:53 ---
Fixed on trunk. I am prepared to backport but the mood appears to be against
it.
Thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from hubicka at gcc dot gnu dot org 2009-04-06 11:24 ---
Subject: Bug 39659
Author: hubicka
Date: Mon Apr 6 11:24:32 2009
New Revision: 145589
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145589
Log:
PR middle-end/39659
* except.c (remove_unrea
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
--- Comment #3 from hubicka at ucw dot cz 2009-04-06 09:28 ---
Subject: Re: [4.5 Regression] ICE building libstdc++v3 functexcept.cc
Hi,
this does not reproduce on my setup, but the following patch should fix it.
Honza
Index: except.c
=
--- Comment #17 from jakub at gcc dot gnu dot org 2009-04-06 08:59 ---
Smaller self-contained testcase:
int z;
void __attribute__((noinline))
bar (int *x)
{
#pragma omp atomic
z += x[2];
x[2] += x[3];
}
int
main ()
{
int i;
#pragma omp parallel for
for (i = 0; i < 65536; i+
--- Comment #23 from dave at boostpro dot com 2009-04-06 09:35 ---
Subject: Re: deep typedef substitution in error message
On Apr 3, 2009, at 11:45 PM, jason at redhat dot com wrote:
>
>
>> Also, I'm not thrilled that
>>
>> boost::sequence::detail::range_maker> CalcSize>::type
>>
>>
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-06 09:39 ---
tree PRE : 362.75 (97%) usr 3.30 (80%) sys 366.55 (97%) wall
7515 kB ( 8%) ggc
So you can use -fno-tree-pre to work around this issue or limit the size
of the SCCs processed (with the same effect)
I understand C is low-level, but I'd love the compiler to refuse to compile or
link a mixed C and C++ code that is not mixed correctly.
The story is: parts of the program are implemented in C, parts are in C++. The
functions in C++ are made callable from C using the "__attribute__((stdcall))"
feat
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-06 09:11 ---
*** This bug has been marked as a duplicate of 39659 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-04-06 11:00 ---
Ok, I can see at least one missed CCP optimization when looking at what
the x86_64 target produces. Now building a cross to see why for cris the
second CCP pass together with either FRE or DOM or the third CCP pass
--- Comment #11 from pault at gcc dot gnu dot org 2009-04-06 10:57 ---
Enfin, j'aborde le boulot
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
I understand C is low-level, but I'd love the compiler to refuse to compile or
link a mixed C and C++ code that is not mixed correctly.
The story is: parts of the program are implemented in C, parts are in C++. The
functions in C++ are made callable from C using the "__attribute__((stdcall))"
feat
--- Comment #1 from pavel dot petrovic at gmail dot com 2009-04-06 12:23
---
Created an attachment (id=17594)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17594&action=view)
archive with all sources, and i. .ii, .s files
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39662
--- Comment #2 from pavel dot petrovic at gmail dot com 2009-04-06 12:28
---
*** Bug 39661 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39662
--- Comment #1 from pavel dot petrovic at gmail dot com 2009-04-06 12:28
---
*** This bug has been marked as a duplicate of 39662 ***
--
pavel dot petrovic at gmail dot com changed:
What|Removed |Added
---
--- Comment #7 from ayers at gcc dot gnu dot org 2009-04-06 12:29 ---
Fixed.
--
ayers at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #15 from hp at gcc dot gnu dot org 2009-04-06 13:36 ---
(In reply to comment #14)
> In particular, I would like to know if on such targets stdint.h is
> available at C++ library configure time, the configure tests succeed
Well *some* configure tests succeed (see "Description
Mingw hosted arm-elf output differs from linux hosted arm-elf when compiling
with -Os and -mthumb for the code added below. Remove -mthumb and the output
won't differ.
Mingw hosted toolchain:
Target: arm-elf
Configured with: ../gcc-4.2.2/configure --target=arm-elf
--prefix=/proj/crossgcc/arm-elf -
--- Comment #16 from paolo dot carlini at oracle dot com 2009-04-06 13:49
---
(In reply to comment #15)
> Well *some* configure tests succeed (see "Description"), but grep says, of
> cris-elf/libstdc++-v3/include/cris-elf/bits/c++config.h:
> /* #undef _GLIBCXX_USE_C99_STDINT_TR1 */
Ok.
--- Comment #1 from info dot gnu at rt-labs dot com 2009-04-06 13:50
---
Created an attachment (id=17595)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17595&action=view)
source file that cause output difference
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39663
--- Comment #2 from info dot gnu at rt-labs dot com 2009-04-06 13:51
---
Created an attachment (id=17596)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17596&action=view)
sample makefile to genererate output difference
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39663
--- Comment #17 from hp at gcc dot gnu dot org 2009-04-06 14:03 ---
(In reply to comment #16)
> I hope my explanation is more clear.
Yes, thanks, sorry I didn't get the picture before.
> The above said, I'm not sure we should spend much time trying to figure out
> why
> for your targe
--- Comment #18 from paolo dot carlini at oracle dot com 2009-04-06 14:13
---
(In reply to comment #17)
> Superficially, it looks as if it fails because stdint.h isn't picked up
> properly by libstdc++ (in contrast to the C test-suite) so I do think this is
> worthwhile. I don't think
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-04-06 14:16 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-04-06 14:16 ---
Subject: Bug 39643
Author: rguenth
Date: Mon Apr 6 14:16:15 2009
New Revision: 145604
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145604
Log:
2009-04-06 Richard Guenther
PR tree-optimization/
--- Comment #19 from paolo dot carlini at oracle dot com 2009-04-06 14:36
---
One final remark: since you are having problem with uint_fast32_t, unqualified,
what really matters is _GLIBCXX_HAVE_STDINT_H, *not*
_GLIBCXX_USE_C99_STDINT_TR1. Have a look to include/c_global/cstdint for
det
--- Comment #19 from rguenth at gcc dot gnu dot org 2009-04-06 14:55
---
Subject: Bug 28868
Author: rguenth
Date: Mon Apr 6 14:55:31 2009
New Revision: 145607
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145607
Log:
2009-04-06 Richard Guenther
PR tree-optimizatio
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-04-06 14:56
---
Fixed for GCC 4.5.0.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Assi
--- Comment #20 from hp at gcc dot gnu dot org 2009-04-06 15:15 ---
(In reply to comment #19)
> One final remark: since you are having problem with uint_fast32_t,
> unqualified,
> what really matters is _GLIBCXX_HAVE_STDINT_H, *not*
> _GLIBCXX_USE_C99_STDINT_TR1.
I see in gccobj/cris-e
--- Comment #21 from paolo dot carlini at oracle dot com 2009-04-06 15:21
---
Interesting. Then you should really look inside the pre-processed
using_namespace_std_tr1_neg.cc and see why uint_fast32_t is not known.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
--- Comment #24 from jason at redhat dot com 2009-04-06 15:32 ---
Subject: Re: deep typedef substitution in error message
dave at boostpro dot com wrote:
> I'm confused as to why you think you need to give a still-dependent
> type in the signature
Because the signature we're printin
--- Comment #22 from paolo dot carlini at oracle dot com 2009-04-06 15:32
---
Probably, somewhere, an _GLIBCXX_USE_C99_STDINT_TR1 is protecting the inclusion
of itself, thus we are back to square one...
If you want - as I said, I don't think it's really a good way to spend our time
-
--- Comment #13 from jason at redhat dot com 2009-04-06 15:39 ---
Subject: Re: C++ ABI needs clarification on mangling of complex
expressions
hjl dot tools at gmail dot com wrote:
> /export/gnu/src/gcc-work/gcc/gcc/testsuite/g++.dg/template/foo.ii:45: sorry,
> unimplemented: mangling
On Linux/ia32 and Linux/x86-64, revision 145573 gave:
Running 436.cactusADM ref base o2 default
Error with
'/export/gnu/import/svn/gcc-test/spec/2006/x86_64/spec/bin/specinvoke
-E -d
/export/gnu/import/svn/gcc-test/spec/2006/x86_64/spec/benchspec/CPU2006/4
36.cactusADM/run/run_base_ref_o2.
--- Comment #1 from hjl dot tools at gmail dot com 2009-04-06 15:42 ---
It may be caused by revision 145571:
http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00193.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
Many fortran tests, like libgfortran.dg/arrayio_9.f90 and
libgfortran.dg/arrayio_10.f90 are failing on IA64 because the IO library is
reading and writing double values to unaligned addresses.
In gdb I see:
(gdb) r
Starting program: /proj/opensrc/nightly/build-ia64-hp-hpux11.23-trunk/x
Program re
--- Comment #1 from sje at cup dot hp dot com 2009-04-06 16:20 ---
I forgot to mention that this failure started with the merging of the
fortran-dev brach into the mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39665
--- Comment #2 from hp at gcc dot gnu dot org 2009-04-06 17:16 ---
It'd be nice to know if -fno-tree-reassoc helped here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39621
[Follow-up to http://gcc.gnu.org/ml/gcc/2009-04/msg00175.html]
$ cat range.f90
FUNCTION f(n)
INTEGER, INTENT(in) :: n
REAL:: f
SELECT CASE (n)
CASE ( :-1); f = -1.0
CASE (0); f = 0.0
CASE (1: ); f = 1.0
END SELECT
END FUNCTION
$> gfortran-svn -c -O -W
See: http://gcc.gnu.org/ml/fortran/2009-04/msg00054.html
Some namelist and utf8/widechar tests now require a working fd_truncate, which
causes failures on systems not offering this.
Thus one should check whether the truncations are really needed.
--
Summary: Possibly unneccesary tru
--- Comment #2 from domob at gcc dot gnu dot org 2009-04-06 18:16 ---
See also this thread: http://gcc.gnu.org/ml/fortran/2009-04/msg00065.html
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from ubizjak at gmail dot com 2009-04-06 18:18 ---
It looks to me that this is a reload bug, independent of IRA. See thread [1]
for analysis of what seems to be the same problem.
[1] http://gcc.gnu.org/ml/gcc/2009-04/msg00033.html
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #6 from ubizjak at gmail dot com 2009-04-06 18:20 ---
(In reply to comment #5)
> It looks to me that this is a reload bug, independent of IRA. See thread [1]
> for analysis of what seems to be the same problem.
>
> [1] http://gcc.gnu.org/ml/gcc/2009-04/msg00033.html
Thread
#define ESP
(rel,value,addr) \
asm volatile ("mov (%%esp, %2, 4), %0\n
\t" \
"lea (%%esp, %2, 4), %1\n
\t" \
: "=r" (value),
"=r" (addr)
--- Comment #8 from js-gcc at webkeks dot org 2009-04-06 19:41 ---
Any news on this? Any way how I could compile libobjc as a shared library?
Specifying --enable-shared breaks basically every library that gcc ships and I
haven't found a way to only enable it for libobjc.
--
http://g
--- Comment #2 from burnus at gcc dot gnu dot org 2009-04-06 19:49 ---
Could you try to reduce the problem - as SPEC is not publicly available it is a
bit hard to debug (by far most gfortraners do not have access to SPEC).
(In reply to comment #1)
> It may be caused by revision 145571:
--- Comment #3 from hjl dot tools at gmail dot com 2009-04-06 19:52 ---
(In reply to comment #2)
> Could you try to reduce the problem - as SPEC is not publicly available it is
> a
> bit hard to debug (by far most gfortraners do not have access to SPEC).
I am working on it.
> (In repl
--- Comment #7 from pault at gcc dot gnu dot org 2009-04-06 20:13 ---
Subject: Bug 38863
Author: pault
Date: Mon Apr 6 20:13:39 2009
New Revision: 145621
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145621
Log:
2009-04-06 Paul Thomas
PR fortran/38863
* dep
--- Comment #8 from jason at gcc dot gnu dot org 2009-04-06 20:14 ---
The testcase in comment #2 is ill-formed;
template <> void foo(S, S*);
is not a specialization of any function template in scope. But we're giving
very much the wrong error for that. Testing
--- Comment #8 from pault at gcc dot gnu dot org 2009-04-06 20:17 ---
Fixed on trunk.
Thanks for the report
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jason at gcc dot gnu dot org 2009-04-06 20:29 ---
...and GCC miscompiles the original testcase due to the same bug.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
---
Fortran code:
INTEGER :: i(3,3)
namelist/namtest/i
i=0
OPEN(10)
CLOSE(10)
READ(10,namtest)
WRITE(6,namtest)
END
Namelist in fort.10:
&namtest
i(1,1)=1,2,3,
i(2,1)=4,5,6,
i(3,1)=7,8,9,
/
Print out of program:
&NAMTEST
I= 1, 4, 7, 0, 6,
--- Comment #10 from jason at gcc dot gnu dot org 2009-04-06 20:55 ---
Subject: Bug 35146
Author: jason
Date: Mon Apr 6 20:55:04 2009
New Revision: 145625
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145625
Log:
PR c++/35146
* pt.c (fn_type_unification): For D
--- Comment #9 from ayers at gcc dot gnu dot org 2009-04-06 21:22 ---
I'm sorry, I'm simply not familiar with cygwin/mingw environments and cross
builds. But I'm surprised that --enable-shared doesn't work. Is that a native
build?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=394
--- Comment #4 from hjl dot tools at gmail dot com 2009-04-06 21:34 ---
It is very hard to extract a small testcase. However, you can
download Cactus from
http://www.cactuscode.org/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
--- Comment #11 from jason at gcc dot gnu dot org 2009-04-06 21:35 ---
Subject: Bug 35146
Author: jason
Date: Mon Apr 6 21:35:29 2009
New Revision: 145634
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145634
Log:
PR c++/35146
* pt.c (fn_type_unification): For D
--- Comment #10 from js-gcc at webkeks dot org 2009-04-06 21:39 ---
What exactly do you mean by native build? Do you mean if I build a compiler to
run on Linux and not on win32, but which targets win32? If so, yes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
--- Comment #2 from janis at gcc dot gnu dot org 2009-04-06 21:39 ---
Surprise, Richard, you fixed this! The failure goes away with r145494, the
merge of the alias-improvements branch.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #11 from ayers at gcc dot gnu dot org 2009-04-06 21:59 ---
With 'native' I meant mingw := build=host=target so no... it's not native in
the sense that I was talking about.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
--- Comment #5 from hjl dot tools at gmail dot com 2009-04-06 22:15 ---
cactusADM has both C and Fortran. The following code
printf("\n");
printf("Done.\n");
in C won't show up when the output is redir
--- Comment #6 from hjl dot tools at gmail dot com 2009-04-06 22:20 ---
Revision 145571 breaks stdio when the output was redirected to a file:
[h[...@gnu-16 pr39664]$ cat foo.c
#include
int
main ()
{
printf("-
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-04-06 22:22 ---
I don't know if this is really a bug. The interaction between Fortran I/O and
C FILE I/O is not defined anywhere.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
--- Comment #10 from eric dot weddington at atmel dot com 2009-04-06 22:38
---
This looks like a duplicate of bug #37466.
*** This bug has been marked as a duplicate of 37466 ***
--
eric dot weddington at atmel dot com changed:
What|Removed |Adde
--- Comment #4 from eric dot weddington at atmel dot com 2009-04-06 22:38
---
*** Bug 39593 has been marked as a duplicate of this bug. ***
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--
--- Comment #8 from hjl dot tools at gmail dot com 2009-04-06 22:41 ---
(In reply to comment #7)
> I don't know if this is really a bug. The interaction between Fortran I/O and
> C FILE I/O is not defined anywhere.
Does it mean that gcc doesn't support mixing C codes which contain stdi
--- Comment #9 from hjl dot tools at gmail dot com 2009-04-06 22:43 ---
This patch seems to work for the small testcase:
Index: io/unix.c
===
--- io/unix.c (revision 145571)
+++ io/unix.c (working copy)
@@ -344,7 +344,1
----
Done.
troutmask:sgk[208] gfc4x --version
GNU Fortran (GCC) 4.5.0 20090406 (experimental)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
--- Comment #11 from pinskia at gcc dot gnu dot org 2009-04-06 22:47
---
(In reply to comment #9)
> This patch seems to work for the small testcase:
This patch looks correct based on the old code:
- if (s->fd != STDOUT_FILENO && s->fd != STDERR_FILENO && s->fd !=
STDIN_FILENO)
-{
--- Comment #12 from hjl dot tools at gmail dot com 2009-04-06 22:53
---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00464.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #13 from hjl dot tools at gmail dot com 2009-04-06 22:57
---
(In reply to comment #10)
>
> Works for me.
> troutmask:sgk[204] ~/work/4x/bin/gcc -c g.c
> troutmask:sgk[205] gfc4x -o z g.o
> troutmask:sgk[206] ./z > zxc
> troutmask:sgk[207] cat zxc
> -
--- Comment #14 from hjl at gcc dot gnu dot org 2009-04-06 23:08 ---
Subject: Bug 39664
Author: hjl
Date: Mon Apr 6 23:07:51 2009
New Revision: 145636
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145636
Log:
2009-04-06 H.J. Lu
PR libgfortran/39664
* io/uni
--- Comment #15 from hjl dot tools at gmail dot com 2009-04-06 23:16
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFI
using a MinGW build of gcov 'gcov (GCC) 3.4.5 (mingw-vista special r3)'
--preserve paths cause mangled output filenames. Say there is a file called
C:/foo/bar.gcda calling 'gcov C:/foo/bar.gcda -o foo --preserve-paths -b' from
'C:\' causes the file 'foo#bar.gcov' to be output in in 'c:\' instead of
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39669
--- Comment #1 from kazeits at rockwellcollins dot com 2009-04-06 23:50
---
Created an attachment (id=17597)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17597&action=view)
test case: zip file containing example project.
unzipping and runing 'make coverage_bad' shows the proble
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-06 23:51 ---
Can you try a newer GCC? 3.4.x has not been supported for a while.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39669
--- Comment #3 from hp at gcc dot gnu dot org 2009-04-07 00:38 ---
The issue is rather 64-bit HOST_WIDE_INT host compared to 32-bit HOST_WIDE_INT
host. (To prove wrong, compare with i686-unknown-linux-gnu instead
x86_64-unknown-linux-gnu or configure and build with 'CC=gcc -m32'.) You
--- Comment #1 from amodra at gcc dot gnu dot org 2009-04-07 00:47 ---
Subject: Bug 39634
Author: amodra
Date: Tue Apr 7 00:47:21 2009
New Revision: 145641
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145641
Log:
PR target/39634
* config.gcc: Merge powerpc-*-l
1 - 100 of 114 matches
Mail list logo
