On Fri, 29 May 2015 10:44:02 +0200
Bernhard Reutner-Fischer wrote:
> On 29 May 2015 at 10:21, Bernhard Reutner-Fischer
> wrote:
> > On 31 January 2015 at 22:10, Bernhard Reutner-Fischer
> > wrote:
> >> On January 31, 2015 9:17:57 PM GMT+01:00, Mike Stump
> &g
On Wed, 30 Oct 2013 10:41:33 +0100
Bernhard Reutner-Fischer wrote:
> > Hi!
> >
> > I've noticed that this testcase doesn't clean up after itself.
> > Fixed thusly, committed as obvious to trunk.
>
> This was nagging me last weekend.. ;)
> What
On Fri, 2 Feb 2018 14:25:22 +0100
Bernhard Reutner-Fischer wrote:
> On 19 June 2016 at 22:21, Mike Stump wrote:
> > On Jun 18, 2016, at 12:31 PM, Bernhard Reutner-Fischer
> > wrote:
> >>
> >> A branch with a name matching scan-assembler pattern
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 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!
>
On Wed, 4 May 2022 15:31:32 +0200
Martin Liška wrote:
> On 5/4/22 15:10, Alexander Monakov wrote:
> > On Wed, 4 May 2022, Martin Liška wrote:
> >
> >> On 5/4/22 14:32, Alexander Monakov wrote:
> >>> On Wed, 4 May 2022, Martin Liška wrote:
> >>>
> The patch is a follow-up of the discus
Hi Andrew,
On Tue, 17 May 2022 14:38:39 -0400
Andrew MacLeod via Gcc-patches wrote:
> commit b7501739f3b14ac7749aace93f636d021fd607f7
> Author: Andrew MacLeod
> Date: Mon May 9 15:35:14 2022 -0400
> diff --git a/gcc/gimple-range-cache.cc b/gcc/gimple-range-cache.cc
> index d3cf8be9bd8..56f45
On Thu, 19 May 2022 10:52:35 -0400
David Malcolm wrote:
> > In file included from ../../../src/gcc-13.mine/gcc/tree-vrp.h:23,
> > from ../../../src/gcc-13.mine/gcc/ssa.h:28,
> > from ../../../src/gcc-13.mine/gcc/gimple-warn-
> > types.cc:30:
> > ../../../src/gcc-
On 20 May 2022 16:39:20 CEST, Segher Boessenkool
wrote:
>On Fri, May 20, 2022 at 10:11:32AM +0200, Eric Botcazou wrote:
>> > I suggest 'deduce', 'deduction', 'deducing a range'. What the code is
>> > actually doing is deducing that 'b' in 'a / b' cannot be zero. Function in
>> > GCC might be call
On Fri, 24 Sep 2021 17:46:53 +0200
Aldy Hernandez via Gcc-patches wrote:
> p.s. "Did I say 5 weeks? My bad, I meant 5 months."
heh. units (.oO~"xkcd.com/1047/")
> +static unsigned int
> +execute_vrp_threader (function *fun)
> +{
> + hybrid_threader threader;
> + threader.thread_jumps (fun);
eue for testing.
LGTM but cannot approve it.
~hybrid_threader wouldn't want to free_dominance_info() would it?
But you certainly looked for such leaks.
thanks,
>
> Aldy
>
> On Wed, Sep 29, 2021 at 7:43 AM Bernhard Reutner-Fischer
> wrote:
> >
> > Aldy, ping?
>
On Thu, 28 Oct 2021 23:37:59 +0200
Harald Anlauf wrote:
> Hi Bernhard,
>
> Am 27.10.21 um 23:43 schrieb Bernhard Reutner-Fischer via Gcc-patches:
> > ping
> > [I'll rebase and retest this too since it's been a while.
> > Ok if it passes?]
> >
> >
From: Bernhard Reutner-Fischer
Due to a typo a user operator used in a reduction was not found in the
symtree so would have been written multiple times (in theory).
E.g. user operator ".add." was looked up as ".ad" instead of "add".
For gcc-11 branch and earl
From: Bernhard Reutner-Fischer
Introduce a helper to construct a user operator from a name and the
reverse operation, i.e. a helper to construct a name from a user
operator.
Cc: Jakub Jelinek
gcc/fortran/ChangeLog:
2017-10-29 Bernhard Reutner-Fischer
* gfortran.h
On Wed, 27 Oct 2021 23:39:43 +0200
Bernhard Reutner-Fischer wrote:
> Ping
> [hmz. it's been a while, I'll rebase and retest this one.
> Ok if it passes?]
Testing passed without any new regressions.
Ok for trunk?
thanks,
>
> On Mon, 15 Oct 2018 10:23:06 +0200
> Ber
On Wed, 27 Oct 2021 23:29:40 +0200
Bernhard Reutner-Fischer wrote:
> Hi!
>
> I found this lying around in an oldish tree.
> Regtest running over night, ok for trunk if it passes?
Regtest turned up no regressions.
Ok for trunk?
thanks,
>
> Bernhard Reutner-Fischer (1):
&
ping
[Rebased, re-regtested cleanly. Ok for trunk?]
On Wed, 5 Sep 2018 14:57:31 +
Bernhard Reutner-Fischer wrote:
> From: Bernhard Reutner-Fischer
>
> compiling gfortran.dg/typebound_proc_31.f90 leaked the type-bound
> structs:
>
> 56 bytes in 1 blocks are defin
From: Bernhard Reutner-Fischer
Bump required DejaGnu version to 1.5.3 (or later).
Ok for trunk?
gcc/ChangeLog:
* doc/install.texi: Bump required minimum DejaGnu version.
---
gcc/doc/install.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/install.texi b
On Fri, 29 Oct 2021 07:54:21 -0700
Jerry D wrote:
> Looks good and simple. Proceed. Thanks
Committed as 7883a7f07c1ad9c8aaccc5bbd96e0ae1fa230c89
Thanks!
Maybe somebody could eyeball and ACK "Fix memory leak in finalization
wrappers"
https://gcc.gnu.org/pipermail/fortran/2021-October/056838.html
On Fri, 29 Oct 2021 13:13:52 +0200
Jakub Jelinek wrote:
> On Fri, Oct 29, 2021 at 01:52:58AM +0200, Bernhard Reutner-Fischer wrote:
> > From: Bernhard Reutner-Fischer
> >
> > Introduce a helper to construct a user operator from a name and the
> > reverse operation, i
On Thu, 28 Oct 2021 23:03:05 +0200
Harald Anlauf via Fortran wrote:
> Dear Fortranners,
>
> the original fix by Steve was lingering in the PR.
>
> We did ICE in situations where in a SELECT CASE a kind conversion
> was deemed necessary, but it did involve different types.
> The check gfc_conver
ping
On Wed, 5 Sep 2018 14:57:04 +
Bernhard Reutner-Fischer wrote:
> From: Bernhard Reutner-Fischer
>
> Aids debugging the fortran FE.
>
> gcc/ChangeLog:
>
> 2017-11-12 Bernhard Reutner-Fischer
>
> * gdbinit.in: Break on gfc_internal_error.
> --
On Fri, 29 Oct 2021 21:36:26 +0200
Harald Anlauf via Gcc-patches wrote:
> Dear Bernhard, all,
>
> Am 29.10.21 um 02:05 schrieb Bernhard Reutner-Fischer via Gcc-patches:
>
> >> diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c
> >> index 53c760a6c38..cde
On Fri, 29 Oct 2021 19:15:13 +0200
Bernhard Reutner-Fischer wrote:
> > But most importantly, I really don't like these helpers at all, they
> > unnecessarily allocate memory of the remaining duration of compilation,
> > and the second one even uses heap for temporary.
>On 10/29/21 11:58 AM, Bernhard Reutner-Fischer via Fortran wrote:
>> ping
>>
>> On Wed, 5 Sep 2018 14:57:04 +
>> Bernhard Reutner-Fischer wrote:
>>
>>> From: Bernhard Reutner-Fischer
>>>
>>> Aids debugging the fortran
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
PR fortran/99884
* io.c (check_open_constraints): Remove double spaces.
---
gcc/fortran/io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/fortran/io.c b/gcc/fortran/io.c
index fc97df79eca
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
* resolve.c (resolve_fl_procedure): Initialize
allocatable_or_pointer.
---
fortran/resolve.c: In function 'bool resolve_fl_procedure(gfc_symbol*, int)':
fortran/resolve.c:13391:7: warning: 'allocatable_or_
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
PR fortran/100972
* decl.c (gfc_match_implicit_none): Fix typo in warning.
* resolve.c (resolve_unknown_f): Reject external procedures
without explicit EXTERNAL attribute whe IMPLICIT none (external
On Sun, 31 Oct 2021 18:05:36 +0100
Thomas Koenig wrote:
> Hi Bernhard,
>
> > gcc/fortran/ChangeLog:
> >
> > * resolve.c (resolve_fl_procedure): Initialize
> > allocatable_or_pointer.
>
> Looking at the code, it is clear that this is a false
> positive, or a false maybe, but the seman
From: Bernhard Reutner-Fischer
PR fortran/101337
gcc/fortran/ChangeLog:
* resolve.c (resolve_operator): Continue resolving on op2 error.
---
The PR rightfully notes that we only diagnose the right operator
and do not check the left operator if the right one was faulty.
c407b
On Fri, 29 Oct 2021 22:09:07 +0200
Bernhard Reutner-Fischer wrote:
> On Fri, 29 Oct 2021 21:36:26 +0200
> Harald Anlauf via Gcc-patches wrote:
>
> > Dear Bernhard, all,
> >
> > Am 29.10.21 um 02:05 schrieb Bernhard Reutner-Fischer via Gcc-patches:
> >
From: Bernhard Reutner-Fischer
contrib/ChangeLog:
* testsuite-management/validate_failures.py: 2to3
---
Tested with python-3.9.7 where it now works again.
---
.../testsuite-management/validate_failures.py | 38 +--
1 file changed, 19 insertions(+), 19 deletions
On Thu, 28 Oct 2021 01:55:30 +0200
Bernhard Reutner-Fischer wrote:
> On Wed, 27 Oct 2021 20:13:21 +0200
> Aldy Hernandez via Gcc-patches wrote:
> > @@ -1306,6 +1307,24 @@ path_oracle::killing_def (tree ssa)
> >ptr->m_next = m_equiv.m_next;
> &
cle::killing_def
and the mark_elimination is reload.
So it's not just a handful of calls saved but some. And it would be
smaller code as it saves a call. Well maybe another day.
thanks,
>
> Aldy
>
> On Mon, Nov 1, 2021 at 3:10 PM Bernhard Reutner-Fischer
> wrote:
> >
&
On 2 November 2021 14:43:38 CET, Richard Biener
wrote:
>On Mon, Nov 1, 2021 at 10:02 PM Bernhard Reutner-Fischer via
>Gcc-patches wrote:
>>
>> On Mon, 1 Nov 2021 15:21:03 +0100
>> Aldy Hernandez wrote:
>>
>> > I'm not convinced this makes the code
On Wed, 3 Nov 2021 21:00:41 +0100
Harald Anlauf via Fortran wrote:
> *PING*
>
> Am 27.10.21 um 21:09 schrieb Harald Anlauf via Fortran:
> > Dear Fortranners,
> >
> > when debugging the testcase, I noticed that a coarray declaration in
> > a COMMON statement wrongly set the dimension attribute i
From: Bernhard Reutner-Fischer
gcc/ChangeLog:
* incpath.c (free_cpp_dirs): New function.
* incpath.h (free_cpp_dirs): Ditto.
---
This adds a helper to allow the fortran FE to free it's include dirs.
Bootstrapped and regtested without new regressions on x86_64-unknown-linu
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
PR fortran/68800
* cpp.h (gfc_cpp_free_cpp_dirs): New declaration.
* cpp.c (gfc_cpp_free_cpp_dirs): New definition.
(gfc_cpp_add_include_path, gfc_cpp_add_include_path_after): Add
comment
.
Ok for tunk?
Bernhard Reutner-Fischer (2):
Add free_cpp_dirs()
Fortran: Fix memory leak in gfc_add_include_path [PR68800]
gcc/fortran/cpp.c | 13 +++--
gcc/fortran/cpp.h | 1 +
gcc/fortran/f95-lang.c | 2 +-
gcc/fortran/scanner.c | 7 ---
gcc/incpath.c | 13
On Fri, 5 Nov 2021 19:46:16 +0100
Mikael Morin wrote:
> Le 29/10/2021 à 01:58, Bernhard Reutner-Fischer via Fortran a écrit :
> > On Wed, 27 Oct 2021 23:39:43 +0200
> > Bernhard Reutner-Fischer wrote:
> >
> >> Ping
> >> [hmz. it's been a while, I&
On Fri, 5 Nov 2021 22:17:16 +0100
Bernhard Reutner-Fischer wrote:
> Hi!
>
> In order to fix this very minor leak, we need a knob to free all
> cpp_dirs that were added.
> This adds a free_cpp_dirs() to gcc/incpath and needs review from some
> global maintainer or maybe lib
On 6 November 2021 01:21:43 CET, Marek Polacek via Gcc-patches
wrote:
>
>Thanks, so like this? I'm including an incremental diff so that it's
>clear what changed:
>
>diff --git a/gcc/attribs.c b/gcc/attribs.c
>index d5fba7f4bbb..addfe6f6c80 100644
>--- a/gcc/attribs.c
>+++ b/gcc/attribs.c
>@@ -
On Sat, 6 Nov 2021 15:29:57 -0400
Jason Merrill wrote:
> On 11/6/21 14:28, Marek Polacek wrote:
> > On Sat, Nov 06, 2021 at 02:32:26AM +0100, Bernhard Reutner-Fischer wrote:
> > No, I want q to point into the copy of the string, since I'm about
> > to modify it. An
On Sat, 6 Nov 2021 13:04:07 +0100
Mikael Morin wrote:
> Le 05/11/2021 à 23:08, Bernhard Reutner-Fischer a écrit :
> > On Fri, 5 Nov 2021 19:46:16 +0100
> > Mikael Morin wrote:
> >
> >> Le 29/10/2021 à 01:58, Bernhard Reutner-Fischer via Fortran a écrit :
>
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/gcc/fortran/cpp.c b/gcc/fortran/cpp.c
> > index e86386c8b17..04fe8fe460b 100644
> > --- a/gcc/fortran/cpp.c
> > +++ b/gcc/fortran/cpp.c
> > @@ -728,12 +728,20 @@
On Tue, 9 Nov 2021 00:12:10 -0500
Jason Merrill wrote:
> On 11/8/21 20:41, Marek Polacek wrote:
> > On Sat, Nov 06, 2021 at 03:29:57PM -0400, Jason Merrill wrote:
> > + for (auto opt : v)
> > +{
> > + char *cln = strstr (opt, "::");
> > + /* We don't accept '::attr'. */
> > +
On Tue, 9 Nov 2021 14:17:14 -0500
Marek Polacek wrote:
> + if (!valid_p (vendor_start, vendor_len)
> + || !valid_p (attr_start, attr_len))
> + {
> + error ("wrong argument to ignored attributes");
> + continue;
> + }
> + canonicalize_attr_name (vendor_start, ve
On Tue, 9 Nov 2021 20:47:02 +0100
Bernhard Reutner-Fischer wrote:
> On Tue, 9 Nov 2021 14:17:14 -0500
> Marek Polacek wrote:
>
> > + if (!valid_p (vendor_start, vendor_len)
> > + || !valid_p (attr_start, attr_len))
> > + {
> > + error (&quo
On Fri, 12 Nov 2021 18:39:48 +0100
Harald Anlauf via Fortran wrote:
Sounds plausible.
Nits:
> diff --git a/gcc/testsuite/gfortran.dg/c_sizeof_7.f90
> b/gcc/testsuite/gfortran.dg/c_sizeof_7.f90
> new file mode 100644
> index 000..3cfa3371f72
> --- /dev/null
> +++ b/gcc/testsuite/gfortran
On Sun, 7 Nov 2021 13:32:34 +0100
Mikael Morin wrote:
> > btw.. Just because it's vagely related.
> > I think f8add009ce300f24b75e9c2e2cc5dd944a020c28 for
> > PR fortran/88009 (ICE in find_intrinsic_vtab, at fortran/class.c:2761)
> > is incomplete in that i think all the internal class helpers sh
name, NULL);
+ CLASS_DATA (sym)->attr.artificial = 1;
+ if (!ret)
+ goto cleanup;
+ }
if (sym->attr.in_common)
{
>From 764a41d4afc1a03e1e8a380f4f92242a5bc9bd65 Mon Sep 17 00:00:00 2001
From: Bernhard Reutner-Fischer
Date: Sun,
On Tue, 16 Nov 2021 15:55:55 +0100
Aldy Hernandez via Gcc-patches wrote:
> All sources before Knuth are clearly wrong. How could they not?
> Folks living in the pre-Knuth era lived without a deity.
>
> :-P
Not sure if this one's a compliment.
Speaking of which:
$ git grep -i "complim"
gcc/Ch
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
On Wed, 19 May 2021 20:35:26 +0200
Tobias Burnus wrote:
> Hi Segher,
>
> Quick version: Jump to the new patch, which I like much more.
> Namely, as the attached updated patch does.
>
> As I like that patch and believe it is obvious, I intent to
/intent/s/tent/tend/
> commit it as such – unle
On Wed, 19 May 2021 22:39:13 +0200
Bernhard Reutner-Fischer wrote:
> On Wed, 19 May 2021 20:35:26 +0200
> Tobias Burnus wrote:
> > commit it as such – unless there are further comments.
>
> No real comment except ..
why don't we end up with IEEE binary128 quadr
On 20 May 2021 12:43:17 CEST, "Martin Liška" wrote:
> /* Given ARG, an unrecognized sanitizer option, return the best
> matching sanitizer option, or NULL if there isn't one.
> OPTS is array of candidate sanitizer options.
>- CODE is OPT_fsanitize_, OPT_fsanitize_recover_ or
>- OPT_f
On 21 May 2021 22:56:09 CEST, Bill Schmidt via Gcc-patches
wrote:
>>> + if (lastpos < pos)
>>> +return 0;
>>> +
>>> + char *buf = (char *) malloc (lastpos - pos + 2);
>>> + memcpy (buf, &linebuf[pos], lastpos - pos + 1);
>>> + buf[lastpos - pos + 1] = '\0';
>>> +
>>> + pos = lastpos + 1
On Fri, 4 Jun 2021 10:29:09 +0300
Claudiu Zissulescu via Gcc-patches wrote:
> Hi Jeff,
>
> I would like to add spport for selecting the ARCv2 FPU extension at
> configuration-time.
>
> The --with-fpu configuration option is ignored when -mfpu compiler
> option is specified.
>
> My concern is
On Mon, 7 Jun 2021 15:30:22 +0200
Martin Liška wrote:
> Anyway, this is resolved as I use more appropriate directive:
> https://splichal.eu/scripts/sphinx/gfortran/_build/html/intrinsic-procedures/access-checks-file-access-modes.html
ISTM there's a typo s/Tailing/Trailing/ in gcc/fortran/intrins
On Tue, 8 Jun 2021 10:05:28 +0300
Claudiu Zissulescu wrote:
> Thank you for your input.
>
> I have made an update using grep's ERE. Please let me know if it is ok.
I would have written [[:space:]]* instead of [[:space:]]+ to handle
potentially missing space, at least after the comma but also be
On Wed, 9 Jun 2021 14:35:01 +0300
Claudiu Zissulescu wrote:
> > ISTM you only set the expected flags in the switch so i would have
> > set only that variable and have grepped only once after the switch for
> > brevity.
>
> ARC has various FPU extensions, some of them are common to EM and HS
>
On Wed, 9 Jun 2021 23:39:45 +0200
Harald Anlauf via Gcc-patches wrote:
> diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
> index c27b47aa98f..016ec259518 100644
> --- a/gcc/fortran/simplify.c
> +++ b/gcc/fortran/simplify.c
> @@ -4512,6 +4512,60 @@ gfc_simplify_leadz (gfc_expr *e)
>
On Thu, 10 Jun 2021 12:24:35 +0200
Bernhard Reutner-Fischer wrote:
> On Wed, 9 Jun 2021 23:39:45 +0200
> Harald Anlauf via Gcc-patches wrote:
> > +/* Check for constant length of a substring. */
> > +
> > +static bool
> > +substring_has_constant_len (gfc_ex
On 10 June 2021 20:52:12 CEST, Harald Anlauf wrote:
>> I think the mpz_set_si args above fit on one line.
>
>That's true.
>
>Since this block is exactly the same as for constant strings,
>which is handled in the first condition, I've thought some more
>and am convinced now that these two can be f
On Fri, 11 Jun 2021 14:25:24 +0300
Claudiu Zissulescu wrote:
> Hi Bernhard,
>
> Please find attached my latest patch, it includes (hopefully) all your
> feedback.
>
> Thank you for comments,
concise and clean, i wouldn't know what to remove. LGTM.
thanks for your patience!
On Sun, 13 Jun 2021 07:58:50 +0200 (CEST)
Gerald Pfeifer wrote:
> RISC-V has received a very nice section in the GCC 11 release notes
> thanks to Kito.
>
> This are a couple of editorial changes, completing some sentence and
> breaking longer sentences among others, and a bit of grammar.
>
> Pu
On 14 June 2021 01:45:36 CEST, Jeff Law via Gcc-patches
wrote:
>
>
>On 6/2/2021 3:40 PM, Martin Sebor via Gcc-patches wrote:
>> The two forms of placement operator new defined in return their
>> pointer argument and may not be displaced by user-defined functions.
>> But because they are ordinary
On 14 June 2021 07:56:38 CEST, Bernhard Reutner-Fischer
wrote:
>On 14 June 2021 01:45:36 CEST, Jeff Law via Gcc-patches
> wrote:
>>
>>
>>On 6/2/2021 3:40 PM, Martin Sebor via Gcc-patches wrote:
>>> The two forms of placement operator new defined in return
>th
On Thu, 14 Oct 2021 15:11:41 +0800
liuhongt via Gcc-patches wrote:
> * lib/target-supports.exp (check_vect_slp_vnqihi_store_usage):
> New function.
> (check_effective_target_vect_slp_v2qi_store): Ditto.
> (check_effective_target_vect_slp_v4qi_store): Ditto.
> (check_
On 19 October 2021 15:23:58 CEST, Richard Sandiford via Gcc-patches
wrote:
>Wilco Dijkstra writes:
>> Hi Richard,
>>
>>> I'm just concerned that here we're using the same explanation but with
>>> different numbers. Why are the new numbers more right than the old ones
>>> (especially when it com
On Sun, 24 Oct 2021 10:57:05 -0600
Jeff Law via Gcc-patches wrote:
> I thought our "counting" based tests could only check equality (ie,
> expect to see this string precisely N times). Though if we could check
> that # threads realized was > some low water mark, that'd probably be
> better th
r trunk if it passes?
thanks,
Bernhard Reutner-Fischer (7):
Fortran: make some trans* functions static
Fortran: make some match* functions static
Fortran: make some constructor* functions static
Fortran: make some trans-array functions static
Fortran: Delete unused decl in trans-stmt.h
Fo
From: Bernhard Reutner-Fischer
gfc_constructor_expr_foreach and gfc_constructor_swap were just stubs.
gcc/fortran/ChangeLog:
* constructor.c (gfc_constructor_get_base): Make static.
(gfc_constructor_expr_foreach, (gfc_constructor_swap): Delete.
* constructor.h
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
* intrinsic.h (gfc_check_sum, gfc_resolve_atan2d, gfc_resolve_kill,
gfc_resolve_kill_sub): Delete declaration.
---
gcc/fortran/intrinsic.h | 4
1 file changed, 4 deletions(-)
diff --git a/gcc/fortran/intrinsic.h b/gcc
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
* trans-types.h (gfc_convert_function_code): Delete.
---
gcc/fortran/trans-types.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/gcc/fortran/trans-types.h b/gcc/fortran/trans-types.h
index 1b43503092b..3bc236cad0d 100644
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
* trans-array.c (gfc_trans_scalarized_loop_end): Make static.
* trans-array.h (gfc_trans_scalarized_loop_end,
gfc_conv_tmp_ref, gfc_conv_array_transpose): Delete declaration.
---
gcc/fortran/trans-array.c | 2 +-
gcc
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
* trans-stmt.h (gfc_trans_deallocate_array): Delete.
---
gcc/fortran/trans-stmt.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/gcc/fortran/trans-stmt.h b/gcc/fortran/trans-stmt.h
index 1a24d9b4cdc..e824caf4d08 100644
--- a/gcc
From: Bernhard Reutner-Fischer
gfc_match_small_int_expr was unused, delete it.
gfc_match_gcc_unroll should use gfc_match_small_literal_int and then
gfc_match_small_int can be deleted since it will be unused.
gcc/fortran/ChangeLog:
* decl.c (gfc_match_old_kind_spec, set_com_block_bind_c
From: Bernhard Reutner-Fischer
This makes some trans* functions static and deletes declarations of
functions that either do not exist anymore like gfc_get_function_decl
or that are unused like gfc_check_any_c_kind.
gcc/fortran/ChangeLog:
* expr.c (is_non_empty_structure_constructor
On Mon, 25 Oct 2021 00:30:16 +0200
Bernhard Reutner-Fischer wrote:
> Hi!
>
> Quickly skimming through the frontend headers.
I'm also attaching the other view for the fortran FE after the header
cleanup:
python3 $topsrc/contrib/unused_functions.py gcc/fortran/ \
grep -
On Mon, 25 Oct 2021 08:43:09 +0200
Tobias Burnus wrote:
> Hi Thomas,
>
> On 25.10.21 07:47, Thomas Koenig via Fortran wrote:
> > what you're doing seems a useful clean-up, thanks.
> >
> > One point for discussion:
> >> -match
> >> +static match
> >> gfc_match_label (void)
> > I have genera
On Mon, 25 Oct 2021 00:30:16 +0200
Bernhard Reutner-Fischer wrote:
> Hi!
>
> Quickly skimming through the frontend headers.
> There are a couple of declarations for functions that do not have
> definitions. And there are a couple of functions that can be static.
> Bootstrap
On 26 October 2021 10:58:50 CEST, Richard Biener via Gcc-patches
wrote:
>@@ -2006,6 +2011,7 @@ get_negative_load_store_type (vec_info *vinfo,
> dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
>"negative step but alignment required.\n");
> return VMAT_
On 26 October 2021 11:19:44 CEST, Richard Biener via Gcc-patches
wrote:
>@@ -2010,6 +2010,7 @@ get_negative_load_store_type (vec_info *vinfo,
> if (dump_enabled_p ())
> dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
>"negative step but alignment r
On Tue, 26 Oct 2021 14:10:05 +0200 (CEST)
Richard Biener wrote:
> I agree in general, where I would diagnose this is when we build the
> CFG I would diagnose unreachable blocks - the above does not have
> any path to the second *poffset store. Like with the prototype patch
> below we warn for
>
On 27 October 2021 11:59:58 CEST, apinski--- via Gcc-patches
wrote:
>From: Andrew Pinski
>
>The problem here is tree-ssa-forwprop.c likes to produce
>&MEM [(void *)_4 + 152B] which is the same as
>_4 p+ 152 which the rest of GCC likes better.
>This implements this transformation back to pointer
AFAICS current trunk still has this issue.
Any takers?
thanks,
On Sun, 2 Sep 2018 17:16:07 +0200
Bernhard Reutner-Fischer wrote:
>i spotted one
> (pre-existing) possible inconsistency that i did overlook back then:
>
> gfc_mat
On Wed, 27 Oct 2021 21:44:52 +0200
Harald Anlauf via Fortran wrote:
> Hi Bernhard,
>
> Am 27.10.21 um 19:40 schrieb Bernhard Reutner-Fischer via Fortran:
> > AFAICS current trunk still has this issue.
> > Any takers?
> > thanks,
>
> can you create a P
On Wed, 27 Oct 2021 21:05:02 +0100
Richard Purdie via Gcc-patches wrote:
> When building in longer build paths (200+ characters), the
> "echo $(PLUGIN_HEADERS)" from the install-plugins target would cause an
> "argument list too long error" on some systems.
>
> Avoid this by calling make's sort
On Wed, 27 Oct 2021 21:05:03 +0100
Richard Purdie via Gcc-patches wrote:
> OpenEmbedded/Yocto Project builds libgcc and the other gcc runtime libraries
> separately from the compiler and slightly differently to the standard gcc
> build.
>
> In general this works well but in trying to build them
From: Bernhard Reutner-Fischer
Hi!
Delete some more declarations without definitions and make some
functions static.
Bootstrapped and regtested on x86_64-unknown-linux without regressions.
Ok for trunk?
gcc/fortran/ChangeLog:
* decl.c (gfc_insert_kind_parameter_exprs): Make static
From: Bernhard Reutner-Fischer
addresses: FIXME: gfc_current_locus is wrong
by using the locus of the current intrinsic.
Regtests clean, ok for trunk?
gcc/fortran/ChangeLog:
2018-09-20 Bernhard Reutner-Fischer
* simplify.c (gfc_simplify_failed_or_stopped_images): Use
Hi!
I found this lying around in an oldish tree.
Regtest running over night, ok for trunk if it passes?
Bernhard Reutner-Fischer (1):
Tweak locations around CAF simplify
gcc/fortran/simplify.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
--
2.33.0
Ping
[hmz. it's been a while, I'll rebase and retest this one.
Ok if it passes?]
On Mon, 15 Oct 2018 10:23:06 +0200
Bernhard Reutner-Fischer wrote:
> If a finalization is not required we created a namespace containing
> formal arguments for an internal interface definition but
ping
[I'll rebase and retest this too since it's been a while.
Ok if it passes?]
On Sun, 21 Oct 2018 16:04:34 +0200
Bernhard Reutner-Fischer wrote:
> Hi!
>
> Regtested on x86_64-unknown-linux, installing on
> aldot/fortran-fe-stringpool.
>
> We did not free glob
On Sat, 4 Aug 2018 18:32:24 +0200
Bernhard Reutner-Fischer wrote:
> On Tue, 16 May 2017 at 21:08, Mike Stump wrote:
> >
> > On May 16, 2017, at 5:16 AM, Jonathan Wakely wrote:
> >
> > > The change I care about in 1.5.3
> >
> > So, we haven't
On Wed, 27 Oct 2021 20:13:21 +0200
Aldy Hernandez via Gcc-patches wrote:
[would have to think about this some more but it's late here. Nits:]
> diff --git a/gcc/value-relation.cc b/gcc/value-relation.cc
> index 2acf375ca9a..0ad4f7a9495 100644
> --- a/gcc/value-relation.cc
> +++ b/gcc/value-relat
On Fri, 2 Jul 2021 13:21:10 -0600
Martin Sebor via Gcc-patches wrote:
> --- a/gcc/tree-ssa-uninit.c
> +++ b/gcc/tree-ssa-uninit.c
> @@ -228,9 +228,26 @@ check_defs (ao_ref *ref, tree vdef, void *data_)
>gimple *def_stmt = SSA_NAME_DEF_STMT (vdef);
>
>/* The ASAN_MARK intrinsic doesn't m
On Sat, 1 May 2021 14:59:01 +0200
Tobias Burnus wrote:
> As this patch is rather obvious, I intent to commit it tomorrow
> as obvious, unless there is an OK earlier or other comments :-)
> (And backport to GCC 11 in a couple of days.)
>
> Before PR100352 (r11-7647),
> st_write_done did:
>st_
On 16 May 2021 20:21:13 CEST, Joern Rennecke
wrote:
>The attached patch adds a new option -fretry-compilation that allows
>you to specify a list - or
>lists - of options to use for a compilation retry, which is
>implemented in the compiler driver.
That's gross ;)
+If the compiler fails, retry
701 - 800 of 906 matches
Mail list logo
