On Thu, Oct 14, 2021 at 02:39:47PM -0500, Bill Schmidt wrote:
> On 10/5/21 12:43 PM, Segher Boessenkool wrote:
> > The last release (version 1.9) was in 2004. If there is interest in
> > making updates to it that coulde be done of course, it is GFDL, there is
> > no red tape getting in the way.
>
Hi!
On Mon, Oct 11, 2021 at 08:11:50PM +, Joseph Myers wrote:
> On Fri, 8 Oct 2021, Segher Boessenkool wrote:
> > But many CPUs do not have hardware floating point in any variant, and
> > their ABIs / calling conventions do not mention floating point at all.
> > Still, this works with GCC
Dear Fortranners,
the attached patch adds a check for the shape of arrays in derived type
constructors. This brings it in line with other major brands.
Example:
type t
integer :: a(1)
end type
type(t), parameter :: y(2) = t([1,2])
end
This was silently accepted before, but now
On 10/5/21 12:43 PM, Segher Boessenkool wrote:
> Hi Joseph,
>
> On Mon, Oct 04, 2021 at 07:24:31PM +, Joseph Myers wrote:
>> On Mon, 4 Oct 2021, Segher Boessenkool wrote:
>>> Some current Power GCC targets support neither. Some support only
>>> double-double. Making IEEE QP float work on
Dear Tobias, Paul, all,
thanks for the feedback!
> Gesendet: Donnerstag, 14. Oktober 2021 um 11:26 Uhr
> Von: "Tobias Burnus"
> > (1) gfortran.dg/derived_constructor_char_1.f90
> > The constructor is shorter than the array component txt in DT t5.
> > Commit r0-101989.
> > @Tobias: can you
On Thu, Oct 14, 2021 at 11:04:59AM +0100, Kwok Cheung Yeung wrote:
> I have now dropped this. This affects test2 in
> gfortran.dg/gomp/declare-variant-8.f90, which I have added a comment to.
Thanks.
> I have added Fortran-specific tests as
> gfortran.dg/gomp/declare-variant-15.f90 to
Hi Harald,
The overfilled constructor in transfer_simplify_2.f90 is indeed an error.
The error is picked up correctly for arrays in
expr.c(gfc_check_conformance):3579 but not for array components.
Regards
Paul
On Thu, 14 Oct 2021 at 10:26, Tobias Burnus wrote:
> Dear all, hello Harald,
>
>
On Thu, Oct 14, 2021 at 12:20:51PM +0200, Jakub Jelinek via Gcc-patches wrote:
> Thinking more about the Fortran case for !$omp sections, there is an
> ambiguity.
> !$omp sections
> block
> !$omp section
> end block
> is clear and !$omp end sections is optional, but
> !$omp sections
> block
>
On Thu, Oct 07, 2021 at 07:09:07PM +0200, Jakub Jelinek wrote:
> The workshare/parallel workshare case is unclear, I've filed
> https://github.com/OpenMP/spec/issues/3153
> for it. Either don't allow block if workshare_stmts_only for now
> until that is clarified, or if we do, we need to make
Dear all, hello Harald,
On 12.10.21 22:50, Harald Anlauf wrote:
while working on a fix for PR102685, I encountered issues with the testsuite.
...
(1) gfortran.dg/derived_constructor_char_1.f90
The constructor is shorter than the array component txt in DT t5.
Commit r0-101989.
@Tobias: can you
Hi Harald,
another simple and obvious fix: we need to reorder the argument checks
to the SHAPE intrinsic so that invalid KIND arguments can be detected.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
As I consider this a safe fix, I'd like to backport to suitable branches.
Also OK for
H Harald,
when simplifying RESHAPE we hit a gcc_assert for negative entries in the
SHAPE array. Obvious solution: replace gcc_assert by an error message.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
As this is a safe fix, I'd like to backport to suitable branches.
OK for both.
12 matches
Mail list logo
