Hi Jerry, all!
Just a quick comment for that area.
On Thu, 25 Apr 2024 20:00:24 -0700
Jerry D wrote:
> Hi posted some thoughts on the subject at our mattermost workspace.
>
> This particular PR caught my attention because I have done things like
> this before. I am looking forward to gcc15. I
On Wed, 28 Feb 2024 21:29:06 -0800
Jerry D wrote:
> The attached patch adds the error checks similar to the first patch
> previously committed.
>
> I noticed a redundancy in some defines MSGLEN and IOMSG_LEN so I
> consolidated this to one define in io.h. This is just cleanup stuff.
>
> I hav
nges do not regress but
behave as intended. I did check that the memory leak in
gfc_find_derived_vtab is fixed with the patch.
Ok for stage 1 if the rebased regression test passes?
thanks
>
> Am 17.11.21 um 09:12 schrieb Bernhard Reutner-Fischer via Gcc-patches:
> > On Tue, 16
On Wed, 10 Jan 2024 23:24:22 +0100
Harald Anlauf wrote:
> diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
> index 82f388c05f8..88502c1e3f0 100644
> --- a/gcc/fortran/gfortran.h
> +++ b/gcc/fortran/gfortran.h
> @@ -2926,6 +2926,10 @@ gfc_dt;
> typedef struct gfc_forall_iterator
> {
[CCing Ian as libgcc maintainer]
On Wed, 1 Nov 2023 10:14:37 +
"Zhu, Lipeng" wrote:
> > >
> > > Hi Lipeng,
> > >
> > > >>> Sure, as your comments, in the patch V6, I added 3 test cases with
> > > >>> OpenMP to test different cases in concurrency respectively:
> > > >>> 1. find and create u
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
d to add one
level of quotes -- sorry for that.
>
> On Jun 19, 2023, Bernhard Reutner-Fischer wrote:
>
> > I don't see explicit tests with _Complex nor __complex__. Would we
> > want to check these here, or are they handled thought the "underlying"
> > t
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?
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_arr
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
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
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
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
he list. A second step would
be RELEASE.
And, depending on the underlying capabilities of available locks,
further tweaks, obviously.
PS: and, please, don't top-post
thanks,
>
> Best Regards,
> Zhu, Lipeng
>
> On 1/1/1970 8:00 AM, Bernhard Reutner-Fischer wrote:
> > O
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;
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
Bernhard Reutner-Fischer wrote:
> 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:
>
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
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)
>
>> Did
d be obvious that we
should not leak these.
>
>On 4/2/23 17:05, Bernhard Reutner-Fischer via Gcc-patches wrote:
>> From: Bernhard Reutner-Fischer
>>
>> Cc: fortran@gcc.gnu.org
>>
>> gcc/fortran/ChangeLog:
>>
>> * array.cc (gfc_ref_d
21.html
thanks,
On Sun, 7 Nov 2021 02:38:21 +0100
Bernhard Reutner-Fischer wrote:
> On Sat, 6 Nov 2021 20:22:53 +0100
> Harald Anlauf wrote:
>
> > Hi Bernhard,
> >
> > I cannot comment on the gcc/ parts, but
> >
>
> > > diff --git a/g
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
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): Ditt
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
(wh
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
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 n
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 sp
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
100644
index 000..e0b7212a1bb
--- /dev/null
+++ b/gcc/gimple-warn-types.cc
@@ -0,0 +1,441 @@
+/* Pass to detect and issue warnings about possibly using narrower types.
+
+ Copyright (C) 2021-2022 Free Software Foundation, Inc.
+ Contributed by Bernhard Reutner-Fischer
+
+ This file is
:55:1: warning: Function ‘i64c’ could return ‘unsigned char’
[-Wtype-demotion]
55 | int i64c(int i)
| ^~~
| unsigned char
return-narrow.cc:55:1: note: with a range of [46,122]
So, any help wrt the template case? -- many TIA!
Bernhard Reutner-Fischer (5):
c: Set the locus of the funct
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
\nbummer\n#endif" \
| ./xgcc -B. -x f95-cpp-input -ffree-form -E -dD - | grep -i x86
$ # nothing
versus
$ echo -e "#ifndef __x86_64__\nbummer\n#endif" \
| ./xgcc -B. -x assembler-with-cpp -E -dD - | grep -i x86
#define __x86_64 1
#define __x86_64__ 1
I'm sure we have exis
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
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
>
> ```
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,
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
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/gc
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!
>
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
>
1 - 100 of 179 matches
Mail list logo
