Here's a general approach to handle PR116701. I considered
adding manual deletions as quoted below and mentioned in the
PR, but seeing the handling of "integer 8" in
fortran-torture-execute I decided to follow that example:
better scan the source for open-statements than relying on
manual annotati
Hi all,
I have now downloaded the file at
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663534.html (by
copying it from the browser, not the source code to avoid '>
This file had had to fix spurious line breaks like:
@@ -5171,7 +5171,7 @@ index_interchange (gfc_code **c, int
*wal
Hi Andre,
Am 19.09.24 um 14:19 schrieb Andre Vehreschild:
Hi all,
the attached patch fixes an ICE when compiling with -fcoarray=lib and using
(proc_-)pointer component in a coarray. The code was looking at the wrong
location for the caf-token.
Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok
Hi Andre,
Am 19.09.24 um 16:01 schrieb Andre Vehreschild:
Hi all,
in PR84870 an ICE was reported, that has been fixed in the meantime by some
other patch. Nevertheless did a testcase reveal that the memory handling still
was not correct. I.e. the test case in the patch was answering 2 for both
Hi Anuj,
thanks for your work!
I am unable to apply the patch, so I only looked at the testcases.
Generally speaking, runtime tests should verify that they work as
expected. Just printing a result does not. Use a comparison
against an expected result and do e.g. STOP 123 on failure.
Also, ne
Andreas Schwab writes:
> It's only about the @opindex. The vast majority have those variable
> parts removed from the index entry.
We can probably do both at the same time, either via makeinfos -D option
and some special macro, or by emitting a machine-generated index, maybe.
How would a flag
On Mon, 23 Sept 2024 at 19:00, Eric Gallager via Gcc wrote:
>
> On Mon, Sep 23, 2024 at 8:09 AM Thomas Koenig via Gcc
> wrote:
> >
> > [For the fortran people: Discussion on gcc@]
> >
> > Just a general remark.
> >
> > There are people, such as myself, who regularly mess up
> > their git reposit
On Sep 23 2024, Mikael Morin wrote:
> For options where the variable is not a separate argument, I think it's
> preferable to keep the variable.
>
> For example, -ffree-line-length-@var{n} looks better on the index page as
> "-ffree-line-length-n" (with the n having a different formatting), than a
Thomas Koenig writes:
> [For the fortran people: Discussion on gcc@]
>
> Just a general remark.
>
> There are people, such as myself, who regularly mess up
> their git repositories because they have no mental model
> of what git is doing (case in point: The Fortran unsigned
> branch, which I mana
On Mon, Sep 23, 2024 at 8:09 AM Thomas Koenig via Gcc wrote:
>
> [For the fortran people: Discussion on gcc@]
>
> Just a general remark.
>
> There are people, such as myself, who regularly mess up
> their git repositories because they have no mental model
> of what git is doing (case in point: The
> On 23 Sep 2024, at 15:33, Jonathan Wakely wrote:
>
> On Mon, 23 Sept 2024 at 14:36, enh wrote:
>>
>> it doesn't make the patch _management_ problem better ("now i have two
>> problems"), but https://github.com/landley/toybox takes the "why not both?"
>> approach --- you can use pull reque
On Mon, 23 Sept 2024 at 16:20, Florian Weimer wrote:
>
> * Jonathan Wakely:
>
> > The discussion is about how we do patch submission and patch review.
> > The GitHub pull request workflow is widely seen as simpler than our
> > current email-based workflow (not everybody agrees, of course). The
> >
* Jonathan Wakely:
> The discussion is about how we do patch submission and patch review.
> The GitHub pull request workflow is widely seen as simpler than our
> current email-based workflow (not everybody agrees, of course). The
> idea is to *lower* the barrier of entry for contributors, not rais
On Mon, 23 Sep 2024, enh via Gcc wrote:
> it doesn't make the patch _management_ problem better ("now i have two
> problems"), but https://github.com/landley/toybox takes the "why not both?"
> approach --- you can use pull requests if you grew up with/adapted to
> git/github, or you can use the ma
On Mon, 23 Sept 2024 at 14:36, enh wrote:
>
> it doesn't make the patch _management_ problem better ("now i have two
> problems"), but https://github.com/landley/toybox takes the "why not both?"
> approach --- you can use pull requests if you grew up with/adapted to
> git/github, or you can use
Am 23.09.24 um 11:02 schrieb Paul Richard Thomas:
Hi All,
The moment I saw the DIN4 proposal for "Generic processing of assumed
rank objects", I thought that this was a highly intuitive and
implementable proposal. I implemented a test version in June and had
some correspondence with Reinhold
Now committed as r15-3799-gcdb9aa0f623ec7 /
https://gcc.gnu.org/r15-3799-gcdb9aa0f623ec7
Tobias
Am 21.09.24 um 01:33 schrieb Tobias Burnus:
Hi Thomas, hello all,
the attached follow-up patch does:
* It fixes an issue (thinko) related to Fortran and \0 terminated,
which fails for at least s
it doesn't make the patch _management_ problem better ("now i have two
problems"), but https://github.com/landley/toybox takes the "why not both?"
approach --- you can use pull requests if you grew up with/adapted to
git/github, or you can use the mailing list otherwise ... taking into
account that
On Mon, 23 Sept 2024 at 13:09, Thomas Koenig via Gcc wrote:
>
> [For the fortran people: Discussion on gcc@]
>
> Just a general remark.
>
> There are people, such as myself, who regularly mess up
> their git repositories because they have no mental model
> of what git is doing
I highly recommend
Hello Andre and everybody else?
Any more comments on the matmul patch? The other ones depend on
it, so I would like to commit (unless there are further
questions, of course).
Best regards
Thomas
On Mon, Sep 23, 2024 at 8:08 AM Thomas Koenig via Gdb
wrote:
>
> [For the fortran people: Discussion on gcc@]
>
> Just a general remark.
>
> There are people, such as myself, who regularly mess up
> their git repositories because they have no mental model
> of what git is doing (case in point: The
[For the fortran people: Discussion on gcc@]
Just a general remark.
There are people, such as myself, who regularly mess up
their git repositories because they have no mental model
of what git is doing (case in point: The Fortran unsigned
branch, which I managed to put into an unrepairable state
Hi Andre,
Andre Vehreschild wrote:
Could you also please specify the commit SHA your patch is supposed to apply
to? At current mainline's HEAD it has several rejects which makes reviewing
harder.
I just tried and here it applies cleanly on mainline, except that I get
a bunch of:
Hunk #1 suc
Hi Paul,
Am 23.09.24 um 10:26 schrieb Paul Richard Thomas:
In addition to Andre's remarks, could you please tell us, when you
resubmit, if this is a complete F2023 implementation of do concurrent.
If not, what is missing?
Regarding missing parts: still to do is actually privatizing (with or
wi
Hi All,
The moment I saw the DIN4 proposal for "Generic processing of assumed rank
objects", I thought that this was a highly intuitive and implementable
proposal. I implemented a test version in June and had some correspondence
with Reinhold Bader about it shortly before he passed away.
Malcolm
Le 23/09/2024 à 00:01, Andreas Schwab a écrit :
On Sep 22 2024, Arsen Arsenović wrote:
Andreas Schwab writes:
On Sep 22 2024, Jakub Jelinek wrote:
On Sun, Sep 22, 2024 at 10:52:37PM +0200, Andreas Schwab wrote:
On Sep 22 2024, Mikael Morin wrote:
@@ -370,7 +370,7 @@ Set the default acce
Hi Anuj,
please check the code style of your patch using:
contrib/check_GNU_style.py
It reports several errors with line length and formatting.
Could you also please specify the commit SHA your patch is supposed to apply
to? At current mainline's HEAD it has several rejects which makes reviewi
Hi all,
as a background – Anuj, did this as part of his Google Summer of Code
project (thanks!).
As I looked as various drafts, I would be happy if someone else could
have a look as well, as I probably start skipping over things and,
hence, as miss potential issues …
A bit hidden in the patch i
Hi Tobias,
to my eye this looks fine. I would appreciate, if you could add some tests for
errors on the fortran side, esp. where modules are involved. But no must.
Ok for mainline. Thanks for the patch.
- Andre
On Sat, 21 Sep 2024 23:37:33 +0200
Tobias Burnus wrote:
> Add support of the 'sel
29 matches
Mail list logo
