Re: [PATCH] docs: Remove empty table column.
Hi Martin,
It looks good to me - please push before release.
Thanks
Paul
On Mon, 12 Apr 2021 at 16:59, Martin Liška wrote:
> A column with empty values seems suspicious.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/fortran/ChangeLog:
>
> * intrinsic.texi: The table has first column empty and it makes
> trouble when processing makeinfo --xml output.
> ---
> gcc/fortran/intrinsic.texi | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/gcc/fortran/intrinsic.texi b/gcc/fortran/intrinsic.texi
> index 73baa34104e..c74a7f56c60 100644
> --- a/gcc/fortran/intrinsic.texi
> +++ b/gcc/fortran/intrinsic.texi
> @@ -4764,15 +4764,15 @@ Unavailable time and date parameters return blanks.
>
> @var{VALUES} is @code{INTENT(OUT)} and provides the following:
>
> -@multitable @columnfractions .15 .30 .40
> -@item @tab @code{VALUE(1)}: @tab The year
> -@item @tab @code{VALUE(2)}: @tab The month
> -@item @tab @code{VALUE(3)}: @tab The day of the month
> -@item @tab @code{VALUE(4)}: @tab Time difference with UTC in minutes
> -@item @tab @code{VALUE(5)}: @tab The hour of the day
> -@item @tab @code{VALUE(6)}: @tab The minutes of the hour
> -@item @tab @code{VALUE(7)}: @tab The seconds of the minute
> -@item @tab @code{VALUE(8)}: @tab The milliseconds of the second
> +@multitable @columnfractions .15 .70
> +@item @code{VALUE(1)}: @tab The year
> +@item @code{VALUE(2)}: @tab The month
> +@item @code{VALUE(3)}: @tab The day of the month
> +@item @code{VALUE(4)}: @tab Time difference with UTC in minutes
> +@item @code{VALUE(5)}: @tab The hour of the day
> +@item @code{VALUE(6)}: @tab The minutes of the hour
> +@item @code{VALUE(7)}: @tab The seconds of the minute
> +@item @code{VALUE(8)}: @tab The milliseconds of the second
> @end multitable
>
> @item @emph{Standard}:
> --
> 2.31.1
>
>
--
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein
[Patch, fortran] PR fortran/100136 - ICE, regression, using flag -fcheck=pointer
Hi All!
Proposed patch to:
PR100136 - ICE, regression, using flag -fcheck=pointer
Patch tested only on x86_64-pc-linux-gnu.
Add handling for pointer expressions.
Thank you very much.
Best regards,
José Rui
Fortran: Fix ICE with -fcheck=pointer [PR100136]
gcc/fortran/ChangeLog:
PR fortran/100136
* trans-expr.c (gfc_conv_procedure_call): Add handling of pointer
expressions.
gcc/testsuite/ChangeLog:
PR fortran/100136
* gfortran.dg/PR100136.f90: New test.
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 213f32b0a67..249b3904cdb 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -6782,16 +6782,15 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
else
goto end_pointer_check;
+ tmp = parmse.expr;
if (fsym && fsym->ts.type == BT_CLASS)
{
- tmp = build_fold_indirect_ref_loc (input_location,
- parmse.expr);
+ if (POINTER_TYPE_P (tmp))
+ tmp = build_fold_indirect_ref_loc (input_location, tmp);
tmp = gfc_class_data_get (tmp);
if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (tmp)))
tmp = gfc_conv_descriptor_data_get (tmp);
}
- else
- tmp = parmse.expr;
/* If the argument is passed by value, we need to strip the
INDIRECT_REF. */
diff --git a/gcc/testsuite/gfortran.dg/PR100136.f90 b/gcc/testsuite/gfortran.dg/PR100136.f90
new file mode 100644
index 000..931a4796846
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/PR100136.f90
@@ -0,0 +1,40 @@
+! { dg-do run }
+! { dg-options "-fcheck=pointer" }
+! { dg-shouldfail "Argument not allocated" }
+! { dg-output "Fortran runtime error: Allocatable actual argument 'c_init2' is not allocated" }
+!
+! Tests fix for PR100136
+!
+! Test cut down from PR58586
+!
+
+module test_pr58586_mod
+ implicit none
+
+ type :: a
+ end type
+
+ type :: c
+ type(a), allocatable :: a
+ end type
+
+contains
+
+ subroutine add_class_c (d)
+class(c), value :: d
+ end subroutine
+
+ class(c) function c_init2()
+allocatable :: c_init2
+ end function
+
+end module test_pr58586_mod
+
+program test_pr58586
+ use test_pr58586_mod
+
+ ! This needs to execute, to see whether the segfault at runtime is resolved
+ call add_class_c(c_init2())
+
+end program
+
Re: possible bug with -fsecond-underscore ?
On Mon, 24 Sep 2018 13:39:03 +0200
Bernhard Reutner-Fischer wrote:
> On Mon, 24 Sep 2018 at 13:26, Bernhard Reutner-Fischer
> wrote:
> >
> > Hi there.
> >
> > gfc_sym_mangled_function_id() and gfc_sym_mangled_common_id both have
> > (identical, but that's for another patch to maybe factor it out) the
> > following code for underscore handling which looks suspicious:
> >
> > ---8<---
> > static tree
> > gfc_sym_mangled_common_id (gfc_common_head *com)
> > {
> > int has_underscore;
> > const char *name;
> >
> > /* Get the name out of the common block pointer. */
> > name = com->name;
> >
> > /* If we're supposed to do a bind(c). */
> > if (com->is_bind_c && com->binding_label)
> > return maybe_get_identifier (com->binding_label);
> >
> > if (name == gfc_get_string (BLANK_COMMON_NAME))
> > return maybe_get_identifier (name);
> >
> > if (flag_underscoring)
> > {
> > has_underscore = strchr (name, '_') != 0;
> > if (flag_second_underscore && has_underscore)
> > return gfc_get_identifier("%s__", name);
> > else
> > return gfc_get_identifier("%s_", name);
> > }
> > else
> > return maybe_get_identifier (name);
> > }
> > ---8<---
> >
> > the strchr looks somewhat suspicious, IMHO:
> > Isn't what the code really wants to check the fact whether or not the
> > name *already*ends* with an underscore?
> >
> > b@h:/tmp/o$ printf "common /C/ j,i\nend" | gfortran -x f95-cpp-input -
> > -ffree-form -c -o huh.o -DC=foo && readelf -s huh.o | grep foo
> > 14: 0010 8 OBJECT GLOBAL DEFAULT COM foo_
> > b@h:/tmp/o$ printf "common /C/ j,i\nend" | gfortran -x f95-cpp-input -
> > -ffree-form -c -o huh.o -DC=foo -fsecond-underscore && readelf -s
> > huh.o | grep foo
> > 14: 0010 8 OBJECT GLOBAL DEFAULT COM foo_
> > b@h:/tmp/o$ printf "common /C/ j,i\nend" | gfortran -x f95-cpp-input -
> > -ffree-form -c -o huh.o -DC=foo_bar && readelf -s huh.o | grep foo
> > 14: 0010 8 OBJECT GLOBAL DEFAULT COM foo_bar_
> > b@h:/tmp/o$ printf "common /C/ j,i\nend" | gfortran -x f95-cpp-input -
> > -ffree-form -c -o huh.o -DC=foo_bar -fsecond-underscore && readelf -s
> > huh.o | grep foo
> > 14: 0010 8 OBJECT GLOBAL DEFAULT COM foo_bar__
> >
> > I had expected "common /foo/" with -fsecond-underscore to produce a
> > "foo__" sym, no?
> > What am i missing?
>
> I should have read the documentation of -fsecond-underscore for
> starters and maybe PR51820
> "[doc] underscoring documentation incorrect" .
>
> sorry for the noise.. :(
[i was looking for something different in my outbox but AFAICS the
above doc PR is still open, in case anyone wants to tackle it for good
anytime "soon"]
Re: [PATCH,FORTRAN 00/29] Move towards stringpool, part 1
On Fri, 7 Sep 2018 10:30:30 +0200 Bernhard Reutner-Fischer wrote: > On Thu, 6 Sep 2018 at 03:25, Jerry DeLisle wrote: > > > > On 09/05/2018 07:57 AM, Bernhard Reutner-Fischer wrote: > > > Hi, > > > > > > The fortran frontend still uses stack-based handling of (symbol) names > > > with fixed-sized buffers. Furthermore these buffers often are too small > > > when dealing with F2003 identifiers which can be up to, including 63 > > > bytes long. > > > > > > Other frontends use the stringpool since many years. > > > This janitorial series is a first step towards using the stringpool in > > > the frontend. > > > Consequently this allows us to use pointer-comparison to see if two > > > given "names" are identical instead of doing lots and lots of string > > > comparisons. > > > > > > > > > Part 1 switches most of the fortran FE. An eventual part 2 would > > > continue to switch the few remaining stack-based identifier > > > manipulations to use the stringpool. My initial plan was to also see if > > > switching gfc_symtree from treap to a hash_map would bring us any > > > measurable benefit, but that, too, is left for an eventual part 2. > > > > > > Bootstrapped and regtested on x86_64-foo-linux. > > > > > > I'd appreciate if someone could double check for regressions on other > > > setups. Git branch: > > > https://gcc.gnu.org/git/?p=gcc.git;a=log;h=refs/heads/aldot/fortran-fe-stringpool > > > > > > > I am not so git savvy as I would like. If you could send me a single > > patch to trunk I will try to test on a FreeBSD system. It is usually a > > bit more picky than linux.. > > I've just encountered a regression in module writing, let me have a > looksie at that first so i don't waste your time. > > PS: You'd: > git clone git://gcc.gnu.org/git/gcc.git ~/src/gcc-9.0-stringpool > cd ~/src/gcc-9.0-stringpool > git checkout aldot/fortran-fe-stringpool > # this should output: > # Branch aldot/fortran-fe-stringpool set up to track remote branch > aldot/fortran-fe-stringpool from origin. > # if your git client is too old, then do it manually: > # git checkout -b aldot/fortran-fe-stringpool --track > origin/aldot/fortran-fe-stringpool > mkdir -p ~/obj/gcc-9.0-stringpool > cd !$ > ../../src/gcc-9.0-stringpool/configure --prefix /opt/. && make > install && make -k check;# as usual > > I'll send you a full patch when i had a chance to track down the > module writing bug. IIRC i fixed the abovementioned bug and pushed it to the branch. Unfortunately the abovementioned personal git branch somehow was deleted in the meantime. Now i was about to rebase my local tree in the light of the upcoming GCC-11 release and i'm confronted with a couple of conflicts that stem from /me touching all these spots that are troublesome _and_ slow (due to gazillions of strcmp calls to match identifiers; Part of the .plan was to see if sacrificing a little bit of memory to maintain hash_map of identifier_pointers would pay off WRT way faster comparison -- pointer cmp versus strcmp as noted above. ISTR that's what other frontends do since decades and i think it would make sense for the fortran FE too). Iff there is any interest in eventually accepting abovementioned direction into the tree, either part1 only which has merity on his own - as you can see from recent asan induced tweaks to our identifier handling - or also part 2 which encompasses the endavour to speedup the actual matching of identifiers and hence speed up some small parts of the frontend then i'm willing to rebase the series. Of course if nobody thinks that the proposed direction is the right thing to do then i will happily delete the effort so far. Saves quite some of my sparetime. For posteriority, a previous series of part1 was archived here: https://gcc.gnu.org/pipermail/gcc-patches/2018-September/thread.html#506111 As can bee seen in the series and was in part explained in https://gcc.gnu.org/pipermail/gcc-patches/2018-September/506849.html this series changes module format a little bit. Specifically, several spots do (or did back then, at least) use NULL module names in certain situations in a non-obvious way (i wouldn't dare to say hackish for i do not remember the gory details offhand i admit). I believe i initially wrote the series even before submodules but AFAIR they did not interfere in any noticable way. Modules were misbehaving but submodules not, IIRC. The fact that i need to change the module content was the main reason why i did not apply the batch back then, even if Jerry was kind enough to OK the submission as is, as you can see in above thread. So i again reach out for consensus so to maybe get this improvement into GCC-12 iff deemed appropriate and useful. Or i'll just drop it for good. thanks,
