On Tue, Oct 10, 2023 at 06:46:35PM +0200, Tobias Burnus wrote:
> * parse.cc (check_omp_allocate_stmt): Permit procedure pointers
> here (rejected later) for less mislreading diagnostic.
s/misl/mis/
> libgomp/ChangeLog:
>
> * libgomp.texi:
Fill in something here.
> @@ -7220,8
On Wed, Oct 18, 2023 at 11:12:44AM +0200, Thomas Schwinge wrote:
> Hi Tobias!
>
> On 2023-10-13T15:29:52+0200, Tobias Burnus wrote:
> > => Updated patch attached
>
> When cherry-picking this commit 2d3dbf0eff668bed5f5f168b3cafd8590c54
> "Fortran: Support OpenMP's 'allocate' directive for sta
On Wed, Oct 18, 2023 at 12:56:01PM +0200, Tobias Burnus wrote:
> On 18.10.23 11:36, Jakub Jelinek wrote:
> > On Wed, Oct 18, 2023 at 11:12:44AM +0200, Thomas Schwinge wrote:
> > > +FAIL: gfortran.dg/gomp/allocate-13.f90 -O (internal compiler
> > > error: tree c
On Thu, Nov 23, 2023 at 03:21:41PM +0100, Tobias Burnus wrote:
> I stumbled over this trivial omission which blocks some testcases.
>
> I am not sure whether I have solved the is-same-expr most elegantly,
> but I did loosely follow the duplicated-entry check for 'map'. As that's
> a restriction to
On Thu, Nov 23, 2023 at 04:21:50PM +0100, Tobias Burnus wrote:
> @@ -21663,7 +21666,25 @@ c_parser_omp_depobj (c_parser *parser)
> clause = error_mark_node;
> }
>else if (!strcmp ("destroy", p))
> - kind = OMP_CLAUSE_DEPEND_LAST;
> + {
> + matching_parens c_par
On Thu, Nov 23, 2023 at 04:59:16PM +0100, Tobias Burnus wrote:
> > There is also OEP_LEXICOGRAPHIC which could be used in addition to that.
> > The question is if we want to consider say
> > #pragma depobj (a[++i]) destroy (a[++i])
> > as same or different (similarly a[foo ()] in both cases).
>
>
On Fri, Nov 24, 2023 at 02:51:28PM +0100, Tobias Burnus wrote:
> Following the general trend to add a "[-W...]" to the warning messages
> for both better grouping of the warnings and - more importantly - for
> providing
> a means to silence such a warning (or to -Werror= them explicitly), this pat
On Mon, Nov 27, 2023 at 11:20:20AM +0100, Christophe Lyon wrote:
> On Fri, 24 Nov 2023 at 15:08, Jakub Jelinek wrote:
> > > Comments or remarks before I commit it?
> >
> > LGTM, thanks for working on it.
> >
> > Jakub
> >
>
> I thin
FC_LOGICAL_2
#define HAVE_GFC_INTEGER_2
-typedef int32_t GFC_INTEGER_4;
-typedef uint32_t GFC_UINTEGER_4;
+typedef long GFC_INTEGER_4;
+typedef unsigned long GFC_UINTEGER_4;
typedef GFC_INTEGER_4 GFC_LOGICAL_4;
#define HAVE_GFC_LOGICAL_4
#define HAVE_GFC_INTEGER_4
in the build dir to em
On Tue, Dec 05, 2023 at 10:47:34AM +, Richard Earnshaw wrote:
> > The following patch makes libgfortran build on i686-linux after hacking up
> > --- kinds.h.xx 2023-12-05 00:23:00.133365064 +0100
> > +++ kinds.h 2023-12-05 11:19:24.409679808 +0100
> > @@ -10,8 +10,8 @@ typedef GFC_INTEGER_
On Tue, Dec 05, 2023 at 10:57:50AM +, Richard Earnshaw wrote:
> On 05/12/2023 10:51, Jakub Jelinek wrote:
> > On Tue, Dec 05, 2023 at 10:47:34AM +, Richard Earnshaw wrote:
> > > > The following patch makes libgfortran build on i686-linux after hacking
> > &g
On Fri, Aug 18, 2023 at 11:18:19AM +0800, Zhu, Lipeng wrote:
> From: Lipeng Zhu
>
> This patch try to introduce the rwlock and split the read/write to
> unit_root tree and unit_cache with rwlock instead of the mutex to
> increase CPU efficiency. In the get_gfc_unit function, the percentage
> to s
On Wed, Nov 08, 2023 at 05:58:10PM +0100, Tobias Burnus wrote:
> --- a/gcc/builtins.cc
> +++ b/gcc/builtins.cc
> @@ -11739,6 +11739,7 @@ builtin_fnspec (tree callee)
> return ".cO ";
>/* Realloc serves both as allocation point and deallocation point. */
>case BUILT_IN_REALLOC
On Mon, Nov 20, 2023 at 11:42:02AM +0100, Tobias Burnus wrote:
> 2023-11-19 Tobias Burnus
> Chung-Lin Tang
>
> gcc/ChangeLog:
>
> * builtin-types.def (BT_FN_VOID_PTRMODE):
> (BT_FN_PTRMODE_PTRMODE_INT_PTR): Add.
> * gimplify.cc (gimplify_bind_expr): Diagnose missin
On Tue, Nov 28, 2023 at 12:28:05PM +0100, Tobias Burnus wrote:
> I stumbled over this omission when looking at Sandra's patch. It turned out
> that this is
> a new OpenMP 5.2 feature - probably added to simplify/unify the syntax. I
> guess the reason
> that release/acquire wasn't added before is
On Sat, Dec 09, 2023 at 12:19:10PM +0100, Thomas Schwinge wrote:
> > --- a/gcc/omp-builtins.def
> > +++ b/gcc/omp-builtins.def
> > @@ -467,6 +467,9 @@ DEF_GOMP_BUILTIN
> > (BUILT_IN_GOMP_WORKSHARE_TASK_REDUCTION_UNREGISTER,
> > DEF_GOMP_BUILTIN (BUILT_IN_GOMP_ALLOC,
> > "GOMP_allo
On Sat, Dec 09, 2023 at 10:39:45AM -0500, Lipeng Zhu wrote:
> This patch try to introduce the rwlock and split the read/write to
> unit_root tree and unit_cache with rwlock instead of the mutex to
> increase CPU efficiency. In the get_gfc_unit function, the percentage
> to step into the insert_unit
16 multiplication only works on the
former.
Tested on x86_64-linux -m32/-m64, committed to trunk.
2023-12-14 Jakub Jelinek
* c-c++-common/gomp/target-enter-data-1.c: Match also sizeof bar on
32-bit targets - 8 bytes - rather than just 16 bytes.
--- gcc/testsuite/c-c++-common/g
On Thu, Dec 14, 2023 at 01:29:01PM +0100, Thomas Schwinge wrote:
> > Sure, I will look into that.
> >
> > BTW, I didn’t have the PowerPC in hands, do you mind granting the access of
> > your
> > test environment to me to help reproduce the issue?
>
> That's unfortunately not possible: it's behind
On Fri, Jan 05, 2024 at 12:23:26PM +, Julian Brown wrote:
> * g++.dg/gomp/bad-array-section-10.C: New test.
This test FAILs in C++23/C++26 modes, just try
make check-g++ GXX_TESTSUITE_STDS=98,11,14,17,20,23,26
RUNTESTFLAGS=gomp.exp=bad-array-section-10.C
While in C++20 comma in ar
On Thu, Jan 04, 2024 at 08:43:26PM -0500, Lipeng Zhu wrote:
> This patch try to fix the bug when HAVE_ATOMIC_FETCH_ADD is
> not defined in dec_waiting_unlocked function. As io.h does
> not include async.h, the WRLOCK and RWUNLOCK macros are
> undefined.
>
> libgfortran/ChangeLog:
>
> * io/i
nd_decl expressions, so hacks like save the previous
value, overwrite it temporarily over some call that will use expr2 and
restore afterwards aren't needed - there are no such calls, so the
following patch fixes it just by not messing up with
expr2->ts.u.cl->backend_decl, only set
On Sat, Feb 17, 2024 at 04:05:16PM +0100, Harald Anlauf wrote:
> > +program pr113503
> > + implicit none
> > + type :: T
> > +character(len=:), allocatable :: u
> > + end type
> > + character(len=20) :: us(1) = 'foobar'
> > + type(T) :: x
> > + x = T(u = trim (us(1))) ! { dg-bogus "is us
On Fri, Feb 23, 2024 at 12:25:54PM +0100, Tobias Burnus wrote:
> When checking something else, I noticed that there was one warning in
> openmp.cc that did not use OPT_Wopenmp.
>
> I intent to commit the attached patch later today as obvious.
>
> Tobias
> Fortran/Openmp: Use OPT_Wopenmp for gfc_
On Mon, Mar 11, 2024 at 11:07:46AM +0100, Tobias Burnus wrote:
> Using dummy procedures in a target region with 'defaultmap(none)' leads to:
>
> Error: 'g' not specified in enclosing 'target'
>
> and this cannot be fixed by using 'firstprivate' as non-pointer dummy routines
> are rejected as "E
On Sun, Apr 28, 2024 at 10:37:06PM +0100, Paul Richard Thomas wrote:
> Could this be looked at quickly? The timing of this regression is more than
> a little embarrassing on the eve of the 14.1 release. The testcase and the
> comment in gfc_trans_class_init_assign explain what this problem is all
>
On Mon, Jul 29, 2024 at 09:53:47AM +0200, Tobias Burnus wrote:
> Hi Andre, hi all,
>
> Andre Vehreschild wrote:
> > yes, I could have looked harder 🙂
>
> I wrote ;-) on purpose as this feature is somewhat hidden and writing 'dg-do
> compile' doesn't harm.
I think an explicit dg-do is better, oth
bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-08-01 Jakub Jelinek
* trans-types.cc (gfc_get_array_descr_info): Add rank_off to t
if rank_off isn't zero rather than dtype_off.
--- gcc/fortran/trans-types.cc.jj 2024-07-19 17:22:59.4050970
linux
successfully, ok for trunk?
2024-08-01 Jakub Jelinek
* dependency.cc (gfc_check_dependency): Fix a pasto, check
sym1->as->type for AS_ASSUMED_SHAPE rather than sym2->as->type.
Formatting fix.
--- gcc/fortran/dependency.cc.jj2024-07-01 11:28:2
ase_decl;
if (!integer_zerop (data_off))
t = fold_build_pointer_plus (t, data_off);
earlier in, because at least in the current ABI data_off is always 0 and
integer_zerop is less expensive than getting through match.pd to find out
that POINTER_PLUS_EXPR something 0 is something, there are no other
inte
On Thu, Aug 01, 2024 at 09:03:39PM +0200, Mikael Morin wrote:
> Le 01/08/2024 à 12:00, Jakub Jelinek a écrit :
> > Hi!
> >
> > A static analyzer found what seems like a pasto in the PR45019 changes,
> > the second branch of || only accesses sym2 while the first one s
On Fri, Aug 02, 2024 at 04:58:09PM +0200, Mikael Morin wrote:
> > But the function actually returns 0 rather than 1 that PR45019 meant.
> > So I bet in addition to fixing the pasto we should move that conditional
> > from where it is right now to the return 0; location after
> > check_data_pointer_
On Fri, Aug 02, 2024 at 06:29:27PM +0200, Mikael Morin wrote:
> I agree with all of that. Sure keeping the condition around would be the
> safest. I'm just afraid of keeping code that would remain dead.
>
> > > > And the pasto fix would guess fix
> > > > aliasing_dummy_5.f90 with
> > > > a
On Wed, Aug 07, 2024 at 02:08:42PM +0200, Tobias Burnus wrote:
> On Aug 1, 2024, Jakub Jelinek wrote:
> > On Tue, Jul 30, 2024 at 10:51:56PM +0200, Tobias Burnus wrote:
> > > - char id[sizeof (SSDF_IDENTIFIER) + 1 /* '\0' */ + 32];
> > > + tree name;
>
On Wed, Aug 07, 2024 at 05:57:05PM +0200, Tobias Burnus wrote:
> for C/C++, -fno-builtin-omp_is_initial_device already disabled the
> expansion.
Good idea.
> RFC: Should be document this new built-in some where? If so, where? As part
> of the routine description in libgomp.texi? Or in extend.texi
On Wed, Aug 07, 2024 at 06:58:23PM +0200, Jakub Jelinek wrote:
> > For Fortran, this plus into gfc_get_extern_function_decl, i.e. that name
> > appears as external declaration. While the user could mess around, it checks
> > that it is a function and the return type is th
On Thu, Aug 15, 2024 at 08:30:12PM +0200, Andre Vehreschild wrote:
> Hi Harald,
>
> whoopsie, I am sorry for that.
>
> What I don't get is, why this has not been reported during my bootstrap. I am
> doing this to bootstrap:
>
> LANG=C "${SRCPATH}/configure" \
> --disable
Hi!
On Thu, Aug 15, 2024 at 08:50:38PM +0200, Jakub Jelinek wrote:
> > whoopsie, I am sorry for that.
> >
> > What I don't get is, why this has not been reported during my bootstrap. I
> > am
> > doing this to bootstrap:
> >
On Sun, Sep 22, 2024 at 11:47:09PM +0200, Andreas Schwab wrote:
> On Sep 22 2024, Jakub Jelinek wrote:
>
> > On Sun, Sep 22, 2024 at 10:52:37PM +0200, Andreas Schwab wrote:
> >> On Sep 22 2024, Mikael Morin wrote:
> >>
> >> > @@ -370,7 +370,7 @@ Set th
On Sat, Sep 21, 2024 at 04:32:38PM +0200, Mikael Morin wrote:
> Thanks for the tip.
> The Makefile dependencies seem to be incomplete.
> Here is what I get:
AFAIK right now one needs to configure at least c,c++,fortran,d
in --enable-languages (or some superset thereof) and
make -C gcc html
make -C
On Sun, Sep 22, 2024 at 10:52:37PM +0200, Andreas Schwab wrote:
> On Sep 22 2024, Mikael Morin wrote:
>
> > @@ -370,7 +370,7 @@ Set the default accessibility of module entities to
> > @code{PRIVATE}.
> > Use-associated entities will not be accessible unless they are explicitly
> > declared as @
On Sun, Sep 22, 2024 at 04:17:11PM +0200, Mikael Morin wrote:
> -@opindex @code{std=}@var{std} option
> +@opindex std=@var{std} option
IMHO this one should be just
@opindex std=@var{std}
The option part is superfluous.
> -@opindex @code{idirafter @var{dir}}
> +@opindex idirafter @var{dir}
> -@op
On Mon, Sep 16, 2024 at 10:52:43AM +0200, Mikael Morin wrote:
> > While I understand the intent of 'positive form' vs 'negative form', the
> > above might be clearer as
> >
> > Usage of intrinsics can be implemented either by generating a call
> > to the libgfortran library function or by
On Fri, Nov 15, 2024 at 07:45:32AM +, Paul Richard Thomas wrote:
> Hi Jakub,
Honza's catch.
> Good catch! Does it fix any specific PR?
Dunno. I think even without a PR it can be backported after a while.
Jakub
On Thu, Nov 14, 2024 at 08:58:26PM +0100, Jan Hubicka wrote:
> fortran produces malloc call with signed size instead of unsigned. This
> in turn makes gimple_call_builtin_p to fail type checking and we do not
> treat the call as malloc call.
>
> regtested x86_64-linux, OK?
>
> gcc/fortran/ChangeL
On Tue, Dec 03, 2024 at 10:34:34AM +0100, Tobias Burnus wrote:
> --- a/gcc/testsuite/c-c++-common/gomp/allocate-18.c
> +++ b/gcc/testsuite/c-c++-common/gomp/allocate-18.c
> @@ -17,14 +17,14 @@ typedef enum omp_allocator_handle_t
>
> void test0 ()
> {
> - int A1[5];
> + int A1[5], B1[1];
I'd
On Wed, Jan 08, 2025 at 09:14:59AM +0100, Eric Botcazou wrote:
> > So, this patch is an alternative to the
> > https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669671.html
> > patch, which had the major problem that it required changing all the
> > DWARF consumers to be able to debug C17 or
On Wed, Jan 08, 2025 at 11:53:53AM +0100, Andre Vehreschild wrote:
> Well, thinking about it, it smells like a side-effect of the 116669 fix. A
> type
> getting the recursive marker enforces the generation of the vtype for it. I
> don't see yet, why the iso_c_binding_C_funptr should be marked as r
On Wed, Jan 08, 2025 at 04:34:18PM +0100, Jakub Jelinek wrote:
> I'm testing for that instead:
> --- gcc/module.cc.jj 2025-01-08 15:23:54.511732946 +0100
> +++ gcc/module.cc 2025-01-08 16:32:14.963984426 +0100
> @@ -7122,9 +7122,11 @@ use_iso_fortran_env_module (voi
On Wed, Jan 08, 2025 at 01:40:20PM +0100, Mikael Morin wrote:
> Le 08/01/2025 à 11:42, Jakub Jelinek a écrit :
> >
> > The full list of changes with the posted patches is
> > (first a.mod, then b.mod, 14 -> 15) below.
> > I have no idea what adds those __copy_* elts
On Wed, Jan 08, 2025 at 03:16:46PM +0100, Mikael Morin wrote:
> I think your patch is enough, we don't need to target same-bytes formats
> between module versions.
I can confirm the ICE on the small reproducer I've posted is gone with the
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/6729
On Wed, Jan 08, 2025 at 03:48:46PM +0100, Andre Vehreschild wrote:
> Hi,
>
> I have added this small patch (attached). Unfortunately I got regressions
>
> some in iso_fortran_env_8.f90
> and several in unsigned_NN.f90 tests.
>
> Just retesting w/o my patch and already seeing the iso_fortran_env
On Wed, Jan 08, 2025 at 06:23:40PM +0100, Andre Vehreschild wrote:
> gcc/fortran/ChangeLog:
>
> PR fortran/118337
> * module.cc (use_iso_fortran_env_module): Prevent additional run
> over (un-)signed ints and assign kind directly.
> ---
> gcc/fortran/module.cc | 13 ++---
On Wed, Jan 08, 2025 at 04:09:36PM +0100, Andre Vehreschild wrote:
> One of the issues are lines:
>
> module.cc 7125-7130: Here it is assumed that the signed and unsigned types are
> adjacent maybe?!
>
> I have changed this:
>
> diff --git a/gcc/fortran/module.cc b/gcc/fortran/module.cc
> index
On Wed, Jan 08, 2025 at 11:34:35AM +0100, Andre Vehreschild wrote:
> marking the vtypes as recursive is odd, but should not be taken as any
> incompatibility marker. Pre version 15 gfortran does not check the recursive
> attr on types. So whether it is set or not, is of no concern to gfortran <=
>
59 -> 63, numeric_storage_size 60 -> 64, etc.
So, I really don't know if it is feasible to ensure backwards compatibility.
Plus how we would actually test whether we are able to accept the older
modules in newer compilers.
2025-01-08 Jakub Jelinek
PR fortran/118337
On Wed, Jan 08, 2025 at 12:42:39PM +0100, Andre Vehreschild wrote:
> Er, call me stupid, but what is the easiest way to apply your patch? 'git am'
> on
> the part from the date-line to the end stripping your greetings, always leads
> to unrecognized patch format. Using `patch -p1` did not work eit
also MOD_VERSION "15",
but it is unfinished.
2025-01-08 Jakub Jelinek
PR fortran/118337
* module.cc (MOD_VERSION): Bump to "16".
--- gcc/fortran/module.cc.jj2025-01-02 11:47:31.697201637 +0100
+++ gcc/fortran/module.cc 2025-01-07 21:41:46.866494776 +010
On Wed, Jan 08, 2025 at 10:47:39AM +0100, Richard Biener wrote:
> I wonder if we can somehow add some test coverage? Are .mod files
> target independent and thus can we include them in the testsuite?
They are, but they are compressed and having binary data in the testsuite
is a problem. But perh
27;ve also added an assert, I think it isn't really needed to assert that
symbol[i].id == a in each case, just that we increment i for all the cases.
2025-01-09 Jakub Jelinek
PR fortran/118337
* module.cc (use_iso_fortran_env_module): Add a comment explaining
On Thu, Jan 09, 2025 at 03:28:28PM +0100, Jakub Jelinek wrote:
> So like this?
Thomas mentioned bad wording in a private mail. Here is a better patch:
2025-01-09 Jakub Jelinek
PR fortran/118337
* module.cc (use_iso_fortran_env_module): Add a comment explaining
On Thu, Jan 09, 2025 at 06:12:51PM +0100, Andre Vehreschild wrote:
> Yes, that is what I had in mind. Being German I don't see any problem with the
> explanation, but that is better judged by a native English speaker.
>
> Is the send patch hunk intentional where only indentation is changed? I
> h
Hi!
ICE on this test was fixed by r15-2131. This just adds test for it.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk
as obvious.
2025-03-06 Jakub Jelinek
PR fortran/104826
* gfortran.dg/gomp/pr104826.f90: New test.
--- gcc/testsuite/gfortran.dg
hing. Note, you'd need
to drop the -O3 from dg-options in that case for sure, because with explicit
-O3 option in there it cycles through -O0 -O3, -O1 -O3, -O2 -O3,
-O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer
-finline-functions -O3,
-O3 -g -O3, -Os -O3.
Ok for trunk?
Or do you
On Thu, Mar 27, 2025 at 07:34:14PM +0100, Jakub Jelinek wrote:
> The following patch runs the test only in the -O3 -g case (just using -O3
> there would run it twice, once with
> -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer
> -finline-functions
> and once with
&g
ave a few occurrences, but not too much).
Ok for trunk?
2025-03-28 Jakub Jelinek
* lib/gfortran-dg.exp: Don't cycle through the option list if
dg-options or dg-additional-options contains -O after space, tab,
double quote or open curly bracket.
* gfortran
On Fri, Apr 18, 2025 at 05:48:46PM -0700, Jerry D wrote:
> I will be committing a fix for this to the 16 mainline tonight.
>
> I am requesting Release Manager approval to push to 15 release branch after
> full testing here.
>
> Regards,
>
> Jerry
>
> See attached diff.
>
> 2025-04-18 Steven G
needed.
Ok for power-ieee128 branch?
2021-12-31 Jakub Jelinek
* libgfortran.h (internal_pack_r17, internal_pack_c17,
internal_unpack_r17, internal_unpack_c17, pack_r17, pack_c17,
unpack0_r17, unpack0_c17, unpack1_r17, unpack1_c17, spread_r17,
spread_c17
abi_kind or kind?
I guess at least before the IO case is solved there is no point
in checking the testsuite, too many things will be majorly broken...
2021-12-31 Jakub Jelinek
* gfortran.h (gfc_real_info): Add abi_kind member.
(gfc_type_abi_kind): Declare.
*
On Fri, Dec 31, 2021 at 03:16:47PM +0100, Jakub Jelinek via Gcc-patches wrote:
> Haven't played enough with it to see if the various *_r17 or *_c17
> API entrypoints are called (but verified abi_kind is right in the
> debugger), in all my attempts so far everything was emitted inl
port_specific_symbol_files="$port_specific_symbol_files
\$(top_srcdir)/config/os/gnu-linux/ldbl-ieee128-extra.ver"
ac_ldbl_alt128_compat=yes
else
ac_ldbl_alt128_compat=no
fi
;;
The idea behind this is that libstdc++ is written such
On Mon, Jan 03, 2022 at 11:33:32AM +0100, Jakub Jelinek wrote:
> The idea behind this is that libstdc++ is written such that it can handle
> both IBM extended and IEEE quad long double, so its object files are
> compatible with both.
Now tested on powerpc64le-linux (and together
Hi!
Testing found that we also need libquadmath to be built with
-mno-gnu-attribute, otherwise -mabi=ieeelongdouble programs don't link.
Ok for power-ieee128?
2022-01-03 Jakub Jelinek
* configure.ac: Set XCFLAGS to -mno-gnu-attribute on
powerpc64le*-
symbols appear conditionally at
different symbol versions, or another option would be to choose different
symbol names for those for the powerpc64le-linux cases
(e.g. _gfortran_transfer_{real,complex}ieee128{,_write}).
Any preferences?
2022-01-03 Jakub Jelinek
* libgfortran.h
Jakub Jelinek
* trans-io.c (transfer_namelist_element): Use gfc_type_abi_kind,
formatting fixes.
(transfer_expr): Use gfc_type_abi_kind, use *REAL128* APIs even
for abi_kind == 17.
--- gcc/fortran/trans-io.c.jj 2021-12-31 11:00:15.052190585 +
+++ gcc/fortran
On Mon, Jan 03, 2022 at 04:36:21PM +0100, Jakub Jelinek via Gcc-patches wrote:
> The following patch adds the library side of -mabi=ieeelongdouble
> I/O support.
>
> There is one issue to be resolved though, for the sake of libgfortran.a
> built on an older powerpc64le-linux syst
On Mon, Jan 03, 2022 at 06:03:41PM +0100, Thomas Koenig wrote:
> On 03.01.22 17:26, Jakub Jelinek wrote:
>
> > so we could similarly have something like:
> > #if !(defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
> >
On Mon, Jan 03, 2022 at 11:43:57PM +0100, Thomas Koenig wrote:
> > clearly there is still work to fix (but seems e.g. most of the lto tests
> > are related to the gnu attributes stuff:( ).
>
> This is looking better than what I expected. Apart from LTO, I expect
I've just verified that LTO is b
-finline-functions execution test
FAIL: gfortran.dg/large_real_kind_1.f90 -O3 -g execution test
FAIL: gfortran.dg/large_real_kind_1.f90 -Os execution test
Ok for power-ieee128?
2022-01-04 Jakub Jelinek
* io/write_float.def (CALCULATE_EXP): If HAVE_GFC_REAL_17, also use
: gfortran.dg/quad_2.f90 -Os execution test
Ok for power-ieee128?
2022-01-04 Jakub Jelinek
gcc/fortran/
* trans-io.c (transfer_array_desc): Pass abi kind instead of kind
to libgfortran.
libgfortran/
* io/read.c (convert_real): Add missing break; for the
/dec_math_1.f90 -O3 -g execution test
FAIL: gfortran.dg/ieee/dec_math_1.f90 -Os execution test
Ok for power-ieee128?
2022-01-04 Jakub Jelinek
gcc/fortran/
* trans-intrinsic.c (gfc_get_intrinsic_lib_fndecl): Use
gfc_type_abi_kind.
libgfortran/
* libgfortran.h
fortran or elsewhere)?
At least in libgfortran/generates/*, GFC_DESCRIPTOR_SIZE is mostly used
as mask_kind (I think the mask arrays are always logical not real/complex,
right?), or for logical stuff like matmul_l*.
2022-01-04 Jakub Jelinek
* gfortran.dg/pr47614.f: Don't use -mcpu=
On Thu, Jan 06, 2022 at 09:01:54PM +0100, Thomas Koenig wrote:
> On 06.01.22 06:00, Michael Meissner via Fortran wrote:
> > I pushed the patch to the branch.
>
> Test results are looking quite good right now.
>
> What is still missing is the conversion for unformatted I/O, both
> ways. I'll star
On Thu, Jan 06, 2022 at 09:01:54PM +0100, Thomas Koenig wrote:
>
> On 06.01.22 06:00, Michael Meissner via Fortran wrote:
> What is still missing is the conversion for unformatted I/O, both
> ways. I'll start doing some stuff on it. Just one question:
> What are functions that I can use to conver
On Thu, Jan 06, 2022 at 09:01:54PM +0100, Thomas Koenig wrote:
>
> On 06.01.22 06:00, Michael Meissner via Fortran wrote:
> > I pushed the patch to the branch.
>
> Test results are looking quite good right now.
I've just tried to build libgfortran on an old glibc system
(gcc112.fsffrance.org) an
On Fri, Jan 07, 2022 at 12:29:25PM +0100, Jakub Jelinek wrote:
> we don't do it consistently:
> readelf -Wr
> /home/jakub/gcc/obj38/powerpc64le-unknown-linux-gnu/libgfortran/.libs/libgfortran.so.5.0.0
> | grep ieee128
> 00250310 01280015 R_PPC64_JMP_SLOT
n and uses
it together with TARGET_GLIBC_M* checks to decide whether to use
libquadmath APIs (for the IEEE quad kind=16 if -fbuilding-libgfortran
and not glibc or glibc is older than 2.32) or glibc 2.32 APIs
(otherwise). This way, libgfortran uses solely the libquadmath APIs
on glibc < 2.32 and __
On Fri, Jan 07, 2022 at 11:26:15AM +0100, Thomas Koenig wrote:
> In
>
> https://gcc.gnu.org/pipermail/fortran/2021-October/056895.html
>
> I made a suggestion how how the format could look like. I used
> a plus sign instead of a comma because I thought the environment
> variable should follow th
On Fri, Jan 07, 2022 at 10:40:50PM +0100, Thomas Koenig wrote:
> One thing that one has to watch out for is a big-endian IBM long double
> file, so the byte swapping will have to be done before assigning
> the value.
I've tried to handle that right, i.e. on unformatted read with
byte-swapping and
On Sat, Jan 08, 2022 at 11:07:24AM +0100, Thomas Koenig wrote:
> I have tried to unravel the different cases here, I count six
> (lumping together the environment variables, the CONVERT specifier
> and -fconvert, and leaving out the byte swapping)
>
> CompilerConvert Read action Write ac
On Sat, Jan 08, 2022 at 12:00:38PM +0100, Jakub Jelinek via Gcc-patches wrote:
> And IMHO the default like for byte-swapping should be the native
> format, i.e. the one the program actually used.
One reason for that is that neither conversion is lossless, neither format
is a subset or super
On Sat, Jan 08, 2022 at 12:10:56PM +0100, Jakub Jelinek via Gcc-patches wrote:
> One reason for that is that neither conversion is lossless, neither format
> is a subset or superset of the other. Yes, IEEE quad has both much bigger
> exponent range (-16382..16383 vs. -1022..1023) and
On Sat, Jan 08, 2022 at 03:13:10PM +0100, Thomas Koenig wrote:
>
> On 08.01.22 15:02, Jakub Jelinek via Fortran wrote:
> > Note, as for byteswapping, apparently it wasn't ever working right fox
> > the IBM extended real(kind=16) and complex(kind=16).
>
> The
On Wed, Nov 24, 2021 at 06:08:02PM +0100, Marcel Vollweiler wrote:
> + case OMP_CLAUSE_HAS_DEVICE_ADDR:
> + t = OMP_CLAUSE_DECL (c);
> + if (TREE_CODE (t) == TREE_LIST)
> + {
> + if (handle_omp_array_sections (c, ort))
> + remove = true;
> + e
es. We need to git merge master; git rebase of course
before trying to cherry-pick those commits into trunk and pushing there.
2022-01-11 Jakub Jelinek
* io/transfer.c (unformatted_read, unformatted_write): When
byteswapping IBM extended real(kind=16), handle it as byteswapp
On Tue, Jan 11, 2022 at 02:27:57PM +0100, Tobias Burnus wrote:
> Hi Jakub, hi all,
>
> let me quickly comment on 'has_device_addr' with Fortran arrays
> and with an array section (i.e. regarding your comment quoted
> at the very bottom of this email).
>
> Unfortunately, the OpenMP specification i
On Tue, Jan 11, 2022 at 04:50:02PM +0100, Martin Liška wrote:
> On 1/11/22 16:48, Toon Moene wrote:
> > On 1/11/22 13:56, Martin Liška wrote:
> >
> > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> > > Plus it survives build of all FEs (--enable-languages=all) on
> > >
On Tue, Jan 11, 2022 at 05:03:34PM +0100, Martin Liška wrote:
> On 1/11/22 16:56, Jakub Jelinek wrote:
> > While e.g. libcpp or gcc are in C++.
>
> Which means I should rename .c files under libcpp, right?
> Is there any other folder from gcc/ and libcpp/ that would need that a
On Tue, Jan 11, 2022 at 06:23:51PM +, Jonathan Wakely via Gcc-patches wrote:
> > Regarding fortran: can we have a vote on this one?
> >
> > Some developers (including myself) are not really familiar with C++,
> > and in the past preference has been expressed on the fortran ML in
> > favor of no
On Tue, Jan 11, 2022 at 10:44:56PM +0100, Thomas Koenig wrote:
> > > So... time to merge the branch into trunk before stage 4
> > > kicks in?
> >
> > IMHO yes. We need to git merge master; git rebase of course
> > before trying to cherry-pick those commits into trunk and pushing there.
>
> I wou
1 - 100 of 364 matches
Mail list logo
