On Aug 20 2019, Steve Kargl wrote:
On Tue, Aug 20, 2019 at 09:56:27PM +0200, Thomas Koenig wrote:
I wrote:
> Committed as r274551.
Well, this revision appears to have woken quite a few bugs from their
slumber. While argument mismatch was always illegal, it seems to have
been a common idiom
On Tue, Aug 20, 2019 at 09:56:27PM +0200, Thomas Koenig wrote:
> I wrote:
>
> > Committed as r274551.
>
> Well, this revision appears to have woken quite a few bugs from their
> slumber. While argument mismatch was always illegal, it seems to have
> been a common idiom at one time. And, like
I wrote:
Committed as r274551.
Well, this revision appears to have woken quite a few bugs from their
slumber. While argument mismatch was always illegal, it seems to have
been a common idiom at one time. And, like almost all bad habits of
the past, SPEC also has this (see PR 91473, where
Hi Janne,
The patch itself looks Ok. One worry, are you introducing an
O(N**2)(?) algorithm (looping over all symbols for every symbol?), and
does this cause performance issues when compiling some gigantic F77
project?
This is a single pass over the code, so O(N) for the code size.
The lookup
On Thu, Aug 15, 2019 at 2:35 PM Thomas Koenig wrote:
>
> Hello world,
>
> this patch fixes PR 91443, in which we did not warn about a mismatched
> external procedure. The problem was that the module this was called in
> was resolved before parsing of the procedure ever started.
>
> The approach
Hello world,
this patch fixes PR 91443, in which we did not warn about a mismatched
external procedure. The problem was that the module this was called in
was resolved before parsing of the procedure ever started.
The approach taken here is to move the checking of external procedures
to a stage
