# What are the benefits of User-defined derived-type Input/Output? **URL:** \ **Category:** Uncategorized\ **Created:** [July 24, 2021, 9:29pm UTC](https://fortran-lang.discourse.group/t/what-are-the-benefits-of-user-defined-derived-type-input-output/1585 "2021-07-24T21:29:58Z")\ **Posts on this page:** 1\ **Showing post:** 5
**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\ **Post date:** [July 25, 2021, 1:33pm UTC](https://fortran-lang.discourse.group/t/what-are-the-benefits-of-user-defined-derived-type-input-output/1585/5 "2021-07-25T13:33:26Z")
> [@Beliavsky](#): > > … The code cited in the other thread compiles and runs with Intel Fortran but not with gfortran GNU Fortran (GCC) 12.0.0 20210718 from [equation.com](http://equation.com) for Windows. Gfortran does not like the `private` statements in that code, and even when they are commented out, it gives the messages below. I won’t give up gfortran compataiility … The code example I provided **conforms** to **current** standard Fortran whereas `gfortran` has certain **gaps** in support toward the standard and there is an outstanding list of support requests at GCC Bugzilla. If you seek “gfortran compataiility,” the comment in this [thread](https://fortran-lang.discourse.group/t/constant-expressions-for-bind-c-name/1319/3) applies. gfortran needs a growing team of dedicated FOSS volunteers to contribute to its development and resolve bugs. So the users who rely on `gfortran` should seriously consider joining GCC as FOSS volunteers and/or encourage others to do the same. Otherwise, `gfortran` faces the risk and fate of `g77` and `g95`. --- _[View the full topic](https://fortran-lang.discourse.group/t/what-are-the-benefits-of-user-defined-derived-type-input-output/1585)._