On 22 September 2023 21:16:35 CEST, Harald Anlauf via Fortran
wrote:
>Dear all,
>
>the attached simple and obvious patch fixes several NULL pointer
>dereferences that are encountered for a duplicate declaration of
>a class variable. Another one from Gerhard's torture tests...
Obviously ok.
than
On Tue, 5 Sep 2023 12:28:28 -0700
Julian Brown wrote:
> + static bool
> + equal (const omp_name_type &a,
> + const omp_name_type &b)
> + {
> +if (a.name == NULL_TREE && b.name == NULL_TREE)
> + return a.type == b.type;
I'm curious if (and why) the type comparison above is safe a
On Wed, 21 Jun 2023 22:08:55 -0300
Alexandre Oliva wrote:
> Thanks for the test.
>
> Did you mean for me to incorporate it into the patch, or do you mean to
> contribute it separately, if the feature happens to be accepted?
These were your tests that i quoted but i or my MUA botched to add one
Hi!
First of all, many thanks for the patch!
If i may, i have a question concerning the chosen style in the error
message and one nitpick concerning a return type though, the latter
primarily prompting this reply.
On Tue, 20 Jun 2023 11:54:25 +0100
Paul Richard Thomas via Fortran wrote:
> diff
On 16 June 2023 07:35:27 CEST, Alexandre Oliva via Gcc-patches
wrote:
index 0..634feaed4deef
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/hardbool-err.c
@@ -0,0 +1,28 @@
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+typedef _Bool __attribute__ ((__hardbool__))
+hbbl; /* { dg-error
On 14 June 2023 11:40:06 CEST, Mikael Morin wrote:
>> What do you prefer? "not affiliated" or
>> "private", ...?
>>
>Yes, that's fine. Nothing. Whatever.
IMHO that usually would be not applicable / n/a
On 1 June 2023 11:18:08 CEST, Andre Vehreschild via Fortran
wrote:
>Hi Damian, all,
>
>thank you for your input. I have incorporated most of it. Due to Germany
>stepping out of nuclear use, I have reduced the cites on these to a minimum. I
>don't know anything about the people evaluating the prop
On 26 May 2023 06:34:52 CEST, Jerry DeLisle via Fortran
wrote:
>Maybe we can get someone to push forward on te native coarrays work?
It would be nice if someone could streamline the locking therein, as said.
On Thu, 18 May 2023 21:20:41 +0200
Mikael Morin wrote:
> Le 18/05/2023 à 17:18, Bernhard Reutner-Fischer a écrit :
> > I've fed gfortran.h into the script and found some CLASS_DATA spots,
> > see attached bootstrapped and tested patch.
> > Do we want to have that?
> Some of it makes sense, but
On Sun, 14 May 2023 14:27:42 +0200
Mikael Morin wrote:
> Le 10/05/2023 à 18:47, Bernhard Reutner-Fischer via Fortran a écrit :
> > From: Bernhard Reutner-Fischer
> >
> > gcc/fortran/ChangeLog:
> >
> > PR fortran/78798
> > * array.cc (co
On Sun, 14 May 2023 15:10:12 +0200
Mikael Morin wrote:
> Le 14/05/2023 à 01:23, Bernhard Reutner-Fischer via Gcc-patches a écrit :
> > From: Bernhard Reutner-Fischer
> >
> > gcc/fortran/ChangeLog:
> >
> > * trans-array.cc (is_pointer_array): Use _P() defines from tree.h.
> > (gfc_conv_
On Sun, 14 May 2023 15:04:15 +0200
Thomas Koenig wrote:
> On 14.05.23 14:27, Mikael Morin wrote:
> >
> > (...)
> >> @@ -2098,7 +2098,7 @@ ref_same_as_full_array (gfc_ref *full_ref,
> >> gfc_ref *ref)
> >> there is some kind of overlap.
> >> 0 : array references are identical o
On Mon, 27 Jun 2022 14:10:36 +0800
Xi Ruoyao wrote:
> fgrep has been deprecated in favor of grep -F for a long time, and the
> next grep release (3.8 or 4.0) will print a warning of fgrep is used.
> Stop using fgrep so we won't see the warning.
>
> We can't hard code grep -F here or it may break
[re-adding the lists, i hope you don't mind]
On Wed, 10 May 2023 18:52:54 +0200
Thomas Koenig wrote:
> Hi Bernhard,
>
> both patches look good to me.
Pushed as r14-664-g39f7c0963a9c00 and r14-665-gbdc10c2bfaceb3
Thanks!
>
> No user impact, so they should have the lowest possible impact :-)
>
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
PR fortran/109624
* dump-parse-tree.cc (debug): New function for gfc_namespace.
(gfc_debug_code): Delete forward declaration.
(show_attr): Make sure to print balanced braces.
---
(gdb) call debug(gfc_current_n
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
* dump-parse-tree.cc (gfc_debug_expr): Remove forward declaration.
(debug): Add DEBUG_FUNCTION.
(show_code_node): Remove erroneous whitespace.
---
Regression tested on x86_64-linux, OK for trunk?
---
gcc/fortran/dump
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
PR fortran/78798
* array.cc (compare_bounds): Use narrower return type.
(gfc_compare_array_spec): Likewise.
(is_constant_element): Likewise.
(gfc_constant_ac): Likewise.
* check.cc (dim_rank_che
On Mon, 8 May 2023 17:44:43 +0800
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 func
On Wed, 1 Mar 2023 16:07:14 -0800
Steve Kargl wrote:
> On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via
> Fortran wrote:
> > libgfortran/caf/single.c |6 ++
> > libgfortran/io/async.c |6 ++
> > libgfortran
On Mon, 17 Apr 2023 15:18:27 -0700
Steve Kargl wrote:
> On Mon, Apr 17, 2023 at 09:47:50PM +0200, Bernhard Reutner-Fischer via
> Fortran wrote:
> > On Mon, 03 Apr 2023 23:42:06 +0200
> > Bernhard Reutner-Fischer wrote:
> >
> > > On 3 April 2023 21
On 28 April 2023 09:26:06 CEST, Tobias Burnus wrote:
>Committed as r14-319-g7ebd4a1d61993c0a75e9ff3098aded21ef04a4da
> Only other changes are fixing the variable name a(b)breviated_modproc_decl
I think this is not good, I've mentioned it somewhere, i think, but I'll rename
it.
thanks!
On 28 April 2023 11:23:55 CEST, Florian Weimer via Fortran
wrote:
>* Martin Liška:
>But that's okay for me as well.
Even better.
On 26 April 2023 20:31:10 CEST, Florian Weimer via Fortran
wrote:
>* Martin Liška:
>
>> On 11/15/22 16:47, Martin Liška wrote:
>>> Hi.
>>>
>>> I've just pushed libsanitizer update that was tested on x86_64-linux and
>>> ppc64le-linux systems.
>>> Moreover, I run bootstrap on x86_64-linux and ch
Hi!
[please do not top-post]
On Thu, 20 Apr 2023 21:13:08 +0800
"Zhu, Lipeng" wrote:
> Hi Bernhard,
>
> Thanks for your questions and suggestions.
> The rwlock could allow multiple threads to have concurrent read-only
> access to the cache/unit list, only a single writer is allowed.
right.
Cc:ing Thomas, who knows openacc better.
There is a devel/omp/gcc-12 branch you might want to try. I don't know
how different that branch is wrt openacc.
HTH,
On Mon, 24 Apr 2023 19:39:15
+0200 Patrick Begou via Fortran wrote:
> Hi Harald
>
> as I said, it is a large, massively parallel fortr
On Sun, 23 Apr 2023 23:48:03 +0200
Harald Anlauf via Fortran wrote:
> Am 22.04.23 um 10:32 schrieb Paul Richard Thomas via Gcc-patches:
> > PR103931 - I couldn't reproduce the bug, which involves 'ambiguous c_ptr'.
> > To judge by the comments, it seems that this bug is a bit elusive.
See Haral
On 19 April 2023 09:06:28 CEST, Lipeng Zhu via Fortran
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
On Wed, 19 Apr 2023 at 03:03, Jerry D via Fortran wrote:
>
> On 4/18/23 12:39 PM, Harald Anlauf via Fortran wrote:
> > Dear all,
> >
> > the attached patch adjusts the scan-tree-dump patterns of the
> > reported testcases which likely were run in a location such
> > that a path in an error message
On Wed, 19 Apr 2023 at 14:51, Bernhard Reutner-Fischer
wrote:
>
> On 19 April 2023 09:06:28 CEST, Lipeng Zhu via Fortran
> wrote:
>
> >+#ifdef __GTHREAD_RWLOCK_INIT
> >+#define RWLOCK_DEBUG_ADD(rwlock) do { \
> >+aio_rwlock_debug *n; \
> >+n = malloc
On 19 April 2023 09:06:28 CEST, Lipeng Zhu via Fortran
wrote:
>+#ifdef __GTHREAD_RWLOCK_INIT
>+#define RWLOCK_DEBUG_ADD(rwlock) do { \
>+aio_rwlock_debug *n; \
>+n = malloc (sizeof(aio_rwlock_debug));\
My malloc can fail.
>+n->prev = TAIL_RW
Ping!
Harald fixed the leak in set_exponent in the meantime.
As stated in the cover-letter, it was bootstrapped and regtested
without regression on x86_64-foo-linux.
I consider it obvious, but never the less, OK for trunk (as in gcc-14)
so far?
thanks,
On Mon, 03 Apr 2023 23:42:06 +0200
Bernhar
fyi
Begin forwarded message:
Date: Mon, 17 Apr 2023 15:56:29 +0200
From: Jakub Jelinek via Gcc-patches
To: g...@gcc.gnu.org, gcc-patc...@gcc.gnu.org
Subject: GCC 14.0.0 Status Report (2023-04-17)
Status
==
The trunk has branched for the GCC 13 release and is now open
again for general dev
fyi
Begin forwarded message:
Date: Mon, 17 Apr 2023 15:54:45 +0200
From: Jakub Jelinek via Gcc-patches
To: g...@gcc.gnu.org, gcc-patc...@gcc.gnu.org
Subject: GCC 13.0.1 Status Report (2023-04-17)
Status
==
We have reached zero P1 regressions today and releases/gcc-13 branch has
been creat
Hi all, Janne!
On Wed, 19 Sep 2018 16:40:01 +0200
Bernhard Reutner-Fischer wrote:
> On Fri, 7 Sep 2018 at 10:07, Bernhard Reutner-Fischer
> wrote:
> >
> > On Wed, 5 Sep 2018 at 20:57, Janne Blomqvist
> > wrote:
> > >
> > > On Wed, Sep 5, 2018 at 5:58 PM Bernhard Reutner-Fischer
> > > wrote
On 6 April 2023 08:11:11 CEST, Alexandre Oliva wrote:
>On Apr 2, 2023, Bernhard Reutner-Fischer wrote:
>
>> On Tue, 09 Aug 2022 10:53:08 -0300
>> Alexandre Oliva via Gcc-patches wrote:
>
>>> Ping? (sorry, Joseph, I failed to Cc: you last time)
>
>> Didn't move yet did it.
>
>'fraid not, and sur
On 3 April 2023 21:50:49 CEST, Harald Anlauf wrote:
>Hi Bernhard,
>
>there is neither context nor a related PR with a testcase showing
>that this patch fixes issues seen there.
Yes, i forgot to mention the PR:
PR fortran/68800
I did not construct individual test cases but it should be obvious t
ping?
libcpp maintainers, is the helper in incpath.* ok?
fortraners,
Do you prefer a rogue, local forward declaration, or is the
introduction of that trivial wrapper ok? I don't think pulling in cpp.h
from f95-lang.cc is desirable, but i can do that if you all think
that's preferred.
cover-lette
From: Bernhard Reutner-Fischer
Cc: fortran@gcc.gnu.org
gcc/fortran/ChangeLog:
* array.cc (gfc_ref_dimen_size): Free mpz memory before ICEing.
* expr.cc (find_array_section): Fix mpz memory leak.
* simplify.cc (gfc_simplify_reshape): Fix mpz memory leaks in
error
On 7 March 2023 23:18:58 CET, Roland Hughes via Fortran
wrote:
[ snip namelist IO ]
>Btw, is there a "search" utility for the archives or do I have to pull down
>all of the zip files, unzip into directory, and grep to look for stuff like
>this? I'm guessing it has come up before.
Indeed we h
On 2 March 2023 02:23:10 CET, Jerry D wrote:
>On 3/1/23 4:07 PM, Steve Kargl via Fortran wrote:
>> On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via
>> Fortran wrote:
>>> libgfortran/caf/single.c |6 ++
>>> li
On Wed, 1 Mar 2023 07:39:40 -0800
Steve Kargl via Gcc-patches wrote:
> In fact, Hollerith should be hidden behind a -fallow-hollerith
> option and added to -std=legacy.
While i'd be all for that, in my mind this will block off literally all
consultants and quite some scientists unless we error o
On Wed, 1 Mar 2023 10:40:15 +0100
Tobias Burnus wrote:
> Hi,
>
> Please CC fortran@gcc for Fortran patches.
> > --- a/gcc/fortran/target-memory.cc
> > +++ b/gcc/fortran/target-memory.cc
> > @@ -417,10 +417,13 @@ gfc_interpret_float (int kind, unsigned char *buffer,
> > size_t buffer_size,
> >
On Wed, 1 Mar 2023 14:59:44 -0800
Andrew Pinski wrote:
> On Wed, Mar 1, 2023 at 1:31 PM Bernhard Reutner-Fischer via Fortran
> wrote:
> >
> > Hi!
> >
> > Mere cosmetics.
> >
> > - if (foo != NULL)
> > free (foo);
> >
> > With th
On Wed, 1 Mar 2023 22:28:56 +0100
Bernhard Reutner-Fischer wrote:
> Remarks:
> 1) We should do this in if-conversion (?) on our own.
>I suppose. Independently of -fdelete-null-pointer-checks
and iff we can prove that ptr was NULL when passed to free(ptr) then we
can elide the call, of course
Hi!
Mere cosmetics.
- if (foo != NULL)
free (foo);
With the caveat that coccinelle ruins replacement whitespace or i'm
uneducated enough to be unable to _not_ run the diff through
sed -e 's/^+\([[:space:]]*\)free(/+\1free (/'
at least. If anybody knows how to improve replacement whitespace,
On Sun, 31 Oct 2021 21:25:44 +0100
Bernhard Reutner-Fischer wrote:
> On Sun, 31 Oct 2021 20:46:07 +0100
> Harald Anlauf wrote:
>
> > Am 30.10.21 um 23:51 schrieb Bernhard Reutner-Fischer via Fortran:
> > >>> The only caller is translate_all_program_units.
>
Hi Rimvydas!
On Sat, 18 Feb 2023 21:35:47 +0100
Bernhard Reutner-Fischer wrote:
> On Fri, 10 Feb 2023 07:42:47 +0200
> Rimvydas Jasinskas via Fortran wrote:
>
> > * decl.cc: Add EXT_ATTR_NOINLINE, EXT_ATTR_NORETURN, EXT_ATTR_WEAK.
> > * gfortran.h (ext_attr_id_t): Ditto.
>
> We had that dis
On Sun, 19 Feb 2023 03:29:43 +0100
Bernhard Reutner-Fischer wrote:
> But i've seen in C++ too that there are GC dangles like here.
s/like here//;# not true in this case. Those were GC marks for names
elsewhere.
To be fair, i'd have made lhd_overwrite_decl_assembler_name a
(where supported) weakr
On Tue, 22 Nov 2022 12:54:01 +0100
Jan Hubicka wrote:
> > > I am not quite sure how safe this is. We generally produce DECL_RTL
> > > when we produce assembly file. So if DECL_RTL is set then we probably
> > > already output the original function name and it is too late to change
> > > it.
>
On 19 January 2023 20:03:38 CET, NightStrike wrote:
>The problem is that patch tracking is unsustainable. You could go the other
>way and have a patch tracker automatically echo messages to the mailing
>list.
Currently it's the other way round. Patchwork collects the patches sent to the
list. E
On 19 January 2023 20:39:08 CET, Jason Merrill wrote:
>On Sat, Nov 12, 2022 at 4:24 PM Harald Anlauf via Gcc-patches
> wrote:
>>
>> Am 12.11.22 um 22:05 schrieb Bernhard Reutner-Fischer via Gcc-patches:
>> > This function definition was removed years ago, remove it's prototype.
>> >
>> > gcc/fortr
On 19 January 2023 13:52:55 CET, NightStrike via Fortran
wrote:
>You can, and people naturally do this, and I think it's great, but
>there's usually a response from someone saying "post that to the
>mailing list instead".
The mailing list has a 20-30 year history with reasoning about what curre
On Mon, 21 Nov 2022 20:13:40 +0100
Mikael Morin wrote:
> Hello,
>
> Le 09/11/2022 à 20:02, Bernhard Reutner-Fischer via Fortran a écrit :
> > Hi!
> >
> > Add support for attribute target_clones:
> > !GCC$ ATTRIBUTES target_clones("arch1", "arc
On Mon, 21 Nov 2022 12:08:20 +0100
Mikael Morin wrote:
> > * gfortran.h (struct ext_attr_t): Remove middle_end_name.
> > * trans-decl.cc (add_attributes_to_decl): Move building
> > tree_list to ...
> > * decl.cc (gfc_match_gcc_attributes): ... here. Add the attribute to
> > th
On Mon, 21 Nov 2022 12:24:11 +0100
Mikael Morin wrote:
> > --- a/gcc/fortran/decl.cc
> > +++ b/gcc/fortran/decl.cc
> (...)
> > @@ -11849,7 +11850,9 @@ gfc_match_gcc_attributes (void)
> > if (strcmp (name, ext_attr_list[id].name) == 0)
> > break;
> >
> > - if (id == EXT_ATTR_LA
On Mon, 21 Nov 2022 20:02:49 +0100
Jan Hubicka wrote:
> > Hi Honza, Ping.
> > Regtests cleanly for c,fortran,c++,ada,d,go,lto,objc,obj-c++
> > Ok?
> > I'd need this for attribute target_clones for the Fortran FE.
> Sorry for delay here.
> > > void
> > > @@ -303,6 +301,10 @@ symbol_table::chang
Hi Honza, Ping.
Regtests cleanly for c,fortran,c++,ada,d,go,lto,objc,obj-c++
Ok?
I'd need this for attribute target_clones for the Fortran FE.
thanks,
On Wed, 9 Nov 2022 20:02:24 +0100
Bernhard Reutner-Fischer wrote:
> We were changing the ASSEMBLER_NAME of the function decl
> but not the name
yearly ping. Ok for trunk after re-regtesting?
thanks,
On Sun, 31 Oct 2021 13:57:46 +0100
Bernhard Reutner-Fischer wrote:
> From: Bernhard Reutner-Fischer
>
> gcc/fortran/ChangeLog:
>
> PR fortran/99884
> * io.c (check_open_constraints): Remove double spaces.
> ---
> gcc/fortran
On 13 November 2022 21:29:50 CET, Harald Anlauf wrote:
>Replacing "int" by "signed char" adds confusion and makes code
>less understandable, so I would oppose it, as we don't solve a
>real problem and rather add confusion.
Ok so consider the non-bool hunks dropped, they just fell out of my helpe
On Sun, 13 Nov 2022 12:13:26 +0200
Janne Blomqvist wrote:
> On Sun, Nov 13, 2022 at 1:47 AM Bernhard Reutner-Fischer via Fortran
> wrote:
> > --- a/gcc/fortran/arith.cc
> > +++ b/gcc/fortran/arith.cc
> > @@ -1135,7 +1135,7 @@ compare_complex (gfc_expr *op1, gfc_expr *o
gcc/ChangeLog:
* value-range.cc (get_bound_with_infinite_markers): New static helper.
(irange::as_string): New definition.
* value-range.h: New declaration.
---
Provide means to print a value range to a newly allocated buffer.
The caller is responsible to free() the alloca
gcc/fortran/ChangeLog:
* arith.cc (compare_complex): Use narrower return type.
(gfc_compare_string): Likewise.
* arith.h (gfc_compare_string): Same.
(gfc_compare_with_Cstring): Ditto.
* array.cc (compare_bounds): Ditto.
(gfc_compare_array_spec): Like
gcc/ChangeLog:
* Makefile.in (OBJS): Add gimple-warn-types.o.
* passes.def: Add pass_warn_type_demotion.
* tree-pass.h (make_pass_warn_type_demotion): New declaration.
* gimple-warn-types.cc: New file.
gcc/c-family/ChangeLog:
* c.opt (Wtype-demotion): New.
Hi!
The location of function result declarations was not set.
The first two patches set the location of normal functions in C and C++.
Jason, Nathan, I failed to support C++ template functions, see below.
TL;DR.
Why all this?
PR78798 noted that we should use narrower function return types if fea
Bootstrapped and regtested on x86_86-unknown-linux with no regressions.
Ok for trunk?
Cc: Joseph Myers
---
gcc/c/ChangeLog:
* c-decl.cc (start_function): Set the result decl source
location to the location of the typespec.
---
gcc/c/c-decl.cc | 6 +-
1 file changed, 5 insert
gcc/cp/ChangeLog:
* decl.cc (start_function): Set the result decl source location to
the location of the typespec.
---
Bootstrapped and regtested on x86_86-unknown-linux with no regressions.
Ok for trunk?
Cc: Nathan Sidwell
Cc: Jason Merrill
---
gcc/cp/decl.cc | 15 +++
This function definition was removed years ago, remove it's prototype.
gcc/fortran/ChangeLog:
* gfortran.h (gfc_check_include): Remove declaration.
---
gcc/fortran/gfortran.h | 1 -
1 file changed, 1 deletion(-)
---
Regtests cleanly, ok for trunk?
diff --git a/gcc/fortran/gfortran.h b/g
Hi!
On Mon, 07 Nov 2022 11:04:17 +
Dave Love via Fortran wrote:
> Bernhard Reutner-Fischer via Fortran writes:
>
> > I see.
> > So target_clones is one thing. What other attributes would be important?
>
> At least optimization-related ones could be useful,
Bootstrapped and regtested cleanly on x86_unknown-linux.
The document bits will be rewritten for rst.
Ok for trunk if the prerequisite target_clones patch is approved?
gcc/fortran/ChangeLog:
* decl.cc (gfc_match_gcc_attributes): Handle flatten.
* f95-lang.cc (gfc_attribute_table):
Tiny cleanup opportunity since we now have ext_attr_args in
struct symbol_attribute.
Bootstrapped and regtested on x86_64-unknown-linux with no new
regressions.
Ok for trunk if the prerequisite was approved ([PATCH 2/2] Fortran: add
attribute target_clones) ?
gcc/fortran/ChangeLog:
* gfor
Hi!
I could imagine that the flatten attribute might be useful.
Do we want to add support for it for gcc-13?
Bernhard Reutner-Fischer (2):
Fortran: Cleanup struct ext_attr_t
Fortran: Add attribute flatten
gcc/fortran/decl.cc | 41 +---
gcc/fortran/f9
Hi!
These two patches add support for attribute target_clones to the fortran
frontend.
1) The symtab hunk is identical to the one sent in
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605081.html
which had some additional information.
I only tested it on x86_64-unknown-linux and for
lan
We were changing the ASSEMBLER_NAME of the function decl
but not the name in DECL_RTL which is used as the function name
fnname in rest_of_handle_final(). This led to using the old, wrong name
for the attribute target default function when using target_clones.
Bootstrapped and regtested cleanly on
Hi!
Add support for attribute target_clones:
!GCC$ ATTRIBUTES target_clones("arch1", "arch3","default") :: mysubroutine
Bootstrapped and regtested on x86_64-unknown-linux with
--target_board=unix'{-m32,-m64}'.
OK for trunk?
gcc/fortran/ChangeLog:
* decl.cc: Include fold-const.h for size
On Sat, 5 Nov 2022 23:28:47 +0100
Tobias Burnus wrote:
[no comment. I wonder why we malloc versus realloc in the first place,
i'd realloc always for starters. We end up calling into libc anyway, we
don't inline any of those calls and we suffer lib-boundary non-IPA
trouble either way, still, no? S
On Sat, 5 Nov 2022 08:40:06 +0100
Thomas Koenig wrote:
> On 04.11.22 21:59, Bernhard Reutner-Fischer via Fortran wrote:
> > And not sure if fellow gfortraners would accept this attribute
> > target_clones in there in the first place..
>
> It might actually be useful.
On Thu, 3 Nov 2022 00:19:26 +0100
Bernhard Reutner-Fischer wrote:
> So target_clones is one thing. What other attributes would be important?
> > doing something previously! (I don't know if I'll actually be able to
> > work on it in the end, at least on work time.)
>
> heh, me neither. Lucki
On Mon, 31 Oct 2022 21:19:18 +
Dave Love via Fortran wrote:
> Bernhard Reutner-Fischer via Fortran writes:
> > Ideally the syntax would be the same as in C.
>
> Right. I hoped it would be possible to lift machinery easily from C.
Lifting that won't work easil
On Fri, 28 Oct 2022 15:35:45 +0100
Dave Love via Fortran wrote:
> Assuming there's no technical reason not to, can someone say what would
> be involved in adding relevant attributes (at least function ones) like
> those for C? I'm thinking particularly of target_clones, but others
> probably mak
On 4 October 2022 10:06:00 CEST, LIU Hao wrote:
>在 2022-10-03 13:03, Bernhard Reutner-Fischer 写道:
>>
>> No, sorry for my brevity.
>> Using __gthread_t like in your patch is correct.
>>
>
>I see. In 'libgfortran/io/async.c' there is
>
> ```
>async_unit *au = u->au;
>LOCK (&au->lock);
>
On 2 October 2022 14:54:54 CEST, LIU Hao wrote:
>在 2022-10-02 04:02, Bernhard Reutner-Fischer 写道:
>> On 1 October 2022 20:34:45 CEST, LIU Hao via Gcc-patches
>> wrote:
>>> Greetings.
>>
>>> The first patch is necessary because somewhere in libgfortran, `pthread_t`
>>> is referenced. If the thr
On 1 October 2022 20:34:45 CEST, LIU Hao via Gcc-patches
wrote:
>Greetings.
>The first patch is necessary because somewhere in libgfortran, `pthread_t` is
>referenced. If the thread model is not `posix`, it fails to compile.
One of several shortcomings mentioned already on Sun, 02 Sep 2018 15:
On 17 September 2022 21:50:20 CEST, Mikael Morin wrote:
>Le 17/09/2022 à 21:33, Mikael Morin a écrit :
>> The testcase from the patch was not specifically checking lack of
>> side-effect clobbers, so I have double-checked with the following testcase,
>> which should lift your concerns.
>>
>The
On 17 September 2022 21:33:22 CEST, Mikael Morin wrote:
>Le 17/09/2022 à 19:03, Thomas Koenig via Fortran a écrit :
>>
>> Hi Mikael,
>>
>>> This adds support for clobbering of partial variable references, when
>>> they are passed as actual argument and the associated dummy has the
>>> INTENT(OUT
On 2 September 2022 17:54:00 CEST, FX wrote:
>Hi Bernhard,
>
>> Please do not call the non-standard abort, but use stop N.
>
>Is there a specific reason? It’s a well-documented GNU extension, and it’s
>useful because it can easily display a backtrace and give line info for the
>failure, unlike S
On 2 September 2022 13:37:41 CEST, FX via Fortran wrote:
>Hi,
Please do not call the non-standard abort, but use stop N.
IIRC I once had a trivial script..
https://www.mail-archive.com/search?l=gcc-patc...@gcc.gnu.org&q=subject:%22%5C%5BPATCH%2C+OpenACC%5C%5D+Fortran+deviceptr%22&o=newest&f=1
On 31 August 2022 20:29:12 CEST, FX via Fortran wrote:
+ case GFC_FPE_GFC_FPE_AWAY:
typo?
thanks,
On 2 July 2022 14:47:01 CEST, Mikael Morin wrote:
>Le 02/07/2022 à 13:18, Thomas Koenig a écrit :
>>
>> One thought: If we have to bite the bullet and break the ABI, why not go
>> all the way and use the C descriptors in ISO_Fortran_binding.h as
>> gfortran's native format?
>>
>As far as I know,
On 24 June 2022 14:35:20 CEST, Rainer Orth
wrote:
>Hi Xi,
>
>> On Fri, 2022-06-24 at 13:13 +0200, Bernhard Reutner-Fischer wrote:
>>
>>> > - if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v
>>> > -i debian' >/dev/null 2>&1; then \
>>> > + if $(SHELL) -c 'install-info --ve
On Fri, 24 Jun 2022 15:06:32 +0800
Xi Ruoyao via Gcc-patches wrote:
> fgrep has been deprecated in favor of grep -F for a long time, and the
> next grep release (3.8 or 4.0) will print a warning of fgrep is used.
> Stop using fgrep so we won't see the warning.
>
> gcc/ChangeLog:
>
> * for
On 17 June 2022 21:55:47 CEST, Jakub Jelinek wrote:
>On Fri, Jun 17, 2022 at 08:45:04PM +0200, Bernhard Reutner-Fischer via Gcc
>wrote:
>> PS: we should rm
>> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=contrib/gcc_build
>
>No. gcc_build is used by maintainer-scripts/gcc_release, so by killing
On 13 June 2022 17:26:59 CEST, Jonathan Wakely via Fortran
wrote:
>https://gist.github.com/jwakely/95b3a790157f55d75e18f577e12b50d7#file-build_gcc_versions-sh
s/[[/[/
s/==/=/
The former are deprecated or obsolescent notations of test(1) syntax, fwiw.
PS: we should rm https://gcc.gnu.org/git/?
On Fri, 29 Apr 2022 20:03:55 +0200
Thomas Koenig wrote:
> On 28.04.22 19:17, Bernhard Reutner-Fischer wrote:
> > ISTM that this should be s/mod.e/mode./ ?
>
> Yep, fixed as obvious and simple on trunk with
> r13-49-g4a8b45e8bc8246bd141dad65f571a3e0cc499c6b .
thanks!
>
> OK for backport to gc
Hi Thomas,
On 27 April 2022 22:34:39 CEST, Thomas Koenig via Fortran
wrote:
+@item @code{'big_endian'} Do all unformatted I/O in big_endian mod.e
ISTM that this should be s/mod.e/mode./ ?
thanks,
On 25 April 2022 14:12:30 CEST, Jakub Jelinek via Fortran
wrote:
>On Mon, Apr 25, 2022 at 01:38:25PM +0200, Mikael Morin wrote:
>> I have just pushed the attached fix for two UNRESOLVED checks at -O0 that I
>> hadn’t seen.
>
>I don't like forcing of DSE in -O0 compilation, wouldn't it be better
>
On Wed, 12 Jan 2022 16:54:46 +0100
Martin Liška wrote:
> +def replace_file_in_changelog(lines, filename):
> +if not filename.endswith('.cc'):
> +return
> +
> +# consider all componenets of a path: gcc/ipa-icf.cc
> +while filename:
> +for i, line in enumerate(lines):
>
On Mon, 22 Nov 2021 19:17:51 +0100
Harald Anlauf via Gcc-patches wrote:
> Am 21.11.21 um 12:46 schrieb Mikael Morin:
> > Le 19/11/2021 à 20:47, Harald Anlauf via Fortran a écrit :
> >> Dear Fortranners,
> >>
> >> scalariziation of the elemental intrinsic LEN_TRIM was ICEing
> >> when the option
hole point was ...
>
> Am 21.11.21 um 01:22 schrieb Bernhard Reutner-Fischer via Fortran:
> > Roger pinged this on gcc-patches some time ago fwiw.
> > [The commit-hooks will likely fix or ignore s/bext/next/ in his
> > mail-addr]
> >
> >
> > On Sun, 14
Roger pinged this on gcc-patches some time ago fwiw.
[The commit-hooks will likely fix or ignore s/bext/next/ in his
mail-addr]
On Sun, 14 Jun 2020 23:39:32 +0100
"Roger Sayle" wrote:
>
>
> The following patch to gfortran's trans-instrinsic.c tweaks the generic that
> is produced
>
> for po
x memory leaks.
>
> PR88009 is closed and seems to have nothing to do with this.
Well it marked only _final as artificial and forgot to adjust the
others as well.
We can remove the reference to PR88009 if you prefer?
thanks!
>
> Harald
>
> Am 14.11.21 um 23:17 schrieb Bernhard Reu
1 - 100 of 174 matches
Mail list logo
