Re: Invalid "dg-do run" in the testsuite (with 2 blanks)
On Sun, Mar 24, 2024 at 1:19 PM Harald Anlauf wrote: > > Dear all, > > I noticed by chance that we have quite a lot of improperly specified do-do > directives in the testsuite. > > % grep "dg-do run" gcc/testsuite/gfortran.dg/ -rl|wc -l > 83 > > Note that with two blanks instead of just one a testcase does not get > executed. > > Does anybody want to earn the honors to change the directives and > check for "fallout" in the testsuite? Note this seems related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28032 (or maybe this is the "workaround" for not doing torture options on the testcases). If this gets documented to avoid doing the torture options, then the testsuite should be auditted for dg-options with `-ON` and add the extra space for dg-do to get the non torture way. Thanks, Andrew > > Cheers, > Harald >
Re: [PATCH] libgfortran: Disable gthreads weak symbols for glibc 2.34
On Tue, Apr 9, 2024, 10:07 H.J. Lu wrote:
> Since Glibc 2.34 all pthreads symbols are defined directly in libc not
> libpthread, and since Glibc 2.32 we have used __libc_single_threaded to
> avoid unnecessary locking in single-threaded programs. This means there
> is no reason to avoid linking to libpthread now, and so no reason to use
> weak symbols defined in gthr-posix.h for all the pthread_xxx functions.
>
First you forgot to cc fortran@. Second the issue is in gthrd-posix.h which
should be fixed instead of libgfortran since the issue will also be seen
with libobjc, and the other users of gthrd.
Note the fix for libstdc++ was also done in the wrong location too and
should have done once and for all in gthrd-posix.h.
Thanks,
Andrew
> Also add prune_warnings to libgomp.exp to prune glibc static link warning:
>
> .*: warning: Using 'dlopen' in statically linked applications requires at
> runtime the shared libraries from the glibc version us ed for linking
>
> libgfortran/
>
> PR libgfortran/114646
> * acinclude.m4: Define GTHREAD_USE_WEAK 0 for glibc 2.34 or
> above on Linux.
> * configure: Regenerated.
>
> libgomp/
>
> PR libgfortran/114646
> * testsuite/lib/libgomp.exp (prune_warnings): New.
> * testsuite/libgomp.fortran/pr114646-1.f90: New test.
> * testsuite/libgomp.fortran/pr114646-2.f90: Likewise.
> ---
> libgfortran/acinclude.m4 | 14 +
> libgfortran/configure | 29 +++
> libgomp/testsuite/lib/libgomp.exp | 14 +
> .../testsuite/libgomp.fortran/pr114646-1.f90 | 11 +++
> .../testsuite/libgomp.fortran/pr114646-2.f90 | 22 ++
> 5 files changed, 90 insertions(+)
> create mode 100644 libgomp/testsuite/libgomp.fortran/pr114646-1.f90
> create mode 100644 libgomp/testsuite/libgomp.fortran/pr114646-2.f90
>
> diff --git a/libgfortran/acinclude.m4 b/libgfortran/acinclude.m4
> index a73207e5465..f4642494c4f 100644
> --- a/libgfortran/acinclude.m4
> +++ b/libgfortran/acinclude.m4
> @@ -92,6 +92,20 @@ void foo (void);
>AC_DEFINE(GTHREAD_USE_WEAK, 0,
> [Define to 0 if the target shouldn't use #pragma weak])
>;;
> +*-*-linux*)
> + AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
> +#include
> +#if !__GLIBC_PREREQ(2, 34)
> +#error glibc version is too old
> +#endif
> +]], [[]])],
> + libgfor_cv_use_pragma_weak=no,
> + libgfor_cv_use_pragma_weak=yes)
> + if test $libgfor_cv_use_pragma_weak = no; then
> +AC_DEFINE(GTHREAD_USE_WEAK, 0,
> + [Define to 0 if the target shouldn't use #pragma weak])
> + fi
> + ;;
>esac])
>
> dnl Check whether target effectively supports weakref
> diff --git a/libgfortran/configure b/libgfortran/configure
> index 774dd52fc95..1f477256b75 100755
> --- a/libgfortran/configure
> +++ b/libgfortran/configure
> @@ -31057,6 +31057,35 @@ $as_echo "#define SUPPORTS_WEAK 1" >>confdefs.h
>
> $as_echo "#define GTHREAD_USE_WEAK 0" >>confdefs.h
>
> + ;;
> +*-*-linux*)
> + cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> +/* end confdefs.h. */
> +
> +#include
> +#if !__GLIBC_PREREQ(2, 34)
> +#error glibc version is too old
> +#endif
> +
> +int
> +main ()
> +{
> +
> + ;
> + return 0;
> +}
> +_ACEOF
> +if ac_fn_c_try_compile "$LINENO"; then :
> + libgfor_cv_use_pragma_weak=no
> +else
> + libgfor_cv_use_pragma_weak=yes
> +fi
> +rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
> + if test $libgfor_cv_use_pragma_weak = no; then
> +
> +$as_echo "#define GTHREAD_USE_WEAK 0" >>confdefs.h
> +
> + fi
>;;
>esac
>
> diff --git a/libgomp/testsuite/lib/libgomp.exp
> b/libgomp/testsuite/lib/libgomp.exp
> index cab926a798b..9cfa6d7b31d 100644
> --- a/libgomp/testsuite/lib/libgomp.exp
> +++ b/libgomp/testsuite/lib/libgomp.exp
> @@ -54,6 +54,20 @@ set dg-do-what-default run
>
> set libgomp_compile_options ""
>
> +# Prune messages that aren't useful.
> +
> +proc prune_warnings { text } {
> +
> +verbose "prune_warnings: entry: $text" 2
> +
> +# Ignore warning from -static: warning: Using 'dlopen' in statically
> linked applications requires at runtime the shared libraries from the glibc
> version used for linking
> +regsub -all "(^|\n)\[^\n\]*: warning: Using 'dlopen' in statically
> linked\[^\n\]*" $text "" text
> +
> +verbose "prune_warnings: exit: $text" 2
> +
> +return $text
> +}
> +
> #
> # libgomp_init
> #
> diff --git a/libgomp/testsuite/libgomp.fortran/pr114646-1.f90
> b/libgomp/testsuite/libgomp.fortran/pr114646-1.f90
> new file mode 100644
> index 000..a48e6103343
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.fortran/pr114646-1.f90
> @@ -0,0 +1,11 @@
> +! PR libgfortran/114646
> +! { dg-do run }
> +! { dg-additional-options "-static" }
> +
> +!$OMP PARALLEL
> +!$OMP CRITICAL
> + write(6,*) "Hello world"
> +!$OMP END CRITICAL
> +!$
Re: Tests of gcc development beyond its testsuite (in this case, for gfortran)
On Mon, May 6, 2024 at 2:27 PM Toon Moene wrote: > > I have now, for some time, ran LAPACK's test programs on my gcc/gfortran > builds on both on the x86_64-linux-gnu architecture, as well as the > aarch64-linux-gnu one (see, e.g., > http://moene.org/~toon/lapack-amd64-gfortran13-O3). > > The results are rather alarming - this is r15-202 for aarch64 vs r15-204 > for x86_64 (compiled with -O3): Did you test x86_64 with -march=native (or with -mfma) or just -O3? The reason why I am asking is aarch64 includes FMA by default while x86_64 does not. Most recent x86_64 includes an FMA instruction but since the base ISA does not include it, it is not enabled by default. I am suspect the aarch64 "excessive exceeding the threshold for errors" are all caused by the more use of FMA rather than anything else. Thanks, Andrew Pinski > > diff lapack-amd64-gfortran15-O3 lapack-aarch64-gfortran15-O3 > > 3892,3895c3928,3931 > < REAL 1327023 0 (0.000%)0 > (0.000%) > < DOUBLE PRECISION 1300917 6 (0.000%)0 > (0.000%) > < COMPLEX 786775 0 (0.000%)0 > (0.000%) > < COMPLEX16 787842 0 (0.000%)0 > (0.000%) > --- > > REAL 1317063 71 (0.005%)0 > (0.000%) > > DOUBLE PRECISION 1318331 54 (0.004%)4 > (0.000%) > > COMPLEX 767023 390 (0.051%)0 > (0.000%) > > COMPLEX16772338 305 (0.039%)0 > (0.000%) > 3897c3933 > < --> ALL PRECISIONS4202557 6 (0.000%)0 > (0.000%) > --- > > --> ALL PRECISIONS 4174755 820 (0.020%)4 > (0.000%) > > Note the excessive exceeding the threshold for errors on the aarch64 > side (>). > > Of course, this is only an excerpt of the full log file - there is more > information in it to zoom in on the errors on the aarch64 side (note > that the x86_64 side is not faultless). > > Is there a way to pass this information to our websites, so that we do > not "forget" this - or in the alternative, follow the progress in > solving this ? > > Kind regards, > > -- > Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 > Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: Tests of gcc development beyond its testsuite (in this case, for gfortran)
On Tue, May 7, 2024 at 11:31 AM Toon Moene wrote: > > On 5/7/24 00:02, Toon Moene wrote: > > > OK, perhaps on the aarch64 I need the following option to make the > > comparison fair: > > > > ‘rdma’ > > > > Enable Round Double Multiply Accumulate instructions. This is on by > > default for -march=armv8.1-a. > > > > I.e., -mno-rdma > > > > (I hope that's correct - I'll will try that when the Sun rises again and > > I have some power to run the AArch64 machine ...). > > Well, I did two independent runs with gfortran-13.2 and the following > options: > > -O3 -march=armv8.1-a+rdma > > and > > -O3 -march=armv8.1-a+nordma > > No difference in the number of error runs exceeding the prescribed > thresholds. > > So, unless I made a mistake in the option specification (or the compiler > silently ignored them because they were not applicable to my machine - > ugh), the cause of the problem lies elsewhere. AARCH64 armv8-a has FMA as part of its base ISA. So you want to try with `-ffp-contract=off` instead. RDMA turns on/off instructions which are not used by the auto-vectorizer (yet) and used by intrinsics for them (If I read the code correctly). Thanks, Andrew Pinski > > Kind regards, > > -- > Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 > Saturnushof 14, 3738 XG Maartensdijk, The Netherlands >
Re: How to add an additional option to dg-compile and dg-run
On Mon, Jul 29, 2024 at 1:20 AM Thomas Koenig wrote:
>
> Hi,
>
> for the fortran-unsigned branch, I would like to be able to run all
> existing Fortran tests also with -funsigned, to make sure the option
> does not break anything on existing code.
>
> Question is: How?
>
> I came as far as
>
> $ make check-fortran RUNTESTFLAGS="--target_board=unix/-funsigned"
>
> but that causes testsuite failures because C does not recognize
> the option.
>
> Any other possibilites?
Yes you could add it into the list of Torture options that
gfortran-dg-runtest uses.
Something like:
```
diff --git a/gcc/testsuite/lib/gfortran-dg.exp
b/gcc/testsuite/lib/gfortran-dg.exp
index fcba95dc396..0589d507382 100644
--- a/gcc/testsuite/lib/gfortran-dg.exp
+++ b/gcc/testsuite/lib/gfortran-dg.exp
@@ -153,6 +153,12 @@ proc gfortran-dg-runtest { testcases flags
default-extra-flags } {
} else {
set option_list [list { -O } ]
}
+ set old_option_list $option_list
+ set option_list {}
+ foreach option $option_list {
+ lappend option_list $option
+ lappend option_list "$option -funsigned"
+ }
set nshort [file tail [file dirname $test]]/[file tail $test]
list-module-names $test
```
should work but I am not 100% I got the TCL syntax correct.
Thanks,
Andrew Pinski
>
> Best regards
>
> Thomas
Re: Issue about buildpath introduced by -fintrinsic-modules-path option
On Thu, Oct 17, 2024 at 7:52 PM ChenQi wrote:
>
> Hi Fortran community,
>
> I recently got a buildpath issue when building libgfortran. I'm sending
> out email to this mailing list first, but if you think it's a bug
> instead of some expected behavior, please let me know and I'll file a bug.
>
> Here's the issue: the generated binary has buildpath in the
> DW_AT_producer section. Below are some output from 'readelf --debug-dump
> libgfortran.so.5.0.0'.
>
> """
>
> <0><1a37d3>: Abbrev Number: 4 (DW_TAG_compile_unit)
> <1a37d4> DW_AT_producer: (indirect string, offset:
> 0xd653): GNU Fortran2008 14.2.0 -m64 -march=core2 -mtune=core2 -msse3
> -mfpmath=sse -mshstk -g -O2 -O2 -fstack-protector-strong -fimplicit-none
> -fno-repack-arrays -fno-underscoring -fcf-protection=full
> -fallow-leading-underscore -fbuilding-libgfortran -fPIC
> -fintrinsic-modules-path
> /ala-lpggp72/qichen/Yocto/builds/build-poky/tmp/work/core2-64-poky-linux/libgfortran/14.2.0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../lib/x86_64-poky-linux/gcc/x86_64-poky-linux/14.2.0/finclude
> -fpre-include=../../../../recipe-sysroot/usr/include/finclude/math-vector-fortran.h
>
> """
>
> The problem is that this '-fintrinsic-modules-path' is not passed by me.
> Use some .o file as an example. Here's command to build out
> .libs/_mod_r17.o:
>
> """
>
> libtool: compile: x86_64-poky-linux-gfortran -m64 -march=core2
> -mtune=core2 -msse3 -mfpmath=sse -fstack-protector-strong -O2
> -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security
> --sysroot=../../../../recipe-sysroot -fcanon-prefix-map
> -fdebug-prefix-map=/ala-lpggp72/qichen/Yocto/builds/build-poky/tmp/work-shared/gcc-14.2.0-r0/gcc-14.2.0=/usr/src/debug/libgfortran/14.2.0
> -fdebug-prefix-map=/ala-lpggp72/qichen/Yocto/builds/build-poky/tmp/work/core2-64-poky-linux/libgfortran/14.2.0/gcc-14.2.0/build.x86_64-poky-linux.x86_64-poky-linux=/usr/src/debug/libgfortran/14.2.0
> -fdebug-prefix-map=/ala-lpggp72/qichen/Yocto/builds/build-poky/tmp/work/core2-64-poky-linux/libgfortran/14.2.0/recipe-sysroot-native=
> -DHAVE_CONFIG_H -I. -I../../../../../../../../work-shared/gcc-14.2.\
> 0-r0/gcc-14.2.0/libgfortran
> -iquote../../../../../../../../work-shared/gcc-14.2.0-r0/gcc-14.2.0/libgfortran/io
> -I../../../../../../../../work-shared/gcc-14.2.0-r0/gcc-14.2.0/libgfortran/../gcc
> -I../../../../../../../../work-shared/gcc-14.2.0-r0/gcc-14.2.0/libgfortran/../gcc/config
> -I/ala-lpggp72/qichen/Yocto/builds/build-poky/tmp/work/core2-64-poky-linux/libgfortran/14.2.0/gcc-14.2.0/build.x86_64-poky-linux.x86_64-poky-linux/x86_64-poky-linux/libgfortran/../.././gcc
> -I../../../../../../../../work-shared/gcc-14.2.0-r0/gcc-14.2.0/libgfortran/../libgcc
> -I/ala-lpggp72/qichen/Yocto/builds/build-poky/tmp/work/core2-64-poky-linux/libgfortran/14.2.0/gcc-14.2.0/build.x86_64-poky-linux.x86_64-poky-linux/x86_64-poky-linux/libgfortran/../libgcc
> -I../../../../../../../../work-shared/gcc-14.2.0-r0/gcc-14.2.0/libgfortran/../libbacktrace
> -I/ala-lpggp72/qichen/Yocto/builds/build-poky/tmp/work/core2-64-poky-linux/libgfortran/14.2.0/gcc-14.2.0/build.x86_64-poky-linux.x86_64-poky-linux/x86_64-poky-linux/libgfortran/../libbacktrace
> -I../libbacktrace -I . -Wall -Werror -fimplicit-none -fno-repack-arrays
> -fno-underscoring -fcf-protection -mshstk -fallow-leading-underscore
> -fbuilding-libgfortran -g -O2 -c
> ../../../../../../../../work-shared/gcc-14.2.0-r0/gcc-14.2.0/libgfortran/generated/_mod_r17.F90
> -fPIC -o .libs/_mod_r17.o
>
> """
>
> You can see that there's no '-fintrinsic-modules-path' there. This means
> that this '-fintrinsic-modules-path' is added automatically by gfortran.
> And the generated _mod_r17.o has buildpath encoded.
>
> I tried to add '-fintrinsic-modules-path=/not/exist', hoping that no
> extra '-fintrinsic-modules-path' option would be added, but it does not
> work.
>
> I searched the whole gcc source codes, and really cannot find any codes
> that adds this option automatically.
It comes from the fortran specs:
```
#define F951_OPTIONS"%(cc1_options) %{J*} \
%{!nostdinc:-fintrinsic-modules-path finclude%s}" \
TARGET_F951_OPTIONS \
"%{!fsyntax-only:%(invoke_as)}"
...
{"@f95",
"f951 %i %{E:%{!cpp:%egfortran does not support -E without -cpp}}\
%{cpp:" F951_CPP_OPTIONS ";: " CPP_FORWARD_OPTIONS "} \
%{!E:" F951_OPTIONS "}", 0, 0, 0},
```
I see the producer string should only have the saved options if
dwarf_record_gcc_switches is true which is the default.
You can turn that off with -gno-record-gcc-switches so build
directories don't show up.
Thanks,
Andrew Pinski
>
> Does someone know what's going on? Why is this
> '-fintrinsic-modules-path' added automatically? Is there any way to get
> rid of this buildpath?
>
> Thanks in advance.
>
> Regards,
>
> Qi
>
[PUSHED] fortran: Add default to switch in gfc_trans_transfer [PR117843]
This fixes a bootstrap failure due to a warning on enum values not being handled. In this case, it is just checking two values and the rest should are not handled so adding a default case fixes the issue. Pushed as obvious. PR fortran/117843 gcc/fortran/ChangeLog: * trans-io.cc (gfc_trans_transfer): Add default case. Signed-off-by: Andrew Pinski --- gcc/fortran/trans-io.cc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/gcc/fortran/trans-io.cc b/gcc/fortran/trans-io.cc index 906dd7c6eb6..9b0b8cfdff9 100644 --- a/gcc/fortran/trans-io.cc +++ b/gcc/fortran/trans-io.cc @@ -2664,6 +2664,8 @@ gfc_trans_transfer (gfc_code * code) case EXPR_FUNCTION: case EXPR_OP: goto scalarize; + default: + break; } } } -- 2.43.0
Re: [Linaro-TCWG-CI] gcc patch #105542: 12 regressions on arm
On Tue, Jan 28, 2025 at 10:32 AM Jerry D wrote: > > > Before I go clicking on links, is this legit? I presume patches are > getting checked before being pushed. Yes this is a legit email from the Linaro automation. And yes patches are being tested before they get pushed to help developers just in case things like this are missed. I don't see why arm would be different from any other target here though and why it is failing for arm only. Thanks, Andrew > > I do not have an arm based machine to test on. > > Regards, > > Jerry > > Forwarded Message > Subject: [Linaro-TCWG-CI] gcc patch #105542: 12 regressions on arm > Date: Tue, 28 Jan 2025 11:04:22 + (UTC) > From: ci_not...@linaro.org > Reply-To: linaro-toolch...@lists.linaro.org > To: jvdelis...@gmail.com > > Dear contributor, > > Our automatic CI has detected problems related to your patch(es). Please > find some details below. > > In gcc_check master-arm, after: >| gcc patch https://patchwork.sourceware.org/patch/105542 >| Author: Jerry D >| Date: Mon Jan 27 19:41:04 2025 -0800 >| | [patch, libfortran] PR114618 Format produces incorrect > output when contains 1x, ok when uses " " >| | Hello all, >| | The attached patch is part 1 of my effort to fix these > X and T edit >| ... 58 lines of the commit log omitted. >| ... applied on top of baseline commit: >| 846f08623b4 Remove ChangeLog entry that shouldn't be there. > > Produces 12 regressions: >| | regressions.sum: >| Running gfortran:gfortran.dg/dg.exp ... >| FAIL: gfortran.dg/char4_iunit_2.f03 -O0 execution test >| FAIL: gfortran.dg/char4_iunit_2.f03 -O1 execution test >| FAIL: gfortran.dg/char4_iunit_2.f03 -O2 execution test >| FAIL: gfortran.dg/char4_iunit_2.f03 -O3 -fomit-frame-pointer > -funroll-loops -fpeel-loops -ftracer -finline-functions execution test >| ... and 8 more > > Used configuration : > *CI config* tcwg_gcc_check master-arm > *configure and test flags:* --target arm-linux-gnueabihf > > If you have any questions regarding this report, please ask on > linaro-toolch...@lists.linaro.org mailing list. > > -8<--8<--8<-- > > The information below contains the details of the failures, and the ways > to reproduce a debug environment: > > You can find the failure logs in *.log.1.xz files in > * > https://ci.linaro.org/job/tcwg_gcc_check--master-arm-precommit/10959/artifact/artifacts/artifacts.precommit/00-sumfiles/ > The full lists of regressions and improvements as well as configure and > make commands are in > * > https://ci.linaro.org/job/tcwg_gcc_check--master-arm-precommit/10959/artifact/artifacts/artifacts.precommit/notify/ > The list of [ignored] baseline and flaky failures are in > * > https://ci.linaro.org/job/tcwg_gcc_check--master-arm-precommit/10959/artifact/artifacts/artifacts.precommit/sumfiles/xfails.xfail > > Current build : > https://ci.linaro.org/job/tcwg_gcc_check--master-arm-precommit/10959/artifact/artifacts > Reference build : > https://ci.linaro.org/job/tcwg_gcc_check--master-arm-build/3353/artifact/artifacts > > Warning: we do not enable maintainer-mode nor automatically update > generated files, which may lead to failures if the patch modifies the > master files.
Re: 15 is now at or very near release
On Thu, Apr 17, 2025 at 5:31 PM Jerry D wrote: > > I now see this in git: > > remotes/origin/releases/gcc-15 > > So we are at or very close to the release. Very close. See https://gcc.gnu.org/pipermail/gcc/2025-April/245943.html . Thanks, Andrew > > Cheers, > > Jerry
Re: gfc_char_t
On Sun, Jan 9, 2022 at 1:46 PM Harald Anlauf via Fortran wrote: > > Dear all, > > while working on a PR related to kind=4 character issues, I saw the > following in gfortran.h: > > > /* We need to store source lines as sequences of multibyte source > characters. We define here a type wide enough to hold any multibyte > source character, just like libcpp does. A 32-bit type is enough. */ > > #if HOST_BITS_PER_INT >= 32 > typedef unsigned int gfc_char_t; > #elif HOST_BITS_PER_LONG >= 32 > typedef unsigned long gfc_char_t; > #elif defined(HAVE_LONG_LONG) && (HOST_BITS_PER_LONGLONG >= 32) > typedef unsigned long long gfc_char_t; > #else > # error "Cannot find an integer type with at least 32 bits" > #endif > > > This seems to have been introduced by FX, but I do not really > understand it. Can't we use a fixed and platform-independent > type that can hold wide chars? Isn't a 32-bit / 4-byte type > sufficient? I suspect HOST_BITS_PER_INT will always be 32bit for all hosts GCC will be supported but who knows. The point of the check is to find a type which is at least 32bits enough to hold the wide character. HOST_BITS_PER_* are defined in hwint.h: #define HOST_BITS_PER_CHAR CHAR_BIT #define HOST_BITS_PER_SHORT (CHAR_BIT * SIZEOF_SHORT) #define HOST_BITS_PER_INT (CHAR_BIT * SIZEOF_INT) #define HOST_BITS_PER_LONG (CHAR_BIT * SIZEOF_LONG) #define HOST_BITS_PER_PTR (CHAR_BIT * SIZEOF_VOID_P) Where SIZEOF_* are defined while doing a configure and CHAR_BIT is defined in limits.h which is defined as a preprocessor constant. Does that help you understand the code better? Thanks, Andrew Pinski > > Thanks for any enlightenment, > Harald >
Re: [PATCH 4/5] value-range: Add as_string diagnostics helper
On Sat, Nov 12, 2022 at 3:47 PM Bernhard Reutner-Fischer via
Gcc-patches wrote:
>
> gcc/ChangeLog:
>
> * value-range.cc (get_bound_with_infinite_markers): New static helper.
> (irange::as_string): New definition.
> * value-range.h: New declaration.
>
> ---
> Provide means to print a value range to a newly allocated buffer.
> The caller is responsible to free() the allocated memory.
>
> Bootstrapped and regtested on x86_86-unknown-linux with no regressions.
> Ok for trunk?
>
> Cc: Andrew MacLeod
> Cc: Aldy Hernandez
> ---
> gcc/value-range.cc | 56 ++
> gcc/value-range.h | 3 +++
> 2 files changed, 59 insertions(+)
>
> diff --git a/gcc/value-range.cc b/gcc/value-range.cc
> index a855aaf626c..51cd9a38d90 100644
> --- a/gcc/value-range.cc
> +++ b/gcc/value-range.cc
> @@ -3099,6 +3099,62 @@ debug (const value_range &vr)
>fprintf (stderr, "\n");
> }
>
> +/* Helper for irange::as_string(). Print a bound to an allocated buffer. */
> +static char *
Can we start using std::string instead of char* here?
> +get_bound_with_infinite_markers (tree bound)
> +{
> + tree type = TREE_TYPE (bound);
> + wide_int type_min = wi::min_value (TYPE_PRECISION (type), TYPE_SIGN
> (type));
> + wide_int type_max = wi::max_value (TYPE_PRECISION (type), TYPE_SIGN
> (type));
> +
> + if (INTEGRAL_TYPE_P (type)
> + && !TYPE_UNSIGNED (type)
> + && TREE_CODE (bound) == INTEGER_CST
> + && wi::to_wide (bound) == type_min
> + && TYPE_PRECISION (type) != 1)
> +return xstrdup ("-INF");
> + else if (TREE_CODE (bound) == INTEGER_CST
> + && wi::to_wide (bound) == type_max
> + && TYPE_PRECISION (type) != 1)
> +return xstrdup ("+INF");
> + else
> + return print_generic_expr_to_str (bound);
No reason to do xstrdup any more either.
> +}
> +
> +
> +/* Return an irange as string. Return NULL on failure, an allocated
> + string on success. */
> +char *
Likewise.
Thanks,
Andrew Pinski
> +irange::as_string ()
> +{
> + char *ret = NULL;
This becomes std::string ret;
> + if (undefined_p() || varying_p () || m_num_ranges == 0)
> +return ret;
> +
> + for (unsigned i = 0; i < m_num_ranges; ++i)
> +{
> + tree lb = m_base[i * 2];
> + tree ub = m_base[i * 2 + 1];
> + /* Construct [lower_bound,upper_bound]. */
> + char *lbs = get_bound_with_infinite_markers (lb);
> + char *ubs = get_bound_with_infinite_markers (ub);
> + /* Paranoia mode */
> + if (!lbs)
> + lbs = xstrdup ("");
> + if (!ubs)
> + ubs = xstrdup ("");
> +
> + if (ret)
> + ret = reconcat (ret, ret, "[", lbs, ",", ubs, "]", NULL);
> + else
> + ret = concat ("[", lbs, ",", ubs, "]", NULL);
> +
> + free (lbs);
> + free (ubs);
> +}
> + return ret;
> +}
> +
> /* Create two value-ranges in *VR0 and *VR1 from the anti-range *AR
> so that *VR0 U *VR1 == *AR. Returns true if that is possible,
> false otherwise. If *AR can be represented with a single range
> diff --git a/gcc/value-range.h b/gcc/value-range.h
> index c87734dd8cd..76242e4bf45 100644
> --- a/gcc/value-range.h
> +++ b/gcc/value-range.h
> @@ -160,6 +160,9 @@ public:
>wide_int get_nonzero_bits () const;
>void set_nonzero_bits (const wide_int_ref &bits);
>
> + // For diagnostics.
> + char *as_string ();
> +
>// Deprecated legacy public methods.
>tree min () const; // DEPRECATED
>tree max () const; // DEPRECATED
> --
> 2.38.1
>
Re: Testsuite, dejagnu
On Mon, Jan 30, 2023 at 12:27 PM Harald Anlauf via Fortran wrote: > > Dear Hackers, > > is there a way to check that a particular warning is emitted only > once for a source code line instead of multiple times? > > It appears that by default dg-warn matches one or more times. One example of how to do this is located in testsuite/g++.dg/lookup/duperr1.C . I don't know if this is the best way of doing it though. Basically it uses dg-bogus to match the multiple warnings (since it is a regex over all output lines and `.*` will even match new lines) so you get a failure if there was a duplicated one and then dg-message to match the original message just to make sure it is outputted once (dg-message was because it was originally a note: rather than a warning/error but similar thing can be done for dg-error/dg-warning). Thanks, Andrew Pinski > > Thanks, > Harald >
Re: [PATCH v5 0/5] P1689R5 support
On Wed, Jan 25, 2023 at 1:07 PM Ben Boeckel via Fortran wrote: > > Hi, > > This patch series adds initial support for ISO C++'s [P1689R5][], a > format for describing C++ module requirements and provisions based on > the source code. This is required because compiling C++ with modules is > not embarrassingly parallel and need to be ordered to ensure that > `import some_module;` can be satisfied in time by making sure that any > TU with `export import some_module;` is compiled first. I like how folks are complaining that GCC outputs POSIX makefile syntax from GCC's dependency files which are supposed to be in POSIX Makefile syntax. It seems like rather the build tools are people like to use are not understanding POSIX makefile syntax any more rather. Also I am not a fan of json, it is too verbose for no use. Maybe it is time to go back to standardizing a new POSIX makefile syntax rather than changing C++ here. Thanks, Andrew Pinski > > [P1689R5]: https://isocpp.org/files/papers/P1689R5.html > > I've also added patches to include imported module CMI files and the > module mapper file as dependencies of the compilation. I briefly looked > into adding dependencies on response files as well, but that appeared to > need some code contortions to have a `class mkdeps` available before > parsing the command line or to keep the information around until one was > made. > > I'd like feedback on the approach taken here with respect to the > user-visible flags. I'll also note that header units are not supported > at this time because the current `-E` behavior with respect to `import > ;` is to search for an appropriate `.gcm` file which is not > something such a "scan" can support. A new mode will likely need to be > created (e.g., replacing `-E` with `-fc++-module-scanning` or something) > where headers are looked up "normally" and processed only as much as > scanning requires. > > FWIW, Clang as taken an alternate approach with its `clang-scan-deps` > tool rather than using the compiler directly. > > Thanks, > > --Ben > > --- > v4 -> v5: > > - add dependency tracking for imported modules to `-MF` > - add dependency tracking for static module mapper files given to > `-fmodule-mapper=` > > v3 -> v4: > > - add missing spaces between function names and arguments > > v2 -> v3: > > - changelog entries moved to commit messages > - documentation updated/added in the UTF-8 routine editing > > v1 -> v2: > > - removal of the `deps_write(extra)` parameter to option-checking where > ndeeded > - default parameter of `cpp_finish(fdeps_stream = NULL)` > - unification of libcpp UTF-8 validity functions from v1 > - test cases for flag parsing states (depflags-*) and p1689 output > (p1689-*) > > Ben Boeckel (5): > libcpp: reject codepoints above 0x10 > libcpp: add a function to determine UTF-8 validity of a C string > p1689r5: initial support > c++modules: report imported CMI files as dependencies > c++modules: report module mapper files as a dependency > > gcc/c-family/c-opts.cc| 40 +++- > gcc/c-family/c.opt| 12 + > gcc/cp/mapper-client.cc | 4 + > gcc/cp/mapper-client.h| 1 + > gcc/cp/module.cc | 23 +- > gcc/doc/invoke.texi | 15 ++ > gcc/testsuite/g++.dg/modules/depflags-f-MD.C | 2 + > gcc/testsuite/g++.dg/modules/depflags-f.C | 1 + > gcc/testsuite/g++.dg/modules/depflags-fi.C| 3 + > gcc/testsuite/g++.dg/modules/depflags-fj-MD.C | 3 + > gcc/testsuite/g++.dg/modules/depflags-fj.C| 4 + > .../g++.dg/modules/depflags-fjo-MD.C | 4 + > gcc/testsuite/g++.dg/modules/depflags-fjo.C | 5 + > gcc/testsuite/g++.dg/modules/depflags-fo-MD.C | 3 + > gcc/testsuite/g++.dg/modules/depflags-fo.C| 4 + > gcc/testsuite/g++.dg/modules/depflags-j-MD.C | 2 + > gcc/testsuite/g++.dg/modules/depflags-j.C | 3 + > gcc/testsuite/g++.dg/modules/depflags-jo-MD.C | 3 + > gcc/testsuite/g++.dg/modules/depflags-jo.C| 4 + > gcc/testsuite/g++.dg/modules/depflags-o-MD.C | 2 + > gcc/testsuite/g++.dg/modules/depflags-o.C | 3 + > gcc/testsuite/g++.dg/modules/modules.exp | 1 + > gcc/testsuite/g++.dg/modules/p1689-1.C| 18 ++ > gcc/testsuite/g++.dg/modules/p1689-1.exp.json | 27 +++ > gcc/testsuite/g++.dg/modules/p1689-2.C| 16 ++ > gcc/testsuite/g++.dg/modules/p1689-2.exp.json | 16 ++ > gcc/testsuite/g++.dg/modules/p1689-3.C| 14 ++ > gcc/testsuite/g++.dg/modules/p1689-3.exp.json | 16 ++ > gcc/testsuite/g++.dg/modules/
Re: [PATCH][stage1] Remove conditionals around free()
On Wed, Mar 1, 2023 at 1:31 PM Bernhard Reutner-Fischer via Fortran wrote: > > Hi! > > Mere cosmetics. > > - if (foo != NULL) > free (foo); > > With the caveat that coccinelle ruins replacement whitespace or i'm > uneducated enough to be unable to _not_ run the diff through > sed -e 's/^+\([[:space:]]*\)free(/+\1free (/' > at least. If anybody knows how to improve replacement whitespace, > i'd be interrested but didn't look nor ask. ISTM that leading > whitespace is somewhat ruined, too, so beware (8 spaces versus tab as > far as i have spot-checked). > > Would touch > gcc/ada/rtinit.c |3 +-- > intl/bindtextdom.c |3 +-- > intl/loadmsgcat.c|6 ++ > intl/localcharset.c |3 +-- intl is imported from glibc, though I don't know we have updated it in recent years from glibc. > libbacktrace/xztest.c|9 +++-- > libbacktrace/zstdtest.c |9 +++-- > libbacktrace/ztest.c |9 +++-- > libgfortran/caf/single.c |6 ++ > libgfortran/io/async.c |6 ++ > libgfortran/io/format.c |3 +-- > libgfortran/io/transfer.c|6 ++ > libgfortran/io/unix.c|3 +-- > libgo/runtime/go-setenv.c|6 ++ > libgo/runtime/go-unsetenv.c |3 +-- > libgomp/target.c |3 +-- > libiberty/concat.c |3 +-- This code is really old and only has gotten some modernization in recent years (post 8 years ago). > zlib/contrib/minizip/unzip.c |2 +- > zlib/contrib/minizip/zip.c |2 +- > zlib/examples/enough.c |6 ++ > zlib/examples/gun.c |2 +- > zlib/examples/gzjoin.c |3 +-- > zlib/examples/gzlog.c|6 ++ zlib is definitely imported from zlib upstream. So it might be good to check if we could import a new version and see if it still works instead. Thanks, Andrew Pinski > > coccinelle script and invocation inline. > Would need to be split for the respective maintainers and run through > mklog with subject changelog and should of course be compiled and > tested before that. > > Remarks: > 1) We should do this in if-conversion (?) on our own. >I suppose. Independently of -fdelete-null-pointer-checks > 2) Maybe not silently, but raise language awareness nowadays. >By now it's been a long time since this was first mandated. > 3) fallout from looking at something completely different > 4) i most likely will not remember to split it apart and send proper >patches, tested patches, in stage 1 to maintainers proper, so if >anyone feels like pursuing this, be my guest. I thought i'd just >mention it. > > cheers,
Re: [PATCH][stage1] Remove conditionals around free()
On Wed, Mar 1, 2023 at 3:52 PM Bernhard Reutner-Fischer wrote: > > On Wed, 1 Mar 2023 14:59:44 -0800 > Andrew Pinski wrote: > > > On Wed, Mar 1, 2023 at 1:31 PM Bernhard Reutner-Fischer via Fortran > > wrote: > > > > > > Hi! > > > > > > Mere cosmetics. > > > > > > - if (foo != NULL) > > > free (foo); > > > > > > With the caveat that coccinelle ruins replacement whitespace or i'm > > > uneducated enough to be unable to _not_ run the diff through > > > sed -e 's/^+\([[:space:]]*\)free(/+\1free (/' > > > at least. If anybody knows how to improve replacement whitespace, > > > i'd be interrested but didn't look nor ask. ISTM that leading > > > whitespace is somewhat ruined, too, so beware (8 spaces versus tab as > > > far as i have spot-checked). > > > > > > Would touch > > > gcc/ada/rtinit.c |3 +-- > > > > > > It's funny how you apparently did not comment that hunk in the end ;) No, I was just trying to make it look seperate from the intl hunk really. > > > > intl/bindtextdom.c |3 +-- > > > intl/loadmsgcat.c|6 ++ > > > intl/localcharset.c |3 +-- > > > > intl is imported from glibc, though I don't know we have updated it in > > recent years from glibc. > > i don't think we did, overdue, as we (probably) all know. > OTOH i'm thankful that we don't have submodules but a plain, manageable > repo. Of course that comes with a burden, which is nil if ignored > throughout. Doesn't always pay out too well longterm if nobody > (voluntarily) is in due charge. I looked and nobody has filed a bug report about merging from recent glibc sources for intl. Most likely because not many folks use code from intl any more as glibc is main libc that people use for development these days in GCC world. > > > > zlib/contrib/minizip/unzip.c |2 +- > > > zlib/contrib/minizip/zip.c |2 +- > > > zlib/examples/enough.c |6 ++ > > > zlib/examples/gun.c |2 +- > > > zlib/examples/gzjoin.c |3 +-- > > > zlib/examples/gzlog.c|6 ++ > > > > zlib is definitely imported from zlib upstream. > > So it might be good to check if we could import a new version and see > > if it still works instead. updating zlib is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105404 . Thanks, Andrew > > From a meta POV, i wonder where the trailing space in the subject comes > from, looking at e.g.: > https://gcc.gnu.org/pipermail/gcc-patches/2023-March/date.html#613110 > I think and hope that the newer(?) ones by > https://inbox.sourceware.org/gcc-patches/?t=xyz do not exhibit these > invented trailing blanks nobody ever wrote for real, does it. > > Thanks for reminding me of intl and it's outdatedness, although i > certainly don't have ambition to do anything about it for sure. > I didn't care 15 or 20 years ago and nowadays i'd call that attitude a > tradition, at least ATM ;) TBH i initially had only considered gcc/ but > somehow found that unfair. Great idea that inclusion was. > > thanks, > > > > 4) i most likely will not remember to split it apart and send proper > > >patches, tested patches, in stage 1 to maintainers proper, so if > > >anyone feels like pursuing this, be my guest. I thought i'd just > > >mention it. > > > > > > cheers, >
[PATCH] Fix fc-prototypes usage with C_INT64_T and non LP64 Targets.
The problem here is we were outputing long_long instead of
"long long". This was just an oversight and a missing check.
Committed as obvious after a bootstrap/test on x86_64-linux-gnu.
gcc/fortran/ChangeLog:
* dump-parse-tree.cc (get_c_type_name): Fix "long_long"
type name to be "long long". Add a comment on why adding
2 to the name too.
---
gcc/fortran/dump-parse-tree.cc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/fortran/dump-parse-tree.cc b/gcc/fortran/dump-parse-tree.cc
index 3b24bdc1a6c..f4490da6a19 100644
--- a/gcc/fortran/dump-parse-tree.cc
+++ b/gcc/fortran/dump-parse-tree.cc
@@ -3696,7 +3696,10 @@ get_c_type_name (gfc_typespec *ts, gfc_array_spec *as,
const char **pre,
if (c_interop_kinds_table[i].f90_type == ts->type
&& c_interop_kinds_table[i].value == ts->kind)
{
+ /* Skip over 'c_'. */
*type_name = c_interop_kinds_table[i].name + 2;
+ if (strcmp (*type_name, "long_long") == 0)
+ *type_name = "long long";
if (strcmp (*type_name, "signed_char") == 0)
*type_name = "signed char";
else if (strcmp (*type_name, "size_t") == 0)
--
2.17.1
Re: Hosting our gfortran MatterMost workspace
On Fri, Apr 28, 2023 at 8:32 AM Jerry D via Fortran wrote: > > Hello all and gcc overseers, > > I received a notice that the MasterMost server providers decided to drop > their free service. Unfortunate and understandable. > > I plan to contact the Open Software Lab folks at Oregon State University > to see if they can host for us. > > If anyone else has any suggestions of possible places we can host an > instance, please let me know. The software for the platform is open > source many folks self host, so we can do this. > > I am not sure where gcc.gnu.org is hosted, but that might be a logical > place. Take a look at https://sourceware.org/bugzilla/show_bug.cgi?id=29853 . gcc.gnu.org is currently hosted as part of sourceware so ... Thanks, Andrew > > Best regards, > > Jerry
Re: libsanitizer: sync from master
On Tue, Nov 15, 2022 at 7:47 AM Martin Liška wrote: > > Hi. > > I've just pushed libsanitizer update that was tested on x86_64-linux and > ppc64le-linux systems. > Moreover, I run bootstrap on x86_64-linux and checked ABI difference with > abidiff. This broke hwasan on aarch64. See https://gcc.gnu.org/PR109674 . Thanks, Andrew > > Pushed as r13-4068-g3037f11fb86eda. > > Cheers, > Martin
Re: Building Legacy Code and Intel Libraries
On Wed, May 17, 2023 at 1:15 PM Larry Lemons via Fortran wrote: > > Hello, > > I inherited a project where the customer wants us to re-build this ForTran > application with a more modern compiler. I did some research and found that > the GCC compiler probably has the most up to date compiler available, so we > decided to us 13.1.0 version of GCC. It has been about 40 years since I last > used Fortran, and very little at that time, and I didn't realize that there > were different libraries available based upon which compiler that was used at > the time. Apparently, from what I can tell from the research that I've done, > is it was last built using a MicroSoft compiler because of two of the > libraries that are used. From what I've read, Compaq had the compiler for a > time and now Intel has it. > > Anyway, since I was not the person who originally worked on this code, I am > not sure what functionality from the two libraries are being used, so I would > like to find the one or more libraries that are equivalent to the libraries > that are being used from the Intel libraries. From what I understand, the > libraries have been split up into more than one library since Intel took it > over, but all that I know is that the two libraries in question are DFPORT > and DFLIB. > > Can someone help me find the equivalent libraries in GCC that replace all of > the functionality in DFPORT and DFLIB or point me in a direction where I can > find this information? I've been trying to find it for the last 3 weeks and > have found a lot of things, but nothing I can use or that works. I've tried, > unsuccessfully, to use the Intel libraries, as well as trying to rebuild > them. If there aren't any equivalent libraries then I may need to work on > getting the Intel compiler added to the software list, which will take > another month or more. Please read https://gcc.gnu.org/legacy-ml/fortran/2010-04/msg00314.html for about DFPORT and gfortran. For DFLIB, you might need to re-implement some of it. It looks like it was Windows only even. Thanks, Andrew Pinski > > So any help would be very much appreciated. > > Thank you, > > Larry M. Lemons > Sr. Software Developer
[PATCH] libfortran: Fix build for targets that don't have 10byte or 16 byte floating point
So the problem here is EXPAND_INTER_MACRO_16 expands to nothing if 16 byte FP does not exist but we still add a comma after it and that causes a build failure. The same is true for EXPAND_INTER_MACRO_10 too. Committed as obvious after a bootstrap and test on x86_64-linux-gnu and aarch64-linux-gnu. libgfortran/ChangeLog: PR libfortran/110759 * ieee/ieee_arithmetic.F90 (COMP_INTERFACE): Remove the comma after EXPAND_INTER_MACRO_16 and EXPAND_INTER_MACRO_10. (EXPAND_INTER_MACRO_16): Add comma here if 16 byte fp exist. (EXPAND_INTER_MACRO_10): Likewise. --- libgfortran/ieee/ieee_arithmetic.F90 | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/libgfortran/ieee/ieee_arithmetic.F90 b/libgfortran/ieee/ieee_arithmetic.F90 index aa897abae39..debe40449f4 100644 --- a/libgfortran/ieee/ieee_arithmetic.F90 +++ b/libgfortran/ieee/ieee_arithmetic.F90 @@ -535,13 +535,13 @@ UNORDERED_MACRO(4,4) end interface #ifdef HAVE_GFC_REAL_16 -# define EXPAND_INTER_MACRO_16(TYPE,OP) _gfortran_ieee_/**/TYPE/**/_/**/OP/**/_16 +# define EXPAND_INTER_MACRO_16(TYPE,OP) _gfortran_ieee_/**/TYPE/**/_/**/OP/**/_16 , #else # define EXPAND_INTER_MACRO_16(TYPE,OP) #endif #ifdef HAVE_GFC_REAL_10 -# define EXPAND_INTER_MACRO_10(TYPE,OP) _gfortran_ieee_/**/TYPE/**/_/**/OP/**/_10 +# define EXPAND_INTER_MACRO_10(TYPE,OP) _gfortran_ieee_/**/TYPE/**/_/**/OP/**/_10 , #else # define EXPAND_INTER_MACRO_10(TYPE,OP) #endif @@ -549,8 +549,8 @@ UNORDERED_MACRO(4,4) #define COMP_INTERFACE(TYPE,OP) \ interface IEEE_/**/TYPE/**/_/**/OP ; \ procedure \ - EXPAND_INTER_MACRO_16(TYPE,OP) , \ - EXPAND_INTER_MACRO_10(TYPE,OP) , \ + EXPAND_INTER_MACRO_16(TYPE,OP) \ + EXPAND_INTER_MACRO_10(TYPE,OP) \ _gfortran_ieee_/**/TYPE/**/_/**/OP/**/_8 , \ _gfortran_ieee_/**/TYPE/**/_/**/OP/**/_4 ; \ end interface ; \ -- 2.31.1
Re: gfortran: error: unrecognized argument in option '-mcmodel=medium'
On Tue, Sep 26, 2023 at 11:39 PM Richard Biener via Fortran wrote: > > On Tue, Sep 26, 2023 at 4:44 PM Lingadahally, Vishakha (2023) > wrote: > > > > Dear GCC Team, > > > > I'm running Ubuntu 22 on my Mac virtually and my gfortran version is > > 11.4.0. When I try to install a certain software package, I encounter the > > following error: > > > > gfortran: error: unrecognized argument in option '-mcmodel=medium' > > gfortran: note: valid arguments to '-mcmodel=' are: large small tiny > > > > Is this due to attempting to run gfortran on arm64 architecture? Could you > > please let me know how I could resolve the issue? > > You have to turn to Ubuntu here, -mcmodel=medium is certainly > supported in GCC 11, maybe Ubuntu patches out > the support? Well -mcmodel=medium is the x86_64 specific option while they are trying to run on aarch64 which has a different set options. > > > > > Thank you > > > > Warm regards, > > Vishakha > > > > This email, its contents and any attachments are intended solely for the > > addressee and may contain confidential information. In certain > > circumstances, it may also be subject to legal privilege. Any unauthorised > > use, disclosure, or copying is not permitted. If you have received this > > email in error, please notify us and immediately and permanently delete it. > > Any views or opinions expressed in personal emails are solely those of the > > author and do not necessarily represent those of Royal Holloway, University > > of London. It is your responsibility to ensure that this email and any > > attachments are virus free.
Re: Test with an lto-build of libgfortran.
On Wed, Sep 27, 2023 at 11:28 PM Richard Biener via Fortran wrote: > > On Wed, Sep 27, 2023 at 11:48 PM Jeff Law via Fortran > wrote: > > > > > > > > On 9/27/23 12:21, Toon Moene wrote: > > > > > > > > The lto-ing of libgfortran did succeed, because I did get a new warning: > > > > > > gfortran -O3 -flto -flto-partition=none -static -o xlintstrfz zchkrfp.o > > > zdrvrfp.o zdrvrf1.o zdrvrf2.o zdrvrf3.o zdrvrf4.o zerrrfp.o zlatb4.o > > > zlaipd.o zlarhs.o zsbmv.o zget04.o zpot01.o zpot03.o zpot02.o chkxer.o > > > xerbla.o alaerh.o aladhd.o alahd.o alasvm.o ../../libtmglib.a > > > ../../liblapack.a ../../librefblas.a > > > In function 'xtoa_big', > > > inlined from 'write_z' at > > > /home/toon/compilers/gcc/libgfortran/io/write.c:1296:11, > > > inlined from 'formatted_transfer_scalar_write' at > > > /home/toon/compilers/gcc/libgfortran/io/transfer.c:2136:4: > > > /home/toon/compilers/gcc/libgfortran/io/write.c:1222:6: warning: writing > > > 1 byte into a region of size 0 [-Wstringop-overflow=] > > > 1222 | *q = '\0'; > > >| ^ > > > /home/toon/compilers/gcc/libgfortran/io/write.c: In function > > > 'formatted_transfer_scalar_write': > > > /home/toon/compilers/gcc/libgfortran/io/write.c:1291:8: note: at offset > > > [34, 4294967294] into destination object 'itoa_buf' of size 33 > > > 1291 | char itoa_buf[GFC_XTOA_BUF_SIZE]; > > >|^ > > > > > > which was (of course) not given with a non-lto libgfortran. > > Yea. This certainly can happen with LTO. These warnings would > > definitely be something worth investigating. > > > > Essentially the inlining enabled by LTO can expose a different set of > > diagnostics. > > This particular place in libgfortran has > > /* write_z, which calls xtoa_big, is called from transfer.c, > formatted_transfer_scalar_write. There it is passed the kind as > argument, which means a maximum of 16. The buffer is large > enough, but the compiler does not know that, so shut up the > warning here. */ > #pragma GCC diagnostic push > #pragma GCC diagnostic ignored "-Wstringop-overflow" > *q = '\0'; > #pragma GCC diagnostic pop > > so obviously the #pragma doesn't survive through LTO. Somehow I think > this is a known bug, but maybe I misremember (I think we are not streaming > any of the ad-hoc location parts). Yes it is a known bug. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80922 . Thanks, Andrew > > Richard. > > > > > Jeff
