--- Comment #13 from julian1844 at yahoo dot com 2009-05-04 06:23 ---
(In reply to comment #12)
Should I conclude that the MinGW site is now www.equation.com?
(In reply to comment #11)
(In reply to comment #9, comment #10)
I did not build MinGW 4.3.0. I got it from the official
--- Comment #2 from dominiq at lps dot ens dot fr 2009-05-04 06:30 ---
Confirmed on i686-apple-darwin9, array_memcpy_4.f90.003t.original is
MAIN__ ()
{
struct t d[5];
struct t s[5];
static integer(kind=4) options.0[8] = {68, 255, 0, 0, 0, 1, 0, 1};
_gfortran_set_options (8,
--- Comment #3 from dominiq at lps dot ens dot fr 2009-05-04 06:32 ---
At revision 147065 I get:
MAIN__ ()
{
struct t d[5];
struct t s[5];
static integer(kind=4) options.0[8] = {68, 255, 0, 0, 0, 1, 0, 1};
_gfortran_set_options (8, (void *) options.0);
d =
--- Comment #20 from kreckel at ginac dot de 2009-05-04 06:47 ---
So, Joseph explained that the code should execute as expected, at least with
-frounding-math as a workaround. However, with GCC 4.4 it is still not possible
to write code that takes advantage of those advanced features of
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-04 07:11 ---
Wrong comp.lang.fortran link; the correct one is:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/b3a7e94ddf6b8ff3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39997
--- Comment #10 from jv244 at cam dot ac dot uk 2009-05-04 07:12 ---
This is the outermost stack trace to the segfault (with default 8M stack),
shows the depth of the recursion, and the location:
#174699 0x00528487 in gt_ggc_mx_lang_tree_node (x_p=value optimized
out) at
--- Comment #11 from jv244 at cam dot ac dot uk 2009-05-04 07:49 ---
I have a gdb session open, but I'm rather clueless. I have this:
(gdb) print (*x).generic.type
$5 = {common = {base = {code = RECORD_TYPE, side_effects_flag = 0,
constant_flag = 0, addressable_flag = 0, volatile_flag
--- Comment #10 from dennis dot wassel at googlemail dot com 2009-05-04
08:50 ---
Edited the Known to fail instead of Reported against.
--
dennis dot wassel at googlemail dot com changed:
What|Removed |Added
--- Comment #9 from dennis dot wassel at googlemail dot com 2009-05-04
08:45 ---
Also fails with 4.3.3 (precisely the same error message as 4.3.2)
gfortran -O2 -ftree-parallelize-loops=2 -c ma57.f -o ma57.o
ma57.f: In function 'ma57od':
ma57.f:2724: error: edge from 676 to 686 should
--- Comment #3 from dennis dot wassel at googlemail dot com 2009-05-04
08:55 ---
Also fails with 4.3.3:
gfortran -v pr37744.f90
Driving: gfortran -v pr37744.f90 -lgfortranbegin -lgfortran -lm -shared-libgcc
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
--- Comment #5 from rguenther at suse dot de 2009-05-04 09:01 ---
Subject: Re: [4.5.0 Regression] Revision 147083 failed
gfortran.dg/array_memcpy_4.f90
On Mon, 4 May 2009, dominiq at lps dot ens dot fr wrote:
--- Comment #4 from dominiq at lps dot ens dot fr 2009-05-04 08:59
--- Comment #4 from dominiq at lps dot ens dot fr 2009-05-04 09:06 ---
Also ICE on trunk r147065 powerpc-apple-darwin9 or r147085 i686-apple-darwin9.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37744
--- Comment #1 from pault at gcc dot gnu dot org 2009-05-04 09:10 ---
Dominique,
Thanks for setting this up. I'll poll everybody involved for contributions and
have assigned myself the bug(s).
Cheers
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pault at gcc dot gnu dot org 2009-05-04 09:29 ---
see PR40006: allow type cheating for procedures with an implicit interface
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rearnsha at gcc dot gnu dot org 2009-05-04 09:41
---
(In reply to comment #6)
We can compute the maximum possible function length first. If the length is
not
large enough far jump is not necessary, and we can do this optimization
safely.
No, it's not that
--- Comment #3 from pault at gcc dot gnu dot org 2009-05-04 09:31 ---
...and PR39896 : ICE with -fwhole-file
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from carrot at google dot com 2009-05-04 10:08 ---
Sorry for my ignorance to gcc. What types of instructions reload will add?
Spilling and loading registers? and more?
By reading the the implementation of thumb_far_jump_used_p() I can get the
conclusion that if reload
--- Comment #5 from pault at gcc dot gnu dot org 2009-05-04 10:19 ---
(In reply to comment #2)
It may be worth noting that there are no warnings in the application about
labels not being in the same block as the corresponding GOTO if compiled
without -fwhole-file, but if compiled
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-05-04 09:25 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from dominiq at lps dot ens dot fr 2009-05-04 08:59 ---
This test has been introduced by the patch in
http://gcc.gnu.org/ml/fortran/2007-01/msg00425.html.
The tests gfortran.dg/array_memcpy_[1-3].f90 use
! { dg-final { scan-tree-dump-times memcpy * original } }
So a
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||4.3.3
Summary|[4.4 regression] ICE when |[4.4
--- Comment #6 from pault at gcc dot gnu dot org 2009-05-04 10:31 ---
For some reason that I do not see right now, cs_base in resolve.c is not being
pushed or popped correctly.
Ah yes! resolve_codes nulls out cs_base. The problem is fixed by storing
cs_base before calling
--- Comment #7 from pault at gcc dot gnu dot org 2009-05-04 10:32 ---
I guess that I should take it :-)
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-05-04 11:02 ---
Subject: Bug 40015
Author: rguenth
Date: Mon May 4 11:01:59 2009
New Revision: 147094
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147094
Log:
2009-05-04 Richard Guenther rguent...@suse.de
PR
--- Comment #1 from jakub at gcc dot gnu dot org 2009-05-04 11:26 ---
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00116.html
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from dominiq at lps dot ens dot fr 2009-05-04 11:42 ---
This pr is fixed as long as *-apple-darwin9 is concerned. Due to comments #3 to
#5, I don't close it as fixed. If someone wants to keep this PR open, (s)he
should change subject and priority.
--
--- Comment #15 from dominiq at lps dot ens dot fr 2009-05-04 11:45 ---
This pr is fixed as long as *-apple-darwin9 is concerned. Due to comments #11
to
#13, I don't close it as fixed. If someone wants to keep this PR open, (s)he
should change subject, platform, and priority.
--
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-05-04 12:43 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from manu at gcc dot gnu dot org 2009-05-04 12:48 ---
Subject: Bug 28152
Author: manu
Date: Mon May 4 12:47:53 2009
New Revision: 147097
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147097
Log:
2009-05-04 Manuel Lopez-Ibanez m...@gcc.gnu.org
PR
--- Comment #10 from manu at gcc dot gnu dot org 2009-05-04 12:49 ---
FIXED in GCC 4.5
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
Hi, when i compiling gnu parted 1.8.8 with gcc 4.5.0, got error
include regex.i
TIA
=
/bin/sh ../libtool --tag=CC --mode=compile gcc -std=gnu99 -I. -Os
-Werror -MT regex.lo -MD -MP -MF .deps/regex.Tpo -c -o regex.lo
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-04 14:23 ---
Works for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40016
#include stdbool.h
#include altivec.h
vector bool int b;
int
main (void)
{
return 0;
}
used to compile up to 4.3, doesn't any longer. I wonder what can be done here
though, for C++ with the conditional macros bool keywords can coexist well with
the context sensitive keywords, but
--- Comment #8 from dennis dot wassel at googlemail dot com 2009-05-04
14:18 ---
Marked as 4.3/4.4 regression.
What should I try next? Need I provide any additional info? Any help is much
appreciated!
--
dennis dot wassel at googlemail dot com changed:
What|Removed
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-05-04 14:28 ---
Do not set CFLAGS in
make CFLAGS='-O2' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2
-fno-implicit-templates' profiledbootstrap
or specify your host compiler version.
--
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-05-04 14:29
---
It obviously works for me, you system seems to be messed up / special.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jakub at gcc dot gnu dot org 2009-05-04 14:30 ---
I'd say handling _Bool the same way as bool after vector would be a good idea.
It has a disadvantage that in addition to the (I'd say desirable):
#include stdbool.h
#include altivec.h
...
vector bool int i;
also
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-04 14:32 ---
Yes that seems like the right idea; the altivec specs was written before C99
was out.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from dennis dot wassel at googlemail dot com 2009-05-04
14:55 ---
I just noticed/remembered that [x]gcc only drives the compilers, so I plugged
cc1 into gdb and here is the (somewhat messy, slightly edited) result:
gdb /localdata/install/gcc/gcc-4.4.0-build/./gcc/cc1
--- Comment #21 from laurent at guerby dot net 2009-05-04 14:50 ---
No objection in one week, so closing as WORKSFORME with binutils from CVS =
20090423
--
laurent at guerby dot net changed:
What|Removed |Added
--- Comment #15 from dennis dot wassel at googlemail dot com 2009-05-04
15:09 ---
Created an attachment (id=17796)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17796action=view)
Preprocessed source
Sure!
Attaching preprocessed source of gcc-4.4.0/gcc/config/soft-fp/divtf3.c
--
--- Comment #3 from jakub at gcc dot gnu dot org 2009-05-04 14:52 ---
Not surprisingly when the error is during preprocessing.
regex.h parted ships (why?) is broken by the #elif changes, there is:
#if some_condition_that_is_true_on_sane_targets
...
#elif BITSET_WORD_MAX == (0x +
--- Comment #14 from pinskia at gcc dot gnu dot org 2009-05-04 15:00
---
Yes slightly, it is trying to warn about something which is unitialized. This
works for me on i686-linux-gnu. Can you provide the preprocessed source?
--
pinskia at gcc dot gnu dot org changed:
--- Comment #3 from guerby at gcc dot gnu dot org 2009-05-04 15:32 ---
Subject: Bug 38874
Author: guerby
Date: Mon May 4 15:32:00 2009
New Revision: 147102
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147102
Log:
2009-05-04 Laurent GUERBY laur...@guerby.net
PR
--- Comment #7 from danglin at gcc dot gnu dot org 2009-05-04 15:35 ---
The patch from comment #4 was installed here:
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00018.html
From my perspective, this fixes the 4.5 regression reported here.
Possibly the change should be back ported to fix
--- Comment #8 from luisgpm at linux dot vnet dot ibm dot com 2009-05-04
15:41 ---
Oops... forgot about that bit, sorry.
Compile flags: -m32 -O3 -mcpu=power[4|5|6] -ffast-math -ftree-loop-linear
-funroll-loops -fpeel-loops
This reproduces on both 32-bit and 64-bit.
Luis
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #9 from luisgpm at linux dot vnet dot ibm dot com 2009-05-04
15:50 ---
Follows the configure options, although i think you'll be able to reproduce it
with the flags i've mentioned.
/gcc/HEAD/configure --target=powerpc64-linux --host=powerpc64-linux
--build=powerpc64-linux
--- Comment #11 from dennis dot wassel at googlemail dot com 2009-05-04
14:35 ---
(In reply to comment #9)
Do not set CFLAGS in
make CFLAGS='-O2' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2
-fno-implicit-templates' profiledbootstrap
This ^ was only in my first iteration, and I've
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2009-05-04
13:48 ---
Subject: Re: [4.5 Regression] SEGV compiling libiberty/regex.c in stage2
Which pass? p *pass in frame 20 should tell you.
(gdb) p *pass
$1 = {type = GIMPLE_PASS, name = 0x27bb734 forwprop,
gate =
--- Comment #7 from matz at gcc dot gnu dot org 2009-05-04 14:37 ---
Compile options please. I can't reproduce it with a powerpc64 compiler
with -O2, neither with -m32 nor -m64, -ffast-math or no -ffast-math.
Also 'gcc -v' can't hurt to make sure our compilers are configured the same.
--- Comment #1 from happyarch at gmail dot com 2009-05-04 13:59 ---
Created an attachment (id=17795)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17795action=view)
.i file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40016
--- Comment #10 from matz at gcc dot gnu dot org 2009-05-04 16:10 ---
Yes, I can now, thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
--- Comment #12 from dennis dot wassel at googlemail dot com 2009-05-04
14:43 ---
(In reply to comment #10)
It obviously works for me, you system seems to be messed up / special.
Seems so, although it is a Debian 4 with an unknown amount of modifications by
our admin.
One symptom of
--- Comment #3 from jakub at gcc dot gnu dot org 2009-05-04 14:39 ---
_Bool would need to be a conditional macro too though, I wonder if some ISO C99
pedantry can't test that _Bool isn't defined or something like that.
But then for C++ it is similar with defined(bool) also being true
--- Comment #6 from luisgpm at linux dot vnet dot ibm dot com 2009-05-04
13:50 ---
Just for the sake of information, -fselective-scheduling doesn't help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
--- Comment #4 from dominiq at lps dot ens dot fr 2009-05-04 17:54 ---
With thee patch in http://gcc.gnu.org/ml/fortran/2009-05/msg00056.html without
type cheating, all the ICEs in my tests are gone. It even fixes pr37744!-(it
may give a clue on how to fix it without -fwhole-file).
For
--- Comment #8 from dfranke at gcc dot gnu dot org 2009-05-04 18:08 ---
Paul, your patch fixes all issues I came across when compiling my largish set
of fortran sources with -fwhole-file. So, now I just need to sort out all the
warnings that came up *cough* ;)
Many thanks!
--
$ cat a.f90
integer(kind=8) :: i
write(*,*) [(i, i = 1, 10)]
end
$ gfortran a.f90
a.f90:2: internal compiler error: in output_constructor, at varasm.c:4712
The GDB backtrace is:
#0 fancy_abort (file=0xd7999a ../../trunk/gcc/varasm.c, line=4716,
function=0xd792d0 output_constructor)
--- Comment #1 from dominiq at lps dot ens dot fr 2009-05-04 19:19 ---
Confirmed on trunk and 4.4.0. Works with 4.3.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40018
LEADZ and TRAILZ can give wrong results for kinds other than 4 and 8. For
example, the following code:
integer(kind=1) :: i1
integer(kind=2) :: i2
integer(kind=4) :: i4
integer(kind=8) :: i8
integer(kind=16) :: i16
i1 = -1
i2 = -1
i4 = -1
i8 = -1
i16 = -1
print *,
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-05-04 19:37
---
About POPCNT and POPPAR, beware! Implementations are much harder than simply
using the GCC __builtin_popcount{,l,ll}: see PR40019 for similar issue with
LEADZ and TRAILZ.
--
--- Comment #10 from janis at gcc dot gnu dot org 2009-05-04 19:50 ---
Fixed for trunk, expected to become GCC 4.5.0.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from janis at gcc dot gnu dot org 2009-05-04 19:55 ---
This was fixed in trunk, expected to become GCC 4.5.0, on 2009-04-01 as
revision 145422. The ChangeLog entries have the correct PR number but the svn
log messages use 29027, which is why the checkins were not
--- Comment #10 from mikael at gcc dot gnu dot org 2009-05-04 20:24 ---
cf PR36462
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39772
--- Comment #13 from mikael at gcc dot gnu dot org 2009-05-04 20:27 ---
(In reply to comment #12)
don't know how to use it to compile gcc being a normal user (no root
privileges) without scrambling everything else. Any help on this direction?
Thanks
export
--- Comment #3 from hjl dot tools at gmail dot com 2009-05-04 20:44 ---
blas.fppized.f was miscompiled by
-m32 -c -O3 -msse2 -mfpmath=sse -ffast-math -fno-inline-functions
-funroll-loops -ffixed-form
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39973
--- Comment #4 from hjl dot tools at gmail dot com 2009-05-04 20:52 ---
blas.f90 was miscompiled by
-m32 -O3 -msse2 -mfpmath=sse -ffast-math -fno-inline-functions -funroll-loops
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39972
--- Comment #3 from janis at gcc dot gnu dot org 2009-05-04 21:24 ---
On x86_64 with a 64-bit compiler, positive decimal float constants are OK,
negative decimal float constants are wrong for both -m64 (the default) and
-m32.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39986
I tried to migrate well running program from g77 to gfortran.
I found a problem with new gfortan:
Fortran runtime error: Bad value during floating point read
to read REAL from file.
read(nin,'(6e11.0)') a
and numbers were:
7.73118- 3 4.26617+ 0 8.17285- 3 ...
It helps to add number '0' to
On Linux/ia32, revision 146817 miscompiled DAXPY in BLAS with
-m32 O3 -msse2 -mfpmath=sse -ffast-math -fno-inline-functions -funroll-loops
-ffixed-form
--
Summary: [4.5 Regression] Revision 146817 miscompiled DAXPY in
BLAS
Product: gcc
--- Comment #5 from dominiq at lps dot ens dot fr 2009-05-04 21:52 ---
With the patch in http://gcc.gnu.org/ml/fortran/2009-05/msg00056.html
gas_dyn.f90 fails as in commet #0, except for -O1:
[ibook-dhum] lin/test% gfc -O1 -fwhole-file gas_dyn.f90
gas_dyn.f90: In function 'chozdt':
--- Comment #1 from hjl dot tools at gmail dot com 2009-05-04 21:52 ---
*** Bug 39972 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40021
--- Comment #5 from hjl dot tools at gmail dot com 2009-05-04 21:52 ---
*** This bug has been marked as a duplicate of 40021 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #4 from hjl dot tools at gmail dot com 2009-05-04 21:53 ---
*** This bug has been marked as a duplicate of 40021 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2009-05-04 21:53 ---
*** Bug 39973 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40021
--- Comment #1 from kargl at gcc dot gnu dot org 2009-05-04 22:17 ---
(In reply to comment #0)
I tried to migrate well running program from g77 to gfortran.
I found a problem with new gfortan:
Fortran runtime error: Bad value during floating point read
to read REAL from file.
--- Comment #6 from dominiq at lps dot ens dot fr 2009-05-04 22:20 ---
Regtest gives:
=== gfortran Summary ===
# of expected passes117714
# of unexpected failures576
# of expected failures 78
# of unsupported tests 906
for
--- Comment #3 from bkoz at gcc dot gnu dot org 2009-05-04 22:33 ---
No feedback.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from dominiq at lps dot ens dot fr 2009-05-04 22:44 ---
Also gfortran.dg/contained_3.f90 is miscompiled with -fwhole-file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
--- Comment #3 from hjl dot tools at gmail dot com 2009-05-04 23:07 ---
Created an attachment (id=17797)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17797action=view)
A testcase
[...@gnu-33 pr40021]$ make
/export/gnu/import/rrs/146817/usr/bin/gfortran -m32 -c -O3 -msse2
Hello, I have to admit I'm clueless about how to debug this.
On Fedora 11 preview release with gcc-4.4.0 alpine reply to all
does not include the list of cc'd addresses. Linus found that if
you compile the pith/reply.cc without optimizations it works
properly (see Fedora bug report at
--- Comment #4 from hjl dot tools at gmail dot com 2009-05-04 23:09 ---
The vectorizer seems broken:
/export/gnu/import/rrs/146817/usr/bin/gfortran -m32 -c -O2 -ftree-vectorize
-msse2 -mfpmath=sse -ffast-math -ffixed-form test.f
/export/gnu/import/rrs/146817/usr/bin/gfortran -m32 -c
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-04 23:16 ---
Hmm, so -fwrapv and -fno-strict-aliasing fixes the problem which case it might
be a bug in the source.
Can you provide the preprocessed source of pith/reply.cc?
--
pinskia at gcc dot gnu dot org changed:
--- Comment #2 from joshuadfranklin at yahoo dot com 2009-05-04 23:36
---
Created an attachment (id=17798)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17798action=view)
alpine pith/reply.c compiled with O0 and save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022
--
joshuadfranklin at yahoo dot com changed:
What|Removed |Added
CC||joshuadfranklin at yahoo dot
|
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-05-04 23:55 ---
That is the assembler that is produced not the preprocessed source, use
-save-temps and attach the .ii file.
Thanks,
Andrew Pinski
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from joshuadfranklin at yahoo dot com 2009-05-05 00:00
---
Created an attachment (id=17799)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17799action=view)
alpine pith/reply.c compiled with save-temps
'
My compile line:
gcc -c -save-temps -std=gnu99
--- Comment #5 from joshuadfranklin at yahoo dot com 2009-05-05 00:01
---
(In reply to comment #3)
That is the assembler that is produced not the preprocessed source, use
-save-temps and attach the .ii file.
Sorry. Does this one look right? It's actually .c I typo'd the .cc.
--
--- Comment #5 from hjl dot tools at gmail dot com 2009-05-05 00:45 ---
Created an attachment (id=17800)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17800action=view)
A testcase
[...@gnu-33 pr40021]$ make
/export/gnu/import/rrs/146817/usr/bin/gfortran -m32 -c -O2
--- Comment #8 from jv244 at cam dot ac dot uk 2009-05-05 04:18 ---
(In reply to comment #6)
opt/gcc/gcc-4.5-work/gcc/testsuite/gfortran.dg/import6.f90:42.13:
call func1(x)
1
Error: Type mismatch in argument 'param' at (1); passed TYPE(my_type) to
TYPE(my_type)
91 matches
Mail list logo
