dg-error question
Hello,
I have a novice question to dg-error. The testcase if for Fortran, but I
hope to find more dejagnu experts here
I have:
> gcc/testsuite/gfortran.dg> cat -n namelist_internal2.f90 | grep dg-
1 ! { dg-do compile }
2 ! { dg-options "-fall-intrinsics -std=f95" }
16write(str,nml=nam) ! { dg-error "Internal file at .* is incompatible
with namelist" }
20read(str,nml=nam) ! { dg-error "Internal file at .* is incompatible
with namelist" }
Now, if I run "make -k check" I get (from gfortran.sum):
PASS: gfortran.dg/namelist_internal2.f90 -O (test for errors, line 16)
FAIL: gfortran.dg/namelist_internal2.f90 -O (test for errors, line 20)
PASS: gfortran.dg/namelist_internal2.f90 -O (test for excess errors)
That is: The first test succeeds, but the second one fails.
In gfortran.log I find the following:
output is:
In file
/home/tob/projects/gcc/gcc/testsuite/gfortran.dg/namelist_internal2.f90:16
write(str,nml=nam) ! { dg-error "Internal file at .* is incompatible with nam
1
Error: Internal file at (1) is incompatible with namelist
In file
/home/tob/projects/gcc/gcc/testsuite/gfortran.dg/namelist_internal2.f90:20
read(str,nml=nam) ! { dg-error "Internal file at .* is incompatible with name
1
Error: Internal file at (1) is incompatible with namelist
I don't see any reason why it is working with the first one, but failing with
the second one?
Analogously, I get:
PASS: gfortran.dg/write_check2.f90 -O (test for errors, line 5)
FAIL: gfortran.dg/write_check2.f90 -O (test for errors, line 6)
FAIL: gfortran.dg/write_check2.f90 -O (test for errors, line 7)
PASS: gfortran.dg/write_check2.f90 -O (test for excess errors)
That is: First works, others fail. For:
> cat -n write_check2.f90 | grep 'dg-error'
5write(13,'(a)',advance='y')'Hello:' ! { dg-error
"ADVANCE=specifier at .* must have value = YES or NO." }
6write(13,'(a)',advance='yet') 'Hello:' ! { dg-error
"ADVANCE=specifier at .* must have value = YES or NO." }
7write(13,'(a)',advance='yess') 'Hello:' ! { dg-error
"ADVANCE=specifier at .* must have value = YES or NO." }
And again I have:
output is:
In file /home/tob/projects/gcc/gcc/testsuite/gfortran.dg/write_check2.f90:5
write(13,'(a)',advance='y')'Hello:' ! { dg-error "ADVANCE=specifier at .*
1
Error: ADVANCE=specifier at (1) must have value = YES or NO.
In file /home/tob/projects/gcc/gcc/testsuite/gfortran.dg/write_check2.f90:6
write(13,'(a)',advance='yet') 'Hello:' ! { dg-error "ADVANCE=specifier at .*
1
Error: ADVANCE=specifier at (1) must have value = YES or NO.
In file /home/tob/projects/gcc/gcc/testsuite/gfortran.dg/write_check2.f90:7
write(13,'(a)',advance='yess') 'Hello:' ! { dg-error "ADVANCE=specifier at .*
1
Error: ADVANCE=specifier at (1) must have value = YES or NO.
Any ideas?
Tobias
PS: Cross link (contains not more information):
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01337.html
Volatile / TREE_THIS_VOLATILE question
Hi,
if I dump the tree of the following C program,
int main() { volatile int i; i = 5; return 0; }
I get (-tree-original):
{
volatile int i;
volatile int i;
i = 5;
return 0;
}
However, if I apply my volatile-in-Fortran patch [1] and compile
integer, volatile :: i; i = 5; end
then the dumped tree contains:
{
int4 i;
_gfortran_set_std (70, 127, 0);
i = 5;
}
I use in my patch:
+ if (sym->attr.volatile_)
+ TREE_THIS_VOLATILE (decl) = 1;
Question:
- Is TREE_THIS_VOLATILE the right thing to do?
- How do I see (tree dump etc.) whether I did the right change?
Tobias
PS: I sneaked at g95 and there Andy also uses TREE_THIS_VOLATILE; g95
-fdump-tree-original has also no "volatile".
[1] http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01601.html
Detemining the size of int_fast8_t etc. in the frontend
Hi, gfortran provides via ISO C Bindings access to the C types int, float etc. It also provides access to int_fast8_t, int_fast16_t, etc. of stdint.h. Using "#include " with e.g. sizeof(int_fast8_t) does not work with cross compilations. (It actually fails already for -m32 on x86-64.) On the other hand, "struct gcc_target" does not seem to provide this information. What is the proper way to obtain this information? Tobias
Re: symbol names are not created with stdcall syntax: MINGW, (GCC) 4.3.0 20061021
Ross Ridge wrote: > Danny Smith writes: >> Unless you are planning to use a gfortran dll in a VisualBasic app, I >> can see little reason to change from the default "C" calling convention > > FX Coudert writes: >> That precise reason is, as far as I understand, important for some >> people. Fortran code is used for internal routines, built into shared >> libraries that are later plugged into commercial apps. > > > Well, perhaps things are different in Fortran, but the big problem > with using -mrtd in C/C++ is that it changes the default calling > convention for all functions, not just those that are ment to be > exported. While most of MinGW's of headers declare the calling > convention of functions explictily, not all of them do. I think the problem is even bigger in Fortran as the language defines a lot of intrinsic functions, which are implemented in a library (libgfortran). > >How hard do you think it would be to implement a -mrtd-naming option > >(or another name) to go with -mrtd and add name decorations > > Any library that needs to be able to be called from VisualBasic 6 or some > other "stdcall only" environment should explictly declare it's exported > functions with the stdcall calling convention. Thus, if I understood you correctly, you recommend that we add, e.g., pragma support to gfortran with a pragma which adds the __attribute__((stdcall)) to the tree? Tobias
Re: GSoC 2020
Hi Yusuke, hi all,
On 3/2/20 12:16 PM, Thomas Koenig wrote:
Would you tell me more information about the project?
Before the introduction of modules and "contained" procedures
(both: Fortran 90), there was no way to declare/define a function
at one place and when using the procedure to know (and, hence,
check) the arguments. – In C, header lines which declare the
prototype of a function are common, hence, the issue does not exist
there. (One can still call a function in C without prototype, but as
it is rarely done on purpose, one can warn for this – or
with -Werror even fail to compile.)
In terms of the language, even procedures in the same file are not
known, i.e.
subroutine foo(x)
integer :: x
end
subroutine bar()
call foo(1.1) ! < invalid should be integer not real
end
From version to version, gfortran does more tests whether
(a) the call matches the actual declaration (in the same file),
(b) when no interface is known, whether it two usages (calls)
in the same file are both permitted – if one uses "integer" and
the other "real" it is surely wrong.
(c) where an interface block matches either another interface
block or the usage or the actual declaration in the same file.
* * *
In terms of run-time checking, there are two kind of uses:
(a) A code where the interface is not known from the definition
of the procedure. That's either calling the procedure without
an implicit interface ("external") or with a self-written
"interface", which may happen not match the actual procedure
interface.
For instance, a code I recently came across called BLAS's "dcopy"
with a 64bit instead of default-kind integer (32bit).
(b) Even with known interface, having an invalid use of the argument.
For instance, the procedure takes an "integer :: x" as argument and
the call does "call foo(55)". That's perfectly valid as long as the
argument is not modified — otherwise, it crashes.
The simple check is whether the INTENT matches, the interface has
IN and the declaration has INOUT/OUT or whether a constant/intent-in
variable has been passed to an INOUT/OUT variable. – but those are
both for case (a). — One could also run-time check the use (i.e.
annotate the places where the variable is modified) but that can
become very complex. A simple version would be to deduce whether the
input is always modified (unconditionally assigned to or passed to
another procedure with intent OUT/INOUT) and then add the check.
As alluded in the wiki, I was thinking of having some global variable
and then in the procedure call do (pseudo C code):
__gfortran_check_args = {.version=1, .nargs=2, .arg[0].type = int_kind_4,
.arg[0] = readonly, arg[1].type = real_4, filename="abc.f90", line=123, … }
__gfortran_check_func = my_func
my_func (&23, &rvar)
and in the callee "my_func":
if (__gfortran_check_func == my_func)
{
if (__gfortran_check_args.nargs != 2) error(wrong number of arguments)
if (__gfortran_check_args.arg[0] != int_kind_4) error(arg1: wrong arg type)
if (__gfortran_check_args.arg[0] == readonly) error(arg1: cannot )
}
The check "__gfortran_check_func == my_func" is needed if one mixes
code which is instrumented with code which is not.
Fortran has aliasing rules which allow for much better optimization
than C; for example, it is not allowed to pass the same actual
argument to several dummy arguments and change one of
them. The programmer has to follow these rules, or undefined
behavior can occur.
That's another case of (b), e.g.
call sub (a, a, b)
subroutine (x, y, z)
if (y == 9)
z = 4
x = 5
end
is invalid as "x" (alias "a") is modified but the value of "y" (alias "a")
is also accessed. It is perfectly valid to modify "x" if "y" is completely
untouched – or to access both "x" and "y" without modifying. That's really
a run-time condition, i.e.
if (z == 9) then
y = 5
else
x = 7
endif
is valid as only "x" or "y" are accessed in this case.
As in my INTENT example: If as in the first example, "x" and "y" are both
accessed unconditionally, one can add a run-time check without much effort.
(And possibly even a compile-time check.) – While for, e.g.,
if (y == 9) then
y = 7
return
endif
x = 6
the code is valid only if y == 9.
In terms of the tasks:
* one has to think about how to organize the data in the global variable
(what information to put there etc.)
* what to check in general
* how to do the checking (in the code vs. library calls to libgfortran).
For instance, something like
if (arg[1].type != real_4) arg_error ("filename", 123, "my_func",
ERROR_TYPEMISMATCH, 1, __gfortran_arg_check, real_4); would probably be useful:
One only has two string constants in the object file, does the checking in place
but passes all information for the error string on to the library.
One could also do also all checking in libgfortran or …
* * *
As Thomas mentioned, it would be useful to get to know the code a bit before
starting. One useful way is usually to pick some bug
gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments)
CC overseers. they are not stripped – I do see them both in my inbox and at https://gcc.gnu.org/pipermail/fortran/2020-March/054050.html However, attachments of the "text/x-…" format (here: text/x-patch) are no longer shown inline but have to be downloaded (with the inconvenient suffix: .bin) – which is very inconvenient. Cheers, Tobias On 3/9/20 9:23 AM, Thomas König wrote: Hi, looks like the new mailing list setup is stripping off patches. Example: https://gcc.gnu.org/pipermail/fortran/2020- March/054050.html The attachments are also not distributed via mail. This breaks the gfortran review process. Could somebody please fix this? Regards - Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter
text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments))
Hi Thomas, hi Overseers I can confirm that those are stripped off! I did sent an email with three attachments: * test.txt (text/plain) * test.diff (text/x-diff) * the company's disclaimer The attachment with 'text/x-diff' MIME was removed :-( See: https://gcc.gnu.org/pipermail/fortran/current/054078.html Tobias - Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter
Re: access to Subversion links forbidden?
That's a known to-do item – see "cvsweb/svn" under https://sourceware.org/sourceware-wiki/MigrationWorkItems/?updated Tobias On 3/18/20 9:07 PM, Nicholas Krause via Gcc wrote: On 3/18/20 3:49 PM, Martin Sebor via Gcc wrote: I've been getting Error 403 (Forbidden - You don't have permission to access /viewcvs on this server) following the Subversion links in Bugzilla for some time now (they worked for me before the switch to Git, but I'm not sure if they also did before the recent hardware upgrade). For example: https://gcc.gnu.org/viewcvs?rev=268827&root=gcc&view=rev https://gcc.gnu.org/viewcvs?rev=267096&root=gcc&view=rev https://gcc.gnu.org/viewcvs?rev=244881&root=gcc&view=rev Are they supposed to work and if so, is anyone else having trouble with them and is it a known problem that's already being worked on? Thanks Martin Martin, I've been having trouble with them as well for the last day or so. If I recall correctly they worked fine a few weeks ago post Git so I've assuming its a current issue. Nick - Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter
Re: How do I make a double free at runtime fail reliably in the testsuite?
-fsanitize=address should work – but I think you need to create gfortran.dg/asan/asan.exp, e.g. by copying gcc.dg/asan/asan.exp and adapting it. That not only checks for double free but also for instruments the code for use-after-free errors. Cheers, Tobias On 4/29/20 9:23 PM, Thomas Koenig via Fortran wrote: Hi, I have a test case which does a double free on a pointer, at runtime. I have to narrow it down a bit before comitting, but it indicates a regression. Assuming I put this into the testsuite, how can I make sure that this actually fails if the problem ever re-occurs? Is there a combination of options and dejagnu statements that will allow this? It doesn't matter much if the failure is only on a single, common platform. A x86_64-pc-linux-gnu solution would be enough to find any regression there. Regards Thomas
Re: Automatically generated ChangeLog files - script
On 5/4/20 9:05 PM, Jakub Jelinek via Gcc wrote: On Mon, May 04, 2020 at 08:56:16PM +0200, Martin Liška wrote: What's missing right now is how will we declare a Backport format. Can we just use something like: 'Backport from 6607bdd4c834f92fce924abdaea3405f62dc'? No. What we should allow is that people just git cherry-pick r11-1234-g123456 into a release branch and push it (of course after testing), so we don't want the user to change the commit log in that case. How does one handle partial backports? I mean those where only half of the original patch applies easily to the old branch and the other half is simply ignored? This happened a couple of times to me, especially when applying a patch to the last but one release branch. Tobias - Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter
Re: gcc math functions for OpenMP vectoization
On 6/5/20 4:11 PM, Jakub Jelinek via Gcc wrote: It is glibc that provides them, not GCC. See https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86/fpu/bits/math-vector.h;h=0801905da7b85e2f43fb6b682a7b84c5eec469d4;hb=HEAD Minor addition: That header file is included in math.h, i.e. automatically available. For Fortran/gfortran there is math-vector-fortran.h (also provided by glibc) which has the same functions and a similar effect. Cheers, Tobias - Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter
[Patch, committed] Fortran texi: Fix typos (was: Re: FWIW)
Thanks for reporting the typo. I have now fixed it together with some
other typos.
Tobias
On 8/2/20 10:27 PM, Jonathan Wakely via Fortran wrote:
CC The gfortran list.
On Sat, 1 Aug 2020 at 23:38, Nino Pereira via Gcc wrote:
https://gcc.gnu.org/onlinedocs/gfortran/INT.html#INT
has two occurrences of 'or' next to each other.
Arguments:
A Shall be of type INTEGER, REAL, or COMPLEX or or a boz-literal-constant.
HTH,
Nino
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander
Walter
commit b7dd405948d12e005ce4ebe665120fa028e050b4
Author: Tobias Burnus
Date: Mon Aug 3 09:35:49 2020 +0200
Fortran texi: Fix typos
gcc/fortran/ChangeLog
* gfc-internals.texi: Fix typos.
* gfortran.texi: Likewise.
* intrinsic.texi: Likewise.
* invoke.texi: Likewise.
---
gcc/fortran/gfc-internals.texi | 2 +-
gcc/fortran/gfortran.texi | 14 +++---
gcc/fortran/intrinsic.texi | 4 ++--
gcc/fortran/invoke.texi| 2 +-
4 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/gcc/fortran/gfc-internals.texi b/gcc/fortran/gfc-internals.texi
index e74d5d60c1d..6c720434eee 100644
--- a/gcc/fortran/gfc-internals.texi
+++ b/gcc/fortran/gfc-internals.texi
@@ -810,7 +810,7 @@ gfc_add_modify (block, var, build_int_cst (integer_type_node, 42));
@end smallexample
@node Converting Expressions
-@section Converting Expressons to tree
+@section Converting Expressions to tree
Converting expressions to @code{tree} is done by functions called
@code{gfc_conv_*}.
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index d927ebc4abc..151e3d764e7 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -862,7 +862,7 @@ deferred character length left-hand sides are correctly handled but arrays
are not yet fully implemented.
@item Deferred-length character variables and scalar deferred-length character
-components of derived types are supported. (Note that array-valued compoents
+components of derived types are supported. (Note that array-valued components
are not yet implemented.)
@item Transferring of allocations via @code{MOVE_ALLOC}.
@@ -4168,7 +4168,7 @@ an array descriptor. All other arrays pass the address of the
first element of the array. With @option{-fcoarray=lib}, the token
and the offset belonging to nonallocatable coarrays dummy arguments
are passed as hidden argument along the character length hidden
-arguments. The token is an oparque pointer identifying the coarray
+arguments. The token is an opaque pointer identifying the coarray
and the offset is a passed-by-value integer of kind @code{C_PTRDIFF_T},
denoting the byte offset between the base address of the coarray and
the passed scalar or first element of the passed array.
@@ -4362,7 +4362,7 @@ typedef struct caf_reference_t {
The references make up a single linked list of reference operations. The
@code{NEXT} member links to the next reference or NULL to indicate the end of
-the chain. Component and array refs can be arbitrarly mixed as long as they
+the chain. Component and array refs can be arbitrarily mixed as long as they
comply to the Fortran standard.
@emph{NOTES}
@@ -4683,7 +4683,7 @@ status. Note that for critical blocks, the locking is only required on one
image; in the locking statement, the processor shall always pass an
image index of one for critical-block lock variables
(@code{CAF_REGTYPE_CRITICAL}). For lock types and critical-block variables,
-the initial value shall be unlocked (or, respecitively, not in critical
+the initial value shall be unlocked (or, respectively, not in critical
section) such as the value false; for event types, the initial state should
be no event, e.g. zero.
@end table
@@ -5134,7 +5134,7 @@ error message why the operation is not permitted.
@table @asis
@item @emph{Description}:
Acquire a lock on the given image on a scalar locking variable or for the
-given array element for an array-valued variable. If the @var{aquired_lock}
+given array element for an array-valued variable. If the @var{acquired_lock}
is @code{NULL}, the function returns after having obtained the lock. If it is
non-@code{NULL}, then @var{acquired_lock} is assigned the value true (one) when
the lock could be obtained and false (zero) otherwise. Locking a lock variable
@@ -5142,7 +5142,7 @@ which has already been locked by the same image is an error.
@item @emph{Syntax}:
@code{void _gfortran_caf_lock (caf_token_t token, size_t index, int image_index,
-int *aquired_lock, int *stat, char *errmsg, size_t errmsg_len)}
+int *acquired_lock, int *stat, char *errmsg, size_t errmsg_len)}
@item @emph{Arguments}:
@multitable @columnfractions .15 .70
@@ -5151,7 +5151,7 @@ int *aquired_lock, int *stat, char *errmsg, size_t errmsg_len)}
scalars, it is always
[Patch, committed] Update MAINTAINERS (was: OpenACC maintainer)
On 8/26/20 5:17 PM, Joseph Myers wrote: The SC has approved Tobias Burnus as an additional OpenACC maintainer. Tobias, please add yourself as OpenACC maintainer to the MAINTAINERS file. Thanks to the SC for the trust; I also have now updated that file. Tobias - Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter commit b6cd5c3786cd3cdaa794574518585caba9822b09 Author: Tobias Burnus Date: Wed Aug 26 17:55:36 2020 +0200 MAINTAINERS: Add myself as OpenACC maintainer ChangeLog: * MAINTAINERS (Various Maintainers): Add myself as OpenACC maintainer. diff --git a/MAINTAINERS b/MAINTAINERS index 8912b52f5f3..a5cea68ad55 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -240,6 +240,7 @@ loop infrastructure Zdenek Dvorak loop ivopts Bin Cheng loop optimizer Bin Cheng OpenACC Thomas Schwinge +OpenACC Tobias Burnus OpenMP Jakub Jelinek testsuite Rainer Orth testsuite Mike Stump
Re: [patch, doc] Update people who can review gfortran patches
On 9/25/20 8:02 AM, Thomas Koenig via Fortran wrote: for review of its patches, gfortran relies on a group of people who can approve patches. Unfortuntately, many of them are not active. Others, who have the capability and who have acted as de facto approvers (without anybody minding) are missing. I think you want to link to https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=MAINTAINERS which is the official list. — At least additionally. I note the the HTML page states "contributions will be reviewed" and not "approved" – and (nearly) any review comment is welcome, be it from an experienced maintainer or just by someone who passes by. Still, it is a bit misleading if this list includes someone who is not an official reviewer. New reviewers get added by approval of the steering committee (https://gcc.gnu.org/steering.html, typically by some existing maintainer/reviewer proposing a new one – by sending a private email to one of the SC members.) Regarding Jakub: while he is a global reviewer and very active, for Fortran, he is mostly reviewing OpenMP and – to a lesser extent – OpenACC patches and only a very few other patches. Thus, listing him under 'contributions will be reviewed' is a bit misleading. Cheers, Tobias
Re: Minimum CUDA version supported by GCC?
On 19.11.20 12:03, Thomas Schwinge wrote:
As far as I can tell, we (GCC) don't currently state the minimum CUDA
version supported: for nvptx target, and especially then for
OpenACC/OpenMP nvptx offloading.
The nvptx target generates ".version 3.1" (= PTX ISA version) code
with ".target sm_30" and ".target sm_35".
If one looks at
https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#release-notes__ptx-release-history
that means that we need at least CUDA 5 (which introduced PTX ISA 3.1).
CUDA 5 also added sm_30/sm_35 support - i.e. the sm_30/sm_35 GPUs.
[Hence, without bumping the .version, we cannot support newer sm_XX
and I do not see us adding support for sm_20 or other older hardware.]
In theory, newer CUDA versions still support the oldest GPUs down to sm_10.
There is an (unofficial) list which maps sm_* to GPU names at
https://arnon.dk/matching-sm-architectures-arch-and-gencode-for-various-nvidia-cards/
Contrary to the official CUDA documentation, that page states that
CUDA 10 dropped sm_20 support in CUDA 10.
And Tom's testing showed that CUDA 11.1 no longer supports sm_30
– at least its "ptxas" (which we use in JIT mode at program startup).
That is the reason that GCC 11 now defaults to sm_35.
(Use -misa=sm_30 if you have an older card.)
* * *
In terms of supported features, moving to PTX ISA 6.3 (= CUDA 10)
makes most sense as that adds a lot of new features, in particular
'.alias'. – There are a few new features between after ISA 3.1 and
before 6.3 but they are not really worthwhile.
(The .alias issue mostly pops up for C++ code with constructors
or in special cases. There are some PRs about this.)
Do distribution maintainers have an opinion on this maybe, what they need
to support (for upcoming GCC 11, especially)? (Matthias, others?)
I think for license reasons, CUDA itself is not shipped by the
distributions but I might be wrong.
In any case, the question is which CUDA versions are installed in
practice and whether requiring an update (e.g. to CUDA 10+) is
sensible and possible.
CUDA 10 was released in September 2018 – thus, it is rather new.
On 19.11.20 12:18, Jakub Jelinek via Gcc wrote:
I think it would be nice not to kill support for older devices
unnecessarily. If there is a strong reason, sure. And ditto for older
CUDA versions.
But I'm afraid many people have older HW and don't have anything newer.
I'm testing offloading only from time to time, but the only remaining hw
I have has 3.5 capability (Quadro K6000, GK110GL core). And I use that for
both upstream development and distro offloading testing.
If I look at the list above, 3.5 are still supported by CUDA 11.1,
hence, CUDA 10's PTX ISA 6.3 including .alias should still work with
sm_30 (w/ CUDA < 11.1) and sm_35.
If we add support for PTX ISA 6.3 (i.e. CUDA >= 10) to use newer
PTX features (both generic and, possibly, those for newer GPUS/sm_XX),
the question is whether we still want to support older PTX ISA/CUDA
or not.
If so, we need an additional -m* flag.
In terms of userfriendliness, adding -misaversion={3.1,6.3} makes
sense – and then adding .alias support (with warning/error with version 3.1)
plus modifying the shfl vs. shfl.sync depending on the version.
IMHO:
Especially due to the .alias issue, I am very much in favor of supporting
.version 6.3 in GCC 11; about adding -misaversion I am a bit unsure, but
it probably makes sense given that CUDA 10 is still relatively new.
Continued: On 19.11.20 12:03, Thomas Schwinge wrote:
"CUDA" here primarily means libcuda (CUDA Driver API and corresponding
Nvidia Linux kernel driver).
A related topic then is which Nvidia GPU devices are supported by GCC.
Due to the generic nature of PTX code generation as well as pretty
generic hardware access via the CUDA Driver API in libgomp, this is
primarily dictated by whichever Nvidia GPU devices are supported by
libcuda, which GCC doesn't influence.
(A related topic also is PR96005 "Add possibility to use newer ptx isa",
etc., but that's for a separate discussion thread.)
Well, if we do not update the PTX ISA version, we are stuck to PTX ISA 3.1
features and the PTX for sm_30 and sm_35. – Those will work with newer
hardware but prevent supporting the newer hardware better.
Thus, I regard the newer ptx isa question as tightly coupled with the
questions raised in this thread – and do not think that discussing it
in another thread makes sense.
I can confirm that as of present, things are still working fine with
many-years-old CUDA 6.5/libcuda 346.46 (2014), with Nvidia Tesla K40c
GPU, for example.
Until recently (but not anymore), I've been running testing with a Dell
Precision M4700 laptop's Nvidia Quadro K1000M GPU (GK107 core). If I
remember correctly, that one supports Compute Capability 3.0, which Tom
recently removed (default) support for via PR97348 "[nvptx] Make
-misa=sm_35 the default". For avoidance of doubt: that's OK as far as
I'm concerned; not using this laptop anymore for GCC
Re: git commits no longer visible on bugzilla?
Hi Thomas, On 06.12.20 10:22, Thomas Koenig via Gcc wrote: it seems that git commits are no longer automatically transferred to the relevant PRs. In principle, that still works. See "cvs-commit" at https://gcc.gnu.org/pipermail/gcc-bugs/2020-December/date.html#end Recently, there were issues regarding commits with non-ASCII characters and also some issues with gcc-csv@ emails and updating the ChangeLog. This time, this seemed to have worked (for gcc-cvs and ChangeLog). However, what puzzles me is https://gcc.gnu.org/pipermail/gcc-cvs/2020-December/338684.html – this is your commit. But while in the commit, I see "Koenig" for both 'Author' and 'Commit', the 'From:' of that email shows (at least in Pipermail) instead of 'oe' the Hindi letters 'tha' and 'Gh: '*थघ*'. I have no idea where those letters come from; I could image that the conversion of 'ö' goes wrong, but I do not see 'ö' anywhere. Tobias - Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter
Re: git commits no longer visible on bugzilla?
Hi Thomas, On 07.12.20 09:27, Tobias Burnus wrote: However, what puzzles me is https://gcc.gnu.org/pipermail/gcc-cvs/2020-December/338684.html – this is your commit. But while in the commit, I see "Koenig" for both 'Author' and 'Commit', the 'From:' of that email shows (at least in Pipermail) instead of 'oe' the Hindi letters 'tha' and 'Gh: '*थघ*'. Seemingly, the hook (→ https://github.com/AdaCore/git-hooks) takes the full name belonging to the user at gcc.gnu.org. And when Richard checked it for me, for your name it returns (for his locale): getent passwd tkoenig: 'Thomas Kथà¤'. or passed through 'od': …: T h o m a s K 340 244 245 340 244 230 n i g :… If I didn't make a mistake, those numbers convert to hex: E0 A3 A5 E0 A3 98 which I looks like garbage to me. At least it does not seem to make sense in neither UTF-8, UTF-16, UTF-32 and I also do not see any relation with the byte-order character. I think there are two issues: (a) Your name is wrong (should be 'ö' or safer 'oe') → I think you need to contact overseers via IRC or email overseers@ (b) Non-ASCII should probably be accepted in the flow; it looks as if the bugzilla email script mishandles/rejects this email even though it contains valid Hindi letters. Currently, the name comes from /hooks/updates/emails.py: self.email_from = '%s <%s@%s>' % (get_user_full_name(), get_user_name(), from_domain) (those functions come from the 'utils' module.) e_msg['From'] = sanitized_email_address(self.email_info.email_from) (and this does a RFC2047 encoding) Tobias - Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter
Re: How do I print the name of a variable created with create_tmp_var_raw
Hi Thomas, On 08.12.20 19:34, Thomas Koenig via Fortran wrote: I would like to know the name of a variable created with create_tmp_var_raw, but it is not clear to my how to do it. ... t = create_tmp_var_raw (type, prefix); - + dprintf (2, "%s\n", IDENTIFIER_POINTER (DECL_NAME (t))); I think that's okay. However: Do you have a prefix or not? If there is no prefix, DECL_NAME (t) == NULL. If there is a prefix, the name is create_tmp_var_name (prefix), which is (on most systems) "%s.%d", prefix, tmp_var_id_num++ Otherwise, the D.1234 you see in the dump is mostly the result of "D.%u", DECL_UID (t). I hope it helps, Tobias - Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter
Re: Non-dwarf blocks detected by valgrind
Hi Thomas, which binutil version do you have? I am asking because Jakub just submitted: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564206.html If that does not help, it might be that valgrind simply does not like the DWARF which GCC now produces by default. Defaulting to 4: Well, one way would be to use '4' in "init(5)" of "gdwarf-" in gcc/common.opt. Tobias PS: When checking myself, I did not set LD_LIBRARY_PATH, using the *.so of the Linux distro; hence, I might have missed the issue you are seeing. On 25.01.21 15:05, Thomas Koenig via Fortran wrote: Hi Tobias, Does this constitute a regression? From your description, yes. Can you give more details how to reproduce it? $ cat hello.f90 print *,"Hello, world!" end $ valgrind --version valgrind-3.15.0 $ gfortran -g hello.f90 $ valgrind ./a.out [...] --4184-- WARNING: Serious error when reading debug info --4184-- When reading debug info from /home/ig25/lib64/libgfortran.so.5.0.0: --4184-- Ignoring non-Dwarf2/3/4 block in .debug_info --4184-- WARNING: Serious error when reading debug info --4184-- When reading debug info from /home/ig25/lib64/libgfortran.so.5.0.0: [...] --4184-- WARNING: Serious error when reading debug info --4184-- When reading debug info from /home/ig25/lib64/libgcc_s.so.1: --4184-- Ignoring non-Dwarf2/3/4 block in .debug_info [...] --4184-- WARNING: Serious error when reading debug info --4184-- When reading debug info from /home/ig25/lib64/libquadmath.so.0.0.0: --4184-- Ignoring non-Dwarf2/3/4 block in .debug_info So, the problem (at least for me) is that libgfortran and other libraries are built in a format that valgrind can not understand, so it becomes much harder to debug libgfortran :-( Is there a way to configure the build so that the old debug format is used for the libraries? Best regards Thomas - Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter
[Patch, committed] Fortran: Fix wording in intrinsic.texi's MIN (was: Minor error on MIN() page)
Thanks for the report. I have now applied the attached patch.
Tobias
On 10.03.21 20:44, Russ Childers via Gcc wrote:
https://gcc.gnu.org/onlinedocs/gfortran/MIN.html
...says
"
The return value corresponds to the maximum value among the arguments, and
has the same type and kind as the first argument.
"
Should be "minimum value"
Best,
Russ Childers
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
Thürauf
commit 9dcc2edfa657d26223f7e74d27af225d4bbf11a9
Author: Tobias Burnus
Date: Wed Mar 10 21:24:18 2021 +0100
Fortran: Fix wording in intrinsic.texi's MIN
gcc/fortran/ChangeLog:
* intrinsic.texi (MIN): Correct 'maximum' to 'minimum'.
diff --git a/gcc/fortran/intrinsic.texi b/gcc/fortran/intrinsic.texi
index ea78f7d343a..73baa34104e 100644
--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -10621,21 +10621,21 @@ Elemental function
@item @emph{Arguments}:
@multitable @columnfractions .15 .70
@item @var{A1} @tab The type shall be @code{INTEGER} or
@code{REAL}.
@item @var{A2}, @var{A3}, ... @tab An expression of the same type and kind
as @var{A1}. (As a GNU extension, arguments of different kinds are
permitted.)
@end multitable
@item @emph{Return value}:
-The return value corresponds to the maximum value among the arguments,
+The return value corresponds to the minimum value among the arguments,
and has the same type and kind as the first argument.
@item @emph{Specific names}:
@multitable @columnfractions .20 .20 .20 .25
@item Name @tab Argument @tab Return type@tab Standard
@item @code{MIN0(A1)} @tab @code{INTEGER(4) A1} @tab @code{INTEGER(4)} @tab Fortran 77 and later
@item @code{AMIN0(A1)} @tab @code{INTEGER(4) A1} @tab @code{REAL(4)} @tab Fortran 77 and later
@item @code{MIN1(A1)} @tab @code{REAL A1} @tab @code{INTEGER(4)} @tab Fortran 77 and later
@item @code{AMIN1(A1)} @tab @code{REAL(4) A1}@tab @code{REAL(4)} @tab Fortran 77 and later
@item @code{DMIN1(A1)} @tab @code{REAL(8) A1}@tab @code{REAL(8)} @tab Fortran 77 and later
Re: GSoC 2021 - Fortran run-time argument checking
Hi Krishna, On 03.04.21 13:52, Krishna Kariya wrote: I am Krishna, a final-year undergraduate student from India. I am interested in the project “Fortran – run-time argument checking” for GSoC 2021. Please share some resources about the project. Please point to some issues or programming tasks that I can try out to understand the project better. In older Fortran program, no modules were used and, hence, no argument checking was possible. Think of: subroutine caller() external callee integer :: A(5), b(4) call callee(A, B, 5.0, "Hello") end Here, the compiler only knows that 'callee' is a subroutine but has no idea about the actual arguments. Alternatively, in semi-modern code, it could use: subroutine caller() integer :: A(5), b(4) interface subroutine callee(w,x,y,z) integer :: w(*), x(*) real :: y character(*) :: z end end interface call callee(A, B, 5.0, "Hello") end The idea is that the caller now fills global variables: __gfortran_called_proc = callee ! function pointer __gfortran_called_interface = ... pointer to a struct/derived type and afterwards, it would set both to null. The latter contains then: - a version number (to be able to add more data later on) - file name, function name and line number of the caller - information about the arguments: - 4 arguments - first: integer array of size 4 - ... And in subroutine callee() it would check: if (__gfortran_called_proc == callee) and then fill a similar struct with similar data (version number, filename, proc name, line number, arguments) and then call the library function __libgfortran_check_args( __gfortran_called_interface, callee_interface); which then checks whether the arguments match. Internal procedures and module procedures can be excluded as those can not be access from the outside. Minimal check would be: - number of arguments - data type - array + array size - caller/callee is a function – and expected return values (type, array) but that can be extended especially in the context of an interface block (with a zoo of attributes, additional array types etc.) and with intent handling (intent(out) in caller but constant or intent(in) as argument, intent(out) argument to intent(in) etc.) Tobias - Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank Thürauf
Re: bug report : gfortran E edit descriptor
I think gfortran's result *is* *correct* according to the Fortran standard. (I concur that the result is not what one would expect but it is now decades to late to change that.) sudo.michio wrote: > I have an trouble in E edit descriptor of gfortran. > This is a example. ... > write(*,'(e9.3,a,f7.1)')a,' ',b > write(*,'(1pe9.3,a,f7.1)')a,' ',b ... > (execute) > a.exe > (result) > 135.00 1737.5 > 0.135E+03 1737.5 > 1.350E+02 17375.0 ( <--- wrong value ) Looking at the Fortran standard [1], the result looks correct: "The k P edit descriptor temporarily changes (9.5.2) the scale factor for the connection to k. The scale factor affects the editing done by the F, E, EN, ES, D, and G edit descriptors for numeric quantities. [...] * On output, with F output editing, the effect is that the externally represented number equals the internally represented number multiplied by 10**k; the internal value is converted using the I/O rounding mode and then the scale factor is applied to the converted decimal value. * On output, with E and D editing, the effect is that the significand (R414) part of the quantity to be produced is multiplied by 10**k and the exponent is reduced by k." The referenced 9.5.2 contains the following, which implies that the "1p" not only affects the immediately following "e9.3" but also the later "f7.1": "Edit descriptors take effect when they are encountered in format processing. When a data transfer statement terminates, the values for the modes are reset to the values in effect immediately before the data transfer statement was executed." Cheers, Tobias [1] http://j3-fortran.org/doc/year/10/10-007r1.pdf Section "10.8.5 P editing" Page 279 of the document, page number labelled as "261"
Re: [GSoC] a wiki page on the gcc wiki
Roman Gareev wrote: I've created an account on the gcc wiki but I don't allowed to create and edit any page. I would like to set up a wiki page to post the updates of the project after reaching my mile stones. Could you please advise me how to get appropriate rights? I have added you to the edit group. Tobias
Re: Debugging LTO.
Tejas Belagod wrote: Are there any tricks I can use to debug an LTO ICE? See LTO section on https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction Tobias
[RFC] Fortran: How to handle allocatable polymorphic components with OpenMPv5/OpenACCv3
This email is probably a bit premature as the OpenMPv4.0 and OpenACC 2.0a specs do not seem to handle Fortran 2003's polymorphic variables. However, as I am currently thinking how to handle a similar problem for Fortran's coarray, I want to raise the issue for OpenMP/OpenACC to see whether something should be done in gfortran to solve the problem for OpenMP/OpenACC and coarrays at the same time. For coarrays, see also https://gcc.gnu.org/ml/fortran/2014-06/msg00132.html The issue described below occurs when one needs to copy variables which are polymorphic or contain components which are polymorphic. That applies both to copying them to a thread-local variable or with offloading to the memory of an accelerator. In case of Fortran, doing an assignment of a derived type (record type) will also copy the allocatable components, which in turn might have again allocatable components. For nonpolymorphic variables, one can simply recursively walk through all components and do the copying that way. That's how the Fortran FE does for intrinsic assignments – and what Jakub's recently committed OpenMPv4.0 patch does. However, how to handle it for polymorphic types? In case of the intrinsic assignment, the variable/component has a pointer to a virtual table, which contains a function pointer to the type's copy function. But how to handle it in case of OpenMP (v4.1?, v5.0?)? One could augment the vtable by a function pointer to an function which handles this for OpenMP/OpenACC, probably by calling some libgomp library function. In case of coarrays, I have (see link above) the same problem: I need to add library calls to transfer allocatable components forth to and back from a remote process. Thus, I am also thinking of adding a new entry to the virtual table Another issue arises when one mixes code with and without -fopenmp/-facc/-fcoarray=lib. One either has to generate the vtable entry and function unconditionally – or only with that option, but then one might run into corner cases, where the function is not available. One option* I see is some kind of generic function, which takes as additional argument a function pointer; this pointer could point either to libgomp or to the coarray library (for -fcoarray=lib), depending on the caller. In addition, it avoids issues with dependencies on the called library. What do you think? Would this be a sensible way for OpenMPv5/OpenACCv3/coarrays? Or do you see pitfalls with this approach? One additional issue would be the way the arguments are passed, which one would have to agree on. Comments? Suggestions? Questions? Tobias * The other option is to generate specific functions, but that is not only less flexible but also runs into issues like library dependencies. Those can be solved with weak symbols and stubs, but that's also not very elegant.
Using BUILT_IN_ATOMIC_...
Hello all, I am trying to use BUILT_IN_ATOMIC_..., but it does not quite work. I am calling them as: tmp = builtin_decl_explicit (BUILT_IN_ATOMIC_LOAD_4); tmp = build_call_expr_loc (input_location, tmp, 2, atom.expr, ... That gives the following dump: __atomic_store_n (&i, 5, 0); __atomic_store_n (&i, (integer(kind=4)) *k, 0); j = (integer(kind=4)) __atomic_load_4 (&i, 0); __atomic_add_fetch (&i, 5, 0); The "__atomic_load_4" works, but the "__atomic_store_n" and "__atomic_add_fetch" lead to link-time errors: fo4o.f90:(.text+0x44): undefined reference to `__atomic_store_n' fo4o.f90:(.text+0x73): undefined reference to `__atomic_add_fetch' The issue with `__atomic_store_n', I can solve by replacing it by, e.g., BUILT_IN_ATOMIC_STORE_4. However, how does one properly use __atomic_add_fetch alias BUILT_IN_ATOMIC_ADD_FETCH_N, given that there is no _4 version of it? Additionally, if one wants to fetch the old value (e.g. with __atomic_add_fetch), how does one properly use the function result? The problem is that TREE_TYPE() doesn't automatically match the type of the first argument. Ignoring the type issue in the front end and simply calling MODIFY_EXPR will lead to a gimplify.c ICE. Tobias
Re: Slides from Cauldron talks
David Malcolm wrote: I didn't see a place to post slides for Cauldron talks, so am posting links to them here. I have added the links to https://gcc.gnu.org/wiki/cauldron2014#Slides_and_Notes Does anyone know if any Cauldron talks were recorded? At least the ones in Lecture Theatre One were. However, I don't know when the organizers will upload the videos. Tobias
Re: Gfortran issue
Good morning Jerome, Jerome Huck wrote: > I have warning with COMMON. The COMMONS are the same along the code... > When compiled I have warnings with different sizes !!! Well, neither /NO1/ nor /NO4/ are not the same size throughout the code. > There were some bugs/issues in the past see : Those issues were about not warning in this case - not about falsely warning. Back to your code. In the main program and in GRID your code contains for /NO4/ the variables: QF(6,14,3), QC(4,13,3), DXW But in WING it only has in /NO4/ only: QF(6,14,3) Similarly for /NO1/, which has: COMMON/NO1/ DS,X,B,C,S,AR,SN1,CS1 COMMON/NO1/ DS,X,B,C,S,AR,SN1,CS1 COMMON/NO1/ DS The Fortran standard mandates that all named common blocks have the same size. However, looking at your common blocks, I think your declarations are fine in practice. Thus, you can ignore the warning, unless you want to make the code conforming to the Fortran standard. Quoting Fortran 77's 8.3.3: "Within an executable program, all named common blocks that have the same name must be the same size." (Fortran 90/95/2003/2008 have similar wordings.) For those liking language archeology, they could try to find out what Fortran 66 specified... Tobias
Re: gcc parallel make check
Hi Joost, VandeVondele Joost wrote: > I've noticed that > make -j -k check-fortran > results in a serialized checking, while > make -j32 -k check-fortran > goes parallel. I have to admit that I don't know why that's the case. However, I can answer the next question, is presumably related to this one: > Somewhat related is there a rule of thumb on how is the granularitys > of parallel check decided ? DejaGNU is not able to run checks in parallel - thus, we have only makefile parallelization (check-gcc, check-gfortran). As that wasn't suifficient, Jakub (?) split the single tests into multiple ones, trying to do ensure that those subtargets all take about the same time. See: gcc/fortran/Make-lang.in, which has: # For description see comment above check_gcc_parallelize in gcc/Makefile.in. check_gfortran_parallelize = dg.exp=gfortran.dg/\[adAD\]* \ dg.exp=gfortran.dg/\[bcBC\]* \ dg.exp=gfortran.dg/\[nopNOP\]* \ dg.exp=gfortran.dg/\[isuvISUV\]* \ dg.exp=gfortran.dg/\[efhkqrxzEFHKQRXZ\]* \ dg.exp=gfortran.dg/\[0-9gjlmtwyGJLMTWY\]* Thus, you currently get 6 parallel check-gfortran checks - followed by one which tries to combine the results. I think Diego has some means to run GCC's in a vastly parallel way, which break due to a test-framework issue / gfortran.dg-dependency issues. See PR56408. Thus, you could asks him how he does it. Additionally, I wouldn't mind if some lispy person could look at the PR - my attempts failed, but, admittedly, I didn't spend much time on it. Tobias PS: There was/is the reoccuring thought of replacing DejaGNU by a different framework or to enhance it, but not much substantial work has happened, despite some occasional effort. At least DejaGNU is now back under maintaince, cf. http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=summary
Re: [PATCH] gcc parallel make check
On 11.09.2014 20:33, VandeVondele Joost wrote:
>For PR56408 we need some fix.
BTW, is there anything special about Fortran ? There are at least 180 test
files that contain 'dg-additional-sources' some in a very non-local way:
Well, the question is what you want to do with the different files. If
you just want to compile them, e.g. for linking or executing, you are
fine. However, with Fortran module's there is a .mod file produced –
which gives an ordering constraint: The file with the module has to be
compiled first before the other file can be compiled. (If one puts the
module into the same file, one has effectively one translation unit and
some bugs do not pop up in this case.)
The current scheme comes at its limits in that case. Mainly because the
file specified in dg-additional-sources is compiled after the one in
which this line is written. That can be fine for linking/run-time tests,
where one disables the by-itself compilation of the second file - and
puts the module into the first file. However, as soon as one wants to do
more, e.g. dg-error/dg-warning output, checking the dump/assembler etc.,
one is in trouble. See the files listed in the PR for issues.
By contrast, for C/C++, one has a header file which is included by the
preprocessor (hence before the compiler), thus, there is no ordering
issue as no compiler input is generated. I don't know whether one could
run into issues with precompiled header files - but there on has at
least the different name *.h/*.hpp and *.c/.cc. I don't know about Ada
or C++'s upcoming ISO-version of precompiled headers ("modules"), maybe
there one runs into similar issues?
See the PR for some attempts to fix it.
Tobias
Re: [GSoC] Status - 20140901 FINAL
On 12.09.2014 18:10, Manuel López-Ibáñez wrote:
Hi Maxim, Many thanks for your leadership and hard work administering this.
Also thanks from my side.
I would be interested in reading about the results of the projects and
evaluations. Please student (and mentors), could you provide some
details?
Let me write a few words regarding the Alessandro's coarrays project.
Coarrays are a way to parallelize programs; conceptually, they are about
distributed memory as each process (called image) has its own memory
except for certain variables – called coarrays – which are available on
all images/processes. They act as local (remote accessible) variable –
unless one explicitly accesses remote memory using the image index of a
remote process. The scheme is known as Partitioned Global Address Space
- short PGAS - and other languages also know that, such as Universal
Parallel C (UPC) and, I think, Chapel, Fortress and X10.
Coarrays are a new feature in the Fortran 2008 standard and are being
extended (collectives, teams, events etc.) in a Technical Specification
(TS18508), which will be part of Fortran 2015.
On the GCC/gfortran side, some initial support has been added in 4.6 and
4.7, but the multi-image support has never materialized. And a parallel
feature which only works on a single process is kind of boring.
Enter Alessandro: Starting a bit before GSoC, but mostly during and as
GSoC work, he worked on the library side of coarrays, ensuring that the
communication actually happens. (At the same time, his progress forced
me to add some missing bits to the compiler itself.)
While there are still some issues – both on the library and on the
compiler side, coarrays now mostly work! The basic features are all
there and the performance is also competitive. That was also also part
of Alessandro's work: To measure and to decide which communication
library should be used. Currently, MPI and GASNet are the supported
backends.
For the comparison with other implementations and the scaling, see:
http://opencoarrays.org/yahoo_site_admin/assets/docs/Coarrays_GFortran.217135934.pdf
For the current status and usage https://gcc.gnu.org/wiki/Coarray and
the links there in.
Coarrays were (albeit with a slightly different syntax) supported for a
long time in the Cray compiler – but only recently with the Fortran 2008
syntax. Additionally, the Intel compiler has an implementation which is
known to be slow. (I assume that will now change.) Hence, there aren't
not that many coarray programs. However, there is definitely interest by
the developers – such that the feature will likely become more popular.
Outlook on the gfortran side: Locking is not yet implemented on the
compiler side (not crucial as one has synchronization and atomics, but
still) – nor are allocatable/pointer derived-type components ('struct
elements') *of* coarrays, which will then also require more work on the
library side. And completely missing are some of the nifty features of
the upcoming Technical Specification.
One of the next items is in any case the new array descriptor, which is
a different project but would help with some of the issues we have with
array access to components of array coarrays
Tobias
Re: Implementing OpenACC's Fortran module
On 19.09.2014 11:03, Thomas Schwinge wrote:
Regarding linking the object file produced by Fortran openacc.f90 into
libgomp: (with the version that Jim already has internally checked in)
I find that libgomp then has undefined references to
_gfortran_internal_unpack and _gfortran_internal_pack.
Internal pack and unpack appears when you a (potentially) noncontiguous
array is passed as argument to an argument which requires a contiguous
argument. Internal pack checks at run time whether the argument is
contiguous - and if not it creates a temporary and copies the data to
the temporary ('copy in') - internal unpack ensures for all arrays but
intent(in) that the data is propagated back to the original one.
I am pretty sure that copy-in will break the OpenACC functions.
One possibility would be to mark the dummy arguments in openacc.f90 as
CONTIGUOUS. That way, no internal pack/unpack is called by openacc.f90.
(If one has a noncontiguous array, the caller of openacc.f90 will do the
copy in/out.)
Thus, you could try to add ", contiguous" to all procedures which take
an assumed-rank array "(..)" as argument.
Tobias
Re: Implementing OpenACC's Fortran module
On 22.09.2014 17:17, Thomas Schwinge wrote: That works. For avoidance of doubt: just tag to the actual implementation (which is enough to avoid the references to _gfortran_internal_unpack and _gfortran_internal_pack), or also the interfaces, as detailed in the following "pseudo patch": Well, the standard mandates that those match, thus, I think one should do it. If one passes a noncontiguous array to a CONTIGUOUS dummy argument, the caller ensures that the argument is truly packed by creating a temporary and packing it, iff it is not contiguous. (If it is known at compile time that the array is contiguous, no run-time test is inserted.) The idea is to avoid wrong code, if one passes something noncontiguous. Hence, the caller has to see the attribute - and if it only sees the interface block and not the function itself, it must be in the interface block. In case of OpenACC, the OpenACC semantics require that the argument is contiguous. If users gets it wrong, it will be wrong either way: If the variable is not packed and when it is packed (and the temporary removed after the function call). Tobias
Re: Implementing OpenACC's Fortran module
On 22.09.2014 17:31, Tobias Burnus wrote: In case of OpenACC, the OpenACC semantics require that the argument is contiguous. If users gets it wrong, it will be wrong either way: If the variable is not packed and when it is packed (and the temporary removed after the function call). Post script: Actually, in some cases, the copy-in/copy-out using a temporary will actually work: Namely, if one only needs to transfer the memory once, such that the pointer address does not matter (e.g. only acc_copyin w/o later copyout or update). Thus, while copy-in/out with a temporary is bad, passing the unpacked array is worse as it will also use the wrong values in this special case. – That's another argument for using CONTIGUOUS also in the INTERFACE block. Tobias
Re: [Patch, Fortran] Add CO_BROADCAST
Dominique Dhumieres wrote: > The failures for the gfortran.dg/coarray_collectives_9.f90 are fixed > with the following patch: Looks good to me. The patch is OK with a ChangLog. Thanks for the patch and sorry for the test fails. Tobias
RFC: Update ISL under gcc/infrastructure/ ? // Remove CLooG?
Hi all, currently, contrib/download_prerequisites downloads isl-0.12.2 from ftp://gcc.gnu.org/pub/gcc/infrastructure/$ISL.tar.bz2 However, that version has a bug which causes an ICE (PR 62289). End of October, ISL 0.14 was released, which should contain a fix for that issue. Hence, one should consider using 0.14 instead of /infrastructure/ and download_prerequisites. Download: http://isl.gforge.inria.fr Disclaimer: I haven't tested that version, yet. * * * The page https://gcc.gnu.org/install/prerequisites.html lists 0.12.2 as version to be used (without "(or later)"). The configure script does some version checks, but seeminly only to rule out early version of ISL as it is only the check for an include file. According to https://groups.google.com/forum/#!topic/isl-development/CQGVfj60SQM "0.14 was kept backward compatible with 0.13." [But 0.15 will break it.] Thus, assuming 0.13 works, 0.14 also should work. Release notes: http://repo.or.cz/w/isl.git/blob/HEAD:/ChangeLog * * * Comments? Especially from Richard and Tobias? * * * Finally, is CLooG still needed or will GCC also work with only ISL? Looking at https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01742.html , it seems as if it is about the right time to remove it. Regards, Tobias
Re: RFC: Update ISL under gcc/infrastructure/ ? // Remove CLooG?
Richard Biener wrote: On Thu, Nov 6, 2014 at 8:02 AM, Tobias Grosser wrote: Also, as Tobias suggested we should raise the minimal supported isl level to 0.14 to be sure PR 62289 is fixed. As I am testing with system isl/cloog that would be unfortunate as it means I'd either drop testing graphite for 4.8 and 4.9 or for 5.0 ... AFAIK ISL 12.x and 13+ cannot co-exist in the system due to include file conflicts. An alternative would be to still accept ISL 0.12.x in terms of configure, while updating infrastructure / contrib/download_prerequisites to ISL 0.14 (while keeping 0.12 for GCC 4.8/4.9 on the ftp server). The question is only what then to write at https://gcc.gnu.org/install/prerequisites.html? "0.14.0" (but still accepting 0.12)? "0.12.2 or later, recommended 0.14.0"? Tobias
Re: [PATCH 0/4] OpenMP 4.0 offloading to Intel MIC
Kirill Yukhin wrote: > Support of OpenMP 4.0 offloading to future Xeon Phi was > fully checked in to main trunk. Thanks. If I understood it correctly: * GCC 5 supports code generation for Xeon Phi (Knights Landing, KNL) * KNL (the hardware) is not yet available [mid 2015?] * liboffloadmic supports offloading in an emulation mode (executed on the host) but does not (yet) support offloading to KNL; i.e. one would need an updated version of it, once one gets hold of the actual hardware. * The current hardware (Xeon Phi Knights Corner, KNC) is and will not be supported by GCC. * Details for building GCC for offloading and running code on an accelerator is at https://gcc.gnu.org/wiki/Offloading Question: Is the latter up to date - and the item above correct? BTW: you could update gcc.gnu.org ->news and gcc.gnu.org/gcc-5/changes.html Otherwise: * OpenACC support is about to be merged (as alternative to OpenMP 4) * Support for offloading to NVidia GPUs via PTX is also about to be merged. Tobias
libcpp how-to question: Tokenizing and spaces & tabs – or special Fortran needs
BACKGROUND
Currently, gfortran reads source files directly. If preprocessing is
enabled, it calls libcpp directly but writes the preprocessed output
into a temporary file, which is then read. In order to bring processing
closer to the common code, show macro expansion in error messages and
similar, I'd like to use libcpp for the reading of the files –
preprocessed and to-be preprocessed.
The problem is that whitespace seems to get lost in libcpp. In Fortran,
spaces play a role:
* In free format only to warn if tabs appear (invalid per ISO standard,
-Wtabs) and to print an error if the line is too long (max 132
characters according to the standard; with -ffree-line-length-none =
unlimitted.)
* For fixed format, the whitespace is crucial. The columns 1 to 6 have a
special meaning, but also the total length is limited to 72 characters;
excess characters are ignored (comment). That dates back to the time of
punch cards and the eight excess characters were e.g. used to enumerate
the punch cards. There are still Fortran programs out there which assume
that everything beyond 72 characters is ignored. Others assume that 80
(= full punch card) or 132 characters are permitted (free-form limit).
(gfortran permits any value >=72, including unlimited.)
LIBCPP
Now back to libcpp: As first step, I tried to use
token = cpp_get_token (cpp_in);
cpp_token_as_text (cpp_in, token);
for converting the input. I can recover linebreaks and whether there was
a preceeding line space with the flags BOL and PREV_WHITE; for line
breaks also by defining a call back. At the beginning of the line, I can
still recover the number of spaces from the source location
(SOURCE_COLUMN) but not whether it was done with " " or via a tab. For
mid line, I could use: souce column of current token minus previous
token minus the length of the previous token when spellt as text.
However, that's not really elegant.
[A bit related, adding a special Fortran mode makes sense; currently,
preprocessing can only use the traditional mode as things like
print *, 'That''s a string which &
! Here's a comment line inbetween
&is continued in the next line'
is not properly handled. Complaining about unterminated strings either
because of the & continuation line or the ' in the comment. However, as
some other compilers support features such as "##" concatenation,
there's the wish by users to go beyond traditional.]
As the Fortran standard doesn't define how the preprocessing works,* we
do have quite some leeway. However, for -fpreprocessed, the white spaces
have really to be passed as is. (-fpreprocess which is the default in
gfortran, unless the special file extension (.F, .F90, .fpp) or "-cpp"
is used.
Do you have a suggestion how to best implement this white-space
preserving with libcpp? It can (and presumably should) be a special
flag/function for Fortran.
Tobias
* To be precise: Part 3 of the Fortran standarization series (ISO/IEC
1539-3:1998) defines conditional compilation ("coco") but that never
caught on [an external tool "coco" exists to use it]. I think coco is
supposed to get retired. On the other hand, all Fortran compilers
support to optionally but automatically run the code through the C
pre-processor; some use simply "cpp", others netlib.org's fpp and some
support newer features.
Re: trying out openacc 2.0
Mark Farnell wrote: > Has OpenACC 2.0 support been merged into the trunk yet? If not, then > is it contained in gomp-4_0-branch? > > If so, what parameters should I pass to ./configure to enable OpenACC > 2.0, and relevant backends such as CUDA, MIC and other GPGPU/manycore > architecture? > > Also, I have a feeling that OpenACC 2.0 did NOT make it to gcc 5.0, am > I correct? If I am correct, then will it be included in gcc 5.1? If > I am wrong and it is already included into gcc 5.0, then I would > really really like to use it. > > In the latter case, will I be able to write OpenACC 2.0 / OpenMP 4.0 > code that runs on my nvidia GPU and/or Intel Xeon Phi? Let's start from the end: OpenMP 4 support for Intel's Xeon Phi is in the trunk and - in principle - working. The only problem is that only Knights Landing (knl) is supported and not the old Knights Corner (knc); given that Knights Landing is not yet available, you currently can only use it with a simulator. Regarding the question how to build GCC with accelerator support, see https://gcc.gnu.org/wiki/Offloading - That page applies both to OpenACC and OpenMP and to KNL and Nvidia's PTX. However, it is currently still a bit KNL centric. Regarding OpenACC: The support has not yet been merged, however, I think the goal is still to get it included in GCC 5. The first bits - like PTX support - have already been merged. I think the gomp-4_0-branch provides all what's needed and it has been recently updated to match the trunk (last Sunday). For building the branch and using OpenACC+PTX, again start with https://gcc.gnu.org/wiki/Offloading Tobias, who has yet to try offloading himself
Re: trying out openacc 2.0
Mark Farnell wrote: > So what parameters will I need to pass to ./configure if I want to > support PTX offloading? Pre-remark: I think that the https://gcc.gnu.org/wiki/Offloading page will be updated, once the support has been merged to the trunk. I think using the triplet "nvptx-unknown-none" instead of "x86_64-intelmicemul-linux-gnu": https://gcc.gnu.org/wiki/Offloading#A1._Building_accel_compiler > So if I want to have CPU, KNL and PTX, do I end up building three compilers? That's my understanding. You then generate for the offloading/target section code for the host (as fall back) and for one or multiple accelerators. At invokation time, you then decide which accelerator to use (KNL, PTX or host fallback.) Assuming that you target both accelerators during compilations. > Finally, is the nvptx-tools project mentioned in Tobia's page aiming > at replacing the CUDA toolchain? Depend's what you mean by "CUDA toolchain"; the purpose of those tools is https://gcc.gnu.org/ml/gcc-patches/2014-10/msg03372.html Namely, "as" just does some reordering and "ld" reduces the number of files by combining the PTX files. The actual 'assembler' is in the CUDA runtime library. However, GCC (plus the few aux tools) replaces the compilers (nvcc etc.) as that task is done by GCC. >> Also, are other GPUs such as the AMD ATI and the built-in GPUs such as >> the Intel GPU and AMD fusion supported? There was some work underway to support OpenACC with OpenCL as output, which is then fed to the OpenCL runtime library. The OpenACC part of that work ended up in gomp-4_0-branch and is hence not lost. I don't recall whether there was a branch or patch for the OpenCL support part. For AMD's HSA, see Jakub's email. Tobias
Re: RTEMS FORTRAN Pattern Failures
Joel Sherrill wrote: On 1/12/2015 10:30 AM, Andreas Schwab wrote: Joel Sherrill writes: FAIL: gfortran.dg/g77/f77-edit-x-out.f -Os output pattern test, is 1 2 3 1 2 3 , should match ^1 2 3( | |)1 2 3( | |)$ Where is the \r gone? The pattern has (\n|\r\n|\r). I am not exactly sure what you mean but when I run the test by itself from the command and redirect the output to a file, this is what the output looks like: 0002031203233200a0d2031203233200a0d 000 1 2 3 \r \n 1 2 3 \r \n 0100a0d2a2a202a584554496320646f2065 010 \r \n * * * E X I T c o d e 0200d30000a 020 0 \r \n 023 It looks like we have \r\n at the end of each line. Is it possible it is not CR/LF but the EXIT code message confusing the pattern? Contrary to Andreas, I do see \r in run.txt – at least when I look at the file when saved from Thunderbird. Namely, the output is (sp = space, nl = \n, cr = \r): 1 sp 2 sp sp 3 cr cr nl 1 sp 2 sp sp 3 cr cr nl cr cr nl *** EXIT code 0 cr cr nl Namely: I do not see CR-NL but CR-CR-NL. That looks rather odd and does not match what you get when you manually run the program. Looing at other lines like "spawn sis -i ./f77-edit-x-out.exe", they have a CR-NL, i.e. only a single CR. Thus, the question is what inserts an additional "\r" into the output. Additionally, I think you are right that the "*** EXIT code 0" also causes problems with the pattern. Can you try the following: a) Replace the pattern by "1 2 3(\n|\r\r\n|\r)" (twice), note the duplicated "\r" b) Remove the "dg-output "\$" line [Best would be if you could try them also separately.] My bet would be that doing (a) and (b) will succeed, while only (a) and (b) will fail. If using (a) [alone or together with (b)] works, you should really find out what inserts the "\r", especially as it does not appear if you manually run the program. "\r\r\n" is definitely not a pattern I would like to see in the test file. If (b) works [alone or together with (a)]: Any chance that you silence the "\r\r\n*** EXIT code 0\r\r\n" output? I think it could potentially confuse other test cases and it doesn't belong there. – I am also inclined not to remove the '\$', unless there are very compelling reasons to do so. Tobias
Re: RTEMS FORTRAN Pattern Failures
Joel Sherrill wrote:
run.txt is the cut and paste of the log file which reflects DejaGNU's
view of the run.
Which means that it hopefully matches every bit of the original output
and that no editor interferes by adding or removing line breaks.
Additionally, I think you are right that the "*** EXIT code 0" also
causes problems with the pattern.
Details below but this is standard DejaGNU output when the target
doesn't return
an exit code.
Good to know. If the pattern is known, one can add it to the pattern.
Can you try the following:
a) Replace the pattern by "1 2 3(\n|\r\r\n|\r)" (twice), note the
duplicated "\r"
b) Remove the "dg-output "\$" line
[Best would be if you could try them also separately.] My bet would be
that doing (a) and (b) will succeed, while only (a) and (b) will fail.
If using (a) [alone or together with (b)] works, you should really find
out what inserts the "\r", especially as it does not appear if you
manually run the program. "\r\r\n" is definitely not a pattern I would
like to see in the test file.
I assume the file in question is
gcc/gcc/testsuite/gfortran.dg/g77/f77-edit-x-out.f
Yes.
(a) alone didn't make it pass.
(b) alone didn't make it pass.
(a) and (b) together did not make it pass
Does this file get copied or something else during the process that
would eliminate edits having an impact?
I don't think so. Too bad that it didn't seem to help.
Is there an easy way to take out.txt and just force it against this
.exp pattern?
Well, you could try whether PERL is able to match it, i.e. something
like "cat file | perl ..." if you manage to get the exact output into a
file (esp. with the right number of \r and \n, including the last line).
I don't know whether that's really identical but it should come close to
how DejaGNU matches the pattern.
Example - I use printf instead of a file:
printf '1 2 3\n1 2 3\n\n*** EXIT code 0' \
| perl -e '$in = join("", ); if ($in =~ m/^1 2 3(\n|\r\n|\r)1
2 3(\n|\r\n|\r)((\n|\r\n|\r)\*\*\* EXIT code 0)?$/s) { print
"matched\n" } else { print "not matched\n" };'
Tobias
Re: RTEMS FORTRAN Pattern Failures
Hi Joel,
Am 12.01.2015 um 22:04 schrieb Joel Sherrill:
That was very close.
cat out.txt | \
perl -e '$in = join("", ); if ($in =~ m/^1 2 3(\n|\r\n|\r)1 2
3(\n|\r\n|\r)((\n|\r\n|\r)\*\*\* EXIT code 0)(\n|\r\n|\r)?$/s) { print
"matched\n" } else { print "not matched\n" };'
That won't work on systems which don't print EXIT. You have to move the
")" from after the "0" to before the "?" to make the whole part as
optional (the ? applies to the preceding token).
I think I mainly fixed the first line to have two spaces between the 2 and 3
and added another the EOL pattern at the end.
The former was a bug (feature) of Thunderbird, which ate the second
space, the second, I forgot.
That just leaves translating that back into DejaGNU/Expect. :)
Well, that's simple: Either remove all "dg-output" from the test case
and add the string between "m/" and "/s" instead of ... in
C { dg-output "..." }
You additionally have to change "\*" to "\\*" and "$" to "\$".
Or, alternatively, only modify the last "dg-output" by replacing "\$" by
the string starting with "((" and ending with "$". (Again, you have to
replace \* by \\* and $ by \$.)
That should be all. I wonder whether that now works or still fails.
Can you try whether this works (see attachment)?
Tobias
diff --git a/gcc/testsuite/gfortran.dg/g77/f77-edit-x-out.f b/gcc/testsuite/gfortran.dg/g77/f77-edit-x-out.f
index 13a9d7a..4aacd4d 100644
--- a/gcc/testsuite/gfortran.dg/g77/f77-edit-x-out.f
+++ b/gcc/testsuite/gfortran.dg/g77/f77-edit-x-out.f
@@ -8,5 +8,5 @@ C { dg-output "^" }
write(*,'(I1,1X,I1,2X,I1)') 1,2,3! { dg-output "1 2 3(\n|\r\n|\r)" }
C Section 13.5.3 explains why there are no trailing blanks
write(*,'(I1,1X,I1,2X,I1,3X)') 1,2,3 ! { dg-output "1 2 3(\n|\r\n|\r)" }
-C { dg-output "\$" }
+C { dg-output "((\n|\r\n|\r)\\*\\*\\* EXIT code 0(\n|\r\n|\r))?\$" }
end
Re: Why is floor() only compiled to roundsd when using -funsafe-math-optimizations?
On 26 January 2015 at 23:50, Fredrik Tolf wrote: > Consider the following small program: [...] > When compiling this with a -march that supports the roundsd instruction, the > floor() call seems to only be compiled to such an instruction if > -funsafe-math-optimizations is specified. > > Why is this? I notice the glibc's floor() implementation (for SSE4.1-enabled > processors) consists of only this instruction, so barring a bug in glibc, > that would seem to imply to me the roundsd is IEEE-compliant and safe. Why > does GCC consider it unsafe? Partial answer. I first want to point to POSIX, which has: "floor, floorf, floorl - floor function" [...] "An application wishing to check for error situations should set errno to zero and call feclearexcept(FE_ALL_EXCEPT) before calling these functions. On return, if errno is non-zero or fetestexcept(FE_INVALID | FE_DIVBYZERO | FE_OVERFLOW | FE_UNDERFLOW) is non-zero, an error has occurred." No one seems to care about the "errno" handling (and prefers to use the trapping information directly), thus, I wouldn't be surprised if most libc do not set errno. And, looking at the handling in GCC itself (for i386), it is secured by if (SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH && !flag_trapping_math) Thus, using -fno-trapping-math or -fno-signaling-nans is enough - no need for -funsafe-math-optimizations. But that doesn't quite answer the question, why the !flag_trapping_math is needed. At least testing shows that both the GCC version and glibc are signalling a SNaN (when trapping is enabled). Tobias
[GSoC] Google Summer of Code 2015: GCC got accepted
Dear all, GCC has been accepted as Google Summer of Code mentor organization, https://www.google-melange.com/gsoc/homepage/google/gsoc2015 Time line: * March 27: Deadline of Student applications (opens March 16) * Until May 25: Community bonding * May 25 to August 24: Coding time Suggestions for projects are listed at https://gcc.gnu.org/wiki/SummerOfCode Maintainers: Please check whether the list is up to date or some new fancy proposal is missing. Potential GSoC Students: Have a look at the list - but if you have a nice idea, feel also free to discuss other proposals at the GCC mailing lists (-> https://gcc.gnu.org/lists.html). Maintainers: Please register at GSoC 2015 as (potential) mentor. We will need you for ranking the proposals and for mentoring students. This year's GSoC is org-mentored by me and Maxim (as backup org maintainer). Cheers, Tobias
GSoC: Accepted projects
Dear all, we have this year two good GSoC projects for which we managed to get a slot and a mentor: Erik Krisztián Varga will work on the "Addressing mode selection in GCC". Citing the abstract: "CPU architectures often provide a variety of ways to load and save data into memory and registers. Because of this, there are lot of possible addressing sequences for a given code, and finding the optimal one is not a trivial task. However, better addressing can lead to improvements in a program's code size and execution time. The goal of this project is to add a prototype version of such an addressing mode selection pass to GCC." The primary mentor will be Oleg Endo. Fan You will work on "Completing the missing parts of the Fundamentals TS in libstdc++": "Finish extending shared_ptr to support arrays and Polymorphic memory resources (erase allocator from the container's type)." The primary mentor will be Tim Shen. Congratulation to the Erik and Fan You for the accepted proposal. And thanks to the two mentors for volunteering! The list of all accepted proposals (of all orgs) can be found at https://www.google-melange.com/gsoc/org/list/public/google/gsoc2015 Cheers, Tobias
Fwd: AIX vs long double
Cf. http://gcc.gnu.org/ml/gcc/2011-02/msg00109.html and http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47032 Seems as if one needs to add link-time tests to libgfortran for some of the C99 functions - the compile checks exists and succeed. Tobias Original Message Subject: AIX vs long double Date: Mon, 7 Feb 2011 14:01:44 -0500 From: David Edelsohn To: GCC Development AIX provides two versions of long double and declares all of the C99 long double symbols in math.h header file. One implementation aliases long double to IEEE double precision type and the other implementation aliases long double to IBM's paired double format. All of the C99 symbols for IEEE double precision are implemented in libm, but not all of the C99 symbols for the IBM long double format are implemented. IBM's proprietary XL compiler (cc, xlc) defaults to IEEE double precision and provides a special invocation to default to IBM long double (cc128, xlc128). GNU/Linux and GCC on GNU/Linux default to IEEE quad precision long double. Because the long double choice is an ABI change, GCC on AIX switched to GNU/Linux compatibility with support for AIX 6.1, before the incomplete implementation was noticed. This mostly worked until libgfortran started using additional C99 functions, causing GCC Bugzilla [target/47032] libgfortran references complex long double functions missing on AIX libstdc++-v3 on AIX builds with AIX long double support, although user programs that try to access the missing functions (copysign, nextafter, etc.) will experience link-time failures. libgfortran on AIX fails to build with AIX long double support because it accesses the missing functions in its implementation. I would like to solicit feedback about how to proceed: Should GCC on AIX revert back to 64 bit long double size, allowing all libraries to build and work, but breaking GCC/G++ ABI on AIX? Or should it continue to utilize 128 bit long double, building libstdc++-v3 that works if the user program does not utilize the missing symbols and fails to build libgfortran? Thanks, David
[RFC] gfortran's coarray (library version): configure/build and the testsuite
Hello,
Fortran 2008 has a build in parallelization (Coarray [Fortran], CAF)
[1]. gfortran did the first steps to a communication-library version
[2]. The library will be based MPI.
There are two issues I like to discuss in this email:
a) configuring and building
b) Test-suite support
Let's start with (b) which is more important for me. The current scheme
is that the user somehow compiles the communication library (libcaf) [2]
and then builds and links doing something like:
mpif90 -fcoarray=lib fortran.f90 -lcaf_mpi
or alternatively
gfortran -fcoarray=lib fortran.f90 -lcaf_mpi
-I/usr/lib64/mpi/gcc/openmpi/include -L/usr/lib64/mpi/gcc/openmpi/lib64
-lmpi
with some -I, -L -l are added. (Cf. "mpif90 -show" of
some MPI implementations.) The resulting program is then run using, e.g.,
mpiexec -n 3 ./a.out
Alternatively, it could be just "-lcaf_single" which is run like normal
("./a.out").
Thus, one needs some means to add link and compile options - and a means
to add an (optional) run command. Those one would probably pass via
environment variables.
One would then either only run the tests if the environment variable is
set - or if "libcaf_single.a" is installed by default (cf. below), one
could default to linking that version if no environment variable is set.
Then "make check-gfortran" could then always run the CAF library checks
- otherwise, only conditionally.
What do you think? Do you have comments how this should be done? I also
wouldn't mind if someone could help as I am not really comfortable with
the test-suite setup nor do I know Lisp well.
Regarding (a): As mentioned above, one could consider compiling, linking
and installing "libcaf_single" by default. libgfortran/caf/single.c is a
simple stub library which essentially does nothing; the only purpose is
to be able to (re)link -fcoarray=lib compile program without recompiling
and for testing and debugging purpose (e.g. for the testsuite?). If one
wants to seriously use a serial program: -fcoarray=single produces much
faster code.
Additionally, there is libgfortran/caf/mpi.c which is an MPI
implementation in a very early stage. (Currently, MPI v2 is required;
however, the plan is to move to an MPI v1 implementation - maybe using
optionally also MPI v2.)
Thus, the first question is: Should one build and install single.c
(libcaf_single.a) by default? (Might also relate to (a), namely how the
test suite is handled.)
And the second question is: Should one be able to configure and build
mpi.c (libcaf_mpi.a) by some means? I think users interested in could
also do the procedure of [2] - or let their admin do it. (For Linux
distributions one would run into the problem that they typically offer
several MPI implementations, e.g. Open MPI and MPICH2, which couldn't be
handled that way.)
(In any case, only static libraries should be created; the libraries
could then be installed in $PREFIX/$lib/gcc/$target/$version/, where
already libgcc.a etc. are located.)
Tobias
[1] http://gcc.gnu.org/wiki/Coarray
[2] http://gcc.gnu.org/wiki/CoarrayLib
PS: At some point there will be also a shared-memory version - maybe for
GCC 4.8.
PPS: Tiny example program - to be compiled with -fcoarray=single -- or
with -fcoarray=lib as described in [2]:
program coarray_example
print *, 'This is image ', this_image(), ' of ', num_images()
end program coarray_example
RFC: Telling the middle end about asynchronous/single-sided memory access (Fortran related)
Dear all, I have question how one can and should tell the middle end about asynchonous/single-sided memory access; the goal is to produce fast but race-free code. All the following is about Fortran 2003 (asynchronous) and Fortran 2008 (coarrays), but the problem itself should occur with all(?) supported languages. It definitely occurs when using C with MPI or using C with the asynchronous I/O functions, though I do not know in how far one currently relys on luck. There are two issues, which need to be solved by informing the middle end - either by variable attributes or by inserted function calls: - Prohibiting some code movements - Making assumptions about the memory content a) ASYNCHRONOUS attribute and asynchronous I/O Fortran allows asynchronous I/O, which means for the programmer that between initiating the asynchronous reading/writing and the finishing read/write, the variable may not be accessed (for READ) or not be changed (for WRITE). The compiler needs to make sure that it does not move code such that this constraint is violated. All variables involved in asynchronous operations are marked as ASYNCHRONOUS. Thus, for asynchronous operations, code movements involving opaque function calls should not happen - but contrary to VOLATILE, there is no need to take the value all time from the memory if it is still in the register. Example: integer, ASYNCHRONOUS :: async_int WRITE (unit, ASYNCHRONOUS='yes') async_int ! ... WAIT (unit) a = async_int do i = 1, 10 b(i) = async_int + 1 end do Here, "a = async_int" may not be moved before the WAIT line. However, contrary to VOLATILE, one can move the "async_int + 1" before the loop and use the value from the registry in the loop. Note additionally that the initiation of an asynchronous operation (WRITE statement above) is known at compile time; however, it is not known when it ends - the WAIT can be in a different translation unit. See also PR 25829. The Fortran 2008 standard is not very explicit about the ASYNCHRONOUS attribute itself; it simply states that it is for asynchronous I/O. (However, it describes then how async I/O works, including WAIT, INQUIRE, and what a programmer may do until the async I/O is finished.) The closed to an ASYNCHRONOUS definition is the non-normative note 5.4 of Fortran 2008: "The ASYNCHRONOUS attribute specifies the variables that might be associated with a pending input/output storage sequence (the actual memory locations on which asynchronous input/output is being performed) while the scoping unit is in execution. This information could be used by the compiler to disable certain code motion optimizations." Seemingly intended, but not that clear in the F2003/F2008 standard, is to allow for asynchronous user operations; this will presumbly refined in TR 29113 which is currently being drafted - and/or in an interpretation request. The main requestee for this feature is the MPI Forum, which works on MPI3. In any case the following should work analogously and "buf" should not be moved before the "MPI_Wait" line: CALL MPI_Irecv(buf, rq) CALL MPI_Wait(rq) xnew=buf Hereby, "buf" and (maybe?) the first dummy argument of MPI_Irecv have the ASYNCHRONOUS attribute. My question is now: How to properly tell this the middle end? VOLATILE seems to be wrong as it prevents way too many optimizations and I think it does not completely prevent code moving. Using a call to some built-in function does not work as in principle the end of an asynchronous operation is not known. It could end with a WAIT - possibly also wrapped in a function, which is in a different translation unit - or also with an INQUIRE(..., PENDING=aio_pending) if "aio_pending" gets assigned a .false. (Frankly, I am not 100% sure about the exact semantics of ASYNCHRONOUS; I think might be implemented by preventing all code movements which involve swapping an ASYNCHRONOUS variable with a function call, which is not pure. Otherwise, in terms of the variable value, it acts like a normal variable, i.e. if one does: "a = 7" and does not set "a" afterwards (assignment or via function calls), it remains 7. The changing of the variable is explicit - even if it only becomes effective with some delay.) B) COARRAYS The memory model of coarrays is that all memory is private to the image - except for coarrays. Coarrays exists on all images. For "integer :: coarray(:)[*]", local accesses are "coarray = ..." or "coarray(4) = ..." while remote accesses are "coarray(:)[7] = ..." or "a = coarray(3)[2]", where the data is set on image 7 or pulled from image 2. Let's start directly with an example: module m integer, save :: caf_int[*] ! Global variable end module m subroutine foo() use m caf_int = 7 ! Set local variable to 7 (effectively: on image 1 only) SYNC ALL ! Memory barrier/fence SYNC ALL ! caf_int should now be 8, cf. below; thus the f
Re: RFC: Telling the middle end about asynchronous/single-sided memory access (Fortran related)
On 04/15/2011 11:52 AM, Janne Blomqvist wrote: Q1: Is __sync_synchronize() sufficient? I don't think this is correct. __sync_synchronize() just issues a hardware memory fence instruction.That is, it prevents loads and stores from moving past the fence *on the processor that executes the fence instruction*. There is no synchronization with other processors. Well, I was thinking of (a) assumptions regarding the value for the compiler when doing optimizations. And (b) making sure that the variables are really loaded from memory and not remain in the register. -- How the data ends up in memory is a different question; for the current library version, SYNC ALL would be a __sync_synchronize() followed by a (wrapped) call to MPI_Barrier - and possibly some additional actions. Q2: Can this be optimized in some way? Probably not. For general issues with the shared-memory model, perhaps shared memory Co-arrays can piggyback on the work being done for the C++0x memory model, see I think you try to solve a different problem than I want. I am not talking about implementing a full SYNC ALL, but I want to implement for SYNC ALL that no code moving happens and that the memory is moved out of the register into the memory - and related, fetched from the memory afterwards. On 04/15/2011 12:02 PM, Richard Guenther wrote: Q2: Can this be optimized in some way? For simple types you could use atomic instructions for the modification itself instead of two SYNC ALL calls. Well, even with atomic you need to have a barrier; besides the example was only for illustration. I think if one uses the variable in "foo" before the first sync all, one even would need two barriers - atomic read/write or not. (For the current example, setting the value in "foo" is pointless. And the obfuscated way the variable is set, makes the program fragile: someone modifying might not see the dependency and break it.) To conclude: * For ASYNCHRONOUS, one mostly does not need to do anything. Except that for the asynchronous version of the transfer function belonging to READ and WRITE, the data argument needs to be marked as escaping in the "fn spec" attribute. Similarly, for ASYNCHRONOUS dummy arguments, the "fn spec" must be such that the compiler knows the the address could be escaping. (I don't think there is currently a way to mark via "fn spec" a variable as escaping but only be used for reading the value - or to restrict the scope of the escaping.) * For coarrays, I still claim that __sync_synchronize() is enough for SYNC* in terms of restricting code moving and ensuring the registers are put into the memory - and for succeeding accesses to the variable, the data comes from the memory. (The actual implementation of a barrier is a separate task - be it a library call or some shared-memory atomic counter. Only for SYNC MEMORY it should be fully sufficient.) Comments? Tobias PS: The coarray example will fail if there more than two images as one can wait for ever for the SYNC with image 3, with image 4, ...
Re: Syncing with Launchpad Bug Tracker
Ian Lance Taylor wrote: Does any gcc maintainer object to setting this up? It sounds like a good idea to me. I concur. I think the simple way for you to do this is to just create an account on the gcc bugzilla (http://gcc.gnu.org/bugzilla/). Then I can grant that account the necessary rights. I think of one should use http://www.bugzilla.org/docs/3.6/en/html/api/Bugzilla/WebService.html for this. It seems to require xmlrpc.cgi or jsonrpc.cgi - neither of them seems to be installed. Tobias PS: I wonder whether it makes sense to update Bugzilla from 3.6 to 4.0...
Re: GCC on GPU - graphite OpenCL (was: WHOPR Linux distribution)
On 05/30/2011 12:10 PM, Robert Beeporbop wrote: I have some questions for the gcc developers: Also, I had a couple other general development questions: ~ Has anyone been working on GPU support, automatically-utilized or otherwise? I have not used it - nor have I seen much documentation, but the Graphite branch of GCC supports shovelling loops to the GPU via OpenCL. I have to admit I have not seen much documentation for it, just the talk at http://gcc.gnu.org/wiki/summit2010?action=AttachFile&do=get&target=belevantsev.pdf Thus, I cannot comment on how to use it nor how well it performs. Others might know better. Tobias
Re: Strange git commit on master branch in gcc git mirror
On 06/06/2011 11:47 AM, Richard Guenther wrote: Looks like an accident, modifying both trunk and branches/fortran-dev. But the git mirror splits it between the trunk and fortran-dev branches. Jerry, can you fix it up please? This has been fixed else thread (cf. "Strange commit from fortran-dev branch") by HJ's commit: http://gcc.gnu.org/ml/gcc-cvs/2011-06/msg00150.html (The question are: Why does "svn merge" produce merge errors for directories/files untouched in the branch? libgo was never modified in "fortran-dev" and should thus match the trunk to 100%. I also do not quite understand how a merge of the trunk into a branch via "svn merge; svn commit" can create files in the trunk.) Tobias
Re: Strange git commit on master branch in gcc git mirror
On 06/06/2011 02:00 PM, jerry DeLisle wrote: This whole thing has me puzzled. The branch was created before go and libgo existed on trunk. Then I did a plain vanilla merge and got a whole bunch of tree conflicts just for those two directories. Then I attempted to manually resolve those tree conflicts. So Tobias question remains open. Since yesterday after HJ fixed up, I deleted the whole local fortran-dev branch and did a clean checkout of fortran-dev. I have now done another plain vanilla merge of trunk into my local fortran-dev and again I get tree conflicts for go and libgo. I have proceeded to one by one resolve these by copying over the current trunk file. In some cases I have to do an svn add, other places I have to do svn resolve. My impression is that such issues often occurs if one merges a branch into a trunk (as opposed to only merging the trunk into branches). For instance, one has (older fortran-dev checkout): $ svn pg svn:mergeinfo /branches/cxx0x-lambdas-branch:136126-152315 /trunk:130803-130804,144975-163757 I wouldn't be surprised if the "/branches/cxx0x-lambdas-branch" causes the libstdc++v3 merge issues. Nor would me surprise if the current version has a "go" branch. (I don't know svn merge well enough to solve or properly diagnose such issues.) Tobias
Re: Original commit history for gfortran
On 06/19/2011 06:04 PM, "C. Bergström" wrote: 3) Fortran HPC community as a whole - The majority of Fortran users I know work in or around HPC. (I may be biased) With that I can't say most of them care about open source at all. (Some do) They buy/use PathScale/PGI/Intel and for the larger labs I'm not sure if they use gfortran. I think you are biased that most Fortran users work around HPC. They mostly do work in natural science; thus, the kind of programs which run on HPC machines. But there are many users which have programs fast enough to run them on a laptop or work station in serial mode. However, a large minority of those programs also runs in parallel and thus on multi-cores, small clusters up to the HPC machines. While for HPC sites and larger institutions the compiler costs are negligible, for a smaller university group or for the laptop/computer at home, it matters - and gfortran fills the gap. That's also what I hear from vendors: The availability of gfortran - other free Fortran compilers do not seem to play a role (any more) - improves their sales. For HPC sites themselves: All sites I know run Linux have have besides one - or several - vendor compilers also GCC/gfortran installed - and support it. Also some HPC vendors give support to their customers for GCC/gfortran. The reason for having a backup compiler is on one hand that code might not work with the vendor compiler (esp. in case of C/C++) but also if the vendor compiler has a bug. (Someone told me that gfortran saved a PhD thesis by being a replacement for a vendor compiler - with being only minutely slower. The vendor compiler was fixed eventually, but it took several months.) My impression from both HPC sites, from users and other vendors is: All HPC sites have GCC/gfortran installed and use it as additional compiler besides the vendor/commercial compiler(s). Additionally, it is very common to have a commercial compiler at work - and use gfortran at home/on the laptop. Thus, many institutions require that their code also runs with gfortran - even though their main work horse is a commercial compiler. [Personal observation: On x86-64, gfortran is everywhere installed, the Intel compiler is very often, on two systems I also saw PGI - but I have never seen PathScale.] I also do not agree about the statement that they do not care about Open Source. I know several places (large institutions like weather services or small projects) where the availability of a free (mostly: Open Source) compiler is a requirement and features not supported by gfortran my not be included. Thus, gfortran seems to be rather known among users and in the lower management. I heard also of some aviation company which considered to use gfortran because it was the only compiler supporting all their platforms. On the other hand, there are places where only some commercial compiler will do because the management does not trust free/OpenSource software. (They still often have GCC installed additionally.) Most of them want their code to compile, get best performance and sometimes use F2K3. You're not going to stop them from buying commercially supported compilers. First, one can also buy support for GCC and thus gfortran: Either directly via support contracts or indirectly via buying an enterprise Linux distribution. But having a commercial compiler does not rule out having an Open Source compiler; similarly, producing a commercial compiler does not stop companies of also supporting GCC - be it by bug reports, support to customers or directly contribution to the development of GCC. I also use all kinds of compiler: Having multiple compilers helps to find bugs in the code; independent of performance, it is convenient to use the default compiler on a given system - which might be gfortran at home and some commercial compiler at work/HPC centers. However, I do not buy the F2003 and performance argument. gfortran is not really lagging behind Fortran 2003/2008. The number of compilers which are further is quite low and they are also not years ahead. (Though, having a more complete implementation is wished by everyone: Users, compiler developers and also other vendors [at least if they support that feature already].) And with regards to performance, I think GCC is seriously underrated. One reason might be that the default settings are rather on the safe than on the performance side. If I look at benchmarks - such as at the one at Polyhedron (http://www.polyhedron.com/compare0html) I do not see a drastic difference (~25% slower than the fastest compiler for the geometric means) - and the site compares an old version of gfortran against the latest commercial compilers. In my test, GCC 4.7 -Ofast -march=native -funroll-loops -finline-limit=600 is on average 3 to 16% *faster* than the other known-to-be-fast compilers I tested. [1] The variance is large and can easily reach a factor 2 for single
Re: GFortran download - failure
Mike Du wrote: I am helping my 9th grader child to learn using Gfortran for computation programming. [...] But could not find any compiler to download. We are using Vista and Window7. There does not exist an official binary of the GCC. Having said that, the MinGW project and the Cygwin project both offer GCC binaries. If you don't know Cygwin (which provides a Unix-like environment under Windows), you probably should install MinGW. Besides the official Cygwin and MinGW builds, some individuals also build more recent versions of GCC. All those builds are linked from http://gcc.gnu.org/wiki/GFortranBinaries An overview about the new gfortran features in the different GCC releases can be found at http://gcc.gnu.org/wiki/GFortran#news (An IDE, which supports (g)fortran is Photran/Eclipse, cf. http://www.eclipse.org/photran/) Tobias
RFC: DWARF debug tags for gfortran's OOP implementation
Dear all,
during the GCC Gathering I realized during the LTO debugging symbol
discussion that gfortran does not generate debug information for the OOP
features (cf. PR 49475).
The first issue to solve is which DWARF information one should generate.
I have only very limited knowledge of DWARF, except that I quickly
scanned "5.5.3 Derived or Extended Structs, Classes and Interfaces" and
"5.5.7 Member Function Entries" (of http://www.dwarfstd.org/doc/DWARF4.pdf).
I think one should handle member functions (cf. example below). I am not
sure whether other things like type extension or accessibility should be
handled.
Tobias
! Example
module m
implicit none
type parent
integer :: var_p = 3
contains
procedure, nopass :: memb => proc_parent
end type parent
! Side note: nopass disables passing of the type itself ("this")
! Otherwise, the effective type would be passed as first argument to
! proc_parent
type, extends(parent) :: child
contains
procedure, nopass :: memb => proc_child
end type child
contains
subroutine proc_parent()
print *, "proc_parent"
end subroutine proc_parent
subroutine proc_child()
print *, "proc_child"
end subroutine proc_child
end module m
program main
use m
implicit none
class(parent), allocatable :: a
type(child) :: b
allocate (parent :: a)
call a%memb() ! Uses vtable to see that proc_parent should be called
deallocate (a)
allocate (child :: a)
call a%memb() ! Uses vtable to see that proc_child should be called
! Variable access - resolved at compile time
print *, b%var_p ! Directly access "var_p"
print *, b%parent%var_p ! Access it via the parent type
end program main
Re: RFC: DWARF debug tags for gfortran's OOP implementation
Hi Janus, On 06/28/2011 02:12 PM, Janus Weil wrote: Btw, how was the London meeting? Anything interesting to report (Fortran-wise)? General topics, cf. http://gcc.gnu.org/wiki/GCCGathering2011 Fortran wise: - I met Paul and Thomas, we had some discussions - but the notes still have to be completed. - We discussed with Richard the middle-end scalarizer (middle-end array expressions), which lead to the patches Richard has posted. (Fortran to do: Move more to that scalarizer, test it and remove then the Fortran scalarizer.) - We found one module usage with rename debug issue (gdb bug, Jan has already posted [but not committed] a patch). - (Thomas and I realized during the C vs. C++ discussion that Fortran - like C++ but contrary to C - allows a function result as lvalue. Fortran: A pointer-returning function call is a variable. Also other C++ 0x problems or specialities sounded familiar - even if they show differences under the hood.) - Array debug issue: As known, gdb cannot debug C99 VLA/Fortran-90-style arrays. (Jan has written a patch for Fedora in 2007, but that is not upstreamable.) Not discussed as the Diego immediately stopped it to move to another gdb item - thus there is no news about that one. - Fortran OOP debug: Came into my mind in the debug streaming discussion related to freeing the lang-specific node vs. streaming of the debug info. I think one should handle member functions (cf. example below). I am not sure whether other things like type extension or accessibility should be handled. Well, in principle all of those should be handled, I guess. I have to admit that I am not 100% sure which make sense and match Fortran's semantic. I agree we should stream all debug tags which make sense to be streamed. How would one tackle this practically? All the DWARF stuff is generated in the middle-end, I assume See gcc/dwarf2out.c - especially gen_type_die_for_member. This is called in gen_decl_die. I think in order to get this working, one also needs to use DECL_VINDEX (described in tree.h). (and probably the type extension/member function info is already there for C++, right?). Yes, but one might still need middle end changes to accommodate for Fortran - the semantics of Fortran and C++ or Java are slightly different. By the way, I can recomment elfutils's "eu-readelf -w" to dump the DWARF of object files and binaries. (You can also use binutil's "readelf", but that does not indent the output depending on the hierarchy and is thus less readable.) Tobias
Re: RFC: DWARF debug tags for gfortran's OOP implementation
On 06/28/2011 04:21 PM, Michael Eager wrote:
DWARF has attributes for accessibility (e.g., public, private). If the
attributes are similar to those for C++, you should generate them in a
similar fashion.
Well, Fortran has public and private - but I am not sure in how far it
matches C++'s public and private (cf. also below).
> I'm not sure what "type extension" means.
Type extension is inheritance, i.e. Fortran's
type parent
end type parent
type, extends(parent) :: child
end type child
matches C++'s
class parent {};
class child : public parent { };
> If there is
a comparable feature in C++ or other languages supported by DWARF, you
should generate similar DWARF info.
I think that's to a certain extend my problem: I do not completely
understand the current DWARF - nor the fine points of C++ to see in how
far it matches.
For instance: While both in C++ and Fortran variables and methods can be
public or private, Fortran just extends a type without having a concept
of public/private/protected inheritance. The semantics of Fortran's
public, private and protected is related to modules - which does not
really match C++ concept. The DWARF spec does not really tell the
implications of the accessibility tags, which makes it a tad more
difficult to understand what should be done.
I think we will start by marking the VTABLE as such and to try to handle
member functions. - And do compare how g++/gdb handle the approximate
C++ version.
Tobias
Re: GSoC libgomp task project: What should I do next?
Sho Nakatani wrote: > Then I would like to ask you what I should do next. > > (A) Try to change implementation of libgomp following > my current implementation. >Then test and evaluate it using some applications. >(I think Barcelona OpenMP Task Suite [3] contains good applications >to test OpenMP Task implementations) I think it makes sense to start working on libgomp; even if the chosen implementation is not perfect, one can make real-world experiments with it. Additionally, to be used at the end, it has to end up in libgomp. Tobias
RFH: Impose code-movement restrictions and value assumption (for ASYNCHRONOUS/Coarrays)
Hello all,
I seek a tree attribute which tells that a "pointer" (in the
C/middle-end sense) does not alias with any other variable in the
translation unit (i.e. like "restrict"), but on the other hand, it
should prevent code movements and value assumptions across (impure)
function calls - as it is done for non-restrict pointers.
The primary usage are Fortran's coarrays. Those variables exists on all
processes ("images") and can be accessed remotely using one-side
communication semantics. As coarrays are also used in hot loops, I would
like avoid using a non-restricted pointer. A similar issue exists for
variables with the ASYNCHRONOUS attribute.
Middle-end question: How to handle this best with regards to the middle end?
C/C++ question: As one can also with C/C++ use asynchronous I/O,
asynchronous communication via libraries as MPI, or single-sided
communication via POSIX threads - or with C++0x's std:thread: How do you
handle it? Just by avoiding "restrict"? Or do you have a solution, which
can also be applied for Fortran? I'm sure that a "restrict + hope &
pray" solution won't work reliably and thus is not used ;-)
Fortran question: Do my requirements make sense? That is: No code
movements for any variable which is a coarray or has the asynchronous
attribute in the scoping unit. Plus, no assumption of the value after
any call to any impure function? Can something be relaxed or has
anything to be tightened?
ASYNCHRONOUS is defined in the Fortran standard (e.g 2008, Section
5.3.4) and extended to explicitly allow for asynchronous user functions
in Technical Report 29113. The latter functionality will be used in the
Message Passing Interface (MPI) specification 3.0. Like VOLATILE, the
asynchronous attribute might be restricted to a block (in C: { ... }).
Coarrays are defined in the Fortran 2008 standard. (For semantics of
interest, see especially Section 8.5 and, in particular, Subsection 8.5.2.)
The Fortran 2008 standard is available at
ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1830.pdf and the PDTR 29113 at
ftp://ftp.nag.co.uk/sc22wg5/N1851-N1900/N1866.pdf
Example 1: Asynchronous I/O; in this example using build-in functions,
but asynchronous MPI communication would be another example
integer, ASYNCHRONOUS :: a
...
READ(unit_number,ID=idvar, asynchronous='yes') a
...
WAIT(ID=idvar)
... = a
Here, "= a" may not be moved before WAIT.
Example 2: Coarray with sync. The SYNC is not directly called, but via a
wrapper function to increase the fun factor.
subroutine sub(coarray)
integer :: coarray[*]
coarray = 5
call SYNC_calling_proc()
! coarray is modified remotely
call SYNC_calling_proc()
if (coarray /= 5) ...
end subroutine sub
Here, the "if" may not be removed as the image could have been changed
remotely.
Example 3: Allow other optimizations
subroutine sub(coarray1, coarray2)
integer :: coarray1[*], coarray2[*]
coarray1 = 5
coarray2 = 7
if (coarray1 /= 5)
Here, the "if" can be removed as "coarray1" cannot alias with any other
variable in "sub" as it is not TARGET - and, in particular, it cannot
alias with "coarray2" as neither of them is a pointer.
Tobias
Re: RFH: Impose code-movement restrictions and value assumption (for ASYNCHRONOUS/Coarrays)
On 07/13/2011 12:57 PM, Richard Guenther wrote:
On Wed, Jul 13, 2011 at 12:30 PM, Tobias Burnus wrote:
Example 2: Coarray with sync. The SYNC is not directly called, but via a
wrapper function to increase the fun factor.
subroutine sub(coarray)
integer :: coarray[*]
coarray = 5
call SYNC_calling_proc()
! coarray is modified remotely
call SYNC_calling_proc()
if (coarray /= 5) ...
end subroutine sub
Here, the "if" may not be removed as the image could have been changed
remotely.
> From the last two examples it looks like a regular restrict qualified pointer
would work. At least I don't see how it would not.
Would it? How does the compiler know that between "call
SYNC_calling_proc()" the value of "coarray" could change? Hmm,
seemingly, that's indeed the case, looking at the optimized dump of the
example above:
sub (integer(kind=4) * restrict coarray)
{
integer(kind=4) D.1560;
*coarray_1(D) = 5;
sync_calling_proc ();
sync_calling_proc ();
D.1560_2 = *coarray_1(D);
if (D.1560_2 != 5)
Well, then I have a different question: How can one tell the middle end
to optimize the "if (...)" away in the following case? Seemingly having
an "integer(kind=4) & restrict non_aliasing_var" does not seem to be
sufficient to do so:
subroutine sub(non_aliasing_var)
interface
subroutine some_function()
end subroutine some_function
end interface
integer :: non_aliasing_var
non_aliasing_var = 5
call some_function()
if (non_aliasing_var /= 5) call foobar_()
end subroutine sub
That's an optimization, which other compiles do - such as NAG or
PathScale/Open64/sunf95.
Tobias
Re: RFH: Impose code-movement restrictions and value assumption (for ASYNCHRONOUS/Coarrays)
On 07/13/2011 03:27 PM, Ian Lance Taylor wrote:
The C99 restrict qualifier doesn't mean that some random function can
change the memory to which the pointer points; it means that assignments
through pointer 1 can't change the memory to which pointer 2 points.
That is, restrict is all about whether one pointer can affect another;
it doesn't say anything about functions, and in general a call to a
function can change any memory pointed to by any pointer.
That was actually my impression - thus, I wanted to have a different
flag to tag asynchronous/coarray variables, which do not alias but might
change until a synchronization point via single-sided communication or
until a wait with asynchronous I/O/communication. As one does not know
where a synchronization/waiting point is, all code movements and
variable value assumptions (of such tagged variables) should be
prohibited across impure function calls.
By contrast, for a normal Fortran variable without POINTER or TARGET
attribute does not alias - and may not be changed asynchronously.
The latter is what I thought "restrict" (more precisely:
TYPE_QUAL_RESTRICT) does, but seemingly it currently also does the former.
From a C perspective, the trick here is to know that the address
"non_aliasing_var" does not escape the current function, and that
therefore it can not be changed by a function call. gcc already knows
that local variables whose address is not taken do not escape the
current function. I don't know how to express the above code in C; is
there something in there which makes the compiler think that the code is
taking the address of non_aliasing_var? If not, this should already
work. If so, what is it? I.e., what does this code look like in C?
I am not sure whether there is a 100% equivalence, but it should match:
void some_function(void);
void
sub (int *restrict non_aliasing_var)
{
*non_aliasing_var = 5;
some_function ();
if (*non_aliasing_var != 5)
foobar_();
}
Also in this case, the "if" block is not optimized away with -O3.
Tobias
PS: See also just-filled PR middle-end/49733.
Re: RFH: Impose code-movement restrictions and value assumption (for ASYNCHRONOUS/Coarrays)
On 07/13/2011 03:46 PM, Tobias Burnus wrote: On 07/13/2011 03:27 PM, Ian Lance Taylor wrote: [...] it doesn't say anything about functions, and in general a call to a function can change any memory pointed to by any pointer. I misread the paragraph - in particular the last sentence. In Fortran that's not the case. Fortran alias rules says that a dummy argument may only be modified through the dummy argument, i.e. for subroutine foo(a, b) ! "a" and "b" are passed by reference integer :: a, b a = 5 b = 6 call bar() the value of "a" is neither modified by "b = 6" nor by "call bar()". Exception: If "a" is a target (i.e. some pointer may point to it) or "a" is a POINTER. Thus, in my test case, the function call does not may change the value - and, thus, the "if" block can be optimized away. See quote of the Fortran standard at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49733#c0 Seemingly, in C only the first case, Fortran's "b = 5" (C: "*b = 5"), would be guaranteed to be not affected if "a" (and "b") are "restrict", while the function call can change the value. In that sense, I do not seem to need a new flags for asynchronous/coarrays - which are handled by TYPE_QUAL_RESTRICT, but I need a new flag for normal (noncoarray, nonasychronous) variables, which are passed by value or are allocatable - and where a function call won't affect the value. Tobias
Re: RFH: Impose code-movement restrictions and value assumption (for ASYNCHRONOUS/Coarrays)
On 07/14/2011 11:21 AM, Richard Guenther wrote:
That Fortran passes everything by reference is really really not helping
optimizers.
I think it also does not harm optimizers. The problem is just that
optimizers are not tuned for it - but for C with later (C99?) attached
qualifiers.
Whether one has
int func(int arg) {
do_something_with_arg
return arg;
}
or
subroutine func(arg) ! arg passed by reference
integer :: arg
shouldn't make any difference for optimizers. The value can only change
by either directly modifying "arg" or by calling a procedure with it as
explicit actual argument, which modifies it.
In Fortran, any tricks like modifying "arg" via a global variable (which
shares the memory location with "arg") are invalid. It is not even
allowed to read the value of the global variable (having the same memory
address as "arg"), if the value of "arg" is modified in "func" - not
even before it is modified.
If one wants to play those tricks, "arg" needs to have at least the
TARGET attribute (i.e. some pointer may point to it) - or even the
POINTER attribute, for which nearly anything goes.
Some of the restrictions are compile-time checkable, i.e. if you try to
pass a non-target, non-pointer variable as actual argument to a
pointer-dummy argument, you will get a compile-time error.
For others, it's the users responsibility. For instance, you may pass a
non-TARGET variable to a function taking a TARGET as dummy argument, but
as soon as that function returns, all pointers to the dummy become
undefined.
The advantage of Fortran is that it not only applies to basic types like
"int" but also to character strings, arrays - and to "allocatables".
Allocatables have to be allocated before one can use them, allowing one
to change the array size or (for deferred-length strings) the string
length. Still, they share the same semantics, i.e. no aliasing unless
there is TARGET or (for non-ALLOCATABLEs) a POINTER attribute.
(Side remark: allocatables [unless SAVE, i.e. in static memory] are
automatically freed, when one leaves their "scoping unit", e.g. for a
variable local to a function, when one leaves that function. That's
Fortran's way of garbage collection. If one does not want it, one has to
use pointers.)
In that sense, the lack of a qualifier in C, which matches Fortran, is
"really really not helping optimizers". ;-)
It's also not helping that my Fortran FU is weak
so I'm not able to produce testcases that will immediately show
issues with (proposed) middle-end representations.
Yes, that's indeed a problem, though I don't see how one can best solve
it. I can only offer to help with questions, finding the relevant
sections in the standard, and helping to interpret them.
For what it is worth, in the Fortran 2008 standard, one finds regarding
this issue (cf. PR 49733) more at:
* "12.5.2.13 Restrictions on entities associated with dummy arguments"
Namely, rules when a dummy argument may be changed behind the scenes,
including when the standard guarantees that the actual and the dummy
argument actually point to the same memory.
That also forbids that one passes twice the same variable as actual
argument, if one modifies either argument. (Unless one has a pointer -
or a TARGET (+ some additional restrictions).)
The additional restrictions are there to avoid issues, when
copy-in/copy-out happens. In some cases Fortran has to make a copy - and
pass the copy instead of the (address of the) actual argument, e.g. if
the dummy argument wants to have a contiguous array but the actual
argument has strides.
* "16.5.2.5 Events that cause the association status of pointers to
become undefined"
For instance, the issue mentioned above: One has a pointer to some
object which has locally a target attribute - or exists only locally -
then the pointer becomes undefined, if one returns from that function.
There are some more relevant spots in the standard, e.g. those where
pointer and target is defined. Or the place, where argument passing is
handled, cf. "12.5.2 Actual arguments, dummy arguments, and argument
association".
For instance an actual argument may only passed to a pointer dummy
argument, if it is a pointer - or if the dummy argument has the target
attribute and the dummy argument is INTENT(IN); the first avoids alias
issues and the second ensures that one does not modify the memory
address to which the argument points to. Cf. "12.5.2.7 Pointer dummy
variables" for the latter.
Tobias
Fortran's DO CONCURRENT - make use of it middle-end-wise
Hi, Fortran 2008 has a do concurrent construct, where the programmer guarantees that the result is independent of the order; e.g. do concurrent (i = 1:10:2) ! from, to, step/stride A(i) = sin(B(i)) end do can be run as i = 1, 3, 5, 7, 9; in any permutation or in parallel. The plan is to translate it as normal loop; however, it would be useful if this non-order-dependence could be used by the middle end (general optimization or at least for -floop-parallelize-all / -ftree-parallelize-loops). Is there a way to tell the middle-end about this property? Tobias PS: By default, do concurrent loops will run consecutively, but I was thinking of optionally using OpenMP parallelization for those by explicitly adding an OMP directive. The do-concurrent parsing/resolving patch is at http://gcc.gnu.org/ml/fortran/2011-09/msg2.html. The tree-generating part still needs to be written, but should be simple (for the serial case).
Re: performance decreased
On 11/07/2011 07:32 PM, Francisco Llaryora wrote: With the purpose of measuring the SpedUp by changing the number of threads. I did run fourty times by changing the value OMP_NUM_THREAD from 1 to 40. I run it in a node with 40 cores Xenon.4 Processors with 10 cores each one. The next is time in sec, no speedUP: First, the email is more appropriate for gcc-help@ as gcc@ is the developer list. Regarding the issue itself: Try OMP_WAIT_POLICY=PASSIVE - cf. http://gcc.gnu.org/onlinedocs/libgomp/OMP_005fWAIT_005fPOLICY.html or any OpenMP documentation. One still expects that the performance decreases if one has more threads than cores, but it should not decrease as much as with ACTIVE. The default value is something in between - it burns wait cycles as with ACTIVE but only for a very short time while with ACTIVE is does so for a much longer time before continuing to wait passively. Note: The comments are for the current version; I am not sure about GCC 4.2.1 - it might well be that the default wait policy wasn't falling back to a passive wait that quickly. Tobias
Re: libstdc++ breaks bootstrap (at least on x86_64-darwin11, maybe more)
On 11/08/2011 09:10 AM, FX wrote: > I've filed PR 51026 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51026). In the meantime, how do I build "the old way", with just a C compiler? I tried to configure with "--enable-languages=c,fortran --disable-build-with-cxx", but the configure script still says: > >> The following languages will be built: c,c++,fortran You could try: --disable-build-poststage1-with-cxx Tobias
Re: gfortran 4.6 incompatible with previous?
Sewell, Granville wrote: I know that gfortran 4.3 was not compatible with earlier versions (can't mix object code), but now a user is telling me that 4.6 is not compatible with 4.3, is that true? The library .so version number of GCC 4.3 to 4.7 is the same and no symbol was deleted from libgfortran since 4.3 - though new symbols have been added such that a GCC 4.6 program might not work with a GCC 4.3 libgfortran. Thus, a newer libgfortran should work with older programs. I am also not aware about any ABI issue. The only thing I am aware of are issues with REAL(16) and selected_real_kind. Namely, mixing a libgfortran on a system where libquadmath was available with one compiler which does not support libquadmath. That might to lead issues when a configure script tests for the available kind numbers in a certain way (such as HDF5 did). Note: The gcc@gcc.gnu.org mailing list is about the development of GCC. Such questions are better suited for the gcc-h...@gcc.gnu.org mailing list, though they might also be suited for the fort...@gcc.gnu.org. Tobias
Re: trunk bootstrap failure in libgfortran for i686-pc-cygwin
Hi Rainer, Rainer Emrich wrote: > error: 'I' undeclared (first use in this function) That's PR 40863 and a patch has been posted to http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01520.html That patch should also remove all those > warning: no previous prototype for 'csinhf' warnings. Tobias
Re: Large slowdown with gfortran vs f77 (x7)
On 09/04/2009 05:04 PM, FX wrote:
> -- it's unarguably a glibc issue: if exp() is fast and expf() is
> slow, why doesn't glibc implement expf() by calling exp()? (yes, there
> can be other issues like rounding or so, but they can also be dealt
> with separately)
If I recall correctly, it is mostly an x86-64 problem. AMD has some math
patches for GLIBC which speed things up a lot. I think those are used in
openSUSE/SLES but not in Fedora. On the other hand, the AMD patches have
a problem with signaling NaN, which is being fixed [1,4].
Some older timings (from PR 34128) on openSUSE (!) -- for "sin" but
there is the same problem as for exp:
g77 gfortran
-m32 real(4) 0.408s 0.421s
-m64 real(4) 1.040s 0.589s ! sinf on x86-64: 40% faster!
-m32 real(8) 0.411s 0.408s
-m64 real(8) 0.976s 0.968s ! sin on x86-64
As this is a math-library problem, one cannot do much from the
GCC/gfortran side. You could consider using the AMD Math Core Library
[2] which implements fast versions of the trigonometric functions and
exp [3]. Those functions are not fully IEEE compliant but it might not
be needed in your case [3,4]. (See AMCL manual [3] for the details.)
Intel's MKL should have something similar if you are on Intel hardware
and have by chance the library.
Switching to SUSE or applying the patches oneself is another
possibility. (I do not know why the patches are not included in the
upstream version of glibc. There must be some (somewhat) well-founded
reason.)
> -- a similar bug was already reported a year and a half ago, and no
> activity was recorded on that front
> (http://sources.redhat.com/bugzilla/show_bug.cgi?id=5997);
Well, it is assigned to someone @suse and as written it is not an issue
on openSUSE. It might be also related to the AMD patches and the reason
why they are not included in GLIBC.
Tobias
(who uses openSUSE [11.1/Factory] at home, Fedora [version 6 (!)] at work)
[1] For sNaN, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39314 and
https://bugzilla.novell.com/show_bug.cgi?id=487576
[2] ACML (free as in free beer): http://www.amd.com/acml
[3]
http://developer.amd.com/cpu/Libraries/acml/onlinehelp/Documents/Simple.html
; the functions are prefixed by "fast" but if you include the library
before the math library ("-lm") the fast version is used instead of the
libm version; "-lm" is automatically appended (internally) at the end of
the command line when using "gfortran" thus simply adding "-lacml_mv"
(or was it -lacml ?) to the command line should be sufficient.
[4] Note, the GLIBC patches of AMD are supposed to be fully IEEE
complient while the fastexp etc. of ACML are not (esp. regarding
denormal numbers and signaling NaN.)
Re: is LTO aimed for large programs?
On 11/09/2009 12:03 AM, Basile STARYNKEVITCH wrote: > is gcc-trunk -flto -O2 aimed for medium sized programs (something like > bash), or for bigger ones (something like the linux kernel, the Xorg > server, the Qt or GTK graphical toolkit libraries, or bootstrapping GCC > itself. My understanding is that LTO aims at both, but that one needs to use -fwhopr for really large systems as the otherwise e.g. the memory usage may exceed the available memory. I don't know whether one can really estimated how much memory compilation needs. It is surely not a simple function on the number of code lines. I tried -flto successfully for our 100 kLoC Fortran code and there lto1 needs <1/2 GB of RAM (370 MB if I recall correctly). (Thanks to especially Richard; initially more than 4 GB were needed and lto1 crashed thus). Toon also used LTO [1] for their HIRLAM weather forecasting program, which has according to [2] 1.2 MLoC in Fortran and O(10 kLoC) in C. If I recall correctly, bootstrapping GCC also works in principle, except for problems when comparing stage2 with stage3. > Perhaps the question is when not to use -flto and use -fwhopr instead? My rule of thumb is: Try -flto first, if it does not work (running out of memory), try -fwhopr. I think the advantage of -flto is also that it is better tested, while -fwhopr has known issues. Tobias [1] http://gcc.gnu.org/ml/gcc/2009-10/msg00122.html [2] http://moene.org/~toon/GCCSummit-2006.pdf
Re: GCC development plan
On 01/20/2010 12:17 PM, Piotr Wyderski wrote: > is there something like an unofficial documentation > of trunk features Well, for the new features in the trunk: Have a look at the release notes for the upcoming version 4.5 at http://gcc.gnu.org/gcc-4.5/changes.html For C++ 0x (1x?) have also a look at http://gcc.gnu.org/gcc-4.5/cxx0x_status.html > or a more or less detailed development > plan of the compiler? No - there might be some (tentative) plan for some parts of the compiler and ideas what should implemented first but there is no overall development plan. > What I'm trying to say... how do you know what to work on That depends on who is paying (if any), personal interest, and perceived importance of a given feature/bug. > and what are schedules? See Stage 1/2/3 at http://gcc.gnu.org/develop.html and the time line on that page that gives you an idea of a schedule of GCC (though not for a given feature). Tobias
Re: How to update my SSH authorized_keys on gcc.gnu.org?
Hi, > Is there a way to update my SSH authorized_keys on gcc.gnu.org? I > tried As written at http://sourceware.org/cgi-bin/pdw/ps_form.cgi ssh sourceware.org updatekey < ~/.ssh/id_dsa.pub should do the deed. Tobias
(Fortran) Coarrays in GCC - library/build questions, RFC & announcement
Hello all,
I have a library-usage question to the SC, a (wrapping) library
building/shipping question to GCC@ readers, and, of course, I also want
to announce the project a bit wider and seek for comments.
* * *
Coarrays are an extension of Fortran, which date back to the 1990s but
have now been integrated into the upcoming* Fortran 2008 standard
(ISO/IEC 1539-1:2010). Coarrays can be used to parallelize programs
using a partitioned global address space (PGAS) and following the
single-program--multiple-data (SPMD) scheme. As coarrays are part of the
language, a strong type checking is provided. Each process (called
image) has its own private variables. Only variables which have a
so-called codimension are addressable from other images.
The C (C99) analogue is called Unified Parallel C (UPC), which is,
however, not (yet) an international standard. There exists a GCC UPC
compiler since a couple of years and there are plans to merge it
("GUPC") into GCC 4.6 trunk, cf.
http://gcc.gnu.org/ml/gcc/2010-04/msg00117.html (There are also plans to
standardize the UPC--Coarray-Fortran interoperability.)
A bit longer description of coarrays, references to the standard, to
introductory texts, to talks (including Toon's GCC Summit talk), the
current status, and an unsorted collection of thoughts can be found at
http://users.physik.fu-berlin.de/~tburnus/coarray/README.txt
Currently, single-image support (i.e. compiling a coarray program as
serial program for one image) is (nearly fully) implemented in the GCC
trunk (4.6, -fcoarray=single). The next step is add support for multiple
images. It is planned to implement a shared-memory thread-based version
and a library version.
* * *
Regarding the library version (which will be implemented first): There
are several suitable libraries available:
a) MPI (message passing interface, http://www.mpi-forum.org/), which is
widely used and several Open Source implementations exist, such as Open
MPI and MPICH(2). MPI is also well documented (the API, how to use a
given implementation, and MPI in general). MPIv1.x allows for two-sided
communication, MPIv2 added additionally single-sided communication.
b) GASNet (http://gasnet.cs.berkeley.edu/) a single-sided communication,
BSD-licensed library by UC Berkeley. This library is also used by GUPS
via Berkeley's UPC library.
c) ARMCI (Aggregated Remote Memory Copy,
http://www.emsl.pnl.gov/docs/parsoft/armci/) + GA (Global Array), a
single-sided communication library by DoE's EMSL; rather free licence
and redistributable, but requires registration for download at the EMSL
homepage
d) Not really available, but as in-between solution: One can implement
the threaded version used a library, which might be a faster way to get
additionally a threaded version than implementing thread version
directly in the front end. (Which is also planned.)
[Both (b) and (c) are used with PGAS languages on HPC systems and are
said to scale well. There are claims that the PGAS programming scheme
allows to write faster communication libraries than MPI does, but as the
underlying task is the same, I only expect minute difference, which more
depend on the actual implementation than on the interface/programming
model. The plan is to provide at the end MPI, GASNet, and ARMCI+GA
wrappers, which will then allow to do comparisons.]
Question to the GCC Steering Committee: Do you see any problems of
supporting those libraries? For Berkeley's GASNet the question also
applies to GUPS. (GUPS uses shared-memory via threads but also can use
Berkeley's UPC library, which is based on GASNet.)
Implementation: The current plan is to start with (a), i.e. MPI, and try
hard to avoid race conditions and thus possibly tries to avoid
single-sided communication.** - Next would be probably (d), (b), or a
version of (a) which fully relies on MPI's single-sided-communication
[let's see]. There might be also two versions for each library - one
which tuned for performance and one for debugging, possibly with
different API.
As - contrary to, e.g., UPC - one cannot read C header files in Fortran,
one needs a always a wrapper library. For MPI it also depends on the MPI
implementation. Thus, I was thinking of simply providing
gfortran_caf_.c files to be used as:
mpicc -c $(CFLAGS) gfortran_caf_mpi.c
mpif90 $(FFLAGS) coarray_program.f90 gfortran_caf_mpi.o
That way also LTO nicely works (even without gold); however, the
question is only how to best ship this library. The thread version could
be simply compiled and shipped with gfortran, but the others ... Ideas?
Suggestions?
For the implementation, the current agenda is:
a) Finishing the remaining to-do items for the single-image version
b) Design an MPIv1 version (maybe simultaneously start implementing the
more obvious parts, such as startup, barriers, shutdown, and error abort)
c) Implement the the actual coarray initialization/communication part
d) Test it
I would be happy to have some more support for (b), (c) and (d
Re: [graphite] Cleanup of command line parameters [PATCH]
Hi, Tobias Grosser wrote: > another patch. It contains: > > - Removal of documentation outside of common.opts for (-fgraphite, > -floop-block, -floop-interchange, -floop-strip-mine) > This means doc/invoke.texi. > (Proposed by Richi) While I agree that -fgraphite does not make sense as user option, I'm not sure about -floop-block and -floop-interchange. I could imagine that some users would like to play with this option (though I have no real opinion about this). > - Removal of flag "-floop-strip-mine", as it never will improve > performance and so there will be no use for it. > (Proposed by Harsha) I might have misunderstood Harsha, but I think he said that it only does not improve the performance if used by itself, i.e. combined with other options it is/might be profitable. Thus one may leave it in as undocumented option. (I have no opinion about this and I did no tests, I only wanted to stress the "by itself".) In any case, those changes should also be documented at http://gcc.gnu.org/gcc-4.4/changes.html, which currently lists all options. Tobias B
Re: Errors on your web page
Robert Dewar wrote: >> With regard to the top 10% performance, Absoft is simply comparing >> the overall mean performance numbers from the Polyhedron Benchmark. >> gfortran will never look good by that metric because there are at >> least 2 programs that would benefit from in-lining non-contained >> subprograms and intraprocedural optimization. gfortran doesn't do >> these, yet. > overall mean performance seems a perfectly fair measure I would say ... I agree. Against the "will never do" we should do something in 4.5 - the mutiple-decl-per-function problem really should to be fixed; cf. http://gcc.gnu.org/ml/fortran/2008-05/msg00247.html and (predating that) http://gcc.gnu.org/ml/fortran/2008-02/msg5.html Tobias
Re: Account Update
Emmanuel Fleury wrote: >> Username : (**) >> Password : (**) >> Date of Birth : >> Future Password : ()(Option) > > Do they really think that it will succeed ??? > I guess not. I guess they do. For spam, the reply rate might be as low as low as 1 in 12 million, for pishing (if cleverly done) the number is probably higher. For spam see: http://www.theregister.co.uk/2008/11/10/storm_botnet_spam_economics/ * * * To have something less off topic: I find it quite interesting, how much the benchmark results between the same two compilers vary on different platforms. Compared with Absoft Fortran, GCC/gfortran 4.3 is by the following percentages slower: 0.2% 32bit on Vista64 on Intel XEON 21%32bit on Vista AMD X2 6%64bit on Linux64 on Intel XEON 16%64bit on Linux64 on AMD X2 (http://www.polyhedron.com/compare0html) (See also "Errors on your web page" thread in gcc@/fortran@) While the bottleneck programs vary a lot, fatigue and gas_dyn are slow on all platforms (incl. on AMD Athlon64, where other compilers are up to almost twice as fast). If we are lucky, the middle-end array work by Richard plus the single-function-decl patch will fix that ... Tobias
Supporting IEEE 754 [exceptions] (in a front end [gfortran])
Hello, I'm thinking about how to implement Fortran 2003's IEEE support in gfortran. The IEEE allow a) To set an IEEE value (NaN, INF, etc.) b) Check whether a value is NaN, etc. c) To query for IEEE capabilities (IEEE_SUPPORT_NAN, IEEE_SUPPORT_SQRT (a sqrt() which has IEEE exception support), etc.) d) To query/set haltmodes for DIVIDE_BY_ZERO, INVALID etc. e) Getting/setting an exception flag, etc. While (a) and (b) can be easily handled in the front end, I don't see how I can handle the rest efficiently. Most parts are provided by fenv.h, for which I seemingly have to write a wrapper function (in libgfortran) as the typedefs and constants cannot be made available in the front end - or have I missed something? My biggest issue is that I don't see how I can compile-time evaluate the following - or how to evaluate it at all: if (IEEE_SUPPORT_NAN(x)) &! should be always true (or false) on a given system x = IEEE_VALUE(IEEE_QUIET_NAN, x) ! x = qNaN (trivial in the front end). The Fortran standard lists: IEEE_SUPPORT_DENORMAL, _DIVIDE (by zero), _INF, _NAN, _SQRT (a sqrt which follows IEEE), _ROUNDING, (and _IO). Is there some possibility to query the target whether e.g. NaN is supported? For querying/setting the halting mode, I would work with the data in libgfortran/config/*.h. Tobias
Re: Supporting IEEE 754 [exceptions] (in a front end [gfortran])
Joseph S. Myers wrote: >> My biggest issue is that I don't see how I can compile-time evaluate the >> following - or how to evaluate it at all: >> >> if (IEEE_SUPPORT_NAN(x)) &! should be always true (or false) on a >> given system >> > See MODE_HAS_NANS etc. in real.h > Thanks. There I find: - MODE_HAS_NANS - MODE_HAS_INFINITIES - MODE_HAS_SIGNED_ZEROS - MODE_HAS_SIGN_DEPENDENT_ROUNDING Those match IEEE_SUPPORT_INF, IEEE_SUPPORT_NAN. However, Fortran 2003 has additionally: - IEEE_SUPPORT_ROUNDING (which can be catered for using the presence of fenv.h's FE_DOWNWARD etc.) and also the following items: a) IEEE_SUPPORT_DIVIDE - Inquire whether the processor supports divide with the accuracy specified by the IEEE International Standard. b) IEEE_SUPPORT_DENORMAL - Inquire whether the processor supports IEEE denormalized numbers. c) IEEE_SUPPORT_SQRT - Inquire whether the processor implements SQRT in accord with the IEEE Inter19 national Standard. (In this case, SQRT(-0.0) has the value -0.0.) d) IEEE_SUPPORT_UNDERFLOW_CONTROL - Inquire whether the procedure supports the ability to control the underflow mode during program execution. For the latter four I don't see where I can obtain those pieces of information. Additionally, one is supposed to set (if possible) whether (1) denormal numbers are used or (2) denormals are zero (DAZ); I have not seen an easy option to set/query. (SSE2 seems to allows DAZ, cf.gcc/config/i386/crtfastmath.c) Tobias
Re: gcc binary download
Ben Elliston wrote: >> I cannot find where to download gcc binary for Linux. Can you email me >> the link? It's so confusing in the http://gcc.gnu.org/ web site. > > You should install gcc from your Linux distribution. It will be far > easier. To add: There are no binaries of GCC released by the GCC project or the FSF. Thus it is best to stick to the GCC packages which come with your Linux version. If you need newer versions, you could consider updating your Linux or try to find newer builds on some build server, which some Linux distributions have. Otherwise, you could consider building GCC yourself, cf. http://gcc.gnu.org/install/. (Furthermore, some gfortran developers offer regular GCC builds, which are linked at http://gcc.gnu.org/wiki/GFortranBinaries; those are all unofficial builds, come without any warrantee/support, and due to, e.g., library issues they may not work on your system.) Unless you need a newer version because of some new feature or because of a fixed bug, I would stay with the GCC of the Linux distribution and - if needed be - I would update the installed Linux. Tobias
Re: gfortran manual : error in function range documentation ?
Hello Jacque,
Jacques Lefrere wrote:
> I thought that the argument of the intrinsic function "range"
> could be integer, real or complex.
> But the manual mentions that it should be of type real or complex only.
> (see "http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gfortran/RANGE.html#RANGE";)
Corrected for 4.4.0. Thanks for the report. Note: The better email
address for gfortran issues is fort...@gcc.
Tobias
PS: I committed as obvious in Rev. 143524:
Index: ChangeLog
===
--- ChangeLog (Revision 143523)
+++ ChangeLog (Arbeitskopie)
@@ -1,3 +1,7 @@
+2009-01-20 Tobias Burnus
+
+ * invoke.texi (RANGE): RANGE also takes INTEGER arguments.
+
2009-01-19 Mikael Morin
PR fortran/38859
Index: intrinsic.texi
===
--- intrinsic.texi (Revision 143523)
+++ intrinsic.texi (Arbeitskopie)
@@ -214,7 +214,7 @@
* @code{RANDOM_NUMBER}: RANDOM_NUMBER, Pseudo-random number
* @code{RANDOM_SEED}: RANDOM_SEED, Initialize a pseudo-random number
sequence
* @code{RAND}: RAND, Real pseudo-random number
-* @code{RANGE}: RANGE, Decimal exponent range of a real kind
+* @code{RANGE}: RANGE, Decimal exponent range
* @code{RAN}: RAN, Real pseudo-random number
* @code{REAL}: REAL, Convert to real type
* @code{RENAME}:RENAME,Rename a file
@@ -8884,7 +8884,7 @@
@node RANGE
-...@section @code{RANGE} --- Decimal exponent range of a real kind
+...@section @code{RANGE} --- Decimal exponent range
@fnindex RANGE
@cindex model representation, range
@@ -8904,7 +8904,8 @@
@item @emph{Arguments}:
@multitable @columnfractions .15 .70
-...@item @var{X} @tab Shall be of type @code{REAL} or @code{COMPLEX}.
+...@item @var{X} @tab Shall be of type @code{INTEGER}, @code{REAL}
+or @code{COMPLEX}.
@end multitable
@item @emph{Return value}:
Re: Creating imaginary inf/nan in GCC
Hi Kaveh, Kaveh R. GHAZI wrote: > I'm trying to create complex number expressions that contain inf or > nan in the imaginary part. I.e. (0 + inf I) or (0 + nan I). If it does not need to be C (e.g. to try MPC in the middle end), you could use Fortran: ! compile with gfortran -fno-range-check complex :: z z = cmplx(0.0, 0.0/0.0) print *, z end Tobias
Re: GCC & OpenCL ?
Michael Meissner wrote: > I am just starting to think about adding OpenCL support into future > versions of GCC, as it looks like a useful way of programming highly > parallel type systems, particularly with hetrogeneous processors. At > this point, I am wondering what kind of interest people have in > working together on OpenCL in the GCC compiler? I'm personally less interested in OpenCL (maybe because I don't know it yet so well - I just have head of it). However, I wonder whether one can create some infrastructure in GCC which can also be used by other parts. Or at least I assume one needs to have some library which somehow provides the communication and common routines for that. And at least for non-shared memory this library support could be of interest for Fortran 2008's coarrays and for UPC. (I don't know what the plans for UPC support in GCC; there exists patches on top of GCC 4.2 but seemingly there is no plan of merging it. I also don't know how big the demand is. For Fortran, I think there is some demand already since Cray and g95 support it - and there is the intention to implement it in gfortran and ifort.) (It would also be cool if one could get Fortran work in heterogenous environements such as GPUs, but I don't see how Fortran/coarrays fit into the OpenCL ideas.) Tobias
Re: heise.de comment on 4.4.0 release
Toon Moene wrote: >>> Can somebody with access to SPEC sources confirm / deny and file a bug >>> report, if appropriate? >> >> It is an x87 bug only and has already been filed: >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39856 and working on >> being fixed already. The reason that is was not found before - despite several people running SPEC's CPU benchmark - was exactly that they run it in 32bit mode. After they send me the options, Richard could immediately reproduce the problem. The patch is at: http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01926.html > A x87 bug only exposed using SPEC ?!?!?!? Seemingly yes. To a certain extend this was by accident as "-msse3" was used, but it is on i586 only effective with -mfpmath=sse (that is not completely obvious). By the way, my tests using the Polyhedron benchmark show that for 32bit, x87 and SSE are similarly fast, depending a lot on the test case thus it does not slow down the benchmark too much. The author regretted that Atom support is not available in 4.4 - it will be in 4.5, but that's rather late given that the CPUs are around since some time. I agree with this. If I understood correctly, the 32bit mode was used since the 64bit mode needs more than the available 2GB memory. Similarly, the option -funroll-loops was avoided as they expect that unrolling badly interacts with the small cache Atom processors have. (That CPU2006 runs that long, does not make testing different options that easy.) > What are these guys thinking - like, lets cripple this benchmark and > use completely out of date floating point arithmetic ? > Duh, I hope the rest of their reporting is more useful ... Well, I think it will be just a short article announcing the new version. I think it is difficult to give a full account of a new compiler if the article needs to be in the next issue. And SPEC seemingly runs for 4 days with the additional problem that if a result is too much off, the run completely aborts (which makes the journalists avoid certain options). I would have liked that the options were reported. For instance -ffast-math was not used out of fear that it results in too imprecise results causing SPEC to abort. (Admittedly, I'm also careful with that option, though I assume that -ffast-math works for SPEC.) On the other hand, certain flags implies by -ffast-math are already applied with -O1 in some commercial compilers. David Korn wrote: > They accused us of a too-hasty release. My irony meter exploded! I think their accuse it right and wrong at the same time. Between the release candidate and the release there was indeed very little time. Thus 4.4.0 was released before he could report the bug which he found in RC1. -- And it is wrong since there was a very long Stage4. Whether one agrees, also depends on one's expectations. I think .0 releases are usually not as stable as people only start with .0 testing the release and that release candidates are also not much more tested than the Stage4 builds. (And in general, I believe .0 releases or - even most of the time the trunk - are quite well usable.) Tobias
Re: Checking for the Programming Language inside GCC
Basile STARYNKEVITCH wrote: > Shobaki, Ghassan wrote: >> In some optimization passes it may be useful to know the programming >> language that we are compiling. Is there a way to get that information >> in the middle end and back end? > > I am not sure that would be a good idea. In fact you are suggesting that > the intermediate representation[s] (ie Gimple) is not intermediate > enough, since you need something more (like the source language). I think some kind of optimization behaviour depends on the language used, but this should be represented in some way in the Gimple and not via some parsing of the programming language. One example is "-fcx-fortran-rules" which allows for complex multiplication and division to follow the Fortran rules - it is used when compiling the gfortran library, but I think it is also a good option for several C programs as it goes a middle way between strict IEEE and maximal optimization. Another example of language specifics is the handling of parenthesis: Fortran requires that they are honoured, e.g. for (a/b)/c the optimization a/(b*c) is not allowed. This is honoured via PAREN_EXPR and thus there is no need to know the programming language. Thus I'm in favour of programming language specific optimization - by having it expressed in the Gimple itself. Tobias PS: I think one exception are debugging symbols - there is some language dependence, but I think no plug-in support is planed for this.
Re: Fortran bootstrap broken
Dear Gerald, > /usr/test/gcc/gcc/fortran/intrinsic.c: In function 'add_sym': > /usr/test/gcc/gcc/fortran/intrinsic.c:306: error: enum conversion in > assignment is invalid in C++ Can you try whether the following patch works? If so, you can commit it as obvious. (I cannot test/commit it until this evening.) Tobias Index: intrinsic.c === --- intrinsic.c (revision 147659) +++ intrinsic.c (working copy) @@ -303,7 +303,7 @@ type = (bt) va_arg (argp, int); kind = va_arg (argp, int); optional = va_arg (argp, int); - intent = va_arg (argp, int); + intent = (sym_intent) va_arg (argp, int); if (sizing != SZ_NOTHING) nargs++;
Re: [fortran] Different FUNC_DECLS with the same DECL_NAME - MAIN__ and named PROGRAM main functions [was Re: gcc-4.5-20090528 is now available]
Dave,
Dave Korn wrote:
> I see there are two places in fortran/parse.c
Side remark: You know that the actual middle-end TREE is only generated
in trans*.c? Thus, all things which happen before like parse.c can be
still remodeled in trans*c.
> that call
> main_program_symbol(): either as a result of a PROGRAM statement
> ... or if the code starts with a nameless block:
>
The reason is one can write a Fortran main program either as:
---
print *, 'Hello World'
end
---
or as
---
program HelloWorld
print *, 'Hello World'
end program HelloWorld
---
And both denotes a Fortran main program, which should end up under the
(assembler) name "MAIN__" in the .s file.
> One thing I don't understand is why there is a function
> gfc_sym_mangled_function_id() in trans-decl.c that has this code:
> /* Main program is mangled into MAIN__. */
> if (sym->attr.is_main_program)
> return get_identifier ("MAIN__");
>
As for debugging messages etc. the name to the front end is, e.g.,
"HelloWorld", one needs to convert it into MAIN__ (which is for historic
reasons the assembler name of the Fortran main program in code generated
by several compilers, be it g77, g95, gfortran, ifort or sunf95).
> It appears that this or something else is causing both functions to have the
> same DECL_NAME when they are passed to gimple_expand_cfg() in cfgexpand.c, so
> they both get identified as the main function and potentially have static ctor
> calls to __main() inserted. This is because the testcase I'm looking at uses
> a "program main" directive. The two function decls have different underlying
> sym_refs - "MAIN__" vs. "main" - but they both point to the same
> IDENTIFIER_NODE, for "main" in their DECL_NAME fields.
>
Hmm, that should not be the case that the middle end gets confused. I
think there is some merit in printing also the name, e.g., HelloWorld
rather than MAIN__ in middle end warnings ("unused variable foo in
HelloWorld"), but otherwise the name given to the program in gimple
shouldn't matter as long as the assembler name is MAIN__.
Seemingly there are some issues; however, they do not seem to be new.
MAIN__ was before generated and the main() was linked from the library.
The library's main (in fmain.c / libgfortranbegin.a) should already have
called __main(). Thus if gimple_expand_cfg() automatically adds __main()
calls for "main" then this must have happened before.
> I think this is probably an invalid way for the front-end to drive the
> mid-end - it's ok when the two functions are semantically the same, as when
> C++ clones constructors, but these are actually two entirely different
> functions, and in particular, only one of them should cause
> expand_main_function to be called. I'd like that to be the real "main"
> function, which is where the fortran runtime init gets called, rather than
> "MAIN__", which is the user-level main function, because the runtime init
> itself might need to use st_printf and that won't work until __main() is
> called, but I'm not sure how to disetangle the two now.
>
I agree that for "main" the call to "__main()" should happend and thus
expand_main_function should be called. I'm not sure in about the exact
assumptions of the middle end. In principle, it would be OK if the
MAIN__ function would show up as MAIN__ in gimple/-fdump-tree-original.
The only potential inconvenience I see, is the mentioned reference to
MAIN__ instead of in middle-end warnings, which can
confuse users.
Tobias
Re: [fortran] Different FUNC_DECLS with the same DECL_NAME - MAIN__ and named PROGRAM main functions [was Re: gcc-4.5-20090528 is now available]
Dave Korn wrote: >> Wouldn't the simplest thing be to rename the other main function - the >> initialisation one that is automatically generated by create_main_function()? >> It could be called anything different we liked, and it's not user-visible, >> so >> it ought to not be a problem to rename? >> > > Argh, no. Cygwin crt0 for one expects the entrypoint function to be called > _main in any language. Hmmm. > In terms of -fdump-tree-original (all(?) other dumps place the assembler name in parentheses) and for the special handling of "main" in the middle end, having MAIN__ everywhere would be useful. Except for the warnings; having test.f90: In function 'helloworld': test.f90:3: warning: 'i' is used uninitialized in this function is better readable for the user than a test.f90: In function 'MAIN__': test.f90:2: warning: 'i' is used uninitialized in this function Frankly, I don't have any idea how to solve the problem while retaining the proper names in the middle-end diagnostics. But of cause on can decide that the diagnostic output is less of a problem and live with "MAIN__" in the middle-end diagnostics. (The front-end diagnostic message are not effected.) Tobias
Re: [fortran] Different FUNC_DECLS with the same DECL_NAME - MAIN__ and named PROGRAM main functions [was Re: gcc-4.5-20090528 is now available]
Dave Korn wrote:
> Dave Korn wrote:
>> Dave Korn wrote:
>>> Tobias Burnus wrote:
>>>> I agree that for "main" the call to "__main()" should happend and thus
>>>> expand_main_function should be called. I'm not sure in about the exact
>>>> assumptions of the middle end. In principle, it would be OK if the
>>>> MAIN__ function would show up as MAIN__ in gimple/-fdump-tree-original.
>>>> The only potential inconvenience I see, is the mentioned reference to
>>>> MAIN__ instead of in middle-end warnings, which can
>>>> confuse users.
>
> Is it legitimate to have a space in an IDENTIFIER_NODE? I have a cheeky
> idea:
> - gfc_get_symbol (name, ns, &main_program);
> + identifier = gfc_get_string ("PROGRAM %s", name);
> That should give reasonable warnings from the middle end, no? I don't know
> what it might do to debugging though.
Currently one can use "b MAIN__" and "b helloworld" in the debugger:
(gdb) b helloworld
Breakpoint 1 at 0x400737: file test.f90, line 3.
(gdb) b MAIN__
Note: breakpoint 1 also set at pc 0x400737.
Breakpoint 2 at 0x400737: file test.f90, line 3.
(gdb) b main
Breakpoint 3 at 0x4007b9: file test.f90, line 9.
I have another idea: Just handle "PROGRAM main" specially by using the
name "MAIN__". It should be still quite readable in the middle-end
diagnostics. Furthermore, it matches the assembler name and using "b
main" one still get something useful - and it is less confusing for
everyone (middle end, users of -fdump-tree-original etc.) if there is
only a single "main".
Tobias
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(Revision 148004)
+++ gcc/fortran/trans-decl.c(Arbeitskopie)
@@ -289,7 +289,10 @@ gfc_get_label_decl (gfc_st_label * lp)
static tree
gfc_sym_identifier (gfc_symbol * sym)
{
- return (get_identifier (sym->name));
+ if (sym->attr.is_main_program && strcmp (sym->name, "main") == 0)
+return (get_identifier ("MAIN__"));
+ else
+return (get_identifier (sym->name));
}
@@ -3874,6 +3877,8 @@ create_main_function (tree fndecl)
tmp = build_function_type_list (integer_type_node, integer_type_node,
build_pointer_type (pchar_type_node),
NULL_TREE);
+ main_identifier_node = get_identifier ("main");
+ ftn_main = build_decl (FUNCTION_DECL, main_identifier_node, tmp);
ftn_main = build_decl (FUNCTION_DECL, get_identifier ("main"), tmp);
DECL_EXTERNAL (ftn_main) = 0;
TREE_PUBLIC (ftn_main) = 1;
Re: [fortran] Different FUNC_DECLS with the same DECL_NAME - MAIN__ and named PROGRAM main functions [was Re: gcc-4.5-20090528 is now available]
Jerry DeLisle wrote: > I tested the above on x86-64 Linux. OK to commit. Thanks for the review. Committed: Sendinggcc/fortran/ChangeLog Sendinggcc/fortran/trans-decl.c Transmitting file data .. Committed revision 148035. Tobias
Re: [fortran] Different FUNC_DECLS with the same DECL_NAME - MAIN__ and named PROGRAM main functions [was Re: gcc-4.5-20090528 is now available]
Dave Korn wrote:
>>> + main_identifier_node = get_identifier ("main");
>>> + ftn_main = build_decl (FUNCTION_DECL, main_identifier_node, tmp);
>>>ftn_main = build_decl (FUNCTION_DECL, get_identifier ("main"), tmp);
>>>
> I just took a second look at this. We surely didn't mean to build two decls
> and throw one away, did we?
Why have I always read
- ftn_main = build_decl (FUNCTION_DECL, get_identifier ("main"), tmp);
although there was no "-"?
> I think the second assignment to ftn_main was supposed to have been
> deleted when the middle argument was changed. Ok if so?
Yes, of cause it should have been deleted. OK for the trunk and thanks
for spotting it!
Tobias
> gcc/fortran/ChangeLog
>
> * trans-decl.c (create_main_function): Don't build main decl twice.
Re: error in gfc_simplify_expr
Hello,
Revital1 Eres wrote:
> I get the following error while bootstrap trunk -r148275 on ppc.
Worked with r148271 on x86-64-linux.
> -I../libdecnumber../../gcc/gcc/fortran/expr.c -o fortran/expr.o
> cc1: warnings being treated as errors
> ../../gcc/gcc/fortran/expr.c: In function גgfc_simplify_exprג:
> ../../gcc/gcc/fortran/expr.c:1660:8: error: גstartג may be used
> uninitialized in this function
The code is new but seems to be OK:
1657if (p->ref && p->ref->u.ss.start)
1658 {
1659gfc_extract_int (p->ref->u.ss.start, &start);
1660start--; /* Convert from one-based to zero-based.
I don't see why "start" should be uninitialized here.
Tobias
Re: [RFC] Introduce -Ofast
On 05/06/2010 04:24 PM, Richard Guenther wrote: > I would initially propose to make -Ofast be -O3 -ffast-math > and would strongly encourage target maintainers that consider > adding to -Ofast make sure that popular benchmarks for > their target still behave correctly when using -Ofast. I am in favour of the suggestion. How about also adding "-march=native" (for targets where it is available)? Otherwise, one may end up, e.g. on x86, to compile for i386 - and then -O3 -ffast-math won't help. But also on other systems configuring for the compile system is useful - but it should be overridable. Another option one could consider is -funroll-loops. (Intel's "-fast" also implies "-xHost". Pathscale (always) defaults to "-march=auto", Portland also [unless "-tp..." is used].) Tobias
Re: [RFC] Switching implementation language to C++
Am 31.05.2010 20:50, schrieb Mark Mitchell: > Gabriel Dos Reis wrote: > >> Yes, this is the sort of issues I have in mind. For example, I do not see >> how >> we can use C++ in tree.h without requiring other front-ends to use C++, at >> least >> for the parts that use tree.h. By components, I meant "for example, is it >> the >> case that the C++ front-end would use C++, but with sufficient care >> that it can be >> linked with the common C codes if the C front-end is not using C++?". > > Yes, I think it's possible for a front-end or a back-end to use C++ > without the rest of the compiler doing so. I doubt that's where we get > maximum bang from allowing use of C++, but it could certainly be done. I think the C -> C++ switch is in terms of compiling GCC an all or nothing: You need have all of a sudden a C++ compiler for bootstrapping; otherwise, the middle end and all front ends should be C++ save thanks to to work of Ian et al. and -Wc++-compat. Thus, you get all the avantages and disadvantage of C++ and a C++ compiler everywhere. And as long as the code remains clear to a little-experience C++ compiler (at least, e.g., the middle-end code to which a front end programmer is exposed), I also do not see a problem for C++. Whether and to what extend the different parts of the compilers will switch, remains to be seen. I could imagine that some C++ will slowly creep in everywhere. Tobias, who is rather agnostic about the change, but who does not want to see overloaded operators of the type "+" or "*" (neither in C++ nor in Fortran).
[Patch,Fortran,Committed] Re: Incorrect format of copyright statement for Fortran manuals
Gerald Pfeifer wrote: > It has been reported via the FSF that 'gfortran.info' is copyrighted by > the FSF '1999-2008', although it should be under the form '1999, 2000, > [other years], 2008'. > > Would you mind changing this accordingly? > Fixed in Rev. 160390 using the attached patch. Thanks for the report! Tobias 2010-06-07 Tobias Burnus * gfc-internals.texi (copyrights-gfortran): Fix copyright year format. * gfortran.texi (copyrights-gfortran): Ditto. diff --git a/gcc/fortran/gfc-internals.texi b/gcc/fortran/gfc-internals.texi index f01393e..cee34a0 100644 --- a/gcc/fortran/gfc-internals.texi +++ b/gcc/fortran/gfc-internals.texi @@ -1,7 +1,7 @@ \input texinfo @c -*-texinfo-*- @c %**start of header @setfilename gfc-internals.info -...@set copyrights-gfortran 2007-2010 +...@set copyrights-gfortran 2007, 2008, 2009, 2010 @include gcc-common.texi diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi index a7f6fba..96a912e 100644 --- a/gcc/fortran/gfortran.texi +++ b/gcc/fortran/gfortran.texi @@ -1,7 +1,7 @@ \input texinfo @c -*-texinfo-*- @c %**start of header @setfilename gfortran.info -...@set copyrights-gfortran 1999-2010 +...@set copyrights-gfortran 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 @include gcc-common.texi
Re: Patch pinging
On 06/08/2010 05:42 PM, H.J. Lu wrote: >> Think about mercurial or git. Every one can commit on his/her own >> local repository, and "publish" his/her repository. [...] > > git is an excellent tool to create and share patches. Maybe we should > have an open gcc git mirror with gitweb and every contributor can create > his/her own branches and publish them. Well, we do: Goto http://repo.or.cz/w/official-gcc.git and click on "fork". I do like Git, but Git seems to make mostly sense if you have a small project on which you are working. If you have only a small patch (or a collection of small and unrelated patches), it won't help much. Additionally, I do not think that pulling from a branch will happen - rather that one creates patches from an (published or unpublished) git repository and submits them like normal. Thus, I do not think it helps with patch reviewing/tracking, though I believe it helps with developing patches. Tobias, who happily uses his private GCC git repository, which does not diverge much from the git master.
Re: [Patch,Fortran,Committed] Re: Incorrect format of copyright statement for Fortran manuals
On 06/13/2010 03:09 PM, Gerald Pfeifer wrote: > On Mon, 7 Jun 2010, Tobias Burnus wrote: > >>> It has been reported via the FSF that 'gfortran.info' is copyrighted by >>> the FSF '1999-2008', although it should be under the form '1999, 2000, >>> [other years], 2008'. >>> >> Fixed in Rev. 160390 using the attached patch. >> > Thanks, Tobias! > > Any chance you could make the similar change for GCC 4.5 as our active > release as well? > Fixed in Rev. 160797 using the attached patch. Index: gfortran.texi === --- gfortran.texi (revision 160796) +++ gfortran.texi (working copy) @@ -1,7 +1,7 @@ \input texinfo @c -*-texinfo-*- @c %**start of header @setfilename gfortran.info -...@set copyrights-gfortran 1999-2008 +...@set copyrights-gfortran 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 @include gcc-common.texi Index: ChangeLog === --- ChangeLog (revision 160796) +++ ChangeLog (working copy) @@ -1,3 +1,8 @@ +2010-06-15 Tobias Burnus + + * gfc-internals.texi (copyrights-gfortran): Fix copyright year format. + * gfortran.texi (copyrights-gfortran): Ditto. + 2010-06-15 Jakub Jelinek PR fortran/44536 Index: gfc-internals.texi === --- gfc-internals.texi (revision 160796) +++ gfc-internals.texi (working copy) @@ -1,7 +1,7 @@ \input texinfo @c -*-texinfo-*- @c %**start of header @setfilename gfc-internals.info -...@set copyrights-gfortran 2007-2008 +...@set copyrights-gfortran 2007, 2008, 2009 @include gcc-common.texi
Re: plugin-provided pragmas & Fortran or Ada?
On 06/22/2010 06:20 AM, Basile Starynkevitch wrote: > Assuming a plugin (e.g. MELT) add a new pragma using PLUGIN_PRAGMAS, is > this pragma usable from Ada or Fortran code? > > I am not very familiar with Ada or Fortran. I believe Ada has some > syntax for pragmas -but do Ada pragma have the same API inside GCC > plugins as C or C++ pragmas?- and I am not sure about Fortran. Many > Fortran dialects or implementations parse specially some kind of > comments -but I don't know if these are giving pragma events to plugins. Regarding Fortran: "Pragmas" seem to be only rarely used in Fortran programs - with possible exception of the !DEC$ directives, which seem to be mostly used for attributes and has been superseded mostly by the C bindings of Fortran; !DEC$ has also been used for parallelization as precursor of OpenMP. gfortran only supports setting some attributes via !GCC$ (and supports OpenMP) - but nothing more; cf. http://gcc.gnu.org/onlinedocs/gfortran/GNU-Fortran-Compiler-Directives.html The plan is to support all function/variable attributes, but that's still on the TODO list. Additionally, one might add more functionality, but that's currently not even on the TODO list. Thus, if you need more, it has to be programmed. Tobias
