--- Comment #28 from burnus at gcc dot gnu dot org 2009-07-15 09:41 ---
(In reply to comment #24)
> So maybe approach the question differently. Which element in an array of NaNs
> is the smallest one and what is its value? If I pick any one element, its
> "value" i
--- Comment #6 from burnus at gcc dot gnu dot org 2009-07-15 20:27 ---
You should also add -march=native to the command line; it probably does not
help much, bit it should help a bit. I recall also the standard GLIBC misses
some optimized version for math on x86-64 while AMD provides
--- Comment #13 from burnus at gcc dot gnu dot org 2009-07-16 09:43 ---
See PR 40770 for "Vectorization of complex types, vectorization of sincos
missing"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40766
--- Comment #4 from burnus at gcc dot gnu dot org 2009-07-16 13:32 ---
(In reply to comment #3)
> Yes - there is no vector type for complex double. But the vectorizer
> could query for a vector type for the complex component type (double)
> and divide the vector element count
--- Comment #2 from burnus at gcc dot gnu dot org 2009-07-20 08:32 ---
Further simplified test below. Valgrind shows first:
==29083== Conditional jump or move depends on uninitialised value(s)
==29083==at 0x4007E4: MAIN__ (aa.f90:12)
The problem is that t2's y is unallo
--- Comment #4 from burnus at gcc dot gnu dot org 2009-07-21 08:06 ---
Also works with -m32 (= i386) on x86-64-linux. (For completeness: There is a
2GB problem for FTELL, cf. PR 39654, due to the ABI.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40812
--- Comment #5 from burnus at gcc dot gnu dot org 2009-07-22 07:10 ---
Reduced test case. The crucial part is the span ("1:2") in the assignment - and
that "Ro" is use-associated.
Dump:
tf_ad_splitting_driver_plane ()
{ [...]
extern integer(kind=8) span.0 = 0;
--- Comment #6 from burnus at gcc dot gnu dot org 2009-07-22 07:12 ---
Paul, do you immediately see what goes wrong here? If not, I can also dig
myself.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2009-07-22 08:11 ---
The error comes about since with -std=2003, asinh is not an available
intrinsic. Solution for the testcase/attached file: "-fall-intrinsics" or
removal of a(sin,cos,tan)h - which were added only with F2008
--- Comment #5 from burnus at gcc dot gnu dot org 2009-07-22 08:14 ---
The patch is indeed obvious (and OK). Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40796
--- Comment #3 from burnus at gcc dot gnu dot org 2009-07-22 08:38 ---
Found it: In "resolve_function" one has:
switch (procedure_kind (sym))
{
case PTYPE_GENERIC: ...
case PTYPE_SPECIFIC: ...
case PTYPE_UNKNOWN: ...
The correct branc
--- Comment #7 from burnus at gcc dot gnu dot org 2009-07-22 09:20 ---
My current understanding is that "span" is only created (in
gfc_get_symbol_decl)
if (sym->attr.subref_array_pointer)
is true - and is then assumed to live at the same place as the symbol (array
descr
--- Comment #2 from burnus at gcc dot gnu dot org 2009-07-22 11:53 ---
Crash happens at:
resolve_fl_variable (gfc_symbol *sym, int mp_flag)
[...]
if (sym->ts.type == BT_CHARACTER)
{
/* Make sure that character string variables with assumed length are
du
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40824
--- Comment #4 from burnus at gcc dot gnu dot org 2009-07-23 08:52 ---
Hmm, to early, the gfc_*_intrinsic are not called, unless attr.intrinsic is
set. The but the issue is indeed that they are regarded as PTYPE_SPECIFIC and
not as PTYPE_UNKNOWN, as a printf in resolve_function shows
--- Comment #30 from burnus at gcc dot gnu dot org 2009-07-24 08:19 ---
Regarding the just committed inline version: It would be interesting to know
whether it is vectorizable (with/without -ffinite-math-only [i.e.
-ffast-math]).
Additionally, for size-1 result arrays, the function
--- Comment #29 from burnus at gcc dot gnu dot org 2009-07-24 08:21 ---
Probably fixed by the commit of PR 40643 comment 7
Author: jakub
Date: Fri Jul 24 07:57:13 2009
New Revision: 150041
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150041
Log:
PR fortr
--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-24 18:41 ---
Confirmed. Janus - I think it could be do to your 4.5 argument checking
patches.
==8885== Invalid read of size 8
==8885==at 0x4C2050: compare_type_rank (interface.c:474)
==8885==by 0x4C20C4
--- Comment #2 from burnus at gcc dot gnu dot org 2009-07-25 06:55 ---
CONFIRM. Affects all GCC with pointer intent (4.3/4.4/4.5). For
subroutine set_ptr (ptr)
type(string_container), pointer, intent(out) :: ptr
one shall not deallocate the pointer. The pointer intent is
--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-25 07:32 ---
CONFIRM - happens with 4.2/4.3/4.4/4.5.
==13529== Invalid read of size 8
==13529==at 0x400F2A: __mod_all_MOD_add (in /dev/shm/a.out)
==13529== Address 0x58d56c8 is 8 bytes inside a block of size 112 free&#
--- Comment #5 from burnus at gcc dot gnu dot org 2009-07-25 17:09 ---
(In reply to comment #4)
> I am inclined to leave this as is because it is a common practice to use
> positions 73 thru 80 for indexing in legacy fixed form code. (Remember those
> punch cards!)
Yes - and t
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot
|dot org
--- Comment #29 from burnus at gcc dot gnu dot org 2009-07-25 19:39 ---
Subject: Bug 33197
Author: burnus
Date: Sat Jul 25 19:39:07 2009
New Revision: 150087
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150087
Log:
2009-07-25 Tobias Burnus
Francoi
--- Comment #30 from burnus at gcc dot gnu dot org 2009-07-25 19:44 ---
(Patch was approved by Steve on IRC.)
TODO (carried on):
- Support inverse functions as initialization expressions, when MPC is ready
- TAN(X,Y) (= TAN2(X,Y)) - and fix wrong TAN2 description in intrinsic.texi
--- Comment #33 from burnus at gcc dot gnu dot org 2009-07-26 09:50 ---
(In reply to comment #32)
> > Regarding the just committed inline version: It would be interesting to know
> > whether it is vectorizable (with/without -ffinite-math-only [i.e.
> > -ffast-math]).
--- Comment #31 from burnus at gcc dot gnu dot org 2009-07-26 17:26 ---
Subject: Bug 33197
Author: burnus
Date: Sun Jul 26 17:25:56 2009
New Revision: 150100
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150100
Log:
2009-07-26 Tobias Burnus
PR fortr
--- Comment #2 from burnus at gcc dot gnu dot org 2009-07-26 18:42 ---
Created an attachment (id=18255)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18255&action=view)
Draft patch
Patch. As I cannot test all the combinations, I would be happy if someone could
test it or r
--- Comment #6 from burnus at gcc dot gnu dot org 2009-07-26 20:28 ---
(In reply to comment #4)
> The prototype warnings have been there foreever.
They should be fixed with the patch ... Do they still appear?
> On hpux, the error
> appears as a result of your change:
>
--- Comment #7 from burnus at gcc dot gnu dot org 2009-07-26 20:32 ---
(In reply to comment #6)
> Can you try whether the following works (place somewhere in
> intrinsics/c99_functions.c):
Enhanced version with yet another version for I:
#ifndef I
# if defined(_Imaginary_I)
#
--- Comment #35 from burnus at gcc dot gnu dot org 2009-07-27 09:18 ---
(In reply to comment #34)
> Does ifort vectorize the exact same implemantion of minloc?
I tried to convert the minloc implementation into Fortran loops - and the
result is at
http://users.physik.fu-berlin
--- Comment #10 from burnus at gcc dot gnu dot org 2009-07-27 09:24 ---
Subject: Bug 40863
Author: burnus
Date: Mon Jul 27 09:24:41 2009
New Revision: 150107
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150107
Log:
2009-07-27 Tobias Burnus
PR fortr
--- Comment #11 from burnus at gcc dot gnu dot org 2009-07-27 09:27 ---
FIXED on the trunk (4.5). Thanks for the bug report and sorry for the breakage.
Feel free to open a PR if build warnings show up in libgfortran. In principle,
there should be none. (I have forgotten why we cannot
--- Comment #3 from burnus at gcc dot gnu dot org 2009-07-27 09:32 ---
Subject: Bug 40851
Author: burnus
Date: Mon Jul 27 09:32:20 2009
New Revision: 150108
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150108
Log:
2009-07-26 Tobias Burnus
PR fortr
--- Comment #4 from burnus at gcc dot gnu dot org 2009-07-27 09:33 ---
Thanks for the report. FIXED on the trunk (4.5); I will soon backport it to
4.4/4.3.
(Workaround: Do not use INTENT for pointers [which is a Fortran 2003 feature].)
--
burnus at gcc dot gnu dot org changed
--- Comment #2 from burnus at gcc dot gnu dot org 2009-07-27 09:40 ---
Confirmed. Fails with gfortran 4.1 to 4.5 and is thus no regression, but it
works with ifort, g95, openf95, and NAG f95.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from burnus at gcc dot gnu dot org 2009-07-27 10:08 ---
The following looks wrong:
gfc_resolve_transfer (gfc_expr *f, gfc_expr *source ATTRIBUTE_UNUSED,
gfc_expr *mold, gfc_expr *size)
[...]
if (mold->ts.type == BT_CHARACTER && !
--- Comment #3 from burnus at gcc dot gnu dot org 2009-07-27 12:57 ---
The real issue is that mold->expr_type is EXPR_VARIABLE and not EXPR_ARRAY. In
gfc_simplify_transfer everything is fine: mold->expr_type is EXPR_ARRAY but in
gfc_resolve_transfer it is already wrong. Must go
--- Comment #39 from burnus at gcc dot gnu dot org 2009-07-27 13:15 ---
(In reply to comment #38)
> However, the loop can be split: [..]
> making the first loop vectorizable (inner-most loop vectorization).
OK. I tried it with a Fortran program:
http://users.physik.fu-ber
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40873
--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-27 14:47 ---
(Note: -fwhole-program implies -fwhole-file; the -O option is required.)
Test case. Run with "-O1 -fwhole-program".
Fails with: test.f90:(.text+0x1b): undefined reference to `three_'
program pr
--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-28 08:33 ---
In a similar vain: One could introduct an option to disable warning for the
deleted features (such as using real-valued loops) - currently, those warnings
alre always printed, hiding other warnings in all the output
--- Comment #14 from burnus at gcc dot gnu dot org 2009-07-28 09:57 ---
(In reply to comment #13)
> Still missing in intrinsics (at least as far as
For those which have one-dimensional arrays, one should consider adding the
checks in trans*.c as this is faster for the non -fcheck=bou
--- Comment #4 from burnus at gcc dot gnu dot org 2009-07-28 14:43 ---
(In reply to comment #1)
> I certainly can't reproduce any kind of segfault with this.
Neither can I. Regarding both examples (comment 0 and comment 1), ifort 11.1
happily accepts both.
I am not sure wheth
--- Comment #3 from burnus at gcc dot gnu dot org 2009-07-28 18:09 ---
> Could somone check if this pr has not been fixed (hidden) by some recent
> changes? It works on powerpc-apple-darwin9 at revision 150097 (it did not work
> on i686-apple-darwin9 at this revision) on i
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40898
--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-29 07:04 ---
Function declaration
function LoadLibrary(lpFileName) bind(C,name='LoadLibraryA')
!gcc$ ATTRIBUTES STDCALL :: LoadLibrary
use ISO_C_BINDING
... and use
hmodule = LoadLibrary('fu
--- Comment #2 from burnus at gcc dot gnu dot org 2009-07-29 07:27 ---
>From the thread at c.l.f:
"A little testing revealed that the assembly code is correct, only the mangled
name is wrong when there is a character argument. Perhaps the mangled name
takes into account a
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40899
--- Comment #5 from burnus at gcc dot gnu dot org 2009-07-29 09:35 ---
Subject: Bug 40851
Author: burnus
Date: Wed Jul 29 09:35:15 2009
New Revision: 150203
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150203
Log:
2009-07-29 Tobias Burnus
PR fortr
--- Comment #4 from burnus at gcc dot gnu dot org 2009-07-29 10:20 ---
FX: As you seemingly have a working cross compiler: Can you check the patch
below?
(One does not need to consider the return value as gfc_return_by_reference
deals with that. Only the last change is relevant, the
normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40904
--- Comment #6 from burnus at gcc dot gnu dot org 2009-07-29 14:45 ---
Subject: Bug 40898
Author: burnus
Date: Wed Jul 29 14:44:51 2009
New Revision: 150216
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150216
Log:
2009-07-29 Tobias Burnus
PR fortr
--- Comment #7 from burnus at gcc dot gnu dot org 2009-07-29 14:47 ---
FIXED on the trunk (4.5) - does not affect any branch.
(In reply to comment #5)
> The patch seems to work:
It caused a regression when I tried to regtest it as I missed another
(follow-up) place, cf. h
--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-30 19:07 ---
See also http://gcc.gnu.org/ml/fortran/2009-07/msg00260.html and PR 40899.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38319
--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-30 19:07 ---
See PR 38319
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40899
: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40920
--- Comment #6 from burnus at gcc dot gnu dot org 2009-08-03 07:04 ---
(In reply to comment #3)
> The warnings about deleted features can be turned off via -std=legacy, and are
> turned into errors by -std=f95 and above.
I think I would like to see a way to disable them with -s
--- Comment #1 from burnus at gcc dot gnu dot org 2009-08-03 09:53 ---
Could not find the problem so far, cf. symbol.c's verify_bind_c_derived_type as
starting point.
* * *
The following TODO should be checked; I heard it is invalid C99 (as per grammar
in 6.7.2.1 Structure and
--- Comment #2 from burnus at gcc dot gnu dot org 2009-08-03 21:14 ---
See also:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/eb7ca487876d9420
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40875
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40955
--- Comment #3 from burnus at gcc dot gnu dot org 2009-08-03 21:16 ---
(In reply to comment #2)
> See also: [...]
Mis-pasted. That should go to PR 40955 - sorry for the spam.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40875
--- Comment #1 from burnus at gcc dot gnu dot org 2009-08-03 22:34 ---
Mine! -- Patch:
Index: gcc/fortran/module.c
===
--- gcc/fortran/module.c(Revision 150376)
+++ gcc/fortran/module.c(Arbeitskopie
--- Comment #1 from burnus at gcc dot gnu dot org 2009-08-03 23:17 ---
> I see the Fortran FE accepts excess parameters to functions and only warns
> for that with -fwhole-file ...
Well, that's not surprising - if the function is not in CONTAINS
(internal/module procedu
--- Comment #2 from burnus at gcc dot gnu dot org 2009-08-04 09:34 ---
The following patch is also missing. Probably appears when using abstract
interfaces. One needs to check the proc pointer machinery as well as there one
might also miss such an option - there, one might also need to
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40961
--- Comment #3 from burnus at gcc dot gnu dot org 2009-08-04 16:09 ---
Thomas, as you know a bit about the array descriptor, can you have a look? The
problem seems to be in libgfortran/intrinsics/iso_c_binding.c's c_f_pointer*
Simplified test case:
One: 1 2 -1 -2
Two: 1 2
--- Comment #2 from burnus at gcc dot gnu dot org 2009-08-04 16:14 ---
The issue is that the expression is an array ("expr->rank > 0") but the symbol
itself is not, only it's component.
==16545== Invalid read of size 4
==16545==at 0x55343F: gfc_conv_procedu
--- Comment #3 from burnus at gcc dot gnu dot org 2009-08-04 17:36 ---
Subject: Bug 40949
Author: burnus
Date: Tue Aug 4 17:35:59 2009
New Revision: 150465
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150465
Log:
2009-08-04 Tobias Burnus
PR fortr
--- Comment #4 from burnus at gcc dot gnu dot org 2009-08-04 22:36 ---
FIXED on the trunk.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2009-08-05 07:19 ---
Works for me on x86-64-linux and seems also to work on several other systems
according to the testresults mailing list.
(Only failure - your ia64 system:
http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg00487.html
--- Comment #3 from burnus at gcc dot gnu dot org 2009-08-05 08:00 ---
Regarding gfc_copy_attr: The following program should print on x86-64(-linux)
the warnings:
warning: 'dllexport' attribute directive ignored
warning: 'stdcall' attribute directive ignored
--- Comment #4 from burnus at gcc dot gnu dot org 2009-08-05 12:50 ---
(In reply to comment #3)
> Tobias, do you remember any of your thoughts when writing this?
Well, they are essentially written in the patch email (linked from the PR
40383):
http://gcc.gnu.org/ml/gcc-patches/2
ct: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40973
--- Comment #9 from burnus at gcc dot gnu dot org 2009-08-05 19:33 ---
(In reply to comment #6)
> 21if ( a1 != *a2 ) abort();
> (gdb) p a1
> $1 = 0
> (gdb) p *a2
> $2 = 42
Thanks! I think the following patch should cure this. I think we will still
have issues wit
diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40976
--- Comment #12 from burnus at gcc dot gnu dot org 2009-08-05 20:03 ---
(In reply to comment #10)
> It failed at a different place:
> 61if ( c1 != *c2) abort();
> (gdb) p c1
> $1 = 43 + 0 * I
> (gdb) p *c2
> $2 = -1 + 2 * I
Hmm, I honestly have no idea why
dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40978
--- Comment #13 from burnus at gcc dot gnu dot org 2009-08-05 20:36 ---
(In reply to comment #11)
> This patch works:
> + if (typelist || sym->attr.if_source != IFSRC_UNKNOWN)
> +typelist = gfc_chainon_list (typelist, void_type_node);
That patch essentially undoes the
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot
|dot org
--- Comment #1 from burnus at gcc dot gnu dot org 2009-08-05 20:43 ---
See also vaguely related PR 40978.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from burnus at gcc dot gnu dot org 2009-08-05 20:47 ---
Subject: Bug 40949
Author: burnus
Date: Wed Aug 5 20:47:19 2009
New Revision: 150500
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150500
Log:
2009-08-05 Tobias Burnus
PR fortr
--- Comment #14 from burnus at gcc dot gnu dot org 2009-08-05 20:47 ---
Subject: Bug 40969
Author: burnus
Date: Wed Aug 5 20:47:19 2009
New Revision: 150500
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150500
Log:
2009-08-05 Tobias Burnus
PR fortr
--- Comment #6 from burnus at gcc dot gnu dot org 2009-08-05 20:51 ---
Patch broke IA64 and was reverted (cf. 40969). Proper fix is PR 40976 which
should solve several of the remaining LTO problems as well.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #15 from burnus at gcc dot gnu dot org 2009-08-05 20:52 ---
FIXED by reverting the bug.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2009-08-07 11:48 ---
Of cause, you need to add a -std=f95 check - and one should do some
thinking/testing whether other items are missing.
There are some other related issues, which should be handled separately:
- Allocate on assignment
--- Comment #1 from burnus at gcc dot gnu dot org 2009-08-07 12:06 ---
Confirmed. Thanks for the report.
Janus, I think it is another side effect of your intrinsic patches. In 4.4
attr.implicit_type is "1" but now on 4.5 it is "0". ts is set in
resolve_intrin
--- Comment #1 from burnus at gcc dot gnu dot org 2009-08-07 13:57 ---
I think there is a general GCC 4.5 problem with debugging symbols. I opened a
PR about this (PR 40660) - which is regarding Fortran - but there was recently
also GCC complaining at #gcc about this issue when
--- Comment #2 from burnus at gcc dot gnu dot org 2009-08-07 14:23 ---
Hmm, actually your example works here:
(gdb) b 7
Breakpoint 1 at 0x4007a0: file hjff.f90, line 7.
(gdb) run
[...]
Breakpoint 1, dummy () at hjff.f90:7
7 PRINT *, 'Hello',nerr
(gdb) p ner
--- Comment #3 from burnus at gcc dot gnu dot org 2009-08-07 14:32 ---
The result of eu-readelf looks OK, however, since I read "module" for item 175,
I wonder whether this is a problem that gdb is too old. There was a change (I
think in the later stages of 4.4.0) which wrote
--- Comment #2 from burnus at gcc dot gnu dot org 2009-08-07 14:41 ---
Using 4.5.0 20090805 with GDB 6.8.50.20090803-10.1 (includes patches of
Fedora/Jan Kratochvil which support F90 arrays/C99 VLA and module variables),
the result is now:
Breakpoint 1, test () at fhjf.f90:3
3
--- Comment #4 from burnus at gcc dot gnu dot org 2009-08-07 16:00 ---
> There was a change (I think in the later stages of 4.4.0) which wrote the
> proper
> DWARF_MODULE* to the ELF binary. However, gdb did ignore that bit.
> There was a fix for the gdb trun
--- Comment #4 from burnus at gcc dot gnu dot org 2009-08-09 08:36 ---
Subject: Bug 40955
Author: burnus
Date: Sun Aug 9 08:35:36 2009
New Revision: 150589
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150589
Log:
2009-08-05 Tobias Burnus
PR fortr
--- Comment #5 from burnus at gcc dot gnu dot org 2009-08-09 08:40 ---
FIXED on the trunk (4.5).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
proc pointer
assignment with CDECL (compiler-directive_1.f90)
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: fortran
AssignedTo: un
--- Comment #1 from burnus at gcc dot gnu dot org 2009-08-11 19:06 ---
The following patch is needed to initialize the variables; however, it does not
solve the actual problem - here, we only make the checks tighter.
For some reason, the LHS seems to be 0 all the time while the RHS
--- Comment #2 from burnus at gcc dot gnu dot org 2009-08-12 08:06 ---
If one looks at the failing test case one finds:
!gcc$ attributes cdecl :: cdecl
!gcc$ attributes stdcall :: stdcall
procedure(), pointer :: ptr
procedure(), pointer :: cdecl
procedure(), pointer
--- Comment #3 from burnus at gcc dot gnu dot org 2009-08-12 09:04 ---
Subject: Bug 41034
Author: burnus
Date: Wed Aug 12 09:03:38 2009
New Revision: 150678
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150678
Log:
2009-08-12 Tobias Burnus
PR fortr
--- Comment #4 from burnus at gcc dot gnu dot org 2009-08-12 09:07 ---
FIXED on the trunk (4.5)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from burnus at gcc dot gnu dot org 2006-10-18 21:29 ---
Fixed on trunk
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #2 from burnus at gcc dot gnu dot org 2007-01-26 11:06 ---
> > And OMP_NUM_THREADS's default setting is completely undefined; does it
> > use by default one or the maximal number of available processors?
>
> Section 3.3 states:
> "If undefin
401 - 500 of 4285 matches
Mail list logo
