public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [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).