https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #39 from Steve Kargl ---
On Wed, Mar 04, 2020 at 12:07:18PM +, thenlich at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
>
> On the other hand side, always folding sind(45...90) to cosd(45...0) and
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
--- Comment #42 from Steve Kargl ---
On Wed, Mar 04, 2020 at 04:35:02PM +, thenlich at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
>
> --- Comment #41 from Thomas Henlich ---
> One would assume that fast FMA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94228
--- Comment #5 from Steve Kargl ---
On Thu, Mar 19, 2020 at 10:24:10PM +, markwayne1969 at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94228
>
> --- Comment #4 from Mark Paris ---
> (In reply to kargl from comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94246
--- Comment #4 from Steve Kargl ---
On Sat, Mar 21, 2020 at 10:27:03PM +, dcb314 at hotmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94246
>
> --- Comment #3 from David Binderman ---
> (In reply to kargl from comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94228
--- Comment #7 from Steve Kargl ---
On Mon, Mar 23, 2020 at 02:41:23AM +, markwayne1969 at gmail dot com wrote:
>
> (In reply to Steve Kargl from comment #5)
> >
> > > Links to information about gcc development for this specific
> > > possi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94246
--- Comment #6 from Steve Kargl ---
On Mon, Mar 23, 2020 at 07:35:54AM +, rguenth at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94246
>
> Richard Biener changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94246
--- Comment #9 from Steve Kargl ---
On Mon, Mar 23, 2020 at 07:29:02PM +, anlauf at gcc dot gnu.org wrote:
> --- Comment #7 from anlauf at gcc dot gnu.org ---
> I get an ICE even for the non-valgrind version on x86_64-pc-linux-gnu:
>
> gcc/t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94397
--- Comment #3 from Steve Kargl ---
On Mon, Mar 30, 2020 at 04:23:11PM +, kargl at gcc dot gnu.org wrote:
>
> --- Comment #2 from kargl at gcc dot gnu.org ---
> (In reply to Martin Liška from comment #1)
> > Confirmed, started with r10-7369-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94411
--- Comment #3 from Steve Kargl ---
On Tue, Mar 31, 2020 at 04:47:04AM +, longb at cray dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94411
>
> --- Comment #2 from Bill Long ---
> Thanks for the quick reply. Is there a predi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93762
--- Comment #3 from Steve Kargl ---
Here's a better testcasei, which removes IO statement, which
makes it easier to read -fdump-tree-original.
module deepest_call_m
implicit none
contains
subroutine deepest_call(str)
charact
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #3 from Steve Kargl ---
On Tue, Apr 14, 2020 at 07:23:32AM +, rguenth at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
>
> --- Comment #2 from Richard Biener ---
> Not all targets have a C99 math ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #5 from Steve Kargl ---
On Tue, Apr 14, 2020 at 12:55:45PM +, dave.anglin at bell dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
>
> --- Comment #4 from dave.anglin at bell dot net ---
> On 2020-04-13 11:02 p
-04-14 11:40 a.m., sgk at troutmask dot apl.washington.edu wrote:
> > After '#include ' in trigd.c, add
> >
> > #if (__STDC_VERSION__ < 199901L)
> > #define fmaf(a,b,c) ((a)*(b)+(c))
> > #define fma(a,b,c) ((a)*(b)+(c))
> > #define fmal(a,b,c) ((a)*(b
0-04-14 2:12 p.m., sgk at troutmask dot apl.washington.edu wrote:
> > #ifdef HAVE_GFC_REAL_16
> > #endif
> This one.
> >
> > Is hppa64 claiming support for a REAL type that it actually
> > doesn't support?
> Support is a fuzzy word. There's enough support
0-04-14 6:08 p.m., sgk at troutmask dot apl.washington.edu wrote:
> > So, hppa64 has REAL(16), but it does not use __float128 or
> > GFC_REAL_16_IS_FLOAT128 is somehow not getting set. Instead
> > of the above kludge you can do something like
> It appears GFC_REAL_16_IS_F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #14 from Steve Kargl ---
On Wed, Apr 15, 2020 at 03:28:29PM +, dave.anglin at bell dot net wrote:
>
> On 2020-04-15 11:02 a.m., sgk at troutmask dot apl.washington.edu wrote:
> >
> > #if defined(HAVE_GFC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #15 from Steve Kargl ---
On Wed, Apr 15, 2020 at 06:04:08PM +, dave.anglin at bell dot net wrote:
>
> /usr/lib/dld.sl: Unresolved symbol: strtoflt128 (data) from
This should be in libquadmath.
% nm /usr/home/kargl/work/lib/lib
0-04-15 2:14 p.m., sgk at troutmask dot apl.washington.edu wrote:
> > What does -fdump-tree-original show for
> >
> > function foo(x)
> >real(16) foo, x
> >foo = cos(x)
> > end function foo
> foo (real(kind=16) & restrict x)
> {
> real(ki
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #22 from Steve Kargl ---
On Thu, Apr 16, 2020 at 08:06:00PM +, danglin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
>
> --- Comment #21 from John David Anglin ---
> Created attachment 48295
>
0-04-16 5:07 p.m., sgk at troutmask dot apl.washington.edu wrote:
> > It is unclear to me if the patch will meet everyone's
> > expectation. In particular, there are currently no
> > target-specific macros used in the Fortran frontend.
> > Using 'defined(_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #34 from Steve Kargl ---
On Wed, Apr 22, 2020 at 04:02:01PM +, dave.anglin at bell dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
>
> --- Comment #33 from dave.anglin at bell dot net ---
> On 2020-04-22 10:54
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94737
--- Comment #5 from Steve Kargl ---
On Sun, Apr 26, 2020 at 02:39:37AM +, busby1 at llnl dot gov wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94737
>
> --- Comment #4 from Lee Busby ---
> (In reply to kargl from comment #3)
> > (In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94769
--- Comment #4 from Steve Kargl ---
On Mon, Apr 27, 2020 at 06:27:25AM +, stefansf at linux dot ibm.com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94769
>
> --- Comment #3 from Stefan Schulze Frielinghaus ibm.com> ---
> Since one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94769
--- Comment #6 from Steve Kargl ---
On Mon, Apr 27, 2020 at 05:12:50PM +, tkoenig at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94769
>
> Thomas Koenig changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93366
--- Comment #4 from Steve Kargl ---
On Wed, Apr 29, 2020 at 08:57:44PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93366
>
> anlauf at gcc dot gnu.org changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94931
--- Comment #3 from Steve Kargl ---
On Mon, May 04, 2020 at 01:13:22AM +, ryofurue at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94931
>
> --- Comment #2 from Ryo Furue ---
> Thanks for the detailed description.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94931
--- Comment #5 from Steve Kargl ---
On Mon, May 04, 2020 at 01:33:43AM +, ryofurue at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94931
>
> --- Comment #4 from Ryo Furue ---
> > There is only place gfortran will sear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94931
--- Comment #7 from Steve Kargl ---
On Mon, May 04, 2020 at 08:23:17AM +, ryofurue at gmail dot com wrote:
>
> But, then the question is, why don't you need the -L option? as in
>
> gfortran -I/usr/include mysourcefile.f -L/usr/lib -lne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
--- Comment #14 from Steve Kargl ---
On Tue, May 12, 2020 at 06:43:54PM +, seurer at linux dot vnet.ibm.com
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
>
> --- Comment #13 from Bill Seurer ---
> I don't know fortran and this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
--- Comment #23 from Steve Kargl ---
On Thu, May 14, 2020 at 02:57:37PM +, wschmidt at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
>
> Bill Schmidt changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
--- Comment #27 from Steve Kargl ---
On Thu, May 14, 2020 at 06:39:24PM +, tkoenig at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
>
> --- Comment #26 from Thomas Koenig ---
> (In reply to wschmidt from commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95177
--- Comment #4 from Steve Kargl ---
On Tue, May 19, 2020 at 04:38:32AM +, roland.illig at gmx dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95177
>
> --- Comment #2 from Roland Illig ---
> >--- Comment #1 from kargl at gcc do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95177
--- Comment #9 from Steve Kargl ---
On Wed, May 20, 2020 at 04:10:50AM +, tkoenig at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95177
>
> Thomas Koenig changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293
--- Comment #3 from Steve Kargl ---
On Sat, May 23, 2020 at 10:43:23PM +, david.sagan at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293
>
> --- Comment #2 from David Sagan ---
> The gcc documentation says:
>
> ‘a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293
--- Comment #5 from Steve Kargl ---
On Sun, May 24, 2020 at 06:47:18AM +, tkoenig at gcc dot gnu.org wrote:
>
> and the effective argument has the TARGET attribute
>
> That I will have to look up; if a has the TARGET attribute,
> does a%b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293
--- Comment #7 from Steve Kargl ---
On Sun, May 24, 2020 at 02:45:32PM +, david.sagan at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293
>
> --- Comment #6 from David Sagan ---
> > program foo
> >real x
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104
--- Comment #7 from Steve Kargl ---
On Tue, May 26, 2020 at 08:30:36PM +, anlauf at gcc dot gnu.org wrote:
>
> --- Comment #6 from anlauf at gcc dot gnu.org ---
> Steve, do you want me to commit it for you, including backports?
>
I no long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95373
--- Comment #4 from Steve Kargl ---
On Wed, May 27, 2020 at 08:04:22PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95373
>
> --- Comment #3 from anlauf at gcc dot gnu.org ---
> Patch:
>
> diff --git a/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95398
--- Comment #1 from Steve Kargl ---
On Thu, May 28, 2020 at 09:33:08PM +, kargl at gcc dot gnu.org wrote:
>
> Code posted at
>
> https://groups.google.com/forum/#!topic/comp.lang.fortran/mW1gV6tyxXk
Here's the code
implicit none
t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95544
--- Comment #4 from Steve Kargl ---
Likely, want to include this in the commit if someone ever gets
around to committing the patch(es).
Index: gcc/fortran/misc.c
===
--- gcc/fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95546
--- Comment #5 from Steve Kargl ---
On Fri, Jun 05, 2020 at 03:46:18PM +, jvdelisle at charter dot net wrote:
>
> I am curious, did this just start happening or is it a long time issue just
> reported. Locking mecahnisms were adjusted recen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95543
--- Comment #3 from Steve Kargl ---
On Sat, Jun 06, 2020 at 04:34:53PM +, kargl at gcc dot gnu.org wrote:
>
> This cures the ICE, which then I believe leads to wrong-code.
>
PDT are completely broken. When this is parsed
type t(a, b)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95543
--- Comment #4 from Steve Kargl ---
On Sat, Jun 06, 2020 at 05:13:31PM +, sgk at troutmask dot
apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95543
>
> --- Comment #3 from Steve Kargl ---
> On Sat, Jun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95544
--- Comment #7 from Steve Kargl ---
On Mon, Jun 08, 2020 at 08:02:48PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95544
>
> anlauf at gcc dot gnu.org changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640
--- Comment #4 from Steve Kargl ---
On Thu, Jun 11, 2020 at 02:56:58PM +, kargl at gcc dot gnu.org wrote:
>
> IEEE-754 permits the extended double type (See 3.7 Extended and
> extendable precisions). I do not see in the Fortran standard tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640
--- Comment #7 from Steve Kargl ---
On Thu, Jun 11, 2020 at 04:12:57PM +, longb at cray dot com wrote:
>
> --- Comment #5 from Bill Long ---
> The same user also submitted a bug about IEEE_FMA not being supported. Is
> there already a bug/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640
--- Comment #8 from Steve Kargl ---
On Thu, Jun 11, 2020 at 04:21:25PM +, longb at cray dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640
>
> --- Comment #6 from Bill Long ---
> (In reply to kargl from comment #3)
> > (In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640
--- Comment #9 from Steve Kargl ---
On Thu, Jun 11, 2020 at 10:14:21AM -0700, Steve Kargl wrote:
>
> IEEE-754 calls binary32, 64, 128 the basic formats (Sec. 3, p. 6):
>
> Five basic formats are defined in this clause:
> Three binary form
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640
--- Comment #13 from Steve Kargl ---
On Fri, Jun 12, 2020 at 04:16:53AM +, kargl at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640
>
> --- Comment #12 from kargl at gcc dot gnu.org ---
> (In reply to Bill Long fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640
--- Comment #15 from Steve Kargl ---
On Fri, Jun 12, 2020 at 03:33:20PM +, anlauf at gcc dot gnu.org wrote:
> --- Comment #14 from anlauf at gcc dot gnu.org ---
> Why don't we simply set IEEE_SUPPORT_DATATYPE (1._10) to .false.?
>
> use, int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640
--- Comment #16 from Steve Kargl ---
On Thu, Jun 11, 2020 at 10:40:29PM -0700, Steve Kargl wrote:
> On Fri, Jun 12, 2020 at 04:16:53AM +, kargl at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640
> >
> > --- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647
--- Comment #4 from Steve Kargl ---
On Sat, Jun 13, 2020 at 08:11:22AM +, tkoenig at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647
>
> --- Comment #3 from Thomas Koenig ---
> If we treat .eq. and == differently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640
--- Comment #18 from Steve Kargl ---
On Sat, Jun 13, 2020 at 10:14:43AM +, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640
>
> --- Comment #17 from Andrew Pinski ---
> (In reply to Steve Kargl from com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30372
--- Comment #14 from Steve Kargl ---
This patch brings UNLINK subroutine into agreement with
its documentation.
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (revision 2801
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93635
--- Comment #4 from Steve Kargl ---
On Sun, Jun 21, 2020 at 05:44:51PM +, drikosev at gmail dot com wrote:
>
> The attached patch contains various test cases for the PR's you mentioned at:
> https://groups.google.com/d/msg/comp.lang.fortran/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95614
--- Comment #4 from Steve Kargl ---
On Mon, Jun 22, 2020 at 09:10:25AM +, drikosev at gmail dot com wrote:
>
> --- Comment #3 from Ev Drikos ---
>
> Hello,
>
> Perhaps, an additional check in file resolve.c might be necessary, or
> one wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52279
--- Comment #8 from Steve Kargl ---
On Thu, Jul 02, 2020 at 03:53:22PM +, jakub at gcc dot gnu.org wrote:
>
> --- Comment #7 from Jakub Jelinek ---
> (In reply to kargl from comment #6)
> > There is no -fno-allow-invalid-boz option. The op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96033
--- Comment #6 from Steve Kargl ---
On Thu, Jul 02, 2020 at 04:10:38PM +, skorzennik at cfa dot harvard.edu
wrote:
>
> GCC is the single one that decides that old code is trash and needs to be
> rewritten. When 64b was introduced, gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52279
--- Comment #10 from Steve Kargl ---
On Thu, Jul 02, 2020 at 05:10:51PM +, sch...@linux-m68k.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52279
>
> --- Comment #9 from Andreas Schwab ---
> That means you cannot override a defau
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96033
--- Comment #8 from Steve Kargl ---
On Thu, Jul 02, 2020 at 05:31:21PM +, skorzennik at cfa dot harvard.edu
wrote:
>
> I gave up on gfortran when the 64b record marker made it unusable for me. I'm
> not surprised it was fixed, but this point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52279
--- Comment #12 from Steve Kargl ---
On Thu, Jul 02, 2020 at 05:24:36PM +, sch...@linux-m68k.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52279
>
> --- Comment #11 from Andreas Schwab ---
> If it was enabled by default, you can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96033
--- Comment #9 from Steve Kargl ---
On Thu, Jul 02, 2020 at 06:30:40PM +, sgk at troutmask dot
apl.washington.edu wrote:
>
> It isn't a matter of simply switching rules. It's a matter of bugs
> and whether the bug i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96024
--- Comment #4 from Steve Kargl ---
On Sat, Jul 04, 2020 at 09:29:49AM +, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96024
>
> --- Comment #3 from Dominique d'Humieres ---
> > The patch in PR 95025 fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95980
--- Comment #9 from Steve Kargl ---
On Mon, Jul 06, 2020 at 08:29:24PM +, anlauf at gcc dot gnu.org wrote:
> I have the impression that there's a lot of bad things happening with
> invalid input that is not always caught on x86_64.
This has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96158
--- Comment #6 from Steve Kargl ---
On Mon, Jul 13, 2020 at 12:23:58PM +, amelvill at umich dot edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96158
>
> --- Comment #4 from AJM ---
> >> I won't comment on the questionable program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96158
--- Comment #7 from Steve Kargl ---
On Mon, Jul 13, 2020 at 01:42:29PM +, amelvill at umich dot edu wrote:
>
> As far as workarounds go, if it came to that I'd rather just make a dummy
> "debug" function that stored these common variables as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96158
--- Comment #9 from Steve Kargl ---
On Mon, Jul 13, 2020 at 03:44:13PM +, amelvill at umich dot edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96158
>
> --- Comment #8 from AJM ---
> > > >> I won't comment on the questionable pro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85796
--- Comment #4 from Steve Kargl ---
On Sat, Jul 18, 2020 at 08:13:31PM +, jvdelisle at charter dot net wrote:
>
> --- Comment #3 from jvdelisle at charter dot net ---
> This looks OK Steve. Assuming your regression tested, shall I commit thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30372
--- Comment #19 from Steve Kargl ---
On Sun, Jul 19, 2020 at 02:42:24PM +, arjen.markus895 at gmail dot com
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30372
>
> --- Comment #17 from Arjen Markus ---
> As UMASK has two arguments,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96255
--- Comment #6 from Steve Kargl ---
On Tue, Jul 21, 2020 at 07:44:16PM +, jvdelisle at charter dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96255
>
> --- Comment #5 from jvdelisle at charter dot net ---
> (In reply to kargl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320
--- Comment #8 from Steve Kargl ---
On Sun, Jul 26, 2020 at 09:35:56PM +, jvdelisle at charter dot net wrote:
>
> I my too simple terms, when you define the interface and then use
> module procedure in the contains, all of the declarations in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320
--- Comment #17 from Steve Kargl ---
On Tue, Jul 28, 2020 at 10:32:50AM +, dominiq at lps dot ens.fr wrote:
>
> What I guessed, but I still see (not new)
>
> /opt/gcc/work/gcc/testsuite/gfortran.dg/whole_file_23.f90:18:32:
>
>18 |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325
--- Comment #13 from Steve Kargl ---
On Wed, Jul 29, 2020 at 02:54:59PM +, pault at gcc dot gnu.org wrote:
> --- Comment #12 from Paul Thomas ---
> (In reply to kargl from comment #10)
> > (In reply to jvdelisle from comment #9)
> > > I regr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325
--- Comment #15 from Steve Kargl ---
Hi Paul,
Not sure how the UK is handling the pandemic. Here, in
Washington we have 4 phases. Phase 1 has the most
restrictions and phase 4 is the pandemic is over. Most
of Washington made it into phase 2 (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320
--- Comment #22 from Steve Kargl ---
On Mon, Aug 03, 2020 at 11:45:20PM +, damian at sourceryinstitute dot org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320
>
> --- Comment #21 from Damian Rouson ---
> Now that the patch fixin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486
--- Comment #14 from Steve Kargl ---
On Thu, Aug 06, 2020 at 08:03:29AM +, markeggleston at gcc dot gnu.org
wrote:
> (In reply to kargl from comment #6)
> > I do note there are other problems with get_environment_variable.
>
> It looks to me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486
--- Comment #15 from Steve Kargl ---
On Thu, Aug 06, 2020 at 08:42:20AM +, jussilehtola at fedoraproject dot org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486
>
> --- Comment #13 from Susi Lehtola ---
> The gdb output is the s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486
--- Comment #17 from Steve Kargl ---
On Thu, Aug 06, 2020 at 08:33:12PM +, jussilehtola at fedoraproject dot org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486
>
> --- Comment #16 from Susi Lehtola ---
> Yes, then I installed m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486
--- Comment #20 from Steve Kargl ---
On Fri, Aug 07, 2020 at 01:14:04PM +, jussilehtola at fedoraproject dot org
wrote:
>
> It already was reproduced in comment #9?
>
There is clearly a language barrier. At this point, I have
no idea what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486
--- Comment #24 from Steve Kargl ---
On Fri, Aug 07, 2020 at 08:35:49PM +, jussilehtola at fedoraproject dot org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486
>
> --- Comment #21 from Susi Lehtola ---
> to repeat: libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486
--- Comment #26 from Steve Kargl ---
On Fri, Aug 07, 2020 at 09:55:06PM +, sch...@linux-m68k.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486
>
> --- Comment #25 from Andreas Schwab ---
> But why does it error out? It should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96613
--- Comment #6 from Steve Kargl ---
On Mon, Aug 17, 2020 at 06:03:31PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96613
>
> --- Comment #5 from anlauf at gcc dot gnu.org ---
> (In reply to kargl from c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
--- Comment #9 from Steve Kargl ---
On Wed, Aug 19, 2020 at 09:36:32PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
>
> --- Comment #8 from anlauf at gcc dot gnu.org ---
> A very quick hack seems t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
--- Comment #11 from Steve Kargl ---
On Thu, Aug 20, 2020 at 01:47:58PM +, bre08 at eggen dot co.uk wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
>
> --- Comment #10 from B Eggen ---
> I've been experimenting with the suggeste
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
--- Comment #13 from Steve Kargl ---
On Thu, Aug 20, 2020 at 03:54:44PM +, bre08 at eggen dot co.uk wrote:
>
> PS (and maybe I need to post this separately as a suggestion) - will
> there be a fast "octuple-precision floating point / integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95352
--- Comment #5 from Steve Kargl ---
On Thu, Aug 20, 2020 at 11:15:27PM +, jrfsousa at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95352
>
> --- Comment #4 from José Rui Faustino de Sousa ---
> I have tested the patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95352
--- Comment #7 from Steve Kargl ---
On Fri, Aug 21, 2020 at 10:35:27AM +, jrfsousa at gmail dot com wrote:
> Done!
>
> https://gcc.gnu.org/pipermail/fortran/2020-August/054908.html
>
> Thank you very much.
>
Thanks for submitting. If no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96811
--- Comment #4 from Steve Kargl ---
On Thu, Aug 27, 2020 at 04:57:14PM +, burnus at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96811
>
> --- Comment #3 from Tobias Burnus ---
> (In reply to kargl from comment #2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96859
--- Comment #8 from Steve Kargl ---
On Tue, Sep 01, 2020 at 12:52:49PM +, jakub at gcc dot gnu.org wrote:
>
> --- Comment #5 from Jakub Jelinek ---
> I think this boils down to:
> program foo
> print *, int(o'1234567',2), int(o'1234567',4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96859
--- Comment #10 from Steve Kargl ---
On Tue, Sep 01, 2020 at 03:20:20PM +, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96859
>
> --- Comment #9 from Jakub Jelinek ---
> I've read that. But I think in this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96890
--- Comment #4 from Steve Kargl ---
On Thu, Sep 03, 2020 at 02:32:32PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96890
>
> --- Comment #3 from anlauf at gcc dot gnu.org ---
> (In reply to kargl from c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97031
--- Comment #3 from Steve Kargl ---
On Sun, Sep 13, 2020 at 08:02:01AM +, jean-pierre.flam...@univ-lille.fr
wrote:
>
> I just noticed that cpp recognizes the extensions .fpp .F and other uppercase
> extensions.
> This is why I added -cpp in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97046
--- Comment #3 from Steve Kargl ---
On Mon, Sep 14, 2020 at 11:56:18PM +, gilles.gouaillardet at gmail dot com
wrote:
> This is the libc subroutine
>
> void sync(void);
>
> The point here is any subroutine (that will not cause a crash) can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92174
--- Comment #3 from Steve Kargl ---
On Tue, Oct 22, 2019 at 02:14:55PM +, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92174
>
> --- Comment #2 from Martin Liška ---
> (In reply to kargl from comment #1)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92174
--- Comment #6 from Steve Kargl ---
On Tue, Oct 22, 2019 at 02:56:01PM +, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92174
>
> --- Comment #5 from Martin Liška ---
> > Problem is that the compiler invoke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178
--- Comment #3 from Steve Kargl ---
On Tue, Oct 22, 2019 at 07:32:59PM +, kargl at gcc dot gnu.org wrote:
>
> The effect of the intent(out) in assign is to deallocate the code on entry to
> assign. This is done with the if-block. The side-e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178
--- Comment #5 from Steve Kargl ---
On Tue, Oct 22, 2019 at 09:03:42PM +, vladimir.fuka at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178
>
> --- Comment #4 from Vladimir Fuka ---
> It would be really strange if e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178
--- Comment #6 from Steve Kargl ---
On Tue, Oct 22, 2019 at 09:30:14PM +, sgk at troutmask dot
apl.washington.edu wrote:
>
> Cutting the -ftree-dump-original down to the 'call' statement
> gives
>
> MAIN__ ()
&g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178
--- Comment #7 from Steve Kargl ---
On Tue, Oct 22, 2019 at 10:22:42PM +, sgk at troutmask dot
apl.washington.edu wrote:
> --- Comment #6 from Steve Kargl ---
> On Tue, Oct 22, 2019 at 09:30:14PM +0000, sgk at troutma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178
--- Comment #10 from Steve Kargl ---
On Thu, Oct 24, 2019 at 05:09:55AM +, mscfd at gmx dot net wrote:
>
> --- Comment #9 from martin ---
> Is this possibly related to bug 87142?
>
Certainly appears that way. If I add a 'print *, ">"//tr
1 - 100 of 1026 matches
Mail list logo
