Re: LIBGCC14 fails to build on MacOS Sequoia x64

[FX Coudert via Gcc]

Hi Samuele,

The gcc-patches list is for submission and review of patches to GCC. For 
general help, please use the generic gcc mailing-list (gcc@gcc.gnu.org 
), and/or file a bug directly at 
https://gcc.gnu.org/bugzilla/

The issue you’re referring to, a failure to build libgcc_s.1.dylib on macOS 15 
for Intel, is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809

Best,
FX

Re: GCC Quad-Precision Math Library Manual: Errors

[FX Coudert via Gcc]

Hi Peter,

You are right, thanks for reporting these issues in the libquadmath 
documentation. I am CC’ing the GCC mailing-list. Does the following patch seem 
right?

diff --git a/libquadmath/libquadmath.texi b/libquadmath/libquadmath.texi
index dc2a9ff374b..ce4accf6421 100644
--- a/libquadmath/libquadmath.texi
+++ b/libquadmath/libquadmath.texi
@@ -118,15 +118,15 @@ The following mathematical constants of type 
@code{__float128} are defined.
   @table @asis
 @item @code{M_Eq}: the constant e (Euler's number)
-@item @code{M_LOG2Eq}: binary logarithm of 2
-@item @code{M_LOG10Eq}: common, decimal logarithm of 2
+@item @code{M_LOG2Eq}: base 2 logarithm of e
+@item @code{M_LOG10Eq}: decimal (base 10) logarithm of e
 @item @code{M_LN2q}: natural logarithm of 2
 @item @code{M_LN10q}: natural logarithm of 10
 @item @code{M_PIq}: pi
 @item @code{M_PI_2q}: pi divided by two
 @item @code{M_PI_4q}: pi divided by four
 @item @code{M_1_PIq}: one over pi
-@item @code{M_2_PIq}: one over two pi
+@item @code{M_2_PIq}: two over pi
 @item @code{M_2_SQRTPIq}: two over square root of pi
 @item @code{M_SQRT2q}: square root of 2
 @item @code{M_SQRT1_2q}: one over square root of 2


Regarding the naming of M_SQRT1_2q, it simply follows the traditional M_SQRT1_2 
macro which, according to glibc doc: "These constants come from the Unix98 
standard and were also available in 4.4BSD”. I agree with you that logic would 
dictate M_1_SQRT2, but we simply follow the existing pattern there.

Best,
FX


> Many thanks for the 'quadmath.h' library, which is where I found this email 
> address.  I have addressed this email to you as the problem isn't a bug in 
> GCC itself, it didn't seem right to try and coerce it into the bug report 
> system, and I didn't know where else to start, but I appreciate that the 
> problem is not yours, especially as the corresponding comments in  
> 'quadmath.h' itself are correct.  I'd be grateful if you could forward it to 
> whoever is maintaining the Quad-Precision Math Library Manuals. 
> 
> Three of the constants are mis-labelled in the current (14.2) version of that 
> Library Manual document (and in all the previous versions I've looked at) , 
> as follows:
> 
> M_LOG2Eq:  )  both are described as logarithms of 2, whereas they are 
> logarithms of 'e'
> M_LOG10Eq: )
> ...
> M_2_PIq:described as "one over two pi", actually two over pi [2/pi]
> 
> Additionally, whilst I realise that the two are mathematically equal, the 
> generic 'M_numerator_denominatorq' naming format convention suggests that 
> M_SQRT1_2q, described as "one over square root of 2", should better be 
> labelled as "square root of (1/2)"; M_1_SQRT2q would be the name that 
> corresponds to the original description.  Is this a lacuna in the standard?
> 
> Regards
> 
> Peter Randall

Re: Nonbootstrap build with Apple clang broken in gm2

[FX Coudert via Gcc]

> Ah yes indeed it is systematic.  Many thanks for spotting this - git
> pushed GNU flex required
> https://gcc.gnu.org/pipermail/gcc-cvs/2024-July/406305.html

Couldn’t the generated files be committed to the tree, so that flex is not 
needed (unless one modifies the source). This is what is done for the other use 
of flex.

FX

Re: Nonbootstrap build with Apple clang broken in gm2

[FX Coudert via Gcc]

Another quick m2-related question: I am seeing, in a build of GCC 14.1.0 on 
Linux, that flex is called when building with the modula-2 front-end. It was 
not the case in previous builds, and the only difference is that I added m2 to 
the languages. Is that systematic? If so, the prerequisites page should be 
amended: https://gcc.gnu.org/install/prerequisites.html

Best,
FX

Nonbootstrap build with Apple clang broken in gm2

[FX Coudert via Gcc]

Hi,

I am unable to perform a nonbootstrap build when gm2 is included, with Apple 
clang 15 as compiler. The error is due to incorrect inclusion of headers 
( and ) which are included after GCC’s system.h has been 
included, and macros like abort() are redefined or poisoned.

I think the correct idiom in GCC is to #define INCLUDE_STRING (for example) 
before “system.h” is included, rather than #include  directly. The 
attached patch fixes the issue.

Best,
FX



gm2.diff
Description: Binary data

Re: What is the purpose of these two fixincludes?

[FX Coudert via Gcc]

> Laugh or cry.

Wow. But how does any other compiler deal with them?

I’ve pushed the change as 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=66d6b1861ec57ba29540a5fa7854df3978ba5409
Please let me know if you see any issue in the next tests.

FX

Re: What is the purpose of these two fixincludes?

[FX Coudert via Gcc]

Hi,

> I usually just install with install-no-fixedincludes, but really this
> should probably be a configure option and default to on.

It would be great if we could measure what fixincludes are still needed, on 
which targets. Could we possibly modify contrib/test_summary to list the 
fixincluded headers? How would people feel about that?

Out of 273 fixes, ~170 are explicitly target-specific. When we look at machines 
involved:

  34 *-*-aix*
  22 *-*-darwin*
  15 *-*-solaris2*
  12 *-*-vxworks*
  10 *-*-*vms*
   5 *-hp-hpux11*
   3 i[34567]86-*-linux*
   3 *-hp-hpux11.[0-3]*
   3 *-*-solaris*
   3 *-*-netbsd*

The question is: out of the remaining ~100, how many trigger on common targets, 
when they are actually useless. Having the information in the test summary 
would be great, I think.

Best,
FX

What is the purpose of these two fixincludes?

[FX Coudert via Gcc]

Hi,

I am trying to reduce the number of unneeded fixincludes that are used on 
darwin (because fixincluded headers make it impossible to change SDK once the 
compiler is built, which is common practice in the macOS world, and quite 
useful).

There are currently two generic (not darwin-specific) fixincludes that are 
triggered: 

- math_exception. Right not it is very broad, and only skipped on glibc and 
Solaris. I think the comment "This should be bypassed on __cplusplus, but that 
does not work on solaris 8 and 9” indicates that this fix is really outdated, 
probably not necessary. Most if not all headers nowadays are C++-compatible, 
no? I would like to suggest replacing this with a proper bypass on __cplusplus, 
with the attached patch.

- stdio_stdarg_h and stdio_va_list. These, I simply don’t understand what is 
the intent. It appears to me that they are not necessary on darwin, and I could 
potentially add it to “skip”. But… is it really necessary anywhere? It is from 
before 1998.


I would welcome guidance on how to handle these, or advice on what the second 
is supposed to achieve.

Thanks,
FX



math_exception.diff
Description: Binary data

Re: Updated Sourceware infrastructure plans

[FX Coudert via Gcc]

> I regenerate auto* files from time to time for libgfortran. Regenerating
> them has always been very fragile (using --enable-maintainer-mode),
> and difficult to get right.

I have never found them difficult to regenerate, but if you have only a non 
maintainer build, it is a pain to have to make a new maintainer build for a 
minor change.

Moreover, our m4 code is particularly painful to use and unreadable. I have 
been wondering for some time: should we switch to simpler Python scripts? It 
would also mean that we would have fewer files in the generated/ folder: right 
now, every time we add new combinations of types, we have a combinatorial 
explosion of files.

$ ls generated/sum_*
generated/sum_c10.c generated/sum_c17.c generated/sum_c8.c  generated/sum_i16.c 
generated/sum_i4.c  generated/sum_r10.c generated/sum_r17.c generated/sum_r8.c
generated/sum_c16.c generated/sum_c4.c  generated/sum_i1.c  generated/sum_i2.c  
generated/sum_i8.c  generated/sum_r16.c generated/sum_r4.c

We could imagine having a single file for all sum intrinsics.

How do Fortran maintainers feel about that?

FX

Analyzer test failures

[FX Coudert via Gcc]

Hi,

I’m seeing the following analyzer test failures on darwin. They were introduced 
in December, when the tests were moved around:

FAIL: c-c++-common/analyzer/fd-glibc-byte-stream-socket.c
FAIL: c-c++-common/analyzer/fd-manpage-getaddrinfo-client.c
FAIL: c-c++-common/analyzer/fd-mappage-getaddrinfo-server.c
FAIL: c-c++-common/analyzer/fd-symbolic-socket.c

They all have an unexpected analyzer warning, like this:

/Users/fx/gcc-upstream/gcc/testsuite/c-c++-common/analyzer/fd-glibc-byte-stream-socket.c:
 In function 'int main()':
/Users/fx/gcc-upstream/gcc/testsuite/c-c++-common/analyzer/fd-glibc-byte-stream-socket.c:43:17:
 warning: leak of file descriptor 'socket(2, 1, 0)' [CWE-775] 
[-Wanalyzer-fd-leak]
/Users/fx/gcc-upstream/gcc/testsuite/c-c++-common/analyzer/fd-glibc-byte-stream-socket.c:43:17:
 note: (1) socket created here
/Users/fx/gcc-upstream/gcc/testsuite/c-c++-common/analyzer/fd-glibc-byte-stream-socket.c:43:17:
 note: (2) when 'socket' succeeds
/Users/fx/gcc-upstream/gcc/testsuite/c-c++-common/analyzer/fd-glibc-byte-stream-socket.c:43:17:
 note: (3) 'socket(2, 1, 0)' leaks here
FAIL: c-c++-common/analyzer/fd-glibc-byte-stream-socket.c  -std=c++98 (test for 
excess errors)

I see they’ve been xfail'ed off on AIX and HPUX in previous patches, so I’m 
wondering: are the tests glibc-specific? If so, should we mark them as suck? Or 
are they real failures of the analyzer?

FX

Re: Analyzer failure due to missing header

[FX Coudert via Gcc]

> std::max and std::min, introduced by d99d73c77d1e and 2bad0eeb5573, are not 
> available because  is not included.

I originally thought this was only seen in cross-compilers, but it actually 
broke bootstrap on darwin.
Attached patch restores it, OK to commit?

FX



0001-Analyzer-include-algorithm-header.patch
Description: Binary data

Analyzer failure due to missing header

[FX Coudert via Gcc]

Hi David,

I’m seeing the following failures on building GCC with Apple’s clang:

> /Users/fx/devel/gcc/gcc-repo-write/gcc/analyzer/region-model.cc:3426:16: 
> error: unexpected type name 'byte_size_t': expected expression
>std::max (bytes.m_size_in_bytes,
> ^
> /Users/fx/devel/gcc/gcc-repo-write/gcc/analyzer/region-model.cc:3426:12: 
> error: no member named 'max' in namespace 'std'; did you mean 'fmax'?
>std::max (bytes.m_size_in_bytes,
>~^~~
> fmax
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/cmath:420:9:
>  note: 'fmax' declared here
> using ::fmax _LIBCPP_USING_IF_EXISTS;
> ^
> /Users/fx/devel/gcc/gcc-repo-write/gcc/analyzer/region-model.cc:3450:18: 
> error: expected '(' for function-style cast or type construction
>   = std::min ((TREE_STRING_LENGTH (string_cst)
>  ^
> /Users/fx/devel/gcc/gcc-repo-write/gcc/hwint.h:59:31: note: expanded from 
> macro 'HOST_WIDE_INT'
> #   define HOST_WIDE_INT long long
>   ^
> /Users/fx/devel/gcc/gcc-repo-write/gcc/analyzer/region-model.cc:3450:14: 
> error: no member named 'min' in namespace 'std'
>   = std::min ((TREE_STRING_LENGTH (string_cst)
> ~^

std::max and std::min, introduced by d99d73c77d1e and 2bad0eeb5573, are not 
available because  is not included. The following patch fixes the 
build for me:

diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/region-model.cc
index 4f31a6dcf0f..1ca8c8839bf 100644
--- a/gcc/analyzer/region-model.cc
+++ b/gcc/analyzer/region-model.cc
@@ -20,6 +20,7 @@ along with GCC; see the file COPYING3.  If not see
   #include "config.h"
 #define INCLUDE_MEMORY
+#define INCLUDE_ALGORITHM
 #include "system.h"
 #include "coretypes.h"
 #include "make-unique.h”


Could you check it is what you intended, and push it?

Thanks,
FX

Re: Testsuite issue and warning about floating-point conversion

[FX Coudert via Gcc]

Hi,

> That seems like a bug in the aarch64-darwin port.
> 1.0q should definitely be __float128 rather than _Float128.

Is there a simple way to test what type 1.0q is, in C? I tried using _Generic, 
but it says

> a.c:7:52: error: ‘_Generic’ specifies two compatible types
> 7 |   int i = _Generic(0.q, default: 0, __float128: 1, _Float128: 2);
>   |^
> a.c:7:37: note: compatible type is here
> 7 |   int i = _Generic(0.q, default: 0, __float128: 1, _Float128: 2);
>   | ^~


Then:

>  /* For C, let float128t_type_node (__float128 in some backends) be the
> same type as float128_type_node (_Float128), for C++ let those
> be distinct types that mangle and behave differently.  */

OK so my mistake is in not defining float128t_type_node in the aarch64-darwin 
port. I will do that. Am I correct in reading that this “new” way of handling 
extended types in C++ was introduced in 2022-09-27? If so, my port to 
aarch64-darwin was done two years ago, and that explains why I missed that 
entirely…

Thanks a lot Jakub for the help!
FX

Re: Testsuite issue and warning about floating-point conversion

[FX Coudert via Gcc]

Hi,

> I don't know why 1.0q is _Float128 on aarch64 instead of __float128.

That’s weird. I create it in this way:

+  /* Populate the float128 node if it is not already done so that the FEs
+ know it is available.  */
+  if (float128_type_node == NULL_TREE)
+{
+  float128_type_node = make_node (REAL_TYPE);
+  TYPE_PRECISION (float128_type_node) = 128;
+  SET_TYPE_MODE (float128_type_node, TFmode);
+  layout_type (float128_type_node);
+}
+
+  lang_hooks.types.register_builtin_type (float128_type_node, "__float128");



> An explicit cast prevents the warning:
> float dummy = (float) 1.0q;

Yes, I think a cast does the job. It will still error out when q suffix is not 
supported, and will not have other messages.

FX

Re: Testsuite issue and warning about floating-point conversion

[FX Coudert via Gcc]

Hi Jakub,

I should have pinged you, I see you recently touched that code.

FX


> Le 18 août 2023 à 21:07, FX Coudert  a écrit :
> 
> Hello,
> 
> On the WIP aarch64-darwin port of GCC 
> (https://github.com/iains/gcc-darwin-arm64), there are some C++ testsuite 
> failures which are due to the following:
> 
> 1. The testsuite check_effective_target_has_q_floating_suffix check tries to 
> compile the code "float dummy = 1.0q;” to determine if the q suffix is 
> allowed on floating-point types.
> 
> 2. The check should pass on aarch64-darwin, and indeed the code compiles, 
> because the q suffix matches the _Float128 type.
> 
> 3. However, a warning is emitted which makes the test fail:
> 
> a.cpp:1:15: warning: converting to 'float' from '_Float128' with greater 
> conversion rank
>1 | float dummy = 1.0q;
>  |   ^~~~
> 
> 
> 4. Therefore, the expectations of the different tests fail.
> 
> 
> Now, I am not sure why other targets are not affected in the same way, for 
> example, x86_64-linux or x86_64-darwin. Also, I am unsure: is the warning 
> warranted here? If so, we should adjust the check to silence warnings, or use 
> a cast. Or is the warning emitted in error?
> 
> Any help would be appreciated.
> 
> Thanks,
> FX

Testsuite issue and warning about floating-point conversion

[FX Coudert via Gcc]

Hello,

On the WIP aarch64-darwin port of GCC 
(https://github.com/iains/gcc-darwin-arm64), there are some C++ testsuite 
failures which are due to the following:

1. The testsuite check_effective_target_has_q_floating_suffix check tries to 
compile the code "float dummy = 1.0q;” to determine if the q suffix is allowed 
on floating-point types.

2. The check should pass on aarch64-darwin, and indeed the code compiles, 
because the q suffix matches the _Float128 type.

3. However, a warning is emitted which makes the test fail:

a.cpp:1:15: warning: converting to 'float' from '_Float128' with greater 
conversion rank
1 | float dummy = 1.0q;
  |   ^~~~


4. Therefore, the expectations of the different tests fail.


Now, I am not sure why other targets are not affected in the same way, for 
example, x86_64-linux or x86_64-darwin. Also, I am unsure: is the warning 
warranted here? If so, we should adjust the check to silence warnings, or use a 
cast. Or is the warning emitted in error?

Any help would be appreciated.

Thanks,
FX

Re: Hundreds of gcc.dg/guality failures on both 14 and 13.1 branches

[FX Coudert via Gcc]

Hi,

> Which is why people should just compare testsuite results from earlier run
> on the same configuration to watch for regressions, especially in the
> guality testsuite.

All this gives the idea of a test framework that is too rigid, or tests that 
are too fragile. I mean, The accumulation of noise just decreases the value of 
the the test results.

FX

Hundreds of gcc.dg/guality failures on both 14 and 13.1 branches

[FX Coudert via Gcc]

Hi,

I am finding it very hard to reliably compare test results and regressions with 
the very large number of gcc.dg/guality test failures that are apparently the 
new norm on x86_64-linux: more than one hundred on 13.1, and several hundreds 
on 14. Is there any on-going discussion about this?

I mean, from an almost-external point of view, these tests should probably be 
xfail'ed and a PR opened against them to reenable them.

FX

gcc/config.in was not regenerated

[FX Coudert via Gcc]

Hi,

Building GCC in maintainer mode leads to changes in gcc/config.in 
:

> diff --git a/gcc/config.in b/gcc/config.in
> index 4cad077bfbe..25442c59aec 100644
> --- a/gcc/config.in
> +++ b/gcc/config.in
> @@ -67,6 +67,12 @@
>  #endif
> +/* Define to larger than one set the number of match.pd partitions to 
> make. */
> +#ifndef USED_FOR_TARGET
> +#undef DEFAULT_MATCHPD_PARTITIONS
> +#endif
> +
> +
>  /* Define to larger than zero set the default stack clash protector size. */
>  #ifndef USED_FOR_TARGET
>  #undef DEFAULT_STK_CLASH_GUARD_SIZE

which I think are because this commit 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0a85544e1aaeca41133ecfc438cda913dbc0f122
should have regenerated and committed config.in 

Christina, can you please have a look?

FX

Re: Copyright assignment wiki page

[FX Coudert]

Moreover, our contribute page says "the GCC maintainer that is  
taking care of your contributions" and there is no documentation  
to maintainers, so that part at least is wrong: maintainers don't  
know what to do. Or else, I just didn't receive the maintainer  
welcome package including the appropriate documentation :)


The FSF defines maintainer a bit differently than the gcc project.   
In the FSF view, the GCC SC is the maintainer of GCC, and no one else.


Then I suggest changing our contribute page from
contact us (either via the gcc@gcc.gnu.org list or the GCC  
maintainer that is taking care of your contributions) to obtain the  
relevant forms



to
contact us (either via the gcc@gcc.gnu.org list or a GCC Steering  
Commitee member) to obtain the relevant forms




to reflect this.

FX

--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Re: Copyright assignment wiki page

[FX Coudert]

I'm afraid I have to ask to remove the form from that Wiki. :-(


You're welcome to remove it yourself, but please replace them with  
appropriate, *clear* documentation of the copyright assignment  
process. The recent past (including my own experience some years ago)  
has shown that http://gcc.gnu.org/contribute.html is not clear on  
what needs to be done, and what happens afterwards.


Moreover, our contribute page says "the GCC maintainer that is taking  
care of your contributions" and there is no documentation to  
maintainers, so that part at least is wrong: maintainers don't know  
what to do. Or else, I just didn't receive the maintainer welcome  
package including the appropriate documentation :)


More fundamentaly, I think it's a strange pattern when an open-source  
project makes the path harder for our contributors. How long before  
people get sued for breaking bootstrap? :)



We originally had those forms up on gcc.gnu.org and had to remove
them upon explicit request from RMS.  (And, yes, I am aware that we
also have the form in the mailing list archives, but I hope editing
those is something we can steer clear off.)



I'd point out that other GNU (or not) projects have the same form on  
their website, e.g. http://wiki.list.org/display/DEV/GNU+copyright 
+assignment+request+form or http://www.g95.org/contrib.html, in  
addition to many mailing-list archives.


FX

--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Re: Copyright assignment wiki page

[FX Coudert]

That's true in the US as well, but what happens later on if your  
employer
comes by later on and claims you DID use employer resources?  Where  
would

that leave the FSF?  Very few employees have deep enough pockets to
indemnify the FSF from their employer!


Then, I think the FSF has no solution but to discard contributions  
from quite a few people. How many employers actually are going to  
issue such a disclaimer? In all academic places I know, at least,  
you'll never get anything like that, just because it's not a standard  
paper and they simply don't care about doing it.


The fact is: the FSF doesn't request such a disclaimer. Little use  
being more royalist than the king (don't know if that translates well  
from the French idiom, but you get the idea).


FX

--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Re: Regression with ltrans-7.f90

[FX Coudert]

Hi Steve,

I don't think you should send mail directly to gcc-bugs ("gcc-bugs is  
a relatively high volume list with mails from our Bugzilla bug- 
tracking system"). I think, apart from Andrew, noone's subscribed to  
it :)


FAIL: gfortran.dg/ltrans-7.f90  -O  scan-tree-dump-times ltrans  
"transformed loop" 1



Sounds like a target-specific issue with -ftree-loop-linear.  
According to gcc-testresults, it is seen on i386-freebsd and i386- 
netbsd. Similar C failures happen on i386-rtems. Maybe the loop can  
be transformed only for processors later than i386? In any case, this  
most probably isn't a Fortran issue.


Daniel, Zdenek, I assume you being "linear loop transforms" and "loop  
infrastructure" maintainers means you're the right persons to CC, so  
there you go.


FX

--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Re: RFC: adding knowledge of the int_fastN_t types to the compiler

[FX Coudert]

it's just targets that might have them but haven't
had the relevant information recorded in GCC that I think should  
not have
the types defined by default in GCC.  (How this relates to Fortran  
is up

to the Fortran maintainers.)


Fortran requires that a negative value be returned if the  
"int_fastN_t type isn't defined in the companion C compiler" (quoting  
from memory). Thus, of the three cases:


  1. on targets that do have int_fastN_t types defined, we register  
the information in the compiler (for Fortran, but maybe other uses)  
but don't override stdint.h
  2. on targets that don't have int_fastN_t types, we provide a  
stdint.h and give the corresponding values in Fortran
  3. on targets that have int_fastN_t types but the compiler wasn't  
updated to know, we either provide our own defaults in Fortran and  
hope they match; a carefully crafted testcase in the testsuite might  
help checking that and adding information about these targets when we  
see the testcase FAILing.


FX

--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Re: RFC: adding knowledge of the int_fastN_t types to the compiler

[FX Coudert]

I suggest runtime-variable values depending on a
target-independent macro such as LONG_TYPE_SIZE.  Also remember the
various GNU/Linux targets that do not use config/linux.h (alpha,  
rs6000,

sparc).


Thanks for both hints, I'll update the patch.

Note that the size is not enough for implementing , you  
need the

actual type as well to get C++ mangling right.  So I suggest using
type-name strings as is done for the other standard typedefs


That raises a question: darwin has, for example, in its system headers:

typedef signed char   int8_t;
[...]
/* 7.18.1.3 Fastest-width integer types */
typedef int8_tint_fast8_t;
typedef int16_t  int_fast16_t;

To do the right thing, do I have to #define INT_FAST8_TYPE in  
darwin.h to be "int8_t", or "signed char"? I'd go for the second, but  
as I know nothing about C++, I'd like to be sure :)


Thanks,
FX

--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

RFC: adding knowledge of the int_fastN_t types to the compiler

[FX Coudert]

Hi all,

The Fortran 2003 standard requires that Fortran compilers be able to  
know, at compile-time, what size the various int_fastN_t types have  
on the target (for N = 8, 16, 32 and 64). I've discussed that issue  
before on this list, and was told it's a known issue, tracked as PR  
448. For 4.3, we ignored the issue; for 4.4, I'd like to move forward  
and propose some way to go. Here's the idea I've been following: it's  
not excellent, but I don't think there are many alternatives available!


I propose we implement target macros INT_FAST8_TYPE_SIZE (and so on  
for 16, 32 and 64): they would be defined to -1 in defaults.h  
(meaning that int_fastN_t types are not available), and independent  
targets can redefine them. Front-ends and the middle-end can then use  
it if they feel like it. Attached is a patch implementing this idea,  
including target definitions for linux, darwin, mingw, AIX, IRIX,  
OpenBSD, Solaris 2.10.


Comments on that first draft are welcome. I know it's a hard issue  
and most possible fixes are more hacks than fixes, but the starting  
point is that we really need it to work, and a system that covers 99%  
of cases is better than nothing.


Thanks,
FX

--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/


intfast-1.diff
Description: Binary data

Re: [PATCH][4.3] Deprecate -ftrapv

[FX Coudert]

In Fortran, integers are used to index arrays.  So if you want  
integer overflow checking, use -fbounds-check :-)


I know there is a smiley here, but it seems to me that range checking
is quite different from overflow checking.


I think what Toon was alluding to is that "real" Fortran programmers  
don't use integers except for array subscripts. Real life is floating- 
point based!


FX

--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Re: Interoperability of Fortran array and C vector?

[FX Coudert]

But the remaining question is: can we
support type introperability from Fortran array to C vector?


I think this is more a middle-end issue that a Fortran issue, so I'm  
following there: can the middle-end VIEW_CONVERT_EXPR between and  
ARRAY_REF of, say, INTEGER_TYPE (which is what the Fortran array is)  
and a VECTOR_TYPE?


I'm CCing the main GCC devel list, since we might have more answers  
form there.


FX

--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Re: [PATCH][4.3] Deprecate -ftrapv

[FX Coudert]

C: integer overflow undefined, checking desirable at least for
debugging purposes.

I think latest Fortran is same as C, can someone confirm?


Yes, it is. Overflow undefined and no checking required; I think very  
few Fortran users actually use (or would use) checking on signed  
overflow.


FX

--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Re: Some help with fold_convert() on RECORD_TYPEs

[FX Coudert]

Works for me.  Ok if that passes bootstrap / regtest and with a proper
changelog entry.


Committed as rev. 132780 with the following ChangeLog, thanks!

2008-02-29  Francois-Xavier Coudert  <[EMAIL PROTECTED]>

* fold-const.c (fold_convertible_p): Correct the logic to  
follow

that in fold_convert().


FX

--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Re: [patch,target] Fix ppc-darwin issue with long double intrinsics (PR25477)

[FX Coudert]

  nanl
  strtold

are missing.  In addition, there are some lessor functions like  
err, errc, errx, strtold_l, swprintf, vfwscanf missing.  I assume  
this is due to no builtins for them or Fortran not using them.  If  
Ada or other non-C languages might, might make sense to add them too.


I've not limited myself to builtins used by Fortran, but tried to  
provide a complete list (Fortran only uses math builtins and memory  
(de)allocation functions). The missing functions are those for which  
there is currently no definition in builtins.def: that also includes  
strtold.


The issue with nanl() is more complex. It is in the list of functions  
that need to be fixed:



$ nm -arch ppc /usr/lib/libSystem.dylib | grep _nanl
 U _nanl$LDBL128
90178f20 T _nanl$LDBL128
901791a0 T _nanl
90179190 T _nanl$LDBL64
taigne ~ $ nm -arch ppc64 /usr/lib/libSystem.dylib | grep _nanl
00161290 T _nanl
00161090 T _nanl$LDBL128
00161280 T _nanl$LDBL64


but in Andrew's and Jack's patch, it is excluded with the following  
comment:


+  /*darwin_patch_builtin (BUILT_IN_NANL);*/ /* Broken for now  
since it
+is defined as DEF_GCC_BUILTIN when it is also a C99  
function.  */





Because my gfortran time right now is limited, I have decided against  
trying to get it into the patch. I'll note that fact into the PR  
after committing the patch, and maybe someone (or myself) can try  
later on to determine what needs to be done. For now, it's of limited  
importance, because it's not among the builtins used in Fortran.


Thanks for the review and comments,
FX

--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

[patch,target] Fix ppc-darwin issue with long double intrinsics (PR25477)

[FX Coudert]

Thanks to Andrew's code, Mike's and Geoff's comments in the PR, help  
from Uros, Paolo and Jack, and Dominique's machine for testing, here  
is a patch for fixing this PR. It has three independent parts, joined  
together because I regtested them together:


  1. the target part, in gcc/config/darwin* and gcc/config/rs6000,  
that takes care of setting correct assembler names for the builtins,  
if needed
  2. the Fortran front-end part, bordering on obvious, that makes  
cpow{f,,l} builtins instead of simply considering them library  
functions (otherwise, they don't benefit from the patch above)
  3. the Fortran testsuite part, splitting testing of ERF/ERFC from  
large_real_kind_2.F90 into its separate test case, which still fails  
on Darwin at -O0 because Apple's PowerPC erfl() and ercl() are plain  
useless.


The patch was bootstrapped on powerpc-apple-darwin9.2.0 with C and  
Fortran, and regtested with both -m32 and -m64 for these same  
languages. OK for trunk? (I need a Darwin maintainer approval for the  
target stuff, and a Fortran maintainer for Fortran parts.)


FX

--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/



darwin-longdouble-4.ChangeLog
Description: Binary data


darwin-longdouble-4.diff
Description: Binary data

Re: RFC: GCC 4.4 criteria - add Fortran as primary language?

[FX Coudert]

[adding fortran list to CC]


According to the GCC 4.4 Release Criteria,
http://gcc.gnu.org/gcc-4.4/criteria.html, only C and C++ are primary
languages. And thus only C and C++ regressions can be release  
critical.


I propose to add Fortran to these languages.


My first thought is does gfortran support and have
similarly good test results on all primary and secondary
platforms.


I'm trying here to summarize our testresults on primary and secondary  
platforms.


Primary platforms:
  * arm-eabi: don't know, can't find testresults posted for  
gfortran; last time arm-unknown-elf was reported, it had 8000+  
failures, most of them due to PR33947 (not Fortran specific) that was  
fixed since.
  * i386-unknown-freebsd: 1 FAIL / 23522 PASS (compared to C: 80  
FAIL / 3 XPASS / 47658 PASS)


  * i686-pc-linux-gnu: clean (compared to C: 7 FAIL / 48648 PASS)

  * i686-apple-darwin: clean (compared to C: 7 XPASS)

  * mipsisa64-elf: 32 failures reported; clean on mipsel-unknown- 
linux-gnu, relatively clean on mips-sgi-irix6.5 (72 FAIL, most of  
them due to the same, IRIX-specific complex support problem)
  * powerpc64-linux: 7 FAIL / 23641 PASS; the 7 FAILs are on the  
same testcase, a glibc issue, they should be XFAILed
  * sparc-sun-solaris: 58 FAIL / 23606 PASS; of the 8 testcases  
failing, 4 will be xfailed (denormal I/O not handled by system libc),  
and 2 are probably not actually a problem (gfortran.dg/stat_ 
{1,2}.f90, usually due to testsuite running under root or other  
priviledged id)

  * x86_64-unknown-linux-gnu: clean



Secondary platforms:

* hppa2.0w-hp-hpux11.11: 1 FAIL, probably libc bug
* powerpc-ibm-aix5.2.0.0: 53 FAIL, half of them suspected to be libc  
bugs; lack of AIX access has prevented us working on getting this one  
better

* powerpc-apple-darwin: 32 FAIL, 16 of them due to libc bugs
* i686-pc-cygwin: 13 FAIL, including 8 libc bugs
* i686-mingw32: no testing posted; gfortran is believed to be fairly  
good on mingw, since this is probably one of our most used targets,  
large number of people download prebuilt binaries linked from the GCC  
wiki

* ia64-unknown-linux-gnu: 2 FAIL (compared to C: 32 FAIL)
* s390-linux-gnu: clean


As you can see, the gfortran testsuite stresses dark corners of the  
libc (I/O and math of denormalized fp numbers, I/O of very large fp  
numbers, ...). More of these should be marked as XFAIL, but different  
versions of system's libc (and limited access to some targets)  
sometimes make it hard to know what exactly is to be XFAILed.


Some more progress could be made on bare metal targets, but that  
requires some help from people who actually have access or simulators  
set up. Some newlib targets are relatively clean, though: sh-elf has  
no failure at all, mipsisa64-elf has 32 failures, cris-elf has 231.  
Hans-Peter Nilsson started helping me progressing on these (PR 21185  
tracks these efforts), specifically on arm-elf, cris-elf, frv-elf,  
mipsisa64-elf and v850-elf.


As a Fortran maintainer, I don't feel strongly about being or not  
being listed as a primary language.


Thanks,
FX


--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Re: bootstrap broken on mingw

[FX Coudert]

gcc/ChangeLog:
2008-02-17  Ralf Wildenhues  <[EMAIL PROTECTED]>

PR bootstrap/35218
* Makefile.in (build_file_translate): New.
* config.build (build_file_translate): Set to `CMD //c' on MinGW.
* configure.ac (build_file_translate): Substitute it.
* configure: Regenerate.


I'm willing to try, but running "autoconf" doesn't regenerate the  
configure file, what am I missing?


FX

--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Re: bootstrap broken on mingw

[FX Coudert]

One question I have, Eric and FX: do you both have self-built  
texinfo on

MinGW?


Yes, because the one provided with MSYS is from texinfo 4.3, which  
GCC finds too old. Apparently, MSYS-1.0.11 will come with texinfo  
4.11, but it's still labeled "technology preview" for now.



Because the specially-built one in /usr/bin should be able to
handle the file names just fine.


mingw doesn't have texinfo, and the one from MSYS is too old... or  
maybe you're refering to MSYS-1.0.10?



If not, another
possibility would be to just require users on MinGW to update their
system texinfo installation.


Weeks before the release? That doesn't give much time to anyone for  
getting it working and actually testing the release candidates.


--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Re: bootstrap broken on mingw (was: Re: AVR port broken on 4.3 20080215 snapshot)

[FX Coudert]

Actually there seems to be a recent change "backward" to that logic:

2008-02-13  Ralf Wildenhues  <[EMAIL PROTECTED]>

PR other/35148
* Makefile.in (gcc-vers.texi): Use abs_srcdir for the value of
srcdir.


Doesn't look too good for mingw.


and we have PR35218 which seems to be the same issue?



Yes, it is exactly, it was open by Eric and I added my information. I  
should have given the PR number in my mail.


FX

--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

bootstrap broken on mingw (was: Re: AVR port broken on 4.3 20080215 snapshot)

[FX Coudert]

Hi all,

I also see this failure on a native build for i386-pc-mingw32, so  
this is probably a mingw issue. Since i686-pc-mingw32 is a seconday  
platform, this makes it a release blocker (I've marked it as such in  
bugzilla, and gave it P1 status; I hope that was the right thing to do).


The error here is the same:

../../trunk/gcc/doc//invoke.texi:1243: @include `/home/FX/ibin/ 
gcc/../../trunk/gcc/../libiberty/at-file.texi': No such file or  
sdirectory.


What's interesting is that the file actually exists:


$ wc -l /home/FX/ibin/gcc/../../trunk/gcc/../libiberty/at-file.texi
 15 /home/FX/ibin/gcc/../../trunk/gcc/../libiberty/at-file.texi


Thus, I suspect some sort of absolute vs. relative path issue, to  
which mingw (and especially the MSYS environment) is often very  
sensitive. For example, bootstrap only work if you use a relative  
path to configure.


FX

--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Re: Problem with libiberty's hash tables

[FX Coudert]

Sure it's faster this way, but what's wrong with valgrind? ;-


valgrind (and mtrace) are OS-specific. Also, tracking memory  
allocations has other benefits, like allowing to give memory  
statistics (what are the largest allocations, how much is used for  
compiler-generated temporaries, etc.).


What do you mean, is not library code?  Do you need it in  
libgfortran or in GCC?


In libgfortran.

If the latter, of course you could write pointer_map_delete  
yourself; it might be worthwhile since pointer maps are a tad  
faster than libiberty hashtabs.  It's on my todo list, but I wrote  
pointer_map for my private work on gcc and it was not needed at the  
time.


But didn't you say the need to remove entries (quite frequently,  
actually) makes pointer_map unsuitable?


FX

--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Re: ARM testsuite failures

[FX Coudert]

gfortran has 7442 unexpected failures.  Most of them are due to  
"test for

excess errors".  Many are simply because of this:

| warning: 'const' attribute directive ignored
| warning: 'nothrow' attribute directive ignored

which seems to be mentioned in PR21185 (comment #20).  Is that problem
still on the radar of the gfortran developers?


I thought it was newlib-specific, and thus did not hurry too much  
(gfortran for newlib targets is currently not a high priority). Can  
you reduce one of these failures to a short example and file a PR  
(and CC me)? Is there something target-specific we should know about  
arm that could explain that kind of warnings?



But then we also have e.g.:

| gfortran.dg/PR19754_1.f90:7.7-12:
|x = x + y ! { dg-error "Shapes for operands at" }
|  12
| Error: Shapes for operands at (1) and (2) are not conformable


That can't be a "test for excess error". This is perfectly normal: we  
are checking that an error is emitted and, apparently, it is. Are you  
sure this is what is failing? Could you post your testsuite log file  
(${builddir}/gcc/testsuite/gfortran/gfortran.log) somewhere or send  
it to us?



| access_spec_2.f90:9.13:
|  public :: x  ! { dg-error "was already specified" }
| 1
| Error: ACCESS specification at (1) was already specified


Same here


| access_spec_2.f90:18.19:
| integer, public :: y  ! { dg-error "Fortran 2003: Attribute  
PUBLIC" }

|   1
| Error: Fortran 2003: Attribute PUBLIC at (1) in a TYPE definition


and there.

FX

Possible Fortran testsuite failures for default_format_*.f90

[FX Coudert]

Hi,

A reworking of Fortran testcases might lead to the following cases  
failing (or starting to fail):


  * gfortran.dg/default_format_1.f90
  * gfortran.dg/default_format_2.f90
  * gfortran.dg/default_format_denormal_1.f90
  * gfortran.dg/default_format_denormal_2.f90

This would indicate an issue with the target printf() implementation,  
so if you spot these failures on your favorite target, please report  
them to the [EMAIL PROTECTED] mailing-list so that we can xfail them.


Thanks,
FX

[RFC,wwwdocs] Ditch MetaHTML and use our own Perl preprocessor

[FX Coudert]

Hi,

I am in the process of rewriting the Fortran part of our website  
(http://gcc.gnu.org/), part of which consists of adding the GCC  
navigation bar. To do so, I had to install localy MetaHTML, our  
current web preprocessor, and my experiences with it have left me  
less than impressed [1].  We currently use it for including headers  
and footer, making them depend on whether we are preprocessing HTML  
or XHTML, modifying in place a few tags (, , ) and  
adding navigation bar on files that need it.  This can easily be done  
by a simple preprocessing script, and seeing that MetaHTML was last  
released 1999 and apparently unsupported since then, I suggest that  
we do this move right now.


This patch includes the new preprocessor, changes to the script, and  
quite a few new files (footer, navigation bars, etc.) split from the  
MetaHTML file, style.mhtml.  I chose to write the preprocessor script  
in Perl, since Perl is already used for the wwwdocs/bin/preprocess  
script, so I'm sure it will be available on the webserver. The  
preprocessor does what MetaHTML was needed, but it can be extended in  
the future if we need more functionality. Also, we can in the future  
offload some of its work, such as  and  modifications and  
part of the navigation bar to CSS, which is obviously better suited  
for the job. I intend to do so as a follow-up to the preprocessor  
change, if/when it is accepted.


This change shouldn't change the website, but I can't check since I  
don't have MetaHTML, so I'd appreciate if someone with shell access  
to the webserver could check it.  Oh, there is one thing that I  
changed: the detailled search page, http://gcc.gnu.org/search.html,  
currently has a "Database last updated -MM-DD" line that doesn't  
work (it displays "1900--"), so I removed it.


Comments are highly welcome, both on the idea itself, and on the Perl  
script (my Perl is a bit rusty since I haven't used it for years).


Thanks,
FX


[1] As a record, here's what my "final" status is: in addition to  
Gerald's patch and script provided by Joel Sherrill (thanks guys), I  
needed to patch of few more (~ 15) occurences of multilines strings,  
force the Makefiles to use the version of readline included in  
metahtml instead of the system one (too recent, apparently there's  
been an ABI change), and tweak the Makefiles for the shared modules,  
which aren't portable (at least, not to Mac OS). As of yesterday,  
I've managed to compile it, but the resulting binary acts as an  
endless cpu-consuming loop. At that point, I gave up.





www.diff
Description: Binary data

Bootstrap failure on i386-pc-linux-gnu

[FX Coudert]

My automated nightly build failed to bootstrap this evening on i386- 
pc-linux-gnu. This is for trunk rev. 127311, and the error is:


/home/fx/gfortran_nightbuild/ibin-20070809/./prev-gcc/xgcc -B/home/ 
fx/gfortran_nightbuild/ibin-20070809/./prev-gcc/ -B/home/fx/ 
gfortran_nightbuild/irun-20070809/i386-pc-linux-gnu/bin/ -c   -g - 
O2 -fomit-frame-pointer -DIN_GCC   -W -Wall -Wwrite-strings - 
Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition - 
Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic- 
macros   -Wno-overlength-strings -Werror- 
DHAVE_CONFIG_H -I. -I. -I/home/fx/gfortran_nightbuild/trunk/gcc -I/ 
home/fx/gfortran_nightbuild/trunk/gcc/. -I/home/fx/ 
gfortran_nightbuild/trunk/gcc/../include -I/home/fx/ 
gfortran_nightbuild/trunk/gcc/../libcpp/include -I/home/fx/ 
gfortran_nightbuild/software/include  -I/home/fx/ 
gfortran_nightbuild/trunk/gcc/../libdecnumber -I/home/fx/ 
gfortran_nightbuild/trunk/gcc/../libdecnumber/bid -I../ 
libdecnumber/home/fx/gfortran_nightbuild/trunk/gcc/tree.c -o  
tree.o

cc1: warnings being treated as errors
/home/fx/gfortran_nightbuild/trunk/gcc/tree.c: In function  
'initializer_zerop':
/home/fx/gfortran_nightbuild/trunk/gcc/tree.c:7694: error: passing  
argument 1 of 'fixed_zerop' discards qualifiers from pointer target  
type

make[3]: *** [tree.o] Error 1
make[3]: Leaving directory `/home/fx/gfortran_nightbuild/ 
ibin-20070809/gcc'

make[2]: *** [all-stage2-gcc] Error 2


I filed PR 33031 for this issue.

Thanks,
FX

Re: Ongoing bootstrap failures on ppc64 since 2007-07-02

[FX Coudert]

Starting 2007-07-02 my daily ppc64 tester has failed bootstrap with  
a SEGV in libgfortran:


libtool: compile:  /home/dnovillo/perf/sbox/gcc/local.ppc64/bld/./ 
gcc/gfortran -B/home/dnovillo/perf/sbox/gcc/local.ppc64/bld/./gcc/ - 
B/home/dnovillo/perf/sbox/gcc/local.ppc64/inst/powerpc64-unknown- 
linux-gnu/bin/ -B/home/dnovillo/perf/sbox/gcc/local.ppc64/inst/ 
powerpc64-unknown-linux-gnu/lib/ -isystem /home/dnovillo/perf/sbox/ 
gcc/local.ppc64/inst/powerpc64-unknown-linux-gnu/include -isystem / 
home/dnovillo/perf/sbox/gcc/local.ppc64/inst/powerpc64-unknown- 
linux-gnu/sys-include
 -I . -Wall -fno-repack-arrays -fno-underscoring -fallow-leading- 
underscore -g -O2 -c /home/dnovillo/perf/sbox/gcc/local.ppc64/src/ 
libgfortran/intrinsics/selected_int_kind.f90  -fPIC -o .libs/ 
selected_int_kind.o
/home/dnovillo/perf/sbox/gcc/local.ppc64/src/libgfortran/intrinsics/ 
selected_int_kind.f90: In function '_gfortran_selected_int_kind':
/home/dnovillo/perf/sbox/gcc/local.ppc64/src/libgfortran/intrinsics/ 
selected_int_kind.f90:22: internal compiler error: Segmentation fault

Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [selected_int_kind.lo] Error 1

Anyone else experiencing this?  Should I upgrade GMP/MPFR?


Depends what is your current version, I guess. Can you get us a  
backtrace?


FX

Re: Help on emitting static constant arrays

[FX Coudert]

It's probably a beginner mistake, but I never wrote code to emit  
GIMPLE arrays before, and don't know where to look exactly. I'll  
continue looking for the reason, but if someone thinks of  
something trivial I'd be interested in knowing!


I am pretty sure you should pass the array as a pointer.  That's  
how C works.


Hum, I really thought it was something stupid, and it actually was  
even more stupid than I thought. Sorry for the noise, and thanks for  
the answer!


FX

Help on emitting static constant arrays

[FX Coudert]

Hi all,

I'm modifying the Fortran front-end to emit code such as:

  static int4 options.2[5] = {102, 127, 1, 1, 1};
  _gfortran_set_options (5, options.2);

where _gfortran_set_options is a library function with prototype  
"void _gfortran_set_options (int , int [])". This works well (the  
pseudo-code snippet above is in fact an extract of the optimized tree  
dump), but breaks when used with -O2 -funroll-loops: I get a segfault  
due to the function being called with (seen from gdb):


  *_gfortran_set_options (num=5, options=0x0)

It's probably a beginner mistake, but I never wrote code to emit  
GIMPLE arrays before, and don't know where to look exactly. I'll  
continue looking for the reason, but if someone thinks of something  
trivial I'd be interested in knowing!


Thanks for the help, and sorry (in advance) if it's a completely  
stupid mistake.

FX




try.diff
Description: Binary data

Re: [patch,committed] Make Fortran maintainers "Non-Autopoiesis Maintainers"

[FX Coudert]

Mostly what I want is some discussion about what we expect this to  
mean as a formal rule, and how strictly we're expecting to  
interpret it.  For values of "we" meaning both the GFortran  
maintainers, and the wider GCC maintainer community.


I agree with your intrepretation of this rule exactly as you stated  
it, and as it is stated on http://gcc.gnu.org/fortran/ : approval of  
non-obvious patches is required as a rule, but the scope of "obvious"  
can be extended at times, and it's also possible to send a patch  
asking if anyone has comments, saying that you plan on committing it  
on a given date. I did change the Fortran maintainers from the  
standard category to this new one because it seemed close to what we  
currently do.


To come to the heart of the issue, I don't think it will be  
intepreted to our disadvantage by the GCC community. From the past,  
it seemed that the steering committee and release managers have kept  
to a simple line: the Fortran maintainers have a system that works,  
even though it's not completely the same as the usual GCC  
maintainership. If it works well, let's keep it that way. [1] I feel  
that we have a wide margin to make our decisions. After all, IIRC,  
the "mostly non-autopoiesis" system that we have is something we came  
up with, not the steering committee.


In short: I understand your point of view, and I think we have been  
given enough liberty for Fortran choices in the past not to worry  
about this MAINTAINERS category not 100% describing our policy.


FX


[1] I'm sorry if I'm misunderstanding the policy that is applied to  
us; and I want to note that I'm only speaking about maintainership,  
not the development and branches rules, for which we're going slowly  
toward the standard GCC practices.

Re: Large number of fortran testsuite failures

[FX Coudert]

The problem is between r125620 and r125628 but is NOT, as I  
suspected, r125621.


Is nobody else seeing it, or is it a Cygwin specific problem?


ia64-linux testresults with rev. 12640 appear to be fine (http:// 
gcc.gnu.org/ml/gcc-testresults/2007-06/msg00572.html).


Doh, wait, it appears that rev. 125624 is the dataflow merge.  
Although it doesn't appear to touch specific cygwin files, it  
certainly is a commit with sufficiently high order-of-magnitude that  
it can disrupt a few seemingly unrelated code paths. Maybe it's worth  
trying to bracket that one? (although I know cygwin bootstrap is  
awfully slow)


FX

bootstrap problem with trunk on i386-mingw32: target multi-do in libiberty

[FX Coudert]

Bootstrapping today's trunk (rev. 125180) on i386-mingw32 (native)  
leads me to the following error at the end of stage3:


make[3]: Leaving directory `/home/coudert/ibin/i386-pc-mingw32/ 
libiberty/testsuite'
make[3]: Entering directory `/home/coudert/ibin/i386-pc-mingw32/ 
libiberty'

make[3]: *** No rule to make target `multi-do'.  Stop.
make[3]: Leaving directory `/home/coudert/ibin/i386-pc-mingw32/ 
libiberty'

make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/coudert/ibin/i386-pc-mingw32/ 
libiberty'

make[1]: *** [all-target-libiberty] Error 2
make[1]: Leaving directory `/home/coudert/ibin'
make: *** [all] Error 2


It is true that ${builddir}/i386-pc-mingw32/libiberty/Makefile  
doesn't have a multi-do rule, while the Makefiles for libgfortran and  
libssp do have one. Does someone have an idea how this is triggered?  
What can I post to help people debug this? (I have kept the build  
directory intact for further debugging, I just don't know what to do  
and where to start fishing.)


FX

Mainline doesn't bootstrap on i386-linux

[FX Coudert]

With revision 124738:

cc1: warnings being treated as errors
/home/fxcoudert/gfortran_nightbuild/trunk/gcc/print-rtl.c: In  
function ‘print_rtx’:
/home/fxcoudert/gfortran_nightbuild/trunk/gcc/print-rtl.c:397: error:  
format ‘%lx’ expects type ‘long unsigned int’, but argument 3 has  
type ‘long int’

make[3]: *** [build/print-rtl.o] Error 1
make[3]: Leaving directory `/home/fxcoudert/gfortran_nightbuild/ 
ibin-20070515/gcc'

make[2]: *** [all-stage2-gcc] Error 2


Probably related to http://gcc.gnu.org/ml/gcc/2007-05/msg00354.html

FX

[doc,patch] Fortran compiler on Ultrix and clobbered registers

[FX Coudert]

I noted in the GCC docs (see for example http://gcc.gnu.org/ 
onlinedocs/gcc/Interoperation.html) that we have the following text  
in the section "Known Causes of Trouble with GCC":


On Ultrix, the Fortran compiler expects registers 2 through 5 to be  
saved by function calls. However, the C compiler uses conventions  
compatible with BSD Unix: registers 2 through 5 may be clobbered by  
function calls.


GCC uses the same convention as the Ultrix C compiler. You can use  
these options to produce code compatible with the Fortran compiler:
  -fcall-saved-r2 -fcall-saved-r3 -fcall-saved-r4 -fcall- 
saved-r5


That code was initially committed to gcc/gcc.texi in 1997 (it's now  
in gcc/doc/gcc.texi). As there have been a few changes on the  
compiler since that time, I wonder if it's still true, and still  
useful to have that comment there. As there is no ultrix maintainer  
(though it's still listed as a supported platform), I'm CCing the VAX  
maintainers: can you comment on the usefulness of this part of the doc?


So, unless someone can raise a reason against it, I'd like to propose  
the patch below to remove it. Built and tested on i686-linux (make  
info && make html). OK for mainline?


FX





Index: gcc/doc/trouble.texi
===
--- gcc/doc/trouble.texi(revision 124144)
+++ gcc/doc/trouble.texi(working copy)
@@ -234,20 +234,6 @@ you cannot successfully use @samp{$} in
to a restriction in the IBM assembler.  GAS supports these
identifiers.
[EMAIL PROTECTED] VAX calling convention
[EMAIL PROTECTED] Ultrix calling convention
[EMAIL PROTECTED]
[EMAIL PROTECTED] fcall-saved
-On Ultrix, the Fortran compiler expects registers 2 through 5 to be  
saved

-by function calls.  However, the C compiler uses conventions compatible
-with BSD Unix: registers 2 through 5 may be clobbered by function  
calls.

-
-GCC uses the same convention as the Ultrix C compiler.  You can use
-these options to produce code compatible with the Fortran compiler:
-
[EMAIL PROTECTED]
--fcall-saved-r2 -fcall-saved-r3 -fcall-saved-r4 -fcall-saved-r5
[EMAIL PROTECTED] smallexample
@end itemize
@node Incompatibilities

Segfault on OpenMP program

[FX Coudert]

Someone reported on bug on a trivial statically-linked Fortran progam  
with OpenMP and a I/O operation. I can reproduce the segfault, which  
happens at:


(gdb) where
#0  0x in ?? ()
#1  0x0804cdbb in get_external_unit (n=6, do_create=1)
at
/home/fxcoudert/gfortran_nightbuild/trunk/libgfortran/../gcc/gthr- 
posix.h:613

#2  0x0804b987 in data_transfer_init (dtp=0xbfe9b024, read_flag=0)
at /home/fxcoudert/gfortran_nightbuild/trunk/libgfortran/io/ 
transfer.c:1702

#3  0x0804827f in MAIN__.omp_fn.0 (.omp_data_i=0x0) at hello.f90:2
#4  0x08048235 in MAIN__ () at hello.f90:2
#5  0x080482dd in main (argc=Cannot access memory at address 0x1

The line 613 in gcc/gthr-posix.h is the call to pthread_mutex_trylock 
() in:


static inline int
__gthread_mutex_trylock (__gthread_mutex_t *mutex)
{
  if (__gthread_active_p ())
return __gthrw_(pthread_mutex_trylock) (mutex);
  else
return 0;
}


Andrew suggested on bugzilla that this might be a GLIBC issue (I use  
glibc-2.4 from redhat), with "pthreads not linking in correctly".  
Does this ring a bell? Can someone confirm that it's not a GCC issue  
(or that it is)? Details can be found in PR 31604.


Thanks,
FX

Re: Call to arms: testsuite failures on various targets

[FX Coudert]

wrt to the Subject of the mail, I'm not sure "Call to arms" means  
what I thought it meant, after all... I really wanted it to sound  
like "call for help" or "call for more arms". Sorry if there was any  
confusion in the tone.


FX

Call to arms: testsuite failures on various targets

[FX Coudert]

Hi all,

I reviewed this afternoon the postings from the gcc-testresults  
mailing-list for the past month, and we have a couple of gfortran  
testsuite failures showing up on various targets. Could people with  
access to said targets (possibly maintainers) please file PRs in  
bugzilla for each testcase, reporting the error message and/or  
backtrace? (I'd be happy to be added to the Cc list of these)


* ia64-suse-linux-gnu: gfortran.dg/vect/vect-4.f90
* powerpc64-unknown-linux-gnu: gfortran.dg/value_4.f90

* powerpc-apple-darwin8.5.0: gfortran.dg/edit_real_1.f90

* sparc{,64}-sun-solaris2.10: gfortran.dg/open_errors.f90 gfortran.dg/ 
vect/vect-5.f90 (and gfortran.dg/cray_pointers_2.f90 when using -fPIC)


* powerpc-ibm-aix5.2.0.0: gfortran.dg/integer_exponentiation_4.f90  
gfortran.dg/static_linking_1.f gfortran.dg/value_4.f90  
gfortran.fortran-torture/execute/intrinsic_nearest.f90


* hppa-unknown-linux-gnu: gfortran.dg/cray_pointers_2.f90
* hppa2.0w-hp-hpux11.11: gfortran.dg/result_in_spec_1.f90
* hppa64-hp-hpux11.11: many failures (http://gcc.gnu.org/ml/gcc- 
testresults/2007-04/msg00585.html)


* x86_64-unknown-netbsd3.0: gfortran.dg/exponent_1.f90 gfortran.dg/ 
scale_1.f90 gfortran.fortran-torture/execute/ 
intrinsic_fraction_exponent.f90 gfortran.fortran-torture/execute/ 
intrinsic_rrspacing.f90 gfortran.fortran-torture/execute/ 
intrinsic_scale.f90 gfortran.fortran-torture/execute/ 
intrinsic_set_exponent.f90



Note1: I omitted all the gfortran.dg/c_by_val_1.f  failures, which  
should be fixed by now
Note2: I also omitted a couple of gfortran.dg/secnds.f failures; this  
testcase should be reworked


Thanks,
FX

Bootstrap is broken on i[345]86-linux

[FX Coudert]

Bootstrap has been broken since 2007-03-25 on i[345]86-linux. This is  
a decimal float issue reported as PR31344, and is due to a decimal  
float patch, probably the following:


2007-03-23  Michael Meissner  <[EMAIL PROTECTED]>
H.J. Lu  <[EMAIL PROTECTED]>

I've asked a few times already, but nothing seems to be done: can  
this be fixed? A simple workaround is to disable decimal float for i 
[345]86-linux, and it would be nice if people who commit patches  
acted as if they felt responsible for the consequences of their commits.


FX

Re: Google Summer of Code: Mentor wanted for Fortran project

[FX Coudert]

Now I learned that there are currently no Fortran developers signed  
up as SoC mentors for GCC. It would be really great if someone with  
a decent knowledge of gfortran would be willing to be my mentor, so  
I can work on this project. This really wouldn't take up too much  
of your time. I just need someone to answer some of my questions  
every now and then and to give me some hints on how to proceed.


I'm willing to be a mentor, seeing that we don't have too many people  
applying for the job :)


I tried to apply on the SoC website, but the application form only  
reloaded when I hit "Become a mentor", neither saying if it worked or  
didn't work. So, I hope it worked. Can someone check it (Ian, maybe?)


FX

4.3 bootstrap broken on i386-linux

[FX Coudert]

Hi all,

My nightly bootstrap of mainline on i386-linux failed tonight, on  
revision 123192, with:


/home/fxcoudert/gfortran_nightbuild/trunk/libgcc/../libdecnumber/ 
decLibrary.c: In function ?isinfd64?:
/home/fxcoudert/gfortran_nightbuild/trunk/libgcc/../libdecnumber/ 
decLibrary.c:65: error: unrecognizable insn:
(insn 11 10 12 3 /home/fxcoudert/gfortran_nightbuild/trunk/libgcc/../ 
libdecnumber/decLibrary.c:62 (set (reg/f:SI 61)

(pre_dec:SI (reg/f:SI 7 sp))) -1 (nil)
(nil))
/home/fxcoudert/gfortran_nightbuild/trunk/libgcc/../libdecnumber/ 
decLibrary.c:65: internal compiler error: in extract_insn, at recog.c: 
2119


The last revision known to compile OK on that particular setup was:  
123178. I filed it as PR 31344 in bugzilla. The compilation fails for  
-mtune=i[345]86 while it doesn't ICE for -mtune=i686.


FX

Re: AC_LIBTOOL_WIN32_DLL for libgfortran

[FX Coudert]

Did you put it in the toplevel configure.in or in
libgfortran/configure.ac?  I suspect it needs to be in the former,
because the latter probably shares the same config.cache and thus it
won't be checked a second time when running configure for libgfortran.


Tried to put it into the toplevel configure.ac, but there is no  
AC_PROG_LIBTOOL there, so I put it somewhere near other AC_ macros  
(see patch below). Autoconf then says:


$ autoconf
configure.ac:1071: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL
  If this token and others are legitimate, please use  
m4_pattern_allow.

  See the Autoconf documentation.


Index: configure.ac
===
--- configure.ac(revision 122655)
+++ configure.ac(working copy)
@@ -1068,6 +1068,8 @@
   fi
fi
+AC_LIBTOOL_WIN32_DLL
+
ACX_PROG_GNAT
ACX_PROG_CMP_IGNORE_INITIAL

Re: AC_LIBTOOL_WIN32_DLL for libgfortran

[FX Coudert]

In any case, I think efforts would be better spent helping get a  
modern
libtool into the tree, since the one there now is ancient and I  
wouldn't

be surprised if the mingw/cygwin-specific parts have bitrotted from
years of neglect.


There is effort to get that done, as you can see in the recent (few  
days ago) thread starting here:

http://gcc.gnu.org/ml/gcc/2007-03/msg00293.html

Please feel free to step into this other discussion and help/give  
advice about how achieve this goal.



For example, this AC_LIBTOOL_WIN32_DLL macro was
removed/deprecated from libtool three years ago.


What should be used with a recent libtool? And where is it documented?

FX

AC_LIBTOOL_WIN32_DLL for libgfortran

[FX Coudert]

Hi all,

I've been trying to use tweak the libgfortran build machinery to get  
it generate a libgfortran.dll on windows systems, but I have no luck.  
I tried adding AC_LIBTOOL_WIN32_DLL to configure.ac (just before  
AM_PROG_LIBTOOL) and -no-undefined to libgfortran_la_LDFLAGS, as is  
indicated in the autobook and other online resources. but configure  
(on a cross-compiler from i686-linux to i386-pc-mingw32) still says:



checking if libtool supports shared libraries... yes
checking if package supports dlls... no
checking whether to build shared libraries... no


Is there another thing needed to get this support? I admit I'm a bit  
lost in the gigantic GCC build system, but I thought the target  
libraries were actually rather... standalone, autoconf-ly speaking. I  
bet I was wrong.


Thanks for any help or hint,
FX

Re: symbol names are not created with stdcall syntax: MINGW, (GCC) 4.3.0 20061021

[FX Coudert]

IMO, anybody who uses -mrtd (with or without decorations) is asking  
for

trouble.
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.


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.


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?


FX

Re: Who should fix platforms broken by extern inline hack?

[FX Coudert]

I'd like to ping these two problems :)

i386-unknown-netbsdelf2.0.2 (and possibly newer versions) and i386-pc- 
mingw32 (latest released version) are still completely broken on  
mainline, as they have been for more that three months.



As it turns out, I do now have access to a NetBSD system, and will
look at that problem when I next get time.


Thanks. When you provid a patch, I will test it. (If someone else ever
wants access to a netbsd system, it's worth noting there's one on the
GCC compile farm!)


My understanding from 30589 is that a sufficiently recent version of
mingw32 has solved the problem.


The CVS version of mingw32 has the workaround, but most people aren't
using the CVS mingw32 (most people aren't using the last released
version anyway), so there'll be a need for a fix anyway.

Re: Performance regression on the 4.3 branch?

[FX Coudert]

Then it's filed as PR 30801.

FX

lib{gomp,decnumber}/autom4te.cache

[FX Coudert]

Is there any reason why libgomp and libdecnumber don't have a  
svn:ignore property containing autom4te.cache? I noticed the  
following always showing up in my "svn status" after a maintainer- 
mode build:

?  libdecnumber/autom4te.cache
?  libgomp/autom4te.cache

Thanks,
FX

Re: gfortran year end status report

[FX Coudert]

Thanks a lot Steve for taking time to prepare and write this mail.

FX

Re: Polyhedron performance regression

[FX Coudert]

Just wanted to note to the list that Tobias spotted a performance  
regression on Polyhedron ac.


http://www.suse.de/~gcctest/c++bench/polyhedron/polyhedron- 
summary.txt-2-0.html


Hum, the performance change on ac is significant. Anyway we can get  
the revision numbers before and after the jump? (and before the last  
jump to zero)? What patches have been commited in that time that  
could affect this? I can't see anything on the fortran patches...


FX

Re: How to grow the Fortran I/O parameter struct and keep ABI compatibility

[FX Coudert]

  What's the problem with just adding a new 'extended private  
stuff' field to
the very end of the struct and allocating one of the remaining flag  
bits to

say if it's present or not?


That requires to have a version of the library that can work without  
it, and it's one more requirement on the code we write :)

But we can do it, I guess.

FX

Re: How to grow the Fortran I/O parameter struct and keep ABI compatibility

[FX Coudert]

Suggestion:  We should make sure we can accommodate F2003 with
4.2 and 4.3 by increasing the possible number of flags as needed.


I'm in favour of that, and I already started writing the necessary  
patch. But it looks like we'll have to bump the so number a last  
time, for 4.3, and then make the private part of the structure wider,  
to accomodate any new flags (for things like extension, or the way  
we'll really handle asynchronous I/O).


FX

How to grow the Fortran I/O parameter struct and keep ABI compatibility

[FX Coudert]

Hi all,

[Cc general gcc list for people with ABI-compatibility experience,  
and Jakub because he's the one who introduced the scheme currently  
used by the library]


The plans for the libgfortran library is to stabilize things from now  
on, and keep ABI compatibility. But I have to admit that I, for one,  
am very new this field, and even if I understand the concept, the  
modi operandi are still not cristal-clear.


The Fortran front-end emits calls to I/O subroutines by creating a  
struct containing all information to be passed to the library, as  
well as some reserved space (for internal use by the library).  
Example of the generated code include:



  {
struct __st_parameter_dt dt_parm.0;

dt_parm.0.common.filename = "u.f90";
dt_parm.0.common.line = 1;
dt_parm.0.common.unit = 10;
dt_parm.0.rec = 2;
dt_parm.0.common.flags = 512;
_gfortran_st_write (&dt_parm.0);
{
  int4 C.876 = 42;

  _gfortran_transfer_integer (&dt_parm.0, &C.876, 4);
}
_gfortran_st_write_done (&dt_parm.0);


where __st_parameter_dt is declared as:

typedef struct st_parameter_dt
{
  st_parameter_common common;
  GFC_IO_INT rec;
  [...lots of other struct members...]
  /* Private part of the structure.  The compiler just needs
 to reserve enough space.  */
union
{
  struct
{
  [... the private stuff ...]
} p;
  /* This pad size must be equal to the pad_size declared in
 trans-io.c (gfc_build_io_library_fndecls).  The above  
structure

 must be smaller or equal to this array.  */
  char pad[16 * sizeof (char *) + 32 * sizeof (int)];
} u;
}
st_parameter_dt;


The idea is that common.flags has a bit for every possible member  
such as rec, to indicated whether it's present or not. The question  
is that we sometimes need to add another struct member (like rec) in  
this structure, to implement new features. I think we can add it at  
the end, since when code generated by older compilers calls the  
library, the flag for that new member is not set, and the struct  
member is never accessed.


Now, we also sometimes want to increase the size of the private  
stuff, and I don't see how we can do that in a way that keeps ABI  
compatibility, because the bits in the private stuff are always used  
by the library. So, I am missing something here or is there actually  
no way to keep that scheme and have ABI compatibility?


FX

Re: regeneration of files

[FX Coudert]

I commited the regenerated libgfortran files on mainline (rev. 118140):

2006-10-29  Francois-Xavier Coudert  <[EMAIL PROTECTED]>

* configure: Regenerate.
* Makefile.in: Regenerate.
* aclocal.m4: Regenerate.

Maybe you have an old version of libgfortran/config.h.in, because  
when I regenerate it there's nothing changed.


FX

How can a front-end know what integer mode corresponds to int_fastN_t?

[FX Coudert]

Hi all,

For Fortran 2003 standard conformance, the Fortran front-end has to  
know at compile-time what integer mode corresponds to some C99 types,  
like intmax_t, intN_t, int_leastN_t, int_fastN_t.


For intN_t and int_leastN_t, I can see how to get them by looking at  
the width of the different integer modes. For intmax_t, it is defined  
in c-common.h as:


#define INTMAX_TYPE ((INT_TYPE_SIZE == LONG_LONG_TYPE_SIZE) \
 ? "int"\
 : ((LONG_TYPE_SIZE == LONG_LONG_TYPE_SIZE) \
? "long int"\
: "long long int"))

But I cannot see how the front-end can know the integer mode for  
int_leastN_t. We're likely to include this functionality for the 4.3  
release, so I'll be happy to get a large number of suggestions around  
on how to implement that.


FX

Re: Darwin -m64 results

[FX Coudert]

   The bug hits about 38 other test in gfortran. These include...

FAIL: gfortran.dg/actual_array_constructor_1.f90  -O3 -g  (test for excess 
errors)
FAIL: gfortran.dg/assign.f90  -O3 -g  (test for excess errors)
[...SNIP...]
Just in case, you can detect any sort of pattern from that set of
tests.


They all use common blocks or modules. Your best shot at this is to try 
to get a reduced testcase, beginning with assign.f90 (which is the 
shortest of these failing testcases):


  integer i
  common i
  assign 2000 to i
2000  continue
  end

Try to remove the 'assign' and 'continue' lines, see if it's still 
broken. Try to compile without linking (gfortran -O3 -g -c assign.f90).


FX

GCC dejagnu testsuite: how to check for non-zero exit code?

[FX Coudert]

I'd like to include cases in the gfortran testsuite to check that we 
correctly issue a run-time error, and exit with non-zero code.


I have the following example:

$ cat runtime_error.f90
! { dg-do run }
! { dg-options "-fbounds-check" }
  integer :: x(5), y(5)
  x = y((/0,2,3,4,6/))
  end
$ gfortran runtime_error.f90 -fbounds-check
$ ./a.out ; echo $?
Fortran runtime error: Array reference out of bounds for array 'y', 
lower bound of dimension 1 exceeded (in file 'runtime_error.f90', at line 4)

2


I'd like to be able to check that this code indeed issue the error 
message on stderr and indicate to dejagnu that non-zero exit codes does 
not mean that the test FAILed). How can I do that?


Thanks for any help,
FX

Re: ICE in complex division

[FX Coudert]

div_comp_red_2.f90: In function 'MAIN__':
div_comp_red_2.f90:1: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.


I reported this bug as PR 28151. It's not target-specific (it happens 
also on i686-linux) and it looks like a middle-end issue. Now, we have 
to hope that it gets more attention than PR 27889 :(


FX

Re: Lots of gfortrans testsuite failuers on sparc64-linux: undefined reference to `_gfortran_reshape_r8

[FX Coudert]

well, I didn't do a full bootstrap, I did a "bubblestrap" ... maybe
that was the issue then. before running the next bubblestrap, what
files do you recommend me to remove so that they get stage wise
properly rebuilt?


Hum... I'm not sure, but I think the safe steps here are:
  - check the original files are there 
(${srcdir}/libgfortran/generated/{reshape,transpose}_r{4,8}.c)
  - force the build mechanism to update your 
${builddir}/${target}/libgfortran/Makefile, either by reconfiguring this 
directory, or removing the Makefile (I'm not sure that works) or 
deleting your whole ${builddir}/${target}/libgfortran directory.


That should work.

FX

Fwd: Lots of gfortrans testsuite failuers on sparc64-linux: undefined reference to `_gfortran_reshape_r8

[FX Coudert]

[Transfering this to the fortran list]

Hi Christian,

I did the commit that introduced these new symbols 
_gfortran_{reshape,transpose}_r{4,8}. They come from 
${srcdir}/libgfortran/generated/{reshape,transpose}_r{4,8}.c

and this file should be present indeed at revision 114896:

$ svn info libgfortran/generated/reshape_r8.c 
Path: libgfortran/generated/reshape_r8.c

Name: reshape_r8.c
URL: svn+ssh://gcc.gnu.org/svn/gcc/trunk/libgfortran/generated/reshape_r8.c
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 114961
Node Kind: file
Schedule: normal
Last Changed Author: fxcoudert
Last Changed Rev: 114880
Last Changed Date: 2006-06-22 08:04:02 +0200 (Thu, 22 Jun 2006)
Text Last Updated: 2006-06-21 11:55:58 +0200 (Wed, 21 Jun 2006)
Checksum: 8c9d27a3b974fbd53754fa7f6ac003d8


Indeed, both library and front-end changes were commited together. Maybe 
you haven't rebuilt the library after your last update, or did not get 
the generated files correctly (but then, I don't know why).


If indeed, you have these sources files and, while rebuilding the 
library, the symbols do not end up in libgfortran.so, I'd appreciate you 
sending me the content of ${builddir}/${target}/libgfortran/kinds.h


Thanks,
FX

Re: Recent VCG changes break gfortran's -std=f95 option

[FX Coudert]

My first patch didn't even compile :(

Here's a new one.


Something is marking random_seed as noreturn.


As far as I understand, symbols are marked as noreturn by use of  
TREE_THIS_VOLATILE, which is done on a few selected trees and is  
also done whenever a symbol has the noreturn attribute. This  
noreturn attribute can be set to 1 by make_noreturn, but nothing  
ever sets it to 0, which is probably why we're experiencing this  
problem.


I have to go and not enough time to check it in detail, but perhaps  
we should change that here:


Index: intrinsic.c
===
--- intrinsic.c (revision 114340)
+++ intrinsic.c (working copy)
@@ -254,6 +254,7 @@
   next_sym->resolve = resolve;
   next_sym->specific = 0;
   next_sym->generic = 0;
+  next_sym->noreturn = 0;
   break;
 default:

Re: Recent VCG changes break gfortran's -std=f95 option

[FX Coudert]

Something is marking random_seed as noreturn.


As far as I understand, symbols are marked as noreturn by use of  
TREE_THIS_VOLATILE, which is done on a few selected trees and is also  
done whenever a symbol has the noreturn attribute. This noreturn  
attribute can be set to 1 by make_noreturn, but nothing ever sets it  
to 0, which is probably why we're experiencing this problem.


I have to go and not enough time to check it in detail, but perhaps  
we should change that here:


Index: intrinsic.c
===
--- intrinsic.c (revision 114340)
+++ intrinsic.c (working copy)
@@ -254,6 +254,7 @@
   next_sym->resolve = resolve;
   next_sym->specific = 0;
   next_sym->generic = 0;
+  next_sym->attr.noreturn = 0;
   break;
 default:

TLS on windows (was: Re: Gfortran on Windows (mingw32) with OpenMP)

[FX Coudert]

[First, a warning: I'm neither an expert in TLS, nor in Windows nor  
in GCC guts



can we have chance to solve the
problem of threadprivate by adding the TLS support to
mingw32?


The support for TLS (Thread Local Storage) would probably come from  
the compiler itself. Windows has TLS (see for example http:// 
dotnet.di.unipi.it/Content/sscli/docs/doxygen/pal/localstorage_8c- 
source.html and http://www.ddj.com/dept/cpp/184403874, or the MSDN  
documentation at http://msdn.microsoft.com/library/default.asp?url=/ 
library/en-us/dllproc/base/tlsalloc.asp), so you'd "only" need to  
teach GCC how to call that.


Now, I don't have competence, time and motivation to do that. So, if  
my analysis above is correct, there are three things you can do: ask  
around here if someone is interested in this and is planning to do  
it; do it yourself, if you have the competence; find someone you  
know, that you have leverage on, to do it :)


Now, for an idea of how much work it represents... perhaps someone  
here can tell us?


FX

Re: mingw32 subtle build failure

[FX Coudert]

xgcc.exe: CreateProcess: No such file or directory^M
This looks to me like a side effect of some file somewhere being  
generated with DOS line endings.


Sorry I didn't remove that ^M when posting. It's purely an effect of  
the way I copied my config.log file over the network before posting  
it, but is not related to the real problem here.


FX

Re: mingw32 subtle build failure

[FX Coudert]

And I forgot to ask: who the heck is supposed to set USE_MINGW_MSYS?  
(grep is soo sloow on my win32 machine)


FX

mingw32 subtle build failure

[FX Coudert]

Hi all, hi mingw32 maintainers,

I'm experiencing a strange bug building mainline as a native compiler  
on i386-pc-mingw32 (with MSYS). It builds fine with the following  
configure line:


../gcc/configure   --prefix=/mingw --with-gmp=/home/coudert/local -- 
disable-nls --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as -- 
disable-werror --enable-bootstrap --enable-threads --host=i386-pc- 
mingw32 --enable-languages=c,fortran


If I add the --enable-libgomp option (I know libgomp is not supposed  
to compile, but go on reading) it fails in configure-stage3- 
libdecnumber (that is, even *before* doing anything with libgomp):  
the error (from config.log) is the following:



configure:1751: error: C compiler cannot create executables
xgcc.exe: CreateProcess: No such file or directory


Now, if I run the same command line that failed during configure,  
directly inside a shell, it works nicely. To understand this strange  
failure, I changed libiberty/pex-win32.c to print



printf ("CreateProcess (%s, %s, ...)\n", full_executable, cmdline);


just before the CreateProcess call, I get the following output:


configure:1706: checking for C compiler default output file name
configure:1709:  /home/coudert/ibin-openmp/./prev-gcc/xgcc -B/home/ 
coudert/ibin-
openmp/./prev-gcc/ -B/mingw/i386-pc-mingw32/bin/ -g -O2
conftest.c  >&5
CreateProcess (C:\msys\1.0.10\home\coudert\ibin-openmp\prev-gcc 
\cc1.exe, "C:/msy
s/1.0.10/home/coudert/ibin-openmp/prev-gcc/cc1.exe" "-quiet" "- 
iprefix" "c:\msys
\1.0.10\home\coudert\ibin-openmp\prev-gcc\../lib/gcc/i386-pc- 
mingw32/4.2.0/" "-i
system" "C:/msys/1.0.10/home/coudert/ibin-openmp/prev-gcc/include"  
"conftest.c"
"-quiet" "-dumpbase" "conftest.c" "-mtune=i386" "-auxbase"  
"conftest" "-g" "-O2"

"-o" "C:/DOCUME~1/coudert/LOCALS~1/Temp/ccIV.s", ...)^M
CreateProcess (C:\msys\1.0.10\home\coudert\ibin-openmp\prev-gcc\as,  
"C:/msys/1.0
.10/home/coudert/ibin-openmp/prev-gcc/as" "-o" "C:/DOCUME~1/coudert/ 
LOCALS~1/Tem

p/ccgHbaaa.o" "C:/DOCUME~1/coudert/LOCALS~1/Temp/ccIV.s", ...)^M
CreateProcess (C:\msys\1.0.10\bin\sh.exe, "\bin\sh" "C:/msys/1.0.10/ 
home/coudert
/ibin-openmp/prev-gcc/as" "-o" "C:/DOCUME~1/coudert/LOCALS~1/Temp/ 
ccgHbaaa.o" "C

:/DOCUME~1/coudert/LOCALS~1/Temp/ccIV.s", ...)^M
xgcc.exe: CreateProcess: No such file or directory^M


I'm trying to understand exactly why all this only happens for -- 
enable-libgomp builds (it's 100% reproducible for me, with different  
versions of mainline, bootstrapping everytime). So, is what I'm  
seeing an expected behaviour? How can I investigate further?


Thanks,
FX

Re: Segmentation fault in openmp simple routine from libgomp testsuite.

[FX Coudert]

The only sure-fire fix I can think of is to actually build
two static versions of libgfortran -- one threaded and one
not threaded.  I'm not sure this is worth the effort, really.
I'd be more inclined to put a couple of checks in such that
the static libgfortran only runs non-threaded, and force
people to use shared libgfortran for OpenMP.


Hum, there are some platforms where libgfortran (and other target 
libraries) cannot be built as shared libraries. i386-mingw32 is an 
example of that. We've been careful until now to keep static 
libgfortran working even as a static library, and it would be a pity 
not to be able to run OpenMP on this platform.


FX

Re: Segmentation fault in openmp simple routine from libgomp testsuite.

[FX Coudert]

Should I file a bug ?


I think it might be better to wait for the opinion of the gomp  
maintainers, as I'm fairly new to that stuff and could have missed  
something important.


Jakuk, Diego? Is this a bug or a feature? :)


Hum... for trunk on i686-linux, I do see the following. Dynamic
linking works fine:

$ gfortran -fopenmp omp_hello.f && OMP_NUM_THREADS=2 ./a.out
 Hello World from thread =0
 Number of threads =2
 Hello World from thread =1

Static linking fails:

$ gfortran -fopenmp omp_hello.f -static
/tmp/cc697VvU.o(.text+0x24): In function `MAIN__':
omp_hello.f: undefined reference to `GOMP_parallel_start'
/tmp/cc697VvU.o(.text+0x39):omp_hello.f: undefined reference to
`GOMP_parallel_end'
/tmp/cc697VvU.o(.text+0x49): In function `MAIN__.omp_fn.0':
omp_hello.f: undefined reference to `omp_get_thread_num_'
/tmp/cc697VvU.o(.text+0xe3):omp_hello.f: undefined reference to
`omp_get_num_threads_'
collect2: ld returned 1 exit status

The reading of the libgomp.spec lead me to give it explicitly the
needed libraries (although it shouldn't be necessary, I guess). But
then, it segfaults:

$ gfortran -fopenmp omp_hello.f -static -lgomp -lrt &&  
OMP_NUM_THREADS=2 ./a.out

zsh: segmentation fault  OMP_NUM_THREADS=2 ./a.out

And the backtrace is:

Program received signal SIGSEGV, Segmentation fault.
0x08048466 in initialize_team () at  
../../../gcc/libgomp/config/posix/sem.h:75
75  ../../../gcc/libgomp/config/posix/sem.h: No such file or  
directory.

in ../../../gcc/libgomp/config/posix/sem.h
(gdb) where
#0  0x08048466 in initialize_team ()
at ../../../gcc/libgomp/config/posix/sem.h:75
#1  0x080aff5e in __do_global_ctors_aux ()
#2  0x08048109 in _init ()
#3  0x080613ed in __libc_csu_init ()
#4  0x08061138 in __libc_start_main ()
#5  0x08048141 in _start ()


PS: Some details on the static linking failure:

Driving: gfortran -fopenmp omp_hello.f -static -v -lgfortranbegin  
-lgfortran -lm

Using built-in specs.
Target: i386-linux
Configured with: ../gcc/configure
--prefix=/cosmic/coudert/tmp/gfortran-20060228/irun
--enable-languages=c,fortran --host=i386-linux
--with-gmp=/cosmic/coudert/tmp/gfortran-20060228/gfortran_libs
Thread model: posix
gcc version 4.2.0 20060228 (experimental)
  
/tmpdir/opt/gfortran/gfortran-20060228/bin/../libexec/gcc/i386-linux/ 
4.2.0/f951

omp_hello.f -ffixed-form -quiet -dumpbase omp_hello.f -mtune=i386
-auxbase omp_hello -version -fopenmp -I
/tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc/i386-linux/ 
4.2.0/finclude

-o /tmp/ccGKM8HT.s
GNU F95 version 4.2.0 20060228 (experimental) (i386-linux)
compiled by GNU C version 4.2.0 20060228 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param  
ggc-min-heapsize=4096

 as -V -Qy -o /tmp/cc08jqIE.o /tmp/ccGKM8HT.s
GNU assembler version 2.15.94.0.2.2 (i386-redhat-linux) using BFD
version 2.15.94.0.2.2 20041220
Reading specs from
/tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc/i386-linux/ 
4.2.0/../../../libgomp.spec
  
/tmpdir/opt/gfortran/gfortran-20060228/bin/../libexec/gcc/i386-linux/ 
4.2.0/collect2

-m elf_i386 -static /usr/lib/crt1.o /usr/lib/crti.o
/tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc/i386-linux/ 
4.2.0/crtbeginT.o
-lgomp -lrt  
-L/tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc/i386-linux/ 
4.2.0

-L/tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc
-L/tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc/i386-linux/ 
4.2.0/../../..

/tmp/cc08jqIE.o -lgfortranbegin -lgfortran -lm --start-group -lgcc
-lgcc_eh -lpthread -lc --end-group
/tmpdir/opt/gfortran/gfortran-20060228/bin/../lib/gcc/i386-linux/ 
4.2.0/crtend.o

/usr/lib/crtn.o
/tmp/cc08jqIE.o(.text+0x24): In function `MAIN__':
omp_hello.f: undefined reference to `GOMP_parallel_start'
/tmp/cc08jqIE.o(.text+0x39):omp_hello.f: undefined reference to
`GOMP_parallel_end'
/tmp/cc08jqIE.o(.text+0x49): In function `MAIN__.omp_fn.0':
omp_hello.f: undefined reference to `omp_get_thread_num_'
/tmp/cc08jqIE.o(.text+0xe3):omp_hello.f: undefined reference to
`omp_get_num_threads_'
collect2: ld returned 1 exit status

Re: [libgomp] patch for -pthread on Tru64

[FX Coudert]

Moreover, removing the first test makes libgomp build on targets (as
Tru64) where the -pthread option is required to include pthread.h.


Commited after approval by Alexandre Oliva on IRC. The exact patch 
commited is attached.


FX



libgomp.diff
Description: Binary data

long double on ppc-darwin

[FX Coudert]

I'm trying to understand the gfortran failure large_real_kind_2.F90 on 
ppc-darwin7.9, which can be reduced to:


$ cat large_real_kind_2.F90
  real(kind=16) :: x
  real(8) :: y

  x = 1
  y = x
  x = cos (x)
  y = cos (y)
  print *, x, y, y-x

  end
$ ./usr/local/gfortran/bin/gfortran -g large_real_kind_2.F90 && ./a.out
  0.5403023058681397650104827000.540302305868140   
1.984153572718682756025749000E-0004


But I can't make a C testcase for that. Is "long double" supposed to be 
usable on ppc-darwin7.9 ?


FX

Re: gfc_build_addr_expr vs. build_fold_addr_expr{,_with_type}

[FX Coudert]

The only downside I see with this type of patch is that backporting
fixes from trunk to 4.1 will be more difficult.  With only a small
group of active gfortran hackers, this may place 4.1 into position
of low maintenance. 


Unless I am mistaken, this patch doesn't touch anything outside the 
fortran/ front-end, so I think we can consider backporting it to 4.1.


$ diff gcc/gcc/fortran gcc-4.1/gcc/fortran|wc -l
743
$ diff gcc/libgfortran gcc-4.1/libgfortran|wc -l
1747

The last number falls down to 484 if we don't count the regenerated files.

FX

GMP on IA64-HPUX

[FX Coudert]

Hi all,

Below is the answer I got from the developer of GMP when I asked about 
support for ia64-hpux.



  So, in short, my questions are: is gmp-4.1.4 supposed to work on
  ia64-hpux?

No, it is not.  It might be possible to get either the LP64 or
the ILP32 ABI to work, but even that requires the workaround you
mention.  Don't expect any HP compiler to compile GMP correctly
though, unless you switch off optimization.

  Will it be working in the next version (and when?)?

I cannot tell for sure.  We are currently determining what will
go into GMP 4.2 and what will have to wait for 5.0.  I must
confess that ia64-hpux is a low-priority platform.

  If it already works in the devel sources (not generally
  available), would it be possible to have a snapshot of these
  devel sources?

There is some support for ia64-hpux, but it was broken last time
I tried it.  (Presumably this is yet another HP compiler bug; the
problem apparently started when we got a compiler update.  I
don't have any plans to isolate it and work around it.)

We don't make development snapshots public.  Sorry.


So, it looks like we will not have gfortran on ia64-hpux before a long 
time, unless someone who cares about it enough patches the GMP sources.

Steve, how did you hack gmp to get it run?

In the short term, that also means that we don't have to care about 
supporting __float80 in gfortran ;-)


FX


PS: I'm amazed that a "GNU project" can have exactly two developers, 
release source snapshots every two years, adopt the too common attitude 
of "every non-i686-linux platform is not mainstream", and so on.

toplevel Makefile.tpl hacking

[FX Coudert]

I've been working on PR libfortran/21547: f951 is linked with libgmp, 
but when this library is shared and located in a non-standard path, 
building with ./configure --with-gmp=/foo/bar fails because the correct 
$(RPATH_ENVVAR) is not set when building the libgfortran. The 
conclusions I draw after gazing helplessly at the toplevel Makefile.* 
for hours is:


  - I should add a GMPLBISDIR variable in the configure.in to store the 
paths to the libraries as a colon-separated list of absolute paths

  - the GMPLIBSDIR should be added to the HOST_LIB_PATH
  - then, i don't really know how this should come into HOST_LIB_PATH; 
perhaps by way of HOST_LIB_PATH_gcc


I have attached a patch that implements things that way. The questions I 
now have are:


  - is that the Right Scheme for doing this?
  - with this patch, the libgfortran is built, but the gfortran 
testsuite doesn't run; why isn't $(RPATH_ENVVAR) including HOST_LIB_PATH 
for the testsuite?


Thanks,
FX
Index: Makefile.tpl
===
--- Makefile.tpl	(revision 106019)
+++ Makefile.tpl	(working copy)
@@ -216,6 +216,7 @@
 
 # Where to find GMP
 HOST_GMPLIBS = @gmplibs@
+HOST_GMPLIBSDIR = @gmplibsdir@
 HOST_GMPINC = @gmpinc@
 
 # --
@@ -615,7 +616,7 @@
 
 # Define HOST_LIB_PATH_gcc here, for the sake of TARGET_LIB_PATH, ouch
 @if gcc
-HOST_LIB_PATH_gcc = $$r/$(HOST_SUBDIR)/gcc:$$r/$(HOST_SUBDIR)/prev-gcc:
+HOST_LIB_PATH_gcc = $$r/$(HOST_SUBDIR)/gcc:$$r/$(HOST_SUBDIR)/prev-gcc:$(HOST_GMPLIBSDIR):
 @endif gcc
 
 [+ FOR host_modules +][+ IF lib_path +]
Index: configure.in
===
--- configure.in	(revision 106019)
+++ configure.in	(working copy)
@@ -1058,6 +1058,7 @@
 # Check for GMP and MPFR
 gmplibs=
 gmpinc=
+gmplibsdir=
 have_gmp=yes
 # Specify a location for mpfr
 # check for this first so it ends up on the link line before gmp.
@@ -1075,6 +1076,7 @@
 if test "x$with_mpfr" != x; then
   gmplibs="-L$with_mpfr/lib $gmplibs"
   gmpinc="-I$with_mpfr/include"
+  gmplibsdir="$with_mpfr/lib"
 fi
 
 # Specify a location for gmp
@@ -1097,6 +1099,11 @@
 if test "x$with_gmp" != x; then
   gmplibs="-L$with_gmp/lib $gmplibs"
   gmpinc="-I$with_gmp/include $gmpinc"
+  if test "x$gmplibsdir" != x; then
+gmplibsdir="$gmplibsdir:$with_gmp/lib"
+  else
+gmplibsdir="$with_gmp/lib"
+  fi
 fi
 
 saved_CFLAGS="$CFLAGS"
@@ -1125,6 +1132,7 @@
 # Flags needed for both GMP and/or MPFR
 AC_SUBST(gmplibs)
 AC_SUBST(gmpinc)
+AC_SUBST(gmplibsdir)
 
 # By default, C is the only stage 1 language.
 stage1_languages=c
Index: libgfortran/Makefile.in
===
--- libgfortran/Makefile.in	(revision 106403)
+++ libgfortran/Makefile.in	(working copy)
@@ -278,6 +278,7 @@
 FC = @FC@
 FCFLAGS = @FCFLAGS@
 FPU_HOST_HEADER = @FPU_HOST_HEADER@
+GMPLIBSDIR = @GMPLIBSDIR@
 INSTALL_DATA = @INSTALL_DATA@
 INSTALL_PROGRAM = @INSTALL_PROGRAM@
 INSTALL_SCRIPT = @INSTALL_SCRIPT@
Index: libgfortran/configure.ac
===
--- libgfortran/configure.ac	(revision 106403)
+++ libgfortran/configure.ac	(working copy)
@@ -141,6 +141,8 @@
 AC_PROG_FC(gfortran)
 FCFLAGS="$FCFLAGS -Wall -fno-repack-arrays -fno-underscoring"
 
+AC_ARG_VAR(GMPLIBSDIR,[Directories containing the GMP and MPFR libraries])
+
 # extra LD Flags which are required for targets
 case "${host}" in
   *-darwin*)

Re: [libgfortran] Patch to handle statically linked libgfortran

[FX Coudert]

How does the test in check_effective_target_static_libgfortran check for
use of static libgfortran?  Shouldn't it pass -static or something?  If
it's really doing it already by a means that is not apprarent, please
add a comment.

That proc has a comment that was copied from another proc, please fix
that.


Sorry for these stupid errors, I should really have read that one 
through one more time before posting. Attached is an updated version 
with both errors corrected. OK?


FX
2005-11-02  Francois-Xavier Coudert  <[EMAIL PROTECTED]>

PR libfortran/22298
* runtime/main.c (stupid_function_name_for_static_linking): New
function.
* runtime/error.c (internal_error): Call
stupid_function_name_for_static_linking.
* libgfortran.h: Add prototype for
stupid_function_name_for_static_linking.


2005-11-02  Francois-Xavier Coudert  <[EMAIL PROTECTED]>

PR libfortran/22298
* gcc/testsuite/lib/target-supports.exp
(check_effective_target_static_libgfortran): New
static_libgfortran effective target.
* gcc/testsuite/gfortran.dg/static_linking_1.f: New test.
* gcc/testsuite/gfortran.dg/static_linking_1.c: New file.
Index: libgfortran/runtime/main.c
===
--- libgfortran/runtime/main.c	(revision 105991)
+++ libgfortran/runtime/main.c	(working copy)
@@ -35,6 +35,14 @@
 
 #include "libgfortran.h"
 
+/* Stupid function to be sure the constructor is always linked in, even
+   in the case of static linking.  See PR libfortran/22298 for details.  */
+void
+stupid_function_name_for_static_linking (void)
+{
+  return;
+}
+
 /* This is the offset (in bytes) required to cast from logical(8)* to
logical(4)*. and still get the same result.  Will be 0 for little-endian
machines and 4 for big-endian machines.  */
Index: libgfortran/runtime/error.c
===
--- libgfortran/runtime/error.c	(revision 105991)
+++ libgfortran/runtime/error.c	(working copy)
@@ -353,6 +353,13 @@
   recursion_check ();
   show_locus ();
   st_printf ("Internal Error: %s\n", message);
+
+  /* This function call is here to get the main.o object file included
+ when linking statically. This works because error.o is supposed to
+ be always linked in (and the function call is in internal_error
+ because hopefully it doesn't happen too often).  */
+  stupid_function_name_for_static_linking();
+
   sys_exit (3);
 }
 
Index: libgfortran/libgfortran.h
===
--- libgfortran/libgfortran.h	(revision 105991)
+++ libgfortran/libgfortran.h	(working copy)
@@ -434,6 +434,9 @@
 
 /* main.c */
 
+extern void stupid_function_name_for_static_linking (void);
+internal_proto(stupid_function_name_for_static_linking);
+
 extern void library_start (void);
 internal_proto(library_start);
 
Index: gcc/testsuite/lib/target-supports.exp
===
--- gcc/testsuite/lib/target-supports.exp	(revision 105991)
+++ gcc/testsuite/lib/target-supports.exp	(working copy)
@@ -522,6 +522,59 @@
 return $et_fortran_large_int_saved
 }
 
+# Return 1 if we can statically link libgfortran, 0 otherwise.
+#
+# When the target name changes, replace the cached result.
+
+proc check_effective_target_static_libgfortran { } {
+global et_static_libgfortran
+global et_static_libgfortran_target_name
+global tool
+
+if { ![info exists et_static_libgfortran_target_name] } {
+	set et_static_libgfortran_target_name ""
+}
+
+# If the target has changed since we set the cached value, clear it.
+set current_target [current_target_name]
+if { $current_target != $et_static_libgfortran_target_name } {
+	verbose "check_effective_target_static_libgfortran: `$et_static_libgfortran_target_name' `$current_target'" 2
+	set et_static_libgfortran_target_name $current_target
+	if [info exists et_static_libgfortran_saved] {
+	verbose "check_effective_target_static_libgfortran: removing cached result" 2
+	unset et_static_libgfortran_saved
+	}
+}
+
+if [info exists et_static_libgfortran_saved] {
+	verbose "check_effective_target_static_libgfortran returning saved $et_static_libgfortran_saved" 2
+} else {
+	set et_static_libgfortran_saved 0
+
+	# Set up, compile, and execute a test program using static linking.
+	# Include the current process ID in the file names to prevent
+	# conflicts with invocations for multiple testsuites.
+	set src static[pid].f
+set exe static[pid].x
+
+	set f [open $src "w"]
+	puts $f "  print *, 'test'"
+	puts $f "  end"
+	close $f
+
+	verbose "check_effective_target_static_libgfortran compiling testfile $src" 2
+	set lines [${tool}_target_compile $src $exe executable "-static"]
+	file delete $src
+
+	if [string match "" $lines] then {
+	# No error message, compilation succeeded.
+	

[gfortran] fortran preprocessing, round 2

[FX Coudert]

This is an updated version of my patch taking care of warnings when cc1 
is called from gfortran to preprocess fortran source. I used a 
different (and in my view, cleaner) approach: Fortran options are not 
marked as C, but when preprocessing fortran source, cc1 is given a 
-lang-fortran flag, which makes the preprocessor not warning about use 
of Fortran options.


Tested on i686-linux, with both languages=c and languages=c,fortran. 
The current behaviour for compiling C and Fortran in a single 
command-line is kept. Regtested for languages=c, regtesting in progress 
for languages=c,fortran -- howdy, how long is that C testsuite to run! 
:(


OK for mainline when it reopens before branching?

FX
:ADDPATCH fortran,c:



preproc.ChangeLog
Description: Binary data


preproc.diff
Description: Binary data

Re: [gfortran] gfortran options and cc1 warnings

[FX Coudert]

 What should "gfortran -fdollar-ok a.f b.c" do, if -fdollar-ok if a 
fortran-only option?


It shouldn't pass -fdollar-ok to cc1, IMHO.


I'm not sure about how other languages handle that. Trying to mix java 
and C gives:


$ gcj -c Example.java a.c -Wredundant-modifiers
cc1: warning: command line option "-Wredundant-modifiers" is valid for 
Java but not for C


So, I guess we need to align on that...

FX

Re: [gfortran] gfortran options and cc1 warnings

[FX Coudert]

New version of the patch attached (this time), to answer Joseph's 
remark. Original questions still apply, including:


  What should "gfortran -fdollar-ok a.f b.c" do, if -fdollar-ok if a 
fortran-only option?


FX
2005-10-31  Francois-Xavier Coudert  <[EMAIL PROTECTED]>

PR fortran/18452
* lang.opt: Add comments about adding Fortran options.


2005-10-31  Francois-Xavier Coudert  <[EMAIL PROTECTED]>

PR fortran/18452
* gcc/c.opt: Add all Fortran options that can be passed to
the preprocessor.
* gcc/c-opts.c: Add cases for all Fortran options that can be
passed to the preprocessor.

Index: gcc/fortran/lang.opt
===
--- gcc/fortran/lang.opt	(revision 106019)
+++ gcc/fortran/lang.opt	(working copy)
@@ -22,6 +22,14 @@
 
 ; Please try to keep this file in ASCII collating order.
 
+; To add a new Fortran option, you need to do the following:
+;-- add the option in the list below
+;-- get it handled by the Fortran front-end in options.c
+;-- add the option in the c.opt file if the option will be passed to
+;   the preprocessor
+;-- add it to the list of Fortran options in c_common_handle_option()
+;   in file c-opts.c
+
 Language
 Fortran
 
Index: gcc/c.opt
===
--- gcc/c.opt	(revision 106019)
+++ gcc/c.opt	(working copy)
@@ -231,6 +231,9 @@
 C ObjC Var(warn_implicit_int)
 Warn when a declaration does not specify a type
 
+Wimplicit-interface
+C Undocumented
+
 Wimport
 C ObjC C++ ObjC++
 Deprecated.  This switch has no effect
@@ -247,6 +250,9 @@
 C ObjC C++ ObjC++
 Warn about PCH files that are found but not used
 
+Wline-truncation
+C Undocumented
+
 Wlong-long
 C ObjC C++ ObjC++ Var(warn_long_long) Init(1)
 Do not warn about using \"long long\" when -pedantic
@@ -299,6 +305,9 @@
 C ObjC Var(warn_nonnull)
 Warn about NULL being passed to argument slots marked as requiring non-NULL
 
+Wnonstd-intrinsics
+C Undocumented
+
 Wnormalized=
 C ObjC C++ ObjC++ Joined
 -Wnormalized=	Warn about non-normalised Unicode strings
@@ -379,6 +388,9 @@
 ObjC ObjC++ Var(warn_strict_selector_match)
 Warn if type signatures of candidate methods do not match exactly
 
+Wsurprising
+C Undocumented
+
 Wsynth
 C++ ObjC++ Var(warn_synth)
 Warn when synthesis behavior differs from Cfront
@@ -403,10 +415,16 @@
 C ObjC C++ ObjC++
 Warn if an undefined macro is used in an #if directive
 
+Wunderflow
+C Undocumented
+
 Wunknown-pragmas
 C ObjC C++ ObjC++
 Warn about unrecognized pragmas
 
+Wunused-labels
+C Undocumented
+
 Wunused-macros
 C ObjC C++ ObjC++
 Warn about macros defined in the main file that are not used
@@ -446,6 +464,12 @@
 C ObjC C++ ObjC++
 Recognize the \"asm\" keyword
 
+fautomatic
+C Undocumented
+
+fbackslash
+C Undocumented
+
 fbuiltin
 C ObjC C++ ObjC++
 Recognize built-in functions
@@ -473,14 +497,38 @@
 ObjC ObjC++ Joined
 -fconst-string-class=	Use class  for constant strings
 
+fcray-pointer
+C Undocumented
+
+fdefault-double-8
+C Undocumented
+
 fdefault-inline
 C++ ObjC++
 Inline member functions by default
 
+fdefault-integer-8
+C Undocumented
+
+fdefault-real-8
+C Undocumented
+
+fd-lines-as-code
+C Undocumented
+
+fd-lines-as-comments
+C Undocumented
+
 fdollars-in-identifiers
 C ObjC C++ ObjC++
 Permit '$' as an identifier character
 
+fdollar-ok
+C Undocumented
+
+fdump-parse-tree
+C Undocumented
+
 felide-constructors
 C++ ObjC++
 
@@ -507,16 +555,28 @@
 fexternal-templates
 C++ ObjC++
 
+ff2c
+C Undocumented
+
 ffixed-form
-C ObjC
+C Undocumented
 
+ffixed-line-length-none
+C Undocumented
+
 ffixed-line-length-
-C ObjC Joined
+C Undocumented
 
 ffor-scope
 C++ ObjC++
 Scope of for-init-statement variables is local to the loop
 
+ffpe-trap=
+C Undocumented
+
+ffree-form
+C Undocumented
+
 ffreestanding
 C ObjC
 Do not assume that standard C libraries and \"main\" exist
@@ -554,6 +614,9 @@
 C++ ObjC++
 Emit implicit instantiations of inline templates
 
+fimplicit-none
+C Undocumented
+
 fimplicit-templates
 C++ ObjC++
 Emit implicit instantiations of templates
@@ -565,6 +628,15 @@
 flabels-ok
 C++ ObjC++
 
+fmax-identifier-length=
+C Undocumented
+
+fmax-stack-var-size=
+C Undocumented
+
+fmodule-private
+C Undocumented
+
 fms-extensions
 C ObjC C++ ObjC++
 Don't warn about uses of Microsoft extensions
@@ -583,6 +655,9 @@
 ObjC ObjC++
 Assume that receivers of Objective-C messages may be nil
 
+fno-backend
+C Undocumented
+
 fnonansi-builtins
 C++ ObjC++
 
@@ -622,6 +697,9 @@
 C++ ObjC++
 Enable optional diagnostics
 
+fpack-derived
+C Undocumented
+
 fpch-deps
 C ObjC C++ ObjC++
 
@@ -637,6 +715,9 @@
 C ObjC C++ ObjC++
 Treat the input file as already preprocessed
 
+frepack-arrays
+C Undocumented
+
 freplace-objc-classes
 ObjC ObjC++
 Used in Fix-and-Continue mode to indicate that object files may be swapped in at runtime
@@ -649,6 +730,9 @@
 C++ ObjC++
 Generate run time type descriptor information
 
+

Re: [gfortran] gfortran options and cc1 warnings

[FX Coudert]

New version of the patch attached, to answer Joseph's remark. Original 
questions still apply, including:


  What should "gfortran -fdollar-ok a.f b.c" do, if -fdollar-ok if a 
fortran-only option?


FX

[gfortran] gfortran options and cc1 warnings

[FX Coudert]

This is a patch proposal about PR fortran/18452. In short, to preprocess 
fortran source files, gfortran calls cc1 with its own options, which 
gives warnings like:


$ gfortran -fdollar-ok a.F90
cc1: warning: command line option "-fdollar-ok" is valid for F95 but not 
for C


A few (two exactly) options were already handled right (-ffixed-form and 
-ffixed-line-length-n), so I applied the method used for those to all 
gfortran options. Questions that need adressing are:


  1. can we get that patch in during the short period when 4.1 will 
unfreeze before branching? it concerns the common code of GCC, and does 
not fix a regression strictly speaking. But that problem is very 
annoying to both users (which make compiling very noisy and errors 
difficult to spot) and developers (preventing libgfortran to be built 
with -Werror), and working around it while changing only gfortran code 
would be *ugly*.


  2. what should be the behaviour of "gfortran -fdollar-ok a.f b.c"? is 
this supposed to be allowed, or not?


  3. if the answer to point 2 is "this isn't allowed", then the 
testsuite framework should be somehow modified :)


  4.  in the case it is allowed, we then need some very clever way to 
get options go where they need (C-only options for b.c and Fortran-only 
options to a.f)


gfortran developers, C front-end maintainers, specs gurus, release 
managers, please speak up! :)


FX
2005-10-31  Francois-Xavier Coudert  <[EMAIL PROTECTED]>

PR fortran/18452
* lang.opt: Add C as language for all options that can be passed
to the preprocessor.


2005-10-31  Francois-Xavier Coudert  <[EMAIL PROTECTED]>

PR fortran/18452
* gcc/c.opt: Remove -ffixed-form and -ffixed-line-length-n
options, now completely handled in fortran/lang.opt.
* gcc/c-opts.c: Add cases for all Fortran options declared as C
and used only when preprocessing.

Index: gcc/fortran/lang.opt
===
--- gcc/fortran/lang.opt	(revision 106019)
+++ gcc/fortran/lang.opt	(working copy)
@@ -22,6 +22,13 @@
 
 ; Please try to keep this file in ASCII collating order.
 
+; To add a new Fortran option, you need to do the following:
+;-- add the option in the list below, using C as well as Fortran
+;   as language if the option will be passed to the preprocessor
+;-- get it handled by the Fortran front-end in options.c
+;-- if you used C as language here, add it to the list of
+;   Fortran options in c_common_handle_option() in file c-opts.c
+
 Language
 Fortran
 
@@ -46,147 +53,147 @@
 Warn about implicit conversion
 
 Wimplicit-interface
-Fortran
+C Fortran
 Warn about calls with implicit interface
 
 Wline-truncation
-Fortran
+C Fortran
 Warn about truncated source lines
 
 Wnonstd-intrinsics
-Fortran
+C Fortran
 Warn about usage of non-standard intrinsics
 
 Wsurprising
-Fortran
+C Fortran
 Warn about \"suspicious\" constructs
 
 Wunderflow
-Fortran
+C Fortran
 Warn about underflow of numerical constant expressions
 
 Wunused-labels
-Fortran
+C Fortran
 Warn when a label is unused
 
 fautomatic
-Fortran
+C Fortran
 Do not treat local variables and COMMON blocks as if they were named in SAVE statements
 
 fbackslash
-Fortran
+C Fortran
 Specify that backslash in string introduces an escape character
 
 fdefault-double-8
-Fortran
+C Fortran
 Set the default double precision kind to an 8 byte wide type
 
 fdefault-integer-8
-Fortran
+C Fortran
 Set the default integer kind to an 8 byte wide type
 
 fdefault-real-8
-Fortran
+C Fortran
 Set the default real kind to an 8 byte wide type
 
 fd-lines-as-code
-Fortran RejectNegative
+C Fortran RejectNegative
 Ignore 'D' in column one in fixed form
 
 fd-lines-as-comments
-Fortran RejectNegative
+C Fortran RejectNegative
 Treat lines with 'D' in column one as comments
 
 fdollar-ok
-Fortran
+C Fortran
 Allow dollar signs in entity names
 
 fdump-parse-tree
-Fortran
+C Fortran
 Display the code tree after parsing
 
 ff2c
-Fortran
+C Fortran
 Use f2c calling convention
 
 ffixed-form
-Fortran
+C Fortran
 Assume that the source file is fixed form
 
 ffree-form
-Fortran
+C Fortran
 Assume that the source file is free form
 
 funderscoring
-Fortran
+C Fortran
 Append underscores to externally visible names
 
 fcray-pointer
-Fortran
+C Fortran
 Use the Cray Pointer extension
 
 fsecond-underscore
-Fortran
+C Fortran
 Append a second underscore if the name already contains an underscore
 
 fimplicit-none
-Fortran
+C Fortran
 Specify that no implicit typing is allowed, unless overridden by explicit IMPLICIT statements
 
 ffixed-line-length-none
-Fortran RejectNegative
+C Fortran RejectNegative
 Allow arbitrary character line width in fixed mode
 
 ffixed-line-length-
-Fortran RejectNegative Joined UInteger
+C Fortran RejectNegative Joined UInteger
 -ffixed-line-length-		Use n as character line width in fixed mode
 
 fmax-identifier-length=
-Fortran RejectNegative Joined UInteger

[libgfortran] Patch to handle statically linked libgfortran

[FX Coudert]

:ADDPATCH testsuite:

Attached patch fixes a bug (PR libfortran/22298) where the libgfortran 
constructor function wasn't linked in when libgfortran was statically 
linked. The patch itself is straightforward and well commented, and it 
could go under the "obvious rule".


I added a test for the testsuite, conditionnal on a new effective 
target. Could someone OK this part?


Thanks,
FX
2005-10-30  Francois-Xavier Coudert  <[EMAIL PROTECTED]>

PR libfortran/22298
* runtime/main.c (stupid_function_name_for_static_linking): New
function.
* runtime/error.c (internal_error): Call
stupid_function_name_for_static_linking.
* libgfortran.h: Add prototype for
stupid_function_name_for_static_linking.


2005-10-30  Francois-Xavier Coudert  <[EMAIL PROTECTED]>

PR libfortran/22298
* gcc/testsuite/lib/target-supports.exp
(check_effective_target_static_libgfortran): New
static_libgfortran effective target.
* gcc/testsuite/gfortran.dg/static_linking_1.f: New test.
* gcc/testsuite/gfortran.dg/static_linking_1.c: New file.
Index: libgfortran/runtime/main.c
===
--- libgfortran/runtime/main.c	(revision 105991)
+++ libgfortran/runtime/main.c	(working copy)
@@ -35,6 +35,14 @@
 
 #include "libgfortran.h"
 
+/* Stupid function to be sure the constructor is always linked in, even
+   in the case of static linking.  See PR libfortran/22298 for details.  */
+void
+stupid_function_name_for_static_linking (void)
+{
+  return;
+}
+
 /* This is the offset (in bytes) required to cast from logical(8)* to
logical(4)*. and still get the same result.  Will be 0 for little-endian
machines and 4 for big-endian machines.  */
Index: libgfortran/runtime/error.c
===
--- libgfortran/runtime/error.c	(revision 105991)
+++ libgfortran/runtime/error.c	(working copy)
@@ -353,6 +353,13 @@
   recursion_check ();
   show_locus ();
   st_printf ("Internal Error: %s\n", message);
+
+  /* This function call is here to get the main.o object file included
+ when linking statically. This works because error.o is supposed to
+ be always linked in (and the function call is in internal_error
+ because hopefully it doesn't happen too often).  */
+  stupid_function_name_for_static_linking();
+
   sys_exit (3);
 }
 
Index: libgfortran/libgfortran.h
===
--- libgfortran/libgfortran.h	(revision 105991)
+++ libgfortran/libgfortran.h	(working copy)
@@ -434,6 +434,9 @@
 
 /* main.c */
 
+extern void stupid_function_name_for_static_linking (void);
+internal_proto(stupid_function_name_for_static_linking);
+
 extern void library_start (void);
 internal_proto(library_start);
 
Index: gcc/testsuite/lib/target-supports.exp
===
--- gcc/testsuite/lib/target-supports.exp	(revision 105991)
+++ gcc/testsuite/lib/target-supports.exp	(working copy)
@@ -522,6 +522,59 @@
 return $et_fortran_large_int_saved
 }
 
+# Return 1 if we can statically link libgfortran, 0 otherwise.
+#
+# When the target name changes, replace the cached result.
+
+proc check_effective_target_static_libgfortran { } {
+global et_static_libgfortran
+global et_static_libgfortran_target_name
+global tool
+
+if { ![info exists et_static_libgfortran_target_name] } {
+	set et_static_libgfortran_target_name ""
+}
+
+# If the target has changed since we set the cached value, clear it.
+set current_target [current_target_name]
+if { $current_target != $et_static_libgfortran_target_name } {
+	verbose "check_effective_target_static_libgfortran: `$et_static_libgfortran_target_name' `$current_target'" 2
+	set et_static_libgfortran_target_name $current_target
+	if [info exists et_static_libgfortran_saved] {
+	verbose "check_effective_target_static_libgfortran: removing cached result" 2
+	unset et_static_libgfortran_saved
+	}
+}
+
+if [info exists et_static_libgfortran_saved] {
+	verbose "check_effective_target_static_libgfortran returning saved $et_static_libgfortran_saved" 2
+} else {
+	set et_static_libgfortran_saved 0
+
+	# Set up, compile, and execute a test program using large integer
+	# kinds.  Include the current process ID in the file names to
+	# prevent conflicts with invocations for multiple testsuites.
+	set src static[pid].f
+set exe static[pid].x
+
+	set f [open $src "w"]
+	puts $f "  print *, 'test'"
+	puts $f "  end"
+	close $f
+
+	verbose "check_effective_target_static_libgfortran compiling testfile $src" 2
+	set lines [${tool}_target_compile $src $exe executable ""]
+	file delete $src
+
+	if [string match "" $lines] then {
+	# No error message, compilation succeeded.
+	set et_static_libgfortran_saved 1
+	}
+}
+
+return $et_static_libgfortran_saved
+}

Re: Vectorizing HIRLAM NN.

[FX Coudert]

Steven Bosscher wrote:

Als je wil, kan ik wel een handje helpen door e.e.a. te analyzeren
voordat je de problemen voorlegt aan de mailing-list.

Erg interessant, als dit werkt.  Gaat het KNMI ook daadwerkelijk
gfortran gebruiken of zijn we nog lang niet ver genoeg daarvoor?


For [EMAIL PROTECTED] subscribers' pleasure, Babelfish proudly 
presents its english translation:


If you want, I can help, however, a hand by e.e.a. at analyzeren before 
you present the problems to the mailing trick. Very interesting, as this 
works. DOES THE KNMI will use also effective gfortran or isn't we still 
long far enough for that?


;-)

Re: RFC: future gfortran development and subversion

[FX Coudert]

A regression is a bug that was not in release N - M and was discovered
in release N.  You are then free to fix N - M + 1 to N.  Like you have
a testcase that crashes gfortran on 4.1.0, but did not on 4.0.2.


But then, you'll explain people that they won't have a decent fortran 
compiler in distros before .


The fortran patches are always fortran-contained, and I think if the 
community thinks it worth to have a different development model (until 
some point in the future, defined in advance) why shouldn't it be so?


FX

Re: GCC 4.1 Status Report (2005-10-02)

[FX Coudert]

I have two separate questions to ask:

  1. what is the status on 21766 (a 4.1 regression)? bootstrap has been 
broken on Windows (cygwin and mingw) for more that 4 months now, is it 
expected to be fixed before branch?


  2. what's the status for fortran wrt the quality push? can we still 
check-in small patches that add support for things g77 supported but 
gfortran does not yet?


Thanks,
FX

Re: gcc 4.1 FAIL: gfortran.dg/large_integer_kind_1.f90 on sparc/sparc64 linux...

[FX Coudert]

is there anything I can provide you with to have a better guess? I'm
definately willing to debug if you direct me...


Unfortunately, I think we need a dejagnu expert here, I have no idea how 
to debug these things...


If nobody can provide help in the next few days, please file a bug-report.

Thanks for your help,
FX

Re: gcc 4.1 FAIL: gfortran.dg/large_integer_kind_1.f90 on sparc/sparc64 linux...

[FX Coudert]

This testcase should only be run if there is a 128-bit integer kind 
available. This looks like it's not the case here, but then why is

check_effective_target_fortran_large_int returning true?

I can't really understand that. What are you tcl/expect/dejagnu versions?