On Mon, Oct 16, 2023 at 08:31:20PM +0200, Harald Anlauf wrote:
>
> Am 16.10.23 um 19:11 schrieb Tobias Burnus:
> > Yesterday, someone was confused because the signal handler did not work.
> >
> > It turned out that the created Fortran procedure used as handler used
> > pass by reference - and 'si
On Tue, Oct 31, 2023 at 02:11:08PM +, Paul Richard Thomas wrote:
> I found this 'obvious' fix, while going through PRs assigned to me.
>
> Regtests. OK for mainline?
>
Yes. Fell free to backport if you have time and desire.
--
Steve
On Fri, Nov 03, 2023 at 07:56:20PM +0100, Harald Anlauf wrote:
> Dear all,
>
> this is a rather weird bug with a very simple fix. If a procedure pointer
> is referenced in a CALL, a symbol was created shadowing the original
> declaration if it was host-associated. Funnily, this affected only
> r
The attached patch has been tested on x86_64-*-freebsd. OK to commit?
2019-10-23 Steven G. Kargl
PR fortran/92178
* trans-expr.c (gfc_conv_procedure_call): Evaluate args and then
deallocate actual args assocated with intent(out) dummies.
2019-10-23 Steven G. Kargl
The attached and committed patch updates gfortran
expression dumper to do something sensible with a
gfc_expr that is a BT_BOZ basic type. That is, for
program a
real :: x = real(b'10101')
real :: y = real(o'')
real :: z = real(z'abcd')
print *, x, y, z
end program a
if one is in
The patch moves the matching of the nonstandard type-spec
BYTE to its own matching function. During this move, a
check for invalid matching in free-form source code it
detected (see byte_4.f90). OK to commit?
2019-10-24 Steven G. Kargl
* decl.c (match_byte_typespec): New function. M
On Fri, Oct 25, 2019 at 10:35:24AM +0200, Tobias Burnus wrote:
> On 9/26/19 10:45 AM, Mark Eggleston wrote:
>
> PS: I was also not that happy about the BOZ changes by Steve, which
> broke code here – but, fortunately, adding int( ,kind=) around it was
> sufficient and that code was supposed to b
On Fri, Oct 25, 2019 at 09:05:03AM +0200, Tobias Burnus wrote:
> On 10/24/19 10:43 PM, Steve Kargl wrote:
> > The patch moves the matching of the nonstandard type-spec
> > BYTE to its own matching function. During this move, a
> > check for invalid matching in fre
On Fri, Oct 25, 2019 at 06:17:26PM +0200, Tobias Burnus wrote:
> This patch is about: libgomp/testsuite/libgomp.fortran/, only
>
> The two test cases I added recently use 'call abort()', which is
> nowadays frowned on as that's a ventor extension. Hence, I change it to
> 'stop'.
>
> Additional
On Sat, Oct 26, 2019 at 07:39:55PM +0100, Paul Richard Thomas wrote:
> As far as I can tell, this is a 6-regression as well - ***sigh***
>
> The patch is fundamentally very simple. Symbols that were marked with
> the fn_result_spec flag that really were module parameters were having
> the wrong na
On Thu, Oct 31, 2019 at 05:12:39PM +0100, Tobias Burnus wrote:
> At some point, 'call abort()' was changed to 'stop'; this works fine as
> long as exit status is != 0. At least on my Linux system, this works
> until 255. (Which matches POSIX, which requires 8 bits.) For "stop 256",
> I get an ex
On Thu, Oct 31, 2019 at 05:46:38PM +0100, Jakub Jelinek wrote:
> On Thu, Oct 31, 2019 at 09:42:07AM -0700, Steve Kargl wrote:
> > On Thu, Oct 31, 2019 at 05:12:39PM +0100, Tobias Burnus wrote:
> > > At some point, 'call abort()' was changed to 'stop'; this wo
On Thu, Oct 31, 2019 at 05:51:38PM +0100, Tobias Burnus wrote:
> On 10/31/19 5:42 PM, Steve Kargl wrote:
> > I suspect the other BSDs also follow posix. I wonder if gfortran
> > should either apply a mask to the stop code or simply map nonzero
> > values to one of EXIT
On Thu, Oct 31, 2019 at 09:30:26PM +0200, Janne Blomqvist wrote:
>
> I'd personally prefer the current behavior. I.e. just let the
> underlying OS/libc handle it as it sees fit. No need to invent our own
> semantics here. Tobias quoted the relevant part of the standard, which
> the current impleme
Jeff Law sent me an email that showed my patch for
PR fortran/90988 caused a regression for fixed-form
source code. The attached patch address that regression.
Briefly, the original patch fixed free-form souce code
parsing for 'PUBLICX' where the required whitespace was
missing (i.e., 'PUBLIC X')
On Fri, Nov 01, 2019 at 08:49:58AM +0100, Tobias Burnus wrote:
> On 10/31/19 11:16 PM, Steve Kargl wrote:
>
> > Jeff Law sent me an email … caused a regression for fixed-form
> > source code.
>
> Interesting, what kind of code is used in the real world!
>
Jeff se
On Sun, Nov 03, 2019 at 06:36:59PM +, Paul Richard Thomas wrote:
> The attached patch is verging on the obvious. Thanks to Tobias for
> spotting Vipul's messages on the J3 list.
>
> Regtests on FC30/x86_64 - OK for trunk and 9-branch?
>
OK for both.
--
Steve
On Sat, Nov 02, 2019 at 10:38:32AM +0100, Thomas Koenig wrote:
>
> the attached patch fixes an 8/9/10 regression where, to fix PR 84487
> by not putting the initializers and vtabs into the read-only section
> (for reasons of size, which could grow enormously) led to a regression
> on POWER9 and ot
On Fri, Nov 01, 2019 at 03:48:04PM -0700, Jerry DeLisle wrote:
>
> The attached patch provides frontend and runtime modifications to allow the
> subject format specifiers. These are allowed as default behavior and under
> -std=f2018.
>
> It does not implement the ew.de0 specifier. I decided to
On Fri, Nov 08, 2019 at 11:17:21AM +0100, Tobias Burnus wrote:
> Additionally, there are several recent reports on segfaults and
> regressions, looking Bugzilla (component = fortran, sort by change data).
>
Easiest way to find open gfortran bugs is through the gfortran wiki.
https://gcc.gnu.org/
On Wed, Jan 15, 2020 at 05:37:11PM +0100, Tobias Burnus wrote:
> Fortran before 2013 only allowed binary-octal-hex values (BOZ literals)
> in DATA statements; Fortran 2013 extended it to support them also as
> argument to INT(), REAL() etc. — Additionally, various compilers
> (including gfortran
> intent to commit it tomorrow.
>
> Regarding the patch, I enclosed a revised version. Do you have more
> suggestions – or does it look okay now?
One missing word in the release-notes. See below.
>
> On 1/15/20 7:56 PM, Steve Kargl wrote:
> >> +{
> >
On Thu, Jan 16, 2020 at 11:34:43PM +0100, Thomas Koenig wrote:
> diff --git a/gcc/testsuite/gfortran.dg/function_reference_1.f90
> b/gcc/testsuite/gfortran.dg/function_reference_1.f90
> new file mode 100644
> index 000..78c92a6f20d
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/function
On Fri, Jan 17, 2020 at 09:29:33AM +0100, Tobias Burnus wrote:
> On 1/17/20 4:49 AM, Steve Kargl wrote:
> > On Thu, Jan 16, 2020 at 11:34:43PM +0100, Thomas Koenig wrote:
> >> +type(t) :: foo
> >> +print *, foo(1)%a ! { dg-error "Function call can not contain a
On Fri, Jan 17, 2020 at 11:20:06PM +0100, Thomas Koenig wrote:
> Am 17.01.20 um 15:42 schrieb Steve Kargl:
> > Gfortran probably should not try to guess what the user
> > thought s/he wanted. The generic "Syntax error" would
> > seem to apply here. To me, foo(1
On Wed, Jan 22, 2020 at 11:59:12AM +0100, Tobias Burnus wrote:
>
> And, additionally, about missing diagnostic related to (2) bind(c) and
> kind=4,
>
Are you sure there is a missing diagnostic? You need to
add -Wc-binding-type or -Wall to your command line.
subroutine p(c) bind(c)
use iso_c
On Wed, Jan 22, 2020 at 04:43:49PM +0100, Tobias Burnus wrote:
> Hi Steve,
>
> On 1/22/20 4:02 PM, Steve Kargl wrote:
> > On Wed, Jan 22, 2020 at 11:59:12AM +0100, Tobias Burnus wrote:
> >> And, additionally, about missing diagnostic related to (2) bind(c) and
> >&g
On Sun, Feb 09, 2020 at 09:15:46PM +0100, Toon Moene wrote:
> On 2/6/20 9:01 PM, David Malcolm wrote:
>
> > PR analyzer/93405 reports an ICE when attempting to use -fanalyzer on
> > certain gfortran code. The second patch in this kit fixes that, but
> > in the meantime I need somewhere to put reg
Patch looks to me. OK to commit.
I'm wondering if we need a macro or helper function to
simplify in conditional from
+ if (gfc_state_stack->previous && gfc_state_stack->previous->previous
+ && gfc_state_stack->previous->previous->state == COMP_SUBMODULE
+ && sym->attr.module_procedure
On Sun, Feb 09, 2020 at 04:19:13PM -0500, David Malcolm wrote:
> On Sun, 2020-02-09 at 12:55 -0800, Steve Kargl wrote:
> > On Sun, Feb 09, 2020 at 09:15:46PM +0100, Toon Moene wrote:
> > > On 2/6/20 9:01 PM, David Malcolm wrote:
> > >
> > > > PR analyzer/
On Mon, Feb 10, 2020 at 03:52:13PM -0500, David Malcolm wrote:
> On Sun, 2020-02-09 at 16:38 -0800, Steve Kargl wrote:
> >
> > Having now looked at the patch, I think it's okay to commit.
> > As you note, it is new functionality in 10 so technically
> > cannot be
On Tue, Feb 11, 2020 at 02:41:26PM +, Mark Eggleston wrote:
> Please find attached a patch, it is based on Steve Kargl's patch in PR93580
> adding a check for %len and test case.
>
Looks like the wrong diff was attached.
> gcc/fortran/match.c | 4 ++--
> gcc/testsuite/g
On Tue, Feb 11, 2020 at 12:10:41PM +, Mark Eggleston wrote:
> Please find attached a patch for PR93484. The original author is Steve
> Kargl. I have added the test cases.
>
> OK for master?
I obviously think the patch is ok, but I'll let someone else review it.
>
Committed as obvious.
2019-12-11 Steven G. Kargl
PR fortran/92897
* array.c (gfc_set_array_spec): Remove invalid assert() triggered
by invalid Fortran code.
2019-12-11 Steven G. Kargl
PR fortran/92897
* gfortran.dg/pr92897.f90: New test.
--
Steve
On Wed, Dec 11, 2019 at 11:24:35PM +0100, Harald Anlauf wrote:
>
> > Gesendet: Dienstag, 10. Dezember 2019 um 23:34 Uhr
> > Von: "Thomas Koenig"
> > An: "Harald Anlauf" , gfortran ,
> > gcc-patches
> > Betreff: Re: [Patch, Fortran] PR92898 - [9/10 Regression] ICE in
> > gfc_check_is_contiguous
On Sun, Dec 15, 2019 at 07:11:25PM +0100, Thomas Koenig wrote:
> Am 10.12.19 um 22:22 schrieb Thomas Koenig:
> > Steve made an excellent suggestion: -finline-arg-packing .
> >
> > So, OK with that change?
>
> In other words, is
>
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00485.html
>
> OK
On Sun, Dec 15, 2019 at 06:41:50PM +, Paul Richard Thomas wrote:
> This patch is straight forward and well explained by the ChangeLogs.
> The ICE comes about because the simplification of the inquiry_part_ref
> expressions produced bad expressions.
>
> Thanks to Steve for spotting the error in
On Tue, Dec 17, 2019 at 03:41:41PM +, Mark Eggleston wrote:
> gcc/fortran/ChangeLog
>
> Mark Eggleston
>
> PR fortran/92896
> * array.c (walk_array_constructor): Replace call to cfg_convert_type
s/cfg_convert_type/gfc_convert_type
> with call to gfc_convert_type_warn w
On Tue, Dec 17, 2019 at 05:28:05PM +, Mark Eggleston wrote:
>
> On 17/12/2019 17:06, Steve Kargl wrote:
> > On Tue, Dec 17, 2019 at 03:41:41PM +, Mark Eggleston wrote:
> >> gcc/fortran/ChangeLog
> >>
> >> Mark Eggleston
> >>
On Tue, Dec 17, 2019 at 08:04:30PM +0200, Janne Blomqvist wrote:
>
> Well, frontends are nowadays C++, so
>
> a) No need to include stdbool.h, bool is a builtin type.
>
> b) optional arguments are a thing (they are also used elsewhere in the
> Fortran frontend).
>
Ah, yes. The creep of C++ in
On Wed, Dec 18, 2019 at 08:47:31AM +, Mark Eggleston wrote:
>
> It is a bit confusing that the Fortran FE source files have the .c
> extension implying C when they are C++ and are compiled using C++.
It is not puzzling at all. gfortran was added to GCC some 15
years ago. gfortran was origin
On Thu, Dec 19, 2019 at 09:30:49PM +0100, Tobias Burnus wrote:
>
> The latter could be "solved" by using %C instead of %L after
> gfc_simplify_expr in gfc_match_stopcode.
> [The "ref" has its own address (e->ref->u.ar->where); hence,
> the a(1,1) error would be still fine.]
> (Though, this potenti
On Tue, Mar 05, 2024 at 08:06:10PM -0800, Jerry D wrote:
> On 3/5/24 1:51 PM, Harald Anlauf wrote:
> > Hi Jerry,
> >
> > on further thought, do we sanitize 'child_iomsg'?
> > We pass it to snprintf as format.
> >
> > Wouldn't a strncpy be sufficient?
> >
> > Harald
> >
> >
>
> Just to be safe
On Tue, Mar 19, 2024 at 04:17:32PM +0100, FX Coudert wrote:
>
> These two (independent) patches add two tiny Fortran 2023 features: new
> ISO_FORTRAN_ENV named constants and SELECTED_LOGICAL_KIND intrinsic.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu.
> Please review, and let me know i
On Wed, Mar 27, 2024 at 04:30:42PM +0100, Mikael Morin wrote:
> Hell(o),
>
> it didn't take long for my recent patch for PR111781 to show a regression.
> The fix proposed here is actually the one Harald posted in the PR.
> I can't imagine a case where it wouldn't do the right thing.
> Regression t
Jerry,
The patch looks good to me, but please give Harald a chance
to comment.
--
steve
On Fri, Feb 02, 2024 at 07:17:55PM -0800, Jerry D wrote:
> On 1/30/24 12:36 PM, Harald Anlauf wrote:
> > Hi Jerry,
> >
> > Am 30.01.24 um 19:15 schrieb Jerry D:
> > > The attached patch attempts to fix the
On Mon, Feb 12, 2024 at 09:57:08PM +0100, Harald Anlauf wrote:
> Dear all,
>
> the attached patch fixes a mis-handling of optional dummy arguments
> passed to optional dummy arguments of procedures with the bind(c)
> attribute. When those procedures are expecting CFI descriptors,
> there is no sp
On Tue, Feb 20, 2024 at 08:53:37PM +0100, Harald Anlauf wrote:
> On 2/19/24 16:19, Peter Hill wrote:
> > Hi Harald,
> >
> > Thanks for your help, please see the updated and signed-off patch below.
>
> Pushed: https://gcc.gnu.org/g:14ba8d5b87acd5f91ab8b8c02165a0fd53dcc2f2
>
Harald, Thanks for ta
I have attached a patch to PR114024, see
https://gcc.gnu.org/pipermail/gcc-bugs/2024-February/854651.html
The patch contains a new testcase and passes regression
testing on x86_64-*-freebsd. Could someone castr an eye
over the patch and commit it?
--
Steve
On Wed, Feb 21, 2024 at 09:28:16PM +0100, Harald Anlauf wrote:
> On 2/21/24 20:41, Jerry D wrote:
> > On 2/21/24 10:30 AM, Steve Kargl wrote:
> > > I have attached a patch to PR114024, see
> > >
> > > https://gcc.gnu.org/pipermail/gcc-bugs/2024-February/854651.
On Wed, Feb 21, 2024 at 10:20:43PM +0100, Harald Anlauf wrote:
> On 2/21/24 22:00, Steve Kargl wrote:
> > Unfortunately, valgrind does not work on AMD FX-8350 cpu.
>
> Do you mean valgrind does not work at all?
> For gcc, you need to configure --enable-valgrind-annotations
On Wed, Feb 21, 2024 at 01:42:32PM -0800, Steve Kargl wrote:
> On Wed, Feb 21, 2024 at 10:20:43PM +0100, Harald Anlauf wrote:
> > On 2/21/24 22:00, Steve Kargl wrote:
> > > memleak vs ICE. I think I'll take one over the other.
> > > Probably need to free code->
On Thu, Feb 22, 2024 at 09:22:37PM +0100, Harald Anlauf wrote:
> Hi Steve!
>
> On 2/22/24 01:52, Steve Kargl wrote:
> > On Wed, Feb 21, 2024 at 01:42:32PM -0800, Steve Kargl wrote:
> > > On Wed, Feb 21, 2024 at 10:20:43PM +0100, Harald Anlauf wrote:
> > > >
On Fri, Feb 23, 2024 at 10:15:17PM +0100, Harald Anlauf wrote:
> Hi Steve, all,
>
> here's an updated patch with an enhanced testcase that also
> checks MOLD= besides SOURCE=.
>
> Regtested on x86_64-pc-linux-gnu. Is it OK for mainline?
>
>From my viewpoint, yes.
Thanks for finding a better s
All,
Consider,
! { dg-do run }
program foo
implicit none
real y
associate (x => log(cmplx(-1,0)))
y = x%im
if (int(100*y)-314 /= 0) stop 1
end associate
end program
% gfcx -c a.f90
a.f90:6:13:
6 | y = x%im
| 1
Error: Symbol 'x' at (1) has no I
On Thu, Feb 29, 2024 at 09:36:43AM -0800, Jerry D wrote:
> On 2/29/24 1:47 AM, Bernhard Reutner-Fischer wrote:
>
> > And, just for my own education, the length limitation of iomsg to 255
> > chars is not backed by the standard AFAICS, right? It's just our
> > STRERR_MAXSZ?
>
> Yes, its what we ha
On Sat, Jan 13, 2024 at 10:12:42PM +0100, Harald Anlauf wrote:
>
> (2) a missing optional argument for SIZE to the ISHFTC intrinsic
> shall be equivalent to using BIT_SIZE(I).
>
> Regtested on x86_64-pc-linux-gnu. OK for mainline?
>
> As I consider the patch safe, I'd like to backport to 13
On Fri, Jan 19, 2024 at 06:47:36PM +0100, Mikael Morin wrote:
>
> I tested this on x86_64-pc-linux-gnu without regression.
> There is no new test, as the problem is visible on an
> existing test with valgrind or an asan-instrumented compiler.
> OK for master?
>
Yes. After your explanation, the
All,
I have attached a new patch to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
which addresses the following issues.
PR113152 -- implement half-cycle trigonometric functions
PR113412 -- better error message for atan(y,x)
PR113413 -- implement atand(y,x)
The patch clocks in at 3488 l
On Tue, Jan 23, 2024 at 10:08:43AM +0100, FX Coudert wrote:
> Hi Steve,
>
> Thanks for the patch. I’ll take time to do a proper review, but
> after a first read I had the following questions:
>
> - "an OS's libm may/will contain cospi(), etc.”: do those functions
> conform to any standard? Are th
On Tue, Jan 23, 2024 at 06:40:27AM -0800, Steve Kargl wrote:
> On Tue, Jan 23, 2024 at 10:08:43AM +0100, FX Coudert wrote:
> > Hi Steve,
> >
> > Thanks for the patch. I’ll take time to do a proper review, but
> > after a first read I had the following questions:
> &
On Tue, Jan 23, 2024 at 01:37:54PM +0200, Janne Blomqvist wrote:
> On Tue, Jan 23, 2024 at 11:09 AM FX Coudert wrote:
> >
> > Hi Steve,
>
> Hello, long time no see.
Time is short and we're all busy with life, but it is nice to see
familiar names!
>
> > Thanks for the patch. I’ll take time to d
On Tue, Jan 23, 2024 at 01:37:54PM +0200, Janne Blomqvist wrote:
>
> > - If I get this right, to take one example, the Fortran front-end will emit
> > a call to gfortran_acospi_r4(), libgfortran provides this as a wrapper
> > calling acospif(), which is called either from libm or from libgfortra
On Wed, Jan 24, 2024 at 11:13:05AM +0200, Janne Blomqvist wrote:
> On Wed, Jan 24, 2024 at 10:28 AM FX Coudert wrote:
> > > Now, if
> > > the OS adds cospi() to libm and it's in libm's symbol map, then the
> > > cospi() used by gfortran depends on the search order of the loaded
> > > libraries.
>
On Sun, Jan 28, 2024 at 08:56:24PM +0100, Harald Anlauf wrote:
>
> Am 28.01.24 um 12:39 schrieb Mikael Morin:
> > Le 24/01/2024 à 22:39, Harald Anlauf a écrit :
> > > Dear all,
> > >
> > > this patch is actually only a followup fix to generate the proper name
> > > of an array reference in derive
On Mon, Dec 18, 2023 at 07:11:59PM +0100, Harald Anlauf wrote:
> Dear all,
>
> starting with Fortran 2018, DATE_AND_TIME allowed a non-default
> integer VALUES argument.
>
> While gfortran accepts this silently, this failed at runtime
> because the library implementation beyond kind=4 and kind=8
On Tue, Jan 02, 2024 at 08:31:15PM +0100, Harald Anlauf wrote:
>
> we might want to update changes.html to reflect this. How about:
>
> diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
> index 403feb06..9b16f5e3 100644
> --- a/htdocs/gcc-14/changes.html
> +++ b/htdocs/gcc-14/
On Sat, Nov 18, 2023 at 11:12:55PM +0100, Harald Anlauf wrote:
>
> Fortran 2023 added restrictions on integer arguments to SYSTEM_CLOCK.
> The attached patch implements these.
>
> I was struggling with the way we should handle features that are sort-of
> deleted in a new standard, but not describ
Harald,
Sorry about delayed response. Got side-tracked by Family this weekend.
On Sun, Nov 19, 2023 at 09:46:46PM +0100, Harald Anlauf wrote:
>
> On 11/19/23 01:04, Steve Kargl wrote:
> > On Sat, Nov 18, 2023 at 11:12:55PM +0100, Harald Anlauf wrote:
> > > Regtested o
On Wed, Nov 22, 2023 at 10:36:00AM +0100, Mikael Morin wrote:
>
> OK with this fixed (and the previous comments as you wish), if Steve has no
> more comments.
>
No further comments. Thanks for your patients, Harald.
As side note, I found John Reid's "What's new" document
where it is noted that
On Fri, Jun 28, 2024 at 10:00:53PM +0200, Harald Anlauf wrote:
>
> the attached patch fixes an ICE occuring for ALLOCATE with SOURCE
> (or MOLD) of deferred character length in the scalar case, which
> looked obscure because the ICE disappears at -O1 and higher.
>
> The dump tree suggests that it
Thanks for the patch and chasing down the magic.
Path is ok to commit.
--
steve
On Fri, Jul 19, 2024 at 05:32:26PM +0100, Paul Richard Thomas wrote:
> Hi All,
>
> Ping!
>
> I understand now why this works. The scope of the block is merged and so
> all the previous declarations that would othe
On Thu, Aug 08, 2024 at 11:09:10AM +0200, Mikael Morin wrote:
>
> These patches are about inlining, there is no manipulation of the parse
> tree. So I would rather use a separate option (-finline-intrinsics?).
I've only followed the discussion from afar, but gcc already supports
a -finline and -
On Sun, Aug 18, 2024 at 12:10:18PM +0200, Thomas Koenig wrote:
>
> this version of the patch includes DOT_PRODUCT, MATMUL and quite
> a few improvements for simplification.
Thomas,
Your updated patch applied cleanly on top-of-tree gcc.
Bootstrap and regression testing on amd64-*-freebsd
comple
On Wed, Aug 21, 2024 at 12:17:46PM +0200, Andre Vehreschild wrote:
>
> attached small patch removes a VIEW_CONVERT that I erroneously inserted during
> patching pr110033. PR86468 fixes the (co-)rank computation and therefore this
> VIEW_CONVERT is IMO obsolete. I think it may cause hard to find ru
On Tue, Aug 27, 2024 at 06:46:08PM +0200, Thomas Koenig wrote:
> Steve,
>
> > On Sun, Aug 18, 2024 at 12:10:18PM +0200, Thomas Koenig wrote:
> > >
> > > this version of the patch includes DOT_PRODUCT, MATMUL and quite
> > > a few improvements for simplification.
> >
> > Thomas,
> >
> > Your upd
Thanks for the patch. If you have not already opened a new PR for the
other issue with C8107, I'll open one later today. It's likely that
we need to check the namelist-group-name for USE association in
match.cc:gfc_match_namelist.
Hmmm, it seems we already catch the error, but accept it as an
ex
On Tue, Jun 18, 2024 at 09:13:23AM +0200, Gerald Pfeifer wrote:
> The original subsite has disappeared and we couldn't find it elsewhere.
>
https://github.com/gklimowicz/FCVS
gklimowicz is a flang developer and member of J3.
--
Steve
On Wed, May 08, 2024 at 01:27:53PM +0800, Kewen.Lin wrote:
>
> Previously effective target fortran_real_c_float128 never
> passes on Power regardless of the default 128 long double
> is ibmlongdouble or ieeelongdouble. It's due to that TF
> mode is always used for kind 16 real, which has precisio
On Thu, May 09, 2024 at 01:37:32PM +0800, Kewen.Lin wrote:
>
> >
> > That said, Fortran has the concept of model numbers, which
> > are set in arith.c. Does this change give the expected
> > value for ibm128? For example, with "REAL(16) X", one
> > has "DIGITS(X) = 113", which is the precision
On Thu, Aug 29, 2024 at 10:05:35PM +0200, Harald Anlauf wrote:
>
> Am 29.08.24 um 21:53 schrieb Steve Kargl:
> > Thanks for the patch. If you have not already opened a new PR for the
> > other issue with C8107, I'll open one later today. It's likely that
> > w
On Fri, Aug 30, 2024 at 06:46:47PM +0200, Harald Anlauf wrote:
> Am 30.08.24 um 18:33 schrieb Steve Kargl:
> > On Thu, Aug 29, 2024 at 10:05:35PM +0200, Harald Anlauf wrote:
> > >
> > >
> > > Should we downgrade this extension to GFC_STD_LEGACY?
> >
ault) to a legacy extension (warning by default).
>
> The feature is tested in at least 4 gfortran testcases. I adjusted
> the pattern of one of these tests to check for the downgrade.
>
> Regtested on x86_64-pc-linux-gnu. OK for mainline?
>
> Thanks,
> Harald
>
>
On Thu, Sep 05, 2024 at 09:07:20AM +0200, Thomas Koenig wrote:
> Ping (a little bit)?
>
> With another weekend coming up, I would have some time to
> work on incorporating any feedback, or on putting in
> more intrinsics.
>
In the documentation, you have
+Generally, unsigned integers are only p
On Thu, Sep 05, 2024 at 09:07:20AM +0200, Thomas Koenig wrote:
> Ping (a little bit)?
>
> With another weekend coming up, I would have some time to
> work on incorporating any feedback, or on putting in
> more intrinsics.
>
Last comment as I've made it to the end of the patch.
Your testcases ar
On Sun, Aug 18, 2024 at 12:10:18PM +0200, Thomas Koenig wrote:
> Hello world,
>
> this version of the patch includes DOT_PRODUCT, MATMUL and quite
> a few improvements for simplification.
>
All,
I have gone through Thomas's current patch and sent a
few emails with comments to him. To keep thin
OK. Sorry about dropping the balli on a review.
I thought it had already been approved and committed.
--
steve
On Fri, Sep 13, 2024 at 12:19:48PM +0200, Mikael Morin wrote:
> Ping:
>
> https://gcc.gnu.org/pipermail/fortran/2024-July/060640.html
>
> Maybe I could argue that I can self approve,
On Fri, Sep 13, 2024 at 12:27:07PM +0200, Mikael Morin wrote:
> >
> > gcc/fortran/ChangeLog:
> >
> > * invoke.texi(finline-intrinsics): Document new flag.
> > * lang.opt (finline-intrinsics, finline-intrinsics=,
> > fno-inline-intrinsics): New flags.
> > * options.cc (gfc_post_opt
On Sat, Sep 14, 2024 at 11:02:42AM -0700, Steve Kargl wrote:
>
> While I understand the intent of 'positive form' vs 'negative form', the
> above might be clearer as
>
>Usage of intrinsics can be implemented either by generating a call
>to the libgf
On Wed, Sep 11, 2013 at 09:54:57PM -0700, Brooks Moses wrote:
> Ping^3?
>
There is little to no Fortran specific content, which
requires a Fortran review. If no one steps up, just
commit the change.
--
Steve
On Wed, Oct 09, 2013 at 11:51:30PM +0200, Tobias Burnus wrote:
> A rather obvious fix; the memory is freed by the caller
> (gfc_simplify_compiler_options). It is unlikely that the compiler has no
> arguments as the driver tends to send some, e.g. "-mtune=generic
> -march=x86-64" on my system. Ho
On Mon, Oct 21, 2013 at 07:15:07PM +0200, Tobias Burnus wrote:
> - c->tb = tb;
> + if (num == 1)
> + c->tb = tb;
> + else
> + {
> + c->tb = XCNEW (gfc_typebound_proc);
> + c->tb->where = gfc_current_locus;
> + *c->tb = *tb;
I haven't convinced myself yet, b
On Mon, Oct 21, 2013 at 09:04:22PM +0200, Tobias Burnus wrote:
> Steve Kargl wrote:
> > On Mon, Oct 21, 2013 at 07:15:07PM +0200, Tobias Burnus wrote:
> >> - c->tb = tb;
> >> + if (num == 1)
> >> + c->tb = tb;
> >> + else
&g
On Tue, Oct 22, 2013 at 08:30:44PM +0200, Tobias Burnus wrote:
> Two weeks ago I submitted the patch, available at:
> http://gcc.gnu.org/ml/fortran/2013-10/msg00022.html ; while the ME patch
> is not yet approved, the C FE was approved (latest C/ME patch:
> http://gcc.gnu.org/ml/gcc-patches/2013
On Fri, Nov 01, 2013 at 04:56:36PM +0100, Paul Richard Thomas wrote:
>
> This one is trivial. The ICE was caused by an assert that turns out
> to be spurious and has been removed.
>
> Bootstrapped and regtested on FC17/x86_64 - OK for trunk and 4.8?
>
OK.
--
Steve
I committed the following changes to gfortran's runtime library.
It converts an assert on an invalid floating-point exponent into
a runtime error.
2013-12-18 Steven G. Kargl
* io/read.c (read_f): Convert assert to runtime error.
2013-12-18 Steven G. Kargl
* gfortran.dg/io_
On Mon, Dec 30, 2013 at 06:03:30PM +0100, Janus Weil wrote:
>
> I even volunteer to make a start with the one mentioned in the subject
> line. The fix is actually easy once you know where to look (which was
> simplified a lot by Dominique's efforts to identify the blameworthy
> commit).
>
> The r
On Wed, Jan 01, 2014 at 07:49:16PM -0800, Mike Stump wrote:
> On Nov 23, 2013, at 12:16 PM, Steve Kargl
> wrote:
>> On Sat, Nov 23, 2013 at 11:21:21AM -0800, Mike Stump wrote:
>>> Richi has asked the we break the wide-int patch so that the
>>> individual port and fr
On Mon, Jan 06, 2014 at 11:28:51PM +0100, Janus Weil wrote:
>
> here is a regression fix for polymorphic deallocation. The attached
> patch is identical in functionality to the one-liner in comment 13 of
> the PR, fixing a bug in the detection of finalizable components (with
> include allocatable
On Sat, Jan 11, 2014 at 09:27:44AM -0800, Jerry DeLisle wrote:
> My apologies please. I forgot to mention Dominiq for his
> superb assistance with this patch and testing. Many thanks!
>
Add Dominiq to the ChangeLog entry. I think the patch
is OK.
--
Steve
1 - 100 of 1352 matches
Mail list logo
