On 2 November 2022 15:45:39 CET, Tamar Christina via Gcc-patches
wrote:
>Hi All,
>
>This patch adds initial support for early break vectorization in GCC.
>The support is added for any target that implements a vector cbranch optab.
>
>Concretely the kind of loops supported are of the forms:
>
> fo
On 31 August 2022 20:29:12 CEST, FX via Fortran wrote:
+ case GFC_FPE_GFC_FPE_AWAY:
typo?
thanks,
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-patches@gcc.gnu.org&q=subject:%22%5C%5BPATCH%2C+OpenACC%5C%5D+Fortran+deviceptr%22&o=newest&f=1
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 11 September 2022 10:04:51 CEST, David Malcolm via Gcc-patches
wrote:
>> +++ b/gcc/testsuite/gcc.dg/analyzer/pr106845.c
>> @@ -0,0 +1,11 @@
>> +int buf_size;
>> +
>> +int
>> +main (void)
>> +{
>> + char buf[buf_size];
>> +
>> + __builtin_memset (&buf[1], 0, buf_size);
>> +
>> + return 0;
>
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 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
> >> wrote:
>
> >>>If you want t
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 about automating this?
>
> Manual part is attache
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 triggers
> >> inappropriate FAIL.
> >
> >>
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!
>
> OK for backport to gc
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);
On Wed, 29 Sep 2021 10:10:00 +0200
Aldy Hernandez wrote:
> Jeff has requested we slow down changes in the threading space while
> we chased down regressions.
Sure. Take your time.
>
> That being said, thank you for your suggestion. I am putting the
> attached patch in my queue for testing.
LG
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 earlier one would
- memcpy (name
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 (gfc_get_uop_from
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
> Bernhard Reutner-Fischer wrote:
>
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):
> Tweak locations arou
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 definitely lost.
> at 0x4C2CC0
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.e. a helper to construct a
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.
> ---
> gcc/gdbinit.in | 1 +
> 1 f
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.
> I can easily switch the
On 30 October 2021 00:13:06 CEST, Jerry D wrote:
>Looks OK.
Thanks!
I guess I need an OK from some global maintainer, too?
The breakpoint is ignored by automatically answering the question with n if the
symbol is not found when loading .gdbinit for e.g. cc1.
thanks,
>
>Cheers
>
>On 10/29/21 11
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..9506f3500
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_pointer' may be used
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)
is
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-2
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(-)
diff
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;
> >m_equiv.m_next = ptr;
> >bitmap_ior_into
On Mon, 1 Nov 2021 15:21:03 +0100
Aldy Hernandez wrote:
> I'm not convinced this makes the code clearer to read, especially if
> it's not on a critical path. But if you feel strongly, please submit
> a patch ;-).
No i don't feel strongly about it.
Compiling e.g. -O2 ira.o
# Overhead Sampl
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-linux.
Ok
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.
* f95
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 libcpp maintainer for this hunk.
Bootstrapped and regtested on x86_64-unknown-linux without regressions.
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'll rebase and retest this one.
> >> Ok if it p
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 libcpp maintainer for thi
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. And I'd prefer a single call t
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 Wed, 27 Oct 2021 23:39:43 +
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 ("wrong argument to ignored attributes");
> >
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
Hi!
Amend fix for PR88009 to mark all these class components as artificial.
gcc/fortran/ChangeLog:
* class.c (gfc_build_class_symbol, generate_finalization_wrapper,
(gfc_find_derived_vtab, find_intrinsic_vtab): Use stringpool for
names. Mark internal symbols as artificial
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
On Tue, 16 Nov 2021 21:46:32 +0100
Harald Anlauf via Fortran wrote:
> Hi Bernhard,
>
> I'm trying to understand your patch. What does it really try to solve?
Compiler generated symbols should be marked artificial.
The fix for PR88009 ( f8add009ce300f24b75e9c2e2cc5dd944a020c28 ,
r9-5194 ) added
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 quadruple precision here per
defaul
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_expr *e)
> > +{
> > + ptrdiff_t istart
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
>their
>>> pointer argument and may not
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
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.
Notes i took while at it / TODOs:
- get rid of VTAB_GET_FIELD_GEN and unused extern decls
- The last block of
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 (gfc_const
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/f
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): Ma
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 -v "gt_"
for a guesstima
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.
> Bootstraps fine, regression te
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_match_associate () reads
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 PR tracking this issue?
now https://gcc.gn
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
current
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 never used
> any o
101 - 200 of 312 matches
Mail list logo
