* [Patch, Fortran] Replace intmax_type_node by INTMAX_TYPE
@ 2009-05-29 21:51 Tobias Burnus
2009-05-29 23:21 ` Steve Kargl
2009-06-02 21:16 ` *PING* " Tobias Burnus
0 siblings, 2 replies; 6+ messages in thread
From: Tobias Burnus @ 2009-05-29 21:51 UTC (permalink / raw)
To: gcc-patches, fortran
[-- Attachment #1: Type: text/plain, Size: 418 bytes --]
Hello all,
since gfortran now uses default.h to access the stdint.h
macros, it makes sense to replace our own definition
of intmax_type_node by INTMAX_TYPE. This was suggested
by Michael and Joseph, cf.
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01245.html
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01095.html
The attached patch was send me by FX. Build and regtested
on x86-84-linux. OK for the trunk?
Tobias
[-- Attachment #2: intmax.diff --]
[-- Type: text/x-patch, Size: 1519 bytes --]
2009-05-29 Francois-Xavier Coudert <fxcoudert@gcc.gnu.org>
Tobias Burnus <burnus@net-b.de>
* iso-c-binding.def: Use INTMAX_TYPE instead of intmax_type_node.
* trans-types.c (init_c_interop_kinds): Remove intmax_type_node.
Index: gcc/fortran/iso-c-binding.def
===================================================================
--- gcc/fortran/iso-c-binding.def (Revision 147987)
+++ gcc/fortran/iso-c-binding.def (Arbeitskopie)
@@ -54,7 +54,7 @@ NAMED_INTCST (ISOCBINDING_LONG_LONG, "c_
get_int_kind_from_node (long_long_integer_type_node), GFC_STD_F2003)
NAMED_INTCST (ISOCBINDING_INTMAX_T, "c_intmax_t", \
- get_int_kind_from_node (intmax_type_node), GFC_STD_F2003)
+ get_int_kind_from_name (INTMAX_TYPE), GFC_STD_F2003)
NAMED_INTCST (ISOCBINDING_INTPTR_T, "c_intptr_t", \
get_int_kind_from_name (INTPTR_TYPE), GFC_STD_F2003)
NAMED_INTCST (ISOCBINDING_SIZE_T, "c_size_t", \
Index: gcc/fortran/trans-types.c
===================================================================
--- gcc/fortran/trans-types.c (Revision 147987)
+++ gcc/fortran/trans-types.c (Arbeitskopie)
@@ -285,11 +285,6 @@ static
void init_c_interop_kinds (void)
{
int i;
- tree intmax_type_node = INT_TYPE_SIZE == LONG_LONG_TYPE_SIZE ?
- integer_type_node :
- (LONG_TYPE_SIZE == LONG_LONG_TYPE_SIZE ?
- long_integer_type_node :
- long_long_integer_type_node);
/* init all pointers in the list to NULL */
for (i = 0; i < ISOCBINDING_NUMBER; i++)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Patch, Fortran] Replace intmax_type_node by INTMAX_TYPE
2009-05-29 21:51 [Patch, Fortran] Replace intmax_type_node by INTMAX_TYPE Tobias Burnus
@ 2009-05-29 23:21 ` Steve Kargl
2009-06-02 21:16 ` *PING* " Tobias Burnus
1 sibling, 0 replies; 6+ messages in thread
From: Steve Kargl @ 2009-05-29 23:21 UTC (permalink / raw)
To: Tobias Burnus; +Cc: gcc-patches, fortran
On Fri, May 29, 2009 at 11:50:08PM +0200, Tobias Burnus wrote:
>
> since gfortran now uses default.h to access the stdint.h
> macros, it makes sense to replace our own definition
> of intmax_type_node by INTMAX_TYPE. This was suggested
> by Michael and Joseph, cf.
> http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01245.html
> http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01095.html
>
> The attached patch was send me by FX. Build and regtested
> on x86-84-linux. OK for the trunk?
>
FX's patch to use stdint.h has caused 18 regressions
on FreeBSD, because GCC apparently does not recognize
that FreeBSD has a perfectly fine /usr/include/stdint.h.
I'm not too thrilled with rushing head long into possible
additional regressions until someone with sufficient
knowledge fixes the current set of regressions.
--
Steve
^ permalink raw reply [flat|nested] 6+ messages in thread
* *PING* Re: [Patch, Fortran] Replace intmax_type_node by INTMAX_TYPE
2009-05-29 21:51 [Patch, Fortran] Replace intmax_type_node by INTMAX_TYPE Tobias Burnus
2009-05-29 23:21 ` Steve Kargl
@ 2009-06-02 21:16 ` Tobias Burnus
2009-06-03 20:52 ` Tobias Burnus
1 sibling, 1 reply; 6+ messages in thread
From: Tobias Burnus @ 2009-06-02 21:16 UTC (permalink / raw)
To: gcc-patches, fortran
*PING*
Patch: http://gcc.gnu.org/ml/fortran/2009-05/msg00437.html
Tobias
Tobias Burnus wrote:
> Hello all,
>
> since gfortran now uses default.h to access the stdint.h
> macros, it makes sense to replace our own definition
> of intmax_type_node by INTMAX_TYPE. This was suggested
> by Michael and Joseph, cf.
> http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01245.html
> http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01095.html
>
> The attached patch was send me by FX. Build and regtested
> on x86-84-linux. OK for the trunk?
>
> Tobias
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: *PING* Re: [Patch, Fortran] Replace intmax_type_node by INTMAX_TYPE
2009-06-02 21:16 ` *PING* " Tobias Burnus
@ 2009-06-03 20:52 ` Tobias Burnus
0 siblings, 0 replies; 6+ messages in thread
From: Tobias Burnus @ 2009-06-03 20:52 UTC (permalink / raw)
To: gcc-patches, fortran
Approved by Janne on IRC. Committed to the trunk:
Sending gcc/fortran/ChangeLog
Sending gcc/fortran/iso-c-binding.def
Sending gcc/fortran/trans-types.c
Transmitting file data ...
Committed revision 148145.
Tobias
Tobias Burnus wrote:
> *PING*
>
> Patch: http://gcc.gnu.org/ml/fortran/2009-05/msg00437.html
>
> Tobias
>
> Tobias Burnus wrote:
>
>> Hello all,
>>
>> since gfortran now uses default.h to access the stdint.h
>> macros, it makes sense to replace our own definition
>> of intmax_type_node by INTMAX_TYPE. This was suggested
>> by Michael and Joseph, cf.
>> http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01245.html
>> http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01095.html
>>
>> The attached patch was send me by FX. Build and regtested
>> on x86-84-linux. OK for the trunk?
>>
>> Tobias
>>
>>
>
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Patch, Fortran] Replace intmax_type_node by INTMAX_TYPE
2009-05-30 15:05 FX
@ 2009-05-31 13:59 ` Gerald Pfeifer
0 siblings, 0 replies; 6+ messages in thread
From: Gerald Pfeifer @ 2009-05-31 13:59 UTC (permalink / raw)
To: fxcoudert; +Cc: Fortran List, Steve Kargl, gcc-patches, Tobias Burnus
On Sat, 30 May 2009, FX wrote:
>> FX's patch to use stdint.h has caused 18 regressions on FreeBSD,
>> because GCC apparently does not recognize that FreeBSD has a perfectly
>> fine /usr/include/stdint.h.
> I think it's unfair to Joseph to criticize him for providing that,
> unless you have a constructive alternative to propose ("patches are
> reviewed on the basis of their technical merit").
If anything, FreeBSD developers/users could be criticized for not
getting their act together and taking better care of FreeBSD support
in GCC.
> Regarding the patch: I don't think this patch should introduce any
> new failure, as on targets such as FreeBSD the middle-end defaults
> (gcc/defaults.h) are the same as the definition we used in the
> front-end.
What I find comparing the snapshot from two days ago
http://gcc.gnu.org/ml/gcc-testresults/2009-05/msg02642.html
with my currently testing patch with stdint.h support on FreeBSD is
that we go from
# of expected passes 30253
# of unexpected failures 19
# of expected failures 20
# of unsupported tests 242
to
# of expected passes 30303
# of unexpected failures 1
# of expected failures 20
# of unsupported tests 250
as far as Fortran is concerned. My tests are still running, but expect
to see a working patch being submitted in a few hours. :-)
Gerald
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Patch, Fortran] Replace intmax_type_node by INTMAX_TYPE
@ 2009-05-30 15:05 FX
2009-05-31 13:59 ` Gerald Pfeifer
0 siblings, 1 reply; 6+ messages in thread
From: FX @ 2009-05-30 15:05 UTC (permalink / raw)
To: Fortran List, Steve Kargl; +Cc: gcc-patches, Tobias Burnus
> FX's patch to use stdint.h has caused 18 regressions
> on FreeBSD, because GCC apparently does not recognize
> that FreeBSD has a perfectly fine /usr/include/stdint.h.
The second part of that statement is wrong. Not matter-of-opinion
wrong, but factually wrong. GCC does not try to "recognize" system
headers such as stdint.h (such a scheme would not work in the general
case, including cross-compilation for example).
New functionality was added to GCC-4.5, requiring an extra bit of
target information. There is no other way this information could have
"guessed"; Joseph's infrastructure does the job, and it necessarily
needs some well-informed input for targets. It is necessary for C99
and F2003 conformance, and I am thankful that he did that job (my two
previous attemps at it were failures). I think it's unfair to Joseph
to criticize him for providing that, unless you have a constructive
alternative to propose ("patches are reviewed on the basis of their
technical merit").
> I'm not too thrilled with rushing head long into possible
> additional regressions until someone with sufficient
> knowledge fixes the current set of regressions.
Regarding the patch: I don't think this patch should introduce any new
failure, as on targets such as FreeBSD the middle-end defaults (gcc/
defaults.h) are the same as the definition we used in the front-end.
FX
PS: I am sure you're aware that Gerald Pfeifer is putting up together
a patch to add the needed information (http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01927.html
).
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-06-03 20:52 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-29 21:51 [Patch, Fortran] Replace intmax_type_node by INTMAX_TYPE Tobias Burnus
2009-05-29 23:21 ` Steve Kargl
2009-06-02 21:16 ` *PING* " Tobias Burnus
2009-06-03 20:52 ` Tobias Burnus
2009-05-30 15:05 FX
2009-05-31 13:59 ` Gerald Pfeifer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).